Could not find play-services-tasks-license.aar or play-services-basement.aar / com.google.android.gms:play-services-basement

Your Environment

Plugin version: Tested 2.3.6 and 3.0.0-alpha.47
Platform: Android
Cordova version (cordova -v): 8.0.0
Plugin configuration options: Tested with none and  --variable GOOGLE_PLAY_SERVICES_VERSION=11+ --variable ANDROID_SUPPORT_LIBRARY_VERSION=23+ --variable ALWAYS_USAGE_DESCRIPTION="App requires ..." --variable MOTION_USAGE_DESCRIPTION="App requires motion detection"
Link to your project: https://github.com/patrickbussmann/cordova-plugin-background-geolocation-bug-example

Context
With this plugin installed the compiling process can't find the com.google.android.gms:play-services-basement things. Like play-services-basement.aar or play-services-tasks-license.aar. (depends on the ANDROID_SUPPORT_LIBRARY_VERSION with 23+ and none specified)
Expected Behavior
No error in build process.
Actual Behavior
I get a build error.
:app:preReleaseBuild FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all files for configuration ':app:releaseCompileClasspath'.
> Could not find play-services-tasks-license.aar (com.google.android.gms:play-services-tasks-license:11.8.0).
  Searched in the following locations:
      https://jcenter.bintray.com/com/google/android/gms/play-services-tasks-license/11.8.0/play-services-tasks-license-11.8.0.aar
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 58s
14 actionable tasks: 14 executed
(node:4061) UnhandledPromiseRejectionWarning: Error: /bitrise/src/platforms/android/gradlew: Command failed with exit code 1 Error output:
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
FAILURE: Build failed with an exception.
* What went wrong:
Could not resolve all files for configuration ':app:releaseCompileClasspath'.
> Could not find play-services-tasks-license.aar (com.google.android.gms:play-services-tasks-license:11.8.0).
  Searched in the following locations:
      https://jcenter.bintray.com/com/google/android/gms/play-services-tasks-license/11.8.0/play-services-tasks-license-11.8.0.aar
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 58s
    at ChildProcess.whenDone (/bitrise/src/platforms/android/cordova/node_modules/cordova-common/src/superspawn.js:169:23)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:925:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
(node:4061) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:4061) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Possible Fix
Don't use the plugin 😭
Steps to Reproduce

$ git clone https://github.com/patrickbussmann/cordova-plugin-background-geolocation-bug-example.git
$ npm install
$ ionic "cordova" "platform" "add" "android"
$ ionic "cordova" "build" "--release" "--emulator" "android"

Context
I wanted to use this plugin.
See log file attached.
7c7526d86167b479.log
f65bcc1481fcfd66.log

I think you need to update your platform to 7.1.2 https://cordova.apache.org/announcements/2018/11/07/cordova-android-7.1.2.html
Specialy CB-14127: Always put the Google repo above jcenter is what affects you.

Yes thank you very much @mauron85.
The funny thing is that in my original project config.xml I had this.
<engine name="android" spec="7.1.2" />

And in Bitrise it uses latest which seems to be 7.1.1 or something like that.
Interesting!
Now it works!
Thanks! 🎉


Abstract the DOM actions to support virtual DOMs

This PR touches many files, but mostly because we need to use type templates in order to tell the various components what the types to use for HTMLElement, Text, and Document (which are now allowed to be other types rather than the actual DOM elements).  These are the <N, T, D> that you will see everywhere in the differences below.  The other changes to existing files involve converting from calling HTMLElement methods to using the corresponding abstracted methods of the new library that mediates the DOM interaction.  This is the defined in the core/DOMAdaptor.ts, which gives the interface and abstract classes.
Specific instances of the DOMAdaptor are in the new adaptors directory.  The adaptors/HTMLAdaptor.ts file is the basic implementation for actual DOM elements, and it is used by adaptors/jsdomAdaptor.ts for the JSDOM version, and adaptors/browserAdaptor.ts for the browser-DOM version.  There is a legacy adaptors/chooseAdaptor.js that does what the current code does, which is select the browser or jsdom version on the fly, but this will probably not be used in production workflows; it just makes it easier to test both implementations without changing the code.
There is also a new adaptor/liteAdaptor.ts file that implements a non-DOM-based adaptor that uses minimal javascript elements rather than actual DOM elements.  This is the proof-of-concept for the fact that the abstraction from the DOM works as intended.  The adaptor needs to be able to do not only the HTMLElement actions (like appending and replacing child nodes, getting the next, previous, or parent node, setting attributes, classes, styles, and so on), but also needs to be able to handle some document-level actions (like the equivalent of getElementsByTagName()), and it also needs to be able to parse a serialized HTML file into its internal form.
For the latter, the liteAdaptor.ts file includes a LiteParser object that handles that.  It is pretty minimal, and I don't pretend to claim that it does all of HTML5 properly (particularly ill-formed HTML).  It is enough to do testing and processing of straight-forward HTML, but probably should not be used for production.  For production work, one would want to use something like parse5 or htmlparser2 instead; the LiteAdaptor object could be used as a template for producing adaptors for those tools (just like we have for jsdom).  I suspect the conversion would not be hard.
Because the output jax have relied in the past on an HTMLElement from the DOM to handle parsing of CSS styles, I needed to make a minimal replacement for that as well, for the case where there is no actual DOM to work with.  This is in the util/Styles.ts file, and is quite minimal (just enough to do what the CommonHTML output needs at the moment).  It could be extended to a more full-featured version, but I don't think it needs to be (and the would make it bigger and slower).  For now, this should be sufficient, but we can address it if the need arises in the future.
In the end, the changes needed for the page author are quite small.  In addition to the input and output jax, you now need to specify the DOM adaptor as well.  The handler needs to be passed the adaptor, and this is done when the handler is registered with MathJax.  So there is a new RegisterHTMLHandler() function that makes this easy to do.  I've modified the sample files to use this, so you can see how that is done.
Finally, the util/DOM.ts and util/HTMLNodes.ts files have been removed, since their functions are now handled via the DOM adaptor.
I suggest that you start by looking at the files in the following order:

core/DOMAdaptor.ts
adaptors/HTMLAdaptor.ts
adaptors/browserAdaptor.ts
adaptors/jsdomAdaptor.ts
The other core, input, and output files
adaptors/liteAdaptor.ts
util/Styles.ts

I know it is a big PR, but I do think that majority of it is straight-forward conversion to use the types and adaptor, and should not pose too much of a problem.

PS, the adaptors/liteAdaptor.ts file may want to be broken into several pieces (certainly the parser can be broken out).  Also, the input/mathml/MmlEntities.ts file and its support files should probably be moved to utilities, since they are being used in the LiteParser as well.  I will do that as a second step (I didn't want to confuse things more by renaming those as part of this PR.)

I have made the changes to the branch that I think are needed.  Can you take another look?

lgtm.


Update Impuation Logic

It seems that we have imputed the speed when volume and occupancy is zero. However, this speed should not be imputed rather it should be replaced with zero speed as there was no vehicle passed over the sensor in that time windows. Below is the screen shoot based on QC run by Ken-

Therefore, we need to update the imputation logic as
Volume =0 and occupancy=0, then speed=0

completed


Trie implementation is incompatible with non-ASCII characters

The current trie implementation fails for Unicode characters greater than 1 byte in size. This is because it indexes string keys directly rather than first converting strings to rune slices, wherein each rune represents a whole Unicode character.
This occurs in both the get and put methods.
If you agree this is a problem, I'm happy to open a PR.

I think it is just the KeysWithPrefix function that was broken with unicode. I pushed a commit that should fix it now, let me know if you are having further problems though. Ideally we can avoid storing runes in the trie to avoid needing to convert strings to slices of runes (the copy/conversion can be costly).

Ah yes, you're right of course. A trie of bytes will work in just the same way as a tree of runes (apart from the performance difference). Thanks for the patch.


⚠ Pactify has degraded performance

In 8f605eb, Pactify (https://www.pactify.fr/) experienced degraded performance:

HTTP code: 522
Response time: 19654 ms

Resolved: Pactify performance has improved in 08b4ecd after 10 minutes.


Proto encapsulate

it would be cool if you would explain a bit what happened in the protos, so the reviewer does not have to guess based on commit messages and code

I even linked the appropriate commit in the spec. What exactly should I explain here?

no, in the description of the pull-request...its not that big of an issue ;)


Ccf upgrade

This PR introduces changes to upgrade CCF version used for PDO-TP from 0.11.7 to 1.0.19.  A few points to note:

CCF Base installation process is different for 1.0.19 (wrt 0.11.7) if one is installing CCF on a bare metal. (without docker) (deb vs tar files). CCF documentation https://microsoft.github.io/CCF/release/1.x/build_apps/install_bin.html should act as your guide. PDO TP Installation expects Ubuntu 20.04.

PDO clients no longer need to install CCF Base. Python client package is installed via pip. The client package is tested only on Ubuntu 20.04.

CCF user keys are no longer required by PDO clients. PDO clients will instead use one-way TLS. PDO TP now implements a custom authentication policy to permit anonymous PDO clients submit unauthenticated transactions.

PDO-dev docker image uses Ubuntu 20.04 as the base.

PDO signing keys while using CCF based PDO TP will now use SECP384R1 as the ECDSA curve.

Overall it looks good.
I can later fix the gipsy and ubuntu 18.04 build/test if we decide so.

I would like to see this fixed before we approve. If there is a fundamental problem with Gipsy & 20.04 then we can discuss. Otherwise lets make sure this failure is legitimate and not part of a bigger issue.

Tests in hw mode pass!

Will create a new PR to replace this one.


Cannot find module ReactPerf when Dimensions

Hi All,
I use jest testing my view and run it. If my view using import Dimensions from 'Dimensions';  then has error Cannot find module ReactPerf when Dimensions.
Can you fix it for me?
Thank you.

Can you provide a code sample ? It seems an integration/usage issue to me.

My source code:
`/**

FormButton.js

Display a button that responds to onPress and is colored appropriately
/
'use strict';
/*

Imports

React
*/
const  React = require('react-native');
const
{
StyleSheet,
View
} = React;

/**

The platform neutral button
*/
const  Button = require('apsl-react-native-button');
import Dimensions from 'Dimensions';
let windowSize = Dimensions.get('window'); // Screen dimensions in current orientation

/**

Styles

/
var styles = StyleSheet.create({
signin: {
marginLeft: 0.2windowSize.width,
marginRight: 0.2*windowSize.width
},
button: {
backgroundColor: '#051efb',
borderColor: '#051efb'
},
fontButtonStyle:{color:'#FFF'}
});
var FormButton = React.createClass({
/**

render

Display the Button
*/
componentWillMount: function() {
this.buttonViewStyle=styles.signin;
this.buttonStyle=styles.button;
this.fontButtonStyle=styles.fontButtonStyle;
if (this.props.buttonViewStyle) {
this.buttonViewStyle=this.props.buttonViewStyle;
}
if (this.props.fontButtonStyle) {
this.fontButtonStyle=this.props.fontButtonStyle;
}
if (this.props.buttonStyle) {
this.buttonStyle=this.props.buttonStyle;
}
},

render() {
return (

<Button style={this.buttonStyle}
onPress={this.props.onPress}
textStyle={{color:'#FFF'}}
>
{this.props.buttonText}

);
}
});
module.exports = FormButton;
`
My file module test:
`/**

ItemCheckbox-test.js

This class tests that the ItemCheckbox renders correctly under
numerous conditions

Note: if you want to understand the structures here, add a
console.log and then npm test.

*/
'use strict';
jest.autoMockOff();
/**

Imports

React is mocked in src/mocks/react-native.js

Note: put a console.log on the outputs to see the structures
*/

import React, { View } from 'react-native';
import utils from 'react-addons-test-utils';
/**

Under test

class under test
*/
jest.dontMock('../FormButton');
var FormButton = require('../FormButton');

/**

Test

*/
describe('FormButton', () => {
function renderFormButton(props) {
const renderer = utils.createRenderer();
renderer.render(<FormButton {...props}/>);
const output = renderer.getRenderOutput();
return {
  props,
  output,
  renderer
};

}
it('ABC', () => {
const props = {
};
const {output} = renderFormButton(props);
//console.warn(JSON.stringify(output));
expect(output.type).toEqual(View);
});
});
`

React and React Native has been split in release 0.25.1, see release notes.
import React, { Component } from 'react';
import {
  StyleSheet,
  View,
} from 'react-native';

thanks you for feedback. But i using react native release 0.24.0

@charpeni : I tried upgrade react native to v0.27.0 but it alert warn UNMET PEER DEPENDENCY<EMAIL_ADDRESS>I edit file parkage.json and changed "react": "0.15.1" and using npm install.
Can you help me?

@Shinichi52 You are better off if ask such questions on stack overflow.

hi,
I upgrade react-native-cli: 1.0.0, react-native: 0.27.2, "react": "^15.1.0", i used "jest test" and i receive alert

Error: Cannot find module 'findNodeHandle' from 'UIManager.js'
at Resolver.resolveModule (node_modules/jest-resolve/src/index.js:117:17)
at Runtime._resolveModule (node_modules/jest-cli/src/Runtime/Runtime.js:214:32)
at Object. (node_modules/react-native/Libraries/Utilities/UIManager.js:18:20)
at Object. (node_modules/react-native/Libraries/Utilities/Dimensions.js:15:15)
1 test suite failed, 0 tests passed (0 total in 1 test suite, run time 2.935s)

Thank you for your patience. We launched Jest 14.0 with experimental react-native support:

Blog Post
React-Native Tutorial

Please feel free to create new issues after trying out the new integration if any issues remain.


Try-samples can't lauch

Describe the bug
Hello, I am complete beginner for .NET CORE. I come across dotnet try when I browse Documentation Page to find more  sample code to learn about LINQ. I followed the instructions to try to get try-samples run, but it never did.
Here is the screenshot:
Imgur
I notice that I'm having an incorrect Content Root Path when trying to run the samples since it should be the path to where the sample codes are stored. I couldn't find anyone having similar problem after the search.
Really appreciate if anyone could help.
Did this error occur while using dotnet try or online?

[x] dotnet-try
[ ] online

What kind of error was it?

[ ] User Interface (UI):  For example the output never displayed
[ ] Service Error: For example "The service is temporarily unavailable. We are working on it"
[x] Other:

Please complete the following:

OS

[x] Windows 10
[ ] macOS
[ ] Linux (Please specify distro)
[ ] iOS
[ ] Android

Browser

[x] Chrome
[ ] Edge
[ ] Safari

Could you try launching it in standalone terminal instead of the Visual Studio PowerShell prompt?


Add RSS feed for release.osism.tech

That's not longer necessary with the Github Atom feeds + the next generation release notes with Reno.


@Inject @BatchProperty into Batchlet doesn't work

 @Inject @BatchProperty into Batchlet doesn't work: at runtime the property values are null.
import javax.batch.api.AbstractBatchlet;
import javax.batch.api.BatchProperty;
import javax.inject.Inject;

public class BatchletWithPropertyInjection extends AbstractBatchlet {
    private static final Logger LOG = LoggerFactory.getLogger(BatchletWithPropertyInjection.class);

    @Inject
    @BatchProperty(name = "datakey")
    private String datakey;

    @Inject
    @BatchProperty(name = "datakey2")
    private String datakey2;

    @Override
    public String process() {
        LOG.info("datakey: " + datakey);
        LOG.info("datakey2: " + datakey2);

        return "OK";
    }
}

See this test in action: BatchletWithPropertyInjectionJsr352Test.java

In order @Inject @BatchPrperty works, the scope of the injection target Spring Bean must be step or job (late binding):
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                              http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="myBatchlet" class="com.example.MyBatchlet" scope="step"/>
</beans>

See Reference Doc.


Add --lib and default new/init to --bin (apps)

This PR addresses a papercut for new users first picking up cargo.  As most people will create applications (especially new users), this PR changes the default for new/init from library templates to binary (app) templates.
It also introduces a new --lib flag for new and init, similar to the --bin flag that exists today.

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

Hm, when we made cargo, we assumed the opposite. What's the basis here?
On Jul 26, 2016, 15:02 -0700, Rust highfive robot<EMAIL_ADDRESS>wrote:

r? @alexcrichton (https://github.com/alexcrichton)
(rust_highfive has picked a reviewer for you, use r? to override)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/rust-lang/cargo/pull/2921#issuecomment-235419777), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsioh44d3w_CYU7KUZbRZ6DMx5kkVJks5qZoPfgaJpZM4JVo20).

Also, while Cargo is technically nightly, we've considered the CLI pretty
stable, this is a pretty big change in behavior.
On Tue, Jul 26, 2016 at 6:29 PM, Steve Klabnik<EMAIL_ADDRESS>wrote:

Hm, when we made cargo, we assumed the opposite. What's the basis here?
On Jul 26, 2016, 15:02 -0700, Rust highfive robot <
<EMAIL_ADDRESS>wrote:
r? @alexcrichton https://github.com/alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/cargo/pull/2921#issuecomment-235419777, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABsioh44d3w_CYU7KUZbRZ6DMx5kkVJks5qZoPfgaJpZM4JVo20
.

@steveklabnik - Cargo is at "0.13.0-nightly (dc12479 2016-07-22)", so we're still pre-1.0.  I agree that we don't want to go breaking things willy-nilly...
It looks like the hunch that most people would make libraries doesn't seem to play out from the results we're seeing.  The 2016 survey puts "contributes to crates.io" as a minority of our users (roughly 550 of the 2000 active Rust users in the survey).
There's another intuition that if you're trying to make a library, you already have a bit of Rust experience under your belt.  You know how to look up documentation and how to set up additional settings.  I'd argue even into your first few days as a Rust developer you may not have created a library yet, but likely would have created a few small apps.
If the minority of users create libraries, and we're making users go down less ergonomic paths because of it, this seems like a good reason to change the default.

One possibility for sequencing this as well is to add the --lib flag, wait for it to hit stable, then switch the defaults. (if we're worried about breakage).
I agree with @steveklabnik that despite cargo being "pre 1.0" it's basically defacto stable in many respects. I'm not too worried about breakage here, but it may be best to head it off by moving slowly.
I don't personally recall the exact reasons why we chose libraries as the default, but I'm sympathetic to the data just being the other way around so don't mind changing on that basis.

cc @rust-lang/tools, thoughts about changing the default?

+1 on adding --lib, +0.5 on changing the default - It annoys me personally, I nearly always want --bin, but Cargo is de facto pretty stable, so we should do this gently rather than flicking the switch. In addition to Alex's suggestion, could we warn when doing cargo new with neither --bin nor --lib?

I think I agree that --bin is a better default purely for the new user experience, regardless of what people do most often, and also that switching it without warning would be undesirable. I also know that I just never remember which is the default and am sometimes surprised that I have a library after creating a cargo project (particularly for the numerous one-off experiments that just get thrown away).
I'm unsure the best way to proceed, or if the breakage is worth it.
Another way we could transition is by temporarily changing cargo new to produce a crate that makes both a lib and a bin and in the lib.rs source write a comment explaining what's going on.

So it sounds like we're leaning towards making it the default but with caution.
Maybe we can switch the default but also just add a general result message for any new/init?  Something like:
> cargo new foobar
  Created binary (application) `foobar` template

@nrc

could we warn when doing cargo new with neither --bin nor --lib?

I think the motivation for this PR from @jonathandturner was to simplify the newbie experience with just cargo new foo being much simpler than cargo new foo --bin in terms of aesthetics.

Another way we could transition is by temporarily changing cargo new to produce a crate that makes both a lib and a bin and in the lib.rs source write a comment explaining what's going on.

This... seems like a great idea! @jonathandturner what do you think of this?
The idea of a status message also seems fine to me, it's arguably just missing today.

I lean towards the status message.
Putting both in works on one level, since it doesn't have a preference.  But what I'm trying to fix is that there's a happy path for users, especially new users.  If a new user types "cargo new foo", they'll end up getting more than they have today they need to read and understand.  I'd rather have a simple starter template.

I'm comfortable with adding --lib now and printing a warning (for now) when people use bare cargo new (similar to the warnings about git changing the behavior of git push). After some time, we can change the behavior to default to --bin and remove the warning.

Switched to using @wycats/@nrc's suggestion, so I now warn if you do a cargo new without a target.
Default is back to --lib.
I also added a status message for successful completion of a new/init.

Started a thread here: https://internals.rust-lang.org/t/should-cargo-new-default-to-applications/3772 to see if we should change the default.  For the time being, leaving the PR as a simple "add --lib and add a status message".

@alexcrichton Fixed and squished.  Defaulting now happens in a constructor that's shared by both functions.

Ah right one last thing is could you add a test where both --lib and --bin are passed? Other than that lgtm

@alexcrichton - done.

@bors: r+ a0a7752040a304a767c10013c7ca1622885d18dd

:hourglass: Testing commit a0a7752 with merge f1bbc08...

:sunny: Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64
Approved by: alexcrichton
Pushing f1bbc08e4e3197de326ae94eb41f4064cc892e09 to master...

Why can't specify both bin and lib? You /can/ have both lib.rs and main.rs...

@SoniEx2 ah yeah in general you should be able to combine any number of --bin, --example, --lib, etc flags. Right now the option parser doesn't quite handle all the cases but it's indeed an issue that should be tracked on this repo most likely


Recheck dependencies (relates to issue #683)

This PR allows incomplete external dependencies to be rechecked while Luigi is running. It can be tested with the following config:
# client.cfg
[core]
max-reschedules: 3
worker-keep-alive: true
retry-external-tasks: true

[scheduler]
retry-delay: 10
disable-num-failures: 5

...and simple workflow:
#!/usr/bin/python
# -*- coding: utf-8 -*-
"""
Flow for testing recomputation of dependencies
"""
import logging
from luigi.file import File
import time

import luigi

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class ExternalFileTask(luigi.ExternalTask):
    path = luigi.Parameter()
    def output(self):
        return File(path=self.path)

class SlowTask(luigi.Task):
    """
    Requires a single file dependency
    """
    path = luigi.Parameter()

    def requires(self):
        yield ExternalFileTask(path="/tmp/luigi/%s.dep" % self.path)

    def output(self):
        return File(
            path="/tmp/luigi/%s.output" % self.path)

    def run(self):
        logger.info("Sleeping for a long time...")
        time.sleep(20)

        # touch file
        open("/tmp/luigi/%s.output" % self.path, 'a').close()

class LastTask(luigi.Task):
    """
    Final task with multiple dependencies
    """
    def requires(self):
        """
        Loads the config file and yields tasks for each one.
        """
        for p in range(1, 3):
            yield SlowTask(path="file-%d" % p)

    def output(self):
        return File(
            path="/tmp/luigi/final.output")

    def run(self):
        open("/tmp/luigi/final.output", 'a').close()

if __name__ == '__main__':
    luigi.run(main_task_cls=LastTask)

Run the above, then touch /tmp/luigi/file-1.dep. Luigi should now detect that this dependency is met and then run SlowTask(path="file-1"). While this is running (or afterwards if config has worker-keep-alive: true), touch /tmp/luigi/file-2.dep. Luigi should then detect that the dependency for SlowTask(path="file-2") is satisified, and run it. Finally LastTask should run.
The worker returns a state of FAILED if an ExternalTask is incomplete. This allows us to reuse the current retry logic. However, it'd be better if a distinction was made between "incomplete and will try later" vs "failed due to too many retries". This last case is covered by DISABLED if disable-num-failures is set though, so I thought it was just simpler to use FAILED as I've done. We can always introduce a WILL_RETRY state later if necessary to make a distinction in the UI between queued tasks vs disabled/failed ones (I'd like per-task configuration of retries, but not sure if we'll be going down that route internally at the moment. If we do, I might address it then).
Note: This feature is beneficial for my needs (polling an FTP server for existence of a file while other long-running computations are taking place). However, handling failure is still an issue. I think failures should cascade so that if a task is disabled by the scheduler (due to the disable-num-failures setting), tasks dependent on the failed task should be marked as disabled or "failed due to an unmet dependency". This would allow the workflow to terminate even if worker-keep-alive is true. Currently the workflow will not terminate until all pending tasks have completed or failed. I think this should be addressed in a separate issue though.

BTW if this looks good I'll create an automated test.

I think I understand your code now. One thing remaining that I don't understand: isn't some kind of modification needed in the scheduler in order to return external task dependencies to the worker in get_work? Or are missing external dependencies always marked as FAILED?

That's done by marking a task as runnable with a status of PENDING (that's what it was before as well). Only runnable tasks are returned to workers to evaluate.

Tests added. Let me know if you want anything else.
Cheers

Looks like it's good to go except the pep8 issues. If you fix, I'll merge

All done. Thanks.


Remove the support for Node 8, 10, 12

This issue is created to update the JS supported versions. Lambda layers should also stop supporting these EOL versions and keep it close with the versions supported by Otel-JSand Otel-JS-contrib
Reference Issue:

https://github.com/open-telemetry/opentelemetry-js-contrib/pull/1065

PR created to address this issue : https://github.com/open-telemetry/opentelemetry-lambda/pull/471


docker: remove mono

Remove mono from main docker image.
With Resonite deprecating the Mono headless, we can remove mono from our Docker image as it is no longer required.

Update released, merging.


Make a plan: Migrate deployment into product

Make an actionable list

Applies for

tip.itis.swiss onto ZMT AWS
s4l-lite into sim4life.io
...

Addressed in https://github.com/ITISFoundation/osparc-ops-environments/issues/672#issuecomment-2110456141


Fix ResolvedTopicReference memory leak when not converting

Bug/issue #, if applicable: rdar://92131596
Summary
The caching mechanism in ResolvedTopicReference never releases references to the ResolvedTopicReferences it holds.
This has likely always been a problem since the introduction of the cache, but is just now appearing as a memory leak when profiling SwiftDocC because we recently added copy-on-write functionality to ResolvedTopicReference.
The current solution proposed here is to selectively enable ResolvedTopicReference caching for specific bundle IDs only when running a conversion. This disables the caching by default when (for example) just using SwiftDocC as a library to load RenderNode’s in memory.
There’s more work to do here- but this resolves the immediate issue of caching (and never releasing) every reference when using SwiftDocC as a library and not to actively convert documentation.
Testing
Use SwiftDocC to load and unload a large RenderNode in-memory and confirm that no ResolvedTopicReferences are held when profiling the process.
Confirm docc convert doesn't regress in performance when generating documentation for a large bundle.
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[x] Added tests
[x] Ran the ./bin/test script and it succeeded
[x] Updated documentation if necessary

Performance test results look good:
TestFramework-5
+-----------------------------------------------------------------------------------------------------+
| Metric                                   | Change     | Before               | After                |
+-----------------------------------------------------------------------------------------------------+
| Duration for 'bundle-registration' (sec) | +0.46%     | 2.61                 | 2.62                 |
| Duration for 'convert-total-time' (sec)  | -0.79%     | 4.07                 | 4.04                 |
| Duration for 'documentation-processing'  | -3.50%     | 1.28                 | 1.24                 |
| Duration for 'finalize-navigation-index' | +1.33%     | 0.07                 | 0.08                 |
| Peak memory footprint (MB)               | +3.78%     | 181.53               | 188.39               |
| Data subdirectory size (MB)              | no change  | 57.35                | 57.35                |
| Index subdirectory size (MB)             | no change  | 0.47                 | 0.47                 |
| Total DocC archive size (MB)             | no change  | 74.44                | 74.44                |
| Topic Anchor Checksum                    | no change  | 65d4ff3050cd1106a21b | 65d4ff3050cd1106a21b |
| Topic Graph Checksum                     | no change  | 0a64c740a2ed5a246836 | 0a64c740a2ed5a246836 |
+-----------------------------------------------------------------------------------------------------+
TestFramework-10
+-----------------------------------------------------------------------------------------------------+
| Metric                                   | Change     | Before               | After                |
+-----------------------------------------------------------------------------------------------------+
| Duration for 'bundle-registration' (sec) | +0.08%     | 5.25                 | 5.25                 |
| Duration for 'convert-total-time' (sec)  | +2.88%     | 8.15                 | 8.39                 |
| Duration for 'documentation-processing'  | +8.74%     | 2.59                 | 2.81                 |
| Duration for 'finalize-navigation-index' | +2.05%     | 0.15                 | 0.15                 |
| Peak memory footprint (MB)               | +1.31%     | 340.56               | 345.04               |
| Data subdirectory size (MB)              | no change  | 114.68               | 114.68               |
| Index subdirectory size (MB)             | no change  | 0.95                 | 0.95                 |
| Total DocC archive size (MB)             | no change  | 148.05               | 148.05               |
| Topic Anchor Checksum                    | no change  | c8f03d4e81da8e3b6d7f | c8f03d4e81da8e3b6d7f |
| Topic Graph Checksum                     | no change  | edce22bce4f8de475a5e | edce22bce4f8de475a5e |
+-----------------------------------------------------------------------------------------------------+
TestFramework-25
+-----------------------------------------------------------------------------------------------------+
| Metric                                   | Change     | Before               | After                |
+-----------------------------------------------------------------------------------------------------+
| Duration for 'bundle-registration' (sec) | -0.23%     | 13.32                | 13.29                |
| Duration for 'convert-total-time' (sec)  | +0.26%     | 21.68                | 21.73                |
| Duration for 'documentation-processing'  | +0.36%     | 7.56                 | 7.59                 |
| Duration for 'finalize-navigation-index' | +1.10%     | 0.36                 | 0.37                 |
| Peak memory footprint (MB)               | -1.46%     | 836.92               | 824.68               |
| Data subdirectory size (MB)              | no change  | 287.73               | 287.73               |
| Index subdirectory size (MB)             | no change  | 2.41                 | 2.41                 |
| Total DocC archive size (MB)             | no change  | 369.96               | 369.96               |
| Topic Anchor Checksum                    | no change  | 9a675b9ad6d69f8b7f0c | 9a675b9ad6d69f8b7f0c |
| Topic Graph Checksum                     | no change  |<PHONE_NUMBER>84b5131a37 |<PHONE_NUMBER>84b5131a37 |
+-----------------------------------------------------------------------------------------------------+
TestFramework-50
+-----------------------------------------------------------------------------------------------------+
| Metric                                   | Change     | Before               | After                |
+-----------------------------------------------------------------------------------------------------+
| Duration for 'bundle-registration' (sec) | +0.13%     | 26.90                | 26.93                |
| Duration for 'convert-total-time' (sec)  | no change  | 46.95                | 46.95                |
| Duration for 'documentation-processing'  | -0.15%     | 18.38                | 18.35                |
| Duration for 'finalize-navigation-index' | +0.27%     | 0.75                 | 0.75                 |
| Peak memory footprint (MB)               | +0.77%     | 1572.60              | 1584.63              |
| Data subdirectory size (MB)              | no change  | 578.41               | 578.41               |
| Index subdirectory size (MB)             | no change  | 4.84                 | 4.84                 |
| Total DocC archive size (MB)             | no change  | 742.07               | 742.07               |
| Topic Anchor Checksum                    | no change  | 08d0a84bec913460905f | 08d0a84bec913460905f |
| Topic Graph Checksum                     | no change  | 74d25c4f1ee185ad5676 | 74d25c4f1ee185ad5676 |
+-----------------------------------------------------------------------------------------------------+

@swift-ci please test


Error: PrismaClient is unable to be run in the browser.

Bug description
OS: Linux Ubuntu 22.04.2 LTS
Browser: Microsoft Edge
Text Editor: vs-code

How to reproduce

Expected behavior
No response
Prisma information

// Add your schema.prisma

// Add your code using Prisma Client

Environment & setup

OS:
Database:
Node.js version:

Prisma Version

Please don't open issues and discussions for the same problem, but give us some time to actually respond to your discussion: https://github.com/prisma/prisma/discussions/19239


[DOC] Trailing slash flickering

Description
Causes SEO problems

Temporary fixed
See: https://github.com/nuxt-themes/docus/issues/974


[SPARK-38825][SQL][tests] Add a test to cover parquet notIn filter

What changes were proposed in this pull request?
Currently we don't have a test for parquet notIn filter, so add a test for this
Why are the changes needed?
to make tests more complete
Does this PR introduce any user-facing change?
no
How was this patch tested?
new test

cc @dongjoon-hyun @viirya @sunchao

I have tested this manually. I will merge this without pending CI.

Merged to master/3.3. Thank you all!


Deprecation info not showing on CLI online docs

Deprecation information being generated for the docs team is not being used online.
Compare cli output (az monitor autoscale-settings -h) to online docs output.
The command group deprecation message is not being shown.  "This command group has been deprecated and will be removed in a future release. Use 'monitor autoscale' instead."
This also applies to deprecated commands and parameters. Like "az cognitiveservices list" and "az monitor activity-log list --filters".
This information is being passed along as "Deprecated" fields in the xml generated by the sphinx-based azhelpgen.py scripts.
For example:
                        <field>
                            **<field_name>Deprecated</field_name>**
                            <field_body>
                                <paragraph>Option ‘–filters’ has been deprecated and will be removed in version ‘2.1.0’.</paragraph>
                            </field_body>
                        </field>
                        <field>
                            <field_name>Summary</field_name>
                            <field_body>
                                <paragraph>OData filters. Will ignore other filter arguments.</paragraph>
                            </field_body>

    <index entries=""></index>
    <desc desctype="clicommand" domain="" noindex="False" objtype="clicommand">
        <desc_signature first="False" ids="cognitiveservices\ list"><desc_addname xml:space="preserve">cognitiveservices list</desc_addname></desc_signature>
        <desc_content>
            <field_list>
                    **<field_name>Deprecated</field_name>**
                    <field_body>
                        <paragraph>This command has been deprecated and will be removed in a future release. Use ‘az cognitiveservices account list’ instead.</paragraph>
                    </field_body>
                </field>

Related to #1264 - @tjprescott this should be handled in a similar way.

@dend do you have a repo for this?

@dend Checking in on this issue since it has been open for 6 months.

This has been filed as an officialrequest with the devrel feature team, so closing this.


add make_concurrent_composition

Closes #681

Closing in favor of #958. We don't need to add new constructors, it is easier on the user to conceal within pre-existing APIs.


Add libbi support

This PR add libbi support to the HA component. (closes #395)
The integration now exposes libbi's:

cumulative energy sensors (grid export/import, solar generation, battery charge/discharge)
various CTs (grid, dc pv)
other diagnostic data (inverter size, battery size)
You can also change the operating mode (normal/stopped) and set the device priority.

I have also included a fix for #375, which is caused by myenergi devices being used a virtual hubs.

@CJNE I know you said you don’t have a Libbi to test against. Letting you know, this works fine for me

Sorry for the delay and thank you for the PR!
Will merge now 👍


Remove commitment ATX from DB and use post_metadata.json

Motivation
Closes #3843
Changes
Instead of the ATX Builder selecting the commitment ATX, the PostSetupManager should take the responsibility. This simplifies several things:

Instead of needing to store the selected commitment ATX in the DB between selecting and publishing it, the source of truth is now post_metadata.json or (if missing) the initial ATX of the node. As before the ATX with the highest weight will be selected if the node has never published an initial ATX before. This removes the need to store the commitment ATX in two places.
An initial ATX can now not be published any more unless a node also starts smeshing. It didn't make sense before to do this but was possible.

Test Plan

All existing tests still pass
Tests for the logic to select the correct commitmentATX have been moved / updated.

TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed

DevOps Notes

[x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources)
[x] This PR does not affect public APIs
[x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.)
[x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)

bors try

bors try

need some clarification in the PR description.

or (if missing) the initial ATX of the node.

if missing it should either get it from the initial ATX of the node. failing that, select the atx with highest tick height?

an initial ATX can now not be published any more unless a node also starts smeshing. It didn't make sense before to do this but was possible.

i don't understand this sentence. do you mean the current code path will publish an ATX regardless if the node is smeshing?

@countvonzero

or (if missing) the initial ATX of the node.

if missing it should either get it from the initial ATX of the node. failing that, select the atx with highest tick height?

This is correct. I just described the changed behaviour, but a node still selects the ATX with the highest weight as commitment ATX if it hasn't published an initial ATX before.

an initial ATX can now not be published any more unless a node also starts smeshing. It didn't make sense before to do this but was possible.

i don't understand this sentence. do you mean the current code path will publish an ATX regardless if the node is smeshing?

Before the ATX builder would select the commitment ATX before StartSmeshing was called. This would allow to the node publishing an initial ATX without starting initialization. Since now the commitment ATX is selected in StartSmeshing this is not possible any more.
Its the difference between a) do I publish my initial ATX first and then start smeshing or b) start smeshing and then publish my initial ATX.

Its the difference between a) do I publish my initial ATX first and then start initialising or b) start initialising and then publish my initial ATX.

i cannot find the codepath where the node would publish an initial ATX without smeshing. can you point me to it?

Looks like you are correct. 🙂
Builder::getCommitmentAtx used to lock in the choice of the Commitment ATX, but it was only called called in Builder::StartSmeshing and Builder::buildNIPostChallenge, which was also only (indirectly) called by Builder::StartSmeshing.
Now PostSetupManager::StartSession commits to an ATX for initialisation (instead of having it passed in from the builder).

Looks like you are correct. slightly_smiling_face
Builder::getCommitmentAtx used to lock in the choice of the Commitment ATX, but it was only called called in Builder::StartSmeshing and Builder::buildNIPostChallenge, which was also only (indirectly) called by Builder::StartSmeshing.
Now PostSetupManager::StartSession commits to an ATX for initialisation (instead of having it passed in from the builder).

thanks for confirming. can you update the PR description for the record? thanks

bors try

bors try

bors merge


Set up and review functional scope of Logstash

[x] Install Logstash on test infrastructure
[x] Compare import pipeline requirements to Logstash capabilties.
[x] Produce report detailing what can be done in Logstash and what cannot
[ ] Open new issues to cover the work required to deliver the import pipeline

Logstash has been setup on test infrastructure

Compare import pipeline requirements to Logstash capabilties.
Logstash can be part of import pipeline.
Logstash supports multiple pipelines through multiple config files to import data from different  sources.
Logstash can be connected to different connectors like Kafka, Beats etc. For example, different source send data to Kafka directly or through ETL code (if source tool does not support kafka directly) to different topics on Kafka. Separate pipeline can be created for each topic from Kafka in Logstash and send the data to Elasticsearch.
There can be one or more Logstash instances depending on the pipeline requirement.
See the attached graphical view of pipeline

Produce report detailing what can be done in Logstash and what cannot
Following  can be done with with Logstash:

Logstash has lot of input plugins which can be sufficient for most of the requirements. Input plugins: beats, file, kafka, http, tcp etc
Data can be parsed using filters before sending to output
An example for parsing can be, if the input data is log file or stream with each log as one line, a filter can be added to parse the log into JSON format before sending to output
Parallel pipelines can be created for multiple input sources using multiple config files
Output can be sent to different destinations by using different output plugins.
Logstash integrates very well with elasticsearch.

Following  cannot be done with with Logstash:

Loststash does not has it own cluster. That means if Logstash instance is down, the pipeline is down.
We need to manage our own cluster if we need Logstash in High Availability mode.
By default Logstash uses in-memory bounded queues. Data can be persisted by using persistent queue feature.
But there is a chance of data loss for some input plugins that does not support achnowledgement to sender. Example of such plugins TCP, UDP

From our discussions today:

We are not sure what is happening with Logstash with regard to future forks by Open Distro, and this may have an impact on our choice to use it.
It may not be easy to build the custom bits of the pipeline, such as connecting to the Reporting Context, though it is possible to write Logstash steps in Ruby.

We think that we should spec out the import pipeline and the pre-compute pipelines before taking this one further. (will open that as a separate issue)

We have had a number of discussions and investigations into Logstash internally, and following recent news from Elastic on their further licensing and functional changes to their various components, we have decided that pursuing Logstash is no longer a suitable Open Source approach for this project.
To that end, we have evaluated a number of alternatives, and concluded that Apache Kafka https://kafka.apache.org/ is the best alternative solution.  In fact, this gives us more flexibility that Logstash, and may be integrated into the Event API directly, to create a high performance import pipeline.
@Pcolar I'm assigning this one to you just to make sure that you get the information.  We can leave this open to discuss at our next call, or if you are happy as-is you can close it off.

IMO - kafka is an excellent choice for event topic queues and feeds. I will see if there are any queries from the NGLP side and close this issue.

Just to finalise this issue:
We made the decision based on the ongoing licensing shenanigans at Elastic to drop Logstash from the project.
Instead we have adopted Apache Kafka, which is a high scale/high throughput event handler.  It is providing us real-time event processing, meaning that events reported to the Event API are available in the reporting interfaces in near real-time.
I'm closing this issue off now.


Standard output with -v0

Given the workflow
print(1)
sh:
  echo 2

we have
$ sos run test -v0
1

$ sos run test -v1
[1
2
#] 1 step processed (1 job completed)

$ sos run test -v2
INFO: Running default:
1
2
INFO: default is completed.
INFO: Workflow default (ID=bfbe8a3fe680bd19) is executed successfully with 1 completed step.

Basically I think

The behavior of -v0 is quite strange because it shows output of some statement (regular python statements), but not others (from action).

The behavior of -v1 is also problematic because it outputs regular output, which messed up with the progress bar anyway.

So perhaps the following makes sense.

With -v0, we shutoff output from regular python statement as well, so basically there would be no output except for errors.
Then with -v0 we can output a progress bar, which will not be disturbed by regular output.
With -v1 we have outputs, but not sos messages.
With -v2 we have both outputs and sos messages.
...

@gaow  The current behavior was proposed by you, any thought?

For actions, we have stderr and stdout options which controls the behavior of output on screen. I wonder if we should rely on these options and not let verbosity levels play a role there?  Then for python statements, -v0 and -v1 both silence them with -v1 outputting progress bar (such that progress bar dont get disrupted), and -v2 will show them all with default SoS messages. My problem with your proposal is -v0 outputs progress bar. Also I think behavior of actions should be controlled case by case at user's discretion.

-v2 is INFO so it is natural to show Executing step 10. It is fine to show both.
With your proposal, there is no level to show "user-generated output only", which is nice to have if we want to execute the workflow as a "script" without showing any workflow related messages. I think this should be -v1.
Then progress bar has to be with -v0.

I agree with the limitations with my proposal. Can we add a -v -1 for absolutely no screen output at all ... ?

Perhaps we should separate progress bar from -v? Too bad -p is already taken (rePort) but it is natural to have -v0 (silent), -v1 (script output), -v2 (sos info), -v3 (debug). And something like -P for progress bar, although it only makes sense to use with -v0. We could let -P implies -v0 though.

I was hesitate about adding a new option ... progress bar is not a very
often used feature. How does -v 0.5 sound :P ?
On the go. Sorry for short text.
On Sun, 22 Dec 2019, 10:06 Bo<EMAIL_ADDRESS>wrote:

Perhaps we should separate progress bar from -v? Too bad -p is already
taken (rePort) but it is natural to have -v0 (silent), -v1 (script
output), -v2 (sos info), -v3 (debug). And something like -P for progress
bar, although it only makes sense to use with -v0. We could let -P
implies -v0 though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vatlab/sos/issues/1349?email_source=notifications&email_token=AAHADYOODSU43TZD7U4SPMLQZ57BBA5CNFSM4J6KCBLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPSBUI#issuecomment-568271057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHADYKQTJIUXQRK5HG2S2LQZ57BBANCNFSM4J6KCBLA
.

Why do you want an absolute silent -v0 then?

You could actually do -v0 2> /dev/null if you do not want the progress bar.

I thought by definition v0 should be silent for having zero extra
information. But compared to having another option for progress bar I am
okay with using v0 for it as you proposed.
On the go. Sorry for short text.
On Sun, 22 Dec 2019, 13:30 Bo<EMAIL_ADDRESS>wrote:

You could actually do -v0 2> /dev/null if you do not want the progress bar.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vatlab/sos/issues/1349?email_source=notifications&email_token=AAHADYJNPB7F237ER6X4FGTQZ6W4ZA5CNFSM4J6KCBLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPW4RA#issuecomment-568290884,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHADYMCKUNENO5UG4B7VGTQZ6W4ZANCNFSM4J6KCBLA
.


Unclear purpose of helmet

Sorry to everybody and please forgive me for the question but I am not particularly versed in web development.
I don't get the purpose of this package. What problem is it trying to solve?

As far as I can tell, it is syntax sugar that replaces manual manipulation of outside DOM (in this case: <head>) from within of React component. Helmet still does it but at least you don't have to, so you keep your own components unpolluted.

@stefanoborini check out this article. https://open.nytimes.com/the-future-of-meta-tag-management-for-modern-react-development-ec26a7dc9183?gi=176d3fe608fa


Feature Request: Support for tvOS17

Hi
tvOS17 will support VPN. Will PIA support tvOS as well?
https://www.apple.com/uk/newsroom/2023/06/tvos-17-brings-facetime-and-video-conferencing-to-apple-tv-4k/

Hi tvOS17 will support VPN. Will PIA support tvOS as well?
https://www.apple.com/uk/newsroom/2023/06/tvos-17-brings-facetime-and-video-conferencing-to-apple-tv-4k/

Thank you for your feature request @dtantono. We are excited to announce there will be a tvOS version soon.
Stay tuned!


Any news?

Hi there,
Stumbled across your repo here while trying to search for ways to speed up my development time using the Anypoint studio version 7.15.0. I am facing very similar issues as you describe here in this repo and I was wondering if you knew if these matters have been resolved in later versions of the Anypoint studio? I opened up this discussion, https://www.reddit.com/r/MuleSoft/comments/1g3murv/improving_startup_times_during_development/,  on Reddit hoping some people might have some ideas on how to improve the developer experience. It feels like I am spending 50-60% of my time just waiting for the tool instead of actually producing some valuable work.

@rbutenuth , thank you for such a quick response. I will ask my team members, who have access to the Mulesoft support systems, to upvote your ticket.


Release v3.0.0

Release notes

Upgrade to Mantine 6 and fixed breaking changes #18 by @dvmichaelpeterseil
Mantine 6 #30 by @dvmoritzschoefl
Vis bugs and improvements #31 by @dvzacharycutler
upgrading storybook to 7 #36 by @dvzacharycutler
Fix: Pin pyright to version 1.1.308 #37 by @dvdanielamoitzi
feat: vis custom colors and bug fixes #39 by @dvzacharycutler
Removing drawer from sidebar, upgrade storybook #40 by @dvzacharycutler

Release dependencies first
In case of dependent Phovea/TDP repositories follow dependency tree from the top.
🏁 Finish line

[ ] Inform colleagues and customers about the release
[ ] Celebrate the new release 🥳

The build is successful, but the cypress tests fail in the workflow run: https://github.com/datavisyn/visyn_core/actions/runs/5153476898/jobs/9280751449


Many tests on 0.1.3 are failing

vapjs-query
Before opening a new issue, please take a moment to review our community guidelines to make the contribution process easy and effective for everyone involved.
Before opening a new issue, you may find an answer in already closed issues:
https://github.com/vapjs/vapjs-query/issues?q=is%3Aissue+is%3Aclosed
Issue Type

[ ] Bug (https://github.com/vapjs/vapjs-query/blob/master/.github/CONTRIBUTING.md#bug-reports)
[ ] Feature (https://github.com/vapjs/vapjs-query/blob/master/.github/CONTRIBUTING.md#feature-requests)

Description
(Add images if possible)
Steps to reproduce
(Add link to a demo on https://jsfiddle.net or similar if possible)
Versions

Node/NPM: LTS/Dubnium
Browser:

Testing must be revisited and are disabled in creation of 0.1,3 build


🎉 2.0.1

ℹ About this release

Version: 2.0.1
Type: patch
Last Release: 2.0.0 (7/26/2022, 8:59:27 AM) [?]
Commits to merge: 15 [?]

📦 Dependencies

Update ical-generator from ^3.4.3 to ^3.5.1

📦 Development Dependencies

Update @sebbo2002/semantic-release-docker from ^1.1.3 to ^2.0.1
Update @typescript-eslint/eslint-plugin from ^5.30.5 to ^5.31.0
Update @typescript-eslint/parser from ^5.30.5 to ^5.31.0
Update eslint from ^8.19.0 to ^8.21.0
Update ts-node from ^10.8.2 to ^10.9.1
Update typedoc from ^0.23.5 to ^0.23.10
Removed @types/luxon
Removed @types/node
Removed dayjs
Removed moment
Removed moment-timezone
Removed rrule

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

v2.0.1
GitHub release
Docker container (sebbo2002/fitness-first-ical-proxy:2.0.1)
v2.0.1

Your semantic-release bot :package::rocket:


Macos Crash due to skulpin dropping object

libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
Abort trap: 6

This seems to happen because when ui_loop finishes something is dropped manually and then automatically drops, causing the MoltenVK to try to destroy a buffer that doesn't seem to exist. Here are the relevant bits of the crash report:
10  libc++.1.dylib                	0x00007fff7056454d std::__1::mutex::lock() + 29
11  libMoltenVK.dylib             	0x0000000131e7069f MVKDevice::destroyBuffer(MVKBuffer*, VkAllocationCallbacks const*) + 31

I'm not sure about the specifics about why this happens, but I am able to resolve the issue by disabling either this line https://github.com/Kethku/skulpin/blob/c0b194833f97b839bd44a30fc2f17851b14e1016/src/renderer/renderer.rs#L461 or this line https://github.com/Kethku/skulpin/blob/c0b194833f97b839bd44a30fc2f17851b14e1016/src/renderer/renderer.rs#L463 for the upstream skulpin dependency.
The above "fix" may lead to memory leaks.

https://github.com/KhronosGroup/MoltenVK#memory-management
Maybe a better mind can make more sense of this than me.

I think the correct step for handling stuff like this bug is to first rebase on the master version of skulpin. As is I think the fork we are using (my private fork for the initial sdl2 support) is not sufficient and has diverged too much. @jotacosta has started some work on this over here: https://github.com/Kethku/neovide/issues/218 but if necessary I can take a quick stab to get it done sooner.
Further @j4qfrost I have invited you as a contributor on the project. I really appreciate the bug reporting and general contributions you've been doing.

Cool, thanks for the invite and kind words. I'll follow the issue. I took a look at the drop implementation for the most up-to-date version of skulpin, and it doesn't seem to be much different aside from the plugins dropping. Though I guess getting everyone on the same page is useful  in that we can start helping push skulpin development forward too.

I've started the port.  But from what I can see, we should move to a logicalSize and try to not have dpi anywhere. This will require a bit of change in the code, as there are dpi validations in the current develop (with skulpin-sdl2) that don't exist in skulpin v0.9.0.
If folks feel this is a priority and needs to be done soon, let me know.

I think there are a number of bugs that are blocked behind this, but that doesn't necessarily make it urgent. I'd rather ramp people up and help people contribute than rush a given feature or bugfix forward.
The dpi changes were all hacks to be honest. I agree that using logical size is the way to go and then fixing any dpi issues upstream. I suspect most of the changes will be mostly tearing out dpi manipulation on our side rather than adding anything else.
Don't hesitate to reach out if you get stuck :)

I was in the process of writing this when Kethku chimed in. I reiterated some of his points.
@jotacosta It's more like a "nice to have" going forward. For this issue, I've essentially smothered the error by not running code for macos, but I don't know if the destructor for the object is being run elsewhere or if it's just left in the wind until the program exits, which could lead to a memory leak. It would be helpful to be using the most up-to-date version of skulpin, but it's not a pressing issue. I'm personally going go back to my other project, but I'll to pop in to see if anyone needs Mac support and help out where I can with development.
I tried running neovide in valgrind, but there's a bad access, which I suspect happens because it runs a separate process for neovim. I get:
Process terminating with default action of signal 4 (SIGILL)

I'm still a bit dependent on rust auto suggestion tools for Sublime Text, but it really helps in a pinch. All of us need help sometimes.

@Kethku We can fix this temporarily by adding process::exit at the end of ui_loop until we figure out a permanent fix. It'll keep the project looking more professional for the time being.

@j4qfrost yeah that did alleviate the crashing however q still doesn't close neovide for some reason, the loop seems to break but the window remains open

This seems to be resolved, I'll close it for now.


Why not use more advanced backbone

Excellent work!
But why not use more advanced backbone, such as resnet or CSPNet et.?
Is that because of in order to prove the progresiveness of the loss designed?

Hi,
Thank you for your attention to our work! For fair comparisons, we use the same backbone network as other losses. You are welcome to replace the backbone with other state-of-the-art networks.

Hi,
Thank you for your attention to our work! For fair comparisons, we use the same backbone network as other losses. You are welcome to replace the backbone with other state-of-the-art networks.

I see.Thank you and happy Chiness new year!

@hhk123 Hi, Good idea.
Have you tried using other backbones?


TeXLive commands make4ht, tex4ebook fail to process images

Describe the bug
I'm trying to produce html and epub files from a LaTeX document with the ht tools and it looks like they don't work properly.
Given the following simple input, with a PDF file pic.pdf,
\documentclass[11pt,a4paper,twoside]{article}
\usepackage{graphicx}
\begin{document}

\section{Introduction}

Look at this Figure~\ref{fig:pic}

\begin{figure}
  \centering
  \includegraphics{pic}
  \caption{Pic.}
  \label{fig:pic}
\end{figure}
\end{document}

the commands make4htand tex4ebook give the following errors
$ make4ht test.tex "mathjax"
[STATUS]  make4ht: Conversion started
[STATUS]  make4ht: Input file: test.tex
sh: line 1: rungs: command not found
[STATUS]  make4ht: Conversion finished

$ tex4ebook test.tex mathml
[STATUS]  tex4ebook: Conversion started
[STATUS]  tex4ebook: Input file: test.tex
sh: line 1: rungs: command not found
[ERROR]   mkutils: File pic-.png doesn't exist
cp: cannot stat 'pic-.png': No such file or directory
sh: line 1: tidy: command not found
[WARNING] exec_epub: tidy command seems missing, you should install it in order
  to make valid epub file
[STATUS]  tex4ebook: Conversion finished

In both cases the output is produced, but the image is missing.
Notify maintainers
@veprbl @vcunat

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.1.60, NixOS, 23.05 (Stoat), 23.05.4662.34bdaaf1f0b7`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.13.6`
 - channels(beffa): `""`
 - channels(root): `"nixos-23.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

How did you install LaTeX / which version of LaTeX do you have installed?
It looks like you have 2 commands missing: rungs and tidy. I ran the same commands on your test file and only got the second error. Easily fixed by installing the html-tidy from the repos.
rungs seems to be part of all the current unstable texlive packages, but none of the 23.05 texlive packages.

Indeed I'm on the 20.05 channel. I installed with the following
...
environment.systemPackages = with pkgs; [
...
    ((texlive.combine {
      inherit (texlive)  # space separated list of pkgs
        scheme-medium
        a4wide
        comment
        enumitem
        fontaxes  # required by svmono
        footmisc  # required by svmono
        framed    # required by svmono
        multirow
        newtx     # required by svmono
        ntheorem  # required by svmono
        pagecolor
        pdfcolmk
        pgfplots
        standalone
        thmtools
        type1cm   # required by svmono
        xstring;  # required by svmono
      pkgFilter = pkg: lib.elem pkg.tlType [ "run" "bin" "doc" ];
    }).override (args: { ignoreCollisions = true; }))
...
];
...

Indeed I'm on the 20.05 channel. I installed with the following

Ok thanks. Just to confirm, are you on 20.05 or did you mean to say 23.05 ?

Yes, sorry.

cc @xworld21, this must have been fixed by the recent changes to scripts packaging? Is this is a wontfix for 23.05?

cc @xworld21, this must have been fixed by the recent changes to scripts packaging? Is this is a wontfix for 23.05?

The rungs script should work now on unstable, I see listed among the binaries on https://search.nixos.org/packages?channel=unstable&show=texlive.combined.scheme-medium
However tidy is most likely an external dependency that must be added to the path via postFixup.

PS: I'll try slip an extra rungs link in the 23.05 texlive.combine, since 23.11 is still some time away. (It should be enough to add rungs to the loop that reads from scripts.lst – not in scripts.lst directly as it would cause a useless rebuild – so if somebody has a moment to do it before me, go ahead!)

Thanks for the rapid fix!


[Bug]: Can't disable specific control

What happened?
I removed the controls from the toolbar by doing this:
public toolbar: Toolbar = [['bold', 'italic'], ['underline'], [], [], [], ['link'], [], [], []];
But I can still add an ordered list if I write something like 1.
How can I remove a certain control for good?
Version
v12.3.0
Angular Version
v13.2.6
What browsers are you seeing the problem on?
Firefox, Chrome, Safari
Link to reproduce
No response
Relevant log output
No response
Willing to submit a PR?
No response

All controls are configurable.
public toolbar: Toolbar = [['bold', 'italic'], ['underline'], ['link']];

should do, the inner array just provides grouping, nothing else.

How can I remove a certain control for good?

Not able to follow, can you elaborate?

Hey thanks for the answer although this does not solve my problem. The thing is that I only want to allow those 4 editing options and nothing else. If I for example write 1.<and hit space> it will treat it as a list instead of just normal text.

Right. That only works for menu. doesn't disable features.

Is there a way to also remove it from the editor itself? For example the user can still just copy paste whatever HTML he wants and it will be displayed.
An expected behaviour to me would be that every html tag that is not visible in the toolbar is also just converted to plain text when applied.

You can manually provide the schemas and include only the ones you want. See https://sibiraj-s.github.io/ngx-editor/#/schema for how to provide a schema.
See https://github.com/sibiraj-s/ngx-editor/blob/master/projects/ngx-editor/schema/index.ts for the default schema. All you need to do is to just ignore the ones you don't need.

There are also few other options you can configure https://sibiraj-s.github.io/ngx-editor/#/editor?id=options

Closing as resolved. Feel free to continue the conversation if required.


[WIP] Try send queries

This PR is open to investigate what data is needed to send queries, and then to finally send a successful query.
We have a Deno app (app.ts) which is for the initial investigation, and we have a node app, which is being used to try figure out the data sent, which is just console.logging in the actual files in node_modules
The deno app connects, but fails to send a message, the node app connects and can send messages (as it's using the mongodb driver)
Links on how mongodb native does it:
https://github.com/mongodb/node-mongodb-native/blob/79df55383b5ba3f081b96513253e566793166199/lib/cmap/connection.js#L28
https://github.com/mongodb/node-mongodb-native/blob/79df55383b5ba3f081b96513253e566793166199/lib/core/wireprotocol/command.js#L41
https://github.com/mongodb/node-mongodb-native/blob/79df55383b5ba3f081b96513253e566793166199/lib/core/connection/connect.js#L70
The wire protocol:
https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/

The app.js file (node socket approach) works perfectly, it connects and gets the results from the db, so going to try base the deno implementation from that

The node implementation works, and the response is correct. I then based the deno impl off of this, but it used node polyfills. This 'works', but when i try decode the response, it's got some odd encoding. I believe this is one of 2 things:

we need to convert the chunk from bson to json (bson_to_json) converter (i think the mongodb sends back bson)
because we send a buffer, the response matches the message, so the response is a pure buffer instead of pure Uint8Array

Then i tried converting the deno impl that used the polyfils, into a pre deno impl, but got stuck on how i could 'transfer' it

FYI i was using https://medium.com/@asayechemeda/communicating-with-mongodb-using-tcp-sockets-521490f981f as baseline


RHEL - rhui2-cds01.REGION.aws.ce.redhat.com not resolvable

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: PE 2017.3.5 (puppet-agent-5.3.5-1.el7.x86_64)
Ruby: ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux]
Distribution: RHEL - Red Hat Enterprise Linux Server release 7.5 (Maipo)
Module version: puppet-yum 2.2.1

How to reproduce (e.g Puppet code you use)
include ::yum

yum::manage_os_default_repos: true

What are you seeing
Errors during yum operations:
Could not retrieve mirrorlist https://rhui2-cds01.REGION.aws.ce.redhat.com/pulp/mirror/content/dist/rhel/rhui/server/7/7Server/x86_64/os error was
14: curl#6 - "Could not resolve host: rhui2-cds01.REGION.aws.ce.redhat.com; Name or service not known"
Could not retrieve mirrorlist https://rhui2-cds01.REGION.aws.ce.redhat.com/pulp/mirror/content/dist/rhel/rhui/server/7/7Server/x86_64/rh-common/os error was
14: curl#6 - "Could not resolve host: rhui2-cds01.REGION.aws.ce.redhat.com; Name or service not known"

What behaviour did you expect instead
I think the defaults provided through module data should work as a general rule. Perhaps, if they are "Amazon" specific defaults, we should add a layer to the hiera.yaml to detect the amazon-ness and include these defaults then? or come up with a generic default, and only override the "mirrorlist"
Output log
Relevant information included above.
Any additional information you'd like to impart
This relates to PR #75  and Issue #76 ... Perhaps @pillarsdotnet can shed some light on how it is supposed to work.

I ran into something similar today, and the cause was a missing /etc/yum/vars/awsregion file.

Ah, it does have something to do with AWS? These settings are AWS defaults for RHEL. I know this may sound crazy, but I have RHEL7 VMs that are not in AWS :p

I know this may sound crazy, but RHEL-on-AWS should detect as a different OS from RHEL-not-on-AWS.
(winky-grin)

Agreed! I am a bit curious... wouldn't a variable need to be formatted like $awsregion (perhaps with the curly braces)? I am certain with all the available AWS facts we ought to be able to figure something out. Unfortunately, I am currently working with a customer that cannot use AWS, so I will have to bow out. For now, I just set yum::manage_os_default_repos: false for os->RedHat, and we'll have to create the entries manually.
~tommy

I agree with @TJM, this is a little odd.  I'm going to do some digging into it to see why it's happening.

The module hiera config file just uses os.family and os.release* to determine which default repos to include.  Obviously trying to figure out if a node is in ec2 in hiera isn't simple, but I don't think assuming it is and laying down repos which don't work isn't the right way to go.
Obviously trying to manage the default repos on RHEL won't work unless the node registered through RHSM.
@pillarsdotnet could you share any background on the changes made in #75 and #76 ?

For me, this was resolived by installing the rh-amazon-rhui-client rpm. Because I could not do anything with dnf (yum), I could not install it with "dnf install rh-amazon-rhui-client". I had to go to a working server, run "dnf download rh-amazon-rhui-client", which downloaded the file rh-amazon-rhui-client-4.0.14-1.el8.noarch.rpm. I copied that file to the broken server and ran "rpm -Uvh rh-amazon-rhui-client-4.0.14-1.el8.noarch.rpm" to install it. Then, when I ran "dnf update", it reconfigured itself and began working.

@albatrossflavour
Sorry; at the time I wrote those patches, I was working AWS-only.
But "trying to figure out if a node is in ec2 in hiera" is pretty simple. All you need is a fact that resolves one way for ec2 and a different way for non-ec2.   I've written such a fact in a proprietary setting.  Here's what the top-level looks like:
Facter.add(:cloud_provider) do
  setcode do
    if (Facter.value(:az_metadata)
      'azure'
    elsif Facter.value(:ec2_metadata)
      'aws'
    elsif Facter.value(:gce)
      'gcp'
    elsif sanity_check_our_own_onprem_servers()
      'onprem'
    else
      Facter.warn('Could not determine cloud_provider fact.')
      nil
    end
  end
end


Update kotlin & gradle versions to fix build errors with Flutter 2.10.3

These updates correct a build error I encountered after upgrading Flutter to 2.10.3:
e: c:\FlutterDev\flutter\.pub-cache\hosted\pub.dartlang.org\disk_space-0.2.1\android\src\main\kotlin\de\appgewaltig\disk_space\DiskSpacePlugin.kt: (14, 6): Class 'kotlin.jvm.JvmStatic' was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.5.1, expected version is 1.1.16.
The class is loaded from C:/Users/ahart/.gradle/caches/transforms-3/386454215e6950cb1162d1da9ff12466/transformed/jetified-kotlin-stdlib-1.5.31.jar!/kotlin/jvm/JvmStatic.class

I did not update the changelog or the readme.
First PR, so apologies if I've done anything wrong, please let me know.

@mboeddeker any chance this PR could be integrated and a new disk_space plugin update released?

@ekuleshov-idexx @abhlabs Hey, ich habe taken over the maintenance of this plugin
check it out here
https://pub.dev/packages/disk_space_plus


Width and height of svgs lost when rendered in the browser

Tasks for this ticket:

Investigate whether the issue outlined in this ticket is still relevant.
If so, try to identify a fix for the bug and implement it.

Width and height of svgs lost when rendered in the browser

Originally posted by @jrbarnes9 in https://github.com/ONSdigital/design-system/issues/195#issuecomment-584655441

 Issue #694: Width and height of svgs lost when rendered in the browser

This is not relevant anymore


Open youtube on a specific video

Hi there
is it possible to open youtube on a specific video when I provide a video id?
currently I can only open youtube app on its' home screen, and I want to be able and open it on a specific video page.
thanks

Would love to figure this out as well.

Try…
service: media_player.play_media
target:
  entity_id: media_player.frame85
data:
  media_content_id: https://www.youtube.com/watch?v=dQw4w9WgXcQ
  media_content_type: url
  enqueue: "play"

media_content_type: url, not video, and also needs the enqueue option.

Try…
service: media_player.play_media
target:
  entity_id: media_player.frame85
data:
  media_content_id: https://www.youtube.com/watch?v=dQw4w9WgXcQ
  media_content_type: url
  enqueue: "play"

media_content_type: url, not video, and also needs the enqueue option.

What you mention is exactly what is described in the integration's docs, and I couldn't think of any other way to do that, than the one that is described, but it doesn't work on the particular TV.

Try…
service: media_player.play_media
target:
  entity_id: media_player.frame85
data:
  media_content_id: https://www.youtube.com/watch?v=dQw4w9WgXcQ
  media_content_type: url
  enqueue: "play"

media_content_type: url, not video, and also needs the enqueue option.

Do you happen to  know how to make the browser full screen using any command?


ScottPlot 5: Eto Control

Limitations:

When targeting WPF (Eto.Platform.WPF) keyboard events don't work. Apparently Control.Focus() doesn't work on every platform so that might be the issue.
Performance is a little poor for large windows on WinForms. It's ok, though not great, on WPF.

I'm going to merge this now, but I think there's room for improvement: click-drag-pan freezes if you continuously move the mouse. This may be a limitation of ImageView, but forcing the window to redraw somehow would fix the remaining issue. I tried this.Invalidate() but it did not help


[feature] Allow specifying output path

Not everyone keeps their i3 config in ~/.i3/config, plus I'd like to temporarily change it for testing purposes.

On the same note, I think the user should be able to specify a full path for both input and output. If I install i3bang into /usr/bin/i3bang, I should be able to run i3bang /home/user/dotfiles/i3/config.bang /home/user/.i3/config.

I should be able to run i3bang /home/user/dotfiles/i3/config.bang /home/user/.i3/config.

Now you can. :D
When not provided, input file defaults to ~/.i3/_config and output to ~/.i3/config.

Awesome, thanks!


Switch to yabawock's static nginx buildpack

The new herokuish branch of buildstep requires changes to the buildpack, but this buildpack should be compatible with the old buildstep.

:+1: