[8.x] Removed Dispatchable trait because it breaks Lumen apps

This PR relates to laravel/lumen-framework#1136 issue.
Description
When initializing vimeo/psalm package for Lumen app, it complains that Illuminate\Foundation\Bus\Dispatchable Trait is missing. Hence it breaks in the initial run.
I ran the test cases after this modification and tests are passing. But I doubt that test cases cover the particular piece of code. This bit of code has introduced 2 years back from this commit, https://github.com/laravel/framework/commit/556b948c41b273144e5f23f6b3b6167bf7e0c84e. So probably @taylorotwell can have a look to decide Dispatachable trait really needs for Lumen.
Steps to reproduce issue

composer create-project --prefer-dist laravel/lumen blog
cd blog
composer require --dev vimeo/psalm
./vendor/bin/psalm --init

Expected result
No errors to be thrown.
Actual result
Following error message throws
Calculating best config level based on project files
Calculating best config level based on project files
Scanning files...
PHP Fatal error:  Trait 'Illuminate\Foundation\Bus\Dispatchable' not found in /.../blog/vendor/illuminate/queue/CallQueuedClosure.php on line 14
Fatal error: Trait 'Illuminate\Foundation\Bus\Dispatchable' not found in /.../blog/vendor/illuminate/queue/CallQueuedClosure.php on line 14

This is foremost a real breaking change on stable release.

Why is this a closed and not worked upon?
If someone would use CallQueuedClosure class in Lumen he would get the same error, because Trait Illuminate\Foundation\Bus\Dispatchable does not exist.

Why is this a closed and not worked upon?
If someone would use CallQueuedClosure class in Lumen he would get the same error, because Trait Illuminate\Foundation\Bus\Dispatchable does not exist.

Why is this closed

See the above comment.

Why is this [...] not worked upon?

Feel free to come up with a non-breaking solution. Laravel is an open source project.

Why is this closed

See the above comment.

Why is this [...] not worked upon?

Feel free to come up with a non-breaking solution. Laravel is an open source project.

@GrahamCampbell This issue is closed  because nobody can figure out how to fix it in a non breaking way?
If this was an open issue maybe someone with more experience would see it and figure out a way to fix it in a non breaking manner.
This behavior of closing issues like this (which I have noticed a lot lately) will be the downfall of Laravel.

@GrahamCampbell This issue is closed  because nobody can figure out how to fix it in a non breaking way?
If this was an open issue maybe someone with more experience would see it and figure out a way to fix it in a non breaking manner.
This behavior of closing issues like this (which I have noticed a lot lately) will be the downfall of Laravel.

Queued closures are not supported in Lumen. We don't plan to add support for them either. If someone needs that feature I suggest using Laravel instead or just using a regular queued job instead of a queued closure. The issue is closed because we have no plans to work on it and we used this issue tracker to know what we need to work on - not what somebody someday might work on. Thanks.

Queued closures are not supported in Lumen. We don't plan to add support for them either. If someone needs that feature I suggest using Laravel instead or just using a regular queued job instead of a queued closure. The issue is closed because we have no plans to work on it and we used this issue tracker to know what we need to work on - not what somebody someday might work on. Thanks.

@taylorotwell  We are not asking for Queued closures for Lumen in this issue. I do not even use queues in the current lumen app.
The issue is that because laravel/lumen-framework is requiring illuminate/queue which has a class CallQueuedClosure which uses a trait Illuminate\Foundation\Bus\Dispatchable which is only available in illuminate/foundation which is not required in laravel/lumen-framework we get the error above when running ./vendor/bin/psalm --init.
Could this be solved by simply adding illuminate/foundation to Lumen require or would that break something. I don't know how that part works.

@taylorotwell  We are not asking for Queued closures for Lumen in this issue. I do not even use queues in the current lumen app.
The issue is that because laravel/lumen-framework is requiring illuminate/queue which has a class CallQueuedClosure which uses a trait Illuminate\Foundation\Bus\Dispatchable which is only available in illuminate/foundation which is not required in laravel/lumen-framework we get the error above when running ./vendor/bin/psalm --init.
Could this be solved by simply adding illuminate/foundation to Lumen require or would that break something. I don't know how that part works.

There is not really any such package as illuminate/foundation. It is just a namespace that exists in laravel/framework. And, of course, adding laravel/framework to Lumen would kind of defeat the purpose of Lumen. Perhaps there is some way to tell Psalm to ignore this?

There is not really any such package as illuminate/foundation. It is just a namespace that exists in laravel/framework. And, of course, adding laravel/framework to Lumen would kind of defeat the purpose of Lumen. Perhaps there is some way to tell Psalm to ignore this?

On the initial psalm run psalm --init  scans the vendor directory and creates a configuration file based on the results. On subsequent runs it ignores the vendor directory.
Because the configuration file is not created until the init command completes there is no way to tell psalm to ignore this.
To get the initial scan to complete I had to manually remove that missing trait from CallQueuedClosed, run the command psalm --init and then restore the file CallQueuedClosed.php as it was.
A potential fix could be to stub illuminate/foundation in lumen-framework to have an empty trait in that location?
I know that this is a very edge case, but solving this would mean that people could use psalm in their lumen apps without encountering this error on the initial run.
I will also create an issue on psalm to see if they can implement some sort of a solution for this. Thank you.

On the initial psalm run psalm --init  scans the vendor directory and creates a configuration file based on the results. On subsequent runs it ignores the vendor directory.
Because the configuration file is not created until the init command completes there is no way to tell psalm to ignore this.
To get the initial scan to complete I had to manually remove that missing trait from CallQueuedClosed, run the command psalm --init and then restore the file CallQueuedClosed.php as it was.
A potential fix could be to stub illuminate/foundation in lumen-framework to have an empty trait in that location?
I know that this is a very edge case, but solving this would mean that people could use psalm in their lumen apps without encountering this error on the initial run.
I will also create an issue on psalm to see if they can implement some sort of a solution for this. Thank you.

They have solved it. The fix will be available in the next release.

They have solved it. The fix will be available in the next release.


Remove snapshot from v1

The hhvm version in 1.x is bad too. Should be something like "hhvm-3.18", not "hhvm".


Turn Replacing existing passage "..." with duplicate. into an error

If you have duplicate passage names in your project, I think tweego should report that as an error. I expect, for backwards compatibility, this won't be possible, but it would be convenient to have a flag or something that could make this warning into an error. In my project, it would always be a mistake to get this warning, but with the noise of my build scripts, it's difficult to notice with my eyes when it prints out.  I'd like some way for my script to fail.
I'm developing on windows with cygwin.

Not an unreasonable request.  I should be able to add something like this to the next minor release.

Thanks!


fix(AccessCodeForm): show generic error on failing to save code

closes #478
Dependencies

https://github.com/seamapi/react/pull/475 has updates to validation which would conflict with changes here. I've left codeError intact for now, but it should be cleaned up once #475  is merged.

Screenshots

@mikewuu Anyway we can test this? Maybe a ui story for AccessCodeForm?
Does the layout shift when there is an error? I'm wondering if it makes more sense to render the error below the buttons.

Anyway we can test this? Maybe a ui story for AccessCodeForm?

@razor-x  sure, added in https://github.com/seamapi/react/pull/484/commits/6d4a84a064cddded125c8a4a0dde9e5bcca443ec
https://github.com/seamapi/react/assets/11449462/81f4ee06-b8df-47a7-8dd3-a10c7f7bcdf2

Does the layout shift when there is an error? I'm wondering if it makes more sense to render the error below the buttons.

Yes, but I believe this is consistent with the current design spec. IMO we should leave it as is until a we get a new design spec for all components for consistency.
cc: @miken-seam


Compression doesn't seems to be consistent

I was considering updating keyv library to the latest version and switching the custom compression wrapper to one of the new packages. Unfortunately I found couple of potential issues I would like to discuss.

Looks like:

compress?: Record<string, unknown> | undefined;

from Keyv.Options interface are no longer used in code.

New compression parameter used in the Keyv implementation doesn't seem to have a clear interface that could be used to define the KeyvBrotli, KeyvGzip or any other future implementations.

The approach of using opts object created inside KeyvBrotli and KeyvGzip instead of methods defined by common interface seems to be a dodgy approach. It doesn't make it easier to work on future integrations.

Both KeyvBrotli and KeyvGzip seems to be defining only two methods in Options interface that when passed to the constructor are immediately overwritten. Additionally compress and decompress methods are being defined in those two classes, which makes it even harder to understand how the code should behave.

I'm not sure if either of those extends EventEmitter implements Store<Value> is really needed in KeyvBrotli and KeyvGzip.

There is not TypeScript compatible way to provide compression-method-related parameters down to the compressors.

I know that's a lot, but I think current approach is bugged and I would be happy to jump on a call to talk all of those points through.

@kdybicz - happy to have a discussion around this as this was our first attempt to get this going and also keep compatibility with all the storage adapters on the backend. Here are some initial thoughts:
Looks like:
compress?: Record<string, unknown> | undefined;
from [Keyv.Options interface](https://github.com/jaredwray/keyv/blob/main/packages/keyv/src/index.d.ts#L88) are no longer used in code.

Correct, our plan will be to remove this on the next release. I will get a pull request going on it.

New compression parameter used in the [Keyv implementation](https://github.com/jaredwray/keyv/blob/main/packages/keyv/src/index.js#L53-L58) doesn't seem to have a clear interface that could be used to define the KeyvBrotli, KeyvGzip or any other future implementations.

Good point, Right now we have attempted to make this more flexible but then harden it over time. Our current thinking is to define a pretty standard interface for people to build off of.

Both KeyvBrotli and KeyvGzip seems to be defining only two methods in [Options interface](https://github.com/jaredwray/keyv/blob/main/packages/compress-brotli/src/index.d.ts#L14-L15) that when passed to the constructor are [immediately overwritten](https://github.com/jaredwray/keyv/blob/main/packages/compress-brotli/src/index.js#L12-L15). Additionally compress and decompress methods are being defined in those two classes, which makes it even harder to understand how the code should behave.

Agree, What we will look at is to adjust this to not overwrite as you mentioned in #3 and also will look to use the compression directly if it is implemented.

I'm not sure if either of those extends EventEmitter implements Store<Value> is really needed in KeyvBrotli and KeyvGzip.

Will validate and see if we can change this.

@alphmth - will get some time with you to discuss the changes.

@kdybicz happy to discuss via a zoom or call if that helps. Shoot me an email and we can setup some time.

@jaredwray I proposed a call just in case I did a bad job at explaining the points. If all is clear, then I leave that up to you. Also, feel free to ping me if you would need help ie. with testing those changes.

@kdybicz - will be working on some clean up for this in a pull request and will tag you in on it.

@kdybicz - https://github.com/jaredwray/keyv/pull/511

@kdybicz - one thing with this architecture is that it will overwrite the serialize and deserialize. We are looking at if this makes sense and if we want to make it more optional to do that which would increase some complexity in the main Keyv code base.

@kdybicz - will be closing this as the v2 architecture is now in main and will be released soon. We decided to keep the overwrite of serialize and deserialize functions in the compress function to simplify the current architecture in Keyv. With that said we will evaluate over time and might move to just needing compress and decompress.
In addition we have added an interface for this to standardize and have updated more of the code to work better and validated it.


Can't initialize new package with pkg-utils init

If you find a security vulnerability, do NOT open an issue. Email<EMAIL_ADDRESS>instead.
Describe the bug
Initialization prompt will error with:
error Cannot find package 'prettier-plugin-packagejson' imported from [.]/noop.js
([.] is the absolute path to the current working directory)
To Reproduce
Steps to reproduce the behavior:

Run npx @sanity/pkg-utils@latest init [path] and answer prompts

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Which versions of Sanity are you using?
Run sanity versions in the terminal and copy-paste the result here.
What operating system are you using?
Which versions of Node.js / npm are you running?
<EMAIL_ADDRESS><EMAIL_ADDRESS>Additional context
Add any other context about the problem here.
Security issue?
Any security issues should be submitted directly to<EMAIL_ADDRESS>In order to determine whether you are dealing with a security issue, ask yourself these two questions:

Can I access something that's not mine, or something I shouldn't have access to?
Can I disable something for other people? If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email us at [security<EMAIL_ADDRESS>

Somehow related to https://github.com/prettier/prettier/issues/15085

Hey @nkgentile – this has been resolved as of v3.2.1 😌


Blitz & Sprig cart not updating dynamically.

Good morning.
As discussed on Discord, I am having some difficulty trying to use Blitz and Sprig. I am trying to update the cart icon in my header to display the correct number of items in the cart. I am using s-trigger:load, which is working and ensuring that the cart qty is correct on every page load. The difficulty is when using the Add to Cart button. I would like this to update the cart widget dynamically so as soon as it is pressed, the number in the cartWidget in the header changes. I've stripped most of the code out below.
Header
{{ sprig('shop/cart/cartWidget', {}, { 's-trigger':'load'}) }} #}

Cart icon/cartWidget

{% if sprig.isRequest %}
 {% if cart.lineItems | length %}
{{ cart.lineItems | length }}
{% else %}
SVG ICON
{% endif %}

Add to cart button
<form sprig s-method="post" s-action="commerce/cart/update-cart">
  <input type="hidden" name="purchasableId" value="{{ variant.id }}">
  <button type="submit">
   FREE SAMPLE
  </button>
</input>
</form>

{% if addedToCart %}

{% endif %}

I am using the Sprig Cart example so the code is pretty much identical.
If Blitz is turned off, the above code works.

Looks fine, except that you've removed the refresh trigger event from the cart component. This should help:
{{ sprig('shop/cart/cartWidget', {}, { 's-trigger': 'load,refresh' }) }} #}

Thank you - that works.


drivers: spi: nrfx: Move MISO lines pull configuration to DT

After switching to nrfx 2.0.0, the Kconfig choice options that allowed
enabling of pull-up or pull-down for MISO lines in SPIs and SPIMs are
not properly supported, they are simply ignored. This commit restores
the possibility of applying pull configuration for MISO lines.
In earlier nrfx versions, the MISO pull configuration could be only
set globally, in nrfx_config files, for all SPI and SPIM instances
together. Since nrfx 2.0.0, this configuration can be applied per
instance. This commit takes advantage of this possibility and instead
of using a common Kconfig option as a global setting for all instances,
allows applying individual instance settings via devicetree.
Signed-off-by: Andrzej Głąbek<EMAIL_ADDRESS>

Rebased on master.

Applied @Mierunski's suggestion.

Applied @Mierunski's suggestion once more. This time in spi_nrfx_spi.c.


Remove API name from the command name

Currently we have some commands that are prefixed with the API they use, eg graph teams add or azmgmt flow list. The graph or azmgmt part of the command name indicates the API that we're using in the command to communicate with Office 365 and is a technicality irrelevant to the user. We should remove the API part from the command name so that it begins with the service, eg. teams add, flow list or spo app list. Simplifying command names will make it easier for users to work with the CLI and don't have to understand how they work internally. Additionally, it will isolate us from breaking changes in case an API that was originally available only through one API, has been released in another, which is regularly the case with MS Graph.
This is a breaking change that will be included in v2.

@waldekmastykarz , I assigned that to myself. I will start working on that in my branch before the end of the week.

Awesome! Thanks!


Setup Android Google Play account & upload build

[x] Setup Google Play Team account
[x] Add<EMAIL_ADDRESS>as admin
[ ] Create an internal testing team (add both of us as testers)
[ ] Upload build of test application to the internal test
[ ] Download the test build to your android phone and validate distribution of test versions is working

Hello Clay, I already created the google play account, and the app demo is ready to upload. But I need to upload in release mode. I have two doubts:

In release mode, do you want to keep leaving the Test environment url? (https://api.usw2-dev1.nidops.net/v3/c)
In release mode, the logs are not shown, how could we test if it works correctly? That is, you could only interact with the application.

Use the production url
-Dont show logs in release mode


How to implement commands for exporting all files in the workspace/all changed files?

Hi, I am in the middle of writing a language server for Argdown, a Markdown-like DSL for analyzing argumentation. I would like to add export commands that can be executed from the command palette. The commands should export all .argdown files in the workspace to html/dot files (other commands could do the same for all open files or the file in the currently active editor window). But I am not sure how to get the uris to all .argdown files in the command handlers. The only option I am seeing right now is to define an internal command that gets executed by the client if the official command is executed from the command palette so that the client can provide all uris in an argument. Is this the best pattern to use?
I would also like to add a file watcher that automatically exports changed files to dot/html files. The user should be able to activate/deactivate the automatic exports from vscode. The language server has the workspace/didChangeWatchedFiles notification, but I am not sure if I can use this as I need to know if the user currently wants to export files or not. If I am understanding the language server concept right, the server is not supposed to keep such client-specific state variables, as it should be able to react to notifications from different clients. Is that right? Or should I simply set a flag if "startExportingFilesOnChange" and "stopExportingFilesOnChange" commands are executed?
The alternatives would be to a) either watch files on the client side and execute the export command if files were changed or b) to give up on implementing this with a language server and use a task and my existing command line tool that already supports this (I would like to avoid using a task and the cli, because many of the users will not be programmers and this would probably make the feature inaccessible to them).
I would really appreciate if you could point me in the right direction.

LSP servers are not multi tenant / multi client. So you can keep the state whether the user want to export or not. Best would be this is a vscode setting and not a command.
Exporting these files should be done by the server and the server should compute the set to export. The client doesn't necessarily need to know all Argdown files. The contract between client and server in terms of files is:

files on disk are owned by the server
file open in the editor are owned by the client and the client guarantees that it notifies the server about any changes in the document.

Thanks, that was very helpful for me.


Issue with assigning deterministic weights[i] <- 1 for dcar_normal() distribution

Compilation error while compiling MCMC algorithm, depending on how weights (vector) argument for dcar_normal() distribution is defined.
If you define it within a loop of deterministic (scalar) declarations, as is commonly done in WingBUGS code, compilation fails.
If you provide weights as a constants vector, compilation gets through.
Reproducible example:
NOTE: checkout branch car, and build package there.
library(nimble)

code <- nimbleCode({
    for(i in 1:L) {   weights[i] <- 1   }
    S[1:N] ~ car.normal(adj[1:L], weights[1:L], num[1:N], 3)
    for(i in 1:N) {
	Y[i] ~ dnorm(S[i], 1)
    }
})

constants <- list(
    N = 3,
    num = c(1,2,1),
    adj = c(2,   1,3,    2),
    ##weights = rep(1,4),
    L = 4
)

data <- list(
    Y = c(1,2,3)
)

inits <- list(
    S = c(0,0,0)
)

Rmodel <- nimbleModel(code, constants, data, inits)

conf <- configureMCMC(Rmodel)
conf$printSamplers()
Rmcmc <- buildMCMC(conf)

Cmodel <- compileNimble(Rmodel)
Cmcmc <- compileNimble(Rmcmc, project = Rmodel)    ## fails here

## There is an error involving the type of neighborWeights.  Going into browser().
## Press Q to exit.FALSE
## Called from: doSetupTypeInference_processNF(setupSymTab, outputNames, instances,
##   add = TRUE)
## Browse[1]>
## debug: if (add) symTab$addSymbol(symbolRCobject)
## Browse[2]> Q
## Warning message:
## In makeTypeObject(name, instances, firstOnly) :
##   Problem, dimensions do no all match for neighborWeights

Other notes:

In the above example, if you comment out the line for(i in 1:L) {   weights[i] <- 1   }, and uncomment the line ##weights = rep(1,4),, this will get through the compiler.
I suspect the issue is coming from.  Nested in here:
Rmcmc$samplerFunctions[[1]]$componentSamplerFunctions[[1]]$dcar$neighborWeights
Rmcmc$samplerFunctions[[1]]$componentSamplerFunctions[[2]]$dcar$neighborWeights
Rmcmc$samplerFunctions[[1]]$componentSamplerFunctions[[3]]$dcar$neighborWeights

are vectors of neighborWeights, and from the warning message, it seems the length-1 ones are being inferred as scalars, and length-2 being inferred as a vector, causing the problem.

I am unable to reproduce this error outside of the car context.  Here is the example I tried on branch devel:
library(nimble)

m <- nimbleModel(
    nimbleCode({
        for(i in 1:L) x[i] <- 1
        a ~ dnorm(sum(x[1:L]), 1)
    }),
    constants = list(L = 3)
)

cm <- compileNimble(m, dirName = '.')
cm$x

When I install branch car, I can reproduce the example.  The warning message from makeTypeObject appears to be correctly informative.  If you run with options(error = recover) and when it stops look at lapply(instances, `[[`, 'neighborWeights'), two are scalar and one is vector.  This is a known problem corner in nimbleFunctions: all instances must have the same type for the same variables.  Workaround is to ensure they are all vectors and adjust in run code as needed.
Next question is why do we get different behavior between the two ways of setting up weights in your reproducible example.  I got as far as seeing that Rmodel$getParam('S[1:3]', 'weights') returns a 1D array in one case and a vector in another case.  This touches issues we've run into before about trying to ensure that the active bindings for model variables return consistent types.  It looks like sampler_CAR_normal calls weights <- Rmodel$getParam('S[1:3]', 'weights') (where target is S[1:3]).  Does any subsequent processing with weights behave differently for 1D array vs vector?  Can you take it from here @danielturek ?

@perrydv, for now I made a workaround in the CAR code so this isn't an issue.  Will revisit the deeper issue later.

@danielturek Sounds good.  I am closing this issue now.  You can open a new issue with more refined topic if necessary.   As of now it is not clear if the current topic qualifies as a bug.


Update build process for JDK 10 (javah removal)

javah has been superseded by the -h option added to javac in JDK 8.
The tool javah.exe was removed in Java 10.
(https://stackoverflow.com/questions/50352098/javah-missing-after-jdk-install)
Also clean output files generated by javac -h.
With this patch I was able to build with JDK 8 and JDK 11.
CI fails for JDK 7 — is it worth supporting that?

We can drop java7 build later. Thanks for the fix


How to identify currently used metrics?

I received an e-mail which advised me to transition to metrics in Azure Monitor, and which said

You're receiving this email because you use classic metrics in Azure Storage.

This documentation page was linked as providing information on the recommended action, and I hoped it would tell me how to find out which classic metrics I'm currently using and where, because I'm not aware of using them at all. However, all it says on the subject is

Compile a list of classic metrics that you currently use.

without any further information or hyperlink. How are we supposed to execute this step?

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

ID: df25630e-0d5f-aaa3-9630-82f11194ba10
Version Independent ID: b92ffb87-5ace-e8ea-0c2b-28e39871446e
Content: Move from Storage Analytics metrics to Azure Monitor metrics
Content Source: articles/storage/common/storage-metrics-migration.md
Service: azure-storage
Sub-service: storage-common-concepts
GitHub Login: @normesta
Microsoft Alias: normesta

@pjt33
Thanks for your feedback! We will investigate and update as appropriate.

We are currently facing the same Issue without having an Idea of what classic Metrics are used by us. The only thing i came across are the Diagnostic Settings (classic) which seem to be activated on each Storage Account by Default.

Following this thread to find the solution for the same alert we received, though there are no alerts configured with the classic metrics, the dashboard components use these metrics and there are huge number of tiles created in multiple dashboards which could contain these old metrics. How can we track all those and update to the new ones?

@pjt33
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly
@normesta
Can you please check and add your comments on this doc update request as applicable.

Hello. Classic metrics is now retired. From a documentation perspective, the only resource I'm aware of for looking at classic metrics is this article (which is archived now - https://learn.microsoft.com/en-us/previous-versions/azure/storage/common/manage-storage-analytics-metrics?source=recommendations&tabs=azure-portal.  If you have discovered an effective approach to parsing which metrics you were using (that is a solution not described by the archived article), please do share for whomever is monitoring this thread. Thank you!
#please-close


Embedding in electron and resizing causes webgl instance to become unrepsonsive

Please avoid duplicates

[X] I checked all open issues and discussions and none of them matched my problem.

Language and Compiler
Babel and WebPack TypeScript
What environment are you using?
Local Development Server
When does your problem occur?
When the Unity App is running
What does your problem relate to?
The problem seems Unity related
React-Unity-WebGL Version
^8.7.4
React Version
^17.0.2
Unity Version
2020.3.21f1
What happened?
Firstly thank you for this amazing and powerful project.
I am trying to embed the unity build in my electron renderer.
It works as expected however, I am running into some resizing/resolution issues that are causing some unexpected behavior.
export default function Gizmo() {
  const unityContext = new UnityContext({
    loaderUrl: '/public/Build/Build.loader.js',
    dataUrl: '/public/Build/Build.data',
    frameworkUrl: '/public/Build/Build.framework.js',
    codeUrl: '/public/Build/Build.wasm',
  });

  return (
    <Box id="GizmoViewer" h="100%" w="100%" bg="#121212">
      <Unity unityContext={unityContext} style={{ width: '100%', height: '100%' }} />
    </Box>
  );
}

After fullscreening the app and then unfullscreening, the webgl instance becomes unresponsive and I get this message:
Performance Warning: Recreating Offscreen FBO (2358x2340 => 2358x2370)
Quitting....
Done
How can I avoid the app quitting when changing the resolution?
Reproducible test case
No response
Would you be interested in contributing a fix?

[ ] yes, I would like to contribute a fix

Second Update:
I am still getting this conosle warning when resizing my browser:
Performance Warning: Recreating Offscreen FBO (1920x1200 => 2400x1880)
I found this https://forum.unity.com/threads/webgl-problem-performance-warning-recreating-offscreen-fbo-1920x1200-300x150.891103/ but the fix mentioned didnt work.
Why is the performance warning showing up and what does it mean?

Hi Jake!
I've never encountered this problem before. But it seems to be unrelated to this module, so I can't help you any further. I recommend keeping an eye on the Unity forums and perhaps opening a ticket in the Unity bug reporter.
For the time being, I'll convert this issue into a discussion so others might help you out.
Best of luck and happy coding!


HHH-18184 rescue<EMAIL_ADDRESS>

cc @sebersole

[Please describe here what your change is about]

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

https://hibernate.atlassian.net/browse/HHH-18184

Why?

Well, partly because it makes migration a little easier, but also just because our CacheMode is still a fully-supported part of our native API, in good standing, and we accept it in every other API where we accept the JPA enums.

Consistency, I guess. 🤷♂

Ok, you effectively changed the type here from CacheModeType to CacheMode.  Which I'm fine with.  But its not "just" restoring them

Yeah yeah it's not a roll back of your change.

Ok, I noted this change on the Jira


feat(styles): add palettes

To ease the review, the changes are grouped into 3 commits:

feat(styles): add palette styles
feat(docs): add palette stories
chore: add palette tests

Accessibility tests are failing because of incorrect tokens.

Tokens are now working for all theme and scheme combinations.
However, there's still a problem with the dark color scheme, which can be seen in the palettes documentation.
The problem seems to be that CSS custom properties declared in the :root cannot be overridden in child elements (see the CodePen reproduction).
Suggested solution:
The palettes logic is based on a workaround that uses hard-coded token maps from this file.
I therefore recommend using these token maps to define the foreground and background colors of each palette directly. This way, we avoid relying on CSS variables.

Limitations for the body color:

Already on main:
The data-color-scheme attribute does not set the body color (see this reproduction)
This issue will not be solved using the light-dark() CSS function (see this example)
Schematic of the issue:

🠊 Resolution: set the body color for each [data-color-scheme="*"] and .palette-* selector.

On this PR:
The body color is not correct for a palette that is used in nested color schemes (see this reproduction)
This issue will also not be solved using the light-dark() CSS function (see this example)
Schematic of the issue:

🠊 Resolution: make sure the color scheme can always be set on the palette directly and document the limitation.

Nice work!


Missing output when evaluating from a scheme buffer

Hello, try the following recipe:

M-x run-guile

Make a scheme buffer, paste and evaluate the following code there:
(define bad-port (current-output-port))
(define (message str) (display str bad-port))

Go to the REPL and run (message "hello\n") there.  There is no
hello output!

Now reevaluate bad-port definiton, but this time do it in the REPL.
And if you rerun message again, the output will be there!
You may repeat: if bad-port definition is evaluated from a scheme
buffer, the output does not appear, but if it is evaluated in the REPL,
it does.
(I checked it only with Guile)

Could not reproduce with Chicken:
#;1> (define bad-port (current-output-port))
#;7> (define (message str) (display str bad-port))
#;8> (message "Hello\n")
Hello
#;9> bad-port
#<output port "(stdout)">

Although, Chicken still has the hilarious numbering bug #58

It happens in Chicken, as well.

#;1> (message "Hello\n")
#;7> (define bad-port (current-output-port))
#;8> (message "Hello\n")
Hello

Also, note that #58 is still present.

Interestingly, this seems port-specific. It doesn't have the same effect with other symbols bound at that scope but of other types.

Hmm.
In a chicken buffer:
(define test-port (current-output-port))
(define (test-message) (display (->string test-port)))

Then in the REPL:
#;1> (test-message)
#<output port "(string)">

This makes sense. Geiser is capturing the response to the eval to a string; what seems to be happening is that data written to stdout isn't also captured, or somesuch.

This is a tricky bug, because it involves binding current-output-port; intuitively, it seems like the solution may have to be unhygienic. :disappointed:

when you evaluate from a scheme buffer, (current-output-port) evaluates to a string port (if you eval it while in the buffer you get something like <:output:string ...>), which is being used by guile's geiser eval function to capture the result of the evaluation, format it, and send it back to emacs.  that's done during a parameterization.  once the evaluation is finished that port is gone.  if you go to the REPL, no redirection is in place, and assigning bad-port there just works as expected (if you eval (current-ouput-port) in the REPL you'll see it's something like <output: file /dev/pts/4>).
so this behaviour is more or less to be expected.  fixing it is non-trivial.

I was thinking about this a little more this morning, and it strikes me that this is a symptom of interpreting code that violates convention. current-output-port is not designed to return a consistent value, but rather it returns whatever port is presently associated with output at the time of invocation; what port that is when invoked at top level is determined by how the Scheme code is invoked. The appropriate use is to invoke (current-input-port) as late as possible, at the time of execution.
IE, I wouldn't expect bad-port to represent a consistent port when executed with csi versus when its compiled with csc or called as a library via load or compile-file.
Now, I wonder what the behaviour for standard-output-port is?
http://www.scheme.com/tspl4/io.html#g124

yes, i think i agree with dan here... the current output ports when
you're in the buffer and we are in the repl are simply different, and
one cannot expect them to be equal... perhaps there's a stronger case to
be made for current-output-port to be the same for all evaluations in a
buffer, but i'm not sure the implementation effort that guarantee would
entail is worth it...

It appears that standard-output-port is unavailable in Chicken.
I vote to close this. :smile:

+1 :) what do you think, alex? do you have a use case in mind where it'd
be important to have a better behaviour?

Yes, there is a use case in GNU Guix.  We have current-build-output-port (http://git.savannah.gnu.org/cgit/guix.git/tree/guix/store.scm#n381) there.  And the problem is when (use-modules ...) clause is evaluated from a scheme buffer, this build output (which is highly important) disappears.
I opened this issue after facing this problem in Guix: http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00130.html
So it would be really great if this could be solved, but I see that it's not easy.

Why not:
(define current-build-output-port
;; The port where build output is sent.
(lambda () (current-error-port)))
Alex Kost<EMAIL_ADDRESS>writes:

Yes, there is a use case in GNU Guix.  We have current-build-output-port (http://git.savannah.gnu.org/cgit/guix.git/tree/guix/store.scm#n381) there.  And the problem is when (use-modules ...) clause is evaluated from a scheme buffer, this build output (which is highly important) disappears.
I opened this issue after facing this problem in Guix: http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00130.html
So it would be really great if this could be solved, but I see that it's not easy.

Reply to this email directly or view it on GitHub:
https://github.com/jaor/geiser/issues/83#issuecomment-138692936

--
-Dan Leslie

Why not:
(define current-build-output-port
  ;; The port where build output is sent.
  (lambda () (current-error-port)))

I guess that with a parameter, it will be bound to a single port.  While
if it's a procedure it may return different ports, because the error
port may change.  But thank you!  This is an interesting proposal, I'll
ask about it on guix mailing list.

It can be improved:
(define current-build-output-port current-error-port)

Sure, I understand :smile:

Can we close this issue, @jaor ?

what do you think, @alezost ? if guix can solve this issue by its own means, it'll save us lots of headaches :)

Oh yes, sorry I forgot about this one.  We have a workaround for this in Guix, so I don't mind if it will be closed, thanks.

Hello, I stumble on this issue today. It took me a couple hours figuring out what was at cause and doing the background research. That this bug was closed didn't help :).
In my case, simply re-evaluating a Scheme buffer twice leads to missing output. My repro is not as trivial as the one of @alezost, but I hope it can show a representative use case:
;;; REPRO STEPS:
;;;
;;; 0. C-z to start the Geiser's Guile REPL.
;;;
;;; 1. C-c C-b to evaluate once. You should see in the output:
;;;
;;;   => #t
;;;
;;;   current-warning-port: #<output: string 255fc40>
;;;   guix-warning-port: #<output: string 255fc40>
;;;   current-error-port: #<output: string 255fc40>
;;;   current-build-output-port: #<output: string 255fc40>
;;;   error: bad-arg: unrecognized option
;;;   Caught exception: (quit 1)
;;;
;;; Notice the error output: error: check: unrecognized option
;;;
;;; 2. C-c C-b again. Now the error output is gone:
;;;
;;;
;;;   => #t
;;;
;;;   current-warning-port: #<output: string 481ab60>
;;;   guix-warning-port: #<output: string 255fc40>
;;;   current-error-port: #<output: string 481ab60>
;;;   current-build-output-port: #<output: string 255fc40>
;;;   Caught exception: (quit 1)

(use-modules (gnu packages)
	     (gnu packages version-control)
	     (guix download)
	     (guix packages)
	     (guix scripts download)
	     (guix store)
	     (guix ui))

(define (check-package-source package)
  "Fetch the archive of a package.  Assumes the definition of PACKAGE
contains an origin using the url-fetch method."
  (catch #t
    (lambda ()
      (guix-download "--bad-arg" (origin-uri (package-source package))))
    (lambda (arg . rest)
      (format #t "Caught exception: ~a~%" (cons arg rest)))))

(format #t "current-warning-port: ~a~%" (current-warning-port))
(format #t "guix-warning-port: ~a~%" (guix-warning-port))
(format #t "current-error-port: ~a~%" (current-error-port))
(format #t "current-build-output-port: ~a~%" (current-build-output-port))

(check-package-source libgit2)

I discussed the issue in #guile but the solutions discussed above (such as making current-build-output-port a procedure) were not deemed adequate. In Guile at least, current-error-port) is a SRFI-39 parameter, just like current-build-output-port in Guix. Both are set to an initial value.


Repo sync for protected CLA branch

The pull request is created from master637340601038387829 to master to fix git push error for protected CLA branch

@ghogen : Thanks for your contribution! The author(s) have been notified to review your proposed change. @evanwindom


ghc: 965 -> 966

Update cabal indicies
Update CHaP
Add upper bound on hspec-junit-formatter
Stop using patched hls
Regenerate plutus scripts
Drop constraint on io-classes-mtl

https://github.com/haskell/haskell-language-server/issues/4046 looks fixed to me.

Well.. seems due to auto-merge like that time is now @locallycompact :D


Add quarkssecret codebase

#172645662

Bit hard to review this one :)
I'll approve it, but I think it's missing the new shared bin scripts and github actions

Bit hard to review this one :)
I'll approve it, but I think it's missing the new shared bin scripts and github actions

okay. They are part of another story - https://www.pivotaltracker.com/n/projects/2192232/stories/169095389


'generating pdf...🔄🔄' notification

Currently the PDF takes about 5-6secs to generate.
For that small interval a popup must come up saying
"Generating PDF. please wait..."
I am a GSSOC particpant

I would like to work on this issue. Kindly assign this to me. I am a  GSSOC'21 particpant.

I would like to work on this issue. Kindly assign this to me. I am a GSSOC'21 particpant.

Keep in mind, the participant who raises the issue would be assigned it by default, only for issues raised by mentors we can consider others with equal preference.
If @ashuvssut fails to complete this, it will be assigned to you


Move language standard baseline to C++11?

The current language standard baseline is C++03 (see STYLE_GUIDE.md).
Thoughts on whether we should move to supporting C++11?
One use case was raised in #3877.

I am in favor in general. We should consider the list of the features that would be helpful (auto, ranged-for loops, constexpr,  enum class, etc.) and if there are any features we may want to limit the use of?
(new function syntax with -> to specify return type, lambda with capture?)

As C++ 20 is coming I think that we may consider newer standards as well (if they have features that may help us). Also we are building with std=gnu++98 configured currently, not 03. And the Android build have no standard defined (I cannot see any std= flag when running Android build on Travis)

Here is a nice brief of new features in each version: https://github.com/AnthonyCalandra/modern-cpp-features

@KaSroka, we can consider adopting newer versions of the C++ language standard. At the same time, we should also consider compiler support as well. If there are good use cases for using newer language features that are well supported by compilers, we can discuss further.

After looking into features of C++14 and 17 i cannot see any features that may help us maybe except relaxed requirements of constexpr in C++14 as well as no implicit const when using them.

Personally I found such code snippet to be appealing if we can adopt C++11 (which introduces argument pack in templates and std::forward):
#include <utility>

extern void LogInfo(const char *format, ...);

template <typename classname, typename U, typename RetType, typename ... ArgType>
class CtxBinder {
public:
    typedef RetType (classname::*Funct)(ArgType...);

    CtxBinder(U ctx, Funct f)
        :mctx(ctx), mf(f) {
    }

    RetType operator()(ArgType... args) {
       return (mctx->*mf)(std::forward<ArgType...>(args...));
    }

private:
    U mctx;
    Funct mf;
};

class A {
public:
    A();

    void f(int x);

    void trigger();

private:
    CtxBinder<A, A*, void, int> mf;
};

A::A()
    :mf (this, &A::f) {
}

void A::f(int x) {
    LogInfo("%d\n", x);
}

void A::trigger() {
    mf(1);
}

A quick test showed that such pattern of binding this to member functions gives even smaller code size than currently used static function and context pattern. The static function code segment can be removed in the final -Os output. Such pattern also will reduce duplicate code only forwarding arguments to member functions.
However, std::function and lambda on the other hand, significantly increases the code size, which should be forbidden.

Based on feedback in #3899, will not pursue C++11 for now.

Based on new feedback https://github.com/openthread/openthread/pull/3899#issuecomment-639715510, reopening this issue again.
Please provide updated thoughts on whether we should move to supporting C++11.


Dispatcher Retry & Dead Letter Queues

Currently the implementation has custom retry logic which is preventing the use of the eventing MessageDispatcher.DispatchMessage()'s ability to send to the Dead Letter Queue.  Doing so would result in a separate Dead Letter Queue message for every retry attempt.  Need to look at retry implementations in conjunction with the Knative Eventing implementations to design a more flexible solution.

Hi @travis-minke-sap , I would like to work on this. Is it possible to kindly assign this to me?

/assign @sbcd90
Sure, give it a shot! It's possible that some change might be required for the eventing library.  The goal here is to share library usage with eventing, but maintain the ability for a reasonable retry, some of which now spans the cloud event sdk (v2 usage coming in an open pr).  Some configurability might need to be added separately there or the knative library as per some discussions in the WG.  Take a look and sketch out your approach/proposal and we can discuss on Wednesday (we have a holiday until then)

Hi @davyodom , thanks a lot. I created a document to initially propose my approach & trigger further discussions.
https://docs.google.com/document/d/1z3psNbyH7YnskzgzjLPdOFcLel4npld0ea7YwUJkZ4o/edit?usp=sharing

Hi @sbcd90 - Thanks for putting together the proposal!  Unfortunately I don't think what you're suggesting will meet our requirements / needs.  Aside from being rather heavy-weight in it's use of another Topic / Consumer, it breaks our in-order guarantees by going async.  I haven't done much investigation into possible solutions as of yet, but my initial thought was one of the following...

A small change to what we currently have whereby we detect the fact that we're on the "last" retry attempt, and then pass the DeadLetter to the MessageDispatcher.  This is essentially the Max no. of retries reached decision point in your proposed solution.  I have no idea how easy/hard that might be.

Stepping back and taking a larger view by digging into the Knative MessageDispatcher implementation to see whether it could natively support the "retry" ability for all channels (optional, configurable, etc.) thereby eliminating the need for our wrapping retry library.  This might be achieved via the native CloudEvent retry capability which I don't believe Knative is currently making use of.

...and we're certainly open to other ideas / approaches as well as long as they preserve our at-least-once / in-order guarantees and don't impact cluster resource consumption and / or performance too much.

Hi @travis-minke-sap , thanks a lot for sharing your thoughts. I'll focus on point 1 first.
& then once it is solved, look into point 2.

Somewhat relevant here : https://github.com/knative/eventing/issues/2411

Hey there @sbcd90 - I was out for a couple days - I'll take a look at your PR now/soon ; )

In case anyone is still looking at this...
as part of the Sarama conversion #31 - I'll be handling the DLQ there so this should not be worked - will close once #31 is completed.

Thanks a lot @tminke for informing. Is introduction of ‘resolver’ still something that can be worked on?


Feature/slim 1964 introduce device last seen status

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 RegisterDeviceMessageProcessor.java#L41: Make this IP "<IP_ADDRESS>" address configurable.


Fix bugs in how aperture correction is applied

This PR does the following:

Applies the aperture correction to the magnitudes in the sn2 file
Set threshold for the PSF stage failing and cause it to fail. This is currently set at 0.1 but should be set to a number acceptable to LCO once PR #52 is merged and the database has been back populated
The code exits with an error message when filetype=3 and type=fit and stage=mag (aperture photometry should be sufficient for difference imaging)
When HOTPANTS is run, look at the aperture correction from the correct, original sn2 file rather than the diff image sn2 file
When PyZOGY is run the aperture correction is set to 0

Testing
Test that if the aperture correction is too big the PSF will not be calculated:
When run on the master branch, this command should update the PSF column with a filename even though the aperture correction is over 1 magnitude (make sure to replace the catalog with the default apass catalog on your machine)
lscloop.py -n 2016cok -e 20180104 -f r -s psf -F --catalog /dark/anaconda/anaconda27/envs/halenv/lib/python2.7/site-packages/lsc/standard/cat/apass/AT2016cok_apass.cat

When run in the new branch is run, a message that the aperture correction is too big and that the PSF is not calculated will be printed and the PSF column will be updated with X
Test the update to the sn2 files
I ran the following command on the master branch and read the sn2 file into an ipython session.
lscloop.py -n 2016cok -e 20180104 -f r -s psf -F --id 238

ipython
from astropy.io import fits
from astropy.io.fits import FITSDiff
ofile = fits.open('../data/lsc/20180104/coj1m011-fl12-20180104-0238-e91.sn2.fits')

I switched branches (and re-installed) and ran the same command. I then read the sn2 file into a different variable in the ipython session.
ofile = fits.open('../data/lsc/20180104/coj1m011-fl12-20180104-0238-e91.sn2.fits')
diff = FITSDiff(ofile, ofile2, ignore_fields=('smagf', 'smagerrf'))
print(diff.report())

The only differences should be the CHECKSUM keyword and comment and DATASUM comment
set(np.round(ofile2[1].data['smagf']-ofile[1].data['smagf'], 3))

The set should return 0 and 0.041
set(np.round(tbdata2['smagerrf']-np.sqrt(0.024**2 + tbdata['smagerrf']**2), 3))

This set should return 0 and 0.001. Inspecting the points that result in 0.001, the I suspect this is a rounding issue resulting from reporting only 3 decimals for both the aperture correction error and the psf magnitude error to 3 decimals.
Test that PSF photometry is not performed on difference images
The default filetype=1 and type=fit
Test that HOTPANTS difference imaging with PSF photometry produces an Exception
lscloop.py -n 2016cok -e 20160601-20160701 -f r -s mag --filetype 3 --difftype 0

Test that PyZOGY difference imaging with PSF photometry produces an Exception
lscloop.py -n 2016cok -e 20160601-20160701 -f r -s mag --filetype 3 --difftype 1

Test that HOTPANTS difference imaging with aperture photometry runs
lscloop.py -n 2016cok -e 20160601-20160701 -f r -s mag --filetype 3 --difftype 1 --type ph

Test that PyZOGY difference imaging with aperture photometry runs
lscloop.py -n 2016cok -e 20160601-20160701 -f r -s mag --filetype 3 --difftype 0 --type ph

Test that non-difference imaging with PSF photometry runs
lscloop.py -n 2016cok -e 20160601-20160701 -f r -s mag

Test change in logic about where aperture correction is read from
For testing this branch, I created a new testing branch from the bugfix/apercorr branch and merged in the feature/add_apercorr_column branch so that I could view the aperture correction that were applied in each scenario
Test that the original image gets the right aperture correction
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s psfmag -F

Aperture correction between the psf and psfmag stage should be the same (-0.051). This is printed to the screen in an update command at both stages
Test merged image has its own aperture correction
lscloop.py -n 2016cok -e 20160529 -f r -s merged
lscloop.py -n 2016cok -e 20160529 -f r --filetype 2 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --filetype 2 -s psfmag -F

Test that for the template image the same aperture correction is applied whether the filetype is 1 or 4
lscloop.py -n 2016cok -e 20180104 -f r --id 238 -s psf -F
lscloop.py -n 2016cok -e 20180104 -f r --id 238 -s psfmag -F

lscloop.py -n 2016cok -e 20180104 -f r --id 238 -s template
lscloop.py -n 2016cok -e 20180104 -f r --id 238 --filetype 4 -s cosmic -F
lscloop.py -n 2016cok -e 20180104 -f r --id 238 --filetype 4 -s psf -F
lscloop.py -n 2016cok -e 20180104 -f r --id 238 --filetype 4 -s psfmag -F

The aperture correction for all psf and psfmag stages should be -0.0412
Test that no aperture correction is applied to difference imaging with PyZOGY
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s cosmic -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize t -T kb --temptel fl --tempdate 20180104 --difftype 1 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 1 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 1 -s psfmag -F

An aperture correction of 0 should be printed in the UPDATE statements for both the psf and the psfmag stages
Repeat for normalizing to image
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize i -T kb --temptel fl --tempdate 20180104 --difftype 1 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 1 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 1 -s psfmag -F

An aperture correction of 0 should be printed in the UPDATE statements for both the psf and the psfmag stages
Test that image aperture correction is applied when the image PSF (--convolve i) is used with HOTPANTS
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize t --convolve i -T kb --temptel fl --tempdate 20180104 --difftype 0 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psfmag -F

The aperture correction for the psfmag stage should be -0.051 (matching the image)
Repeat for normalizing to the image
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize i --convolve i -T kb --temptel fl --tempdate 20180104 --difftype 0 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psfmag -F

Test that template aperture correction is applied when the template PSF (--convolve t) is used with HOTPANTS
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize t --convolve t -T kb --temptel fl --tempdate 20180104 --difftype 0 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psfmag -F

The aperture correction for the psfmag stage should be -0.0412 (matching the image)
Repeat for normalizing to the image
lscloop.py -n 2016cok -e 20160529 -f r --id 116 -s diff  --normalize i --convolve t -T kb --temptel fl --tempdate 20180104 --difftype 0 -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psf -F
lscloop.py -n 2016cok -e 20160529 -f r --id 116 --filetype 3 --difftype 0 -s psfmag -F

The aperture correction for the psfmag stage should be -0.0412 (matching the image)

I would also note that I couldn't get the pipeline to create a merged file, so this has not been tested on filetype 2 files, although I don't expect anything to fail and I don't think this should stop this PR from being merged

Merging this after PR #52 results in the following conflict:
<<<<<<< HEAD
            aperture_correction = np.mean(_dmag)
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCO': (aperture_correction, 'Aperture correction')})
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCOERR': (np.std(_dmag), 'Aperture correction error')})
=======
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCO': (aperture_correction, 'Aperture correction')})
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCOERR': (aperture_correction_err, 'Aperture correction error')})
>>>>>>> bugfix/apercorr

Which should be resolved by keeping the bottom section like this:
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCO': (aperture_correction, 'Aperture correction')})
            lsc.util.updateheader(img + '.sn2.fits', 0, {'APCOERR': (aperture_correction_err, 'Aperture correction error')})

I just noticed that the filename was wrong and so the psf column was never set to X. Please check that in addition to printing to the screen the the PSF was not done, that the database has also been set to X

This also fixes a bug in the way the psf column was updated when the PSF stage failed and the attempt to apply that to difference imaging. First, there was inconsistency in the code about whether basename and img contained the .fits extension. Additionally, there was an attempt to update the sn2 file and the PSF stage in the difference image if the original PSF was updated. However, due to changes in the way the difference images are named (they include the template's telescope), these files were never found and this row was never updated and the sn2 files were not copied. I decided to remove the difference image part of the code and leave it up to the user to update the difference imaging analysis if the original PSF is changed.

Implications of the bugs that this PR fixes for past data reductions:

the aperture correction was not applied to the sn2 file. Since this file is used to calculate the zero point, all apparent magnitudes calculated prior to this PR are incorrect by their aperture correction
when difference imaging was run, the sn2 file for the difference image was a copy of either the sn2 file of the original image or the sn2 file of the template image, determined by the normalization.

For HOTPANTS, the aperture correction should correspond to the convolution, not the normalization. Since the aperture correction was read from the sn2 file for the difference image, when the normalization did not match the convolution, the wrong aperture correction was applied to the instrumental magnitude. Since no correction was applied to the sn2 file, this compounds with the error introduced by the previous point.
For PyZOGY, the PSF used matches neither the the original image nor the template image and therefore neither aperture correction is appropriate to apply

Can you explain why you deleted some SExtractor files in this PR? When trying to do difference imaging using my Dockerized pipeline it fails because it can't find those files.

These files were deleted when I moved the standard directory out of $LCOSNPIPE and into $LCOSNDIR. @cmccully did I move too many files? Should I have just moved the cat directory?

I've added back in the src/lsc/standard files, we can sort out in a different PR if these are needed

Test that default type for filetype 3 is ph and filetype 1 is fit (I don't think the fit matters for filetype 4, since the stages you run on templates don't use the fit)
filetype=3, no type specified (should be ph by default), difftype=0
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat --filetype 3 --difftype 0 -F

I'm not sure how to check what type was used, but this runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag --filetype 3 --difftype 0 -F

This should print:
calibratemag.py _tmp.list -s mag -t ph -f sloan -F
You are specifically looking for -t ph
filetype=3, type=fit, difftype=0
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat --filetype 3 --difftype 0 -F --type fit

I'm not sure how to check what type was used, but this runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag --filetype 3 --difftype 0 -F --type fit

This should print:
/dark/anaconda/anaconda27/envs/haltest/bin/lscloop.py:228: UserWarning: Aperture photometry recommended for difference images (--type ph)
  warnings.warn('Aperture photometry recommended for difference images (--type ph)', UserWarning)
calibratemag.py _tmp.list -s mag -t fit -f sloan -F

You are specifically looking for a UserWarning being raised and that -t fit is present in the calibratemag.py line
filetype not specified, type not specified
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat -F

I don't know how to test this, but it runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag

This should print:
calibratemag.py _tmp.list -s mag -t fit -f sloan -F

You are looking for -t fit
filetype not specified, type=ph
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat --type ph -F

I don't know how to test this, but it runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag --type ph -F

This should print:
calibratemag.py _tmp.list -s mag -t ph -f sloan -F

You are looking for -t ph
filetype=3, no type specified (should be ph by default), difftype=1
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat --filetype 3 --difftype 1 -F

I'm not sure how to check what type was used, but this runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag --filetype 3 --difftype 1 -F

This should print:
calibratemag.py _tmp.list -s mag -t ph -f sloan -F
You are specifically looking for -t ph
filetype=3, type=fit, difftype=1
zcat stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s zcat --filetype 3 --difftype 1 -F --type fit

I'm not sure how to check what type was used, but this runs
mag stage
lscloop.py -n 2016cok -e 20160530 -f sloan -s mag --filetype 3 --difftype 1 -F --type fit

This should print:
/dark/anaconda/anaconda27/envs/haltest/bin/lscloop.py:228: UserWarning: Aperture photometry recommended for difference images (--type ph)
  warnings.warn('Aperture photometry recommended for difference images (--type ph)', UserWarning)
calibratemag.py _tmp.list -s mag -t fit -f sloan -F

You are specifically looking for a UserWarning being raised and that -t fit is present in the calibratemag.py line
Test use of --max_apercorr flag to change default aperture correction maximum value
lscloop.py -n 2016cok -e 20180104 -f r -s psf -F --catalog /dark/hal/lcosn/standard/cat/apass/AT2016cok_apass.cat

This should fail because the aperture correction is too big and PSF should be set to 'X'
lscloop.py -n 2016cok -e 20180104 -f r -s psf -F --catalog /dark/hal/lcosn/standard/cat/apass/AT2016cok_apass.cat --max_apercorr 2

This should work and PSF should be set to the PSF filename

I repeated the above tests and for a variety of commands I ran, the default for filetype 3 is ph and for filetype 1 is fit. The --max_apercorr flag also works as expected.


Spontaneous line wrap in the middle of shell prompt

This issue has originally been reported here for Teleprot project which uses term.js
We have verified that it's not related to anything on the server.

Details
Sometimes when I'm connected to a server via the WebUI the server prompt starts to jump.
Video:
https://www.youtube.com/watch?v=Tx5EGXDXjUk&feature=youtu.be
Chrome on Chrome OS
Version 52.0.2743.116 (64-bit)
Platform 8350.68.0 (Official Build) stable-channel gandof
Firmware Google_Gandof.6301.155.9
Steps to reproduce
Unfortunately we can't figure out how to reproduce it outside of this one laptop. We have tried Asus Chromebox to no avail.

Can you reproduce on the xterm.js demo? It looks like it's related to the blinking cursor, you may have styles that change .terminal-cursor or something?

We (Teleport team) so far were unable to reproduce (do not have access to the server&laptop of the person who've reported it). But yes - we're trying and we'll continue trying, including your suggestion. :-) Reporting here just in case you guys have seen this or have suggestions to reproduce.

Also if you use chjj/term.js and not xterm.js we may not be able to help. The codebase has diverged quite a bit at this point around row/col logic with the introduction of IME support and scroll bars.

@Tyriar yep, we're re-vendoring to the latest ASAP. Thanks.

@kontsevoy are you still experiencing this?

@Tyriar nope. seems to be gone. Thanks.

Awesome :+1:


Can we conclude this Github-repo is dead?

The last change made to this repo dates back in 2020... Espressif for example has improved their embedded MQTT capabilities in ESP-IDF. Wouldn't it be much easier to make the embedded MQTT of Espressif work inside the Arduino IDE?

@knolleary Is there a way that we can support you? currently I have the feeling this repository is dead, but there are a lot of great improvements in the PR. I can totally understand that family or other things are getting more important in live.
Would it be possible to move this repository to somebody else that this code and all PR are not dead anymore?
Why moving and not just forking? Because github will create a internal link to the new owner and copy all open tickets and PR to the new repository.
I am happy to here from you @knolleary!
BR Peter

Looks like it.


bit-width issue in model prepared for QAT

I am using the QAT scripts for ImageNet training with 4-bit QAT. I tried both academic and tensorrt backend with following config passed to prepare_by_platform().
extra_qconfig_dict:
w_observer: LSQObserver
w_fakequantize: LearnableFakeQuantize
w_qscheme:
bit: 4
symmetry: True
per_channel: False
pot_scale: False
symmetric_range: True
a_observer: LSQObserver
a_fakequantize: LearnableFakeQuantize
a_qscheme:
bit: 4
symmetry: True
per_channel: False
pot_scale: False
symmetric_range: True
When I check the network in the forward pass, the bit-width is 3 instead of 4.

I just checked the prepare process with the provided config, for weight:
 (conv2): Conv2d(
      64, 64, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1), bias=False
      (weight_fake_quant): LearnableFakeQuantize(
        fake_quant_enabled=tensor([1], device='cuda:0', dtype=torch.uint8), observer_enabled=tensor([1], device='cuda:0', dtype=torch.uint8), quant_min=-8, quant_max=6, dtype=torch.qint8, qscheme=torch.per_tensor_symmetric, ch_axis=-1, scale=Parameter containing:
        tensor([1.], device='cuda:0', requires_grad=True), zero_point=Parameter containing:
        tensor([0.], device='cuda:0', requires_grad=True)
        (activation_post_process): LSQObserver(min_val=inf, max_val=-inf ch_axis=-1 pot=False)
      )
    )

for acti:
LearnableFakeQuantize(
  fake_quant_enabled=tensor([1], device='cuda:0', dtype=torch.uint8), observer_enabled=tensor([1], device='cuda:0', dtype=torch.uint8), quant_min=-8, quant_max=6, dtype=torch.qint8, qscheme=torch.per_tensor_symmetric, ch_axis=-1, scale=Parameter containing:
  tensor([1.], device='cuda:0', requires_grad=True), zero_point=Parameter containing:
  tensor([0.], device='cuda:0', requires_grad=True)
  (activation_post_process): LSQObserver(min_val=inf, max_val=-inf ch_axis=-1 pot=False)
)

Though not a full 4bit, it is much more than 3 bit.
I found that you use symmetric range and symmetric quant at the same time, which resulted in the non-symmetric quantization. The source could be checked here https://github.com/ModelTC/MQBench/blob/main/mqbench/observer.py.

When I check the unique values after quantization in the graph module during forward pass, they are exactly 3 bits, i.e. 8 unique values.  I check this by printing the values of input after quantization in the graph code generated by fx. There is also a parameter called bit-width which is set to 3 in the graph. I could not figure out how that bit-width parameter is estimated as its not set same as one in the config..
Can you suggest how can i exactly use full 4 bits?

** they are exactly 3 bits, i.e. 8 unique values.** I wonder which 7 values were shown in your model.
You can follow the example we provided at imagenet_example:
extra_prepare_dict:
    extra_qconfig_dict:
        w_observer: MSEObserver
        a_observer: EMAMSEObserver
        w_fakequantize: AdaRoundFakeQuantize
        a_fakequantize: QDropFakeQuantize
        w_qscheme:
            bit: 4
            symmetry: False
            per_channel: True
            pot_scale: False
            p: 2.4
        a_qscheme:
            bit: 4
            symmetry: False
            per_channel: False
            pot_scale: False
            p: 2.4

Unless some hardware(backend) needs a symmetric_range like [-7,7] rather that [-8,7], we do not set this attribute. That is, if you use academic backend, do not use this.

I tried the same experiment with following config:
extra_qconfig_dict:
w_observer: LSQObserver
w_fakequantize: LearnableFakeQuantize
w_qscheme:
bit: 4
symmetry: True
per_channel: False
pot_scale: False
symmetric_range: False
a_observer: LSQObserver
a_fakequantize: LearnableFakeQuantize
a_qscheme:
bit: 4
symmetry: True
per_channel: False
pot_scale: False
symmetric_range: False
I debug the model(x) forward pass by printing out the values inside the graph of quantized mobilenetv2. Below is the graph code returned for quantized model.
def forward(self, x : torch.Tensor) -> torch.Tensor:     x_post_act_fake_quantizer = self.x_post_act_fake_quantizer(x);  x = None     features_0_0 = getattr(getattr(self.features, "0"), "0")(x_post_act_fake_quantizer);  x_post_act_fake_quantizer = None     features_0_2 = getattr(getattr(self.features, "0"), "2")(features_0_0);  features_0_0 = None     features_0_2_post_act_fake_quantizer = self.features_0_2_post_act_fake_quantizer(features_0_2);  features_0_2 = None     features_1_conv_0_0 = getattr(getattr(getattr(self.features, "1").conv, "0"), "0")(features_0_2_post_act_fake_quantizer);  features_0_2_post_act_fake_quantizer = None     features_1_conv_0_2 = getattr(getattr(getattr(self.features, "1").conv, "0"), "2")(features_1_conv_0_0);  features_1_conv_0_0 = None     features_1_conv_0_2_post_act_fake_quantizer = self.features_1_conv_0_2_post_act_fake_quantizer(features_1_conv_0_2);  features_1_conv_0_2 = None     features_1_conv_1 = getattr(getattr(self.features, "1").conv, "1")(features_1_conv_0_2_post_act_fake_quantizer);  features_1_conv_0_2_post_act_fake_quantizer = None     features_1_conv_1_post_act_fake_quantizer = self.features_1_conv_1_post_act_fake_quantizer(features_1_conv_1);  features_1_conv_1 = None     features_2_conv_0_0 = getattr(getattr(getattr(self.features, "2").conv, "0"), "0")(features_1_conv_1_post_act_fake_quantizer);  features_1_conv_1_post_act_fake_quantizer = None     features_2_conv_0_2 = getattr(getattr(getattr(self.features, "2").conv, "0"), "2")(features_2_conv_0_0);  features_2_conv_0_0 = None     features_2_conv_0_2_post_act_fake_quantizer = self.features_2_conv_0_2_post_act_fake_quantizer(features_2_conv_0_2);  features_2_conv_0_2 = None     features_2_conv_1_0 = getattr(getattr(getattr(self.features, "2").conv, "1"), "0")(features_2_conv_0_2_post_act_fake_quantizer);  features_2_conv_0_2_post_act_fake_quantizer = None     features_2_conv_1_2 = getattr(getattr(getattr(self.features, "2").conv, "1"), "2")(features_2_conv_1_0);  features_2_conv_1_0 = None     features_2_conv_1_2_post_act_fake_quantizer = self.features_2_conv_1_2_post_act_fake_quantizer(features_2_conv_1_2);  features_2_conv_1_2 = None     features_2_conv_2 = getattr(getattr(self.features, "2").conv, "2")(features_2_conv_1_2_post_act_fake_quantizer);  features_2_conv_1_2_post_act_fake_quantizer = None     features_2_conv_2_post_act_fake_quantizer = self.features_2_conv_2_post_act_fake_quantizer(features_2_conv_2);  features_2_conv_2 = None     features_3_conv_0_0 = getattr(getattr(getattr(self.features, "3").conv, "0"), "0")(features_2_conv_2_post_act_fake_quantizer)     features_3_conv_0_2 = getattr(getattr(getattr(self.features, "3").conv, "0"), "2")(features_3_conv_0_0);  features_3_conv_0_0 = None     features_3_conv_0_2_post_act_fake_quantizer = self.features_3_conv_0_2_post_act_fake_quantizer(features_3_conv_0_2);  features_3_conv_0_2 = None     features_3_conv_1_0 = getattr(getattr(getattr(self.features, "3").conv, "1"), "0")(features_3_conv_0_2_post_act_fake_quantizer);  features_3_conv_0_2_post_act_fake_quantizer = None     features_3_conv_1_2 = getattr(getattr(getattr(self.features, "3").conv, "1"), "2")(features_3_conv_1_0);  features_3_conv_1_0 = None     features_3_conv_1_2_post_act_fake_quantizer = self.features_3_conv_1_2_post_act_fake_quantizer(features_3_conv_1_2);  features_3_conv_1_2 = None     features_3_conv_2 = getattr(getattr(self.features, "3").conv, "2")(features_3_conv_1_2_post_act_fake_quantizer);  features_3_conv_1_2_post_act_fake_quantizer = None     features_3_conv_2_post_act_fake_quantizer = self.features_3_conv_2_post_act_fake_quantizer(features_3_conv_2);  features_3_conv_2 = None     add_1 = features_2_conv_2_post_act_fake_quantizer + features_3_conv_2_post_act_fake_quantizer;  features_2_conv_2_post_act_fake_quantizer = features_3_conv_2_post_act_fake_quantizer = None     add_1_post_act_fake_quantizer = self.add_1_post_act_fake_quantizer(add_1);  add_1 = None     features_4_conv_0_0 = getattr(getattr(getattr(self.features, "4").conv, "0"), "0")(add_1_post_act_fake_quantizer);  add_1_post_act_fake_quantizer = None     features_4_conv_0_2 = getattr(getattr(getattr(self.features, "4").conv, "0"), "2")(features_4_conv_0_0);  features_4_conv_0_0 = None     features_4_conv_0_2_post_act_fake_quantizer = self.features_4_conv_0_2_post_act_fake_quantizer(features_4_conv_0_2);  features_4_conv_0_2 = None     features_4_conv_1_0 = getattr(getattr(getattr(self.features, "4").conv, "1"), "0")(features_4_conv_0_2_post_act_fake_quantizer);  features_4_conv_0_2_post_act_fake_quantizer = None     features_4_conv_1_2 = getattr(getattr(getattr(self.features, "4").conv, "1"), "2")(features_4_conv_1_0);  features_4_conv_1_0 = None     features_4_conv_1_2_post_act_fake_quantizer = self.features_4_conv_1_2_post_act_fake_quantizer(features_4_conv_1_2);  features_4_conv_1_2 = None     features_4_conv_2 = getattr(getattr(self.features, "4").conv, "2")(features_4_conv_1_2_post_act_fake_quantizer);  features_4_conv_1_2_post_act_fake_quantizer = None     features_4_conv_2_post_act_fake_quantizer = self.features_4_conv_2_post_act_fake_quantizer(features_4_conv_2);  features_4_conv_2 = None     features_5_conv_0_0 = getattr(getattr(getattr(self.features, "5").conv, "0"), "0")(features_4_conv_2_post_act_fake_quantizer)     features_5_conv_0_2 = getattr(getattr(getattr(self.features, "5").conv, "0"), "2")(features_5_conv_0_0);  features_5_conv_0_0 = None     features_5_conv_0_2_post_act_fake_quantizer = self.features_5_conv_0_2_post_act_fake_quantizer(features_5_conv_0_2);  features_5_conv_0_2 = None     features_5_conv_1_0 = getattr(getattr(getattr(self.features, "5").conv, "1"), "0")(features_5_conv_0_2_post_act_fake_quantizer);  features_5_conv_0_2_post_act_fake_quantizer = None     features_5_conv_1_2 = getattr(getattr(getattr(self.features, "5").conv, "1"), "2")(features_5_conv_1_0);  features_5_conv_1_0 = None     features_5_conv_1_2_post_act_fake_quantizer = self.features_5_conv_1_2_post_act_fake_quantizer(features_5_conv_1_2);  features_5_conv_1_2 = None     features_5_conv_2 = getattr(getattr(self.features, "5").conv, "2")(features_5_conv_1_2_post_act_fake_quantizer);  features_5_conv_1_2_post_act_fake_quantizer = None     features_5_conv_2_post_act_fake_quantizer = self.features_5_conv_2_post_act_fake_quantizer(features_5_conv_2);  features_5_conv_2 = None     add_2 = features_4_conv_2_post_act_fake_quantizer + features_5_conv_2_post_act_fake_quantizer;  features_4_conv_2_post_act_fake_quantizer = features_5_conv_2_post_act_fake_quantizer = None     add_2_post_act_fake_quantizer = self.add_2_post_act_fake_quantizer(add_2);  add_2 = None     features_6_conv_0_0 = getattr(getattr(getattr(self.features, "6").conv, "0"), "0")(add_2_post_act_fake_quantizer)     features_6_conv_0_2 = getattr(getattr(getattr(self.features, "6").conv, "0"), "2")(features_6_conv_0_0);  features_6_conv_0_0 = None     features_6_conv_0_2_post_act_fake_quantizer = self.features_6_conv_0_2_post_act_fake_quantizer(features_6_conv_0_2);  features_6_conv_0_2 = None     features_6_conv_1_0 = getattr(getattr(getattr(self.features, "6").conv, "1"), "0")(features_6_conv_0_2_post_act_fake_quantizer);  features_6_conv_0_2_post_act_fake_quantizer = None     features_6_conv_1_2 = getattr(getattr(getattr(self.features, "6").conv, "1"), "2")(features_6_conv_1_0);  features_6_conv_1_0 = None     features_6_conv_1_2_post_act_fake_quantizer = self.features_6_conv_1_2_post_act_fake_quantizer(features_6_conv_1_2);  features_6_conv_1_2 = None     features_6_conv_2 = getattr(getattr(self.features, "6").conv, "2")(features_6_conv_1_2_post_act_fake_quantizer);  features_6_conv_1_2_post_act_fake_quantizer = None     features_6_conv_2_post_act_fake_quantizer = self.features_6_conv_2_post_act_fake_quantizer(features_6_conv_2);  features_6_conv_2 = None     add_3 = add_2_post_act_fake_quantizer + features_6_conv_2_post_act_fake_quantizer;  add_2_post_act_fake_quantizer = features_6_conv_2_post_act_fake_quantizer = None     add_3_post_act_fake_quantizer = self.add_3_post_act_fake_quantizer(add_3);  add_3 = None     features_7_conv_0_0 = getattr(getattr(getattr(self.features, "7").conv, "0"), "0")(add_3_post_act_fake_quantizer);  add_3_post_act_fake_quantizer = None     features_7_conv_0_2 = getattr(getattr(getattr(self.features, "7").conv, "0"), "2")(features_7_conv_0_0);  features_7_conv_0_0 = None     features_7_conv_0_2_post_act_fake_quantizer = self.features_7_conv_0_2_post_act_fake_quantizer(features_7_conv_0_2);  features_7_conv_0_2 = None     features_7_conv_1_0 = getattr(getattr(getattr(self.features, "7").conv, "1"), "0")(features_7_conv_0_2_post_act_fake_quantizer);  features_7_conv_0_2_post_act_fake_quantizer = None     features_7_conv_1_2 = getattr(getattr(getattr(self.features, "7").conv, "1"), "2")(features_7_conv_1_0);  features_7_conv_1_0 = None     features_7_conv_1_2_post_act_fake_quantizer = self.features_7_conv_1_2_post_act_fake_quantizer(features_7_conv_1_2);  features_7_conv_1_2 = None     features_7_conv_2 = getattr(getattr(self.features, "7").conv, "2")(features_7_conv_1_2_post_act_fake_quantizer);  features_7_conv_1_2_post_act_fake_quantizer = None     features_7_conv_2_post_act_fake_quantizer = self.features_7_conv_2_post_act_fake_quantizer(features_7_conv_2);  features_7_conv_2 = None     features_8_conv_0_0 = getattr(getattr(getattr(self.features, "8").conv, "0"), "0")(features_7_conv_2_post_act_fake_quantizer)     features_8_conv_0_2 = getattr(getattr(getattr(self.features, "8").conv, "0"), "2")(features_8_conv_0_0);  features_8_conv_0_0 = None     features_8_conv_0_2_post_act_fake_quantizer = self.features_8_conv_0_2_post_act_fake_quantizer(features_8_conv_0_2);  features_8_conv_0_2 = None     features_8_conv_1_0 = getattr(getattr(getattr(self.features, "8").conv, "1"), "0")(features_8_conv_0_2_post_act_fake_quantizer);  features_8_conv_0_2_post_act_fake_quantizer = None     features_8_conv_1_2 = getattr(getattr(getattr(self.features, "8").conv, "1"), "2")(features_8_conv_1_0);  features_8_conv_1_0 = None     features_8_conv_1_2_post_act_fake_quantizer = self.features_8_conv_1_2_post_act_fake_quantizer(features_8_conv_1_2);  features_8_conv_1_2 = None     features_8_conv_2 = getattr(getattr(self.features, "8").conv, "2")(features_8_conv_1_2_post_act_fake_quantizer);  features_8_conv_1_2_post_act_fake_quantizer = None     features_8_conv_2_post_act_fake_quantizer = self.features_8_conv_2_post_act_fake_quantizer(features_8_conv_2);  features_8_conv_2 = None     add_4 = features_7_conv_2_post_act_fake_quantizer + features_8_conv_2_post_act_fake_quantizer;  features_7_conv_2_post_act_fake_quantizer = features_8_conv_2_post_act_fake_quantizer = None     add_4_post_act_fake_quantizer = self.add_4_post_act_fake_quantizer(add_4);  add_4 = None     features_9_conv_0_0 = getattr(getattr(getattr(self.features, "9").conv, "0"), "0")(add_4_post_act_fake_quantizer)     features_9_conv_0_2 = getattr(getattr(getattr(self.features, "9").conv, "0"), "2")(features_9_conv_0_0);  features_9_conv_0_0 = None     features_9_conv_0_2_post_act_fake_quantizer = self.features_9_conv_0_2_post_act_fake_quantizer(features_9_conv_0_2);  features_9_conv_0_2 = None     features_9_conv_1_0 = getattr(getattr(getattr(self.features, "9").conv, "1"), "0")(features_9_conv_0_2_post_act_fake_quantizer);  features_9_conv_0_2_post_act_fake_quantizer = None     features_9_conv_1_2 = getattr(getattr(getattr(self.features, "9").conv, "1"), "2")(features_9_conv_1_0);  features_9_conv_1_0 = None     features_9_conv_1_2_post_act_fake_quantizer = self.features_9_conv_1_2_post_act_fake_quantizer(features_9_conv_1_2);  features_9_conv_1_2 = None     features_9_conv_2 = getattr(getattr(self.features, "9").conv, "2")(features_9_conv_1_2_post_act_fake_quantizer);  features_9_conv_1_2_post_act_fake_quantizer = None     features_9_conv_2_post_act_fake_quantizer = self.features_9_conv_2_post_act_fake_quantizer(features_9_conv_2);  features_9_conv_2 = None     add_5 = add_4_post_act_fake_quantizer + features_9_conv_2_post_act_fake_quantizer;  add_4_post_act_fake_quantizer = features_9_conv_2_post_act_fake_quantizer = None     add_5_post_act_fake_quantizer = self.add_5_post_act_fake_quantizer(add_5);  add_5 = None     features_10_conv_0_0 = getattr(getattr(getattr(self.features, "10").conv, "0"), "0")(add_5_post_act_fake_quantizer)     features_10_conv_0_2 = getattr(getattr(getattr(self.features, "10").conv, "0"), "2")(features_10_conv_0_0);  features_10_conv_0_0 = None     features_10_conv_0_2_post_act_fake_quantizer = self.features_10_conv_0_2_post_act_fake_quantizer(features_10_conv_0_2);  features_10_conv_0_2 = None     features_10_conv_1_0 = getattr(getattr(getattr(self.features, "10").conv, "1"), "0")(features_10_conv_0_2_post_act_fake_quantizer);  features_10_conv_0_2_post_act_fake_quantizer = None     features_10_conv_1_2 = getattr(getattr(getattr(self.features, "10").conv, "1"), "2")(features_10_conv_1_0);  features_10_conv_1_0 = None     features_10_conv_1_2_post_act_fake_quantizer = self.features_10_conv_1_2_post_act_fake_quantizer(features_10_conv_1_2);  features_10_conv_1_2 = None     features_10_conv_2 = getattr(getattr(self.features, "10").conv, "2")(features_10_conv_1_2_post_act_fake_quantizer);  features_10_conv_1_2_post_act_fake_quantizer = None     features_10_conv_2_post_act_fake_quantizer = self.features_10_conv_2_post_act_fake_quantizer(features_10_conv_2);  features_10_conv_2 = None     add_6 = add_5_post_act_fake_quantizer + features_10_conv_2_post_act_fake_quantizer;  add_5_post_act_fake_quantizer = features_10_conv_2_post_act_fake_quantizer = None     add_6_post_act_fake_quantizer = self.add_6_post_act_fake_quantizer(add_6);  add_6 = None     features_11_conv_0_0 = getattr(getattr(getattr(self.features, "11").conv, "0"), "0")(add_6_post_act_fake_quantizer);  add_6_post_act_fake_quantizer = None     features_11_conv_0_2 = getattr(getattr(getattr(self.features, "11").conv, "0"), "2")(features_11_conv_0_0);  features_11_conv_0_0 = None     features_11_conv_0_2_post_act_fake_quantizer = self.features_11_conv_0_2_post_act_fake_quantizer(features_11_conv_0_2);  features_11_conv_0_2 = None     features_11_conv_1_0 = getattr(getattr(getattr(self.features, "11").conv, "1"), "0")(features_11_conv_0_2_post_act_fake_quantizer);  features_11_conv_0_2_post_act_fake_quantizer = None     features_11_conv_1_2 = getattr(getattr(getattr(self.features, "11").conv, "1"), "2")(features_11_conv_1_0);  features_11_conv_1_0 = None     features_11_conv_1_2_post_act_fake_quantizer = self.features_11_conv_1_2_post_act_fake_quantizer(features_11_conv_1_2);  features_11_conv_1_2 = None     features_11_conv_2 = getattr(getattr(self.features, "11").conv, "2")(features_11_conv_1_2_post_act_fake_quantizer);  features_11_conv_1_2_post_act_fake_quantizer = None     features_11_conv_2_post_act_fake_quantizer = self.features_11_conv_2_post_act_fake_quantizer(features_11_conv_2);  features_11_conv_2 = None     features_12_conv_0_0 = getattr(getattr(getattr(self.features, "12").conv, "0"), "0")(features_11_conv_2_post_act_fake_quantizer)     features_12_conv_0_2 = getattr(getattr(getattr(self.features, "12").conv, "0"), "2")(features_12_conv_0_0);  features_12_conv_0_0 = None     features_12_conv_0_2_post_act_fake_quantizer = self.features_12_conv_0_2_post_act_fake_quantizer(features_12_conv_0_2);  features_12_conv_0_2 = None     features_12_conv_1_0 = getattr(getattr(getattr(self.features, "12").conv, "1"), "0")(features_12_conv_0_2_post_act_fake_quantizer);  features_12_conv_0_2_post_act_fake_quantizer = None     features_12_conv_1_2 = getattr(getattr(getattr(self.features, "12").conv, "1"), "2")(features_12_conv_1_0);  features_12_conv_1_0 = None     features_12_conv_1_2_post_act_fake_quantizer = self.features_12_conv_1_2_post_act_fake_quantizer(features_12_conv_1_2);  features_12_conv_1_2 = None     features_12_conv_2 = getattr(getattr(self.features, "12").conv, "2")(features_12_conv_1_2_post_act_fake_quantizer);  features_12_conv_1_2_post_act_fake_quantizer = None     features_12_conv_2_post_act_fake_quantizer = self.features_12_conv_2_post_act_fake_quantizer(features_12_conv_2);  features_12_conv_2 = None     add_7 = features_11_conv_2_post_act_fake_quantizer + features_12_conv_2_post_act_fake_quantizer;  features_11_conv_2_post_act_fake_quantizer = features_12_conv_2_post_act_fake_quantizer = None     add_7_post_act_fake_quantizer = self.add_7_post_act_fake_quantizer(add_7);  add_7 = None     features_13_conv_0_0 = getattr(getattr(getattr(self.features, "13").conv, "0"), "0")(add_7_post_act_fake_quantizer)     features_13_conv_0_2 = getattr(getattr(getattr(self.features, "13").conv, "0"), "2")(features_13_conv_0_0);  features_13_conv_0_0 = None     features_13_conv_0_2_post_act_fake_quantizer = self.features_13_conv_0_2_post_act_fake_quantizer(features_13_conv_0_2);  features_13_conv_0_2 = None     features_13_conv_1_0 = getattr(getattr(getattr(self.features, "13").conv, "1"), "0")(features_13_conv_0_2_post_act_fake_quantizer);  features_13_conv_0_2_post_act_fake_quantizer = None     features_13_conv_1_2 = getattr(getattr(getattr(self.features, "13").conv, "1"), "2")(features_13_conv_1_0);  features_13_conv_1_0 = None     features_13_conv_1_2_post_act_fake_quantizer = self.features_13_conv_1_2_post_act_fake_quantizer(features_13_conv_1_2);  features_13_conv_1_2 = None     features_13_conv_2 = getattr(getattr(self.features, "13").conv, "2")(features_13_conv_1_2_post_act_fake_quantizer);  features_13_conv_1_2_post_act_fake_quantizer = None     features_13_conv_2_post_act_fake_quantizer = self.features_13_conv_2_post_act_fake_quantizer(features_13_conv_2);  features_13_conv_2 = None     add_8 = add_7_post_act_fake_quantizer + features_13_conv_2_post_act_fake_quantizer;  add_7_post_act_fake_quantizer = features_13_conv_2_post_act_fake_quantizer = None     add_8_post_act_fake_quantizer = self.add_8_post_act_fake_quantizer(add_8);  add_8 = None     features_14_conv_0_0 = getattr(getattr(getattr(self.features, "14").conv, "0"), "0")(add_8_post_act_fake_quantizer);  add_8_post_act_fake_quantizer = None     features_14_conv_0_2 = getattr(getattr(getattr(self.features, "14").conv, "0"), "2")(features_14_conv_0_0);  features_14_conv_0_0 = None     features_14_conv_0_2_post_act_fake_quantizer = self.features_14_conv_0_2_post_act_fake_quantizer(features_14_conv_0_2);  features_14_conv_0_2 = None     features_14_conv_1_0 = getattr(getattr(getattr(self.features, "14").conv, "1"), "0")(features_14_conv_0_2_post_act_fake_quantizer);  features_14_conv_0_2_post_act_fake_quantizer = None     features_14_conv_1_2 = getattr(getattr(getattr(self.features, "14").conv, "1"), "2")(features_14_conv_1_0);  features_14_conv_1_0 = None     features_14_conv_1_2_post_act_fake_quantizer = self.features_14_conv_1_2_post_act_fake_quantizer(features_14_conv_1_2);  features_14_conv_1_2 = None     features_14_conv_2 = getattr(getattr(self.features, "14").conv, "2")(features_14_conv_1_2_post_act_fake_quantizer);  features_14_conv_1_2_post_act_fake_quantizer = None     features_14_conv_2_post_act_fake_quantizer = self.features_14_conv_2_post_act_fake_quantizer(features_14_conv_2);  features_14_conv_2 = None     features_15_conv_0_0 = getattr(getattr(getattr(self.features, "15").conv, "0"), "0")(features_14_conv_2_post_act_fake_quantizer)     features_15_conv_0_2 = getattr(getattr(getattr(self.features, "15").conv, "0"), "2")(features_15_conv_0_0);  features_15_conv_0_0 = None     features_15_conv_0_2_post_act_fake_quantizer = self.features_15_conv_0_2_post_act_fake_quantizer(features_15_conv_0_2);  features_15_conv_0_2 = None     features_15_conv_1_0 = getattr(getattr(getattr(self.features, "15").conv, "1"), "0")(features_15_conv_0_2_post_act_fake_quantizer);  features_15_conv_0_2_post_act_fake_quantizer = None     features_15_conv_1_2 = getattr(getattr(getattr(self.features, "15").conv, "1"), "2")(features_15_conv_1_0);  features_15_conv_1_0 = None     features_15_conv_1_2_post_act_fake_quantizer = self.features_15_conv_1_2_post_act_fake_quantizer(features_15_conv_1_2);  features_15_conv_1_2 = None     features_15_conv_2 = getattr(getattr(self.features, "15").conv, "2")(features_15_conv_1_2_post_act_fake_quantizer);  features_15_conv_1_2_post_act_fake_quantizer = None     features_15_conv_2_post_act_fake_quantizer = self.features_15_conv_2_post_act_fake_quantizer(features_15_conv_2);  features_15_conv_2 = None     add_9 = features_14_conv_2_post_act_fake_quantizer + features_15_conv_2_post_act_fake_quantizer;  features_14_conv_2_post_act_fake_quantizer = features_15_conv_2_post_act_fake_quantizer = None     add_9_post_act_fake_quantizer = self.add_9_post_act_fake_quantizer(add_9);  add_9 = None     features_16_conv_0_0 = getattr(getattr(getattr(self.features, "16").conv, "0"), "0")(add_9_post_act_fake_quantizer)     features_16_conv_0_2 = getattr(getattr(getattr(self.features, "16").conv, "0"), "2")(features_16_conv_0_0);  features_16_conv_0_0 = None     features_16_conv_0_2_post_act_fake_quantizer = self.features_16_conv_0_2_post_act_fake_quantizer(features_16_conv_0_2);  features_16_conv_0_2 = None     features_16_conv_1_0 = getattr(getattr(getattr(self.features, "16").conv, "1"), "0")(features_16_conv_0_2_post_act_fake_quantizer);  features_16_conv_0_2_post_act_fake_quantizer = None     features_16_conv_1_2 = getattr(getattr(getattr(self.features, "16").conv, "1"), "2")(features_16_conv_1_0);  features_16_conv_1_0 = None     features_16_conv_1_2_post_act_fake_quantizer = self.features_16_conv_1_2_post_act_fake_quantizer(features_16_conv_1_2);  features_16_conv_1_2 = None     features_16_conv_2 = getattr(getattr(self.features, "16").conv, "2")(features_16_conv_1_2_post_act_fake_quantizer);  features_16_conv_1_2_post_act_fake_quantizer = None     features_16_conv_2_post_act_fake_quantizer = self.features_16_conv_2_post_act_fake_quantizer(features_16_conv_2);  features_16_conv_2 = None     add_10 = add_9_post_act_fake_quantizer + features_16_conv_2_post_act_fake_quantizer;  add_9_post_act_fake_quantizer = features_16_conv_2_post_act_fake_quantizer = None     add_10_post_act_fake_quantizer = self.add_10_post_act_fake_quantizer(add_10);  add_10 = None     features_17_conv_0_0 = getattr(getattr(getattr(self.features, "17").conv, "0"), "0")(add_10_post_act_fake_quantizer);  add_10_post_act_fake_quantizer = None     features_17_conv_0_2 = getattr(getattr(getattr(self.features, "17").conv, "0"), "2")(features_17_conv_0_0);  features_17_conv_0_0 = None     features_17_conv_0_2_post_act_fake_quantizer = self.features_17_conv_0_2_post_act_fake_quantizer(features_17_conv_0_2);  features_17_conv_0_2 = None     features_17_conv_1_0 = getattr(getattr(getattr(self.features, "17").conv, "1"), "0")(features_17_conv_0_2_post_act_fake_quantizer);  features_17_conv_0_2_post_act_fake_quantizer = None     features_17_conv_1_2 = getattr(getattr(getattr(self.features, "17").conv, "1"), "2")(features_17_conv_1_0);  features_17_conv_1_0 = None     features_17_conv_1_2_post_act_fake_quantizer = self.features_17_conv_1_2_post_act_fake_quantizer(features_17_conv_1_2);  features_17_conv_1_2 = None     features_17_conv_2 = getattr(getattr(self.features, "17").conv, "2")(features_17_conv_1_2_post_act_fake_quantizer);  features_17_conv_1_2_post_act_fake_quantizer = None     features_17_conv_2_post_act_fake_quantizer = self.features_17_conv_2_post_act_fake_quantizer(features_17_conv_2);  features_17_conv_2 = None     features_18_0 = getattr(getattr(self.features, "18"), "0")(features_17_conv_2_post_act_fake_quantizer);  features_17_conv_2_post_act_fake_quantizer = None     features_18_2 = getattr(getattr(self.features, "18"), "2")(features_18_0);  features_18_0 = None     adaptive_avg_pool2d_1 = torch.nn.functional.adaptive_avg_pool2d(features_18_2, (1, 1))     getattr_1 = features_18_2.shape;  features_18_2 = None     getitem = getattr_1[0];  getattr_1 = None     reshape_1 = adaptive_avg_pool2d_1.reshape(getitem, -1);  adaptive_avg_pool2d_1 = getitem = None     classifier_0 = getattr(self.classifier, "0")(reshape_1);  reshape_1 = None     classifier_0_post_act_fake_quantizer = self.classifier_0_post_act_fake_quantizer(classifier_0);  classifier_0 = None     classifier_1 = getattr(self.classifier, "1")(classifier_0_post_act_fake_quantizer);  classifier_0_post_act_fake_quantizer = None     return classifier_1
If I print the value of "torch.unique(x_post_act_fake_quantizer)", it returns
tensor([-2.0197, -1.3465, -0.6732,  0.0000,  0.6732,  1.3465,  2.0197,  2.6929],
device='cuda:0'). This only consists of 8 unique values for the quantized input. Similarly for torch.unique(features_0_2_post_act_fake_quantizer),
tensor([0.0000, 0.2307, 0.4614, 0.6921, 0.9228, 1.1535, 1.3842, 1.6150],
device='cuda:0', grad_fn=)


El Capitan

I'm having trouble making it work with El Capitan... has anyone managed to use it in El Capitan?
Thank you!

+1

I'll take a look at this over the weekend.

It seems to be working .
OS version 10.11.1(15B42)
3x

@elrrrrrrrr Thanks for taking a look and posting back. @Sydney-o9 did you run into any specific issue getting this to work?

Yes my screen was totally black after rebooting. Feel free to close if you guys manage to make it work. It might just be me not going through the steps correctly. Thank you for your help anyway!

Is this still an issue?