add a clearer doc-block comment to $pagination-mobile-current-item

as suggested here: https://github.com/zurb/foundation-sites/pull/9125#issuecomment-254199711
(maybe a native english dev could write the same with fewer words)
best regards

the usual travis build error on phantom-js

npm ERR<EMAIL_ADDRESS>install: node install.js
npm ERR! Exit status 1


Refactor meltano elt, SingerRunner and DbtRunner to be composable

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2725
Originally created by @DouweM on 2021-04-26 16:55:44

As @aaronsteers noticed in https://gitlab.com/meltano/meltano/-/merge_requests/2105#note_558353646, the SingerRunner code is a mess of async futures and very hard to understand.
It is currently hard-coded for the tap | target scenario and will need to be refactored to support tap | transformer | target (https://gitlab.com/meltano/meltano/-/issues/2300) and meltano run tap transformer target dbt (https://gitlab.com/meltano/meltano/-/issues/2301).

View 42 previous comments from the original issue on GitLab


add marcokumu profile

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

LinkFree profile creation

updated checklist

I've made the requested changes. Please check.


Add workflow to receive notifications from upstream Horreum.

Horreum Plugin versioning is being modified to align the version with the upstream Horreum project.
A message will be received from the Horreum project workflow with the released version information.
This workflow does the following:

Version bump Horreum dependency
Set horreum-plugin version to maintain alignment
Commits the change(s)
Creates a Pull Request

This PR relies on using a Personal Access Token or a Fine Grained Access token. Created with the permission public_repo.
To be created with the name GITHUB_PERSONAL_ACCESS_TOKEN.

@MarkEWaite do you have any advice on the feasibility for a Contributor (myself) of getting a PAT created so the Horreum project can initiate a notification ?

@MarkEWaite do you have any advice on the feasibility for a Contributor (myself) of getting a PAT created so the Horreum project can initiate a notification ?

Best way to get in touch is via the jenkinsci-dev mailing list or the helpdesk.
I don't think you need any of this, you can probably just make renovate work for this

@timja Hi and thanks for the suggestions. I created a ticket on the helpdesk.
I agree renovate or dependabot can handle version bumping but I also set the version of the project to be identical.

@timja Hi and thanks for the suggestions. I created a ticket on the helpdesk.
I agree renovate or dependabot can handle version bumping but I also set the version of the project to be identical.

You can get renovate to update the property and use that property for your project version

You can get renovate to update the property and use that property for your project version

Is the end result any different to using the versions plugin with Maven ?

You can get renovate to update the property and use that property for your project version

Is the end result any different to using the versions plugin with Maven ?

If you use one property a human won't be able to move it out of sync and using renovate means you'll need no custom workflow to maintain.

@johnaohara is horreum-plugin project open to the idea of using Renovate to manage the version bump ?

The documentation indicates it is available as a Github Action

@johnaohara but no there is no Self hosting option available to run Renovate.

@timja Thank you for providing some clarity. Have decided to go with using a familiar bot called dependabot rather than Renovate.


Add username to event notification display

closes #1112

Coverage remained the same at 83.226% when pulling 8fced2b0926fba3dcc490f93d48fcb0207491081 on mparke:notifications-add-user into e1efc9930a0f89ccbc90cebaef51e0f30d36e359 on linode:master.

Coverage remained the same at 83.226% when pulling af3c3586768f8e4f760068ca52e7ab968a3359ee on mparke:notifications-add-user into e1efc9930a0f89ccbc90cebaef51e0f30d36e359 on linode:master.


Changed query output to be in camelCase rather than snake_case

Changed query of table data to be in camel case so that object destructuring of parsed JSON output results in camel case variables

I just learned that you can specify aliases in object destructuring


About Me Section Becomes "Shy"

Created a function so the about me fades in and out when the mouse touches this section.

haha great 👍


WIP: Multi cloud dns

https://issues.redhat.com/browse/CO-631
modify the dnsendpoint controller to read the new format of the file containing the managed domains configuration (now just a JSON dump of hiveConfig.Spec.ManagedDomains).
modify ReconcileDNSEndpoint struct to hold a map of domains being managed.
add test cases to ensure proper processing of the updated configuration file format.
update existing test cases to accommodate the new ReconcileDNSEndpoint fields.

@dgoodwin @staebler curious what your thoughts are on the expected behavior for these cases
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR191
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR213

@dgoodwin @staebler curious what your thoughts are on the expected behavior for these cases
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR191
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR213

@joelddiaz They should not return an error. An error will cause the DNSZone to be re-queued. But the DNSZone will always fail, so there is no benefit in reconciling it again.

@dgoodwin @staebler curious what your thoughts are on the expected behavior for these cases
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR191
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR213

@joelddiaz They should not return an error. An error will cause the DNSZone to be re-queued. But the DNSZone will always fail, so there is no benefit in reconciling it again.

Right, that was my thinking in not returning an error. I guess the only way we would end up in this situation is a DNSZone that was created when domain x.y.z was managed, then later hiveconfig was updated to no longer support x.y.z.
Does setting a condition on the DNSZone sound reasonable?

@dgoodwin @staebler curious what your thoughts are on the expected behavior for these cases
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR191
https://github.com/openshift/hive/pull/758/files#diff-f3f1cb0eefaf77b85b906e14900cca3dR213

@joelddiaz They should not return an error. An error will cause the DNSZone to be re-queued. But the DNSZone will always fail, so there is no benefit in reconciling it again.

Right, that was my thinking in not returning an error. I guess the only way we would end up in this situation is a DNSZone that was created when domain x.y.z was managed, then later hiveconfig was updated to no longer support x.y.z.
Does setting a condition on the DNSZone sound reasonable?

Sounds reasonable to me.

@staebler i've gone through your feedback (thanks!), went ahead an implemented the new condition (that required an update to our vendored testify/assert package as i was getting panics while running my new test cases).
lastly, i ran into an issue when restarting the controller. it wouldn't properly handle GCP DNSZone objects as the create/update path the controller took would only work for create. after some research, i came up with a series of API calls that allow updates to an existing NS record.

@staebler i've renamed the condition to something more user-friendly, and changed the flow of the update handling to always just try a create first (and added some live tests to cover the update path)

/test e2e

@staebler ok, i updated the test cases to do a more proper update flow (separate commit). if this all looks good, then i'll squash and repush

@staebler ok, i updated the test cases to do a more proper update flow (separate commit). if this all looks good, then i'll squash and repush

Squash away!

/test e2e

/test e2e-gcp


chore: remove filesystem.hpp

Since we can use C++17 from Galactic, we don't need this file anymore.

Run the full-build CI just in case: https://github.com/autowarefoundation/autoware.universe/runs/5317532653?check_suite_focus=true


python3Packages.guppy3: 3.1.1 -> 3.1.2

Motivation for this change
Update to latest upstream release 3.1.2
Change log: https://github.com/zhuyifei1999/guppy3/blob/master/ChangeLog
Things done

Built on platform(s)

[s] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 141078 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.guppy3
python39Packages.guppy3

Result of nixpkgs-review pr 141078 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.guppy3
python39Packages.guppy3


Dual boot friendly (emulated) EEPROM management

    Hello Rubén!
I am using your iArradio on T5S in 'dual boot' configuration: https://github.com/lyusupov/SoftRF/wiki/SkyView.-Dual-boot
On ESP32 the EEPROM area is emulated by main flash memory region.
When an application is alone - it is Ok, but when there are two of them - they overwrite each other's settings.
My proposal for you is to 'color' your application settings with a dedicated NVS key.
This way is simple, compatible, safe, sane and gives the necessary EEPROM separation effect.
The patch is attached to this pull request.
    Best regards,
    Linar.

Great!
I will try out and merge your modifications. Also I will include a link to your explanation in the README. Didn't knew this ESP32 platform feature. It looks useful, easy to implement and very compatible.

Good news!
FYI:

ESP32 bootloader has to be custom built with 'APP_TEST' option ben enabled
https://github.com/espressif/esp-idf/blob/master/components/bootloader/subproject/main/bootloader_start.c#L97
subtype for app1 partition has to be changed from 'ota_1' onto 'test'
https://github.com/espressif/arduino-esp32/blob/master/tools/partitions/min_spiffs.csv


Support TS

Please make sure these boxes are checked before submitting your PR, thank you!

[x] Make sure you follow DiDi's contributing guide.
[x] Make sure you are merging your commits to dev branch.
[x] Add some descriptions and refer relative issues for you PR.

Codecov Report

Merging #189 into dev will decrease coverage by 0.02%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##              dev     #189      +/-   ##
==========================================
- Coverage   91.44%   91.41%   -0.03%
==========================================
  Files         108      108
  Lines        2372     2376       +4
  Branches      351      351
==========================================
+ Hits         2169     2172       +3
- Misses        102      103       +1
  Partials      101      101

Impacted Files
Coverage Δ

src/components/radio/radio.vue
100% <ø> (ø)
:arrow_up:

src/common/helpers/create-api.js
100% <100%> (ø)
:arrow_up:

src/common/helpers/util.js
77.33% <83.33%> (+0.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Updated the environment-variables.md

Why:

Closes #2693
What's being changed:
I have followed the instructions in the issue to fix this. I have corrected the text in the note box to the mentioned paragraph.
That is,
"When you set a custom environment variable, you cannot use any of the default environment variable names listed above with the prefix GITHUB_. If you attempt to override the value of one of these default environment variables, the assignment is ignored."
I did not remove the Note:  (After reviewing the localization checklist) because it was mentioned that the previous one should be change to 'rather a note'.
I am just getting started with open-source so I am sorry if I have done anything that is incorrect.

Check off the following:

[x] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[x] For content changes, I have reviewed the localization checklist
[x] For content changes, I have reviewed the Content style guide for GitHub Docs.

👋 @Sreelayavuyyuru Thank you so much for opening a PR with this fix!

in content/actions/reference/environment-variables.md, change... to a simple paragraph (rather than a note)

From that statement in the issue, I think we do want to remove the {% note %} and {% endnote %} tags. Since this file is a reusable, it's visible in a few different articles and it looks like @hubwriter would prefer it show up in the article as a paragraph, instead of a note.
Let me know when you've removed the tags and I'll get this up for review ⚡

Hey @janiceilene, Thank you so much for the instructions!
I have removed the tags, so it looks like a paragraph now like you mentioned 👍🏼


Create website blog + welcome post

Contributes to #845
Preview:

https://deploy-preview-1057--opentelemetry.netlify.app/blog
https://deploy-preview-1057--opentelemetry.netlify.app/blog/2022/welcome/

Note the design decisions here:

We're not introducing any Blog subsections to partition posts into "categories" (like News or Releases)
Individual files for post will be placed under a folder for the year that they are published. This will help keep the blog directory manageable over time.

/cc @tedsuo

I agree with the simpler formatting for paths, this looks good to me.


gh-200+221+439+586: Cannot use TPM

Hi @gpakosz  :wave:
I have tested the branch gh-200+221+439+586 without modifying tmux.conf (all my settings are in my tmux.conf.local).
I get the following message when loading the configuration: 'Cannot use tpm which assumes a globally installed tmux'.
Although I don't understand completely the way TMUX_PROGRAM is set, I guess the problem could be that, for me, command -v tmux returns
alias tmux=_zsh_tmux_plugin_run

This is because I am using the tmux plugin from oh-my-zsh, which defines _zsh_tmux_plugin_run and sets this alias.
I don't understand enough what happens in tmux.conf to propose a fix, but I'd be happy to provide more information and test possible solutions.
tmux version: 3.3a

Hello @sylph1o 👋
I pushed a commit in the gh-200+221+439+586 branch to fix that detection

Thanks for the quick reply. I see your fix, and I tried the latest version from gh-200+221+439+586. It didn't change the issue, and I think I know why.
To get the output of command -v tmux that I gave above, I ran the command in my terminal, i.e. an interactive zsh session. However, as I understand it, the code in tmux.conf is run in a non-interactive sh session (sh is linked to bash on my computer), meaning that my zsh aliases and plugins are not loaded. The information I gave was not relevant, sorry for misleading you.
To get the values seen by the functions in tmux.conf, I inserted a few lines above if [ command -v tmux ... (line 1420, where the test fails even though it should not) to return the relevant values (e.g. `echo $TMUX_PROGRAM > some_file'). Below is what I get
> echo $TMUX_PROGRAM
/usr/bin/tmux

> command -v tmux
tmux

> which -a tmux
/usr/sbin/tmux
/sbin/tmux
/bin/tmux
/usr/bin/tmux
/bin/tmux

I don't understand the output of command -v tmux. When I run in my terminal sh -c 'command -v tmux', I get /usr/sbin/tmux, which is coherent with the output of which -a tmux.
Just in case, I have also tried disabling the tmux plugin of oh-my-zsh, and starting the tmux server and session from a bash shell. Neither changed the values that I list above (the ones seen by the functions in tmux.conf).

As a side note, even if command -v tmux returned the same as which tmux (i.e. /usr/sbin/tmux), that would not match $TMUX_PROGRAM.  Both  /usr/sbin/tmux and /usr/bin/tmux are the same file (hardlinks) but /usr/sbin is first in PATH. None of this is my doing, this is the normal setup in Arch Linux.
However, which -a tmux | grep -q $TMUX_PROGRAM would give a positive match, but I don't know if that condition checks what you want to check in line 1420.

> which -a tmux
/usr/sbin/tmux
/sbin/tmux
/bin/tmux
/usr/bin/tmux
/bin/tmux

First time I see this! Why so many?

I don't understand the output of command -v tmux. When I run in my terminal sh -c 'command -v tmux', I get /usr/sbin/tmux, which is coherent with the output of which -a tmux.

My fix is indeed incorrect, that's because .tmux.conf defines a tmux() function to make sure it talks to the proper tmux program that may not be in the pass. Comparatively, TPM uses tmux and assumes it's installed globally.
What Oh my tmux! is trying to guard against is: TPM can't work if there's no tmux program in $PATH while Oh my tmux! can now generally work if you launch it with a locally compiled version of tmux that may be renamed to something else, e.g. tmux-3.3a.
Pushed another tentative fix

Thanks for the explanation, it makes more sense now.

First time I see this! Why so many?

/bin, /sbin and /usr/sbin are all symlinks to /usr/bin (I was wrong to mention hardlinks in my previous comment). This is defined in the file system hierarchy for OS using the systemd service manager (see file-hierarchy(7)), for compatibility.
Additionally, /bin/tmux appears twice because /bin appears twice in the PATH seen by the functions of Oh my tmux!. I don't know why: in my interactive shell, sh -c 'echo $PATH' returns only one occurrence of /bin.

Pushed another tentative fix

I have just tried it, and it works! This solves my issue.
I must say I'm very grateful to see the support for different locations of the configuration file. Having to patch manually was the only (very minor) inconvenience for me so far. This is an appreciable quality-of-life improvement, thanks! :pray:


Error tool capturing only profile MS2 for PRIDE Raw submission

@nielshulstaert @caetera :
We have found an "interesting" behavior (https://github.com/nf-core/proteomicslfq/issues/52) when running TRFP into one raw file from a COVID dataset. The tool only exports into the mzML the profile MS2 but not the centroid.
The raw file is:
03.raw

This sounds like the same bug that I emailed Niels about some time back. I don't think there was a resolution. We're interested in a resolution too. Here was the original report:
We think we have observed a peak-picking bug in ThermoRawFileParser:
Dataset: PXD013999
File: KO5.raw
After running:
mono /regis/sbeams/bin/ThermoRawFileParser/ThermoRawFileParser.exe -i=$name.raw -f=2 -o=./ -m=1 --metadata_output_file=$name-meta.txt
(produces a 13 GB mzML file)
we find that the MS2 scans are not peak-picked?

But when we do:
msconvert.exe --mzML --filter "peakPicking true [1,2]" -z  --32 $name.raw
(produces a 1.2 GB mzML file)
It does seem to peak pick these.

It does work on most files we have, but not on this file (and its siblings)

@edeutsch we will have a look. @nielshulstaert will take a look tomorrow. The dataset I reported is actually a COVID-19 which is really important. I think is the capturing method. If @nielshulstaert can't do it, I will give a try.

I have seen this kind of behavior on some files with IT profile data. It seems like vendor libraries depend on centroiding provided by the instrument (it was named labels, as far as I can remember). Can it be that MSConvert falls back to its own centroiding algorithm when it cannot perform centroiding by vendor libraries?

It could be. msconvert does have its own code for that. I was vaguely under the impression that msconvert always used vendor centroiding for all Thermo data, but I have no concrete information. Should we ask Matt? He could provide a definitive answer.

I think I can find the solution - Scan.ToCentroid  method can perform centroiding of the profile spectra, if no CentroidStream is present in Scan itself. @nielshulstaert did you find this as well? (Just so I know if I need to change the code)

Hi @caetera thanks for the tip, I wasn't aware that method existed! Indeed there is no centroided data available for those profile scans. So should we always use this method unless the p|noPeakPicking argument is provided?

Hi @nielshulstaert , when testing I have found a caveat - when applied to FTMS spectra that spit CentroidStream by default, it will redo the centroiding and thus will give wrong results (as far as I can say, it treats centroids as profile points). I haven't tested it with spectra that are centroided in raw file. If the API will pass them as CentroidStream that should be fine. I should have time this evening to check how API handles the "pre-centroided" spectra.

Ok it makes sense not do to it on already centroided data. I have time to work on it this afternoon, I'll keep you posted on my progress.

Hi @caetera I've made a new branch with the changes, thermolibupgrade. I've tested it on some RAW files and it seems to work. Could you try it on an FTMS dataset? @edeutsch your example file output is a lot smaller now (the resulting MGF has the same size as an MSConvert one).

Hi @nielshulstaert
During the test I can observe that only FTMS scans have CentroidStream, ITMS scans even when centroided still only have SegementedScan. The code you have added performs centroiding every time the spectrum does not have CentroidStream. I tested it on raw file with centroided ITMS (i.e. they do not have CentroidStream ) scans and it works correctly. Although I could not break it maybe it is better to have additional check for the case when scan has no CentroidedStream, but still centroided.
What do you think?
Here is a piece of code I changed in MzMlSpectrumWriter (to explain better what I mean)
if (!ParseInput.NoPeakPicking)
{
   //The spectrum to be written is going to be centroid anyway
   spectrumCvParams.Add(new CVParamType
   {
   	accession = "MS:1000127",
   	cvRef = "MS",
   	name = "centroid spectrum",
   	value = ""
   });

   if (scan.HasCentroidStream)
   // centroided stream is proviede by raw file, for example FTMS scan
   {
   	var centroidStream = scan.CentroidScan;
   	if (centroidStream.Length > 0)
   	{
   		basePeakMass = centroidStream.BasePeakMass;
   		basePeakIntensity = centroidStream.BasePeakIntensity;
   		lowestObservedMz = centroidStream.Masses[0];
   		highestObservedMz = centroidStream.Masses[centroidStream.Masses.Length - 1];
   		masses = centroidStream.Masses;
   		intensities = centroidStream.Intensities;
   	}
   }
   else
   {
   	//if the spectrum is profile perform centroiding otherwise use it as is
   	var segmentedScan = scanEvent.ScanData == ScanDataType.Profile ? Scan.ToCentroid(scan).SegmentedScan : scan.SegmentedScan;

   	if (segmentedScan.PositionCount > 0)
   	{
   		basePeakMass = scan.ScanStatistics.BasePeakMass;
   		basePeakIntensity = scan.ScanStatistics.BasePeakIntensity;
   		lowestObservedMz = segmentedScan.Positions[0];
   		highestObservedMz = segmentedScan.Positions[segmentedScan.PositionCount - 1];
   		masses = segmentedScan.Positions;
   		intensities = segmentedScan.Intensities;
   	}
   }
}
else
// we requested to provide profile spectrum if possible
{
   // Get the scan statistics from the RAW file for this scan number
   var scanStatistics = _rawFile.GetScanStatsForScanNumber(scanNumber);

   basePeakMass = scanStatistics.BasePeakMass;
   basePeakIntensity = scanStatistics.BasePeakIntensity;

   // Get the segmented (low res and profile) scan data
   var segmentedScan = _rawFile.GetSegmentedScanFromScanNumber(scanNumber, scanStatistics);
   if (segmentedScan.Positions.Length > 0)
   {
   	switch (scanEvent.ScanData)
   	{
   		case ScanDataType.Centroid:
   			spectrumCvParams.Add(new CVParamType
   			{
   				accession = "MS:1000127",
   				cvRef = "MS",
   				name = "centroid spectrum",
   				value = ""
   			});
   			break;
   		case ScanDataType.Profile:
   			spectrumCvParams.Add(new CVParamType
   			{
   				accession = "MS:1000128",
   				cvRef = "MS",
   				name = "profile spectrum",
   				value = ""
   			});
   			break;
   	}

   	lowestObservedMz = segmentedScan.Positions[0];
   	highestObservedMz = segmentedScan.Positions[segmentedScan.Positions.Length - 1];
   	masses = segmentedScan.Positions;
   	intensities = segmentedScan.Intensities;
   }
}

You're right @caetera it's better with the check. I've pushed the changes to the thermolibupgrade branch. Thanks for all your input, I'll release a new version on Sunday. Let me know if I missed something.

@nielshulstaert I have added the centroid/profile detection for PROXI format (similarly how it is performed in mzML). When there is no profile spectrum, but user request it.
Also moved few comments.

@edeutsch @ypriverol I've released a new version, let us know if it works.


Doc fixes.

The changes look great.
However, if the correct style for keywords is slightly shaded code boxes, then there are a couple of actual bolds that probably should fixed on the same page:
E.g.

The myStaticValue  in this text:

The following static property definition is based on a scenario in which you have a static field myStaticValue that is the backing store for the property.

let and do in this text:
, just like let bindings and do bindings in a type definition.

Perhaps set in this text.
You can set properties that provide set accessors by using the <- operator.

and 20 in the output here:
The output is 20.

@KevinRansom just committed another change that should fix that. Thanks for the heads-up!

let and do are still bold in this text: , just like let bindings and do bindings in a type definition.
Also I see this text when I view:
You can set properties that provide  set  accessors by using the  <-  operator.

@KevinRansom fixed!

This looks great, thanks Den, you are doing a brilliant job.
Thank you,
Kevin


To use gpt-4-vision-preview add an OpenAI API key?

sorry im new to this, but can someone help me with this issue? also does gpt 4 vision cost money?

The repo's Quick Start Guide should help you with this. You have to edit the .env file, and place your OpenAI API key where it says "api-key here" or like whatever.
Also, yes it does cost money, as you need access to GPT4, which requires a monthly subscription of 20usd per month.
An alternative is using Ollama's LLAVA model, you can access it using this pull request. Requires Ollama, around 5gb of free space, and a somewhat good computer. You will also need to change the code if you are local hosting it. Sadly, lacks sufficient usage documentation. Oh well ;p

@GangstersPairOfDice's input is correct. On a related note, I improved the initial setup flow. Now all you need to do is do pip install self-operating-computer and then operate. It will prompt you for your openai key which makes the process smoother. I'll close this ticket for now since it is not bug related. Reopen a ticket if you have issues or other questions. Thanks


Fix relative paths

Signed-off-by: Luke Hinds<EMAIL_ADDRESS>

apologies, missed this, should be a very quick easy review @dlorenc / @bobcallaway


Iteration and workItem detail overlapped ,Distorted display

Iteration and workItem detail overlapped ,Distorted display

@vikram-raj @naina-verma why is UX needed for this? This is a z-index bug. Looking at the code, the panel is set to a crazy high 9999.


Modify files to get JSON formatted data from server

I will be adding some commits to correctly implement the random message on the page with JSON formatted strings.


would it better to support on external KafkaSink to support single Array[Byte] rather than (Array[Byte], Array[Byte])

I have to make my sink source message format to tuple2(Array[Byte], Array[Byte])
if not match that format, it would throw class cast exception in backend.
but it would be better just support Array[Byte] and then serialize it to an Object?

thanks for your advice. I've opened #1398 to account for both cases.


<rh-cta>: remove public cta getter

Remove public cta getter
https://github.com/RedHat-UX/red-hat-design-system/blob/d983ce43c1b6d82510105fda42589116133165b1/elements/rh-cta/rh-cta.ts#L150-L164
Deprecated 2 months ago
Note: We will likely hold on to this one for a bit as it is a relatively new deprecation that hasn't been released yet.

IIRC we checked with the relevant parties and ensured that this isn't in use on pages likely to bring in 2.0. Let's do this for charmander, put it on my tab ;)


Allow bags to be dumped into a biogenerator

About the PR
Players can now either feed produce one at a time to biogenerators, or in bulk using a container (presumably a plant bag, but any container should work too).
Why / Balance
Adding produce to the biogenerator one at a time is tedious and gets old really quickly.
Technical details
I modified ProduceMaterialExtractorSystem to check if the used item has a StorageComponent, and if it does, process each item in the container with the same code as if they were being used directly.
Media
Screencast from 2024-10-06 16-58-28.webm
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
No breaking changes.
Changelog
:cl:

add: Plant bags (and other containers) can now be used to feed produce to a biogenerator

Function should be copied over for biomass reclaimer (#23731)

The biomass reclaimer code seems completely separate, so I doubt I'll be able to share the logic between them. I'd prefer to keep this PR simple, so I'll open a separate one for the biomass reclaimer.

The test failure seems to be unrelated to this PR (something to do with temperature?)


Secure password reset over email

The register command should take an email address. There should then be a reset password command which takes an email address as an argument and sends a new password to the email provided. There should also be a change password command.

I'm not longer interested in integrating with email.


jQuery .attr() deprecated for use with the "disabled" property

In both /public/js/Variables.js and /public/js/Variables.min.js files .attr() is used with the disabled property. jQuery has deprecated this use in its most recent versions, which WordPress is using now. jQuery now requires .prop() instead to set and retrieve the value of "checked", "selected" and "disabled" properties of a node.
https://github.com/hyyan/woo-poly-integration/blob/383d3aa7ab16f9811344ed84ebb42539ec9e6b60/public/js/Variables.js#L80
The line:
this.$('#submitdiv *').attr('disabled', enable);
should be:
this.$('#submitdiv *').prop('disabled', enable);

do you want to check in an update for this?

Do you want me to do a PR?

sure you seem to have this under control :)
I'm busy looking at synchronisation of variation default attributes and stock status

Done


no setType for createCaptureRequest

i was trying to save the image with my custom proc but it doesnt run because theres no setType in createCaptureRequest. can somebody help me? TIA
get('procedure_loader_factory')
                    ->createProcedureLoader($location);

    $client = Client::getInstance();

    $client->getProcedureLoader()->addLoader($procedureLoader);

    //$request = $client->getMessageFactory()->createRequest($requestLink,'GET');

     $request = $client->getMessageFactory()->createCaptureRequest($requestLink,'GET');

    $file = './captures/';

    $top    = 10;
    $left   = 10;
    $width  = 200;
    $height = 400;

    $setCaptured = $request->setCaptureFile($file);

    $request->setCaptureDimensions($width, $height, $top, $left);

    $request->setType('scrape2');

    $response = $client->getMessageFactory()->createResponse();

    $client->send($request, $response);

    echo "";
    var_dump($response->content);
    echo "";

Set type has been added to the 4.* release.


Update token request to aws-iam-authenticator

Command to request the token for logging into the Kubernetes dashboard needs to be updated to use the aws-iam-authenticator
Issue #, if available:
#740
Description of changes:
Update the shown command to be aws-iam-authenticator token instead of aws eks get-token
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Could also use the --token-only flag with aws-iam-authenticator if we want to eliminate the extra step of piping into jq for parsing. Both provide the required token.

aws eks get-token uses aws-iam-authenticator under the hood. Why do you believe that this needs to be changed? Is something broken?

Call fails when trying to call it with aws eks get-token. Something must be broken. Using the current command you get the following.

The screenshot shown in the example actually uses the aws-iam-authenticator command as well. So not sure where the two diverged.

Hi - could you check if this is still an issue when using the latest aws cli v2? Instructions are available here. https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html
I've raised a PR (#744) to fix this.

Can confirm that after updating with aws-cli v2 the aws eks get-token command works correctly.

Addressed in commit 8c074fa.

awesome! we ended up pushing instructions to upgrade aws-cli to the
latest version, which should enable the get-token function to work as
written. we'll explore moving to the v2 cli with more comprehensive testing
down the road.
Thanks!
Brent
On Wed, Apr 1, 2020 at 1:39 PM Benjamin Fields<EMAIL_ADDRESS>wrote:

Can confirm that after updating with aws-cli v2 the aws eks get-token
command works correctly.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws-samples/eks-workshop/pull/741#issuecomment-607423260,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB3SEFQRXRWIFGKUV7IRD3RKOC4JANCNFSM4LV3OJOA
.


Regenerate VRG manifest work on Hub recovery

We are handling here the case when Hub is recovering and we are in Initial Deploy flow (not Failover and not Relocate!).
We are assuming, that hub recovery does not delete the VRG on the managed cluster, but it's corresponding VRG manifest Work does not exist on the Hub.
We will recreate MW for VRG, cached by drplacement controller from the managed cluster (using MCV). Replication state of MW for VRG recreation is also based on Spec read from the managed cluster.

@ELENAGER can we drop the merge commit, a rebase to main would be better than a merge, such that when we merge this PR the merge commit is not part of it.

Closing this PR because of multiple merge commits. I opened another one: https://github.com/RamenDR/ramen/pull/892


type 'Plugin_2' 'Plugin' is not assignable to type 'PluginOption'.

Describe the bug
4.0 开始插件类类型似乎出现了问题，这导致了很多插件不能直接在vite4上使用
plugins
类型： (Plugin | Plugin[] | Promise<Plugin | Plugin[]>)[]
https://github.com/kumv-net/vite3-4-unocss-macros
Reproduction
https://github.com/kumv-net/vite3-4-unocss-macros
Steps to reproduce
No response
System Info
v4

Used Package Manager
pnpm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[x] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

This seems to be a bug of TypeScript or a incompatibility between TypeScript/pnpm.
Both Vite 3 and Vite 4 exists in the node_modules directory. Vite 3 depends on Rollup 2 and Vite 4 depends on Rollup 3; and these plugin types are not compatible.
import 'vite' in unocss/vite somehow resolves to Vite 3 even if we expect that to resolve to Vite 4.
The workaround is to add the following part to tsconfig.json.
    "paths": {
      "vite": ["node_modules/vite"]
    }

or to add "preserveSymlinks": true to tsconfig.json.

I'm pretty sure this is a pnpm bug.
In pnpm's layout, the path for the version of unocss used with<EMAIL_ADDRESS>is:
./node_modules/.pnpm/unocss@0.51.8_postcss<EMAIL_ADDRESS>
The peer deps appear to all be set up correctly in unocss, given the path for this folder shows the intended version. But, write a loop to emulate the lookup order and you'll see that vite is not actually in this tree until the "fallback" hoisted deps in .pnpm/node_modules (used to try and handle any packages which forget to mark their deps):
$ cd ./node_modules/.pnpm/unocss@0.51.8_postcss<EMAIL_ADDRESS>$ (while [ $PWD != '/' ]; do TEST="$PWD/node_modules/vite/package.json"; [ -f $TEST ] && echo "$TEST $(jq -r '.version' < $TEST)" && break || echo $TEST not found; cd ..; done)
/home/jabaile/work/vite3-4-unocss-macros/node_modules/.pnpm/unocss@0.51.8_postcss<EMAIL_ADDRESS>not found
/home/jabaile/work/vite3-4-unocss-macros/node_modules/.pnpm/unocss@0.51.8_postcss<EMAIL_ADDRESS>not found
/home/jabaile/work/vite3-4-unocss-macros/node_modules/.pnpm/unocss@0.51.8_postcss<EMAIL_ADDRESS>not found
/home/jabaile/work/vite3-4-unocss-macros/node_modules/.pnpm/node_modules/vite/package.json 3.2.6

@jakebailey Thank you for taking a look!
I see. I checked the Node's behavior by injecting import * as v from 'vite'; console.log(v.version) in unocss/dist/vite.mjs and importing unocss/vite from a file inside package/4.3.3 now. I can confirm this is a bug in pnpm.

good👍🏻


Remove default value from type attribute

The XSD defines a default value (string) for the type attribute of the field tag. PhpStorm (or an extension?) even issues a warning ("Redundant default attribute value assignment") when I set the attribute to string.
So either the code has to be changed to reflect the XML definition, or the definition needs to be changed - which this PR does.

I'll have to check whether this makes sense: if there is a default type in the XmlDriver or the mapping itself, it should be reflected in the schema (as it is now).
You can help this by writing a test case that loads an XML mapping containing a field without a type specified: the field shouldn't have a type of string. If it's handled as a string, the default needs to remain in the schema.

I just realized that I left out the most important part from my original post: If I do omit the type attribute, I get an "Undefined index: type" error. As I said: maybe the code should be fixed instead of the XML definition.
Also, IIRC the ORM has the same problem.

FWIW we're having string as the default in annotations

@MidnightDesign in that case, you already answered what I didn't have time to investigate yet. If the code indeed requires you to provide a value for the type attribute, it shouldn't have a default value in the schema. If the same applies to ORM, go ahead and create a pull request there as well.
Thanks!


Made ReadMe More Clear

Hey there!
While using this in my new flutter project, I noticed the ReadMe stated that BDW_HIDE_ON_STARTUP should be added.
This is false, and I believe it could cause some confusion with new users. Adding BDW_HIDE_ON_STARTUP closes the window as soon as it opens, preventing the user from doing anything, even creating a new window, since the application gets terminated because the window was closed.
The library works fine without BDW_HIDE_ON_STARTUP, so I created a pull request ( #68 ) to prevent confusion.
Please review the pull request #68 have a great day!

Well, that's an absolutely normal behavior. Use
doWhenWindowReady(() {
    appWindow.alignment = Alignment.center;
    appWindow.show();
  });

to show the window as soon as it's ready
'BDW_HIDE_ON_STARTUP' flag does not 'closes the window as soon as it opens', it never shows it until you call a show function


📝 Documentation: Consider renaming files from UPPERCASE to PascalCase

Bug Report Checklist

[X] I have pulled the latest main branch of the repository.
[X] I have searched for related issues and found none that matched my issue.

Overview
I asked this:

In JavaScript/TypeScript ecosystem land, is there any good reason for UPPERCASE file names (README.md, .github/DEVELOPMENT.md) instead of PascalCase (ReadMe.md, .github/Development.md)?
Taking a fresh look at them, I'm finding the UPPERCASE names to be kind of jarring... 🤔

...on a few social media platforms:

Bluesky post
Fosstodon post
Twitter post

...and am now thinking about it. Maybe I'll rename everything except README.md? Or maybe everything except the root-level files?
Additional Info
No response

I think it's fine as-is.


Fix: call method 'close' of CancellationTokenSource leads to Concurre…

close CancellationTokenSource directly leads to ConcurrentModificationException to the ListArray 'registrations', because each CancellationTokenRegistration would remove itself from the CancellationTokenSource when in its 'close' method

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at<EMAIL_ADDRESS>Thanks!

Good catch!


label no longer fails when called without a client

What does this pull request do?
elasticapm.label(. . .)no longer fails when no client is present
Related issues
closes #1595

:grey_exclamation: Build Aborted

The PR is not allowed to run in the CI yet

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-07-25T10:10:14.927+0000

Duration: 3 min 24 sec

Steps errors
Expand to view the steps failures

Load a resource file from a shared library

Took 0 min 0 sec . View more details here
Description: approval-list/elastic/apm-agent-python.yml

Error signal

Took 0 min 0 sec . View more details here
Description: githubApiCall: The REST API call https://api.github.com/orgs/elastic/members/dennis-wey return the message : java.lang.Exception: httpRequest: Failure connecting to the service https://api.github.com/orgs/elastic/members/dennis-wey : httpRequest: Failure connecting to the service https://api.github.com/orgs/elastic/members/dennis-wey : Code: 404Error: {"message":"User does not exist or is not a member of the organization","documentation_url":"https://docs.github.com/rest/reference/orgs#check-organization-membership-for-a-user"}

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

/test linters : Run the Python linters only.

/test full : Run the full matrix of tests.

/test benchmark : Run the APM Agent Python benchmarks tests.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

:globe_with_meridians: Coverage report

Name
Metrics % (covered/total)
Diff

Packages
100.0% (68/68)
:green_heart:

Files
100.0% (227/227)
:green_heart:

Classes
100.0% (227/227)
:green_heart:

Lines
89.644% (17260/19254)
:+1: 0.002

Conditionals
76.869% (3147/4094)
:+1:

/test linters

@basepi @beniwohli thanks for reviewing and merging this so quickly! Would it be possible to create a bugfix release with the current changes on master?

Yes I'll create a bugfix release, probably tomorrow.

Version 6.10.2 is released.


About Generic Template

Is it posible to add button customization with foreach?
example :
foreach ($profiles as $profile){

                        $reply->addElement($profile->name, $profile->intro)
                            ->buttons()
                            ->addPostBackButton('Details','PROFILE_'.$profile->id);

                        if(!empty($profile->address)){
                            $reply->addPostBackButton('My Address', ‘ADDRESS_'.$profile->address->id);
                        }

                        if(!empty($profile->contact_phone)){
                                $reply->addCallButton('Call', $profile->contact_phone);
                        }
                    }

If that profile got address, only show 'My Address' and if got contact_phone only show callButton.
Thanks

I think you can do it, but you have to checkt buttons max 3 in each element and element max 10 in the generic template.
https://developers.facebook.com/docs/messenger-platform/send-api-reference/generic-template

Thank for your reply.
But when i use that code it show only 'Details' button, My Address and Call button not showing even that profile has address and contact phone.

You can new Element first then add buttons then add to Template
$reply = new GenericTemplate($message->getSender());

foreach ($profiles as $profile) {
    $element = new Element($profile->name, $profile->intro);

    $element->buttons()->addPostBackButton('Details','PROFILE_'.$profile->id);

    if (!empty($profile->address)) {
        $element->buttons()->addPostBackButton('My Address', 'ADDRESS_'.$profile->address->id);
    }

    if (!empty($profile->contact_phone)) {
        $element->buttons()->addCallButton('Call', $profile->contact_phone);
    }

    $reply->add($element);
}

Owh~ Thanks for your example and help.


Npm error (conflict baucis/mongoose)

The error is:
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "node" "/usr/bin/npm" "install"
npm ERR! node v0.10.38
npm ERR! npm  v2.11.2
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package mongoose does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer<EMAIL_ADDRESS>wants mongoose@3 - 4.0.4

This error is caused because moongose already have version 4.0.6 stable but baucis allows moongose from version 3 to 4.0.4.

Thanks Fede. The error is already reported to baucis at https://github.com/wprl/baucis/issues/266
Closing this here: nothing to fix on baucis-swagger2.

Hi @FedeG The Issue has been fixed at<EMAIL_ADDRESS>


Does the code require any training?

I am just catching up on this work. I don't see a training script set up anywhere. Can this code be modified to run real time instead of a dataset without any training beforehand?

Ah I see it relies on pre established boundary boxes. So we would provide that in a similar format. Thanks!

You got it! The fact that tracking is not coupled to any specific input source or data is one of its big advantages.
You do not even have to provide detections in the same exact format, you can just add a custom parser to inputs/detections_{3d/2d} to consume your format. That's why there are so many parsing functions - to accommodate different detection formats provided by the community that we used in our experiments.


ADD Uthermosillo domain

Add of UTHermosillo domain, so our students and teachers can benefit from edu products 👍🏼
Signed-off-by: JOSE ALONSO LOPEZ ROMO<EMAIL_ADDRESS>

@alonsolopezr First stage of verification passed, official domain is uthermosillo.edu.mx as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

Thanks Philip... have a great day, hope to get our institution on the list soon

@alonsolopezr Thank you for your patience while waiting for a review and processing your request. Pull request merged.

Thanks again, and have a great day 🎉😎


ModuleNotFoundError: No module named 'face_alignment'

After run the bash process_data.sh Obama command, I faced with above-mentioned error. Can you give the solution of the problem?

use this command
conda install -c 1adrianb face_alignment

pip install face_alignment


Non-Latin character set content

I've (successfully) used the archiver script to archive my list. However, a lot of content it downloads ends up being "doubly-charset-encoded": It's cp1255 content, whose encoded form is then encoded in UTF-8. Which means it's non-trivial-to-difficult to actually extract the text from those files.
Saw this in .json files in the about and calendar folders.
Oh, and - thank you for this wonderful script!

Thanks for the report, I think I'm going to have to look more closely at the encoding information (if any) returned by the Yahoo servers.


Define the artistic aspect of the character

The artistic aspect of the character was defined in our game presentation.


remove first rows fallback variable

Remove the FIRST_ROWS_FALLBACK_MAX_DATASET_SIZE from the code.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Note that the CI is failing due to a temporary issue with the GitHub Actions (Azure repository of Ubuntu packages). It's not linked to the PR, and I'll relaunch the actions later, when the outage is over.

Hey, can you tell me what I have to do to correct these errors?

Thanks.
For the CI errors, we have to wait until Azure fixes its repository, and then relaunch the github actions.

We have to wait until Canonical fixes their error on their servers:

https://github.com/actions/runner-images/issues/7048

To finish this PR, you should:

merge main into your branch  git checkout remove-FIRST_ROWS_FALLBACK_MAX_DATASET_SIZE
  git fetch upstream main
  git merge upstream/main
  git push -u origin remove-FIRST_ROWS_FALLBACK_MAX_DATASET_SIZE

remove the two lines in chart/values.yaml at https://github.com/huggingface/datasets-server/blob/3bb80b725c361bb5072e14ffc82ab4838ad12405/chart/values.yaml#L285-L286

It seems like you still have not merged the main branch of this repository into your branch. Do you want us to help with that?

I done it and also create a new pull request
#781

It seems like the branch you merged into your own branch is not the current main branch.


Make OHRI Forms engine library functional PR

What this PR does?

Setup the library

Configure webpack, babel, TS, Jest, Prettier and linter

Update the codebase
Re-structure the codebase
Introduce a dynamic forms registry

@samuelmale  I was updating the base branch, since this will make the DEMO (most stable release) our dev environment, we  should make this test in working, then dev. Only on Friday will go to demo.


upcoming: php 7.2 countable issue

All:
Looking into php7.2 and seeing some upcoming warning(s) that will need to be addressed due to the countable updates - I'll try to look into creating a PR for it but wanted to get it into the issues bucket:
Warning: count(): Parameter must be an array or an object that implements Countable in src/Propel/Runtime/ActiveQuery/InstancePoolTrait.php on line 33
Thanks!

same problem here, BTW, is Propel2 still maintaining?


[plugin][sensors_plus] Need to specify sensor delay level.

Use case
In my case, I need to specify sensor delay level.
sensorManager.registerListener(sensorEventListener, sensor, sensorManager.SENSOR_DELAY_NORMAL);

Proposal
sensorManager.SENSOR_DELAY_GAME is also needed.

Considering that:

iOS uses deviceMotionUpdateInterval to set a time unit.
Android uses abstract delay level values (SENSOR_DELAY_NORMAL, SENSOR_DELAY_UI, SENSOR_DELAY_GAME, or SENSOR_DELAY_FASTEST) that seem to actually be tied to a maximum delay between two updates (https://developer.android.com/guide/topics/sensors/sensors_overview).

A generic interface to cover all platforms could take a maximum desired updated delay (in milliseconds) as a parameter and have predefined constants corresponding to the Android delays.
Would you be willing to accept a pull request that adds support for a maximum desired sensor update delay?

Is there any update on this?

I miss the sensorManager.SENSOR_DELAY_GAME

Hi, are you open to contributions regarding this issue?
I would like to contribute if possible.


Pass variant prop through Checkbox.Group and Radio.Group

Is your feature request related to a problem? Please describe.
I don't like to have to define the variant across all the sub-components in a group
Describe the solution you'd like
Pass the variant prop down through the Group components
Describe alternatives you've considered
Define the variant for each item in the group.

@cmaycumber Thanks for reporting! We've added this feature request to our list.

Hi @cmaycumber, you can use _radio or _checkbox prop to group component to modify props of sub-components now.
This feature is included in version 3.3.6.
Hope this will fix your issue.
Closing this issue. If you face any problem regarding this, feel free to reopen. Thanks.


When Stauts: "Mocked" and Response strategy: "Sequence" it returns "error-response"

Hi @mhewedy.
I have now resolved this issue and released a new version with the fix (1.29).
Thank you so much for raising this issue. As always, much appreciated.
Best regards,
Karl Dahlgren


Added support for dutch

At least like this we dutch people see something when we connect with our browsers, otherwise it is very confusing because the browser does not do anything! Should maybe be build into the code to resort to default EN locale if the current one is not supported

Thanks, actually it should be configured to show the English version as fallback when nothing else is configured. Need to investigate this

Dank je, @brainframe-me!


[GAL-703] feat: add deep linking in home collections

The collections in the /home route now will replace the URL with the collection route. When refreshed the close button will correctly send the user back to the /home route (done via a new "returnTo" param). The refresh causes the lost of the scroll position - I think its possible to add scroll restoration later on.

@evgenyboxer Closing this for now. If you feel like picking up on it lemme know and we can re-open it.


feat: add a chart util for display ChartExecutorResponse

#52

@microsoft-github-policy-service agree

Hi @bx-h ,
Thanks for this, it makes a bit of progress in addressing #52.
I was thinking of a much simpler solution ie. extending ChartExecutor response directly.
I pushed that change. Main approach

Add a savefig to ChartExecutor directly in datamodel.py. This avoids adding an new file to the codebase.
Does not add any additional dependencies e.g. cv2, . This makes the library ligther.

Finally, I think displaying the image should be implemented outside the library, as many applications may chose to visualization an image in different ways.
In terms of your PR, while change e428 covers a bit of it, I think extending the tests you added would be valuable here

Hi @victordibia ,
You're right! I've updated the test cases following your suggestion.


Update scalafmt-core to 3.3.3

Updates org.scalameta:scalafmt-core from 3.3.2 to 3.3.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Codecov Report

Merging #267 (eec4989) into main (e7d15bb) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #267   +/-   ##
=======================================
  Coverage   88.76%   88.76%
=======================================
  Files          91       91
  Lines        2776     2776
  Branches       68       68
=======================================
  Hits         2464     2464
  Misses        312      312

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 e7d15bb...eec4989. Read the comment docs.


Multiple attachments support

Hi,
How to send an email with multiple attachments?
2.1.2 doesn't seem to support it.
Regards,
Albert

Hi all
What's the plan for when attaching multiple attachments in API SDK?
Just let me know if I missed documentation examples on how to do that.

Hi @albertchua, @Marmeladov,
sorry for the late response and thank you for your patience. We've released a new version (3.0.1) that allows you to send an email with multiple attachments. You can find the example of usage in the snippet below:
string attachmentFilePath = "/temp/info.txt";
FileStream attachment = new FileStream(attachmentFilePath, FileMode.Open, FileAccess.Read);

string anotherAttachmentFilePath = "/temp/icon.png";
FileStream anotherAttachment = new FileStream(anotherAttachmentFilePath, FileMode.Open, FileAccess.Read);

EmailSendResponse sendResponse = emailApi.SendEmail(
    from<EMAIL_ADDRESS>    to: new List<string>
    {
<EMAIL_ADDRESS>    },
    subject: "Mail subject text",
    text: "Test message with file",
    attachment: new List<FileParameter>
    {
        attachment,
        anotherAttachment
    }
);

I'm marking this as closed. Feel free to reopen the issue if it still persists.
Kind regards,
Luka


Update to removal of outcome from abieos

Change Description

API Changes

[ ] API Changes

Documentation Additions

[ ] Documentation Additions

Depends on https://github.com/EOSIO/eos/pull/9046


actionlib: 1.11.13-0 in 'melodic/distribution.yaml' [bloom]

Increasing version of package(s) in repository actionlib to 1.11.13-0:

upstream repository: https://github.com/ros/actionlib.git
release repository: https://github.com/ros-gbp/actionlib-release.git
distro file: melodic/distribution.yaml
bloom version: 0.6.2
previous version for package: null

actionlib
* [bugfix] added missing boost/thread/reverse_lock.hpp include (#95 <https://github.com/ros/actionlib/issues/95>)
* Contributors: Robert Haschke

Holding the merge for a bit, need to fix some branch names


initial metadata creation with verification

This PR including the following:

Take json input via handler /metadata
verify json file include the required fields
create metadata
updated EntityService interface and all related tests

@davemasselink does it look good to you?


Update README.md

Connector -> CassandraConnector in the documentation

Hi @foovungle , we've moved all documentation to Github Wiki and fixed all broken links in the process. I will now close this PR as it's out of date.

Thanks
On Saturday, May 30, 2015, Flavian Alexandru<EMAIL_ADDRESS>wrote:

Hi @foovungle https://github.com/foovungle , we've moved all
documentation to Github Wiki and fixed all broken links in the process. I
will now close this PR as it's out of date.
—
Reply to this email directly or view it on GitHub
https://github.com/websudos/phantom/pull/245#issuecomment-107081882.


SHOULD not contain the data entry on JSON parsing failure when accepting application/graphql-response+json also fails on non-JSON responses

The audit SHOULD not contain the data entry on JSON parsing failure when accepting application/graphql-response+json does this:
        assert(
          'Data entry',
          (await assertBodyAsExecutionResult(res)).data,
        ).toBe(undefined);

This will throw if the body is not actually JSON, with the misleading error about "SHOULD not contain the data entry".
First, I'm not actually sure if the spec actually has a SHOULD that JSON parse errors should be returned as JSON at all (as opposed to having opinions about its structure if it is JSON). Apollo Server now expects you to use your web framework's JSON parsing capabilities (eg, body-parser with Express) rather than handling it "in-house" and it is primarily structured as a non-error-handling middleware, so it's challenging for us to respond to invalid JSON with any particular error format. Maybe that's a self-imposed limitation but we're probably not going to change it.  But I don't really see anything that says you SHOULD have a JSON response here. There's

When a server receives a well-formed GraphQL-over-HTTP request, it must return a well‐formed GraphQL response.

but in this case there is no well-formed request, so that doesn't apply.
Second, even if this is a legitimate thing to (optionally) test for, I think it should probably be explicitly tested for separately from this test case, and this particular test shouldn't fail claiming there's a data entry where there really isn't one. ie if the response is not JSON at all then I think this test should pass?

Or I guess another way of wording this is: "non-JSON body results in non-JSON response" might be common enough that it should be something the test suite looks explicitly for, and at the very least it should result in an AuditResult instead of a thrown error.

This is a great argument, we should not audit the errors format during content parsing issues. Will be fixed with #47.
However, I'd say we keep the other tests that expect JSON formatted results failing on parsing issues. We are actually testing a server that's expected to serve GraphQL.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Shipping labels at usps.com don't print

Steps to reproduce:

go to https://sss-web.usps.com/cns/landing.do
On the line right near the top where it says "Print a sample Domestic or International label." click on Domestic
Observe that nothing loads or prints, after the site says it has sent it to you.

With pdf.js disabled I get a pdf download at this point.  I suspect they're loading it in a hidden iframe and calling .print() on it.

Let's wait for #1118 which changes how we handle downloads. Maybe that'll fix it?
/cc @brendandahl

OK, #1118 has landed, and this is still not fixed.  The symptoms have changed, however.
If I poke at the content of the invisible iframe using the Inspector, I can see that the content has indeed loaded though (which it didn't do before), but it still fails to print. Is the Javascript print() function not implemented yet perhaps?

Currently we don't evaluate any javascript in pdfs.  You can see the pdf loads fine by either expanding the iframe in the inspector or by going to the url directly: https://sss-web.usps.com/cns/servlet/com.usps.cns.web.pdf.LabelGenerationServlet?orderId=null&sample=true&productCode=PRI&prtNoInstructions=false
That's really strange that they don't automatically show the iframe. Perhaps you should write them and recommend the iframe be visible with the pdf in it.
I'm not sure when we'll get around to implementing javascript evaluation in pdfs.

Yeah, they don't want you to be able to save it.  It happened automatically if you didn't have a PDF viewer because the browser didn't know how to display it.  They're attempting to get it to come out of your printer without you ever seeing it so you don't get the opportunity to save it to disk.


Still going? Documentation

Is this project still under active development? The documentation could deal with a lot of love for new people.

Hi Julian:
Yes it is in active development of course. I'm going to fuse MFlow with
transient and hplayground.  See the roadmap:
2015-06-06 4:35 GMT+02:00 JulianLeviston<EMAIL_ADDRESS>
Is this project still under active development? The documentation could
deal with a lot of love for new people.
—
Reply to this email directly or view it on GitHub
https://github.com/agocorona/MFlow/issues/62.

--
Alberto.

Hi Julian:
Yes it is in active development of course. I'm going to fuse MFlow with transient and hplayground.  See the roadmap:
https://github.com/agocorona/MFlow/wiki/Roadmap
If you can contribute in any  way, you are welcome

Been looking for projects in Haskell that provide similar solutions to Clojurescript projects like Reagent. None of them feel as simple. Feels like Haskell doesn't quite have the same set of tools for client-side dev that clojurescript has. Hplayground might provide the answer to that question, but it's quite tricky to fully understand what it is. The documentation seems quite opaque / difficult to understand.

What do you think/know about the Eve project, and Functional Relational Programming? (note: NOT functional reactive programming). Seems quite interesting so far. Would be quite interested in building a platform that allows "programming" as modification of code from within code itself, but unsure: does Haskell allow this form of dynamic programming?
There's often an extreme amount of pain involved in programming. It feels a bet like a "proper" programming platform would entail simply relating various "flows" of data together in a declarative "language". One gets rather bored of repeating oneself over and over with each new framework or programming paradigm or language. Re-expressing the same intent over and over is so cumbersome. Why is code not simply data types related to each other through functions? The names that Haskell seems to come up with for things seems to be so much dross, and anything but simple.
Anyway, I'm incredibly interested. I'd like to cut out repeating the same thing over and over and over.

Hi Julian .
There are a lot of interfaces of haskell with react. That is what Reagent
seems to do. if that is what you are looking for, it is a matter of
searching "haskell react".
hplayground is different and it is more simple to use and program with it
while having all reactiv effects. I defy to anyone to create a simpler
client side app for the factorial program:
import Haste.HPlay.View
main = runBody $ do
wprint $ "enter the number"
num <- inputInteger Nothing fire OnChange
wprint $ fact num
fact 0= 1
fact n= n * fact (n-1)
2015-06-06 12:52 GMT+02:00 JulianLeviston<EMAIL_ADDRESS>
Been looking for projects in Haskell that provide similar solutions to
Clojurescript projects like Reagent. None of them feel as simple. Feels
like Haskell doesn't quite have the same set of tools for client-side dev
that clojurescript has. Hplayground might provide the answer to that
question, but it's quite tricky to fully understand what it is. The
documentation seems quite opaque / difficult to understand.
—
Reply to this email directly or view it on GitHub
https://github.com/agocorona/MFlow/issues/62#issuecomment-109564353.

--
Alberto.

Concerning to functional relational, I have  never read about it. But I
have a completely different take of the same problem.
I think that reactive in general is an error. A reactive expression is a
giant and single event handler. for all the possible events. Because it is
a giant event handler, it has to detect what change and what not after his
execution Otherwise some undesired effects would be re executed.  The
problem essentially is the same for which OOP was for:  to handle
asynchronous messages and state.
OOP does manually (by the programmer ) that selection of actions to perform
when a mesage is received. Reactive try to automatize the selection of
actions to do for each event. That can be done with a post processing of
the response (for example in react.js) or by means of a pre-processing, by
means of an analysis of the ,message/s and/or relations between the things
that change (probably that is what the relational reactive do)
My approach (implemented in MFlow, transient and hplayground) is different,
and summarized here:
https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#the-problem--parallelization--concurrency-and-inversion-of-control
2015-06-06 13:25 GMT+02:00 JulianLeviston<EMAIL_ADDRESS>
What do you think/know about the Eve project, and Functional Relational
Programming? (note: NOT functional reactive programming). Seems quite
interesting so far. Would be quite interested in building a platform that
allows "programming" as modification of code from within code itself, but
unsure: does Haskell allow this form of dynamic programming?
There's often an extreme amount of pain involved in programming. It feels
a bet like a "proper" programming platform would entail simply relating
various "flows" of data together in a declarative "language". One gets
rather bored of repeating oneself over and over with each new framework or
programming paradigm or language. Re-expressing the same intent over and
over is so cumbersome. Why is code not simply data types related to each
other through functions? The names that Haskell seems to come up with for
things seems to be so much dross, and anything but simple.
Anyway, I'm incredibly interested. I'd like to cut out repeating the same
thing over and over and over.
—
Reply to this email directly or view it on GitHub
https://github.com/agocorona/MFlow/issues/62#issuecomment-109568230.

--
Alberto.

Yes, aware of the various Haskell interfaces with React, but none of them really connect in a similarly intuitive way that Reagent does (normal react isn't very good). Not particuliarly married to React, by the way, as a rendering engine, it just removes a lot of the incidental complexity of ensuring the DOM is synced up correctly with the code. There are some other ideas such as freagent which throws off the react shackles, using a spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're software transactional memory chunks) and keeps the state synchronisation by using cursors (functional windows into a small section of a big pile of state stored in these atoms). This way of dealing with state seems quite neat, and STM is amazingly awesome.
Effectively in reactive, everything keeps up to date whenever anything is changed. Events are driven through channels (which are message queues), and there is one-way data flow. All data is immutible because of clojure. This is the way the facebook team are slowly driving towards anyway, but the clojurescript people have a bit of a leg up on the JS people, I think.
Now, functional relational is something else entirely...
You can read about functional relational here: http://shaffner.us/cs/papers/tarpit.pdf though in general it seems "coding" is gluing a bunch of descriptions of data together, similarly to how Haskell declares a bunch of types, except that the descriptions of the data are glued with relations, which makes a lot of sense. Haskell doesn't really do that. For example, you have a list of customers, and you use a list of male customers, then you don't have to write a function, the male customers are a filtered view on the customers. The "male customers" "type" is defined in terms of the customers "type". It looks like a very beautiful way to program. Unfortunately there aren't any languages that use it... except maybe cascalog. I'd very much like something like that but with Haskell... because, while clojure is beautiful, I constantly find myself wishing for types and a typechecker (and clojure's core.typed syntax is not pleasant). Essentially, I'd like to create a flexible language to express various things in, that I never want to have to re-express again.
Do note that Functional Relational is NOT Functional Reactive. ReactJS is primarily reactive.
Your appraisal of reactive is interesting, but it's not the day to day experience of using Reagent or any of the other client side clojure(script) frameworks. Because clojure has core.async, (http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this separates component communication and allows for composability and one-way data flow. It seems a core.async is similar to what you're stipulating in your "EDSL for hard-working IT programmers" post. This is very good, and quite complex "under the hood" from what I understand.
 The concurrency story is a little bothering, (very manual) but perhaps that's inevitable. It's also a little bothering that one can't modify programs as they're running in Haskell, or perhaps this is mistake. This would preclude live coding.
Aside from all of this, it seems your code is only intuitive to a Haskeller, sadly.
I'd like to talk more with you about it, and understand more and learn more, and perhaps contribute to some of the documentation if it's a good fit for what I'd like to do.
So far all of the front-side Haskell stuff that I've noticed is about getting haskell to write Javascript and this is awful.

Sorry for the delay. I have been busy. Tomorrow I will ask you.
2015-06-06 16:05 GMT+02:00 JulianLeviston<EMAIL_ADDRESS>
Yes, aware of the various Haskell interfaces with React, but none of them
really connect in a similarly intuitive way that Reagent does (normal react
isn't very good). Not particuliarly married to React, by the way, as a
rendering engine, it just removes a lot of the incidental complexity of
ensuring the DOM is synced up correctly with the code. There are some other
ideas such as freagent which throws off the react shackles, using a
spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're
software transactional memory chunks) and keeps the state synchronisation
by using cursors (functional windows into a small section of a big pile of
state stored in these atoms). This way of dealing with state seems quite
neat, and STM is amazingly awesome.
Effectively in reactive, everything keeps up to date whenever anything is
changed. Events are driven through channels (which are message queues), and
there is one-way data flow. All data is immutible because of clojure. This
is the way the facebook team are slowly driving towards anyway, but the
clojurescript people have a bit of a leg up on the JS people, I think.
Now, functional relational is something else entirely...
You can read about functional relational here:
http://shaffner.us/cs/papers/tarpit.pdf though in general it seems
"coding" is gluing a bunch of descriptions of data together, similarly to
how Haskell declares a bunch of types, except that the descriptions of the
data are glued with relations, which makes a lot of sense. Haskell doesn't
really do that. For example, you have a list of customers, and you use a
list of male customers, then you don't have to write a function, the male
customers are a filtered view on the customers. The "male customers" "type"
is defined in terms of the customers "type". It looks like a very beautiful
way to program. Unfortunately there aren't any languages that use it...
except maybe cascalog. I'd very much like something like that but with
Haskell... because, while clojure is beautiful, I constantly find myself
wishing for types and a typechecker (and clojure's core.typed syntax is not
pleasant). E ssentially, I'd like to create a flexible language to express
various things in, that I never want to have to re-express again.
Do note that Functional Relational is NOT Functional Reactive. ReactJS is
primarily reactive.
Your appraisal of reactive is interesting, but it's not the day to day
experience of using Reagent or any of the other client side clojure(script)
frameworks. Because clojure has core.async, (
http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this
separates component communication and allows for composability and one-way
data flow. It seems a core.async is similar to what you're stipulating in
your "EDSL for hard-working IT programmers" post. This is very good, and
quite complex "under the hood" from what I understand.
 The concurrency story
is a little bothering, (very manual) but perhaps that's inevitable. It's
also a little bothering that one can't modify programs as they're running
in Haskell, or perhaps this is mistake. This would preclude live coding.
Aside from all of this, it seems your code is only intuitive to a
Haskeller, sadly.
I'd like to talk more with you about it, and understand more and learn
more, and perhaps contribute to some of the documentation if it's a good
fit for what I'd like to do.
So far all of the front-side Haskell stuff that I've noticed is about
getting haskell to write Javascript and this is awful.
—
Reply to this email directly or view it on GitHub
https://github.com/agocorona/MFlow/issues/62#issuecomment-109581855.

--
Alberto.

Finally I´m free to answer you:
2015-06-06 16:05 GMT+02:00 JulianLeviston<EMAIL_ADDRESS>
Yes, aware of the various Haskell interfaces with React, but none of them
really connect in a similarly intuitive way that Reagent does (normal react
isn't very good). Not particuliarly married to React, by the way, as a
rendering engine, it just removes a lot of the incidental complexity of
ensuring the DOM is synced up correctly with the code. There are some other
ideas such as freagent which throws off the react shackles, using a
spreadsheet-like setup of "cells" (called "atoms" in Clojure - they're
software transactional memory chunks) and keeps the state synchronisation
by using cursors (functional windows into a small section of a big pile of
state stored in these atoms). This way of dealing with state seems quite
neat, and STM is amazingly awesome.
Effectively in reactive, everything keeps up to date whenever anything is
changed. Events are driven through channels (which are message queues), and
there is one-way data flow. All data is immutible because of clojure. This
is the way the facebook team are slowly driving towards anyway, but the
clojurescript people have a bit of a leg up on the JS people, I think.

I though  that react just bubble up the events to the top of the widget,
then generate all the rendering and a diff engine detect the changes, then
apply the changes to the rendering.

Now, functional relational is something else entirely...
You can read about functional relational here:
http://shaffner.us/cs/papers/tarpit.pdf though in general it seems
"coding" is gluing a bunch of descriptions of data together, similarly to
how Haskell declares a bunch of types, except that the descriptions of the
data are glued with relations, which makes a lot of sense. Haskell doesn't
really do that. For example, you have a list of customers, and you use a
list of male customers, then you don't have to write a function, the male
customers are a filtered view on the customers. The "male customers" "type"
is defined in terms of the customers "type". It looks like a very beautiful
way to program. Unfortunately there aren't any languages that use it...
except maybe cascalog. I'd very much like something like that but with
Haskell... because, while clojure is beautiful, I constantly find myself
wishing for types and a typechecker (and clojure's core.typed syntax is not
pleasant). E ssentially, I'd like to create a flexible language to express
various things in, that I never want to have to re-express again.

I read this paper very shallowly before sending the last reply. I found it
following some links. I will read it in more detail but basically what you
say is what I though. It is nice but honestly I think that the idea behind
hplayground is better. why? because it is composable. each widget is a
single expression that is combined with others. no other seaming is
necessary. That non composability was the problem of every kind of GUI
invented, including the web browser.

Do note that Functional Relational is NOT Functional Reactive. ReactJS
is primarily reactive.

I really dont't know what is reactive. People today adscribe to reactive
almost anything. publish-suscribe frameworks now are called reactive.
impure effects are called functional pure and reactive. It is better not to
use the word reactive. it is almost meaningless.

Your appraisal of reactive is interesting, but it's not the day to day
experience of using Reagent or any of the other client side clojure(script)
frameworks. Because clojure has core.async, (
http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html) this
separates component communication and allows for composability and one-way
data flow. It seems a core.async is similar to what you're stipulating in
your "EDSL for hard-working IT programmers" post. This is very good, and
quite complex "under the hood" from what I understand.

Yes it is somehow related with my article that you mention. both
hplayground and the EDSL share the same principle that is basically a
simpler way to deal with continuations. in hplayground , when an event
arrives, the event continues the rest of the code , render the part of the
widget affected by the event. events can happen anywhere in the program
sequence while in react.js only can happen at the top level of the widget,
so it need to execute it fully, detect the changes etc.  in transient, when
an asynchronous event, like the reception of a file is finished, it trigger
the continuation as well. The mechanism is the same. The advantage is that
this does not need special constructions. It is like programming console
applications. It makes asyncronnous as easy to program as synchronous and
equally readable.
I watched the slides of a presentation of core.async and it solves some
problems but I think that my EDSL solve a wider kind of problems

The trouble with Clojure, though, are that it's not lazy enough:
EVERYTHING is lazy and super-declarative in Haskell. The concurrency story
is a little bothering, (very manual) but perhaps that's inevitable. It's
also a little bothering that one can't modify programs as they're running
in Haskell, or perhaps this is mistake. This would preclude live coding.

well my EDSL edit the continuations while it is executing in some way. I
used it to re execute certain registered statement when some primitive
"goback" is called. This is intended to undo transactions.  There are some
limited examples of live coding in Haskell in youtube. The interpreter is
very fast and can simulate it, although not as well as clojure..

Aside from all of this, it seems your code is only intuitive to a
Haskeller, sadly.

It is like a console application! there are no interruptions of the flow,
no event handlers. Perhaps you are puzzled by the operators <|> <*>
They are standard haskell operations.
For example, a <|> b     return either the result of  'a' or the one of 'b'
if  'a' produces an invalid result (in this case, if 'a' finish with empty
or stop)

I'd like to talk more with you about it, and understand more and learn
more, and perhaps contribute to some of the documentation if it's a good
fit for what I'd like to do.

Very good. I would be very happy to talk with you!

So far all of the front-side Haskell stuff that I've noticed is about
getting haskell to write Javascript and this is awful.
—
Reply to this email directly or view it on GitHub
https://github.com/agocorona/MFlow/issues/62#issuecomment-109581855.

--
Alberto.

Well, my email address is "kvmjboAmfwjtupo/ofu" if you subtract 1 from each of the ASCII codes for the characters.
My point was simply that Haskell is not very intuitive or easy to people who haven't studied it. Contrast this to Ruby or Python, which almost read like English a lot of the time. (I'm not making a case for or against anything here, it's simply an observation about what is "easy" to the average person who doesn't know any of these languages).


Feature Request: Enable Dapr Workflow in Azure Container Apps

Is your feature request related to a problem? Please describe.
I need to run reliable workflows using containers. Dapr Workflows seems like a very good fit: https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/ and I want to have available in ACA.
Describe the solution you'd like.
Support for Dapr Workflow.
Describe alternatives you've considered.
No alternatives.
Additional context.
Dapr Workflow is in alpha but already shows great value.

It would be really great to have this available in Azure Container Apps, especially as an alternative to durable functions.

@itpropro I'd also be interested in hearing about your WF scenario too (if you have one)

Hello, I have an usage scenario that I am currently implementing. I want yo handle CosmosDb Change Feed for "referential integrity" of Azure CosmosDb documents and containers.

Yeah bump for this too :D would love to see this in action!

Will v1.12 https://github.com/dapr/dapr/issues/6508 with Workflows going Beta make this possible to be supported?

Any update on this?

@itpropro I'd also be interested in hearing about you WF scenarios too!

There are many scenarios, but mostly the same as the ones you would use durable functions for. If you want to discuss some, feel free to contact me.
An update on this, especially as it has reached beta for a while would be appreciated :)

I'm eager to see this as well. Lack of workflow support, pre-stable as it might be, is a blocker to me using Azure Container Apps.

I'm eager to see this as well. Lack of workflow support, pre-stable as it might be, is a blocker to me using Azure Container Apps.

At least according to the Docs, the container apps team is willing to support Dapr Beta states. It's also on the 1.13 Dapr roadmap to announce workflows as phase 1 stable, so I think there is no better time to start integrating it than now :)

Hi everyone,
Thank you for your patience as we work towards integrating workflow functionality into ACA.
As it stands, our goal is to release a public preview in January/February 2024.
I will keep everyone posted with updates as we approach the preview release.

Hi everyone,
Thank you for your patience as we work towards integrating workflow functionality into ACA.
As it stands, our goal is to release a public preview in January 2024.
I will keep everyone posted with updates as we approach the preview release.

Sounds great, thanks for the update! Will there be a private preview?

@greenie-msft ... Any news on the public preview release date yet?

Hello everyone,
There has been a change in the timeline for releasing workflow support in ACA.  Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations before making WF available in ACA.
I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

Hello everyone,
There has been a change in the timeline for releasing workflow support in ACA. Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations in our Azure distribution before making WF available in ACA.
I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

Any updates on the release date, especially after the Dapr release 1.13? We are looking to use Dapr workflows in ACA for our Dev environment. Thanks.

Hello everyone,
There has been a change in the timeline for releasing workflow support in ACA. Currently, Dapr WF has certain limitations, and we've received feedback that these limitations make it challenging to use the feature at scale in production. We want to ensure you have the best possible experience using our features, so we’ve decided to proactively address these limitations in our Azure distribution before making WF available in ACA.
I’ll be sure to provide regular updates on this thread as we approach a new release date for WF support in ACA. Thank you for your patience as we navigate through these improvements.

Any updates on the release date, especially after the Dapr release 1.13? We are looking to use Dapr workflows in ACA for our Dev environment. Thanks.

@greenie-msft ... Deos the Dapr 1.13 release mitigate the issues mentioned?

@jaq316 Dapr 1.13 did not change much about the mentioned issues. From a brief chat I had with someone in the Discord channel, I think, a week after the release, it was shared that the NoSQL issue is scheduled to be tackled in the next release (1.14) alongside the initial release of the distributed scheduler, which will solve the horizontal scaling issue (though maybe not for Workflows immediately - more on this in a bit).
I would like to reiterate to @greenie-msft that I would appreciate it if ACA simply ran whatever is available in the latest public/stable release of Dapr and instead highlight that only stable components receive support - use of any other functionality is done at the developer's own risk, and then link to the current Dapr known limitations for Workflows and other blocks. Having ACA support a different build of Dapr than what is available publicly seems like it'd lead to more developer frustration than not and repeatedly eliminate ACA from consideration as a deployment destination because of the unknown lag time between new Dapr functionality and the support timetable from Microsoft (as here).
The documentation indicates that Azure Container Apps only offers fully managed versions of the stable Dapr APIs. By this reasoning, it's unlikely that Workflow will be supported before mid-2025, well after the rest of the Dapr developers will have been using it. Why? (Take all the below with a grain of salt because while I contribute to the Dapr project, I am not privy to any release schedules or priorities listed outside of those shared in public channels on Discord and via the issues and milestones in the various Github projects).

The horizontal scaling issue will be remedied by the release of the Distributed Scheduler which is anticipated to be released in 1.14 (say, early summer 2024), but that will show up in an Alpha release first, meaning that ACA won't host it either.
Actors will need to be updated to realize all the benefits of the new scheduler. While this might be done alongside the 1.14 release, I suspect they'll want to take the time to get it right since Actors are currently marked as a stable component, so they can't be breaking anything, so assume that instead is released with the 1.15 release (fall 2024).
Workflows will likely get the scaling benefits from the Actors without a ton of extra work, so they might be released alongside the 1.15 release in the fall, but they'll likely continue to be in the beta state as they're evaluated for stability. One can hope that the Distributed Scheduler would similarly be promoted to beta here, but that would be a surprisingly fast turnaround in my experience.
This means it's not until perhaps the next release that the Workflow is released as stable in the 1.16 release (winter 2024). But given the ACA policy of only hosting stable APIs, they'll have to decide whether they bend the rule to support the Distributed Scheduler dependency which will almost certainly not be marked stable yet or wait until it is, so that might not be until the 1.17 release (spring 2025).
Assume everything is marked as stable now - the ACA team will still presumably need a quarter to then add Dapr to the product. This is no longer reliant on the Dapr release schedules, but as this would be something the Dapr team is heavily promoting, my guess is support arrives just in time for Build 2025, so the end of May.

@jaq316 So that really leaves three choices:

Don't use Workflows at all and wait for it to be supported (hopefully) just over a year from now in ACA, but otherwise enjoy this managed deployment environment for all other stable APIs.
Use Workflows, but find somewhere else to host your project and Dapr.
Run arbitrary sidecar containers alongside your application in ACA (e.g. opt-out of the Microsoft-provided Dapr implementation and host your own). I have no examples of doing this, but as was pointed out in the ACA Discord channel, it's just a matter of modifying the Bicep template to add your own sidecars per the documentation.

Thanks for the interesting insights @WhitWaldo! It's good to see the timeline so clear lined out, which also shows the issue with the current release strategy in my opinion.
I also think that ACA should not use a different versions of Dapr than the rest of the world, but I definitely think there should be a opt-in to beta (and maybe even alpha) APIs. This would at least take away the initial implementation delay for stable APIs, as they are already tested and received feedback in ACA and there are a lot of metrics already available for the product team.
That is in my opinion what previews in Azure are for, which offer no SLAs and users can accept the risk, but at least test it. From my experience, a lot of the features in beta are totally usable and behave like the beta things in K8s (that are basically stable), I know a lot of customers who willingly use beta APIs for Dapr and other cloud native services in production.
For alpha APIs I can somewhat understand that they are not available in a managed service like ACA, as the underlying architecture can still change completely, but for Beta versions that are already in that stage for some time, I would really like to have them available in ACA.

Thanks for the insights @WhitWaldo !

Run arbitrary sidecar containers alongside your application in ACA (e.g. opt-out of the Microsoft-provided Dapr implementation and host your own). I have no examples of doing this, but as was pointed out in the ACA Discord channel, it's just a matter of modifying the Bicep template to add your own sidecars per the documentation.

I wonder if that is possible and would love to see an example of it.
How would you get the custom sidecar to communicate with the other (standard) sidecars?
I think this may be locked down in ACA, but I could be mistaken.
We are currently running a small part of our orchestration layer on AKS only to support Dapr Workflow and the rest on ACA, but it is obivously not very cost effective nor an efficient system architecture (we found out too late that WF was not supported, once we already rolled out everything on ACA).
I hoped for WF preview support in ACA in Q2 of this year but looking at your breakdown @WhitWaldo, it seems like we may have to wait much longer for that.

Thanks for the insights @WhitWaldo !

Run arbitrary sidecar containers alongside your application in ACA (e.g. opt-out of the Microsoft-provided Dapr implementation and host your own). I have no examples of doing this, but as was pointed out in the ACA Discord channel, it's just a matter of modifying the Bicep template to add your own sidecars per the documentation.

I wonder if that is possible and would love to see an example of it. How would you get the custom sidecar to communicate with the other (standard) sidecars? I think this may be locked down in ACA, but I could be mistaken.
We are currently running a small part of our orchestration layer on AKS only to support Dapr Workflow and the rest on ACA, but it is obviously not very cost effective nor an efficient system architecture (we found out too late that WF was not supported, once we already rolled out everything on ACA). I hoped for WF preview support in ACA in Q2 of this year but looking at your breakdown @WhitWaldo, it seems like we may have to wait much longer for that.

I think he refers to the ACA support for sidecar containers: Containers in Azure Container Apps
From the docs

To run multiple containers in a container app, add more than one container in the containers array of the container app template.

Hi everyone,
I appreciate your continued patience as we’ve been at work developing workflow support in ACA. The good news is we are nearing a preview. I will have more exciting updates to share over the next few weeks so please stay tuned!

@greenie-msft ... Any news yet?

Hello everyone,
I want to apologize for not being active in this discussion recently. As many of you may be aware, Microsoft is currently prioritizing enhancements of our security measures. This has impacted the timeline of our feature development work.
Despite our focus on security, we remain dedicated to providing support for durable workflow/orchestration and are looking forward to rolling out these capabilities soon.
To stay up to date with our progress and availability of the workflow preview, I encourage you to sign up via this link: https://aka.ms/managedworkflow/signup.
I will keep you updated with the latest information as soon as it becomes available.
Thank you,
Nick

@greenie-msft hello. any updates on the roadmap of this feature?

@greenie-msft is there any update on upgrading Dapr to v1.13? we're facing more and more issues on Dapr sidecar crashing on restarting the container and thus, missing subscription to events bus. Restarting each container after each update is quite annoying. AFAIK Dapr fixed this issue - for us in relation with gRPC - within 1.13.

From Microsoft:

The Workflow features of Dapr cannot be used in Azure Container apps at this time. Dapr has a policy where features are enabled in ACA only when they are considered "stable". As an "alpha" feature, Workflow hasn't yet met that bar. There is no specific ETA at this time. Discussion

I find this policy concerning. While I understand the intent to only enable stable features, this approach seems overly restrictive given DAPR's current maturity state. A majority of DAPR features remain in alpha or beta status, for example only about 30% of bindings marked as stable (even features that have been present since DAPR 1.0 still carry an "Alpha" label.).
This creates a significant gap between what's available in standalone DAPR versus ACA. The lack of feature parity has persisted for over a year, which puts ACA developers at a considerable disadvantage.
Perhaps Microsoft could consider a more nuanced approach? Rather than a binary stable/unstable classification, you could allow users to opt-in to beta features with appropriate disclaimers. This would better serve developers who have invested in ACA while still maintaining transparency about feature stability.

Update from Dapr 1.12 to at least 1.14 for ACA would be great! We're looking to run log running workflows with a large amount of activities.

@tmarkovski It's unlikely the ACA team will migrate to 1.14 and enable workflows as they're still deemed unstable in this release. The Dapr workflow is expected to graduate to stable with the release of 1.15 (aiming for a December release).