Add maximum atmos temperature limit

About the PR
Adds Atmospherics.Tmax, a maximum absolute temperature temperature limit for gas mixtures.
Why / Balance
Safe numeric code enforce numeric ranges to be within a certain well-defined range. For example in a temperature simulation, it is safe to constrain temperature in a "reasonable" range where we know that the physical laws stop applying. There is already such a limit for the minimum temperature; this adds one for the maximum temperature.
This should never happen:

And of course while it is better to fix the problem at the root, bugs happen and code should still be robust.
Balance
Anything that scales with temperature, e.g. damage and reaction rates, can still go through a very big range with this temperature cap.
Physical Justification
These sorts of temperatures would never exist in real life for a variety of reasons:

At some pressure the container would just explode, venting it
At some temperature the container would just melt, also venting it
At some temperature any gas would instantly converted to plasma, causing it to violently destroy the container

While it is true that temperatures exceeding this can exist on stars, that sort of defies the simple $PV=nRT$ physics we have. In numerics speak, we'd say that this is out of the domain of our model.

i'm pretty sure this makes maxcaps impossible even if we fix the other changes
20000C is very little, unless we revert this once we get pipe bursting
i believe this kills a lot of TEG setups
setting it to around 200000C or 140000C should work better

Maybe you’ll stop touching the atmosphere? this bug happened because of your shit-pr, and now instead of fixing it, you add a limit of 20,000.
You're not going to get many warnings.

I strongly dislike the idea adding an upper temperature limit to atmos on principle. If we absolutely must, I request it be set to the Hagedorn or Planck Temperature as those are actual physical limits instead of some arbitrary cutoff.

In my honest opinion, early or later, they should be limit, due of humanity progress, cause its kinda funny and unlogical that atmos are able to syntez an entire sun in burn chamber that made from steel and glass.
But due of recently bug that allows to do it... Thats pr is looks like a bandaid of that mistake, rather than balance fix, and of corse, people will be on emotions, cause atmos the most intriguing and interesting mechanic in ss14, and it got limited due of bug.
So anyway, idea of giving limit is okay, someone told that instead if limiting, heat could be on fast cool itself due of some laws that i dont know, but making this due of "plasma flood" situation, is kinda harsh path to walk in.

agree with temporal, seeing atmos hit exceptionally high numbers is also helpful for indicating a bug is present

I strongly dislike the idea adding an upper temperature limit to atmos on principle. If we absolutely must, I request it be set to the Hagedorn or Planck Temperature as those are actual physical limits instead of some arbitrary cutoff.

I gave a few physical justifications for why a limit should exist in the PR description. The ideal gas law, and indeed the physical state of gas breaks down at high enough temperatures. What principle do you feel like is being broken?
Perhaps the limit set here is too low. Some here have suggested a few higher limits. I'm okay with a higher limit, we should decide what it should be.
There would still be ways to catch bugs, namely:

Hitting the debug exception that this adds.
Seeing the temperature limit be reached. Maybe the current limit is too small. But surely there is some limit that we can agree on should never be reached.

It feels like there is no limit now because you can represent infinity as a floating point. But due to floating point precision issues there already is a limit beyond which things just stop behaving correctly (see why we have to have space friction to limit the distance something flies from the station).
I'd liken this to a numeric seat belt that reduces damage when something goes wrong. A seat belt is not a band-aid.

So anyway, idea of giving limit is okay, someone told that instead if limiting, heat could be on fast cool itself due of some laws that i dont know, but making this due of "plasma flood" situation, is kinda harsh path to walk in.

All gases cool to tiles, then to space, when superconduction is enabled. Superconduction is not enabled by default for a variety of reasons. In practice that would also limit temperatures because it's hard to fight $T^4$ scaling.

Seeing the temperature limit be reached. Maybe the current limit is too small. But surely there is some limit that we can agree on should never be reached.

once again, i propose 200kK, i believe that temperature is not reachable unless you're deliberately trying to optimise a burn for extremely high temperatures and nothing else

20kC is nowhere near physics breaking and the starting point for a lot of burns
this will completely gimp teg

That being said - the question we should be asking is: are we sure we want a limit?

Absolutely. In fact there's already a limit, it's called float.MaxValue. But limits of floating point precision mean that some operations don't behave as you would expect at much lower values.

Such an arbitrary maximum introduces new edge-cases (possibly bugs), above being just one example, because now we are violating laws of not just physics, but mathematics as well. ∃x ∈ ℝ / { 0 } (x + x = x).

We're programming with real computers with real limits on the number of bits in the mantissa. The objective of this is to limit values in a range where floats behave relatively sanely. If you want to see on your own computer:
Python 3.9.18 (main, Sep 12 2023, 01:16:40)
>>> 3e305 + 1.1e305 - 1.1e305 - 3e305
-3.89812560456e+289

That number is not zero.

If (and this is a very big if) we wanted to limit temperatures, in my opinion the best way to tackle this problem is by introducing some form of "temperature entropy" which would soft cap temperatures in a sane range, rather than hard capping it, like this:

I welcome a patch. Even then, a limit is prudent to make sure big numbers can actually return to zero. As I showed above, $x + y - y - x$ is not equal to zero when $x$ and $y$ are very large.
Tmax bumped to 200K.

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

did the nerf break atmos? Because atmos has been acting very funky for the past few days or so

burn nerf was just changing energy values so thats not related

before burn energies were nerfed, 200kK was very much a reasonable temperature you could get in normal gameplay. after the nerfs i doubt its possible to get without a dedicated max temp setup.

That's because the energies from before were not unreasonable. The "hard" limit should not be reachable through normal gameplay.

did the nerf break atmos? Because atmos has been acting very funky for the past few days or so

No. This is better addressed in a separate thread, but the breakage is likely from https://github.com/space-wizards/space-station-14/pull/22803 which was partially addressed in https://github.com/space-wizards/space-station-14/pull/22876.   There's no reason why a realistic atmos sim would reach those temperatures nor would even the ability to occasionally reach those temperatures justify the additional performance cost of migrating the entire system to use high precision.

actually no, there are no such issues
i don't think there was any real reason to merge this

Thanks for writing in with your comments.

So I want a design decision be made here. Do we want a temperature limit or not?

The design decision was to limit pressure and temperature in most atmos devices. In practice pressure limits are set by bursting and temperature limits (through what you call "quantum thermal conductivity") are set by the (currently-disabled) "superconduction" code. This is partially implemented e.g. in https://github.com/space-wizards/space-station-14/pull/20931 but not quite ready for show time just yet.
Perhaps that is where our fundamental miscommunication was. I do appreciate your thoughtful comments here.


PNG no longer a WD

PNG has been Candidate Recommendation since 21 September 2023
https://www.w3.org/TR/2023/CR-png-3-20230921/

Thanks!


Add support for NoSketchEngine where applicable

i.e. concordances, freq. distributions, speeches etc.
All the APIs should be part of WaG core distribution.

We should split this into smaller units of work (i.e. Concordance API for NoSkE, Collocation API for NoSke etc.)

First one is already here: https://github.com/czcorpus/wdglance/issues/573

The second one is here: #607. So now I can close this one.


Release v196

https://github.com/heroku/heroku-buildpack-python/compare/v195...5d8d468921897afad2e5f0f75115e26b298f11f3
Closes GUS-W-9318135.

$ make publish
Deploy as version: v196 [y/n]? y

Tagging commit d7bfdc487d6a94e9dfd307dec365ec9ed3ef5525 with v196...
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/heroku/heroku-buildpack-python
 * [new tag]         v196 -> v196

Publishing to the buildpack registry...
Two-factor code: ********************************************
Publishing buildpack heroku/python... done
Publishing buildpack was successful

Version  Released At               Status
───────  ────────────────────────  ─────────
196      2021-05-25T16:08:50.799Z  published


Updates cartodb.js to 3.14.4

@fdansv PTAL! Thanks!

Frontend tests were OK :+1: (details)

All good, go ahead ;)


npm run dev error

▽
;CurrentDir=/root/incubator-dubbo-admin/dubbo-admin-ui
  ✘  http://eslint.org/docs/rules/semi  Extra semicolon
  src/components/ServiceSearch.vue:284:38
            query = group + '/' + query;
                                        ^

✘ 1 problem (1 error, 0 warnings)

Errors:
  1  http://eslint.org/docs/rules/semi

You may use special comments to disable some warnings.
Use // eslint-disable-next-line to ignore the next line.
Use /* eslint-disable */ to ignore all warnings in a file.

it's only warnings


feat: add News home section

This PR resolves ONYX-1238
Description
This adds the News card to the new home view:
https://github.com/user-attachments/assets/426a5844-1da5-45f5-9832-16f7a59b2c2b
There are some TODOS in the code to indicated follow-ups re: view-all behavior
PR Checklist

[ ] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Add news card to home view - roop

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

This PR contains the following changes:

Cross-platform user-facing changes (Add news card to home view - roop)

  Generated by :no_entry_sign: dangerJS against a762ffab259e0298382611f54f7d460f27dbae63


Corrected the Prerequisites section

It's correct, and the live topic is loading the prereqs ...
https://docs.microsoft.com/aspnet/core/tutorials/razor-pages-vsc/razor-pages-start#prerequisites


feat: [LW-6471] Added optional metadata fetch feature from SMASH server

Context
We are introducing configurable modes for fetching stake pool metadata.  In addition to directly fetching metadata, we can now fetch metadata from any configured Cardano smash server.
Proposed Solution

We already had the fetching logic in place. This change adds awareness of the new parameters and handles the smash server handling.
The metadata fetch mode is set by the parameter:  --metadata-fetch-mode.
Cardano smash server URL is set by the parameter: --smash-url.

Refactored stakePoolMetadataHandler.ts and HttpStakePoolMetadataService.ts so fetching stake pool metadata and extended metadata can be called separately.

Refactored stakePoolMetadataHandler.ts and HttpStakePoolMetadataService.ts to get rid of controlling the program flow with side effects.

Important Changes Introduced

Thank you @rhyslbw for the detailed review and responses.

The commit is a breaking change, so will need to be specified as
It looks like not a breaking change, or am I missing something? I mean, if you start without any parameters it defaults to DIRECT and behaves like the good old days.
We should also default to using the CF managed SMASH in our dev launching scripts: https://github.com/input-output-hk/cardano-js-sdk/blob/ed8aafbe54b047c07ce0c4c0a39f66c90e6467a7/packages/cardano-services/package.json#L39-L49
I was confused if I should default our dev environment to SMASH or not, will do it. By the way, I was not able to find a managed SMASH instance for the preview network.

@rhyslbw

Note we're not using Jira references in commit titles, but you could put it in the body of the commit as metadata

Do we have the same limitation for branch names (not to use jira references)?

It looks like not a breaking change, or am I missing something?

Sorry, I should have lead with this detail. It's a breaking change for the cardano-services library, as the interface for this module changed, which is exported

Note to self: Looks like I forgot comment and debug lines all over the place. I suspect this is because I was working on this for a prolonged period of time while learning a lot.
Thank you for helping clean my mass ^^ @rhyslbw  @iccicci

The e2e failure seems to be unrelated, so let's check it again after squashing


Error then import { Store } from 'svelte/store.js';

import { Store } from 'svelte/store.js';
Uncaught (in promise) SyntaxError: Unexpected token {
at eval (modules.js?hash=e85cfce550754a19536a1fda19bffb3b178b0c60:26034)

This error is thrown because svelte/store.js contains an import statement. The easiest way to make it work with Meteor is to import Svelte's pre-compiled version svelte/store.umd.js instead of svelte/store.js. However, if you want to continue using svelte/store.js, you have to tell Meteor that it should compile the two files svelte/store.js and svelte/shared.js like all your other JavaScript modules. You can do this by creating a symlink to these files in your application directory, for example:
cd imports
ln -s ../node_modules/svelte/shared.js
ln -s ../node_modules/svelte/store.js

For more details, check out this forum post (it uses the Polymer library as an example): https://forums.meteor.com/t/litelement-import-litelement-html/45042/8.
Let me know if either way works for you. :slightly_smiling_face:

Thanks. @klaussner
Not works for me.
Display error
Master.html:2 Uncaught (in promise) Error: <Master> references store properties, but no store was provided
Master.html
<NavContainer />

{$name}

store.js
import { Store } from 'svelte/store';
export default new Store({ name: 'world' });

This turned out to be a bug in Svelte, which was fixed in version 2.15.1. I published a new version of svelte:compiler with the latest Svelte version (2.15.3). If you update with meteor update svelte:compiler, the store should work.

Thanks. @klaussner
it works for me.


Latest release won't run on latest Apple Silicon macOS

The current latest release won't run on the latest macOS. macOS flags it as a corrupted executable and refuses to run it.
CPU: Apple M3
macOS: 15.1 (24B83)

I did not. I didn't even see it because of how far down it was.


The Stripe Terminal ConnectionToken has already been redeemed

Describe the bug
Using the example-app in internet discovery mode, when you disconnect and then reconnect to a reader using the example-app you receive the following error:

connectInternetReader error: {"code": "PAYMENT_ERROR.DECLINED_BY_STRIPE_API", "message": "The Stripe Terminal ConnectionToken has already been redeemed. Please generate a new one using v1/terminal/connection_tokens."}

It seems like the same connection token is continually recycled.
I am running stripe-terminal-react-native/example-app and example-terminal-backend.
The reason I'm trying to test the example-app is because my own app is experiencing these same behaviors, whether from the emulator or an S700 Devkit.
To Reproduce
Steps to reproduce the behavior:

Run both the example-app and the example-terminal-backend (ruby)
Point the example-app to your ruby api
Change discovery method to "Internet"
Tap "Discover readers"
Select the "WisePOSE" reader
Disconnect or restart the app
Try to connect to the same reader again
(This simulates what happens with an S700 device)

Expected behavior
A new connection token should be refetched.
 Please generate a new one using v1/terminal/connection_tokens."}

In the logs provided the connection token is always the same: pst_test_YWNjdF8xRGhJTGVDdGJ4NXlES0tlLEJWQWI0alB6QWMxR1hGUTh4Z0s0dUZkWWVNRWE4eVk_003Qok4tIc
The token provider should return a new token every time it's called, otherwise the API will return this error
Make sure your backend is not caching the token and generating a new one every time your tokenProvider function is called

The backend was indeed caching the token. Is it a bug that the library fetches multiple new connection tokens in one render cycle?

That makes sense.


fixed code to make sure the disableAddButton's state is evaluated based on the specific data in each row

Thanks @azurebrd


Add support of subaccount and tags for Mandrill

Add support for subaccount and tags as per https://mailchimp.com/developer/transactional/api/messages/send-new-message/ -> message's properties.

LGTM. If you are happy with it now (not more pushes coming), I'm going to rebase it in.

all good from me @princemaple


Fix CMakeLists.txt

Let the developer choose what kind of build if wants to do  instead of forcing in Release
Expose Boost_INCLUDE_DIR as a PUBLIC include directory for target mstch
Update README.md to include lines about CMAKE_BUILD_TYPE

I approve the patch, it is great. However, I think we should submit it to the mainline project to integrate in official releases rather than maintaining this on our end.

I have a PR to the mainline project already, the same as this one

You should not have merged this like that. We now have diverging histories in our repo and in the mainline project...

Ok, I guess no one is using mstch master right now so what about a reset --hard on mainline and push -f ? We are pointing to mleblanc/fixCMake in the ExternalProject_add


Digital Signature for the container image and a signed SBOM

Hi,
I'd like to be able to verify the container images I'm downloading from https://hub.docker.com/_/amazoncorretto/ have indeed been generated by you and have not been tampered with.
I'd also like to be able to be able to know what components you are including in your containers, ideally in an SBOM format, and I'd also like to make sure that this metadata hasn't been tampered with.
Thanks!

Hi, thanks for contacting us about this. It would be helpful if you could describe in a bit more detail what you're looking for:

What information would you like that isn't already provided by docker trust amazoncorretto or docker sbom amazoncorretto:<tag>?
How would you like that information provided? Do you have an example you can share where another image is vending this information?

As an "Official Image", Dockerhub generates those images based on the Dockerfiles in this repository and the images will get automatically rebuilt when the base images change.

@benty-amzn The docker scout sbom command creates a new SBOM by scanning the contents of the image which has its downsides and depends on the accuracy of the tool. Instead, it is possible for the image author to provide a signed attestation of the contents added as metadata of the image itself (e.g. https://docs.docker.com/build/attestations/ and https://docs.docker.com/build/attestations/sbom/)
@lutkerd If the actual build pipeline is not here, but with DockerHub, I guess it would actually be a request to their build pipeline to generate that metadata.


[Bug]: Remove required field on the key-value widget

Is there an existing issue for this?

[X] I have searched the existing issues

Description
Remove required field on the key-value widget since it's a read-only widget that does not expect user input
Steps To Reproduce

Public Sample App
No response
Environment
Deploy Preview
Severity
Medium (Frustrating UX)
Issue video log
No response
Version
cloud

raised more on #33192


Component definition enhancements

Using this in an actual project has shown some missing pieces in the api. Specifically
A way to designate and query singleton entities.
The main example being the "player" entity. Currently, we can create a player tag and query that in the system. But that will return a list, which is odd
(def-tag player)
(def-system
  {players [:player]}
  (for plyr in players (pp plyr)))

One idea is to add an optional singleton arg to the def-tag function
(def-tag player :singleton)
(def-system
  {plyr [:player]} # since player is singleton, is a single entity
  (pp plyr))

I'm still thinking through how this would interact with more complex entities & components
Some stronger type enforcement on components
this is really a couple of things. I'd like to enforce the type of a components data, be able to provide the component keys when creating an entity, and be able to create components that just hold 1 thing. This possible api shows the changes Im thinking of
# Just 1 data point in the component
(def-component name :string)

# provide the type of each key when component is a table
(def-component position
  :x :number
  :y :number)

# for table components, you provide the keys
(add-entity world
            (name "Bob Guy")
            (position :x 10 :y 10))

Ad singletons: what about destructuring in the query definition? Something like:
(def system
  {[plyr] [:player]}
  (pp plyr))

It is from the top of my head, so probably wrong :-).

hmm destructuring is interesting.  You could then even do some more interesting  destructuring like this
(def-system print-player-one-data
  {[[_ pos nm]] [:player :position :name]}
  (printf "player is named %s: at %q" nm pos))

(def-system two-players
  {[player-one player-two] [:player :position :name]}
  (pp player-one)
  (pp player-two))

there would be no enforcement that there would be only X players, but maybe that's not important (or even desirable)

Indeed, I was thinking this way too.

Oh wow so it turns out you can already do destructuring in the query section of the system. This works!
(use /junk-drawer)

(def-component position x y)

(def-system move
  {[[pos]] [:position]}
  (pp pos))

(def world (create-world))
(add-entity world (position 10 10))
(register-system world move)
(:update world 1)

in the new API
(use /junk-drawer)

(def-component position :x :number :y :number)

(def-system move
  {[[pos]] [:position]}
  (pp pos))

(def world (create-world))
(add-entity world (position :x 10 :y 10))
(register-system world move)
(:update world 1)

also, single value components (not wrapped in a table) ended up not being worth it, since those values are immutable in the system body


Type 'Timer' is not assignable to type 'number'

First of all thank you for your hard work on this project. And special appreciation for 0.10 release with AM Beta.1 and AOT!
I'm trying to identify strange problem with 0.10 release. Even simple new ng-cli project after installing covalent fails in ng serve command. It looks like typescript use definition of setTimeout from Node.Js typings which is installed by angular-cli. Replacing setTimeout with window.setTimeout in src/platform/core/common/animations folder fixes the problem
ng-cli logs:
ERROR in<EMAIL_ADDRESS>Module build failed: Error<EMAIL_ADDRESS>(95,5): Type 'Timer' is not assignable to type 'number'.)
<EMAIL_ADDRESS>(156,7): Type 'Timer' is not assignable to type 'number'.)
at _checkDiagnostics (/home/rem/fm/WebPlanner2/node_modules/@ngtools/webpack/src/loader.js:116:15)
at /home/rem/fm/WebPlanner2/node_modules/@ngtools/webpack/src/loader.js:141:17
<EMAIL_ADDRESS>13:0-73
<EMAIL_ADDRESS>@ ./src/app/app.module.ts
@ ./src/app/index.ts
@ ./src/main.ts
@ multi main
ERROR in<EMAIL_ADDRESS>Module build failed: Error<EMAIL_ADDRESS>(104,5): Type 'Timer' is not assignable to type 'number'.)
<EMAIL_ADDRESS>(141,5): Type 'Timer' is not assignable to type 'number'.)
at _checkDiagnostics (/home/rem/fm/WebPlanner2/node_modules/@ngtools/webpack/src/loader.js:116:15)
at /home/rem/fm/WebPlanner2/node_modules/@ngtools/webpack/src/loader.js:141:17
<EMAIL_ADDRESS>14:0-67
<EMAIL_ADDRESS>@ ./src/app/app.module.ts
@ ./src/app/index.ts
@ ./src/main.ts
@ multi main

Ive seen that before, its the tdconfig.json configuration but you are right, its taking the NodeJS definition of them..
As a work around for now, can you try mimicking the same tsconfig.json file we have?
https://github.com/Teradata/covalent/blob/develop/src/tsconfig.json

Fixed in patch 0.10.1


ssh access has changed for raspberry pi lite

as per https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/ the default user/password is no longer valid, it did not work for me.
After I do this "Headless setup" I can log in with ssh as normal.
Also some useful additions to configure ssh and wifi access point credentials all within the tool.
Suggest update to the documentation.

is now in the latest hyperbian image and also added to the docu thanks to @Lord-Grey


delly: 0.9.1 -> 1.0.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/delly/versions.
meta.description for delly is: "Structural variant caller for mapped DNA sequenced data"
meta.homepage for delly is: ""
meta.changelog for delly is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.3 with grep in /nix/store/br7md8yhh6398slwci0jr5qqwvapbp2a-delly-1.0.3
found 1.0.3 in filename of file in /nix/store/br7md8yhh6398slwci0jr5qqwvapbp2a-delly-1.0.3

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
delly

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/br7md8yhh6398slwci0jr5qqwvapbp2a-delly-1.0.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A delly https://github.com/r-ryantm/nixpkgs/archive/2c4135d59b5f847998d0fd84d19e563037165ba7.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/br7md8yhh6398slwci0jr5qqwvapbp2a-delly-1.0.3
ls -la /nix/store/br7md8yhh6398slwci0jr5qqwvapbp2a-delly-1.0.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

delly

Maintainer pings
cc @scalavision for testing.

I am on vacation. Would have to look into it later next week.

"2 weeks later" :)


Add Method decorators for improved Controller API

The patch on TestMethod.test_decorators doesn't work for some reason, so it checks for a MapMeta instance. I want it to check that it is the mock I tried to set up but it seems to be ignoring them. Any idea why this is happening?

Coveralls implies the test isn't calling the decorator functions properly, which I guess is the problem. Not sure why though...

Can you rebase onto master please?

I need to remember to rebase to origin/master...
I think I know how to test it now so I will fix the coverage now.

OK, how is that?