proposal: x/tools/cmd/deadcode: add new command

The golang.org/x/tools/internal/cmd/deadcode command reports dead code, that is, functions not reachable by a sequence of calls from main, even through reflection, based on an RTA-based call graph. We have found it useful for identifying orphaned bits of code in x/tools and we imagine others might find it useful too. We propose to publish it at cmd/deadcode in the same repo.
This is an example of the tool in action, showing functions in x/tools not reachable from gopls' main or any of its tests, and suppressing functions in generated source files.
xtools$ deadcode -test ./gopls/...
golang.org/x/tools/gopls/internal/lsp
	openClientEditor

golang.org/x/tools/gopls/internal/lsp/cache
	(fileLoadScope).aScope
	(packageLoadScope).aScope
	(moduleLoadScope).aScope
	(viewLoadScope).aScope

golang.org/x/tools/gopls/internal/lsp/debug/log
	(Level).Log
	(Level).Logf

golang.org/x/tools/gopls/internal/lsp/filecache
	SetBudget

golang.org/x/tools/gopls/internal/lsp/regtest
	(State).outstandingWork

golang.org/x/tools/gopls/internal/lsp/source
	WidestPackageForFile

golang.org/x/tools/gopls/internal/lsp/template
	(*Parsed).WriteNode
	(wrNode).writeNode

xtools$ deadcode -test -json ./gopls/...
[
	{
		"Path": "golang.org/x/tools/gopls/internal/lsp",
		"Funcs": [
			{
				"Name": "golang.org/x/tools/gopls/internal/lsp.openClientEditor",
				"RelName": "openClientEditor",
				"Posn": "/Users/adonovan/w/xtools/gopls/internal/lsp/command.go:1178:6",
				"Generated": false
			}
		]
	},
...

I'd particularly interested in feedback on how we could improve the user interface to make it clearer. For example, the first command I ran to produce the example above used just ./gopls, so it did not include tests from subpackages, causing it to report some functions that are only used from those tests. Perhaps better defaults would make such mistakes less likely.
Please try it out and let us know what you find.

-generated=false is awkward. -exclude-generated would be less awkward.

One thing I noticed is that it needs some logic around Example* functions in tests.

it needs some logic around Example* functions in tests.

Logic to do what? The help message says:

Bear in mind that an Example test
function without an "Output:" comment is merely documentation:
it is dead code, and does not contribute coverage.

Are you suggesting that it should treat non-executed Example functions as somehow reachable? I think its current behavior is more sensible. It's also unlikely that anyone would casually delete an Example based on the report produced by this tool.

Why does the output print package "path"? Why not just print path, or perhaps like the go command # path?
package "path" is weird because that's not the syntax of a package declaration.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Logic to do what? The help message says:

Bear in mind that an Example test
function without an "Output:" comment is merely documentation:
it is dead code, and does not contribute coverage.

Are you suggesting that it should treat non-executed Example functions as somehow reachable? I think its current behavior is more sensible. It's also unlikely that anyone would casually delete an Example based on the report produced by this tool.

I can see the logic in that, but having the tool not recognize functions that are meaningful to the standard go tooling feels like friction for most users. The invocation is going to become deadcode . | grep -v Example for users to remove the technically-correct-but-not-useful output.

-generated=false is awkward. -exclude-generated would be less awkward.

I think this depends on the default behavior. If generated files are excluded by default, then -generated=true or -include_generated seems clearer than the doubly negative -exclude_generated=false.
And based on my experience with this command, I think generated files should be excluded by default. I almost always want to exclude generated code, and commands should err on the side of less noise.

One small note about the output: the parens in (*Parsed).WriteNode are both pedantic and harmful.
Pedantic because there is no potential for confusion, since there is only one actual method definition in the source code, so distinguishing pointer vs non-pointer receiver is unnecessary.
Harmful because the result is different syntax from what go doc uses,
so you can't paste the output into a go doc command line.
This should be printed as plain 'Parsed.WriteNode'.
Same thing for (Level).Log: just Level.Log.

In the JSON, the fields "RelName" and "Posn" seem to be new spellings for Go. Are they necessary?
Posn in particular seems like it should be Pos or Position, following our usual spellings.
And maybe Name/RelName should be ID/Name?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
See the top comment.

Pedantic because there is no potential for confusion, since there is only one actual method definition in the source code, so distinguishing pointer vs non-pointer receiver is unnecessary.

Fair enough. (These names from go/ssa, which must be able to distinguish (T).f from (*T).f.)

In the JSON, the fields "RelName" and "Posn" seem to be new spellings for Go. Are they necessary?

Perhaps not: once we've simplified (*T).f to T.f then package-qualifying it is as simple as pkg.T.f. Nice.

Sounds like RelName can be deleted. Posn should be kept but changed to Pos or Position.

I'm still not sure about the semi-structured default output. It is easy to fall back on "well it doesn't matter, programs will use json", but really the default output should be as usable for people as we can make it, including people typing at a Unix prompt. The current output is not greppable, for example. Also, I think it would make sense to think of deadcode as like vet in that it flags code that the user should take a look at. That strongly suggests the position belongs in the default output, so that it is easy to navigate to that code. So the output should probably be individual lines, not stateful sections, and each line should begin with the position:
file:line: pkg.name

And the file:line should default to relative to the current directory, like go vet and go build do. With the file:line, the full package path is probably unnecessary:
$ deadcode ./...
internal/lsp/command.go:1178:6: unused func: openClientEditor
...

The "unused func:" is important because deadcode might also be printing ordinary build errors.
It also leaves the door open to "unused var" in the future (or maybe that's already there?).

Sounds like RelName can be deleted. Posn should be kept but changed to Pos or Position.

Yep, that was done in CL 541238.

I'm still not sure about the semi-structured default output.

OK, done in 542375. I used "unreachable" over "unused" because it's a property of the call graph, not the defs/uses graph.
$ go run ./internal/cmd/deadcode -test ./gopls/...
gopls/internal/lsp/command.go:1206:6: unreachable func: openClientEditor
gopls/internal/lsp/cache/pkg.go:100:22: unreachable func: fileLoadScope.aScope
...

The old format is now just an example -f template in the documentation.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
See the top comment.


Thread.current() returns the Thread object for the currently-executing thread.
Thread instances have an .id property which is the numeric thread ID.

Ping.


Assorted edx-django-utils clean-up.

Description:

Docs and README clean-up.
Python3 support completed.
Address review comments from edx-django-utils/pull/2.
Add latest cookiecutter updates.

JIRA:
ARCH-220
Merge checklist:

[ ] All reviewers approved
[ ] CI build is green
[x] Version bumped
[x] Changelog record added
[x] Documentation updated (not only docstrings)
[ ] Commits are squashed
[ ] PR author is listed in AUTHORS

Post merge:

[ ] Create a tag
[ ] Check new version is pushed to PyPi after tag-triggered build is
finished.
[ ] Delete working branch (if not needed anymore)

@ormsbee: I indicated all the file updates that were just coming from the cookiecutter so you could skip those.  If you need me to pull those out, let me know.  I can also delete those comments if they are a distraction.  Thanks.
Also includes fixes for your comments in https://github.com/edx/edx-django-utils/pull/2

@ormsbee: Thanks for the cleaner Python.  Please add thumb when you are ready and I'll squash.  Thanks.

You beat me by 17 seconds.


Failed Pre-Requisite Check but Node.js and Topojson already installed Windows 10

2015-09-27T23:43:10	0	model 2.10.1-Pisa
2015-09-27T23:43:10	0	model 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
2015-09-27T23:43:10	0	topo Windows
2015-09-27T23:43:10	2	model Exception
Traceback (most recent call last):
File "C:/Users/nefertiti/.qgis2/python/plugins\d3MapRenderer\logic.py", line 100, in hasTopoJson
found = self.topojson.helper.hasTopojson()
File "C:/Users/nefertiti/.qgis2/python/plugins\d3MapRenderer\osHelp.py", line 139, in hasTopojson
nodeFound = self.getNodeJsPath()
File "C:/Users/nefertiti/.qgis2/python/plugins\d3MapRenderer\osHelp.py", line 235, in getNodeJsPath
except self.reg.WindowsError as e:
AttributeError: 'module' object has no attribute 'WindowsError'

Checked on Windows 7, 8.1 and 10 OK.
The actual error is being masked by built in WindowsError exception
being fetched from the _winreg module. This is now fixed, but the
underlying problem remains.
Please check the registry setting for
HKEY_CURRENT_USER\Software\node.js\InstallPath exists and that no
restrictions on the computer prevent access to the registry.

What should HKEY_CURRENT_USER\Software\node.js\InstallPath  be set to?

I just added a blank value and it worked for me.

Yes, that will get it past the prerequisite check.
However, the check is there for a reason, the code will just error later on
when you run the output process, as it can't call the Node executable and
the topojson npm package. On Windows this information is stored in two
registry keys:
HKEY_CURRENT_USER\Software\Node.js\InstallPath  which is the path to the
Node.js installation folder, and should have a value along the lines
of *C:\Program
Files\nodejs*
HKEY_CURRENT_USER\Environment\PATH  which is where your Environment
variables are stored, and should have the path to the NPM packages
(possibly along with a few other things separated by a semicolon)
C:\Users\Simon\AppData\Roaming\npm;C:\Program Files\QGIS
Wien\bin;C:\Program Files\QGIS Wien\apps\qgis\bin
The Node.js installer should be setting these values for you, and Node.js
itself may require other registry keys. However, that is all the
information the plugin requires to create a long command string along the
lines of:
*C:\Program Files\nodejs*node.exe
C:\Users\Simon\AppData\Roaming\npm\node_modules\topojson\bin\topojson
-o C:\Users\Simon\Documents\EnglishIMD\topo\LSOA2001IMD.json --id-property
LSOA01CD -p d3Css -s 1e-9 --
l1=C:\Users\Simon\Documents\EnglishIMD\shp\LSOA_2001_IMD.shp
I'm going to add a GeoJson export as soon as my contracts come to an end
(d3 doesn't require TopoJson, I just went down that particular route as it
produces smaller files) and I'll add an internal conversion to TopoJson at
a later date.
On Thu, Feb 4, 2016 at 8:35 PM, Tim L<EMAIL_ADDRESS>wrote:

I just added a blank value and it worked for me.
—
Reply to this email directly or view it on GitHub
https://github.com/sbenten/d3MapRenderer/issues/11#issuecomment-180035042
.


Content-Length is reset to 0 in HEAD responses

Seems like it has something to do with Axum or some other dependency

Seems to be fixed by https://github.com/tokio-rs/axum/pull/755


more clean up in SchedulerJobsTest (re. FINERACT-922)

@awasum @ptuomola does this LGTY? It's ongoing clean-up, while I get familiar with this code...

This fails again due to the Scheduler problem.  Other than that...Coding to Interface as you done and other clean ups are relevant. @vorburger . Maybe we should assemble a couple of these scenarios for new contributors and our upcoming GSoC students so they use as starter issues.
This LTGM except we want to add a line to ignore the failing test. if not related to these changes.

#815 adds an ignore to the IT that failed here.

@awasum OK, thanks for super quick review, I've merged this now one.   @ptuomola FYI.


fix: contact specialist removing spaces

This PR resolves []
Description

This trim makes it so spaces cannot be added to names in contact specialist form. It looks like it was added deliberately so just want to double check I am not breaking something else.
Before
https://github.com/artsy/eigen/assets/49686530/e4304a95-a810-400a-9c78-9a320df4cf50
After
https://github.com/artsy/eigen/assets/49686530/0b1e6286-6c26-4307-af64-1f16f1d6ac4d
PR Checklist

[] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Fix specialist form not allowing spaces - Brian

iOS user-facing changes

Android user-facing changes

Dev changes

Need help with something? Have a look at our docs, or get in touch with us.

Hey @brainbicycle we ticketed this bug in CX
https://github.com/artsy/eigen/pull/8688

Hey @brainbicycle we ticketed this bug in CX
#8688

whoops! Alright yours is better, closing


initial install issue & policy run issue

Thank you for this wonderful tool.
Perhaps there may be some ideas here for additional developer install instructions - I would be happy to contribute if helpful.
The below steps show my efforts at installing Cloud Custodian.   Eventually, I successfully installed Cloud Custodian and ran tests/coverage.  However - I ran into a traceback issue in running a custom policy.    Any insight on where my environment is invalid would be greatly appreciated.
Using a blank Amazon linux distro,  referencing the following install doc:
http://www.capitalone.io/cloud-custodian/quickstart/developer.html
I configured this new EC2 to run cloud custodian via CLI as follows:
Spin up Amazon linux distro EC2 nano instance:  i-xxxxxxxx
ssh into this new instance
% yum update
% yum install gcc
% yum install git
% yum install install python python-dev python-pip python-virtualdev
% yum install emacs
% git clone https://github.com/capitalone/cloud-custodian.git
% make install
(have make output if needed)
% make test
./bin/nosetests -s -v --with-timer tests
make: ./bin/nosetests: Command not found
make: *** [test] Error 127
Looking @ the makefile -  ran this additional command
% make develop
then - tried the following:
% make test
Progressed further - but my tests failed.
Performed another:
% make install
and looking at the output, noticed:
You are using pip version 6.0.8, however version 8.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command
so - performed the following:
% pip install --upgrade pip
% pip install -r requirements.txt
% pip install -r requirements-dev.txt
% make test -> failed.
Looking at the output, noticed that is was looking for a default AWS region.
Hence - ran:
% aws configure  // inserted Access Keys and default region
% make test -> Successful!
% make coverage  -> Successful!
Happy with my progress so far - copied the following default policy from the documentation:

name: ec2-old-instances
resource: ec2
comment: |
Report running instances older than 60 days
query:

instance-state-name: running
filters:
type: instance-age
days: 60

name: policy.yml
Ran the following command:
% ./bin/custodian run --dryrun -c policy.yml  -s out
which produced quite a bit of verbose output.   Of the relevant pieces, I believe, are the following:
Traceback (most recent call last):
File "./bin/custodian", line 9, in
load_entry_point('c7n==0.8.3', 'console_scripts', 'custodian')()
File "/home/ec2-user/cloud-custodian/c7n/cli.py", line 105, in main
config = policy.load(options, options.config)
File "/home/ec2-user/cloud-custodian/c7n/policy.py", line 45, in load
raise errors[0]
jsonschema.exceptions.ValidationError: [{'comment': 'Report running instances older than 60 days\n', 'query': [{'instance-state-name': 'running'}], 'resource': 'ec2', 'name': 'ec2-old-instances', 'filters': [{'type': 'instance-age', 'days': 60}]}] is not of type 'object'
Failed validating 'type' in schema:
{'$schema': 'http://json-schema.org/schema#',
'additionalProperties': False,
Now - stuck on diagnosing this "object" error.
Any suggestions?
[make output attached]
cloud_custodian_output.txt

Thanks for trying things out, there's some rough spots in the docs that need addressing. wrt to the error the formatting on the policy looks off, which is likely triggering the schema validation error,  but its hard to see in this issue without using a prefix block,  yaml is white space sensitive.
here's an example of a working policy
policies:
  - name: ec2-old-instances
    resource: ec2
    comment: |
      Report running instances older than 60 days
    query:
      - instance-state-name: running
    filters:
      - type: instance-age
        days: 60

and running it on an account
$ custodian run -c config.yml -v  -s out --dryrun
custodian run -c config.yml -v  -s out
2016-04-29 06:51:18,670: custodian.output:INFO Storing output with <DirectoryOutput to dir:out/ec2-old-instances>
2016-04-29 06:51:18,670: custodian.policy:INFO Running policy ec2-old-instances
2016-04-29 06:51:18,670: custodian.resources.ec2:INFO Querying ec2 instances with [{'Values': ['running'], 'Name': 'instance-state-name'}]
2016-04-29 06:51:19,915: custodian.resources.ec2:DEBUG Found 46 instances on 46 reservations
2016-04-29 06:51:19,925: custodian.resources.ec2:INFO Filtered from 46 to 5 ec2
2016-04-29 06:51:19,927: custodian.policy:INFO policy: ec2-old-instances resource:ec2 has count:5 time:1.26
2016-04-29 06:51:19,927: custodian.output:DEBUG metric:ResourceCount Count:5 policy:ec2-old-instances restype:ec2 scope:policy
2016-04-29 06:52:16,282: custodian.policy:DEBUG dryrun: skipping actions

Re other items reported here.

[ ] reference make develop in developer docs
[ ] unit tests or make tests should set their default region it not already set

i think we tackled the doc issue and the unit tests defaulting to region (when executed via make) in #32 and #33, and also the policy example here in the issues.
Re the initial install we can furnish additional instructions there for other distros (contrib welcome), but i think maybe the other option is just shipping a docker image to the public registry, which we use internally for our ci (via drone).


Error in quantile.default

The following error are systematically occuring.
Error in quantile.default(as.numeric(csa[j, 2:(n.s + 1)]), 0.975) :
missing values and NaN's not allowed if 'na.rm' is FALSE
I got this error when run the code from the paper with the data.
I was no able to find how it is any NaN in the data. I used the original data from the article I got it, even with a random generated similar data, and I got the same error. This seems strange because the data I randomlly created was pretty similar to the one of the article and has no NaN on it.
Beside of it, I wanna know if the phase-lock surrogates are implemented in the rEDM package. If it is there are any tutorial how to run it and used it?
Thank you

Hello??


pass frame / stream type parsing errors to the hijacker callbacks

When a stream is reset, we might not have received the frame / stream type yet. The callback might be able to identify if it was a stream intended for that application by analyzing the stream reset error.
This will allow us to resolve https://github.com/marten-seemann/go-libp2p-webtransport/issues/3. The WebTransport implementation can determine if the stream reset error code is in the WebTransport error code range.
@ydnar @hareku Thoughts?

One question not specific to this PR but in general is that it seems like there are UniStreamHijacker tests but no matching StreamHijacker tests. Any specific reason?

Please use https://github.com/lucas-clemente/quic-go/pull/3391 if you like.

@hareku Thank you. I had actually missed your PR. I've merged it now, and rebased this PR.
@MarcoPolo Thanks for pointing this is out in the review. This actually helped uncover a bug, which I fixed in 5cb2e8265cd2832b0d9b961ca48645c1ebd993b3.


Interfaces for Handler Classes

In 3.x Container doc

errorHandler: a callable with the signature: function($request, $response, $exception)

notFoundHandler: a callable with the signature: function($request, $response)

notAllowedHandler: a callable with the signature: function($request, $response, $allowedHttpMethods)

I would like to create  a base interface for these.
Could keep them separated...
interface IErrorHandler {
    public function __invoke($request, $response, $exception);
}

Or we could provide a handler class...
interface ISlimHandler {
    public function errorHandler($request, $response, $exception);
    public function notFoundHandler($request, $response);
    public function notAllowedHandler($request, $response, $allowedHttpMethods);
}

Having a base class that is extendable?
Not needed for 3.0 but maybe 3.1
@akrabat @codeguy @silentworks
Thoughts ?

It will be great to be able create and inject own error handlers without modifing or extending Slim\App. And extending them from base ErrorHandling class, redefining only messages for html/xml/json formats and http code.

@p-golovin you can overwrite the the default handlers in the container as long as you keep the same function signature.

@geggleto I talk not about owerwriting existing handlers, but about adding new one. For example: BadRequest (400 http code). But for now I can't call them for given type of exception without rewriting \Slim\App::handleException function.
And also there may exists different handlers with same logic of defining content-type, but only difference in message text in output.
So it will be great to have smth like this
class Handler
{
    protected $message = [
        'html' => '...',
        'xml' => '...',
        'json' => '...',
    ];

    private function determineContentType(...)
    { ... }

    protected function renderJsonOutput(...)
    { ... }

    ...
}

class NotFound extends Handler
{
    // redefine $message
}

And be able configure map between exceptions and handlers via container for this
    protected function handleException(Exception $e, ServerRequestInterface $request, ResponseInterface $response)
    {
        if ($e instanceof MethodNotAllowedException) {
            $handler = 'notAllowedHandler';
            $params = [$e->getRequest(), $e->getResponse(), $e->getAllowedMethods()];
        } elseif ($e instanceof NotFoundException) {
            $handler = 'notFoundHandler';
            $params = [$e->getRequest(), $e->getResponse()];
        } elseif ($e instanceof SlimException) {
            // This is a Stop exception and contains the response
            return $e->getResponse();
        } else {
            // Other exception, use $request and $response params
            $handler = 'errorHandler';
            $params = [$request, $response, $e];
        }

You can easily do this in a middleware!
Something like this.
$app->add(function ($req, $res, $next) {
    $res = $next($req, $res);
    $hnd = null;
    switch($res->getStatusCode()) {
        case 400: { $hnd = $this->get('400Handler'); }
        ///.....
    }
    if (!is_null($hnd)) { $res = $hnd($req, $res); }
    return $res;
});

I don't see the advantage of an interface?

Will hopefully address in 4.0


Setting minDate disables the desired minimum date

Describe the bug
When setting the minimum date on the date picker via minDate prop, I cannot select the day of the actual minimum date. This does not fit the description of the prop provided in the docs:

minDate
All dates before the given date will be disabled

To Reproduce

Go to https://vue3datepicker.com/api/props/#mindate
Note the example uses today's date for minDate
Open date picker example
Note that today's date is disabled, and hovering over the date changes the cursor to reflect the disabled state.

Expected behavior
I expect to be able to select the actual day of the minimum date, while all days before the minimum date are disabled
Code
<template>
    <Datepicker v-model="date" :minDate="new Date()" />
</template>

<script>
import { ref } from 'vue';

export default {
    setup() {
        const date = ref(new Date());

        return {
            date,
        }
    }
}
</script>

Screenshots

Desktop (please complete the following information):

macOS Big Sur 11.6.4
Chrome
Version 99.0.4844.51

@anne-marcotte Hmm, strange, today should be enabled, can you tell me your timezone so I can check? From my side, I can select today.

@Jasenkoo thanks for taking a look. I'm Eastern Daylight Time (New York)

Tnx for answer, this might be due to a time change last weekend

The issue is fixed, please switch to the new package https://github.com/Vuepic/vue-datepicker

The issue is fixed, please switch to the new package https://github.com/Vuepic/vue-datepicker

Thank you very much!


Update consistent error message

... as we can't do much about it. Let's not invite users to open an issue.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Bugfix/staff rise and other opts

Fixes:

Rise % for staves, sticks, books, scepters - currently these items were overpowering by 2x the supposed value. The item's "magic power" was being used as its rise, while it should be divided by 2.
Excellent/ancient bonus for defensive (armor) items, shields, physical attack weapons, scepters, wizardry weapons (sticks, staves). Made the following table to show values before and after this PR (nominal values were taken from in game with S6E3 client; red color means wrong value, green color right).

Skull Staff - had no wizardry rise base power up because it was being defined as a Summoner item
Excellent/harmony curse attack options - these do not exist until Season 14/16; until then wizardry attack options were used
Some staff group items property values (see comments)
Several wing options and values - Summoner, RF, DL (all shots taken with S6E3 client - see comments)
Always the same option being assigned for 2nd/3rd lvl wings upon JoL'ing (last PR fuckup! :disappointed: )

Additions:

Odd rise tables - because an item's rise is defined by dividing its magic power by 2, this will give rise to different increase by level tables for even and odd magic power values (because OpenMU uses floating point instead of rounded out values, odd base magic power items have a 0,5% extra increase at any level compared to nominal, while their excellent counterparts have 0,5% less; even base magic power items have nominal rise - see spreadsheet table above). Skull Staff MP = 6 (even); Legendary Staff MP = 59 (odd):

BookRise attribute and its CurseAttackDamageIncrease attribute relationship - for Summoner book items rise %, which is used to calculate curse damage.
Excellent/ancient bonus for books
If condition to add base power up physical damage attributes - books have 0 min/max physical dmg
UpdatePlugins to fix rise percentages, group 5 weapons, and the wing options

Thank you for all these fixes 😀


How to deploy in repl?

Is possible to deploy in repl like this repo https://github.com/Ryuk-me/Torrents-Api

@alok99-git a613b301f4239b694fe2eea3fe029eb6748d8175


[BUG] workspace_empty

Describe the bug
No matter what I set workspace_empty to, it always just displays {id}.
To Reproduce

Set workspace_empty to "empty".
Save the config file.
Restart waybar.
Open empty workspace.
Workspace is named {id}.

Expected behavior
Workspace should be named "empty".
Linux Distro (please complete the following information):
NixOS
**Program version?
0.5.2

Thanks we maybe have a bug yes, do you confirm you well have the style apply when your close ALL the app on a workspace and stay on this workspace ?

Ah. If I close all windows on a workspace, then the empty workspace is formatted correctly. But if I switch to an empty workspace that has not had any windows opened on it, it is not formatted correctly.

Hey hey, @ehula can you try the last release 0.5.3 ?

Looks like it is fixed.


sign extention of shamt for C.SLLI/C.SRLI/C.SRAI in RV128

In both V2.1 and V2.2 the C.SRLI and C.SRAI shamt are sign extended in RV128.

Furthermore, the shift amount is sign-extended for RV128C, and so the legal shift amounts are 1–31, 64, and 96–127. C.SRLI expands into srli rd 0 , rd 0 , shamt[5:0], except for RV128C with shamt=0, which expands to srli rd 0 , rd 0 , 64

Please confirm that the sign extension is only to the rightmost 7 bits of the immediate in the RV128 SRLI and SRAI.
C.SLLI does not mention the sign extension, but only the 0 as 64 for RV128.

For RV128C, a shift amount of zero is used to encode a shift of 64. C.SLLI expands into slli rd, rd, shamt[5:0], except for RV128C with shamt=0, which expands to slli rd, rd, 64.

Please confirm that shamt for RV128 C.SLLI is intended to function as for RV128 C.SRLI/C.SRAI.
(Clifford's query about C.ADDI and rd/rs1 == 0 got me looking at the compressed instructions again)

The comment on the top of page 78 of https://cdn.rawgit.com/riscv/riscv-isa-manual/master/release/riscv-spec-v2.2.pdf#page=90 indicates that the range of right shifts and left shifts is deliberately different on RV128 and gives two reasons why.

And the explanation was also in V2.1 - sorry for the noise.


Feature request: Add texture coordinates to smoothing

UVs subdivide with vertices: easy implementation?

In one sense it wouldn't be too hard, but it would require a lot of changes and could slow down the general case where uvs aren't needed.
I've been meaning to do something like this eventually but would like to get the core algorithms more solid.

Understood, many thanks to your contributions so far.


launch conemu option error

jetbrains version: latest webstorm/intellij idea 2018.3
native terminal version: latest 0.2.3
conemu version: latest 180626
error:

enhancement advice:
maybe add start parameters/options config for specified terminal like conemu in setting?
thks.

Hi @darklonely,
Could you please share your "Favorite Terminal" string?
Also, it will be great if you can provide terminal's log messages. It can be found in the IDE log here:
C:\Users<USER>.IntelliJIdea2018.3\system\log\idea.log by searching "cmd.plugin".
Thanks.

@darklonely,
Probably "Favorite Terminal" contains "cmd" somewhere in the path. Move ConEmu outside "cmd" folder can solve the issue.
Yep, I know my "terminal detection" mechanism is not perfect:sweat_smile:
By the way, I have already updated this for EAP channel in version 0.2.4.
Thanks!

@sburlyaev
thanks for the quick answer.
My "Favorite Terminal" string is "F:\software\cmd\conemu\conemu\ConEmu64.exe".
Yep, it contains ### "cmd". :)
I moved the ConEmu outside the "cmd" folder, it works like a charm.  :+1:
thanks for you quick answer one more time. :+1: :+1:

@darklonely, fixed in 0.2.4.
Thanks!

@sburlyaev
I installed 0.2.4. the conemu successfully started.
Unfortunately, the current working directory is not the project root path or the subdirectory in the setting.
I move the conemu out the "cmd" folder again, it works right. :)

Mystery! Could you please share terminal's log messages. It can be found in the IDE log here:
C:\Users.IntelliJIdea2018.3\system\log\idea.log by searching "cmd.plugin".
Thanks

Here:
2018-12-06 11:14:17,660 [ 152426]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - Environment{os=WINDOWS, osVersion='6.1', gui='windows'}  2018-12-06 11:14:17,664 [ 152430]   INFO - yaev.cmd.plugin.CommandBuilder - Favorite terminal is [F:/software/cmd/conemu/conemu/ConEmu64.exe] and using [CON_EMU]  2018-12-06 11:14:17,664 [ 152430]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - [F:/software/cmd/conemu/conemu/ConEmu64.exe, -Dir, E:/workspace/idea/peanut-bi-odps]  2018-12-06 11:15:16,440 [ 211206]   INFO - j.ide.plugins.RepositoryHelper - using cached plugin list (updated at 2018/12/6 11:10)  2018-12-06 11:15:33,101 [ 227867]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - Environment{os=WINDOWS, osVersion='6.1', gui='windows'}  2018-12-06 11:15:33,101 [ 227867]   INFO - yaev.cmd.plugin.CommandBuilder - Favorite terminal is [D:/conemu/ConEmu64.exe] and using [CON_EMU]  2018-12-06 11:15:33,101 [ 227867]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - [D:/conemu/ConEmu64.exe, -Dir, E:/workspace/idea/peanut-bi-odps]  2018-12-06 11:16:51,338 [ 306104]   INFO -              #AgreementUpdater - Error updating privacy policy: Connection refused: connect  2018-12-06 11:24:22,347 [ 757113]   WARN - com.intellij.util.xmlb.Binding - no accessors for class com.aliyun.odps.studio.option.CompilerSettings$MajorVersion  2018-12-06 11:33:29,358 [1304124]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - Environment{os=WINDOWS, osVersion='6.1', gui='windows'}  2018-12-06 11:33:29,359 [1304125]   INFO - yaev.cmd.plugin.CommandBuilder - Favorite terminal is [F:/software/cmd/conemu/conemu/ConEmu64.exe] and using [CON_EMU]  2018-12-06 11:33:29,359 [1304125]   INFO - m.sburlyaev.cmd.plugin.OpenCmd - [F:/software/cmd/conemu/conemu/ConEmu64.exe, -Dir, E:/workspace/idea/peanut-bi-odps]

Looks good.
Is it Windows 7?

yes. it's Windows 7 64bit

Ok. I will try to reproduce this on my own and let you know.
Thanks!

Woops! I know what's the problem.
The conemu -Dir option only works if you don't start the conemu or have "zero" task console tab.
If you started the conemu before and have one more task tab, then it doesn't work.
I tried the following command, it works in both cases:
F:/software/cmd/conemu/conemu/ConEmu64.exe -reuse -Dir E:/workspace/idea/peanut-bi-odps

Hmm... On Win 10 "-Dir" command just opens a new terminal window if you have one already.
However, thank you for the investigation!