GithubHelp home page GithubHelp logo

activitywatch / aw-server-rust Goto Github PK

View Code? Open in Web Editor NEW
165.0 6.0 50.0 1.35 MB

High-performance implementation of the ActivityWatch server, written in Rust

License: Mozilla Public License 2.0

Rust 96.50% Shell 2.59% Makefile 0.91%
rust rest-api activitywatch server sync timetracking

aw-server-rust's Introduction

aw-server-rust

Build Status Coverage Status Dependency Status

A reimplementation of aw-server in Rust.

Features missing compared to the Python implementation of aw-server:

  • API explorer (Swagger/OpenAPI)

How to compile

Build with cargo:

cargo build --release

You can also build with make, which will build the web assets as well:

make build

Your built executable will be located in ./target/release/aw-server-rust. If you want to use it with a development version of aw-qt you'll want to copy this binary into your venv:

cp target/release/aw-server ../venv/bin/aw-server-rust

How to run

If you want to quick-compile for debugging, run cargo run from the project root:

cargo run --bin aw-server

NOTE: This will start aw-server-rust in testing mode (on port 5666 instead of port 5600).

Syncing

For details about aw-sync-rust, see the README in its subdirectory.

aw-server-rust's People

Contributors

2e3s avatar cjc7373 avatar dentosal avatar dependabot-preview[bot] avatar dependabot[bot] avatar erikbjare avatar iloveitaly avatar johan-bjareholt avatar lockblock-dev avatar luzpaz avatar nathanmerrill avatar patrolez avatar shootingking-am avatar skewballfox avatar stefanochiodino avatar victorwinberg avatar xylix avatar y7n05h avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

aw-server-rust's Issues

Needs restart if importing buckets from a large file

When I import large data the bucket list doesn't get updated and I get this error for every bucket:

[2019-03-02][08:14:13][_][ERROR] Failed to write response: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }.

But then if I restart after this all the buckets and their data is there?
Something must be wrong in the Database thread? Are mpsc requests being returned too early?

Found when testing #22

Should the new settings API use values as strings or as JSON?

I was fiddling around with the new settings API, thought it was the value was supposed to also be JSON but realized that it was a string.

Here's an example

// This is how it looks
{
  "key": "johan.test.test1",
  "timestamp": "2020-08-09T17:58:29.672Z",
  "value": "test string"
}
// This is how I expected it to look
{
  "key": "johan.test.test1",
  "timestamp": "2020-08-09T17:58:29.672Z",
  "value": { "test": "data" }
}

I think it would make more sense to allow it to be any JSON type than to force it to be an string specifically.

Do you guys agree @ErikBjare and @xylix?

We need to decide on this before we start using the API, otherwise it might become very hard to change.

Changes to database required for syncing

A couple of things:

  • We need to be able to create instances of the database that do not migrate/update like the local instance does (to ensure that they are readable by versions of aw-server-rust that are not up-to-date)
  • We need a way to enable read-only DB access

Thoughts @johan-bjareholt?

GitHub actions failing due to "No space left on device"

Likely the cache growing very large.

Cargo cache on android builds is currently 2.35GB and growing, maybe it will also be an issue in the future for other targets as well.

Seems to be the same as
rust-lang/rust#70738

System.IO.IOException: No space left on device
Unhandled exception. System.IO.IOException: No space left on device
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.FlushWriteBuffer()
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.IO.FileStream.FlushWriteBuffer()
   at System.IO.FileStream.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at System.Diagnostics.TraceSource.Flush()
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at GitHub.Runner.Common.TraceManager.Dispose(Boolean disposing)
   at GitHub.Runner.Common.TraceManager.Dispose()
   at GitHub.Runner.Common.HostContext.Dispose(Boolean disposing)
   at GitHub.Runner.Common.HostContext.Dispose()
   at GitHub.Runner.Worker.Program.Main(String[] args)
   at GitHub.Runner.Common.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)
   at GitHub.Runner.Common.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)
   at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)
   at GitHub.Runner.Worker.Worker.RunAsync(String pipeIn, String pipeOut)
   at GitHub.Runner.Worker.Program.MainAsync(IHostContext context, String[] args)
System.IO.IOException: No space left on device
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.FlushWriteBuffer()
   at System.IO.FileStream.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at GitHub.Runner.Common.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)
   at GitHub.Runner.Common.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)
   at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)
   at GitHub.Runner.Common.Tracing.Error(Exception exception)
   at GitHub.Runner.Worker.Program.MainAsync(IHostContext context, String[] args)

Significant differences between reporting of aw-server and aw-server-rust

I looked at my events for a day a month ago, and there are a couple of significant differences between what aw-server-rust and what aw-server reports.

Not sure if it's due to the migration or one/multiple transform issues.

  1. Individual application time:
Application aw-server aw-server-rust
Firefox 48m26s 46m38s
Chromium 38m41s 9m31s
Gedit 9m 8m57s
Guake 1m 1m35s
Unknown 14s 15s

Note: Individual application time seems to vary everywhere, and in all of the tabs.

  1. Total Active time
aw-server aw-server-rust
1h 38min 1hr 6 min
  1. Active browser time in Browser tab:
aw-server aw-server-rust
1 hr 21 min 52 min

Another potential bug: If you sum up ALL of the times for each browser domain, they won't be equal to the total active browser time for aw-server-rust. This issue doesn't occur for aw-server.

  1. Top categories amounts are also all very different between the 2 servers. This however, is expected given point 1.

  2. Timelines look the same(from a high level view)

OS: Fedora 32, Gnome 3.36, Xorg

RAM usage grows until it "hits" some limit

When aw-server-rust initially starts the ram usage is very low (res 9MB on my machine, less than aw-watcher-afk/window at 30-40mb) but after a while it grows to a bit above 100mb and stays there.

To reproduce, start aw-server-rust and see it use 9MB RAM, go to the web-ui activity view and click "refresh" a few times until you see aw-server-rust grow in ram usage. For me it stopped growing at around 113MB of RAM usage.

Cut events past starttime/endtime

aw-server-rust storage is now inclusive about filtering events within a starttime+endtime, we need to cut the events which go outside of this filter.

Running aw-client tests on aw-server-rust

This would be a neat because it would enable sharing of tests on the API level. Would be great for ensuring that communication between implementations is consistent.

Low priority though.

Importing of buckets with invalid utf-8 strings fails

I once visited a website which on purpose created invalid utf-16 strings in the title. This should be very rare as this site went to great lengths with messing up the characters (it essentially did so to be artistic, the site is virtualself.co)

When I try to import such buckets from aw-server-python to aw-server-rust it fails with the following

thread '' panicked at 'Failed to deserialize import data as JSON to bucket format: Error("unexpected end of hex escape", line: 24, column: 291)', aw-server/src/endpoints/import.rs:61:38

If someone wants to reproduce this is a minimal export file:

{
    "buckets": {
        "my-test-bucket": {
            "id": "my-test-bucket",
            "hostname": "johan-desktop",
            "client": "test-client",
            "created": "2020-01-28T12:43:29.137000+00:00",
            "type": "test",
            "events": [
                {
                    "timestamp": "2020-01-28T12:43:14.141000+00:00",
                    "duration": 4.993,
                    "data": {
                        "url": "https://virtualself.co/",
                        "title": "\ud835\udc47\ud835\ude29\ud835\udc56\ud835\udc60 \ud835\udc64\ud835\udc56\ud835\udc59\ud835\udc59 \ud835\udc4f\ud835\udc52\ud835\udc50\ud835\udc5c\ud835\udc5a\ud835\udc52 \ud835\udc61\ud835\ude29\ud835\udc52 \ud835\udc53\ud835\udc56\ud835\udc5b\ud835\udc4e\ud835\udc59 \ud835\udc5d\ud835\udc4e\ud835\udc5f\ud835\udc61\ud835\udc56\ud835\udc50\ud835\udc59\ud835\udc52-\ud835\udc38\ud835\udc65\ud835\udc5d\ud835\udc52\ud835\udc5f\ud835",
                        "audible": true,
                        "incognito": false,
                        "tabCount": 57
                    }
                }
            ]
        }
    }
}

Blinking datastore test

thread 'datastore_tests::test_bucket_create_delete' panicked at 'assertion failed: created < now', tests\datastore.rs:77:17

DELETE endpoint to delete event(s)

My suggested API:

  • Remove DELETE <bucketname>/events/<id> endpoint
  • Add POST <bucketname>/events/delete/by_ids
  • Add GET <bucketname>/events/delete/by_period?start=X&end=X

Reasons why the old delete API is bad and should be replaced completely:

  • The new "by_ids" endpoint makes it possible to remove multiple specific events in one go while the old API could only delete one event at a time.
  • The old DELETE endpoint is also broken because both /events/<id> and /events/count are in the same namespace

Things which need to be considered:

  • Vacuuming the database

Resources:

REPLACE endpoint for more reliably replacing events

So it's already possible to replace events by setting the "id" property in the /insert endpoint.

So why would you want to have a separate /replace endpoint?

  • Because /insert does not fail if the "id" does not exist, it creates a new event
  • If one out of many replaces in /insert fails we have no idea what actually happened, we need to do fetch the events after to be certain which should be unnecessary
  • Any other reasons, put a comment below and I'll add it to this list

I don't think this is a high priority task right now, might be in the future if we get a use-case which replaces a lot of events.

Resources:

Excessive logging

aw-server-rust logs every request, making for very spammy output.

Rarely failing datastore_reload in tests

test datastore_tests::test_datastore_reload ... FAILED fails maybe 1/30 - 1/50 test runs.

Failure trace:

---- datastore_tests::test_datastore_reload stdout----
thead 'datastore_tests::test_datastore_reload' panicked at 'assertion failed: `left == right`
left: `None`,
right: `Some(2020-03-06T08:31:16.342827937Z)`', at-datastore/tests/datastore.rs:423:13

Happened in my ubuntu VM when looping tests grepping for failures. Has also sometimes happened on my macOS, but I only saw it when I was adding the KV store so I thought it was related to some other failing tests back then.

Consider using experimental feature NoneError

Something I realized while writing tests in aw-server/tests/api.rs was that if we had the NoneError feature we could use the ? operator instead of the bazillion unwrap calls to unwrap requests etc. It would also require the tests to return Result<(), None> type, but imo it would make them faster to write and a bit more readable.

I'm not sure if other places in our codebase could benefit from NoneError, and that might be the factor which makes it clear if we want it now or maybe we should just wait until the feature is stabilized.

Any opinions @ErikBjare @johan-bjareholt ?

kcov fails to install in travis

Happens every now and then, pretty annoying.

$ if [ "$TRAVIS_OS_NAME" = "linux" ] && [ "$BUILD_ANDROID" != "true" ]; then echo "Installing coverage tools"; cargo install cargo-kcov; cargo kcov --print-install-kcov-sh | sh; fi
Installing coverage tools
    Updating crates.io index
error: binary `cargo-kcov` already exists in destination as part of `cargo-kcov v0.5.2`
Add --force to overwrite

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   124    0   124    0     0    359      0 --:--:-- --:--:-- --:--:--   360
100    15  100    15    0     0     21      0 --:--:-- --:--:-- --:--:--    86

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
The command "if [ "$TRAVIS_OS_NAME" = "linux" ] && [ "$BUILD_ANDROID" != "true" ]; then echo "Installing coverage tools"; cargo install cargo-kcov; cargo kcov --print-install-kcov-sh | sh; fi" failed and exited with 2 during .

See a travis build such as: https://travis-ci.org/ActivityWatch/aw-server-rust/jobs/577815115

image

Discuss the future of query2

In #45 me and @ErikBjare was did not completely agree on what the future of query2 should be. We should plan sometime maybe 15min to actually discuss what we want the scope of it to be so it gets as useful as possible without growing its scope more than needed.

Checklist for disabling Travis

Needed before we can turn off Travis:

  • Build for Android in GitHub Actions
  • Run integration tests
    • Apparently aw-client-rust has some built-in, and it starts the server itself.
  • Run tests with coverage and report
    • Coverage is kinda broken anyway, so not the end of the world if we delay it.

Feedback on Migration to aw-server-rust

Just made the move to aw-server-rust. Very impressed by the change. The transition went smoothly, and the queries are blazingly fast. When I used to wait maybe 30-40 seconds for a monthly review, it now takes 10 seconds. Congrats on a huge milestone for AW!

Couple of observations:

  1. My previous db size was 264MB, and its now 213MB, that's an 8% decrease in size. I checked the logs, the bucket sizes and everything seems to match. Is a decrease of this size expected? Furthermore, does aw-server-rust use sqlite by default compared to peewee for aw-server?

  2. Might be a good idea to put a notice for users to hard-refresh their page in the release notes once aw-server-rust becomes the default. Some of the buttons weren't responding for me and I was getting 404's. Only once I did a hard reset, did web-ui function correctly.

  3. Some people may not be aware that aw-server and aw-server-rust store events in different databases(I definitely wasn't), so if they use them interchangeably they will lose some events. This obviously won't happen when aw-server-rust becomes the default, but in the meanwhile, possibly consider adding a disclaimer to the release

  4. Looking at the logs, there seems to be an issue with sending events from firefox-watcher:

[2020-06-25][21:29:52][rocket::rocket][INFO] OPTIONS /api/0/buckets/aw-watcher-web-firefox/heartbeat?pulsetime=80:
[2020-06-25][21:29:52][_][INFO] Verifying origin: moz-extension://a8cf0cd0-2dad-427e-b3d0-ab9326727db2
[2020-06-25][21:29:52][_][INFO] Origin has a regex match? true
[2020-06-25][21:29:52][_][ERROR] No matching routes for OPTIONS /api/0/buckets/aw-watcher-web-firefox/heartbeat?pulsetime=80.
[2020-06-25][21:29:52][_][WARN] Responding with 404 Not Found catcher.
[2020-06-25][21:29:52][_][INFO] CORS Fairing: Turned missing route OPTIONS /api/0/buckets/aw-watcher-web-firefox/heartbeat?pulsetime=80 into an OPTIONS pre-flight request
[2020-06-25][21:29:52][_][INFO] Response succeeded.
[2020-06-25][21:29:52][rocket::rocket][INFO] POST /api/0/buckets/aw-watcher-web-firefox/heartbeat?pulsetime=80 application/json; charset=utf-8:
[2020-06-25][21:29:52][_][INFO] Verifying origin: moz-extension://a8cf0cd0-2dad-427e-b3d0-ab9326727db2
[2020-06-25][21:29:52][_][INFO] Origin has a regex match? true
[2020-06-25][21:29:52][_][INFO] Matched: POST /api/0/buckets/<bucket_id>/heartbeat?<pulsetime> (bucket_events_heartbeat)
[2020-06-25][21:29:52][_][INFO] Outcome: Success
[2020-06-25][21:29:52][_][INFO] Response succeeded.

Logs for Chrome look to be fine.
System: Fedora 32, Firefox 77.0.1(most up to date)

List of possible query2 optimizations

Processing optimizations:

  • Have the list of events sorted by timestamp, then we could binary search the events intersecting. Doing so would significantly improve performance of transforms like filter_period_intersect and the union_event_split in #179 .

Memory optimizations:

  • Wrap Vec<Event> or whole queries in an allocation arena
  • Reduce the amount of clones in our transforms (already been improved quite a bit the past few months)
  • Add proper lifetimes on variables in query2 to avoid a clone on each variable assignment and reference to it (See #119)

Something else?

Query features missing

Grammar:

  • support empty statements

Functions:

Some of these are needed to support the default query in the query explorer in the web-ui
Since "support empty statements" and "find_bucket" were fixed a few months ago the default query in the query explorer works fine

Write benchmark tests for common transforms/queries

I found this section about benchmark tests in the Rust docs and thought it might be relevant to write some for tests in aw-transforms or aw-query: https://doc.rust-lang.org/1.7.0/book/benchmark-tests.html

There's also this, which runs the benchmark tests on two commits and compares the results: https://github.com/BurntSushi/cargo-benchcmp

Would be interesting to use for comparing different releases or comparing different allocators (#144).

Have you looked at this before @johan-bjareholt?

Unable to list or fetch bucket

Trying to access the following URLs from my browser:

http://localhost:5667/api/0/buckets/
http://localhost:5667/api/0/buckets/aw-watcher-window_erb-laptop2-arch
http://localhost:5667/api/0/buckets/aw-watcher-window_erb-laptop2-arch/events

Gives me {"reason":"Resource was not found.","status":"error"} even though the bucket should exists (watcher is reporting, and bucket is listed at startup).

I also checked http://localhost:5667/api/0/info and it works fine (testing is incorrectly always set to false though).

(I've changed the development port to 5667 to not collide with aw-server testing, but otherwise I haven't changed anything.)

Add rustfmt and clippy to Travis

Currently unreliable since rust nightly doesn't always build rustfmt and clippy.

Once Rocket 0.5 is released with support for stable we should start using rust stable and add this right away.

OPTIONS route not generated for endpoints

I get this error when running aw-server-rust on Android together with aw-watcher-web on Firefox for Android:

D/aw-server-rust: Error: No matching routes for OPTIONS /api/0/buckets/aw-watcher-web-firefox/heartbeat?pulsetime=80.
D/aw-server-rust: Warning: Responding with 404 Not Found catcher.

Flask autogenerates the OPTIONS route for endpoints. I had hoped Rocket would do the same, but apparently not. Do we really implement OPTIONS routes on every endpoint? Hasn't anyone else had this issue before? (A quick search suggested no, but could be mistaken)

Flooding transform seems to be broken

I just took a glance at the flooding transform as @johan-bjareholt suggested in ActivityWatch/aw-core#73 and I find several issues.

pub fn flood(events: Vec<Event>, pulsetime: chrono::Duration) -> Vec<Event> {
let mut events_sorted = sort_by_timestamp (events);
let mut e1_iter = events_sorted.drain(..).peekable();
let mut new_events = Vec::new();
let mut drop_next = false;
while let Some(mut e1) = e1_iter.next() {
if drop_next {
drop_next = false;
continue;
}
let e2 = match e1_iter.peek() {
Some(e) => e,
None => {
new_events.push(e1.clone());
break;
}
};
let gap = e2.timestamp - e1.timestamp;
if gap < pulsetime {
if e1.data == e2.data {
let e2_end = e2.timestamp + e2.duration;
// Extend e1 to the end of e2
e1.duration = e2_end - e1.timestamp;
// Drop next event since they are merged and flooded into e1
drop_next = true;
} else {
// Extend e1 to the start of e2
e1.duration = e2.timestamp - e1.timestamp;
}
}
new_events.push(e1.clone());
}
return new_events;
}

  • gap isn't calculated correctly (calculated as the difference between event starts, should be calculated as the difference between event1 end and event2 start)
  • Calculating gap correctly will lead to some events getting a negative gap, which in turn will lead to the same bug as the one fixed in ActivityWatch/aw-core#73
  • Doesn't seem to prioritize flooding the larger event over the smaller event

No rush to fix, but the issue is there. Should be easier to rewrite now that the issues have been removed from aw-core-python.

Add explicit cloning to query2

Problem

Currently every time we reference a variable we are cloning the whole value to guarantee that the value of the variable cannot be modified in some function without re-assigning it.
If we had explicit cloning built-in to the language so cloning is only done when necessary querying would probably be insanely faster.

The python implementation seems to be inconsistent as some transforms consumes the data and others don't and the query2 language doesn't seem to clone variables so things can get very complicated. Will have to investigate further on this though.

Suggestions on how it could be solved

1. New default is to assume mutable reference

clone(data) returns cloned data
*data to specify that variable will be consumed and undefined after this. Needed to avoid unnecessary cloning
Will not work because here the same value can be in multiple variables, breaks ownership rules.

events1 = query_bucket("bucket");
events2 = filter_keyvals(events1, "key", ["val"]);
# OK, BUT this will modify events1 so it might be unclear to the user what is occuring
events3 = filter_keyvals(clone(events1), "key", ["val"]);
# OK, at this point both events1 and events2 are defined
events4 = filter_keyvals(*events1, "key", ["val"]);
# OK, at this point events1 is undefined as it was consumed by *events1

2. New default is to assume immutable reference

clone(data) returns cloned data
*data to specify that variable will be consumed and undefined after this. Needed to avoid unnecessary cloning.
Will not work because here the same value can be in multiple variables, breaks ownership rules.

events1 = query_bucket("bucket");
events2 = filter_keyvals(events1, "key", ["val"]);
# Error: Not possible to pass events1 into filter_keyvals as it needs mutable data
events3 = filter_keyvals(clone(events1), "key", ["val"]);
# OK, at this point both events1 and events2 are defined
events4 = filter_keyvals(*events1, "key", ["val"]);
# OK, at this point events1 is undefined as it was consumed by *events1

3. New default is to assume consume

clone(data) returns cloned data
&data to specify that variable will be used as a reference

events1 = query_bucket("bucket");
events2 = filter_keyvals(events1, "key", ["val"]);
# OK as it is consumed by default, but after this line it will be consumed so we need to either fist clone it or query the bucket again
events1 = query_bucket("bucket");
events3 = filter_keyvals(clone(events1), "key", ["val"]);
# OK, at this point both events1 and events2 are defined
events4 = filter_keyvals(*events1, "key", ["val"]);
# OK, at this point events1 is undefined as it was consumed by *events1

4. Keep as is, but introduce some pre-processing step which does reference counting before executing

Since we don't have any loops or non-transform function support this would be possible to do, but still a bit messy to get working. The result might not be perfect either.

Swagger/OpenAPI support

I saw you mentioned in 037d875 that Swagger support won't be reimplemented, but Swagger support is actually trivial to reimplement. It's as easy as copying the API spec generated by aw-server and bundling it along with the Swagger UI files (I think).

Just a remark, not saying it's a priority or anything.

Build failure: `error[E0554]: '#![feature]' may not be used on the stable release channel`

Trying to build on Archlinux I get the following errors with make aw-server:

❯ make aw-server
cargo build --release --bin aw-server
   Compiling devise_core v0.2.0
   Compiling pear_codegen v0.1.2
   Compiling plex v0.2.5
   Compiling serde v1.0.104
   Compiling mime_guess v1.8.8
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/user/.local/cargo/registry/src/github.com-1ecc6299db9ec823/pear_codegen-0.1.2/src/lib.rs:1:1
  |
1 | #![feature(crate_visibility_modifier)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/user/.local/cargo/registry/src/github.com-1ecc6299db9ec823/pear_codegen-0.1.2/src/lib.rs:2:1
  |
2 | #![feature(proc_macro_diagnostic, proc_macro_span)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Blinking test_datastore_reload

This has happened to me a couple of times now, only in macOS builds (that I can remember): https://travis-ci.org/github/ActivityWatch/activitywatch/jobs/665409298

---- datastore_tests::test_datastore_reload stdout ----

thread 'datastore_tests::test_datastore_reload' panicked at 'assertion failed: `(left == right)`

  left: `None`,

 right: `Some(2020-03-22T07:35:27.975762Z)`', aw-datastore/tests/datastore.rs:423:13

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've been getting it with GitHub Actions as well, so not Travis-specific.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.