Release 0.6.0 totally screwed up linux support. Many repeated missing events, bogus "removed" events etc.

Using gaze 0.6.4... touch src/*.js when it is watching many files in src will often only register 1. It's basically so broken it isn't even remotely usable for me here.

FIX THIS

@adambratt Patches welcome.

IMO this isn't a case of "patches welcome", this is a case where you should totally pull gaze 0.6+ from npm until it can be fixed. Gaze is now completely worthless on Linux, the most popular platform for running node.js, yet when you npm install gaze this is the release you get. Anybody who does that will waste so much time. Given the popularity of this package, it doesn't seem acceptable.
You could at least put a warning up saying "Gaze 0.6 and above only work on Mac OS X."
You could also push another 0.5 series release with a higher version as the most recently pushed package becomes the default install in npm rather than the highest version.

npm i gaze will install v0.5.1 (because io.js and node v0.12)
"works" is an opinion. v0.6.x passed all the tests on Linux/Windows/OSX. So it "works" for me which is why I released it.
I don't owe you anything. I say "patches welcome" to let you know you can just as well fix things but you have chosen not to.

Yes obviously, but most people when they start a package do "npm install --save packagename" and assume the latest is the best. Just as a favour to the community I think 0.5 should be the default pulled version, you can fix this simply whether you choose to pull the broken releases or not.

Participating in a community isn't about owing stuff, it's about being nice and not wasting people's time.

@shama drop whatever it is you're doing and fix this, you owe it to the world for putting up with your terrible, terrible software. I mean, this project isn't even alive. You should feel bad about releasing this software, free for use and for others to contribute back to, without having it be always bug-free.

@josegonzalez I think that's a little harsh, I just think a warning on the frontpage and a changing of the default npm version number would be appropriate in this instance until a fix can be made at a convenient time.

I mean, he's wasting our time by not doing fixing the issue or telling people otherwise, why should we be kind to him?  Stop choosing to use my code.
Closing as wontfix to not waste any more of the OP's time.


[#818 / #823] - Fixed free text issue

Fixed free text issue when adding CLA Manager
Fixed footer issue on contributor console
Fixed issued in request company access

Signed-off-by: hnexokonkwo<EMAIL_ADDRESS>

@hnexokonkwo can you resolve the conflicts on this PR? Thanks!


Fix code blocks in /about

Add lang- classes so hl.js identifies them correctly (it thought
Rust was C++ and TOML was INI before)

Remove large blank space caused by newlines in HTML source

I haven't tested this aside from copying-and-pasting into Firefox Developer Tools because I don't have a local dev environment set up for docs.rs.

Test failure looks unrelated.

TOML and INI are aliases for each other within highlight.js, their highlighting is identical

TOML and INI are aliases for each other within highlight.js, their highlighting is identical

Okay, but it can't hurt to add the hint in case it changes in the future :)

@rustbot label: -S-waiting-on-author +S-waiting-on-review

Hmm, still not quite right:

Not sure how to fix it though.

What do you mean? That highlighting looks good to me :)

What do you mean? That highlighting looks good to me :)

Yes, but there's an extra blank line at the top (the removal of the bottom one worked though) and the if let is missing indentation inside it.

Try changing the decent level to 3 and removing the newline after  <pre>.


Allow FXFileChooser to reuse an existing observable list of paths (or files)

In certain environments (with folders of 100 000s of files) it might be helpful to run a scheduled task to keep the list of files updated. Therefore it might be useful to have FXFileChooser to work with an externally populated observable list.
Furthermore, provide a scheduled Update service which can be used in Swing and JavaFX applications.
Idea

Decouple the directory update service from FXFileChooser
Make FXFileChooser to use this service

Questions

How to deal with manual refreshing? Hide it and rely only on scheduled refreshes?

This should be used as of commit 7a681dfca46aeb2407e86d530c59fc1c86dc9f10 but there is no nice creation or builder API around.

The file chooser model controls the handling of the files list. There live the FileUpdateService and FindFilesTask inside net.raumzeitfalle.fx.filechooser package. Paths and files are indexed as IndexedPath. The indexed path carries the file modified date with it so browsing no longer causes file system access. Instead a manually triggered refresh is required. This is at least finished since 6d41de8b058847c5cf460c462b9e435da48ff813.


[Doc]: document optimization

In the future, we may be able to remove the version column from the API table and replace it with tag for attribute. like this:

Current version is beta still. Version column could be useful in GA version.


SystemD not executing shell script

Hi,
Great solution. I'm trying to use webhook and I'm unable to get systemd to execute my shell script. It only works when I start webhook from the command line.
/etc/webhook.conf
[
  {
    "id": "app-api",
    "execute-command": "/srv/scripts/webhooks/git_webhook.sh",
    "command-working-directory": "/var/www/api.domain.com",
    "response-message": "Executing deployment script"
  }
]

/srv/scripts/webhooks/git_webhook.sh
#!/usr/bin/env bash

# Redirect stdout/stderr to a file
DS=`date +%Y-%m-%d`; mkdir -p /var/log/webhook/$DS/
exec > /var/log/webhook/$DS/webhook_output.log 2>&1

# Locate and assign git binary.
git=$(which git)
app_path=/var/www/api.domain.com/

cd $app_path && $git fetch && $git pull

# Restart PM2 webserver
/usr/bin/pm2 restart all

When I execute the following, the script runs and everything works:
/usr/bin/webhook -nopanic -hooks /etc/webhook.conf -verbose
When I start webhook "systemctl start webhook" which runs the same command above without the -verbose flag, I get the return message but my shell script isn't executed at all.
Any help is appreciated.

Please share your systemd service definition file for webhook.

@moorereason Thank you for responding.
/lib/systemd/system/webhook.service
[Unit]
Description=Small server for creating HTTP endpoints (hooks)
Documentation=https://github.com/adnanh/webhook/

[Service]
ExecStart=/usr/bin/webhook -nopanic -hooks /etc/webhook.conf -verbose

[Install]
WantedBy=multi-user.target

I'm assuming this is a permissions issue.  I use the following directives to have the process run as the user+group that I want:
[Service]
User=webhook
Group=webhook

I updated it as follows, same issue:
[Unit]
Description=Small server for creating HTTP endpoints (hooks)
Documentation=https://github.com/adnanh/webhook/

[Service]
ExecStart=/usr/bin/webhook -nopanic -hooks /etc/webhook.conf -verbose

[Install]
WantedBy=multi-user.target

This is now fixed. I updated /etc/webhook.conf as follows


Bug: Type guards on Type can lead to never type

This simple code does not compile:
    if (type.isAnonymousType()) {

    } else if (type.isArrayType()) {

    } else if (type.isEnumType()) {

    } else if (type.isBooleanType()) { // Line 77

    }

message: 'Property 'isBooleanType' does not exist on type 'never'.'
at: '77,21'

And I think it is because of a bug in the TypeScript compiler:
https://stackoverflow.com/questions/47111236/generic-type-guards-assuming-never

That is interesting! Thanks for reporting it. I've changed these to all be straight booleans and in the future will (1) wrap the different kinds of compiler types and (2) add back the type guards. This is fixed in 0.81.1 (just packaging for release... will be released in a few mins).

Wait! @dsherret, you can actually have a better fix.
Just add a dummy field __dummy: T in the class where T is the Type of the node. Check the answer of the StackOverflow question.

That's strange, because it already uses the type parameter type on the compilerType property. Maybe there's something else going on here
Anyway, when working on #114, I found out that these type guards were only added for internal reasons and aren't really that useful outside the library. I scraped #114 since everything is already available on Type. So this is no big deal to remove.

Oh, it probably didn't work in this scenario because ts.EnumType extends ts.Type.

I think type guards are useful. They just need to be implemented carefully. By the way, can I invite you to slack? We could discuss these issues faster.

@ezequiel-umu I'm sporadically at my computer today. In general I agree that type guards are very useful, but for this case, can you give one scenario where the type guards that were previously here are useful? All the functionality I can see is available on Type.


Accept nil data when updating polymorphic to_one relationship

Related to #656
Ensure that verified_params[:to_one].values[0] is present before calling [:id] and [:type]
This way the following request clear the polymorphic relationship in the same way as a non-polymorphic relationship.
PATCH /articles/1/relationships/author HTTP/1.1
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json

{
  "data": null
}

Wasn't able to create a test case using defined test model since there is no to_one retaltionship.

@Zooip Thanks!


Remove hard fail when version of remote does not match

Instead, give a warning. This prevents case when someone has container created with 1.2 and updated VS which came with 1.3 and now they can't connect to their containers.

https://github.com/Microsoft/RTVS/commit/cc84c4aa37f69aa5f8a9d63cc4281a734f0ab89d