bbin install should not overwrite other executables in bin - potential security issue

bbin install should fail when a binary with the same name exists at the path.
It should IMO allow user to force installation  with a flag.
This could be a security issue, especially with package owners allowed to set the binary name.
Some people might chose to override things like ls or other stuff.
Current status:

bbin installs binary commands as they are
If a binary is present it will be overwritten

~/.local/bin$ ls -lah neil
-rwxr-xr-x 1 ieugen ieugen 1,2K sep 27 11:05 neil

BABASHKA_BBIN_DIR=~/.local bbin install io.github.babashka/bbin --latest-sha --as neil
{:coords
 {:git/url "https://github.com/babashka/bbin",
  :git/sha "6fde1b1dbfaef3063eb1eba4899a730bf703c792"},
 :lib io.github.babashka/bbin}

~/.local/bin$ ls -lah neil
-rwxr-xr-x 1 ieugen ieugen 1,1K sep 27 11:26 neil

cat neil
#!/usr/bin/env bb

; :bbin/start
;
; {:coords
;  {:git/url "https://github.com/babashka/bbin",
;   :git/sha "6fde1b1dbfaef3063eb1eba4899a730bf703c792"},
;  :lib io.github.babashka/bbin}
;
; :bbin/end

(require '[babashka.process :as process]
         '[babashka.fs :as fs]
         '[clojure.string :as str])

(def script-root "/home/ieugen/.gitlibs/libs/io.github.babashka/bbin/6fde1b1dbfaef3063eb1eba4899a730bf703c792")
(def script-lib 'io.github.babashka/bbin)

Might be related to

https://github.com/babashka/bbin/issues/34
https://github.com/babashka/bbin/issues/18
https://github.com/babashka/bbin/issues/35

I think it's a feature that the older version gets overwritten with the newer version.

We could however prevent overwriting by introducing a flag: --force or so

@ieugen: If you're concerned about security, you need to make sure you only install scripts from a) authors you trust or b) code that you've verified yourself. If you're installing from an untrusted source, there's nothing that bbin can do to help you since we don't have any sandboxing feature in Babashka. Blocking script names isn't enough on its own since the script can do whatever it wants with the filesystem when it's running.

I also recommend putting local bin directories as a suffix in the PATH rather than a prefix. This is how the README does it:
echo 'export PATH="$PATH:$HOME/.babashka/bbin/bin"' >> ~/.$(basename $SHELL)rc && exec $SHELL

This reduces the risk of overriding something like sudo if you did happen to install a malicious script.

@borkdude :

I think it's a feature that the older version gets overwritten with the newer version.

I can overwrite ANY binary this way so IMO it needs some consideration or at least a notice.
@rads :

export PATH="$PATH:$HOME/.local/bin"

This is normally set by the distribution.

Blocking script names during bbin install isn't enough on its own since the script can do whatever it wants with the filesystem when it's running.

True. We can maybe do one or more of the following:

print the changes that are being done what apps are installed and where
ask for permission, esp in case where it will overwrite an existing binary. This could be done on first install only if we consider the next ones to be upgrades and overwriting is expected.
If the script is linked in /local/bin we can check it's contents hash match what we expect to have, before we attempt changes ?!

I agree with @ieugen. I think leaving all the responsibility to the end user of bbin is simply not fair. This user has to understand the following:

What a Babashka script can do (file writing, http requests etc)
How bbin will use the coordinates to create a binary
What potential other binaries this new binary is overwriting, literally or by PATH precedence.
What this other binary is responsible for.

I believe something like bbin should exist for ease of distribution so moving the responsibility of all these safety concerns removes the ease for a serious user actually. Ease would only exist for the naive user, until things go wrong and no one will trust bbin again. Sounds a bit dramatic, but this is how trust works I believe.
So one extra vote for having bbin do a maximum effort to protect the end-user, as this IMO will really contribute to the distribution.
I would want this to go even further than only protecting existing binaries, I would also like so see:

Telling the user what the script potentially can do. Does it write to non-temporary dirs (analyzing the filesystem code would do a great deal here)
Does the script do external requests
etc.

Maybe a permission system would be interesting. "Script asks permission for X, Y, Z. Please confirm"


Make Namingo compatible? Universal Acceptance

Make Namingo compatible?.... Universal Acceptance
for maybe v 1.0.5/ 1.0.6
No more words nedeed....

Fixed in https://github.com/getnamingo/registry/commit/4fa128933409cbeed3397481747b7bc8f5931566 and next.

Reopened as still need to implement on namingo it's self.... to accept likes of  too...
<EMAIL_ADDRESS>seems ✔
<EMAIL_ADDRESS>seems ✖

Yes, unfortunately the html email input is not UA ready, I've removed most but this one is still there. WIll fix.


Display and Size of Linked List | Question

Greetings sir/Mam,
I would like to contribute the code for this issue in C++/CPP.
The code is ready. I have added the code , along with proper explanation of the algorithm , test cases , time complexity and space complexity of the same, as per the guidelines.
Kindly assign it to me.
This is regarding GSSOC'21.
Regards,
Hitain Kakkar

Hello i am nikita jangid, i can contribute the code for this issue.
Kindly assign this to me.

Hello Sir/Maam
I would like to resolve this issue in python and java. Please assign this issue to me.


Centralized Single Point Of Failure - swap_identity

There exist 7 superuser accounts defined in 'ParamUpdaterPublicKeys'.
These accounts can be used to create 'SWAP_IDENTITY' actions that can re-assign any account's username (and coin balances?) to another account. This allows any account on the platform to be cancellable by any of the superuser accounts.
Recommendation: Remove swap_identity and superuser accounts as soon as possible.

There exist 7 superuser accounts defined in 'ParamUpdaterPublicKeys'.
These accounts can be used to create 'SWAP_IDENTITY' actions that can re-assign any account's username (and coin balances?) to another account. This allows any account on the platform to be cancellable by any of the superuser accounts.
Recommendation: Remove swap_identity and superuser accounts as soon as possible.

Absolutely agree this.

This is most likely here while the network is maturing.
Having said this, I would love to read an estimated time for its removal by the dev team.

@maebeam any thoughts on this? I understand why we need to have them for now, but it would be a great way to build some more trust if the core team can share a roadmap for this issue.
Some of the startup teams I've worked at use the following framework: they write up a press release about what needs to be delivered 6 months from now, and it serves as a great primer for a user to see what's upcoming and why it matters. It also forces the team to put their short-term vision down in writing.
My 2 cents :)

They claim this is all open source now yet their infrastructure is still required on the backend calls for tons of stuff like identity and blockchain manipulation outside what should be allowed. I'm really growing tired of this scam 🤦♂

There exist 7 superuser accounts defined in 'ParamUpdaterPublicKeys'.
These accounts can be used to create 'SWAP_IDENTITY' actions that can re-assign any account's username (and coin balances?) to another account. This allows any account on the platform to be cancellable by any of the superuser accounts.
Recommendation: Remove swap_identity and superuser accounts as soon as possible.

I wish more people would hold them accountable like you. This entire platform has so many shady things they lie about constantly on Twitter and in their documentation that is only found by technical people paying attention. If they don't resolve these issues and stop keeping full control of everything nobody can ever trust this system. I feel bad for people who got hoodwinked into this and have a bunch of money tied up who now just have to hope for the best and blindly promote the platform hoping for a return one day. Thanks for bringing attention to these very severe issues 🙏 Hit me up on Twitter anytime @barnacules, I was sick of them censoring me so I do all communication there 👍🏻

So an FAQ was published a few days ago that includes an update on this issue -
https://docs.bitclout.com/faq/bitclout-faq#can-bitclout-com-access-my-private-keys-if-im-a-normal-user

it is important to mention that profiles and creator coins (not $CLOUT) can be recovered by certain ParamUpdater public keys using a SWAP_IDENTITY transaction type that the core dev team intends to remove after an initial bootstrapping phase.

So the claim is that only creator coins are affected by this and not the underlying coins. Also that they intend to remove it, but without a firm timeline.


Fix varargs for hip-cpu

HIP-CPU's hipLaunchKernelGGL is a macro that handles packing varargs into a C++ tuple. I can't find any good way to interface with this function from nim for a variable set of nim tuple arguments.

hipModuleLaunchKernel looks much more reasonable to use from nim, but this branch currently fails with an exception.

#3 is giving me issues with testing this on my desktop

d'oh

ah, hipModuleLaunchKernel expects a hipFunction_t which is some weird class, this is not the right approach...

very strange, tests pass but the vector_sum_cpu.nim build fails: https://github.com/monofuel/hippo/actions/runs/10659502190/job/29542124225
works on my machine and in an ubuntu container

d'oh, the error was actually with the second command, not the first. the hip launch kernel macro should not run when building for cuda.


QAT/Nginx performance is low under asyn mode

Hi
I am evaluating the QAT performance with Nginx.
My set up is:

QAT card is 8950, the host is a desktop PC running Centos 7.
[root@jianqche QAT2]# lspci | grep DH
03:00.0 Co-processor: Intel Corporation DH895XCC Series QAT

Nginx patch is from https://01.org/sites/default/files/downloads/intelr-quickassist-technology/nginx-1.10.3.l.0.3.1-001.tar.gz

OpenSSL is https://www.openssl.org/source/openssl-1.1.0f.tar.gz

QAT engine is https://github.com/intel/QAT_Engine/archive/v0.5.30.tar.gz

QAT driver is https://01.org/sites/default/files/downloads/intelr-quickassist-technology/qat1.7.upstream.l.1.0.3-42.tar.gz

The result of "openssl speed" test is good. Below are test results. We can see the performance of QAT under async mode is much higher than CPU and QAT sync mode.
+++++++++++++++++++++++++++++++++++++++++++++++

CPU - RSA 2018
sign           verify           sign/s  verify/s
rsa 2048 bits 0.001065s 0.001059s    938.7    944.2

QAT - sync - RAS 2018
sign           verify           sign/s  verify/s
rsa 2048 bits 0.001063s 0.001062s    940.7    941.2

QAT - async - RSA 2018
sign           verify          sign/s      verify/s
rsa 2048 bits 0.000050s 0.000031s  20020.2  32320.8
+++++++++++++++++++++++++++++++++++++++++++++++

The problem I have is the Nginx performance test result. I am using "openssl s_time" as client to do the test of new TLS connection per second.

Use CPU for the cryption:
One Nginx worker, CPU 76%
11543 connections in 2.14s; 5393.93 connections/user sec, bytes read 0
11543 connections in 11 real seconds, 0 bytes read per connection

The QAT sync mode performance is slightly higher than CPU:
One Nginx worker, CPU 78%
13864 connections in 2.00s; 6932.00 connections/user sec, bytes read 0
13864 connections in 11 real seconds, 0 bytes read per connection

The QAT async mode performance is bad:
One Nginx worker, CPU 30%
5976 connections in 2.24s; 2667.86 connections/user sec, bytes read 0
5976 connections in 11 real seconds, 0 bytes read per connection

The questions I have are:

I run command "cat /sys/kernel/debug/qat_dh895xcc_03:00.0/fw_counters"
to check the QAT status and I did see the firmware request/response number increased when offloading the cryption to QAT. However I see only AE0, AE3, AE6, AE9 out of total 12 engines got the request, not all of them. Not sure how to use all of the 12 engine's resource.

For QAT async mode, the CPU load is low, seems the nginx worker is spending too much time waiting on epoll for the async data encryption completion. Not sure if there is way to improve it.

Any comment/suggestion?

Hi @jianqiangchen,
In terms of your engine usage, The dh895xcc product uses a hardware arbiter to automatically load balance incoming requests across the engines. The device will start by only utilizing a few of the engines and as the load increases the requests will be spread across more of the engines. In your case above it appears that there are not enough incoming requests to fully utilize all of the engines.
In terms of performance, my answer is assuming correct functioning of the asynchronous nginx application. In that case we need to look at the differences between running asynchronously with QuickAssist and unaccelerated.
By using QuickAssist you are making a tradeoff between latency and throughput. By that I mean it is not necessarily much faster to offload a single request due to the request being sent over the PCIe bus to the acceleration device, then the acceleration device has to DMA memory associated with servicing the request, process the request, and then DMA the result of the operation back. The real benefit is that the accelerator can do many of these operations in parallel allowing you to get much higher throughput overall. In order to see these benefits you need to have plenty of traffic coming in that can be offloaded in parallel (i.e. plenty of incoming connections).
As such there are many things that can affect getting enough incoming connections, these include:

Are the clients themselves making enough connections, in other words how many s_time instances are you running and how are they configured? I'd be looking to run many s_times in parallel and averaging the results, a single s_time will not pump enough requests in parallel.
On the server side are you running anything that could restrict the traffic, i.e. firewalls, connection tracking etc., perhaps check the client(s) as well?
On the server side do you have enough file descriptors configured per process and system wide? An extra file descriptor is needed per connection for the eventfd used for asynch notifications.
Is your server configured to allow access to enough ports to support all the incoming connections?
Is nginx itself configured to accept enough connections in the nginx.conf?

Out of the above I would expect the amount of s_times you are running to have most impact, the rest will just restrict your performance to an upper limit and could prevent you reaching 40K RSA 2K operations per second.
Let me know if this helps you any,
Steve.

Hi @jianqiangchen,
If what I have posted above does not help you then I would also recommend posting the same question to:
https://github.com/intel/asynch_mode_nginx/issues
as the problem your are experiencing is specific to running with asynchronous nginx with QuickAssist, i.e. the QAT Engine is working as expected with OpenSSL speed.
Kind Regards,
Steve.

Hi @stevelinsell
Thank you very much. Your explanation is clear, now I understand the trade off between the latency and throughput of QAT. By increasing the s_time instances, now I can get a much better performance(connections per second) for QAT asyn mode than CPU(double the numbers). Will try other system tuning and check the final result.
Thanks,
Jason


Introduction to Dialog Boxes in C#

Proposed title of article
Introduction to Dialog Boxes in C#
Introduction paragraph (2-3 paragraphs):
A dialog box in C# is a type of window, which is used to enable common communication or dialog between a computer and its user. A dialog box is most often used to provide the user with the means for specifying how to implement a command or to respond to a question. Windows.Form is a base class for a dialog box.
The simplest type of dialog box is the warning which displays a message and may require the user to acknowledge that the message has been read, usually by clicking “OK” or a decision as to whether or not an action should continue by clicking “OK” or “Cancel”.
Key takeaways:

What are dialog and message boxes
Types of dialog boxes
Types of Show Methods in Message boxes
Common Dialog Box and how to use them

References:
N/A

We already covered windows forms here.
Not approved - @mosesmwangi442


remove Canvas.getTotalMatrix

It's only used by sprite box right now. It would let us make Canvas completely opaque. It's not clear that it's a valid thing to query.

Done.


Avoid duplicate names/"shadowing" in homebrew/core and homebrew/cask

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
Doing brew install docker will install the Docker formula (and output a warning). brew install --cask docker will install the Docker cask. This may make sense to Homebrew maintainers but, to many of our users, this is unnecessarily confusing. It also has resulted (and will, most likely) continue to result in many bugs over the years.
We now have the ability to rename both formulae and casks. We should make use of this to pick a better name for each of the formulae and casks with overlapping names and add an audit/cop to ensure that we do not backslide and accidentally add more in future.
More often than not, this should involve renaming the cask. Casks are (generally) much less popular than the formula. If the cask has higher analytics usage (or perhaps just "higher in the rankings" than the formula, however, it may make more sense to rename the formula. Docker has half the cask installs in 365 days than formula but: it's the 4th highest installed cask and the 38th formula. Possible renames could be docker-cli or docker-desktop.
Note: this will almost certainly require making changing to existing audits, documentation and name/token format.
CC @Homebrew/maintainers @Homebrew/core and @homebrew/cask for thoughts
What is the motivation for the feature?
Less confusion and fewer bugs on overlapping formulae/casks.
How will the feature be relevant to at least 90% of Homebrew users?
Removing the ability to fully understand the concept of formula and cask to just use Homebrew.
What alternatives to the feature have been considered?

Do nothing
Keep the shadowing but don't default to the formula and always require disambiguation.
Only rename formulae.
Only rename casks.
Remove all shadowing casks.

Keep the shadowing but don't default to the formula and always require disambiguation.

I like this approach, though a combination with the rename is probably good. For example: the software in the Docker cask is referred to as "Docker Desktop" everywhere on the Docker website, so that's probably a better name.

Keep the shadowing but don't default to the formula and always require disambiguation.

I like this approach, though a combination with the rename is probably good. For example: the software in the Docker cask is referred to as "Docker Desktop" everywhere on the Docker website, so that's probably a better name.

I second this.  It may not make sense to rename all variations, but probably does for some, Docker being the notable example.  I think keeping disambiguation is a good idea if it doesn't cause continued confusion, and does force a user decision.
If there's a desire to rename conflicting items: it's probably worthwhile to have a consistent scheme, TBD if this is a route decided.  Keep the formula as-is with name, and have cask be name-prebuilt, name-upstream or something.

Keep the shadowing but don't default to the formula and always require disambiguation.

For example: the software in the Docker cask is referred to as "Docker Desktop" everywhere on the Docker website, so that's probably a better name.

Agreed here. I think that's an easy case to fix.

and does force a user decision.

We should avoid forcing user decisions in cases like this, particularly when we have analytics. We should decide for them and, if we install the wrong thing, they can choose to uninstall and install the right one.

If there's a desire to rename conflicting items: it's probably worthwhile to have a consistent scheme, TBD if this is a route decided. Keep the formula as-is with name, and have cask be name-prebuilt, name-upstream or something.

I don't think it makes sense universally.
I know Homebrew/cask doesn't historically like foo-app but: this feels most appropriate when installing a .app, to me.
Docker is a nice example, though, of where "Docker Desktop" is actually the name that upstream uses, too.

More often than not, this should involve renaming the cask.

In the current loader implementation, this is likely required as the old formula name will still be found before trying casks.
In order to rename a formula, we would want to adjust priority so that we select:

exact formula name (and maybe aliases?)
exact cask name
old formula names
old cask names

Or automatically drop old names after some timeframe (months/year).

current formula name (and maybe aliases?)
current cask name
old formula names
old cask names

FWIW I think this should be the order we load in regardless of the approach since at this point since casks are equally as official as formulae


Versioned configs

This looks like a neat lib but I have a small question about configuration and extensibility.
How would you handle a config that was initially setup say for version 1.0.0.
{
  "theme": "light"
}

Then in version 2.0.0 you add a new config option say telemetry. How would you expand the config to keep it backwards compatible?
I've seen something in zustand that solves this problem when persiting local storage by allowing versions numbers and migrations to exists. Would that besomething that should be added to this lib?
https://docs.pmnd.rs/zustand/integrations/persisting-store-data
Happy to hear thoughts on this as I'm actively considering switching to this for Overlayed.

Hi @Hacksore! That is a nice feature request, but I am not sure how best to implement this yet.
The library does handle defaults in the SettingsManager class, though. A non-existent field will be initialized with its default value, but deprecated fields will not be removed.

Note that this only works at the top level, so if a new field is added under the telemetry object, its default will not be added.
If you need more control than that, the best way to handle this right now would be to add a version field yourself or check for the existence of the telemetry field, add its value to the settings, and save the new settings.

The merge sounds sufficient, thanks!


[FEAT]: add nixos string for nix logo

Description
nixos and nix package manager has the same logo, i want it to be added on shortnames.
Additional Information
No response

Ok I'm going to look forward into that


WIP : Docker Compose with socketplane, docker-ovs and powerstrip containers. Please dont merge.

This PR depends on #144 entirely. I opened this to get inputs from you guys.
Please dont merge.
Things to consider / discuss :

socketplane container still requires privileged=true. The capabilities SYS_ADMIN & NET_ADMIN are not enough in order for us to manipulate other container's namespace.
Please note that docker-compose cfgs are not a very programmable entity. In order to use it effectively (such as modprobe openvswitch), we need to have some external logic in the script that compensates for the lack of programmability in docker-compose config files. This commit doesn't address the scripting changes. It will be addressed in subsequent commits.

Signed-off-by: Madhu Venugopal<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
http://jenkins.socketplane.io/job/socketplane-verify/54/
Test PASSed.

@mavenugo re: permissions, I'd rather we identify what we need from here than use privileged. Intrigued as to why SYS_ADMIN and NET_ADMIN are not sufficient (I wonder if this could be an issue with AppArmor/SELinux rather than permissions)
Why do we need /var/run/docker.sock and /usr/bin/docker inside the socketplane container?

@dave-tucker @mavenugo The reason why passing these capabilities are not effective is because socketplane container is launched in it's own user namespace and because of that these capability set is only applicable to manipulate things in that namespace. Since you are trying to manipulate the netdev for example to change it's namespace, the kernel checks if the netdev's user namespace is the same as the user namespace of the caller of the netlink api and only if that is the case or if the caller namespace is one of the parent usernamespace of netdev, only then the kernel will check if the capability to preform the operation(in this case CAP_NET_ADMIN) is available. Currently it looks like there is no way to launch docker containers in the host user namespace or the caller user namespace.

Refer to this link for build results (access rights to CI server needed):
http://jenkins.socketplane.io/job/socketplane-verify/58/
Test PASSed.


disable supabase type check action github

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3209   👈

This comment was auto-generated by Graphite.


golint on some pkg/* packages

I started to work on golint the pkg/* package 🐸.

pkg/useragent
pkg/units
pkg/ulimit
pkg/truncindex
pkg/timeoutconn
pkg/term
pkg/tarsum
pkg/tailfile
pkg/systemd
pkg/stringutils
pkg/stringid
pkg/streamformatter
pkg/sockets
pkg/signals
pkg/proxy
pkg/progressreader
pkg/pools
pkg/plugins
pkg/pidfile
pkg/parsers
pkg/parsers/filters
pkg/parsers/kernel
pkg/parsers/operatingsystem

Few TODOs :

[X] pkg/term/winconsole see comments below.
[X] Add some package documentation

This PR is part of #14756 🐧. It also covers a bit of #11578.
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

In pkg/ulimit, golint doesn't really like the const (https://github.com/docker/docker/blob/master/pkg/ulimit/ulimit.go#L27). I'm wondering how to change that though..

@vdemeester This is a good start. I've added some "erroneous" comments around some style issues which might be out of scope for this PR. Feel free to ignore them.
The only feedback I have is to make sure the comments provide more insight that what the function signature provides. Most users come to the godoc to understand why. I understand this can be hard in a sprawling code base, but it is okay to leave a small TODO or question near these comments, indicating more study needs to be done to get to the bottom of this.
Thank you for putting on your archaeologists hat!

@aaronlehmann Thanks a lot for all the typos I've made :blush: :wink:.
@stevvooe Yeah I totally agree on the comments, it has to provide more information than just the name of the function in human readable form. It's not always easy (most on the "why we did that" because there is some history I missed). Overall it's a great exercice to do.

Thanks so much for taking the time to incorporate my feedback. The new diff looks really good. I pointed out a few minor things but it's almost ready to go.

LGTM from a Windows perspective. FYI, https://github.com/docker/docker/pull/14838 will change the winconsole stuff, so I would hold on that for a separate PR.

@jhowardmsft sounds good to me for winconsole :)
@aaronlehmann np :wink:, thans so much for taking the time to make such feedback !!
I'm wondering something, which one is better between :
type VersionInfo struct {
	Kernel int    // Version of the kernel (e.g. 4.1.2-generic -> 4)
	Major  int    // Major part of the kernel version (e.g. 4.1.2-generic -> 1)
	Minor  int    // Minor part of the kernel version (e.g. 4.1.2-generic -> 2)
	Flavor string // Flavor of the kernel version (e.g. 4.1.2-generic -> generic)
}

and:
type VersionInfo struct {
	// Version of the kernel (e.g. 4.1.2-generic -> 4)
	Kernel int
	// Major part of the kernel version (e.g. 4.1.2-generic -> 1)
	Major int
	// Minor part of the kernel version (e.g. 4.1.2-generic -> 2)
	Minor int
	// Flavor of the kernel version (e.g. 4.1.2-generic -> generic)
	Flavor string
}

Rebased and added some package documentation.

needs rebase sorry

feel free to ping me after for merge

@jfrazelle rebased, let's hope janky is a little happier this time :stuck_out_tongue_closed_eyes:.

LGTM effing dev/urandom errors

:tada:


States are too verbos..

Currently the states contain properties and values which are identical to the default state. Before the state gets serialized into the url, it shoul dbe strippe dof any value which is identical to the default.
http://www.gapminder.org/tools/mountain#_entities_select@_geo=chl&labelOffset@:0&:0;;&_geo=khm&labelOffset@:0&:0;;&_geo=bwa&labelOffset@:0&:0;;;&needUpdate_;;&marker_axis%2F_y_min:0&max:2568192312.136342&fakeMin:0&fakeMax:2568192312.136342;&axis%2F_x_fakeMin:0.11&fakeMax:500;&color_palette_asi=%23FF5872&eur=%23FFE700&ame=%237FEB00&afr=%2300D5E9&%2F_default=%23ffb600

That's funny, this should be fixed already

Should have been re-fixed by the Yule goat


App crashes on launch

The app is crashing on launch due to failure access
if let image = icon.value?.image {
        hasher.combine(image.hashValue)
}

Could you paste the file name and line number?

@eviltofu its in TokenObject.swift line number 99


stdin argument used more than once when argument is not in the final subcommand

MRE
use clap::{Parser, Subcommand};
use clap_stdin::FileOrStdin;

#[derive(Parser)]
struct Cli {
    #[clap(default_value = "-", global = true)]
    file: FileOrStdin,

    #[clap(subcommand)]
    command: Command,
}

#[derive(Subcommand)]
enum Command {
    Foo,
}

fn main() {
    let _ = Cli::parse();
}

Then run the resulting binary as <binary> foo:

If this isn't solveable, a feature that disables the "more than one stdin" check would be useful for cases where there is only a single file.
(note that <binary> foo <filehere> works, as expected)

A workaround for the default not working is to set it to "/dev/stdin" instead, as that's a "normal file"

@RGBCube thank you for reporting!! I believe you are running into this issue because of the default=true clap option for the arg. If I remove that, the example seems to work as expected.
The incompatibility ended up being from a side affect of checking for stdin usage when args are parsed instead of when stdin is actually read from.  #10 fixes the issue by doing the duplicate stdin check on read, as I probably originally intended since it matches how I explain it in the doc.
Please feel free to test that PR  (I confirmed it works with your example above) and let me know if that resolves the issue. If so, I'll merge and release a new version soon.

default=true clap option for the arg. If I remove that, the example seems to work as expected.

(i suppose you mean global=true)
This PR indeed fixes it, but won't this regress program behavior?
If I'm understanding correctly, if I accepted two FileOrStdins and the user passed in - -, the cli error wouldn't be printed until after the first stdin is read & the second one attempted. This isn't great, since it could have been determined at the start.
What if instead of this, the argument was checked when the FileOrStdin was created, and the atomic was changed when it was? So when clap tries to construct the second FileOrStdin with once again -, the error message could be printed & the program could exit.

Ah, after looking at the changes, this was already the case before. Disregard my previous comment then :)
After thinking a little more about it, I can actually see the "lazy" behavior being useful for flags which are accessed based on behavior.

(i suppose you mean global=true)

whoops, yes, global=true :)

What if instead of this, the argument was checked when the FileOrStdin was created, and the atomic was changed when it was? So when clap tries to construct the second FileOrStdin with once again -, the error message could be printed & the program could exit.

This is what the previous code did, but that seems to be an issue with global=true as clap must be creating the arg instance twice for each level of commands?

Fix released in v0.5.0


update

I think most of your changes have already been implemented in the master branch. Please rebase and check if anything is left to add.

Closing this for now because of inactivity


[#647][FOLLOWUP] set coordinator id before ApplicationMaster

What changes were proposed in this pull request?
set coordinator id before ApplicationMaster construction, otherwise uuid is used for  AbstractSelectStorageStrategy
Why are the changes needed?
Follow up of #647
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Manually verified

Codecov Report

Merging #654 (45a7d10) into master (dd50282) will increase coverage by 2.31%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #654      +/-   ##
============================================
+ Coverage     60.60%   62.92%   +2.31%
- Complexity     1799     1801       +2
============================================
  Files           216      202      -14
  Lines         12458    10494    -1964
  Branches       1052     1052
============================================
- Hits           7550     6603     -947
+ Misses         4500     3545     -955
+ Partials        408      346      -62

Impacted Files
Coverage Δ

.../apache/uniffle/coordinator/CoordinatorServer.java
57.37% <100.00%> (ø)

...oy/kubernetes/operator/pkg/utils/shufflerserver.go

...bernetes/operator/pkg/controller/controller/rss.go

...pkg/controller/sync/shuffleserver/shuffleserver.go

...oy/kubernetes/operator/pkg/controller/util/util.go

...eploy/kubernetes/operator/pkg/utils/coordinator.go

...tor/pkg/controller/sync/coordinator/coordinator.go

deploy/kubernetes/operator/pkg/utils/config.go

...y/kubernetes/operator/pkg/webhook/inspector/pod.go

deploy/kubernetes/operator/pkg/utils/rss.go

... and 6 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Merged to Master & 0.7 thanks @advancedxy


feat(eva-icons): add eva-icons module

Please read and mark the following check list before creating a pull request:

[x] I read and followed the CONTRIBUTING.md guide.
[x] I read and followed the New Feature Checklist guide.

Short description of what this resolves:
Adds icons module and Icon component
Closes #522

Merge the master in this branch


Rag review merge with master

In development but working.  To test you'll want to create a virtual environment so that cleanup is easy.
Using virtualenv with python3 insures that python invokes py3.5 and python3 invokes py36.  Invoke python36.
$ mkdir dev
$ cd dev
$ virtualenv PackageTest --python=python3
$ source activate PackageTest
$ cd PackageTest
$ pip install cookiecutter
$ git clone -b RAG-Review http;//github.com/datasnakes/Datasnakes-Scripts
$ cd Datasnakes-Scripts
$ python3 tester.py

After the test script runs you should get something similar to the output below.  If you get something different then fix and push or add the errors here.
(cookietest) rgilmore@gpcr-orthologs-project:~/dev/cookietest/Datasnakes-Scripts$ python3 tester.py
Collecting Flask==0.12.1 (from -r requirements/prod.txt (line 4))
  Using cached Flask-0.12.1-py2.py3-none-any.whl
Requirement already satisfied: MarkupSafe==1.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 5))
Collecting Werkzeug==0.12.1 (from -r requirements/prod.txt (line 6))
  Using cached Werkzeug-0.12.1-py2.py3-none-any.whl
Requirement already satisfied: Jinja2==2.9.6 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 7))
Collecting itsdangerous==0.24 (from -r requirements/prod.txt (line 8))
  Using cached itsdangerous-0.24.tar.gz
Requirement already satisfied: click>=5.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 9))
Collecting Flask-SQLAlchemy==2.2 (from -r requirements/prod.txt (line 12))
  Using cached Flask_SQLAlchemy-2.2-py2.py3-none-any.whl
Collecting psycopg2==2.7.1 (from -r requirements/prod.txt (line 13))
  Downloading psycopg2-2.7.1-cp35-cp35m-manylinux1_x86_64.whl (2.7MB)
    100% |████████████████████████████████| 2.7MB 247kB/s
Collecting SQLAlchemy==1.1.9 (from -r requirements/prod.txt (line 14))
  Using cached SQLAlchemy-1.1.9.tar.gz
Collecting Flask-Migrate==2.0.3 (from -r requirements/prod.txt (line 17))
  Using cached Flask-Migrate-2.0.3.tar.gz
Collecting Flask-WTF==0.14.2 (from -r requirements/prod.txt (line 20))
  Using cached Flask_WTF-0.14.2-py2.py3-none-any.whl
Collecting WTForms==2.1 (from -r requirements/prod.txt (line 21))
Collecting gunicorn>=19.1.1 (from -r requirements/prod.txt (line 24))
  Using cached gunicorn-19.7.1-py2.py3-none-any.whl
Collecting Flask-Assets==0.12 (from -r requirements/prod.txt (line 27))
  Using cached Flask-Assets-0.12.tar.gz
Collecting cssmin>=0.2.0 (from -r requirements/prod.txt (line 28))
  Using cached cssmin-0.2.0.tar.gz
Collecting jsmin>=2.0.11 (from -r requirements/prod.txt (line 29))
  Using cached jsmin-2.2.2.tar.gz
Collecting Flask-User==0.6.11 (from -r requirements/prod.txt (line 32))
  Using cached Flask-User-0.6.11.tar.gz
Collecting Flask-Login==0.4.0 (from -r requirements/prod.txt (line 35))
  Using cached Flask_Login-0.4.0-py2.py3-none-any.whl
Collecting Flask-Bcrypt==0.7.1 (from -r requirements/prod.txt (line 36))
  Using cached Flask-Bcrypt-0.7.1.tar.gz
Collecting Flask-Caching>=1.0.0 (from -r requirements/prod.txt (line 39))
  Using cached Flask_Caching-1.2.0-py2.py3-none-any.whl
Collecting Flask-DebugToolbar==0.10.1 (from -r requirements/prod.txt (line 42))
  Using cached Flask_DebugToolbar-0.10.1-py2.py3-none-any.whl
Collecting alembic>=0.6 (from Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
Collecting Flask-Script>=0.6 (from Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
  Using cached Flask-Script-2.0.5.tar.gz
Collecting webassets>=0.11.1 (from Flask-Assets==0.12->-r requirements/prod.txt (line 27))
  Using cached webassets-0.12.1.tar.gz
Collecting passlib (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
  Using cached passlib-1.7.1-py2.py3-none-any.whl
Collecting bcrypt (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
  Downloading bcrypt-3.1.3-cp35-cp35m-manylinux1_x86_64.whl (54kB)
    100% |████████████████████████████████| 61kB 5.1MB/s
Collecting pycryptodome (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
  Using cached pycryptodome-3.4.5.tar.gz
Collecting Flask-Mail (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
  Using cached Flask-Mail-0.9.1.tar.gz
Collecting Blinker (from Flask-DebugToolbar==0.10.1->-r requirements/prod.txt (line 42))
  Using cached blinker-1.4.tar.gz
Collecting python-editor>=0.3 (from alembic>=0.6->Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
  Using cached python-editor-1.0.3.tar.gz
Collecting Mako (from alembic>=0.6->Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
  Using cached Mako-1.0.6.tar.gz
Collecting cffi>=1.1 (from bcrypt->Flask-User==0.6.11->-r requirements/prod.txt (line 32))
  Downloading cffi-1.10.0-cp35-cp35m-manylinux1_x86_64.whl (406kB)
    100% |████████████████████████████████| 409kB 2.6MB/s
Requirement already satisfied: six>=1.4.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from bcrypt->Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Collecting pycparser (from cffi>=1.1->bcrypt->Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Building wheels for collected packages: itsdangerous, SQLAlchemy, Flask-Migrate, Flask-Assets, cssmin, jsmin, Flask-User, Flask-Bcrypt, Flask-Script, webassets, pycryptodome, Flask-Mail, Blinker, python-editor, Mako
  Running setup.py bdist_wheel for itsdangerous ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/fc/a8/66/24d655233c757e178d45dea2de22a04c6d92766abfb741129a
  Running setup.py bdist_wheel for SQLAlchemy ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/62/c3/8f/12a643439a7ba36143e21533ac633b99da8537b1deb8d0f0c3
  Running setup.py bdist_wheel for Flask-Migrate ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/4f/1a/cd/241202c77554d1500b47f169a59432c33834f941e90769bf0e
  Running setup.py bdist_wheel for Flask-Assets ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/d9/1b/68/03cff4faa9c5c8a37202d96a6a6015cfc5e4a804ae93b26887
  Running setup.py bdist_wheel for cssmin ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/c3/79/88/647f59be446af4e9867362ca6e961cc7f218bd793fbdc351a6
  Running setup.py bdist_wheel for jsmin ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/fb/5f/9f/8c4a6aaa73d81713a9080d0a7a541da3dc613934eb66ccebcf
  Running setup.py bdist_wheel for Flask-User ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/78/89/c6/ec2a111b328d353812ecfad5e2be522961de561f6d986475b7
  Running setup.py bdist_wheel for Flask-Bcrypt ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/d5/e7/b5/396663b38fada7b0b7d9698cbdfb356ed7d4718c59855b1a52
  Running setup.py bdist_wheel for Flask-Script ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/e2/ea/d8/8d114e46cef819f7d9879504a7f9cb2a88a479af2858223d9f
  Running setup.py bdist_wheel for webassets ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/9d/cb/c2/340b9b695822b6954840bcb6cd147b3a7cfc2bcd922296e63e
  Running setup.py bdist_wheel for pycryptodome ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/82/80/08/e4cb0e06e4df5c5104899de9018e1829683c28c0ee9c45f4a1
  Running setup.py bdist_wheel for Flask-Mail ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/b5/f8/fb/a2c4ba26c9e4a56d034b410deea2c3bfb9b1a21fed2e245f76
  Running setup.py bdist_wheel for Blinker ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/7b/8a/eb/5a4f4444f366c515073db8a129c92d4727ad945e5e64b9e8bd
  Running setup.py bdist_wheel for python-editor ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/84/d6/b8/082dc3b5cd7763f17f5500a193b6b248102217cbaa3f0a24ca
  Running setup.py bdist_wheel for Mako ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/34/be/28/7999aa61d80a775c9e85a5a7d345777f73e87e6e30573e9551
Successfully built itsdangerous SQLAlchemy Flask-Migrate Flask-Assets cssmin jsmin Flask-User Flask-Bcrypt Flask-Script webassets pycryptodome Flask-Mail Blinker python-editor Mako
Installing collected packages: Werkzeug, itsdangerous, Flask, SQLAlchemy, Flask-SQLAlchemy, psycopg2, python-editor, Mako, alembic, Flask-Script, Flask-Migrate, WTForms, Flask-WTF, gunicorn, webassets, Flask-Assets, cssmin, jsmin, passlib, pycparser, cffi, bcrypt, pycryptodome, Flask-Login, Blinker, Flask-Mail, Flask-User, Flask-Bcrypt, Flask-Caching, Flask-DebugToolbar
Successfully installed Blinker-1.4 Flask-0.12.1 Flask-Assets-0.12 Flask-Bcrypt-0.7.1 Flask-Caching-1.2.0 Flask-DebugToolbar-0.10.1 Flask-Login-0.4.0 Flask-Mail-0.9.1 Flask-Migrate-2.0.3 Flask-SQLAlchemy-2.2 Flask-Script-2.0.5 Flask-User-0.6.11 Flask-WTF-0.14.2 Mako-1.0.6 SQLAlchemy-1.1.9 WTForms-2.1 Werkzeug-0.12.1 alembic-0.9.1 bcrypt-3.1.3 cffi-1.10.0 cssmin-0.2.0 gunicorn-19.7.1 itsdangerous-0.24 jsmin-2.2.2 passlib-1.7.1 psycopg2-2.7.1 pycparser-2.17 pycryptodome-3.4.5 python-editor-1.0.3 webassets-0.12.1
Requirement already satisfied: Flask==0.12.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 4))
Requirement already satisfied: MarkupSafe==1.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 5))
Requirement already satisfied: Werkzeug==0.12.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 6))
Requirement already satisfied: Jinja2==2.9.6 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 7))
Requirement already satisfied: itsdangerous==0.24 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 8))
Requirement already satisfied: click>=5.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 9))
Requirement already satisfied: Flask-SQLAlchemy==2.2 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 12))
Requirement already satisfied: psycopg2==2.7.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 13))
Requirement already satisfied: SQLAlchemy==1.1.9 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 14))
Requirement already satisfied: Flask-Migrate==2.0.3 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 17))
Requirement already satisfied: Flask-WTF==0.14.2 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 20))
Requirement already satisfied: WTForms==2.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 21))
Requirement already satisfied: gunicorn>=19.1.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 24))
Requirement already satisfied: Flask-Assets==0.12 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 27))
Requirement already satisfied: cssmin>=0.2.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 28))
Requirement already satisfied: jsmin>=2.0.11 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 29))
Requirement already satisfied: Flask-User==0.6.11 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 32))
Requirement already satisfied: Flask-Login==0.4.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 35))
Requirement already satisfied: Flask-Bcrypt==0.7.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 36))
Requirement already satisfied: Flask-Caching>=1.0.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 39))
Requirement already satisfied: Flask-DebugToolbar==0.10.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from -r requirements/prod.txt (line 42))
Collecting pytest==3.0.7 (from -r requirements/dev.txt (line 5))
  Using cached pytest-3.0.7-py2.py3-none-any.whl
Collecting WebTest==2.0.27 (from -r requirements/dev.txt (line 6))
  Using cached WebTest-2.0.27-py2.py3-none-any.whl
Collecting factory-boy==2.8.1 (from -r requirements/dev.txt (line 7))
  Using cached factory_boy-2.8.1-py2.py3-none-any.whl
Collecting flake8==3.3.0 (from -r requirements/dev.txt (line 10))
  Using cached flake8-3.3.0-py2.py3-none-any.whl
Collecting flake8-blind-except==0.1.1 (from -r requirements/dev.txt (line 11))
  Using cached flake8-blind-except-0.1.1.tar.gz
Collecting flake8-debugger==1.4.0 (from -r requirements/dev.txt (line 12))
  Using cached flake8-debugger-1.4.0.tar.gz
Collecting flake8-docstrings==1.0.3 (from -r requirements/dev.txt (line 13))
  Using cached flake8_docstrings-1.0.3-py2.py3-none-any.whl
Collecting flake8-isort==2.2 (from -r requirements/dev.txt (line 14))
  Using cached flake8-isort-2.2.tar.gz
Collecting flake8-quotes==0.9.0 (from -r requirements/dev.txt (line 15))
  Using cached flake8-quotes-0.9.0.tar.gz
Collecting isort==4.2.5 (from -r requirements/dev.txt (line 16))
  Using cached isort-4.2.5-py2.py3-none-any.whl
Collecting pep8-naming==0.4.1 (from -r requirements/dev.txt (line 17))
  Using cached pep8_naming-0.4.1-py2.py3-none-any.whl
Requirement already satisfied: Flask-Script>=0.6 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
Requirement already satisfied: alembic>=0.6 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
Requirement already satisfied: webassets>=0.11.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-Assets==0.12->-r requirements/prod.txt (line 27))
Requirement already satisfied: bcrypt in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: pycryptodome in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: Flask-Mail in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: passlib in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: Blinker in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Flask-DebugToolbar==0.10.1->-r requirements/prod.txt (line 42))
Requirement already satisfied: setuptools in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from pytest==3.0.7->-r requirements/dev.txt (line 5))
Collecting py>=1.4.29 (from pytest==3.0.7->-r requirements/dev.txt (line 5))
  Using cached py-1.4.33-py2.py3-none-any.whl
Collecting waitress>=0.8.5 (from WebTest==2.0.27->-r requirements/dev.txt (line 6))
  Using cached waitress-1.0.2-py2.py3-none-any.whl
Requirement already satisfied: six in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from WebTest==2.0.27->-r requirements/dev.txt (line 6))
Collecting WebOb>=1.2 (from WebTest==2.0.27->-r requirements/dev.txt (line 6))
  Using cached WebOb-1.7.2-py2.py3-none-any.whl
Collecting beautifulsoup4 (from WebTest==2.0.27->-r requirements/dev.txt (line 6))
  Using cached beautifulsoup4-4.6.0-py3-none-any.whl
Collecting Faker>=0.7.0 (from factory-boy==2.8.1->-r requirements/dev.txt (line 7))
  Using cached Faker-0.7.12-py2.py3-none-any.whl
Collecting pyflakes<1.6.0,>=1.5.0 (from flake8==3.3.0->-r requirements/dev.txt (line 10))
  Using cached pyflakes-1.5.0-py2.py3-none-any.whl
Collecting mccabe<0.7.0,>=0.6.0 (from flake8==3.3.0->-r requirements/dev.txt (line 10))
  Using cached mccabe-0.6.1-py2.py3-none-any.whl
Collecting pycodestyle<2.4.0,>=2.0.0 (from flake8==3.3.0->-r requirements/dev.txt (line 10))
  Using cached pycodestyle-2.3.1-py2.py3-none-any.whl
Collecting flake8-polyfill (from flake8-docstrings==1.0.3->-r requirements/dev.txt (line 13))
  Using cached flake8_polyfill-1.0.1-py2.py3-none-any.whl
Collecting pydocstyle (from flake8-docstrings==1.0.3->-r requirements/dev.txt (line 13))
  Using cached pydocstyle-2.0.0-py2.py3-none-any.whl
Collecting testfixtures (from flake8-isort==2.2->-r requirements/dev.txt (line 14))
  Using cached testfixtures-4.13.5-py2.py3-none-any.whl
Requirement already satisfied: python-editor>=0.3 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from alembic>=0.6->Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
Requirement already satisfied: Mako in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from alembic>=0.6->Flask-Migrate==2.0.3->-r requirements/prod.txt (line 17))
Requirement already satisfied: cffi>=1.1 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from bcrypt->Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: packaging>=16.8 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from setuptools->pytest==3.0.7->-r requirements/dev.txt (line 5))
Requirement already satisfied: appdirs>=1.4.0 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from setuptools->pytest==3.0.7->-r requirements/dev.txt (line 5))
Requirement already satisfied: python-dateutil>=2.4 in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from Faker>=0.7.0->factory-boy==2.8.1->-r requirements/dev.txt (line 7))
Collecting snowballstemmer (from pydocstyle->flake8-docstrings==1.0.3->-r requirements/dev.txt (line 13))
  Using cached snowballstemmer-1.2.1-py2.py3-none-any.whl
Requirement already satisfied: pycparser in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from cffi>=1.1->bcrypt->Flask-User==0.6.11->-r requirements/prod.txt (line 32))
Requirement already satisfied: pyparsing in /home/rgilmore/dev/cookietest/lib/python3.5/site-packages (from packaging>=16.8->setuptools->pytest==3.0.7->-r requirements/dev.txt (line 5))
Building wheels for collected packages: flake8-blind-except, flake8-debugger, flake8-isort, flake8-quotes
  Running setup.py bdist_wheel for flake8-blind-except ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/13/e0/ec/30c1e770f71fb83dcd50721f138a669feb8c3996a82dc31053
  Running setup.py bdist_wheel for flake8-debugger ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/cb/fa/60/a44ffc95136b4b5ad902d496a63433889bb99adc9d8ed36fdd
  Running setup.py bdist_wheel for flake8-isort ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/17/da/52/8d07e03afddf3bac2e5d1d107df77fc3e2f66512090c3c387f
  Running setup.py bdist_wheel for flake8-quotes ... done
  Stored in directory: /home/rgilmore/.cache/pip/wheels/5a/6c/5e/bb619552bda8cde937b69cd03496f90af2edccc06bc79e5cba
Successfully built flake8-blind-except flake8-debugger flake8-isort flake8-quotes
Installing collected packages: py, pytest, waitress, WebOb, beautifulsoup4, WebTest, Faker, factory-boy, pyflakes, mccabe, pycodestyle, flake8, flake8-blind-except, flake8-debugger, flake8-polyfill, snowballstemmer, pydocstyle, flake8-docstrings, isort, testfixtures, flake8-isort, flake8-quotes, pep8-naming
Successfully installed Faker-0.7.12 WebOb-1.7.2 WebTest-2.0.27 beautifulsoup4-4.6.0 factory-boy-2.8.1 flake8-3.3.0 flake8-blind-except-0.1.1 flake8-debugger-1.4.0 flake8-docstrings-1.0.3 flake8-isort-2.2 flake8-polyfill-1.0.1 flake8-quotes-0.9.0 isort-4.2.5 mccabe-0.6.1 pep8-naming-0.4.1 py-1.4.33 pycodestyle-2.3.1 pydocstyle-2.0.0 pyflakes-1.5.0 pytest-3.0.7 snowballstemmer-1.2.1 testfixtures-4.13.5 waitress-1.0.2
bower invalid-meta  for:/home/rgilmore/dev/cookietest/Datasnakes-Scripts/Tester/web/flask/Vall/bower.json
bower invalid-meta  The "name" is recommended to be lowercase, can contain digits, dots, dashes
bower cached        https://github.com/twbs/bootstrap.git#3.2.0
bower validate      3.2.0 against https://github.com/twbs/bootstrap.git#~3.2.0
bower cached        https://github.com/jquery/jquery-dist.git#3.2.1
bower validate      3.2.1 against https://github.com/jquery/jquery-dist.git#>= 1.9.1
bower cached        https://github.com/jquery/jquery.git#2.1.4
bower validate      2.1.4 against https://github.com/jquery/jquery.git#~2.1.3
bower install       jquery#3.2.1
bower install       jQuery#2.1.4
bower install       bootstrap#3.2.0

jquery#3.2.1 Vall/static/libs/jquery

jQuery#2.1.4 Vall/static/libs/jQuery

bootstrap#3.2.0 Vall/static/libs/bootstrap
└── jquery#3.2.1
 * Serving Flask app "autoapp"
 * Forcing debug mode on
 * Running on http://<IP_ADDRESS>:5252/ (Press CTRL+C to quit)
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 199-030-873

I'm excited to test this out in the am @grabear. Looks good. Should give us an opportunity to really test out everything and ensure things can work seamlessly.

Good deal.  Today I'm going to make this into a PyPi package at a low development stage so we can use it with the python interpreter.


Indexing CC-100 Corpus

Codecov Report

Merging #1873 (082352e) into master (2330d24) will increase coverage by 0.08%.
The diff coverage is 73.21%.

@@             Coverage Diff              @@
##             master    #1873      +/-   ##
============================================
+ Coverage     57.62%   57.70%   +0.08%
- Complexity     1058     1061       +3
============================================
  Files           179      180       +1
  Lines         10272    10328      +56
  Branches       1417     1425       +8
============================================
+ Hits           5919     5960      +41
- Misses         3852     3862      +10
- Partials        501      506       +5

Impacted Files
Coverage Δ

.../anserini/collection/CommonCrawl100Collection.java
73.21% <73.21%> (ø)

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 2330d24...082352e. Read the comment docs.


Add optional rust features for functions in library to keep dependencies down

Note: migrated from original JIRA: https://issues.apache.org/jira/browse/ARROW-11214
As we expand the numbers of functions available in DataFusion, DataFusion will likely pick up additional third-party dependencies. In general, I think it would be a nice feature for DataFusion to  allow users more fine grained control over the features that they wanted to use (and pay the subsequently higher compilation / link time (and binary size) cost. At the moment, with a single codebase and no feature flags, everyone's compile time and binary size will increase even if they don't use a specific set of features.
It seems to me like we might want to start offering a way to keep the number of required dependencies of DataFusion down. For example, in the case of https://github.com/apache/arrow/pull/9139, we could potentially put the use of crypto functions behind a feature flag. Users of DataFusion could then pick a subset of features  like "core" and "func-datetime" and "func-crypto" to have more control over the dependencies they pulled in

This issue looks obsolete. Use of feature flags such as avro are now used to control dependency scope.

Closing this. Thanks @drauschenbach.


0.7.x breaks the pattern matching in get method

Hi there,
We have been using Grapnel router in our project, and it works really well for our requirements, so we want to keep using it.
However we have had an issue when upgrading the library from version 0.6.4 to 0.7.2 because the router.get method does not bind the specified path pattern to the given function. It only works as expected for the wildcard '*'.
So the following works as expected and myHandler gets fired for the wildcard '*':
const router = new Grapnel({ pushState: true, root: MY_ROOT })
router.grapnel.get('*', myHandler);

For any other path pattern value different than '*' however the handler is never fired. For example:
const router = new Grapnel({ pushState: true, root: MY_ROOT })
router.grapnel.get('/:learningLanguage/:flowId', myHandler);

After doing some research we found out that the issue happens because of the following:

The add method is called by the get method

The route is created based on the fullPath value:

let req = route.parse(this.path());

The root is removed from the route:

let req = route.parse(this.path());

The script checks if the route matches the pattern after removing the root:

if (req.match) {

No matches are found so the function is not bound to the specified path

We found out that the solution to this issue is to use routePath instead of fullPath when creating the route as follows:
let route = new route_1.default(routePath);

We have addressed the issue in the following fork that we are currently using as a dependency in our project:
https://github.com/crisperpo/grapnel
We do not have the permissions to create a pull request from this fork to your repository, or to create a branch, so we have decided to raise this issue. It would be awesome if you could check it out, and help us address this :)

Let's get that fixed soon

@rockaBe @crisperpo  There was a problem with the build scripts. They've been reverted to 0.6.x's build system, so please update to the latest version<EMAIL_ADDRESS>


Test absence of element?

Hey, thanks for creating this library. I’m new to Elixir and happy to be able to test-drive my application.
One thing I’m accustomed to is being able to assert both the presence and absence of an element. For instance, if a user logs in as an admin, they should be able to see links to admin-only pages. I’d like to test for their absence when a non-admin logs in, but I can’t find anything like that.
Am I missing something? Is there some way to accomplish this you can suggest?

@backspace Matchers in Hound are very limited right now.
find_all_elements/3 returns a list of elements if a selector matches. You could do the following:
assert find_all_element(:css, "#foo") == []
I'll add a matcher in a few days.

Ah, that’s a good enough workaround for now! Thanks for the quick response.

There's now an element? helper in the master branch. You'll find it here - https://github.com/HashNuke/hound/blob/master/lib/hound/matchers.ex#L39-L49

:tada:


Column visibility

Hi !
Is it possible to hide or show column according to screen type.
For example, I have this html code:

I would like to hide the menu on mobile and show on tablet.
Best regards

http://beta.semantic-ui.com/collections/grid.html#device-visibility
http://semantic-ui.com/collections/grid.html#responsive-visibility


inconsistent licence

Your LICENSE is Simplified BSD, but your project file is Eclipse Public License.
Can you please clarify which licence you are releasing this software under? I will assume dual licence unless corrected :smile: (and I choose Simplified BSD).

Yes, simplified BSD. Will update project file, thanks!

the reason I ask is because I don't want the dependency on clj-http so I'm taking just the bits I need. I've been told that https://github.com/jcf/oauth/ will be the future, if you're not already it would be great if you could pool your resources and perhaps turn it into clj-oauth v2.

There's no reason for a dependency on clj-http. That was a requirement for a project this library was written for, but it should be changed. The clj-oauth functions should just return the params and headers for requests and let the user choose their own HTTP client. It looks like jcf's oauth is doing something similar to that. Out of curiosity, why use clj-oauth instead of jcf's oauth?
If you do end up updating clj-oauth to remove the clj-http dependency, I'll gladly accept a pull request.

I don't think I can remove clj-http without breaking your API but if you're OK doing that I might be able to put something together.
jcf's repo is very new and is "not yet released" according to the notes. Maybe something for the future.

Yes, I think the API will have to change, and that's OK. We'll make it a major version bump.
It may be possible to also provide "authentication workflow" function(s) which would require the user to provide functions for making and parsing HTTP requests and responses. This would help prevent the user from dealing directly with the OAuth workflow.

it's unlikely that I'll get round to this because I've just given myself the weekend to learn clojure and then I'm back to some pretty big commitments in Scala land (plus my wife has just informed me that the laptop has to go away :blush: )

Hah, no worries, it's something that's needed to be done for awhile. But with jcf's oauth lib, maybe it's time to deprecate clj-oauth in the near future.
Fixed the license mismatch in project.clj. Feel free to open up another issue if anything else comes up or you want to tinker with the clj-http removal.

I think it would be best if jcf's library becomes clj-oauth v2 actually, I really hate to see fragmentation.


Bucket-rewrite: the new and old blocks are combined by the compactor to create another block

Thanos, Prometheus and Golang version used:
Thanos: Using https://github.com/thanos-io/thanos/tree/aa148f8fdb28
Prometheus: prometheus, version 2.27.1
Golang: go1.16.6

What happened:
When running the bucket rewrite tool, it creates a new block, and the old one is marked for deletion.
The old block is not deleted right away, as it waits for the deletion delay to pass. However, while it is still marked for deletion, the compactor can still use it for compaction because it ignores the deletion marker for a period of time as explained here:
https://github.com/thanos-io/thanos/blob/aa148f8fdb28/cmd/thanos/compact.go#L224-L227.
When the compactor runs, and picks up the new and deleted block, it see's that there exists two blocks with overlapping time intervals and proceeds to combine them. Once combined, it creates a new block that has the old deleted data in it. The block created by the bucket rewrite tool is marked for deletion.
What you expected to happen:
That the new and old block are not merged together to create another block.
I think this occurs because the source blocks inside the meta.json file for the block are different. The original block has all of its source blocks, while the new block has only itself as the source blocks.
I think a possible fix for this is to add the source blocks inside the meta.json of the new block. I believe it would need to be the source blocks of the rewritten block + the rewritten block itself.  There could be other ways to handle this as well. There was some discussion in Cortex to not compact any block marked for deletion at all. This would fix this issue I believe. Seen here: https://github.com/cortexproject/cortex/pull/4328.
How to reproduce it (as minimally and precisely as possible):

Run the bucket rewrite tool on a block with the option to mark the old block for deletion.
Run the compactor soon after.
It should see the two blocks and proceed to combine them because of the overlapping time intervals to create a new block with the same data as the original block. The block without the deleted data created by the bucket rewrite, should be marked for deletion.

Full logs to relevant components:

Anything else we need to know:
I am running the bucket rewrite logic from inside of Cortex. I suspect that this issue is the same as it would be in Thanos, because the compactor is run inside of the Thanos code which calculates the overlapping blocks.

Yes, I have seen the same problem before and I think the solution makes sense to me.
I think this occurs because the source blocks inside the meta.json file for the block are different. The original block has all of its source blocks, while the new block has only itself as the source blocks.

I think a possible fix for this is to add the source blocks inside the meta.json of the new block. I believe it would need to be the source blocks of the rewritten block + the rewritten block itself.  There could be other ways to handle this as well. There was some discussion in Cortex to not compact any block marked for deletion at all. This would fix this issue I believe. Seen here: cortexproject/cortex#4328.

I was experimenting with setting the source of the new block to original block ID + the original block sources. I also added to the original block to the list of parent blocks (Not sure if this makes a difference). My thought process behind it was to make it similar to how compaction creates the meta.json file. Since after it creates the newly compacted block, it doesn't combine the new block with the smaller source blocks because the smaller blocks are part of the sources of the new block. I don't know if this is the best approach to solving this problem and it could confuse someone looking at the new meta.json file.
So if original block is BlockA,  With Sources: Block1, Block2
The rewritten block would be BlockB,  With Sources: Block1, Block2, BlockA

Another solution might be to add both a deletion marker and a no compact marker to the original block, this seems like the easiest way. WDYT?

One case that could potentially arise is that if a new block was recently created through regular compaction (Lets call it BlockA). The source blocks of BlockA are marked for deletion as per usual. If we were to rewrite the block (Creating BlockB), and place a no compact marker on BlockA, then it would avoid the issue of combining BlockA and BlockB. However, if BlockA was only recently created, then the ignoreDeletionMarkFilter might still have the compactor select the source blocks of BlockA for compaction. Then I think it will combine the source blocks of BlockA with BlockB because of the overlapping time intervals. I think this is a possible but I am not 100% sure. Please let me know your thoughts.

What about adding a new block metadata filter to filter the original block? As the original block ID is present in the new block metadata, we can remove the original block to avoid compacting it.

I think this makes a lot of sense. If the previous scenario described is also valid, then we would have to filter out all the original source blocks as well which are currently present in the bucket rewrite field inside of the meta.json file.


Editing area goes out of bound

When first open the app, it's normal:

When I click on another tab and come back, the editing area extends to outside of the window, therefore hiding the edit and share buttons:

@zhouanbo
Thanks for reporting this issue. What do mean by saying "click on another tab"? Do you mean choosing another gist?

Hi @hackjutsu,
Thanks for your attention! Yes, by saying "click on another tab", I mean choosing another gist. Extending the window doesn't really work because I have a really long code block in the mark down, it'll reveal more code by not enough.

Also pressing cmd+R to force electron re-render will work, but I think it's better to disable this debug function.

@zhouanbo
I met similar issue some time ago. It seems it happens only on markdown files, and goes away after re-rendering (when I noticed and clicked on Command+Option+i, it went away).
I have no clues what could be the culprit at this moment, nor could I reproduce it on my side. It might be caused by the react-split-pane module that makes the gist panel resizable, or the Chromium itself (We used to see a Chromium rendering issue which was solved after updated to a newer version of Electron).
I might need more time to observe and understand this weird issue.

@zhouanbo
Since Lepton is an open source product, I would like everyone to be able to debug it (if they like), and provide as mush as debug information when reporting issues. (To be honest, I don't have the bandwidth to investigate all issues by myself~ )
Therefore, I'll keep these debug features enabled.


Code reports errors in removed source files

From @jeffschwMSFT on February 19, 2016 18:13

On my OS X Yosemite machine running Code, I was adding/removing code in a solution.  One of the files I removed had a C# build error.  The interesting thing was the the error persisted in my Code session even after deleting the file (control - click - delete).  The error only went away once I closed the folder and reopened.
Copied from original issue: Microsoft/vscode#3174

From @egamma on February 20, 2016 15:12
Not clear whether this is Omnisharp or the Code marker infrastructure. The fact that the error count drops to 0 indicates that the marker is properly removed when the file is deleted.

From @dbaeumer on February 29, 2016 15:53
Since the error counts drops to zero I suspect this being a problem in OmniSharp land

Omnisharp doesn't really support delete...

I wanted to put this higher on the stack.  After using VS Code more I have found that this issue is even worse if you rename a file.  VS Code will always give you the error that XYZ class has already been defind.

I've recently come across this bug.

Introduce an error in your code. Remove a semi-colon or something.
Delete the file.

Expected: The error should go away.
Actual: The error stays in VSCode, even after editing other code. I did not observe the error count go down to 0; it remains at 1.
A workaround is to restart Omnisharp after deleting files.

We're going to use https://github.com/OmniSharp/omnisharp-vscode/issues/785 to track the file renaming issue. I believe the other issues mentioned here are addressed.


Support multiplatform

We can migrate to K2 and support Compose Multiplatform, it would be great to publish this lib to MavenCentral.

That actually looks good idea, if u have enough time that would be awesome to contribute.


A11y ignition button

Fixes #335
Ignition buttons look exactly the same, but behaves a bit better. The code might very well not be of your standards, but the functionality is now added.

Hi @boyum - please see my closing comment here: https://github.com/GetmeUK/ContentTools/issues/335


feat: add all command modules

Also made plugins optional on Executable classes.

I attempted to run eslint format, but it was denied due to //@ts-ignore's in the Executable Classes.

a little old, and i could figure out the correct typings for dis


fix AbortPolicyWithReport Semaphore lock not released

https://github.com/apache/dubbo/issues/13605
What is the purpose of the change
fix AbortPolicyWithReport Semaphore lock not released
Brief changelog

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1bdbfd8) 70.37% compared to head (071cf13) 70.37%.

Additional details and impacted files
@@            Coverage Diff             @@
##              3.2   #13609      +/-   ##
==========================================
- Coverage   70.37%   70.37%   -0.01%
==========================================
  Files        1606     1606
  Lines       69997    69998       +1
  Branches    10098    10098
==========================================
  Hits        49260    49260
  Misses      16111    16111
- Partials     4626     4627       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


window.dispatchEvent() on Lumia IE

So it seems that window.dispatchEvent(new Event('resize')); is responsible for throwing an error.
Related issues:
https://github.com/ftlabs/fastclick/issues/348
https://github.com/tdreyno/morlock.js/issues/5

Some more information from the conversation on irc:
window.onerror = function () { alert( JSON.stringify(arguments) ); };


Add prune command

Closes #44.

@tbateson, @troyaf, any thoughts on this?

@tbateson, @troyaf, any thoughts on this?

I have some thoughts but have been too busy to fully form them. I'll give a response soon.

Is the main concern that the prune command might remove packages that the user actually wants? If so, I could split this into 2 separate pull requests, with the first one adding the tracking ability to which packages the user is using and the second one actually implementing the prune command.
If the concern is with how this is implemented, please let me know. I designed this to work like the docker prune command. In docker, as you know, each layer is referenced by hash and the overall image is referenced by tag. When you repull, the image tag points at a new set of hashes. The old hashes are there and can still be used, but they will be pruned as soon as you run the prune command.
Likewise, the pwr packages are all referenced by tags, but they can be treated as both tags and hashes. For example, using jdk:17 as a tag will actually pull jdk:17.0.5. So, jdk:17 is the "name" and jdk:17.0.5 is the "hash". The user only wants jdk:17, so when jdk:17 pulls down the new version jdk:17.0.6, then jdk:17.0.5 becomes orphaned and is ripe for pruning. If the user actually wants jdk:17.0.5, they can use jdk:17.0.5 and it will be un-orphaned, and pwr will remember that the "name" jdk:17.0.5 maps to "hash" jdk:17.0.5 and "name" jdk:17 will still map to "hash" jdk:17.0.6.
To me, this logic makes sense. (And no extra configuration is needed, similar to docker.) If there is something else you are looking for, let me know. I am hoping to get this in soon, since time will be needed to build up the internal package map before pruning can actually be done.

I've updated this to include the things we talked about yesterday. I believe it is good-to-go. It stores the time the package is made "obsolete" (meaning it is no longer referenced), in addition to the association between the "reference" and the loaded tag. This will help with auto-pruning, by allowing packages to only be pruned after so many days of being orphaned.
One thing that is different from what we talked about is: I wasn't able to figure out a good way to consolidate the "load cache" updates to only when a package is downloaded. You could potentially already have a package downloaded when it is loaded (e.g., pwr load llvm:15.0.4 ... pwr load llvm), so I didn't want to lose the ability to capture this association.

I've updated this to include the things we talked about yesterday. I believe it is good-to-go. It stores the time the package is made "obsolete" (meaning it is no longer referenced), in addition to the association between the "reference" and the loaded tag. This will help with auto-pruning, by allowing packages to only be pruned after so many days of being orphaned.
One thing that is different from what we talked about is: I wasn't able to figure out a good way to consolidate the "load cache" updates to only when a package is downloaded. You could potentially already have a package downloaded when it is loaded (e.g., pwr load llvm:15.0.4 ... pwr load llvm), so I didn't want to lose the ability to capture this association.

I think we both still have different ideas of pruning.
The -DaysOld kept track of the last time a package was used, and based off some length of non-use, a package was considered prune worthy. I ultimately think time-based calculations are insufficient because there are many scenarios in which a user still wants a package to exist on their computer despite timing considerations.
Suppose I fetched rust locally to contribute to an open-source rust project. Then, I go on vacation, or focus on other work for a while. I would not want an arbitrary time-based system to delete my rust package since I still have a desire to use the package at any moment.
The docker analogy to this scenario would be one day I pull rust:latest. I should be able to come back a year later and docker run rust:latest without any hiccups--it should still be there exactly as it was despite any calls to prune. It is only when I re-pull rust:latest that the old version becomes orphaned and prune worthy.
This is the behavior I want to mimic. When pwr fetches a package, we store the reference (not resolved name) in a cache. Only on calls to prune do we resolve these references against our local packages. Any local packages not resolvable against the cache are prune worthy.
Explicit calls to remove is the only mechanism to remove a package reference from the fetch cache.
Say I pwr fetch go, go:1.18, jdk. All three of these references are stored in the fetch cache, then pwr uses the tag cache to actually download the packages.
The installed packages at this point might be [go-1.19.0, go-1.18.2, jdk-17.1.1]
Calling prune does nothing because all refs [go, go:1.18, jdk] resolve to all installed packages.
Say a new version of go is pushed to shipyard, 1.19.1. A call to prune should still do nothing because we only resolve the fetch cache against the local packages.
Now, suppose we pwr load go. This will trigger a fetch of go-1.19.1 meaning the next call to prune will leave go-1.19.0 orphaned.

Those are my thoughts, anyway.
You are keeping track of the load time. Is there a behavior you think is valuable from a timing perspective?

I've updated this to include the things we talked about yesterday. I believe it is good-to-go. It stores the time the package is made "obsolete" (meaning it is no longer referenced), in addition to the association between the "reference" and the loaded tag. This will help with auto-pruning, by allowing packages to only be pruned after so many days of being orphaned.
One thing that is different from what we talked about is: I wasn't able to figure out a good way to consolidate the "load cache" updates to only when a package is downloaded. You could potentially already have a package downloaded when it is loaded (e.g., pwr load llvm:15.0.4 ... pwr load llvm), so I didn't want to lose the ability to capture this association.

I think we both still have different ideas of pruning.
The -DaysOld kept track of the last time a package was used, and based off some length of non-use, a package was considered prune worthy. I ultimately think time-based calculations are insufficient because there are many scenarios in which a user still wants a package to exist on their computer despite timing considerations.
Suppose I fetched rust locally to contribute to an open-source rust project. Then, I go on vacation, or focus on other work for a while. I would not want an arbitrary time-based system to delete my rust package since I still have a desire to use the package at any moment.
The docker analogy to this scenario would be one day I pull rust:latest. I should be able to come back a year later and docker run rust:latest without any hiccups--it should still be there exactly as it was despite any calls to prune. It is only when I re-pull rust:latest that the old version becomes orphaned and prune worthy.
This is the behavior I want to mimic. When pwr fetches a package, we store the reference (not resolved name) in a cache. Only on calls to prune do we resolve these references against our local packages. Any local packages not resolvable against the cache are prune worthy.
Explicit calls to remove is the only mechanism to remove a package reference from the fetch cache.

This is exactly how this works. Once, you've pulled (fetch, load, or shell) rust:latest (or just rust), the package becomes referenced and is not eligible for pruning. The only way to make it eligible for pruning is when you pull a new version of rust. (You should see a message saying package rust:1.1.1 is eligible for pruning. That is when the timing mechanism kicks in. If you call prune explicitly, the old version will be removed (but the new version is still available). If you chose to enable auto-pruning, the old package will be removed after the specified number of days.
If you are testing this and seeing this issue, it is because the load cache is not populated. (There is no good way to initially populate the load cache, since we do not know how the user is loading packages. e.g., Are they doing a pwr sh rust or pwr sh rust:1.1.1? Do a pwr fetch rust or pwr sh rust on any existing packages to start populating the cache.) Essentially, pruning will not work correctly until the load cache is populated. The user will need to fetch, load, or sh all their packages before pruning is ready to be used.

Say I pwr fetch go, go:1.18, jdk. All three of these references are stored in the fetch cache, then pwr uses the tag cache to actually download the packages.
The installed packages at this point might be [go-1.19.0, go-1.18.2, jdk-17.1.1]
Calling prune does nothing because all refs [go, go:1.18, jdk] resolve to all installed packages.
Say a new version of go is pushed to shipyard, 1.19.1. A call to prune should still do nothing because we only resolve the fetch cache against the local packages.
Now, suppose we pwr load go. This will trigger a fetch of go-1.19.1 meaning the next call to prune will leave go-1.19.0 orphaned.
Those are my thoughts, anyway.
You are keeping track of the load time. Is there a behavior you think is valuable from a timing perspective?

The only timing used is to tag the time when a package is orphaned. And, it is only used for auto-pruning. The idea being that if someone has multiple pwr shells open, they may not want the old version to be pruned immediately, as that would mess up existing pwr shells. Or, if the user fetches a new version, realizes there is some bug or new "feature" that doesn't work with their workflow, they can then do a pwr sh my-package:0.9.0 to load the old version, and prevent the old version from being auto-pruned.

I guess I could initially assume that all packages are referenced by their package name only (e.g., vs-buildstools for vs-buildtools-17.2.3) to populate the load cache. While it may not be completely accurate, it would probably be accurate enough to initially populate the cache. That would prevent users from accidentally pruning packages they use before the load cache was properly populated. Thoughts?

I've updated this to include the initial population of the load cache.

I updated this to remove the last bit of documentation for the -DaysOld option.
FYI: I've been testing this by making copies of existing packages and renaming the copies as old versions. Then, I will manually change the load cache file to match whatever scenario I want to test and run prune. (Note that prune will remove unreferenced packages even if they aren't listed in the ObsoletePkgs list in the load cache.)
I did think of one more thing in this PR that uses time besides the auto-pruning (which isn't part of this PR, see https://github.com/nicklauslittle/airpwr/compare/add-prune...auto-prune). This PR uses time to detect "stale" packages, which are packages that aren't orphaned (they are still referenced in the load cache) but haven't been used (fetch, load, or shell) in over 180 days. These packages are never pruned but do result in messages of the form consider removing stale pwr packages: ... any time the prune command is run.

Say I pwr fetch go, go:1.18, jdk. All three of these references are stored in the fetch cache, then pwr uses the tag cache to actually download the packages.
The installed packages at this point might be [go-1.19.0, go-1.18.2, jdk-17.1.1]
Calling prune does nothing because all refs [go, go:1.18, jdk] resolve to all installed packages.
Say a new version of go is pushed to shipyard, 1.19.1. A call to prune should still do nothing because we only resolve the fetch cache against the local packages.
Now, suppose we pwr load go. This will trigger a fetch of go-1.19.1 meaning the next call to prune will leave go-1.19.0 orphaned.

For what it's worth, I ran this scenario with the following results:
PS > .\src\pwr.ps1 fetch go, go:1.18, jdk
pwr: fetching go:1.19.3
pwr: fetching go:1.18.4
pwr: fetching jdk:17.0.5
pwr: pkg\jdk-17.0.5 is not a pwr package; it should be removed manually # Ignore this, it's a bug that will be fixed momentarily
pwr: fetched 3 packages (go:1.19.3, go:1.18.4, jdk:17.0.5)
# Load Cache: {"Loads":["jdk:jdk-17.0.5","go:go-1.19.3","go:1.18:go-1.18.4"]}
PS > .\src\pwr.ps1 prune
# Nothing pruned
PS > # Modify tag cache from "go":["1.19.3"...] to "go":["1.19.4"...]
PS > .\src\pwr.ps1 prune
# Nothing pruned
PS > # Modify tag cache back to "go":["1.19.3"...], load cache to "go:go-1.19.2", move go-1.19.3 to go-1.19.2
PS > .\src\pwr.ps1 fetch go
pwr: fetching go:1.19.3
pwr: fetched 1 packages (go:1.19.3)
pwr: package go:1.19.2 is eligible for pruning
# Load Cache: {"ObsoletePkgs":["go-1.19.2:20221112T2250111485Z"],"Loads":["jdk:jdk-17.0.5","go:go-1.19.3","go:1.18:go-1.18.4"]}
PS > .\src\pwr.ps1 prune
pwr: pruning go:1.19.2 ... done
# Load Cache: {"Loads":["jdk:jdk-17.0.5","go:go-1.19.3","go:1.18:go-1.18.4"]}

I believe this matches exactly what you are expecting. If not, let me know.

I guess I could initially assume that all packages are referenced by their package name only (e.g., vs-buildstools for vs-buildtools-17.2.3) to populate the load cache. While it may not be completely accurate, it would probably be accurate enough to initially populate the cache. That would prevent users from accidentally pruning packages they use before the load cache was properly populated. Thoughts?

I would say no. If a user calls prune without -whatif, that's on them.


HUGE UPDATE

Added updating "Install Dependencies"
Added fb token check (to test if valid)
Removed useless duplicate dependencies
Separated CONFIG to  config.js for "clean" access
Fixed RestartTimer to be off if set to 0 (when set to 0 it would restart immediately)
Added Multiple fb accounts (NOT SIMULTANEOUS YET, USEFUL IF YOU HAVE MULTIPLE COMPUTERS/VPS)
Updated README.md
Fix for real bot count
Now bots move and collect food and also split 2 times (MORE XP)
Console now gets cleared on restart
Added restarTimer notification every minute (console.log())
Fixed server.key which was malused and resulted in "undefined"
Fixed "ballAppear" which is the wrong event to listen to ( It gets triggered by everything, even food) and set it to myNewBall
Removed old code
Added images in README.md
More overall stability
Many bugs fixed...
NOTE: NOW MORE RAM/CPU WILL BE USED AS THE BOTS NOW MOVE AND COLLECT FOOD -(MORE XP)...
MULTIPLE REGIONS
NOW MUCH FASTER XP, UPDATE...
-...

IF ANYTHING NOT WORKING, JUST LEAVE A COMMENT BELOW OR OPEN AN ISSUE...

For me it's working nice...  and when you update something plz dont revert the new code. as many (that are new to GitHub) do so

Ok, cool update ! Github say there is conficts, I will merge this when I go to my home.

Conflicts fixed... (Merge?)

@hassanila97 where download?

@hassanila97 solved, now the update is avaiable :)

Here: https://github.com/hassanila97/AGAR-XPBOT/archive/master.zip

@hassanila97 good work, now the code is more cleaner and easy to use with the new config :) from lvl 45 to 73 in one night x3 boost, 500 bots :D awesome

Np :)

For colletting money is a difficult part, cause isnt implemented in agar.io js, but with a good knowledge you could implement it, good work and thanks for share op

Ok i tested this and found it doesnt really have x5, maybe i should select only near servers? Using 2 tabs with x100 bots

I dont know maybe now its faster i deleted some servers very far from italy :D 200/500 exp every 10 seconds with x3 boost

@skillize I have a "fast pc" and run 3 tabs with 500 bots...   I got from LVL 5 TO 70 in 1.5 days   I selected all available servers...   So you need a fast pc or multiple pcs

@hassanila97 yeah i have a pc master race x'D gtx 970 i5 4590, maybe its net problem? are you using vps?

Yes I'm using both pc and vps...   with lan connection 250mbps

Yeah must be this, im level 74 i started with this bot from level 49 so isn't that bad in 2 days :P

Failed to request server (error=REQUEST_ERROR, error_source=Error: socket hang up)
now i put 300 bot on config, sometimes i get this error i think its with some servers but now its extremely fast :D 1 tab 300 bots

Yeah 800/1000 exp in 10 seconds, just use 1 tab and increment bots on cfg this will use your net in the same thread and you will get much faster exp, no need to open more tabs if you have slow net, consider this :)

I now use 2000 bots/pc and they work ubelievably fast and stable with no bugs or connection errors I will make many accounts and reach lvl 100..   USE BEFORE AGAR.IO PATCHES IT

@hassanila97 where u bought the vps?

Got it free one year 1gb ram Windows 2012r2..  From Amazon aws ec2

Oh gonna get this :D thanks i will get my acc lvl 100

Oh you must use a cc..

Yes you need a valid cc and a phone number... but it is free anyway

Yeah i was using some scammed cc but i saw phone verification with pin, no matter if i use socks :\ im 16, i'll use my pc anyways xD

used my friend cc, he will host there his clash of clans bot and i will host my agar, its super fast with 2000 bots :O

@hassanila97 hey i need your help because when i log off from the vps the vps logs also out and bot won't work, you know how 2 disable this?

I can help you on Skype via maybe Teamviewer<EMAIL_ADDRESS> But I'm busy r now...    later

Do nohup yourcommand & to run it in the background and keep it running when you disconnect

Le 17 mars 2016 à 14:45, Hassan<EMAIL_ADDRESS>a écrit :
I can help you on Skype via maybe Teamviewer<EMAIL_ADDRESS>But I'm busy r now... later
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

is it working still...?

Yeah but only with ONE bot. But this project isn't active anymore.

Le 4 mai 2016 à 21:36, fayizan<EMAIL_ADDRESS>a écrit :
is it working still...?
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

Thank you camilleeyries,but its not working for me I tried with premium socks and Vps too but its says the same thing I just posted above,could u please post the working file

someone please help me to create amazon vps


bzip2: add symlink libbz2.so.1.0

Description of changes
 $ ls -l /nix/store/nsgg55q1kh1ala68pas78hzfxsb3bnjk-bzip2-<IP_ADDRESS>.2/lib/
 -r-xr-xr-x 1 root root   950  1. Jan 1970  libbz2.la
 lrwxrwxrwx 1 root root    15  1. Jan 1970  libbz2.so -> libbz2.so.1.0.6
 lrwxrwxrwx 1 root root    15  1. Jan 1970  libbz2.so.1 -> libbz2.so.1.0.6
+lrwxrwxrwx 1 root root    15  1. Jan 1970  libbz2.so.1.0 -> libbz2.so.1.0.6
 -r-xr-xr-x 1 root root 78960  1. Jan 1970  libbz2.so.1.0.6

why? help autoPatchelfHook to resolve libbz2.so.1.0
alternative? fix autoPatchelfHook to resolve libbz2.so.1.0 to libbz2.so.1.0.*
= fuzzy matching by major version number
= general solution, avoid fixing "all the packages"
alternative 2:
{
  nativeBuildInputs = [ autoPatchelfHook ];
  postInstall = ''
    patchelf --replace-needed libbz2.so.1.0 libbz2.so.1.0.6 $out/lib/somelib.so
  '';

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This needs to go to staging for sure.

╭─[~/git/nixpkgs]─[patch-20*]
╰─ % ls -la /nix/store/441lwasaqcwxahqna9s0xngiqmh1rfkm-bzip2-<IP_ADDRESS>.2/lib
.r-xr-xr-x 950 root  1 Jan  1970  libbz2.la*
lrwxrwxrwx  15 root  1 Jan  1970  libbz2.so -> libbz2.so.1.0.6*
lrwxrwxrwx  15 root  1 Jan  1970  libbz2.so.1 -> libbz2.so.1.0.6*
lrwxrwxrwx  15 root  1 Jan  1970  libbz2.so.1.0 -> libbz2.so.1.0.6*
.r-xr-xr-x 79k root  1 Jan  1970  libbz2.so.1.0.6*


I can type /tp, can't type any args.

fixed: also added rule for minecraft.commands.teleport

Looks like you already got it working. The reason minecraft.commands.tp (and it's childs) is not enough, is because /tp is an alias / redirect to /teleport, which "holds" the command / argument logic.


Remove/toggle visibleif and isrequired questions

Are you requesting a feature, reporting a bug or asking a question?
Question
What is the current behavior?
In a survey I have a question with a radio group. If item 1 is selected, question 3 appears. If another item is selected, question 3 disappear. Question 3 is also required and the radio group too.
Screenshot

What is the expected behavior?
How can I toggle the validation error message "Please answer at least one question." in the survey onValueChanged event?
How would you reproduce the current behavior (if this is a bug)?

Open a survey
Button Complete triggers the validation for required fields
When an item is selected in the radio group the message " Please answer at least one question." should disappear.

Specify your

browser: Chrome
browser version: 68.0.3440.106
surveyjs platform (angular or react or jquery or knockout or vue): Vue
surveyjs version: 1.0.40

Thanks for your help.
Best regards

@amehlen could ypu please provide a json or an example to reproduce the problem? I've tried with small example and it looks ok for me.


spelling/ verb form mistake

This tutorial will   teacher   you how to install configure your Load_balancer using HAproxy on Ubuntu 20.04 running on a Nginx web_server.

This tutorial will teacher you how to install configure your Load_balancer using HAproxy on Ubuntu 20.04 running on a Nginx web_server.

Thank you for pointing out the misspell, sometimes things of such happens 🤗

Have corrected the mistake.