[DOCFIX] Fix a issue in secure HDFS doc.

Kerberos configurations should be system properties, not in Alluxio site-properties.

@apc999

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11115/
Test PASSed.

Put a few comments. Thanks for the fix.

@apc999 @calvinjia thanks for the review. I've addressed your comments. PTAL

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11117/Build result: FAILURE[...truncated 630 lines...][JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/local/target/alluxio-underfs-local-1.3.0-SNAPSHOT.jar to org.alluxio/alluxio-underfs-local/1.3.0-SNAPSHOT/alluxio-underfs-local-1.3.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/local/target/alluxio-underfs-local-1.3.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-underfs-local/1.3.0-SNAPSHOT/alluxio-underfs-local-1.3.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/server/pom.xml to org.alluxio/alluxio-keyvalue-server/1.3.0-SNAPSHOT/alluxio-keyvalue-server-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/gcs/pom.xml to org.alluxio/alluxio-underfs-gcs/1.3.0-SNAPSHOT/alluxio-underfs-gcs-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/pom.xml to org.alluxio/alluxio-core-common/1.3.0-SNAPSHOT/alluxio-core-common-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.3.0-SNAPSHOT.jar to org.alluxio/alluxio-core-common/1.3.0-SNAPSHOT/alluxio-core-common-1.3.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.3.0-SNAPSHOT-sources.jar to org.alluxio/alluxio-core-common/1.3.0-SNAPSHOT/alluxio-core-common-1.3.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/common/target/alluxio-core-common-1.3.0-SNAPSHOT-tests.jar to org.alluxio/alluxio-core-common/1.3.0-SNAPSHOT/alluxio-core-common-1.3.0-SNAPSHOT-tests.jar[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/s3/pom.xml to org.alluxio/alluxio-underfs-s3/1.3.0-SNAPSHOT/alluxio-underfs-s3-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/assembly/pom.xml to org.alluxio/alluxio-assemblies/1.3.0-SNAPSHOT/alluxio-assemblies-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/shell/pom.xml to org.alluxio/alluxio-shell/1.3.0-SNAPSHOT/alluxio-shell-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/oss/pom.xml to org.alluxio/alluxio-underfs-oss/1.3.0-SNAPSHOT/alluxio-underfs-oss-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/client/pom.xml to org.alluxio/alluxio-keyvalue-client/1.3.0-SNAPSHOT/alluxio-keyvalue-client-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/hdfs/pom.xml to org.alluxio/alluxio-underfs-hdfs/1.3.0-SNAPSHOT/alluxio-underfs-hdfs-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/swift/pom.xml to org.alluxio/alluxio-underfs-swift/1.3.0-SNAPSHOT/alluxio-underfs-swift-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/s3a/pom.xml to org.alluxio/alluxio-underfs-s3a/1.3.0-SNAPSHOT/alluxio-underfs-s3a-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/examples/pom.xml to org.alluxio/alluxio-examples/1.3.0-SNAPSHOT/alluxio-examples-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/core/server/pom.xml to org.alluxio/alluxio-core-server/1.3.0-SNAPSHOT/alluxio-core-server-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/common/pom.xml to org.alluxio/alluxio-keyvalue-common/1.3.0-SNAPSHOT/alluxio-keyvalue-common-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/pom.xml to org.alluxio/alluxio-underfs/1.3.0-SNAPSHOT/alluxio-underfs-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/underfs/glusterfs/pom.xml to org.alluxio/alluxio-underfs-glusterfs/1.3.0-SNAPSHOT/alluxio-underfs-glusterfs-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/integration/pom.xml to org.alluxio/alluxio-integration/1.3.0-SNAPSHOT/alluxio-integration-1.3.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Alluxio-Pull-Request-Builder/keyvalue/pom.xml to org.alluxio/alluxio-keyvalue/1.3.0-SNAPSHOT/alluxio-keyvalue-1.3.0-SNAPSHOT.pomchannel stopped
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11116/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11120/
Test PASSed.

LGTM

LGTM

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11139/
Test PASSed.

Merged build finished. Test PASSed.


No need to support strong class inheritance checks here

JS class inheritance is based on prototype inheritance. There is no way to guarantee that an object-o created from class-C has the features of the parent class. and vice versa, there is no guarantee that any object-o2 does not have the featuresof class-C. So why add a strong and official type checking method to class declaration?
Try next case:
class C {
  #x
  isC(o) {
    return true; // or other way: `#x in o`
  }
  aMethod() {
    // do somethig
  }
}

x = new C;
Object.setPrototypeOf(x, null)
x.isC = C.prototype.isC;

// I try a hard class brand check, say `yes`
x.isC(x); // true

// crash!
x.aMethod(); //  x is duck-type instance.

So, Does strong/hard class brank check have any meaning?

I'm afraid you are a bit mistake. JS is full of these kinds of checks - every single builtin (except Error) has methods that check for the presence of "internal slots" and throw when they are missing, and user code that extends these builtins can participate in this branching. User code can already ensure this with use of private fields, or with a Weak collection in a closure. Thus, there already is, and has been since JS's inception, the ability to guarantee that an object passed through the appropriate constructor code. This proposal is merely about a more ergonomic way to perform these pre-existing checks.
In your example, you're looking up aMethod on x, after the [[Prototype]] has been modified, so certainly you're not getting the method you expect. However, if you do C.prototype.aMethod.call(x) (as code that cares about being robust often does, which admittedly is not a common practice overall), then it will continue to work as expected. Additionally, if a static method is doing the slot/field lookup, then this issue wouldn't occur.

I'm afraid you are a bit mistake. JS is full of these kinds of checks - every single builtin (except Error) has methods that check for the presence of "internal slots" and throw when they are missing, and user code that extends these builtins can participate in this branching. User code can already ensure this with use of private fields, or with a Weak collection in a closure. Thus, there already is, and has been since JS's inception, the ability to guarantee that an object passed through the appropriate constructor code. This proposal is merely about a more ergonomic way to perform these pre-existing checks.
In your example, you're looking up aMethod on x, after the [[Prototype]] has been modified, so certainly you're not getting the method you expect. However, if you do C.prototype.aMethod.call(x) (as code that cares about being robust often does, which admittedly is not a common practice overall), then it will continue to work as expected. Additionally, if a static method is doing the slot/field lookup, then this issue wouldn't occur.

The type dependency, or type detection dependency is undesirable. For example, how to determine that a function is a constructor and use new operation further?
// How to ensure that f() is always safe?
if (IsConstructor(f)) then
  new f
fi

so, I support annotations/decorators and static syntax checking. It is a credible method and always puts security in the hands of the developers of the application or library.

The type dependency, or type detection dependency is undesirable. For example, how to determine that a function is a constructor and use new operation further?
// How to ensure that f() is always safe?
if (IsConstructor(f)) then
  new f
fi

so, I support annotations/decorators and static syntax checking. It is a credible method and always puts security in the hands of the developers of the application or library.

I greatly desire runtime detection, and prefer not to rely on build-time detections. Let’s not debate the credibility of type systems or static checking here, as these are irrelevant to the JS spec.
you’re right that there’s no convenient IsConstructor check (you’d have to check it with Proxy, and even then a constructor could still throw) but that doesn’t lessen the value of the majority of things that are robustly checkable at runtime.
Thanks for your feedback!

I greatly desire runtime detection, and prefer not to rely on build-time detections. Let’s not debate the credibility of type systems or static checking here, as these are irrelevant to the JS spec.
you’re right that there’s no convenient IsConstructor check (you’d have to check it with Proxy, and even then a constructor could still throw) but that doesn’t lessen the value of the majority of things that are robustly checkable at runtime.
Thanks for your feedback!


Convert to xproj and support for TFM netstandard

Converted and cleaned up the structure (to a more common structure) and switched project to xproj and dotnet to be able to do crosscompile for .net core.
Target Framework Monikers is net45 and netstandard1.1 to be used inside .net core application, build with AutoMapper 4.2.1.
Added build script (windows) in the root that will create nuget packages in an artifacts-folder.
Added new package "AutoMapper.Collection-Signed" that use the code from AutoMapper.Collection and creating a signed output.
For each new release, the version number need to be updated in all project.json, if doing a pre-release package the DOTNET_BUILD_VERSION environment variable to the prerelease name.

I'll have to look into this.  I'm kinda familiar with the building of xproj, but not THAT familiar.

I've set this to be the version 2.0.0 for when I build it.  I want to hold off on pushing it to nuget for now until AutoMapper 5.0.0-beta2 or greater comes out.  I have a PR that will increase performance but there's currently not a nuget package that will work with it right now.


improve use pdqsort to improve percentile_approx function performance

Proposed changes
could faster about 1s on table rows of count 150000000

run buildall

run buildall

run buildall

run buildall

run buildall


Don't measure the construction of the NSPredicate in testQueryConstruction

The parsing of the NSPredicate was moved into the benchmark loop by 2a2ae542d531a4fe6da132e8dbfdb22710989d7f, but it doesn't belong there.
This should fix #2978.

:+1: wow, that's my bad. Thanks for investigating and fixing.


Source for Snippets

Do you know what the source is for snippets with the Markdown package? The .source.gfm does not work. Thanks! -@chris-prener

.text.md should do the trick
On Sat, 4 Feb 2017 at 04:12, Christopher Prener<EMAIL_ADDRESS>wrote:

Do you know what the source is for snippets with the Markdown package? The
.source.gfm does not work. Thanks! -@chris-prener
https://github.com/chris-prener
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/burodepeper/language-markdown/issues/162, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADiC6tCb-Nwlyq7FEq3qStndUW_Cfg2sks5rY-yTgaJpZM4L3BSD
.

perfect, had tried .source.md with no luck. Thanks! Great package.


Newly recorded health data from HealthKit doesn't show up if App is in foreground.

Is your feature request related to a problem? Please describe.
I would like to take health data samples that have been recorded not longer than 10-15 minutes (essentially fresh data). Whenever I try to get the health data using some of the specified library methods like getHeartRateSamples and getElectrocardiogramSamples and I encounter stale data, I prompt the users to take new health readings, after taking the new health readings with their watch which gets stored in HealthKit, it doesn't appear when the library methods are called again with the app in foreground. The app has to be closed and relaunched for the newly recorded samples to appear.
Describe the solution you'd like
I would like the methods to have direct access to the live Healthkit data during the active lifecycle of the app if possible.
Describe alternatives you've considered
I have tried setting up background observers, but it is only supported for one (HeartRate) out of the health data samples I'm looking to take.
I also tried setting up background observers for the HeartRate samples following the steps in the documentation, but I face the same issue mentioned in https://github.com/agencyenterprise/react-native-health/issues/188 and https://github.com/agencyenterprise/react-native-health/issues/185
I have also tried re-initializing the library just before querying for the samples in hopes that the most recent data appears. That doesn't work as well.

Hey, please try enabling the background observers again, we just updated the instruction on the docs.
new NativeEventEmitter(NativeModules.AppleHealthKit).addListener(
      'healthKit:HeartRate:new',
      async () => {
        console.log('--> observer triggered');
      },
    );

I hope this helps :)


nuspell: 4.0.1 -> 4.2.0

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/291

Updated to 4.2.0. Boost is not needed anymore

/marvin opt-in
/status needs_reviewer

Result of nixpkgs-review pr 104291 1

1 package built:

nuspell

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/300

Result of nixpkgs-review pr 104291 run on x86_64-linux 1

1 package built:

nuspell

Thanks!


Extend file permission propagation modes

I'm using mutagen to sync from windows to Linux, and I wish created files/directories to be 666/777 instead of 600/700. Would you consider adding this feature ?

I think that sounds like a reasonable idea.  Perhaps configuration parameters like the following:
[permissions]
POSIXDefaultDirectoryPermissions = 0XXX
POSIXDefaultFilePermissions = 0XXX

I'd like to think about this for a little bit.  In particular, I want to think about whether or not there are similar options that would make sense on Windows (without users having to specify DACLs).  I'm not against having this feature apply only to POSIX.
In the mean time, you can manually set ownership/permissions on the clone with chown -R and chmod -R and Mutagen will preserve them when updating files.

@havoc-io you asked me to raise an issue regarding permissions on the docker-sync project. I think this issue covers my scenario exactly :)
So a BIG +1 to this!

@matthew-gill Cool, glad that's the case.  I plan to come back to working on Mutagen full time for at least a month on 1 November, so I'll be sure to prioritize this additional permission flexibility.

@matthew-gill Regarding the specific issue that you mentioned here, you could potentially meet your needs for the time being by synchronizing inside the container as www-data, e.g. using a Mutagen URL like docker://www-data@container/var/www/projectname or similar.
Or you could make www-data the default container user with the USER directive in your Dockerfile, but that has other implications so I'd recommend the URL option first.

@havoc-io that was where I got stuck last time, admittedly I should've created an issue at that time but I'll create one now: #46
In a nutshell, I get Error: create failed: unable to connect to beta: unable to connect to endpoint: unable to install agent: unable to invoke agent installation: exit status 1

@matthew-gill Thanks for opening that one.  I suspect that there's a shared underlying cause for a lot of the Docker issues, probably something minor, but probably something that will require a lot of testing to fully suss out.

I've just published v0.8.0-beta1, which includes some extended permission specification options.
Documentation is still pending (should be done tomorrow), but I wanted to get this out for you to try.  Please note the beta1 tag on the release.
The quick summary is that you can now specify file mode, directory mode, file owner, and file group.  This can be done via the create flags:
--default-file-mode
--default-file-mode-alpha
--default-file-mode-beta

--default-directory-mode
--default-directory-mode-alpha
--default-directory-mode-beta

--default-owner
--default-owner-alpha
--default-owner-beta

--default-group
--default-group-alpha
--default-group-beta

The endpoint-specific flags (i.e. those with -alpha and -beta) override the more general flags.  The non-endpoint-specific values can also be specified in mutagen.toml, e.g.:
[permissions]
defaultFileMode = 0644
defaultDirectoryMode = 0755
defaultOwner = "name"
defaultGroup = "group"

File and directory modes are specified in octal format (the 0 prefix is optional), e.g. 0644 or 750.  They default to 0600 for files and 0700 for directories.  They are also restricted by the umask on the endpoint.  File modes should not include executability bits since these are managed by Mutagen.
Owner and group specifications can be provided in four different formats:

POSIX-ID-based: A string of the form id:N, where N is a number representing the user or group ID.  This is only supported for POSIX endpoints.
Windows-SID-based: A string of the form sid:XXXXXXXXXX where XXXXXXXXXX is some valid Windows SID (the formats are highly variable).  This is only supported for Windows endpoints.
Name: A non-empty string that does not adhere to one of the above formats is treated as a literal user or group name.  This is supported on both POSIX and Windows endpoints.

Empty ownership specifications specify that the default ownership should be used for the file (whatever that happens to be on the endpoint).
Please note that on POSIX systems you'll need superuser privileges to set ownership to a user besides yourself, or to set a group to which you do not belong.  Windows is even more restrictive (see below).
Also worth noting is that file permissions (other than executability) are no longer preserved - they are always set to the given permissions.  More information about this below...
Windows endpoints have a few caveats:

Setting file ownership to a group or another user requires the SeRestorePrivilege, which has to be granted by a system administrator and then requires that the requesting process activate that privilege.  Mutagen doesn't do this at the moment because having the SeRestorePrivilege gives a process write access to an entire system (including system files) and I'd be uncomfortable with implementing this until Mutagen implements more aggressive sandboxing for local endpoints.
Setting group ownership on Windows is sort of useless.  I don't think this information is even visible from the Win32 subsystem - it's a Windows POSIX relic.
Right now the file and directory modes on Windows are processed as outlined in the Go os.Chmod function. This will improve over time, but it's not a natural fit for Windows.

So, looking forward, there are two additional parameters I can imagine adding, but both need some discussion:
The first parameter would be --permission-mode.  At the moment, there is an implicit permission propagation mode which I call portable.  This is the current default mode where only POSIX executability information is propagated/preserved.  Looking forward, I could imagine posix-raw and perhaps even windows-raw modes that would only work for POSIX-to-POSIX and Windows-to-Windows synchronization sessions, akin to the posix-raw value for --symlink-mode.  Adding these "raw" modes is probably significantly farther down the road.  There are a number of design questions that would need to be considered, including:

Which permissions are transferred?  Base permissions?  Ownership?  Setuid/setgid bits?  Sticky bits?  Full Windows DACLs?  SACLs?
How is user-mapping performed?  On a name basis?  An ID basis?  A SID basis?
How are permissions reconciled along with content?  You might not want a setuid bit to propagate to a file on the remote where it could be a security risk.

The second parameter, which could come sooner, is --preservation-mode.  In v0.8.0, permission preservation has been removed.  Implementing this correctly is difficult because true permission preservation requires either superuser permissions or non-atomic operations.  The two main questions blocking this mode are:

Which permissions are preserved?  The security implications are the same as above, especially for setuid and setgid bits.
Do we require superuser privileges to maintain permissions exactly?  If not, do we want to have a preserve-non-atomic mode that allows for non-superuser preservation (via truncate/write operations)?

Anyway, I want to let these new settings go through a bit of a shakedown before I start expanding the model much further, but there is room for expansion.  I'll leave this issue open until I've tagged v0.8.0, so please have a look and provide feedback.

Initial (and reasonably complete) support for this has now shipped in v0.8.0.  Please don't hesitate to continue the discussion (either here or in another issue) if the new permission settings are inadequate for your workflow.

So as far as understand there is no option to preserve permissions, but rather only an option to override all files with the same permissions and the same fo folders?

@achekulaev There's not an explicit option, but Mutagen's default behavior (in the absence of any permission settings) is fairly close to preservation.  Mutagen won't touch the permissions for anything that it doesn't update, it will only use the specified permission settings (ownership and mode (subject to umask)) for folders that it creates and the files that it creates and/or updates.  Also, if no ownership is specified, then the default ownership (based on the user) is used.  POSIX executability bits are preserved in all cases.
In short, I think the only cases that would be troublesome are those where you're synchronizing files and then manually setting their permissions to be different (e.g. more or less restrictive) or changing the ownership from the defaults that Mutagen is using.  Or if you're manually enabling setuid or setgid bits.  Mutagen may support these in the future with more "raw" permission propagation modes.
Permission preservation (if you mean true, exact permission preservation) requires either superuser privileges (to be able to set ownership and permissions arbitrarily) or non-atomic updates (i.e. rewriting a file in-place).
If there's a problematic case you're running up against, it would be useful to get a quick summary.  It might inform the design of future permission propagation and preservation modes.

Mutagen's default behavior (in the absence of any permission settings) is fairly close to preservation

Frankly speaking I did not find it even remotely close to the preservation, hence the question. For instance here is a result of mutagen create /source/ /destination/ command (there wasn't any default configuration I created, I literally just installed mutagen on Alpine, started daemon and ran create)
08eeaf0258a6:/# ls -la /source/
total 16
drwxr-xr-x   13 502      dialout        416 May  3 02:13 .
drwxr-xr-x    1 root     root          4096 May  3 02:11 ..
drwxr-xr-x    3 502      dialout         96 Jun  6  2018 .circleci
drwxr-xr-x    7 502      dialout        224 May  3 02:09 .docksal
drwxr-xr-x   14 502      dialout        448 Jun  7  2018 .git
-rw-r--r--    1 502      dialout        108 Jun  6  2018 .gitignore
-rw-r--r--    1 502      dialout        184 Jun  6  2018 .travis.yml
drwxr-xr-x    3 502      dialout         96 May  2 20:14 123
drwxr-xr-x    2 502      dialout         64 May  2 20:14 321
-rw-r--r--    1 502      dialout       2254 Jun  6  2018 README.md
drwxr-xr-x    3 502      dialout         96 Jun  6  2018 config
drwxr-xr-x   25 502      dialout        800 Jun  6  2018 docroot
drwxr-xr-x    3 502      dialout         96 Jun  6  2018 drush

08eeaf0258a6:/# ls -la /destination/
total 52
drwxr-xr-x   10 502      dialout       4096 May  3 02:13 .
drwxr-xr-x    1 root     root          4096 May  3 02:11 ..
drwx------    2 root     root          4096 May  3 02:13 .circleci
drwx------    4 root     root          4096 May  3 02:13 .docksal
drwx------    8 root     root          4096 May  3 02:13 .git
-rw-------    1 root     root           108 May  3 02:13 .gitignore
-rw-------    1 root     root           184 May  3 02:13 .travis.yml
drwx------    2 root     root          4096 May  3 02:13 123
drwx------    2 root     root          4096 May  3 02:13 321
-rw-------    1 root     root          2254 May  3 02:13 README.md
drwx------    3 root     root          4096 May  3 02:13 config
drwx------    8 root     root          4096 May  3 02:13 docroot
drwx------    2 root     root          4096 May  3 02:13 drush

As you see group and other permissions are completely different. Mutagen and bash session is running as root.
So I just wanted to double check if this is expected or something went not as you would expect?

Just to clarify terminology here (since I'm differing slightly from the common vernacular): When I say "preservation," I'm referring to the preservation of permissions for existing files when updating them during synchronization.  When I say "propagation," I'm referring to propagating permissions from one endpoint to another when creating copies of content during synchronization, which I think is what you're referring to as "preservation."
Propagating raw permissions from one endpoint to another is, in general, a security risk.  For example, I wouldn't want to propagate group-readable or other-readable permissions from my laptop to a multi-user remote system, especially since the user I'm operating under on the remote system will have a default group which may have other users as members.  Mutagen doesn't have the contextual information necessary to determine which permissions are safe to propagate, and thus it uses a user-restricted set of permissions by default for propagated content.  These defaults are resulting in the permissions that you're seeing.
Mutagen will allow you to set different permissions for propagated files, but it requires them to be set explicitly since only you're in a position to know the security implications.  In this case, if you want to propagate group-readable and other-readable permissions to the remote, you can use the following flags:
--default-file-mode=0644
--default-directory-mode=0755

You can also specify these on a per-endpoint basis with the -alpha and -beta suffixed flags.  For files, Mutagen will handle propagating POSIX executability bits (which is why they're excluded from the --default-file-mode value), enabling them for any entity (user, group, or other) which has a corresponding read bit set (similar to rsync).
In general, systems also have different sets of users and groups, with differing IDs, so propagating ownership and group information is ill-defined, and picking implicit heuristics by which to perform the mapping (for example by name or by ID) is also a security risk.  This is the main reason why Mutagen doesn't propagate ownership and group information by default (in addition to the fact that a superuser is required to set ownership and group information).  However, if you want to set user and group information on the remote, and you have the superuser permissions to do so, you can use the --default-owner or --default-group (or the endpoint-specific variants of these flags) to specify ownership by ID (or SID on Windows) or name.
I hope that clarifies the reasoning a bit.  Essentially the design comes down to what makes sense for development work but with security-oriented defaults.  In your case, you could get a more accurate permission propagation with:
mutagen create --default-file-mode-beta=0644 --default-directory-mode-beta=0755 --default-owner-beta=id:502 --default-group-beta=dialout /source /destination

You could also imagine parameterizing this by shelling out to id, for example --default-owner-beta=id:$(id -u), but it's really dependent on your use case.

Ok sorry I don't follow. Let's say I have
drwxr-xr-x    source/
-rw-rw-rw-      readme.txt
-r-xr-xr-x      executeme.sh
drwx------      private/
-rw-------          id.dsa

What parameters do I need to pass to mutagen create to propagate all permissions as is, if it is possible?

In that case it wouldn't be possible to propagate the permissions precisely as-is.  Mutagen's permission propagation facilities unfortunately don't currently accommodate mixed levels of "privacy" for created files.  The safest option in this case would be to leave the default user-restricted permissions in-place to avoid id_rsa and other private data from becoming visible to the user's group and others on the machine.  Another option would be to --ignore the private directory from synchronization, use more generally accessible base permission (e.g. 0644/0755), and then manually propagate the more restricted files.  A third option would be to create two sessions with different permission modes - one for the public files and one for the private files.
One way Mutagen could potentially solve this would be default permission overrides for specific paths.  Or perhaps implementing the "raw" permission propagation described above, though this is probably (at least) several months away.

To clarify the design choice here, it's really about opting for explicitness over implicitness in favor of security.  Propagating raw permissions as-is has more safety risks than benefits in my opinion, especially since Mutagen's default permission level for files is user-only.

Thanks for your answers. Will be looking for that ability of "raw" permissions propagation whenever it comes.
Just FYI unison does propagate raw permissions. So if I have drwxr-x-r-x and perform chmod 0600 then it becomes drw------- and unison will transfer that change as is.

Just FYI unison does propagate raw permissions. So if I have drwxr-x-r-x and perform chmod 0600 then it becomes drw------- and unison will transfer that change as-is.

I'm aware of Unison's behavior.  It's not a question of technical feasibility, it's just a question of design.  If you accidentally do chmod -R g+r ~/.ssh (or something equivalent, say when trying to restore permissions on your home directory), Unison will also happily propagate that change, which isn't too damaging locally, but could be a problem on a remote multi-user system (say a cluster with 100 users all under the same group).  Unison isn't without its design choices either.  If you do chmod ug+s <executable>, Unison won't transfer the setuid and setgid bits.  It draws the security line a bit later than Mutagen does (and I feel loses some granularity of control in the process), but it still doesn't transfer everything.

Thanks for your answers. Will be looking for that ability of "raw" permissions propagation whenever it comes (I understand it might take time).

This is also probably more of a question of design than implementation time, so feedback is welcome here.  One needs to answer at least the following questions:

Does the permission propagation transfer owner/group information in addition to mode?   If so, is ownership matched by ID or name (or both)?  Unison makes the user decide via its numericids flag, but it has a default that may also not be safe (matching by name).
Do we restrict the users and groups for which we propagate ownership?  Unison, for example, won't propagate root ownership.
What happens in the case where a matching user or group can't be found?
If transferring ownership, do we limit the ability to propagate permissions to superusers?  If not, what do we do in the event that the user doesn't have the required permissions to set ownership?
Are setuid and setgid bits also transferred?  What about sticky bits?
Do we transfer POSIX ACLs?
In what order are permissions applied to the file on the remote?  You can't set mode and ownership simultaneously.

My opinion is that these questions are impossible to answer decisively in the general case, and many of these behaviors are dangerous to choose implicitly.  I think that the behavior is going to need to be highly parameterizable, and those parameters may form an insanely large phase space that's difficult to test and difficult to grok for users (especially in the case of more esoteric options).
Also, just in general, I would avoid propagating sensitive data (such as private keys) with any synchronization tool.  There are distribution systems for secret and sensitive data that would be a better fit for that (perhaps in combination with a synchronization tool for code).

It was never intention to argue in any way, it just seems that 90% of users (or maybe more) have never used the sticky bit, while the same 90% of users had to perform chmod at some point of their development lives because of the CMS or tools requirements or other development needs. So a choice to transfer those permissions seems more developer-oriented to me, and being development-focused is described as the one of the main purposes of the Mutagen tool (which is why it drew my attention) and that is why I figured that as a developer I would provide a feedback.

One needs to answer at least the following questions

I agree that it opens a can of worms. If you ask me, I find unison's answer to those questions adequate >90% of the time. In my humble opinion ideal developer-focused sync tool would build on the same principles while further extending them, and functionality and speed.

It was never intention to argue in any way, it just seems that 90% of users (or maybe more) have never used the sticky bit, while the same 90% of users had to perform chmod at some point of their development lives because of the CMS or tools requirements or other development needs.

No worries, it wasn't perceived that way, it's all constructive discussion.  I do agree that these more esoteric features probably won't enter into the eventual design, but I'm sort of curious about the exact scenarios that you're looking at.  My feeling is that (within a Git working tree) the chmod command is essentially useless for anything other than chmod +x when it comes to code since Git will only set 0755 and 0644 permission modes (obliterating any other accessibility restrictions).  It seems like the majority use case for code synchronization is repository working trees (or some subdirectory thereof), so that's why Mutagen only bothers with propagating executability bits.  If you're working with another use case, I'd be interested to hear more.
In any case, a 90% solution is certainly a reasonable one.  I had sort of hoped that the basic permission settings + POSIX executability propagation would be the 90% case (and it seems like it largely has been), but perhaps we could say that "raw" permission propagation would be the 90% case of that remaining 10%.
Also, I think it's probably safe to choose some implicit propagation heuristics, especially if they're not the default.  My answers to the above questions (targeting that 90% use case) would be something like:

Propagate standard mode bits
Require explicit specification of an owner/group matching mode (say one of id, name, both, or none (meaning don't propagate and just use the default)).

If a match can't be found, just mark the file as a problem and don't transfer it
If the user doesn't have the necessary permissions to set owner/group information, just mark the file as a problem and don't transfer it

Don't restrict the owners or groups for which we propagate permissions
Don't propagate setuid or setgid bits
Don't propagate sticky bits
Don't propagate ACLs
Apply ownership and then permissions

I feel like the documentation would have to be expanded to be very clear about the implications of this mode, especially the fact that group-readable on your laptop is possibly not something you want to be propagating over to a remote.  An example where this will almost certainly come up is Git repositories in combination with multi-user remote systems.  As I mentioned above, Git's default working tree permissions are group/other-readable, which is fine on your local laptop, but if you synchronize code to a multi-user remote, everybody's going to be able to read it.
Even with those answers in mind, there's still the question of conflicts.  For example, if a file's contents are changed on one endpoint and its permissions are changed on the other, should Mutagen mark a conflict?  I'd opt for a "yes" in order to avoid leaking sensitive data.
Finally, there are some questions with the actual implementation, but I think they're all something with a straightforward answer.  In any case, this will probably have to wait a few months.
If you have any additional thoughts about how you think this ought to look, feel free to drop them here or in another issue.  More feedback and discussion is really going to help Mutagen address this better.

@havoc-io reasonable explanation about the x bit and it's true that it covers a lot. I guess mostly what I wanted is to avoid having x on files that don't need it, while at the same time having it on files that do need it (i.e. files that had it in alpha). So executeme.sh should have it, while readme.txt should not. As far as I understand in the current approach I can only set mask for all files. It is not the end of the world, but will get in the way in some of our scenarios.
I am struggling to come up with a common scenario when I would need to override permissions apart from x, but basically it is those rare but regular cases when something got created with improper permissions on the server side, missing w for g+o for instance, and I would not be able to override it from my side.

As far as I understand in the current approach I can only set mask for all files.

@achekulaev That's not the case - POSIX executability bits (the x bits) are the one type of permission that Mutagen does track and propagate (since they're essential for development work).  This is why, when specifying --default-file-mode, Mutagen won't allow you to specify executable bits (i.e. any of the bits in 0111) as part of that value, because it manages those bits as part of synchronization.1 I think maybe that's the part of this that's not clear.
The way Mutagen's executability propagation works is similar to rsync's mechanism, specifically:

A file is considered executable if any executable bit is set
When setting executability for a file, executable bits are set for any entities with a corresponding read bit set

So the --default-file-mode basically just sets the default accessibility permissions (i.e. read/write) on top of which executability bits are synchronized.
It might also help to think of Mutagen's behavior in terms of how Git works.  In Git, a file is tracked as executable (in which case it's added to the index and tree objects with mode 0755) or non-executable (in which case the mode is 0644).  The difference with Mutagen is that you can set that base mode (e.g. if you specify --default-file-mode=0640, then Mutagen's set the permissions for executable files to 0750).
Moreover, Mutagen tracks POSIX executability bits even when synchronizing with a Windows endpoint (it even has a special algorithm for doing this since Windows can't store executability bits), meaning you can edit a POSIX-executable file from Windows without obliterating the executable bits on the POSIX side.
Does that clarify things?  I'm not sure if you've seen it, but another description of the behavior is given here.  The best way to understand the behavior might just be to play with it a bit.  For example, start with the defaults and play with setting and clearing executability (chmod +x, chmod -x) and looking at how that propagates.  Then play with a different --default-file-mode settings.
Let me know if that helps at all.
1 Note though that --default-directory-mode can (and probably should) still include those bits since Mutagen doesn't track/propagate those executability bits for directories since they're almost universally enabled.

That's not the case - POSIX executability bits (the x bits) are the one type of permission that Mutagen does track and propagate

Well as you see from my example above this did not happen. x bit was not propagated properly for group and other permissions.

Well as you see from my example above this did not happen. x bit was not propagated properly for directories for group and other permissions.

Please see what I wrote above about how the executable bit propagation is performed.  It's the same as rsync's behavior in the case that you specify --executability without specifying --perms (have a look at the description of --executability in the rsync man page).  In fact, the best option is just to think of Mutagen's behavior as being the same as rsync --executability ... with the additional feature that you can specify the base read and write permissions for transferred files.  I'm not sure how else to explain it.

I guess more explicitly, you could use the following mental mapping:
mutagen create --default-file-mode-beta=0600 --default-directory-mode-beta=0700 <source> <destination>

is approximately equivalent to:
rsync -r --executability --chmod=Fg=,Fo=,Du=rwx,Dg=,Do= <source> <destination>

It's not an exact mapping, but it should help communicate the idea better.

I don't know how rsync works and I believe the part with "x bit syncs always but now always" should be more clearly explained in the docs.

I don't know how rsync works and I believe the part with "x bit syncs always but not always" should be more clearly explained in the docs.

rsync is a pretty standard and widely used tool, so the docs would probably be best written in terms of its behavior.
But I guess the best one-sentence summary is "x bit syncs if source file has any x bit set, but it only syncs to entities (u/g/o) who have a corresponding r bit set on the destination."  And in this case, the r bit on the destination is controlled by --default-file-mode (or one of its endpoint-specific variants like --default-file-mode-alpha or --default-file-mode-beta).

So far I still don't understand why x bit in my case was not propagated for g+o and what I need to do for it to propagate.

See this comment for a longer explanation, but if you want the x bit to propagate for g+o, you need to set Mutagen's base file permission mode to allow for g+o readability on the destination - i.e. something like --default-file-mode=0644.
To ensure executability bits are set for all directories that Mutagen creates in the process of synchronization (which you almost certainly want), you'd use --default-directory-mode, so to include r+x access for g+o, you'd use something like --default-directory-mode=0755.

@havoc-io got it, thanks.
I fairly believe that should really go into docs.
x bit is only propagating for a permissions set if --default-file-mode has a corresponding r bit included for that permissions set. Default value for --default-file-mode if 0700 so it only includes r for owner permissions set, but not for group and others sets, so x bit for these permissions sets will not propagate by default.

I'll work on adding some expansion/clarification in the documentation updates coming for v0.9.0.

@havoc-io We are trying to propagate using mutagen from Windows to a Docker container and all the executable files that are normally executable in git (and Linux when checked out from git) are not when they hit docker. As we found out, mutagen does not allow to set the file executable bit as part of the default sync mask.
So what solution do we have? For example, in WSL all files are 777 so there's no issue with execution. It's not safe but for development purposes it works if you use Windows.
How can we convince mutagen to set executable bits for shell scripts?

I'd like to make a suggestion: introduce a flag --default-(file|directory)-mode-mask as a (mutually exclusive) alternative to --default-(file|directory)-mode that propagates the original file permissions masked with the given permissions mask. So 0755 and 0777 files both becomes 0755 files with a 0755 mask, but a 0700 stays 0700. Never elevating permissions on propagation feels safer in my opinion.


Avoid decompressing jars/zips in scrooge support

Use scrooge's native support for zip/jar to avoid all the decompression we were doing.
@ianoc please take a look.
We don't actually have tests in the repo that exercise "absolute_path" or the remote_jar which are a features we are using internally. I will try to add tests for that (I'm actually a bit confused about what absolute_path does, but I think it basically chops off a prefix of the path).
Before I merge I want to try to build an internal repo with this change and see if it improves performance. It should, since it avoids a lot of file system operations, and we possibly only decompress files that are actually needed, since it seems scrooge is reasonable smart about that.

so, it looks like this change uncovers a hygiene issue. It passes the test locally, and on travis, but not on bazel CI, where there is sandboxing.

Seems fine to me, obviously need to fix the bug triggering the build failure.
Even if its the ~same speed, it seems much cleaner to me so worth merging

Could you add some flavor on what the issue was with the build hygiene and what the gist of all the new code is? (its a big diff again)

Yeah, let me know how much we should add to the comments:

The build hygiene was that the import happened to be the same relative path to the file on the disk after bazel does it's stuff in bazel-bin. Since scrooge always adds a Importer(".") it would find it from that path by happenstance of how bazel works, but not if there is sandboxing preventing it from seeing it.

The solution is make a new Compiler class, don't reuse thrifts, and have better control of how importing works. Doing this I learned that scrooge's zip/jar support is pretty broken and really only works if all imports are considered relative to some fictional root directory (a style done at Twitter, but not really standard for thrift). With my new Compiler, I could only add the importers I want. I made a new importer which is a zip importer that also knows where it is in the zip file. In this way, it could use a thrift jar that itself has internal relative imports (such as our monster thrift jar at Stripe).

I still have not tested it at Stripe, I am going to try that next.

On an internal aggregate target with a lot of thrifts, this now takes:
(build 1 time, did a clean, timed the second build)
INFO: Elapsed time: 86.657s, Critical Path: 83.56s

real    1m26.787s
user    0m0.073s
sys     0m0.054s

with the old code which does decompression we have:
INFO: Elapsed time: 132.874s, Critical Path: 130.12s

real    2m12.979s
user    0m0.066s
sys     0m0.047s

which is a 65% reduction in elapsed time, so it looks like a fairly good win.

reusing the ZipFile didn't seem to speed anything up, but I guess is a bit friendlier on the GC, so we can keep it.
My guess is that the slow scala parser combinators are the next thing to look at, but at that point, you are really forking or doing a lot of work to upstream code to Twitter.

LGTM
At the top of the scrooge compiler copy pasta could you just outline the weaknesses from your comment ^^, and generally what we do different/why (so allowing paths used in the src jars)

The bazel ci seems to be stuck, but is reporting green if you click on it.
I'm going to merge based on @ianoc 's support.

closes #41


Revert "[feathr] Move pyspark into test requires (#190)"

This reverts commit 874e35ff7e8eb90c44fcd18f2eeb68ac89b5bf97.

Reverting as the last commit breaks main and @windoze need to testing thru a few bugs


Update mlforecast:

version increased and sha256 updated.
remove skipping for py>=310.
abs.yaml added as this package goes to Snowflake channel.

We don't have this package in defaults. This is a Snowflake package and needs to be uploaded to their channel.
I used abs.yaml file with only 'channels' attribute activated, so that the package could use window-ops dependency, which is only available on the Snowflake channel. I was told that by only using 'channels' in the abs.yaml file the specified channel can be used as a source of packages, and that the target package (in this case mlforecst) would not be uploaded to the specified channel. However, the package got uploaded to the Snowflake channel nevertheless. Luckily all archs built successfully from first attempt. I will speak with the Sirius team to see if there is a way to use packages from other channels without uploading the target package to the specified channel(s).

You can use my finder tool to search packages on the Snowflake channel:
distro-incubator/akabanovs/pkg_finder/pkg_finder.py -n mlforecast -c sfe1ed40

We don't have this package in defaults. This is a Snowflake package and needs to be uploaded to their channel.
I used abs.yaml file with only 'channels' attribute activated, so that the package could use window-ops dependency, which is only available on the Snowflake channel. I was told that by only using 'channels' in the abs.yaml file the specified channel can be used as a source of packages, and that the target package (in this case mlforecst) would not be uploaded to the specified channel. However, the package got uploaded to the Snowflake channel nevertheless. Luckily all archs built successfully from first attempt. I will speak with the Sirius team to see if there is a way to use packages from other channels without uploading the target package to the specified channel(s).

but the ticket https://anaconda.atlassian.net/browse/PKG-1846 is not for snowflake ?

We don't have this package in defaults. This is a Snowflake package and needs to be uploaded to their channel.
I used abs.yaml file with only 'channels' attribute activated, so that the package could use window-ops dependency, which is only available on the Snowflake channel. I was told that by only using 'channels' in the abs.yaml file the specified channel can be used as a source of packages, and that the target package (in this case mlforecst) would not be uploaded to the specified channel. However, the package got uploaded to the Snowflake channel nevertheless. Luckily all archs built successfully from first attempt. I will speak with the Sirius team to see if there is a way to use packages from other channels without uploading the target package to the specified channel(s).

but the ticket https://anaconda.atlassian.net/browse/PKG-1846 is not for snowflake ?

I checked with @sumit0190 and @cbouss and both confirmed this should be uploaded to the Snowflake channel at this time, since it had been originally uploaded there.


Unused variables in unit tests

Running our full suite of Minitest tests reports that the following variables are declared but never used. Each test should be verified to see if the variable can be removed entirely or if the test should be refactored to include the use of the variable.
test/new_relic/agent/configuration/manager_test.rb:497: warning: assigned but unused variable - dd
test/new_relic/agent/configuration/manager_test.rb:515: warning: assigned but unused variable - dd
test/new_relic/agent/tracer_test.rb:311: warning: assigned but unused variable - segment
test/new_relic/dependency_detection_test.rb:214: warning: assigned but unused variable - executed
test/new_relic/dependency_detection_test.rb:231: warning: assigned but unused variable - executed
test/new_relic/dependency_detection_test.rb:248: warning: assigned but unused variable - executed

These warnings can be reproduced by running: bundle exec rake test

Hey @kaylareopelle  - I'd love to work on this issue, can you please assign it to me? Thanks. :)

Sorry, I linked the wrong issue with the PR :sweat_smile:

@chahmedejaz - No worries! You've been assigned to this issue. Thank you for your help. Let us know if you have any questions! 😄


Update nth-check to fix vulnerability CVE-2021-3803

Currently react-scripts is using an older version of nth-check - no update available yet that fixes this vulnerability.

Hey @MWSandbox,
We're part of a startup called Seal Security that mitigates software vulnerabilities in older open source versions by backporting/creating standalone security patches - enabling more straightforward remediation in cases like this. We created an nth-check 1.02-sp1 that's vulnerability-free. As with all of our patches, it's open-source and available for free.
If relevant, check out our GitHub repo if you wish to learn more, or start using our app.
Please feel free to reach us at<EMAIL_ADDRESS>if you have any requests/questions.


Team 8 Review - Missing exceptions and parameters for Exported Access Programs in MIS

In the screenshots below it shows that there are no possible exceptions. And for the majority of the access programs in the MIS there are no exceptions listed. It's possible there there may be uncaught built-in Python exceptions raised from code which need to be accounted for. For example, the write_file access program could raise an IO error.

Additionally, there is inconsistency in the inclusion of parameters of your access programs such as the ones below missing despite having input and output variables defined in the Syntax section

Below is an example which does include it

Team 8 TA: @Lyuyang0130

fixed during modularization process


self.clk not being wired by wireclocks pass

Running the test at https://github.com/David-Durst/coreir/blob/aetherlingMultipleParallelism/tests/simulator/aetherlingHelpersSim.cpp#L151 produces the following line when trying to run the simulator (note: 0,1,2,3 are me printing out iterator):
0
Select self.clk is not set in self.clk
Cannot execute because 1 input(s) are not set:
self.clk
1
Select self.clk is not set in self.clk
Cannot execute because 1 input(s) are not set:
self.clk
2
Select self.clk is not set in self.clk
Cannot execute because 1 input(s) are not set:
self.clk
3
Select self.clk is not set in self.clk
Cannot execute because 1 input(s) are not set:
self.clk
self.out_0_container_el0 cannot be found

This was determined to be not a bug.


Create devcontainer.json

@<!-- DO NOT IGNORE THE TEMPLATE!
Thank you for contributing!
Before submitting the PR, please make sure you do the following:

Read the Contributing Guide.
Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
Ideally, include relevant tests that fail without this PR but pass with it.

-->
Description

Linked Issues
Additional context

What is the purpose of this PR?


Super-issue: Rethink / re-design "object-system"

          In general, we need to rethink / redesign the "object-system" anyways. Some aspects are:

[ ] Mutual recursive objects

[x] #274 (globally)
[ ] #600 (locally?)

[ ] toplevel objects (can those be mutually recursive?)
[ ] classes
[ ] implementing multiple interfaces
[ ] objects as members
[ ] private methods
[ ] "extension" methods
[ ] fields

See also

This is inspired by @b-studios in https://github.com/effekt-lang/effekt/issues/600#issuecomment-2370616782

(Of course, feel free to add/edit/make sub-issues etc)

I'd like to be able to allocate an object into a region (if it has mutable state).

I'd like to be able to allocate an object into a region (if it has mutable state).

Would it also make sense to allocate a capability into a region? 🤔
def makeCounter {r: Region} = {
  var count in r = 0
  try {
    println(c.get())
    c.increment()
    c.increment()
    println(c.get())

    c
  } with c: Counter in r {
//                  ~~~^
    def get() = resume(count)
    def increment() = { count = count + 1; resume(()) }
  }
}


can add circle title aiconCreateFunction

eg:

You can add this prompt, in the circle above plus All

https://github.com/Leaflet/Leaflet.markercluster#customising-the-clustered-markers


Fix failing capital spec

What
The capitals_creation_service_spec randomly fails. This is due to the use of Faker::Bank.name to create bank account names. There is only a small pool of bank names to select from so occasionally both accounts are created with the same name, leading to failures when find_by!(name: bank_account[:name]) is executed.
I've fixed this by adding Faker::Bank.account_number to the name created by FactoryBot, which should hopefully result in unique names always being created.
Checklist
Before you ask people to review this PR:

[x] Tests and rubocop should be passing: bundle exec rake
[x] Github should not be reporting conflicts; you should have recently run git rebase master.
[x] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[x] The PR description should say what you changed and why, with a link to the JIRA story.
[x] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[x] You should have checked that the commit messages say why the change was made.

An another way to make it unique is to use FactoryBot's sequence:
sequence(:name) { |n| "#{Faker::Bank.name} #{n}" }

n is incremented each time

You could use "#{Faker::Bank.name} #{Faker::Bank.unique.account_number}" to be sure it's unique and avoid the 22 limit.
account_number seems to have much more unique values. (https://github.com/stympy/faker/blob/8eff383dfe8a05f9f896f1bad13b2c66733fdb6a/lib/faker/default/bank.rb#L8)

I wasn't aware of the unique attribute for Faker. I've added that to the spec. That should give us more than enough names for our tests.


Xterm ssh terminal it's not connecting

When I try to use the webmin ssh terminal it's only showing CONNECTING...

Hello,
What is getting logged to /tmp/.webmin when you're trying to connect?

Thanks for reaching out,
Running shell '/bin/bash -bash' with pid 22701
listening on port 557
timeout waiting for connection at /usr/libexec/webmin/xterm/shellserver.pl line 103.

Is Webmin running behind proxy?

nope

Not sure then. What is Webmin version you're running? Which distro and version is this? Does it work if you switch to the old Framed Theme?

Yes it's working with Framed Theme

No. I get this error: Failed loading terminal : Websocked connection error

What error exactly is thrown to browser's console?

WebSocket connection to 'wss://example.com/xterm/ws-556' failed:

Sorry, this is not enough of details to understand what's wrong!
What OS and version this is? What browser and version are you using?

OS : CentOS Linux 7.9.2009
Kernel : Linux 3.10.0-1160.83.1.el7.x86_64
Browser : Chrome 110.0.5481.178

Can you share your /etc/webmin/miniserv.conf and /etc/webmin/config files in a zip file attached to this threat?

Plus /etc/webmin/xterm/config file.

Config file
ld_env=LD_LIBRARY_PATH
passwd_cindex=2
passwd_uindex=0
find_pid_command=ps auwwwx | grep NAME | grep -v grep | awk '{ print $2 }'
path=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
passwd_pindex=1
passwd_mindex=4
passwd_file=/etc/shadow
tempdelete_days=7
by_view=0
os_type=redhat-linux
os_version=15.9
real_os_type=CentOS Linux
real_os_version=7.9.2009
lang=en
log=1
referers_none=1
md5pass=0
theme=authentic-theme
product=webmin
referers=example.com
noremember=
webprefix=
realname=
passapi=0
Miniserv file
port=1986
addtype_cgi=internal/cgi
realm=Webmin Server
logfile=/var/webmin/miniserv.log
errorlog=/var/webmin/miniserv.error
pidfile=/var/webmin/miniserv.pid
logtime=168
ssl=1
no_ssl2=1
no_ssl3=1
no_tls1=1
no_tls1_1=1
ssl_honorcipherorder=1
no_sslcompression=1
env_WEBMIN_CONFIG=/etc/webmin
env_WEBMIN_VAR=/var/webmin
atboot=1
logout=/etc/webmin/logout-flag
listen=1986
denyfile=.pl$
log=1
blockhost_failures=5
blockhost_time=10600
syslog=1
ipv6=1
session=1
premodules=WebminCore
userfile=/etc/webmin/miniserv.users
keyfile=/etc/webmin/miniserv.pem
passwd_file=/etc/shadow
passwd_uindex=0
passwd_pindex=1
passwd_cindex=2
passwd_mindex=4
passwd_mode=0
preroot=authentic-theme
passdelay=1
login_script=/etc/webmin/login.pl
logout_script=/etc/webmin/logout.pl
cipher_list_def=1
failed_script=/etc/webmin/failed.pl
trust_real_ip=1
error_handler_403=403.cgi
error_handler_404=404.cgi
error_handler_401=401.cgi
nolog=/stats.cgi?xhr-stats=general
pam_end=
pam_conv=
blockuser_time=10600
blocklock=
session_ip=
blockuser_failures=5
no_pam=0
logouttime=
utmp=
root=/usr/libexec/webmin
mimetypes=/usr/libexec/webmin/mime.types
server=MiniServ/2.013
websockets_/xterm/ws-555=host=<IP_ADDRESS> port=555 wspath=/ user=root time=1677859390

You should go to browser's console, open Network tab and check WS sub-tab, then try to re-connect and then check what is happening with WS connection exactly. Your configs work for me.
Another suggestion would be to force restart Webmin by running /etc/webmin/restart-by-force-kill command.

I just restart the server, same thing


SaveAs function only fills File.Path value later, causing problems with subsequent use of Save function

Apparently, the SaveAs function's filling of the File.Path field is done concurrently rather than right away before the execution of code after the SaveAs function is called. This can cause problems when the subsequent code uses the Save function, giving the error:
"Could not save the Excel file test.xlsx: no path defined for file, consider File.WriteTo or File.Write
exit status 1"
The test program below contains a "saveXlFile" function which is called several times after the "SaveAs" function is initially used to save a new Excel file "test.xlsx". Line 30 and 37 containing calls to saveXlFile have been remarked out as they otherwise cause the error mentioned above  However when running the program with the lines 30 and 37 included in the execution (remove the comment characters //), it varies which of them causes the error, and hence my assumption that the SaveAs processing is being executed in parallel.
Here is the test program:
package main

import (
	"fmt"
	"log"
	"os"

	"github.com/360EntSecGroup-Skylar/excelize/v2"
)

const s_file = "test.xlsx"
const s_sh_test = "test"

func main() {
	var wb *excelize.File
	var err error

	if fileExists(s_file) {
		wb, err = excelize.OpenFile(s_file)
		if err != nil {
			log.Fatal(err)
		}
	} else {
		wb = excelize.NewFile()
		err = wb.SaveAs(s_file)
		if err != nil {
			log.Fatal("Could not save new Excel file `", s_file, "`: ", err)
		}
		// fmt.Println("Immediate save of new Excel file after SaveAs")
		// saveXlFile(wb)
	}
	if sheetExists(wb, s_sh_test) {
		wb.DeleteSheet(s_sh_test)
	}
	wb.NewSheet(s_sh_test)
	// fmt.Println("Saving Excel file with new sheet test")
	// saveXlFile(wb)

	// add values to the test sheet
	sl_cells := []string{"A1", "A2", "A3", "B1", "B2", "B3", "C1", "C2", "C3"}
	for _, s_cell := range sl_cells {
		wb.SetCellStr(s_sh_test, s_cell, s_cell)
	}
	fmt.Println("Saving Excel file with cells filled in test sheet")
	saveXlFile(wb)

	s_ch := ""
	sl_menu := []string{"yes", "no"}

	for !contains(sl_menu, s_ch) {
		fmt.Printf("Read content of sheet `%s` using GetRows? [yes/no] \n", s_sh_test)
		fmt.Scanln(&s_ch)
	}
	if s_ch == "yes" {
		fmt.Printf("Content of sheet `%s`: \n", s_sh_test)
		rows, err := wb.GetRows(s_sh_test)
		if err != nil {
			log.Fatal(err)
			return
		}
		for i_row, row := range rows {
			fmt.Print("Row: ", i_row, "\t")
			for _, s_cell := range row {
				if s_cell == "" {
					s_cell = "[]"
				}
				fmt.Print(s_cell, "\t")
			}
			fmt.Println()
		}
	}
	saveXlFile(wb)
	fmt.Println("Final save of Excel file")
}

func saveXlFile(wb *excelize.File) {
	err := wb.Save()
	if err != nil {
		log.Fatal("Could not save the Excel file `", s_file, "`: ", err)
	}
}

func sheetExists(wb *excelize.File, s_sh_name string) bool {
	b_fnd := false
	for _, s_sh := range wb.GetSheetList() {
		if s_sh == s_sh_name {
			b_fnd = true
			break
		}
	}
	return b_fnd
}

func contains(sl_str []string, ss string) bool {
	if len(sl_str) == 0 || ss == "" {
		return false
	}
	for _, str := range sl_str {
		if str == ss {
			return true
		}
	}
	return false
}

func fileExists(s_file string) bool {
	info, err := os.Stat(s_file)
	if os.IsNotExist(err) {
		return false
	}
	if info.IsDir() {
		log.Fatal("Error: ", s_file, " is a directory")
	}
	return true
}

If you create a new spreadsheet by NewFile, it only can be saving it by SaveAs. If you open an existing spreadsheet by OpenFile, you can save the change by Save or saved it as another file by SaveAs.

Look again at my code, please.
I check if the Excel file exists, in which case I use the OpenFile. However, if it does not exist, I use NewFile to create it and immediately afterwards use SaveAs to save it with the given name. At that point the file does then exists. Later in the program, I should not now able to use the Save function as it has now been created by the SaveAs. However, there is a problem with that. which is what my bug report is about.

Here is shorter program that focus on just this issue, which gives this error message when using the master branch:
"Could not save the Excel file test.xlsx: no path defined for file, consider File.WriteTo or File.Write".
After already using SaveAs,  one should now be able to use Save, correct?
Otherwise, how can one do further changes on the Excel file and then save those?
package main

import (
	"fmt"
	"log"
	"os"

	"github.com/360EntSecGroup-Skylar/excelize/v2"
)

const s_file = "test.xlsx"

func main() {
	var wb *excelize.File
	var err error

	if fileExists(s_file) {
		err = os.Remove(s_file)
		if err != nil {
			log.Fatal("Problem removing file `", s_file, "`: ", err)
		}
	}
	wb = excelize.NewFile()
	err = wb.SaveAs(s_file)
	if err != nil {
		log.Fatal("Could not save new Excel file `", s_file, "`: ", err)
	}

	// now I should be able to save this new file as I have already used SaveAs
	fmt.Println("Trying to Save after use of SaveAs")
	saveXlFile(wb)
}

func saveXlFile(wb *excelize.File) {
	err := wb.Save()
	if err != nil {
		log.Fatal("Could not save the Excel file `", s_file, "`: ", err)
	}
}

func fileExists(s_file string) bool {
	info, err := os.Stat(s_file)
	if os.IsNotExist(err) {
		return false
	}
	if info.IsDir() {
		log.Fatal("Error: ", s_file, " is a directory")
	}
	return true
}

Perhaps, as you say, when creating a new Excel with NewFile, one can only use SaveAs, even after the file has been saved using that same function. However, this seems very counter-intuitive and different from other Excel packages and programs I have seen that handle documents.
I would say that only being able to use SaveAs, even when already having saved the new file (it is then not really a new file any longer), is so against convention that many new users of the Excelize will very likely run into this issue again and again. Furthermore, it adds unnecessary logic to an Excelize program, which can handle both new and existing files, having to keep track of whether a file started as new or was an existing file being opened, even if you add your own  "save" function that keeps track of the state of the Excel file.
Is it not possible that when SaveAs is used, the Excel.File struct is updated so it is identical to the one created by the OpenFile function?

To resolve this issue, we just set saved path in the SaveAs like this:
func (f *File) SaveAs(name string, opt ...Options) error {
    f.Path = name
    if len(name) > MaxFileNameLength {
        return ErrMaxFileNameLength
    }
    ...
}

Would you like to make PR for this? or I'll fix it later.

I have fixed this issue, please try to upgrade the master branch code, and this feature will be released in the next version.

Many thanks, xuri.
Works fine.

I wonder why MaxFileNameLength is set to 207 in https://github.com/qax-os/excelize/blob/81d9362b4f1cf765712b61837d5b5831d1cd0c58/xmlDrawing.go#L106
It seems file name length limit is 255 in golang.

To resolve this issue, we just set saved path in the SaveAs like this:
func (f *File) SaveAs(name string, opt ...Options) error {
    f.Path = name
    if len(name) > MaxFileNameLength {
        return ErrMaxFileNameLength
    }
    ...
}

Would you like to make PR for this? or I'll fix it later.

Accroding to ISO 9660:1988 International Standard §7.5.1, the Length of File Name shall not exceed 207.


Fix issue 1382: File info dialog overflow

Fixes issue #1382
As discussed and demonstrated in the issue, the text in the FileInfoDialog widget was prone to overflowing and clipping the text content if it was too long.

This PR fixes that by wrapping the Table in a SingleChildScrollView as demonstrated in this screen recording:
TextOverflow.webm

Nice


[Bug] SAXParseException: not well-formed (invalid token) [sf#146]

Reported by martinellison on 2010-06-13 07:10 UTC
Cannot generate code, get the following traceback:
Traceback (most recent call last):
File "/usr/share/wxGlade/application.py", line 447, in generate_code
class_names=class_names)
File "/usr/share/wxGlade/xml_parse.py", line 527, in init
if from_string: self.parse_string(input)
File "/usr/share/wxGlade/xml_parse.py", line 74, in parse_string
self.parser.parse(source)
File "/usr/lib/python2.6/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.6/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/usr/lib/python2.6/site-packages/_xmlplus/sax/expatreader.py", line 220, in feed
self._err_handler.fatalError(exc)
File "/usr/lib/python2.6/site-packages/_xmlplus/sax/handler.py", line 38, in fatalError
raise exception
SAXParseException: :1:1: not well-formed (invalid token)
Version HG on py 2.6.4 and wxpy <IP_ADDRESS>

Commented by martinellison on 2010-06-13 07:10 UTC
wx file occasioning error
Attached file gl2.wxg:
<?xml version="1.0"?>
<!-- generated by wxGlade HG on Sun Jun 13 14:55:42 2010 -->

<application path="" name="" class="" option="0" language="C++" top_window="" encoding="UTF-8" use_gettext="0" overwrite="0" use_new_namespace="1" for_version="2.8" is_template="0" indent_amount="4" indent_symbol="space" source_extension=".cpp" header_extension=".h">
</application>

Commented by martinellison on 2010-06-13 08:14 UTC
Installed Packages
expat.i686                                           2.0.1-10.fc13
so it might have something to do with the upgrade of expat from 1.05 (?) to 2.0.1

Commented by agriggio on 2010-06-28 09:16 UTC
Hello, can you try with the latest version of wxGlade on bitbucket?
(http://bitbucket.org/agriggio/wxglade)
That should work...

Commented by cgrohmann on 2012-01-07 22:14 UTC
Close this bug because it works with the current development version.
Thank you for reporting this bug.
Carsten


fix https://github.com/pmargreff/juliavm/issues/3

The issue is due to the change of valid JULIAVM_JULIA_AWS value
was: https://julialang.s3.amazonaws.com/bin/linux/
now: https://julialang-s3.julialang.org/bin/linux/

great.

Great, thank you @jeffhongxiao for the fix.


PEX MySQL Syncing problem

I run a network and all servers run PEX with the same config, all connecting to a global MySQL database. Theoretically, this should mean all ranks, permissions etc are synced across the server, right? They don't. For some unknown reason, I can set my rank in hub, hop into creative and not get the rank, even after /pex reload(ing).

MySQL version?

I believe i'm running the latest version, alongside phpMyAdmin. I read somewhere that the issue is with the plugins PEX & zPermissions, where they will not sync across servers well, the only alternative I currently see is SQLPerms but i'd much prefer to use PEX.

do /Pex backend does it say in the output "backend=sql"? If not you are not using mysql, do /pex backend sql to use mysql. If that does not work you have not synced your ranks well. https://www.spigotmc.org/threads/pex-mysql-rank-sync.87618/#post-965105 on the first page there is a small (shitty) tutorial i made about syncing ranks but not their permissions across all servers.

Make sure you're connecting to the same database across all the servers.
PEX will cache user data so that changes may not take effect until a reload or server relaunch by default. The plugin NetEvents can be used to remedy this in some cases.


Tidy up thread locals usage across translation units

Fixes #3015.
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

This change breaks the test
00634_performance_introspection_and_logging_shard
metrics became inconsistent.

I reverted it before investigation.


Disable fetching on region annotations

Uses https://github.com/girder/large_image/pull/187 to fix ROI widgets.

Codecov Report

Merging #328 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #328   +/-   ##
=======================================
  Coverage   45.46%   45.46%
=======================================
  Files         101      101
  Lines        2714     2714
  Branches       98       98
=======================================
  Hits         1234     1234
  Misses       1480     1480

Impacted Files
Coverage Δ

web_client/views/body/ImageView.js
67.52% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af7d9fd...e12185a. Read the comment docs.


Image Editor

DESC

either remove as dependency or use

TASKs

[x] demo

is somewhat working but needs further development


Comma Three will not turn on in car or with just USB power from computer of aux Charging

Describe the bug

How to reproduce or log data

Device/Version information (please complete the following information):

Device: [e.g. EON/EON Gold/comma two]
Dongle ID: [e.g. 77611a1fac303767, can be found in Settings -> Device -> Dongle ID or my.comma.ai/useradmin]
Route: [e.g. 77611a1fac303767|2020-05-11--16-37-07, can be found in my.comma.ai/useradmin]
Timestamp: [When in the route the bug occurs (e.g. 4min 30s into the drive)]
Version: [commit hash when on a non-release branch, or version number when on devel or release2 (e.g. 0.7.6)]
Car make/model: [e.g. Toyota Prius 2016]

Additional context

USB-charging from a computer is very unlikely to provide enough power to boot a C3. Could you provide more details about what you are trying to do exactly?

This is a hardware issue. Contact<EMAIL_ADDRESS>

Thanks for reaching out.  My Comma three installed fine in my 2021 Camry and worked for two days.  I now have a black screen with no activity on it.  I then took the Comma into my house and tried the power out let on my Computer and then two different power sources that I used in programing the Comma in my house before installing it in the car.  No Screen activity on any of the Four different power sources.


Connectionless Presentation of Credentials Protocol

Build the capability to allow for the presentation (or sharing) of digital credentials without a direct, ongoing connection between the presenter (the credential holder) and the verifier (the entity requesting to validate the credential).
This means that individuals can prove their identity or qualifications in various situations without needing a DIDComm connection to the verifier, possibly through pre-verified or self-authenticating credentials.

[x] hyperledger/identus-edge-agent-sdk-ts/pull/272
[x] hyperledger/identus-edge-agent-sdk-swift/pull/171
[x] hyperledger/identus-edge-agent-sdk-kmp/pull/192

I'd love to see more info on these issues - links out to PRs / docs maybe
Actually I think this was released in SDK 6.1.0 right? Raises the question of how living this roadmap is

@mixmix Have updated the ticket description as we are moving to github projects.
This card is completed so far, we can open new issues, etc but this is already completed.
We should discuss if we want to re-use oob links, I would propose to open an issue or a discussion in https://github.com/hyperledger/identus/discussions

https://github.com/hyperledger/identus-cloud-agent/issues/1426


Fix classification bug for ResNet18DefaultBenchmark

This change is based on this PR from buddy-mlir.
Change the input data layout from NHWC to NCHW to fix the classification bug of ResNet18DefaultBenchmark.
Pytorch is using NCHW to store image input. Since ResNet18DefaultBenchmark is based on 'ResNet-18.mlir' which is converted from a torch model, the input's layout should also be NCHW instead of the default setting NHWC in ImgContainer. After modification the following correct output of ResNet18DefaultBenchmark can be reached:
Classification Index: 208
Classification: Labrador retriever
Probability: 0.348121

For other deep learning benchmarks, data layouts are also explictly given to avoid confusion.

Thanks for the PR!
I will move ahead with the review once this PR lands.


CDS-58583 config files topic

Use config files in your deployments
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ x] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

CDS-58583

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Latency and Limits graph for monitorKinesisFirehose don't work

Version
v1.18.4
Steps and/or minimal code example to reproduce

Create a stack with kinesis firehose.
Setup monitoring for kinesis firehose with monitoring.monitorKinesisFirehose().
Deploy cdk to aws account.

Expected behavior
The graphs display information about the kinesis firhose normally.
Actual behavior
The Latency (P90) graph and the Limits (rate) graph both show now data do to their metrics being incorrect. The PutRecords and PutRecordsBatch metrics for kinesis firehose don't support  percentiles so the Latency graph doesn't display any data. Also the DeliveryStreamName dimension isn't isn't specified for BytesPerSecondLimit so the Limits graph doesn't display any data.
Other details
No response

Limits graphs are fixed by #378

regarding to Latency graph, I think the issue should be raised with AWS CloudWatch service, as per Doc indicated, Kinesis metric should support percentile.
Another thing worth checking is the region where your kinesis firehose is deployed. According to the news release here from 2016, only the following regions are supported US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), EU (Ireland), EU (Frankfurt), S. America (São Paulo), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai) and Asia Pacific (Sydney). (this could have changed since then).


Add "copy" compilation mode into contract compilation process

We have new contracts incoming which will be in the form of "raw Michelson". Simply putting those in packages/minter-contracts/bin is not sufficient, as that directory is often cleared out during the compilation process.
Create a new directory to house the set of "raw Michelson" contracts. During the compilation process (alongside LIGO compilation), these contracts should be copied into the packages/minter-contracts/bin directory such that

The subsequent type-generation process will pick them up, and
./bin can be safely blown away and properly regenerated during compilation.

cc @michaeljklein


Cichy dataset.

To enable https://github.com/mne-tools/mne-python/pull/3552.

why did you remove hcp stuff?
also I would call dataset object_visual rather than cichy but please put the refs to cichy's paper in docstrings
maybe someone can come up with a better name
ping @kingjr
@kingjr that should allow you to resurrect your RSA example

WTF. I blame git.

I'll make a clean PR

maybe someone can come up with a better name

How about just 'recognition' dataset. Or 'vis_rec'.

I would say visual_96_categories or something like this. The more explicit the better. Radek might release some additional data in the future, so I wouldn't name it by his name.
Else LGTM

+1 for visual_96_categories

+1


Added character 'q' to drpepper font

Added the character 'q' to the font drpepper.
character added:

character from drpepper.md:

Referenced Issues
closes #1058

Thank you for your contribution <3


doh: Fix mime type

Latest draft uses "application/dns-message".

Codecov Report

Merging #681 into master will increase coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #681      +/-   ##
==========================================
+ Coverage   58.18%   58.22%   +0.03%
==========================================
  Files          37       37
  Lines       10119    10119
==========================================
+ Hits         5888     5892       +4
+ Misses       3174     3171       -3
+ Partials     1057     1056       -1

Impacted Files
Coverage Δ

client.go
58.44% <ø> (ø)
:arrow_up:

msg.go
79.96% <0%> (+0.62%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e57bf42...ebf2e60. Read the comment docs.

I was going to go at this slightly differently. I want to keep the old and new mime-types so it continues to work with servers implementing an older draft. Content Negotiation will handle picking either mime type.

For an older draft... I think we shouldn't bother. If it where standardized
as such we should, but now?
On Sat, 19 May 2018, 12:52 Tom Thorogood<EMAIL_ADDRESS>wrote:

I was going to go at this slightly differently. I want to keep the old and
new mime-types so it continues to work with servers implementing an older
draft. Content Negotiation will handle picking either mime type.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/miekg/dns/pull/681#issuecomment-390399856, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVkWyckHDiVlDu9dwRalDPp_Y53mKzzks5t0Ad1gaJpZM4UFnkl
.

@miekg That sounds good to me.


JavaScript Error while viewing the video

After uploading the video successfuly, I can not play it. Following are the image for the javascript error while loading the view and the CVAT Log

[2019-02-28 12:59:20,236] INFO cvat.server: create task with params = {'labels': 'car @select=color:blue,red,black ~checkbox=parked:true @text=plate:"" @select=model:volvo,mazda,bmw ~radio=quality:good,bad', 'task_name': 'Vehicles$
[2019-02-28 12:59:20,266] INFO cvat.server: create task #1
[2019-02-28 12:59:20,273] INFO cvat.server: Task #1 parameters: {'labels': 'car @select=color:blue,red,black ~checkbox=parked:true @text=plate:"" @select=model:volvo,mazda,bmw ~radio=quality:good,bad', 'compress': 50, 'flip': Fals$
[2019-02-28 12:59:20,275] INFO cvat.server: FFMpeg cmd: ffmpeg -i /home/django/data/1/.upload/videoplayback.mp4 -start_number 0 -b:v 10000k -vsync 0 -an -y -q:v 16 /tmp/cvat-d_d_dqt_.data/%d.jpg
[2019-02-28 12:59:21,684] INFO cvat.server: check task #1
[2019-02-28 12:59:22,598] INFO cvat.server: check task #1
[2019-02-28 12:59:23,705] INFO cvat.server: check task #1
[2019-02-28 12:59:24,444] INFO cvat.server: check task #1
[2019-02-28 12:59:25,659] INFO cvat.server: check task #1
[2019-02-28 12:59:26,658] INFO cvat.server: Founded frames 2301 for task #1
[2019-02-28 12:59:26,660] INFO cvat.server: New segment for task #1: start_frame = 0,             stop_frame = 2300
[2019-02-28 12:59:26,681] INFO cvat.server: check task #1

@iheggo ,
It seems your chrome version is tool old.Could you please update it? It will fix the issue. On our side we will modify code to avoid such problem with old browsers.

@iheggo
The bug has been fixed. It should works in your browser. Please update your branch from remote develop.


Set TEMP path locally before running vagrant - note for locked files

Related to #50, we need to isolate the TEMP environments so that each instance doesn't step on the other. That is to set a TEMP area that we can have each vagrant run in when running the service.
Keep in mind there is something we look for to fail the environment and that is : https://github.com/chocolatey/package-verifier/commit/5b02947249bb2f5dd45ca1b78d5fc42d2bc7d9bb#diff-943f03b4181625724f13ae8ef798df44R67. This could be a local file to the host machine and not in the machine like we may have originally thought. It's best to isolate these environments entirely.
2019-09-11 06:08:38,827 14 [WARN ] -  [Vagrant][Error] The following WinRM command responded with a non-zero exit status.
2019-09-11 06:08:38,827 14 [WARN ] -  [Vagrant][Error] Vagrant assumes that this means the command failed!
2019-09-11 06:08:38,828 14 [WARN ] -  [Vagrant][Error] powershell -ExecutionPolicy Bypass -OutputFormat Text -file c:\tmp\vagrant-shell.ps1
2019-09-11 06:08:38,828 14 [WARN ] -  [Vagrant][Error] Stdout from the command:
2019-09-11 06:08:38,828 14 [WARN ] -  [Vagrant][Error] Stderr from the command:
2019-09-11 06:08:38,828 14 [WARN ] -  [Vagrant][Error] del : Cannot remove item C:\Windows\Temp\WinRM_Elevated_Shell.log: The process
2019-09-11 06:08:38,828 14 [WARN ] -  [Vagrant][Error] cannot access the file 'C:\Windows\Temp\WinRM_Elevated_Shell.log' because it
2019-09-11 06:08:38,829 14 [WARN ] -  [Vagrant][Error] is being used by another process.
2019-09-11 06:08:38,829 14 [WARN ] -  [Vagrant][Error] At C:\tmp\vagrant-elevated-shell.ps1:19 char:3
2019-09-11 06:08:38,829 14 [WARN ] -  [Vagrant][Error] +   del $out_file
2019-09-11 06:08:38,829 14 [WARN ] -  [Vagrant][Error] +   ~~~~~~~~~~~~~
2019-09-11 06:08:38,830 14 [WARN ] -  [Vagrant][Error]     + CategoryInfo          : WriteError: (C:\Windows\Temp\WinRM_Elevated_Shel
2019-09-11 06:08:38,830 14 [WARN ] -  [Vagrant][Error]    l.log:FileInfo) [Remove-Item], IOException
2019-09-11 06:08:38,830 14 [WARN ] -  [Vagrant][Error]     + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell
2019-09-11 06:08:38,830 14 [WARN ] -  [Vagrant][Error]    .Commands.RemoveItemCommand

@ferventcoder I would love to, but it will be at least next week before I can take a stab at it. Let me know if that would work for you.


fixed issue #12

plot.names in measurements:

changed spelling: 'Terra' changed to 'terra'. 'firme' changed to 'firma'
manually changed to be follow what was in plothistory.

deleted duplicate entries in plothistory with no extra information (all NACs).

I had trouble figuring out how to resolve the conflicts (I don't think there are any genuine conflicts in the data), so I made this the new default branch.

@dlebauer, if this can be done easily, could you please get mmw590-patch merged into the master? I'm having trouble figuring out how to do this.


dart2js: output contains unused static const members

Similar to Issue #5972.
The generated JS contains a block of initializations for all the static variables.  Included in this block is initializations for static const members that have no references.
Unused named constants account for about 1% of the size of swarm.
e.g.
class _JsonParser {
  static const int BACKSPACE = 8;
-->
$._JsonParser_BACKSPACE = 8;

This appears to have been fixed.


Error	TS2661	Cannot re-export name that is not defined in the module.	node_modules\angular2\src\facade\promise.d.ts

Any clues?

I solve this problem by adding  declare var Promise: PromiseConstructor;  on the top of  promise.d.ts, problem is typescript 1.8

This issue has been fixed with https://github.com/Microsoft/build2016-vsmobile/blob/master/_fixes/promise.d.ts


Dataframe Assertions

To assist unittest we want to be able to assert on the contents of dataframes.
Assertions may concern

the column names
the full schema (column names and types)
the data contents of some, or all columns
smart matching of some types

timestamps

handling of timeszones
approximate matching

ordered vs unordered matching

Until then, one can convert the pyspark dataframe into a pandas dataframe - and then, use the pandas testing library: https://pandas.pydata.org/docs/reference/api/pandas.testing.assert_frame_equal.html.

dataframe assertions have been implemented in atc-dataplatform-tools


Treat MimeType in Content-Type as case-insensitive

Why
Tenable.io introduced a fun change which is technically RFC compliant, but very annoying.
They changed the Content-Type from application/json to Application/json in the HTTP responses from one of the API endpoints. As a result, this library will not treat the response and JSON and you end up with AttributeErrors in client code.
Like I said, it is technically compliant as RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content § <IP_ADDRESS>. Media Type states:

The type, subtype, and parameter name tokens are case-insensitive.
https://httpwg.org/specs/rfc7231.html#media.type

How

Lowercase the response Content-Type header value before checking if it contains application/json

Amusingly, this was just addressed in 1.4.5.
https://github.com/SteveMcGrath/restfly/commit/5d869a33117807d1dbca2264b72ac08f3ce7aa98

Great minds think alike!

Thanks for the submission though.  feel free to submit a PR if there is anything else.

Will do. Thank you for maintaining this!


Automated Upgrades Only Reacting To Binary Changes

Hello, we have a question/issue please. We are using Flux via Helm and using ECR to store our Docker images.
We are testing the automated upgrades feature by using the following configuration on each "release" file:
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.chart-image: glob:master-*

We use a similar approach for other releases/environments like "qa" etc. Upgrades basically works as it's described on the documentation.. Every time that a new Docker image is pushed using the same preffix mentioned on the annotation (master-, qa- etc), the container image is also upgraded by Flux. So far, so good.
However, there is a special case where we noted that this process doesn't occur. Not sure if this is intentional or a bug. This is the case:

Suppose that your Docker image contains the application code saying "Hello World". Docker image is built and pushed to Docker Registry, tagged as master-v1 (using the build number as suffix)

Then, you change your application code to say "Hello World 2". A new Docker image is built and pushed to Docker Registry, tagged as master-v2. Flux automatically upgrades the container image to use v2 instead of v1, since this is a more recent image. So far, so good.

Then, you change the application code to rollback your previous change, so it says "Hello World" again (exactly as in the point #1). A new build process occurs and the image is pushed to Docker Registry (ECR in our case). This is the third build, so the tag used is master-v3. However, since v1 and v3 are exactly the same code and exactly the same binary image, ECR just adds the new tag to the old image, so you have basically 2 images:

a. First image tagged as v1 and v3
b. Second image tagged as v2
This time, Flux doesn't upgrade the image of the container. So, the container is still running v2 ("Hello World 2") even when a more recent build process occurred. I guess that this behavior occurs because, v2 is still newer than v3 (from a binary point of view). However, could be great if Flux can detect what is the image with the latest tag (v3 in this case). This behavior is very useful to deploy an automated rollback. There are any workarounds to support this use case?
Thank you very much in advance.

If you use semantic versioning it would determine the newest by comparing the versions (and not image creation time which it does when using globs or no filter):
https://github.com/weaveworks/flux/blob/master/site/using.md#semver

Using a semver filter will also affect how flux sorts images, so that the higher versions will be considered newer.

    flux.weave.works/tag.chart-image: semver:*

That means you would need to actually introduce semver tags like v1 or 1.0.0.

@rndstr Thank you very much for your feedback! I think that semver can be a good option. Also, your comment give me another idea: maybe I can also use the regexp option, since we include the name of the git branch (matching a k8s namespace) as preffix. Thank you very much!


[FAB-17133] Add Action to Trigger CI Builds

This change adds a GitHub Action that is used
to trigger CI builds when the PR is commented
on using "/ci-run"
You can test it out here: https://github.com/btl5037/fabric/pull/3
You can see the actual runs here: https://github.com/btl5037/fabric/actions
Signed-off-by: Brett Logan<EMAIL_ADDRESS>Type of change

New feature

Description
This change adds a GitHub action to trigger CI builds on comment
Users can comment "/ci-run" on their PR conversation tab to retrigger CI. It first checks to see if an existing build is running before triggering the new build.

So it's not using the AZ CLI, but I had my moment of clarity when I stepped away last night and got some sleep, it looks like the rest API has an endpoint for retriggering just the failed builds, I am working on that now

So it's not using the AZ CLI, but I had my moment of clarity when I stepped away last night and got some sleep, it looks like the rest API has an endpoint for retriggering just the failed builds, I am working on that now

Just curious - why is a github action comment for retriggering failed jobs better/different than clicking Re-Run on the failed job?
In general we'd like to write down and socialize all the common comment actions people should be using, so for consistency good to have comment actions. Just wondering if there is any difference relative to clicking Re-Run.

The only people authorized to use the re-run function or the /azp-run comment are repo maintainers/admins and people who have been added to the org in Azure DevOps (which is unfortunate). So to maintainers and admins can retrigger individual failed jobs, but there is no mechanism for an author who isn't a maintainer to retrigger ci on their own build.
@mastersingh24 I really dug into the the REST API today, there is no endpoint to re-trigger failed jobs only. Per above, as a maintainer you can do so via the checks tab, but the author cannot if they aren't a maintainer. I did open a ticket with Azure DevOp's to ask if and when this might be implemented and a feature request to add this. Unfortunately it's not perfect, but it's what we can do right now. Since author's can't re-trigger their CI on their own, this would give them some means to do so, even if not perfect.

I updated the job to only allow commenters or those assigned as reviewers (which in our case is our maintainers) to allow the retriggering of a job. It also doesn't retrigger if a build is already executing against it

Unfortunately it's not perfect, but it's what we can do right now. Since author's can't re-trigger their CI on their own, this would give them some means to do so, even if not perfect. They only added rerun failed jobs last month, so it's a fairly new feature, which is probably why there is nothing on the API for it.

Noted. Thanks for digging into it. This LGTM.


IntuneCD monitor uses IntuneCD v2.0.2 with a bug in the prefix argument for backup

I want to use IntuneCD monitor for backup/update across several tenants, but due to the current version of IntuneCD in IntuneCD-monitor, we cannot filter based on the prefixes we use.
This issue is fixed in IntuneCD, but not available in IntuneCD monitor.
Thanks for this awesome tool!

IntuneCD has been bumped to 2.0.7 in the latest version