(PUP-4476) Call lookup with the correct parameters

Prior to this commit, the lookup application was calling the internal
lookup function in a way that was compatible with the old version
of the function (eight parameters) rather than the current version
of the function (six parameters). This meant that attempts to use
the lookup application would fail due to the function being called
improperly.
Fix this issue and also remove a test that had too much stubbing
and was not longer useful.

I also think that Shaigy and I are seeing a but where the errors raised in run_command (e.g. when you don't include a node) are being raised but not appearing on the CLI. My guess is that puppet is putting them somewhere else, but I'm not sure what the correct way to raise an error is so that this doesn't happen.


STM32L4 ADC: Add injected channel support.

Summary
Added support for injected channel conversios on ADC driver.
Impact
Testing
Tested on nucleo-l432kc using adc example using the following configurations.
(1) ADC1 triggered by TIM1 channel 0
DMA disabled;
regular channels only;
Only ADC channell 11 is sampled.
PASS.

(2) ADC1 triggered by TIM1 channel 4
DMA disabled;
injected channels only;
Only ADC channell 11 is sampled.
PASS.

(3) ADC1 triggered by TIM1 channel 0
DMA enabled, circular mode;
regular channels only;
ADC channell 11 and 12 are sampled.
PASS.

Help is necessary to test on boards with more than one AD converter and using timers other than TIM1.

Thank you very much Daniel!


Add CMake ESP-IDF build file.

Add a top-level CMake project file to create a component for this repo.

Thanks!
I think once we add a Cmake file we should add a "general case" too. Something like here.
Do you agree?

Agreed. I also made one this weekend which builds for Linux and Windows. Unfortunately it looks like GitHub Workflows (or maybe lukka/run-cmake) don't support CMake's ExternalProject. I use that to clone and build LVGL. Once I have a clean solution to that problem I'll send out another PR.

Can we add the linked Cmake file too?

Hi @kisvegabor . Yes, I'm definitely going to complete the CMake file - as well as create a GitHub workflow. I want to make sure it does what you need. I created https://github.com/lvgl/lv_lib_split_jpg/issues/24, as I expect a few questions. If you're OK with what I propose there, then I'll complete the work. As part of this effort I plan on making the example fully buildable. Also, once we're happy with the CMake file then I can do the same work in other LVGL projects. I'll close this PR as this component CMake file has landed.


RFC for hashtags

#18 introduces /slashlinks. We might consider uses for #hashtags and @mentions as well.
Really, either of these usecases could be accomplished via slashlinks, so these amount to a separate namespaces. There may be value in them anyhow.
Notes and questions:

Hashtags could conceptually link to collections, or queries, rather than documents. The distinction is fuzzy in Subconscious, but there are ways we could leverage this.
One could use hashtags to tag blocks. This could be used to e.g. grab all blocks with a specific tag
Slashlinks have an obvious mapping to URLs, where adding an origin to namespace them makes them valid URLs. It's less clear how #hashtags and @mentions should unambiguously map to URLs.
Subconscious does not have a concept of identity or person right now. Should it? I'm not so sure. I think the key-management paradigm is a better one, with any username style abstraction being layered on top. However, other uses for Subtext may

Observations:

Tags are semantic triples without predicates (the subject is the document)
Tags are backlinks to pages that don't exist

Just digging up another file - https://github.com/subconsciousnetwork/subtext/blob/main/explorations/hashtags.md -

Hashtags
We could explore expanding Subtext to include support for hashtags in text blocks:

There’s no such thing as advantageous in a general sense. It’s advantageous in the circumstances you’re living in. #evolution #ecology

Hashtags could be collected into a "tags" field of text blocks, and perhaps stripped from the text as well.
OTOH: Tags are just a backlinks to pages that don't exist. To use an OODA lens, tagging is O without ODA. Collecting into tagged buckets is not sense-making, only a coarse-grained first approximation. Sense-making should fold into Orientation, and make it possible to expand your repertoire of Actions. That means synthesizing collected information into new knowledge. This is something linking supports, and tags do not. So if we have to choose one primitive, Wikilinks are the better primitive.

I like the equivalence of /foo-bar, and [[Foo bar]] that you've mentioned.
One question is - when would a client render a transclusion? I guess when it's on a line by itself?
e.g.
# Some heading /evolution

Here is a pic of a turtle -
/turtle.jpg

Hashtags might be useful because they seem to have a slightly different meaning than a slashlink. A hashtag is like "file this item under evolution", or "this item is a book", while a link is like "see also this article", or "include this iamge below"?
It goes back to the issue of anchor links in html - what do they mean exactly? ie what kind of relationship is it?
There is the 'rel' attribute for 'a' elements - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-rel

The relationship of the linked URL as space-separated link types.

https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types

alternate
external
help
search
Indicates that the hyperlink references a document whose interface is specially designed for searching in this document, or site, and its resources.
tag
Indicates that the hyperlink refers to a document describing a tag that applies to this document.
up
Indicates that the page is part of a hierarchical structure and that the hyperlink leads to the higher level resource of that structure.

So having a hashtag available would give some more meaning to a link.
Same for @ signs.
And editors could also use them in restricting the namespace for autocomplete, eg in github # starts autocomplete for issues, @ for people.

Or, what if could assign an optional link type to slashlinks? eg
/person:gibson
/tag:evolution
so @gibson and #evolution would be shorthand for those.
And maybe link types could be user-defined? eg
/author:gibson
/type:fish
So they would make different namespaces, useful for autocomplete.
And those could have corresepondence with links in the header? eg
author: /gibson
type: /fish

Another issue would be assigning properties to links, to be able to make complete property graphs - maybe assign key:values like
# love and the pilgrim
/artist:burne-jones
/date:1896-7
/location:tate{since:1942}

I think that hashtags (in the context of KM) are best employed when they have a clear "is-a" meaning. In my experience, using them for other purposes leads to ambiguity and cognitive overhead.
"Gödel, Escher, Bach" is a #book about /computer-science and /consciousness written by /douglas-hofstadter. (How that other info could be structured is another matter).
I don't know how opinionated Subconscious should be on this, but I've seen other apps incentivizing this practice by rewarding it with extra functionality.

It should also be considered that with the current spec, hashtags at the beginning of a line are not possible, as it would turn the block into a heading.

Note that the space after the sigil characters is NOT part of the sigil and is optional, but recommended.
# This is a heading
#This is also a heading


Fix the table element overflow

I have tried to add a horizontal-scrollable div mdx component for table wrapper that could fix the table overflow
It's a solution for #776

Mind running the code through prettier to format it? Thanks

Thanks for the fix, closes https://github.com/timlrx/tailwind-nextjs-starter-blog/issues/776


Need to support pass through of the the proxies keyword to the requests

Trying to use this behind the corporate firewall.   I need to be able to set the proxies paramaeter to the requests session

@dwmoran5104 Checkout my add-proxies-to-requests-session branch. This should solve it. Let me know if it works for you. Thanks.

@juanbrena Could you please create a merge request for this please?


Some images have important data outside of partitions or partition tables.

Like Variscite DART-6UL for example.
It's a flashed type device.
When preloading this type of image, the preload script needs to recreate a disk image in order to be able to move partitions after the root partition (which needs to be resized).
This process creates the new partition table using sfdisk and then copies the partitions from the old image to the new one.
This means that data outside of partitions is not copied.
As https://community.nxp.com/docs/DOC-95015 says,

U-boot should reside at offset 1024B of your SD card.

We need to copy data between the partition table and the first partition to the new image.

ping @jhermsmeier and @jviotti - this is obviously something to be aware of in Etcher too, when we add the "dynamic blockmap" code and ignore any non-partitioned diskspace.


Allow customers to parse certificate, key, and secret IDs from URLs

We will add methods to parse URLs into VaultUri, Collection, Name, and optional Version components for Certificates, Keys, and Secrets

Due to the complexity of doing this across Key Vault libraries and the simplicity of our internal parsing code, I'm closing this issue until there's a compelling reason to tackle its complexities. In the meantime, we can direct users to our internal parsing code and, if there's enough demand, add a sample demonstrating the same.


Update data-access.md

Added "have" :)

You may disregard these recommendations if you used the Edit on GitHub button from dvc.org to improve a doc in place.

❗ Please read the guidelines in the Contributing to the Documentation list if you make any substantial changes to the documentation or JS engine.
🐛 Please make sure to mention Fix #issue (if applicable) in the description of the PR. This causes GitHub to close it automatically when the PR is merged.
Please choose to allow us to edit your branch when creating the PR.
Thank you for the contribution - we'll try to review it as soon as possible. 🙏

thanks, merged the restyled version of this PR https://github.com/iterative/dvc.org/pull/1829 !


Record parseable interface imports in the debug info.

When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface.  By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
(cherry picked from commit 8d03cb7a6124b8ec78ea6aea755e88972196183d)

@swift-ci test and merge


hi, can add text similarity, percentage?

I don't think this package would be suitable for calculating that; you can use the Levenshtein distance algorithm then divide that by the total number of words.. see: https://stackoverflow.com/questions/6087281/similarity-score-levenshtein
If you want to calculate the % of different words, you can use this package by counting the number of elements returned from  GenerateDiffOutput and then dividing that by the number of words (similar concept to above).


Fix external semaphore test when exportability is not supported

An implementation may not support exportable semaphore, subtests available in cl_khr_external_semaphore assumes support for exportable semaphore, resulting in failure on such implementation. Allow implementations to use importable semaphore in such cases.

Merging as discussed in the September 3rd memory subgroup.


rm unnecessary quotes

PR to remove unnecessary quotes

Codecov Report

Merging #29 (31c8bdd) into main (edd4f3d) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #29   +/-   ##
=======================================
  Coverage   13.58%   13.58%
=======================================
  Files          10       10
  Lines         508      508
=======================================
  Hits           69       69
  Misses        430      430
  Partials        9        9

/approve


Cannot read property '0' of undefined

I am getting the following error when trying to consume wsdl
/home/dc-user/myproject/node_modules/soap/lib/wsdl.js:720
for (var i = 0, child; child = children[i]; i++) {
^
TypeError: Cannot read property '0' of undefined
at ServiceElement.postProcess (/home/dc-user/myproject/node_modules/soap/lib/wsdl.js:720:40)
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1035:26
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1134:7
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1134:7
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1134:7
at WSDL._processNextInclude (/home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1115:12)
at null.callback (/home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1133:10)
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1070:12
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1134:7
at /home/dc-user/myproject/node_modules/soap/lib/wsdl.js:1134:7

At wsdl.js: 720 I tried to put in
if(!children) {
return;
}
then I am getting a different error message. It was not able to identify functions that are available for me to consume
client.describe does not give any functions.

hard to say what's causing the issue/error without the WSDL itself (please, shorten if possible!).

Closing for lack of activity.  Please open a PR with a fix if there is a defect.


Sunbeam Heating Bedding (Blanket) (unsupported)

Device normal info

Sunbeam
Dual Zone (Queen / King) Connected Heating Bedding (Blanket)

Device info (please complete the following information, which can be found in log):
like this:
I need some help here, I looked and could not find any similar entries in the log.
Device specifications (please complete the following information, which can be found in log):
Same device's id, like this:
I need some help here again, as I don't see this information in the logs. I do have access to debuging on Tuya's dev site, but not sure what is needed.

It appears that this works with LocalTuya if you want to try that. Here is a post about how to set it up.
https://community.home-assistant.io/t/integration-with-sunbean-wifi-heated-mattress-pad/362588/3

Thanks, I will look into it.

Yesterday, Home Assistant 2022.2 was released and it contains a new diagnostic tool.
There is now a "Download Diagnostics" button on each Tuya device on the device page. Clicking that button will download diagnostics information for that specific device. Drag the downloaded file into this issue.
This will help us learn about your device and provide details for implementing/adding support.
Thanks!

Wow, now that is a VERY useful new feature, especially for those of us who are new to all this.
tuya-94ee0895011d98ae6c551589e95c4fac-Sunbeam Bedding-ea7b903bfd965562651b9953e47dbcbf.json.txt

Thanks for sharing that @RJ-Make! That is extremely helpful. I will add this to my list of things to do and fix.

Looked at this, is seems like this device is not following the documented standards:
https://developer.tuya.com/en/docs/iot/f?id=K9gf45zyt7sco
For example, according to specifications, it should provide a temperature setting, but your device doesn't.
For that reason, I'm at this point unsure how to support or implement this device.

I see what you're saying. The blanket doesn't have an actual temp setting, It uses temp Levels.  L, 2 through 9, H. I believe 1 is low and 10 is High
Anyway, thanks for looking into it.

If this works in LocalTuya, does that mean it might eventually be supported by the actual Core integration?

If this works in LocalTuya, shouldn’t there be a way to get it working in the actual Core integration?

You would think so.

Here are the entities if this helps, @frenck
entities:
- platform: switch
friendly_name: Master Power
id: 1
- platform: switch
friendly_name: Side A Power
id: 14
- platform: switch
friendly_name: Side B Power
id: 15
- platform: switch
friendly_name: Master Preheat Power
id: 8
- platform: switch
friendly_name: Side A Preheat
id: 24
- platform: switch
friendly_name: Side B Preheat
id: 25
- platform: select
friendly_name: Master Heat Level
id: 4
select_options: level_1;level_2;level_3;level_4;level_5;level_6;level_7;level_8;level_9;level_10
select_options_friendly: 1;2;3;4;5;6;7;8;9;10
- platform: select
friendly_name: Side A Heat Level
id: 20
select_options: level_1;level_2;level_3;level_4;level_5;level_6;level_7;level_8;level_9;level_10
select_options_friendly: 1;2;3;4;5;6;7;8;9;10
- platform: select
friendly_name: Side B Heat Level
id: 21
select_options: level_1;level_2;level_3;level_4;level_5;level_6;level_7;level_8;level_9;level_10
select_options_friendly: 1;2;3;4;5;6;7;8;9;10
- platform: select
friendly_name: Side A Set Timer
id: 26
select_options: (30m;1h;1h30m;2h;2h30m;3h;3h30m;4h;4h30m;5h;5h30m;6h;6h30m;7h;7h30m;8h;8h30m;9h;9h30m;10h;Stay_On)
select_options_friendly: (.5 hours;1 hour;1.5 hours;2 hours;2.5 hours;3 hours;3.5 hours;4 hours;4.5 hours;5 hours;5.5 hours;6 hours;6.5 hours;7 hours;7.5 hours;8 hours;8.5 hours;9 hours;9.5 hours;10 hours;24 hours)
- platform: select
friendly_name: Side B Set Timer
id: 27
select_options: (30m;1h;1h30m;2h;2h30m;3h;3h30m;4h;4h30m;5h;5h30m;6h;6h30m;7h;7h30m;8h;8h30m;9h;9h30m;10h;Stay_On)
select_options_friendly: (.5 hours;1 hour;1.5 hours;2 hours;2.5 hours;3 hours;3.5 hours;4 hours;4.5 hours;5 hours;5.5 hours;6 hours;6.5 hours;7 hours;7.5 hours;8 hours;8.5 hours;9 hours;9.5 hours;10 hours;24 hours)
- platform: sensor
friendly_name: Side A Auto Off Timer
id: 28
unit_of_measurement: "seconds"
- platform: sensor
friendly_name: Side B Auto Off Timer
id: 29
unit_of_measurement: "seconds"

I created a pull request to add support for the sunbeam heated mattress pad (https://github.com/home-assistant/core/pull/84869).  It looks like my Sunbeam dual zone mattress pad uses the same configuration as the blanket.
You can test this locally by copying the homeassistant/components/tuya folder from that pull request (branch) to your installations custom components folder and restarting.

Side A Auto Off Timer

This saved me an immense amount of work. Thank you very much for adding this


Update config.yaml for new translation languages

Changes
Added new keys to the locales list in config.yaml following to this translation guide.

Implementation details

How to read this PR

Screenshots

I noticed that these languages are not ready based on the preview site made by this PR. So I will close this.


How to use requestConnectionPriority?

I'm trying to use requestConnectionPriority but cannot find a way to call the method on the client.
I read #36 and the attached pull request !125 and tried peripheral.requestConnectionPriority(Priority.High) with no success on v0.18.0.
I might be wrong but I'm guessing the method is missing in the Peripheral interface though it is implemented in the AndroidPeripheral Class.
Is there something I'm missing? Thanks in advance!

Oh. 🤦
I think the CoroutineScope.peripheral extension functions on Android need to return AndroidPeripheral rather than Peripheral interface. I'll investigate if that is the best approach.
As a workaround, can you (on Android only) cast to AndroidPeripheral until I've had a chance to update the extension functions?
val peripheral = scope.peripheral(..) as AndroidPeripheral

Thanks for your answer, your point looks consistent... Unfortunate!
I did cast it and can now access the interface.
(_peripheral as AndroidPeripheral).requestConnectionPriority(Priority.High)

Thanks again!

It appears that changing the return type to AndroidPeripheral isn't a viable option:

At least not for the CoroutineScope.peripheral extension function that is available to common (expect / actual) code.
Making only some of the CoroutineScope.peripheral extension functions return AndroidPeripheral makes for an inconsistent API (and can be confusing for newcomers to the library).
A CoroutineScope.androidPeripheral (on Android only) could be introduced, but that feels like it unnecessarily increases the API surface, which I'd prefer to avoid. Unless I can think of a compelling reason(s), it is probably best to expect library consumers to create their own CoroutineScope.androidPeripheral (or similar) extension function (that performs the cast), or perform the cast at the usage site.
Unless a similar "connection priority" functionality can be configured on the other platforms (then a common function could be provided on Peripheral interface) — but I'm not aware of a similar functionality for Apple or JS. 😞
Apologies, I'm not aware of a better solution.

Well, the casting does the job at least, no worries.
I did successfully call it and yeah... Seems like it's working better (seems!)
The thing that the method is Android only and does return only an ACK instead of a complete calback is really confusing and tells a lot in itself how hacky it is (thanks Android team😅)
The "right" way in my mind would be to add it to the PeripheralBuilder constructor in an onConnection callback and make it does nothing for js & apple platforms (basically the same way requestMtu works).
Something like:
val peripheral = scope.peripheral(advertisement) {
    onConnection {
        requestConnectionPriority(Priority.High)
    }
}

That said, that's working as-is and I feel like a short note in the docs would be sufficient to avoid the refactor.
Thanks again for your help anyway!


update: docker

Name: app-containers/docker
CVEs: CVE-2024-24557, https://github.com/moby/moby/security/advisories/GHSA-xw73-rw38-6vjc
CVSSs: 6.9 (Medium)
Action Needed: Update to 24.0.9 or higher. 20.x will not be patched by upstream.
Summary: In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered a valid cache candidate for some build steps.
refmap.gentoo: TBD

The latest sysext bakery release ships a Docker sysext that includes a fix (docker 24.0.9): https://github.com/flatcar/sysext-bakery/releases/tag/latest. Using the sysext can mitigate the issue until we publish new OS releases later in February.
Check out the readme in the sysext bakery https://github.com/flatcar/sysext-bakery as well as our documentation on sysexts https://www.flatcar.org/docs/latest/provisioning/sysext/ for more information

Next alpha, beta and stable will have docker 24.0.9.


Doc: update Pull_Request template for contributor

See: Discussion#20 http://github.com/orgs/cloudberrydb/discussions/20

Change logs
Update the contributor's checklist type from a bulleted list to a task list, so that contributors can check them before/when they submit PRs.
Why are the changes needed?
For a better check to contributors.
Does this PR introduce any user-facing change?
No, no changes to the core code.
How was this patch tested?
Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.
Contributor's Checklist
Here are some reminders before you submit the pull request:

Document changes
Communicate in the GitHub Issues or Discussions (list them if needed)
Add tests for the change
Pass make installcheck
Pass make -C src/test installcheck-cbdb-parallel

Hi @tuhaihe Please don't use merge for first commit in your pull request. We need to keep git history linear.

Hi @tuhaihe Please don't use merge for first commit in your pull request. We need to keep git history linear.

Use rebase instead.

Got it, thanks! @my-ship-it @avamingli

I dropped the merge history and rebased my commit, PTAL again! @avamingli


VenusOS MQTT is reporting incorrect Cell Temperature Min (Tmin) and Cell Temperature Max (Tmax) values.

The setup
A 16-cell battery is equipped with a 123SmartBMS, connected to a Raspberry Pi 4 via the "123/Smart BMS to USB cable." The Raspberry Pi is running the latest stable version (small image) of VenusOS, with the 123Smart BMS Victron integration installed.
The installation command used without the need of a USB stick:
ssh<EMAIL_ADDRESS>'wget -qO - https://123electric.eu/downloads/123smartbmstousb/venus-data.tar.gz | tar -xzf - -C /data && reboot'

The Problem
When viewing individual cell temperatures on my phone, all the boards report a cell temperature of 3°C.

However, when I subscribe to the MQTT broker on the Raspberry Pi running VenusOS, I see Tmin and Tmax values of 2.0°C and 5.0°C, respectively. This is wrong.

Hi,
There is a software filter in the app which filters the temperature a little. When all temperature values in the app are near each other, the displayed temperature value is compensated. This was needed for older generation 123\SmartBMS (gen1 and gen2) which had a fluctuating temperature.
The Victron GX MQTT values display the unfiltered values.
For gen3, we will disable this software filter in the 123\SmartBMS app.


[MM-39652] Fix missing suggestion when CRT is on

Summary
This PR fixes missing run suggestions when CRT is on
Ticket Link
Fixes: https://mattermost.atlassian.net/browse/MM-39652
Checklist

[ ] Telemetry updated
[ ] Gated by experimental feature flag
[X] Unit tests updated

I suggest getting buy-in from the channels team on the proposed solution for fixing ephemeral messages in threads and we spend the mana to implement it. Presumably this issue contributes to the delay in general availability of collapsed reply thread so it'd be helpful for everyone.

 Please review the PR again @crspeller @agarciamontoro , it is working now.


Fix time conversion

With EF Core 6 and Npgsql 6 DateTimes can only be saved in UTC format. In order to fix that for all possible modules, the UOW will now check for DateTimes before it calles DbContext.SaveChanges().
Additionally DateTimes where forgotten in the EntryConvertGenerator. Because of that it wasn't possible for Resources and Products to have DateTime properties. These properties would always be set to the default value.

Do we have any idea, how this will impact performance. I would prefer something that more precisely targets the date time properties instead of iterating over all properties on all entities during saving.
Thinking about it: Maybe we just make it mandatory for user code to do the conversion, right at the time when needed. Yes, this will be more work, but seams like the proper solution. We already have Storage classes for most models, so that should be an isolated issue.

@dbeuchler that is even better. Less redundant code and it does not iterate all properties of all entities on every write.

With EF Core 6 and Npgsql 6 DateTimes can only be saved in UTC format.

We found that, do you have different information?

With EF Core 6 and Npgsql 6 DateTimes can only be saved in UTC format.

We found that, do you have different information?

Both is possible, but it has to be defined as I understand. In the docs I found just

Starting with 6.0, Npgsql maps UTC DateTime to timestamp with time zone , and Local/Unspecified DateTime to timestamp without time zone`

and

In versions prior to 6.0 (or when Npgsql.EnableLegacyTimestampBehavior is enabled), reading a timestamp with time zone returns a Local DateTime instead of Utc.

In versions prior to 6.0 (or when Npgsql.EnableLegacyTimestampBehavior is enabled), DateTime is always written as timestamp without time zone.

I am using the Npgsql.EnableLegacyTimestampBehavior in connection to the extension. But currently I am also not too deep in topic.
For this MR I would say providing all options is a good idea but for the postgres integration a custom behaviour could be applied.

Additionally: We had a couple of issues in the past when analyzing the database we had different timestamps for Created vs ActivityStarted with timezone gaps.
I think that's why we decided to have all timestamps as UTC, but maybe we take the annotation and just apply it to our databases first.

Additionally: We had a couple of issues in the past when analyzing the database we had different timestamps for Created vs ActivityStarted with timezone gaps.
I think that's why we decided to have all timestamps as UTC, but maybe we take the annotation and just apply it to our databases first.

Yes I know this problem - using DateTime.UtcNow at every point would be a good starting point and additionally apply the annotation to all MORYX models sounds good. Forcing UTC for every model, on the other hand is not a good idea, this should be the decision of the developer what is required for his use-case.


Add FreeBSD support

This PR contains  changes to support to FreeBSD.

Add a register_probes!() macro, which insert a noop call to a extern function, which argument referencing the set_dtrace_probes section, this prevents the probes from being gc by lld
Enable standard backend for FreeBSD if on nightly or if link-dead-code is set.
Perform null check on dli_fname and dli_sname as they can be null
on some platforms.
Enable some existing linker workaround on FreeBSD
Changes to support FreeBSD specific ioctl

Added FreeBSD specific fields to dof_helper
Use FreeBSD specific ioctl value

Currently support FreeBSD targets with nightly toolchain, as well as stable toolchain if link-dead-code is set in RUSTFLAGS
There is a linker related issue that make the FreeBSD support preliminary
and limited that crate consumers on FreeBSD need to build binary with
-C link-dead-code=yes
Without this workaround , the linker will omit some symbols and complain
about __start_set_dtrace_probes not found.
A nightly feature, #[used(linker)] is available to fix the issue of linker
omitting __(start|stop)_set_dtrace_probes;  It however does not
prevent the linker throwing the probes generated by the provider macros
away. The -C link-dead-code=yes is therefore currently necessary
regardless of the availability of used_with_arg

Hi @michael-yuji, thanks for sending this patch! It's good to see broader platform support.
In general the patch looks fine, however I have a few questions and concerns about the details. I'll comment on specific lines as appropriate, but overall it seems like there are several contortions required to prevent the FreeBSD linker from throwing the probe section into the trash. I think these can be simplified, but I don't have a FreeBSD system to test that on. Hopefully we can iterate together.
Last, would you mind including some details on how you tested the code? Output showing some of the example or integration test probes firing would be excellent. Thanks!

@bnaecker I have been testing mostly with a dummy project implemented some probes right now, however, I do just find out some issues regarding my patch, that when probes are defined outside the mod main lives, lld is still able to throw out the probes.
Regarding of unit tests there are a few issue I am having, the main one is that unlike on Illumos, dladdr does not able to extract the current function names and friends, attached is a result of does-it-work
running 1 test
test tests::test_does_it_work ... FAILED

failures:

---- tests::test_does_it_work stdout ----
   ID   PROVIDER            MODULE                          FUNCTION NAME
85654 doesit94425 does_it_work-733877c2fa8bfdc9                        ?0x128af37 work

	Probe Description Attributes
		Identifier Names: Internal
		Data Semantics:   Internal
		Dependency Class: Unknown

	Argument Attributes
		Identifier Names: Internal
		Data Semantics:   Internal
		Dependency Class: Unknown

	Argument Types
		args[0]: uint8_t
		args[1]: char *

thread 'tests::test_does_it_work' panicked at 'Mangled function name appears incorrect: ?0x128af37', tests/does-it-work/src/main.rs:94:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    tests::test_does_it_work

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.14s
``

@bnaecker seems like you have the details well in hand, but I wanted to add that it would be good to add CI for FreeBSD if we can either using a built-in action or buildomat... somehow...

@ahl @bnaecker Turns out I am a joke and the fix for FreeBSD is quite trivial, seems like recent LLVM and GNU both added support for the "R" section flag, which prevents the section from GC. Therefore the horrible macro hack is not needed at all.
Still need used_with_arg to prevent __(start|stop)_set_dtrace_probes from missing, however.
Reference:
https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001191.html
unit test results except test_compile_errors:
test tests::test_does_it_work ... FAILED

failures:

---- tests::test_does_it_work stdout ----
   ID   PROVIDER            MODULE                          FUNCTION NAME
85654 doesit21421 does_it_work-ec75ae5d51b02d06                        ?0x10b4909 work

	Probe Description Attributes
		Identifier Names: Internal
		Data Semantics:   Internal
		Dependency Class: Unknown

	Argument Attributes
		Identifier Names: Internal
		Data Semantics:   Internal
		Dependency Class: Unknown

	Argument Types
		args[0]: uint8_t
		args[1]: char *

thread 'tests::test_does_it_work' panicked at 'Mangled function name appears incorrect: ?0x10b4909', tests/does-it-work/src/main.rs:94:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    tests::test_does_it_work

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.08s

    Finished test [unoptimized + debuginfo] target(s) in 0.12s
     Running unittests src/main.rs (target/debug/deps/argument_types-3e47aa3fb9f42b47)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/compile_errors-3946579ff3e35045)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/does_it_work-ec75ae5d51b02d06)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/dof-ee37c50d83ec6a43)

running 1 test
test ser::test::test_padding ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/dtrace_parser-aa5be91b87495e32)

running 37 tests
test tests::test_basic_tokens::case_3 ... ok
test tests::test_bad_basic_token - should panic ... ok
test tests::test_basic_tokens::case_1 ... ok
test tests::test_basic_tokens::case_4 ... ok
test tests::test_basic_tokens::case_6 ... ok
test tests::test_data_type_enum::case_01 ... ok
test tests::test_basic_tokens::case_5 ... ok
test tests::test_basic_tokens::case_2 ... ok
test tests::test_data_type_enum::case_02 ... ok
test tests::test_data_type_conversion ... ok
test tests::test_basic_tokens::case_7 ... ok
test tests::test_data_type_enum::case_03 ... ok
test tests::test_data_type_enum::case_04 ... ok
test tests::test_data_type_enum::case_05 ... ok
test tests::test_comment_provider ... ok
test tests::test_data_type_enum::case_07 ... ok
test tests::test_data_type_enum::case_06 ... ok
test tests::test_data_type_enum::case_10 ... ok
test tests::test_data_type_enum::case_11 ... ok
test tests::test_data_type_enum::case_08 ... ok
test tests::test_data_type_enum::case_09 ... ok
test tests::test_data_type_enum::case_13 ... ok
test tests::test_data_type_enum::case_12 ... ok
test tests::test_data_type_enum::case_15 ... ok
test tests::test_data_type_enum::case_14 ... ok
test tests::test_data_type_enum::case_16 ... ok
test tests::test_data_type_enum::case_17 ... ok
test tests::test_data_types ... ok
test tests::test_basic_provider ... ok
test tests::test_identifier ... ok
test tests::test_null_provider ... ok
test tests::test_probe ... ok
test tests::test_probe_struct_parse ... ok
test tests::test_pragma_provider ... ok
test tests::test_provider_struct ... ok
test tests::test_two_providers ... ok
test tests::test_file_struct ... ok

test result: ok. 37 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/dusty-25bf72e11a140ff9)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/empty-457f2d06cbc03ba7)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/fake_cmd-0876ad23a5a11590)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/fake_lib-b7392c3f8f88aea3)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/modules-1fa27ec5d7a593c6)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_attr-ec93d5109236da25)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_build-f2e60a9240c763dd)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_macro-078de5e7ba89b97b)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/rename-e52f9fa993216f61)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/rename_builder-2516d87a789cc891)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/test_json-3952c817cc5613ba)

running 1 test
test tests::test_json_support ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.03s

     Running unittests src/main.rs (target/debug/deps/test_unique_id-ba924155b99a5305)

running 1 test
test tests::test_unique_ids ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.24s

     Running unittests src/lib.rs (target/debug/deps/usdt-4639f33e2fbde32a)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_attr_macro-cbf97a7e9c22db03)

running 18 tests
test tests::test_data_type_from_path ... ok
test tests::test_is_simple_type ... ok
test tests::test_parse_probe_argument_native::case_2 ... ok
test tests::test_parse_probe_argument_native::case_3 ... ok
test tests::test_parse_probe_argument_native::case_1 ... ok
test tests::test_parse_probe_argument_native::case_4 ... ok
test tests::test_parse_probe_argument_native::case_5 ... ok
test tests::test_data_type_from_path_panics - should panic ... ok
test tests::test_parse_probe_argument_native::case_7 ... ok
test tests::test_parse_probe_argument_native::case_6 ... ok
test tests::test_parse_probe_argument_span::case_1 ... ok
test tests::test_parse_probe_argument_span::case_2 ... ok
test tests::test_parse_probe_argument_serializable::case_3 ... ok
test tests::test_parse_probe_argument_serializable::case_1 ... ok
test tests::test_parse_probe_argument_serializable::case_2 ... ok
test tests::test_parse_probe_argument_serializable::case_4 ... ok
test tests::test_verify_use_tree ... ok
test tests::test_check_probe_function_signature ... ok

test result: ok. 18 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_impl-32e21314cbac76ae)

running 20 tests
test common::tests::test_generate_type_check_empty ... ok
test record::test::test_process_section ... ok
test record::test::test_emit_probe_record_dunders ... ok
test record::test::test_emit_probe_record ... ok
test common::tests::test_asm_type_convert ... ok
test record::test::test_process_section_future_version ... ok
test record::test::test_process_probe_record ... ok
test common::tests::test_generate_type_check_with_string ... ok
test common::tests::test_generate_type_check_with_shared_slice ... ok
test common::tests::test_construct_probe_args ... ok
test record::test::test_re_process_section ... ok
test record::test::test_process_probe_record_long_names ... ok
test test::test_compile_providers_config ... ok
test test::test_probe_to_d_source ... ok
test test::test_unique_id ... ok
test test::test_provider_to_d_source ... ok
test test::test_unique_id_clone ... ok
test common::tests::test_generate_type_check_native ... ok
test common::tests::test_generate_type_check_with_custom_type ... ok
test test::test_data_type ... ok

test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_macro-984b4a9c5e5eec56)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_tests_common-482927fb349e680c)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/zero_arg_probe-4c18eb482f61b800)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests compile-errors

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests dof

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests dtrace-parser

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests fake-lib

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt

running 7 tests
test src/lib.rs - (line 145) ... ignored
test src/lib.rs - (line 160) ... ignored
test src/lib.rs - (line 179) ... ignored
test src/lib.rs - (line 243) ... ignored
test src/lib.rs - (line 44) ... ignored
test src/lib.rs - (line 57) ... ignored
test src/lib.rs - (line 92) ... ignored

test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt-attr-macro

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt-impl

running 2 tests
test src/lib.rs - UniqueId (line 301) ... ignored
test src/lib.rs - UniqueId (line 339) - compile fail ... ok

test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.11s

   Doc-tests usdt-macro

running 4 tests
test src/lib.rs - dtrace_provider (line 32) ... ignored
test src/lib.rs - dtrace_provider (line 41) ... ignored
test src/lib.rs - dtrace_provider (line 53) ... ignored
test src/lib.rs - dtrace_provider (line 65) ... ignored

test result: ok. 0 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt-tests-common

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Thanks for the testing notes @michael-yuji, that's very good to see things are mostly passing! And it's also great to hear that we can avoid the macro and public API change. Using the section flag and / or the unstable #[used(linker)] attribute if supported both seem like better approaches.
It's a bit surprising the does-it-work test is failing. As you noted, that relies on dladdr to find the function containing the probe's address. It's true that dladdr may fill dli_sname to NULL, though I've never seen dli_fname == NULL. No platforms that I've used indicate that should be possible based on the man pages (macOS, illumos, Linux). FreeBSD may be different in this regard.
I'm still surprised that the address cannot be resolved to a symbol, especially in an unoptimized, debug build. Do you actually see the expected function containing the probe in the symbol table of the binary? For reference, here's how I can see that on my machine:
bnaecker@feldspar : ~/usdt $ cargo t -- does --nocapture
    Finished test [unoptimized + debuginfo] target(s) in 0.04s
     Running unittests (target/debug/deps/argument_types-835cdcabe3d483e8)
     Running unittests (target/debug/deps/does_it_work-e0be16543f85d0b6)

<SNIP>

running 1 test
   ID   PROVIDER            MODULE                          FUNCTION NAME
89494 doesit2953 does_it_work-e0be16543f85d0b6 _ZN12does_it_work8run_test17hfefac3e354dbfbb0E work

        Probe Description Attributes
                Identifier Names: Internal
                Data Semantics:   Internal
                Dependency Class: Unknown

        Argument Attributes
                Identifier Names: Internal
                Data Semantics:   Internal
                Dependency Class: Unknown

        Argument Types
                args[0]: uint8_t
                args[1]: char *

test tests::test_does_it_work ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.24s

<SNIP>

That's showing the full output of dtrace -lv on the binary, indicating that the function name is correct. I can see that exact symbol in the table as well:
bnaecker@feldspar : ~/usdt $ nm target/debug/deps/does_it_work-e0be16543f85d0b6 | grep does_it_work8run_test
[7095]  |             9778784|                 444|FUNC |LOCL |2    |14     |_ZN12does_it_work8run_test17hfefac3e354dbfbb0E
[7804]  |             9779232|                  35|FUNC |LOCL |0    |14     |_ZN12does_it_work8run_test28_$u7b$$u7b$closure$u7d$$u7d$17h7ecd26e668047f99E

If the symbol name is in the table, then it's possible that the dladdr approach we have here doesn't work on FreeBSD for some reason. I can't see anything suggesting this should fail in the man page.

I can see the expected function in the symbol table, however I do realized something in compare to my OmniOS box, on Illumos, parameter addr passed to addr_to_info matches the address in the symbol table, which is not the case on FreeBSD. In fact the address seems to be much lower.
FreeBSD
nm -t x ../usdt/target/debug/deps/does_it_work-733877c2fa8bfdc9 | grep does_it_work8run_test
00000000004cf480 t _ZN12does_it_work8run_test17h138985bf45becfc8E
00000000004d3590 t _ZN12does_it_work8run_test28_$u7b$$u7b$closure$u7d$$u7d$17h4e8c5651b5acc520E

good progress; can we get CI?

@ahl I've not dug too deeply. There's nothing on GH itself, so we'd have to spin up a buildomat runner. I'll try to dig into that this week.

@bnaecker I have found a workaround for the dladdr issue on FreeBSD.
The root cause is that dladdr examines only the dynamic symbol table and hence static functions are not visible. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=134391
The bug report inspired me to look into how backtrace is implemented on FreeBSD. Turns out, libexecinfo implemented backtrace_symbols_* functions to not only use dladdr but also lookup executable for the symbols. Most importantly, it is able to pull the mangled symbol and pathname by the given address, and therefore is used to implement the fix.
Annoyingly, backtrace_symbols_fmt is not part of the libc crate on FreeBSD, so I have to create an extern block.

Thanks for the ping @michael-yuji, and for your patience. I've triggered the CI run to make sure everything works on the main platforms we support (illumos, macOS, and the no-op implementation on Linux). Let's see how that all shakes out and go from there!

The failures in CI are due to the tests around error messages we emit when the macros fail. They've always been a bit annoying to maintain. I believe the issue would be resolved by you rebasing on the latest main, which should include this fix that helps stabilize these messages in CI.

@bnaecker Thank you so much for your time and review. Do you mean rebase to #67?

@michael-yuji I meant an earlier commit actually, but I think was not right. During development, we built tests that verify the errors we produce when compilation fails, for example creating a probe with an unsupported data type. Those were useful initially, but have become a pain to maintain across many toolchain versions. I'm removing them in #67, as you noted. Once that merges, you should be able to rebase onto that. Thanks!

@michael-yuji Thanks for your patience again. I resolved the CI issues causing the error-message checks to fail. You should now be able to rebase onto master and pick those up as well. Once that's done, I can kick off the CI job. Thanks!

@michael-yuji Friendly ping on this PR! I'd love to see all your hard work integrated. If you bring this up-to-date with master, I can take another quick look to make sure that all the requested changes have been integrated. I still need to look into getting a FreeBSD running through our CI system. I'll check that out today, and add commits if we can get that in place. If not, I think you posting the output of your tests against the final commit would be acceptable.

@bnaecker Thanks for following up, I'm a bit busy this week, but I can probably bring it up to date this weekend.

@bnaecker I have updated the patch and following are the test outputs. :raised_hands:
uname
FreeBSD 14.0-CURRENT #13 main-n261297-61507ae30b90-dirty: Fri Mar  3 06:49:30 PST 2023

The complete cargo test command
RUST_BACKTRACE=1 TRYBUILD=overwrite cargo +nightly test

Output
warning: unused import: `Dl_info`
  --> usdt-impl/src/record.rs:21:20
   |
21 | use libc::{c_void, Dl_info};
   |                    ^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: unused import: `null`
  --> usdt-impl/src/record.rs:29:11
   |
29 |     ptr::{null, null_mut},
   |           ^^^^

warning: `usdt-impl` (lib) generated 2 warnings (run `cargo fix --lib -p usdt-impl` to apply 2 suggestions)
warning: `usdt-impl` (lib test) generated 2 warnings (2 duplicates)
    Finished test [unoptimized + debuginfo] target(s) in 0.38s
     Running unittests src/main.rs (target/debug/deps/argument_types-3822dfef754a62d6)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/compile_errors-613756f1a0ff9a44)

running 1 test
warning: unused import: `Dl_info`
  --> /usr/home/yuuji/devel/usdt/usdt-impl/src/record.rs:21:20
   |
21 | use libc::{c_void, Dl_info};
   |                    ^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

warning: unused import: `null`
  --> /usr/home/yuuji/devel/usdt/usdt-impl/src/record.rs:29:11
   |
29 |     ptr::{null, null_mut},
   |           ^^^^

warning: `usdt-impl` (lib) generated 2 warnings (run `cargo fix --lib -p usdt-impl` to apply 2 suggestions)
warning: `usdt-impl` (lib) generated 2 warnings (2 duplicates)
    Checking compile-errors-tests v0.0.0 (/usr/home/yuuji/devel/usdt/target/tests/trybuild/compile-errors)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s

test src/type-mismatch.rs ... ok
test src/unsupported-type.rs ... ok
test src/no-closure.rs ... ok
test src/no-provider-file.rs ... ok
test src/zero-arg-probe-type-check.rs ... ok
test src/different-serializable-type.rs ... ok
test src/relative-import.rs ... ok

test tests::test_compile_errors ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.73s

     Running unittests src/main.rs (target/debug/deps/does_it_work-1274211c3d19efca)

running 1 test
test tests::test_does_it_work ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.26s

     Running unittests src/lib.rs (target/debug/deps/dof-f2ce2dbc6acaca39)

running 1 test
test ser::test::test_padding ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/dtrace_parser-b5e8e807368ca5c9)

running 37 tests
test tests::test_basic_tokens::case_2 ... ok
test tests::test_basic_tokens::case_1 ... ok
test tests::test_basic_tokens::case_3 ... ok
test tests::test_basic_tokens::case_6 ... ok
test tests::test_basic_tokens::case_4 ... ok
test tests::test_basic_tokens::case_5 ... ok
test tests::test_basic_tokens::case_7 ... ok
test tests::test_data_type_enum::case_02 ... ok
test tests::test_data_type_enum::case_01 ... ok
test tests::test_data_type_enum::case_03 ... ok
test tests::test_data_type_conversion ... ok
test tests::test_data_type_enum::case_05 ... ok
test tests::test_comment_provider ... ok
test tests::test_data_type_enum::case_04 ... ok
test tests::test_data_type_enum::case_09 ... ok
test tests::test_data_type_enum::case_10 ... ok
test tests::test_data_type_enum::case_06 ... ok
test tests::test_data_type_enum::case_08 ... ok
test tests::test_basic_provider ... ok
test tests::test_data_type_enum::case_07 ... ok
test tests::test_data_type_enum::case_12 ... ok
test tests::test_data_type_enum::case_11 ... ok
test tests::test_data_type_enum::case_14 ... ok
test tests::test_data_type_enum::case_13 ... ok
test tests::test_data_type_enum::case_15 ... ok
test tests::test_data_type_enum::case_16 ... ok
test tests::test_data_type_enum::case_17 ... ok
test tests::test_data_types ... ok
test tests::test_null_provider ... ok
test tests::test_identifier ... ok
test tests::test_probe ... ok
test tests::test_pragma_provider ... ok
test tests::test_probe_struct_parse ... ok
test tests::test_provider_struct ... ok
test tests::test_two_providers ... ok
test tests::test_file_struct ... ok
test tests::test_bad_basic_token - should panic ... ok

test result: ok. 37 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

     Running unittests src/main.rs (target/debug/deps/dusty-4d9a5dba952efede)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/empty-7ccf4b06c10c6159)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

     Running unittests src/main.rs (target/debug/deps/fake_cmd-fd011476e60a8b14)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s

     Running unittests src/lib.rs (target/debug/deps/fake_lib-1886748ee3d00de8)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/modules-92a1c0c0969e827f)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_attr-736e04c8de600335)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_build-20e92746b3e70cf6)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/probe_test_macro-489893017ac54e2b)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/rename-4f3c51398c80a6b1)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/rename_builder-e09c8911f0abaa56)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/test_json-2b04342493121bd0)

running 1 test
test tests::test_json_support ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.08s

     Running unittests src/main.rs (target/debug/deps/test_unique_id-37c3158cbc3dbf81)

running 1 test
test tests::test_unique_ids ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.64s

     Running unittests src/lib.rs (target/debug/deps/usdt-07986fab38b26e9a)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_attr_macro-f6800b505fbb402c)

running 18 tests
test tests::test_is_simple_type ... ok
test tests::test_data_type_from_path ... ok
test tests::test_parse_probe_argument_native::case_1 ... ok
test tests::test_parse_probe_argument_native::case_3 ... ok
test tests::test_parse_probe_argument_native::case_5 ... ok
test tests::test_parse_probe_argument_native::case_4 ... ok
test tests::test_parse_probe_argument_native::case_2 ... ok
test tests::test_parse_probe_argument_native::case_6 ... ok
test tests::test_check_probe_function_signature ... ok
test tests::test_parse_probe_argument_native::case_7 ... ok
test tests::test_parse_probe_argument_serializable::case_1 ... ok
test tests::test_parse_probe_argument_serializable::case_2 ... ok
test tests::test_parse_probe_argument_serializable::case_3 ... ok
test tests::test_parse_probe_argument_span::case_2 ... ok
test tests::test_parse_probe_argument_span::case_1 ... ok
test tests::test_verify_use_tree ... ok
test tests::test_parse_probe_argument_serializable::case_4 ... ok
test tests::test_data_type_from_path_panics - should panic ... ok

test result: ok. 18 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.07s

     Running unittests src/lib.rs (target/debug/deps/usdt_impl-c60a222c45607fc5)

running 20 tests
test record::test::test_emit_probe_record ... ok
test common::tests::test_generate_type_check_empty ... ok
test common::tests::test_asm_type_convert ... ok
test common::tests::test_construct_probe_args ... ok
test common::tests::test_generate_type_check_native ... ok
test record::test::test_emit_probe_record_dunders ... ok
test record::test::test_process_section_future_version ... ok
test common::tests::test_generate_type_check_with_custom_type ... ok
test common::tests::test_generate_type_check_with_string ... ok
test common::tests::test_generate_type_check_with_shared_slice ... ok
test test::test_compile_providers_config ... ok
test test::test_probe_to_d_source ... ok
test test::test_unique_id ... ok
test test::test_unique_id_clone ... ok
test test::test_provider_to_d_source ... ok
test test::test_data_type ... ok
test record::test::test_process_probe_record ... ok
test record::test::test_process_probe_record_long_names ... ok
test record::test::test_process_section ... ok
test record::test::test_re_process_section ... ok

test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.05s

     Running unittests src/lib.rs (target/debug/deps/usdt_macro-e52611059a383cb7)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/lib.rs (target/debug/deps/usdt_tests_common-482927fb349e680c)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/zero_arg_probe-31bb2163c6a65f4e)

running 1 test
test test::test_main ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

   Doc-tests compile-errors

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests dof

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests dtrace-parser

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests fake-lib

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt

running 7 tests
test src/lib.rs - (line 104) ... ignored
test src/lib.rs - (line 157) ... ignored
test src/lib.rs - (line 172) ... ignored
test src/lib.rs - (line 191) ... ignored
test src/lib.rs - (line 58) ... ignored
test src/lib.rs - (line 69) ... ignored
test src/lib.rs - (line 255) ... ok

test result: ok. 1 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out; finished in 0.55s

   Doc-tests usdt-attr-macro

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt-impl

running 2 tests
test src/lib.rs - UniqueId (line 301) ... ignored
test src/lib.rs - UniqueId (line 337) - compile fail ... ok

test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.17s

   Doc-tests usdt-macro

running 4 tests
test src/lib.rs - dtrace_provider (line 32) ... ignored
test src/lib.rs - dtrace_provider (line 41) ... ignored
test src/lib.rs - dtrace_provider (line 53) ... ignored
test src/lib.rs - dtrace_provider (line 65) ... ignored

test result: ok. 0 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests usdt-tests-common

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

@michael-yuji @bnaecker Hi all, it would be cool to merge this PR one way or the other, right? Do I understand correctly that the main issue now is that we either merge this but are forced to use nightly or we keep stable but force FreeBSD users to include  link-dead-code flag?
If that's the case, then the latter option seems cool to me, if it counts for anything. Are there other options, maybe? Is there some alternative path for making it work under stable?


GUI params empty

✅ Works using substreams run
substreams run map_transfers -s -1 -p map_transfers="to=swap.defi&symcode=USDT"

----------- BLOCK #312,541,107 (12a0ffb3d62ec7ddedcba0043096fa3f8267af550c631942077cc0752311389d) ---------------
map_transfers: log: params: "to=swap.defi&symcode=USDT"
map_transfers: log: filter: "from" {}
map_transfers: log: filter: "to" {"swap.defi"}
map_transfers: log: filter: "symcode" {"USDT"}
map_transfers: log: filter: "contract" {}
map_transfers: log: filter: "to_or_from" {}

❌  empty using substreams gui
substreams gui map_transfers -s -1 -p map_transfers="to=swap.defi&symcode=USDT"

Hey Denis, this feature has been added since commit 1e07b59f8bed536e6c8ec756644448207ef279c5
(May 23)
it is part of release v1.1.4, can you try again with this version ?
It works for me ™

@sduchesneau still doesn't show any params when using gui
Release used
$ substreams --version
substreams version dev (Commit d89602d, Built 2023-06-02T14:33:34Z)

Example
❌ GUI

substreams gui -e eos.firehose.eosnation.io:9001 https://github.com/pinax-network/substreams/releases/download/eosio.token-v0.12.1/eosio-token-v0.12.1.spkg map_transfers -s -1 -p map_transfers="to=swap.defi&symcode=EOS,USDT"

✅ Run

substreams run -e eos.firehose.eosnation.io:9001 https://github.com/pinax-network/substreams/releases/download/eosio.token-v0.12.1/eosio-token-v0.12.1.spkg map_transfers -s -1 -p map_transfers="to=swap.defi&symcode=EOS,USDT"

also having this same issue

Fixed by https://github.com/streamingfast/substreams/commit/bb09e70b6f3067feb7796d2e10ecd958c5a1b918, will be included in next release, probably early next week.


Mario matching [New game]:

🎮 Game Request
It is a spin and match images game, if you get all the parts you win else you can re-spin.
Point down the features
It will have a spin again button which will reset the game and give the user next chance.
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @laibaahsan27 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hello @laibaahsan27, Time's Uppp!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗

Hey @laibaahsan27 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


Installation error

I'm trying to install the pytimeloop module. I installed the timeloop and set the TIMELOOP_INCLUDE_PATH and TIMELOOP_LIB_PATH but when I'm running the "pip3 install -e ." it will give me the following error:
Installing build dependencies ... done
Checking if build backend supports build_editable ... done
Getting requirements to build editable ... done
Preparing editable metadata (pyproject.toml) ... done
Requirement already satisfied: pyyaml in /home/kiarash/miniconda3/envs/cobra/lib/python3.8/site-packages (from
pytimeloop==0.0.1) (6.0)
Building wheels for collected packages: pytimeloop
Building editable for pytimeloop (pyproject.toml) ... error
error: subprocess-exited-with-error

× Building editable for pytimeloop (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [140 lines of output]
    running editable_wheel
    creating /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info
    writing /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/PKG-INFO
    writing dependency_links to /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/dependency_links.txt
    writing requirements to /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/requires.txt
    writing top-level names to /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/top_level.txt
    writing manifest file '/tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/SOURCES.txt'
    reading manifest file '/tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/SOURCES.txt'
    adding license file 'LICENSE'
    writing manifest file '/tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop.egg-info/SOURCES.txt'
    creating '/tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop-0.0.1.dist-info'
    adding license file "LICENSE" (matched pattern "LICEN[CS]E*")
    creating /tmp/pip-wheel-4ml299j7/tmp6kuymqkg/pytimeloop-0.0.1.dist-info/WHEEL
    running build_py
    running build_ext
    -- The C compiler identification is GNU 8.4.0
    -- The CXX compiler identification is GNU 8.4.0
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- Using timeloop includes from: /home/kiarash/cobra/timeloop/include
    -- pybind11 v2.8.0 dev2
    CMake Warning (dev) at /tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/cmake/data/share/cmake-3.24/Modules/CMakeDependentOption.cmake:89 (message):
      Policy CMP0127 is not set: cmake_dependent_option() supports full Condition
      Syntax.  Run "cmake --help-policy CMP0127" for policy details.  Use the
      cmake_policy command to set the policy and suppress this warning.
    Call Stack (most recent call first):
      lib/pybind11/CMakeLists.txt:101 (cmake_dependent_option)
    This warning is for project developers.  Use -Wno-dev to suppress it.

    -- Found PythonInterp: /home/kiarash/miniconda3/envs/cobra/bin/python (found version "3.8.13")
    -- Found PythonLibs: /home/kiarash/miniconda3/envs/cobra/lib/libpython3.8.so
    -- Performing Test HAS_FLTO
    -- Performing Test HAS_FLTO - Success
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /tmp/tmp0uk855y2.build-temp
    [  4%] Building CXX object CMakeFiles/define_gterminate.dir/bindings/gterminate.cpp.o
    [  9%] Linking CXX shared library /tmp/tmprxx_j31b.build-lib/libdefine_gterminate.so
    [  9%] Built target define_gterminate
    [ 14%] Building CXX object CMakeFiles/pytimeloop.dir/src/mapper/coupled-mapper.cpp.o
    [ 19%] Building CXX object CMakeFiles/pytimeloop.dir/src/mapspace/status.cpp.o
    [ 23%] Building CXX object CMakeFiles/pytimeloop.dir/src/model/accelerator.cpp.o
    [ 28%] Building CXX object CMakeFiles/pytimeloop.dir/src/model/bounded-queue-accelerator-pool.cpp.o
    [ 33%] Building CXX object CMakeFiles/pytimeloop.dir/src/model/unbounded-queue-accelerator-pool.cpp.o
    [ 38%] Building CXX object CMakeFiles/pytimeloop.dir/src/model/util.cpp.o
    [ 42%] Linking CXX shared library /tmp/tmprxx_j31b.build-lib/libpytimeloop.so
    [ 42%] Built target pytimeloop
    [ 47%] Building CXX object CMakeFiles/bindings.dir/bindings/accelergy_interface.cpp.o
    [ 52%] Building CXX object CMakeFiles/bindings.dir/bindings/bindings.cpp.o
    [ 57%] Building CXX object CMakeFiles/bindings.dir/bindings/config.cpp.o
    [ 61%] Building CXX object CMakeFiles/bindings.dir/bindings/mapper.cpp.o
    [ 66%] Building CXX object CMakeFiles/bindings.dir/bindings/mapping.cpp.o
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp: In function ‘void pytimeloop::mapping_bindings::BindMappingClasses(pybind11::module&)’:
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:24: warning: converting to ‘pybind11::arg’ from initializer list would use explicit constructor ‘constexpr pybind11::arg::arg(const char*)’
               py::arg() = {}, py::arg() = {}, py::arg() = {},
                            ^
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:24: note: in C++11 and above a default constructor can be explicit
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:40: warning: converting to ‘pybind11::arg’ from initializer list would use explicit constructor ‘constexpr pybind11::arg::arg(const char*)’
               py::arg() = {}, py::arg() = {}, py::arg() = {},
                                            ^
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:40: note: in C++11 and above a default constructor can be explicit
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:56: warning: converting to ‘pybind11::arg’ from initializer list would use explicit constructor ‘constexpr pybind11::arg::arg(const char*)’
               py::arg() = {}, py::arg() = {}, py::arg() = {},
                                                            ^
    /home/kiarash/cobra/timeloop-python/bindings/mapping.cpp:53:56: note: in C++11 and above a default constructor can be explicit
    [ 71%] Building CXX object CMakeFiles/bindings.dir/bindings/mapspace.cpp.o
    [ 76%] Building CXX object CMakeFiles/bindings.dir/bindings/model.cpp.o
    [ 80%] Building CXX object CMakeFiles/bindings.dir/bindings/problem.cpp.o
    [ 85%] Building CXX object CMakeFiles/bindings.dir/bindings/search.cpp.o
    [ 90%] Linking CXX shared module /tmp/tmprxx_j31b.build-lib/bindings.cpython-38-x86_64-linux-gnu.so
    [ 90%] Built target bindings
    [ 95%] Building CXX object cpp_tests/CMakeFiles/pytimeloop_cpptest.dir/test-main.cpp.o
    In file included from /home/kiarash/cobra/timeloop-python/cpp_tests/test-main.cpp:10:
    /home/kiarash/cobra/timeloop-python/cpp_tests/test-worker-pool.h: In member function ‘void WorkerPool<Worker>::worker_loop(Worker&&) [with Worker = AddOneWorker]’:
    /home/kiarash/cobra/timeloop-python/cpp_tests/test-worker-pool.h:13:49: warning: ‘*((void*)& task +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
       Result operator()(Task& task) { return task + 1; }
                                                     ^
    In file included from /home/kiarash/cobra/timeloop-python/include/pytimeloop/mapper/coupled-mapper.h:13,
                     from /home/kiarash/cobra/timeloop-python/cpp_tests/test-mapper.h:10,
                     from /home/kiarash/cobra/timeloop-python/cpp_tests/test-main.cpp:9:
    /home/kiarash/cobra/timeloop-python/include/pytimeloop/utils/worker-pool.h:75:20: note: ‘*((void*)& task +8)’ was declared here
           WithId<Task> task;
                        ^~~~
    /home/kiarash/cobra/timeloop-python/include/pytimeloop/utils/worker-pool.h:75:20: warning: ‘task.WithId<int>::id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    [100%] Linking CXX executable pytimeloop_cpptest
    /usr/bin/ld: CMakeFiles/pytimeloop_cpptest.dir/test-main.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
    //lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
    collect2: error: ld returned 1 exit status
    cpp_tests/CMakeFiles/pytimeloop_cpptest.dir/build.make:99: recipe for target 'cpp_tests/pytimeloop_cpptest' failed
    make[2]: *** [cpp_tests/pytimeloop_cpptest] Error 1
    CMakeFiles/Makefile2:201: recipe for target 'cpp_tests/CMakeFiles/pytimeloop_cpptest.dir/all' failed
    make[1]: *** [cpp_tests/CMakeFiles/pytimeloop_cpptest.dir/all] Error 2
    Makefile:90: recipe for target 'all' failed
    make: *** [all] Error 2
    /tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
      warnings.warn(
    Traceback (most recent call last):
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/editable_wheel.py", line 140, in run
        self._create_wheel_file(bdist_wheel)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/editable_wheel.py", line 330, in _create_wheel_file
        files, mapping = self._run_build_commands(dist_name, unpacked, lib, tmp)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/editable_wheel.py", line 261, in _run_build_commands
        self._run_build_subcommands()
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/editable_wheel.py", line 288, in _run_build_subcommands
        self.run_command(name)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/_distutils/cmd.py", line 319, in run_command
        self.distribution.run_command(command)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/dist.py", line 1217, in run_command
        super().run_command(command)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/_distutils/dist.py", line 987, in run_command
        cmd_obj.run()
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/command/build_ext.py", line 84, in run
        _build_ext.run(self)
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 346, in run
        self.build_extensions()
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 466, in build_extensions
        self._build_extensions_serial()
      File "/tmp/pip-build-env-ok6b9upz/overlay/lib/python3.8/site-packages/setuptools/_distutils/command/build_ext.py", line 492, in _build_extensions_serial
        self.build_extension(ext)
      File "<string>", line 91, in build_extension
      File "/home/kiarash/miniconda3/envs/cobra/lib/python3.8/subprocess.py", line 364, in check_call
        raise CalledProcessError(retcode, cmd)
    subprocess.CalledProcessError: Command '['cmake', '--build', '.']' returned non-zero exit status 2.
    error: Support for editable installs via PEP 660 was recently introduced
    in `setuptools`. If you are seeing this error, please report to:

    https://github.com/pypa/setuptools/issues

    Meanwhile you can try the legacy behavior by setting an
    environment variable and trying to install again:

    SETUPTOOLS_ENABLE_FEATURES="legacy-editable"
    [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building editable for pytimeloop
Failed to build pytimeloop
ERROR: Could not build wheels for pytimeloop, which is required to install pyproject.toml-based projects

I need pytimeloop for a project I'm working on and I would really appreciate any help.
Thanks

Hi, there has been a good amount of changes and bugfixes committed to PyTimeloop recently. Would you mind trying it again?


Cannot read property 'indexOf' of undefined

Cannot read property 'indexOf' of undefined

when i use hard-source run app more then twice times, i will get this error;

Actual Behavior
the first time run hard-source always work fine.

the second time work all right, and get cache.

but third time i will get the error！

more detail:
TypeError: Cannot read property 'indexOf' of undefined
    at splitQuery (/Users/user/work/moviepro-h5/node_modules/_loader-runner@2.3.1@loader-runner/lib/LoaderRunner.js:19:14)
    at getContext (/Users/user/work/moviepro-h5/node_modules/_loader-runner@2.3.1@loader-runner/lib/LoaderRunner.js:238:17)
    at new NormalModule (/Users/user/work/moviepro-h5/node_modules/_webpack@2.7.0@webpack/lib/NormalModule.js:67:18)
    at Object.thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/serial.js:200:12)
    at Object.thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/serial.js:217:25)
    at Compiler.pluginCompat.tap (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30)
    at Compiler.applyPluginsWaterfall (/Users/user/work/moviepro-h5/node_modules/_tapable@0.2.9@tapable/lib/Tapable.js:92:24)
    at Object.exports.call (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38)
    at thaw (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/SystemArchetype.js:126:29)
    at fetch (/Users/user/work/moviepro-h5/node_modules/_hard-source-webpack-plugin@0.13.1@hard-source-webpack-plugin/lib/SystemArchetype.js:173:16)

debug info:

Operating System, Node, and NPM dependency versions
Mac OS
Node 8.9.4

"devDependencies": {
        "@ali/image-loader": "^1.1.0",
        "@ali/retcodelog": "^0.2.15",
        "@antv/data-set": "^0.8.9",
        "@types/jest": "^23.1.4",
        "babel-core": "^6.24.1",
        "babel-eslint": "^10.0.1",
        "babel-jest": "^23.6.0",
        "babel-loader": "^6.4.1",
        "babel-plugin-import": "^1.11.0",
        "babel-plugin-transform-runtime": "^6.23.0",
        "babel-preset-es2015": "^6.24.1",
        "babel-preset-stage-2": "^6.24.1",
        "babel-runtime": "^6.23.0",
        "chalk": "^1.1.3",
        "clean-webpack-plugin": "~0.1.16",
        "css-loader": "^0.14.5",
        "cssmin": "^0.4.3",
        "cssnano": "^3.10.0",
        "eslint": "^3.7.1",
        "eslint-config-standard": "^5.1.0",
        "eslint-config-vue": "^1.1.0",
        "eslint-friendly-formatter": "^4.0.1",
        "eslint-loader": "^2.1.1",
        "eslint-plugin-html": "^1.5.3",
        "eslint-plugin-promise": "^1.0.8",
        "eslint-plugin-standard": "^1.3.2",
        "eslint-plugin-vuefix": "^0.2.1",
        "extract-text-webpack-plugin": "^2.1.2",
        "file-loader": "~0.8.5",
        "friendly-errors-webpack-plugin": "1.7.0",
        "fs-extra": "^2.1.2",
        "glob": "^7.0.6",
        "happypack": "^5.0.0",
        "hard-source-webpack-plugin": "~0.13.1",
        "html-minifier": "^3.5.3",
        "html-webpack-plugin": "^2.30.1",
        "jasmine-core": "^2.99.1",
        "js-yaml": "^3.9.1",
        "json-loader": "~0.5.4",
        "less": "^2.7.2",
        "less-loader": "^2.2.3",
        "lodash": "^4.17.4",
        "optimize-css-assets-webpack-plugin": "^1.3.0",
        "parse5": "^3.0.2",
        "postcss-cssnext": "^3.1.0",
        "postcss-loader": "^2.0.10",
        "strip-json-comments": "^2.0.1",
        "style-loader": "^0.13.2",
        "uglifyjs-webpack-plugin": "^1.1.1",
        "url-loader": "~0.5.8",
        "vue-lazyload": "^1.2.6",
        "vue-loader": "^11.0.0",
        "vue-style-loader": "^1.0.0",
        "vue-template-compiler": "~2.5.13",
        "webpack": "^2.5.1",
        "webpack-bundle-analyzer": "^2.9.1",
        "webpack-dev-server": "2.7.1",
        "webpack-merge": "^4.1.4",
        "webpack2-polyfill-plugin": "^0.0.2"
    },

same problem, the plugin version is last 0.13.1

Just started getting this. Should I downgrade to an older version? Have you guys figured out a way around it?

I am randomly getting this error on gitlab CI builds. Does anyone have a workaround?
Ihave a parameter to clean cache folder in case of any error but I am looking for a permanent solution.
[hardsource:e3cd29b8] Using 132 MB of disk space.
[hardsource:e3cd29b8] Tracking node dependencies with: package-lock.json.
[hardsource:e3cd29b8] Reading from cache e3cd29b8...
(node:30186) **UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'indexOf' of undefined**
    at splitQuery (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/loader-runner/lib/LoaderRunner.js:19:14)
    at getContext (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/loader-runner/lib/LoaderRunner.js:238:17)
    at new NormalModule (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/webpack/lib/NormalModule.js:69:18)
    at Object.thaw (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/util/serial.js:199:12)
    at Object.thaw (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/util/serial.js:216:25)
    at Compiler.pluginCompat.tap (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30)
    at Compiler.applyPluginsWaterfall (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/tapable/lib/Tapable.js:92:24)
    at Object.exports.call (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38)
    at thaw (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:126:29)
    at fetch (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:173:16)
    at NormalModuleFactory.normalModuleFactoryHooks.createModule.tap (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/hard-source-webpack-plugin/lib/TransformNormalModuleFactoryPlugin.js:213:28)
    at NormalModuleFactory.applyPluginsBailResult (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/tapable/lib/Tapable.js:129:27)
    at applyPluginsAsyncWaterfall (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/webpack/lib/NormalModuleFactory.js:75:31)
    at /home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/tapable/lib/Tapable.js:268:11
    at NormalModuleFactory.params.normalModuleFactory.plugin (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/webpack/lib/CompatibilityPlugin.js:52:5)
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/home/gitlab-runner/builds/81c81de8/1/dbs/dbs-front-end-react/node_modules/tapable/lib/Tapable.js:272:13)
(node:30186) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:30186) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I am randomly getting this error on gitlab CI builds. Does anyone have a workaround?
Ihave a parameter to clean cache folder in case of any error but I am looking for a permanent solution.
[hardsource:e3cd29b8] Using 132 MB of disk space.
[hardsource:e3cd29b8] Tracking node dependencies with: package-lock.json.
[hardsource:e3cd29b8] Reading from cache e3cd29b8...
(node:30186) **UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'indexOf' of undefined**
    at splitQuery (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/loader-runner/lib/LoaderRunner.js:19:14)
    at getContext (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/loader-runner/lib/LoaderRunner.js:238:17)
    at new NormalModule (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/webpack/lib/NormalModule.js:69:18)
    at Object.thaw (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/util/serial.js:199:12)
    at Object.thaw (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/util/serial.js:216:25)
    at Compiler.pluginCompat.tap (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/TransformNormalModulePlugin.js:654:30)
    at Compiler.applyPluginsWaterfall (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/tapable/lib/Tapable.js:92:24)
    at Object.exports.call (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/util/plugin-compat.js:175:38)
    at thaw (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:126:29)
    at fetch (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/SystemArchetype.js:173:16)
    at NormalModuleFactory.normalModuleFactoryHooks.createModule.tap (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/hard-source-webpack-plugin/lib/TransformNormalModuleFactoryPlugin.js:213:28)
    at NormalModuleFactory.applyPluginsBailResult (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/tapable/lib/Tapable.js:129:27)
    at applyPluginsAsyncWaterfall (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/webpack/lib/NormalModuleFactory.js:75:31)
    at /home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/tapable/lib/Tapable.js:268:11
    at NormalModuleFactory.params.normalModuleFactory.plugin (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/webpack/lib/CompatibilityPlugin.js:52:5)
    at NormalModuleFactory.applyPluginsAsyncWaterfall (/home/gitlab-runner/builds/81c81de8/1/myApp/react-app/node_modules/tapable/lib/Tapable.js:272:13)
(node:30186) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:30186) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Yeah, have the same error. Version 0.13.1.

Got this after working fine for a while. Not I get it every time.

Last commit more than year ago, is this project still alive?
Is there any alternatives for this plugin?

I have the same error on v0.13.1.

updating @popperjs/core fixed the issue for us. We used to have version 2.1.0. I updated it to 2.4.4 and Cannot read property 'indexOf' of undefined error went away.

2022年还停留在0.13.1版本，且同样有这个问题。
webpack: ^3.0.0


Remove checkStringQuoteValidity in loadIngressRouteConf

What does this PR do?

This PR is to show a simple fix to the issue "Cannot correctly escape in IngressRoute" containous/traefik#6773 . It may not ready to be merged in production code.
With this patch the configuration can work as expected.
However, without knowing what checkStringQuoteValidity is intended to check, I cannot provide a replacement.
Motivation

More

[ ] Added/updated tests
[ ] Added/updated documentation

Additional Notes

Hello @fefe982,
This function should be removable in its entirety.
Can you update this PR to remove the function and all its references?

There are two copies of the checkStringQuoteValidity function, one in  "pkg/provider/kubernetes/crd/kubernetes.go", the other in "pkg/provider/kubernetes/ingress/kubernetes.go".
Do they both need to be removed?


CD workflow

We need a CD workflow with kubernetes commands

Deploy sock shop using k8s yamls ( today it uses deployments)
Deploy sock shop using Helm charts ( available today, need to test it)
Deploy sock shop with statefulsets and PVs (GKE and AWS) - convert any of the mongodb based service from Deployment to statefulset using volumes
Show Blue green deployment and rolling upgrade modifying the front end service  (GKE and AWS)
Show that deployment was successful by adding steps to check some logs/monitors - ELK and some open source monitor
Using Istio in the control plane to manage the services

Namespace based deployment workflow - directory of specs (2-3 directories). input parameter is git url of yamls and namespace name

Namespace healthchecker workflow - availability/ resource usage/ error

Helm deploy

4.Helm healthchecker

Blue green deployment (using label group)

fluentd + ELK (generic)

7.prometheus + grafana
8.7.istio - manually inject to sock shop and collect telemetry


Outline of tsap idea and prototype

In the last half year I used hydra extensively for machine learning at my university job. It provides a configuration tool for complex applications, remote capability (e.g. executing on SLURM cluster) and multiruns (e.g. doing hyperparameter search).
This issue proposes a similar crate for Rust and linfa to build and configure machine learning applications. Similar to structopt and clap it consists of two elements, a macro system to derive structs and a argument parser to override default hierarchies. Compared to established argument parsers, we don't follow Unix argument patterns and combine a default from file with override by arguments step. The crate is therefore geared towards ML instead of command line applications.
To keep dependencies low we make most of the API surface optional. In minimal setting the parameter macro generates only a builder pattern; allowing programmatical control of the algorithm. This is geared for consumer crates, which uses simple parameter sets and don't have to make configuration accessible. In more complex settings we also want to take files and command line arguments into account and extend our API surface to that of Hydra.
Because most of the infrastructure already exist, we use serde for serialization, TOML as configuration format and add a small template engine to rewrite TOML's configuration tree. Extending configuration from other files is a typical usecase for a resolver. In total tsap exists to give a unified macro for generating highly configurable parameter sets for algorithms we have at Linfa.
Motivation
We will start with a simple example to illustrate a usecase:
use tsap::param;

#[param]
struct RandomForest {
    ntrees: usize,
}

#[param]
struct SVClassifier {
    regul_term: f32,
}

#[param]
enum Model {
    RandomForest(RandomForest),
    SVClassifier(SVClassifier),
}

#[param]
struct Main {
    seed: usize,
    #[check]
    model: Model,
}

fn main() {
     // load default configuration from entry file
     let conf: Main = Main::from_file("config/main.toml")
        .amend_args()
        .seed(40)
        .try_into()?;

     // start experiment, do other stuff...
     conf.run_experiment();
}

The following binary calls are then valid:

just plainly with default params: cargo run
override default model: cargo run model=svclassifier
do multirun with multiple seeds: cargo run -m model=randomforest seed=10,20,30,40

Default values are defined with a hierarchy of TOML files, typical parametrizations can be shaped by using using default values. For example the upper example could have one for the main entry and one for the model:
seed = 42

[model]
from_file = { base_path="models/", default="randomforest" }

variant = "randomforest"
ntrees = 128

The keys variant and from_file are reserved keys and indicate enum variant and where to look for the configuration. When overloading the model with a different configuration, the application will automatically look in that folder for a TOML file with the same name.
Guide-level explanation
WIP
Alternatives

use YAML instead of TOML (or make backend agnostic over configuration file)

complex hierarchy of YAML files, when your application can't be fitted into a simple structure, then you should refactor it
configuration backend agnostic seems sensible, but more work required

support traits instead of enums for variants of keys
add inline templates supporting system more similar to omegaconf (e.g. "cmd:data" with expansion to current date)

Unresolved Questions

is the current prototype possible in a static typed language?
should we add a builder pattern generator to help simplify linfa's parameter structs?
should we implement Try when building for nightly, this would support ? for building

talked with @nils-werner recently and he mentioned that one of the key features of Hydra is dependency injection. To give an example: for clustering algorithms you want to be generic over your distance function and allow extending them in retro (which would not be possible with enums).

Why do you want to extend them in retro (I understand that as without re-compiling)? Why not instead require the config files to list all available functions and parameters (and generate Enums from them), and only allow the CLI to override the values, but not add new ones?
In my experience in 95% of cases I don't randomly change a function or class to a completely unseen one, I mostly pick from an existing list, or change their parameters. In the remaining 5% of cases I could accept a re-compile, if I get Rusts Enum-goodness and safety in return.

Why do you want to extend them in retro (I understand that as without re-compiling)? Why not instead require the config files to list all available functions and parameters (and generate Enums from them), and only allow the CLI to override the values, but not add new ones?

using Rust enums has two disadvantages: (1) you loose performance if you use them in your critical path (like as a distance function) because you are adding indirection by branching (2) you can't implement functionality from a downstream crate easily.
So what you have to do in the example is writing your algorithm generic over the distance, but over a closed enum to the user of what you expect them to use. After compilation you can't change those variants anymore.

In my experience in 95% of cases I don't randomly change a function or class to a completely unseen one, I mostly pick from an existing list, or change their parameters. In the remaining 5% of cases I could accept a re-compile, if I get Rusts Enum-goodness and safety in return.

If Rust supported JIT compilation and extensible ADT (https://www.andres-loeh.de/OpenDatatypes.pdf) then it would be possible to extend it from configuration but also quite a different language

P.S. sorry for the necrobump, I'm only just slowly starting to dig deeper into Rust which made me think of this issue again.

learned a new word will steal it from now on :zombie:

Oh I see, if I write an algorithm and you want to replace the distance function afterwards, you can't. Unless I'd make the distance function parameterizable via its trait, which in turn forces me to use a Box. Got it...
OK, I didn't think of composing components from different crates.

you can also implement the trait for your enum, but in practice I have not used boxed trait object yet


pivpn with openvpn and ca certificate

Hi All
I have setup pivpn with openvpn on my rpi3 model b
Im having difficulty to generate a  .p12file  CA  certificate authentication to be imported on my client machine
i have looked on many tutorials but no luck
i have easy-rsa 3.0

Im having difficulty to generate a .p12file CA certificate authentication to be imported on my client machine
i have looked on many tutorials but no luck
i have easy-rsa 3.0

You don't need to do this on the client, just generate a configuration file on the raspberry using pivpn -a and use that file to connect via the OpenVPN app on the client.

No comments in a while, closing...


How to use it with laradock?

https://github.com/laradock/laradock/issues/2002

https://github.com/beyondcode/laravel-websockets/issues/185#issuecomment-535739882


Node connections with incompatible types should be rejected instead of erroring

Instead, this should reject the connection from occurring in the first place.

The crash was fixed so I've edited this issue to now refer to no error being shown, so it can instead just reject the connection.

Is this ideal behaviour? If we have an add node that has implementations for node(f64, f64) -> f64 and node(vec2, vec2) -> vec2, and by default used the f64 version, it would be impossible for the user to use the vec2 version because any attempts to connect a vec2 to either port would be immediately rejected.

Excellent point! Yeah, they should probably just turn red then.

(fwiw Blender does the same, although sometimes I'd wish for a bit more feedback on what exactly doesn't fit)

Excellent point! Yeah, they should probably just turn red then.

@Keavon which input should turn red? Take the previous example of the add node for f64 and vec2. If the user connects an f64 and vec2 as input, which one should be highlighted red?

Perhaps both? (So all become red if invalid.) If it's not crucial, I'd kind of like to just try it out before attempting to decide which is best in theory. But if that complicates implementation then I'm happy to take a closer look at evaluating and comparing the potential solutions to hopefully predict the best approach.

With #1535 now giving the correct indices for exposed inputs, it is mostly just a frontend change to add highlighting.