profile
viewpoint
Marius Bergmann mbrgm mtbit Erlangen, Germany

push eventfacebookexperimental/eden

Kostia Balytskyi

commit sha 329adafbdba5596b5c3b04cb0eefdd3dea575588

blobstore_healer: avoid unnecessary blob clones Summary: Currently, the healer would clone a blob at least once if it needs to be healed. This is done because `blobstore.put` needs to take ownership of the `blob`. It is pretty wasteful in several different ways: - if there's just one `put` needed, we can just use the existing `blob` instance and avoid cloning it - we clone `blob` for every `stores_to_heal` at the same time, therefore consuming `stores_to_heal.len() * blob.len()` bytes of RAM. On the plus side, this allows us to run those `put`s in parallel, but on the flip side - it uses a lot of RAM. In cases when we need to heal a 4Gb blob to two different blobstores, this would immediately jump memory usage from 4Gb to 12Gb. Taking into account that we use 15Gb containers and heal 100 blobs in parallel, this is pretty bad. One way of dealing with this is doing `put`s one-by-one, cloning for each (except the last one). As each `put` succeeds, we drop the original cloned `blob`, therefore freeing some memory. Formulaically this means that our peak usage per blob is `blob.len() * 2` if there's >1 heal needed and just `blob.len()` if there's 1 heal needed. So let's support two different strategies of healing: `Sequential` and `Concurrent`. We can choose `Concurrent` when we know that there's plenty of RAM to clone our blob enough times. To know what "plenty of RAM" is, let monitor our RSS and allow passing a "ceiling" on the command line (newly added `--max-rss-bytes` arg). Note 1: Of course, this all is just best effort: there are obvious TOCTTOU problems with RSS checks, so false positives are possible. Note 2: A much better approach here would be to have `.put` not take ownership of the blob in the first place, and to only clone from a passed reference when needed (I think it's actually not always needed, like `sqlblob` takes ownership, and then creates chunks by cloning it one more time, IIUC). Unfortunately, this is a much larger change with a lot of complexities, so I'd rather not do it here. Reviewed By: krallin Differential Revision: D25196372 fbshipit-source-id: 1128c13f68f2dc877cebcf45d8d96954543daf3c

view details

push time in a day

issue commentEmilTholin/svelte-routing

Add the ability to specify class for Link

@mefechoel thanks for the clarification, I'll use:link then!

Bigaston

comment created time in a day

issue commentEmilTholin/svelte-routing

Add the ability to specify class for Link

@timohausmann Having a class attribute on the Link would unfortunatly not help with that. Svelte does not treat class props to components as special props and does not recognize them as classnames either. It would still mark them as unused. Using the link action, as described by @bskimball is the only way to get this working proberly.

Maybe a LinkContainer component would make sense for these cases with an api similar to this:

<LinkContainer to="login" let:href let:props>
  <a {href} {...props} class="my-link">Login</a>
</LinkContainer>
Bigaston

comment created time in a day

issue commentEmilTholin/svelte-routing

Add the ability to specify class for Link

I would appreciate a simple class attribute too.

getProps doesn't work inside components unless you make your CSS selector global, otherwise it will be detected as unused thus removed from the CSS bundle by default.

<style>
    :global(.logo-link) { color: red; }
</style>
<h1><Link to="/" getProps={() => ({class: "logo-link"})}>Svelte Web</Link></h1>
Bigaston

comment created time in a day

issue commentEmilTholin/svelte-routing

Theming support via classes?

Can I maybe help you out here?

kamiyaa

comment created time in a day

issue commentEmilTholin/svelte-routing

Theming support via classes?

I think that would be great. It would provide more familiarity to people coming from Vue & React. They expect non-used props to be passed to the underlying anchor.

kamiyaa

comment created time in a day

issue commentEmilTholin/svelte-routing

Create @types/svelte-routing

A list of types that should be supported:

  • Router
  • Link
  • Route
  • navigate
  • link
  • links

That's all, right @EmilTholin ?

vaclav-stummer-ooo

comment created time in a day

issue commentEmilTholin/svelte-routing

Create @types/svelte-routing

Or add it in this project, for that matter. That might be easier. The @types repo is for projects that do not provide type by themselves.

vaclav-stummer-ooo

comment created time in a day

push eventfacebookexperimental/eden

Pavel Aslanov

commit sha 6f08815dc32225dbcf8915bf2f32b605c8e3490b

convert `BlobRepo::get_bonsai_bookmark` to new type futures Summary: convert `BlobRepo::get_bonsai_bookmark` to new type futures Reviewed By: StanislavGlebik Differential Revision: D25188577 fbshipit-source-id: fb6f2b592b9e9f76736bc1af5fa5a08d12744b5f

view details

Pavel Aslanov

commit sha 4a0cb69c4eef13acc293b385b904fc6c289e235a

convert `BlobRepo::{changeset_exists_by_bonsai, get_changeset_parents_by_bonsai}` to new futures Summary: convert `BlobRepo::{changeset_exists_by_bonsai, get_changeset_parents_by_bonsai}` to new futures Reviewed By: ahornby Differential Revision: D25195811 fbshipit-source-id: 0238440aa0757af6362effe09f1771c939bda030

view details

Pavel Aslanov

commit sha ac33b17233973236252cd4772d5f96bf7fa649e1

convert globalrev related methods to new futures Summary: convert globalrev related methods to new futures Reviewed By: ahornby Differential Revision: D25196171 fbshipit-source-id: 10c31f5869b9dd803955a7755d74b31ba1d8f7c5

view details

Pavel Aslanov

commit sha ca4b5cf073be116c89b5df533a7b93c7f33410ab

convert bookmark methods to new type futures Summary: convert bookmark methods to new type futures Reviewed By: ahornby Differential Revision: D25196555 fbshipit-source-id: b41014937e1dd10ad839aca5011f199ee6007827

view details

push time in 2 days

push eventfacebookexperimental/eden

Stanislau Hlebik

commit sha 43e7e847bb708218d539f9e851dbf4bf3de6aa45

mononoke: modernize bookmarks_validator tests Summary: Let's use fbinit::compat_test, it makes the tests a bit shorter Reviewed By: ikostia Differential Revision: D25196759 fbshipit-source-id: bd8aca4b676a71158269195fd35153a0934b0cbc

view details

push time in 2 days

push eventfacebookexperimental/eden

Pavel Aslanov

commit sha 13ee62332d43bc781ab76950771380d6183b83e3

prefix old future with `Old` Summary: Prefix old futures with `Old` so it would be possible to start conversion of BlobRepo to new type futures Reviewed By: StanislavGlebik Differential Revision: D25187882 fbshipit-source-id: d66debd2981564b289d50292888f3f6bd3343e94

view details

Pavel Aslanov

commit sha beaca55a406743d49ed4c4b01d75f8b7164aab34

convert BlobRepo::get_bonsai_heads_maybe_stale to new futures Summary: convert BlobRepo::get_bonsai_heads_maybe_stale to new futures Reviewed By: StanislavGlebik Differential Revision: D25187883 fbshipit-source-id: 78b8202a1e8d101ec69740fee2a8665ccc8334c8

view details

Pavel Aslanov

commit sha 938af42e9ca18cc1e9785770e6d12c837b70bcd4

convert `BlobRepo::get_bonsai.*bookmarks` to new futures Summary: convert `BlobRepo::get_bonsai.*bookmarks` to new futures Reviewed By: StanislavGlebik Differential Revision: D25188208 fbshipit-source-id: f071d38cbc74002e7a631d4590137418b1b07a22

view details

push time in 2 days

push eventfacebookexperimental/eden

Alex Hornby

commit sha 2b703be885eb60fd949b20d02b0b1d05008cef5e

mononoke: fix flaky walker test case Summary: The expected walker validation failures can appear in any order. Sort them so the comparison is deterministic Reviewed By: StanislavGlebik Differential Revision: D25195052 fbshipit-source-id: aeded6675c85186e12d27023fb862d7c52dd764f

view details

push time in 2 days

push eventfacebookexperimental/eden

James Donald

commit sha c7fe8b849e35067dc837c30868eed26978dfc6fb

Fix merge on Windows when path contains spaces Summary: editmergeps.bat was separating a filename with spaces into args[0] and args[1] when calling editmergeps.ps1. Use proper quoting to send files with spaces as a single argument. Reviewed By: ikostia Differential Revision: D25194324 fbshipit-source-id: 065f677c9015681b310e1cfc46f52ff563a35f99

view details

push time in 2 days

push eventfacebookexperimental/eden

Lukas Piatkowski

commit sha fa1a195fd0a8fbb58e720e60c7ae385b29991ecc

mononoke/blobstore: pass CoreContext via borrowed instead of owned value Summary: Follow up after removing 'static from blobstore. Reviewed By: StanislavGlebik Differential Revision: D25182106 fbshipit-source-id: e13a7a31d71b4674425123268e655ae66127f1b7

view details

Lukas Piatkowski

commit sha a1e8abc88c2196eb5f3e0ffd01d44758759009a8

mononoke/unbundle: mark non-public all objects that are not used outside unbundle Summary: This will make it easier to choose how to migrate this code to futures 0.3 Reviewed By: ahornby Differential Revision: D25185646 fbshipit-source-id: b39f7540275115fff4e8b6f2e740d544c2c876ef

view details

push time in 2 days

push eventfacebookexperimental/eden

Thomas Orozco

commit sha 8840f92d077960f81529d11983f8ff282a2eced8

edenapi server: properly deserialize history requests Summary: While trying to repro a user report (https://fburl.com/jqvm320o), I ran into a new hg error: P151186623, i.e.: ``` KeyError: 'Key not found HgId(Key { path: RepoPathBuf("fbcode/thrift/facebook/test/py/TARGETS"), hgid: HgId("55713728544d5955703d604299d77bb1ed50c62d") })' ``` After some investigation (and adding a lot of prints), I noticed that this was trying to query the EdenAPI server for this filenode. That request should succeed, given Mononoke knows about this filenode: ``` [torozco@devbig051]~/fbcode % mononoke_exec mononoke_admin fbsource --use-mysql-client filenodes by-id fbcode/thrift/facebook/test/py/TARGETS 55713728544d5955703d604299d77bb1ed50c62d mononoke_exec: Using config stage prod (set MONONOKE_EXEC_STAGE= to override) I1126 08:10:02.089614 3697890 [main] eden/mononoke/cmdlib/src/args/mod.rs:1097] using repo "fbsource" repoid RepositoryId(2100) I1126 08:10:02.995172 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:137] Filenode: HgFileNodeId(HgNodeHash(Sha1(55713728544d5955703d604299d77bb1ed50c62d))) I1126 08:10:02.995282 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:138] -- path: FilePath(MPath("fbcode/thrift/facebook/test/py/TARGETS")) I1126 08:10:02.995341 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:139] -- p1: Some(HgFileNodeId(HgNodeHash(Sha1(ccb76adc7db0fc4a395be066fe5464873cdf57e7)))) I1126 08:10:02.995405 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:140] -- p2: None I1126 08:10:02.995449 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:141] -- copyfrom: None I1126 08:10:02.995486 3697890 [main] eden/mononoke/cmds/admin/filenodes.rs:142] -- linknode: HgChangesetId(HgNodeHash(Sha1(dfe46f7d6cd8bc9b03af8870aca521b1801126f0))) ``` Turns out, the success rate for this method is actually 0% — out of thousands of requests, not a single one succeeded :( https://fburl.com/scuba/edenapi_server/cma3c3j0 The root cause here is that the server side is not properly deserializing requests (actually finding that was a problem of its own, I filed T80406893 for this). If you manage to get it to print the errors, it says: ``` {"message":"Deserialization failed: missing field `path`","request_id":"f97e2c7c-a432-4696-9a4e-538ed0db0418"} ``` The reason for this is that the server side tries to deserialize the request as if it was a `WireHistoryRequest`, but actually it's a `HistoryRequest`, so all the fields have different names (we use numbers in `WireHistoryRequest`). This diff fixes that. I also introduced a helper method to make this a little less footgun-y and double-checked the other callsites. There is one callsite right now that looks like it might be broken (the commit one), but I couldn't find the client side interface for this (I'm guessing it's not implemented yet), so for now I left it as-is. Reviewed By: StanislavGlebik Differential Revision: D25187639 fbshipit-source-id: fa993579666dda762c0d71ccb56a646c20aee606

view details

push time in 2 days

push eventfacebookexperimental/eden

Stanislau Hlebik

commit sha f10d77ce5ddde9cb9ff63da3824cd1e39c81bf4c

mononoke: continue asyncifying main hg sync job loop Reviewed By: aslpavel Differential Revision: D25184859 fbshipit-source-id: 7cdc4a2676ee04d8832dc5fd60072cadf5474a18

view details

Stanislau Hlebik

commit sha d856af393a72e7badb9a628e2485b84f8df39804

mononoke: asyncify BundlePreparer constructor Reviewed By: aslpavel Differential Revision: D25185048 fbshipit-source-id: 251bca9e6693151e889520e0a40a8051e824d4f7

view details

Stanislau Hlebik

commit sha 966d33a84f165e2f6b44dfaf5f783380e41bd403

mononoke: asyncify prepare_single_bundle Reviewed By: aslpavel Differential Revision: D25185096 fbshipit-source-id: 4a61420cdf01ceb7e64592c515271459c27114b3

view details

Stanislau Hlebik

commit sha cebde43d3faa2160d12c6742d70ea685cd567f57

mononoke: refactoring to allow combining bundles in the sync job Summary: In the next diff I'd like to allow hg sync job to combine a few bookmark update log entries and send a single bundle for all of them. The goal is to reduce the lag between mononoke and hg servers. We've already made an attempt to implement bundle combining some time ago, hence why we have things like CombinedBookmarkUpdateLogEntry. However it was never really used in prod - back then the only way to sync a bundle from mononoke to hg servers was to replay a bundle that client has pushed to us, and combining bundles like that was tricky. Now it's different, because hg sync job has the logic to generates the bundles itself rather than re-use the bundle that client has pushed to us. This makes implementing bundle combinging easier. This diff doesn't add the actual bundle combining, but it does the refactoring that makes it easier. In particular: 1) Old logic for combining bundles was removed - it was never really used anyway. 1) prepare_bundles() function was added - this function takes a vector of BookmarkUpdateLogEntry and returns a vector of CombinedBookmarkUpdateLogEntry. The idea is to move bundle combining logic from main function to BundlePreparer class, since it has better knowledge of how to do bundle combining (in particular, it knows whether sync job re-uses existing bundle or generates it) 1) prepare_single_bundle() was changed - instead of taking bookmark name, from/to changeset id from BookmarkUpdateLogEntry, it now requires passing them explicitly. This makes adding bundle combining easier in the next diff. Reviewed By: mitrandir77 Differential Revision: D25168877 fbshipit-source-id: 2935d1795925b4bf0456b9221e2f76ce3987cbd0

view details

push time in 2 days

push eventfacebookexperimental/eden

Alex Hornby

commit sha 867c6785c47004776a5a95b2115b7b97af486cd5

mononoke: Fsnode does not need path in walker key Summary: The path is not needed to load the fsnode, only as route info for things like compression Reviewed By: mitrandir77 Differential Revision: D25184485 fbshipit-source-id: afd84dcd9dbd82c2c9018e86fb676bc57a5d009b

view details

Alex Hornby

commit sha 0b873a594f643bd06ce184298af4eb20d8d35f1d

mononoke: DeletedManifest does not need path in walker key Summary: Only the id is used when loading the manifest, not the path. Path is only needed for route information Reviewed By: mitrandir77 Differential Revision: D25185264 fbshipit-source-id: 1af453fa2716d53ea4fb18a81d59867e98ea07f6

view details

push time in 2 days

push eventfacebookexperimental/eden

Thomas Orozco

commit sha acf1453e1284785776bfb99fc832a33932372b00

mononoke: rename BlobManifest to HgBlobManifest Summary: We have `HgBlobChangeset`, `HgFileEnvelope`, `HgManifestEnvelope` ... but we also have `BlobManifest`. Let's be a little consistent. Reviewed By: markbt Differential Revision: D25122288 fbshipit-source-id: 9ae0be49986dbcc31cee9a46bd30093b07795c62

view details

push time in 3 days

push eventfacebookexperimental/eden

Alex Hornby

commit sha 49ead437dd049ae80e57c5963de045101c19c9ab

mononoke: add SkeletonManifest to walker Summary: Add them to the walker so we can scrub and inspect them Reviewed By: StanislavGlebik Differential Revision: D25124144 fbshipit-source-id: 5df1ca6e48d18d3d55f68905e93fd75fbae92adb

view details

push time in 3 days

push eventfacebookexperimental/eden

Lukas Piatkowski

commit sha 077b90de0de304d5e107fc842940052a041d1309

mononoke:hgcli: fix broken OSS build Summary: OSS build fails due to unused `res` variable, I don't know why it passes buck builds. Reviewed By: ikostia Differential Revision: D25187773 fbshipit-source-id: ee15132f5ccd279104a07bc8dc91de096566d9cf

view details

push time in 3 days

push eventfacebookexperimental/eden

Thomas Orozco

commit sha 34fbac34e19aa34e5ad187e946e4a3a7a634de42

mononoke/mercurial_types: remove unused ContentBlobInfo Summary: This contains a path, which it turns out is actually never used throughout the codebase. Remove it. Reviewed By: markbt Differential Revision: D25122292 fbshipit-source-id: eab528bfb1e3893bca4d92d62c30499cf9eead6c

view details

Thomas Orozco

commit sha c43aa44aca3ecd91a6d917ecf42f9098461aa604

mononoke/mercurial_types: use manifest::Entry instead of HgEntryId Summary: I'd like to remove the number of places that use HgEntryId, and make its usage a little more consistent. Indeed, right now, HgEntryId is used in some places to upload things where we just give it a fake entry type, and sometimes to represent an actual entry in a manifest; This isn't great. Let's remove it from here. Reviewed By: markbt Differential Revision: D25122289 fbshipit-source-id: 5075383e037e4e890af203d133f0a25118c19823

view details

Thomas Orozco

commit sha 1916f9c60be11585889edd932d6acd3870575abb

mononoke/derived_data/mercurial: prepare to remove HgEntry Summary: I'd like to get rid of HgEntry altogether, as it's not a very useful abstraction (`Entry` is better). This is one step towards this, by moving the HgEntry -> Leaf conversion close to where the `HgEntry` is created (which is where we upload filenodes). Reviewed By: markbt Differential Revision: D25122290 fbshipit-source-id: 0e3049392791153b9547091516e702fb04ad7094

view details

Thomas Orozco

commit sha 015331583d4f1b0550304f69c99cf2b055ce0908

mononoke: remove HgBlobEntry Summary: HgBlobEntry is kind of a problematic type right now: - It has no typing to indicate if it's a file or a manifest - It always has a file type, but we only sometimes care about it This results in us using `HgBlobEntry` to sometimes represent `Entry<HgManifestId, (FileType, HgFileNodeId)>`, and some other times to represent `Entry<HgManifestId, HgFileNodeId>`. This makes code a) confusing, b) harder to refactor because you might be having to change unrelated code that cares for the use case you don't care about (i.e. with or without the FileType), and c) results in us sometimes just throwing in a `FileType::Normal` because we don't care about the type, which is prone to breaking stuff. So, this diff just removes it, and replaces it with the appropriate types. Reviewed By: farnz Differential Revision: D25122291 fbshipit-source-id: e9c060c509357321a8059d95daf22399177140f1

view details

Thomas Orozco

commit sha 65c6869384d72f744f3d84638514229276972582

mononoke/blobrepo/test: use fbinit::compat_test consistently Summary: We have 4 different ways of awaiting futures in there: sometimes we create a runtime, sometimes we use async-unit, sometimes we use `fbinit::test` and sometimes we use `fbinit::compat_test`. Let's be consistent. While in there, let's also get rid of `should_panic`, since that's not a very good way of running tests. Reviewed By: HarveyHunt Differential Revision: D25186195 fbshipit-source-id: b64bb61935fb2132d2e5d8dff66fd4efdae1bf64

view details

push time in 3 days

push eventfacebookexperimental/eden

Alex Hornby

commit sha 636536bebb7ca68590ad67bdb75d35435f024d93

mononoke: add SkeletonManifestMapping to walker Summary: So we can scrub and inspect them Reviewed By: StanislavGlebik Differential Revision: D25120995 fbshipit-source-id: d150e55f0d72f584c15dbaf2bd017d19130312b2

view details

push time in 3 days

push eventfacebookexperimental/eden

Stanislau Hlebik

commit sha 569733215cc8464a7911d89a49c019205898ab04

mononoke: make SYNC_LOOP async Summary: This diff asyncifies SYNC_LOOP similar to how SYNC_ONCE was asyncified. The biggest part of SYNC_LOOP is a stream that starts with loop_over_log_entries. Previously it was a very long chain of combinators. This diff makes this chain ~2 times smaller, but unfortunately it can't make it even smaller because of the use of "buffered(...)" method. Reviewed By: ahornby Differential Revision: D25123487 fbshipit-source-id: e913bbd1369e4375b5b1d0e6ba462e463a5a44fc

view details

Stanislau Hlebik

commit sha 196dec1904f5d2c7950afaf5fdbd3187fad7d467

mononoke: asyncify sync_single_combined_entry in hg_sync job Reviewed By: ahornby Differential Revision: D25184245 fbshipit-source-id: 59985cdc3cadc7ff945db60fabbcd6c241ff3ba1

view details

Stanislau Hlebik

commit sha 9f6fb707d988e0a1f97a1b8dca370bb3e57fb3f8

mononoke: asyncify combine_entries in hg_sync job Reviewed By: ahornby Differential Revision: D25184363 fbshipit-source-id: fcc289e72b99fe524e6f92ab672bbcfba7101e9a

view details

Stanislau Hlebik

commit sha c8400473c98bc168d3e8515ffee819b74e0d8088

mononoke: asyncify locking/unlocking functions in hg_sync Reviewed By: aslpavel Differential Revision: D25184377 fbshipit-source-id: 72457cb669d00c68eee0fb2c19a866458a369bdb

view details

Stanislau Hlebik

commit sha 629cfc750dd372b94ee85cb24c220bf7a0f2e95b

mononoke: asyncify build_reporting_handler Summary: This diff asyncifies build_reporting_handler, and while there also simplifies this function a bit by ignoring cases where log_entries is empty or not specified Reviewed By: farnz Differential Revision: D25184396 fbshipit-source-id: 46b5d2f9fb5571e502bcdf5a0fe964fb62426313

view details

Stanislau Hlebik

commit sha 3492e5531bf3f1fe17c45b9afce5e6e71e03660d

mononoke: asyncify build_outcome_handler Reviewed By: aslpavel Differential Revision: D25184784 fbshipit-source-id: 66ca7fb874c7172c39ddfafd0ebde36e9c71f350

view details

Stanislau Hlebik

commit sha 3d03808d050fc9fc6ac709067f109b968e7ace9e

mononoke: asyncifying loop_over_log_entries Reviewed By: aslpavel Differential Revision: D25184814 fbshipit-source-id: 74e702e059856371fc8737bea3e755321ebe07ba

view details

push time in 3 days

push eventfacebookexperimental/eden

Thomas Orozco

commit sha e209225921068fc8857781aa34656c0427e131ec

commitcloud: read backed up heads via `backedup()` revset Summary: The write & read path use different back up state files, which means they can go out of sync. If that happens, it's a bit annoying because: - The output of `hg cloud check` is out of sync with that of `hg sl` - `hg cloud backup -r` says the commit is backedup, and `hg cloud check -r` says it isn't. This diff fixes this by just using the `backedup()` revset, which under the hood reads all state files. Reviewed By: liubov-dmitrieva Differential Revision: D25186071 fbshipit-source-id: 0ae2d43227d65a3564b2f796218b55982d5cc467

view details

push time in 3 days

push eventfacebookexperimental/eden

Stanislau Hlebik

commit sha 657d226360bac6268df52a5777ba4df05aef0800

mononoke: make try_prepare_single_bundle async Reviewed By: farnz Differential Revision: D25121835 fbshipit-source-id: 2564c404a01ad1f1772da4fef47c4a8940f80f0d

view details

Stanislau Hlebik

commit sha ed51aac36cfd397675df713d91731c3f152783ba

mononoke: make retry asynchronous Reviewed By: ikostia Differential Revision: D25122781 fbshipit-source-id: a7d69c2cdeff0c9c6abd92e486af191e8baed8d5

view details

Stanislau Hlebik

commit sha 2ca8bd5900fe2600839eae15dffa079da34bae6e

mononoke: make hg sync job SYNC_ONCE async Reviewed By: farnz Differential Revision: D25123103 fbshipit-source-id: 634287909a6be9e1b34160d63e27f14eabcdce95

view details

push time in 3 days

PR opened EmilTholin/svelte-routing

Error: Package subpath ./compiler.js is not defined by "exports" err…

…or fix

ref: https://github.com/sveltejs/svelte/issues/5665 plugin version up

+1 -1

0 comment

1 changed file

pr created time in 4 days

push eventfacebookexperimental/eden

Lukas Piatkowski

commit sha 15f0f924e66f397b0d843072c809f25d3f5c5ec5

mononoke/blobstore: use async_trait instead of BoxFuture Reviewed By: farnz Differential Revision: D25124793 fbshipit-source-id: 1ebe72d1db8043fabf9f20538f3e95c755e049e0

view details

push time in 6 days

issue openedfacebookexperimental/eden

osxfuse 4.0 issue

Hello guys, I saw your post here: https://github.com/osxfuse/osxfuse/issues/742 Just wanted to let you know that I can help you compile a previous "open source" version (3.8.3) of osxfuse for macOS 11.

Many people are having issues with this because it seems the interface was changed to encourage support without proper documentation.

created time in 6 days

push eventfacebookexperimental/eden

Thomas Orozco

commit sha 95cc0e5a30fba61ecbfdfae85fad020a17ae9c77

revisionstore: log more info when we time out Summary: Right now we just get a "deadline exceeded" error, which isn't very amenable to helping us understand why we timed out. Let's add more logging. Notably, I'd like to understnad what we've actually received at this point, if anything, and how long we waited, as I'm starting to suspect this issue doesn't have much to do with HTTP. See https://fb.workplace.com/groups/scm/permalink/3361972140519049/ for more context. Reviewed By: quark-zju Differential Revision: D25128159 fbshipit-source-id: b45d3415526fdf21aa80b7eeed98ee9206fbfd12

view details

push time in 6 days

push eventfacebookexperimental/eden

svcscm

commit sha 080712c602833b4d66074e8a07adffb238421e5a

Updating submodules Summary: GitHub commits: https://github.com/facebook/rocksdb/commit/1a5fc4f5771d6996d8ece9359788ceeaba32df98 https://github.com/facebook/watchman/commit/8ed313ff53dbad438354ff83493a6a7b01dcc9f8 https://github.com/facebookexperimental/rust-shed/commit/0186ce639371da6184eb1e82a73fadbc7f12ab05 Reviewed By: wittgenst fbshipit-source-id: 1772b81a9f6aecf2f7175385683d08cb505c1707

view details

push time in 8 days

more