SDK is out!

Hey, now that the sdk is out, could you release it on jcenter?
Cheers,

Thanks for reminder :) I will upload is but firstly I need to add more useful feature, ETA is 1-2 weeks.

cool ;)

I updated Nammu with easier monitoring, coverage of all permissions, better/easier sample, ignored lists of permissions.
I will wait some time to test those features before rolling into jcenter to be sure it is stable.

i see that you released version 1.0.0 but gradle can't find  or the other old one 0.4.5  maven { url "https://jitpack.io" }

@k0shk0sh take a look here: https://github.com/tajchert/RuntimePermissionWorkshop
I used there 1.0.0 version and it works.
In this commirt you can find how to add jitpack library: https://github.com/tajchert/RuntimePermissionWorkshop/commit/eacbcbf492a27bbc8dadb74a38388155f85422c3


[Storage] Update rollup-config as per the template

Update rollup-config as per the template.
Update test:node command to use the generated dist-test/index.node.js instead of running ts-node on the test files.

Rename test files for consistency across packages.

#2297


chore: Increase probe delay

List of Changes

increased liveness and readiness probe delay in all environment

Motivation and Context
Avoid deploy action failure

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

@gioelemella increase this timeout too


Refine build_buildrun_establish_duration_seconds buckets and make buckets configurable

The build_buildrun_establish_duration_seconds histogram metric used the following buckets: 0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4, 4.5.
Two issues exist with that:

Values with .5 cannot exist because k8s timestamps have no milliseconds. Those are therefore not of value.
Longer durations cannot be differentiated which makes it impossible to define reasonable alerts.

The new buckets for the metric are: 0, 1, 2, 3, 5, 7, 10, 15, 20, 30. The number of buckets is unchanged, but the longer durations can be better monitored.
In addition, I am changing the metrics implementation to get the buckets from the configuration and I allow environment variables to overwrite the defaults.
The downside of that is that the metrics package cannot anymore instantiate the histograms statically but requires the config. This means that those metrics can only be initializes in InitPrometheus. This works fine at runtime but is a little issue for the unit tests because there is no single "main" for them. I therefore had to add the initialized flag (see https://github.com/redhat-developer/build/commit/d42fada56ede2f0f5d9f0ecfae2f97010ed97f2a#diff-7cbe8e056d62a2de30c7066e359bd9c9R35-R44) which I do not like so much. Better ideas are welcome.

/retest

Hi Sascha,
Thanks for the fix.
Should we add an example how to configure the env property in the metric document? I think it is better that we can give an example so that user can follow that directly.

Hi Sascha,
Thanks for the fix.
Should we add an example how to configure the env property in the metric document? I think it is better that we can give an example so that user can follow that directly.

Hi @zhangtbj, done, see https://github.com/redhat-developer/build/pull/298/files?short_path=683a405#diff-683a405c5c005542f9e848b827fe0765.

/approve

/lgtm


Download while stream is still "Live"

It would be great to download a stream while they are live.
I would search for twitch.tv/kitboga
The leecher would see he is live
and it would download the previous segments along with real time segments.
This might need some stitching when stream is finished with ffmpeg or something.
I know youtube-dl can download live streams if that helps.

There is a PR open for this but I need to review and maybe re-code. Patience pls 😄


Do not run checks on draft PRs

It would be nice if we could avoid running checks on draft PRs (like https://github.com/developmentseed/lonboard/pull/613) and trigger only when the PR is ready for review.
cc @kylebarron

One interesting option is something like https://github.com/rouault/gdal/commit/422220b599546b00dc0860cf59c2493fe5fd6b4a where you can annotate a PR title with [no ci] to avoid running CI checks.
Sometimes I like having CI run on draft PRs. Even if they're not ready for review yet, it can be nice to see if CI passes


Swift 2 Patch

Updated a few things to make compatible with Xcode7b6

Thanks for the effort, many of the things were already fixed in the xcode-7 branch though. I've updated to make the Element typealias public, that was the final bit that changed between the betas


postcode_data_join - filter out NAs, ""s, codes that don't match a postcode regex, etc...

Closing as non-reproducible (insufficient information / no reprex provided). Issues alluded to to be addressed through improved unit tests.


Windows doesn't scroll back to top when openning a item

When a item is opened from the bottom of the page, the page doesn't scroll back to top in the item detail view.
(sorry , co workers are very picky, opening a PR right now)

Thanks for this!! Wow I'm surprised I didn't catch this, I think it must have been handled at one point but some refactoring may have removed it.
Thanks again mate, appreciate it!


How to use this plugin with a function only?

Hi, thanks for this plugin! I've some trouble setting it up. I want to use a function only, no S3, no other data sources. I tried to modify the Readme example but it didn't worked well since it required a Origin.
I found a example from Amazon here which use Type: 'AWS::Serverless::Function' but after trying that out I'll just get a Error back that this is not a valid value: Resource with logical name "ServerSideRenderer" is not type AWS::CloudFront::Distribution.
My current setup with Lambda (not Edge) based on API Gateway. The config looks like this:
functions:
  NextJS:
    handler: lambda.handler
    warmup: true
    events:
      - http: ANY /
      - http: ANY {proxy+}

This plugin attaches a Lambda function to a CloudFront distribution. That's why you need a CloudFront distribution. If you aren't making a CloudFront distribution, this plugin is not for your usecase.


Add system prompt to rebuff

Hi,
I have trouble adding system prompt to rebuff, is there any tutorial on how to do that?

Can you put some examples so that I can have a look

Closing since there's been no response. @Tizzzzy, if you're still interested in getting help with your issue, feel free to open a new issue. Please give more details so we can understand what your issue is.


Change banner on GetMonero.Org website

Present banner is very confusing.  My suggestion is--
"To all Monero holders.  Please upgrade your Monero software to the current April 6th network version"
MORE INFO (radio button to follow)

I like the idea, and think this needs to change, but I would take out "To all Monero holders." Move away from the 'holder' verbiage. It denotes trading as the primary usecase, imo.
Perhaps "There was a network upgrade on April 6th, please make sure your software is upgraded to continue using the Monero chain."
Or something?

How about the following--
"There was a network upgrade on April 6th.  If you haven't already, please update your software now to continue using the Monero block chain"

Sorry, closed issue by mistake

"Make sure to be up-to-date with the network upgrade that occurred on April 6th"

The sentence should be relevant before and after any network upgrade. So i suggest "To continue using the Monero chain, make sure your software is up-to-date with the April 6th network upgrade."

I like it.

"To continue using the Monero chain, make sure your software is up-to-date with the April 6th network upgrade."

I like this, i would just remove the word 'chain', to keep it as less techy as possible, something like:
To continue using Monero correctly, make sure your software is up-to-date with the April 6th network upgrade

I don't think "correctly" or "with no issue" is even needed. If you don't upgrade, you're not using Monero anymore, but an old monero chain.

True, if nobody have any other suggestioni think we should go for:
To continue using Monero, make sure your software is up-to-date with the April 6th network upgrade
+discussion

It's a zinger.  I like it very much.

@el00ruobuob and @erciccione nailed the wording, nice work! Two questions about which key points of information we want to bring to visitors' attention.
Question 1) Is it valuable to state that this occurred on the sixth of April, specifically? This was pertinent precision before the update, seems like an unnecessary use of user attention now.
Question 2) Would it be helpful to specify "version 7" and/or "GUI 0.12.X.0" ...
I'm trying to put myself in the shoes of somebody that is learning about the upgrade for the first time from the getmonero.org banner. Version numbers might be more helpful for checking whether I'm up to date.

the idea is to keep an accurate message before and after network upgrade. We agree that it is not needed after, it's just that the same thing will stay here for weeks.

I believe the link is here for such details.

this has not been updated in a month. Obviously the banner is not part of the monero-site code (or i'm blind), and i think it's added on the hosting server itself. @rehrar could you tell? Who could then change the actual banner with the one we agreed upon? Is it @luigi1111 or @fluffypony ?

To continue using Monero, make sure your software is up-to-date with the April 6th network upgrade

@el00ruobuob is there broad consensus on that wording?

@fluffypony i think @SamsungGalaxyPlayer @erciccione @uncagedpotential @One-horse-wagon and me seemed to agree on this. At least, it's still better than the actual one.

Sure, I would be okay with the proposed: "To continue using Monero, make sure your software is up-to-date with the April 6th~ 2018 network upgrade"
^ I removed the date, "6th" which is irrelevant now, and added the year for clarity.

Smaller commentary: Reading the above comments, there appear to be two considerations.
Consideration 1) Making sure that the before banner and after banner both cleanly convey the crucial information, without extraneous details or awkward tense wording
Consideration 2) Making the message be the same before and after the fork. (meh)
Given consideration 1 (highest priority for me) and the presumed triviality of changing the banner text, I do not see the impetus to use a single one-size-fits-all message for before and after the fork.
A counterexample for why a single before/after message is difficult - the before message should contain future tense, the height, and the precise date. For the after message, the tense changes, and the exact date/height become extraneous information that wastes user attention.
Regarding homepage banners, we should never sacrifice informativeness or linguistic precision for convenience. :- )
For the September fork, perhaps we could just approve both (before & after) banners in one step, so that this doesn't balloon out into multiple conversations. Or maybe there is a clean single solution that is works both ways (I just haven't seen it yet).
Anyways, this meta conversation can happen for the next fork; I'm fine with the message above to clean up our current banner.
Cheers,
UncagedPotential

@uncagedpotential, as the network upgrade occurs on a specific block height, it would be very complicated to have a core member behind the website to change the banner at this exact moment.
I think To continue using Monero, make sure your software is up-to-date with the April 6th network upgrade is valid before and after, as it is infinitive.
The point is the core team member has bigger things to do than changing a banner on the fly. They are busy enough merging all those Pull Request, dealing with FFS, and so on.
Once the new major release is published and the block height for the new version is defined, then the banner could be updated to reflect the new date, keeping it until next network upgrade block height definition and release publication.

Changed, closing this issue.


python310Packages.aioairzone: 0.4.6 -> 0.4.8

Description of changes
https://github.com/Noltari/aioairzone/releases/tag/0.4.8

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

3 packages built:

home-assistant-component-tests.airzone
python310Packages.aioairzone
python39Packages.aioairzone


Remove Hadoop dependency

@kjmccarthy I fixed the logging issue by adding log4j2. Any conflict we might have had with log4j1 (guessing this is what was happening) was removed with the Hadoop dependency.

3 tests are failing now in DefaultProvisioningServiceSpec.scala. I'm not sure what changed but I'm not going to dig into it now, the whole provisioning thing is difficult to reason about and needs to be refactored. That will be another task


Refactor F5 testing code that uses "src" to find the root directory

repo = str(Path(__file__)).split("src")[0] will no longer work with current setup...need to make it something else


Remove faulty reference to controller manager image in deploy

It seems this file was preventing us from using our own controller image as specified by the IMG environment variable in the Makefile.

Thanks for the effort here.
I've chosen to keep the patch and adapted it to use the correct image. It's used in the release process now.


Added new ability to override resource query builder

This change allows setting up the SCIMConfig like this:
return ['query' => User::withTrashed()];

Which I needed to be able to map active in the schema to my deleted_at model and still support activation/deactivation updates.
I tested without the query and with it null (default) and everything still works as expected.

Sorry to keep bugging @arietimmerman. I ran into one last thing I needed for my implementation if you get time to take a look. Appreciate all the help and happy holidays my friend!

I see the problem and the solution. If you can take a look at my comment I'll merge it in.

Sounds good. That works for me too. Thanks @arietimmerman


File > New option to create a new project

Right now, the only way to "create" a new project is to hard refresh the workstation which sets up a default project. It would be nice to have a dropdown menu option for this behavior in-app.
If the current editor state is dirty, it should open up a confirmation modal like #10

Completed with https://github.com/brandongregoryscott/beets/commit/e407e67ea7a590ed341ac5e26b4a5220130c5d05


Rasa X - Using createEvent endpoint also adds to training data

Rasa version:
RASA_VERSION=1.10.8
Rasa X version (if used & relevant):
RASA_X_VERSION=0.31.2
Python version:
3.7
Operating system (windows, osx, ...):
osx
Issue:
Hello, I’ve been migrating conversations from a non-rasa chatbot, using the http-api of rasa X. In particular, the endpoint createEvent.
Weirdly, using that endpoint also adds the message to the training data and the intents to the domain file. For example, it adds intents that aren't in the domain file but show up in the migrated conversations events.
I think this is a bug? Can some reproduce it to make sure?

Thanks for raising this issue, @tttthomasssss will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗


IB behavior exposed by #2038

In Julia, we have a test that uv_fs_sendfile gracefully handled the 0-byte case, but with PR #2038, it now calls abort() in that test on Windows:
1460    static void fs__sendfile(uv_fs_t* req) {
...
1463      size_t length = req->fs.info.bufsml[0].len; // == 0
...
1465      const size_t max_buf_size = 65536;
1466      size_t buf_size = length < max_buf_size ? length : max_buf_size;
...
1469      char* buf = (char*) uv__malloc(buf_size);
1470      if (!buf) {
1471        uv_fatal_error(ERROR_OUTOFMEMORY, "uv__malloc"); // now dead, Jim!
1472      }

@bnoordhuis confirmed that this case is something the code is supposed to handle before calling `uv__malloc.
In reviewing the code, there's a few other places that look like they need to be fixed now (not including all places where we use ncpus, if we assume you could have zero cpus)—which I think was indeed the point of this PR:

ifc.ifc_req = (struct ifreq*)uv__malloc(size); (aix-commmon.c:188, missing check on return value)
uv_getaddrinfo (for the empty string hostname, both unix and win32 might behave oddly)
uv__getaddrinfo_done (win32, if it's possible for GetAddrInfoW to return success but no routes)
uv__interface_addresses_v6 (os390, if the machine does not have any active IPv6 routes)
uv_pipe_bind (win32, will now call abort(), if uv_pipe_pending_instances was called with the nonsensical value of count==0)
uv__build_coalesced_write_req (on 32bit win32, if the total size nearly overflows a UINT32_MAX) but this would break and fail anyways
make_program_args (win32, if the user maliciously—but validly—calls uv_spawn with length(args)==0, now will fail with ERROR_OUTOFMEMORY)
make_program_env (win32, if the user passes an empty environ list, now will fail with ERROR_OUTOFMEMORY)

(This is also not the only place that the win32 code calls abort on a failed allocation, the uv_fs_event code also makes liberal use of abort, and the poll code implementations usually call abort if their realloc fails.)
Originally posted by @vtjnash in https://github.com/libuv/libuv/pull/2038#issuecomment-438800429

It looks like #2279 only added a test for the first item on the list. Was it reviewed that the other items were unreachable, or should this be reopened?

I remember checking src/unix but I don't remember if I also looked at src/win. I'll reopen.

The stale bot was an interesting idea and libuv had just few enough issues that it caused progress on a couple, but could we disable that now, or at least flip the default so that it only closes issues that have been marked needs-more-info?

@vtjnash It'd be best if you open a new issue to discuss.

Not sure why stale bot is malfunctioning there. Anyways, I'm surprised we don't have a regression tag. Should we? These bugs were introduced over a year ago by #2038, and broke Julia when attempting to upgrade (therefore, that PR is reverted on our fork). They seem to be getting slowly addressed as users report these bugs as nodejs regressions (e.g. by https://github.com/libuv/libuv/pull/2408), so stale-bot shouldn't be touching this.


Create haystack-commons.

Initial code facilitates creating Servo objects (generic Counter or
Timer are currently supported) and pushes metrics from those Servo
objects to InfluxDb, via graphite messages. The graphite messages are
then split into InfluxDb style tags and measurements and written to the
database.

Can we add a README on how you expect this to be used by the consumers?

Yes...I actually mentioned during standup that I’ll be doing this today.
From: mchandramouli<EMAIL_ADDRESS>Reply-To: ExpediaDotCom/haystack<EMAIL_ADDRESS>Date: Tuesday, August 22, 2017 at 8:39 PM
To: ExpediaDotCom/haystack<EMAIL_ADDRESS>Cc: Jeff Baker<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [ExpediaDotCom/haystack] Create haystack-commons. (#13)
Can we add a README on how you expect this to be used by the consumers?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/ExpediaDotCom/haystack/pull/13#issuecomment-324212274, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQhRLhJeuAocWKMMhE3hRNFFBXCdd_IRks5sa57ggaJpZM4O_VZR.


tighten static pod UID until v1.23 to account for kubelet bug fix

found in https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.10-e2e-aws-serial/1466323246101041152
The kube-scheduler operand pod doesn't appear to be getting updated.  This is only one of a few different problems in the kube-scheduler-operator.

/lgtm

/approve


TypeError: Expected Map instance

In the conversion of google-cloud-logging from GRPC to GAPIC using GAX, we ran into the following problem dealing with hash objects not being converted to Map objects.
The generated write_log_entries method is as follows:
# Writes log entries to Stackdriver Logging.  All log entries are
# written by this method.
#
# @param log_name [String]
#   Optional. A default log resource name that is assigned to all log entries
#   in +entries+ that do not specify a value for +log_name+.  Example:
#   +"projects/my-project/logs/syslog"+.  See
#   LogEntry.
# @param resource [Google::Api::MonitoredResource]
#   Optional. A default monitored resource object that is assigned to all log
#   entries in +entries+ that do not specify a value for +resource+. Example:
#
#       { "type": "gce_instance",
#         "labels": {
#           "zone": "us-central1-a", "instance_id": "00000000000000000000" }}
#
#   See LogEntry.
# @param labels [Hash{String => String}]
#   Optional. Default labels that are added to the +labels+ field of all log
#   entries in +entries+. If a log entry already has a label with the same key
#   as a label in this parameter, then the log entry's label is not changed.
#   See LogEntry.
# @param entries [Array<Google::Logging::V2::LogEntry>]
#   Required. The log entries to write. Values supplied for the fields
#   +log_name+, +resource+, and +labels+ in this +entries.write+ request are
#   added to those log entries that do not provide their own values for the
#   fields.
#
#   To improve throughput and to avoid exceeding the
#   {quota limit}[https://cloud.google.com/logging/quota-policy] for calls to +entries.write+,
#   you should write multiple log entries at once rather than
#   calling this method for each individual log entry.
# @param partial_success [true, false]
#   Optional. Whether valid entries should be written even if some other
#   entries fail due to INVALID_ARGUMENT or PERMISSION_DENIED errors. If any
#   entry is not written, the response status will be the error associated
#   with one of the failed entries and include error details in the form of
#   WriteLogEntriesPartialErrors.
# @param options [Google::Gax::CallOptions]
#   Overrides the default settings for this call, e.g, timeout,
#   retries, etc.
# @return [Google::Logging::V2::WriteLogEntriesResponse]
# @raise [Google::Gax::GaxError] if the RPC is aborted.
# @example
#   require "google/cloud/logging/v2/logging_service_v2_api"
#
#   LoggingServiceV2Api = Google::Cloud::Logging::V2::LoggingServiceV2Api
#
#   logging_service_v2_api = LoggingServiceV2Api.new
#   entries = []
#   response = logging_service_v2_api.write_log_entries(entries)

def write_log_entries \
    entries,
    log_name: nil,
    resource: nil,
    labels: nil,
    partial_success: nil,
    options: nil
  req = Google::Logging::V2::WriteLogEntriesRequest.new(
    entries: entries
  )
  req.log_name = log_name unless log_name.nil?
  req.resource = resource unless resource.nil?
  req.labels = labels unless labels.nil?
  req.partial_success = partial_success unless partial_success.nil?
  @write_log_entries.call(req, options)
end

The labels argument is clearly documented as a hash of strings ([Hash{String => String}]). However, when providing a hash of strings, TypeError: Expected Map instance is raised. This is because the protobuf object is inconsistent in how it automatically boxes Hash to Map when setting the value using an accessor method. One option is to track which arguments are going to be Maps and convert them in the GAPIC method:
def write_log_entries \
    entries,
    log_name: nil,
    resource: nil,
    labels: nil,
    partial_success: nil,
    options: nil
  req = Google::Logging::V2::WriteLogEntriesRequest.new(
    entries: entries
  )
  req.log_name = log_name unless log_name.nil?
  req.resource = resource unless resource.nil?
  unless labels.nil?
    labels_map = Google::Protobuf::Map.new(:string, :string)
    labels.each { |k, v| labels_map[String(k)] = String(v) }
    req.labels = labels_map
  end
  req.partial_success = partial_success unless partial_success.nil?
  @write_log_entries.call(req, options)
end

Another option is to skip the use of accessor methods and set all values in the constructor. The protobuf class correctly boxes Hash to Map in the constructor. This is how google-cloud-ruby has chosen to avoid this bug before converting to GAPIC and GAX:
def write_log_entries \
    entries,
    log_name: nil,
    resource: nil,
    labels: nil,
    partial_success: nil,
    options: nil
  req = Google::Logging::V2::WriteLogEntriesRequest.new(
    {
      entries: entries,
      log_name: log_name,
      resource: resource,
      labels: labels,
      partial_success: partial_success
    }.delete_if { |_, v| v.nil? }
  )

  @write_log_entries.call(req, options)
end

This should be in the fix of the code generator.  I prefer the latter one, more concise and simpler.

I would like the actual bug to be fixed in protobuf as well, but baby steps. :)

FWIW, this issue is also somewhat blocking GoogleCloudPlatform/google-cloud-ruby#971. I have changes for that issue implemented, but get TypeError: Expected repeated field array when running the acceptance tests. Basically, the GAPIC layer's list_log_entries method it tries to set the resource_names attribute on the protobuf object and it raises an error.

@blowmage If you use the constructor then it should work, right?

If the generated Ruby code was setting values in the constructor instead of using the method setters, then yes it would work for how we use the generated code.


Adding color combinations in addition to the list of colors?

Hello dblodorn,
Thank you for all the efforts. Do you have a plan to add the Japanese names of the colors are placed next to the English ones? This repo definitely deserves a wider audience.

Hi @xanderchf - Yes I would love to do that - in fact I met with a Japanese friend to get an explanation of how the colors are organized. I should probably put a roadmap in the readme as I have a number of goals with the project - with the ultimate goal of presenting to the publishing company, Seigensha Art Publishing.
I welcome any thoughts on what could make this a more useful tool!


Proposal:  $UnionMap<U, F>, the dual of $ObjMap<O, F>

Background
As far as I can understand, $ObjMap<O: Object, F>, given an Object type, returns a new Object type with a type function F applied uniformly to the values of O.
So $ObjMap, given an Object, returns a modified Object.
Proposal
It would be nice to also have its dual, $UnionMap<U: Union, F>, which given an Union, returns a Union with the type function F applied uniformly to the types being unioned in U.
So $UnionMap will, given a disjoint Union, return a modified disjoint Union.
Bonus
In addition, we can also derive the coveted $Values<O> from $UnionMap<U, F>,  $Keys<O>, and an upgraded $PropertyType<O, K> that allows type variables in addition to string literals (which doesn't yet exist):
type $Values<O> = $UnionMap<$Keys<O>, <K>(key: K) => $PropertyType<O, K>>;

conditional type

Exciting!! Anywhere I can read more about this?

Right now the TS docs might be the best reference: https://www.typescriptlang.org/docs/handbook/2/conditional-types.html
We plan to implement the exact behavior as TS' conditional type, modulo some small improvements and deviations.

Super cool!! I had a need for a conditional type when drafting the React Navigation libdefs, and ended up hacking a "solution". Would be great to have first-class support for this


Add magic package

This is a WIP PR

@mithro I believe this version should finally build, but I won't be able to test it until tomorrow evening

Hopefully this is ready for review @mithro


Change Button Colour Dynamically / Multiple Buttons

Correct me if I'm wrong, but it looks like you're resurrecting alertify?
If so, the following is an feature request I posted on the master branch (after maintenance was discontinued)

I think it would be great to be able to change the button colour of the alertify-button-ok and alertify-button-cancel dynamically.

E.g. A dialog window for a "delete" task in my opinion should have a red alertify-button-ok where a dialog for a more "positive/safe" task can have  a green alertify-button-ok.

I've been able to work around this is by appending inline styles to the  that override the alertify's css, but I still think it would be great to have it as an option in the plugin itself.

Keep up the good work!

You're right, it's being maintained here.
The request makes sense, and I think it's something that would be useful. Right now, it seems that it would be great for the next upcoming branch. Everything's going to get a major rewrite, so it would make sense to put it there.

Perfect, that's great to hear!
Thanks!

@bradberger I personally don't know if we need this anymore, but I'm interested to know what you think.
I'm personally quite fond of the new style of alertify.js, i.e. the colourless buttons, and figure it's easy enough to append a .alertify-button-ok { background: green; } to the head anyways.
Let me know.

Yeah, think you might be right again.
One thing that I've had in mind and would still like to get implemented is allowing the whole template to change dynamically, which would take care of all of that. It would be something like:
alertify
    .setAlertTemplate("
content-here
")
    .alert("Hello, world");

That would allow for custom buttons, styles, etc. Right now the html for some parts of the dialogs/etc. would be very easy to change, as with the latest version it's part of the alertify._$$alertify "private" class, so someone "in the know" could actually change it (for example to be a real bootstrap styled buttons:
alertify._$$alertify.dialogs.buttons.ok = "<button class='ok btn btn-success' tabindex='-1'>{{ok}}</button>";
alertify._$$alertify.dialogs.buttons.cancel = "<button class='cancel btn btn-danger' tabindex='-1'>{{cancel}}</button>";
</button>

The underlying code actually just looks for a child .ok class and attaches the event listeners to that, so any other classes can be added to customize things.
That being said, I don't think it's a particularly good idea for people to go around altering the private sections of the code, so that's why I think a public method to change the template (and reset it again with the reset() method) would be useful. Plus, there would have to be some more documentation about setting a custom template, too, to know how it's parsed.
The above is actually the reason we recently pulled the themes from the website, as it would be much better to integrate an option to switch to buttons with real classes for the various frameworks, like Bootstrap, Pure CSS, Material Design Light, etc. so that it wouldn't be just imitating the default style but would actually integrate the user's custom styles.
// Bootstrap
alertify._$$alertify.dialogs.buttons.ok = "<button class='ok btn btn-success' tabindex='-1'>{{ok}}</button>";
// Pure CSS
alertify._$$alertify.dialogs.buttons.ok = "<button class='ok pure-button' tabindex='-1'>{{ok}}</button>";
// Material Design Light
alertify._$$alertify.dialogs.buttons.ok = "<button class='ok mdl-button mdl-js-button mdl-js-ripple-effect'>{{ok}}</button>";
// Angular Material
alertify._$$alertify.dialogs.buttons.ok = "<button class='ok md-raised md-primary md-button md-default-theme'>{{ok}}</button>";
// etc..

The templates themselves are implemented here right now if you want to check it out.
If we wanted to support some basic frameworks by default, I also thought it might be easier to do it for the user, too, perhaps something like this, and behind the scenes we'd change the templates manually:
alertify.useBootstrapTheme();
alertify.usePureCSSTheme();
// etc...

But it's all a question of finding the time to design/implement it :smile: Feedback is always welcomed. It might be good to get a discussion going around this idea of templating/changing the default styles and how we can do that best. Those are just a few ideas, but I'm sure other people would come up with some great solutions, too.

Going to close this for now, as it's more a part of issue #50 now

@bradberger It would make sense if you could do something like this:
alertify   .okBtn("Remove")   .okBtnClass("cancel")   .cancelBtn("Cancel")   .cancelBtnClass("tertiary")   .confirm('Are you sure you want to remove from the team?')
This way you could easily switch the classes around. Right now in my styles I have the .ok class set to a green background and the .cancel class to a red. It would be great to be able to set another class in the way shown above as it pertains to the UI.

Similar to the above, I'd like to have the ability to add a class to the alert itself. Perhaps something like this:
alertify
  .log("Some message")
  .class('myLogClass')


fix(prop-types): update node

component: PropTypes.oneOfType([PropTypes.func, PropTypes.string]).isRequired,
children: PropTypes.node,

Deploy preview ready!
Built with commit b3325bd4bc9010b8e24dabc3d158b962e9dfc141
https://deploy-preview-347--mcs-lite-introduction.netlify.com

Deploy preview ready!
Built with commit b3325bd4bc9010b8e24dabc3d158b962e9dfc141
https://deploy-preview-347--mcs-lite-ui.netlify.com


service option for entity is not fully processed

This is a rather weird issue with parser in JHUML so it might or might not be present here as well
When there are say 4 instructions for serviceClass or serviceImpl only the last 2 are applied
eg:
service Region with serviceClass
service Task with serviceImpl

service Employee with serviceClass
service Department with serviceImpl

In the generated json files only Employee and Department had the option set, If I change the order again whichever entity comes last gets the option

I've a fix for this (tests are being done), and I'm going to add it to JUML for now, and move all the code here when the migration's over.


Links on Index are broken

If you try the links from the gh-pages site. They all point to 404's this is likely due to a relative link issue.

The links are settings for work from a Root domain like `blackpythondevs.com/about'
You can give a test opening the branch in Codespaces (using devcontainer)

I will set the domain and see if that works

We renamed the repo to blackpythondevs.github.io to enable the root path. We'll work on getting things published. We can work on getting the domains working. But it's good now.


bring makefile rust versions inline with nix

PR summary
@ddd-mtl FYI - this bumps makefile rust version to nightly-2019-07-14 bringing it inline with nix here - https://github.com/holochain/lib3h/pull/193
Review checklist

[ ] The story has unit or integration tests
[ ] No new bugs, and any tech-debt is identified and justified
[ ] There is enough API documentation (how to use)
[ ] There is enough code documentation (how the code works)

In this particular case it was failing because the appveyor.yml wasn't in this branch yet. Also, we seem to be getting stuck behind holochain-rust builds in the queue... I think we should not mark it required for merge until we see how stable it is && if we can get a separate queue for builds


add MISIS University

Institution/School Name
MISIS University of Science and Technology
Instiution/School Website
Website URL
Email Users
Please place an x between the square brackets if yes

[x] Students
[x] Academic/Teaching Staff
[ ] Other/Support Staff
[ ] Alumni

Education Levels
Please place an x between the square brackets if yes

[x] Post-graduate research
[ ] Graduate School
[x] College (University) or Undergraduate School or equivalent
[ ] Community College or equivalent
[ ] High School or equivalent
[ ] Elementary School or equivalent

@artik19129 First stage of verification passed, official domain is misis.ru 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.

@philipto After how long will there be a decision?

@artik19129 Unfortunately, your request cannot be processed further because JetBrains doesn’t provide products or services to territories subject to applicable EU, UN, or US sanctions or under comprehensive export control restrictions due to legal, compliance, and other commercial risks.


Version 0.2.0

When will version 0.2.0 be released?

Later today :-)

I'm waiting for it. ;)
But seriously, using dev-master (especially in Production) is a bad thing.

This has just been released :-)

Ah - use 0.2.1 now (0.2.0 is broken)

Nice! Thank you. :)


Not supporting multiple auth guards

I am using multiple auth guard (User & Admin) on my website. adminlte::page has Auth::user(), Auth::user()->adminlte_image(), etc. This is working fine for my User auth guard but not for Admin auth guard since both table are different. I tried to copy adminlte::page to my view but it throws.
Facade\Ignition\Exceptions\ViewException Undefined variable: adminlte (View: /resources/views/admin/page.blade.php)
Please suggest me what should I do?

@tanmay27vats can you please post the content of your admin/page.blade.php?


Reddit proof isn't working

Unable to update/reaffirm my reddit proof. Assuming something on the Reddit side was recently changed that broke this but am unable to replace and retry a new proof via the CLI as well as the web UI.
my log id: 9da52892e310cf4e7855241c

This issue is duplicated by these: https://github.com/keybase/client/issues/25772, https://github.com/keybase/client/issues/25747, https://github.com/keybase/client/issues/25759.

It looks like Reddit may be blocking keybase, based on the available chatter.

✔ "mrjoy" on reddit failed: 403 Blocked (code=240) [cached 2024-06-05 13:23:28 PDT]

Yes.  Reddit is blocking Keybase.

reddit proof suddenly reported as working again.


UI Refresh has completely broken the app

A new UI refresh they've done has completely broken the color themes and the bookmark solver. This seems to be affecting everyone.

Hi @realrandombeans,
Thanks for bringing this to my attention. It seems this update to the sparx website has changed overall website structure. they now use random DIV names, which now makes it extremely difficult to use program features.
For an example;
Old: a class=".status-bar-label-text">XP/a>
New: a class="_XPCount_g7mut_68" href="/student/rewards">XP/a>
With the new change, we will now need to account for the additional class name.
Thanks, Najm

let sparxSolver = dead;
console.log(dead)

i havent looked at the sparx html properly yet but perhaps could use regex to find it????

I think @NajmAjmal has already looked into it and discovered that each html element class has a unique id for every user, for more information ask him, I'm not quite sure what he found out.

I think @NajmAjmal has already looked into it and discovered that each html element class has a unique id for every user, for more information ask him, I'm not quite sure what he found out. @kincho4

Sure. I will try to help and research it to get this working again

again

Great!

I think @NajmAjmal has already looked into it and discovered that each html element class has a unique id for every user, for more information ask him, I'm not quite sure what he found out. @kincho4

i just realised that we might jsut have to change the html names in here and it will be up and running. i have the same as him so i doubt it would be a user id thing. but as long as it does not keep changing even if it is unique we could make something where users put there own id.

Hi @kincho4,
This piece of info is interesting, I assumed it maybe random for all users etc. but that does not seem to be the case. This specific area can easily be fixed. The problem lies with bookwork codes and answers. They have also updated the structure on the website as well. Now it's more likely we can bring back the extension.
Thanks, Najm

let me make a fix for the div change issue. would it be also better to have the script hosted on github so it would be easier for others to make changes. i can modify like it to do that. so it can inject from github raw file.

let me make a fix for the div change issue. would it be also better to have the script hosted on github so it would be easier for others to make changes. i can modify like it to do that. so it can inject from github raw file.

Yes, currently the script (console.js) is hosted on GitHub. It can be modified any time. Any changes will be made live to all users.

i meant the inject is on jsdelivr

Hi @kincho4 & @sulaymaanajmal,
We are going to use Rosie's Azalea as a base for our update. Their version still functions.
Thanks, Najm

Hi @kincho4 & @sulaymaanajmal,
We are going to use Rosie's Azalea as a base for our update. Their version still functions.
Thanks, Najm

It doesn't "still function". It functions because I spent hours rewriting most of the codebase to allow it to still function.


runtime: simplify macro by removing parameters

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Remove a few parameters which are easily derived via the C-preprocessor.  The
global symbol name and the implementation names are derived via the
SWIFT_RT_ENTRY_{REF,IMPL} macros in the implementation.  However, we were
repeating the names through the runtime function list.  This simply changes the
macro definitions to derive the name as necessary.  We can restore additional
parameters if the greater flexibility is ever needed.  NFC.

Mind taking a look, @swiftix ?

@compnerd I don't think it is such a good idea to simplify these macros this way.
The idea behind those explicit parameters is that you can provide custom free-form names for some of the runtime functions, their function pointers and their actual implementations. Yes, we seem to be using the underscores notation for (almost) all of them at the moment, but it may change in the future.
Besides that I prefer this more explicit style, because IMHO it makes it easier to understand what is the name of the runtime function, its function pointer and implementation without looking into any other file.

I can see the point of the explicit names.  However, it is redundant as it currently stands.  Adding the additional parameter in the future if needed doesn't seem too terrible.  However, if you have a strong preference, thats fine.  It just seemed unnecessary to have the name spelt out three times.


[BUG]: Print button when results buttons disabled

Describe the bug
The Print button still appear in the result page even when RESULT_BUTTONS is disabled.
Steps to reproduce the behavior
Disable result_buttons in user interface settings.
Enable print_from_result from the printing settings.
Expected behavior
The print button is hidden.
I'm using a custom keyboard for Collage and Printer, so I just need Collage, QR and Print enabled, with no buttons.
Photobooth Version
Up-to-date
Browser and browser version
Firefox up to date
Operating System
Ubuntu 24.04
Did it work before?
Yes
Latest working version
No response
Additional context
No response

Like you've noticed, print is handled independent. Button bar config handles the following buttons:

take picture
take collage
take video
galllery
Email
qr code

You can anyway hide the button using a own overrides.css inside the private folder of your Photobooth installation.

Didn't know for overrides.css feature, thanks!

I guess the key code trigger part should be revisited before the next major release as some actions use different API endpoints while on print we need to simulate a button press.
Maybe I need to add some extra checks to also prevent taking new images, collage or video on result screen if the button bar is disabled.


Renaming/refacotring name of inline replaces all instances in files with the file name only, no path.

Basically what happens renaming an inline causes all invocations of the inline to get refactored wrong.
For example, if i rename my_inline.txt to my_new_name_inline.txt, the refactor swaps all inline script invocations from
inline_script = path/to/my_inline

to:
inline_script = my_new_inline.txt

Thus removing the path prefix.

I tried doing shift+F6 for other too (ie script values, triggers and effects) and those work no issue it seems


selective IV checks based on a pre-defined filter

Right now its either all or nothing for IV checks. As IV checks now have a clear delineation for over lvl30 accounts, I would like to suggest that an ability to check for IV on select poke with a separate account list will be highly utilized, and is needed for feature comparison.
Thanks.!

This is the only thing I miss about RocketMap. I hope someone can do this?!

This is something that would be highly useful.
At the very least, it would be nice if ENCOUNTER configuration setting could be considered only for accounts above level 30, so that if IVs are shown, they are reliable.


Support insecure-skip-tls-verify config flag

fixes #99

Current coverage is 94.46% (diff: 80.00%)

Merging #107 into master will decrease coverage by 0.06%

@@             master       #107   diff @@
==========================================
  Files             9          9
  Lines           658        668    +10
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            622        631     +9
- Misses           36         37     +1
  Partials          0          0

Powered by Codecov. Last update f10f4f3...8fc978e

LGTM


Change with Orientation

Hello,
Width and Height does not change when the orientation of the mobile change to portrait to landscape.
Could you help ?
Thank you,
Christophe

I'll be happy to look into that. I can't remember what I coded up for each platform there. Is this an issue on Android, iOS, UWP, or all? Thanks! On Apr 13, 2017, at 11:47, CJACQUEL<EMAIL_ADDRESS>wrote:
Hello,
Width and Height doesnot change when the orientation of the mobile change to portrait to landscape.
Could you help ?
Thank you,
Christophe
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
On Apr 13, 2017, 11:47, at 11:47, CJACQUEL<EMAIL_ADDRESS>wrote:

Hello,
Width and Height doesnot change when the orientation of the mobile
change to portrait to landscape.
Could you help ?
Thank you,
Christophe
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jasonCodesAway/XamJam/issues/4

The issue is for Android, I use this plateform only for the moment. It is simple to reproduce, display the width the change the orientation of the screen, the width does not change.
Thx

I should be able to add that functionality this weekend and hopefully cut a beta release. Are you willing to be the tester? :-)

Yes I can test with Android, I have no iMac. Thx.

I just pushed 1.0.7. This bug should only have affected Droid. Thanks for the report!
If you encounter any issues in testing please re-open this issue or file a new one.
Happy Weekend :)


mounted property on ConsumerWidget

Hi and thank you for Riverpod. I appreciate all the hard work that has gone into creating this library.
When performing navigation across async gaps, I would have wanted to be able to continue using ConsumerWidget rather than ConsumerStatefulWidget since, from what I understand, ConsumerWidget is in fact a stateful widget! However, at the moment ConsumerWidget does not expose a mounted property which can be checked before doing navigation across async gaps.
It would be really good if ConsumerWidget could expose a getter called mounted which could be used for navigation across async gaps.
Thank you again for Riverpod and for your time,
/v

Hello!
ConsumerWIdget extends StatefulWidget for the sole reason of having two parameters on build. Otherwise it'd extend StatelessWidget
But in any case, what you're asking isn't possible. ConsumerWidget is still a Widget, not a State. There's no way to pass the mounted property there.
And even if we could do that, I probably wouldn't do it. I'd instead suggest asking Flutter to add one for StatelessWidget (as ConsumerWidget as similar constraints to that of StatelessWidget). I'd then add it to ConsumerWidget

Hi Remi and thank you for your response. I agree that it probably needs to go all the way down to the Flutter team hence this issue won't belong here in this repo anymore. Thank you for your time and I'll take the liberty of closing this issue. Have a good rest of the day. /v


Updated dashboard.py - printing decreasing order

No description provided.

reviewing..

Again, Thanks a lot !! 🔥


[RFE] Add support for fqdn pool member references

This was not part of the initial build and breaks app parsing if present.  Should also go with issue #1 to minimize any processing errors

This support has been added in the last couple of days


Fixed warnings in script templates

I was getting warnings in the editor with scripts derived from the script templates because they didn't specify a return type for the _get_configuration_warnings() function.
That said, this has created four warnings that I cannot understand in VSCode's linting, however that works. So this is theoretically not ready for incorporation without further review.
The errors I'm seeing are all:
The function signature doesn't match the parent. Parent signature is "_get_configuration_warnings() -> Variant".

This makes no sense to me, because if I ctrl-click to the parent, it clearly shows -> PackedStringArray. I'm seeing this for the following files:

fsm_state_integrated_bt.gd
fsm_state_integration_return.gd
new_state.gd
new_transition.gd

The common link here is that these are FSM ones, and the BT ones didn't give me any such issues, but I have no idea if that's relevant.
Also, I have the formatter installed, so various changes to whitespace are a result of that.

Do you also get these warnings in the editor? I'll look into it later today.

The original ones that caused me to report this, yes I originally saw those in the editor. The errors I mentioned seeing after those fixes I somehow didn't see in the editor. Since I thought the editor and code used the same language server, I do find that perplexing.

And you saw the warning when extending these specific classes?

Just checked it out and can't seem to get the Warnings in VSCode. Are you using any specific Linter or just the GDScript language server? I also can't reproduce the original warning message in the editor.  How exactly did you get that?

In Project Settings -> Debug -> GDScript, I have everything turned on, including "Untyped Declaration".

Ah, I see. I am now getting those warnings too.

The common link here is that these are FSM ones, and the BT ones didn't give me any such issues, but I have no idea if that's relevant.

I figure, the problem is mostly because some of the FSM scripts do not have static return types, where as most BTs use -> PackedStringArray. This is just an inconsistency on my part. I guess the linter uses the overridden method that has an untyped  return declaration (equals -> Variant) and starts screaming and kicking.

I cannot get any other warnings. Would you mind uploading a minimal project where you get these other warnings so I can see?

Not seeing those anymore, now that I've closed everything and gone back in fresh. Makes sense I guess, since the warnings weren't making sense anyway.

Not seeing those anymore, now that I've closed everything and gone back in fresh. Makes sense I guess, since the warnings weren't making sense anyway.

Yeah, I found the language server can be a bit of a mess sometimes. Especially when files haven't been loaded in a long time. If you don't have anything to add, I will merge this ASAP! Thank your for contributing <3


Autodeps + shakeCommandOptions

Looks good, modulo the deriving typeable (and anything else the buildbots spot). Just off to bed, but I'll merge tomorrow, assuming it's all passing then.

BTW, in general, ignore the Appveyor failures - I'm still working on bringing them up to spec. The Travis failures. In this case, you need to add the new module to the .cabal file as well.

Merged, thanks! I also renamed Autodeps to AutoDeps, which seems nicer (splits the words properly). Let me know if that seems like a bad idea.


Edit classify results

Closes https://github.com/ethyca/fidesctl-plus/issues/226
Closes https://github.com/ethyca/fidesctl-plus/issues/341
Sorry about the size of this PR, but there didn't seem to be a good stopping point... In retrospect, I probably could've done the EditDrawer refactor separately, as that touched a lot of files (though all in the same way!)
Code Changes

[ ] Pull out EditDrawer into a common component
[ ] Make some of the props of EditDrawer optional to be more flexible, update the components already using the drawer with the updated props
[ ] Most of the new stuff: new drawer for editing a system classification. Follows much of the same logic as dataset classification did. some formik, some accordions, all of our favorite things
[ ] Cypress tests

Steps to Confirm

Same steps as in https://github.com/ethyca/fides/pull/1752
But now you can click through and classify things 🎉
...except there is a redux related bug right now I haven't figured out yet.

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation Updated:

[ ] documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
[ ] documentation issue created (tag docs-team to complete issue separately)

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md

Description Of Changes
https://user-images.githubusercontent.com/24641006/202797842-b3dfd3e0-93ee-46e2-a557-1c3ea27634f3.mov
Can also manually classify things that were not classified
https://user-images.githubusercontent.com/24641006/202798744-fefc69e4-19f3-43e7-9764-95d7fa32ab76.mov

Currently there's something going on where the state isn't being updated after the system PUT (likely I'm doing something wrong with redux but I haven't figured it out yet)
https://user-images.githubusercontent.com/24641006/202799590-baef955b-1420-47e4-a7c3-e4aaf5161117.mov

fixed, and now I understand redux just a lil more 😌
https://user-images.githubusercontent.com/24641006/202810060-08df51d0-1f43-4fbb-b163-fc0e226f2f4b.mov

Do I need to run the plus off a branch? The server on main (397f500) gives me a 404 /api/v1/plus/scan

Do I need to run the plus off a branch? The server on main (397f500) gives me a 404 /api/v1/plus/scan

You can run it on main, but you'll have to follow these instructions for enabling the scanning API


allow esnext by removing gulp

Description
Allow JSX syntax by replacing jshint with eslint, and replacing incompatible gulp-tape package with a tape script.
Expected behaviour
Contributor should be able to use JSX.
Actual behaviour
gulp-tape and jshint error when using jsx syntax
Operating system and version
Darwin Macs-MacBook-Pro-2.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
For information on the specific distribution. Please consult your distribution documentation.
Avrgirl Arduino version
<EMAIL_ADDRESS>NodeJS version
v10.15.3

we can close this now 🎉


890 complier errors

Hi guys im on the latest version of X code and followed the instructions here but I get a load of errors
does anyone know why this is happening?
this is my pod file, all installed fine no errors
Uncomment this line to define a global platform for your project
platform :ios, '9.0'
target 'PartyRockApp' do
Comment this line if you're not using Swift and don't want to use dynamic frameworks
use_frameworks!
Pods for PartyRockApp
pod 'Alamofire', '~> 4.0'
end
thanks

Make sure you are using CocoaPods 1.1.0-rc.2 and that your project is set up to compile against Swift 3. You can install the rc version of CocoaPods using: gem install cocoapods --pre.


Publish to Azure Fails

Describe the bug
Publish to Azure using a project I have published several times before. It fails with a 400 error.
400 - "{\r\n "error": {\r\n "code": "BadArgument",\r\n "message": "The source completed without providing data to receive."\r\n }\r\n}"
Version
Version:  1.1.1-nightly.172371.8d1fc5a
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0
OS

[ ] macOS
[x] Windows
[ ] Ubuntu

To Reproduce

Go to 'Publish'
Click on 'Publish to selected profile'
See error

Expected behavior
Publish should complete with no error.
Screenshots

Additional context
I started with the EchoBot template. I made several changes, and added several intents. I was able to publish many times. Now it fails.

From the publish log:
{   "status": "DEPLOY_INFO",   "message": "start publish luis" } {   "status": "DEPLOY_ERROR",   "message": "{\"name\":\"StatusCodeError\",\"statusCode\":400,\"message\":\"400 - \\\"{\\\\r\\\\n  \\\\\\\"error\\\\\\\": {\\\\r\\\\n    \\\\\\\"code\\\\\\\": \\\\\\\"BadArgument\\\\\\\",\\\\r\\\\n    \\\\\\\"message\\\\\\\": \\\\\\\"The source completed without providing data to receive.\\\\\\\"\\\\r\\\\n  }\\\\r\\\\n}\\\"\",\"error\":\"{\\r\\n  \\\"error\\\": {\\r\\n    \\\"code\\\": \\\"BadArgument\\\",\\r\\n    \\\"message\\\": \\\"The source completed without providing data to receive.\\\"\\r\\n  }\\r\\n}\",\"options\":{},\"response\":{\"statusCode\":400},\"stack\":\"StatusCodeError: 400 - \\\"{\\\\r\\\\n  \\\\\\\"error\\\\\\\": {\\\\r\\\\n    \\\\\\\"code\\\\\\\": \\\\\\\"BadArgument\\\\\\\",\\\\r\\\\n    \\\\\\\"message\\\\\\\": \\\\\\\"The source completed without providing data to receive.\\\\\\\"\\\\r\\\\n  }\\\\r\\\\n}\\\"\\n    at new StatusCodeError (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\errors.js:32:15)\\n    at Request.plumbing.callback (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\plumbing.js:104:33)\\n    at Request.RP$callback [as _callback] (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\plumbing.js:46:31)\\n    at Request.self.callback (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:185:22)\\n    at Request.emit (events.js:210:5)\\n    at Request.<anonymous> (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:1154:10)\\n    at Request.emit (events.js:210:5)\\n    at IncomingMessage.<anonymous> (C:\\\\Users\\\\kdubi\\\\AppData\\\\Local\\\\Programs\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:1076:12)\\n    at Object.onceWrapper (events.js:299:28)\\n    at IncomingMessage.emit (events.js:215:7)\\n    at endReadableNT (_stream_readable.js:1183:12)\\n    at processTicksAndRejections (internal/process/task_queues.js:80:21)\"}" } 400 - "{\r\n  \"error\": {\r\n    \"code\": \"BadArgument\",\r\n    \"message\": \"The source completed without providing data to receive.\"\r\n  }\r\n}"

I deleted the app from LUIS, and published again.
The app was back in LUIS, but same failure error in Composer.
I then connected the app in LUIS to the Prediction Resource and published again. Same error.

@kdubious This seems like a luis account issue, https://github.com/microsoft/BotFramework-Composer/issues/3321#issuecomment-644619986. Is there anything changed for your luis account?

@luhan2017 Interesting! The Azure CLI seems to have jumped to another tenant. When I ran the command to get an updated token, it pulled one from another tenant to which I have access, but to whom i did not connect in that terminal session.

I have the same problem, when trying to publish with LUIS Service fails, my token is working good, any idea?

I have the same problem, when trying to publish with LUIS Service fails, my token is working good, any idea?

Here's the log
Publish starting...
{
"status": "DEPLOY_INFO",
"message": "C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\interuption\enigmamxbot.en-us.lu loaded\n"
}
{
"status": "DEPLOY_INFO",
"message": "C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\interuption\enigmamxbot.en-us.lu no changes\n"
}
{
"status": "DEPLOY_INFO",
"message": "Writing to C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\enigmamxbot.en-us.lu.dialog\n"
}
{
"status": "DEPLOY_INFO",
"message": "Writing to C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\enigmamxbot.lu.dialog\n"
}
{
"status": "DEPLOY_INFO",
"message": "Writing to C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\enigmamxbot.lu.qna.dialog\n"
}
{
"status": "DEPLOY_INFO",
"message": "Writing to C:\Users\slipk\AppData\Roaming\BotFrameworkComposer\publishBots\e6919890eb277b4044adbbd03678093c\azurewebapp\ComposerDialogs\generated\luis.settings.aeba.westus.json\n"
}
{
"status": "DEPLOY_INFO",
"message": "lubuild succeed"
}
{
"status": "DEPLOY_INFO",
"message": "start publish luis"
}
{
"status": "DEPLOY_ERROR",
"message": "{"name":"StatusCodeError","statusCode":400,"message":"400 - \"{\\r\\n  \\\"error\\\": {\\r\\n    \\\"code\\\": \\\"BadArgument\\\",\\r\\n    \\\"message\\\": \\\"The source completed without providing data to receive.\\\"\\r\\n  }\\r\\n}\"","error":"{\r\n  \"error\": {\r\n    \"code\": \"BadArgument\",\r\n    \"message\": \"The source completed without providing data to receive.\"\r\n  }\r\n}","options":{},"response":{"statusCode":400},"stack":"StatusCodeError: 400 - \"{\\r\\n  \\\"error\\\": {\\r\\n    \\\"code\\\": \\\"BadArgument\\\",\\r\\n    \\\"message\\\": \\\"The source completed without providing data to receive.\\\"\\r\\n  }\\r\\n}\"\n    at new StatusCodeError (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request-promise-core\\lib\\errors.js:32:15)\n    at Request.plumbing.callback (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request-promise-core\\lib\\plumbing.js:104:33)\n    at Request.RP$callback [as _callback] (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request-promise-core\\lib\\plumbing.js:46:31)\n    at Request.self.callback (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request\\request.js:185:22)\n    at Request.emit (events.js:210:5)\n    at Request. (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request\\request.js:1154:10)\n    at Request.emit (events.js:210:5)\n    at IncomingMessage. (C:\\Users\\slipk\\AppData\\Local\\Programs\\Bot Framework Composer\\resources\\app.asar.unpacked\\build\\plugins\\azurePublish\\node_modules\\request\\request.js:1076:12)\n    at Object.onceWrapper (events.js:299:28)\n    at IncomingMessage.emit (events.js:215:7)\n    at endReadableNT (_stream_readable.js:1183:12)\n    at processTicksAndRejections (internal/process/task_queues.js:80:21)"}"
}
400 - "{\r\n  "error": {\r\n    "code": "BadArgument",\r\n    "message": "The source completed without providing data to receive."\r\n  }\r\n}"

@jpd21122012 did you make sure the token is from the correct tenant?

@jpd21122012 did you make sure the token is from the correct tenant?

Yes, totally sure, I've also created a token from Azure Cloud Shell, selecting the correct subscription, and it's the same.

Hello there, my partner and I have also run into the same issue as above.
After following the tutorial on Microsoft's web page (to make a weather bot) we have been unable to get it to publish. the Luis account works in composers emulator, but when we try to push in publishing it comes up with the error.
The log shows the same (or similar) error:
Publish starting... {   "status": "DEPLOY_INFO",   "message": "C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\interuption\\Cancel.en-us.lu loaded\n" } {   "status": "DEPLOY_INFO",   "message": "C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\interuption\\GetWeather.en-us.lu loaded\n" } {   "status": "DEPLOY_INFO",   "message": "C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\interuption\\help.en-us.lu loaded\n" } {   "status": "DEPLOY_INFO",   "message": "C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\interuption\\weatherbot.en-us.lu loaded\n" } {   "status": "DEPLOY_INFO",   "message": "C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\interuption\\weatherbot.en-us.lu no changes\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\weatherbot.en-us.lu.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\weatherbot.lu.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\Cancel.lu.qna.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\GetWeather.lu.qna.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\help.lu.qna.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\weatherbot.lu.qna.dialog\n" } {   "status": "DEPLOY_INFO",   "message": "Writing to C:\\Users\\Otter\\AppData\\Roaming\\BotFrameworkComposer\\publishBots\\5fc68681cb5057b653b63f12dd99d431\\azurefunctions\\ComposerDialogs\\generated\\luis.settings..westus.json\n" } {   "status": "DEPLOY_INFO",   "message": "lubuild succeed" } {   "status": "DEPLOY_INFO",   "message": "start publish luis" } {   "status": "DEPLOY_ERROR",   "message": "{\"name\":\"StatusCodeError\",\"statusCode\":400,\"message\":\"400 - \\\"{\\\\r\\\\n  \\\\\\\"error\\\\\\\": {\\\\r\\\\n    \\\\\\\"code\\\\\\\": \\\\\\\"BadArgument\\\\\\\",\\\\r\\\\n    \\\\\\\"message\\\\\\\": \\\\\\\"The source completed without providing data to receive.\\\\\\\"\\\\r\\\\n  }\\\\r\\\\n}\\\"\",\"error\":\"{\\r\\n  \\\"error\\\": {\\r\\n    \\\"code\\\": \\\"BadArgument\\\",\\r\\n    \\\"message\\\": \\\"The source completed without providing data to receive.\\\"\\r\\n  }\\r\\n}\",\"options\":{},\"response\":{\"statusCode\":400},\"stack\":\"StatusCodeError: 400 - \\\"{\\\\r\\\\n  \\\\\\\"error\\\\\\\": {\\\\r\\\\n    \\\\\\\"code\\\\\\\": \\\\\\\"BadArgument\\\\\\\",\\\\r\\\\n    \\\\\\\"message\\\\\\\": \\\\\\\"The source completed without providing data to receive.\\\\\\\"\\\\r\\\\n  }\\\\r\\\\n}\\\"\\n    at new StatusCodeError (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\errors.js:32:15)\\n    at Request.plumbing.callback (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\plumbing.js:104:33)\\n    at Request.RP$callback [as _callback] (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request-promise-core\\\\lib\\\\plumbing.js:46:31)\\n    at Request.self.callback (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:185:22)\\n    at Request.emit (events.js:210:5)\\n    at Request.<anonymous> (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:1154:10)\\n    at Request.emit (events.js:210:5)\\n    at IncomingMessage.<anonymous> (C:\\\\Program Files\\\\Bot Framework Composer\\\\resources\\\\app.asar.unpacked\\\\build\\\\plugins\\\\azurePublish\\\\node_modules\\\\request\\\\request.js:1076:12)\\n    at Object.onceWrapper (events.js:299:28)\\n    at IncomingMessage.emit (events.js:215:7)\\n    at endReadableNT (_stream_readable.js:1183:12)\\n    at processTicksAndRejections (internal/process/task_queues.js:80:21)\"}" } 400 - "{\r\n  \"error\": {\r\n    \"code\": \"BadArgument\",\r\n    \"message\": \"The source completed without providing data to receive.\"\r\n  }\r\n}"`
We figured this may be some sort of access issue to azure, but have tried from different access tokens (both generated in azure CLI and Azure Cloud Shell) and from both users (both have owner privileges) but this is an error we receive if we try to provision new resources, or use existing ones.
We have managed to publish bots using regex with no issues, it seem to be any we do with LUIS any help to shed light on this matter would be greatly appreciated!

@philip-mc, this issue usually happens at this step: after we use the authoring key to create luis applications, we need to bind the luis applications to a prediction resource ， Could you please try this api directly in this web page, if you get the same error, that means there are some issues for the luis account.
https://westus.dev.cognitive.microsoft.com/docs/services/5890b47c39e2bb17b84a55ff/operations/5be313cec181ae720aa2b26c/console

Please let me know the result, we can schedule a call for this if needed. Thanks :)

hello and thanks for getting back, it does appear we have an error!

This was the results from the publish generated app id and luis auth key

@luhan2017  Forgive me, it appears that was a lack of bearer in the authorisation box, the new error -

the same as in publisher

@philip-mc , This error usually happens when the arm token and authoring service is not under the same tenant. But you already confirmed that right?  Several similar issues have been reported recently, I will try to connect with luis team to understand if there are any authentication update in their side.

Thanks for the quick reply, here are a few screens of the current set up, the tenant and subscription match the token and they both match the Luis resource
Tenant:

Subscription:

Luis Authoring:

Token Generation:

Again, thank you for help in this matter

@philip-mc , could you please submit a ICM ticket to luis team referring to this doc? https://docs.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request. It is the best way to get their attention and have them prioritized for this.


Rust toolchain can't build hello world crate on aarch64-darwin

Describe the bug
Rust toolchains installed from nixpkg rustup tool can't build hello world crate on aarch64-darwin due to a linker error against libiconv.
Steps To Reproduce
Steps to reproduce the behavior:

Spin up a aarch64-darwin machine
nix build nixpkgs#rustup
result/bin/cargo new helloworld
cd helloworld
../result/bin/cargo build

Expected behavior
I expect the rustup cargo to be able to compile things.
Error message from cargo
   Compiling testblah v0.1.0 (/Users/ath/Desktop/testblah)
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-arch" "arm64" "/var/folders/jv/jm_5dpd13k1czv1qhs_v89h00000gn/T/rustcG7f5px/symbols.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.14zk7xfwqfsi8obc.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.2i6y6y31mosa6scy.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.2tio27vfxt1a8lu5.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.4exdptxntusv1fad.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.58xrho40r656pdxz.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.eg5oyg41tbtyj2m.rcgu.o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca.2nytofdm5s8bcmvm.rcgu.o" "-L" "/Users/ath/Desktop/testblah/target/debug/deps" "-L" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-e24e0c7fd09714c0.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-b21ee2fb93f4a334.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-4ce05f7a889fff94.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libmemchr-066d562bc324b771.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-8cb0c59b12697637.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-07d89e6b9536e071.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-c65b90a0ba43b683.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd_detect-9f8f7348c047b33a.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-34c451524b66e414.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libminiz_oxide-b1a98f39eda4ff6a.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libadler-1c7622591b95f47e.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-5ee0c1cf171b84b0.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-3ee364d970255739.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-85b53c7fb22d1018.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-b5372de70a998108.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-945b7af0c9f21aac.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-0251f0b5857602a2.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-9382e8c089006a25.rlib" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-6b5d600bff28faab.rlib" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" "-L" "/Users/ath/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/Users/ath/Desktop/testblah/target/debug/deps/testblah-0add0e46f6f9b1ca" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: ld: library not found for -liconv
          collect2: error: ld returned 1 exit status

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
 - system: `0`
 - host os: `Darwin 22.2.0, macOS 13.1`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`
 - channels(root): `""`

This is a flake-based deployment without any channels configured and nix-info bails out after that.
CC @Mic92

This has nothing to do with rustup, FWIW, you're using Nixpkgs' Cargo.
This is expected behavior (but will be fixed with 1.66), you can fix it by adding libiconv to your environment.

I'll keep this open until 1.66 hits unstable.

Hm, yes and no: using the repro steps in the original post, I use the cargo downloaded by rustup and in my second comment I use nixpkg cargo. Both have the same issue.

Oops, you're right, didn't notice that.

you can fix it by adding libiconv to your environment.

If you allow me the somewhat off-topic question: how do I actually do that idiomatically? I tried nix shell --impure nixpkgs#libiconv but am still running into the same issue. It appears that it's only adding the /bin directory to my PATH.

So this is going to sound weird, but does nix-shell -p libiconv properly set LIBRARY_PATH? (Not sure off the top of my head.)
The idiomatic method is to use per-project development environments by way of pkgs.mkShell (manual), which will definitely specify the library where it's needed.

So this is going to sound weird, but does nix-shell -p libiconv properly set LIBRARY_PATH? (Not sure off the top of my head.)

No, but it does set two more other environment variables: NIX_CFLAGS_COMPILE and NIX_LDFLAGS which makes things work. I'm guessing that NIX_LDFLAGS is probably picked up by the ld wrapper. Interesting, so it looks like the nix3-shell isn't really a full replacement yet. Anyway, that's certainly a topic for a separate issue!

The idiomatic method is to use per-project development environments by way of pkgs.mkShell (manual), which will definitely specify the library where it's needed.

Thanks! I was trying to avoid that variant because I can't upstream Nix config for the project I'm working on, but I guess I can just keep a corresponding Nix expression outside the source tree.

So this is going to sound weird, but does nix-shell -p libiconv properly set LIBRARY_PATH? (Not sure off the top of my head.)

No, but it does set two more other environment variables: NIX_CFLAGS_COMPILE and NIX_LDFLAGS which makes things work. I'm guessing that NIX_LDFLAGS is probably picked up by the ld wrapper.

Correct, yup.

Interesting, so it looks like the nix3-shell isn't really a full replacement yet. Anyway, that's certainly a topic for a separate issue!

Yeah, they use completely different methods of adding dependencies to the shell. Feel free to file an issue at https://github.com/NixOS/nix if you'd like, even if just for clarification of why the behavior is different/if it's intentional or not :)

Closing this since this is no longer an issue with newer Rust toolchains.

@athre0z what are the newer toolchains?
I'm still running into this problem with rustc 1.75.0 (82e1608df 2023-12-21) (built from a source tarball) which is installed as a nix package

Running into this with rustc-1.78.0 in 24.05 when cross-compiling rust programs from aarch64-darwin to gnu64, but not when compiling natively on either platform. nix build nixpkgs#legacyPackages.aarch64-darwin.pkgsCross.gnu64.static-web-server (warning, may take half an hour or more)


[TF:MLIR] Canonicalize ShapeNOp with partial input shape

Canonicalize ShapeNOp by replacing corresponding output with static input shape.

/cc @smit-hinsu for visibility.


Latest firefox-esr not working at all under x11docker 6.5

First of all, I believe firefox is doing something irregular here, because everything else seems to work. And one of firefox's command line options is --display=DISPLAY so that it is obviously designed to mess with X remoting in its own ways.
I tried all options, --gpu, --xpra, --nxagent (I have all of the auxiliary tools installed), with or without giving the container the device mount of /dev/dri, set or not set the DISPLAY parameter of firefox, and I have built essentially the same image out of both Debian and Alpine, I get nothing no matter what, not even a error message when I run it from a terminal window.
I am out of options, according to my research, the firefox command line option --no-remote and --no-xshm is supposed to make a difference, didn't work for me, but hopefully can help you debug this. Last but not least, if I throw tightvnc inside the container and put a viewer on it, firefox works just fine, so it really comes down to firefox not liking X remoting.

How did you start firefox?
In README.md I give this example:
x11docker --share $HOME/Downloads -- --tmpfs /dev/shm -- jess/firefox

jess/firefox is not ESR but the latest beta version.
Note the part -- --tmpfs /dev/shm -- that avoids tab crashing.

one of firefox's command line options is --display=DISPLAY so that it is obviously designed to mess with X remoting in its own ways.

This won't hurt if you don't use it.

the firefox command line option --no-remote and --no-xshm is supposed to make a difference,

--no-remote only disallows multiple firefox instances to communicate with each other. That would not hurt a container setup.
--no-xshm is interesting. It does not appear if I run firefox --help. Where did you find it?

I have built essentially the same image out of both Debian and Alpine, I get nothing no matter what, not even a error message when I run it from a terminal window.

Can you show me your Dockerfile?

I figured out why ... long story short .... you overrode the /etc/sudoers file within the container without me asking for it, how do I turn that feature off please?

you overrode the /etc/sudoers file within the container without me asking for it, how do I turn that feature off please?

You can set option --user=RETAIN to keep the container user settings (including /etc/sudoers). By default, x11docker sets up an unprivileged container user.

Could you show me the Dockerfile, please? I'd like to know what user setup in image can cause a failure with x11docker.


Adding API Gateway

Moving API Gateway related changes from Original Repo to this new repo
Signed-off-by: Kamesh Sampath<EMAIL_ADDRESS>

@jcrossley3 - I still need to add the APIManagement job, wondering shall I add to the same template?

@kameshsampath sure that's fine


Enhancement: Use proper validation for language code in aad user add

Currently the command aad user add uses a validation for the language code to see if it contains at least 2 characters, which doesn't cover the load. Since there is a list of possible combinations (which is available in the docs) I suggest to validate this more strictly
This issue is resolved when the preferredLanguage option is validated by the following points:

the language code can consist of a minumum of 1 group and a maximum of 3 groups, combined with a dash
the first group can consist of a maximum of 2 characters, only letters
the second group can consist of a minumum 2 and a maximum of 4 characters where a combination of letters and numbers is possible
The third group can consist of exactly 2 characters, only capital letters possible

I'm always in for better validation, but here it might become a bit tricky. While speccing the aad user add command, I used this page to define the language because it was the best reference for language codes. However while reviewing the PR, I noticed that some languages listed there don't work. If I'm not mistaken, the upper casing was not required as well. nl-be works just fine iirc. Because some language codes don't work, I'm wondering if other languages that are not listed here are supported.

We also noticed that some preferred language codes also contain 3 characters to start with, for example:

This is getting too complicated for what it is. As we don't have a 100% accurate list of what is supported we should let the API error handling do its job. We should document it accordingly so the users are aware of this scenario. I feel like, if we implement a custom regex validator it can become a hurdle for the users to send the request. In the end, when they pass validation, the API can still throw an error because the language isn't supported.
So my vote would go to document this properly and remove the validation.

I remember a command that I worked on where there was a much stricter supervision of the validation of an option that in my eyes was much more general than what we are talking about here. Here I just try to extend the line, but at the moment I wonder what the vision is about validation of options.
In the documentation they themselves talk about the fact that this must be an ISO 639-1 code, a clear definition of the possibilities. That not all the possibilities work from the list that they offer themselves seems to me a problem from Graph itself. But no reason for me not to clear it out here

So first of all, I don't think this is a bug because users are currently not blocked to enter valid language codes, this actually an enhancement.

My bad, @milanholemans, I misunderstood the issue.

In the end, when they pass validation, the API can still throw an error because the language isn't supported.

This is very much the case: just because a value validates, it doesn't mean it won't lead to the API returning an error. The idea behind the validation is to catch errors as quickly as possible and return a meaningful error that helps user recover.
If we can add a meaningful validation, we should do it. If it gets too complicated and introduces a risk of blocking the user, we shouldn't do it. Completing validation is prerequisite for executing a command, so if validation fails, the user is blocked in a way they can recover without our intervention. Let's try to avoid that.

I remember a command that I worked on where there was a much stricter supervision of the validation of an option that in my eyes was much more general than what we are talking about here. Here I just try to extend the line, but at the moment I wonder what the vision is about validation of options.

Yes but in this example, it's documented by Microsoft how a choice value prefix should look like. If you provide an invalid value, the API returns a response saying that the choice value prefix should match:

It only contains characters a-z A-Z 0-9 or _
First character is not a number (a-z A-z or _)

I'm certainly not a power platform expert, but this was an error the API was giving me. So I thought we can check this in our validation quite easily.

In the documentation they themselves talk about the fact that this must be an ISO 639-1 code, a clear definition of the possibilities. That not all the possibilities work from the list that they offer themselves seems to me a problem from Graph itself. But no reason for me not to clear it out here

Yes in the documentation of Graph they say it's an ISO 639-1 code. But the list we are using has BCP 47 codes.
There is a list of ISO 639-1 codes and these work as well. ISO-639-1 language codes consist of only 2 characters, but I found out many BCP 47 codes are working as well.
Because with ISO 639-1 codes you are only targeting a language and not a country, you cannot choose between British English and American English for example. That's why I chose to use the least strict validation there is being: "it has to be 2 characters", because this matches the ISO 639-1 codes, but people can still provide BCP 47 country specific codes.
unlike from the power platform API, Graph is just telling us: Property preferredLanguage has an invalid value. And Graph doesn't provide us with an exact list of which language codes are accepted.

If we can add a meaningful validation, we should do it. If it gets too complicated and introduces a risk of blocking the user, we shouldn't do it. Completing validation is prerequisite for executing a command, so if validation fails, the user is blocked in a way they can recover without our intervention. Let's try to avoid that.

Completely agree with this. If we know exactly the format of something (e.g. a GUID) we can definitely validate the input. However for this property I feel like we don't really know which values are accepted, we know ISO 639-1 codes are accepted, also BCP 47 codes are accepted. In the Graph docs they claim you should use ISO 639-1 codes, but these codes are only language specific and not country specific. So for example you have to pick en while for BCP 47 codes, you can pick en-GB and en-US. And because BCP 47 codes are also working I found it useful to document these codes because they are much more relevant in my opinion. But who knows what other language codes are accepted?

Based on your observations, @milanholemans, I suggest we keep the current - simple validation in place and don't narrow it down to avoid potentially blocking users. Not to mention, making validation more restrictive at this point, would be a breaking change that we can't just implement.

Even though we decided not to change this feature, I really appreciate our debate and everyone bringing different arguments. Thank you all. Together we make CLI an awesome tool for everyone! ❤


Write unit tests for all python functions

Issue to be closed when unit tests have been written for all functions

I have completed the testing for my function


[doc] add Resource-Requirement recommend hardware spec [Future extend best practices doc]

What would you like to be added:
add Resource-Requirement recommend hardware spec []
Why is this needed:
change wiki page
Without this feature, how does the current module work：
work well, but user confused about how to config it
Components that may involve changes:
wiki page of https://github.com/Microsoft/pai/wiki/Resource-Requirement

@YanjieGao I'm not very clear what's expected in this issue? There is resource-requirement page already, is anything needed more?

Close it, we already have a resource-requirement page.


No reponse or action from calling /custom_templates/string and  /custom_templates/file endpoints

Before you start please confirm the following.

[X] Yes, I've searched similar issues on GitHub.
[X] Yes, I've checked whether this issue is covered in the Portainer documentation or knowledge base.

Problem Description
While running the following bash script I don't get any response:
ADMIN=admin
PASS=$(az keyvault secret show --name portainerrootpassword --vault-name keyvault --query value -o tsv)
TEMPLATE="template"

JWT=$(curl -H 'Content-Type: application/json' -X POST --data '{"Username":"'$ADMIN'","Password":"'$PASS'"}' https://portainer.mydomain.com/api/auth | jq -r '.jwt')
echo Testing File POST
curl -H 'Content-Type: application/json' -H 'Authorization: Bearer '$JWT'' -X POST -F Title=mytemplate -F Note=template -F Platform=1 -F Type=2 -F Description=my_description_text -F<EMAIL_ADDRESS>'https://portainer.mydomain.com/api/custom_templates/file'
echo Testing String POST
curl -H 'Content-Type: application/json' -H 'Authorization: Bearer '$JWT'' -X POST --data '{"title":"mytemplate","description":"my_description_text","note":"template","fileContent":"'$TEMPLATE'","type":2,"platform":1}' 'https://portainer.mydomain.com/api/custom_templates/string'

No template is added to Portainer.
When adding the verbose flag on the last two curl command I get:
< HTTP/2 405
< content-length: 0

405 stands for Method Not Allowed. It appears that this API enpoints are broken somehow
Performing a GET to /custom_templates works accordingly with the JWT token retrieved.
Expected Behavior
The template gets added to the Portainer instance with either API endpoints.
Actual Behavior
Described above
Steps to Reproduce
Described above
Portainer logs or screenshots
No response
Portainer version
2.19.2
Portainer Edition
Community Edition (CE)
Platform and Version
Kubernetes 1.26.6
OS and Architecture
Linux
Browser
No response
What command did you use to deploy Portainer?
No response
Additional Information
No response

This is also happening to me on 2.19.3.  Note that the docs describe these methods, but I too am getting 405 on both:
https://app.swaggerhub.com/apis/portainer/portainer-ce/2.19.3#/custom_templates/CustomTemplateCreateString

@jb95x good news, I decided to check the source code and it leads directly to the answer:
https://github.com/portainer/portainer/blob/db46dc553f9957ebe8143d0ff3933f228b0f54fc/api/http/handler/customtemplates/handler.go#L34
The documentation is wrong, the correct paths are /custom_templates/create/file or /custom_templates/create/string etc.
This is still a bug, but it is a documentation bug.

@corydodt , thank you!
I still wasn't able to use the file one, it's complaining about the title being invalid. But the string one worked fine and is enough to achieve what I was trying to do.

Thanks for flagging this (and for the digging!) - I've opened an internal issue to get the Swagger docs updated.
Internal Ref: PCT-302

This should be resolved now with the 2.20 release.