Fix PHP version requirements

For composer, this should be a given because of dependencies that require it and usage of ?? null coalescing operator. For the readme, I believe that this project will run just swell on PHP 7.0 even though you might have 7.1 installed for now.

Hey man. Sounds about right. However please update it to "PHP 7.1" because It am using 7.1 specific syntax in it.

Which PHP 7.1 features are you using? I'm running this on PHP 7.0 myself.

At the top of my head: ?? mark

?? was introduced in PHP 7.0

Turns out you're right about the ??. But since I have 7.1 installed on my local machine, I feel safer setting to 7.1 since I can be sure it's been tested.

That’s fair, I’ve been working to get Laravel Dusk up and running with CircleCI so that there can be automated browser testing

I used Laravel Dusk in a recent project I was on. I will begin writing tests for Voten soon(feel free to jump in, since I'm lazy and need a push for it!). I'm not familiar with CircleCI, could you explain it to me like I'm 5?

You know how there's a check for StyleCI (continuous-integration/styleci/pr)? It runs all the code through the syntax checker and makes sure it passes and if it doesn't it creates a PR with the appropriate changes.
CircleCI (or TravisCI for an alt) will run all your tests (unit or feature or browser aka dusk) and make sure they all pass. If it doesn't, then it shows a red X by the PR or commit (last one pushed if in a group). This lets you know if something has broken or not from the latest changes. It can't make a PR to fix your stuff though.

Very cool and useful! Speaking of such services, @lukepolo and I recently launched (but have had time to spread the word) http://stylejs.io/. It does the same kinda of service for front-end codes.


Can't restart after failures in file export code

The basic flow of a Toil script is:

Import files to the file store from somewhere
Run a bunch of Toil jobs that manipulate these files and produce output files
Export the output files from the file store to somewhere

I recently had a Toil script fail at step 3. I tried to restart it, but since the root job had already finished, Toil couldn't do anything useful with the job store, complaining that the root job had finished or had never been started.
Here's the message I get from Toil:
INFO:root:Running on Toil from /cluster/home/anovak/python/lib/python2.7/site-packages/toil-3.5.0a1.dev251-py2.7.egg/toil/__init__.pyc
INFO:toil.lib.bioio:Root logger is at level 'INFO', 'toil' logger at level 'INFO'.
INFO:toil.jobStores.fileJobStore:Path to job store directory is '/hive/users/anovak/ga4gh/hgvm/hgvm-builder/tree'.
INFO:toil.common:Using the single machine batch system
WARNING:toil.batchSystems.singleMachine:Limiting maxCores to CPU count of system (64).
WARNING:toil.batchSystems.singleMachine:Limiting maxMemory to physically available memory<PHONE_NUMBER>200).
INFO:toil.common:Created the workflow directory at /scratch/tmp/toil-aaf73598-8176-451c-b972-dc7d339ce25e
WARNING:toil.batchSystems.singleMachine:Limiting maxDisk to physically available disk<PHONE_NUMBER>36).
INFO:toil.batchSystems.singleMachine:Setting up the thread pool with 640 workers, given a minimum CPU fraction of 0.100000 and a maximum CPU value of 64.
INFO:toil.common:Written the environment for the jobs to the environment file
INFO:toil.common:Caching all jobs in job store
INFO:toil.common:0 jobs downloaded.
INFO:toil.jobStores.abstractJobStore:Checking job graph connectivity...
Traceback (most recent call last):
  File "/cluster/home/anovak/python/bin/build-hgvm", line 11, in <module>
    load_entry_point('hgvm-builder', 'console_scripts', 'build-hgvm')()
  File "/hive/users/anovak/ga4gh/hgvm/hgvm-builder/src/hgvmbuilder/build.py", line 245, in entrypoint
    sys.exit(main(sys.argv))
  File "/hive/users/anovak/ga4gh/hgvm/hgvm-builder/src/hgvmbuilder/build.py", line 214, in main
    toil_instance.restart()
  File "/cluster/home/anovak/python/lib/python2.7/site-packages/toil-3.5.0a1.dev251-py2.7.egg/toil/common.py", line 619, in restart
    rootJob = self._jobStore.clean(jobCache=self._jobCache)
  File "/cluster/home/anovak/python/lib/python2.7/site-packages/toil-3.5.0a1.dev251-py2.7.egg/toil/jobStores/abstractJobStore.py", line 475, in clean
    getConnectedJobs(self.loadRootJob())
  File "/cluster/home/anovak/python/lib/python2.7/site-packages/toil-3.5.0a1.dev251-py2.7.egg/toil/jobStores/abstractJobStore.py", line 190, in loadRootJob
    "is finished or has never been started" % rootJobStoreID)

I need to be able to successfully call restart(), and get the return value from the root job, as many times as it takes, in different invocations of my user script, until the code in the with Toil(options) as toil_instance: block finishes without throwing an error.

I agree that this is a problem. I disagree that --restart is applicable here. It would be weird to use --restart to resume failed imports before the workflow has even started. Failed imports are equally likely as failed exports. The import/export on leader feature is still a valid use case. CWL depends on it, for example. Should we instead implement special leader jobs that are tracked by Toil but are guaranteed to run on the leader?

With leader jobs, --restart would be applicable.

If jobs can import and export, it would make sense to be able to delegate
imports from HTTP and FTP sources to workers. Only file URL imports and
exports really need to happen on the leader.
On Fri, Nov 18, 2016 at 1:29 AM, Hannes Schmidt<EMAIL_ADDRESS>wrote:

With leader jobs, --restart would be applicable.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/BD2KGenomics/toil/issues/1319#issuecomment-261486757,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE0_X88Lbim0USrO1rFjsNrAmPlV6kxmks5q_W_sgaJpZM4K0ZXW
.

Maybe Toil.importFile() and Toil.exportFile() can be rewritten to make use of these leader jobs.

I just wanted to note that I have once again lost time to this bug. This time it's about 3 hours of wallclock time on kolossus that I'm going to have to repeat, but in the future it might be hundreds of dollars of AWS credit.
Maybe we shouldn't delete the return value of the root job until the user script on the master exits successfully?

Wait, is this still a thing? This is really easy to fix if so: we can just check for whether the root promise has been fulfilled before doing anything else.

I'm not sure. I haven't had this happen lately.


Navbar linting issue

💡 Description
When executing npm run build, the output includes the following issue relating to the implementation of the Navbar component:
(!) Plugin typescript: @rollup/plugin-typescript TS2741: Property 'titleLink' is missing in type '{ navItems: [{ id: string; label: string; href: string; items?: [{ id: string; label: string; href: string; }] | undefined; }]; subTitle: string; subTitleLink: string | undefined; }' but required in type 'Omit<HeaderProps, "title">'.
src/components/Header/Header.tsx: (44:10)

44         <Navbar
            ~~~~~~

  src/components/Header/Header.tsx:21:3
    21   titleLink: string;
         ~~~~~~~~~
    'titleLink' is declared here.

(!) Plugin typescript: @rollup/plugin-typescript TS2741: Property 'titleLink' is missing in type '{ navItems: [{ id: string; label: string; href: string; items?: [{ id: string; label: string; href: string; }] | undefined; }]; subTitle: string | undefined; subTitleLink: string | undefined; }' but required in type 'Omit<HeaderProps, "title">'.
src/components/Header/Header.tsx: (56:14)

56             <Navbar
                ~~~~~~

  src/components/Header/Header.tsx:21:3
    21   titleLink: string;
         ~~~~~~~~~
    'titleLink' is declared here.

⚔ Parent Epic / Related Tickets
No response

Fixed via PR #48


0.8版本后为啥报错require is not defined

升级到0.8后的版本,vue3+vite报错 ,0.7的版本是正确的
require is not defined
生成的源代码中
const { ref, onBeforeMount } = require('vue');
但是vite又不支持require.这个如何解决

We temporarily close this due to the lack of enough information.
Please provide a minimal reproduction to reopen the issue.
Thanks.

Why reproduction is required


Restore acls for ::server-admins and org read access groups if they a…

…re missing
Signed-off-by: Josh Hudson<EMAIL_ADDRESS>

This looks good! Thanks @itmustbejj


Bug: react/prop-types fails to parse destructured Flow typing with Flow union type

Symptom: react/prop-types indicates that props validation is missing for all props in the component.
This occurs whenever there is a destructured Flow typing anywhere in the component, and props are typed in the component using a union &. This is reproducible on v7.2.0 and earlier. Minimally reproducible example:
// @flow

import React, { Component } from 'react';

type PropsA = {
  a: string,
};

type PropsB = {
  b: string,
};

type Props = PropsA & PropsB;

export default class Sample extends Component {
  props: Props;

  handleEvent = ({ value }: { value: string }) => {};

  render() {
    const { a, b } = this.props;

    return (

        {a}{b}

    );
  }
}

The reported errors are:
  21:13  error  'a' is missing in props validation                          react/prop-types
  21:16  error  'b' is missing in props validation                          react/prop-types

No ESLint errors are generated if value is not Flow-typed in the destructure:
// @flow

import React, { Component } from 'react';

type PropsA = {
  a: string,
};

type PropsB = {
  b: string,
};

type Props = PropsA & PropsB;

export default class Sample extends Component {
  props: Props;

  handleEvent = ({ value }: Object) => {};

  render() {
    const { a, b } = this.props;

    return (

        {a}{b}

    );
  }
}

Further, no errors are generated if the destructure typing is preserved, but the union typing is removed in favor of a single object:
// @flow

import React, { Component } from 'react';

type Props = {
  a: string,
  b: string,
};

export default class Sample extends Component {
  props: Props;

  handleEvent = ({ value }: { value: string }) => {};

  render() {
    const { a, b } = this.props;

    return (

        {a}{b}

    );
  }
}

@PFarejowicz FYI

Hi @LINKIWI - I have opened a PR for this. Could you test it out on your code and see if it works for you?


Shouldn't the dist files be in ES5?

A lot of people use exclude: /node_module/ in their .js and .vue rules. And the arrow functions aren't transpiled into ES5 code.
Then we get the punc error from uglify. Unexpected token: punc (()...
REF: https://github.com/ktquez/vue-disqus/issues/9

Me too.I can't post files to my server right now.

I think your js file has some errors,you may need rebuild it ,if I reference vue file it is ok.

@zangxx66
VueDisqus v4, can you check if the error persist?

If the problem persists, feel free to reopen that issue.


SSH key management & Git access via SSH

Before you hit that Submit button....
Please read our contribution guidelines
before submitting a pull-request.
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

If you want to raise a pull-request with a new feature, or a refactoring
of existing code, it may well get rejected if it hasn't been discussed on
the mailing list or
slack team first.
Proposed changes
Describe the nature of this change. What problem does it address?
Checklist
Put an x in the boxes that apply

[x] I have read the contribution guidelines
[x] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[x] I have added suitable unit tests to cover the new/changed functionality

@naka7808 Hi - I would like to get this merged as I need to make some changes to code this touches and would like to avoid an merge conflict.
I've added some review comments above that I think should be quiet quick to resolve. Please let me know if you're able to address them this week - otherwise I'll merge and make the necessary changes.

I'm sorry for the delay in my reply. I've revised my code according your advices.
Could you please review them again?


Find a place to include stargazer chart

Stargazers over time

You can discuss it with Nikolay if it is still a relevant
/invite @n-boshnakov

obsolete


deepstream java client in android not working

Hello ,
I am facing problem with deepstream java client on android. I am using deepstream version 2.1.2, deepstream-java-client version 1.0.1 . Event emitting and subscribing is working very fine on web but there is some problem in android client.
I am attaching server log here , my android code is available on this link android app .
Can anyone please help ? If I am doing anything wrong please let me know
Here are few code snippets
new Thread(()->{
            try {
                ds = new DeepstreamClient( "<IP_ADDRESS>:6020" );
                ds.login();
                ds.setRuntimeErrorHandler((topic, event, s) -> {
                    Log.i("@melayer", "Topic - "+topic +" Event - "+ event +" String - "+s);
                });
                ds.addConnectionChangeListener(connectionState -> {
                    Log.i("@melayer", "Connection state - "+connectionState);
                });
                ds.event.subscribe("fromWeb", this::inComingEvent);
                ds.event.subscribe("otherMobile", this::inComingEvent);
            } catch (URISyntaxException e) {
                e.printStackTrace();
            }
        }).start();

on button click I am emitting event
private void okay(View view){
        Log.i("@melayer","okay clicked");
        ds.event.emit("fromMobile",new Object[]{new Date().toString()});
    }

in above code when I write ds.login() it hangs forever, if I comment that it proceeds to connection listener and gives following output
Connection state - AWAITING_CONNECTION
01-24 07:51:48.656 17876-17903/com.melayer.deepstreamapp I/@melayer: Connection state - CHALLENGING
01-24 07:51:48.663 17876-17903/com.melayer.deepstreamapp I/@melayer: Connection state - AWAITING_AUTHENTICATION
what is wrong with above code, but login work on web . I am using java8 in android, is that the problem ?

in above code when I write ds.login() it hangs forever, if I comment that it proceeds to connection listener and gives following output
Connection state - AWAITING_CONNECTION 01-24 07:51:48.656 17876-17903/com.melayer.deepstreamapp I/@melayer: Connection state - CHALLENGING 01-24 07:51:48.663 17876-17903/com.melayer.deepstreamapp I/@melayer: Connection state - AWAITING_AUTHENTICATION
what is wrong with above code, but login works on web . I am using java8 in android, is that the problem ?
how did you solve this  ?

Hello,
for a java client, you need to activate ws-text endpoint and connect to
endpoint @.***:/deepstream-v3
then no problem with login, I'm working with java 11, no issue. At worst
case you may need to rebuild the java client from code source (gradle
build).
Regards,
On Mon, Nov 28, 2022 at 9:46 AM Nikhil Krishna Ghodke <
@.***> wrote:

in above code when I write ds.login() it hangs forever, if I comment that
it proceeds to connection listener and gives following output
Connection state - AWAITING_CONNECTION 01-24 07:51:48.656
17876-17903/com.melayer.deepstreamapp @.: Connection state -
CHALLENGING 01-24 07:51:48.663 17876-17903/com.melayer.deepstreamapp
@.: Connection state - AWAITING_AUTHENTICATION
what is wrong with above code, but login works on web . I am using java8
in android, is that the problem ?
how did you solve this ?
—
Reply to this email directly, view it on GitHub
https://github.com/deepstreamIO/deepstream.io/issues/541#issuecomment-1328726660,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATKH2XGJQNNRUPSECYMZGTWKRWN5ANCNFSM4C5ME6JA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Slah Lachtar
Tel. (+216) 98 221 575


Passing --blocked-url-patterns in config.json

Hi there,
I'm trying to pass an argument to the lighthouse, which would block Google Analytics.
Here's the code from config.json.
"lighthouseFlags": {     "output": ["html", "csv"],     "emulatedFormFactor": "desktop",     "blocked-url-patterns": [       "*www.google-analytics.com/analytics.js*"     ]   }
Based on Lighthouse documentation, it's possible to pass that argument. I've tried passing just the URL, without brackets, it didn't work, then I tried using the brackets without the asterisk and it didn't help. Any idea how to block requests for this url: www.google-analytics.com/analytics.js?
My goal is to perform audit reports but without notifying google analytics about it, since running 100-200 tests on websites that have maybe 1, 2000 monthly visitors would mess the data.

Actually, after a little bit of digging, figured it out. I was using blocked-url-patterns instead of blockedUrlPatterns.
The full code that's working properly from what I can see is:
"lighthouseFlags": {     "output": ["html", "csv"],     "emulatedFormFactor": "desktop",     "blockedUrlPatterns": [       "www.google-analytics.com/analytics.js"     ]   }

You could just filter your traffic from analytics...


feat(webpack): generate output manifest in webpack build

I mistakenly excluded output_manifest from the webpack GCC options, but a manifest can be useful for debugging the build.
The official option exclusion list from the plugin docs is:
module_resolution
output_wrapper
dependency_mode
create_source_map
module
entry_point

We also exclude js and js_output_file because these are controlled by the plugin, despite not being explicitly stated.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Use functools.wraps() to update the attributes of the decorator

Makes docstrings of decorated functions available.
See for example: https://stackoverflow.com/a/1782888

Great, thanks for contributing!


[gyb] check isinstance(result, basestring) before string comparison

Guard against types that override __eq__ and do things like
raise TypeError when the types being compared don't match.

@swift-ci please python lint.

@swift-ci Please smoke test

PyLint failures unrelated to this change.

I'll open a PR fixing the python-lint issues by the way, just claiming that :D

@toffaletti Looks like you don't have your collaborator bit, so CI has to be done by somebody else
@swift-ci please smoke test

@swift-ci Please smoke test and merge

@swift-ci Please smoke test and merge


Hover: app packaging

Regrouping the issues related to app packaging:

windows: https://github.com/go-flutter-desktop/go-flutter/issues/106
linux: https://github.com/go-flutter-desktop/go-flutter/issues/160
Mac: https://github.com/go-flutter-desktop/go-flutter/issues/99 / https://github.com/go-flutter-desktop/go-flutter/issues/179

Packaging can be done by the user, that why it's not our top priority.
We don't want to add too much dependencies in hover; what we would like to have is commands like hover package init-snapcraft, hover package init-innosetup. Those commands will create templates files that can be customized by the user; once the user is happy with the configuration, he can run manually the actual program that does the packaging.

Maybe a different repo then within the org ?
I would really like to see the polish of proper packaging.
I started to do some but got side tracked.
I was also working on auto updating functionality. Again not finished.

@joeblew99 no it should not be in another repo of the organization.
It should be another hover command.

I think it would be better to not have to initialize the packaging, because the configuration files for will change when the pubspec.yaml changes and have to be regenerated. I would prefer something like this:
hover package snapcraft
hover package innosetup

There's a lot of nice stuff in go-flutter-desktop/hover#15. Thanks @jld3103 for getting started on this story and working out a viable solution.
I've been discussing with @Drakirus about how to fit packaging into the hover cli. A number of idea's came to mind, and after some brainstorming we've come to realize some changes are required to improve how the packaging features can be used by developers.
In the examples here I will pretend that go-flutter-desktop/hover#12 has already been merged, which means that the desktop directory has been renamed to go. So there is go/cmd and go/build and go/go.mod etc.
Packaging and distribution works differently on desktops than it does on mobile. For starters, packaging is optional. The current build outputs can be zipped and distributed. There is no complex structures or file formats needed like there is for mobile.
For desktops, there are tens of different packaging methods, which you may all want to use at the same time to cover a broad range of users. Whereas for iOS there is just one way to package your app. And for Android there are two, of which you'll probably only use one at a time (apk vs aab). ((ofcourse aab contains apk's, but lets focus on the final outputted file for distribution)).
We propose a structure where configuration for packaging tools is separated from the packaging process and the actual packaged output.
Packaging methods
Packaging methods are each implemented specifically for one OS. Their names consist of the OS, and the packaging kind joined by a dash; $os-$packagingName. e.g.: linux-snap, darwin-dmg, windows-msi.
Packaging configuration
Packaging configuration is stored in a folder which should be included in git (we don't exclude them in our boilerplate .gitignore files). The directory path follows the structure go/packaging/$packagingMethod. e.g.: go/packaging/linux-snap.
Packaging configuration is generated once, by running a specific hover command for each packaging format that the user needs; hover init-packaging <packaging method>.
For example: hover init-packaging linux-snap creates a folder go/packaging/linux-snap and the file go/packaging/linux-snap/snapcraft.yaml inside it. This file is never overwritten by hover. Users may remove go/packaging/linux-snap and run hover init-packaging linux-snap again to regenerate the file. The file may be modified manually, just like users can modify all configuration in the android or ios directories inside a flutter project.
Packaging and packaged output
Packaged output files are stored in go/build/outputs/$packagingSolution.
Breaking change to hover CLI
A breaking change to the hover CLI will be introduced. Currently, flutter build just prints help message, you'll have to select a build target (apk, ios, etc.). However, hover build defaults to the current OS platform and no target platform can be specified. This will be changed; hover build will print help and a second subcommand is needed to actually start a build. The second subcommand can be a target os (linux), or a packaging method (linux-snap). Some examples:

hover build darwin builds raw (non-packaged) binary file for use on darwin, outputted in go/build/outputs/darwin. This is exactly the same as running hover build on a Mac today. The output files are the same, it just becomes mandatory to explicitely state the target platform.
hover build darwin-dmg builds for darwin, then packages the dmg and stores it in go/build/outputs/darwin-dmg/$projectName.dmg
hover build linux-snap builds for linux, then packages the snap and stores it in go/build/outputs/linux-snap/$projectName.snap

This breaking change will also be beneficial to future cross-compiling efforts.

@GeertJohan On mobile the version of the app changes with the version in the pubspec. The way you mentioned only generates the files once and the user would have to update the version manually.
Otherwise I agree with you, but at least the version should be generated every time.

@GeertJohan Your approach outlined above looks really good.
Like how extensible it is. I can see go-flutter being used for many diverse projects this way.
Going to try out the branch and see if i can help.

@jld3103 you mean the version number?

@GeertJohan yes

@jld3103 I agree, but currently we dont have a version number compiled into the binary anyway. It's still on my wishlist though, with support for override via the --build-number and --build-name flags as well.

just copying it here : https://github.com/fyne-io/fyne/blob/master/cmd/fyne/package.go

Nice! Maybe you make a pull request with the proposed implementation after #20 gets merged?

New packaging formats:
linux-appimage: go-flutter-desktop/hover#39
windows-msi: go-flutter-desktop/hover#40
darwin-bundle and darwin-pkg: go-flutter-desktop/hover#42

The feature got released into hover  v0.33.0
Thanks to @jld3103, I'll close this issue.


try-catch-throw in ArcadiaBehaviour not wrapping exception

The try-catch-throw in ArcadiaBehaviour.runFunctions doesn't wrap the caught function in another one, which will overwrite the stacktrace of the inner function

closed.


fastqutils bfq can't decode it's own output

$ cat testfastq.fastq
@aa/1
AAACTCTACAGACAATACATCCGTAATTTTTTCCAGCTTATCTAGTTGCTTTCTGATCCTTAGCTTCTCGAAACCGACGATAGCGCTTCGAATTAAGTCT
+
dbdddcdd_da_cccWcbcccccBcccbbcd^dddededeeee_e^dddbdacWaaddadbd^bdYbccdaaaVWbabaZQbaS^\Z^ZQYYQ`\cZccd
@bb/1
CTCAGTAGATCGTGGGCCGTAGCTTCGCGCATCTCTGAGGGCACC
+
BPMKSSQPPNY[][YY[][[YYSYY______Z_[U^^^^____
$ fastqutils bfq testfastq.fastq -o tfq.bfq
$ fastqutils bfq -d tfq.bfq > tfq.roundtrip
Traceback (most recent call last):
File "/home/amcdavid/src/ngsutils-ngsutils-0.5.7/bin/..//ngsutils/fastq/bfq.py", line 710, in
bfq_decode(fnames[0])
File "/home/amcdavid/src/ngsutils-ngsutils-0.5.7/bin/..//ngsutils/fastq/bfq.py", line 396, in bfq_decode
bfq = BFQ(fname)
File "/home/amcdavid/src/ngsutils-ngsutils-0.5.7/bin/..//ngsutils/fastq/bfq.py", line 160, in init
self._read_header()
File "/home/amcdavid/src/ngsutils-ngsutils-0.5.7/bin/..//ngsutils/fastq/bfq.py", line 258, in _read_header
self.description, = struct.unpack('<%ss' % lendesc, self.fobj.read(lendesc))
struct.error: unpack requires a string argument of length<PHONE_NUMBER>
So it looks like it's unpacking lendesc improperly, but without documentation or knowledge of what the binary format is, I don't think I have any hope of fixing it myself.

I'm impressed that this was found - it was a hidden module. I removed the command from git HEAD. If you're interested in a more compact tool for FASTQ files, please check out this one: https://github.com/compgen-io/sqz.  It's an updated version of the same concept, and it is supported.


nspr: 4.25 -> 4.26

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/nspr/versions.
meta.description for nspr is: "Netscape Portable Runtime, a platform-neutral API for system-level and libc-like functions"
meta.homepage for nspr is: "http://www.mozilla.org/projects/nspr/"
meta.changelog for nspr is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 4.26 with grep in /nix/store/7mh37w37164rq4zyrgr9gz98zfx8w71f-nspr-4.26

directory tree listing: https://gist.github.com/e0e0a0d441247606a37637c9e34974ad

du listing: https://gist.github.com/96b8ce199133bfce447cb7c586dcd6a1

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

1639 total rebuild path(s)

648 package rebuild(s)

645 x86_64-linux rebuild(s)
473 i686-linux rebuild(s)
73 x86_64-darwin rebuild(s)
448 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
Sylk
_389-ds-base
adapta-gtk-theme
adoptopenjdk-icedtea-web
airtame
akregator
aliza
almanah
alpine-make-vm-image
amarok
amarok-kf5
android-studio
androidStudioPackages.beta
androidStudioPackages.canary
androidStudioPackages.dev
androidStudioPackages.stable
anki
ankisyncd
appimage-run
aqemu
atom
atom-beta
aucdtect
autofs5
avocode
azuredatastudio
badvpn
bareos
betaflight-configurator
bitwarden
bluejeans-gui
bookworm
brackets
brave
calamares
calibre
calls
cantata
ceph
ceph-client
ceph-dev
chrome-gnome-shell
chromedriver
chromium
chrony
cinnamon.cinnamon-control-center
cinnamon.cjs
clair
clementine
clementineUnfree

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7mh37w37164rq4zyrgr9gz98zfx8w71f-nspr-4.26 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

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

Pre-merge build results
NixPkgs review skipped

Maintainer pings

See #91746


Gradle task ignoring working directory parameter

Question, Bug, or Feature?
Type: Bug
Enter Task Name: Gradle
Environment

Server - Azure Pipelines
Agent - Hosted (ubuntu-latest)

Issue Description
My pipeline definition contains the following:
- task: Gradle@2
	displayName: Gradle build
	inputs:
	  workingDirectory: $(Build.SourcesDirectory)/android
	  gradleWrapperFile: gradlew
	  tasks: assemble

However the output in Azure Pipelines is:
2020-08-24T13:14:32.9606796Z ##[section]Starting: Gradle build
2020-08-24T13:14:32.9615067Z ==============================================================================
2020-08-24T13:14:32.9615535Z Task         : Gradle
2020-08-24T13:14:32.9615757Z Description  : Build using a Gradle wrapper script
2020-08-24T13:14:32.9616214Z Version      : 2.173.0
2020-08-24T13:14:32.9616666Z Author       : Microsoft Corporation
2020-08-24T13:14:32.9616974Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/gradle
2020-08-24T13:14:32.9617302Z ==============================================================================
2020-08-24T13:14:33.2768112Z ##[error]Error: Not found wrapperScript: /home/vsts/work/1/s/gradlew
2020-08-24T13:14:33.2788492Z ##[section]Finishing: Gradle build

As can be seen from the path, it seems that the working directory I specified is being ignored (no mention of Android anywhere in the path). My project structure means that I can't have my Android project at the root directory so I need to use the 'android' directory as the working directory.

Hi, @Garand-Gary! Could you please try to pass the relative path from the repository root to the Gradle Wrapper script to gradleWrapperFile  parameter.
If it's located in the android folder than it should look like:
gradleWrapperFile: 'android/gradlew'
Could you please let me know whether it helps? Thank you!

Hi Egor, thanks for your reply.
So simple, with hindsight so obvious, and so effective! That is now allowing me to complete my builds.
I had tried your suggestion of 'android/gradlew', and I had tried the working directory being set, but I had not tried both together as that seemed incorrect to me as the combination of those options would give the wrong path.
Thanks


screed 0.8

[x] Is it mergeable?
[ ] Did it pass the tests?
[x] If it introduces new functionality in scripts/ is it tested?
Check for code coverage with make clean diff-cover
[x] Is it well formatted? Look at make pep8, make diff_pylint_report,
make cppcheck, and make doc output. Use make format and manual
fixing as needed.
[x] Did it change the command-line interface? Only additions are allowed
without a major version increment. Changing file formats also requires a
major version number increment.
[x] Is it documented in the ChangeLog?
http://en.wikipedia.org/wiki/Changelog#Format
[x] Was a spellchecker run on the source code and documentation after
changes were made?

@bocajnotnef Review & merge please

retest this please

Jenkins, test this please


Convert to Python3

using : find . -name '*.py' | xargs 2to3 -w

This looks good to me; can you make a new PR that doesn't include the .bak files?

Ok now.

I was thinking a new PR with only 1 commit to keep from cluttering up the history, but this project isn't big enough to really worry about it.
Thanks for your changes!


Second attempt at Win64 instead of Win32

According to
https://github.com/ethereum/cpp-ethereum/wiki/Building-on-Windows#2-generate-solution-with-cmake
when using cmake 2.8.XXX you need to provide a different argument than
when using 3.x.

lgtm


How to write Between condition in v2.+?

How can I write Between condition in v2.+?

Condition.column(columnName).between(value1).and(value2)


Use git:// protocol instead of https:// to clone from github?

I'm running into a weird problem where github keeps asking for my username and password.
See: https://help.github.com/articles/why-is-git-always-asking-for-my-password
This doesn't usually happen, so it's probably a problem with my environment right now, but should be avoidable by vim-plug if it just used the git:// protocol instead of https://.
Also another benefit, from https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols
The Git protocol is often the fastest network transfer protocol available. If you’re serving a lot of traffic for a public project or serving a very large project that doesn’t require user authentication for read access, it’s likely that you’ll want to set up a Git daemon to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead.
There could be some headache trying to migrate people's existing projects from https:// to git:// though.

Oh, heh, apparently it's because the repository is down due to DMCA takedown. I didn't even know that happens on github.
Anyway, the speedup of git:// over https:// is still something to consider. You could make it so vim-plug recognizes and respects existing URLs with any protocol, but create new clones with git:// only. That would solve the migration problem.

Plug command takes any valid git url, so you can already do it, right?
There is also g:plug_url_format option.

Yeah, but it's arguably a better default.

I disagree. For me it doesn't work in corporate environment where I'm behind http proxy. And I don't think we should choose unencrypted protocol for marginal performance benefit it provides considering that most vim plugins are relatively small. And GitHub officially recommends https protocol for cloning. I can understand someone prefers it, but it's not a good default.

Okay. Fair enough.


registryfinder: add initial manifest version 2.52

Adding Registry Finder
https://registry-finder.com/

[x] I have read the Contributing Guide.

This isn't ready yet... sorry.

You can mark it as a draft :)

This took too long today.

BTW, why not rename app name to registry-finder (adding dash)?

/verify


Proposal: add '$schema' property at root of the spec 2.x

JSON schema specifies a standard way for a document to tell what JSON Schema document can be used to validate it. This is the /$schema property.
Unfortunately this property is strictly disallowed in the Swagger 2.0 JSON schema (/additionalProperties is set to false): Swagger authors decided to use instead the /swagger property (following previous versions). This is enough for humans, but the presence of /$schema could be useful for machines to validate Swagger specifications that use vendor extensions and for which a JSON schema specifying the schema of those extensions is available. That would allow to write a Swagger spec that explicitely points to the JSON schema that validates those extensions.
So I propose to add /$schema, with a default value of http://swagger.io/schema/v2.0/schema.json (see swagger-api/swagger.io#48 which is a request to have canonical URLs for Swagger JSON schemas).
As this feature is incompatible with the 2.0 schema (/$schema is forbidden in 2.0 because /additionalProperties is set to false), setting this value in a document will only be possible if a version 2.0.1/2.1 of the specification is published with that extension.
An implementation in the JSON Schema is proposed in #485.

I agree, it would be very useful.
Several validation libraries will use the "$schema" property to automatically validate the document against that schema. I can include "$schema": "http://swagger.io/schema/v2.0/schema.json" in my swagger spec, but all it will do is tell me that it's invalid because of that attribute. ^_^

@webron Proposal for OpenAPI.next

#561 provides a nice reason to endorse this, some of the benefits past that are listed above.

@webron about your comment in #561

The OpenAPI spec is not JSON Schema. It uses it to describe input/output, it provides it as a limited form of validation, but it is not the same.

I agree that the OpenAPI spec is not JSON Schema. But an OpenAPI document is written in JSON and the OpenAPI specification itself is described with a JSON Schema (that I agree does not validate the spec rules comprehensively) and it would be helpful to be able to use a JSON Schema validator to do the basic validations. And it would be particularly useful to be able to use a JSON Schema validator to validate an (OpenAPI+extensions) document against a JSON Schema of that OpenAPI+extensions.

I'm afraid I still fail to see why this needs to be part of the spec. For JSON Schema documents, I get the benefit, but to have each OpenAPI specification point to a JSON Schema that partially validates it, and it would be the same JSON Schema for all specs, there's no added value in it. This is a tooling issue - it can read the version of the spec and map that to the JSON Schema it can use to validate it with which is constant. Why bloat specs to add that detail which is constant and can be derived from other parts of the spec? If this comes instead of #561 - that may make sense.

Parent issue: #560

This is helpful for validation, but not helpful from the tooling point of view.  Please see my comments here for what I feel are pros and cons.

We have decided to not add support for $schema.


[feature proposal] Per-Repo Linting

Featrure proposal for Per-Repo Linting
Linters are generally applied at the repo (or even standardized across orgs) and are not package-specific.  The way it is now if you have many packages in a single repo to have standardized linting you need to specify the set of linters you want to use in every package.xml and CMakeLists.txt by copy-pasting them.  This seems to me that the lint tests could be declared at a more optimal level of abstraction that would enable some advanced features.
I would like there to be a way to define which linters apply to all packages within a given repo.  My idea is something like a .lint.yaml file in the root of the repo that would contain things like this:
linters: [ament_clang_format, ament_clang_tidy]
ament_clang_format:
  version: 10
  config: .clang-format
ament_clang_tidy:
  config: .clang-tidy
  mixins: compile-commands

Then when someone runs colcon test it runs the linters per-repo.  The way it exists now (afaik) the linters are run through ctest per-package via cmake args and colcon test is basically just a way to call ctest recursively per-package.
This would enable you to have per-repo configurations for the linters which would reduce copy-pasted configurations, increase standardization across the repo, and enable features that operate on a per-repo level.  The specific feature I want is to limit linting to packages with source changes since some point in the git history.  By doing linting per-repo we would be able to have linting logic (including filtering) per-repo.
Background
I want to be able to use ament lint tests on a ros1 project built with colon.  I also want to add features to the executing of those tests that are per-repo.  Specifically, I want to only run clang-tidy on packages that have source file changes since a specified branch.  I starting implementing these as features to ament_clang_tidy here: https://github.com/ament/ament_lint/pull/280.  There I was told that this should exist at a higher level of abstraction than the ament_lint script and should instead be done at or above colcon.  One of the motivations for this change is to make it simple for developers to run the linters locally before submitting PRs.  The current design of colcon test includes running the linters however it is done per-package instead of per-repo which does not adding per-repo linting logic.
Other options
A new verb to colcon that handles per-repo execution of linters.  Maybe colcon lint?  This has some upsides as maybe it could be developed outside of colcon itself and installed as an extension or plugin of sorts.  While this makes some parts of developing this feature easier it would add yet another disjointed way to run part of the tests.
A script that executes colcon/git/ament commands.  This is what I think @tfoote was suggesting I do.  This is sort of what we have already with moveit_ci for clang-tidy.  We have a bash script that depends on variables in travis to execute the clang-tidy tests as a step in CI.  This script can't be easily used locally to test and is not easily reused for other projects.

After reading through the documentation on the wiki for the colon project there is already an option for setting the base directory to do discovery from.  Maybe this could be used for limiting tests to a specific repo.
After that, there would have to be some concept of a per-repo test/lint config.  I'm not sure where that would fit.  Would that be something that would make sense as an extension to colcon?

After reading through the documentation on the wiki for the colon project there is already an option for setting the base directory to do discovery from.  Maybe this could be used for limiting tests to a specific repo.
After that, there would have to be some concept of a per-repo test/lint config.  I'm not sure where that would fit.  Would that be something that would make sense as an extension to colcon?

You don't need permission from the colcon maintainers to create your own external plugin implementing a {{lint}} verb or whatever else.
That said, as it stands at present, colcon has zero repo-level visibility— the only unit of division it understands is the package, and a package could be a lot of different things: part of a git checkout, a partial checkout from a VCS which supports that such as svn or p4, an extracted tarball, a symlink to a checkout somewhere else, etc. So I think attempting to determine "repo membership" would basically be down to something like starting from each repo's directory and climbing back up the directory hierarchy looking for some kind of marker/config file.
As someone who deals regularly with a workspace containing hundreds of packages from a variety of sources (internal and external to my company) at varying levels of lint compliance and overall maintained-ness, I certainly appreciate linting being managed at the individual package level and that's always what I've advocated for (I'm the original roslint author). However, linting is special in the sense that it doesn't actually depend on building the package or really anything else, so some projects choose to call their linter exclusively at CI time— thinking of tox files in Python repos, for example. So I might focus your attention first on building an external tool which can do just the linting given a list of packages (and whatever config scheme you devise), and then from there see what kind of minimal glue would be necessary to invoke that tool in conjunction with the package paths emitted by colcon's package discovery mechanisms.

You don't need permission from the colcon maintainers to create your own external plugin implementing a {{lint}} verb or whatever else.
That said, as it stands at present, colcon has zero repo-level visibility— the only unit of division it understands is the package, and a package could be a lot of different things: part of a git checkout, a partial checkout from a VCS which supports that such as svn or p4, an extracted tarball, a symlink to a checkout somewhere else, etc. So I think attempting to determine "repo membership" would basically be down to something like starting from each repo's directory and climbing back up the directory hierarchy looking for some kind of marker/config file.
As someone who deals regularly with a workspace containing hundreds of packages from a variety of sources (internal and external to my company) at varying levels of lint compliance and overall maintained-ness, I certainly appreciate linting being managed at the individual package level and that's always what I've advocated for (I'm the original roslint author). However, linting is special in the sense that it doesn't actually depend on building the package or really anything else, so some projects choose to call their linter exclusively at CI time— thinking of tox files in Python repos, for example. So I might focus your attention first on building an external tool which can do just the linting given a list of packages (and whatever config scheme you devise), and then from there see what kind of minimal glue would be necessary to invoke that tool in conjunction with the package paths emitted by colcon's package discovery mechanisms.

linting is special in the sense that it doesn't actually depend on building the package or really anything else

clang-tidy and many static analysis tools that depend on the compile_commands.json files would disagree slightly.  Not that these files are the explicit product of building (like object files) but they are at least a sideafect.
As of now, there is no nice way to add a clang-tidy check, even on a per-package level, and only run it when the compilation files exist as the ament_clang_tidy or ament_cmake_clang_tidy test has no way to affect how the project is built.  Right now all the litners would be run, and clang-tidy would always fail for missing input.
Secondly, one of the big motivations for this is clang-tidy takes a long time to run (~30 sec per compilation unit, of which MoveIt has hundreds).  As a result of the lack of knowledge of the repo layer in the build environment, there is no nice way to filter to only packages that have changed or packages that have changed and their dependencies.  In the case of clang-tidy the former is sufficient to keep a codebase in compliance.  There are other static analysis tools that would also need to run over all dependencies also because they trace execution paths in binaries.

As someone who deals regularly with a workspace containing hundreds of packages from a variety of sources (internal and external to my company) at varying levels of lint compliance and overall maintained-ness

I'm sorry this has been your experience and does seem normal in a product or hasty prototyping, but I would hope that large open-source libraries would not have this practice.  Instead, the maintainers would agree at an org or at the least repo level what linters to use and standardize on a set of configurations for them.  My current use-case is both, products, and open source libraries.  I feel that linters being applied globally is one of the best ways of using CI to enforce standards on all PRs accepted into the project.  On the projects we also work on that are not libraries I've fought to have this same standard be applied to any code we build from source.
The reason I think linting should be per-repo is that I've never seen code mixed from different sources (and therefore different standards) within a repo.  If you need a fork or a source build of something external it normally comes with its own form of source control (or I can just put it in a separate repo).  I think your use-case of having varying levels of linting inside a single repo as a result of mixing internally developed tools with external ones in one repo seems odd.  Maybe you or others can point to open source examples where this is done?  This seems like it'd be error-prone at best and should generally not be encouraged.

So I think attempting to determine "repo membership" would basically be down to something like starting from each repo's directory and climbing back up the directory hierarchy looking for some kind of marker/config file.

Another thing I'd like to point out is that while it is possible for there to be other forms of source control, as far as I'm concerned there is only git (or gerrit which is built on git).  This is for our own sanity and those we work with.  Any project where we are maintaining the code is either in git or we put it in git, or package it in a debian and put that in a package repo.  We always strive to contribute upstream if possible when we make improvements.  As to making this something that is more generic I would leave that to those who care for other forms of source control and hopefully answering the question of "which source files have changed in this sub-directory since <branch, tag, hash, whatever string key>?" is generic enough they can figure out how to suggest changes to work with their preferred source control.  I'd be happy to return an error if given a path that didn't have a .git folder as a child directory.

So I might focus your attention first on building an external tool which can do just the linting given a list of packages

I did attempt this as new parameters in ament_clang_tidy in a PR because I thought it was the right place to implement that (it is a standalone script that crawls the build and source directory executing clang-tidy).   Every other linter can be used as is as we'll just have a target workspace in ci with only what we want to test and those are all much faster.  I was told that was not the right place for it as nothing in ament should depend on package discovery which is a feature I needed for my approach.
I started with the PR to ament_lint and then came here because I am frustrated with the federated nature of all the ci systems used by large (including ours) ros libraries and would like to work towards collaboration and standards in linting and testing in general to reduce the maintenance burden of CI systems for everyone (checkout moveit_ci if you want to see how we are working now).  As it stands there are many projects with varying amounts of quality in their testing that are all struggling with similar problems.  Instead of trying to fix these problems in our own little bubble for ourselves, I'd like to make this easier for others as well, and at the same time learn from others.
The intent of putting this here was to get input from others as to how to go about implementing this and to propose that the default approach to linting should maybe be per-repo by default.  The current default (imho) results in a bunch of copy-pasted code and just plain doesn't work for clang-tidy on large projects.  Are you using ament_clang_tidy in your 600 package project?  Do you have 600 source packages in a single repo from many different original sources?  If so, do you think that has been a good experience, would you recommend it to others as good practice?  I think moveit itself has gotten too big for one repo and we have maybe two dozen packages.  I don't like the CI and test times of our project... I could only imagine what running linters over that project would be like.
Thank you for responding to the issue.  I look forward to hearing your opinion further.

linting is special in the sense that it doesn't actually depend on building the package or really anything else

clang-tidy and many static analysis tools that depend on the compile_commands.json files would disagree slightly.  Not that these files are the explicit product of building (like object files) but they are at least a sideafect.
As of now, there is no nice way to add a clang-tidy check, even on a per-package level, and only run it when the compilation files exist as the ament_clang_tidy or ament_cmake_clang_tidy test has no way to affect how the project is built.  Right now all the litners would be run, and clang-tidy would always fail for missing input.
Secondly, one of the big motivations for this is clang-tidy takes a long time to run (~30 sec per compilation unit, of which MoveIt has hundreds).  As a result of the lack of knowledge of the repo layer in the build environment, there is no nice way to filter to only packages that have changed or packages that have changed and their dependencies.  In the case of clang-tidy the former is sufficient to keep a codebase in compliance.  There are other static analysis tools that would also need to run over all dependencies also because they trace execution paths in binaries.

As someone who deals regularly with a workspace containing hundreds of packages from a variety of sources (internal and external to my company) at varying levels of lint compliance and overall maintained-ness

I'm sorry this has been your experience and does seem normal in a product or hasty prototyping, but I would hope that large open-source libraries would not have this practice.  Instead, the maintainers would agree at an org or at the least repo level what linters to use and standardize on a set of configurations for them.  My current use-case is both, products, and open source libraries.  I feel that linters being applied globally is one of the best ways of using CI to enforce standards on all PRs accepted into the project.  On the projects we also work on that are not libraries I've fought to have this same standard be applied to any code we build from source.
The reason I think linting should be per-repo is that I've never seen code mixed from different sources (and therefore different standards) within a repo.  If you need a fork or a source build of something external it normally comes with its own form of source control (or I can just put it in a separate repo).  I think your use-case of having varying levels of linting inside a single repo as a result of mixing internally developed tools with external ones in one repo seems odd.  Maybe you or others can point to open source examples where this is done?  This seems like it'd be error-prone at best and should generally not be encouraged.

So I think attempting to determine "repo membership" would basically be down to something like starting from each repo's directory and climbing back up the directory hierarchy looking for some kind of marker/config file.

Another thing I'd like to point out is that while it is possible for there to be other forms of source control, as far as I'm concerned there is only git (or gerrit which is built on git).  This is for our own sanity and those we work with.  Any project where we are maintaining the code is either in git or we put it in git, or package it in a debian and put that in a package repo.  We always strive to contribute upstream if possible when we make improvements.  As to making this something that is more generic I would leave that to those who care for other forms of source control and hopefully answering the question of "which source files have changed in this sub-directory since <branch, tag, hash, whatever string key>?" is generic enough they can figure out how to suggest changes to work with their preferred source control.  I'd be happy to return an error if given a path that didn't have a .git folder as a child directory.

So I might focus your attention first on building an external tool which can do just the linting given a list of packages

I did attempt this as new parameters in ament_clang_tidy in a PR because I thought it was the right place to implement that (it is a standalone script that crawls the build and source directory executing clang-tidy).   Every other linter can be used as is as we'll just have a target workspace in ci with only what we want to test and those are all much faster.  I was told that was not the right place for it as nothing in ament should depend on package discovery which is a feature I needed for my approach.
I started with the PR to ament_lint and then came here because I am frustrated with the federated nature of all the ci systems used by large (including ours) ros libraries and would like to work towards collaboration and standards in linting and testing in general to reduce the maintenance burden of CI systems for everyone (checkout moveit_ci if you want to see how we are working now).  As it stands there are many projects with varying amounts of quality in their testing that are all struggling with similar problems.  Instead of trying to fix these problems in our own little bubble for ourselves, I'd like to make this easier for others as well, and at the same time learn from others.
The intent of putting this here was to get input from others as to how to go about implementing this and to propose that the default approach to linting should maybe be per-repo by default.  The current default (imho) results in a bunch of copy-pasted code and just plain doesn't work for clang-tidy on large projects.  Are you using ament_clang_tidy in your 600 package project?  Do you have 600 source packages in a single repo from many different original sources?  If so, do you think that has been a good experience, would you recommend it to others as good practice?  I think moveit itself has gotten too big for one repo and we have maybe two dozen packages.  I don't like the CI and test times of our project... I could only imagine what running linters over that project would be like.
Thank you for responding to the issue.  I look forward to hearing your opinion further.

As mentioned before colcon doesn't have the concept of repositories but only knows about packages. That comes from the fact that a workspace containing packages might not be a repository, e.g. when a specific tarball of a repository is being used / unpacked. I don't think that should change.
In the current design colcon  doesn't provide any specific tests or linters because that would prevent these to be run on an individual package without the tool. Instead tests as well as linters (which are implemented as tests) are provided by each package. That allows to run these tests independently of colcon.
One of the design philosophies of colcon is not force itself on the user. A user should be free to use native tools to achieve the same (which supposedly is less convenient since colcon aims to improve usability). Implementing something like linting within a colcon extension would prevent a user to run the same linter on a single package without colcon.
In ROS 2 specific linters provide their own executable which can be used to lint arbitrary file. Unfortunately there is no single executable which triggers all available linters - optimally depending on some package-level configuration only the ones which should be applied. I would think extending this subsystem to satisfy your use case would be a better direction rather than implementing a custom colcon extension providing a lint verb.

As mentioned before colcon doesn't have the concept of repositories but only knows about packages. That comes from the fact that a workspace containing packages might not be a repository, e.g. when a specific tarball of a repository is being used / unpacked. I don't think that should change.
In the current design colcon  doesn't provide any specific tests or linters because that would prevent these to be run on an individual package without the tool. Instead tests as well as linters (which are implemented as tests) are provided by each package. That allows to run these tests independently of colcon.
One of the design philosophies of colcon is not force itself on the user. A user should be free to use native tools to achieve the same (which supposedly is less convenient since colcon aims to improve usability). Implementing something like linting within a colcon extension would prevent a user to run the same linter on a single package without colcon.
In ROS 2 specific linters provide their own executable which can be used to lint arbitrary file. Unfortunately there is no single executable which triggers all available linters - optimally depending on some package-level configuration only the ones which should be applied. I would think extending this subsystem to satisfy your use case would be a better direction rather than implementing a custom colcon extension providing a lint verb.

Implementing something like linting within a colcon extension would prevent a user to run the same linter on a single package without colcon.

I'm sorry I don't understand what you mean by this?  Right now I'm able to construct the commands to run the linter clang-tidy in ament_clang_tidy on any arbitrary package within the workspace.  The problem is that to do that I depend on package discovery and that is something explicitly outside the available dependencies for ament (I implemented it using a script from catkin, but I could have done the same thing with colcon list).
I'm not understanding why implementing something in a colcon extension (in this case constructing the commands to run specific linters) would prevent a user from calling those same commands outside of colcon?  I can invoke cmake even though colcon can do it for me.

In ROS 2 specific linters provide their own executable which can be used to lint arbitrary file.

This doesn't apply to clang-tidy (the reason I'm here) because it works per compilation unit and depends on the compilation_commands.json files being exported per-package.

Unfortunately there is no single executable which triggers all available linters - optimally depending on some package-level configuration only the ones which should be applied.

I am specifically trying to filter which linters are run based on what files have changed since some arbitrary point in the past.  This is because running clang-tidy over all the compilation units in moveit takes hours on CI systems.  Because of the execution time of doing this we wouldn't be able to just "always run clang-tidy on all packages" as a fact of configuration.  colcon provides many features to filter what packages are being built or tested.  As a result, colcon seemed to me to be the natural place to implement this.

I would think extending this subsystem to satisfy your use case would be a better direction rather than implementing a custom colcon extension providing a lint verb.

What is this subsystem?  Are you referring to ament_lint?
To be clearer what I'm hoping for is something like this:
colcon lint [test type, ie. clang-tidy, default to looking for some configuration file at path] --base-paths <root path of packages, ie. src/moveit> --packages-changed-since <branch name>

Or maybe an extension on the way colcon test works so there is a new type (not just ctest and pytest) that is based on repo level lint config files:
colcon test --lint --packages-changed-since <branch name> --test_names <test names, ie. clang-tidy> --base-paths <src/moveit>

One of the problems I see with what I'm asking is I would be introducing a dependency from one argument on another.  For --packages-changed-since to work I need a --base-paths argument that points into some repo so I can discover the paths in that repo and the base repo path (there is a git command that'll do that or I can search for a .git directory).  Once I have that I can find the root source directory by parsing the cmakecache for that package.  With the base source directory, I can then ask git for a list of source files that have changed (filtering for add and modify diff types) since some branch/tag/hash.  Using that I can filter to just run the linter over packages that have changed in the given PR.
Your reaction to this complex behavior is probably that it is niche and specific to the requirements of running in CI.  Ideally ci just verifies what the submitter already knows (that their change will pass).  For that to be true I want people to be able to easily run linters locally.  In the case of clang-tidy if it were to do the nieve thing and lint all the packages every time no one would use it.  I'm not waiting around for an hour with my computer tied up after changing a couple of files to see if I pass the linter.  Because of this, I need this sort of filtering for users also to run locally.  Otherwise, people will continue to use CI as a way to test if their PR passes clang-tidy which is at the least doubling the amount CI runs.  This is also bad because CI runs take over an hour as it is with this logic implemented in bash.  I'm working to reduce this CI time separately but reducing the number of times CI runs by enabling users to run the same tests easily locally would be a major improvement for our workflow.

Implementing something like linting within a colcon extension would prevent a user to run the same linter on a single package without colcon.

I'm sorry I don't understand what you mean by this?  Right now I'm able to construct the commands to run the linter clang-tidy in ament_clang_tidy on any arbitrary package within the workspace.  The problem is that to do that I depend on package discovery and that is something explicitly outside the available dependencies for ament (I implemented it using a script from catkin, but I could have done the same thing with colcon list).
I'm not understanding why implementing something in a colcon extension (in this case constructing the commands to run specific linters) would prevent a user from calling those same commands outside of colcon?  I can invoke cmake even though colcon can do it for me.

In ROS 2 specific linters provide their own executable which can be used to lint arbitrary file.

This doesn't apply to clang-tidy (the reason I'm here) because it works per compilation unit and depends on the compilation_commands.json files being exported per-package.

Unfortunately there is no single executable which triggers all available linters - optimally depending on some package-level configuration only the ones which should be applied.

I am specifically trying to filter which linters are run based on what files have changed since some arbitrary point in the past.  This is because running clang-tidy over all the compilation units in moveit takes hours on CI systems.  Because of the execution time of doing this we wouldn't be able to just "always run clang-tidy on all packages" as a fact of configuration.  colcon provides many features to filter what packages are being built or tested.  As a result, colcon seemed to me to be the natural place to implement this.

I would think extending this subsystem to satisfy your use case would be a better direction rather than implementing a custom colcon extension providing a lint verb.

What is this subsystem?  Are you referring to ament_lint?
To be clearer what I'm hoping for is something like this:
colcon lint [test type, ie. clang-tidy, default to looking for some configuration file at path] --base-paths <root path of packages, ie. src/moveit> --packages-changed-since <branch name>

Or maybe an extension on the way colcon test works so there is a new type (not just ctest and pytest) that is based on repo level lint config files:
colcon test --lint --packages-changed-since <branch name> --test_names <test names, ie. clang-tidy> --base-paths <src/moveit>

One of the problems I see with what I'm asking is I would be introducing a dependency from one argument on another.  For --packages-changed-since to work I need a --base-paths argument that points into some repo so I can discover the paths in that repo and the base repo path (there is a git command that'll do that or I can search for a .git directory).  Once I have that I can find the root source directory by parsing the cmakecache for that package.  With the base source directory, I can then ask git for a list of source files that have changed (filtering for add and modify diff types) since some branch/tag/hash.  Using that I can filter to just run the linter over packages that have changed in the given PR.
Your reaction to this complex behavior is probably that it is niche and specific to the requirements of running in CI.  Ideally ci just verifies what the submitter already knows (that their change will pass).  For that to be true I want people to be able to easily run linters locally.  In the case of clang-tidy if it were to do the nieve thing and lint all the packages every time no one would use it.  I'm not waiting around for an hour with my computer tied up after changing a couple of files to see if I pass the linter.  Because of this, I need this sort of filtering for users also to run locally.  Otherwise, people will continue to use CI as a way to test if their PR passes clang-tidy which is at the least doubling the amount CI runs.  This is also bad because CI runs take over an hour as it is with this logic implemented in bash.  I'm working to reduce this CI time separately but reducing the number of times CI runs by enabling users to run the same tests easily locally would be a major improvement for our workflow.

To solve my imidiate problem and better explain the use-case I'm looking for I created this package:
https://github.com/tylerjw/moveit_ci_tools
and this PR to ament_lint: https://github.com/ament/ament_lint/pull/287
Together what I want for clang-tidy testing can be achieved like this:
packages_with_changes=$(colcon_list_packages_changed_since --names-only src/moveit master)
ament_clang_tidy --config src/moveit/.clang-tidy --packages-select $packages_with_changes

I'd appreciate more advice on how I could structure these changes as first-class features in colcon or ament.  I am content to let my desire for per-repo lint config to as it seems like more trouble than it is worth.  However, some sort of cli way to run ament_lint tests over specific packages would be really nice.  To do this I propose adding a --packages-select command to all the ament_lint scripts.  Thoughts?

To solve my imidiate problem and better explain the use-case I'm looking for I created this package:
https://github.com/tylerjw/moveit_ci_tools
and this PR to ament_lint: https://github.com/ament/ament_lint/pull/287
Together what I want for clang-tidy testing can be achieved like this:
packages_with_changes=$(colcon_list_packages_changed_since --names-only src/moveit master)
ament_clang_tidy --config src/moveit/.clang-tidy --packages-select $packages_with_changes

I'd appreciate more advice on how I could structure these changes as first-class features in colcon or ament.  I am content to let my desire for per-repo lint config to as it seems like more trouble than it is worth.  However, some sort of cli way to run ament_lint tests over specific packages would be really nice.  To do this I propose adding a --packages-select command to all the ament_lint scripts.  Thoughts?

clang-tidy and many static analysis tools that depend on the compile_commands.json files would disagree slightly. Not that these files are the explicit product of building (like object files) but they are at least a sideafect.

Something to clarify, compile_commands.json files actually get generated at configure stage, not build stage (in other words, when you run cmake, not when you run make/ninja/etc.). colcon build happens to do both configure (if needed) and build. There is no colcon verb that does only configure.

packages_with_changes=$(colcon_list_packages_changed_since --names-only src/moveit master)
ament_clang_tidy --config src/moveit/.clang-tidy --packages-select $packages_with_changes

This usage looks reasonable. I'm not familiar with the inner workings of colcon, but maybe introducing a colcon verb that one only does configure and returns the list of packages that needs building/rebuilding is the way to go.

clang-tidy and many static analysis tools that depend on the compile_commands.json files would disagree slightly. Not that these files are the explicit product of building (like object files) but they are at least a sideafect.

Something to clarify, compile_commands.json files actually get generated at configure stage, not build stage (in other words, when you run cmake, not when you run make/ninja/etc.). colcon build happens to do both configure (if needed) and build. There is no colcon verb that does only configure.

packages_with_changes=$(colcon_list_packages_changed_since --names-only src/moveit master)
ament_clang_tidy --config src/moveit/.clang-tidy --packages-select $packages_with_changes

This usage looks reasonable. I'm not familiar with the inner workings of colcon, but maybe introducing a colcon verb that one only does configure and returns the list of packages that needs building/rebuilding is the way to go.

I'm sorry I don't understand what you mean by this?

If a feature like linting is implemented in colcon then a user choosing to not use colcon but the native build tool (e.g. cmake / make / make install) wouldn't be able to run the linting - since it isn't part of the native build tool.
That is why linting is and imo should be implemented as a test in each package. Independent of what a user uses they can always run that test shipped by the package.

colcon provides many features to filter what packages are being built or tested. As a result, colcon seemed to me to be the natural place to implement this.

And I think colcon should provide you with a way to select the packages, e.g. as described in colcon/colcon-package-selection#25. That being said it would only provide the feature to select the desired packages - but the actual linting functionality would still come from each of the selected packages.

This usage looks reasonable. I'm not familiar with the inner workings of colcon, but maybe introducing a colcon verb that one only does configure and returns the list of packages that needs building/rebuilding is the way to go.

If an upstream package is only configured but not built and installed it would be impossible to configure any downstream packages because the dependencies aren't available. That is why colcon performs these a steps together in a single command.

There are tools that address linting on higher level, e.g., https://github.com/sscpac/statick, but IMO they are quite limiting and in the end you have to write a bunch of shell scripts and cmake toolchains tailored to your specific project and preferences.

Regarding different linting preferences for the same repo: it is totally possible, e.g., when a third party project is imported into your repo as a cmake submodule, I've done that. So linting consistency on a per-repo level cannot be taken for granted.

IMO linting of modified files should be addressed with something like ccache for clang-tidy, i.e., you would have to set CMAKE_CXX_CLANG_TIDY to a proxy utility that would check only those files that do not match anything in a cache. Anything like 'check only files modified from a specific commit' is too ad-hoc. PS: Just to avoid confusion -- I dont run clang-tidy on compile_commands.json, but rather via cmake during project compilation.

actually -> https://github.com/ejfitzgerald/clang-tidy-cache, havent tried it though


[BUGFIX] Fix Embroider by using a global variable

This isn't working/tested etc, just pushing to share the idea. Will resume likely tomorrow afternoon.
But TL;DR the idea is to make this function how import Object from '@ember/object' functions.
So we would take user code:
import classic from 'ember-classic-decorator';

export default @classic class Apple { };

And transform it into:
const classic = __EMBER_CLASSIC_DECORATOR;
export default @classic class Apple { };

And also change our vendor imported script from an AMD module, to a global which exposes __EMBER_CLASSIC_DECORATOR.
This should ensure we don't leave unresolvable module imports around.

[x] confirm the idea will be ok with @pzuraq
[ ] write node-tests for the babel transform
[x] make work
[x] cleanup

@pzuraq I'll likely not have time to work on this until tomorrow evening or saturday afternoon. I know you mentioned you would be able to PR in the AM, so if you can don't let me stand in your way, I would love for this to fix itself ;)

@stefanpenner do you think we need the node tests for the transform? I think the integration tests give us enough coverage, since the API surface area is small and it's not a very general transform. Would be happy to merge as-is if tests pass.
Sidenote, I was having a very hard time busting the cache locally due to the issues caused by https://github.com/babel/broccoli-babel-transpiler/pull/174 . I tried rm -rf node_modules && yarn and that wouldn't work, is there another way to ensure the cache doesn't get used if I run into issues like this again?

Sidenote, I was having a very hard time busting the cache locally due to the issues caused by babel/broccoli-babel-transpiler#174 . I tried rm -rf node_modules && yarn and that wouldn't work, is there another way to ensure the cache doesn't get used if I run into issues like this again?

@pzuraq unless you have a node_modules dir up your file-system, that contains the appropriate files, I am surprised by this. Unless we have another regression.
Also, let me publish the above fix.

thanks @pzuraq for driving this to completion.


[Crash // 1.18.2 - 1.0.2] Oculus/Iris Flywheel Compat requires a Non-existant Version of Flywheel

Recently I updated this mod to 1.0.2, and upon launching Minecraft, the game immediately crashes because I'm missing the correct version of Flywheel, which is to be expected. Knowing that, I went to look for version 0.6.9 of Flywheel and they have it available nowhere. This issue on the Flywheel GitHub also mentions this issue, but it's closed with the suggestion of removing Create, which doesn't work for this issue since I don't play with Create.
I know that Flywheel has been made an optional mod for some mods and a required mod for the rest--therefore calling it legacy, but please let me know if this specific issue is on the side of this mod or Flywheel.
Solutions for this crash might work for everyone who's having this same issue but are 100% not guaranteed to work for those with even a slightly different issue. Regardless, I appreciate your input(s)!
Version Info

Minecraft 1.18.2
Forge 40.2.21
Flywheel 0.6.8a
Oculus Flywheel Compat 1.0.2

Steps to Reproduce

Update this mod to this version.
Have any version of Flywheel before 0.6.9.
Expect 0.6.9 to exist.

Behaviors

Expected: Launch my game like normal.
Actual: Crash my game due to a wrong-version mod dependency exception.

What I Tried

Disable Flywheel (crashes my game due to a missing mod dependency exception).

Crash Log(s)
crash-2024-08-09_22.09.42-client.txt
Relevant Info
The crash log shows that I'm missing v0.6.9 of Flywheel:

Me trying to look for said version only for it to not be available:

You can download it from this website.

The latest version includes Flywheel in the jar, so you don't need to install it separately now.

That seemed to have fixed it. 🖤
This issue has been solved, but for anyone who's having the same issue and can't access the link: _**https://maven.tterrag.com/com/jozufozu/flywheel/flywheel-forge-1.18.2/**_


Document when hooks are run.

Oops, there's a trailing space after "all the rewrites." (I used the web editor so didn't run cargo fmt).

I formatted it!


Merge back pull https://github.com/EOSIO/fc/pull/169/ to 2.0.x, ( std…

Merge back pull https://github.com/EOSIO/fc/pull/169/ to 2.0.x  (std_out does not work in Nodeos logging)

In the future please use git cherry-pick as it is easier to track changes.

However, git cherry-pick told me the base is different so cherry-pick failed.

However, git cherry-pick told me the base is different so cherry-pick failed.

➜  eos-develop git:(log-spam) ✗ cd libraries/fc
➜  fc git:(a4ad789) git checkout eosio-2.0.x
Previous HEAD position was a4ad789 Merge branch 'eosio' into file_copy_norecursive
Branch 'eosio-2.0.x' set up to track remote branch 'eosio-2.0.x' from 'origin'.
Switched to a new branch 'eosio-2.0.x'
➜  fc git:(eosio-2.0.x) git checkout -b tmp
Switched to a new branch 'tmp'
➜  fc git:(tmp) git cherry-pick 4b6855299f5d208bf8c408b7fdc8d251d44b2213
Auto-merging src/log/console_appender.cpp
CONFLICT (content): Merge conflict in src/log/console_appender.cpp
error: could not apply 4b68552... Fix support for stdout
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
➜  fc git:(tmp) ✗ vi src/log/console_appender.cpp
➜  fc git:(tmp) ✗ git add src/log/console_appender.cpp
➜  fc git:(tmp) ✗ git cherry-pick --continue
[tmp a6dceda] Fix support for stdout
 Date: Wed Oct 21 13:11:33 2020 -0500
 1 file changed, 7 insertions(+), 7 deletions(-)

I see, thanks. will use this way in future.


Cleanup readme

Changes:

specify 1.4 as minimal supported version (according to .travis.yml),
consolidate "Installation" and "Quickstart" sections for brevity,
shrink "Usage" to point to docs and examples,

Rendered.

LGTM, thank you for your contribution


Clarify transform for ViewStyleProps, include children in union prop docs

Show the proper shape of transform props:

Currently it is just transform: [object], so this should make it much clearer in the docs as well as properly validate.
cc @vjeux @ide

Nice work there.

d177a45bdce124b635dbc31ab0949d2e9d139eb3 broke the transform docs, rebased and fixed so this is now in a new section:


cloneBox corrupt ref url

printRefUrls(mov);
MovieBox clone = (MovieBox) NodeBox.cloneBox(mov, 16*1024*1024, BoxFactory.getDefault());
printRefUrls(clone);

"file://~~~\samples\sample.mp4"
"file://~~~\samples\sample.mp4"

"file://~~~\samples\sample.mp4 "
"file://~~~\samples\sample.mp4 "

in this code based on Cut.java, corrupt clone 's data ref url.
there is one more space in the end. so i'm continously failed to save as file.
i could save after i manually changed every track's dataRef

Understood, it would be great if you could attach a file you tried this on, so it's easier for me to repro and fix.


(Fix) Proxy usage update: support of Dutch Auction

Relates to https://github.com/poanetwork/token-wizard/issues/957
The 3d step: support of Dutch Auction Proxy
Nothing changes from UI perspective or from logic for usage of exec-id

@fernandomg thanks, fixed


Plat 11912

Description
Preparing for 2.6.1 release
Contains
Features
#625 : Polish Groups API
#632 : Target specific commit for symphony-api-specs
#633 : Supported a list of files in multipart form data
#637 : Support user apps patch
#643 : Deprecating DFv1
Dependency upgrades
#624 : Upgraded to Gradle to 7.3.3
#629 : Upgrade Hazelcast version in examples
#630 : Upgrade dependencies
#635 : Upgrade Hazelcast
#636 : Upgrade dependencies (SB 2.6.4)
#642 : Upgrade Jackson to 2.13.2
#649 : Upgraded Spring Boot to 2.6.6
#646 : Upgrading dependencies
Documentation
#626 : Update PR template
#627 : Add proxy configuration example
#639 : Example to import messages with attachments
#641 : Generate javadoc for group extension
#644 : Fixing broken documentation links

Closed because it is replaced by a new 2.7-rc branch and https://github.com/finos/symphony-bdk-java/pull/651


Fortify load_neurons to handle pathlib.Path and sequences

And remove remnants of python 2 compat code

Where do you plan to do a mass replace of os.path with Path

Yes, I should do this one day. But I did not have time yet.

Do we still need OrderedEnum implementation in utils.py?

I think we do. The code provided at https://docs.python.org/3/library/enum.html#orderedenum is just a recipe. So I think we need to implement it even in python 3. Correct me if I'm wrong.

The bug is at l.117 of io/utils.py, you need to add Path along with str ;)

Ahh, you mean the name = None bug. Okay, I'll hotfix that. Thanks for finding out.

Yes! I just converted to Path -> str to make it work on morph-validator, but maybe good to have this consistent in neurom loaders.


[FIX] We don't need a signup with google button when user is logged in

-Take an updated pull of dev-frontend branch and commit your changes there

I am solving it @cb7chaitanya

Done @cb7chaitanya check it #113  fixes it

@cb7chaitanya look into  PR #113 ..


Refactoring Provisioning Logic for Improved Activation

Refactor tools/lib/provision_inner to conditionally write activation commands to the user's bash profile based on the machine type. Activation commands are now skipped for non-Vagrant/Droplet/Docker setups.

This pull request refactors the tools/lib/provision_inner script to enhance machine type detection. Activation commands for the Zulip environment are now conditionally written to the user's bash profile, specifically targeting Vagrant, Droplet, and Docker setups. This change ensures that the activation script is only added for dedicated Zulip environments.
Fixes:  #15029

Screenshots and screen captures:

Self-review checklist

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

Communicate decisions, questions, and potential concerns.

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

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

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

Completed manual review and testing of the following:

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

Hey there,
I am newbie here and i don't know how to start , Can someone please guide me ?
I guarantee with proper guidance i am ready to commit my very best

Hey there,
I am newbie here and i don't know how to start , Can someone please guide me ?

Hey there, I am newbie here and i don't know how to start , Can someone please guide me ?
Welcome to Zulip. This is a PR, so you might wanna avoid asking your queries here.  You can follow this link https://zulip.readthedocs.io/en/latest/contributing/contributing.html# to get started. You can also join https://chat.zulip.org/ to ask your specific queries.

Hi @amanagr,
I've made some refinements to my PR. It would mean a lot to me if you could take a look.
Thanks!

Looks promising. Can you squash both your commits into one?

Looks promising. Can you squash both your commits into one?

I've squashed the commits in my PR into one for a cleaner commit history. Please take another look when you have a moment.
Thanks!

@s-bose7 thanks marked for integration review.

@amanagr  Thank you for marking my PR for integration review. I appreciate the consideration. Please let me know if there are any further steps or actions needed from my end to facilitate the integration process.

OK this looks good but I think we also need to check if a system is WSL2, since that's another common configuration where it should apply.

OK this looks good but I think we also need to check if a system is WSL2, since that's another common configuration where it should apply.

I was working under the assumption that WSL2 host machines should also be skipped for writing the activation command. The current changes allow only vagrant/docker/droplet machines to be eligible for automatic activation. However, based on your feedback, I now understand that WSL2 should be considered as another dedicated container for running Zulip; I must specify that in the activation logic. Thanks for pointing that out; I'd refine my PR.

@timabbott please take a look, when you've a moment.
Thanks!

LGTM

Merged, thanks @s-bose7!

Thank you for merging my PR!
Looking forward to my next contribution!

Reverted in 60f324518b0c674cdc33886186701e70df29f255.

@andersk thanks for pointing out the mistakes. I see that I can't use /vagrant to identify vagrant containers, so as the docker container using /var/run/docker.sock. Can you please tell me, why the test for WSL and droplets is not making sense?


Linux TCP stack not reacting to SYN packet sent from the FPGA board

Hi all,
Has anyone tried to build a connection between the board and the Linux kernel TCP stack?
I'm using the board as TCP client, and the Linux as TCP server. I found the Linux is not reacting to the first SYN packet from the board. The board and the server are connected directly with no switch in between.
I suppose I could debug the TCP headers whatnot, but just want to ask whether anyone has the same experience. Thanks.
Here is the SYN packet from tcpdump. The board is <IP_ADDRESS>. The server is <IP_ADDRESS>.
11:37:33.578934 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto TCP (6), length 48)
    <IP_ADDRESS>.32768 > <IP_ADDRESS>.60000: Flags [S], cksum 0x32ff (correct), seq<PHONE_NUMBER>, win 65535, options [mss 4096,wscale 2,eol], length 0
        0x0000:  0b0a 0908 0706 0605 0403 0201 0800 4500  ..............E.
        0x0010:  0030 0000 0000 4006 f728 c0a8 0108 c0a8  .0....@..(......
        0x0020:  0147 8000 ea60 5623 01b0 0000 0000 7002  .G...`V#......p.
        0x0030:  ffff 32ff 0000 0204 1000 0303 0200       ..2...........

Hi, I want to do TCP iperf benchmarking, is the TCP port number 32768 in this project? Or where to see the TCP port number, if you have any suggestions, appreciated.
I tested with TCP port number 32768, but it shows
connect failed connection refused


`GLIBC_2.32' not found error during installation of apibara indexer

Describe the bug
Getting the following error when trying to install apibara indexer:
root@vmi1205672:~# curl -sL https://install.apibara.com | bash
apibara-installer: installing Apibara CLI to /root/.local/share/apibara
apibara-installer: installing CLI version 0.1.0 for x86_64-linux
apibara-installer: checking installation
/root/.local/share/apibara/bin/apibara: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /root/.local/share/apibara/bin/apibara)
/root/.local/share/apibara/bin/apibara: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /root/.local/share/apibara/bin/apibara)
/root/.local/share/apibara/bin/apibara: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /root/.local/share/apibara/bin/apibara)
apibara-installer: command failed: /root/.local/share/apibara/bin/apibara --version

To Reproduce Steps to reproduce the behavior.
execute the command curl -sL https://install.apibara.com | bash on a ubuntu with`GLIBC_2.31'
Expected behavior A clear and concise description of what you expected to
indexer should be installed
Software (please complete the following information):
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31

Thank you for reporting

Looks like an issue with the interpreter. I will look into it, at the moment it's tested on ubuntu 22.04.

I checked and the issue is that we link against a recent version of glibc (2.37), but ubuntu 20.04 has glibc 2.31. I will see if it's possible to link an older version of glibc.


try/catch having a finally block in an async function generates invalid code

The following method:
public static async Task<string> bug_in_try_catch_finnaly_with_async()
{
    try
    {
        //await to force state-machine generation
        await Task.Delay(1);

        //raise exception
        int j = 1;
        j = j / 0;

        return "OK";
    }
    catch (Exception oException)
    {
        return "ERROR";
    }
    finally
    {
        //may be empty
    }
}

generates
...
case 3: {
    $returnValue = "ERROR";
$step = 4;
    continue;$async_e = null;
$step = 4;
    continue;
}
...

what causes exception not being cleared (continue is executed first)

Deck sample:
public class Program
{
    public async static void Main(string[] args)
    {
        var s = await TestMethod();

        Console.WriteLine(s);
    }

    public static async Task<string> TestMethod()
    {
        try
        {
            //await to force state-machine generation
            await Task.Delay(1);

            //raise exception
            int j = 1;
            j = j / 0;

            return "OK";
        }
        catch (Exception)
        {
            return "Caught exception";
        }
        finally
        {
            //may be empty
        }
    }
}


IOS does not render bold/italic fonts correct

issue only exists on IOS (chrome and safari)
android and desktop (chrome and safari) are oke
Link to PDF file (or attach file here):
https://www.dropbox.com/s/zbfswrqjgelzgni/PAGE-122715.pdf?dl=0
Configuration:

Web browser and its version: Safari and Chrome
Operating system and its version: IOS 10.3.1
PDF.js version: 1.8.254
Is an extension:

Steps to reproduce the problem:

open the pdf in IOS (chrome or safari)
The title 'op met vergelijken' is not correctly displayed (it is correct on desktop chrome/safari)

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

I investigated a bit further and the issue is only there on IOS 10.3 and not on IOS 10.2

PS: @yurydelendik, it is not safari-specific, I also have the issue on chrome

The issue is solved in the ios 11 beta version.
Probably related to this bug: https://forums.developer.apple.com/thread/74980


m/g/1 and lotka-voltera implementations

Dear SBI,
I did a search for the words in my title along with the term "benchmarks," but didn't see anything. Therefore, I ask, is there an "accepted" implementation m/g/1 and lotka-voltera around someplace? I checked hypothesis and lfi. lfi had one but was very non-portable.
Thank you!
Ben

I think I found a good answer.
https://github.com/gpapamak/snl

I think I found a good answer.
https://github.com/gpapamak/snl

The Lotka-Volterra model and other benchmarking tasks are also part of sbibm, which was just released publicly:
https://github.com/sbi-benchmark/sbibm

The Lotka-Volterra model and other benchmarking tasks are also part of sbibm, which was just released publicly:
https://github.com/sbi-benchmark/sbibm


[#1767] feat(netty): The client-side supports choosing Netty's ByteBufAllocator

What changes were proposed in this pull request?
The client-side supports choosing Netty's ByteBufAllocator.
Why are the changes needed?
For https://github.com/apache/incubator-uniffle/issues/1767.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests.

@zuston @jerqi PTAL. Just add an option. No user-facing changes.


Support notifications of new versions for full nodes/validators

Currently, notifying operators of full nodes and/or validators of a new release is an offline process.
It would be helpful for a full node and/or validator to be able to learn about potential new releases during the DiemNet handshake and perhaps via a JSON-RPC query as well.
There could be a metric triggered that an upgrade is available and/or log line printed to notify the operator.

Could do something like an OS, where when you startup the process, it says you've got a new update and you should upgrade.  Notifying operators would require us to do one of two things though:

Have a periodic centralized place to check e.g. a github repo
Push this information through the onchain information (which would then need to say what's the "current" version)

Though, it may not be straightforward for operators to get this information unless they're paying attention to the logs / metrics and they could fall behind significantly.  Might want to look into other ways to notify public full node owners, like their running full nodes email themselves or something similar.

Could do something like an OS, where when you startup the process, it says you've got a new update and you should upgrade. Notifying operators would require us to do one of two things though:

Have a periodic centralized place to check e.g. a github repo
Push this information through the onchain information (which would then need to say what's the "current" version)

A message during startup is useful idea that we could do in addition to online notification (long running full nodes).
on-chain has some pros/cons - for instance, it would require a txn to upgrade it rather than automatically on validator node upgrades.  On the other hand, full nodes who aren't directly connected to the VFNs would learn about the upgrade as well.  Also, putting out the call to upgrade on-chain has another nice property that the notice is open, dated, and irrefutable. =)  Long term, I think this would be the right path for notifications.
Email or other notification would be cool, but setting that up would require an specify SMTP, username, password.  Let's see if anyone would be interested. =)


JS: How to convert a negative big decimal (Uint32Array(4)) to String?

https://github.com/apache/arrow/blob/d54425de19b7dbb2764a40355d76d1c785cf64ec/js/src/util/bn.ts#L99
This function does not handle negative cases If I understand correctly!

Can you open a JIRA issue if you can provide a reproduction of the problem?

It is obvious to find that the function does not return "-" minus sign in any case. But I'll try to reproduce it and create a JIRA. Thanks!

https://issues.apache.org/jira/browse/ARROW-6627


Configuration: Free up space

Details

[ ] Delete all files in the Desktop except Recycle Bin, Tools and fakenet_logs.
[ ] Execute as admin in cmd del /q /S %TEMP% && rmdir /S /Q "%TEMP%\chocolatey" "%LOCALAPPDATA%\NuGet\cache" "%PROGRAMDATA%\Package Cache"
[ ] Run Disk-Cleanup (select all)
[ ] Execute as admin in cmd sdelete -z C:

Ideally we add this to a helper in common so that it can be run after installing extra packages

I've added these commands into separate functions inside of common.vm (as per how I interpreted your 2nd comment). We can create a singular function that incorporates all of them if desired. I left it this way until we decide the best route to take.
See the PR in VM-Packages: https://github.com/mandiant/VM-Packages/pull/747


Add Deno example

I just think Deno's neat :)
Works as intended, as of version 1.22.2.

Deno is indeed cool, but I'm not ready to officially document support for it yet.