Remove unnecessary scheme

As discussed in #148, this scheme doesn't work and is not necessary. <3

Thanks!


Feature request: Add option for custom annotations

Hi colleagues,
I am using the btp-operator in a setup where it (among other microservices) is deployed via ArgoCD.
The parameters I use in the secret are imported from Hashicorp Vault via the ArgoCD Vault Plugin. Its' functionality relies on a certain annotation of the secret template and the current version of the secret doesn't provide the option to add this annotation:
https://argocd-vault-plugin.readthedocs.io/en/stable/howitworks/
With few simple changes of the secret template and the values file we can add the option for custom annotations.

Hi @gi02sap
please provide the tempalte with the required changes and we'll review it.
Thanks!

Hi @kerenlahav,
Can you share any information whether the change will be included and when eventually?

https://github.com/SAP/sap-btp-service-operator/pull/496
will be released next week


Keep LF endings when checkout on windows

I checkout source code from Github on Windows than compile it in Gitbash.  Error message:
[ERROR] src\main\resources\io\prestosql\spi\type\zone-index.properties:[2233] (regexp) RegexpMultiline: Line contains carriage return

Git may convert LF to CRLF when checkout on windows. Some description from GitHub:git-handle-line-ending
An old issues of prestodb:
Build fails due to Checkstyle violations
I propose to add a git attribute: "text eol=lf", so git will always convert line endings to LF on checkout.
Compile can accomplish by Gitbash on windows[/smile].

@ssquan we currently don't have capacity to support building Presto on windows.
I expect you will run into further problems (e.g. lack of native Windows libraries for hadoop) when going this path.
Currently, a workaround for building Presto on Windows that is known to work is to do this in a VirtualBox Linux.
Also, my (quite long) past experience of using Windows for work tells me that EOL conversion on check-out/check-in is not something I would recommend.
Instead, I would always ask my git on Windows not to mess with the files EOLs at all.  E.g. https://stackoverflow.com/questions/21822650/disable-git-eol-conversions
(Then I would tell my IDE / file editor to use the EOLs I want, which we already do -- https://github.com/prestosql/presto/blob/cd6c18a1a148f716587333dee24cb6e7ba29619b/.editorconfig#L6)
Does this address your needs?
(BTW I invite you to join the #dev channel of our slack https://prestosql.io/slack.html. See you there!)

/ close


Remove deprecated _log() probability functions. (Breaking change; bump major version)

Summary
This PR removes all the deprecated _log() probability functions.
As a consequence, many of the tests needed to be updated.
Tests
I tried to catch all the tests and update them appropiately.
All the log_matches_lpdf and log_matches_lpmf tests are now gone!
Side Effects
This is a breaking change since functions that existed are now removed.
Release notes
Removing deprecated _log distribution functions. Please use _lpdf or _lpmf functions instead.
Checklist

[x] Copyright holder: Daniel Lee
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[ ] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
dependencies checks pass, (make test-math-dependencies)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

Absolutely! There's no rush. I just had time and wanted to work on it. I'm relying on the CI machinery.

(It should definitely go after the release is done.)

Once the merge conflict is resolved I'm cool approving this and merging it to the 5.0 branch.
Once the 5.0 branch has another PR in it let's open a PR up for it so the tests go off for the 5.0 branch

Just fixed the merge conflict.
The 5.0 branch doesn't have continuous integration in place, unfortunately.

Lets start merging to it and open a PR for the 5.0 branch


LiteCreditCardInput throwing Warning: componentWillReceiveProps has been renamed, and is not recommended for use on Focus

Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code
to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: %s, CCInput, LiteCreditCardInput

Thanks for your quick response... Is there a timeframe for this enhancement?

@BobRusch Sorry for delay reply, I wil look into it this week

Thanks, NP, it seems that react has again made a breaking change.
Bob
On Fri, Mar 19, 2021, 11:06 PM Juan David Landazabal <
@.***> wrote:

@BobRusch https://github.com/BobRusch Sorry for delay reply, I wil look
into it this week
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/juandl/react-native-credit-card-input-plus/issues/1#issuecomment-803234080,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJILXXVYKKD3NJLK2GMQVTDTEQGKFANCNFSM4ZA2X24A
.

Any plans to fix this soon?

@Kiura Next week will spend few hours for this hopefully


Some questions about your paper

Hi, congratulations for the acceptance of your paper. I carefully checked it and tried to reproduce the experimental results using your code. Here are some questions:

the idea of your paper is actually very similar to 'ELECTRA: Pre-training Text Encoders as Discriminators Rather Than Generators', but you did not  mention and cite this paper. [This is a very severe problem because it is a kind of academic misconduct ...]
For a fair comparison, we used your code to test the SASRec model and found that the improvements of your model over SASRec is very limited using the same experimental setting, which is not consistent with such a large performance gain reported in your paper.

Hope you could answer these questions soon!

Hi @PALIN2018 , thank you for bringing up these questions!

A key difference with ELECTRA is that: ELECTRA in NLP domain distinguishes if a word token from the ‘current’ position is generated or from the training data for model pre-training, while our method target for recommendation domain and aims to distinguish the plausible ‘future’ items, which better aligned with the recommendation tasks. I will update our paper to cite ELECTRA and describe the differences in detail shortly.
The original SASRec is trained with BCE loss while in our method, the Generator is trained with Softmax (Eq.3). We provided a detailed ablation study in Section 4.3 and highlighted the benefits of switching from BCE loss to Softmax (compare between model C & D). Besides, having a discriminator indeed gives a large performance gain, especially on Yelp (compare between model A & C). During the experiments, I do observe that the training is a bit sensitive to the hyperparameters such as sampling rate and reported in the study in Section 4.4.

Hope that answers your questions. Please feel free to let me know if you have any other questions! - Thanks

Thanks for your reply. For the citation issue, it is obvious that your idea is inspired by ELECTRA, and the main contribution is that you adapt this NLP method to sequential recommendation. But I just could not understand why you just ignore ELECTRA and it is definitely a kind of academic misconduct behavior. And for the experimental parts, I still think that the way that you compare with the baseline models is unfair. You use two modules similar to SASRec, but when reporting the performance, you just show the weak performance of SASRec (which as you said is caused by BCE loss) to demonstrate the effectiveness of your method. In my opinion, you should ensure all these experiments are conducted under the same experimental settings.

Thanks for your suggestions @PALIN2018! For the citation, I agree that I need to cite ELECTRA and I have updated our paper accordingly (takes a few days to reflect.). I focused too narrowly on the existing works in recommendation areas in my previous writing. For experiments, I will conduct the additional experiments and put the new main table in this repo. Please let me know if you have any further questions. - Thanks


fixes typoo errors

Corrections manually merged in Bibledit to avoid conflict with that editing system. Updates will appear on eBible.org and in the base branch within 24 hours. ¡Gracias!


Key generation for private MSTeams conversations can exceed 255 characters

Releated to https://github.com/Microsoft/BotBuilder/issues/3637
I'm currently seeing in a subset of 1:1 conversations to the bot in MSTeams, dialogue fails on an attempt write to state service.  Happy to PR something here but guidance to make this backwards compatible would be appreciated.
System.Web.HttpException (0x80004005): Message: {"Errors":["The input name 'msteams:private{large key}' is invalid. Ensure to provide a unique non-empty string less than '255' characters.","The request payload is invalid. Ensure to provide a valid request payload."]}

Thank you for opening an issue against the BotBuilder-Azure repo. As part of the Bot Framework v4 release, we’ve moved all the Azure related work to the platform SDK repo. We will continue to support and offer maintenance updates via this repo.
From now on, https://github.com/Microsoft/botframework-sdk repo will be used as hub, with pointers to all the different SDK languages, tools and samples repos.
As part of this restructuring, we are closing all tickets in this repo.
For defects or feature requests, please create a new issue in the Bot Framework repo found here:
https://github.com/Microsoft/botframework-sdk/issues
For product behavior, how-to, or general understanding questions, please use Stackoverflow.
https://stackoverflow.com/search?q=bot+framework
Thank you.
The Bot Framework Team


revamp readme to point to relevant resources

The readme was written a long time ago and had outdated pointers.
This patch re-organizes and adds in relevant pointers in the readme.

/lgtm
/approve


Separate IPv4 and IPv6 lists

I'm using these two Crowdsec packages on FreeBSD:
crowdsec-1.4.6_2 CrowdSec lightweight and collaborative security engine
crowdsec-blocklist-mirror-0.0.1_5 CrowdSec Blocklist Mirror
I wanted to know if it would be possible to dismember the current list of IP's separately, where a list is only for IPv4 and another only for IPv6.
This makes it easier to use a firewall in IPv4 and IPv6.

v0.0.2 was released for both linux and freebsd, do you need anything else?


PowerShell Kernel - Support for PowerShell 6+

Is your feature request related to a problem? Please describe.
Opening a new notebook and selecting the PowerShell Kernel it is only utilizing Windows PowerShell for output within the notebook.
Describe the solution or feature you'd like
I would like the ability to configure it, or have it default to use the PowerShell configured under terminal.integrated.shell.windows.
Describe alternatives you've considered
There is none really, but I've opened an issue asking them to add support for calling pwsh in Windows as well. ref: vors/jupyter-powershell#24
Additional context
I believe the issue is going to be based on the pip library being used. I looked at the vors/jupyter-powershell library that seems to be what is getting installed and right now they have it hard coded to only call the engine based on the OS name returned.
The util.py only considers powershell when it sees NT as the OS, so it is not looking at the fact we can use pwsh in Windows as well.
https://github.com/vors/jupyter-powershell/blob/e418eb055b4d89ef88249e1b6a1bd7e0835e19d0/powershell_kernel/util.py#L3-L5
def get_powershell():
    # nt is a name for windows
    return 'powershell' if os.name == 'nt' else 'pwsh'

I want to thumbs up but it won't let me.
The experience cross-platform should be the same. Right now, PowerShell notebooks I write on Windows may not work on Linux and vice versa.
I would potentially request that both OS's use pwsh rather than WIndows PowerShell
but the ability to choose will be useful when PowerShell 7 is GA

The response I was given in the PR from vors:
If you read the https://github.com/vors/jupyter-powershell#install-kernel it shows the command to use pwsh on windows.

python -m powershell_kernel.install --powershell-command pwsh

python -m powershell_kernel.install --powershell-command pwsh

the command has actually no impact when used on computer with Azure Data Studio 1.21.0 and jupyter notebook server 6.1.3
https://github.com/vors/jupyter-powershell/issues/35

Simple Jupyter Notebook to reproduce issue embedded in attached zip archive
checkPwshVersion.zip

I was able to get it to shift to PWSH by running the python -m powershell_kernel.install --powershell-command pwsh line within a code block within a notebook. Not sure I liked that solution, but it worked.

I'm facing the same problem.

Screenshot


Reorganization of configuration files

Model configuration could be easier with less config files. In particular:

lossRatesOutput.config and productionRatesOutput.config could be merged

JFacSpecies.config could be merged with environmentVariables.config, eg by modifying the JFAC switch in environmentVariables.config (pending resolution of Issue #16)

model.parameters and solver.parameters: do they need to be separate? If so are the option/switches organized logically?

lossRates.output and productionRates.output  do not have any output if only one species is in lossRatesOutput.config and productionRatesOutput.config

I've opened issue #81 to address the missing output given only one species in those config files.

@rs028 Do we want to merge lossRatesOutput.config and productionRatesOutput.config or not? Currently they are separate, so you can keep track of the production and loss of different collections of species. Is there a real benefit to merging them? That would reduce the flexibility of the code, but would simplify it a bit. I'm loathe to get rid of that separation however, as that is removing functionality - is it ok if we just ensure that the machinery is actually working?

@rs028 Or have I misunderstood, and you're just saying the contents of the two files could be placed into the same file, but kept as separate lists of species? That would be workable.

@spco The second one. I think it would be easier (less error prone, maybe) to have the two lists in the same file.

#81 seems to have fixed the missing output in lossRates.output and productionRates.output.

Personally I'm happy to leave the lossRates.config and productionRates.config separate for now, it can always be come back to.
I'm also of the opinion that the model.parameters and solver.parameters are fine to be kept separate - there is a logical separation of the model and the solver, so reflecting that in the inputs isn't too bad. It's largely a matter of taste though.
I'll be working on the area of the JFacSpecies this afternoon, so once that is fixed, this can be closed.

Yeah, okay.

In solver.parameters there is this bit here:
For one day
96.0e+00		number of steps
900.0e+00		step size

for two days
192.0e+00		number of steps
900.0e+00		step size

2880.0e+00	number of steps
60.0e+00		step size

standard
1.0e-04		  atol
1.0e-06	 	  rtol

It is meant to give suggestions on possibile values. I think it makes more senses to remove it and stick in the wiki. Related: I am not sure what all the parameters in this file actually mean.

I like that suggestion - that also allows us to drop the line -9999 End of file : previously we had to keep that to separate the 'live' values from the reference values you've highlighted. I'm happy to raise a pull request for that, and for model.parameters too.
Would it be helpful to have a wiki page that both documents what the parameters mean and also gives these reference values?

Yes it would be very useful. You have added a lot of comments to the code (much appreciated!) but documentation is still lagging far behind.

model.parameters and solver.parameters are tidied up by #222. The reference values have also been moved to the wiki.


Ability to do an insert without re-running query streams

Is your feature request related to a problem? Please describe.
I am listening to changes on a table using watch and also have a background download process (in separate isolate) running at the same time which inserts many records ( > 1000 records) using the into(table_name).insert(record) statement for each record and this causes the watch to emit an event for each insert.
I am also using the https://pub.dev/packages/diffutil_dart package to check for changes (create, update, etc.) in the List of data emitted for each watch event and this would result in a lot of processing on the main thread. Due to this heavy processing on the main thread the UI is adversely affected. I could use a customInsert without setting the updates parameter but is it possible to still use the into(table_name).insert(record) but not re-run the stream query ?
Describe the solution you'd like
Perhaps the insert could have another named optional parameter of type bool, say updateStreamQuery  and passing false would not re-run the stream query.
e.g. into(table_name).insert(record , updateStreamQuery : false)

Are you running the inserts in a transaction? This will only cause the watch to emit once the transaction is complete
db.transaction(() async {
    ...
});

You could also use batches which are more efficient at inserting/updating/deleting multiple items from the same table
  await batch((batch) {
    // functions in a batch don't have to be awaited - just
    // await the whole batch afterwards.
    batch.insertAll(todos, [
      TodosCompanion.insert(
        title: 'First entry',
        content: 'My content',
      ),
      TodosCompanion.insert(
        title: 'Another entry',
        content: 'More content',
        // columns that aren't required for inserts are still wrapped in a Value:
        category: Value(3),
      ),
      // ...
    ]);
  });

No I'm not running it in a transaction or using a batch. I could use a batch to make the inserts efficient but that would still cause the watch stream query to re-run once.
I'm looking for a solution where I can do the downloads (insert) using the into(table).insert(record) query but at the same time this query shall not notify the stream query of the table changes

I could use a batch to make the inserts efficient but that would still cause the watch stream query to re-run once.

Once for the entire transaction or batch though, which is much better than once for each row! Streams created outside of a transaction will only be updated once after the transaction completes (the same goes for batches, which use transactions internally).

I'm looking for a solution where I can do the downloads (insert) using the into(table).insert(record) query but at the same time this query shall not notify the stream query of the table changes

I think this is very rarely needed and shouldn't be part of drift. Instead of relying of some built-in mechanism, you could also do something like this:

Call StreamSubscription.pause on the listener you want to pause while downloads are being processed.
Run the code inserting all the downloads.
Call SttreamSubscription.resume.

But since it's probably ok to get notified once, I'd just use transactions.


User manual fixes

Describe the bug
The user manual contains few bugs that needs to be fixed for the July 2021 milestone
To Reproduce
Expected behavior
Screenshots
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context

For Change Control Board: Issue Review
This review should occur before any development is performed as a response to this issue.

[x] 1. Is it tagged with a type: defect or task?
[x] 2. Is it tagged with a priority: critical, normal or minor?
[x] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[x] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[x] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure
This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system?  (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

manual updates, no crash or different calculation results, no need to inform users.

additional issues were found.


Feat: Footer Enhancement

Describe the feature
I want to work on enhancing the footer with maybe a different bg, few page and social handle links. I was thinking a template similar to this would look good. I will make it responsive as well.
@VanshKing30 can you please assign this to me?
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Hey, hope you're doing great! As an GSSoC contributor, I'm keen on ramping up my involvement for GSSoC'24. Could you assign this issue to me? I'm excited to continue contributing to the project. Thanks a bunch!!

@Hemashree21 Kindly proceed! Assigning this issue to you...
@iamrudhresh If @Hemashree21 didn't reply in 2-3 days I will assign this issue to you..

@hustlerZzZ Thankyou!


daemon, option: consistently hard-code host device

The host device name is currently stored in option.Config.HostDevice
which is always initialized to defaults.HostDevice and there is no
command line option or other method to change it. Remove the option var
and always consistently hard-code the host device name using
defaults.HostDevice, like already done in several other places in the
code base.

/test

/test-1.16-4.9

/test-1.22-4.19

Seems OK to me, just curious if the initial intent was to eventually allow this to be CLI driven. Tho I think we have other flags which allow defining devices?

It looks like this is a leftover from the flannel integration which was removed in 3b64f2372319ec25c112c7c2d008d76b05ea8968 (the commit originally adding it was 1e0a8f70516dd7a3751fd7acf285787867cfaa67).

/test

/test

/test

/mlh new-flake Cilium-PR-Runtime-net-next

/test-runtime


feat(appactive):doc init

feat(appactive):doc init

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.就砺 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


New useDockWindow error when window is attached to launcher

Steps to replicate:

Use new 1.2.0 React hooks
Attach another window (.e.g watchlist) to the launcher

Error log (snippets):

Launcher will not allow other windows to dock to it, to be fixed in https://github.com/ScottLogic/StockFlux/issues/1304


How to use it.

How to use this adapter? any readme or anything?

Hi ,
I need to write some guide on how exactly to use it. I didn't find some time yet but i will do it soon.
The main idea is to use it exactly the same way you use any other auth provider.

Add firebase provider to your config auth list, add your firebase databaseURL and firebase credential JSON file path

  "auth" : {
       "firebase" : {
           "module" : "parse-server-firebase-auth-adapter",
           "databaseURL" : "https:/*****.firebaseio.com",
           "credential" : "/parse-server/keys/firebase/*****.json"
       }
   }

Add firebase SDK to your client (currently i am doing it only in iOS but it should be similar steps for android as well) described in here: https://firebase.google.com/docs/ios/setup

Sign in or sign Up or login with facebook, google etc. your user by reading the steps described in here: https://firebase.google.com/docs/auth/ios/password-auth

post signing in you have an access token. This access token should be sent to parse via parse SDK. this can achieve via parse SDK by using the logInWithAuthTypeInBackground there you need to pass the id of the user in firebase and the auth_token

You can look at an example in here: https://gist.github.com/flovilmart/68a6c538496953408bb1
Anyway, if you still don't manage to do it please let me know and i will do my best to add it to the README asap.

thank you very much

Sure, meantime I close this issue. If you have any further questions pleas feel free to open a new issue.


feat: unify all protocol options

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?

Don't use Option to wrap protocol options.
Adds enable to opentsdb, mysql, posgres options etc.

After this refactoring,  the gRPC and HTTP protocol will always be enabled. The other protocols contain an enable option to control whether to enable them, and all are enabled by default.
Checklist

[ ]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)

@waynexia @fengjiachun Please take a look


Upgrade to Swift 5

The repo is upgraded from upstream and I kept all the customization we did.
This is part of this issue: https://github.com/Expensify/Expensify/issues/85715
Test

Clone this repo and checkout this branch
Open the Podfile of the Expensify app
Assuming you cloned the repo on your home directory, change the pod 'TTGSnackbar'

#pod 'TTGSnackbar', :tag => '1.7.7', :git => 'https://github.com/Expensify/TTGSnackbar'
pod 'TTGSnackbar', :path => '~/TTGSnackbar'

Run pod install from /iOS directory
Do regression test based on this PR: https://github.com/Expensify/Mobile-Expensify/pull/11169
Do regression test based on this PR: https://github.com/Expensify/Mobile-Expensify/pull/11263

both cases test good! 👍


[Test only] Apollo 3 with ESM support

Description
Add support for ESM in graphql-testing

/snapit

/snapit

/snapit

/snapit

/snapit

/snapit

/snapit

/shipit


win32: Support PerMonitorV2

Improve High DPI support by using PerMonitorV2.
Close #3102
Implementation notes:

PerMoniterV2 should be able to enable by using manifest. However, on some environment, it didn't work.
Use SetThreadDpiAwarenessContext() to enable it explicitly.
Currently gVim uses system DPI. Add support for per-monitor DPI only where it is needed. Font size is still managed with system DPI.
Dialog box is created by using system DPI. Let Windows scale it automatically.
Don't consider PerMonitorV1.
V2 is available since Windows 10 1703. It is already 5 years ago.

I wonder - does this still work on Windows 7?
I would appreciate some people trying it out on their system and giving feedback.

I wonder - does this still work on Windows 7?

Yes, I've just confirmed that this works on Windows 7.


[Do not review] GEODE-10349: Client connects to a new server socket should check its …

…availability

For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

I'm not reviewing since the title says [Do not review]


Are my val_loss values valid?

Hi Nils, thanks for your great job in Deep Noise Suppression.I met a traning problem that confused me.
I followed the traning steps in 'README.md' to train the DTLN model, but the val_loss values I got after steps are always positive numbers around 45.I found that all the val_loss values people talked about here are always negtive numbers around -16.Anything wrong with me?I set the training set and validation set file path as:
path_to_train_mix = '/home/xxx/DNS-Challenge/training_set/train/noisy'
path_to_train_speech = '/home/xxx/DNS-Challenge/training_set/train/clean'
path_to_val_mix = '/home/xxx/DNS-Challenge/training_set/val/noisy'
path_to_val_speech = '/home/xxx/DNS-Challenge/training_set/val/clean'

My traing logs as:
None
Epoch 1/200
2023-04-12 15:02:54.045877: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcublas.so.10
02023-04-12 15:03:46.368859: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcufft.so.10
2023-04-12 15:05:01.907399: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library libcudnn.so.7
2023-04-12 15:10:02.601697: W tensorflow/stream_executor/gpu/redzone_allocator.cc:314] Internal: ptxas exited with non-zero error code 65280, output: ptxas fatal   : Value 'sm_86' is not defined for option 'gpu-name'

Relying on driver to perform ptx compilation.
Modify $PATH to customize ptxas location.
This message will be only logged once.
3000/3000 [==============================] - ETA: 0s - loss: 0.0015
Epoch 00001: val_loss improved from inf to 45.35575, saving model to ./models_DTLN_model/DTLN_model.h5
3000/3000 [==============================] - 1332s 444ms/step - loss: 0.0015 - val_loss: 45.3558 - lr: 0.0010
Epoch 2/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0049
Epoch 00002: val_loss did not improve from 45.35575
3000/3000 [==============================] - 1333s 444ms/step - loss: 0.0049 - val_loss: 45.4326 - lr: 0.0010
Epoch 3/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0143
Epoch 00003: val_loss did not improve from 45.35575
3000/3000 [==============================] - 1336s 445ms/step - loss: 0.0143 - val_loss: 45.4434 - lr: 0.0010
Epoch 4/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0434
Epoch 00004: val_loss improved from 45.35575 to 42.06635, saving model to ./models_DTLN_model/DTLN_model.h5
3000/3000 [==============================] - 1329s 443ms/step - loss: 0.0434 - val_loss: 42.0663 - lr: 0.0010
Epoch 5/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0482
Epoch 00005: val_loss did not improve from 42.06635
3000/3000 [==============================] - 1332s 444ms/step - loss: 0.0482 - val_loss: 43.5876 - lr: 0.0010
Epoch 6/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0778
Epoch 00006: val_loss did not improve from 42.06635
3000/3000 [==============================] - 1329s 443ms/step - loss: 0.0778 - val_loss: 46.5396 - lr: 0.0010
Epoch 7/200
3000/3000 [==============================] - ETA: 0s - loss: 0.0847
Epoch 00007: val_loss did not improve from 42.06635
3000/3000 [==============================] - 1328s 443ms/step - loss: 0.0847 - val_loss: 46.8308 - lr: 0.0010

2023-04-12 15:10:02.601697: W tensorflow/stream_executor/gpu/redzone_allocator.cc:314] Internal: ptxas exited with non-zero error code 65280, output: ptxas fatal   : Value 'sm_86' is not defined for option 'gpu-name'

Relying on driver to perform ptx compilation.
Modify $PATH to customize ptxas location.
This message will be only logged once.

Does this error make the training course invalid?

That's the reason!
I used a RTX 3060Ti GPU,which is not compatible with CUDA 10.1.When I change CUDA version to 11.2, and TensorFlow version to 2.5.0,the val_loss goes to negtive now.


Add optional support for rendezvous hashing

To minimize the number of key channel migrations when resizing the cluster https://github.com/SocketCluster/skeleton-rendezvous

Done. Made it the default.


build error 2.2.0-preview1-17099

Is this a Bug or Feature request?:
Steps to reproduce (preferably a link to a GitHub repo with a repro project):
Security warning
Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your
computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning
message. Do you want to run C:\Users\Angkor\Downloads\Mvc-release-2.2\run.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"): r
Using KoreBuild 2.2.0-preview1-17099
WARNING: dotnet found on the system PATH is 'C:\Program Files\dotnet\dotnet.exe' but KoreBuild will use
'C:\Users\Angkor.dotnet\x64\dotnet.exe'.
WARNING: Adding 'C:\Users\Angkor.dotnet\x64' to system PATH permanently may be required for applications like Visual
Studio or VS Code to work correctly.
Adding C:\Users\Angkor.dotnet\x64 to PATH
dotnet-install: Downloading link: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.1.301/dotnet-sdk-2.1.301-win-x64.zip
Description of the problem:
Version of Microsoft.AspNetCore.Mvc or Microsoft.AspNetCore.App or Microsoft.AspNetCore.All:

https://4sysops.com/archives/powershell-bypass-executionpolicy-to-run-downloaded-scripts/ has some suggestions on how to fix this.
FYI @natemcmaster


Add support for recoginizing allow.pub as an spiffe issuer

Summary
Add support for fulcio to allow spiffe tokens signed by allow.pub
Description
I'm building an OCI registry that would like to perform server side
cosign support via fulcio. The OCI registry is called vcr.pub and should
be available in beta form soon.
The reason that the domain used here is allow.pub rather than vcr.pub is
one of the future services we'd like to support is other OIDC related
authentication tasks, so we've separated it from the OCI registry off
the bat.

Once you get the DCO fixed this should be good!

@dlorenc Ah! Ok, DCO fixed!

This should be live!

@dlorenc Thank you!


No confounds file due to IndexError for tcompcor

The following error resulted in not having a confounds file for that run of the subject. Everything else looked fine but I might be missing something.
Node Name: fmriprep_wf.single_subject_100068_wf.func_preproc_task_machinegame_run_001_wf.bold_confounds_wf.tcompcor
File: /oak/stanford/groups/russpold/data/ds000054/0.0.4/derivatives/fmriprep_1.4.0/fmriprep/sub-100068/log/20190704-092934_a41c660f-f278-453c-b0f6-56dc37edc4bb/crash-20190704-200938-zenkavi-tcompcor-34a37fb7-b906-4389-8d3f-3dee188531cc.txt
Working Directory: /tmp/work/fmriprep_wf/single_subject_100068_wf/func_preproc_task_machinegame_run_001_wf/bold_confounds_wf/tcompcor
Inputs:
components_file: tcompcor.tsv
failure_mode: NaN
header_prefix: t_comp_cor_
high_pass_cutoff: 128.0
ignore_initial_volumes: 1
mask_files: ['/tmp/work/fmriprep_wf/single_subject_100068_wf/func_preproc_task_machinegame_run_001_wf/bold_confounds_wf/tcc_tfm/sub-100068_T1w_corrected_xform_rbrainmask_eroded_trans_boldmsk.nii.gz']
mask_index:
mask_names:
merge_method:
num_components:
percentile_threshold: 0.05
pre_filter: cosine
realigned_file: /tmp/work/fmriprep_wf/single_subject_100068_wf/func_preproc_task_machinegame_run_001_wf/bold_bold_trans_wf/merge/vol0000_xform-00000_merged.nii.gz
regress_poly_degree: 1
repetition_time: 1.0
save_metadata: True
save_pre_filter: True
use_regress_poly:
variance_threshold: 0.5
Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 69, in run_node
    result['result'] = node.run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 472, in run
    result = self._run_interface(execute=True)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 563, in _run_interface
    return self._run_command(execute)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 643, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/interfaces/base/core.py", line 375, in run
    runtime = self._run_interface(runtime)
  File "/usr/local/miniconda/lib/python3.7/site-packages/niworkflows/interfaces/patches.py", line 51, in _run_interface
    runtime = super(RobustTCompCor, self)._run_interface(runtime)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/algorithms/confounds.py", line 560, in _run_interface
    mask_images = self._process_masks(mask_images, imgseries.get_data())
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/algorithms/confounds.py", line 760, in _process_masks
    (1. - self.inputs.percentile_threshold)).astype(int))
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/lib/function_base.py", line 3540, in percentile
    a, q, axis, out, overwrite_input, interpolation, keepdims)
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/lib/function_base.py", line 3652, in _quantile_unchecked
    interpolation=interpolation)
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/lib/function_base.py", line 3250, in _ureduce
    r = func(a, **kwargs)
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/lib/function_base.py", line 3767, in _quantile_ureduce_func
    x1 = take(ap, indices_below, axis=axis) * weights_below
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/core/fromnumeric.py", line 181, in take
    return _wrapfunc(a, 'take', indices, axis=axis, out=out, mode=mode)
  File "/usr/local/miniconda/lib/python3.7/site-packages/numpy/core/fromnumeric.py", line 51, in _wrapfunc
    return getattr(obj, method)(*args, **kwds)
IndexError: cannot do a non-empty take from an empty axes.

I'm also missing confounds files for some subjects. As far as I can tell, however, all the confounds are written to the working directory (I've looked specifically at the realignment parameters and framewise displacement). Here is the crash log for this component:
crash-20191011-015931-jvanbaar-merge_confound_metadata-224ef30b-5a7f-43ef-b8f0-50c3a2f9167d.txt
Key lines:
Node: fmriprep_wf.single_subject_002_wf.func_preproc_ses_1_task_wordReading_run_4_wf.bold_confounds_wf.merge_confound_metadata
Working directory: /s1/sub-002/fmriprep_wf/single_subject_002_wf/func_preproc_ses_1_task_wordReading_run_4_wf/bold_confounds_wf/merge_confound_metadata

Node inputs:

axis = vstack
in1 = {'t_comp_cor_00': {'SingularValue':<PHONE_NUMBER>774, 'VarianceExplained': 0.1847431329, 'CumulativeVarianceExplained': 0.1847431329, 'Retained': True, 'Method': 'tCompCor'}, 't_comp_cor_01': {'SingularValue':

[...]

{'Mask': 'WM', 'SingularValue': 0.0, 'VarianceExplained': 0.0, 'CumulativeVarianceExplained': 1.0, 'Retained': False, 'Method': 'aCompCor'}}
no_flatten = False
ravel_inputs = False

Traceback (most recent call last):
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/plugins/multiproc.py", line 316, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 488, in run
    self, report_type='postexec', is_mapnode=isinstance(self, MapNode))
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/utils.py", line 152, in write_report
    result = node.result  # Locally cache result
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/nodes.py", line 198, in result
    op.join(self.output_dir(), 'result_%s.pklz' % self.name))[0]
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/pipeline/engine/utils.py", line 300, in load_resultfile
    result = loadpkl(results_file)
  File "/usr/local/miniconda/lib/python3.7/site-packages/nipype/utils/filemanip.py", line 687, in loadpkl
    pkl_file = pklopen(infile.name, 'rb')
  File "/usr/local/miniconda/lib/python3.7/gzip.py", line 53, in open
    binary_file = GzipFile(filename, gz_mode, compresslevel)
  File "/usr/local/miniconda/lib/python3.7/gzip.py", line 163, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'result_merge_confound_metadata.pklz'

Strangely the file 'result_merge_confound_metadata.pklz' does exist in my working dir.

@jeroenvanbaar I'm quite positive this is a different error - please follow up on #1819.
@rciric, how are we doing with respect to the original issue?

I have re-run this subject without issues.
Re-running led me to think about the nipype issue linked above, to discovering https://github.com/poldracklab/smriprep/issues/189 and then to filing #2129.

I'm closing this as the root cause of it seems to have been addressed.


Add documentation on how to register a changelog from the liquibase docker images

Environment
Liquibase Version:docker latest and docker 4.2.0
Liquibase Integration & Version: <Pick one: CLI, maven, gradle, spring boot, servlet, etc.>CLI docker
Liquibase Extension(s) & Version: N/A
Database Vendor & Version:All
Operating System Type & Version:Mac OS
Description
Need to add documentation on how to use the docker image to register a changelog so that docker liquibase can use hub
Steps To Reproduce
run something like
docker run --rm \
                -v /Users/molivas/Documents/SE/code/props/lms_postgresql:/liquibase/project \
                 liquibase/liquibase \
                 --defaultsFile=project/liquibase.properties \
                 --changeLogFile=project/changelogupdateddemo.xml \
                 --classpath=/liquibase/project/postgresql-42.2.11.jar \
                 registerChangeLog

As the examples show on how to run a liquibase command
Actual Behavior
Error occurs
Unexpected error running Liquibase: No console available
For more information, please use the --logLevel flag
Expected/Desired Behavior
docker liquibase is able to register a changelog file and use it.
Screenshots (if appropriate)
If applicable, add screenshots to help explain your problem.
Additional Context
something like
docker run --rm -it
-v /Users/molivas/Documents/SE/code/props/lms_postgresql:/liquibase/project
liquibase/liquibase
--defaultsFile=project/liquibase.properties
--changeLogFile=project/changelogupdateddemo.xml
--classpath=/liquibase/project/postgresql-42.2.11.jar
registerChangeLog
might work

Closing this as we have deprecated Hub. If this still needs to be documented, please reopen.


Linux PopOs issues

Describe the bug

Icon
Title

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Desktop (please complete the following information):

OS: [e.g. MacOS 10.2]
App Version [e.g. 0.2.0]

Additional context
Add any other context about the problem here.

Updates: Icon works in dev mode only

It doesn't work at all on ubuntu

I am giving up on the icon. couldn't make it work on an arm based ubuntu


Ability to have more than one instance

Implemented this recently, and love it. We have a project where we want to isolate an API in a shared code base. Meaning we want to have our internal users have access to one set of API documentation, and another set of user have access to a different set of api documentation.
We have spring mvc, and I'm having a heckuva time trying to get this to work under two instances.

Eh, I found away it appears, and sorry for posting this here. Call me rookie.


Internal response error. event listener sync: websocket: close 1011

Summary
ERRO[2021-05-26T06:48:14Z] event listener sync: websocket: close 1011 (internal server error): Internal response error
Steps to reproduce
started with docker
Expected behavior
run narmal
Actual behavior
Internal error

The only websocket that I know that bee uses is the swap-endpoint.  So, this error probably means that your swap-endpoint went down while your bee was running.

@ldeffenb 这个问题怎么处理呢,我也全是这个问题

@ldeffenb How do I deal with this problem, which I have a lot of nodes with

This is usually caused by API call limit being exceeded. Please review your infrastructure setup to allow enough API calls per bee node


Bump dart module and improve keybindings

After some months coding with dart I ended with these mapping which I find it's very useful.

Improve mappings for dart
Bump hover and lsp-dart(add test tree feature) to latest version

Ping @hlissner

Done @hlissner

Good work. Thanks again!


fix(db) fix target cleanup and cascade-delete for Targets

This fixes two problems:

Target cleanup was happening in the wrong order. This was not a problem for
the target being inserted (because cleanup happened before insertion), but it
would cause the other targets of the list to be corrupted in case they had a
target history themselves.
Since cleanup happened before insertion (meaning before a weight=0 entry was
inserted upon deletion), this meant that deleting targets never truly emptied
the table -- this meant that Cassandra could not delete upstreams, because the
cascade-delete annotation was missing from the entity schema. Merely adding
on_delete = "cascade" to targets.upstream would fix the problem in #4317
illustrated by the regression test added to
spec/02-integration/04-admin_api/07-upstreams_routes_spec.lua but would not
fix the other problem, illustrated by the test added to
spec/02-integration/04-admin_api/08-targets_routes_spec.lua.

We also add on_cascade = "delete" to the schema, which fixes the inconsistency in behavior between Postgres and Cassandra, as the former included cascade-delete in its migration already.

Fixes #4317.

totally! that was an editing mistake. good catch, thanks!
On Fri, Feb 15, 2019, 14:24 Aapo Talvensaari<EMAIL_ADDRESS>wrote:

@bungle requested changes on this pull request.
Just one question
In kong/db/dao/targets.lua
https://github.com/Kong/kong/pull/4319#discussion_r257300947:

@@ -111,7 +115,7 @@ function _TARGETS:delete(pk)
return nil, err, err_t
end

return self:insert({

self:insert({

Should we handle possible errors in this case?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Kong/kong/pull/4319#pullrequestreview-204323687, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAO_dYJ94ZrZsseS3gTbFyP2xOXzpTX-ks5vNt9FgaJpZM4a92-M
.


Add 'moved' block to terraform module so other teams can use it

User Need
As a moj team
I want to be able to use the central github repo terraform module
so that I can manage my repositories in terraform
Functional Requirements:

Add 'moved' block to terraform module which accounts for changes in resource names, so that teams migrating from other modules, where resources have different names, can more easily transition to use our module e.g., github_repository.main > github_repository.default.

There is no official stance on this, but the "convention" on naming resources in modules tends to use this
https://www.terraform-best-practices.com/naming
https://www.globaldots.com/resources/blog/terraform-naming-conventions-best-practices-a-hell-of-a-practical-guide/#:~:text=Resource name should be named this


Implement SeamMultiWorkspace client

For some reason is shows 0 files changed but if you click into the commits, you'll see the changes


Unify RESP error serialization

In #223 @vazois wished to remove the need from callers to format error messages.
In RESP spec, it is said that the serialized errors of the form -ERR [errorMessage]\r\n are "generic errors". I used this distinction to add WriteGenericError to RespWriteUtils.
The original plan was to have WriteGenericError, which would only take in the error message for the generic errors which are most common. However that specialization would complicate and confuse I abandoned it and instead went for the WriteError
Before this PR all error response serialization happened either by copying the static ASCII encoded error constants or by manually formatting them in the middle of parsing code. The parsing logic often returned a ROS<byte> that could either be a simple error or a CmdString.RESP_OK and used this as the indicator whether an operation was successful or not. Often this returned ROS<byte> was directly copied to the send buffer. This approach was very error prone, as the caller had to correctly format the error string to start with - and end with a terminator \r\n. This was hard to remember and while doing this PR I came across more where this was forgotten or lost during refactors.
This PR flows all simple error serialization string to RespWriteUtils.WriteError. This requires making the error serialization a separate operation from serializing "+OK\r\n" and such required some adjustments in many method overloads. A common pattern introduced in this PR and that already existed in the project is familiar and intuitive bool TryX(.., out Y value) pattern from BCL. In majority of the places where we previously returned a ROS<byte> of either error or OK, we now return boolean indicating whether the there was error or not. If there was error (it returned false), we can grab the error string from out parameter.

Starting to think special casing the generic errors would be a mistake and everything should flow into WriteError instead..

Fantastic cleanup!!

Gonna do one more commit where I move more of these error strings to CmdStrings

Gonna do one more commit where I move more of these constant error strings to CmdStrings

Sounds good, though try to avoid big PRs since they hard to review and could result in a lot of conflicts at merge time.

Gonna do one more commit where I move more of these constant error strings to CmdStrings

Sounds good, though try to avoid big PRs since they hard to review and could result in a lot of conflicts at merge time.

Yeah.. these tend to get a bit out of hand too easily😬I'll leave the constant as follow-up for anyone to do instead..


Motivation / Problem Statement

I wanted to drill down into the problems with the current Luarocks installation process. There's an excellent corpus of issues on the repo proper:

Why Luarocks user experience is so bad?
Compiler error
Docs improvement
Suspected rock packaging error
Actual CLI issue because of dynamic dependencies
All Windows issues

I've mostly looked at Windows issues because that's where I would expect that the developer experience is the worst. Based on the number of labelled issues, MinGW seems to improve the experience. I wouldn't be surprised if a properly configured Cygwin environment also made things simpler. Although this may be selection bias as the users capable of installing and configuring Cygwin are going to be less likely to encounter issues setting up Luarocks generally.
More work should be done to categorize issues from more than just this single source but from this cursory overview I can begin to identify a few distinct problem areas.

Compiler infrastructure and environment on Windows. This is probably not solvable. Rust does a decent job of it but they own the whole ecosystem and can put guardrails in place. Maybe improvable in concert with package structure and validation but the flexibility that rocks offer with regards to packaging means that this almost certainly can't be made to work for all users.
Package validation - particularly cross-platform. This segues into but is distinct from compiler infrastructure. There are some issues about invalid rocks being published. There really isn't a reason to ever allow that to happen unless the packaging allows so much flexibility that it can't be validated (which is where the compiler infrastructure ties back in).
Contribution guidelines for docs. I sort of think that the only way to solve this is by making thing so simple that they require fewer docs. The number of people and the amount of docs would make this a full time job to administer. Tedious.
Ergonomics. Again, I don't know if this is just the nature of the complexity or if there's actually some gnarly footguns in here. Best solution would be to keep cutting until it's very barebones. But is what you're left with useful?

To synthesize, I think that the largest issue is compiling and environment on Windows and I think that that is largely because most of these packages were never compiled on Windows. The simplest solution would be to ship static binaries for all packages with native modules. Would be interesting to see, from the existing set of luarocks, how many are source rocks that expect to be compiled and how much work it would be to convert those to binaries for all supported architectures. Does that then allow you to basically shim the existing ecosystem? Do you even need to fix compilation if you can just download packages with a CLI without needing a compiler?

Here's a first pass at a dump of the luarocks root manifest.
There are 26326 total package-version combinations.
Of those, 11308 use a "non-simple" build type (not "builtin" or "none"). Take this with a grain of salt. "builtin" packages can still indicate that a compilation step must take place. And also people misuse this field like crazy and it is apparently not validated so it is probably a very noisy metric. To wit, 8556 packages use a built type that is not outlined in the rockspec format specification but, as you will see later, that spec is pliable with regards to build types.
34 of the packages in the root manifest have a syntax error in their rockspec or are otherwise malformed. However, many of these are just that they have a shebang at the start of the file with two exceptions:

This one has a space in the name and is rejected by hosting server despite being in the manifest.
This one has no source rock or source URL. It purely metadata and would (hopefully) be rejected if submitted today.

There are some packages that report having platform-specific binaries (whether that's true or not) but it's very rare. Almost everything distributes source.
"win32-x86": 59,
"src": 21457,
"linux-x86_64": 2,
"macosx-x86_64": 75,
"kindlepw2": 1,
"macosx-x86": 1,
"all": 124,

My perspective at the end of this is that the flexibility and lack of validation in the luarocks package/build system means that there is generally not enough information present to ensure that a package can be compiled on a user machine.
Consider decasify. I've picked this at random because it uses a custom build system but it's also the development environment that I've most familiar with: Rust.
It depends on and correctly invokes the build system for rust-mlua.
Rock: https://luarocks.org/modules/khvzak/luarocks-build-rust-mlua
Source: https://github.com/mlua-rs/luarocks-build-rust-mlua/blob/main/src/luarocks/build/rust-mlua.lua
That would likely build on my machine. But it won't build on someone's machine if they don't have Rust installed. It won't build on someone's machine if they have an old version of Rust installed. And it will build but probably won't work on someone's machine if their native Rust target differs from the arch their Lua was compiled for.
Solvable? Definitely.
Solvable on everyone's individual setups? Probably not.
So the question in my mind is: do we care about this package? Do we care about any of the packages that have as many downloads as this one does (~200 over the course of a year+)? Do we care about packages that use toolchains outside of C? Outside of C++? Outside of GCC? If we only cared about packages that could be compiled with GCC what additional information would the Luarocks package have to contain in order to ensure that it's compilable on a user's machine?
I think this is a pretty gnarly problem to tackle, holistically. I do think it is, partially, a package manager problem but I think that what information is required to be contained in that package is tough to know because of how dynamic these rocks are allowed to be. Maybe a collection of rocks that are difficult to compile on Windows but are well-used would be a good corpus to start looking more deeply at.


Fix emitting hexlike strings without quotes

The emitter omitted quotes for strings that start with 0x those would
subsequently be parsed as strings again. This should fix #133.

:point_up_2:  @chyh1990 @dtolnay this should be a 0.4.4


fix(docs): method name and minor typos

Hey!
By reading the docs I found out a wrong method name used in the cross-reference serialization section and a few typos. This PR aims to fix them.

Thanks! I forgot to cross check that getCrossReferenceHeader


NO-ISSUE: Minor fixes in the DMN Runner with Included Models

On this PR

Fix DMN Runner breaking after deleting the file that is included in another DMN;
Improved the error message to guide the user to remove any reference of a deleted file in the "Included Models" section if this is the case;
Add the case where the DMN JSON Schema comes with nsYInputSetX instead of InputSetX; This case happens when the target DMN has included models with types or nodes with the same name.

@ljmotta is there some relationship with https://github.com/kiegroup/kie-issues/issues/403?


Fails to parse inline includes when async loading

I place next to the demo HTML the following template files:
bar.twig:
Test template = {{ test }}

and foo.twig:
Before{% include "bar.twig" %}After

From the HTML I request loading and parsing like:
    twig({
      id: "foo",
      href: "foo.twig",
      allowInlineIncludes: true,
      async: false
    });

    console.log( twig({ref: 'foo'}).render({test: 'tst'}) );

Here what I get in the console:
Error parsing twig template foo:
Cannot read property 'renderAsync' of undefined

it refers to parse method of Twig to the line:
return template.renderAsync(innerContext);

Well, seems I had absolute path when referring template from template, but relative one is expected


Will Linorobot work with "Teach and Repeat"?

Have you tried the (non-akkerman) linorobot with github.com/norlab-ulaval/husky-trainer?
I could only get it to work about 10 seconds before crashing on my ROS machine

Hi Russ, this should technically work with teach and repeat. As long as the topics from both packages are mapped correctly.


Add comment to top of the snapshot file

Something to explain to people new to the concept that this is a generated file and perhaps a link that explains how snapshotting works :)

I think that will be quite annoying if you have looads of snapshot files and all of them have the same header.

Hmmm... I was just thing something like:
// this is a generated file. Learn more: bit.ly/jest

Something simple so new people don't try to edit the file directly. I honestly don't see any problem with having the same comment in every file. I would expect people to naturally glaze over the top of the file anyway. I'd get used to it anyway :)

I think to do this we need two things:

A detailed blog post explaining what snapshot testing is and why it is useful (and when not to use it). @kentcdodds are you willing to help with that for the Jest blog?
A simple 3-5 word explanation so that the comment with URL fits into one line.

I'd be happy to write a blogpost for the Jest blog sometime.
For the wording, how about:
// this file is generated, learn more: http://bit.ly/jest-snapshot

I'm sure that'd fit on one line on pretty much anyone's screen.

@cpojer Is this still needed? I'd be happy to try and tackle this one if @kentcdodds don't want it.

Go ahead :-)

I'm gonna close this out due to inactivity. It hasn't really come up, so I'm inclined to keep snapshot files to the bare minimum.

I just move to jest 22, and I have a lot of .snap files, now I have to commit all of them again =/


Retraining for TFLite

Hi Dusty,
After having achieved pretty good object detection results with Jetson Nano, DeepStream SDK, Resnet and PeopleNet (both 4 classes models), I'm now going to achieve the same performance on another platform (RaspberryPI+Coral TPU). I know it is not your party, but I'm really baffled by the quality of your work, tutorials and documentation and I thought you could provide me some input from your experience, if you like.
Since I was not able to follow successfully the Google tutorial (https://coral.ai/docs/edgetpu/retrain-detection/#using-the-coral-dev-board) for transfer learning on object detection, I thought probably this could work:

The aim is to re-train a MobileNet SSD v1 or v2 model for 90 classes to be fit for 4 classes only (person, car, roadsign, bicycle) and run it on a Coral TPU with the same performance I get from a Jetson Nano with DeepStream. Right now I'm achieving  30 fps inference rate at 640x480 for three USB cameras simultaneously on the Nano, 30 fps for each cam. I'm only able to achieve 10 fps per cam with the RPI/Coral tuple. I would like to improve that at least by factor 3. I'm sure, using a class-reduced model would definitely help.

So I thought I could follow one of your tutorials first and either re-train an existing model with a sub-dataset or create a new model from scratch with own imagery and annotations. You have provided very nice videos and documentations for that, it shouldn't be too problematic to come to first results with that. That would allow me to run the training on the Jetson GPU and - as far as I hope - I could also use the resulting model together with the DeepStream SDK (?) on the Nano for comparison and tests.

Then it would be awesome to make this model "Google TPU ready". As far as I understood you are in a first step converting Torch to ONXX, while I would need a TFLite model from the Torch output, which then would need to be compiled by the edgetpu compiler to an edgetpu.tflite model. I thought I could use maybe this repo in order to make the conversion from Torch to TFLite

https://github.com/omerferhatt/torch2tflite
I have not started any of these adventures. I was just checking, if this path is promising. May I ask you for your opinion on that?
I hope it is not too blasphemic to ask for Google on a Jetson project.
Kind regards

Hi @neilyoung, unfortunately having never used the Coral device (and not much hands-on TensorFlow myself), I'm afraid I won't have much experience to lend here.  You could give the torch2tflite converter a shot.  Here is also one that I found for ONNX-to-tflite:  https://github.com/joshuacwnewton/ONNX-to-TFLite

Hi Dusty,
thanks for the quick and honest answer. And for the link. I quickly tested it, it looked promising, but I got stuck https://github.com/joshuacwnewton/ONNX-to-TFLite/issues/1
Anyway, I think I will give it a try and report if successful

Regarding your "fruit" retrain video: I followed it, but the number of images available for exactly the same classes is way less 6000. It is about 1600. Does that make sense?

OK, I was running the training on this set of 1600 images on the Jetson Nano. Besides the fact, that I had to switch to sudo init 3 in between, the training came through with an avg error of 6%. Note: I did run it with epoch=1 first in order to see, if it passes. The torch -> onxx conversion was fine and also detectnet did run. But it didn't detect anything, means: There was no object annotated with a bounding box and a likelihood in the data/images/test folder. Is this an expected result for epoch = 1 (what I could understand) ?
I'm just asking because I also didn't achieve any detection with the model you are offering for download on the tutorial page (the one with the 100 epochs)

Works


Custom element won't render in nested element under IE8.

Look at the following code, 123456 will be displayed in other browser but IE8,
IE8 only show 123，a-item element does not render. What should I do?
document.registerElement(
    'a-item',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    this.innerText = this.getAttribute('name');
                }}
            }
        )
    }
);

document.registerElement(
    'a-list',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    this.innerHTML = '123<a-item name=456></a-item>';
                }}
            }
        )
    }
);

var a = document.createElement('a-list')
document.body.appendChild(a);

innerHTML  requires a special file ... have you included it?
https://github.com/WebReflection/document-register-element#using-innerhtml

Yes,I has include it,should I use innerHTML instead of element.innerHTML?

that would be my first hint, the second one:
var a = document.createElement('a-item');
a.name = '456';
this.append('123', a);

the .append method comes from DOM4 https://github.com/WebReflection/dom4/#dom4

Actually, I want to use element.innerHTML method creating dom.Can you support it or what should I do ?

if you read this https://github.com/WebReflection/document-register-element#using-innerhtml
and the bug related https://github.com/WebReflection/document-register-element/issues/21
you realize that I won't support that within the polyfill, but I am supporting it already through the helper script: https://github.com/WebReflection/document-register-element/blob/master/build/innerHTML.max.js
Your code should look like the following:

var innerHTML = innerHTML || document.registerElement.innerHTML;

document.registerElement(
    'a-item',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    this.innerText = this.getAttribute('name');
                }}
            }
        )
    }
);

document.registerElement(
    'a-list',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    // this is the main difference
                    innerHTML(this, '123<a-item name=456></a-item>');
                }}
            }
        )
    }
);

var a = document.createElement('a-list')
document.body.appendChild(a);

If you don't have the innerHTML available it means you are not including it instantly after this polyfill, but you should.
This is an example on how you should include bits and bops
https://github.com/WebReflection/document-register-element/blob/master/index.html#L9-L14
Be sure every version of each script points to the latest/right file.
I am going to close this. Let me know how that went.

ok, I try to run your code, but it can't render under IE8 too.

innerHTML's way
It won't render

append's way
It will be render as 123null

The following is my full code.
<!DOCTYPE html>
<html>
    <head>
        <title>document-register-element test</title>
        <meta http-equiv="content-language" content="en-US"/>
        <meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no"/>
        <meta name="apple-mobile-web-app-capable" content="yes"/>
        <meta names="apple-mobile-web-app-status-bar-style" content="black"/>
        <!--[if lte IE 9]><script>(function(f){window.setTimeout=f(window.setTimeout);window.setInterval=f(window.setInterval)})(function(f){return function(c,t){var a=[].slice.call(arguments,2);return f(function(){c.apply(this,a)},t)}});</script><![endif]-->
        <!--[if IE 8]><script src="http://cdnjs.cloudflare.com/ajax/libs/ie8/0.2.3/ie8.js"></script><![endif]-->
        <script src="http://cdnjs.cloudflare.com/ajax/libs/dom4/1.4.5/dom4.js"></script>
        <!--[if IE 8]><script src="build/dre-ie8-upfront-fix.js"></script><![endif]-->
        <script src="build/document-register-element.max.js"></script>
        <script src="build/innerHTML.max.js"></script>
        <!--[if IE 8]>
     <script src="//cdnjs.cloudflare.com/ajax/libs/es5-shim/4.1.0/es5-shim.js"></script>
     <script src="//cdnjs.cloudflare.com/ajax/libs/es5-shim/4.1.0/es5-sham.js"></script>
   <![endif]-->
    </head>
    <body>
      <script>
      document.registerElement(
    'a-item',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    this.innerText = this.getAttribute('name');
                }}
            }
        )
    }
);

document.registerElement(
    'a-list',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    // this is the main difference
                    innerHTML(this, '123<a-item name=456></a-item>');
                    // var a = document.createElement('a-item');
                    // a.setAttribute('name', '456');
                    // this.append('123', a);
                }}
            }
        )
    }
);

var a = document.createElement('a-list')
document.body.appendChild(a);
      </script>
    </body>
```html

what happen if you move that part after onload?
this.onload = function () {
  var a = document.createElement('a-list');
  document.body.appendChild(a);
};

Maybe there is some asynchronous initialization problem.
In any case, bear in mind support for IE8 is experimental. There might be hiccups

The same result.May be it's not onload reason. I find the problem, asynchronous reminds me.
I try to use append's way,and make createdCallback asynchronous, it works.
document.registerElement(
    'a-item',
    {
        prototype: Object.create(
            HTMLElement.prototype,
            {
                createdCallback: {value: function () {
                    setTimeout(function(){
                       this.innerText = this.getAttribute('name');
                    }.bind(this), 10);
                }}
            }
        )
    }
);

so I think should make createdCallback asynchronous under IE8, I try to modify code at https://github.com/WebReflection/document-register-element/blob/master/src/document-register-element.js#L471-L472
if(IE8){
      setTimeout(function(){
        node.createdCallback();
        node.created = false;
      },10);
    }else{
      node.createdCallback();
      node.created = false;
     }

well, it works any way, even I use element.innerHTML.(Just create it before append DOM)
Thanks.

unfortunately making it always asynchronous breaks every other test so it's not an option.
I will think about it, meanwhile it's good there is a bug to point at. I am going also to keep this close for now as won't fix, I might eventually update it or reopen it whenever I'll find time to dig into why on earth IE8 is again causing troubles.
Apologies if this solution is not ideal but the support for IE8 is very edge-case and experimental, I can't make this right now a priority for me (zero time)


Fix typo: "server-only" to "client-only"

Fixed a heading that did not correctly reflect the following text.
This section describes how to display server-side fallback for client-only content. Saying "server-only content" is inappropriate.

Yeah nice catch. I think "client only" is what's meant here, given the code throws on the server.


Teams ActionBasedMessagingExtensionFetchTask Scenario

Add MessagingExtensionQuery param to OnTeamsMessagingExtensionFetchTaskAsync
Update ActionBasedMessagingExtensionFetchTaskBot and Readme.md

Pull Request Test Coverage Report for Build 80140

0 of 0   changed or added relevant lines in 0 files are covered.
348 unchanged lines in 58 files lost coverage.
Overall coverage decreased (-0.6%) to 80.633%

Files with Coverage Reduction
New Missed Lines
%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Twilio/TwilioAdapter.cs
1
85.71%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Webex/WebexAdapter.cs
1
95.41%

/libraries/integration/Microsoft.Bot.Builder.Integration.ApplicationInsights.Core/ApplicationBuilderExtensions.cs
1
71.43%

/libraries/Microsoft.Bot.Builder/ActivityHandler.cs
1
9.72%

/libraries/Microsoft.Bot.Builder.AI.LUIS/LuisApplication.cs
1
95.45%

/libraries/Microsoft.Bot.Builder.Dialogs/Prompts/PromptValidatorContext.cs
1
82.35%

/libraries/Microsoft.Bot.Builder.Dialogs/WaterfallStepContext.cs
1
86.96%

/libraries/Microsoft.Bot.Builder/TelemetryLoggerMiddleware.cs
1
57.58%

/libraries/Microsoft.Bot.Builder.Testing/XUnit/TestDataObject.cs
1
82.35%

/libraries/Adapters/Microsoft.Bot.Builder.Adapters.Twilio/TwilioClientWrapper.cs
2
0.0%

Totals

Change from base Build 80137:
-0.6%

Covered Lines:
3872

Relevant Lines:
4802

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.3.1

:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.Luis.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.AI.QnA.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.ApplicationInsights.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Azure.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.Dialogs.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Builder.TemplateManager.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Configuration.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Connector.dll compared against version 4.3.1
:heavy_check_mark: No Binary Compatibility issues for Microsoft.Bot.Schema.dll compared against version 4.3.1


Add another possible attack surface for self hosted runners

Why:
Closes #7731

What's being changed:
Please refers to the changed files.
Check off the following:

[ ] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[ ] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@BoleynSu Thanks so much for opening a PR! I'll get this triaged for review ⚡


TNBC Games - MILESTONE 1-

Link to the milestone and objectives table.
#268
Detailed log of all completed objectives including valid proof of work.
https://whimsical.com/tnbc-games-439zkbRtHN5xmLUyX353Sw
Project Wallet
86ee75d4cea77ca8339cc97f5e7426a3434d9f91465cd441c0c7593bd852e955

Approved.


You recently pushed to this branch does not always appear on first push

Description
I've noticed that the You pushed on branch <branch> <time> ago message doesn't always appear when you open the repo after pushing the branch for the first time.
Subsequent pushes are handled correctly as intended.
But in my experiments, I only got the message 1 out of 3 times that I pushed a branch initially.
In particular, if you get the message for a branch, you will consistently get it with every page reload.
But if you don't get it, you will consistently not get it, no matter what you do.
Seems like something is getting inserted into the DB incorrectly.
Gitea Version
1.22.0+dev-47-g70f8d10fc
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
I cannot show the absence of something in a screenshot
Git Version
Whatever try.gitea.io is running
Operating System
Whatever try.gitea.io is running
How are you running Gitea?
try.gitea.io
Database
None

This should be fixed by #29493. In previous implementation, the branches will be inserted async.


Support "get type of the expression" functionality

It's very useful to be able to get the type of the expression at the cursor position. The way this feature should ideally work is that you place the cursor on the target expression, like 1 +<|> 2.foo(), then press "extend selection" several times until you select the the whole expression, and then invoke "show type".
Unfortunatelly, LSP does not have an API for this sort of functionality yet, so we need to hack it a bit.
I propose the following plan:

define type_of_expression(&self, FileRange) -> Option<String> API on the Analysis
implement  textDocument/hover on top of it. Hover talks about positions, not ranges, so the implementation should first find an ast::Expr at the given offset (using find_node_at_offfset) and then invoke type_of_expression.
Implement our own extension ra-lsp/typeOfExpression which sends a range instead of a single offset.

See this issue for the implementation tips.

I try this, before #388.

@matklad
I think type_of_infer needs Hir::Expr and that is discussed at #386.
Did I get that right?

add Hir::Expr
add type_of_expression to ra_analysis
add textDocument/hober
add ra-lsp/typeOfExpression that might be as textDocument/codeAction

@h-michael I am not sure: we already have Analysis::type_of which works with ranges, here:
https://github.com/rust-analyzer/rust-analyzer/blob/5a866a772c863ba7e3ec8bad353c1b6997a7a62a/crates/ra_analysis/src/lib.rs#L373-L375
So we only need to expose that to the LSP layer, by writing appropriate handlers in ra_lsp_server crate.
hir::Expr is required to make the implementation of Analysis::type_of more powerful, but it shouldn't affect the interface.

@matklad
Now, ra_lsp_server#handle_hover shows Analysis#doc_text_for's results.
Might we merge Analysis#type_of's result with above, or replace with Analysis#type_of's result?

I think we should prefer to show docs over showing the type.

I think we should prefer to show docs over showing the type.

What you said is that we show type by ra-lsp/typeOfExpression or textDocument/codeAction instead of textDocument/hober ?

No, I mean the logic should be as roughly follows:
fn handle_hover(position) {
    lf let Some(docs) = analysis.doc_text_for(position) {
        return docs
    }
    if let Some(type_of) = analysis.type_of(position) {
        return type
    }
}

I see, thanks for explaining a detail!

This is handled in description_of, btw.

This should be handled in description_of, btw.

I also think it is better.

Blocked on upstream: https://github.com/microsoft/language-server-protocol/issues/377

Actually, there's no reason to wait for the upstream -- we can just impletent this extension on the server, emacs and vim folks will probably pick it up, and then we can poke upstream until this is documented. So, mentoring instructions:

take a look at the https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/docs/dev/lsp-extensions.md#L1
and https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/rust-analyzer/src/lsp_ext.rs#L1
add hoverRange server capability.
change HoverParams to contain Position or Range. See lsp_ext::CodeAction for how to extend existing structures
document the extension
extend the implementation to support ranges: https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/ide/src/lib.rs#L405-L414
plumb this to LSP: https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/rust-analyzer/src/handlers.rs#L858-L881

@matklad Can I take a jab at implementing this?

@alexfertel it's yours.

@alexfertel sure!

Hey, guys, sorry to be this slow, I haven't had a lot of time and there's a lot of reading (both code and not code) to be done, so I can tackle this implementation.
I promise that I will eventually submit a PR, hopefully in the next few days.

No rush, it takes time to get familiar with unknown codebases. If you got questions about things you don't understand or which seem unclear feel free to hit up the zulip channel.


Fixes 7640

Related issues (optional)
Fixes #7640

Deploy preview for docsdocker ready!
Built with commit 60a3b22611c75929bfd9e57e77bea3a8881fd2d8
https://deploy-preview-7644--docsdocker.netlify.com


how to clear the existing hypervisor information from the KVM-VDI dashboard

Thanks!!!!!!
Am cleared the hypervisor information from the database.


StringLookupPropertyEditor initiates postbacks instead of callbacks

When selecting an item from the list

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


🎉 3.0.0

ℹ About this release

Version: 3.0.0
Type: major
Last Release: 2.0.5 (2/8/2023, 7:10:31 PM) [?]
Commits to merge: 36 [?]

🐛 Bug Fixes

Fix CalendarPage date issue (5a8937a)
Update MQTT Client import (21a3ebd)

Build System

Deprecate node.js 12 (426588b)

⚡ BREAKING CHANGES

From now on, only node.js ^14.8.0 || >=16.0.0 are supported

📦 Dependencies

Update node-ical from ^0.15.3 to ^0.16.0

📦 Development Dependencies

Added tsup ^6.7.0
Update @qiwi/semantic-release-gh-pages-plugin from ^5.2.4 to ^5.2.5
Update @types/node from ^18.13.0 to ^18.15.3
Update @typescript-eslint/eslint-plugin from ^5.51.0 to ^5.54.1
Update @typescript-eslint/parser from ^5.51.0 to ^5.54.1
Update c8 from ^7.12.0 to ^7.13.0
Update eslint from ^8.33.0 to ^8.36.0
Update eslint-plugin-jsonc from ^2.6.0 to ^2.7.0
Update typedoc from ^0.23.24 to ^0.23.28
Update typescript from ^4.9.5 to ^5.0.2

:tada: This PR is included in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release
Docker container (sebbo2002/vestaboard2mqtt:3.0.0)
v3.0.0

Your semantic-release bot :package::rocket:


Printing Copyright text optionally

This seems to find the license only in the representative license file (ex- NOTICE, LICENSE.txt). Is that right?
At this time, it would be really nice to print copyright text in the file as an execution option.
Is there a way to do this?
Best regards

That is correct. In fact, askalono actively tries to throw out copyright data when identifying a license, as it helps with license matching and speed.
It would be possible to add a mode to preserve and extract copyrights, but a significant overhaul would be needed to some components. I'm open to the possibility.
Right now, if you want to extract copyright data, I recommend checking out https://github.com/nexB/scancode-toolkit.


Upgrading ChefDK with user gems installed often fails

When ChefDK gets a new ruby and new dependencies, the gems installed in ~/.chefdk are still there, but their dependencies are not. Bringing up things that include those gems will fail.
One fix to this is to make the gems directory version-specific, i.e. ~/.chefdk/0.8.0/gems.
Another possibility is to install a copy of all dependent gems into ~/.chefdk/gems when we install any gems there (but this won't handle Ruby version upgrades).

related issue for /opt/chef and /opt/chefdk wiping on upgrade:  chef/chef#4939

Potential solution here is to implement a chef doctor (similar to brew doctor) that could recognize when an upgrade has occurred and recommend remediation steps.

@tduffield I like that idea. It would need to run without loading the gems that would cause a problem. Perhaps there is some simple early platform examination operation that would check, report and perhaps suggest potential fixes.

Prior art from vagrant:
Vagrant failed to initialize at a very early stage:

The plugins failed to initialize correctly. This may be due to manual
modifications made within the Vagrant home directory. Vagrant can
attempt to automatically correct this issue by running:

  vagrant plugin repair

If Vagrant was recently updated, this error may be due to incompatible
versions of dependencies. To fix this problem please remove and re-install
all plugins. Vagrant can attempt to do this automatically by running:

  vagrant plugin expunge --reinstall

Or you may want to try updating the installed plugins to their latest
versions:

  vagrant plugin update

Error message given during initialization: Unable to resolve dependency: user requested 'vagrant-winrm (= 0.7.0)'

The same kind of repair/expunge/update commands could be implemented to support maintenance of the .chefdk directory after an upgrade.

This is going to be a multiple phase card. First we need to identify exactly what the failure scenarios are. Second we need to decide how we want to fix those different scenarios. We may end up creating multiple cards based on this.
Questions: What do we do about gems that violate the mega-gem-lock? What about gems that have been installed for a super long time?

Custom gems and hardened runtime on MacOS - something to consider, see https://discourse.chef.io/t/chef-software-on-macos-catalina/16626

Also see https://github.com/chef/chef/issues/9338

Given:

Chef Workstation has a pre-approved set of gems.
Chef Workstation is their Chef development environment, not their Ruby development environment

Developing a cookbook locally with an extra gem not in ChefWS means they have to also install that gem on all their nodes
We don't want them to develop Rails apps using ChefWS

Questions:

What constitutes a 'bad gem'? What is our repro case?

Gem installed that depends on a non-existing gem in the mega lock
Gem that has changed the class definition so inheritence breaks

What do we do about gems that violate the mega-gem-lock? How do those even pop up with the current Appbundler?
What is the repro case for custom gems on MacOS Catalina? https://discourse.chef.io/t/chef-software-on-macos-catalina/16626

chef_gem fails because / is a protected resource (https://github.com/chef/chef/issues/9338)

Things that are not broken - chef gem install works correctly

Problem:

Users need to install gems to have their workflow function

chef_gem resource (is this valid?) (installs to /opt/chef)
chef gem install command line

Solutions:

Wipe /opt/chefdk and ~/.chefdk before installation

Means users would have to chef gem install again
We could leave a marker

Get rid of chef gem install

Bad for users

Automatically re-install gems from ~/.chefdk

Could use a command like chef doctor

Chick-and-egg problem
unless we do it from Golang, but we would still need to leverage the ruby install

Could attempt to do on install and either fail or log a message
Probably need all chef commands to fail if they have bad gems in that directory?

Repros:

Completely random, non-conflicting gems don't seem to be an issue
Downgrading from ChefWS 0.15.18 (ruby 2.6) to 0.3.2 (ruby 2.5) gives a LoadError: cannot load such file error trying to load a file installed into ~/.chefdk

chef gem env: - USER INSTALLATION DIRECTORY: /Users/tball/.chefdk/gem/ruby/2.5.0
Manually changing the gem path finds the old install
But it prepends the gem path, so that would probably raise errors for conflicts

gem install rspec -v 3.9.0 on ChefWS 0.3.2 (rspec 3.8.0)

running chef exec rspec -v returns 3.9.0 even though it is appbundled to 3.8.0

gem install opscode-pushy-client -v "< 2.99" on ChefWS 0.3.2 (pushy 2.99.0)

pushy-client -v and chef exec pushy-client -v respect the appbundle and return 2.99.0

Looks like the GEM_PATH load order wants to load the higher version gem regardless of the appbundle?
gem install chef -v "~> 13.0" installs 13.12.14 into ChefWS 0.3.2

chef exec chef-client -v -> 14.13.11

gem install chef -v "~> 15.0" installs 15.8.23 into ChefWS 0.3.2

chef exec chef-client -v -> 14.13.11
chef-client -v -> 14.13.11
pry; require "chef"; Chef::VERSION -> 15.8.23

Install ChefWS 0.3.2, chef shell-init, gem install chef-apply -v 0.3.0

update to ChefWS 0.15
knife node list

custom tbizzle gem with dependency on logify
If the ruby version switches they will also have this problem because chef shell-init will no longer be pointing
at that existing folder.

> tbizzle
Traceback (most recent call last):
	8: from /Users/tball/.chefdk/gem/ruby/2.5.0/bin/tbizzle:23:in `<main>'
	7: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems.rb:303:in `activate_bin_path'
	6: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems.rb:303:in `synchronize'
	5: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems.rb:304:in `block in activate_bin_path'
	4: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1420:in `activate'
	3: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1438:in `activate_dependencies'
	2: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1438:in `each'
	1: from /opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems/specification.rb:1449:in `block in activate_dependencies'
/opt/chef-workstation/embedded/lib/ruby/2.6.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'logify' (= 0.2.0) among 36 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/Users/tball/.chefdk/gem/ruby/2.5.0:/opt/chef-workstation/embedded/lib/ruby/gems/2.5.0', execute `gem env` for more information

There is some kind of pre-install script, somewhere, that detects if the user has ChefDK already installed
https://github.com/chef/chef-workstation/pull/251/files
Desired Outcomes:

Chef WS is a locked set of gems that we declare works together
Users can install gems into that environment as long as they do not conflict
Chef WS is their Chef Ecosystem development environment (not their rails development environment)
When users upgrade Chef Workstation they do not see conflicts from missing gems or conflicting versions

Putting gems into ~/.chefdk/0.16.8 creates a new problem of user installed gems that were working suddenly stop working.
But this same break would happen whenever the ruby version we package changes.
check - uninstall command and postrm script honors the folder (leave them alone)
Reasoning

We want a better plugin model - no installing any plugin into the Ruby development environment

get rid of chef gem install

File a card to implement a 'clean install' option to the installer

this would need review from product and UX

versioned gem folders make sense, but we want a full featured plugin model instead of replace chef gem install
that plugin model would have some kind of chef doctor functionality if necessary

Okay, we spent some time looking at this issue and here are our thoughts:

Chef Workstation (the package formerly known as "ChefDK") is meant to be the Chef ecosystem development environment. It is not meant to be a general-purpose Ruby development environment. To this purpose, chef gem install has been deceptive in the long term, although necessary. There are valid reasons users want to install gems into their development environment.
We want to allow users to modify their Chef Workstation installs with a plugin system. This would allow us to add features to Chef Workstation that have the same benefits (guaranteed dependencies, testing across the ecosystem, etc.) without making it seem like a general-purpose Ruby development environment.
A plugin system is not something we have the resources to implement right now. So we discussed the following as short term solutions:

Deleting ~/.chefdk on package install. This is our suggested solution to users who encounter problems like this (dependency problems caused by installing gems into the Chef Workstation development environment). Drawbacks:

This removes user-installed gems that do not have conflicts.
It is hard to communicate to the user if we do this at installation time.
It removes any record of gems users had installed, which sucks if they installed something a long time ago that still worked and have forgotten what it is.
It requires users to re-install their gems every time they upgrade their version of Chef Workstation.
We would like to get better telemetry about gem installations to determine how many users this would affect.
Side note - this happens to users automatically whenever we upgrade our Ruby version because the GEM_PATH is modified. EG, .chefdk/gem/ruby/2.5.0 -> .chefdk/gem/ruby/2.6.0. But we only switch Ruby versions about once per year so this does not happen to users very often. Whenever we do, if they run chef shell-init in a new terminal it looks like all their previously installed gems are no longer there.

Moving gems in ~/.chefdk/gem to a folder versioned on the Chef Workstation installation, EG, ~/.chefdk/0.18.15/gem. This keeps a history of gems, and allows users to 'roll back' their installation to a known working state if they get dependency conflicts. But it presents a lot of the same issues with deleting ~/.chefdk at installation time, so is only a minor improvement.
A chef doctor command that would attempt to migrate gems from a previous Chef Workstation installation to a new Chef Workstation installation. We determined we do not currently have the resources to create this tool, and it also re-inforces usage of chef gem install, a tool we want to get away from.
A post-installation hook that users could create that would re-install gems for them. Something like ~/.chefdk/postinstall.sh that is called from the installer automatically after installing. This would allow us to delete previous gems and users only have to define custom gems they want installed once. But again, it reinforces usage of chef gem install.
A 'clean installation' option in the installer. This would be an option, selected by default, in the installer. Users who did not want their ~/.chefdk folder deleted could uncheck it and choose to deal with potential dependency issues. We hypothesize it would be advanced users who unchecked this box and are comfortable with the work of managing their installed gem dependencies.

Weighing our estimate of how many users this issue affects (hopefully less since we improved appbundler and reduced our old bundled software), how long the issue has been open, and how many resources we have we decided to work on the clean installation option. Closing this issue for now and we will track future work in https://github.com/chef/chef-workstation/issues/960


Fix/issue #294: Upgrading Node and npm versions

This PR will upgrade the Node version from v12 to v16 and npm version from v6 to v8 for backend and frontend
Code and test cases are also updated according to same.
Angular version would be updated in separate PR

The main docker file still says 12.22.0 node image, should be updated to 16.3.0
Running in local docker setup I get js heapspace error in the frontend build.... running outside of docker all appears to work fine. Did you run into this @ppratikcr7 ?

I increased the memory settings in my local docker app (via the docker GUI > settings gear > resources > advanced) from 2GB to 4GB, and it started.
It could be very well that the app uses resources differently now with npm / angular versions updated; many suggestions online point to including a command in the npm scripts or in the Dockerfile to add something like "export NODE_OPTIONS=--max_old_space_size=4096 or whatever is needed. If this is an issue that pops up for others or in the pipeline builds, this may be something that needs to be added.

Thanks @danoswaltCL for pointing this out, actually I had mentioned in the meeting notes that I am yet testing this for docker setup. Earlier I did check on docker when I managed to get frontend peer dependencies to be installed using a force flag. But, I am yet to test this now when I have managed to get frontend packages installed without a force flag. Thanks for the finding, this will help me out in case I also get into this issue.

@danoswaltCL I have added the env variable to set NODE_OPTIONS for heap memory to 4GB in the latest commit. Still, we need to update the memory unto 4Gb in Docker GUI for it to work. We still need to check it once when this runs on dev branch deployment. The extra memory used probably is due to Node16 version and buildOptimizer value set to true during this PR change. Angular is still kept to v8 as moving to higher versions was causing a lot of issues, I will do this in a new PR later.

I've pulled latest, app runs as expected (and in docker, looks good), but the jest tests won't run for me when I test a commit:
TypeError: Jest: a transform must export a process function.
The suggestion for this error is to make sure jest and ts-jest are matching and 27+.
When i tried this, it wants typescript 3.8 at least: peer<EMAIL_ADDRESS><5.0".
Are you able to run tests @ppratikcr7 ? Could just be an issue on my side if so.

@danoswaltCL Actually I downgraded jest from v27 as they require angular versions above v9 and this was getting populated as npm warnings in node v12, but the same gets logged as npm error in node v16. I am able to run the jest tests, also they do run successfully on all commits in this PR. Also, I had to keep typescript version in frontend to v3.4 due to few other packages that doesn't support typescript above 3.4
Maybe someone else can also verify once and we may find out what's exactly going on,

@YashilDepani Can you try it out once?

Are we waiting on the enrollment table to merge this?

Actually we were waiting for the production to be up and work normal and later merge this in dev. Now, we can wait for enrollment table changes to be merged first, then will merge this one.

@amurphy-cl We are planning to merge this PR. Let us know in case we need to hold.

Updating a test case for providing awsservice mock. So cahnged title to DO NOT MERGE