Make kepler metrics conform to the Prometheus metrics guideline

Why this PR is needed?
Currently it is hard to understand all the prometheus metrics and even know which are the metrics that we are exporting...
The metric naming is complex and does not follow the prometheus metric name guideline.
More details are written in the issue #286
What this PR does?
This PR updates the prometheus metrics along with some changes to enable the new metrics.
Additionally, Prometheus suggest to only report metrics in joules instead of watts. Giving that, we don't need to report the current power consumption since it can be calculated using promQL. There are more details about this in the issue #286
For the sake of compatibility with other modules, we keep some deprecated metrics and will remove it later.
Additional comments
The changes are carefully separated in different commits to be easier to review.
I will update the Grafana dashboard in another PR. There are already many updates in this PR....
Signed-off-by: Marcelo Amaral<EMAIL_ADDRESS>

@sustainable-computing-io/reviewer

The metric change will also impact dashboard @williamcaban @Feelas @sallyom

Also, note that the goal is to update the metrics again later, we should export container energy consumption and not pod. Like container_cpu_usage_seconds_total, but we will have kepler_container_package_joules_total...
Did not use the container name right now because it will require much more changes in the code...

Moved this to draft, since we should report metrics per container not per pod
And then, the metric will have the pod label, for example the container_cpu_usage_seconds_total, but we will have kepler_container_package_joules_total

The Model Server is currently using the old prometheus metrics. Will the old ones be kept for legacy?

Will the old ones be kept for legacy?

@KaiyiLiu1234, yes!
That is why I included the deprecated tag in the old metrics.
When the model server gets updated, we can remove the old metrics...

I added the node name as the label instance also in the container metrics, as suggested here

let's merge this one. @marceloamaral would you like to follow up with an option to turn on/off/enable metrics? That'll give us flexibility to meet multiple goals.

@sustainable-computing-io/reviewer any more feedback?

I agree to apply these changes. However, I, of course, will affect the currently trained model.
All models needs to be re-trained and may be re-collected (with the container level data).
The default weight will not be available until all previously steps have re-done (that I cannot put my hand on this work within these three weeks).

@sunya-ch you might be referring to the case that Kepler is running on the VM, right?
So that Kepler will not use the ratio model. And the ratio model will not be impacted by pre-trained models....
But in relation to the other context, where the ratio model cannot be used, we will need to recalibrate the models.
But that's all model server logic, right?
Note that this also happens if the model was trained on a different system and needs to be recalibrated again when Kepler is running on another system...
So I don't think it's going to be too harmful to merge this PR now...
Especially because there are some use cases that have recently disabled Kepler to run on VMs, e.g the PR #294.

I did some rough tests and want to have some idea the cpu  load and scrape latency if the metrics go into the conformance direction.
I use node_exporter as a reference, since the amount and the format of metrics match what the new kepler metrics will become in a well populated environment
On my setup, the node_exporter port is 9100.
First of all, there are around 3K metrics exported by node_exporter:
# curl http://localhost:9100/metrics |grep -v \# |wc -l
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  215k    0  215k    0     0   189k      0 --:--:--  0:00:01 --:--:--  189k
3234

Next, I just keep scrape the node_exporter metrics endpoint every 3 seconds (as used by kepler service monitor)
while true; do time curl http://localhost:9100/metrics 2>&1 > /dev/null;sleep 3;done

real    0m1.102s
user    0m0.004s
sys     0m0.007s

During the scraping, node_exporter has high cpu usage:

By comparison, current kepler latency is less than 0.02 seconds and cpu usage is less than 5%.
The latency is likely proportionally related to the computation done by node_exporter. If kepler metrics gets expansive, the latency and cpu will be a huge concern.
I suggest:

Let's keep metrics used by model server, autoscaler, and other special purposes. They are not designed to be used end users Prometheus conformance is less important than efficiency.
Performance and scalability impact need to be studied in more details.
The container level metrics needs to be discussed. The benefits can go both ways: although it is nice to have more info but unless there is a real use case for fine grained info, let's prioritize scalability and efficiency first.

@sunya-ch you might be referring to the case that Kepler is running on the VM, right? So that Kepler will not use the ratio model. The ratio model will not be impacted by pre-trained models....
But in relation to the other context, where the ratio model cannot be used, we will need to recalibrate the models. But that's all model server logic, right? Note that this also happens if the model was trained on a different system and needs to be recalibrated again when Kepler is running on another system...
So I don't think it's going to be too harmful to merge this PR now... Especially because there are some use cases that have recently disabled Kepler to run on VMs, e.g the PR #294.

Model server used exported metric from Kepler to do the online training for the other system that doesn't have the power measurement (no matter it is the VM or not).
The point is not whether recalibrating due to the system change. The point is the name of features is mismatch and not support right now and the training scope is changed from pod to container. It is not that severe as from VM-scope to pod-scope because it is the same process level and sharing the operating processes. However, there is no experimental result support whether how much that affects the model accuracy yet.

@rootfs very good analysis! Ok, let's keep the old metrics, I'll remove the deprecated label from them.

@sunya-ch

The point is that the resource name is incompatible

It's not necessary as we keep the old metrics as they are...
In the end, the request to the Model Server will be just a bigger array with more instances...(per container, not per pod)
And of course, we will need to validate everything, but we are still working on validate everything right?

very good analysis! Ok, let's keep the old metrics, I'll remove the deprecated label from them.

@marceloamaral should we revert the revert of podID PR?

@jichenjc, don't think so, this PR here will fix the issue....

@marceloamaral got it :)

@sunya-ch we will still keep the old metrics
But eventually we must update kepler-model-server and kepler-estimator
And we definitely need to update the PR #225.

Add also the old metric pod_cpu_instructions since the clever dashboard use it

Reopening, it was closed by mistake

As I was already updating a lot of parts, I also needed to combine this PR with another PR that introduced a design change.
I also took the opportunity to refactor and reorganize some packages to improve code readability.


feature: add network disconnect interface

Signed-off-by: Michael Wan<EMAIL_ADDRESS>Ⅰ. Describe what this PR did
support network disconnect restful api
Ⅱ. Does this pull request fix one issue?
fixes part of https://github.com/alibaba/pouch/issues/868
Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
show container network information
root@osboxes:pouch (zr/network-disconnect) -> pouch inspect -f {{.NetworkSettings.Networks.bridge}} test
{[] map[] bfdbbdd9fb28258c270eed0a93b90da4172eee62336b35ddcf9f58e1375237f7 <IP_ADDRESS>  0 <nil> <IP_ADDRESS> 24  [] 02:42:ac:11:00:02 89f1c37aac4c6cd86848290c54a85f9af37b4c7ce18b64358cc4dc49d4c89f74}

check network config inside container:
root@osboxes:pouch (zr/network-disconnect) -> nsenter -t 14414 -p -n -m ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

check network config on host:
root@osboxes:pouch (zr/network-disconnect) -> brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.0242fbc4e8bd	no
p0		8000.1ad80237a756	no		veth9489e6d
virbr0		8000.525400edda3f	yes		virbr0-nic

disconnect container from network
root@osboxes:pouch (zr/network-disconnect) -> pouch network disconnect bridge test

check network config again:
root@osboxes:pouch (zr/network-disconnect) -> brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.0242fbc4e8bd	no
p0		8000.000000000000	no
virbr0		8000.525400edda3f	yes		virbr0-nic

endpoint has been removed
Ⅴ. Special notes for reviews

Codecov Report

Merging #1172 into master will decrease coverage by 0.02%.
The diff coverage is 11.47%.


Add Azure page blob snapshot functionality

Snapshot functionality for Azure (page) blobs is not implemented yet. As far as I can tell this functionality was planned in rootfs/snapshot#4 but could not find any other forks/issues/PRs that would have dealt with Azure snapshot support, so I am planning to implement it myself. Any advice and suggestions are more than welcome!
/area snapshot

I don't have an Azure account and have no experience with it either. Any contributions would be welcome.

Work is ongoing, however, instead of (unmanaged) page blobs focus has shifted to managed disks, which is the recommended and more up-to-date way of using Azure Disks. Look here for more info: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/faq-for-disks and https://docs.microsoft.com/en-us/azure/virtual-machines/linux/about-disks-and-vhds#managed-disks
Updated the issue name and message accordingly.

Update for @wongma7 and @tsmetana: snapshots for managed disks on our Azure cluster have been up and running for a few weeks now, I'll try to prepare a formal pull request shortly.


Homepage: Show counts

x Is new feature

Description of suggestion or shortcoming:
Show the number of Models/Definitions/Groups. Ideally, this would also work for Exports, when that happens.
The number should be shown in a bubble next to it, like we do with exports.

Most work is done in https://github.com/quantified-uncertainty/squiggle/issues/2297


SLES OS disk support - when?

Could you share a (rough) timeline for OS disk support of SLES, please?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 75aaea98-a087-c6d0-61cd-4a2edab37be5
Version Independent ID: 6a2fa1ec-fadc-2d1c-2ab3-8ded33843414
Content: FAQ - Azure Disk Encryption for IaaS VMs
Content Source: articles/security/azure-security-disk-encryption-faq.md
Service: security
GitHub Login: @mestew
Microsoft Alias: mstewart

@igomat Thank you for your query. We will have this checked internally and update the conversation here. Please give us some time.
thank you.

@igomat We currently do not have any ETA on this.  If you wish you may leave your feedback here All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

@igomat We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Make 'create_detector_parameters' more generic

create_detector_parameters in nexus_utils.py is specific to i03. We need to allow for this to be selected based off the beamline - probably from detector_params
This should also be moved into mx_bluesky
Acceptance Criteria

create_detector_parameters  moved to mx_bluesky, and gives us beamline-specific detector parameters

In fact, I think everything in hyperion.external_interaction.nexus should be moved to mx_bluesky. I will make a separate issue for that


Implement requirement rule CPMR0026 - Description Character Count Above 4000

:tada: This issue has been resolved in version 0.1.0 :tada:
The release is available on:

GitHub Release
Chocolatey Package

Your GitReleaseManager bot :package: :rocket:


Real life example needed

I'm a bit new to slack bots, and it seems that I need a better example than what's in the readme. Running this exact code in Nodejs simply starts and immediately stops. It doesn't seem to do anything at all, definitely is not listening for anything.

Yeah.. I also feel lost. No idea as to what to do and where to go.

Yes, sure.
Does Node.js throw any error?
Did you get and specify your own token for the bot?
You get token, when will have created a bot here https://my.slack.com/services/new/bot

Yes a have a token. I've abandoned using this framework. Instead I'm using https://github.com/xBytez/slackbotapi now, but also investigating other frameworks.

Anyway, I would glad to know what unclear in example. Could you provide you code? Or it was the same as in readme.md

As previously stated, I started with the example code in the readme.

I've tried using the example code as well and I can't get the bot to fire any events. Am I missing an init function for the bot?

@alexlrobertson it didn't throw error in some cases (https://github.com/mishk0/slack-bot-api/commit/20f629648805fc8dd8ca1bad465612ede945f447). Please take index.js from master and try to run this example again. Maybe the reason will become clear.


Backport "Make ceph-common aware off osd config fragments" to stable-2.1

This is already in master, I just backported it to the stable-2.1 branch.
Original commit message below this line:
Make ceph-common aware off osd config fragments
This removes the implicit order requirement when using OSD fragments.
When you use OSD fragments and ceph-osd role is not the last one,
the fragments get removed from ceph.conf by ceph-common.
It is not nice to have this code at two locations, but this is
necessary to prevent problems, when ceph-osd is the last role as
ceph-common gets executed before ceph-osd.
This could be prevented when ceph-common would be explicitly called
at the end of the playbook.
Signed-off-by: Christian Zunker<EMAIL_ADDRESS>

Did not see that there already is a pull request for this: #1436


Styling for DatePicker not rendering properly

Detailed description
Upon rendering the DatePicker with the carbon-components scss in our app.scss
@import '../../../node_modules/carbon-components/scss/components/date-picker/date-picker';
@import '../../../node_modules/carbon-components/scss/components/date-picker/flatpickr';

package.json:
"react: ~16.2"
"carbon-components": "~8.18.1",
"carbon-components-react": "~5.41.6",
"carbon-icons": "^6.3.2",

I am getting the following DatePicker render:

Browser: Version 65.0.3325.181
Here is the reproduced environment: https://codesandbox.io/s/4jv88114mx

It looks like using "carbon-components-react": "~5.41.3" has the DatePicker rendering correctly.

My issue was partially resolved by importing the flatpickr css before the date-picker css.
@import '../../../node_modules/carbon-components/scss/components/date-picker/flatpickr';
@import '../../../node_modules/carbon-components/scss/components/date-picker/date-picker';


Running "smt repeat x" using Python 2.7 leads to deepcopy issue

I just used sumatra for the first time to create a run of my model.
The goal is to create a run that I can repeat as I work on the model,
and check if the output remains constant. However, when I issued:
{{{
$ smt repeat primary_test
Traceback (most recent call last):
File "/usr/people/hiemstra/progsandlibs/bin/smt", line 5, in

pkg_resources.run_script('Sumatra==0.3.1.dev', 'smt')
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 467,
in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1200,
in run_script
execfile(script_filename, namespace, namespace)
File "/usr/people/hiemstra/progsandlibs/lib/python2.7/site-packages/
Sumatra-0.3.1.dev-py2.7.egg/EGG-INFO/scripts/smt", line 33, in

main(sys.argv[2:])
File "/usr/people/hiemstra/progsandlibs/lib/python2.7/site-packages/
Sumatra-0.3.1.dev-py2.7.egg/sumatra/commands.py", line 441, in repeat
original = deepcopy(tmp)
File "/usr/lib/python2.7/copy.py", line 190, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "/usr/lib/python2.7/copy.py", line 344, in _reconstruct
state = deepcopy(state, memo)
File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
y = copier(x, memo)
File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
y = copier(x, memo)
File "/usr/lib/python2.7/copy.py", line 298, in _deepcopy_inst
state = deepcopy(state, memo)
File "/usr/lib/python2.7/copy.py", line 163, in deepcopy
y = copier(x, memo)
File "/usr/lib/python2.7/copy.py", line 257, in _deepcopy_dict
y[deepcopy(key, memo)] = deepcopy(value, memo)
File "/usr/lib/python2.7/copy.py", line 174, in deepcopy
y = copier(memo)
TypeError: cannot deepcopy this pattern object
}}}
After googling a bit, I found this issue: http://bugs.python.org/issue10076
: on the bugtracker of python. I think the problem is that the Project
class does not provide a deepcopy function. I also tried to
replace deepcopy by copy in commands.py:line 441 (I thought, just give
it a try :)), but this led to the following error:
{{{
$ smt repeat primary_test
Traceback (most recent call last):
File "/usr/people/hiemstra/progsandlibs/bin/smt", line 5, in

pkg_resources.run_script('Sumatra==0.3.1.dev', 'smt')
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 467,
in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1200,
in run_script
execfile(script_filename, namespace, namespace)
File "/usr/people/hiemstra/progsandlibs/lib/python2.7/site-packages/
Sumatra-0.3.1.dev-py2.7.egg/EGG-INFO/scripts/smt", line 33, in

main(sys.argv[2:])
File "/usr/people/hiemstra/progsandlibs/lib/python2.7/site-packages/
Sumatra-0.3.1.dev-py2.7.egg/sumatra/commands.py", line 444, in repeat
original.repository.checkout() # should do nothing if there is
already a checkout
File "/usr/people/hiemstra/progsandlibs/lib/python2.7/site-packages/
Sumatra-0.3.1.dev-py2.7.egg/sumatra/versioncontrol/_mercurial.py",
line 129, in checkout
local_repos = hg.repository(self._ui, path, create=True)
File "/usr/lib/python2.7/site-packages/mercurial/hg.py", line 94, in
repository
repo = lookup(path).instance(ui, path, create)
File "/usr/lib/python2.7/site-packages/mercurial/localrepo.py", line
2049, in instance
return localrepository(ui, util.drop_scheme('file', path), create)
File "/usr/lib/python2.7/site-packages/mercurial/localrepo.py", line
68, in init
raise error.RepoError(("repository %s already exists") % path)
mercurial.error.RepoError: repository /nobackup/users/hiemstra/speedo/
speedo_blackbox_tests already exists
}}}
Some information on my system:
{{{
$ uname -a
Linux bhp012.host.nl <IP_ADDRESS>-92.fc14.i686.PAE #1 SMP Sat May 21
17:33:09 UTC 2011 i686 i686 i386 GNU/Linux
$ python --version
Python 2.7
$ smt
Usage: smt  [options] [args]
Simulation/analysis management tool version 0.3.1.dev
}}}
Imported from Bitbucket issue 93,  created by apdavison on 03-29-2012 at 07:43, last modified: 05-02-2012 at 10:59

This fixed the problem! Thanks...
Trac comment by anonymous on 05-02-2012 at 10:59

This turns out to be a problem with deepcopy of ConfigParserParameterSet objects, which I had not seen before since I mostly use SimpleParameterSet or NTParameterSet  in the tests and in my own code.
The problem should be fixed in r298
Trac comment by apdavison on 04-19-2012 at 14:08


If -prune=0 is set, Uncheck Prune on Intro page

If the bitcoin-qt is started with -prune=0 arg, On the Intro page,
the Prune Checkbox will be unchecked too, to prevent confusions.
refs: https://github.com/bitcoin/bitcoin/issues/25052

This is a probably a good-enough fix and better than the status quo, but it could be improved in the futue:

If -prune=size setting is given, size could be shown in intro dialog bog
If data directory path is changed, and path contains bitcoin.conf or settings.json files with a prune value, that value could be shown.

But this fix is probably good enough to fix problem at hand

Thanks for the valuable comments. The first one is already working as intended. I took a note about the 2nd one and will work on it separately.
Thanks.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts
Reviewers, this pull request conflicts with the following ones:

#149 (Intro: Have user choose assumevalid by luke-jr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

When passing -prune= >1 to the command line, it forces the prune checkbox to be checked and disables it.
With this PR, when passing -prune=0 to the command line, it forces the prune checkbox to be unchecked but does not disable it.
Should behavior be consistent?

This is a good point. It would be better for behavior to be consistent and it would be better to disable the setting if leaving it enabled gives user the misleading impression that setting they are chosing in the checkbox will be applied. For example, if bitcoin is started with -prune=0 and checkbox is enabled and user checks, they could have misleading impression that pruning will be applied when it won't be.
Even so, the PR in it's current form is still an improvement over the status quo. Disabling the checkbox would be an even bigger improvement, but just having checkbox show correct value is an improvement by itself.

ACK f4b0c0c

Even so, the PR in it's current form is still an improvement over the status quo. Disabling the checkbox would be an even bigger improvement, but just having checkbox show correct value is an improvement by itself.

Agree. Could leave a bigger improvement for an follow up.
@jadijadi Please squash all commits into one before merging.

Thanks @hebasto , I squashed the commits into one.


Fix #105 - Mac release.sh should use_prov_client

Checklist

[X] I have read the [contribution guidelines] (https://github.com/Azure/azure-iot-sdk-python/blob/master/.github/CONTRIBUTING.md).
[ ] I added or modified the existing tests to cover the change (we do not allow our test coverage to go down).
If this is a modification that impacts the behavior of a public API

[ ] I edited the corresponding document in the devdoc folder and added or modified requirements.

I submitted this PR against the correct branch:

[X] This pull-request is submitted against the master branch.
[X] I have merged the latest master branch prior to submission and re-merged as needed after I took any feedback.
[X] I have squashed my changes into one with a clear description of the change.

Reference/Link to the issue solved with this PR (if any)
Issue #105
Description of the problem
A ./release.sh for Mac performs a full build, which fails to find
the file iothub_security_factory.h. But build.sh worked. The
failure is caused by a difference in the cmake command run
by each script.
Add "-Duse_prov_client:BOOL=ON" to release.sh, matching build.sh
Housecleaning, update the cmake command in build.sh to include "BOOL"
matching the other arguments on the same command line.

@alanjcastonguay
Could you please double check if the build is OK with the proposed change?
It is failing on our gate  with error:
10:57:56 python2.7 iothub_service_client_map_test.py
10:57:56 Traceback (most recent call last):
10:57:56   File "iothub_service_client_map_test.py", line 12, in
10:57:56     import iothub_service_client
10:57:56 ImportError: No module named iothub_service_client
[Pipeline] }
[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 1
Finished: FAILURE
Please let us know...
Best Regards,
Zoltan

@alanjcastonguay
Sorry for the late follow up, but we started to working on to clean up the MAC build now.
Regarding the  original pull request, I have to decline it, because we are not going to support the device  provisioning on Mac devices.
So the build flag always have to be "OFF".
Best Regards,
Zoltan

Closing as the scenario is not supported


update juliomixtreria

Motivation

Have you read the Contributing Guidelines on pull requests?

Test Plan

Related PRs

@omega5300 Please remember to sign the CLA. PRs without CLA will be closed after two weeks.

I decided to close this PR more pre-emptively. It looks like a really random PR that's not even close to the finish line. If you ever have time @omega5300 to come back, sign the CLA, and add the screenshot, feel free to re-open it. No need to send a new one.


examples\system\sysview_tracing_heap_log generate svdat can not analysis. (IDFGH-9080)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v4.4.3-release
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
PowerShell
What is the expected behavior?
At project README.md introduce, when I use gdbinit command esp sysview start file://heap_log.svdat(I change the route to compatible my PC) generate svdat file and I should use the file open with systemview software.
And as the doc introduce, when I use $IDF_PATH/tools/esp_app_trace/sysviewtrace_proc.py -p -b build/sysview_tracing_heap_log.elf /tmp/heap_log.svdat to check the svdat, the output is:
[0.002272225] HEAP: Allocated 8 bytes @ 0x3ffaff6c from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:85
/home/user/projects/esp/esp-idf/components/esp32/cpu_start.c:570

[0.002307300] HEAP: Allocated 2500 bytes @ 0x3ffb580c from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:804
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:84 (discriminator 2)

[0.002323775] HEAP: Allocated 356 bytes @ 0x3ffb61d4 from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:84 (discriminator 2)

[0.002427700] HEAP: Allocated 120 bytes @ 0x3ffaff78 from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/queue.c:391
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:46

[0.002471225] HEAP: Allocated 2500 bytes @ 0x3ffb633c from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:804
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

[0.002487725] HEAP: Allocated 356 bytes @ 0x3ffb6d04 from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

[0.002569725] HEAP: Allocated 2 bytes @ 0x3ffafff4 from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:59
/home/user/projects/esp/esp-idf/components/freertos/port.c:145

[0.002835275] LOG: I (298) example: Task[0x3ffb61d4]: allocated 2 bytes @ 0x3ffafff4
[0.002974600] LOG: I (299) example: Task[0x3ffb6d04]: free memory @ 0x3ffafff4

....

[2.942891550] LOG: I (3239) example: Task[0x3ffb7840]: allocated 396 bytes @ 0x3ffb9d08
[2.943024150] LOG: I (3239) example: Task[0x3ffb6d04]: free memory @ 0x3ffb9c3c
[2.943035600] HEAP: Freed bytes @ 0x3ffb9c3c from task "free0" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:24 (discriminator 9)
/home/user/projects/esp/esp-idf/components/freertos/port.c:145

[2.943212125] LOG: I (3239) example: Task[0x3ffb83ec]: free memory @ 0x3ffb9d08
[2.943223500] HEAP: Freed bytes @ 0x3ffb9d08 from task "free1" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:24 (discriminator 9)
/home/user/projects/esp/esp-idf/components/freertos/port.c:145

[2.943649025] HEAP: Allocated 594 bytes @ 0x3ffb9c3c from task "alloc2" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:59
/home/user/projects/esp/esp-idf/components/freertos/port.c:145

[2.943734250] LOG: I (3240) example: Task[0x3ffb8f28]: allocated 594 bytes @ 0x3ffb9c3c
[2.943867850] LOG: I (3240) example: Task[0x3ffb9ad4]: free memory @ 0x3ffb9c3c
[2.943879200] HEAP: Freed bytes @ 0x3ffb9c3c from task "free2" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:24 (discriminator 9)
/home/user/projects/esp/esp-idf/components/freertos/port.c:145

[2.972813425] LOG: I (3269) example: Got notify val 2
[2.972870400] LOG: I (3269) example: Wait notify 1
[2.972932800] LOG: I (3269) example: Got notify val 1
[2.972989825] LOG: I (3269) example: Wait notify 2
[2.973756125] LOG: I (3270) example: Got notify val 1
Processed 13467 events
=============== LOG TRACE REPORT ===============
Processed 600 log messages.
=============== HEAP TRACE REPORT ===============
Processed 612 heap events.
[0.002272225] HEAP: Allocated 8 bytes @ 0x3ffaff6c from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:85
/home/user/projects/esp/esp-idf/components/esp32/cpu_start.c:570

[0.002307300] HEAP: Allocated 2500 bytes @ 0x3ffb580c from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:804
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:84 (discriminator 2)

[0.002323775] HEAP: Allocated 356 bytes @ 0x3ffb61d4 from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:84 (discriminator 2)

[0.002427700] HEAP: Allocated 120 bytes @ 0x3ffaff78 from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/queue.c:391
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:46

[0.002471225] HEAP: Allocated 2500 bytes @ 0x3ffb633c from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:804
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

[0.002487725] HEAP: Allocated 356 bytes @ 0x3ffb6d04 from task "alloc0" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

[0.003102175] HEAP: Allocated 8 bytes @ 0x3ffb6e6c from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:85
/home/user/projects/esp/esp-idf/components/esp32/cpu_start.c:570

....

[0.003713175] HEAP: Allocated 356 bytes @ 0x3ffb8f28 from task "main" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:84 (discriminator 2)

[0.003814375] HEAP: Allocated 120 bytes @ 0x3ffb9090 from task "alloc2" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/queue.c:391
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:46

[0.003845875] HEAP: Allocated 2500 bytes @ 0x3ffb910c from task "alloc2" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:804
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

[0.003862350] HEAP: Allocated 356 bytes @ 0x3ffb9ad4 from task "alloc2" on core 0 by:
/home/user/projects/esp/esp-idf/components/freertos/tasks.c:809
/home/user/projects/esp/esp-idf/examples/system/sysview_tracing_heap_log/build/../main/sysview_heap_log.c:55

Found 17520 leaked bytes in 18 blocks.

What is the actual behavior?
When I generate svdat is:
heap_log1.zip
(Please unzip this)
And when I use systemview, It show cannot parse:

When I use python file to parse:
PS D:\mine\debug_temp\sysview_tracing_heap_log> python C:/Espressif/frameworks/esp-idf-v4.4.3/tools/esp_app_trace/sysviewtrace_proc.py -p -b build/sysview_tracing_heap_log.elf heap_log.svdat
Traceback (most recent call last):
File "C:/Espressif/frameworks/esp-idf-v4.4.3/tools/esp_app_trace/sysviewtrace_proc.py", line 140, in
main()
File "C:/Espressif/frameworks/esp-idf-v4.4.3/tools/esp_app_trace/sysviewtrace_proc.py", line 90, in main
reader = apptrace.reader_create(trace_source, args.tmo)
File "C:\Espressif\frameworks\esp-idf-v4.4.3\tools\esp_app_trace\espytrace\apptrace.py", line 357, in reader_create
return FileReader(trc_src[7:], tmo)
File "C:\Espressif\frameworks\esp-idf-v4.4.3\tools\esp_app_trace\espytrace\apptrace.py", line 179, in init
self.trace_file = open(path, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'g3.svdat'
Steps to reproduce.
I am not use gdbinit file, I am take break at heap_trace_stop():

When the program stop at there, I am stop sysview in telnet.
Build or installation Logs.
No response
More Information.
No response

@WangShuoran
It is known problem.
As a workaround you can use SystemView v2.52


[Automation] Generate SDK based on TypeSpec 0.20.3 DEV

[Automation] Generate SDK based on TypeSpec 0.20.3 DEV

API change check
API changes are not detected in this pull request.


feat(cheatcodes): add vm.assumeNoRevert for fuzz tests

Motivation
Closes #4090
Closes #7246
Similar with assume cheatcode, but for discarding inputs in fuzz runs that reverts:
    /// Discard this run's fuzz inputs and generate new ones if next call reverted.
    function assumeNoRevert() external pure;

Solution

split assume* cheatcodes in separate mod
in call_end, if assumeNoRevert cheatcode set, discard run if we're at the same depth as cheatcode and call reverted by returning result with MAGIC_ASSUME output (caught by fuzz and invariant tests and discarded). If call didn't revert then reset chetcode state and continue test
unit tests

should this only re-run if next call reverts? went through issues and seems like this is the common usecase, current version might result in footguns, especially given that sometimes it's hard to craft an array with addresses whitelist

Spec sgtm, and do we also increment the rejects counter the same way? A single test rejects counter for this + vm.assume seems like the best UX, to keep it simple

Spec sgtm, and do we also increment the rejects counter the same way? A single test rejects counter for this + vm.assume seems like the best UX, to keep it simple

yep, the rejects counter is incremented same way


Zip code via URL

There it is a nice implementation to read zip code via the URL. The format would be something like this:
localhost:5000/{zip_code}
Here it is how it works:

It will check if there's any cache with the given zip code as a key. If it already exists, it will return the context that's been saved in that cache.

if cache.get(zip_code):         return render_template('index.html', **cache.get(zip_code))

If there is not any cache with that key, it will execute the normal code, obtaining all the data from the API corresponding to the given zip code. Checks if the zip is none or not, if it's none, it will assign a default zip code, in this case, New York, Manhattan, Central Park.
After that it will follow the normal flux of the application, storing the new cache object with the zip code as the key.

It could be a nice approach, let me know if it works good for you!

@JulianNorton you can check the modifications I've made on this PR. Caching is limited to 3 calls, so 3 unique locations would be cached. Should we rewrite the cached locations if new calls arrive?

Thanks @sebasblancogonz. Right now I think if a 4th unique location is requested, it should overwrite the oldest cache. Let me review and get back to you!

@sebasblancogonz I tried zipcode 01610 (Worcester, MA) and got a key error – can you look into it?

Going to check it out

Hello Julian, the problem is that apparently for that given ZIP there is no available data on the following endpoint: https://api.weather.gov/gridpoints/BOX/46,66/forecast.
We have the following information for that ZIP:

[zip_code: '01610', lat: '42.247049', lng: '-71.808366']

If we get the area_data for the given zip executing the call https://api.weather.gov/points/42.92,-71.80, we will get this forecast endpoint mentioned above, which will return the following data:

I will add some error handling and send some message to the front-end

With the new changes the app shouldn't crash when an invalid zip code is given. Now I'm working on the functionality to manage and rewrite the oldest cache! I'll let you know as soos as I got that done!

Hey @sebasblancogonz,
I tried with a couple different zips and couldn't get it to work: 01610, 10025, and 91780 and get the not found message:

Is this something I'm not testing right? Or should I wait for your additional changes? I appreciate it and let me know if you need anything from me!

I was wondering how could I do the cache rewriting stuff aand, what about queues? FIFO?

I recommend to split it out into separate PRs and issues. Maybe it's best to just focus on the URL input first. Once that's confirmed working, we can work together on the cache?

I recommend to split it out into separate PRs and issues. Maybe it's best to just focus on the URL input first. Once that's confirmed working, we can work together on the cache?

Sure, that's perfect for me! I'll submit the last modification to avoid non-valid format zip codes

Not it's finished! Test it and let me know if I have to change anything! 😊

Stale PR


templ generate not working for multi line arguments

Hi there, i'm encountering an issue when having multi line in the function arguments.
this doesn't work, but if i remove the new lines, it works.
also, moving the type declaration to another file works for both, it's only an issue when it's in the same .templ file.
doesn't work
package components

type expense struct {
	A string
}

templ Expense1(
	params expense,
) {

}

works
package components

type expense struct {
	A string
}

templ Expense2(params expense) {

}

error when running templ generate
failed to process path: <.templ file path>  source formatting error: 16:1: expected declaration, found templ

Thanks. That's currently a limitation of the templ parser. The current implementation is at https://github.com/a-h/templ/blob/main/parser/v2/templateparser.go - it looks for the templ  prefix and then assumes that everything until the next linebreak is Go code.
To support multi-line arguments for templ functions, would need to parse the code after "templ" with the Go parser up until the opening brace of the template body.

@julianooi - got a draft PR change to the templ parser that will fix this issue, I added a test that demonstrates the fix.

This is now fixed.


Introduce default targets; compile for generic by default

Previously, acpp by default would error if --acpp-targets (or ACPP_TARGETS environment variable) was not given. There was the option to use a default targets specification in cmake, but it was not used by default, and judging by its name -DDEFAULT_GPU_ARCH, came from the very old days when we still had --hipsycl-gpu-arch.
This is a problem for cmake-based projects using the stdpar model. In this model, since it is just standard C++, generally the CMAKE_CXX_COMPILER needs to be set to acpp. However, cmake tests whether the compiler works, and then finds that it does not, because acpp is not given --acpp-targets during cmake validation and thus complains.
This is a major inconvenience for any user of stdpar and cmake. The only workaround is to use environment variables like ACPP_TARGETS which can however be confusing and hacky.
This PR:

Deprecates -DDEFAULT_GPU_ARCH and introduces -DDEFAULT_TARGETS cmake option;
For backwards compatibility, DEFAULT_TARGETS is filled with DEFAULT_GPU_ARCH if DEFAULT_GPU_ARCH is given, and DEFAULT_TARGETS is not.
If neither DEFAULT_TARGETS nor DEFAULT_GPU_ARCH are given, DEFAULT_TARGETS is set to generic if the SSCP compiler is enabled, and to omp otherwise.

This means that every installation of AdaptiveCpp (assuming it has SSCP enabled, which is the default for any recently new LLVM) will be able to just acpp -o test test.cpp have a binary that can offload to anywhere.
That was always the game plan for SSCP, although originally I had planned to wait a little longer until at least group algorithms are ported over. However, the new stdpar use case merits a change of plans in my opinion.
It is unclear whether we should also include omp as default target instead of just generic (i.e. omp;generic).
This would increase compile time, but would allow execution for OpenMP by default. On the other hand, execution on CPU is also possible through generic and OpenCL, and users could enable omp explicitly if they wanted to.
@al42and I recall that you run a configuration on LUMI with default target specified. Please verify that this does not break things.
@tom91136 This should make things a little more convenient for you :)

I like this PR and how it makes the overall interface more uniform.
The new option works fine.
But there old approach is now broken. Previously,  -DDEFAULT_PLATFORM=rocm -DDEFAULT_GPU_ARCH=gfx90a is how it was supposed to be used (platform could be skipped if there's only one). Now, these flags are equivalent to DEFAULT_TARGETS=gfx90a, which does not work.
And we should also deprecate DEFAULT_PLATFORM and remove default-platform from syclcc.json

Thanks for checking, @al42and ! I totally forgot about DEFAULT_PLATFORM :( That stuff is truly ancient, from back when we could only target a single device at a time..
I have now changed the behavior for backwards compatibility, i.e. DEFAULT_TARGETS is not set:

If DEFAULT_PLATFORM is not given, but DEFAULT_GPU_ARCH is, then DEFAULT_TARGETS=${DEFAULT_GPU_ARCH}
If DEFAULT_PLATFORM is cpu, then DEFAULT_TARGETS=omp.
If both DEFAULT_PLATFORM and DEFAULT_GPU_ARCH are given, then:

For DEFAULT_PLATFORM=="cuda", DEFAULT_TARGETS="cuda:${DEFAULT_GPU_ARCH}"
For DEFAULT_PLATFORM=="rocm", DEFAULT_TARGETS="hip:${DEFAULT_GPU_ARCH}"

Can you check if it is now working correctly?
I have also deprecated DEFAULT_PLATFORM and removed it from syclcc.json.
Unfortunately, since DEFAULT_PLATFORM was set by default depending on available backends (in an incomplete way, since it only took host/NVIDIA/AMD into account), I had to remove the existing default values of DEFAULT_PLATFORM in order to not conflict with the new defaults for omp and generic.
This means that if the variables are not set, this PR can potentially change the default behavior. I don't see any way around that though, unless we want to abandon the idea of generic as default. This however does not seem like the right choice to me, since the old defaults do not allow to actually be compatible with all supported devices like generic. So generic does seem like the natural choice here.

Can you check if it is now working correctly?

Works fine!
I made a few suggestions above to make the misconfigurations more apparent. Better to see the problem ASAP, and not only after installing and trying to use the compiler.

This however does not seem like the right choice to me, since the old defaults do not allow to actually be compatible with all supported devices like generic. So generic does seem like the natural choice here.

I agree with you on generic. What I am not so sure is setting omp as the default target in absence of SSCP. If you ask me, this is a useful target to have, but it is unlikely to be the main target for people using ACpp, and defaulting to it can lead to confusion. A clear error asking to add --acpp-target flag would be better in this case, IMO

I made a few suggestions above to make the misconfigurations more apparent. Better to see the problem ASAP, and not only after installing and trying to use the compiler.

Thanks, good suggestions! (see my one comment)

I agree with you on generic. What I am not so sure is setting omp as the default target in absence of SSCP. If you ask me, this is a useful target to have, but it is unlikely to be the main target for people using ACpp, and defaulting to it can lead to confusion. A clear error asking to add --acpp-target flag would be better in this case, IMO

I see your point, but I also think there are some counterpoints:

The reason we have generic and omp is that these are the two targets that we know should work (mostly) independently of the end user's hardware. If we don't use omp as a fallback, we will not be able to have a default target in case SSCP is unavailable.
If we don't set  a default target without SSCP, our communication regarding the --acpp-targets flag will be more confusing.  It would be useful and less confusing if we could say that acpp -o test test.cpp will always at least work, whether or not it will offload. I can imagine that might be similar tooling issues as the one described in the initial comment, and of course such a behavior will be better for teaching.
There are users who are in fact using stdpar with the omp backend on CPU since it has a better NUMA behavior than e.g. regular TBB-based PSTL. Those users might not need the LLVM dependency, and thus not want SSCP. They will be stuck with the same cmake problem that motivated this PR in the first place (as described in the initial comment) if we don't set omp as default target.

How about we issue a warning, if we set the default target to omp saying that an invocation without --acpp-targets will not be able to offload?
If users still try to use a SYCL device from another backend in this case they will still get an error, although one at runtime. I admit that this error is currently not very intuitive (I believe it will be something like could not find requested kernel launcher), but we could add to the message there that users should check their --acpp-targets flag.

If we don't use omp as a fallback, we will not be able to have a default target in case SSCP is unavailable.

I think that is good. Without SSCP, the user must have the target hardware in mind when compiling, so I think it is better to be explicit about this rather than to have a bad and counter-intuitive default. With SSCP, the choice is delayed till the runtime, so one does not have to make a choice when compiling.

It would be useful and less confusing if we could say that acpp -o test test.cpp will always at least work, whether or not it will offload.

I would question the definition of "works" here. The whole reason people use PStl or SYCL is for performance. If they expect GPU offloading but get CPU multithreading instead -- that might not count as "working" in their books (if it does, they can set the target explicitly).

If we don't set a default target without SSCP, our communication regarding the --acpp-targets flag will be more confusing.

I don't think it is more confusing than "without specifying --acpp-targets, either a CPU-only binary or a fully-portable (adaptive) binary with CPU and GPU support will be produced".

There are users who are in fact using stdpar with the omp backend on CPU since it has a better NUMA behavior than e.g. regular TBB-based PSTL. Those users might not need the LLVM dependency, and thus not want SSCP. They will be stuck with the same cmake problem that motivated this PR in the first place (as described in the initial comment) if we don't set omp as default target.

They can set ACPP_TARGETS when building explicitly. Or change syclcc.json. Or use CMAKE_CXX_FLAGS.
That's an important case, and it's amazing how AdaptiveCpp is beating TBB. But AdaptiveCpp is also beating NVC++, if I recall correctly; so, GPU-offloading is an attractive use-case too, and we should avoid unexpected and potentially-undesirable behavior there.

How about we issue a warning, if we set the default target to omp saying that an invocation without --acpp-targets will not be able to offload?

Agree, that's also fine. As long as it's clear what's happening.
Alternatively, we can issue a CMake-time error is SSCP is not available and ACPP_TARGETS is not set.

They can set ACPP_TARGETS when building explicitly. Or change syclcc.json. Or use CMAKE_CXX_FLAGS.

The common pattern in existing cmake infrastructure for stdpar projects is already to rely on something like -DCMAKE_CXX_COMPILER=acpp -DCMAKE_CXX_FLAGS=--acpp-stdpar --acpp-targets=.....  (See e.g. https://github.com/uob-hpc/cloverleaf)
However this won't be sufficient because when cmake validates acpp as C++ compiler, it will find that acpp does not run unless --acpp-targets is provided somehow. At the point when it does that, CMAKE_CXX_FLAGS is not yet applied.
You can circumvent that by also setting the environment variable ACPP_TARGETS at cmake time, but this is inconvenient because you need to set the target twice, and it might also be confusing. Modifying syclcc.json is similarly more of a hack, and perhaps syclcc.json should be regarded more of an implementation since it is only half-documented.

That's an important case, and it's amazing how AdaptiveCpp is beating TBB. But AdaptiveCpp is also beating NVC++, if I recall correctly; so, GPU-offloading is an attractive use-case too, and we should avoid unexpected and potentially-undesirable behavior there.

Yes, we generally either closely match nvc++ or crush it, depending on the workload.
I think we are in agreement that we want to ensure that nothing unexpected happens. I would propose that I add the warning, and then we can perhaps refine the defaults from there based on actual user feedback in the future, if needed.

However this won't be sufficient because when cmake validates acpp as C++ compiler, it will find that acpp does not run unless --acpp-targets is provided somehow. At the point when it does that, CMAKE_CXX_FLAGS is not yet applied.

Hm, I see a different behavior with CMake 3.28.1. I don't have the default target set and the test fails without CXX_FLAGS, but the following command configures CloverLeaf just fine, and all compiler sanity tests are run with acpp-targets flag set: cmake .. -DCMAKE_C_COMPILER=clang-17 -DCMAKE_CXX_COMPILER=acpp -DCMAKE_CXX_FLAGS=--acpp-targets=generic

I think we are in agreement that we want to ensure that nothing unexpected happens. I would propose that I add the warning, and then we can perhaps refine the defaults from there based on actual user feedback in the future, if needed.

Yes, that sounds reasonable, I agree.
I would perhaps even suggest to always print a warning when no default target is set: "acpp warning: target not set, using XXX. Add --acpp-targets flag or add the default target to your configuration file to silence this warning". Best of both worlds: we gently encourage user to be explicit in their wishes to avoid surprises in the future, without impeding the simplest use of acpp now.

My concern would be that this would reinforce the belief that AdaptiveCpp needs to be custom-built for all users, even though we have generic which is supposed to work for all users if it is available.

I don't see how. We're asking users to be explicit, since many compilation flows are supported and genuinely have their uses. Compare with -O flags: ACpp always complains when they are not set, because that could lead to potentially undesired behavior; but if the user elaborates their wishes by setting -O0, then no warning is necessary, even though the resulting behavior is not changed.

I think fundamentally, the issue is that currently acpp behaves differently from stdpar vendor compilers like nvc++, icpx, or roc-stdpar. All of those can generate a binary without special flags, but might require special flags to offload.

That also sounds like a good solution. Maybe delegate checking of the target validity to the Clang plugin, so that it can see if offload is used in the source, and only then raises an error? And, as you said, that follows existing patterns -- always a good thing.

I think fundamentally, the issue is that currently acpp behaves differently from stdpar vendor compilers like nvc++, icpx, or roc-stdpar. All of those can generate a binary without special flags, but might require special flags to offload.

Curiously, even acpp --acpp-version does not work without specifying a target architecture.

This is strange indeed. --acpp-version does want to print all of the configuration, so it might access the targets value. However, it should handle that: https://github.com/AdaptiveCpp/AdaptiveCpp/blob/f2d41975ba3e5db44713abc5ae3dbe974f28abcf/bin/acpp#L1981

After some internal discussion, I have decided:

we do not want to deviate from the existing behavior of acpp of being an offloading C++17 compiler. In the future, if there is user demand/sufficient reason, we could introduce a new compiler driver in addition to acpp which would adopt the behavior of being just a regular host compiler unless offload flags are provided explicitly.

This could also solve issue #1300, although it is not clear to me whether this issue is something that AdaptiveCpp needs to solve.
The current acpp semantics are also not without precedent, as they mirror what e.g. nvcc or hipcc do, although these support older C++ standards than we do.

Ideally, if we do not have SSCP, we should enforce that users explicitly provide a DEFAULT_TARGETS setting to cmake. However, I am concerned that this might break existing deployments of AdaptiveCpp (e.g. installation and packaging scripts maintained by third parties). I have thus expanded the warning in this case to say that setups without SSCP in the future may only be supported if DEFAULT_TARGETS is provided.

This hopefully causes users to migrate to providing -DDEFAULT_TARGETS so that we can enforce users providing DEFAULT_TARGETS in future versions.


[Feature] [Flink-K8s-V2] Refactor the lifecycle control code of Flink clusters on Kubernetes

… clusters on Kubernetes

What changes were proposed in this pull request
Issue Number: close #2884

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
•
FlinkClusterService.start 中 KUBERNETES_NATIVE_SESSION 类型的适配到 FlinkK8sOperator.deployCluster;
•
FlinkClusterService.shutdown 中 KUBERNETES_NATIVE_SESSION 类型的适配到 FlinkK8sOperator.delete;
(or)
This change added tests and can be verified as follows:

Does this pull request potentially affect one of the following parts

Dependencies (does it add or upgrade a dependency): (yes / no)

This is the mvp version. Since the cluster involves the console module java code, it needs to be optimized later.

cc @Al-assad @wolfboys

@Al-assad Thank you for your review. It has been moved. Because changes to some parameters of deployrequest will affect the main process of v1, so I choose to use the default values for TaskManager and JobManger now. I will debug and optimize these parameters in the future.

cc @Al-assad @wolfboys

cc @wolfboys @Al-assad


Help!

I like openbullet so far. The stack especially is fun! But I've had issues :(
Is there a matrix/IRC/telegram/slack/discord thing where I can get help?
(Sorry for asking here, if it's not super appropriate)

https://discourse.openbullet.dev/

Please go to https://discourse.openbullet.dev/ and ask questions. github is there to report bugs or request for Features.


Just one Production across schemas

In the directory hierarchy of datasets, "production" for each schema should be a sym link to the DESC protected shared area, /global/cfs/cdirs/lsst/shared
Production datasets (and only those) may be dependencies of datasets in any schema, so entries for them probably belong in a schema of their own (along with all the other tables belonging to current schemas).
Code will have to be revamped to handle any references to production datasets specially, since they will have to be qualified by schema name.
The structure of the dependency table will have to change to allow the possibility of a dependency dataset which is in the production schema, even if the dataset depending on it is not (add another foreign key column referencing production.dataset.dataset_id?)  Or maybe better just add a new table production_dependency.
Something similar might have to be done about the foreign key reference dataset.execution_id. Or maybe not since I would expect production datasets to only be created by production executions. However at some point we need to think about how to allow someone to move a dataset from one of the other owner types to production. It is going to be difficult, or at the very least tedious, to update all relations correctly.

Started to look at this in #74
Some initial thoughts questions:

The provenance table is part of the schema. So if we have a production schema, is there a risk of versions going out of sync?

Should we have just provenance for the database, does that mean it has to be in its own schemea? Or maybe the provenance is just in the production schema?

Currently owner_type is unchanged. However it will raise an error if you try to assign owner_type="production" to anything other than the production schema. And also raise an error anything going into production that is not owner_type == "production"

sqllite can't have multiple schemas, this means we can't have a production schema for that backend

Think about ways to query between schemas

For 1. - each schema has its own version tracking in its provenance table.  It's up to us as maintainers to ensure that the production schema is compatible with any schema someone might want to access along with it in the same session. Perhaps at connection time we can check and issue a warning if they're not compatible (once we figure out what that means).
For 3. - I had forgotten, but actually sqlite can have multiple schemas, sort of. See https://www.sqlite.org/lang_attach.html .    I'm not sure whether we can make use of this or not (and, if we can, if it's worth the effort).
For 4. - I think all we need to support are queries that involve the original schema (the one coming from the DbConnection call) and the well-known production schema.
For 5. - I don't have strong feelings about the name; so far I haven't found anything wrong with sticking with "production".   Whatever we decide, it should be a constant, probably declared in db_basic, which is available to the rest of the code, e.g.
PRODUCTION_SCHEMA="production"

@JoanneBogart if we want query support for the production schema whilst connected to the original schema, I'm not sure how this would work.
I'm guessing, for a given query on the dataset name for example, it would search both the current schema and the production schema and return the results?
But there is no index between the two schemas to make a join, so it would require the two schemas to have the exact same format, which we ruled out by keeping their versions separate.
You could have it return two search results, one per schema, but that's a little clunky (and then you can't necessarily just concatenate those two results unless we ensure the schemas have the same layout).
For the dregs ls command its easy enough to do two queries and print the results. Just not sure if they can be returned robustly in a single object in the dataregistry package unless we ensure the schemas are exactly the same layout.
Any thoughts?

I hadn't thought this through and wasn't very clear - I was only thinking that results might include items from production, in particular production dependencies.  So if you ask for dependencies of a particular non-production dataset, the code should look at the execution for that dataset (always in the same schema) and the inputs attached to it, which could come either from the same schema or the production schema. I guess any production (dependency) datasets or columns from them would have to be qualified with "production".  Is that doable?
In the case of returning dependencies, what exactly do we return?  I would think just the id.   But since those ids can now come from two different tables, they should be returned in separate lists (or something), say called dependencies and production_dependencies.


Modify SetLocation method

Signed-off-by: Harshita sharma<EMAIL_ADDRESS>
What this PR does / why we need it: Modify SetLocation method
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:

/approve
/lgtm


Convert most data from enums to keyed interfaces

This PR proposes moving most of our string enum data definitions to a set of keyed interfaces, which can allow us to expand on the data offered beyond what enums allow. The sets of data I'm moving as of this PR:

Job and Role definitions
Action (ie SkillNames)
Resources and Cooldowns
Traits

A few things this allowed me to do was to remove some use of arbitrary arrays controlling things like:

Does this job use MP?
Is this resource toggle-able in the status display?
Can this resource be clicked off in the status display?
How many stacks does this status effect resource have?

This also now drives the stacked icon registration behavior

In addition, for these sets of Data, I moved the source of the translated strings out of maps in Localization.tsx to the Data definitions themselves.
I also provided a few examples of unused properties that we might eventually move to using for future updates such as:

Action ID: For exporting to Tischel's plugin and/or other systems, related to Issue #78
Cooldown maximum, and Cooldown charges

We could move to getting more data from the interface type when building out job behavior code

I considered but did not include moving the BuffType enum used for the skill timeline buff covers and party buff markers, and the WarningType enum to this format. Doing so will be left for future work.
In addition to the above, as part of the ongoing effort to consolidate where developers need to look to add their new jobs to the site, I moved the function that returns the job-specific GameState class out of Controller.ts and into the Game/Jobs/index.ts file, and pushed the retrieval of the job-specific StatusPropsGenerator UI class into a getter on the GameState class. This will mean in most cases, job developers don't need to jump over to the Controller class to hook up their job, it'll be done in or near files they'd be editing anyways.

Added traits port for a further example of usage

The type checker blocks on strings not in the key set (as long as it knows it's expecting a ShellJob key, ActionKey, etc). That was the main reason I pulled over the ensureRecord utility from xivanalysis instead of just exporting a bunch of Record<string, T> objects, was to get that type checking on the keys.
The plethora of blank job files under the Data/<etc>/Jobs directories are indeed things I just haven't ported, or stub files for jobs nobody has implemented yet to make it clearer where their data should go. It's an extension of the "predefine as much as possible" PR I had a whole back, I want to make it easier for a new job contributor to find where things need to go, without needing to do the work of stitching it all together.

I'll probably also take a look at it starting 1/2/25, after I get back to GMT-8


Is sshd available?

I see there are sshd.c in ssh_agent package. But sshd seems not available in system. It would be great to have it, so that can config things for a-shell via ssh from a full-keyboard computer.

closing. There is an sshd issue under https://github.com/holzschu/a-shell

Hi, thanks for asking (and for cleaning up the issue afterwards).
I’ve tried adding sshd recently, but I ran into a lot of issues that I on’t know how to solve yet.
The problem is not sshd itself, but the configuration files and especially the host key. An iPhone or iPad is likely to change IP address regularly, and ssh does not like when the IP address changes and the host key doesn’t.
Nothing impossible to surmount, but still something I need to think about before release.


tree mapping

There's no mention here of the tree mapping, which is evident in the image on Exploring the dataview

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 595c371b-cced-07b1-2581-07a96b4c5af0
Version Independent ID: bebdf7f8-3ea0-cea4-4c9f-9b029020ef9f
Content: Data view mappings - Power BI
Content Source: powerbi-docs/developer/visuals/dataview-mappings.md
Service: powerbi
Sub-service: powerbi-custom-visuals
GitHub Login: @asander
Microsoft Alias: asander

Thanks for your comment, @saviourofdp. I've assigned this issue to the doc author for review.

@saviourofdp currently, tree option isn't supported by Custom Visuals.

#please-close @kfollis


BUG: fix amax constraint not enforced in scalar_search_wolfe2

Fixing the error indicated by this question.

I'm not sure that this is a good example, because for default amax the answer is not as expected:
In [17]: ls.scalar_search_wolfe2(phi, derphi, amax=0.001)
Out[17]: (1.0, 16.0, 25.0, -8.0)

In [18]: ls.scalar_search_wolfe2(phi, derphi, amax=None)
Out[18]: (1.0, 16.0, 25.0, -8.0)

Okay, verified now - all looks good. Merged, thanks @vegatheil

For future reference: the test verifies a private function; the corresponding public one is optimize.line_search:
>>> def phi(alpha):
...           return (alpha - 5) ** 2
>>> def derphi(alpha):
...            return 2 * (alpha - 5)
>>> x_current = 0
>>> search_direction = 1
>>> optimize.line_search(phi, derphi, x_current, search_direction)
(1.0, 2, 1, 16.0, 25.0, -8.0)

@rgommers could you help me with #11360 ?


Make all controllers inherit from a single DeviseController

Just a simple change introducing an empty controller between devise controllers and ApplicationController. This means you can use template inheritence in rails 3.1 (a la template-inheritence, but it's rails 3.1 only then).
It also means you can move some of the shared stuff into the devise controller. (a la controller-inheritence-experimental)
Additionally, using Rails 3.1 you can easily add an extra template scope lookup, so it searches "app/views/", "app/views/devise", then "app/views/application". I'm working on this in a template-inheritence-experimental.
(Have been meaning to send this for a while...)

:+1:


Issue with Processing Nested includes in Requests

Problem Description
An issue has been identified in the processing of requests involving nested includes. The API does not seem to handle requests with multiple levels of includes correctly. Specifically, when requesting resources with nested relationships (e.g., posts.user and posts.comments), the expected related entities are not always properly included in the response.
Expected Behavior
When making a request with nested includes, such as ?include=posts,posts.user,posts.comments, the API should return the main resource along with all the specified related entities in the included section of the response.
Actual Behavior
The API response does not consistently include all the specified nested relationships. This leads to incomplete data being returned for requests that require detailed relational information.
Steps to Reproduce

Make a request to the endpoint (e.g., /users) with the query parameter ?include=posts,posts.user,posts.comments.
Observe the returned JSON response, particularly the included section.

Proposed Test
A test has been written to validate the correct behavior of nested includes in the API response. The test ensures that all specified relationships are properly included in the response data.

fixes in #59


Migrated the Build Badge from TraviS CI .org to .com Domain

Codecov Report

Merging #16 (8410e11) into master (79f92f3) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #16   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files           2       2
  Lines         241     241
======================================
  Misses        241     241

Continue to review full report at Codecov.

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


backup file has wrong format

Hardware
ESP32
Firmware version
v2.4.2
Application version
v2.4.2
What happened? What did you expect to happen?
Something went wrong when I updated to the latest 2.4.2 pre-release (probably my own fault, as I was in a hurry and may have made a mistake). Luckily I had done a backup right before.
I had to re-onboard the ESP and wanted to do a restore. However, the backup file had the wrong format: the extension was ".txt".
Maybe it was because I made the backup with the iPhone (iOS 17.4.1) and once again an unintentional "Apple Magic" hit me (normally I love the Apple Magic, but sometimes it's just annoying...)?
Fortunately, I was able to solve the problem by simply renaming the file and removing the extension.
Now that the ESP is up and running again, I made a backup and noticed that the extension .txt is actually suggested in the file dialog.
I had overseen this and didn't know it would cause problems anyway...
By the way, the restore worked perfectly! 👍👏👏👏
How to reproduce it (step by step)
1. Go to...
2. Click on...
...

Logs
No response

Unfortunately, I cannot control what shows up in the dialog since that is based on the mime type for the file.  Most of the fruity magic I could do without.   Anyhow, I will allow the backup to accept .backup and .backup.txt.

👍☺🙏🙋♂


fix(TU-8855): Build respectOpenModals from HTML attributes

[BOT] Preview available with hash 871e38e99629fe0267459a44f9ed365e2a243843 here.

:tada: This PR is included in version @typeform/embed-v4.8.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Multi-line table entry or way to ignore line break.

For example, table with three rows and two columns each.
 Header One  | Header Two
 -------------- | -----------------------------
 Row1           | This is This is very, very very very very longooooooooo ooooooooooooooooo line.
 Row2          | Short entry

I like to break "This is very very loooo...ng entry" into two source line.
 Header One  | Header Two
 -------------- | -----------------------------
 Row1           | This is This is very, very very very very
longooooooooo ooooooooooooooooo line.
 Row2          | Short entry

This does not mean that it will break line in display (like <BR>) Just markdown parser will ignore newline after the last "very" and continue accept next line as part of the table entry. This is more consistent behavior for markdown format which largely treats single line break as space in source.
This can be done by adding "line continuation" back slash (\) as character escape or some other mean like  enclosing the multi-line entry or whole the table itself with bracket ({{ entry... }}) or any similar way.
TRDR: There must be some way to  accept long table entry spreaded in 2 lines as single table entry.

afaik, none of the existing markdown parser table implementation support this, so we won't try to support this for now.


Out-of-memory error may occur when large ranges are requested with GetObject (Rclone version < 1.64.0)

Describe the bug
When reading a very large file (40 GiB; larger than the machine RAM size) with Rclone (version 1.60.1 from Debian), I observe that versitygw gets killed by the oom-killer.
Rclone prior to version 1.64 requests very large ranges. When reading a 40 GiB file with Rclone version 1.60.1, I observe that 4 GET requests are sent with 10 GiB ranges:

Range: bytes=0-10737418239
Range: bytes=10737418240-21474836479
Range: bytes=21474836480-32212254719
Range: bytes=32212254720-42949672959

These very large ranges cause versitygw to allocate a large amount of memory to serve these chunks.
I tested with several versions of Rclone. Since version 1.64.0, Rclone requests much smaller chunks (64 MiB) and this issue does not occur.
To Reproduce

Serve files with versitygw 1.0.1 (I use the posix backend)
Download a very large file with Rclone (version < 1.64.0; for instance version 1.60.1 from Debian 12 bookworm)
Observe that versitygw gets oom-killed because it consumes too much memory.

Expected behavior
Requesting a very large range from a very large file with GetObject should not crash versitygw.
Server Version
$ ./versitygw --version
Version  : 1.0.1
Build    : d98ca9b0346d8f097ab42d8832895a248756259a
BuildTime: 2024-06-11T21:29:09Z

$ uname -a
Linux xxx 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux

$ rclone --version
rclone v1.60.1-DEV
- os/version: debian 12.5 (64 bit)
- os/kernel: 6.1.0-21-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.19.8
- go/linking: dynamic
- go/tags: none

Additional context
This bug occurs with Rclone version < 1.64.0. Since version 1.64.0, Rclone requests much smaller chunks (64 MiB) and this issue does not occur.

We changed the upload paths to a streaming model to conserve memory. We can look into if it's possible to do the same on the download side to address excessive memory use for large downloads.

Thank you @jonaustin09 ans @benmcclelland!


Gracefully exit from kani-driver process

Description of changes:
When an error that was properly handled ocurrs in kani-driver we now gracefully exit and return ExitStatus::FAILURE.
We still print all error context to keep a similar experiece to what it was before. However, this will no longer include the backtrace if users set RUST_BACKTRACE=1.
The backtrace will still be included if you enable the debug logs and also enable the backtrace. I.e.:
export RUST_BACKTRACE=1
export KANI_LOG=kani_driver=debug
cargo kani

Resolved issues:
Resolves #2064
Related RFC:

Optional #ISSUE-NUMBER.
Call-outs:

Testing:

How is this change tested?

Is this a refactor change?

Checklist

[ ] Each commit message has a non-empty body, explaining why the change was made
[ ] Methods or procedures are documented
[ ] Regression or unit tests are included, or existing tests cover the modified code
[ ] My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

It makes sense. What you are suggesting is already the current behavior though. The standard library checks those variables before generating the backtrace.
That said, it doesn't fix the problem at hand. So I think the question here is whether #2064 should be fixed in the first place. @zhassan-aws ?

I think we should fix it. The behavior I was suggesting is this:

If you want only panics to have backtraces, set RUST_BACKTRACE=1 and RUST_LIB_BACKTRACE=0.

So to fix this in kani-driver, if the former is set, and the latter is not, then we explicitly set the latter to 0.

Ah, I see what you are saying, you think we should change the behavior only when RUST_BACKTRACE=1 and RUST_LIB_BACKTRACE isn't set, right? Why is that? Do you think people just aren't used to the second variable?
This PR mimics cargo and rustc behavior, which I think makes more sense. No matter the value of RUST_BACKTRACE and RUST_LIB_BACKTRACE, these two tools won't print the stack trace of an error that is due to a user error (like compilation error). Note that today passing the wrong argument will not print the error stack, no matter the values of these two variables.
No matter which approach we take, we should consider improving the driver error handling to make a distinction between internal tool error and user error, so this can be handled in a better way.

So I think the question here is whether #2064 should be fixed in the first place. @zhassan-aws ?

I think it should be fixed, because a backtrace gives an impression that something is broken in the tool.

Do you think people just aren't used to the second variable?

Pretty much.
Also, just want to make it clear: I don't object to this change.

Do you think people just aren't used to the second variable?

Yeah, tbh, I am not a big fan of the design they came up with these two variables. It's not very intuitive.

Pretty much.
Also, just want to make it clear: I don't object to this change.

Sounds good. Thanks!


Line Data - N/A for different graphs

The name "Line Data" doesn't seem applicable when different type of graph is being selected. Same goes with the "Line 2, Line 3, ..."

We could change "Line Data" to "Graph Data"
We could do Set 1
Each line is a set of data.
Another question would be does Scatter Plot need Average? Maybe we could replace Average on the Scatter Plot with the correlation?

I also think that Data Plot could be called Data Points

Data Plot now is Data Table
Line Data is now Graph Data
and each Line # is now Set #


Add support for temperature sensors coming from sonoff devices that have it.

Current implementation is only used for switches, but could be extended for sensors to show temperature information on devices that have it such has TH16.

I would hold off a bit into merging this. It was already on my roadmap and the current code contains some duplicated/unused logic and I don't have the time right now to check it and fix it.
could you please let me know if you get temperature updates inside eWeLink app without refreshing the devices? i would like to implement the update over websocket if possible and rely less on the polling part

The version of the app I am sing only allows me to see temperature when I click on the device, not sure if that refreshes automatically or not.


macOS event loop fixes

When running pugl as a PUGL_MODULE, it's dangerous to call sendEvent on arbitrary events, as processing such events could cause the UI instance to be destroyed. Then, when statements later on in puglUpdate are executed, they may attempt to access resources that have been freed, crashing the process. This is currently seen in LV2 UIs which execute puglUpdate from the idle callback.
This change just posts events to the CFRunLoop directly, which seems a bit cleaner. This way, there's no need to convert the event to an NSEvent and back, as we can just capture the event in a block instead.
I also noticed that the test_redisplay app asserts on Big Sur because the OS invalidates the entire window in response to the invalidate request, so I've updated the test a little to be slightly more forgiving about mismatches between the requested and actual repainted areas.
Finally, I noticed that the meson build currently doesn't work out-of-the-box due to undefined references to c_warnings and objc_warnings. Perhaps this is a configuration issue on my system, so I haven't pushed a fix. That said, removing the references allowed the build to succeed.
See also #56 and https://github.com/DISTRHO/DPF/issues/299.

Well, there's a rebased version at https://github.com/lv2/pugl/tree/nested-event-loop-fix and it doesn't break the tests, but the tests don't currently cover modules.
I don't particularly understand this, but it still seems like an elaborate way to do "make client events not work in modules in MacOS" (and "make puglUpdate do nothing") to me.  If it's literally impossible to dispatch events within a specific scope on MacOS... okay I guess?  That seems unlikely though?
In any case, I don't have the ability to test this at the moment, but if any of you can, and if there's some reason why making puglUpdate work properly is impossible, I can probably be convinced to merge it.

if it is worth anything I have been using pugl with this patch/change applied for as long as it has been originally reported, and have seen no issues (contrary to before the patch).

@falkTX You snuck in before the edit, I hadn't noticed that @reuk said it has been tested.
Client events are only used for... well, code that explicitly uses client events, so pugl would generally work aside from that either way.

right I never make use of those for the moment.

Merged as 28d75f7, thanks.
I had to change the run loop mode to kCFRunLoopBeforeSources to get reliable behaviour for programs.  Hopefully that doesn't cause any new issues...


[BUG] Cannot delete  kamelet deployment on OperateFirst

Describe the bug
Trying to delete a Kamelet from the Deployment window, generates an HTTP Status 400 error
Error processing deployment: Failure executing: DELETE at: https://<IP_ADDRESS>/apis/camel.apache.org/v1alpha1/namespaces/kaoto/kamelets/integration-action.

Message: Forbidden!Configured service account doesn't have access.

Service account may have been revoked. kamelets.camel.apache.org "integration-action" is forbidden: User "system:serviceaccount:kaoto:kaoto-operator-integrator-sa" cannot delete resource "kamelets" in API group "camel.apache.org" in the namespace "kaoto".

To Reproduce
Steps to reproduce the behavior:

Go to Deployments
Click on the 3 dots menu
Click on Delete
See error in the network console

Expected behavior
The kamelet should be deleted
Environment (please complete the following information):

OS: [Operate First]
Kaoto Version [0.7.2-dev]

Additional context

Found in operate first

this is not a bug in this case. We simply secured the deployed kamelets from being deleted otherwise they would be missing from the catalog. @mmelko can maybe explain more details.


Crashing upon opening mod menu

Whenever i click on the mod menu it opens it and crashes. the crash report is
`#
A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007fae8e2ba628, pid=12226, tid=12227

JRE version: Java(TM) SE Runtime Environment (17.0.8+9) (build 17.0.8+9-LTS-211)
Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.8+9-LTS-211, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
Problematic frame:
C  [iris_dri.so+0x134628]

Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t<PHONE_NUMBER>854775808 %h" (or dumping to /home/jeebak/Desktop/UltimMC/instances/Sodium Plus 2.2.8-2/.minecraft/core.12226)

If you would like to submit a bug report, please visit:
https://bugreport.java.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

---------------  S U M M A R Y ------------
Command Line: -javaagent:/home/jeebak/Desktop/UltimMC/injectors/authlib-injector-1.2.3.jar=http://localhost:34133 -Xms512m -Xmx1024m -Duser.language=en -Djava.library.path=/home/jeebak/Desktop/UltimMC/instances/Sodium Plus 2.2.8-2/natives org.multimc.EntryPoint
Host: 12th Gen Intel(R) Core(TM) i5-1235U, 12 cores, 7G, Linux Mint 21.2 Victoria
Time: Thu Sep 14 16:48:14 2023 IST elapsed time: 36.224235 seconds (0d 0h 0m 36s)`

After i removed and added each mod i found that removing Zoomify-2.11.0 seemed to solve the problem. So for now as a temporary solution removing Zoomify-2.11.0 seems to be the best option for know. I am requesting a proper solution.

After searching for a bit I found that this problem can be solved by updating the YACL to the newest fabric release meaning it is possible to have zoomify again. I request the Dev to please update the YACL which comes with the pack to the newest fabric release.

Thanks for your report, your right I need to update the pack, I've been quite busy recently. I will update sodium plus within the next couple days.

Thanks


Initial commit of python installation

Do we definitely need this image?  I ran this to check and it looks like Python is included in the base image already:
vagrant@vagrant-mesos:~$ docker container run -it --rm cafapi/opensuse-jre8:1.2 python -c "print ('Hello from Python')"
startup.sh: Running startup scripts...
startup.sh: Running install-ca-cert-base.sh...
install-ca-cert-base.sh: Not installing CA Certificate.
startup.sh: Running install-ca-cert-java.sh...
install-ca-cert-java.sh: Not installing CA Certificate for Java
startup.sh: Startup scripts completed
Hello from Python

I didn't know python was in the base image already. I was building this to use for the base of the jep-talon-image as it needs extra stuff installed like pip and libxml. I wanted to talk to you about this anyway.


[WIP] Optimize write step by skipping convert to 3 steps

Why is this PR needed?
What changes were proposed in this PR?
Does this PR introduce any user interface change?

No
Yes. (please explain the change and update document)

Is any new testcase added?

No
Yes

Build Failed  with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/749/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2457/

Build Failed  with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/766/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2474/

Build Failed  with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/774/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2481/

This is WIP PR, I am NOT working on it now. as it take so much time to finish and stabilize it


Prevent empty contact-us form submission and missing hrefs in the navigation bar

What the title says.

I can work on this one also.

Pull request for this issue : #181

#181 merged

@capooods vivek0033 is a beginner and he already had a PR on this one, so I had to assign him instead. This issue was one of his introductions to open-source. I hope you understand.

No problem, @jay-io ! Good job @vivek0033


Integration with AD [Active Directory] for Requirements / Users

Just revisiting after ~1 year, I feel like my last comment still holds; leaving this in the wish list.

After another read-through, I really don't see this kind of custom integration ever happening. Closing.


Added assets cleanup optimization script

Removes unused jQuery migrate
Removes unused sitepress.js when WPML is enabled
Removes language selector css when WPML is enabled

@aritzolaba Why would we want to remove this scripts?? They are never necessary?

Firstly, let's see what jQuery Migrate does:
"Migrate plugin is created to simplify the transition from older versions of jQuery to newer ones. The plugin restores deprecated features and behaviors so that older code will still run properly on the current jQuery version and later."
So we can assume it is safe not to include it if your project additional libs and jQuery related tools work ok with the jQuery version you are using. It's one request less.
For sitepress.js and the language-selector.css, they can be removed if you are including a custom language selector where you have already coded the selector itself and applied styles.
If those 2 scenarios are met (90% of the projects I believe) we can apply these optimizations that lead to 3 http requests less to make and a lighter website.


Duplicate class definition bug

The css class on author span is duplicated in two places
https://github.com/BST-Plus/BST-Plus/blob/master/includes/loops/content.php#L22
https://github.com/BST-Plus/BST-Plus/blob/master/includes/loops/content-single.php#L16
should read
... span class="text-muted author">

Thanks, DeepSilver. These are now fixed


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/113597

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/120748

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/120782


removing ffmpeg from run dependencies

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


Reproduce incremental compilation bug on file typo rename

Reproduces issue #28916.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

Pull Request Feedback (Trigger) (Check)

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

Pull Request Feedback (Trigger) (Check)

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

Pull Request Feedback (Trigger) (Check)

@bot-gradle clean


Why does ZuulConfiguration use @ConditonalOnMissionBean?

So it seems that ZuulConfiguration.java is no AutoConfiguration Bean but still uses @ConditionOnMissingBean for checking for the absence of certain beans.
But @ConditionalOnMissionBeans seems to be discouraged for non-AutoConfiguration Beans according to the docs:

The condition can only match the bean definitions that have been processed by the application context so far and, as such, it is strongly recommended to use this condition on auto-configuration classes only. If a candidate bean may be created by another auto-configuration, make sure that the one using this condition runs after.

It's a bug


Cannot remove docsets containing a space.

I installed the .Net Framework documentation:
$ dasht-docsets
NET Framework

They did not include FSharp documentation, so I tried to remove them:
$ dasht-docsets-remove
Removable docsets (2):

        NET, Framework

echo Remove NET docset [y/N] ?...
echo Remove Framework docset [y/N] ?...

The space in the NET Framework.docset directory seems to be the culprit.

If in dasht-docset-remove I add:
IFS="
"

right before the set -- $(dasht-docsets "$@") it does work since the output of dasht-docset only gets split on newlines, not on spaces/tabs. The "Removable docsets" line is still incorrect as the sed still replaces spaces by a comma followed by a space.

Thanks for your report! :+1: I'm wondering where that space came from in the first place, because the installer shows that an underscore is used between "NET" and "Framework".  Did the tarball extract out to a folder named with a space instead of underscore?
$ dasht-docsets-install net
--2016-03-07 10:30:58--  https://kapeli.com/docset_links
Resolving kapeli.com (kapeli.com)... <IP_ADDRESS>
Connecting to kapeli.com (kapeli.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 304 Not Modified
File ‘/home/sunny/.local/share/dasht/docsets/docset_links’ not modified on server. Omitting download.

Installable docsets (2):

        MarionetteJS, NET_Framework

Fixed now in master branch at commit b73f37ce0838ecaec2ee826bca113074d372fcae. :gift:
I decided to avoid spaces in the first place by introducing a new dasht-docsets-extract(1) script.


hsic works with kernels, not distances

unlike all other tests used as backends of the latent distribution test (via hyppo), HSic works on kernels, not distances (it is actually almost identical to DCorr, except that it expects a kernel function, not a distance, and hence flips the sign on the test statistic). we currently do nothing about that. some options to consider are:

removing it completely (not a big loss, since, once again, DCorr does a similar thing)
leaving it as is, but expecting a user to provide a callable metric. (if they try to provide "euclidean" - raise an exception)
wrapping the currently used dissimilarity metrics into similarity measures (very obvious how to do it for the gaussian kernel. less so obvious for l1/l2, but obviously possible (for example by subtracting all from the max or doing 1/. )
some sort of a combination of the two right above: for example, expecting a callable metric, but using a gaussian kernel if unspecified.

i might be missing something obvious, but I legitimately have no idea why was it valid and consistent when we ran those simulations, if it expects a kernel, not a distance, and we were providing it with the latter.
@sampan501 maybe you know?

If I'm not wrong, I think @bvarjavand did the transformation for kernel to distance as specified in the exact equivalence paper. In that case, the test should be valid

@sampan501 i do not exactly understand what that means. the way you implement hsic is by using the transformation of kernel to distance, computing the distance (i.e. dissimilarity) matrix, and then using dcorr, since EE says that this is identical to just using hsic:
https://github.com/neurodata/hyppo/blob/da63f814023f956defd0f773b5eb7a59b4f540fa/hyppo/independence/hsic.py#L128-L136
this makes total sense. but... if I were to provide you with a distance to begin with, you would subsequently transform it as 1 - K / max(K) to a kernel and then use dcorr, but that can't be the right thing to do?
unless you are saying that @bvarjavand implemented a way to check whether something is a kernel or a distance and convert it, but I cannot find anything of this sort in hyppo.

"The population HSIC is zero at independence, so the sample is unlikely to be independent when the empirical HSIC is large." ( http://www.gatsby.ucl.ac.uk/~gretton/indepTestFiles/indep.htm ).
that is, both dcorr and hsic reject for the large positive values of the statistic, so it makes sense that it was valid, but we were still using it wrong and should be providing it with kernels.

Yes I meant I think @bvarjavand implemented it this way since he had asked me similar, but he probably knows better. But I agree with your assessment that you should provide kernels


Can't generate .csv files: No such file or directory: 'log/.txt'

Trying to run
python graph.py
yields the following error
Traceback (most recent call last):   File "graph.py", line 64, in <module>     g.generate_all_csvs(start_time=now - 3 * ONE_DAY_SECONDS, end_time=now)   File "graph.py", line 56, in generate_all_csvs     self.to_csv(uid, start_time, end_time)   File "graph.py", line 27, in to_csv     status_history = history.StatusHistory(uid)   File "/Users/vinted/Documents/zzzzz-master/history.py", line 18, in __init__     with open("log/{uid}.txt".format(uid=uid)) as f: IOError: [Errno 2] No such file or directory: 'log/.txt'
A workaround is to replace {uid} with a concrete uid

You need to first collect some data with python3 fetcher.py.

well I have done that

ok, downloaded again and now it works


OAuth2 Fetch token in Auth tab fails to parse out tokens from server response.

It goes through the authorization_code grant type flow correctly, all the way to issuing the POST request to the access_token_uri, the response from the server seems to be correct with the tokens, yet Insomnia reports that it "Failed to fetch token ... status=0" and does not parse out the tokens.
There is nothing useful in the Developer Tools console.
I had to install a local proxy to see the actual http communication (btw, it would be useful to see the oauth2 traffic in the Timeline tab, I think)
The access_token in the server response is a valid JWT token. This is the server response that Insomnia failed to parse out the tokens from:
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2020 21:00:08 GMT
Content-Type: application/json
Content-Length: 1090
Content-Encoding: chunked
X-B3-TraceId: 6c55574578445a36
Server: DexcomApiGateway/1.0.0
Via: 1.1 google, 1.1 google

{"access_token":"{VALID_JWT_TOKEN}","refresh_token":"refreshtoken1","expires_in":600,"token_type":"Bearer"}

Insomnia v<IP_ADDRESS>50 on macOS
Please see my setup:

It looks like the POST access_token_uri is not being executed by the main Insomnia process, it is executed by the "Insomnia Helper" process instead. Is it possible that this process cannot communicate the results back to the mothership?

any  update here?

I do have the same issue, maybe someone should try to build from source to find out where it is caused exactly and open a pr?

same here

This resolved it for me


MdStepper not an exported component of @angular/material

Cannot find any issues concerning this, but I cannot import MdStepper.
import {MatStepperModule} from '@angular/material'; Does not recognize this.
import {MdStepperModule} from '@angular/material'; Does not recognize this.
Does anyone know how to import MdStepperModule properly?

MdStepperModule should work. What version of Material do you have installed?

"@angular/material": "^2.0.0-beta.10",

The stepper component was released in beta.11.

Closing as beta.11 is required to import MatStepper


index macro fails when following form macro

Create a resource and in the register resource block, customize the form page followed by a custom index page. Get error like:
== Compilation error on file web/admin/contact.ex ==
** (CompileError) web/admin/contact.ex:26: undefined function index/1
    expanding macro: ExAdmin.Register.register_resource/2
    web/admin/contact.ex:4: ContactDemo.ExAdmin.Contact (module)
    (elixir) lib/kernel/parallel_compiler.ex:116: anonymous fn/4 in Kernel.ParallelCompiler.spawn_compilers/1

Work around. Create index first, followed by form