Allow processing datapackage

@zelima can you please provide details on pull requests explaining what problem the PR solves, etc.

@pwalsh updated PR description

@akariv @zelima can we pls make sure that we have tests for new code in this lib? it is relied on too widely for us to accept code that does not have tests.
https://github.com/okfn/coding-standards
S3 behaviour can be tested with https://github.com/spulec/moto

@zelima I think what you describe can be achieved by adding a custom processor before the dump processor which handles these adjustments
if I understand you correctly, your pipeline will look like this:
- run: load_resource
- run: convert_s3_urls
- run: dump.to_s3

I think this way is better because it provides greater clarity into what each pipeline is doing

@OriHoch This is not about dumping to S3 but loading a resource from a private S3. Eg: my datapackage,json might look like this
{
  name: my-datapackage
  resources: [
    name: my-resource
    path: data/data.csv
    schema: {...}
  ]
}

And that dp.json and resource are stored in my private bucket:

https://amazonaws.com/my.private.bucket/my-datapackage/datapackage.json
https://amazonaws.com/my.private.bucket/my-datapackage/data/data.csv

Now if I want to save data.csv locally I would  normally  run:
my-pipeline:
  -
    run: load_resource
    parameters:
      url: s3-signed-url-for(https://amazonaws.com/my.private.bucket/my-datapackage/datapackage.json)
  - run: stream_remote_resources
  - run: dump.to_path

But this will fail as when dpp will try to load https://amazonaws.com/my.private.bucket/my-datapackage/data/data.csv it will get 403 forbidden
This PR will allow me to add custom load_resource where I can use process_datapackage method to generate pre-signed url for resources first and after continue regular process, That will use that URLs to load resources (avoiding 403 forbidden)

@pwalsh This is the feature for only custom processors, that will inherit ResourceLoader and override the new method, that in the base class does nothing, but returning what it gets. That is tested since none of the previous tests is failing.
Do you want me to write a test case for a custom processor?

I see, ok then, LGTM

Can we merge this anytime soon if it's OK?


Feature: added loader for homepage [Fixes #18]

Feature: added loader for homepage [Fixes #18]
you can change the loader animation anytime.
checkout https://lottiefiles.com/ and paste the animation 'url' in code.
 <Player               autoplay               loop               speed={1}               src="https://assets1.lottiefiles.com/packages/lf20_p8bfn5to.json"               style={{ height: "200px", width: "200px" }}             ></Player>

Feature: added loader for homepage [Fixes #18]
you can change the loader animation anytime. checkout https://lottiefiles.com/ and paste the animation 'url' in code.  <Player autoplay loop speed={1} src="https://assets1.lottiefiles.com/packages/lf20_p8bfn5to.json" style={{ height: "200px", width: "200px" }} ></Player>

@najeebkp ok I like it your work ..

@najeebkp can also work on this issue...
See this issue


Make first letter of each driver for cluster/node drivers capitalized

Version: Master 2.2 (2/12/19)
What kind of request is this (question/bug/enhancement/feature request):
Enhancement
Details and Proposal:
Look at the Node drivers and Cluster drivers list. Notice that some do not have the first letter capitalized for nodes and under clusters they are all lowercase.
We'd like to override the first letter for each cluster/node driver always capitalized.

If not overridden with a specific name, which cloud.ca needs to be anyway.

Version: Master 2.2 (2/13/19)
Confirmed issue. Every Node and Cluster driver now has the first letter for each name capitalized.


2020

Codecov Report

Merging #488 into gatsby will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           gatsby     #488   +/-   ##
=======================================
  Coverage   95.71%   95.71%
=======================================
  Files          28       28
  Lines         140      140
  Branches        8        8
=======================================
  Hits          134      134
  Misses          6        6

Continue to review full report at Codecov.

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


Problems Chrome - Androïd and Windows 10

With Chrome 78.0.3904 under Android 6.0.1 and Windows 10, the drop-down list becomes inactive and stops the video

Hello confined people,
We have solved our problem. We had an error message: Unable to post message to http://youtube.com. Recipient has origin http://www.youtube.com.
We have added:
and it works perfectly.


corporate: Move functions for realm installation data to new file.

Moves two functions in corporate/lib/stripe.py that are used for the main analytics installation activity page to a separate file: corporate/lib/analytics.py.
Also, updates these functions for the possibility of realm being None for a Customer object.
Notes:

These two functions are only used for the installation activity page data.
A follow-up (or additional change to add to this PR) could be to combine these two functions so that only one database query is made. I'm pretty sure the CustomerPlan query could return the discount information as well as the projected annual revenue.
There is a corporate/lib/support.py file that only has one function currently, and I thought about moving these two functions there. But keeping the support and analytics logic (in the corporate helpers) separate seemed possibly a good idea for further refactoring.

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Merged, thanks @laurynmm!


Update genesis files

Over to you @WadeBarnes on whether/when to merge this given the errors that are presumably unrelated to the PR.

Test failures are unrelated to the changes in this PR.


Replaced "backport" of Gem.source_index / Gem::SourceIndex with Gem::Specification

Description
Because the former doesn't correctly load gems installed via :path or :git options in a Gemfile, meaning serving documentation for such gems via yard server -G throws silent errors (and spins infinitely in the UI).
The "backport" was introduced in https://github.com/lsegal/yard/commit/75e5aea51f149694269118ccd3ef6db09e7efc76 because RubyGems 1.8 removed SourceIndex and replaced it with Gem::Specification, but @lsegal didn't want to require YARD users to upgrade to Rubygems > 1.8. That was 5 years ago, and we should be able to move on now.
Completed Tasks

[x] I have read the Contributing Guide.
[x] The pull request is complete (implemented / written).
[x] Git commits have been cleaned up (squash WIP / revert commits).
[x] I wrote tests and ran bundle exec rake locally (if code is attached to PR).

The spec failure here was unrelated, fixed by https://github.com/bbatsov/rubocop/commit/3bcea86aec03114838492180713f03d45b2d42bd, and just needs an update to the installed gems on Travis. I figure they run a cache, so maybe we just have to wait.

Coverage decreased (-0.01%) to 93.508% when pulling c328575f36acf5e6ab81dda470d2fd8909c98db2 on benlangfeld:bugfix/serve-Gemfile-path-git-gem-docs into 1ff313492862f268647dfa66b21d8016f34c8db3 on lsegal:master.

This will technically be a breaking change. We could probably just toggle this based on the installed system RubyGems version.

This will technically be a breaking change.

Sure, but only for those using ancient RubyGems versions, of which you can guess my opinion. Point taken though.

We could probably just toggle this based on the installed system RubyGems version.

What version would you like to cut off at?

What version would you like to cut off at?

Well instead of cutting off, you can just do feature detection:
module YARD
  module GemIndex
    module_function
    def find_all_by_name(*args)
      if defined? Gem::Specification
        Gem::Specification.find_all_by_name(*args)
      else
        Gem.source_index.find_name(*args)
      end
    end
  end
end

Then just use YARD::GemIndex.find_all_by_name instead so there's less churn if we ever remove support for older RubyGems. And the backports/* would not need to be removed or touched.

Well instead of cutting off, you can just do feature detection

Of course I can. Sorry, long day. Will prep this tomorrow.

Coverage decreased (-0.02%) to 93.505% when pulling 300da8e6a01f143f1a4a3d2c23e1936bfa6b08b2 on benlangfeld:bugfix/serve-Gemfile-path-git-gem-docs into 1ff313492862f268647dfa66b21d8016f34c8db3 on lsegal:master.

Coverage decreased (-0.02%) to 93.505% when pulling 60f18267ba27a6a19599a9bf46265f09847bd171 on benlangfeld:bugfix/serve-Gemfile-path-git-gem-docs into 1ff313492862f268647dfa66b21d8016f34c8db3 on lsegal:master.

Updated as requested @lsegal. Anything else you'd like changing?

Coverage decreased (-0.02%) to 93.505% when pulling 6e09ea810b6062f5eea939724b3138236963f1d3 on benlangfeld:bugfix/serve-Gemfile-path-git-gem-docs into 1ff313492862f268647dfa66b21d8016f34c8db3 on lsegal:master.

If we get the changelog formatting right I can merge. Thanks for doing this!

Could you be more specific @lsegal? What is wrong with the changelog formatting?

Took a wild guess; hope that's what you were after :)

Coverage decreased (-0.02%) to 93.505% when pulling ceca9667f100d7917801cf7e73cc0083ac799c4f on benlangfeld:bugfix/serve-Gemfile-path-git-gem-docs into 1ff313492862f268647dfa66b21d8016f34c8db3 on lsegal:master.

LGTM!

Thanks for the PR, @benlangfeld!


Html.ActionLink loses the link when adding a bunch of html attributes

Title
Html.ActionLink loses the link when adding a bunch of html attributes
Functional impact
The '<a href' points to some garbage instead of the actual link
Minimal repro steps
On my index page, I had:
    You may sign up here using your credit card via PayPal:
    @Html.ActionLink("Signup Here", "Index", "Signup")

which worked properly
I changed it to:
    You may sign up here using your credit card via PayPal:
    @Html.ActionLink("Signup Here", "Index", "Signup", htmlAttributes: new
{ style = "font-size: x-large;  line-height: 1.33;color:black; background-color:yellow;  border-color: black; border-radius: 6px;" })

Expected result
Expect the page to have:
  You may sign up here using your credit card via PayPal:
    Signup Here

Actual result
The html link sent to the web page is:
  You may sign up here using your credit card via PayPal:
    Signup Here

Further technical details
Version installed: Microsoft Razor 3.2.3

When reporting an issue with ASP.NET MVC 5.2.3 / Razor 3.2.3, please do so at https://github.com/aspnet/aspnetwebstack/issues  This repo is for ASP.NET MVC Core.

FYI it appears your working code calls the following overload:
public static MvcHtmlString ActionLink(this HtmlHelper htmlHelper, string linkText, string actionName, string controllerName)
{
    // ...
}

while the broken code calls
public static MvcHtmlString ActionLink(this HtmlHelper htmlHelper, string linkText, string actionName, object routeValues, object htmlAttributes)

Update your code as follows and everything should work:
@Html.ActionLink(
    "Signup Here",
    "Index",
    "Signup",
    routeValues: null, // Need routeValues to provide htmlAttributes
    htmlAttributes: new { style = "font-size: x-large;  line-height: 1.33;color:black; background-color:yellow;  border-color: black; border-radius: 6px;" })

Sorry about putting this on the wrong forum.  Yes, I can see that there is an coding error. Thank you.


i2c_master handle NACK (IDFGH-12083)

Closes #13134
In summary, this PR:

Resolves a deadlock on s_i2c_synchronous_transaction failure
Handles NACK received on the slave address when using i2c_master_receive
Handles NACK received on the slave address and write bytes when using i2c_master_transmit and i2c_master_transmit_receive

TODO
i2c_master_probe reports incorrect NOT FOUND if previous transaction failed
I noticed that after dealing with an unexpected NACK (on slave address or write byte) on i2c_master_transmit, the i2c_master_probe function will report NOT_FOUND on an existing address. This is seems to be due to some missing cleanup or resetting of initial state when starting i2c_master_probe.
I was planning on continuing to develop this PR until the probe issue was resolved and was looking into writing tests. Since then, @mythbuster5 has voiced that they would add NACK checking in https://github.com/espressif/esp-idf/issues/13136#issuecomment-1933340595. Wanting to prevent duplication of effort, I'm not sure if I should continue further development on this PR.
I look forward to feedback, both on the current approach and if/how to continue.

 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.

Hi @MatthiasKunnen, thanks for writing up this PR!
I just tested this PR with the i2c async callback as follows, and it doesn't seem to work as expected.  First, this is how we tested without the PR applied:
Without the PR

Start querying an i2c RTC clock, it works.
Register an async i2c callback with i2c_master_register_event_callbacks
Unplug the clock from the i2c bus: the data returned becomes all 0xFF's, which is expected.
The callback from above never provides I2C_EVENT_NACK, it always claims I2C_EVENT_DONE.
Plug the i2c clock back into the bus (hot), and it continues to update: The 0xFF's return to proper time data.

With the PR
This is the same procedure with this PR applied:

Start querying an i2c RTC clock, it works.
Register an async i2c callback with i2c_master_register_event_callbacks
Unplug the clock from the i2c bus: the data returned becomes all 0x00's, which may be expected.
The callback from above never provides I2C_EVENT_NACK, it always claims I2C_EVENT_DONE.
Plug the i2c clock back into the bus (hot), and it no longer updates.
- N.B.: I know i2c hot-plug is not generally supported, but without this PR the i2c bus does recover from the disconnect/reconnect.

TL;DR
This PR doesn't fix NACK detection for async (I've not tested sync), and it introduces a hang when the bus is compromised.
Do you know what may have caused the hang, and how might the NACK detection be fixed for asynchronous requests?
This is our callback:
bool esp32_i2c_dev_callback(i2c_master_dev_handle_t i2c_dev, const i2c_master_event_data_t *evt_data, void *arg)
{
       // i2c_req_t is our own i2c request tracking structure.  For the purpose of this example,
       // its just a way of passing `evt_data->event` outside of the ISR:
       i2c_req_t *req = arg;

       req->esp_callback_event = evt_data->event;
       if (evt_data->event == I2C_EVENT_DONE)
               req->status = i2cTransferDone;
       else if (evt_data->event == I2C_EVENT_NACK) // <- never happens
               req->status = i2cTransferError;
       else
               req->status = -evt_data->event;

       return false;
}

Since I read that the async API was still experimental, I hadn't tested it before pausing development.
I'll have a look and see what can be done.

I'll have a look and see what can be done.

Sounds good.  Here is a simple test routine that implements both sync and async side-by-side if it helps you with testing:
https://github.com/KJ7LNW/esp32-i2c-test

I merged https://github.com/espressif/esp-idf/commit/016877b7ce184e8e8e0cdb037c230a887bc8a5dc, so this is gonna fixed. Thanks for your contribution, I will close this one.


watching open files for changes is broken after git pull

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

[x] Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
[x] Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
[x] Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
[x] Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
[x] Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
We have a deploy script that merges current feature branch into the integration branch then deploys that and checks out the feature branch again. I have noticed that after executing it the open files contents is reset to the state in the integration branch before the merge. Further investigation showed that it is actually a git pull of the integration branch that causes the problem.
I have created a minimal "model" of our script that demonstrates the problem on a toy repository: https://github.com/artm/test-atom
I think it has to do with the file operations that git pull performs when replacing files and would thus affect other scenarios where an external software uses the same operations. I don't know exactly which operations or why it is a problem.
Steps to Reproduce

fork the repository (the script executes a git push, so simply cloning is not enough)
clone the repository
git checkout feature
atom --safe README.md
edit and commit the README.md to the feature branch
./repro

Expected behavior: the README.md open in atom contains the changes from step 5
Actual behavior: README.md contains the version from deploy branch before merging the feature
Reproduces how often: 100%
Versions
You can get this information from copy and pasting the output of atom --version and apm --version from the command line. Also, please include the OS and what version of the OS you're running.
Ubuntu 18.04
$ atom --version
Atom    : 1.27.0
Electron: 1.7.11
Chrome  : 58.0.3029.110
Node    : 7.9.0

$ apm --version
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.27.0
python 2.7.15rc1
git 2.17.0

$ uname -a
Linux parurak 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Additional Information
This happens with any File System Watcher setting.
In most of my tests the problematic git pull actually had nothing to do and would report:
Already up to date.
Current branch deploy is up to date.

Nevertheless it would cause the problem and commenting it out would solve it.

@smashwilson do you have any ideas as to what could be the problem here?

For me this sounds like the return of #8888 . I stumbled upon this when two days ago I found an old version of my sources in the editor in contrast to a fresh git pull --rebase on disk. I didn't have the time to investigate deeper, but for short I did the following:
At home: atom / save / commit / git push leave atom window open
At work: git pull --rebase / open in atom / edit / commit / push
At home: git pull --rebase and it seems atom was not refreshing. Still had the old sources open, but on disk everything was latest & greatest as git log showed. Would I have saved, I would have overwritten my 'work' version.
There was no 'blue'  file-has-changed indicator and git-diffindicator bars showed a lot of changes ( which didn't make sense, since it were the changes I did at home the day before and not the changes I did at work as far as I remember. No screenshots, no proof 8-)
Stopping, restarting atom didn't do the trick, it still loaded the old version from some cache location. I planned to strace -e file it but for a first test I exited atom and opened it with the filename on the commandlilne supplied and then it loaded the current disk version. I didn't try to reproduce since I was fed up.
home: atom 1.26 on debian
work: atom 1.25 on LFS linux
sorry if I can't get into more detail.

@lee-dohm text-buffer is still using pathwatcher, so it isn't an atom/watcher bug (and changing the "file system watcher" setting won't help). This might be a failure to create a watch descriptor? I'm not sure offhand why that might happen, though, especially in such a specific scenario.

For reference, these lines are where we establish the watch on the buffer's file.

After consulting with @smashwilson , it looks like there are still a few steps to fix this bug. Mainly, get text-buffer to use @atom/watcher instead of node-pathwatcher; then verify that this fixes it, or at least see what the error is and address it in @atom/watcher.

still an issue on september 2019


Non-WSGI code does not work after sls function deploy -f name

I have service which has a WSGI application and some regular lambda functions.
The non-WSGI code api.py is this:
# https://github.com/logandk/serverless-wsgi/#automatic-requirement-packaging
import os
import sys
root = os.path.abspath(os.path.join(os.path.dirname(__file__)))
sys.path.insert(0, os.path.join(root, '.requirements'))

import xmltodict

def handler(event, context):
    return xmltodict.unparse({"foo": "BAR"})

serverless.yml:
functions:
  web:
    handler: wsgi.handler
    events:
      - http: ANY /
      - http: ANY {proxy+}

  api:
    handler: api.handler

custom:
  wsgi:
    app: app.app

requirements.txt
xmltodict

After a full deploy, the non-WSGI code is fine.
$ sls deploy -v
Serverless: Packaging Python WSGI handler...
Serverless: Packaging required Python packages...
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (2.06 MB)...
...
$ sls invoke -f api -l
"<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<foo>BAR</foo>"

However, after redeploying just the function, it fails.
$ sls deploy function -f api
Serverless: Packaging function: api...
Serverless: Excluding development dependencies...
Serverless: Uploading function: api (2.02 KB)...
Serverless: Successfully deployed function: api
$ sls invoke -f api -l
{
    "errorMessage": "Unable to import module 'api'"
}
--------------------------------------------------------------------
START RequestId: 94f3188a-9239-11e7-8d0e-01bfd0695980 Version: $LATEST
Unable to import module 'api': No module named 'xmltodict'

Notice how the sls deploy function only uploads 2.02KB.

Aside: having a service which has both WSGI and non-WSGI components is very useful to me. Use cases:

I want to bundle an API (directly called by lambda) together with the web interface for managing the API.
I want to standardise on serverless-wsgi and not have to use serverless-python-requirements as well
I might want to have a WSGI app which also contains handlers for other AWS events, e.g. S3 buckets

(so it would be nice to have first-class support for such functions, so that they don't need to add .requirements to the path themselves)

Note: redeploying just the WSGI function is fine.
$ sls deploy function -f web
Serverless: Packaging Python WSGI handler...
Serverless: Packaging required Python packages...
Serverless: Packaging function: web...
Serverless: Excluding development dependencies...
Serverless: Uploading function: web (2.06 MB)...
Serverless: Successfully deployed function: web

Indeed, we should be packaging the requirements for the non-WSGI function here as well

Thanks.
BTW I had a quick look how serverless-python-requirements avoids the need to put .requirements into sys.path. AFAICS, it seems to be simply that it puts all the requirements at the top level:
$ unzip -v .serverless/my-sql.zip
Archive:  .serverless/my-sql.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
      84  Defl:N       77   8% 1980-01-01 00:00 0163f8c9  env_dev.yml
     639  Defl:N      418  35% 1980-01-01 00:00 22eb0fcd  env_dev.yml~
     544  Defl:N      315  42% 1980-01-01 00:00 51ec2ddf  handler.py
      10  Defl:N       12 -20% 1980-01-01 00:00 d27f2d5e  PyMySQL-0.7.11.dist-info/DESCRIPTION.rst
       4  Defl:N        6 -50% 1980-01-01 00:00 c2971fc7  PyMySQL-0.7.11.dist-info/INSTALLER
     534  Defl:N      311  42% 1980-01-01 00:00 37a15918  handler.py~
     850  Defl:N      330  61% 1980-01-01 00:00 c27f473b  PyMySQL-0.7.11.dist-info/METADATA
    6278  Defl:N     2522  60% 1980-01-01 00:00 8c0e447f  PyMySQL-0.7.11.dist-info/RECORD
     935  Defl:N      429  54% 1980-01-01 00:00 a29c8b8a  PyMySQL-0.7.11.dist-info/metadata.json
       8  Defl:N       10 -25% 1980-01-01 00:00 f50e859b  PyMySQL-0.7.11.dist-info/top_level.txt
     110  Defl:N       95  14% 1980-01-01 00:00 1382dbab  PyMySQL-0.7.11.dist-info/WHEEL
    4516  Defl:N     1953  57% 1980-01-01 00:00 07a9d10f  pymysql/__init__.py
    5033  Defl:N     2810  44% 1980-01-01 00:00 fb588bea  pymysql/__pycache__/__init__.cpython-35.pyc
     668  Defl:N      436  35% 1980-01-01 00:00 01f3dc51  pymysql/__pycache__/_compat.cpython-35.pyc
    4440  Defl:N     2116  52% 1980-01-01 00:00 ab9efe58  pymysql/__pycache__/_socketio.cpytho
...

Yeah, I did consider doing that originally, however I went with a separate directory to avoid accidentally overwriting files in the project with any of the files from the requirements and to keep the deployment package organized. It would be nice to avoid having to add .requirements to sys.path, but I'm not convinced yet that just dumping everything in the root directory is a great approach.

Could it be done by setting PYTHONPATH environment variable?
(Even if that has to be explicitly set in serverless.yml, that's still probably better than changing the code)

Thanks for the suggestion. Since PYTHONPATH needs to be set before the Python interpreter is invoked, and Lambda is probably not invoking the interpreter on each request (in order to keep start-up times low), it may not work - but it's worth trying out.
Alternatively, we can extract the part of wsgi.py that sets sys.path into its own script, say wsgi_requirements.py which is bundled along with wsgi.py, and used by wsgi.py as well. For non-wsgi scripts, using the packaged requirements would simply be an import wsgi_requirements statement. It's still not completely transparent, but simpler.
I'll also reconsider the serverless-python-requirements approach of putting requirements in the package root, perhaps simply throwing an error if there are file name conflicts will suffice to avoid any unexpected behaviour.

PYTHONPATH=.requirements doesn't work here, but you can see why if I change my api.py:
def handler(event, context):
    import os, sys
    return {
      "PYTHONPATH":os.environ['PYTHONPATH'],
      "sys.path":sys.path,
    }

You get:
$ sls invoke -f api
{
    "PYTHONPATH": ".requirements",
    "sys.path": [
        "/var/task",
        "/var/runtime/awslambda",
        "/.requirements",
        "/var/lang/lib/python36.zip",
        "/var/lang/lib/python3.6",
        "/var/lang/lib/python3.6/lib-dynload",
        "/var/lang/lib/python3.6/site-packages"
    ]
}

I don't know why / is prepended, but it works properly if I set PYTHONPATH to /var/task/.requirements. Maybe that's a reasonable solution.

That's great, I was surprised to see that it did have an effect. The downside is that we'll need to hardcode a path that is implementation-specific to AWS lambda, it may (unlikely) change and will most likely be different on other providers. I think that putting packages in the root and checking that no files are overwritten may be the most reliable long-term solution.

The downside is that we'll need to hardcode a path that is implementation-specific to AWS lambda

True, or you could just document that the user should set PYTHONPATH=/var/task/.requirements (at least that's better than the current 4-line code change).

I think that putting packages in the root and checking that no files are overwritten may be the most reliable long-term solution

On balance, I think you're right.  Speaking as a user, it's helpful if this project and serverless-python-requirements can work in similar ways.

I found a problem with setting PYTHONPATH=/var/task/.requirements globally in a mixed WSGI/non-WSGI app, and my WSGI app tries to use the AWS-provided instance of boto3, it fails to load:
Unable to import module 'wsgi': No module named 'boto3'

It turns out that AWS sets PYTHONPATH=/var/runtime by default.  Setting PYTHONPATH=/var/runtime:/var/task/.requirements solves this.

Thanks for the feedback, I'm wondering how many of the other providers except for AWS that allow settings ENV vars and whether they'll also set them before starting the interpreter


Having trouble getting writable canned queries to work

Hey,
I'm trying to get canned inserts to work. I have an DB with following metadata:
sqlite> .mode line

sqlite> select name, sql from sqlite_master where name like '%search%';
 name = search
  sql = CREATE TABLE "search" ("id" INTEGER NOT NULL PRIMARY KEY, "name" VARCHAR(255) NOT NULL, "url" VARCHAR(255) NOT NULL)

# ...
queries:
    add_search:
        sql: insert into search(name, url) VALUES (:name, :url),
        write: true

which renders a form as expected, but when I submit the form I get incomplete input error.

but when submit post the form
I've attached a debugger to see where the error comes from, because incomplete input string doesn't appear in datasette codebase.
Inside datasette.database.Database.execute_write_fn
https://github.com/simonw/datasette/blob/4fa7cf68536628344356d3ef8c92c25c249067a0/datasette/database.py#L69
result = await reply_queue.async_q.get()

this line raises an exception.
That led me to believe I had something wrong with my SQL.
Turns out I had a sneaky comma , after sql key:
... (:name, :url),

which tells sqlite to expect another values(...) list.


source-serif-pro: 3.000 -> 4.004, source-sans-pro: 3.006 -> 3.046, source-code-pro: 2.030 -> 2.038

Motivation for this change
Things done

Built on platform(s)

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 142434 at 52b447d4 run on x86_64-linux 1

1 package failed to build:

source-sans

2 packages built successfully:

source-code-pro
source-serif

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.


[docs] Fix global styles leaking on different pages

As per emotoin's documentation, the cache should be re-created per request (see the note https://emotion.sh/docs/ssr#extractcritical). So far we've been reusing the same cache instance, which was leading to global styles leaking on different pages.
Preview: https://deploy-preview-25855--material-ui.netlify.app/components/grid/#interactive

There is a big flickering when opening the page this way :\ https://deploy-preview-25855--material-ui.netlify.app/components/grid/#main-content

@mnajdova The changes break the SSR output, on all the pages. I assume the extractCritical used on the server is overridden by the second RTL/LTR cache.

We will need to update the Next.js examples .

@oliviertassinari can you check now after https://github.com/mui-org/material-ui/pull/25855/commits/af27d29aa6250379fc15c9fc7b11775d2e6c5d3e, I remember that I was exporting cacheLtr so that I can reuse it in createEmotionServer, but I don't remember why.

@mnajdova The changes break the SSR output, on all the pages. I assume the extractCritical used on the server is overridden by the second RTL/LTR cache.

Yeah I noticed, not sure how to make both of them work at the same time. Looks like they are contradicting, or I am doing something wrong..

@mnajdova We could, for instance, only mount the RTL cache after the hydration.

@mnajdova We could, for instance, only mount the RTL cache after the hydration. In JSS I had to use a special prop to allow the nesting of multiple StyleProvider to work with SSR, for this very configuration.

Interesting, ok I'll try this tomorrow.

@oliviertassinari I believe everything should be fixed now. I was missing CacheProvider in _document.js. I've tested locally

RTL & LTR switching works
Page rendered with Disabled JavaScript works
styles are respecting the ssr style tags that we are creating

Let's wait for the prod build and verify and I think it should be good to go

👍 to @Andarist's comment, the cache is still global, it leaks: https://deploy-preview-25855--material-ui.netlify.app/components/grid/#interactive (Cell 1 is font-family Inter, our branding)

When I was cleaning up I reverted the changes for getCache 🤦

It's not working  is empty. See https://validator.w3.org/nu/?doc=https://deploy-preview-25855--material-ui.netlify.app/components/grid/#interactive
Adding cache.compat = true; will probably do it

It was broken with https://github.com/mui-org/material-ui/pull/25855/commits/2adb0fa98d4573c17e084b1d877586b224db3b47, once the global styles leaks were solved, this broke 😕
So basically I am at this:

new cache instance - solves leaks 👍  , breaks SSR 👎
global cache instance - introduces leaks 👎  , solves SSR 👍

I tried using cache.compat=true, but it didn't solve the issue.
Let me open additional PR that fixes the SSR and compare and see what are the changes and what we can do. I am running in circles now...

So on https://deploy-preview-25863--material-ui.netlify.app/ (PR https://github.com/mui-org/material-ui/pull/25863) ssr is fixed, but the leaking is still there

@mnajdova Please have a look at my latest commit. It seems to fly.

@mnajdova Please have a look at my latest commit. It seems to fly.

I could still repro the leaking:

Go on https://deploy-preview-25855--material-ui.netlify.app/branding/about/
Click Docs link
Visit Grid page

@oliviertassinari last try, I've tried to incorporate these changes together with the changes from https://github.com/emotion-js/emotion/pull/2334 in https://github.com/mui-org/material-ui/pull/25690
I think everything works over there, but I may be missing something (I can't trust myself on this one anymore):
https://deploy-preview-25690--material-ui.netlify.app/components/avatars/#main-content

The emotion's ssr style tag looks like contains the styles:

I could not spot the issue with the leaking

rtl works

@mnajdova Oh yes correct. This time, the leak is not on the server, but on the client-side. We end up with:

This looks like a different issue, isn't the same as #2158 where the old global theme isn't removed?

last try

@mnajdova We are good to go 👌

last try […] I think everything works over there

@mnajdova I corroborate 👌

Good! I started to lose my mind over this one 😄 I'd say let's merge this one, and after upgrading emotion, we can verify again that this  new scenario works.

@mnajdova IMHO these two issues are independent, happy with what ever order

Ok, I'll merge this one and rebase https://github.com/mui-org/material-ui/pull/25690

🎉


KlimaDao Infinity LandingPage

Description
This is the continuation of the work of @goatsOnDrugs from this PR: https://github.com/KlimaDAO/klimadao/pull/493
Despite of the set-up of the complete Inifnity page of the original PR from goats,
this PR contains fixes from this ticket https://github.com/KlimaDAO/klimadao/issues/540
DONE

[x] Link "Contact Sales" buttons to "https://notionforms.io/forms/klima-infinity-collab-request-form"
[x] First "Get Started" button scrolls down to section instead of going away to Blog "https://www.klimadao.finance/blog/klima-infinity-user-guide"
[x] All other "Get Started" buttons open blog link "https://www.klimadao.finance/blog/klima-infinity-user-guide"
[x] make all buttons tanslatable
[x] Open external links in new tab
[x] Fix links to Blog Pages
[x] Remove doubled cards
[x] Link LaunchIcon in cards to external URL
[x] Some text changes

TODOs

[x] ~Fix Card Slider (does not work)~=> re-build slider from scratch
[x] Fix Main Buttons in Hero are not clickable due to wrong z-index overlapping => replaced with css gradients
[x]  Card Link for MarkCuban (currently google.com)
[x] Card link for stadiusLogo (currently google.com)
[x] Blue Fade on top of page (see Figma design) => replaced with css gradients
[x] Open FAQ with click on Text too
[x] Fix Page Head meta data
[ ] Blurry images behind "Fast", "Affordable", "Transparent", "Accelerate your path"
[ ] Check Chrome on iPad ?

Preview Link
=> https://klimadao-site-git-lady-ki-lp-klimadao.vercel.app/infinity
🔥  NOTE:  NEW Translations are NOT WORKING on Preview Links 🔥
Related Ticket
Closes https://github.com/KlimaDAO/klimadao/issues/540
Closes https://github.com/KlimaDAO/klimadao/issues/446
Checklist

[x] Building the site with npm run build-site works without errors
[x] Building the app with npm run build-app works without errors
[x] I formatted JS and TS files with running npm run format-all

Ideally we wouldn't repeat cards like that for the retirements, I'll see if I can get some more

Yes please, we need more cards.

Awesome work, this landing page is looking beautiful!! Some observations on having a peek (chromium browser) 👁👅👁

[ ] Klima Infinity logo is low resolution (first section and by the footer). An svg version of the logo is available in through @klimadao/lib.

[ ] Similarly for the social proofs section. #538 adds these logos as svgs.

Frequently asked questions

[ ] Padding between question and answer looks too large
[ ] The '+' looks a bit small
[ ] The CTA button's height here doesn't align with the rest of the buttons

Polygon Section

[ ] Padding between content too far apart
[ ] Section styling doesn't match design. Don't think this is a show stopper though

[ ] Button height doesn't align with the rest of the buttons

Hi @0xAeterno
I refactored a few suggestions you made, but not all of it. Let's create dedicated tickets for further issues with this page. Otherwise we wait until inifinty until this gets merged.

[ ]  Similarly for the social proofs section. add social proofs section to home page #538 adds these logos as svgs.

Sure! But this is still an open PR. Let´s create a reusable Featured-Section later 👍 I'll create a ticket.

here is the ticket => https://github.com/KlimaDAO/klimadao/issues/554


Variables not being replaced in media queries declaration

http://is.gd/fEiLJ

Ah, looks like I stumbled upon the same bug.  My statement:
@import "desktop/nav";
This imports perfectly well OUTSIDE a media query, but vanishes with no error inside a media query.

I have a patch for this I am getting ready to submit. Haven't looked at the importing, just the variable replacement.

So, I messed up my pull request apparently. The patch for this is in this request: https://github.com/cloudhead/less.js/pull/481
Should have been in its own. It is the second commit. Can find the original commit on my branch here:
https://github.com/razialx/less.js/commit/1f97c2752c4bd38c0a00932a24c42e9c2ce60b46

Would be awesome to get this in the next release. And then it would be awesomer to have that release be today.

@razialx - Is there JS file that includes the parser changes?

Sure. Give me a moment to boot my laptop up
Sent from my iPhone
On Dec 5, 2011, at 5:30 PM, matthewdl
<EMAIL_ADDRESS>wrote:

@razialx - Is there JS file that includes the parser changes?

Reply to this email directly or view it on GitHub:
https://github.com/cloudhead/less.js/issues/122#issuecomment-3024596

@matthewdl Here you are: https://github.com/downloads/razialx/less.js/less-mediaquery-1.1.5.zip
The un-minified version has been tested. I just ran it through an online uglifyjs tool to minify it, so I haven'ted tested that at all.

Thanks! I've already incorporated it into the latest version of
Crunch. Http://crunchapp.net/ :-)
On 2011-12-05, at 2:51 PM, razialx
<EMAIL_ADDRESS>wrote:

@matthewdl Here you are: https://github.com/downloads/razialx/less.js/less-mediaquery-1.1.5.zip
The un-minified version has been tested. I just ran it through an online uglifyjs tool to minify it, so I haven'ted tested that at all.

Reply to this email directly or view it on GitHub:
https://github.com/cloudhead/less.js/issues/122#issuecomment-3024874

@matthewdl Oh, no, thank you. I have Crunch on my machine right now. This is a great example of when open source just works, heh.

Yep, creating or even contributing to open source (other than filing issues / asking questions) is something new for me, and it's been fun to see who gets involved. I'm sure if you were willing to figure out @imports inside @media querys, that would make bunches of people happy too! ;-)

Working on it. I have imports on the query line working in that it
imports but then it fails to parse. Example:
Style.less:
@media screen and (@import "Import.less"){...}
Import.less:
min-width: 1000px
Fails because the less parser tries to parse Import.less as a complete
legal less file. It isn't, only being a fragment. I would propose a
new token perhaps? @fragment "filename" but I would need to really
think about the impact and honestly it isn't my call at all. I would
need to discuss it with the less devs.
Sent from my iPhone
On Dec 6, 2011, at 9:52 AM, matthewdl
<EMAIL_ADDRESS>wrote:

Yep, creating or even contributing to open source (other than filing issues / asking questions) is something new for me, and it's been fun to see who gets involved. I'm sure if you were willing to figure out @imports inside @media querys, that would make bunches of people happy too! ;-)

Reply to this email directly or view it on GitHub:
https://github.com/cloudhead/less.js/issues/122#issuecomment-3033151

Hmmm..... I disagree with your example. I think it's perfectly valid for the parser to reject import.less, because otherwise I (or someone else) can't do something like build syntax checking into that particular file. So, while it make sense to, say, start a curly brace in style.less, and finish it in import.less (different from your example, but would still follow the model of a fragment) it's much harder to form an object tree.
Instead, what would seem the better case would be to import the file, and then call a mixin which outputs the min-width declaration.  That way, all my LESS files follow the spec, and everyone is happy.
I think if you put in the @fragment piece or importing of fragments, it probably won't be merged, but I couldn't say for sure. Maybe you can get @cloudhead 's thoughts here or on Twitter.
In the meantime, if you have a build that otherwise fully supports @import, I'd love to see it. :-)

@matthewdl
Could you post an example of what you would like to see with the import
statement then?
Are you looking for:
style.less:
@media screen and (min-width:1024px){
@import "import.less";
.page { ... }
.aside { ... }
}
import.less:
.header { ... }
? That is something I can definitely look at doing. The current problem is,
when a directive is found it scans until it gets an open curly brace, then
reads a 'block' and then a closing curly brace.
I changed it to tokenize the contents after the @media directive with a few
modifications elsewhere. To get the above example working I would need to
change the 'block' reading code to watch for imports, which should be easy
enough.
Tim
On Tue, Dec 6, 2011 at 10:22 AM, matthewdl <
<EMAIL_ADDRESS>
wrote:

Hmmm..... I disagree with your example. I think it's perfectly valid for
the parser to reject import.less, because otherwise I (or someone else)
can't do something like build syntax checking into that particular file.
So, while it make sense to, say, start a curly brace in style.less, and
finish it in import.less (different from your example, but would still
follow the model of a fragment) it's much harder to form an object tree.
Instead, what would seem the better case would be to import the file, and
then call a mixin which outputs the min-width declaration.  That way, all
my LESS files follow the spec, and everyone is happy.
I think if you put in the @fragment piece or importing of fragments, it
probably won't be merged, but I couldn't say for sure. Maybe you can get
@cloudhead 's thoughts here or on Twitter.
In the meantime, if you have a build that otherwise fully supports
@import, I'd love to see it. :-)

Reply to this email directly or view it on GitHub:
https://github.com/cloudhead/less.js/issues/122#issuecomment-3033514

--
Tim Reynolds

@matthewdl Ok, I have imports working inside of a media query. Was pretty simple, though I have no idea if there are further reaching implications of to this. Will make sure unit tests pass and commit it up shortly.

@matthewdl Here is an updated zip: https://github.com/downloads/razialx/less.js/less-mediaquery-import-1.1.5.zip
It was a one-line change.
In the code imports are only evaluated if the context is the root of the document. I added code to flag a media query block as a 'root.' This could of course cause problems, so use with caution. Unit tests do pass, however.
Tim

Awesome. I'll test it out today with my projects.

@razialx - Btw, to answer how I'd like to be using @import, there's an example of almost the exact scenario that I attempted yesterday. This blog post popped up today: http://alwaystwisted.com/post.php?s=2011-12-01-a-less-approach-to-mobile-first-css-supporting-older-ie-browsers
The first example (which wouldn't work except for your hotfix) would be the cleanest way to set up imports.

Just pushed a fix to this, it's in the master branch. Let me know if it solves the problems.
https://github.com/cloudhead/less.js/blob/master/test/less/media.less#L27

Is it @razialx 's fix?  It's currently working in Crunch.

Nope, different implementation.

Ah, okay, so just to clarify, this addresses variables inside of media queries, but does it address @imports inside of media queries?
Thanks so much, @cloudhead!

This addresses variables inside media and import queries, stuff like:
    @import screen and (max-width: @var);

Imports inside media queries is a separate issue, I'll work on that in a bit.

Hmm, how is that going to work for server-side compilers? Less imports are included / compiled immediately, and setting the import as a condition of max-width would only work in the browser, I guess? Which is perfectly valid for the project, I imagine, since that's the main target, but I'm just curious about that syntax what one would expect the LESS parser to do: wait to parse until it matches the media query? Or parse to a separate block of CSS that's still contained in a media query?  Would it be equivalent behavior to this?
@media screen and (max-width: @var) {
    @import "hello";
}

I would assume that it would do the latter; that is, output the compiled LESS in a preserved media block.

Indeed. Right now the import media-features are not very useful (only for css), but eventually, I want it to output a media directive like your example, if the imported file is a .less.


when returning the VM to a pool the info is not updated

VM still stays open. The page should close because VM is returned to the pool
main grid is not reloaded so the VM is still in the list - it shouldn't be.

I don't follow your first sentence 'vm stays open'. Can you describe more or post a screenshot?

you go to the VM detail view, hit shutdown, the VM should return to the pool and you shouldn't see it anymore.
Instead you should see the pool icon(same picture, but you know what i mean:) in the main grid

Note: This should be current behavior since pool redesign (#195, #990) has been merged.

C

Note: This should be current behavior since pool redesign (#195, #990) has been merged.
Right, closing this issue. The whole pools redesign was verified already.

Reopening this issue as it is still/again present in the UI. After the shutdown of the Pool VM, the VM does not return to the Pool and I can see its details page. It's present in the main grid, too, even after manual refresh (Refresh button up right). Only after F5, the correct list of the VMs is displayed.

Please note that this issue is NOT reproduced if userRole permission is set on the pool itself and not on an upper global level. So this issue seems to be related to this issue: https://github.com/oVirt/ovirt-web-ui/issues/1343.
Permissions inheritance somehow causes this.


Subtracting dates?

Is there a way to find the difference in weeks between two dates in this library? I implemented my own one-line method and would be happy to make a PR.

That would be a great addition. Go ahead and make it. Thanks in advance!

Closing this issue for inactivity.


psock_tcp_cansend: return EWOULDBLOCK when send buffer is full

Summary
with nonblocking sockets, POLLOUT is returned when the application calls poll even if the send buffer is full
Impact
Testing
Cortex-M55

@xiaoxiang781216 could you please point to me when we could expect libuv things fixed?

@xiaoxiang781216 could you please point to me when we could expect libuv things fixed?

@no1wudi could you finish in libuv upgrade in the weekend?

@xiaoxiang781216 could you please point to me when we could expect libuv things fixed?

@no1wudi could you finish in libuv upgrade in the weekend?

OK


Initial go at wagtail2

I had a bit of a go at wagtail2.
Haven't worked out how to get testing working so no idea if this works yet.

Code looks nice, but that Travis matrix failure is pretty weird indeed!

I tried so many combinations .... and couldn't work out how to do it.
Almost tempting to have an explicit entry for each combination ?

Sure, that'll work. Not too many combinations so far anyway, so go ahead :)

The nice folks at Travis pointed out the fix - case was wrong in the exclude rule.

Hey @akx any chance of merging this ?
I've been procrastinating on my sites feature that uses wagtail-svgmap, and if this is merged I'll have no excuse..

Looks good! I'll squash-merge these. Thank you for the work! :)

Awesome !   Right, I have no excuse now but to use this :D
Look forward to seeing it on pypi ;)


FluentCheckbox or FluentSwitch does not show correct first checked state in EditForm

🐛 Bug Report
The checked state does not show on first check when  FluentCheckbox or FluentSwitch is used in EditForm. Clicking on it 3 times will show the correct checked state.
💻 Repro or Code Sample
Counter.razor.txt
🤔 Expected Behavior
Show the correct checked state.
😯 Current Behavior
Not showing the correct checked state on first check.
💁 Possible Solution
Workaround: use checked and onchange instead of @bind-Value
<FluentCheckbox<EMAIL_ADDRESS>       @onchange="@(() => Content.IsChecked = !Content.IsChecked)">Check test</FluentCheckbox>
🔦 Context

🌍 Your Environment

OS & Device: Windows 10
Browser: Microsoft Edge, Google Chrome, Mozilla FireFox, Opera
.NET6.0 and Microsoft.Fast.Components.FluentUI Version 3.3

As far as I understand, you have in a blazor component, an editform which has as context the variable Content of type TestData, which to initiate it or to load it, in the cases in which you request the information and IsChecked returns true, the checkbox corresponding to that property, is not represented selected.
The code that you passed, as far as I understand, is a reference code and not the real case where your problem happens, so, I recommend you to check, if after loading the information in a possible OnInitializedAsync or OnAfterRenderAsync method, check that at the end you execute a StateHasChanged() or InvokeAsync(StateHasChanged).

Thanks for looking into this. I have tried copying the sample BasicFormFluentUIComponents.razor and Starship.cs and seeing the same issues. Testing this on the server side.

I am seeing this issue to (rendermode: ServerPrerendered).
Simply put:
<FluentSwitch @bind-Value="_value1" Label="Test Switch"></FluentSwitch>

@code {
  private bool _value1;
}

As long as the value of _value1 is false by default, setting it to true the first time using the switch won't be shown. I tested by adding some console logging - This shows setting the value is working, it is only not visually represented by the switch/checkbox control.
when using
@code {
  private bool _value1 = true;
}

the switch/checkbox components function as expected.
Hope this helps/


remove plot_example

I think this file is unused currently and we can remove the entire directory.

I think we might need this helper for extending the documentation with all those currently undocumented examples. So the script should be moved to examples not just deleted.


actions: bump node 20.9.0

Applied mkpr on .github/workflows/*.yml
sed s/20.8.1/20.9.0/

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.334%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1032

Relevant Lines:
1288

💛  - Coveralls


Feat: update profile account info sub type field

@moltar : I tried to update account info subtype but they still don't return.

@moltar : I've resolved the conflict. Please help me review them.

@nguyentoanit when can we merge this?


Add new count parameter:

update print_result function:

new parameters:

add new count parameter. It's number of sorted results. It can be useful for a large number of identical results. It's acceptable to use numbers with minus sign(-5 as example), then results will be from the end of results list
print_host - print host or not

It's a good idea, but my idea is much simpler. I just wanted to be able to limit the amount of output to the terminal without changing the terminal settings (scrollback settings), but at the same time see some results.
If there are errors on some hosts, then to avoid looking at the entire print_result output, for example, for 100 hosts, there is a new print_stat function that will show the task execution status for each host. You can combine print_result and print_stat for optimal output of results.
For example, output the last 5 results to see some results and view statistics for all 100 hosts.
I replaced all new functions to single PR with ipynb examples #21


Improve associated type ergonomics

While we have a shorthand notation Iterator<Item = MyType> for specifying an associated type, it's still more verbose than input types. It may be worth adding support for positional specification of associated types, so that Iterator<MyType> works. There are at least two difficulties/drawbacks:

This should be done in a way that still allows for new, defaulted input types to be added to a trait without breaking existing code.

This might make the order of items within a trait significant, which has no precedent elsewhere in the language.

It's possible for a design to avoid both pitfalls, but the complexity may not be worth it.

cc @Gankro @wycats

+1 this would be a huge boon. I see a couple paths forward:

Add a way to mark an associated type as "primary". In this way we would only support a single positional argument, which would cover 99% of the interesting traits

Add a way to mark an associated type with an explicit index. Supports multiple positional args, but more complex.

It's harder to read if you don't know the trait definition exactly, and it erases the syntactic difference between input and output type parameters.
@Gankro, you're suggesting introducing extra rules into the language, making it bigger arbitrarily just to be nicer in some cases. This is tempting, but it's bad overall in the long run to have more special cases.
I don't feel like I would gain anything from this, except having the old syntax in a world that doesn't work like that anymore.

@bluss

It's harder to read if you don't know the trait definition exactly, and it erases the syntactic difference between input and output type parameters.

This would only apply when bounding by the trait, not when defining or implementing it. As I said in the original issue text, the question of input/output is largely irrelevant when you are trying to specify bounds.

I don't feel like I would gain anything from this, except having the old syntax in a world that doesn't work like that anymore.

There's a somewhat widespread feeling that the use of associated types in traits like Iterator and Deref (each of which has exactly one assoc type) has made Rust more verbose without increasing clarity.
I'm not saying that this is a slam dunk change we should make, but something we ought to consider the tradeoffs for.

This would only apply when bounding by the trait, not when defining or implementing it. As I said in the original issue text, the question of input/output is largely irrelevant when you are trying to specify bounds.

I realize. I just don't think it's worth adding more special cases to be nice. More rules have a cost, but to us who know the language well it might not be apparent.

@bluss wrote: It's harder to read if you don't know the trait definition exactly, and it erases the syntactic difference between input and output type parameters.

@aturon wrote: This would only apply when bounding by the trait, not when defining or implementing it. As I said in the original issue text, the question of input/output is largely irrelevant when you are trying to specify bounds.

Think I agree with @bluss. There needs to be a distinction for clarity somehow. Aside from making it unclear what is happening in a specific line of code, having it where specifying an associated type looks like using a regular generic parameter does more to confuse the difference between the two from a design perspective for newcomers. In fact, I already wonder if associated types are being used in places where it doesn't necessarily make sense.
As far as input/output when specifying bounds, I'm not so sure it's irrelevant, although maybe I'm misunderstanding. Perhaps you can expand on what you mean. I've used bounds a number of times where I intended specifying the associated type to be interpreted as the output of the bound being equal to some other type. In fact there are some useful patterns that require this.

By the way, I think this could be done (eventually) just using default parameters and equality constraints:
trait Foo<X = Self::Out> {
    type Out where Out == X;
}

One could also use a helper trait to specify the type of Out to avoid Self::Out.

By the way, I think this could be done (eventually) just using default parameters and equality constraints:

Genius!

@darinmorrison

Think I agree with @bluss. There needs to be a distinction for clarity somehow. Aside from making it unclear what is happening in a specific line of code, having it where specifying an associated type looks like using a regular generic parameter does more to confuse the difference between the two from a design perspective for newcomers. In fact, I already wonder if associated types are being used in places where it doesn't necessarily make sense.

I do agree that this (as well as complexity) is a downside. My main point, though, is that the primary place clarity about the input/output distinction matters is with impl blocks, where it would remain clear.

As far as input/output when specifying bounds, I'm not so sure it's irrelevant, although maybe I'm misunderstanding. Perhaps you can expand on what you mean. I've used bounds a number of times where I intended specifying the associated type to be interpreted as the output of the bound being equal to some other type. In fact there are some useful patterns that require this.

So I'm saying that, if I write
foo<T>(t: T) where T: Foo<X, Output = Y>

the distinction between constraints on the inputs (the X parameter) and the outputs is not all that relevant; they're all just constraints on which impls are being considered for this function.
The input/output distinction, to my mind, is primarily about what impls you're allowed to write -- a different one for each set of inputs, with each set of inputs uniquely determining the outputs.

@aturon I think I understand your points better now, thanks for clarifying. I suppose that for the majority of the code the distinction is probably not that important. I believe there may be some exceptions but as long as it's just sugar it should be okay. I wouldn't mind a positional syntax, maybe something like prefixing those parameters with a - (for "output") or a -n:.

I find that the Iterator<Item=T> syntax is actually not needed very often at all, and I fear that making it easier to use will make some people use it like a normal bound. For example, I think that if associated types could be written like normal type parameters, people might accidentally right things like this (with a redundant type parameter):
pub struct Map<A, B, I, F> where I: Iterator<A>, F: FnMut(A) -> B {
    ...
}

Instead of this:
pub struct Map<B, I, F> where I: Iterator, F: FnMut(I::Item) -> B {
    ...
}

(This example is from std::iter::Map, but the reason the redundant type parameter exists is (I assume) only because it was not changed when Iterator transitioned to an associated type.) I’ve already seen this in a few libraries, and although they do have the excuse of the associated type transition being a recent change, it’s entirely possible that especially if we get a shorter syntax, redundancies like this will be even harder to spot and will go unnoticed for long periods of time.


Not Able to use the python extention

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

/needsMoreInfo


UnicodeEncodeError

Hi,
I run the extractor against a windows 7 ultimate system and encountered the following errors:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 125-128: ordinal not in range(128)
The registry and ntuser files are not extracted after I ran them. Not sure if you encountered the same issue as well. Just curious, if there are more then one partitions on the system (e.g. C, D and E), does the extractor extract the $J from these 3 partitions?
I hope this helps. Thank you.

Would appreciate if you could provide the full debug information that appear when you encounter the error, and the logfile (sanitize any sensitive information if necessary) created. Thanks.
No, it does not extract the $J from these 3 partitions, only the 1 you have selected.

logfile.txt
I have attached the debug information fyi. Do note that some data in the evidence of the windows 7 is in chinese.
Would be great if we could retrieve $J from multiple ntfs partitions.

Thanks for providing the files for me to debug. I suspect this error was due to the lack of support by logging for unicode characters. I have pushed out a fix in the development branch 5beebf3, but I don't have an image with unicode filenames to test, so please let me know if it fixes your error.
As for retrieving $J from multiple ntfs partitions, looking at your screenshot, you seem to have selected 3 partitions. Hence, the script should have extracted $J from all 3 selected partitions. Let me know if it doesn't.

No problem! I got the same error message with the updated new code.

For a temporary fix, comment out all logging.info lines. Will try to create an image with chinese characters to ensure that I fix this

Noted thank you. The script does not extract $J from multiple partitions, same for its $MFT.

I have fixed the unicode logging bug in 245bbb1, added support for multiple partitions in 245bbb1. Also, you can now select all the artifacts you wish to extract using the latest release executable.

Thank you so much! let me give it a shot and I will update you whether it works.

I just tested on the same evidence, the program and logging works. However, it does not loop through all partitions and retrieve the $J or $MFT from other partitions.

Did you select all the partitions when prompted?

Yup! I chose all partitions. Recycle bin files are not there as well.

For the other partitions besides C:, are they NTFS? Also, has it been verified that the recycle bin is not empty? If your answers to both questions are yes, would appreciate if you could provide me the commands you used to trigger the script, and send me the log file (with necessary desanitisation). Thanks.

Yes they are all NTFS. D drive does not have a $J but a $MFT file. E drive has both $MFT and $J file. All 3 partitions have files in the recycle bin.
The command I used is:
python artifact_extractor.py
Attached is the log file for your reference. Thank you for your help.
logfile.txt

As you did not specify the artifacts you want, the script defaults to the common artifacts it extracts (without MFT, USNJrnl, Recycle bin files). Please see python artifact_extractor.py -h to view how to use the optional argument -a to include those artifacts you want (or just use this: python artifact_extractor.py <image source> <destination> -a std,recycle,mft,usnjrnl)

Ah I see. Yup you using (python artifact_extractor.py   -a std,recycle,mft,usnjrnl) works!

Changed my account to this instead. Will update you if there are any issues.


no font and css generation

when running icon-font-generator, it logs "Generating font kit from 3 SVG icons" in the console but is not generating css or fonts at all.
this is my task config:
icon-font-generator src/icon-font/*svg -o public/assets/fonts/mesh-icons --html false --name mesh-icons --fontspath ../fonts/mesh-icons/ --csspath src/scss/settings/icon-font.scss --j false

Hi @SlimMarten, I've attempted to replicate your directory structure and run a test and it works fine for me (see screenshot) what environment are you running this from?

Running on Node v8.2.1.
I noticed that the problem only occurs if the svg contains svg shapes like . If I convert my shapes to  everything works fine.


Handle missing edits

This seems to have been exposed in https://github.com/dotnet/aspnetcore-tooling/commit/584aafdd321c34af17171806d9aff30b71b62b4c but the actual mistake here was introduced in my codeAction PR from way back. We named that function tryApplyingCodeActions but if you try calling it on an edit which doesn't apply it throws rather than returning undefined as one would expect.

Fixes https://github.com/aspnet/AspNetCore-ManualTests/issues/101.

Tests failed, but they appeared unrelated. Re-running.


Changed data is not displayed after saving inside WorkshopDetails

Was fixed using the DetailsHeader and DetailsBody component, which create a form


Consider flavors (Limited or Unlimited) to find directories

For #599, raiden-contracts needs to provide both limited and unlimited deployment data.  This PR computes the directory names for these flavors.  This changes the ABI.  See the diff of Changelog.

The code looks good... the tests have to be updated though

I changed so much, so I'm trying the deployment procedure once.

I can still deploy some contracts, and submit sources to Etherscan.


Add NADA implementation

This change adds the NADA congestion control implementation.
The binding to cc is left TODO.

@kevmo314 This is great, thanks for implementing it! Sorry I didn't get to review/test this earlier! I started #149 now to integrate it into interceptors and will try to find some time to review the code and understand NADA better.


Add support for .NET Core installs

Where's this at?

Where's this at?

Should be complete, however as mentioned I have been unable to get a proper test environment working, so this should definitely be checked before being merged.

I've tested:

without --Core in a non-core Celeste install, successfully compiled 👍
with --Core in a non-core Celeste install, does not compile, as expected 👍
without --Core in a core Celeste install, does not compile due to not setting up legacyRef (🤷 )
with --Core in a core Celeste install, successfully compiled 👍

Looks good :glumbsup:


Add endpoint to API to delete all images

This patch creates an endpoint to delete all images.
I ran into some issues with the order of tests and images needed by other tests being deleted, so I skipped the TestApiImagesDeleteAll test.
Fixes #10867
Signed-off-by: Peter Malmgren<EMAIL_ADDRESS>

Janky fails are related. Probably also need something more complicated, as with the current method, the order of images should matter for deletion. It would also be nice if this endpoint would have much better performance than regular docker images | xargs docker rmi, but for that I think this needs to happen in image.Store level.
Should this endpoint fail on an error(validate first) or do a best effort? If someone wants to use it for clearing the graph, it doesn't currently do that very well.

I think it might make the most sense to fail completely if all the images can't be deleted, and then ask the user to pass a force flag. This would also be consistent with the behavior of the other delete endpoint.

bulk remove is very dangerous, I'd rather not have this endpoint. If people want to remove all their images, they can do it with docker images -q | xargs docker rmi -f. Sorry, but this does NOT LGTM.

@calavera Yeah I got a bad feeling about it when it broke a bunch of other tests, and I recently had other problems when it would partially fail, leaving my Docker in kind of a weird state.


possible to override just the /home route with a custom controller?

I've created a custom view for my /products via a controller. (http://dev7.oddballsinvitations.net/products)
This page is generated from a BREAD table on the backend. How would I get this pages content to display on the frontend between the voyager-frontend views for the partial/header and partial footer?
Basically, I'm asking how to replace the voyager-pages /home page view with the controller generated /products page and route so that my /products content replaces the "this is the home page" here: http://dev7.oddballsinvitations.net

Hi @steveadamsfixedit, you could create a custom view for your controller that extends a voyager-frontend layout. e.g.
@extends('voyager-frontend::layouts.default')
@section('meta_title', '')
@section('meta_description', '')
@section('page_title', '')

@section('content')
    {{-- Your product code --}}
@endsection

And then override the index route to display it as your home page.
Route::get('/', 'ProductController@index');

You could also look into https://github.com/pvtl/voyager-page-blocks, which overrides the default voyager-frontend page editor and allows you to include custom controller methods on a page.

I managed to write the custom controller and resolve the issue. Many thanks for your help!


Fixed small typo in connectData.js comment.

I noticed this when I was writing some documentation for our own project based on your excellent boilerplate. Cheers!

Thanks! However, I believe we're not using this file anymore. I'm going to remove it


Note vscode remote limitation when client install fails

Just adding a note about the limitation referenced in https://github.com/rust-analyzer/rust-analyzer/issues/2522/
Considered checking if this message is relevant in the context (is this remote?) but decided against it because of return on investment - seeing how fast vscode iterates this limitation might just disappear in the near future.
Also checked if there is a way to already do this which lead me to leaving a specifing question at https://github.com/microsoft/vscode-remote-release/issues/385

bors r+


Unknown function when using the datapack method

I exported the zip to the world folder. I tried doing the command as displayed on many different versions, all said that its an unknown function. What's happening?

Is the issue related to #144? If not, please make sure the data pack is loaded properly by using /datapack list, and enable it with /datapack enable <name>.

I haven't played Minecraft in a while and forgot how these worked.
I put it in the wrong location. Oops, my mistake.


Pypi missing 1.0.4 release.

Long story short
Looks like the 1.0.4 release wasn't uploaded to pypi.  I'd prefer to stay in sync with pypi in the ebuild definition.
Expected behaviour
Release tarball is available via pypi.
Actual behaviour
Release tarball is not available via pypi.
Steps to reproduce
wget 'https://pypi.python.org/packages/source/a/aiohttp/aiohttp-1.0.4.tar.gz'
Your environment
aiohttp-1.0.4, Gentoo Linux, no proxy.

It was my bug as release manager.
There is no 1.0.4 release but there is a record for it and git tag.
Basically 1.0.3 and 1.0.4 are the same.
After merging #1297 I'll publish aiohttp==1.0.5

aiohttp 1.0.5 released


Broken Link to UserVoice Page

Under Shared Mailboxes:
Currently it's not possible to migrate a shared mailbox to a Microsoft 365 group. Is this something you want? Let us know. Vote here
The Vote here link goes to a link that no longer exist as Microsoft no longer uses UserVoice.

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

ID: 1a37b2d3-f63b-a719-565b-a46f2b1f2e96
Version Independent ID: e267656e-4bda-f03b-4d9c-d5149ec0a227
Content: Compare groups - Microsoft 365 admin
Content Source: microsoft-365/admin/create-groups/compare-groups.md
Service: o365-administration
GitHub Login: @MikePlumleyMSFT
Microsoft Alias: mikeplum

@msbemba Thank you very much for the contribution and updating the documentation with PR. @ITSourcePro Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Change "Do not hoard masks" to "Do not hoard surgical masks"

If you want to craveat that, then say don't hoard N95, FFP1, FFP2 or FFP3 masks.
Cloth masks should be encouraged for civilians. Ref https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2440799 as they do not deplete the masks that medical professionals use. That notwithstanding https://www.sacbee.com/news/coronavirus/article241330531.html and https://www.deaconess.com/How-to-make-a-Face-Mask

Alternatively, remove the whole section, since it is too vague and contains poor arguments.

Perhaps we can flip this to the proactive/positive.  Specifically things like,

If you are sick, wear a mask to prevent getting others sick
If you are high risk due to health status or profession/caretaker status.  Consider wearing an N95 style mask but be sure to get help to practice and train on how to use them.
etc...

@jaysonvirissimo  and @paul-hammant would you all be willing to draft something more concise and well-cited with primary sources?

I can draft something, but it won’t be until tomorrow night. Don’t wait for me if you can get to it before then @paul-hammant.

US health services group Deaconess Health Systems shares a mask design as part of their appeal for cloth masks (March 20):
PDF: https://www.deaconess.com/How-to-make-a-Face-Mask/Documents-Mask/Mask-Information Video: https://youtu.be/9tBg0Os5FWQ
US health services group Providence shares a cloth mask design video (March 21) - part of their "100 million mask" initiative:
Video: https://vimeo.com/399324367/13cd93f150

I stand by what I said - "do not hard surgical masks" https://github.com/flattenthecurve/guide/issues/203 is for pro-mask content.

As reqeuested https://github.com/flattenthecurve/guide/pull/204

And as @jaysonvirissimo said, much of that section just needs to go. Nobody on earth can remain associated with the "masks don't work messaging".

Just merged https://github.com/flattenthecurve/guide/pull/131 that removed the whole section. @paul-hammant I did see your PRs but since the section was going away I didn't want to act on those to avoid inconsistencies. Please feel free to open a new one with a new do/dont reflecting this conversation.

Section is still on the hosted site. Is there a delay on publication?  Netlift can use a GitHub WebHook to trigger build/deploys.

I think we can close this now that the offending section has been removed (although the idea of specifying the kind of mask we mean in various places would generally improve things).

agree


Stub generation

based on #18
removed weak attributes
generates operator stub source file for each type permutation to satisfy mac&win linkers

ok. mac ld seems to be happy. win ld is not. the problem with windows seems to be that the windows binary format does not support weak attributes at all.

I see these options regarding windows:

"drop" support

wsl is capable of executing linux binaries
cygwin injects its own dll that wraps syscalls
wsl is much better at doing this than cygwin will ever be

try mingw-w64

the old mingw itself also had problems with weak attributes

try other win c compilers

most of them are proprietary

replace weak attributes with preprocessor magic

maybe even Kconfig or sth similar?
not a fan of this one, because we would move a lot of complexity inside the build system
currently we can just omit sth while compiling and it's still a valid build (because stubs just take over)
with Kconfig we have a config dictating the the build process and if we forget to integrate it somewhere we get into trouble.

Some comments:

Do we really need the info folder? Why do we need to store the attribute names? Or input/output types? Or if its variadic? Where do you plan to use all this information? Some of this information is relevant (i.e. attribute names) but IMHO it doesn't need to be accessed programatically. Also n_attribute, n_input and n_output are redundant. I don't think we need all these files.
Regarding linking, weak attributes and so on. The whole point of this project is to have a runtime that is as simple as possible and that can be compiled in with every compiler. If we start to rely on compiler-dependant features that are not widely supported by all compilers, we are losing the purpose of the project. I'm not a huge fan of the following solution, but maybe we can just get rid of all the extern, weak and so on, and just have a normal function prototype. Then we generate also the implementations (files + functions) with some dummy content. Now, whenever someone wants to implement an operator they just have to replace the dummy implementation by the actual one. Continuing in #35.

Some comments:
* Do we really need the `info` folder? Why do we need to store the attribute names? Or input/output types? Or if its variadic? Where do you plan to use all this information? Some of this information is relevant (i.e. attribute names) but IMHO it doesn't need to be accessed programatically. Also `n_attribute`, `n_input` and `n_output` are redundant. I don't think we need all these files.

We do not need any of these while doing inference, they are just a byproduct of the generation and can be omitted while compiling or linking. The idea behind these informations was to provide extended debug functionality and compliance checks at runtime.
The n_* are not redundant since they refer to the maximum number of these objects.
I think the only redundant thing is the name.

* Regarding linking, weak attributes and so on. The whole point of this project is to have a runtime that is as simple as possible and that can be compiled in with every compiler. If we start to rely on compiler-dependant features that are not widely supported by all compilers, we are losing the purpose of the project. I'm not a huge fan of the following solution, but maybe we can just get rid of all the `extern`, `weak` and so on, and just have a normal function prototype. Then we generate also the implementations (files + functions) with some dummy content. Now, whenever someone wants to implement an operator they just have to replace the dummy implementation by the actual one. Continuing in #35.

Good compromise, will implement it.
I'm a little sad about the attribute stuff, but I concur.

We do not need any of these while doing inference, they are just a byproduct of the generation and can be omitted while compiling or linking. The idea behind these informations was to provide extended debug functionality and compliance checks at runtime.

Okay, thumbs up for debugging functionalities, doesn't harm.

The n_* are not redundant since they refer to the maximum number of these objects.

Right, I meant redundant in another way.

Good compromise, will implement it.
I'm a little sad about the attribute stuff, but I concur.

Perfect and yep, I feel you.

@alrevuelta
implemented #32.
seems to work

@nopeslide
Looks good to me. Just one comment. What are operator__onnx__add__7.c, operator__onnx__argmax__12.c,...? Do we expect to have something in these files or its just a bug? I mean, I expected to have operator__onnx__add__7__TENSORTYPE.c
In the future we can create one folder per operator so it looks less messy, but lets leave it for another patch.

@nopeslide
Looks good to me. Just one comment. What are operator__onnx__add__7.c, operator__onnx__argmax__12.c,...? Do we expect to have something in these files or its just a bug? I mean, I expected to have operator__onnx__add__7__TENSORTYPE.c
In the future we can create one folder per operator so it looks less messy, but lets leave it for another patch.

see #40

@alrevuelta
Any concerns regarding merging?

@nopeslide Go for it :D


.Net: Validate that Microsoft vector DBs work

Validate the following memory connectors
Microsoft solutions

Azure Cognitive Search
Cosmos DB for MongoDB
Redis (link to docs)
PostgreSQL (doc link)
Kusto (github repo)

Closing as this will be resolved with the new memory abstractions


marked profile description as required and set default for profile.ro…

…utingDisabled

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/490/
Test PASSed.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/445/


Upgrade spfx 1.6 FN002008 saves exact when it shouldn't

When upgrading a project from spfx 1.5.1 to 1.6.0 the report instructs the following command:
npm i<EMAIL_ADDRESS>--save-exact -D

However the default version specification for this package when scaffolding a net new project is ~5.0.0. I don't think this is a big problem, however if tomorrow 1.6.1 comes along and the cli implements the upgrade sequence as well, a project that was upgraded from 1.5.1 will trigger a finding for this rule.

Why do you think this is the case? The package you mentioned above wasn't present in v1.5.1, so when you update the project to v1.6.0 it will suggest running the command you mentioned. If v1.6.1 still requires<EMAIL_ADDRESS>then the rule will match the previously installed package and shouldn't yield a finding.

Thanks for the fast answer!
It makes sense, because the rule is only included in the version specific sequence, which is based on the version detected on the yo rc.
Allow me to correct my scenario:

Upgrade a project from 1.5.1 to 1.6.0
do no change the yo rc version
re-run the upgrade sequence to make sure you didn't forget anything.
this rule will trigger again because of the version specification difference

Let me check if I can repro it 👍

side note, if this needs fixing, that probably means that #572 needs the "inexact" arrays again.
Let me know how this goes, I'll update my PR accordingly.

I can't repro it. In my project I ran the upgrade from 1.5.1 to v1.6.0, ran the command as suggested by the CLI, and when I run upgrade again, the finding is not reported.

I'm still having the issue with the latest version that was just published.
Easier repro path.
Scaffold a spfx 1.6.0 project, edit the yo rc to 1.5.1 and run the upgrade command, you'll get the finding.
Technically you should not get any findings in this scenario.
Hope that helps.

So if I understand things properly the idea would be to make the version detection "more permissive" by considering ~5.0.0 or ^5.0.0 or 5.0.0 the same thing in the package.json? thus not triggering any finding.

Not quite: what we do at the moment, is to detect if the specified version or the range satisfy the requirement coming from a rule. If the exact version equals the upgrade requirement we don't yield a notification. If the upgrade range meets the requirement, we yield a notification with the exact version just to be sure that you have the particular version which might be higher than the minimal version of the range.

That however doesn't bring fidelity with what a net new SPFX project with the newer version would be if I'm understand things properly? If the new project comes with ~5.0.0 and the cli instructs -DE (so 5.0.0), it technically makes a difference. The SPFX team intended people to get updates for that dependency and now we're locking it down. Don't you think a project upgraded with the CLI should be exactly the same as if I created a new project and brought my custom files over?

By default, when you use npm, you're already getting a lock file, so even if you restore dependencies tomorrow, you will get the same version of each package as you installed initially. Without specifying the exact version to upgrade to, we couldn't update packages to newer versions if they're in the original version range, unless we manually rewrote package.json and instructed users to delete node_modules and their lock file, which could cause more trouble than installing a specific version of the package.

Yes, I'm aware of that :)
However omitting the ~ means npm outdated won't yield something and npm update won't do anything. That'll make it harder for projects maintainers to know if it's lock down because it absolutely has to be that version or just because the tool the use didn't make the proper recommendation, making it harder to stay up to date.

we could create a inexact dependency rule that instruct users to enter npm i<EMAIL_ADDRESS>-S, and then put back the different arrays I had in the part I was "compressing" the commands. I can take it on if you want.

How would this rule deal with a case where package.json says ~5.0.0 but the latest version is 5.0.1 which meets the rule and which wouldn't trigger the upgrade?

you're right it wouldn't solve the issue. Besides a save (which translates by a caret), a save exact (which translated by the exact version number) and a range (which saves the range) there doesn't seem to be a way anymore to save a tilde in the package.json even if you specify it in the command npm i<EMAIL_ADDRESS>I think the only way to have full fidelity would be to build some kind of grep/replace command line which would replace the version spec in the package.json to exactly what's it's supposed to be in a new project. And then instruct a general npm install. I'm not super happy about that solution. Any other idea?

With that approach, we'd also need to remove the lockfile, which would otherwise prevent parsing  package.json. Given the trade-offs I'd say, let's not do it for now, even if it means that your project file is a bit different than if you created a new project.

If you look back at the previous versions of SPFx, the same applied to the core packages as well. And it might get hard to get it fool-proof for a case like, in<EMAIL_ADDRESS>all core packages were referenced by ~1.4.0. Back then, when you created the project, you'd get 1.4.0. If you installed the same project today, you'd get 1.4.1, which would give you a different project than what you'd get originally and that potentially might even not work.

One could argue that if they properly followed semver, a patch bump should not contain any breaking change. But I don't want to digress.
I think we can assume that most open source packages properly implement semver and a patch or minor bump should not be an issue. We should also be able to assume that if Microsoft didn't lock down that specific package, they trust that minor changes to it should not have a major impact to the broader SPFX.
Now to wrap things up for this discussion, we established that implementing any automatic control would be complex/costly at runtime. So I think our options are to either leave it as is or add some kind of message to let the user know that some manual change could be involved and that they are free to follow this guidance or not.
What do you think?

Let's skip it for now. Let's keep an eye out on future updates. If we ever stumble upon any problems, we can reiterate this discussion and see what the best approach would be.

thanks for taking the time to discuss this item. closing for now


Add test cases for delete.py

Build is failing https://app.travis-ci.com/github/sak007/MyDollarBot/builds/240895751
Don't hardcode path

Updated the Styling issues and Style Checkers - 134544d20b15bc493ee7d5703259fce1d3bf7e18
Build passing and test cases updated for delete.py and history.py
Please verify the close the issue if there are no more errors. @sak007 @sak1997


Image Isn't rendering

When image link is presented in html, renderer just ignoring it.
HTML:

Also tried base64 string.

Tried directly from wkhtmltopdf and seeing the same problem. So issue is not in pydf.
@samuelcolvin But if you know what I'm doing wrong, let me know please :slightly_smiling_face:

Problem is probably because you have the file on disk eg. file://.
Try putting the file at a real url (or localhost:<port> by running a server locally) and see what happens.

Problem is probably because you have the file on disk eg. file://.
Try putting the file at a real url (or localhost:<port> by running a server locally) and see what happens.

Tried but the same problem.


Additional time slots

Would it be possible to add additional time slots to the general configuration such as:
1 hour
2 hours
5 hours
1 day
Thanks a lot
Bruce Sciboz

Hi @AxelDorian - we have released a new minor version with these updated slots. Let us know how it works for you.

Hi @jweisman
It looks promising. Thanks a lot for your promptness!

Good to hear- thanks for the feedback.


Glitch

Please describe the changes this PR makes and why it should be merged, as well as any and all proof of successful tests:
Semantic versioning classification:

[ ] This PR changes the framework's interface (methods or parameters added)

[ ] This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[ ] This PR only includes non-code changes, like changes to README, etc.

g

Please don't PR your entire bot to this boilerplate, push to your own repository.


Server breaks without dev tools open

I know I've filed a bunch of bugs, just want to let you all know that Haul is awesome and we love it here. Without Haul we would not have been able to use react-native with our internal infra so we're eternally grateful.
Current Behavior
While dev tools are open, all works as expected. With dev tools closed, I see the following:

Expected Behavior
Code should evaluate properly regardless of whether or not dev tools are open
Haul Configuration (webpack.haul.js)

module.exports = ({ platform }, { resolve }) => ({
  entry: `./index.${platform}.js`,
  resolve: Object.assign(resolve, {
    alias: Object.assign({
      Immutable: 'immutable'
    }, resolve.alias || {}, extAliases)
  })
});

Your Environment

software
version

Haul
0.5.0

react-native
0.42.0

node
7.8.0

npm or yarn
yarn 0.22.0

can you post the libraries you use? I suspect it's coming from a library. By default, we only transpile modules whose name start with react. for compatibility.

the only libraries we're using are internal ones which i unfortunately can't post the code to, all protected stuff. i can say this was all working fine on 0.3.0 but is broken on 0.5.0

hmm... any of those libs are ES2015+?
don't think we changed something around transpiling, but need to check.

Nah our internal stuff doesn't support anything past ES6 standard

@aem so it uses ES2015, JSC version on Android most likely doesn't support all of ES2015. We don't transpile everything under node_modules by default, but you can whitelist your own modules in webpack.haul.js to have your internal modules transpiled.

But why would this only be an issue without the dev tools open?

@aem when devtools is open, your code runs in a web worker inside Google Chrome, which supports a different set of features. Chrome supports full ES2015, so you won't see any errors.


[Feature]: Have github actions to allow CI/CD

Describe the feature
Currently, shuttle requires manual deployment. The shuttle/deploy-action also looks more "hack-y" than elegant.
I would like for there to be independent and composable github actions that allow you to

Set up shuttle on the runner
Build and test your project
Set or reset secrets (possibly using the Github Action secrets as the backing store)
Deploy the application.

Suggestion or Example of how the feature would be used
No response
Duplicate declaration

[X] I have searched the issues and this feature has not been requested before.

Additional Thoughts:
I am considering designing five different actions here:
What is needed:

Set up shuttle binary
Log in to shuttle
Check if a project exists and create one if necessary
Create a secrets.toml file for consumption by deploy
Deploy a rust project to shuttle and create necessary outputs

Plan:
I will create three actions. Each action will do one thing and one thing only.

action
kind

shuttle-setup
typescript

shuttle-login
typescript

shuttle-create-project
typescript

shuttle-set-secrets
typescript

shuttle-deploy
docker

Each action will have its own repository.

Apologies for the delayed reply here  @AliSajid. This sounds great, using shuttle in a CI/CD workflow definitely could use some work! I think your proposed actions make sense, although the create project step is due to be removed in a month or two (:crossed_fingers:), so I wouldn't spend a lot of time on that, but that's up to you. :slightly_smiling_face:

@oddgrd So are we implicitly creating projects? The only reason I have this up is because deploys would fail if a project didn't exist. If that's the plan then this will definitely become a redundant method.

Also AliSajid/shuttle-login is almost ready for prime time. The functionality is there and I'm just writing some tests to ensure that all edge cases are covered.

Yes, a user will no longer need to be concerned with starting/stopping projects (containers), they will just deploy and their service will be started in a container by our orchestrator. But this is some weeks away, I'd say.

The current GitHub action can do pretty much all of the above points, to the point where I can consider this issue closeable.

Since the current action can accomplish everything above except (re)starting projects (which will be removed), I'll close this.


How to animate changes in container height when switching between child components of different heights?

Dear emilkowalski
How to apply animation for height changes when a child component with varying heights is swapped?

It's up to the user, you can use framer motion for example, or recalculate the height yourself and add a transition to it.

Oh i see, thanks for the quick response


Move zip file methods to the NBugZipFile class.

Hello Teoman,
I refactored the BugReport class. I was looking at the CreateReportZip method and noticed that the if else logic could be replaced by 2 methods:
IsMaxReportingDaysExceeded and IsMaxQueuedReportCountExceeded
then I created a NBugZipFile and moved all the zip logic to that class.
I understand if you don't want to include this as it is a large change...

CreateReportZip was gigantic and needed refactoring for a while. However since nbug has been in production by many, I'm also sure that it works as it should.
Now these changed require proper testing and I don't use Windows anymore so I'm not sure what to do.

That's ok,
We can include this change later. Maybe in a new release?
Do you want me to close this PR?

To be honest, at this point I can't approve any major changes or even make a new major release as I have no means to test it. I can only read and try to reason about changes as long as they are minor.
Automated testing coverage is also very basic so if you want to continue refactoring big stuff and making major changes, you can keep your own fork of the project.
For instance the biggest user of this library is gitextensions and they keep their own fork: https://github.com/gitextensions/NBug/network


change plot subtitles for Ranked abundance

This will resolve https://github.com/VEuPathDB/web-monorepo/issues/265.
It is obvious what to do, though I could not find where the plot subtitles are displayed 😅

haha no worries! They are very subtle :) Here's one using your branch!