Karma testing does not seem to work

I followed the instructions and everything installed, but when I run karma start I get the following warnings:
WARN [reporter]: Can not load "mocha", it is not registered!
Perhaps you are missing some plugin?
WARN [watcher]: Pattern "/Users/Quirksmode/Downloads/NG6-starter-jspm/client/jspm_packages/es6-module-loader.js" does not match any file.
INFO [karma]: Karma v0.12.36 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome

Try  :
$ npm install -g karma-cli
$ npm install -g mocha
When I'm running the karma tests I get the following :
Uncaught TypeError: baseURL should only be configured once and must be configured first.

Installing all the packages globally seems to get it working.
But this is not ideal as ideally we want the package.json to set everything up on different developers machines using 'npm install'. Am I missing something here, or is this just how it has to be?

Testing is not working for me with a clean clone / install ( even with globally installing the packages ). How did u get it to work? Do the tests run?

works for me (fresh install) - make sure you are at the root of the app and run
karma start // or npm test

returns
START:
04 12 2015 13:58:20.508:INFO [karma]: Karma v0.13.15 server started at http://localhost:9876/
04 12 2015 13:58:20.531:INFO [launcher]: Starting browser Chrome
04 12 2015 13:58:26.986:INFO [Chrome 47.0.2526 (Mac OS X 10.10.5)]: Connected on socket -AFYu1246eJAI_M-AAAA with id 37112570
  Hero
    Controller
      ✔ has a name property [REMOVE]
    Template
      ✔ has name in template [REMOVE]
    Component
      ✔ includes the intended template
      ✔ uses `controllerAs` syntax
      ✔ invokes the right controller
  Navbar
    Controller
      ✔ has a name property [REMOVE]
    Template
      ✔ has name in template [REMOVE]
    Component
      ✔ includes the intended template
      ✔ uses `controllerAs` syntax
      ✔ invokes the right controller
  About
    Controller
      ✔ has a name property [REMOVE]
    Template
      ✔ has name in template [REMOVE]
    Component
      ✔ includes the intended template
      ✔ uses `controllerAs` syntax
      ✔ invokes the right controller
  Home
    Controller
      ✔ has a name property [REMOVE]
    Template
      ✔ has name in template [REMOVE]
    Component
      ✔ includes the intended template
      ✔ uses `controllerAs` syntax
      ✔ invokes the right controller

Finished in 0.104 secs / 0.004 secs

SUMMARY:
✔ 20 tests completed

and sorry if I'm stating the obvious here but these packages have to be installed globally
npm install -g gulp karma karma-cli webpack

Thanks for your reply. I did the following :
$ git clone -b jspm https://github.com/AngularClass/NG6-starter.git
$ npm install
$ karma start
Returns  :
Error: Cannot find module 'mocha'
at Function.Module._resolveFilename (module.js:337:15)
at Function.require.resolve (module.js:389:19)
at initMocha (/Users/justinkames/Documents/workspace-webstorm/NG6-starter/node_modules/karma-   mocha/lib/index.js:8:40)

$ npm install mocha --save-dev
$ npm install chai --save-dev
Then :
$ karma start
  INFO [karma]: Karma v0.12.37 server started at http://localhost:9876/
  INFO [launcher]: Starting browser Chrome
  INFO [Chrome 47.0.2526 (Mac OS X 10.11.1)]: Connected on socket PsA3cTt6RyO-dS3CEJiB with    id 63391663
  Chrome 47.0.2526 (Mac OS X 10.11.1) ERROR
  Uncaught ReferenceError: System is not defined
  at /Users/justinkames/Documents/workspace-webstorm/NG6-starter/jspm.config.js:1
  Finished in 0.119 secs / 0 secs

Fixed by running $ jspm dl-loader
$ karma start
 INFO [Chrome 47.0.2526 (Mac OS X 10.11.1)]: Connected on socket J1D8hfUGqGv4gPFsFCpd with   id 31894073
 Chrome 47.0.2526 (Mac OS X 10.11.1) ERROR
Uncaught TypeError: baseURL should only be configured once and must be configured first.
at /Users/justinkames/Documents/workspace-webstorm/NG6-starter/client/jspm_packages/system.js:4

Updating karma-jpsm in package.json fixed this
"karma-jspm": "2.0.1",
$ karma start
INFO [karma]: Karma v0.12.37 server started at http://localhost:9876/
INFO [launcher]: Starting browser Chrome
INFO [Chrome 47.0.2526 (Mac OS X 10.11.1)]: Connected on socket 0Al7Wml4ToEgVk9KIXpG with id   294793
WARN [web-server]: 404: /client/app/common/hero/hero.spec.js
WARN [web-server]: 404: /client/app/common/navbar/navbar.spec.js
WARN [web-server]: 404: /client/app/common/user/user.spec.js
WARN [web-server]: 404: /client/app/components/about/about.spec.js
WARN [web-server]: 404: /client/app/components/home/home.spec.js
Chrome 47.0.2526 (Mac OS X 10.11.1) ERROR: 'Potentially unhandled rejection [5] Error: XHR error     (404 Not Found) loading http://localhost:9876/client/app/common/hero/hero.spec.js
at error (http://localhost:9876/base/client/jspm_packages/system.src.js? 6536115be64e0ff966e05546f7767676fa7c03d6:1020:16)
at XMLHttpRequest.xhr.onreadystatechange (http://localhost:9876/base/client/jspm_packages/system.src.js?  6536115be64e0ff966e05546f7767676fa7c03d6:1028:13)'
WARN [Chrome 47.0.2526 (Mac OS X 10.11.1)]: Disconnected (1 times), because no message in 10000 ms.

This where I am currently stuck ( package versions below )
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>

@justinkames your steps seem to be ok (I have my own environment, as anyone else), but the point is you have to add in karma.conf.js
proxies: {
  '/client': '/base/client'
}

Hope it helps, karma+jspm uses to be a bit of hell. Check https://github.com/Workiva/karma-jspm/issues/91 for further info.

Same issue:
C:\ > git clone -b jspm https://github.com/AngularClass/NG6-starter.git
C:\ > cd NG6-starter
C:\ > git checkout jspm
C:\ > npm install
C:\ > karma start
Error: Cannot find module 'mocha'     at Function.Module._resolveFilename (module.js:325:15)     at Function.require.resolve (internal/module.js:16:19)
Then
C:\ > npm install mocha --save-dev
C:\ > npm install chai --save-dev
Results in
START: WARN [watcher]: Pattern "C:\Users\bkdevconstructiv\tmp\NG6-starter\client\jspm_p ackages\es6-module-loader.js" does not match any file. ERROR [karma]: { [Error: EMFILE: too many open files, open 'C:\Users\bkdevconstr<EMAIL_ADDRESS> errno: -4066,   code: 'EMFILE',   syscall: 'open',
What to do?

Looks like you are using a PC. On a mac, you can add ulimit -f [some high number] in the .bash_profile or .zshrc file. Mine is set to ulimit -f 20000.
Therefore on a PC, maybe look for something comparable to ```ulimit``?


feat(#677): add helpful links to mobile footer

Description
added helpful links to footer
discord username:RedCore#6872
closes #issue
#677
Please describe your changes. Also describe your aim and content. Do not forget to list the dependencies required caused by those changes.

## Things to check before creating a PR

[ ] I have inspected my topic, checked.
[ ] If it is a core feature, executed detailed tests.

Creating PR rules

[ ] PR must be created for an issue with approved tag. Otherwise PR will be rejected.
[ ] Relevant issue number: The issue number related to PR must be attached to head of PR header, after prefix after prefix # must be attached in parenthesis. A header like this could be used "prefix(#issue_number): PR header" .
[ ] A descriptive and understandable title: The PR title should clearly describe the nature and purpose of the changes. The PR title should be the first thing displayed when the PR is opened. And it should follow the semantic commit rules. For example, a title like "docs(#issueId): Add README.md" can be used.
[ ] Related file selection: Only relevant files should be touched and no other files should be affected.
[ ] Format and Lint Suitability : The code should be made in accordance with a certain format standard and examined according to the lint rules.
[ ] Clean commit history: The commits where the changes are made should be clear and organized.
[ ] Opening PR when job is completed: PR should be opened when job is completed and sent for review by other team members.

Changes

[ ] A new feature (a change that adds a new feature, not a breaking change)
[ ] A new refactor (a change that is not a breaking change, that improves the readability or performance of the code)
[ ] A breaking change
[ ] Documentation change

How were these changes tested?
Please describe the tests you did to test the changes you made. Please also specify your test configuration.
Test Configuration:

Firmware version:
Hardware:
Toolchain:
SDK:

@emirhnergn did you get a guidance from design or product for this?

@emirhnergn did you get a guidance from design or product for this?

no, is it not compatible?

I added the UX/UI label, I am guessing they are going through those PRs labeled as UX/UI.

@cdagli @emirhnergn thanks for your effort. I have just contacted the design team, they will give feedback on this feature. ASAP

Design part is done. You can check it out on Figma as "Referans Linkleri". @emirhnergn
https://www.figma.com/file/sctw6xtcdoFOfmE0gC97Ft/Afetharita.com?node-id=2349%3A8093&t=v67k1CJDv8Ws7zE0-1

product part is done? do we really need this feature? after.org does it for all the apps.

we have urgent problems. please keep this work in your locale. we will announce when we need this features.


[new-parser] Reconsider RHS_DRL_END Lexer Island mode or parser rule

Parent issue

#5678

Issue
RHS_DRL_END detection is complicated. We need to find the best way for maintainability.
Parser rule is better than Lexer Island mode?

May revisit after all unit tests green


Header

This PR introduces basic conventions in regard to file structure we can follow.
Tried to add some comments to CSS files to understand why we do stuff, let me know if they're rather confusing and you prefer without them.

I like the comments!
We don't need them for all, but for the most important settings it is very helpful for me. 👍

closing this, will do another one once everything is done in regard to header


[WIP] Improve Windows node e2e tests

What this PR does / why we need it:
Improve e2e tests for Windows containers.  After talking with @PatrickLang around DNS issues, I did a review of the e2e tests for windows containers and notice a quite a few missing scenarios.  Opening this PR to start the work of adding more e2e test and get feedback on tests we should plan on including.
List of improvements and additions planned:

[X] Include a linux agent node in end to end tests.  This will enable testing of other scenarios down the line.
[ ] Enable DNS checks that are disabled during windows only tests.
[ ] Port above tests that make sense to a windows node
[X] Test outbound Connectivity already implemented
[ ] Windows to Windows network connectivity via DNS
[ ] Windows to Linux network connectivity via DNS
[ ] Linux to Windows network connectivity via DNS
[ ] After pod DNS is confirmed working kill the pod and try DNS again
[ ] Enable after awhile DNS check when have windows nodes.  Add tests for dns lookups for windows containers.
[ ] Add HPA auto tests (currently linux only)

Special notes for your reviewer:
Work in Progress.  Don't merge yet.
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

improve windows e2e tests

closing this PR to create issue #3632 and will submit sets of tests as they are implemented


Configure services from CLI ?

Hello and thanks for this wonderful app!
Is it possible to configure transmission, sickrage, couchpotato, etc... from CLI or from a config file please?
I'm trying to pre-configure everything on install so that services are integrated flawlessly. My users do not know the technicalities (transmission rpc url, pass, etc...).
Thanks

Thanks! There is no Cali except from the command line arguments but that for htpc manager, but any modules.
You would have to write sql "script" or a script that automatically adds it via the web gui.


{ code: -32601, message: 'Method not found' }

Hi, using shiden network got error when I geting nonce from chain by system_accountNextIndex:
{ code: -32601, message: 'Method not found' },
And this is a common api for polkadot,
https://polkadot.js.org/docs/substrate/rpc/#system
so I want to ask how can I reslove that? Any other JSON RPC api to get nonce?

should be fixed with the latest updates


Updates for dawn4.1

published<EMAIL_ADDRESS>(see version chart in README.md)

Travis can be very slow.


Crash when starting the server

Describe the bug
I have noticed that on the client side the versions are compatible, however when installing it on the server side it simply crashes, even when the server is blank without any mod.
Steps to reproduce

Install Connector-1.0.0-beta.32+1.20.1.jar, ConnectorExtras-1.8.0+1.20.1.jar, fabric-api-0.91.0+1.10.4+1.20.1.jar.
Launch server Mohist - Minecraft version:1.20.1 - Forge version: 47.2.17
Crashes instantly
...

Logs
https://mclo.gs/AlvSUA1
Additional context
Thanks to whom it may concern

Custom server apis is noot supported by connector, however u can try using MagmaMaintained which should work

Perfect, I'm going to try it, thank you very much for your support.


Blender crashing when cats blender plugin is installed

my blender keeps popping up with this issue every time I addon cats blender plugin and merge an armature to a model

I'm also experiencing this issue

i just removed the 'TESTING' entry from the list in the init.py file and it worked fine for me

from which version of the file? All of them?

@BishopVFX Remove TESTING from the __init__.py file at the root of the archive on line 319

where exactly I don't want to delete the wrong file lol

dont delete the entire file, just the TESTING attribute of the list on line 319 from the init.py file located where it said it was in the error message.
delete the comma after COMMUNITY as well


Tag number conversion functions

Tag numbers are a very useful way to sort and filter results, however, the implementation is a bit convoluted (as described here) so I propose we implement a couple of handy functions to convert to and from a tag number.

Is there any further documentation on why the bitshift is necessary for computing the tag number? The API doc is more prescriptive than explanatory.

We are approaching a vast number of news items. Many are connected to games which in turn are connected to genres, themes, player perspectives etc. All are moving parts and are subject to change. The elasticsearch query for connecting news articles to other values was too devastating for production, but merging a "type" and "id" value together and creating a single index was a vast improvement.
TL;DR for server performance and technical reasons.

I see. So the bitshift is to push the value of the tag type upwards to make room for combining with the tag value via bitwise OR. This is a unique identifier that matches both on any objects to which they apply. Is this understanding correct?
Is the bitshift always 28? Does it have any reason to vary?

That's correct. Always 28, never varies.
On Jun 19, 2017 1:36 AM, "Duane Sibilly"<EMAIL_ADDRESS>wrote:

I see. So the bitshift is to push the value of the tag type upwards to
make room for combining with the tag value via bitwise OR. This is a
unique identifier that matches both on any objects to which they apply. Is
this understanding correct?
Is the bitshift always 28? Does it have any reason to vary?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/igdb/igdb-api-node/issues/13#issuecomment-309310358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmDZ7VfcA0vqkgpZKjWm_sbvT9p27Kuks5sFbSFgaJpZM4N9k_p
.


elp server process stays up after a window reload

After a window reload, the prior server is not killed.
Originally reported in Slack.

I just checked and likely the same issue affects neovim (installation with mason.nvim). Every time I start neovim, a new elp process is started. I have a dozen running right now. :)

I meet this issue too in my neovim.
Here is my environment:
$ elp version
elp 1.1.0+build-2024-06-07

The elp binary: elp-macos-aarch64-apple-darwin-otp-25.3.tar.gz manually installed in my PATH.
When I quit nvim, the elp server process is still running. It seems to have become an orphaned process.
In the DEBUG level log of neovim, it shows the shutdown and exit methods of the lsp RPC were actually sent when I quit neovim. But the elp server was still there.
If I execute :LspStop elp ++force or :lua vim.lsp.get_active_clients()[2].stop(true)in the neovim, the elp server is killed.


In linear_sampler(data, bias), bias 'shape should NTG?

In linear_sampler(), bias'shape is NTG, why is it not N*G?

In our setting, bias is different according to its location in the temporal dimension. For detail, you can refer to our paper TIN.


remove unneeded Singularity file.

Many thanks for contributing to nf-core/bcellmagic!
Please fill in the appropriate checklist below (delete whatever is not relevant). These are the most common things requested on pull requests (PRs).
The file Singularity is not needed within the project.
PR checklist

[x] This comment contains a description of changes (with reason)

Please update CHANGELOG accordingly. This has also been addressed upstream in the nf-core/tools template so would have happened automatically upon the next tools release ;-)

Sorry, I wasn't aware of that by following the slack discussion :-|
On the other hand it looks like the template changed quite a long time ago and this wasn't incorporated into the project with the last release.

It was added today by me to the template to check for the existence of such a file - you're right that we dropped the Singularity file a while ago though ;-)


QuickLook fails to load model displaying "Object requires a newer version of iOS."

Description
QuickLook launches, but fails to load model, and displays the following message: "Object requires a newer version of iOS."
Devices with repro: iPhone
This must be intermittent because I encountered it a few weeks ago, but it stopped reproducing before I logged a bug.
Device: iPhone 12 pro
iOS version: 14.4.1 (latest updates installed)
Open Safari and go to https://modelviewer.dev/examples/augmentedreality/#customButton
Click on custom button ("👋 Activate AR") to launch QuickLook
Screenshot:

Version

model-viewer: v1.6

Browser Affected

[ ] Chrome, version <>
[ ] Edge
[ ] Firefox
[ ] IE
[x] Safari

OS

[ ] Android <>
[x] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

Interesting, but that's not SceneViewer, it's QuickLook (since it's iOS). I'm guessing there must be some kind of Safari problem happening here. Does it repro consistently?

Oops, I spaced on the name.
It's intermittency is a difficult question to answer. Both times I've encountered it, (a week or two apart) it reprod consistently. But in-between that time, on the same config that I tested the first time I encountered it, it did not repro.

I found that if the models weren't properly formatted or it's too big quick look won't work. Always try with the default Astronaut model and if it works then it's an issue with your model (most likely)


Scala Hadoop Shred: update bad rows to include timestamp

I think we can close this since it's covered by #1914


[Swift][Object] Made Object.init() a required initializer

Fixes #1916.
As far as I can tell, this doesn't negatively impact anything since convenience initializers can still be created for Object subclasses without having to override init(). /cc @tgoyne @segiddins @bdash

:+1: assuming that test failed before

That test did fail before. I'll wait for @tgoyne to review before merging.

Should we also make init(realm:schema:) and init(value:) required?

Users explicitly shouldn't be overriding init(realm:schema:), so if anything it should be final, not required.

Totally forgot about final, we should make sure we mark all the 'implementation detail' public methods as such.

I've updated this PR. /cc @tgoyne @segiddins
We can't make those other initializers final (and they certainly shouldn't be required):
public final override init(realm: RLMRealm, schema: RLMObjectSchema) {
       ^~~~~ 'final' modifier cannot be applied to this declaration

public final override init(value: AnyObject, schema: RLMSchema) {
       ^~~~~ 'final' modifier cannot be applied to this declaration

:+1:
Current CI failure is just a spurious simulation init error that's happened for a few other jobs.


Exc_Bad_Access on pusherWithKey

Hi Luke,
Sorry if I'm missing something simple.
I'm using the following code in the viewDidLoad method within the ViewController.m of a brand new project
PTPusher *client = [PTPusher pusherWithKey:@"MyKey" delegate:self encrypted:YES];
In Other Linker Flags I have -all_load
I'm linking to the following libraries:
libPusher-combined.a
libicucore.dylib
Security.framework
CFNetwork.framework
SystemConfiguration.framework
UIKit.framework
Foundation.framework
CoreGraphics.framework
libPusher-combined.a is being copied in a build phase.
The app builds and runs successfully though immediately crashes with the following crash log:
https://gist.github.com/1942930

Hi Luke. Are you retaining the client at all? Is the crash happening shortly after calling pusherWithKey: or immediately?

Damn it - sorry. Yeah it wasn't being retained :( Thanks for your help.

No problem. Please reopen this if you still have a problem.


[SPARK-34541][CORE] Fixed an issue where data could not be cleaned up when unregisterShuffle.

What changes were proposed in this pull request?
Fixed an issue where data could not be cleaned up when unregisterShuffle.
Why are the changes needed?
While we use the old shuffle fetch protocol, we use partitionId as mapId in the ShuffleBlockId construction,but we use context.taskAttemptId() as mapId that it is cached in taskIdMapsForShuffle when we getWriter[K, V].
where data could not be cleaned up when unregisterShuffle ,because we remove a shuffle's metadata from the taskIdMapsForShuffle's mapIds, the mapId is context.taskAttemptId() instead of partitionId.
Does this PR introduce any user-facing change?
yes
How was this patch tested?
exist test.

gentle ping @srowen , thanks for taking a look.

Can one of the admins verify this patch?

The existing tests are not catching this issue - can you add something to ensure we test for this problem ?

+CC @otterc

The change in SortShuffleManager looks good to me. However, we should add a UT to cover this. Also, I don't quite get how the change in StringExpressionsSuite.scala is related to this bug fix.

The change in  StringExpressionsSuite.scala is unrelated to this bug fix, for code simplifications only.

The existing tests are not catching this issue - can you add something to ensure we test for this problem ?

i will add the UT for this problem.

@yikf, can you open a PR against master branch?

@yikf, can you open a PR against master branch?

ok, should i close the currently PR?

open a PR https://github.com/apache/spark/pull/31664 against master branch


Agent stuck when reproducing the "Embodied Continuous Navigation" tutorial.

Habitat-Sim version
v0.2.1
Docs and Tutorials
Did you read the docs?  Yes
Did you check out the tutorials? Yes
❓ Questions and Help
I have read the Habitat-sim Interactivity tutorial and I want to reproduce the "Embodied Continuous Navigation" part, what I do is I loaded a mp3d scene(1LXtFkjw3qL) and copied the code in the google colab, also load the locobot_template_handle as my agent, find navigable points in the nevmesh and then defined 2 path, sometimes the agent can finished the path successfully but more often it will stuck during the 2. path, I checked related functions especially the track_waypoint() function but couldn't find where the problems, the way the agent stuck is that it jaggle around between two angels and won't move, say I set angular_error_threshold = 0.5 in the track_waypoint() function, then it stucked and the angular_error will only jump between 0.543107 and 0.542775 and not decrease as the track_waypoint() should have done. Can you give me some advice? Thanks!
Also I found in the code that, after using vel_control.integrate_transform() to get the target_rigid_state, instead set the translation of the agent to target_rigid_state.tranlation, sim.step_filter() is used to get a end_pos to place the agent, can you explain why you do that? I set the agent location directly using target_rigid_state.tranlation and get the agent successfully make the two paths, I wonder what's the difference?
this is the path setting part of my code:
while not found_path:

    origin = sim.get_translation(locobot_id)
    path1.requested_start = origin
    path1.requested_end = mn.Vector3(sim.pathfinder.get_random_navigable_point())
    path2.requested_start = mn.Vector3(path1.requested_end)
    path2.requested_end = mn.Vector3(sim.pathfinder.get_random_navigable_point())

    found_path = sim.pathfinder.find_path(path1) and sim.pathfinder.find_path(path2)

if not found_path:
    print("Could not find path to object, aborting!")

vis_objs = []

recompute_successful = sim.recompute_navmesh(sim.pathfinder, default_nav_mesh_settings)
if not recompute_successful:
    print("Failed to recompute navmesh 2!")

continuous_path_follower = ContinuousPathFollower(
    sim, path1, sim.get_object_scene_node(locobot_id), waypoint_threshold=0.4
)

# set fps
show_waypoint_indicators = True  # @param {type:"boolean"}
time_step = 1.0 / 60.0

sim.config.sim_cfg.allow_sliding = True

for i in range(2):
    if i == 1:
        continuous_path_follower = ContinuousPathFollower(
            sim, path2, sim.get_object_scene_node(locobot_id), waypoint_threshold=0.1
        )

    if show_waypoint_indicators:
        for vis_obj in vis_objs:
            sim.remove_object(vis_obj)
        vis_objs = setup_path_visualization(sim,continuous_path_follower)

    start_time = sim.get_world_time()
    max_time = 10.0
    previous_pos = sim.get_translation(locobot_id)
    while (
        continuous_path_follower.progress < 1.0
        and sim.get_world_time() - start_time < max_time
    ):
        continuous_path_follower.update_waypoint()
        if show_waypoint_indicators:
            sim.set_translation(continuous_path_follower.waypoint, vis_objs[0])

        if locobot_id < 0:
            print("locobot_id " + str(locobot_id.object_id))
            break

        previous_rigid_state = sim.get_rigid_state(locobot_id)

        # set velocities based on relative waypoint position/direction
        track_waypoint(
            continuous_path_follower.waypoint,
            previous_rigid_state,
            vel_control,
            dt=time_step,
        )

        # manually integrate the rigid state
        target_rigid_state = vel_control.integrate_transform(
            time_step, previous_rigid_state
        )

        # snap rigid state to navmesh and set state to object/agent

        end_pos = sim.step_filter(
            previous_rigid_state.translation, target_rigid_state.translation
        )

        sim.set_translation(end_pos, locobot_id)
        sim.set_rotation(target_rigid_state.rotation, locobot_id)

        # Check if a collision occured
        dist_moved_before_filter = (
            target_rigid_state.translation - previous_rigid_state.translation
        ).dot()
        dist_moved_after_filter = (end_pos - previous_rigid_state.translation).dot()

        EPS = 1e-5

        collided =  (previous_pos-sim.get_translation(locobot_id)).dot() < EPS

        previous_pos = sim.get_translation(locobot_id)

        # run any dynamics simulation
        sim.step_physics(time_step)

        # render observation
        observations.append(sim.get_sensor_observations())

Hey @Goooyi, thanks for your thoughts on this tutorial code, hopefully it was useful for you to understand how one might consume Habitat-sim for continuous navigation.
Sorry to hear you are experiencing issues with the example heuristic controller for tracking rotations. This isn't really meant to be a perfect control function, but rather to provide a simple example of how to use the APIs. Ideally you can use this as a stepping stone to invent or train a replacement controller which works better for your use cases!
Regarding the purpose of the step_filter function: We use the NavMesh to constrain agent motion without simulating dynamics and 3D contact testing. The step filter validates and, if necessary, truncates the agent's desired linear step against the NavMesh. By skipping this filter, the agent would be allowed to move through walls and obstacles. Following the computed shortest path through the scene as the example is doing will minimize these artifacts, but be aware of the implications here.

Hi @aclegg3 thanks for the explanation! I will sure use this as a start to do more with the agent. And I have a few more questions, one is that, I seen the agent will stuck during simulation whenever a stairs(going down or up) is encountered, my question is, whether the way you control the agent in the tutorial can go up or down in stairs? I haven't be able to recompute a suitable navmesh for the agent to walk, so I wonder it's have something to do with that.  Another question is that, when I set two robots to walk randomly in the scene, if they bump each other, after step_filter, they will go though each other or the agents' desired linear step will be truncated?

I've seen the agent will stuck during simulation whenever a stairs(going down or up) is encountered, my question is, whether the way you control the agent in the tutorial can go up or down in stairs?

In general stairs are not a problem for the NavMesh. Low ceilings and missing stair geometry in some scenes can, however, cause issues for certain configurations of the NavMeshSettings (used to configure the parameters of the NavMesh for recomputation). There are a few parameters which impact this: agent_height, agent_max_climb, agent_max_slope, filter_low_hanging_obstacles.
I suggest you take a look at this Colab tutorial from ECCV 2020 which has an interactive NavMesh computation cell (start at "Working with the NavMesh") where you can play with the settings and visualize the resulting top-down map. You can also configure the Simulator to render the current NavMesh as a wireframe by setting the navmesh_visualization property to true allowing you to inspect the NavMesh for a scene. The viewer.cpp or examples/viewer.py can be useful for this kind of debugging.

Another question is that, when I set two robots to walk randomly in the scene, if they bump each other, after step_filter, they will go though each other or the agents' desired linear step will be truncated?

Currently there is no agent collision logic in the step filter if you are setting agent positions kinematically using only the NavMesh as a constraint. You could add this logic with a custom step_filter function that checks other agent positions if this is necessary for your work and we'd be happy to review the code if you decided to contribute it back to the project as a PR.
Alternatively, contact between agents could be modeled dynamically if your robots are simulated using forces/torques as control and have attached collision objects instead.


Update ALR release to 2.0.2. MacOS rework.

In docs/learn/getting-started:

installation.md: Updated release verson to 2.0.2. Better link to installation description.
macos-issues/alire-vs-aarch64.md: Availability of tools for Apple silicon also mentioned.
macos-issues/alire.md: Likewise. Updated stable tools version to 2.0.2.
macos-issues/crates.md: Removed links to alr, compilers (now they're all available via alire).
macos-issues/issues.md: Reworked. Added discussion of new C, C++ errors related to SDK v16.

It would be great to have this in the Alire documentation.


Add some new modes in Config and add a Join game NPC

Hello developers, I would like to suggest that you can improve the BungeCord mode by adding an NPC (such as Hypixel) to allow players to connect to the game through BungeCord. You can also add Lobby and Game options to identify whether the server is a Lobby server or a Game server. This way, you can do better

I want to use RealSkywars' Level and achievements in the Lobby but I need use BungeeCord mode in realskywars Config

What you want to use is a shared RSW database between the lobby and the game server

but ur RealSkywars can't custom ItemJoin

what?

I change the Config "ITEM in lobby" but there is nothing to appear I want to remove the "Maps" Item on Lobby

Put it in slot -1 so it disappears

ok thx
I translate the language file to Chinese Maybe I can give u next Sunday
This plugin is very good!

Ok. Make sure to open a issue with the new config file, thanks.


Add a new / updated generator to the roadmap

It seemed like a good idea at the time, but the generator at https://github.com/github/generator-hubot is a bit of a maintenance headache. Previously, it was just part of the hubot package and just dropped files on disks without a 'real' generator.
https://github.com/github/generator-hubot/issues has some of the current issue, but I have also seen in the past lots of issues with just installing yeoman, since it has a ton of dependencies.
I'm not picky about where on the roadmap it is, but it should go somewhere.
cc @bkeepers @mose

Yes I think we really need to add it on the roadmap.


gif image in ios, use "File file = await entity.file" return jpg, how get gif to upload

gif image in ios, use "File file = await entity.file" return jpg, how to get gif image to upload and preview, this in android is ok, but in ios is not working, i am used version is 0.5.6

gif image in ios, use "File file = await entity.file" return jpg, how to get gif image to upload and preview, this in android is ok, but in ios is not working, i am used version is 0.5.6

Because HEIC cannot be directly used by flutter, the file is designed to be transcoded. If you want to obtain the original image, try to obtain titleAsync first, determine whether the name is the end of gif, and then use originFile to obtain the original resource.
See if it solves your problem.

.file will return a file that has been compressed with a default argument. Use originalFile to fetch the original one.


Local mp4 movie does not play from its torrent in the UI

Using<EMAIL_ADDRESS>built per instructions from git and npm.
Operating system: OS X El Capitan 10.11.6 with Node version v0.10.22
Did this: Created a torrent with Transmission for a local MP4 movie sized 106 MB   (without any trackers of course), dropped it on the designated area of the UI, and tried to play it in the UI.
Should have: The movie should have started to play
Instead: Nothing downloads and the circular icon spins forever and the movie does not play

Node v0.10 is really old. If you want to help develop WebTorrent, try upgrading to the current version of Node, v6.4
Alternatively, if you just want to use the app, I recommend installing from the DMG. That way, you don't have to care about dependency versions and you'll also get the latest fixes and improvements thru the auto updater

If you try option 1 or 2 and this still happens, let me know!


fix(region): Add public/private feature for Guest Image

这个 PR 实现什么功能/修复什么问题:
Public/private subimages firstly when do public/private for guest image.
Add cmd "guest-image-public" and "guest-image-private".
是否需要 backport 到之前的 release 分支:

release/2.12
release/2.13

/area glance climc
/cc @wanyaoqi

/area image

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@1417338). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master   #3786   +/-   ##
========================================
  Coverage          ?   6.94%
========================================
  Files             ?     499
  Lines             ?   84252
  Branches          ?       0
========================================
  Hits              ?    5850
  Misses            ?   77906
  Partials          ?     496

Flag
Coverage Δ

#aFlag
6.94% <ø> (?)

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 1417338...d0529e1. Read the comment docs.

/lgtm

/lgtm

/approve

/approve


Some unhandled metrics

pool - subnet[id].pool[pid] has a bunch of per-pool stats
v4-lease-reuses - Number of times an IPv4 lease had its CLTT increased in memory and its expiration time left unchanged in persistent storage as part of the lease caching feature. This is referred to as a lease reuse. This statistic is global.
v6-ia-na-lease-reuses - Number of times an IA_NA lease had its CLTT increased in memory and its expiration time left unchanged in persistent storage as part of the lease caching feature. This is referred to as a lease reuse. This statistic is global.
v6-ia-pd-lease-reuses - Number of times an IA_PD lease had its CLTT increased in memory and its expiration time left unchanged in persistent storage as part of the lease caching feature. This is referred to as a lease reuse. This statistic is global.

Support for per-pool labeling and v4-lease-reuses is now available on develop. I will have to upgrade my router to Kea 2.4.0 to test for the other two metrics.


Fixes #75 - Upgrade nokogiri to 1.7.1 to address the security alerts.

Fixes #75 ; refs #75
Upgrade nokogiri to address the security and critical alerts.
Changes proposed in this pull request:

Upgrade nokogiri to 1.7.1

@ucsdlib/developers - please review

👍

:+1:


Adopt prettier for consistent formatting

@feross what do you think in terms of adopting prettier ? The reason I find it appealing is because in the process of adopting standardjs (see browserhtml/browserhtml#1271) we found out that it's too permissive and does not catch variety of awkward formatting options.
I think with a help of prettier standardjs could deliver promise of "JavaScript Standard Style". Unfortunately that would require some work prettier/prettier#736 to make prettier output standardjs compatible.

Posted this too early going to edit description to include more detalis.

It isnt the right thing in any way. There is ES-Beautifier that tries to does everything using the ESLint ecosystem. That's the right move. Prettier is meant to be opinionated and so it can be easily integrated and should not be.
The ESLint --fix feature is awesome, and we all should just invest much time to implement autofixes for any rules that we want, then no matter the style we will have awesome consistency prettifier and linter in one. ESLint is the right tool for such things.
ESLint autofix works great here. I think the most important rule that we should implement autofix is max-len :) Most of the other things are handled already.
And everyone should use standard --fix by default (even, I think it should be enabled by default here) while they run their lints. I even seen few times that there is even two separate npm scripts for just standard called lint and another for fix called fix, wtf? Why? Why you should care and why you want to get tons of warnings most of whose can be autofix with just adding a single flag? It is completely mess.
Just Prettier isn't the right tool. Tried it in last months. Both approaches - first linter than prettiefier and reversed first prettier then the linter - both not work well.
ESLint is most awesome ecosystem in that community, for sure. And we should use it, everyone should use it as both Linter and Prettiefier/Beautifier. It just need help.

It isnt the right thing in any way. There is ES-Beautifier that tries to do everything using the ESLint ecosystem. That's the right move. Prettier is meant to be opinionated and so it cant be easily integrated and should not be.

I fundamentally disagree with this. Prettier completely disregards input format and spits out in a consistent format while ESLint and tools around that attempt to preserve typed style & that is pretty much makes consistent styling impossible.

The ESLint --fix feature is awesome, and we all should just invest some time to implement autofixes for any rules that we want, then no matter the style we will have awesome consistency prettifier and linter in one. ESLint is the right tool for such things.

As we tried to adopt standard style we run into too many cases where ESLint was unable to fix things up.

ESLint autofix works great here. I think the most important rule that we should implement autofix for is max-len :) Most of the other things are handled already.

Not in my experience there is ton of things it can not fix and there is also ton of flex in the way code can be formatted, and standard will accept. So at the end of the day we still have majority of comments in pulls about formatting, which defeats the purpose, to us anyway.

And everyone should use standard --fix by default (even, I think it should be enabled by default here) while they run their lints. I even seen few times that there is even two separate npm scripts for just standard called lint and another for fix called fix, wtf? Why? Why you should care and why you want to get tons of warnings most of whose can be autofix with just adding a single flag? It is completely mess.

In my experience fixes actually produce awkward results in terms of formatting, my guess would be that is a reason.

Just Prettier isn't the right tool.

You have not offered any convincing argument to support that claim, just your own opinion that ESLint is a way to go. Please try to offer more constructive input and offer some data to support claims.

Tried it in last months. Both approaches - first linter than prettiefier and reversed first prettier then the linter - both not work well.

I am not surprised given that prettier output does not follow stardardjs rules. By work is required I meant following @jlongster's suggestion to fork prettier to add an options for [standardjs][] rules, hopefully it would be possible to merge it back in.
Can you share list of things that did not work.

ESLint is most awesome ecosystem in that community, for sure. And we should use it, everyone should use it as both Linter and Prettiefier/Beautifier/Formatter. It just need help.

It's cool that you feel that way, but saying everyone should use it is a bit too much. For flow typed projects ESLint has very little to offer other than enforcing formatting as type system deals with actual errors. And given that formatting rules are too flexible result is again, valuable engineering time is spend in discussing or comprehending code formatting.

@Gozala We used a separate tool to do formatting in the past (esformatter) and it was a huge maintenance burden and very difficult to get the formatter to output code that would consistently pass standard. See https://github.com/maxogden/standard-format
I think prettier is cool, especially if you want to always re-format code on every git check-in, but it's too aggressive for normal use. It will reformat even code that passes standard, which is just too intrusive to recommend to the average user. If you want to start a separate project that uses prettier to format code in standard style, that sounds like a great idea.
But I think we'll stick with eslint's --fix since we want the following:

One config where we maintain all our rules.
Code that passes should not be reformatted.

I'll also mention that the trend of each release of standard is to tighten up rules to allow multiple ways of writing the same thing. There are many more rules around formatting that we plan to add in future releases in 2017. So issues like the ones you ran into should be caught in future releases once we tighten up those rules.
But we would like to go about enabling these rules a few at a time in a slow, steady process so we don't overwhelm the community with too many changes at once.

standard doesn't have to do everything. A package.json script that runs prettier then standard --fix should solve your problem and requires no changes to standard at all.

@timoxley That's actually a neat solution for folks who prefer more aggressive regular formatting of their code.

standard doesn't have to do everything. A package.json script that runs prettier then standard --fix should solve your problem and requires no changes to standard at all.

That won't work, because Prettier and Standard rules will collide. It would be great if efforts could be unified and maintainers of boths libs would agree on same code style...

but it's too aggressive for normal use.

I think it's very strange to hear that from creator of lib, which actually aggressively enforces rules on developer.

I think this might be one of those things we look back at in a year and be like, why did we cling on manually formatting the code. Auto standard ftw.

I think this might be one of those things we look back at in a year and be like, why did we cling on manually formatting the code. Auto standard ftw.

Yeap. I'm ready for this right now :D
As a side information, about "love" between Standard and Prettier, I will just leave this link here https://github.com/facebookincubator/create-react-app/issues/1847#issuecomment-287631806, maybe someone has somthing meaningful to add.

I think it's very strange to hear that from creator of lib, which actually aggressively enforces rules on developer.

@ArmorDarks not a fan of your tone here, it could be mistaken as hostile; please show some moderation going forward. Thank you kindly :sparkles:

@yoshuawuyts If you read my conversation with Dan by following link above, you will see that I'm adept of Standard and defend it, thus I didn't mean to be hostile.
However, yeap, I was sarcastic, because both libraries enforces aggressive rules, so it sounded like very strange and vague argument against when said by creator of one of those libs.

@ArmorDarks I'm a fan of the concept of prettier, but hesitate to adopt it for the following reasons:

Maintaining two configs that will be hard to keep in sync.

It might not be possible to configure prettier in a way that complies with all the ESLint rules that standard enforces. In that case, it would autofix code in a way that doesn't pass standard.

In an ideal world, they'd adopt all the standard rules (and possibly allow configuration to change controversial ones, like no semis, for their users). Then we could use it for --fix.
If you or someone else wants to look into this approach in more detail, I'm open to at least reviewing the PR.

Ah, @feross. nevermind my earlier replies.
To make this happen we will need attitude to make compromises and changes from both and Standard, and Prettier communities, to unite efforts and focus on strongest points (linting with Standard and code formatting with Prettier) instead of continuing bikeshedding.
I was hoping to make this happen, to help communities unite, but after pretty much aggressive replies of @gaearon against Standard here https://github.com/facebookincubator/create-react-app/issues/1847 and recently discovered regreatful issue https://github.com/feross/standard/issues/78 (which explains nature of @gaearon attitude toward Standard) started by @gaearon and supported by @jlongster (creator of Prettier) here https://github.com/feross/standard/issues/78, I have very little believe that this could happen.
Not in this world, I guess.

@ArmorDarks FWIW, I'm open to working with the prettier team. It would be nice to replace standard --fix with prettier.
Do you know if it's possible to configure prettier in a way that produces code that passes standard?

cc @vjeux

You can already use standard without its formatting rules by using https://www.npmjs.com/package/eslint-config-prettier, and then use prettier to format it. Users interested in this issue are mostly interested in getting the non-formatting rules.
For standard using prettier by default, it's going to be hard, not because of any ill will on either sides, but because there is already a significant community behind both so changing the styles is going to force one of them to change a lot. I don't know what the answer is. If someone wants to pursue it we need to more concrete changes to evaluate it.
Note that a large number of people prefer to run prefer in their editor frequently as they are coding (prettier by default is very fast, much faster than eslint, so it's very responsive), and do linting as a less frequent step. I think it makes sense to separate linting and formatting, and allow users to combine them how they want.

Also, prettier's code wrapping (which is an integral part of why it produces good code) is always going to be a big change for the output of standard. There's not way we can make it so that our output is exactly the same as the current eslint --fix with standard, if that's what is being proposed. There wouldn't be much point in switching to prettier anyway then.

If we did this, we'd probably want to add a new standard --format flag:

standard --fix – make the minimal changes to satisfy standard (uses eslint --fix)
standard --format – format the code, which may end up changing valid code (that already satisfies standard) into another valid format (uses prettier)

So, then users that want one canonical format could throw standard --format into their editor.

there is already a significant community behind both so changing the styles is going to force one of them to change a lot

The good news here is that standard already has a --fix flag that helps to ease the transition when we change a rule in new major versions. It would be interesting to see a full list of the style differences so we can evaluate how doable this is.

Just thought I'd link to this: prettier-standard-formatter. It's actually simpler to implement than prettier-eslint because with standard you don't need to search around for eslint configs/derive prettier options based on those configs. Pretty nifty :+1:

If we did this, we'd probably want to add a new standard --format flag

I think I'm a little confused what the goal is: do you want to take advantage of prettier's wrapping & forcing consistency on more general things (like function arguments), but still apply standard's whitespace rules? If so, that should be pretty easy: run prettier first and then standard --fix. Is that what standard --format could do?
Or are you all somehow wanting the output of standard to be the same as prettier, meaning it runs prettier as the last step? That seems harder because we would have to talk about all the differences and see if we can reconcile. I'm not sure I see the benefit of that since you could easily run standard --fix after prettier to tweak it to get all the current rules (like a space after function name).
Looks like prettier-standard-formatter is runs prettier first and than standard --fix which makes sense.
I'm happy to continue talking about what potential integrations look like!

Thinking out loud here...
I think the goal of standard --format would be to automatically format invalid code so that it's valid according to standard (this is what standard --fix already does) but also, to format even valid code into one unambiguous format.
standard's style rules are designed to be easy for humans to remember, so that you can write valid code without constantly referring to the guide or using a tool to format the code.
So, there are a number of situations where standard allows multiple styles.
// both styles are allowed by `standard`
const x = (z) => z
const y = z => z

Since both styles are allowed by standard, then standard --fix will not touch this code.
But standard --format would rewrite this code using prettier:
const x = z => z
const y = z => z

Then after running prettier, we'd run standard to check for non-style issues, like possible errors, usage of deprecated APIs, confusing code, etc.
So, it seems like in an ideal world, standard --format would just be prettier plus standard's non-style rules. That is, it would literally run prettier && standard.
To get to this world, I think we'd need unify our style guides so that prettier outputs code that passes standard.

I think we want (I want) standard to automformat the code (such that all
standard codebases are identical, unambiguous). Maybe that just means I
should switch to prettier.
But Feross makes a good point - standard is designed to be human writable
and indeed very pleasant to write.
Feels like we should be able to converge the two, fudamentally, I mean cant
see why we need both prettier and standard. Im sure I (and anyone) could
get used to whatever slight variations of style each lib chooses. It's more
about the question of - should code style be enforced and unambiguous or
should we leave a bit of room for human interpretation (not sure which one
is better). The goal of "human writable" is great, but maybe at conflict
with "unambiguous".
🤔
On Thu, 13 Apr 2017 at 21:30, James Long<EMAIL_ADDRESS>wrote:

If we did this, we'd probably want to add a new standard --format flag
I think I'm a little confused what the goal is: do you want to take
advantage of prettier's wrapping & forcing consistency on more general
things (like function arguments), but still apply standard's whitespace
rules? If so, that should be pretty easy: run prettier first and then standard
--fix. Is that what standard --format could do?
Or are you all somehow wanting the output of standard to be the same as
prettier, meaning it runs prettier as the last step? That seems harder
because we would have to talk about all the differences and see if we can
reconcile. I'm not sure I see the benefit of that since you could easily
run standard --fix after prettier to tweak it to get all the current
rules (like a space after function name).
Looks like prettier-standard-formatter is runs prettier first and than standard
--fix which makes sense.
I'm happy to continue talking about what potential integrations look like!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/feross/standard/issues/811#issuecomment-294013393,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATzWIkMPFHv9-ssY2v7ORyuGYzFuwdoks5rvoXWgaJpZM4MSpCd
.

@feross I see, thanks for explaining!
I'm a little worried about both of the communities having to keep in sync and making sure that any changes need to be accepted by both, etc. But I actually think most of the things we'd change are not even whitespace-related or things that standard's formatting rules care about. Usually it's bug with how things are laid out.
Although.. that might not be true. A good example is that we are thinking of changing how we output ternaries. Right now we happen to output them as standard expects, actually. But we might change that.
I think we're actually very in sync already. The biggest difference is the space after function name. I'm betting that you all don't want to change that, I don't think we're going to change that on prettier... as its a pretty frequent thing in the code. Not sure what we'd do about that specific case, but concerns about not being able to change the format still stands.
Is there any reason it can't be prettier && standard --fix? Does standard --fix behave exactly the same way that standard does, meaning it outputs a list of failures, except that it fixes ones that it knows it can? If so, what would be the downside of that?

I think we're actually very in sync already.

Agreed! I think there's a real opportunity here, given a few compromises, to prevent further fragmentation in community conventions.

but concerns about not being able to change the format still stands.

This is a fair point. But I think that if we wanted, we could each do a release where we change a rule or two and then we're totally in sync. Bam. Then we can recommend standard --fix to help our users migrate, and of course with prettier, your users just run it once more and they're upgraded.
There are challenges, but this seems totally doable if both projects want to make it happen.

Is there any reason it can't be prettier && standard --fix? Does standard --fix behave exactly the same way that standard does, meaning it outputs a list of failures, except that it fixes ones that it knows it can? If so, what would be the downside of that?

Your description of how standard --fix behaves is correct. We could totally do prettier && standard --fix. If there's support for that idea amongst the standard team, we could ship that without any cooperation between projects.
But, then we don't get the huge win that would come from aligning our styles. Namely that it would be easy to switch from/to the different projects, prettier would output code that passes standard, and then there's one fewer style out there in the wild.

Awesome. I gotta run but let's keep talking!
Are you all really opinionated about the space after function name? fwiw we've been referencing the airbnb style guide to inform us (as one data point) of what is a popular style, and they don't use the space there. It also seems to be preferred by most people who use it. This is probably going to be the biggest sticking point between our styles, I'm guessing.

Also our default style is semicolons, but we just added an option to not use semicolons, so we can do prettier --no-semi && standard but technically standard's default style will still by different than our default style...

most noticeable thing for me is that prettier expands function arguments if >1 and i believe not makes code more readable but more bad. i 'm totally okey with that tobe only when >3.
second one is that it expands objexts, even if object has only one prop. (no space between curlies in objects isng good too  {foo:1}, not sure if that can be fixed using esling config prettier)
as about the space after fn name, it's acceptable to relax the rule so there won't have breaking changes.

btw, to clarify a bit about fn args expanding, i'm okey with if line is around 80 to do the expanding in multiple lines, even if the only one arg.
sorry, im on phone

@jlongster and @feross
Glad to hear you two talking about harmonizing both tools. I already use standard as a linting tool, and it is one of the tests in the build process.  I'm keen to bring on board Prettier as well, especially if I can easily configure the editor to do auto formatting (in my case, that's VS Code), without having to do manual configuration per developer.
prettier --no-semi --single-quote gets us pretty far already, but I'd be very glad to see a solid solution for the last mile (either on the side of prettier or standard).  I especially think of the following issues:

The "the space after function name" you already mentioned
In JSX, --single-quote still spawns double quotes. I understand this is more HTML-like, but standard doesn't like it (yet?).

Keep up the good work. I'm definitely keeping an eye on this!

Hey, what's the latest? Have peace talks broken down?

Basically, the only thing that differs between prettier's style and standard's style is the rule about parens after a function declaration (the space between the name and parens, e.g. function test ()).
I ran some quick tests on one of my codebase, and it's the only thing that triggers warning from standard.
So, there's three possibilities :

Prettier adds an option to choose between function test() and function test (). Con: one more option, for something very small — many people would then ask that Prettier adds an option for every minor detail they don't like.
Standard removes this rule. Con: it "breaks" many files. Once.
Nobody does anything, and we have fragmentation AND two great tools that can't work together. Using prettier, then applying --fix is not a great solution imo.

Cheers.

It's worth noting that even with --single-quote option prettier will still use double quotes in jsx.
https://github.com/prettier/prettier/pull/126

FWIW, I have been using prettier and standard together for months now, and have not felt a huge need to marry the two packages with each other directly.
I have the following inside of an NPM script
prettier --write **/*.js && standard --fix **/*.js

I write my code following the best practices of standard, then use this script to update anything that prettier is more opinionated about. If standard --fix has a non-zero exit code, then I know there is something incompatible between what prettier wrote and what standard is okay with, and I will need to fix it manually (note: this has yet to happen in any codebase I've used this script in).
With this script, I have been able to reap the benefits of both prettier and standard with virtually no friction, and without having to force the two libraries to support each other.

@solarsailer

Prettier adds an option to choose between function test() and function test (). Con: one more option, for something very small — many people would then ask that Prettier adds an option for every minor detail they don't like.

I just added --space-before-function-paren to prettier-miscellaneous, if anyone wants to use that instead. See https://github.com/arijs/prettier-miscellaneous/issues/22 for details.

@sorahn

It's worth noting that even with --single-quote option prettier will still use double quotes in jsx.

I'll probably try to add a --jsx-single-quote option as well, but it looks a little more complicated.

I'll probably try to add a --jsx-single-quote option as well, but it looks a little more complicated.

This is now also supported, see https://github.com/arijs/prettier-miscellaneous/pull/23
However, it looks like there's (at least) one more inconsistency between prettier --no-semi --single-quote --jsx-single-quote --space-before-function-paren and standard: the formatting of blocks within ternaries. For example, here's some code that is correctly formatted according to prettier-miscellaneous with the aforementioned options:
let options
const events = typeof options.trigger === 'string'
  ? options.trigger.split(' ').filter(trigger => {
      return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
    })
  : []
console.log(events)

However, standard unindents the callback:
let options
const events = typeof options.trigger === 'string'
  ? options.trigger.split(' ').filter(trigger => {
    return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
  })
  : []
console.log(events)

Here's the diff:
diff --git a/p.js b/s.js
index c778a36e..0ccb242f 100644
--- a/p.js
+++ b/s.js
@@ -1,7 +1,7 @@
 let options
 const events = typeof options.trigger === 'string'
   ? options.trigger.split(' ').filter(trigger => {
-      return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
-    })
+    return ['click', 'hover', 'focus'].indexOf(trigger) !== -1
+  })
   : []
 console.log(events)

https://github.com/prettier/prettier/issues/1271#issuecomment-294163500 has a good argument in favor of the prettier formatting, so I wonder if standard would be willing to adopt it.

I personally prefer the prettier formatting for those ternary blocks :)

https://github.com/prettier/prettier/issues/1271#issuecomment-294163500 has a good argument in favor of the prettier formatting, so I wonder if standard would be willing to adopt it.

I created a separate, more general issue for this: https://github.com/feross/standard/issues/927

Looks on this issue globally, I don't think that hijacking prettier formatting with additional options to fit standard helps anyway the situation. As long as development of styles of prettier and standard goes on divided and without common agreement between contributors of both libraries, we will constantly struggle and will always end up in situation when some library changes something, and we need to adapt to those changes again. Well, not a problem if you're borg, but we aren't borg.
In other words, it isn't reliable solution, which patches the issue, but doesn't resolve it fundamentally.

What situation? Every developer wanting to format their code the way they want? This is specially not a problem because it can be easily changed back afterwards.
Yes, the language evolves, and there will be work to be done. What's the problem? It's not rocket science. What is the fundamental solution? That the Javascript standard stop evolving so that the formatters stop needing to be updated?

I'm just want to make standardjs happy, any solution about this? will the "--jsx-single-quote" and "--space-before-function-paren" work?

makes some falsy activity

I've been using tslint/eslint and standard for years and tried prettier yesterday for the first time. I totally blow away by its capabilities and plan to switch. I guess I have to keep standard in order to test the code. In this case I think this will be my solution before committing
prettier --write **/*.js && standard --fix **/*.js

@QuantumInformation yup. But make sure to use quotes for the globbing patterns.

Don't remember what the conclusion in this thread is, but for what it's worth..

❤ standard – been using it for many years now in all of my projects
❤ prettier – started it using more recently, and it's auto formatting is very liberating

But in some ways it feels like 2 "standards" now. I'm using https://github.com/sheerun/prettier-standard which works really well. And perhaps that's that.
But it kind of means I have to be using 3 tools instead of just 1 – prettier, standard and prettier-standard. That's because:

prettier is really good at formatting the code, but doesn't lint against common errors
standard is much stricter and is really good at catching various linting errors

So you can't use just one or the other. And so you end up using prettier-standard, which for example, doesn't have a lint command, only format command. So if you want to make sure in say CI that everything conforms, you have to run standard in addition to having prettier-standard installed.
Anyway, sorry for the longish post. But still seems like .. there's a future where there's 1 tool that does both formatting and linting really well. Having to use ~3 tools (or prettier-standard) seems a bit like a small step back (although a good experiment).
And to me that tool is standard - if it had formatting powered by prettier built in.

I'd be up for helping to maintain a fork of prettier that adds the necessary options for making it compliant with Standard without having to run eslint --fix afterward. We could have it under the standard org and have the explicit goal of merging options upstream.
We could then create a tool that requires that fork, and exposes a nice cli, without any options, working like standard --fix, but reformats all source.
Potentially that could then be included in the standard command behind e.g. --format.
Just an idea ☺

@LinusU that sounds good. I wonder if you've used prettier-standard before? It actually already works really well. But the only command it has is formatting.
So really, standard already lints, if we just switched standard --format to do what prettier-standard does that's basically would do it. We'd have 1 cli with both standard linting and prettier and standard compatible formatting.

If we did this, people that prefer prettier could continue using that, people that prefer raw eslint could continue using that, but standard would be for the rest of us - the linter rules we (the rest of us..) all agree to follow + a very powerful formatter.

On Fri, Oct 19, 2018, 2:21 PM Linus Unnebäck<EMAIL_ADDRESS>wrote:

I'd be up for helping to maintain a fork of prettier

Considering that tools such as prettier-standard and
prettier-standard-formatter already exist, can someone elaborate on the
possible need for direct integration with prettier itself?
Any comments on how existing tools such as prettier-standard and
prettier-standard-format compare?
I wonder if anyone might want to use prettier together with semistandard or
custom standard or eslint rules?
My understanding is:

standard is a more simple combination of items of good practice based on
eslint
prettier has a larger scope of making the code look better, hopefully
following at least some of the principles of good practice

I would favor the following:

document how standard could be used together with prettier in this
project
Integration should be outside this project
raise/promote an issue on prettier to provide more integrated support for
following standard, semistandard, custom eslint rules, etc.

Considering that tools such as prettier-standard and prettier-standard-formatter already exist, can someone elaborate on the possible need for direct integration with prettier itself?

These packages basically first run prettier and then run standard --fix. Preferably, we would be able to just run prettier and it would output code that already conforms to the Standard rules.
It was a while since I last tried them out, but I remember having some problems with that approach, and it was also quite slow.

Again, prettier-standard works really well, it's fast on Visual Code (but very slow on Sublime Text). So whatever prettier-standard and vscode plugin are doing, I think this whole thing is already doable with not too much effort at this point.
It's just a matter of whether the owners of standard wish to integrate it into --format command essentially merging in prettier-standard into this tool.
What other technical challenges are there? One negative is increasing the size of standard with all of prettier.. But that's probably tolerable?

Just saying that this thread and the possibility for the 2 biggest tools to merge (or at least be compatible with each other) is fantastic! For my team the deal-breaker is space-after-function-parens, so we're forced to run TSLint after prettier every time and it's a bit slow (TSLint is way slower than prettier). If only we could have an option in prettier to add space after function name - that would make it compatible with Standard and everyone will be happy!

@KidkArolis @sheerun
So I've recently switched to prettier-standard which is awesome so far. Unfortunately, I've run into a few issues getting my VSCode setup working ideally. I found the most popular extension for Prettier+Standard had some slight inconsitencies with the prettier-standard CLI, so I ended up just using an extension to run the CLI on file save and that's working great. The thing I'm missing though (and it's huge), is the auto-linting hints I got while typing from the standard extension.
The only way I can see getting that working is adding back babel, eslint, and babel-eslint as project dependencies which is unfortunate. I would set it up globally, but here doesn't appear to be any way to have a global config for standard :thinking:
Anyways, just wondering if anyone has gotten format on save and linting while typing working with prettier-standard

You can use healthier or lynt for linting while using prettier-standard just for formatting.

Healthier has both healthier pkg which behaves mostly like standard and has editor plugins. Or you can use it as eslint-config-healthier combined with eslint editor plugin. That way you can use either prettier or prettier-standard to format the code.

So, I think the ideal setup would be one npm module (+ one editor plugin) that gives you formatting on save and linting as you type - all with no configuration. Then use husky and lint-staged to enforce both on pre-commit.
I've been using standard now for a few years, but decided to give prettier a try as I was unhappy with certain style inconsistencies that kept occurring.
Long story short, I ended up going down a rabbit hole of inconsistencies between prettier and standard  (like spaces after function names :man_facepalming:). I've since settled on prettier and healthier with a 4-line prettier config. healthier basically just provides an ESLint config that is close to standard but compatible with prettier. If I ever need to customize, I can just drop down to vanilla ESLint.
@KidkArolis Thanks for the awesome package, and great choice on the name :+1:
Good bye standard :wave: , it's been fun :tada:

It's a bummer that prettier can't adopt spaces after function names though. Seems like the only major incompatibility between prettier and standard left. Spaces after function names are so obviously correct from a consistency stand point, but I guess they're sticking with popularity on that one.

@NathanielHill: Spaces after function names are so obviously correct from a consistency stand point

Same was here. But I switched around 1.5 year ago (after years of using Standard) to the @Airbnb style - definitely liked it and it makes much more sense to me, cuz I always been a fan of a bit more strictness (pretty great considerations/practices and a lot lot rules).
Looking from the perspective of a few years using both Airbnb+Prettier (~2y) and Standard (2y), I really think that tools like standard, xo and the others that appeared after them, isn't that great thing. It sounds and feels unnecessary stacking of tooling, APIs and deps.
"Zero config". But you can have zero config with picking up basic eslint and preset of your choice (or your own), or just throw the most popular ones - airbnb & standard, as configs.
Anyway, no bad feelings :1st_place_medal: It's probably great from someone who is junior-to-mid or just starting up until realizing he/she (or its community) need better style and quality.

@tunnckoCore with airbnb, does airbnb code style rules not complain about prettier’s formatting? Or do you turn them off somehow?
Re, “it’s probably great for someone who is junior-to-mid”, a strange way to classify this. Since so many many people and tools use standard who I wouldn’t call junior.. And I have been using standard 5+ years because of its ease of use, when you work on dozens of repos, the zero config approach shines, one dep, does it all, helps you catch the bugs, is not too strict so never complains about things that would get in the way. But admittedly, I actually never really tried airbnb, there’s just not enough time to try all the things :)

@tunnckoCore I loved standard as well. My main problem was just that it's not opinionated enough! I was getting tired of the mental overhead of dealing with style inconsistencies. It sounds silly, but it's really non-trivial over a large code base. Especially, writing as you are constantly exerting mental overhead to at least try to be consistent. Now that I've got my linting working again (50% of the benefit for me is just catching typos in real time) I'm loving how much less I have to think about styling with prettier :+1:

Not a nice bot

I decided to do the same and move back to ESLint with Prettier + eslint-config-standard

Absolute legend @sheerun

I am using prettierx along with eslint to avoid having to fix then format, with good results so far. Here are my simplified config files, if anyone is interested:
// .eslintrc.js

module.exports = {
  parserOptions: {
    ecmaVersion: 2019,
    sourceType: 'module'
  },
  env: {
    node: true
  },
  plugins: ['prettierx'],
  extends: ['standardize', 'plugin:prettierx/standardize-bundle'],
  settings: {
    prettierx: {
      usePrettierrc: true,
      editorconfig: true
    }
  },
  rules: {
    'generator-star-spacing': [
      'error',
      {
        before: true,
        after: true,
        anonymous: { before: true, after: true },
        method: { before: true, after: true }
      }
    ],
    'prettierx/options': ['error', require('./.prettierrc.json')]
  }
}

// .prettierrc.json
{
  "printWidth": 100,
  "semi": false,
  "singleQuote": true,
  "quoteProps": "consistent",
  "jsxBracketSameLine": true,
  "jsxSingleQuote": true,
  "endOfLine": "lf",
  "spaceBeforeFunctionParen": true,
  "trailingComma": "none",
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "generatorStarSpacing": true,
  "yieldStarSpacing": true
}

As far as I can see, it mostly adheres to standard, and a simple eslint --fix checks and formats everything. It is also supported by all editor eslint plugins I have tried so far.

It is worth considering adding this feature for standard@17 already.
I opened a PR in standard-engine to add prettier support. :smile:
https://github.com/standard/standard-engine/pull/231

A different approach: #1872 .


Add install instructions for Docker Extension for Meshery

Current State
A Docker Extension for Meshery has been created and will be publicly available at DockerCon 2022.  A description of the extension and how to install it are needed. See https://layer5.io/docker-extension-meshery and https://hub.docker.com/r/meshery/docker-extension-meshery for details.

Desired State
Add Docker Extension as a second option in the Docker deployment instructions.
docker extension install meshery/docker-extension-meshery:stable-latest

Contributor Guides and Resources

📚 Instructions for contributing to documentation

Meshery documentation site and source

🛠 Meshery Build & Release Strategy
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

Contributor Resources
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
See Meshery site designs in this Figma designfile. Fill-in the Layer5 Community Member Form and join the Layer5 Community Slack for access.

Hello @leecalcote ,If this is unassigned can I work on this?
and is this related/same as https://github.com/meshery/meshery/issues/5473

@karnatisrinivas, right: two highly related issues. ✔

Two related issues, but two different sites, so two updates needed.

@karnatisrinivas, heads-up: the deadline for this update is Sunday, May 8th, 2022. If a PR isn't submitted by the 7th, I'll carry this request forward.

Hello Lee, Please let me know if this is the action required.

Looks good to me, @karnatisrinivas 👍


Duplicate translate-string for GROUP.DESCRIPTION

GROUP.DESCRIPTION is in the translation file twice - creates some random translation errors in other languages.

GROUP.DESCRIPTION was originally the string for the create and edit page.
Now there is another key needed for the tab in the mobile group view.

We now have a verbose and a short description.


test: execute rth with the interpreter

This variable is needed to run the validation test suite on Windows.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test

This fixes a single instance, but, matches what we do for %gyb.  We can improve this later.


query problem

Hi
I use UserMixin to create my User class:
class User(UserMixin):
    email = db.Column(db.String(255), unique=True, nullable=False)
    password = db.Column(db.String(255), nullable=False)
    registered_on = db.Column(db.DateTime, nullable=False)
    admin = db.Column(db.Boolean, nullable=False, default=False)

I can save data to the database but I can't fetch anything from database! I think the problem is on type part, when I check the query statement I can see this:
print(User.query)
SELECT fp_user.id AS fp_user_id, fp_user.type AS fp_user_type, fp_user.email AS fp_user_email, fp_user.password AS fp_user_password, fp_user.registered_on AS fp_user_registered_on, fp_user.admin AS fp_user_admin
FROM fp_user
WHERE fp_user.type IN (NULL)

and because of this where part nothing coming out from this query!

Having the same problem also. No problem adding a user, which shows up in the database:
# select * from fp_user;
 id | type | username |                                           password
----+------+----------+-----------------------------------------------------------------------------------------------
  1 |      | flask    | pbkdf2:sha256:50000$32tQqbEE$57c91570bb2b508d8ce4233facbe4154dba14feefbd20b1671b56fe17aea5ddf
(1 row)

But when I query the User class in Python I get an empty list:
>>> User.query.all()
[]

tablename = 'fp_user'
table_args = {'extend_existing': True}
Add these lines in User model. That's worked for me.


don't allow any service url if custom services backend is used

Reopen of previous PR with a separate branch, see #78 for details.

Looks good to me, @jbittel what do you think? I'll do some local testing if you think it is ok to merge.
@evilscientress could you please rebase on current master?

@manelclos I rebased the branch on the current master.


Hi, I'm having trouble starting the bot.

Hi, I'm having trouble starting the bot, I have configured everything, but when I start it it tells me this: internal / modules / cjs / loader.js: 883   throw err;   ^  Require stack:     at Function.Module._resolveFilename (internal / modules / cjs / loader.js: 880: 15)     at Function.Module._load (internal / modules / cjs / loader.js: 725: 27)     at Module.require (internal / modules / cjs / loader.js: 952: 19)     at require (internal / modules / cjs / helpers.js: 88: 18)     at Object.  (C: \ Users \ user \ Desktop \ MinecraftServer-DiscordBot-2.1.1 \ bot.js: 1: 17)     at Module._compile (internal / modules / cjs / loader.js: 1063: 30)     at Object.Module._extensions..js (internal / modules / cjs / loader.js: 1092: 10)     at Module.load (internal / modules / cjs / loader.js: 928: 32)     at Function.Module._load (internal / modules / cjs / loader.js: 769: 14)     at Function.executeUserEntryPoint [as runMain] (internal / modules / run_main.js: 72: 12) {   code: 'MODULE_NOT_FOUND',   requireStack: [     'C: \ Users \ user \ Desktop \ MinecraftServer-DiscordBot-2.1.1 \ bot.js'

Hello,
It seems like you are missing some libraries/have outdated libraries. Have you installed/updated all the needed libraries?
I've also updated the bot with updated libraries and better code the past few days. Try a newer release and see if the problem still exists.

I just released v3.0.0 of the bot now, which is fully up to date and easier to configure. You can download the new version here.

Closing this issue for now because of inactivity.
I can reopen it if you still have the issue but first try the new version 3.


Add nominee: OpenLMIS

Automatic addition of a new nominee submitted through the online form available at https://digitalpublicgoods.net/submission

https://digitalpublicgoods.net/platform/#OpenLMIS


Add a new "Node.js Fullstack" ebook

@jollen Could you, please, fix the alphabetical order ?

@kataras Yes, I could. I have fixed the order.

Thanks!


KB - How can you leverage service dependencies in Gradle daemon to im…

KB - How can you leverage service dependencies in Gradle daemon to improve build performance?
KB - Using Images from multiple ACRs
Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the maintainers.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore
[x] Tested Locally
[ ] Optional Screen Shoot.

Resolving the conflict


feat:  join

Closes #745
Summary of Changes
Implemented a join function for Table

@zogomii @FredericAbels Can you finish this today?

@zogomii @FredericAbels Can you finish this today?

Camilla has an exam tomorrow. I will go to the institute and try my best to finish the issue.

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

v0.27.0
GitHub release

Your semantic-release bot :package::rocket:


Update RDS module and add replica

https://trello.com/c/F6UQeeiN/777-design-rds-replicas-and-backups
Please see detail in commits.
This updates the module with some sane defaults, and assigns a replica for app-postgresql.

I've added two more commits which change the way in which the module works.
I'm also aware that I've created the replica in a different way that was envisioned; I think that we it was envisioned to have a separate project for the replica rather than rolling it into the same project.
I don't think this makes sense. A database cluster should be an atomic thing, and having to manage them separately seems counter intuitive to me, but I am willing to be convinced otherwise.


Players can enter a claim with enter-claim player false with ender pearls

GD Version: 1.2.1h
Paper 186 (Minecraft 1.14.4)
For this test, I created a claim and did /gd flag player Tobeka enter-claim player false
Tobeka can get inside the claim with ender pearls and move around inside with the ender pearls (as long as he doesn't walk).

Does this occur with 1.2.1j?


ColumnChartStyle reverses data

I am on version 1.0. The ChartStyle influences the order of the input data as you can see in the screenshot.
As this is kind of unintuitive and I couldn't find any note that/why it is done this way I guess it's a bug.

I found that you can easily reverse the array before passing it to the Chart, in order to get around this bug:
Chart(data: Array(yourArray.reversed()))
The LineChartStyle and AreaChartStyle are affected by this. ColumnChartStyle is ok. I haven't tried the others.

Hi would you take a PR? I think this will fix it
public func makeBody(configuration: Self.Configuration) -> some View {
    let data: [ColumnData] = configuration.dataMatrix
      .map { $0.reduce(0, +) }
      .reversed() // <-- this
      .enumerated()
      .map { ColumnData(id: $0.offset, data: $0.element) }

    return GeometryReader { geometry in
      self.columnChart(in: geometry, data: data)
    }
  }

@23inhouse I think it is better to change the leadingAlignmentGuide function in Styles/Column/ColumnChartStyle.swift.
Simply add a negative sign before the returning result.
private func leadingAlignmentGuide(for index: Int, in availableWidth: CGFloat, dataCount: Int) -> CGFloat {
    let columnWidth = (availableWidth - (CGFloat(dataCount - 1) * spacing)) / CGFloat(dataCount)
    return -((CGFloat(index) * columnWidth) + (CGFloat(index - 1) * spacing))
}


Add 'how we use react-router' doc

This PR is a first pass at getting documentation around how we use (and test) react-router. I tried to describe and provide examples of patterns and related utilities. I hope to eventually add a bit more in the testing section but this seemed complete enough to move forward with a PR.
To run locally
I was able to run with: bash <(curl -s https://raw.githubusercontent.com/monfresh/fresh-brew/main/fresh-press). if that doest work check out the readme https://github.com/transcom/mymove-docs/blob/main/README.md
Validation

[ ] Docs build and the new doc is visible at /docs/frontend/guides/how-we-use-react-router
[ ] No spelling or grammar errors
[ ] Content makes sense and is easy(ish) to follow/understand
[ ] Nothing to egregious is missing

@duncan-truss Hi, no rush at all, just wanted to note since you're the maintainer can you add Brandonhere?. Thanks!

@mandaem I can make the changes on GitHub but it won't persist unless Platform or myself opens a PR because it is managed in Terraform.  It was likely just missed during onboarding https://github.com/transcom/transcom-infrasec-com/blob/main/transcom-com-infrasec/github-global/truss_team_teen_vogue.tf


Korean language support added

kr.js file has been uploaded on lnbits/lnbits/static/i18n folder.

I reworked your PR to PR https://github.com/lnbits/lnbits/pull/2119 - it adds more stuff that need to be added in order to add Korean into the user interface. Thank you for your contribution to LNbits!


Bleve

Has anyone tried using this with bleve.
Bleve does this plus alot more but lacks decent Chinese / Japanese stemmers.
Using this with bleve would be a powerful stack

It is recommended to refer to riot's gse participle to using bleve.

Closed because it is currently unsure whether to add.

bleve does facets and from what i saw riot does not.
facets are very powerful

I will consider joining it and welcome to contribute code.

any progress ?

I wrote Gse plugin for Bleve.
Repo is here: https://github.com/leopku/bleve-gse-tokenizer

I wrote Gse plugin for Bleve.
Repo is here: https://github.com/leopku/bleve-gse-tokenizer


Dockerfile.s390x: Move to gcc 6.1 (go 1.6.1)

Pull request #22840 and commit 40b21745cc ("Upgrade to golang 1.6.2")
introduces gcc 6.1 for Dockerfile.gccgo and Dockerfile.ppc64le.
So do this also for s390x and use "s390x/gcc:6.1" as base image.
In addition to this use "GO15VENDOREXPERIMENT=0" for notary build
as a workaround for golang/go#15814
Signed-off-by: Michael Holzheu<EMAIL_ADDRESS>

LGTM

Hmm, the Z test didnt seem to fail for a good reason, just seemed to hang, retrying.

Hmm, the Z test didnt seem to fail for a good reason, just seemed to hang, retrying.

Well... at least the build was successful.
Currently CI tests do not work reliably on s390x because we are waiting for two glibc fixes (needed for the gccgo runtime) for Debian Jessie:

https://sourceware.org/git/?p=glibc.git;a=commit;h=890b7a4b33d482b5c768ab47d70758b80227e9bc
https://sourceware.org/git/?p=glibc.git;a=commit;h=2e807f29595eb5b1e5d0decc6e356a3562ecc58e

The fixes are already in the Debian Jessie glibc repository: https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/log/?h=jessie
But they have not released a new glibc package up to now.
Once they release a new glibc package version, the s390x/gcc:xxx images will automatically updated by the build process that @tianon installed.
I contacted @tianon if it is possible to manually update the packages in the s390x/gcc:xxx images until we get the official release, but he seems to be busy with other things at the moment.
Ping @tianon :-)

Ah ok, well LGTM then.

LGTM


batching not working in the stable release

The example 5 mentioned in this article is not working in the stable build of PnP PowerShell. If batching feature is not available for the stable build then it is not mention it in this article so others won't be get confused. Otherwise it is better to mention the required version on PnP PowerShell Module.
As from the github issue https://github.com/pnp/powershell/issues/327 it specified that this feature were removed from Stable build and moved in to the 1.3.14-nightly release.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cc3efa2d-f7d5-d9d0-d306-7707e4906065
Version Independent ID: f30dd9c9-c9fc-f3f9-d5f4-ee4e1b8d3f53
Content: Set-PnPListItem (PnP.Powershell)
Content Source: sharepoint/sharepoint-ps/sharepoint-pnp/Set-PnPListItem.md
Service: sharepoint-powershell
GitHub Login: @pamgreen-msft
Microsoft Alias: pamgreen

Hello @JosephJojo
how are you?
Even though the PnP documentation articles are on this repository, I need to kindly redirect you to open PnP cmdlets issues/pull requests here, in that repository, where a member of the PnP community will be able to correct the article/review your inquiry with your feedback.
The documentation for PnP cmdlets is then synced from that repo into this one.
Thank you!

@get-itips Thank you very much for the contribution and sharing this explanation. @JosephJojo Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


feat: semantic-release reconfiguration

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

1.24.0
GitHub release

Your semantic-release bot :package::rocket:


sktime's AutoARIMA doesn't run seasonal detection by default

This issue tracks setting a "period for seasonal differencing" in ARIMA based on the number of periods in each season that are expected. Due to AutoARIMA's inability to iterate over the period for seasonal differencing parameter, we're limited in our default implementation when tackling seasonal issues, and would therefore be unable to adapt to use cases with AML.
from sktime.forecasting.arima import AutoARIMA
from sktime.datasets import load_airline

y = load_airline()
forecaster = AutoARIMA(suppress_warnings=True)
forecaster.fit(y=y[:100])
preds = forecaster.predict(fh=[i+1 for i in range(44)])

preds.plot()

y = load_airline()
forecaster = AutoARIMA(sp=12, suppress_warnings=True)
forecaster.fit(y=y[:100])
preds = forecaster.predict(fh=[i+1 for i in range(44)])

preds.plot()

Based on that granularity of intervals that we decide to separate the data with, this parameter will have to be updated prior to running AutoML.

This could be related to why ARIMA does not perform well on the user guide dataset. This came up in #2697

Closing in favor of #2922


JavaScript error in IE11

HI,
I am getting a java script error in IE11 while i am adjusting the pane.

Hi,
Thanks for reporting this.
Should be fixed in e74399344fc4338cf7482368e99b0ba9d9ab10dc. Fix will be included in next version.


Improvements to Button component appearance and documentation

Summary
Multiple improvements to the Buttons visual appearance, and its documentation in Storybook (with more visual testing coverage applied as a result).
🔗 Try the changes in Storybook
List of notable changes:

added an inactive visual appearance to the Button, which it previously didn't have

added additional Storybook stories for: hover, focus and disabled states

added visual screenshot coverage of all the above

added new design tokens to apply required changes and enable app-side customisation

updated Storybook structure to match recent ADR around playgrounds, defaults and feature

updated focus styles from previously bespoke grey to global focus tokens

What should reviewers focus on?

Try out Storybook and see if the states work as expected

Steps to test:

Open the Button in Storybook with this link.
Cycle through the stories and playground
Verify that all Storybook controls behaves as expected

Supporting resources (related issues, external links, etc):

Designs in Figma

Contributor checklist:

[x] All new and existing CI checks pass
[ ] Tests prove that the feature works and covers both happy and unhappy paths
[ ] Any drop in coverage, breaking changes or regressions have been documented above
[x] New visual snapshots have been generated / updated for any UI changes
[x] All developer debugging and non-functional logging has been removed
[ ] Related issues have been referenced in the PR description

Reviewer checklist:

[ ] Check that pull request and proposed changes adhere to our contribution guidelines and code of conduct
[ ] Check that tests prove the feature works and covers both happy and unhappy paths
[ ] Check that there aren't other open Pull Requests for the same update/change

Screenshots:

Please try to provide before and after screenshots or videos

🆕 Storybook playground

 Before  After

🆕 Inactive (disabled) states
Primary

 Light  Dark

Secondary

 Light  Dark

Subtle

 Light  Dark

Updated focus styles

 Light  Dark

In Safari, the focus doesn't look good because the outline is not following the border-radius. The latest Safari Technology Preview is changing this. I'm unsure if we could try to work around this in the meantime (e.g., by only using a double drop-shadow) or if it's better to keep it as-is and wait for this change to land on the stable version of Safari.


Docker improvements

I've edited Sweetie Bot to work better with Docker, adding a dedicated data folder/mount and a database volume to make backing up and restoring data easier, modifying the compose file to stop the bot before the DB, preventing "Database failure detected!" messages when stopping the containers. I've also edited the dockerfile to fix issues I encountered while building the containers, such as missing dependencies and files not having the execute flag.
The way I moved the files to the data folder has worked fine for a week on Windows and Linux without any apparent issues, but I'm sure someone who actually knows Go can think of a better way of doing it.

While this is a relatively simple change that could in principle be merged, because you moved the data files to another folder, it is totally impossible to merge this change without a substantial effort being put into figuring out how to migrate existing configurations. This is made even worse because the current migration code is focused on per-server changes. There is no actual migration path for dealing with the bot's configuration itself, and this changes the location of all of that.


feat(derive): BatchStream buffering

Overview
Implements the rest of the BatchStream, buffering the span batch that is received and sending only SingleBatches to the batch queue.

Assignee: https://github.com/anton-rs/kona/issues/559

Dawg: #576

oop, mb - thought this was something different, closing

#592
#590  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @clabby and the rest of your teammates on  Graphite


Add Jason Knight mailmap entry.

Add Jason Knight mailmap entry.

Thanks! As discussed on chat, I'll include this in an AUTHORS.md update commit I plan to push tomorrow.


add scan command that calls gitleaks detect

it should also help the user install gitleaks and introduce them to it.

https://github.com/dotenvx/dotenvx/pull/90
going out in 0.19.0


Staff : Create a new API for updating an existing user

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable) ### https://tools.hmcts.net/jira/browse/RDCC-5457
Change description ### Staff : Create a new API for updating an existing user
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

new PR will be raised to merge in dev branch . closing this one.


Create a "How to CDK" reference page

Create a basic reference page to cover getting started with CDK deployment, possibly nested under the "SDKs" section.
Related: https://github.com/restatedev/cdk/issues/18

Merged.


Option to specify maximum single line length vs wrapping width

It would be nice to say: if the imports are longer than 100 characters, wrap at 80 characters
For example:
from django.core.exceptions import FieldDoesNotExist, FieldError, PermissionDenied, ValidationError
from django.forms.models import (
    BaseInlineFormSet, inlineformset_factory, modelform_defines_fields,
    modelform_factory, modelformset_factory)

HI @collinanderson,
Thanks for the suggestion! I agree this would be a useful feature, and will implement it before the next version of isort.
~Timothy Crosley

Hi @collinanderson,
This is now supported in release 3.9.5 - using the wrap_length setting documented here  https://github.com/timothycrosley/isort/wiki/isort-Settings
Thanks!
~Timothy

Wow. That was fast! Thanks!


Fixed references to Yahoo pages

Motivation
Fixed links to yahoo/pulsar github repo and examples with com.yahoo.pulsar package names.
Added disclaimer in download page to notice the release is for "Yahoo Pulsar" and not "Apache Pulsar"
(We'll remove the disclaimer once the next release is out).

cc/ @lucperkins

👍