Multi-container preview limitations incorrectly state that Managed Identities is not supported

Preview Limitations incorrectly state that managed identities is not supported. I believe both system and user managed identities can now be used to pull images from the azure container registry?

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

ID: 1d385179-7730-3b99-aff6-75491deb070a
Version Independent ID: 7da429ea-5421-9d99-3e7c-af1b3fee5ca8
Content: Configure a custom container - Azure App Service
Content Source: articles/app-service/configure-custom-container.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@stambunan Thank you for your feedback . We will investigate and update the thread .

stambunan, Managed Identity is still not supported on multi-container. However, it works on custom container (the one you indicated). This doc outlined the steps to the Pull image into App Service using a managed identity. Since there is no doc update on this, we will close this thread. Thanks again for your feedback.


Regarding Network Parameters

Hi, so i was building out an esrgan on my own and tried to keep it as faithful to the paper as possible. However, the thing is that the number of parameters is quite large(55M for 16 rrdb blocks) . I wanted to ask if what i was doing was right or is there some error, below i have attached my architecture for my rrdbnet
def rdb_block(model, kernal_size, filters, strides):

    gen = model
    model = Conv2D(filters = filters, kernel_size = kernal_size, strides = strides, padding = "same")(model)
    model = LeakyReLU(alpha = 0.2)(model)
    model = Concatenate()([gen, model])
    gen2 = model

    model = Conv2D(filters = filters, kernel_size = kernal_size, strides = strides, padding = "same")(model)
    model = LeakyReLU(alpha = 0.2)(model)
    model = Concatenate()([gen, gen2, model])
    gen3 = model

    model = Conv2D(filters = filters, kernel_size = kernal_size, strides = strides, padding = "same")(model)
    model = LeakyReLU(alpha = 0.2)(model)
    model = Concatenate()([gen, gen2,gen3, model])
    gen4 = model

    model = Conv2D(filters = filters, kernel_size = kernal_size, strides = strides, padding = "same")(model)
    model = LeakyReLU(alpha = 0.2)(model)
    model = Concatenate()([gen, gen2,gen3, gen4, model])

    model = Conv2D(filters = filters, kernel_size = kernal_size, strides = strides, padding = "same")(model)
    model = Lambda(lambda x: x*0.2)(model)
    return Add()([model, gen])

def rrdb_block(model, kernel_size, filters, strides):
    rdb1 = rdb_block(model, kernel_size, filters, strides)
    rdb2 = rdb_block(rdb1, kernel_size, filters, strides)
    rdb2 = rdb_block(rdb2, kernel_size, filters, strides)
    rdb2 = Lambda(lambda x: x*0.2)(rdb2)

    return Add()([rdb2, model])

def generator(self):
	    gen_input = Input(shape = self.input_shape)
	    model = Conv2D(filters = 64, kernel_size = 9, strides = 1, padding = "same")(gen_input)
	    gen_model = model
        # Using 16 Residual Blocks
	    for index in range(16):
	        model = rrdb_block(model, 3, 64, 1)

	    model = Conv2D(filters = 64, kernel_size = 3, strides = 1, padding = "same")(model)
	    model = add([gen_model, model])

	    # Using 2 UpSampling Blocks
	    for index in range(2):
	        model = up_sampling_block(model, 3, 256, 1)

	    model = Conv2D(filters = 3, kernel_size = 9, strides = 1, padding = "same")(model)

	    generator_model = Model(inputs = gen_input, outputs = model)

	    return generator_model

The total number of parameters should be around 16M.
The channels of Conv in RDB are not the same as those in ESRGAN implementation.
https://github.com/xinntao/ESRGAN/blob/b7c263b8c8f201a9123921d83dfe9bd73b38ec0c/RRDBNet_arch.py#L14-L23

Hey @xinntao correct me if I'm wrong but in pytorch conv2d the first argument is input channels while the second one is the output channels, while in keras the argument filter is only for output channels, which according to your code must be the same

Yes, your understanding of pytorch is right.
For the rdb_block, the output channel in pytorch code is gc=32, while in your code, the output channel is filters=64.

wow thanks the parameters are way down now and i can train it in the original configuration. Thanks :)


cookie based auth to preserve access to original db/docs so not lost, e.g. on gpt.h2o.ai

https://stackoverflow.com/questions/66836600/cookie-based-authentication-in-fastapi
https://www.gradio.app/guides/sharing-your-app#mounting-within-another-fastapi-app
https://github.com/gradio-app/gradio/issues/461

Or google auth
https://github.com/gradio-app/gradio/issues/2790

Where should this source code file be placed?

https://github.com/h2oai/h2ogpt/pull/618

Where should this source code file be placed?

this is a separate file, just make main.py or something similar

This issue was closed because we already support native gradio way with --auth related options.  See gen.py.


Check if a model has a connection to the outlet

This could probably done even before translating the model to code and thus save computational time
For this one would have to write a function that checks the status of the variables for the existens of the storages and the fluxes.
E.g.
If first_storage not present:
return ModelNotClosedError
if first storage has no connections
return ModelNotClosedError
and so forth

Use the recusrive algorithm from the fluxogram to go throught the model. If an outlet is included in the returned file, a connection exists. For this the model must run at least one day.

Settled for a mode construction that always has a connection to the outlet.


No support for show functions

https://gist.github.com/958125 has a function that adds this support.

show is now supported in last head. Thanks!


Should Molecule equality compare the exact bond order for aromatic bonds?

This snippet fails
file_path = get_data_filename('molecules/MiniDrugBank_tripos.mol2')
molecules = Molecule.from_file(file_path, exception_if_undefined_stereo=False)
molecule = [mol for mol in molecules if mol.name == 'DrugBank_2210'][0]

iupac = molecule.to_iupac()
molecule_copy = Molecule.from_iupac(iupac)
assert molecule.is_isomorphic(molecule_copy)

because the molecule has a benzene ring for which the two methods of creating the Molecule end up assigning the alternate bond orders 1 and 2 differently.
I'm thinking of changing our condition for an equal bond from
(x['bond_order'] == y['bond_order']) and
(x['is_aromatic'] == y['is_aromatic']) and
(x['stereochemistry'] == y['stereochemistry'])

to
((x['bond_order'] == y['bond_order']) or (x['is_aromatic'] == y['is_aromatic'])) and
(x['stereochemistry'] == y['stereochemistry'])

Are there cases in which this wouldn't do what we want?

I think this is a good idea. The only case I can think of where this would fail would be a really exotic molecule, like the one in the second response here: https://www.quora.com/Can-aromatic-compound-have-triple-bonds
Since I seriously doubt we'll run into anything like that, I think your proposed change is great..

Fixed in #209 .


show date of last successful run

the adapter should hold the date (date and time) of the last successful run. This info can be used on the visualization:
adapter.info.lastrun => String (00:00 1.1.1971)

https://github.com/baerengraben/ioBroker.swiss-weather-api/commit/9224b6253a4ec3b5fd6ddb6e252a03d4740a30cb


Script fails due to error

Hi! I've tried to use your script, but it fails for some reason. Can you take a look at error log below and fix it? @gryf

2017-08-05 14:39:20,567 INFO: Skipping message from `kotlyar' since it's empty
Traceback (most recent call last):
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 152, in _create_message
    filter(o.User.slackid == data['user']).one()
KeyError: 'user'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odmin/myenv/bin/slack-backup", line 10, in <module>
    command.main()
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/command.py", line 118, in main
    args.func(args)
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/command.py", line 39, in fetch_data
    slack.update()
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 53, in update
    self.update_history()
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 132, in update_history
    self._create_message(msg, channel)
  File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 155, in _create_message
    filter(o.User.slackid == data['comment']['user']).one()
KeyError: 'comment'

Looking at slack API docs, I see, that there could be messages without user defined at all - possibly messages generated by slack itself, or by bots with special messages types different than message. Funny, that I didn't bump on such messages, even I'm doing backups in weekly basis…
Anyway, I'll post patch soon, stay tuned.

@Legionivo, please, see if version 0.5 will resolve your issue.

@gryf
Hi! Now it fails with another error
2017-08-06 11:12:12,786 INFO: Update channel xorjobs' information in DB
2017-08-06 11:12:12,918 INFO: Fetching and storing messages in DB
2017-08-06 11:12:12,923 INFO: Getting messages for channel automation' Traceback (most recent call last):   File "/home/odmin/myenv/bin/slack-backup", line 10, in <module>     command.main()   File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/command.py", line 118, in main     args.func(args)   File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/command.py", line 39, in fetch_data     slack.update()   File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 53, in update     self.update_history()   File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 132, in update_history     self._create_message(msg, channel)   File "/home/odmin/myenv/lib/python3.5/site-packages/slack_backup/client.py", line 156, in _create_message     filter(o.User.slackid == data['user']).one()   File "/home/odmin/myenv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2820, in one     raise orm_exc.NoResultFound("No row was found for one()") sqlalchemy.orm.exc.NoResultFound: No row was found for one()

Do you have any users populated in the db? It's kind of strange, that you don't have particular user in a database, while you get the identifier within data returned from slack api… I'm afraid, that without the actual data I can't do much more.
You can add at line 150 of client.py lines, like below:
        import json
        logging.debug('Message data: %s', json.dumps(data))

and run fetch with additional -vv parameter to see which message is causing the error. If thre is an user field there (it will be an identifier, an alphannumeric value which is starting from capital u, for example U34P4DPHQ), and check if such user exists in your team (using an api test).

One of users was recently deactivated. Can it be the root cause?

If such user isn't listed in user.list call, than it's an issue on Slack API side, since there are no restriction in fetching user data in slack-backup code - all users are kept, regardless they are deleted or not. According to the Slack API docs, user.list method should return all users:

Lists all users in a Slack team.
This method returns a list of all users in the team. This includes deleted/deactivated users.

Could you please check, if deactivated user shows up using api test page? If not, than there are two ways to proceed:

Either you'll report defect on Slack somehow
I can add an workaround for such cases, with two possibilities:

slack-backup will ignore messages for unknown senders,
or there would be created some phantom account for all unknown users
or there would be separate phantom user for every each unknown users.

Although, I think it is an issue with your particular case, or general error with deleted/deactivated users on Slack side.

I have the same error as in the original post in this issue, with slack-backup 0.6 and python 3.4.
Traceback (most recent call last):
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/client.py", line 159, in _create_message
    filter(o.User.slackid == data['user']).one()
KeyError: 'user'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/bin/slack-backup", line 10, in <module>
    command.main()
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/command.py", line 141, in main
    args.func(args)
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/command.py", line 62, in fetch_data
    slack.update()
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/client.py", line 54, in update
    self.update_history()
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/client.py", line 133, in update_history
    self._create_message(msg, channel)
  File "/fh/fast/_ADM/SciComp/svcacct/envs/slack-backup/lib/python3.4/site-packages/slack_backup/client.py", line 162, in _create_message
    filter(o.User.slackid == data['comment']['user']).one()
KeyError: 'comment'

If this behaviour bothers you, @dtenenba , just make another issue and help me choose appropriate way for handle that. You can judge that by examining a message body, which should be displayed in the log (if your log level is low enough). I still didn't bump on such issue.


Refactor

So I've made some pretty major changes and figured I would submit them to see what others think:

simplify API to just be isSingleLine min and max
old perfectFit can be achieved by not sending a min or max value.
single line with show an ellipsis if wider than containing box
multiline will scroll if taller than containing box
move demos into a create-react-app project
add prettier for code formatting

(this also pulls in @tbroadley's changes)
closes #12

@chrisdrackett Nice! Just a comment: I wrote the bugfixes branch so that I could include my fork of react-textfit in a project directly from Github, rather than pulling the released version from NPM. I would suggest including just the changes from https://github.com/malte-wessel/react-textfit/pull/10, rather than all the changes from the bugfixes branch.

Unless this branch actually gets merged I'm doing the same :) that being said, I probably should separate the two.

Aha makes sense :)

Sorry guys, I don't want to change the whole API. Would be cool if each change would be a single PR.

@malte-wessel I want to understand your thinking on the API and the future of this project so I can decide how best to move forward with my work. My goals with this work was to update the API to solve some of my confusion and similar confusion coming from issues on this app. I'm pretty happy with what I came up with, but understand its a big change and might still need some work and improvement.
If there isn't a place for this new thinking in this project I'm happy to create a new project, but my work is similar enough (and uses just about all your code) that I feel like it is worth keeping it here if that is a possibility.
I'm happy to break what I did into smaller chunks and/or start a 2.0 branch, but I want to make sure that work in welcome before I put in the effort.
/cc @tbroadley

@chrisdrackett, @tbroadley, please note the updated code in master.
Small PRs implementing a small feature or a bug fix are very welcome.
For big features and bug fixes, you are encouraged to discuss them in issues before implementing, so that in case there are disagreements you won’t lose any effort.
Consider avoiding PRs that are about refactoring, or PRs that have a lot of unrelated changes all in one.


[website] Update React Engineer - xCharts Ashby link

Ashby role has been created so this is the correct link for this position

It may be a bit late but is it possible to just push this commit so it is applied to the website and not wait a week?


Place policies to sync in spoke clusters

What
As part of the Policy sync RFC implementation, a new field in the gateway class params has been added to configure policies to be synced to the spoke clusters, watches are dynamically created for the policies that are included in this field.
Currently the watch events do nothing, add the logic to place the policy using ManifestWorks among the spoke clusters
The placed policy is a copy of the original hub policy with the following changes:

The TargetRef of the policy is changed to reference the downstream Gateway
The kuadrant.io/policy-synced annotation is set
The kuadrant.io/origin-creation: <timestamp> annotation is set, propagating the timestamp of the hub policy

See Policy sync RFC for more details
Done

When configuring the gateway class params to include a policy (for example AuthPolicy), any newly created and updated AuthPolicies are placed in the spoke clusters
Include tests for this feature

This issue is stale because it has been open for 60 days with no activity.

This issue was closed because it has been inactive for 30 days since being marked as stale.


@onDismissed event of  is called twice

The action bound to @onDismissed event of <BsAlert> is called twice. Both if dismissed using the rendered button and if the property bound to @visible argument is set to false.
Reproduction

Create a new ember application and install latest version of Ember Bootstrap (v4.1.2).
Create this application template:<button {{on "click" this.hideAlert}}>
  hide
</button>

<BsAlert
  @onDismissed={{this.hideAlert}}
  @visible={{this.showAlert}}
>
  an alert
</BsAlert>

Create this application controller:import Controller from '@ember/controller';
import { action } from '@ember/object';
import { tracked } from '@glimmer/tracking';

export default class ApplicationController extends Controller {
  @tracked showAlert = true;

  @action
  hideAlert() {
    console.log('hideAlert');
    this.showAlert = false;
  }
}

I expected to see hideAlert console message only once if alert is dismissed. But it's shown twice in console.

Hi, @jelhan. I'm not familiar with the addon yet, but would like to see if I can help with this issue for Hacktoberfest. Can you assign the issue to me?

Sure. Thanks a lot for supporting us. Feel free to reach out to me if you have any question.

Thanks!

The reproduction in the initial post is wrong if using the external button to hide the alert and not the dismiss button rendered by the component itself.
The external button is using the same method as click event handler on the button ({{on "click" this.hideAlert}}) as well as on @onHidden={{this.hideAlert}} argument. In that case I would actually expect that hideAlert is called twice if the button clicked.
A simplified reproduction is this one:
<BsAlert
  @onDismissed={{this.onHidden}}
  @visible={{this.showAlert}}
>
  an alert
</BsAlert>

import Controller from '@ember/controller';
import { action } from '@ember/object';
import { tracked } from '@glimmer/tracking';

export default class ApplicationController extends Controller {
  @tracked showAlert = true;

  @action
  hideAlert() {
    console.log('hideAlert');
    this.showAlert = false;
  }
}

A click on the dismiss button causing the alert to be hidden, which executes the hideAlert method passed as @onDismissed argument. hideAlert method sets showAlert to false, which is passed to the alert as @visible argument. This causes the alert to be hidden again (even though it's already hidden), which executes the hideAlert method again. We have an endless loop.
The issue can be reproduced on master but is fixed by #1281.


interp2d function crashes python

I generate a "interp2d" function. I then try to pass in large pandas series objects and it crashes.   If I create a loop and ask this function one point at a time it works but it is slow.   Can someone help me get a fast method working?
Thanks,
--Liam
SciPyInterp2dCrash.zip

How does it crash? What is the error message?

CrashDebugError.docx
python.exe crashes and I click "Debug the program".   I attached the visual studio error messages and call stack.

Any ideas?  Has anyone been able to reproduce the crash I am seeing?

Yes, I can reproduce it. If I pass in the underlying arrays instead of the Pandas dataframes then I see this message:
_fitpack_impl.py:975: RuntimeWarning: No more knots can be added because the additional knot would
coincide with an old one. Probable cause: s too small or too large
a weight to an inaccurate data point. (fp>s)
	kx,ky=1,1 nx,ny=4,4 m=88 fp=643518.400213 s=0.000000
  warnings.warn(RuntimeWarning(_iermess2[ierm][0] + _mess))

If you could pare down the example to something that can be reasonably copy-pasted into a comment then it would make it easier for people to take a look.

I have the same problem.
Here is a minimal example:
import numpy as np
from scipy.interpolate import interp2d

# Example case: We have a 512 by 512 pixel image:
img = np.random.randn(512, 512)
grid_vec = np.linspace(1, 512, 512)
interp_fun = interp2d(grid_vec, grid_vec, img)

# Lets say we want to evaluate the pixel values in some new grid
# (simulated here as a 512 by 512 grid of random locations):
x_query = np.random.rand(512**2) * 512
y_query = np.random.rand(512**2) * 512

# This will crash python (hard crash, no error message):
img_interp = interp_fun(x_query, y_query)

This shouldn't even need that much memory. I use Matlab's interp2 function like that all the time. I'm wondering if I'm using scipy.interpolate.interp2d correctly here.

Can you add np.seed to your example, so that it's reproducible?

This last example calls interp2d(x_query, y_query) and tries to produce a 262144 x 262144 result. This would take 0.5 TB of memory, so probably this was not what was intended.

Similarly, the first example above tries to produce a 88372x88372 array as a result, which would take 62GB.
However, neither of these should crash, but raise a MemoryError instead.


[alert_handler/top] Top-level integration of LPG feature

This integrates the alert handler LPG concept into the top-level.
The mapping of resets / clocks to LPGs to alerts works as follows:

topgen determines the number of unique LPGs in the system (unique in this context means a unique combination of clock group, reset name and reset domain).
the clock gated / reset asserted indication signals from clkmgr and rstmgr are wired to the LPGs at the top-level (this also incurs a conversion from structs to arrays since the alert handler works on array signals).
the clock gated / reset asserted indication signals are then combined and synchronized to the alert handler clock within the alert handler
topgen provides a mapping from alert to LPG that is used inside the alert handler to index the correct combined indication signal for each alert

Note that this is dependent on several block-level changes (#8296, #8418, #8419) and needs a big rebase (some CI errors are due to pending DV alignments). Only the last two commits are actually relevant for this PR.

Alright, I have rebased this onto recent changes - PTAL.

Rebased and updated such that the LPG logic takes into account per-clock clock group assignments (if they are present).

Rebased onto recent changes on master.

sorry for being late on reviews, i'll have a one last closer look and let's
get it merged.
On Fri, Oct 1, 2021 at 7:59 PM Michael Schaffner @.***>
wrote:

@msfschaffner https://github.com/msfschaffner requested your review on:
#8369 https://github.com/lowRISC/opentitan/pull/8369
[alert_handler/top] Top-level integration of LPG feature.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/8369#event-5397510347, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSSBAFREXOGWTWT2A4LUEZYPLANCNFSM5EXEL2OQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

No worries!
Last push just rebased this onto the latest rstmgr changes.

Thanks for the reviews! Merging this now...


cargo build --release: cannot find macro asm in this scope

Expected behavior
Hello! When I clone this repo and run make create-synthetic-network and then make run-chrome, I would expect the latter command to build the Docker image and exit successfully per the README.
Describe the bug (unexpected behavior)
Instead, when I clone this repo and run make run-chrome the docker build (...) errors while running cargo build --release:

Click to expand a shell session of the build and error log

~/dev $ git clone https://github.com/daily-co/synthetic-network.git
Cloning into 'synthetic-network'...
remote: Enumerating objects: 1446, done.
remote: Counting objects: 100% (1446/1446), done.
remote: Compressing objects: 100% (1187/1187), done.
remote: Total 1446 (delta 215), reused 1445 (delta 215), pack-reused 0
Receiving objects: 100% (1446/1446), 4.77 MiB | 6.21 MiB/s, done.
Resolving deltas: 100% (215/215), done.

1s ~/dev $ cd synthetic-network/

0s (main) ~/dev/synthetic-network $ ls
CODE_OF_CONDUCT.md Dockerfile         Makefile           aarch64.nix        doc                run-in-vnc.sh      setup.sh
CONTRIBUTING.md    LICENSE            README.md          default.nix        frontend           rush               synth-chrome
0s (main) ~/dev/synthetic-network $ make create-synthetic-network
export SYNTHETIC_NETWORK=<IP_ADDRESS>/16
docker network create synthetic-network --subnet=<IP_ADDRESS>/16
a349f6a728c19feddf76a4af9f021d4b967d30aa5045d0ffcd5df6ebffe52cc3
7s (main) ~/dev/synthetic-network $ make run-chrome
docker build -t syntheticnet:vnc --build-arg VNC=true .
[+] Building 100.4s (14/17)
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.08kB                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/library/node:12.20.2                                                                                1.9s
 => [auth] library/node:pull token for registry-1.docker.io                                                                                0.0s
 => [internal] load build context                                                                                1.0s
 => => transferring context: 12.72MB                                                                                1.0s
 => [ 1/12] FROM docker.io/library/node:12.20.2@sha256:0140c4e17aa1f3fd78b939e3c7ac45accdd5274d0194046b484029a5e46b9db6                                                                             38.6s
 => => resolve docker.io/library/node:12.20.2@sha256:0140c4e17aa1f3fd78b939e3c7ac45accdd5274d0194046b484029a5e46b9db6                                                                                0.0s
 => => sha256:0140c4e17aa1f3fd78b939e3c7ac45accdd5274d0194046b484029a5e46b9db6 776B / 776B                                                                                0.0s
 => => sha256:2571706a0e9a90a55ea51746239ff8acd489e5c2ce2f119273245ccbc0a94392 2.21kB / 2.21kB                                                                                0.0s
 => => sha256:3aab5c2e02a68fcfa5e8c766e1689c6790580f0d51ee647ab67ea57b21fa6dc2 7.83kB / 7.83kB                                                                                0.0s
 => => sha256:296c9f0bf5f2cf24e87bc5abd674fc486e8df419d4aa2d362453f64d38900504 43.18MB / 43.18MB                                                                                10.1s
 => => sha256:84d546321c8e11789c75187b5b592633207519d75f96e8f03e8378d2da4a72a9 10.18MB / 10.18MB                                                                                3.9s
 => => sha256:f91c8ffe219846d18819503633eb252121c21cd20dbff74278b85c4029370992 4.10MB / 4.10MB                                                                                1.8s
 => => sha256:df8d698654f0ee6c5be4a19593a2d7a793c4bed9cb10de0c87d1d1c2ce6ba368 47.73MB / 47.73MB                                                                                11.2s
 => => sha256:eb8f7931e7aa1d31b83a8db251eb9107d989c9244f8bd7a542788aef3b6d1975 201.71MB / 201.71MB                                                                                32.0s
 => => sha256:6516b36f67a70cc6094778e92c2002789a89825b2769c9d5ce9f6427c5c813c2 4.20kB / 4.20kB                                                                                10.4s
 => => extracting sha256:296c9f0bf5f2cf24e87bc5abd674fc486e8df419d4aa2d362453f64d38900504                                                                                2.3s
 => => sha256:8592970063e59260afa874fb5f28a75d3e4742e7edaaafc1ba690c492e2039d4 23.70MB / 23.70MB                                                                                15.0s
 => => sha256:934b7a74b39bb36b47f580e3c33386d8edf20b9f9bc885442b1e78875d253ddf 2.38MB / 2.38MB                                                                                11.8s
 => => sha256:68a1166726ff6c90bb9e39a88d2245a71adb142bc16a8731e84ac31b4762ccbc 292B / 292B                                                                                12.1s
 => => extracting sha256:84d546321c8e11789c75187b5b592633207519d75f96e8f03e8378d2da4a72a9                                                                                0.7s
 => => extracting sha256:f91c8ffe219846d18819503633eb252121c21cd20dbff74278b85c4029370992                                                                                0.2s
 => => extracting sha256:df8d698654f0ee6c5be4a19593a2d7a793c4bed9cb10de0c87d1d1c2ce6ba368                                                                                3.1s
 => => extracting sha256:eb8f7931e7aa1d31b83a8db251eb9107d989c9244f8bd7a542788aef3b6d1975                                                                                5.2s
 => => extracting sha256:6516b36f67a70cc6094778e92c2002789a89825b2769c9d5ce9f6427c5c813c2                                                                                0.0s
 => => extracting sha256:8592970063e59260afa874fb5f28a75d3e4742e7edaaafc1ba690c492e2039d4                                                                                0.8s
 => => extracting sha256:934b7a74b39bb36b47f580e3c33386d8edf20b9f9bc885442b1e78875d253ddf                                                                                0.1s
 => => extracting sha256:68a1166726ff6c90bb9e39a88d2245a71adb142bc16a8731e84ac31b4762ccbc                                                                                0.0s
 => [ 2/12] RUN apt-get update && apt-get install -y     iproute2 ethtool iputils-ping iperf3 python3 lsof tcpdump net-tools                                                                         5.7s
 => [ 3/12] ADD run-in-vnc.sh /opt/lib/                                                                                0.0s
 => [ 4/12] RUN if [ -n "true" ] ; then apt-get install -y tigervnc-standalone-server ratpoison ; else echo "No VNC for you" ; fi                                                                   13.1s
 => [ 5/12] RUN apt-get install -y curl build-essential                                                                                1.9s
 => [ 6/12] RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs     | sh -s -- --default-toolchain nightly -y                                                                             26.2s
 => [ 7/12] ADD rush /opt/lib/rush                                                                                0.1s
 => [ 8/12] WORKDIR /opt/lib/rush                                                                                0.0s
 => ERROR [ 9/12] RUN cargo build --release                                                                                12.7s
------
 > [ 9/12] RUN cargo build --release:
#14 0.695    Compiling libc v0.2.68
#14 0.695    Compiling proc-macro2 v1.0.24
#14 0.695    Compiling unicode-xid v0.2.1
#14 0.695    Compiling syn v1.0.60
#14 0.695    Compiling getrandom v0.2.2
#14 0.697    Compiling cfg-if v1.0.0
#14 0.700    Compiling memchr v2.3.3
#14 0.845    Compiling serde_derive v1.0.123
#14 0.873    Compiling ryu v1.0.5
#14 1.092    Compiling serde v1.0.123
#14 1.125    Compiling signal-hook v0.3.6
#14 1.198    Compiling byteorder v1.3.4
#14 1.206    Compiling ppv-lite86 v0.2.10
#14 1.207    Compiling serde_json v1.0.62
#14 1.312    Compiling lazy_static v1.4.0
#14 1.337    Compiling regex-syntax v0.6.17
#14 1.403    Compiling itoa v0.4.7
#14 1.435    Compiling once_cell v1.3.1
#14 1.687    Compiling thread_local v1.0.1
#14 1.854    Compiling aho-corasick v0.7.10
#14 2.162    Compiling quote v1.0.9
#14 2.342    Compiling signal-hook-registry v1.3.0
#14 2.470    Compiling rand_core v0.6.2
#14 2.700    Compiling rand_chacha v0.3.0
#14 3.014    Compiling rand v0.8.3
#14 3.564    Compiling regex v1.3.6
#14 11.58    Compiling rush v0.1.0 (/opt/lib/rush)
#14 12.45 error: cannot find macro `asm` in this scope
#14 12.45    --> src/checksum.rs:151:5
#14 12.45     |
#14 12.45 151 |     asm!("
#14 12.45     |     ^^^
#14 12.45     |
#14 12.45     = note: consider importing one of these items:
#14 12.45             std::arch::asm
#14 12.45             core::arch::asm
#14 12.45
#14 12.61 error: could not compile `rush` due to previous error
------
executor failed running [/bin/sh -c cargo build --release]: exit code: 101
make: *** [image-vnc] Error 1

Steps to reproduce
$ git clone https://github.com/daily-co/synthetic-network.git
$ cd synthetic-network/
$ make run-chrome

Screenshots
System information
I am not familiar with Rust programming. I found this thread that seems surface-similar to the error I received, and so I thought perhaps it was an architecture-specific problem; I am running on arm64 on an M1 Mac. However I see the same error on an x86 Mac.
OS and arch for both systems:
# m1 mac, macOS Monterey 12.1
$ uname -a
Darwin MacBook-Pro.local 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 arm64
$ docker --version
Docker version 20.10.11, build dea9396

# x86 mac, macOS Monterey 12.0.1
$ uname -a
Darwin Jasons-MacBook-Pro-2.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64_x86_64
$ docker --version
Docker version 20.10.11, build dea9396

Hi @eugeneia and @vipyne - thanks for what appears to be a super useful project! I'm very new toRust programming and am not sure how to debug the build error. Could you point me in the right direction? Thanks!

Hi @jasonm , thanks for taking a look. What is the output of $ rustc -V and $ rustup -V ?

Hi @vipyne thanks for your message! I ended up opening https://github.com/daily-co/synthetic-network/pull/3 and included my notes below.
Versions of rustc and rustup
The cargo build command is executing as part of building a docker image per the Makefile/Dockerfile in this repo, so here's the version of rustc and rustup from the intermediate docker image layer immediately prior to the failing cargo build command:
~/dev/synthetic-network $ docker run -it --rm 04ca521c91d6 /bin/bash

root@4cb8abbf11ca:/opt/lib/rush# rustc -V
rustc 1.60.0-nightly (5e57faa78 2022-01-19)

root@4cb8abbf11ca:/opt/lib/rush# rustup -V
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.60.0-nightly (5e57faa78 2022-01-19)`

Here's the full docker build ... command that resulted in this image, so you can see where the 04ca521c91d6 came from.
Looks like the Dockerfile in this repo is always installing the latest nightly build of rust.
Namespacing the asm! macro
I spent a little more time reading the https://github.com/rust-lang/rust/issues/84019 thread I found earlier, and figured I'd try fiddling with the source to see if I could move things forward.
I namespaced the asm! macro  and voila! It built! Well, it complained with a warning, but that seems harmless:
Step 11/15 : RUN cargo build --release
 ---> Running in e28fc7c0a3ed
   Compiling libc v0.2.68
(...)
   Compiling rush v0.1.0 (/opt/lib/rush)
warning: the feature `asm` has been stable since 1.59.0 and no longer requires an attribute to enable
 --> src/main.rs:3:12
  |
3 | #![feature(asm)]
  |            ^^^
  |
  = note: `#[warn(stable_features)]` on by default

warning: `rush` (bin "rush") generated 1 warning
    Finished release [optimized] target(s) in 12.60s

De-feature-ing asm
Removing the feature line caused the compilation to succeed with no warnings.

Fixed with #3


Control amplify init profile via AWS_PROFILE and/or --profile

My problem
I am automating the creation of my Angular/Amplify project using Ansible. I am stuck on running amplify init in Ansible. Ansible does not provide a good way to navigate the amplify init menus. I have discovered that interactively, j works as the down arrow key, but I cannot get even j to work as input to Ansible expect.
For the most part, I am able to use the amplify init defaults, which requires no menu navigation using arrow keys.
The problem comes when I try to specify the Amplify administrator profile. The AWS CLI documentation says that AWS_PROFILE and --profile can be used to specify the profile. It would be nice if this worked for amplify init. To verify, I tried,
AWS_PROFILE=AmplifyAdministrator amplify init --profile=AmplifyAdministrator

but the default profile remains default:

Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project mediatekaiotcom
? Enter a name for the environment dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using angular
? Source Directory Path:  src
? Distribution Directory Path: dist
? Build Command:  npm run-script build
? Start Command: ng serve
Using default provider  awscloudformation
For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html
? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use (Use arrow keys)
AmplifyAdministrator
amplify-administrator
❯ default

Expected behavior
For the sake of automating Amplify setup, and for the sake of consistency, it would be nice if amplify used AWS_PROFILE and/or --profile.
Another workable alternative is to have an amplify init mode or configuration file that allows literal text input.
Desktop (please complete the following information):

Amplify: 4.18.1
OS: Ubuntu 18
Node Version: v12.16.2

Describe alternatives you've considered
As mentioned above, I discovered that j acts as the down arrow key, but in Ansible, jj does not have the desired effect.
Another approach I tried was to extract all the profile values using:
aws configure --profile AmplifyAdministrator get <parameterName>

Then I tell amplify init that I do not want to use a profile. However, I still need to use arrow keys to select the region.

Hello @jmcgeheeiv
You can run amplify init in headless mode.
Docs here: https://docs.amplify.aws/cli/usage/headless#amplify-init-parameters

Yes, I at last found those docs. Thank you.
I figured it out and wrote up how use Ansible to run amplify init.


Command "oauth2-server:migrations" is not defined.

There is no artisan oauth2-server:migrations command in 4.0.x@dev, the doc seems out-dated.

Thanks for pointing it out.

After php artisan vendor:publish, all migrations are now included in /database/migrations/*.
I have a separate database for OAuth, what is the recommended way to migrate only OAuth tables on it? Laravel 5 removed --package option from the migrate command.
My current solution is to move oauth-server related migrations to a separate directory, luckily, the --database and --path options of migrate command are still available. Do you have a better plan? @lucadegasperi

You should be able to specify the database connection to use on each migration as well. What I'm not sure is where the migrations table will be located in this case.


[app-configuration] only pack dist-esm/src

We should not pack files from samples-dev or test folders.  This PR limits them
to be those under dist-esm/src

Packages impacted by this PR
@azure/app-configuration

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

If we plan to move to .tshy soon then this is not needed.


Refreshing a layer

I have a raster source that is updated every five minutes, so I need to be able to refresh the tiles on the map. I tried mapController.requestRender() after the tiles had expired, but that didn't do anything. Is there currently any way to force a refresh of a layer?

Hi @brewin, right now there isn't an easy way to do what you're describing. requestRender() will re-draw the tiles that are already in memory, but it won't re-load the tiles from their source.
We'll consider this need in further revisions, but we might be able to find a work-around for now. Which platform are you using tangram with (Android, C++, iOS)?

Thanks @blair1618. I'm using the Android snapshot. A workaround would be great. I've made a custom HttpHandler to avoid caching the tiles, but I can't quite figure out how to get them to reload.

tangram-es is designed to minimize http requests so it's actually rather tricky to force tile data to reload, but there is a hack-y way: you can update the scene to remove and re-add the data source that you want to refresh. Here is how it would look using Mapzen's tiles:
mapController.queueSceneUpdate("sources", "{}");
mapController.applySceneUpdates(); // remove the source and its tile data
mapController.queueSceneUpdate("sources", "{ osm: { type: MVT, url: 'https://vector.mapzen.com/osm/all/{z}/{x}/{y}.mvt' } }");
mapController.applySceneUpdates(); // add the source again, retrieving tile data from the server

There may be an easier way to handle this in the future, but I hope that helps for now.

It would be cool to have a way to reload a specific source instead of all of them, but this seems to work well enough for now. Thanks for the help!

I agree, this is a reasonable/useful feature to add, we'll look into it.
On Mon, May 16, 2016 at 5:29 PM, brewin<EMAIL_ADDRESS>wrote:

It would be cool to have a way to reload a specific source instead of all
of them, but this seems to work well enough for now. Thanks for the help!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/tangrams/tangram-es/issues/731#issuecomment-219554158


more demos please

hello DelphiBuilder , and congrats to your very good project ,
i would like to ask you if you can give us more demos about for example chat communication between two selected  clients
lets say client one select client  two to chat with , how do you implement that .
thanks have a nice day

Ben, thanks for your kind words. NetCom7 is the distillation of work of many years. I wanted a piece of software that was very powerful and very easy to use anytime you wanted two or more computers to communicate.
There are many ways to do that. First, you client needs to know which is the other client that it needs to communicate with, let's say it knows its login name. So, when clients connect they need to also login like in the VideoChat demo. Next, you could invent a new command, which only targets specific clients. Now, there are no commands in the simple chat demo, all are tackled as command 0. You could leave command 0 to post to every client from the server and invent a new command, let's say command 1, to have the server post the data only for specific clients. When the client issues a "command 1", it also provides a list with the client login names the message should get to (you have to put into aData the list of clients along with the data itself). You can do that packing by using a simple TStringList and use its CommaText property to pack the list (on the client) and unpack it on the other side (the server). When Sever's OnHandleCommand, sees an aCmd of 1, it knows it should only post the data to the clients packed in the aData, so the loop should check if the client is in the list and only then send the data.
Hope this helps. I will extend at some point the demo, please bare with me as I have a small program to finish these days.

Thank a lot you for your replay ,i will try it as soon i can ,and good luck on your other project ,
waiting patiently on the next demo ,its will help me a lot ...Thanks again and take care


Make relative paths possible

in case someone has her local server set up in a way that /Hello-PWA is not the document root  (but e.g. /, so that one would access http://<IP_ADDRESS>/HelloPWA/index.html instead of just http://<IP_ADDRESS>/index.html ) this allows to run the PWA nevertheless, independent from the path: otherwise the manifest is looked up from the wrong URL, the service worker has the wrong URL and the start_url in the manifest is also incorrect.

PS: great tutorial, thanks


Update fonts CSS with smaller formats for Fira Sans

This brings down the size of the fonts dramatically on browsers that support the lighter-weight formats. The full font payload goes from approximately 3MB to less than 1MB.
This commit also removes redundant character class declarations, reducing the number of @font-face blocks. A few typos were fixed as well.

Typo fixed. I had accidentally removed the font-display: block; declarations, but those are back now.

@chriskrycho since you are who added this - could you take a look? thanks!

Ah, very nice – thank you for this pr, @msmorgan! I'm a big fan of going to woff/woff2 wherever possible.
A couple notes:

We definitely don't need anything but woff and woff2 – even IE9 had woff support! – so we should drop the .eot files
The character subsetting could in principle reduce the size loaded as well… if we split the font files apart. My guess is that Google Fonts was smart enough to be doing that; we definitely aren't doing anything that fancy, so I'm good with removing those here.
While we're at it, we should replace the existing .ttf files with .woff and .woff2 files.

@chriskrycho I copied the faces and styles directly from the Fira repository. It was last updated 3 years ago, and I suppose it was best practice at that time to use eot fonts. I'll go ahead and remove the eot fonts, as well as the ttf fonts for Fira Sans.
I looked online and could not find a woff or woff2 version of Alfa Slab One. I found some online conversion tools, but I'm not sure if the license of Alfa Slab One allows the conversion.

I found a tool (font-ranger) capable of splitting the fonts into separate versions for different Unicode ranges. I ran that on all the fonts, which had the side effect of converting Alfa Slab One to woff and woff2. I generated a new version of fonts.css using sass.

Outstanding! I will re-review in a bit and test locally as well, but thank you so much for doing that!

I think I'm done fiddling with this now. On the homepage the font payload is now less than 90kB.

@chriskrycho If you'd like, I can squash the first few commits so the unused fonts don't end up in the version history.

That would be great – a nice bit of savings of download bandwidth in its own way!

@chriskrycho I've cleaned up the commit history. This should be ready to merge.

Perfect! I'll verify/test myself and merge by the end of the day! Thank you again; this is really outstanding.


editable dependency causes wrong versions to be installed

Issue description
An error is not reported at the end of a pipenv sync command if an installed dependency violates a constraint / does not match the version specified in the lockfile.
An error is not reported at the end of creating a lockfile via pipenv install if an installed dependency violates a constraint specified in the Pipenv file / newly created lockfile.
Looks like an editable dependency is key to causing this issue.
May be related to https://github.com/pypa/pipenv/issues/3296
Note that there appears to be a datarace involved as SOMETIMES when I run pipenv install the versions that are installed match the generated/established lockfile and SOMETIMES they do not!
The test case I describe here will be able to repeat the issue consistently. It appears to happen whenever there is a dependency of an editable dependency that is loosely locked down ( > or >= or < or <= or * ) this rarely happens if at all when such a dependency is locked down exactly ( == )
Output from test:
STARTING TESTS

testing 'pipenv sync' operation; iteration = 1
Creating a virtualenv for this project…
Pipfile: /workspace/Pipfile
Using /usr/local/bin/python (3.7.5) to create virtualenv…
⠋ Creating virtual environment...Already using interpreter /usr/local/bin/python
Using base prefix '/usr/local'
New python executable in /workspace/.venv/bin/python
Installing setuptools, pip, wheel...
done.

✔ Successfully created virtual environment!
Virtualenv location: /workspace/.venv
Installing dependencies from Pipfile.lock (bfdd12)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 18/18 — 00:01:08
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
All dependencies are now up-to-date!

verifying...FAIL

the following python packages did not install correctly:
 amqp: expected 1.4.9 got 2.5.2 instead
 celery: expected 3.1.19 got 4.4.0 instead
 billiard: expected <IP_ADDRESS> got <IP_ADDRESS> instead

Expected result
I expect installed dependency versions to not violate constraints specified in the Pipenv file and I expect dependencies that are installed when running pipenv sync or pipenv install to match exactly the version specified in the lockfile - whether that lockfile be pre-existing or newly created.
If this does not happen, I expect an error to be reported.
( In addition, if the lockfile exists and I run pipenv sync I still expect the lockfile and Pipenv file to remain unchanged. Though there appears to be no issue around that combination of conditions I feel it should be enumerated. )
Actual result
Versions of dependencies that violate the top-most Pipenv file are installed when running pipenv install. Also they do not match the version stated in the newly created lockfile.
Versions of dependencies that do not match the lockfile are installed when running pipenv sync.
No error is thrown.
Steps to replicate
Made a couple of minor tests that express the problem:
On a linux friendly system with make:

clone https://github.com/bottom-text-everywhere/test-python-project

cd test-python-project

install docker

make test

View the README.md file in the project root for more details.
There are two tests: calling pipenv sync and calling pipenv install which creates a lockfile.

$ pipenv --support
Pipenv version: '2018.11.26'
Pipenv location: '/usr/local/lib/python3.7/site-packages/pipenv'
Python location: '/usr/local/bin/python'
Python installations found:

3.7.5: /usr/local/bin/python
3.7.5: /usr/local/bin/python3.7m
3.7.3: /usr/bin/python3.7m
3.7.3: /usr/bin/python3.7
2.7.16: /usr/bin/python2

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.7.5',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.9.184-linuxkit',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Tue Jul 2 22:58:16 UTC 2019',
 'python_full_version': '3.7.5',
 'python_version': '3.7',
 'sys_platform': 'linux'}

System environment variables:

PIPENV_VENV_IN_PROJECT
HOSTNAME
PYTHON_VERSION
DOCKER_SHELL_ACTIVE
PWD
HOME
LANG
GPG_KEY
TERM
SHLVL
PYTHON_PIP_VERSION
PYTHON_GET_PIP_SHA256
PYTHON_GET_PIP_URL
PATH
_
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_SHIMS_BASE_MODULE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

PIPENV_VENV_IN_PROJECT: 1

Debug–specific environment variables:

PATH: /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG: C.UTF-8
PWD: /workspace

Contents of Pipfile ('/workspace/Pipfile'):
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
requests = "==2.22.0"
anyjson = "==0.3.3"
Babel = "==2.2.0"
certifi = "==2019.6.16"
chardet = "==3.0.4"
idna = "==2.8"
pytz = "==2015.7"
tornado = "==4.2"
urllib3 = "==1.25.3"
vine = "==1.3.0"
flower = {editable = true,git = "https://github.com/mher/flower",ref = "f20f43c858df3c0a94e5e10015fcd7d52089e3f0"}
celery = "==3.1.19"
kombu = "==3.0.37"
amqp = "==1.4.9"
billiard = "==<IP_ADDRESS>"
importlib-metadata = "==1.1.0"
zipp = "==0.6.0"
more-itertools = "==8.0.2"

[requires]
python_version = "3.7"

Contents of Pipfile.lock ('/workspace/Pipfile.lock'):
{
    "_meta": {
        "hash": {
            "sha256": "5a05b2be1247f8f5df396dbe9a557d43c34516cb9b9c0ae3a3c2eb4b9fbfdd12"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.7"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "amqp": {
            "hashes": [
                "sha256:2dea4d16d073c902c3b89d9b96620fb6729ac0f7a923bbc777cb4ad827c0c61a",
                "sha256:e0ed0ce6b8ffe5690a2e856c7908dc557e0e605283d6885dd1361d79f2928908"
            ],
            "index": "pypi",
            "version": "==1.4.9"
        },
        "anyjson": {
            "hashes": [
                "sha256:37812d863c9ad3e35c0734c42e0bf0320ce8c3bed82cd20ad54cb34d158157ba"
            ],
            "index": "pypi",
            "version": "==0.3.3"
        },
        "babel": {
            "hashes": [
                "sha256:d8cb4c0e78148aee89560f9fe21587aa57739c975bb89ff66b1e842cc697428f",
                "sha256:fed07cbcdcb3de79b53a8220eebed21c93f8dbb3dbce1d9c6b1c4b09e8aecf2b"
            ],
            "index": "pypi",
            "version": "==2.2.0"
        },
        "billiard": {
            "hashes": [
                "sha256:204e75d390ef8f839c30a93b696bd842c3941916e15921745d05edc2a83868ab",
                "sha256:23cb71472712e96bff3e0d45763b7b8a99e5040385fffb96816028352c255682",
                "sha256:692a2a5a55ee39a42bcb7557930e2541da85df9ea81c6e24827f63b80cd39d0b",
                "sha256:82041dbaa62f7fde1464d7ab449978618a38b241b40c0d31dafabb36446635dc",
                "sha256:958fc9f8fd5cc9b936b2cb9d96f02aa5ec3613ba13ee7f089c77ff0bcc368fac",
                "sha256:c0cbe8d45ba8d8213ad68ef9a1881002a151569c9424d551634195a18c3a4160",
                "sha256:ccfe0419eb5e49f27ad35cf06e75360af903df6d576c66cb8073246d4e023e5c",
                "sha256:d4d2fed1a251ea58eed47b48db3778ebb92f5ff4407dc91869c6f41c3a9249d0"
            ],
            "index": "pypi",
            "version": "==<IP_ADDRESS>"
        },
        "celery": {
            "hashes": [
                "sha256:434b4e62308428b0e83fbcd1cebb8853beb230237b1b23484063fcf1ff610b6e",
                "sha256:bd6a21290c822ecf78947a7dbc8b2270d88a5fa08a7a2bfcd908bb3d5ed66b71"
            ],
            "index": "pypi",
            "version": "==3.1.19"
        },
        "certifi": {
            "hashes": [
                "sha256:046832c04d4e752f37383b628bc601a7ea7211496b4638f6514d0e5b9acc4939",
                "sha256:945e3ba63a0b9f577b1395204e13c3a231f9bc0223888be653286534e5873695"
            ],
            "index": "pypi",
            "version": "==2019.6.16"
        },
        "chardet": {
            "hashes": [
                "sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
                "sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
            ],
            "index": "pypi",
            "version": "==3.0.4"
        },
        "flower": {
            "editable": true,
            "git": "https://github.com/mher/flower",
            "ref": "f20f43c858df3c0a94e5e10015fcd7d52089e3f0"
        },
        "idna": {
            "hashes": [
                "sha256:c357b3f628cf53ae2c4c05627ecc484553142ca23264e593d327bcde5e9c3407",
                "sha256:ea8b7f6188e6fa117537c3df7da9fc686d485087abf6ac197f9c46432f7e4a3c"
            ],
            "index": "pypi",
            "version": "==2.8"
        },
        "importlib-metadata": {
            "hashes": [
                "sha256:b044f07694ef14a6683b097ba56bd081dbc7cdc7c7fe46011e499dfecc082f21",
                "sha256:e6ac600a142cf2db707b1998382cc7fc3b02befb7273876e01b8ad10b9652742"
            ],
            "index": "pypi",
            "version": "==1.1.0"
        },
        "kombu": {
            "hashes": [
                "sha256:7ceab743e3e974f3e5736082e8cc514c009e254e646d6167342e0e192aee81a6",
                "sha256:e064a00c66b4d1058cd2b0523fb8d98c82c18450244177b6c0f7913016642650"
            ],
            "index": "pypi",
            "version": "==3.0.37"
        },
        "more-itertools": {
            "hashes": [
                "sha256:b84b238cce0d9adad5ed87e745778d20a3f8487d0f0cb8b8a586816c7496458d",
                "sha256:c833ef592a0324bcc6a60e48440da07645063c453880c9477ceb22490aec1564"
            ],
            "index": "pypi",
            "version": "==8.0.2"
        },
        "pytz": {
            "hashes": [
                "sha256:3ede470d3d17ba3c07638dfa0d10452bc1b6e5ad326127a65ba77e6aaeb11bec",
                "sha256:8b6ce1c993909783bc96e0b4f34ea223bff7a4df2c90bdb9c4e0f1ac928689e3",
                "sha256:99266ef30a37e43932deec2b7ca73e83c8dbc3b9ff703ec73eca6b1dae6befea",
                "sha256:fbd26746772c24cb93c8b97cbdad5cb9e46c86bbdb1b9d8a743ee00e2fb1fc5d"
            ],
            "index": "pypi",
            "version": "==2015.7"
        },
        "requests": {
            "hashes": [
                "sha256:11e007a8a2aa0323f5a921e9e6a2d7e4e67d9877e85773fba9ba6419025cbeb4",
                "sha256:9cf5292fcd0f598c671cfc1e0d7d1a7f13bb8085e9a590f48c010551dc6c4b31"
            ],
            "index": "pypi",
            "version": "==2.22.0"
        },
        "tornado": {
            "hashes": [
                "sha256:e8b1207da67dbdceebfb291292b4ef1b547d6171525bec1b366853f923456a5f"
            ],
            "index": "pypi",
            "version": "==4.2"
        },
        "urllib3": {
            "hashes": [
                "sha256:b246607a25ac80bedac05c6f282e3cdaf3afb65420fd024ac94435cabe6e18d1",
                "sha256:dbe59173209418ae49d485b87d1681aefa36252ee85884c31346debd19463232"
            ],
            "index": "pypi",
            "version": "==1.25.3"
        },
        "vine": {
            "hashes": [
                "sha256:133ee6d7a9016f177ddeaf191c1f58421a1dcc6ee9a42c58b34bed40e1d2cd87",
                "sha256:ea4947cc56d1fd6f2095c8d543ee25dad966f78692528e68b4fada11ba3f98af"
            ],
            "index": "pypi",
            "version": "==1.3.0"
        },
        "zipp": {
            "hashes": [
                "sha256:3718b1cbcd963c7d4c5511a8240812904164b7f381b647143a89d3b98f9bcd8e",
                "sha256:f06903e9f1f43b12d371004b4ac7b06ab39a44adc747266928ae6debfa7b3335"
            ],
            "index": "pypi",
            "version": "==0.6.0"
        }
    },
    "develop": {}
}

ping

The solution to this (to avoid compatibility issues in the next release anyway) will be to set PIPENV_RESOLVE_VCS=1 while running pipenv. You can experiment with it for now by installing the prerelease via pip install --upgrade --pre pipenv.
Currently pipenv allows VCS dependencies to resolve on the fly unless they are installed in editable mode for legacy reasons. This will go away in the following release, assuming nothing catastrophic happens.
Sorry for the issue!

https://github.com/bottom-text-everywhere/test-python-project/blob/master/Dockerfile#L7
Adjusting from version "2018.11.26" to "2020.5.28" ended up installing the RIGHT versions of dependencies and the Pipfile.lock file has new sha256 entries.
diff --git a/Pipfile.lock b/Pipfile.lock
index c6d4e78..3022834 100644
--- a/Pipfile.lock
+++ b/Pipfile.lock
@@ -116,9 +116,18 @@
         },
         "pytz": {
             "hashes": [
+                "sha256:3abe6a6d3fc2fbbe4c60144211f45da2edbe3182a6f6511af6bbba0598b1f992",
+                "sha256:3cca0df08bd0ed98432390494ce3ded003f5e661aa460be7a734bffe35983605",
                 "sha256:3ede470d3d17ba3c07638dfa0d10452bc1b6e5ad326127a65ba77e6aaeb11bec",
+                "sha256:68c47964f7186eec306b13629627722b9079cd4447ed9e5ecaecd4eac84ca734",
+                "sha256:81af9aec4bc960a9a0127c488f18772dae4634689233f06f65443e7b11ebeb51",
                 "sha256:8b6ce1c993909783bc96e0b4f34ea223bff7a4df2c90bdb9c4e0f1ac928689e3",
+                "sha256:939ef9c1e1224d980405689a97ffcf7828c56d1517b31d73464356c1f2b7769e",
                 "sha256:99266ef30a37e43932deec2b7ca73e83c8dbc3b9ff703ec73eca6b1dae6befea",
+                "sha256:a77c52062c07eb7c7b30545dbc73e32995b7e117eea750317b5cb5c7a4618f14",
+                "sha256:dd5d3991950aae40a6c81de1578942e73d629808cefc51d12cd157980e6cfc18",
+                "sha256:e079b1dadc5c06246cc1bb6fe1b23a50b1d1173f2edd5104efd40bb73a28f406",
+                "sha256:ead4aefa7007249e05e51b01095719d5a8dd95760089f5730aac5698b1932918",
                 "sha256:fbd26746772c24cb93c8b97cbdad5cb9e46c86bbdb1b9d8a743ee00e2fb1fc5d"
             ],
             "index": "pypi",

Is there any unit test or feature that should be added to ensure that constraints/contracts enumerated by the Pipfile are verified at the end of installing/syncing/locking dependencies?
I can see this easily popping up again as people mix more flags into play ( note that adding PIPENV_RESOLVE_VCS=1 resulted in the same correct result with version 2020.5.28 ).
My first rule when writing software is: "Don't lie to the user"
As a user, if I tell a dependency management software to constrain package version I expect it to honor those constraints or report an error to me if something is not kosher.
I appreciate the feedback! Keep up the awesome work guys!

This was definitely a bug in version 2018.11.26
Please let me know if you have any issue repeating it because I can 100% of the time and will modify my test for any env you need to use.
I prefer linux ( and if I have to Mac ) - but I do all my real work in docker containers.

From a user experience perspective I think we all can agree that it's definitely a bug: you're working with a dependency solver and it's not solving the dependency graph.
From a tool maturity standpoint, it's a bunch of functionality that is honestly quite complicated and wasn't yet built as of the version you mentioned. From your perspective, you want to pin a version and have that take precedence no matter what -- for others, they want to install their (previously unresolveable) package and have it work.
Because the nature of that problem means we don't know what that package will install along with it, it becomes a race to see what gets installed first -- your pinned package might win, (i.e. be installed last), but if it isn't, we would have no way of knowing anything ever conflicted with it as pipenv is not actually performing the installation. This is not impossible per se -- but again, the validation required was not something that we had developed.
Hopefully that provides some insight about why things were the way they were -- far from perfect, for sure.

Please let me know if you have any issue repeating it because I can 100% of the time and will modify my test for any env you need to use.

The issue is pretty well understood -- we really just were not resolving these at all in some cases because there was no tooling built around that use case. Over the last ~1 year we have built the tools to handle this a lot more robustly, which is why you can expect better / more thorough resolution now

From your perspective, you want to pin a version and have that take precedence no matter what -- for others, they want to install their (previously unresolveable) package and have it work.

I actually have a much different request and perspective.
The Request:
Please verify the end virtualenv package version contents against the set of constraints discovered when traversing a dependency tree as a lockfile is constructed/updated and possibly when installing from a lockfile's metadata view.
Lets Get Technical:
I understand the intricacies of resolving a tree of dependencies where each subsequent dependency can introduce another tree. If when traversing the tree of dependencies where results will be stored in a flat-way, a set of version constraints are incompatible and no resolution path is viable, then an error should be reported. I also know this is further complicated by the shear number of paths over time that pop up where constraints enumerate a minimum version but fail to set a maximum version. I am sure you have a technique for addressing these concerns and I trust they work.
If I run pipenv sync I expect to get the very same virtualenv since it only reads from the lockfile if it exists and does not need to re-resolve the dependency tree. ( Even if in an edge case where I have stipulated a VCS dependency and failed to use an immutable version-ref a.k.a. did not use a gitsha things should be just fine. Other language package resolvers use sha256 checksums to detect things such as floating reference drift and throw errors when the downloaded files appear to differ from signatures defined in a lockfile. )
Fail loud, fail proud, fail fast; fix and move on. 👍
The perspective:
In my example, me enumerating the full set of dependencies and locking them to specific versions was a work around I chose to try. I was upgrading a project from pip to pipenv and wanted to make sure I kept all the same previously resolved dependency versions the same. Once I had a lockfile I would have gone back and made the versions in the Pipfile match the way they were declared in the legacy requirements.txt file. I was shocked to find that even when I attempted to lock the dependency to a specific version the resulting env DID NOT MATCH the explicit version I had stipulated. And that's my main issue I feel needs to be addressed in a more strict manner.
This issue was a breach of expectations.
This is especially bad when I see the lockfile says one version should be installed, but the reality is another version has made its way into the virtualenv that does not match the lockfile nor the Pipenv file. Pipenv can verify everything is khosher at least to the degree the various package authors and the root project importing packages stipulate, even if there are legacy concerns from the way pip worked in the past.
It was not a huge issue as we caught the subtly broken image had issues before it went live and a quick audit proved a version of a dependency was wrong. I was just happy that we could explain some wonky behavior we've seen with Pipenv finally and offer a repeatable test back to everyone.
I also can understand that this would seem pretty edgelord amongst the current community of users. Though I do have to wonder: How many are affected by this or will be affected eventually?

I would sleep much better at night knowing pipenv verifies that package versions are within the constraints discovered for the resolution path it chose. And I would sleep like a baby if I new for certain it honored the root project package constraints.
In my opinion, this is behavior that needs to be looked at closer and prevented.
I believed pipenv has two modalities:

pipenv sync which recreates a virtualenv exactly using the lockfile metadata
pipenv lock/install which creates/updates a lockfile and resolves a dependency tree

The first would be used in cicd, the second in daily efforts as I import new things. Please let me know if my understanding is incorrect. This is how other tools like yarn, npm, gem, crystal shards work so I hope this holds true here.
So far the latest version looks like it is miles ahead from the previous experience we had here!
Thanks for your time and all the hard work! 😄

Pipenv now feeds everything through the resolver -- I get that the previous behavior was not desirable, that's why we corrected it.
All I'm saying is, given the situation at the time, the options were to have the previous behavior (sometimes, a VCS or file-based dependency would override something that was otherwise pinned or resolved) or to use pip which clobbers everything without regard for your environment. The previous approach handles most cases, operating under the assumption that this is surely better than just clobbering anything.
Yes, the previous behavior couldn't fundamentally guarantee you a deterministic install if you didn't use editable dependencies.

In my example, me enumerating the full set of dependencies and locking them to specific versions was a work around I chose to try.

This didn't work because pipenv didn't pass PIP_NO_DEPS with dependencies that it thought might rely on unknown or unresolveable packages, e.g. VCS dependencies. Fundamentally, python dependencies which might require execution might also fail or fail to report some dependencies, e.g. for certain python versions or environments, so in some cases executing setup.py is the only way to verify that nothing is missed.
As a result, because this could happen in parallel, the VCS dependency will have its own dependencies installed at some arbitrary time -- and if done in serial, this happens as the last step. In old versions of pipenv, this is true even when using pipenv sync.
The latest versions of pipenv are able to resolve these dependencies and feed the constraints from the VCS dependencies into the initial constraint set of the resolver before resolution even begins.
To illustrate the difference, lets take a sample Pipfile:
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
colorama = "*"
requests = {git = "https://github.com/psf/requests.git", ref="5a1e738ea9c399c3f59977f2f98b083986d6037a"}
urllib3 = ">=1.25"

[requires]
python_version = "3.8"

Pipenv 2018.11.26

Pipenv 2020.6.2

In the second case, pipenv lock fails:
/t/test2  pipenv lock --dev
[...snipped]
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
 Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
  Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: Could not find a version that matches urllib3<1.25,>=1.21.1,>=1.25 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 5))
Tried: 0.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.7.1, 1.8, 1.8.2, 1.8.3, 1.9, 1.9.1, 1.10, 1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.11, 1.11, 1.12, 1.12, 1.13, 1.13, 1.13.1, 1.13.1, 1.14, 1.14, 1.15, 1.15, 1.15.1, 1.15.1, 1.16, 1.16, 1.17, 1.17, 1.18, 1.18, 1.18.1, 1.18.1, 1.19, 1.19, 1.19.1, 1.19.1, 1.20, 1.20, 1.21, 1.21, 1.21.1, 1.21.1, 1.22, 1.22, 1.23, 1.23, 1.24, 1.24, 1.24.1, 1.24.1, 1.24.2, 1.24.2, 1.24.3, 1.24.3, 1.25, 1.25, 1.25.1, 1.25.1, 1.25.2, 1.25.2, 1.25.3, 1.25.3, 1.25.4, 1.25.4, 1.25.5, 1.25.5, 1.25.6, 1.25.6, 1.25.7, 1.25.7, 1.25.8, 1.25.8, 1.25.9, 1.25.9
There are incompatible versions in the resolved dependencies:
  urllib3<1.25,>=1.21.1 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 5))
  urllib3>=1.25 (from -r /tmp/pipenvlsx1jhhhrequirements/pipenv-81b4tigh-constraints.txt (line 6))

This is expected because it's a fundamental shift in the design of how the resolver works.
Does this clear things up?

Absolutely, thank you for taking the time to go into such detail.
It looks like this would effectively surface the concerns of unresolvable constraint sets to the user and fail rather than break any constraint contract/expectation set by the user on any level of the dependency tree. Glad to see that it is now possible to resolve all dependencies in the tree before installing them.
Again, great work all!
💯

Because it is already fixed in 2020.6.2, I am closing it now.


Black screen flashes when hello world app launcher

This problem occurred when upgrading to the latest version of Flutter
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, v1.12.13+hotfix.5, on Microsoft Windows [Version 10.0.17134.885], locale zh-CN)
[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[√] Android Studio (version 3.5)
[√] IntelliJ IDEA Community Edition (version 2019.1)
[√] Connected device (2 available)
• No issues found!

Just add the following code to the MainActivity node in the manifest
 <meta-data
                android:name="io.flutter.embedding.android.SplashScreenDrawable"
                android:resource="@drawable/launch_background" />


fix: luis recognizer tests

There were a few issues with this test -

Throttle code sprinkled unnecessarily throughout
Inconsistent promise rejection/async/done handling
Code style issues

This commit cleans up all these issues and ensures that TestJson
failures are properly logged as test failures rather than unhandled
promise rejections.
(node:2921) UnhandledPromiseRejectionWarning: AssertionError [ERR_ASSERTION]:
Returned JSON
  /Users/runner/work/1/s/libraries/botbuilder-ai/tests/TestData/LuisRecognizer/SingleIntent_SimplyEntityTelemetry.json.new
!= expected JSON
  /Users/runner/work/1/s/libraries/botbuilder-ai/tests/TestData/LuisRecognizer/SingleIntent_SimplyEntityTelemetry.json
    at TestJson.recognizer.recognize.then.res (/Users/runner/work/1/s/libraries/botbuilder-ai/tests/luisRecognizer.test.js:179:13)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Note: the first commit on this branch just represents prettier changes. I would suggest using the commit range filter to just view the second commit.


[Docs] Build fails due to missing Ninja.

Describe the bug, including details regarding any error messages, version, and platform.
I built it on Ubuntu22.04 according to Building Arrow C++.
Then I get an error.
$ cmake .. --preset ninja-debug-minimal
Preset CMake variables:

  ARROW_BUILD_INTEGRATION="OFF"
  ARROW_BUILD_STATIC="OFF"
  ARROW_BUILD_TESTS="OFF"
  ARROW_EXTRA_ERROR_CONTEXT="ON"
  ARROW_WITH_RE2="OFF"
  ARROW_WITH_UTF8PROC="OFF"
  CMAKE_BUILD_TYPE="Debug"

-- Building using CMake version: 3.22.1
CMake Error: CMake was unable to find a build program corresponding to "Ninja".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "/home/xxx/arrow/cpp/build/CMakeFiles/CMakeOutput.log".

After installing ninja-build, I can build.
I propose to update the document.
diff --git a/docs/source/developers/cpp/building.rst b/docs/source/developers/cpp/building.rst
index 3b065aa40..ea7f08440 100644
--- a/docs/source/developers/cpp/building.rst
+++ b/docs/source/developers/cpp/building.rst
@@ -53,6 +53,7 @@ On Ubuntu/Debian you can install the requirements with:

    sudo apt-get install \
         build-essential \
+        ninja-build \
         cmake

 On Alpine Linux:

Component(s)
Documentation

Can you propose your diff as a PR.  It looks like a good addition to me.  You can (I think) click the "edit" icon on https://github.com/apache/arrow/blob/master/docs/source/developers/cpp/building.rst and create a PR that way.

Thank you for your comment.
I have opened #34040.


Unable to connect to chef-zero

System: Ubuntu1404
chef_config_file:
chef_server_url   'http://<IP_ADDRESS>:4000'
node_name         'bcr-node'
client_key        '/etc/chef/client.pem'
validation_key '/etc/chef/validator.pem'

Code snippet:
def self.set_up_server(chef_objects)
  require 'chef_zero/server'
  require 'ridley'
    @server = ChefZero::Server.new({host: ['<IP_ADDRESS>'], port: 4000})
    @server.start_background

    # create the chef server objects in the chef zero server
    fixture_dir = File.expand_path('..', File.dirname(__FILE__))

    puts "======#{fixture_dir}"
    chef_config_file = '/etc/chef/client.rb'

    puts "=====#{File.readlines('/etc/chef/client.rb')}"
    ridley = Ridley.from_chef_config(chef_config_file)

    chef_objects['environments'].each { |env| ridley.environment.create env }

    chef_objects['nodes'].each { |node| ridley.node.create node }

    puts "========#{@server.running?}"
  end

Error message:
ERROR: Connection refused connecting to http://<IP_ADDRESS>:4000/search/node?q=*:*&sort=X_CHEF_id_CHEF_X%20asc&start=0, retry 1/5

Thanks for filing a GitHub Issue.
At Chef, we use GitHub Issues to track bugs and feature requests. Questions like "How do I .... with Chef?" are better answered by our awesome community on the Chef mailing lists, or on StackOverflow. (Please pick only one place to ask your question, however, as it's considered impolite to post the same question to multiple forums.)
You can find information about joining and asking questions on our mailing lists here. On StackOverflow, please tag your question with the "chef" label so that it shows up in this list.
We will be closing your issue. Please get in touch with the community via the above mechanisms in order to find a solution to your problem.


Is it possible to write a geopackage file?

I am trying to generate a geopackage file based on multiple drawn features in a layer using OpenLayers 5 Draw class. Could you provide me any example or interesting class methods for such a task?
Thanks in advance

Yes. I don't have a simplified example right now, but the gist is to use OL's GeoJSON format and then call addGeoJSONFeatureToGeopackage(gpkg, geojson, tablename).
Not so simplified example from the worker we use here (the highlighted line and the three functions that follow): https://github.com/wallw-bits/opensphere-plugin-geopackage/blob/master/src/worker/gpkg.worker.js#L425


How to set background of sliding up panel  to transparent

I have tried to set    android:background="#00000000  in following code.
<com.sothree.slidinguppaneldemo.SlidingUpPanelLayout
    android:id="@+id/sliding_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="#00000000 >

or set the same code on the layout (for example, RelativeLayout) whitch is inner SlidingUpPanelLayout, but the background is still white.
How do I write the code to make background transparent?

@dominicthomas worked for me as well but I can see some black color behind!

You need to set umanoOverlay="true" to make sliding panel overlay main content.

@dominicthomas, also worked for me. Thanks. But how can we add umanoFadeColor to all the first child, because when we make sliding layout transparent, part of the first child is under the umanoFadeColor attribute, and some part is not.

@DinhPhucTran  thanks bro..i just stucked from 3 days to resolve that bug


Create NuGet package

Add .nuspec metainfo file for NewRelic.Platform.Sdk project.
You can create NuGet package and publish it to nuget.org using this manual.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


App isn't starting at startup!

Microsoft PowerToys version
0.78.0
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
The app was working properly, all of a sudden, I noticed today that it isn't starting at startup! I went to the settings and saw that the "run PowerToys at startup" option was off, then I set back on and left. But after I restarted my pc, it didn't start up, I checked again and I see that the option for startup is again off, then I turned on and left app and came back right after closing the app and still see that the option was off, the option for startup automatically turns off, which is why it doesn't run at startup.
Thank you for your support!!
✔ Expected Behavior
Run at startup option should have not automatically turn off!
❌ Actual Behavior
Run at startup option automatically turns off!
Other Software
No response

Is it possible that the older installation was done with user-scope, and the latest is machine-scope?

Hi there!We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here?  Then drag the zipfile from your desktop onto the GitHub comment box in this issue. Thanks!

nothing seems to appear if i press report bug!

Hi there!We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here?  Then drag the zipfile from your desktop onto the GitHub comment box in this issue. Thanks!

Uploading PowerToysReport_2024-02-22-16-50-55.zip…
Here you go!
Thank you!

Is it possible that the older installation was done with user-scope, and the latest is machine-scope?

Um sorry i didnt get you!

helloo!!?

Sorry for the mistake.
Here you go!
PowerToysReport_2024-03-05-17-54-06.zip

@SupBro5 from the bugreport it is not clear what is happening. Can you take these steps and report back:

Enabling "Run at startup" in PowerToys Settings
Exit PowerToys from the tray icon.
Launch PowerToys from Start Menu
Go to settings and check the status of "Run at startup"

I did the steps mentioned above. After I enabled and exited and launched again, I see that the option is disabled again!! It automatically disables, or maybe it shows that I will run at startup but can't make a change in its program I guess!!

@SupBro5 can you open Task Scheduler and open the PowerToys folder. Here is what mine looks like:

That is where PowerToys tells Windows to launch when the user logs on.

Same problem here, Task scheduler shows an Internal error happened messagebox, then it is empty. I am a windows insider stuck on Microsoft Windows [Version 10.0.26040.1000], so may have other problems, too.

@SupBro5 can you open Task Scheduler and open the PowerToys folder. Here is what mine looks like:

That is where PowerToys tells Windows to launch when the user logs on.

My PC says- Remote desktop not found.

@SupBro5 can you open Task Scheduler and open the PowerToys folder. Here is what mine looks like:

That is where PowerToys tells Windows to launch when the user logs on.

well in powertoys section...its empty!!! like there no file or anything...

hello??

@SupBro5 Please review this similar issue and see if you can add PowerToys to TaskScheduler. The issue may be you installed PowerToys as an admin user, then login as a different standard user which does not trigger launching PowerToys in Task Scheduler.
#31962
Let me know if this helps. /needinfo


Error running simpleaf quant within singularity container

Hello,
I'm trying to run simpleaf quant from within the singularity container on a Ubuntu server, and I get an error generating the permit list.
This is the last few lines of the captured standard output:
gpl:
command: /opt/conda/bin/time -v -o /workdir/quants/logdir/gpl.time alevin-fry generate-permit-list -u /workdir/.afhome/plist/10x_v3_permit.txt -d fw -i /workdir/quants/alevin_map -o /workdir/quants/gpl/ |& stdbuf -oL tr '\r' '\n' > /workdir/quants/logdir/gpl.log

This is the output of gpl.log:
thread 'main' panicked at 'assertion failed: `(left == right)`
 left: `16`,
right: `7`: found barcodes of different lenghts 16 and 7', libradicl/src/cellfilter.rs:203:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

However, I installed a local version of alevin-fry from the bioconda channel and was able to successfully step through the simpleaf_quant function in the simpleaf script from generating the permit list onwards, using the .rad files and splici index I generated from within the singularity container and the 10x_v3_permit.txt downloaded from the link in get_10x_permit_lists.sh.
My local version of alevin-fry is 0.4.1 and the version in the singularity container is 0.4.0.
Do you have any idea why I get an error using the singularity container?

Hi @HelenLindsay,
I am not sure why you might be seeing this issue.  It's a bit hard to say without the data (is that publicly available?).
Regardless, alevin-fry 0.4.0 and 0.4.1 are both quite old now, and it's certainly time that we update the docker image and singularity container (are you using the latest one?).  @DongzeHE and I will try to push out the update ASAP and ping back here when its done.
Best,
Rob

Hi @HelenLindsay,
Could you please pull down the latest docker container into singularity and see if the issue persists for you?
singularity pull docker://combinelab/usefulaf:latest

I should also note that we are in the process of moving away the assorted collection of scripts that constitute simpleaf as implemented here, and instead are moving to a dedicated and more capable workflow wrapper (https://github.com/COMBINE-lab/simpleaf).  We will also update the README here once there is also a container for that.

Hi @rob-p
Thanks for the info.  I think I was running the singularity container from the umd.box link here:
https://combine-lab.github.io/alevin-fry-tutorials/2021/quickstart-usefulaf-singularity/
I hadn't even thought to check the version as I only installed alevin-fry from bioconda yesterday, but there's evidently something wrong with my conda configuration.
I've pulled the latest docker into singularity and will run my analysis again and let you know once it's finished.

Yes, I get the same error using the latest singularity container.  Here's a subset of my fastq files, this is enough to generate the error on the Ubuntu server I'm using: fastq_subset.tar.gz
I'm happy if you want to close this issue as I've finished the quantification on my local machine and this version of the simpleaf pipeline will be retired.

Thanks so much for sharing the data. We will see if we can reproduce it on our end, and will post the result here either way to close the issue once we've looked at it.  I'm glad you were able to get everything to run locally.
In the mean time, I've been able to get a nice small docker (hence singularity) image wrapping the improved workflow tool simpleaf, and we will update the information and pointers in this repo once that is pushed.  Since you got things working locally natively, I don't want to mess with your workflow — but since you can install things via bioconda, you might want to check out simpleaf itself to simplify your processing (e.g. running fewer commands to get to your end point).
Thanks again for the report and all the feedback!

Thanks again @HelenLindsay! I've updated the readme on this repo to point to the relevant places, and we have again updated the latest Docker image to be based around the new and improved simpleaf wrapper.  The updated tutorial is here.  I'm guessing it will avoid the above error since building the splici reference no longer requires invoking any R code at all, so that the entire indexing and quantification process happens entirely in Python/C++/Rust.
Let us know if you have any more questions or run into any more issues!


fixing and expanding basic tests

ALL tests in test_condition and test_reversible_graph_net are now run on both cuda (only if available) and cpu
fixed graph_INN numerical jacobian (slogdetm instead of .det() causing inf)
removed bugs concerning model construction and call signatures from tests
fixed overly verbose output

Give me a ping once you are done. I'd love to review this so that I learn what happened in the latest commits. ;-)

@psteinb all tests are now passing at least (there were still plenty of things to fix).
I am considering merging this, and then taking more time sometime to add more tests, etc.