Failed to identify PDU

[facebook]

Failed to identify PDU

[wez]

I think this might be due an issue with the BSER client in the watchman CLI.
Try this instead:

$ watchman --persistent --server-encoding=json log-level debug

[nmalcolm]

Thanks. I'm now getting a bunch of assessing triggers messages. To clarify, is that to fix the issue with debugging or with watchman not executing scripts? If the latter, is there a way to set server-encoding to json always (I'm assuming that watchman does its own thing with starting up; correct me if I'm wrong)?

[wez]

my comment was about connecting to the debug output. You haven't given any details on your other issue, so it's difficult to say whats's going on. What does watchman trigger-list $root say?

[nmalcolm]

{
    "version": "2.8.2",
    "triggers": [
        {
            "name": "generatestatic",
            "command": [
                "./scripts/celerity_mapper.php ./webroot"
            ],
            "rules": [
                {
                    "pattern": "*.css",
                    "include": true,
                    "negated": false
                }
            ]
        }
    ]
}

Running ./scripts/celerity_mapper.php ./webroot from the root works fine, and git status does show that .css files have been modified. I tried using absolute paths too, to no avail.

[wez]

Run watchman --persistent --server-encoding=json log-level debug in one window, then in another, touch a .css file. Watchman should assess the trigger for your css and try to invoke celerity_mapper.php.

The triggers happen on file changes as they are noticed; it doesn't talk to git to see if the file is different

[nmalcolm]

Output: http://pastebin.com/d8QeTWej

The triggers happen on file changes as they are noticed; it doesn't talk to git to see if the file is different

I'm aware; git status shows that the .css files are modified but once they have been it should also show that ./src/__celerity_resource_map__.php has been modified too.

[wez]

Have to dash, but wanted to quickly respond: the output in your paste shows that watchman is trying to execute this:

"./scripts/celerity_mapper.php ./webroot" "changedfile.css"

We use a driver script for the command; you could do something like:

#!/bin/sh
exec ./scripts/celerity_mapper.php ./webroot $*

and then register that as your trigger

[nmalcolm]

The command which needs to be executed is ./scripts/celerity_mapper.php ./webroot. Is there a way to omit the argument which watchman adds?

This is the command I'm using to create the trigger.

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- "./scripts/celerity_mapper.php ./webroot"

[wez]

If you don't want to pass the changed files to celerity_mapper.php, you should use a script like this:

#!/bin/sh
exec ./scripts/celerity_mapper.php ./webroot

Then

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- './scripts/run-celerity-mapper.sh'

otherwise, change your quoting so that it runs the right thing:

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- ./scripts/celerity_mapper.php ./webroot

We don't currently have a way to tell the trigger dispatcher to not pass the changed filenames, but do want to add that functionality.

[nmalcolm]

I had tried that originally but this is the only debug output when I changed the CSS file:

{
    "version": "2.8.2",
    "log": "1381517326: tid=798742272 inotify read: returned 256.\n"
}
{
    "version": "2.8.2",
    "log": "1381517326: tid=798742272 inotify read: returned 192.\n"
}

It doesn't look like it's trying to execute celerity_mapper.php?

[wez]

I turned off BSER by default in the CLI, so I'm considering this good enough for now.
The future for this is a BSER implementation based on libphenom when I finally get a chance to push that diff.