profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/tgoyne/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

tgoyne/aegisub 19

Personal development tree for Aegisub

mongodb/docs-realm 17

MongoDB Realm & Realm Database documentation

tgoyne/fontconfig 8

fontconfig with msvc compilation support and a few Windows fixes

tgoyne/google-code-issues-migrator 6

A simple script to migrate issues from google code to github.

tgoyne/luasynth 6

LuaJIT bindings for VapourSynth

tgoyne/aegisub-scripting-stuff 3

Experimental stuff for a future Aegisub scripting API

tgoyne/libass 3

libass with msvc compilation support. No longer updated due to that upstream can now be built unpatched.

tgoyne/ffms-py 1

Python bindings for ffms2

tgoyne/verbum 1

Language learning app written in Switft w/ Realm.io

tgoyne/ABFRealmSearchViewController 0

Drop-in text search interface for an RLMObject subclass.

issue commentrealm/realm-core

Realm core crash

Is the stack trace for the crash identical, or has it switched to crashing in a different spot?

duncangroenewald

comment created time in a day

issue commentrealm/realm-core

Realm core crash

Just the RealmCore library. The other libraries are separate targets specifically because we don't use them in the Swift SDK.

duncangroenewald

comment created time in a day

issue commentrealm/realm-core

Realm core crash

Please try pointing SPM at the tg/callback-lock branch for realm-core and retesting the steps that hit the crash. You can do this by explicitly adding realm-core as a dependency in your app and selecting that branch, and it'll override the version specified by realm-cocoa's package. This branch (probably?) doesn't fix the bug, but I think it might make it impossible to hit without using the not-yet-released keypath filtering feature.

duncangroenewald

comment created time in a day

create barnchrealm/realm-core

branch : tg/callback-lock

created branch time in a day

issue commentrealm/realm-core

Realm core crash

As long as it's cleaned up at some point it's not necessarily important that you invalidate the NotifierToken for a deleted object immediately. Not doing so will waste a small amount of memory but not slow things down. Invalidating it in response to the object being deleted shouldn't be causing any problems, though.

duncangroenewald

comment created time in 2 days

issue commentrealm/realm-core

Realm core crash

Debug+SPM is the only configuration where you'll actually have a debug build of realm-core, as the other installation methods always use a release build of it. Debug builds of core are significantly slower than release builds, so if a bug requires a specific timing to hit (which is quite likely here as there's multiple threads interacting in complicated ways) you'll often only hit it in either debug or release builds.

duncangroenewald

comment created time in 2 days

issue commentrealm/realm-cocoa

Concurrently accessing child relation (LinkingObjects.first) inconsistently causes crash (EXC_BAD_ACCESS)

This is probably fixed in v10.11.0. In v10.7.5, swiftGenericProperties was lazily populated in a thread-unsafe manner even though RLMObjectSchema instances are shared between threads. This almost never caused problems because it required that the very first thing you do with Realm after app startup be concurrent, and even then the timing window for it to break was very narrow. As of v10.10.0 the array is now constructed eagerly as part of initializing the RLMObjectSchema, both because the lazy construction was thread-unsafe and because it wasn't actually a useful optimization.

floorish

comment created time in 2 days

issue commentrealm/realm-core

Realm core crash

The crash is inside ObjectNotifier::do_add_required_change_info(), so this is related to an individual Object being observed rather than a collection. The stack trace indicates that the notifier has run at least once previously, and some time after that first run a callback was added or removed. A quirk of how object notifications are exposed in Swift means that we never actually add more callbacks to existing notifiers (and instead create multiple notifiers rather than reusing one as we do for collections), so that should mean that the callback was removed due to the NotificationToken being destroyed.

As you say that this happens when objects are deleted, are you perhaps observing objects and then removing the observation when you get a delete notification for that object?

Simply by reading through the code I don't see how we'd get to this point with m_table being null and m_table_key being non-null. If the object was deleted we set both to null, and otherwise the only place m_table could be set to null is if the Table for m_table_key doesn't exist in do_attach_to(), which also should only happen if m_table_key is null.

duncangroenewald

comment created time in 2 days

issue commentrealm/realm-cocoa

Slow notification when adding object to synced Realm (MongoDB Realm SDK V10.x)

The release is currently building and will be out today. Turns out it'll actually be 10.11.0 though as another PR landed that added features.

In general notifications for adding an object to a collection should be sent nearly instantly and should not be taking 2 - 5 seconds.

For the simplest case where you're observing a single List and nothing else, your schema is acyclic, and you perform a write which does nothing but create a new object and add it to the List, it is reasonable to expect a change notification from that in the ballpark of 10ms on a relatively recent iPhone. If your collection is a sorted Results with a hundred thousand objects, then we have to recalculate the sort after modifications, and that obviously takes longer. If you modify any of the objects of the type which a List contains then we check if any of the objects in the List were modified, and this can sometimes take an unreasonably long amount of time (and it is this checking which 10.11.0 will have some improvements for).

Multiple second delays is not the expected behavior and probably means that either you're (possibly unintentionally) observing a very large number of collections or are hitting some code which needs to be better optimized.

(Or it means that you're using a debug build while installing via SPM, which builds the whole library without compiler optimizations and so can be dramatically slower than release builds).

Is there any difference in behaviour for synced or non-synced realms ?

There should not be. Write transactions on synchronized Realms are sometimes slower than on non-synchronized Realms, but nothing that happens between commitWrite() returning and a notification being delivered differs in any way between them.

duncangroenewald

comment created time in 2 days

push eventrealm/realm-core

Thomas Goyne

commit sha f7ee79e424744676b07cda14db4a0c16481da8eb

Report if Realm::delete_files() actually deleted the Realm file Our objective-c API for removing files returns true if the Realm file was deleted, and sets an error out parameter if any errors occurred. This means that even if an exception is thrown when trying to delete one of the auxiliary files we still need to know if the main file was deleted, and that awkwardly requires an out parameter. This also refactors things to eliminate the unordered_map of auxiliary files because none of the things using it actually needed a map, and consolidates the two places where we deleted all the files into one.

view details

push time in 3 days

push eventrealm/realm-cocoa

Thomas Goyne

commit sha cd180c437be5cab764ec8aa36b5c86ab9fb37ce6

Release v10.11.0

view details

Thomas Goyne

commit sha cef59658a3e447bf6994e20af6ec408633963d52

Temporarily remove Xcode 13 from the release pipeline as beta 3 is broken

view details

push time in 3 days

push eventrealm/realm-core

Thomas Goyne

commit sha f307555ab5f49dfaf38733a0fa0b729f5f42d298

Test logger formatting in debug builds regardless of log level

view details

Thomas Goyne

commit sha faf9cb15afd2ffad9250def88f92de8af287d619

Add some more string formatting tests

view details

James Stone

commit sha fc8d687d3fb36ba25edaafcb66488c62628dcf80

test improvements (#4764) * remove old hard coded baas configurations * isolate test data by assigning a unique collection name per app * update more hard coded test db names * remove unused parameter

view details

James Stone

commit sha 56570dd90bed1d0cb0fd1cf350c1fa1d7b59355b

Do not try to auto refresh a token on a revoked user (#4747) * do not try to auto refresh a token on a revoked user * more robust testing for disable and revoke user * refactoring some tests to clean up duplicated code

view details

Thomas Goyne

commit sha 1e90daede6a3395d3a0ce9ce3fea9cbad4db2999

Merge pull request #4758 from realm/tg/to-string-tests Add some more string formatting tests

view details

Dominic Frei

commit sha 844fb7be33e217a851dd51432b136a77a1b2ce56

Check if the path exists before trying to delete Realm files. (#4765)

view details

Finn Schiermer Andersen

commit sha b2d96fba0624fcbd85800f816ea4d8e80727ac67

fix for delete/open race (#4768)

view details

James Stone

commit sha 4cec443f1a6a6d9b8f081737a6e78d77a96b30e9

fix notifications on list of primitive mixed (#4770) * fix notifications on list of primitive mixed * fix handling of unresolved links in dict/set when checking deep changes * fix table cache, optimize and reuse more code

view details

James Stone

commit sha 4f487dde53014f524d682928da77167c7ed17059

Merge branch 'master' into js/update-from-base

view details

Jørgen Edelbo

commit sha 7b69a0f751815b1163524cb58ee928381eef2c10

Remove backlinks when clearing list or set of Mixed containing links

view details

James Stone

commit sha aa3251b993144a4014a36f8ed2a3e5742a0ab97c

Merge pull request #4780 from realm/js/update-from-base Update from base

view details

James Stone

commit sha 75aceec6f620fdbcc4b8a87e525e92e0f80c20a5

Merge branch 'v11' into je/fix-mixed-clear

view details

Jonathan Reams

commit sha 3f1f90c07b9e9b0892154206f47fa56c061196ac

RCORE-440 Track compileunits output from bloaty (#4786)

view details

Jørgen Edelbo

commit sha e5c8b290c1ca3116be091a50e55492a5ba2d6dec

Merge pull request #4785 from realm/je/fix-mixed-clear Remove backlinks when clearing list or set of Mixed containing links

view details

Diana Perez Afanador

commit sha 5ed4343e61e2c949ae03443c4bc3d450396e0ce2

Renamed targets on SPM file from `Core`, `QueryParser` to `RealmCore` and `RealmQueryParser` to avoid conflicts with other libraries products (#4772)

view details

Nikola Irinchev

commit sha 281af3184f601e7ea4fb77186a2121cabd950d40

Don't pass a shared_ptr to SyncManager to the sync client (#4789) * Don't pass a shared_ptr to SyncManager to the sync client * Static cast the correct variable * Revert the whitespace changes

view details

Jørgen Edelbo

commit sha 46a0c0ae70ce55f1cc346131203362a97e08765f

Collision handling in Dictionary (#4784) When a collision is detected, the new entry is created with a random key value with the upper most bit set. This prevents it from colliding with future hashes. These sibling entries are linked from the 'master' entry by a list in a third column in the Dictionary. When a master entry is deleted, the last sibling is copied over and becomes the new master. When a sibling is deleted, it is just removed from the list in the master. Co-authored-by: James Stone <james.stone@mongodb.com> Co-authored-by: Finn Schiermer Andersen <finn.schiermer.andersen@gmail.com>

view details

Jørgen Edelbo

commit sha 0116a73a2272e40bbb5a8a78ef559b573ca3531f

Add test and fix (#4790)

view details

Jørgen Edelbo

commit sha 44304ce6104c4a9fc7e2359990c75be3b867b8fe

Merge branch 'master' into je/merge-master

view details

Jørgen Edelbo

commit sha d75802e3bb045789f7eac6ad87f3adbe9dc59a36

Prepare release

view details

push time in 3 days

issue commentrealm/realm-cocoa

Slow notification when adding object to synced Realm (MongoDB Realm SDK V10.x)

If 10.10.1 doesn't help with your specific case, then some sort of sample app which hits problems would be very useful. There's a lot of room for further optimizations in the notifier code, but where the hot spots are varies quite a bit depending on what your schema and object graph look like so it's easy to speed a bunch of artificial benchmarks up without actually fixing the problem that a specific app is running in to.

duncangroenewald

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrealm/realm-cocoa

Key Path Filtering for Change Notifications

 class RLMObservationTracker { std::vector<realm::BindingContext::ObserverState> RLMGetObservedRows(RLMSchemaInfo const& schema); void RLMWillChange(std::vector<realm::BindingContext::ObserverState> const& observed, std::vector<void *> const& invalidated); void RLMDidChange(std::vector<realm::BindingContext::ObserverState> const& observed, std::vector<void *> const& invalidated);++// ???: Will not using RLM conflict with other libraries?+realm::KeyPath KeyPathFromString(RLMRealm *realm,

Everything except for static functions and functions defined inside an anonymous namespace should have the RLM prefix.

ericjordanmossman

comment created time in 4 days

PullRequestReviewEvent

pull request commentrealm/realm-cocoa

Update core to v11.1.1

Xcode 13 beta 3 has a broken Combine.framework for iOS, which is responsible for all of the failures except for swiftpm-thread. The swiftpm-thread failure is probably just a networking hiccup.

ericjordanmossman

comment created time in 4 days

Pull request review commentrealm/realm-cocoa

Update core to v11.1.1

 x.y.z Release notes (yyyy-MM-dd)   This allows you to select elements in a collection with a given IndexSet (Cocoa [#7298](https://github.com/realm/realm-cocoa/issues/7298). * Add `App.emailPasswordAuth.retryCustomConfirmation(email:completion:)` and `[App.emailPasswordAuth retryCustomConfirmation:completion:]`.    These functions support retrying a [custom confirmation](https://docs.mongodb.com/realm/authentication/email-password/#run-a-confirmation-function) function.+* Improve performance of creating collection notifiers for Realms with a complex schema. +  This means that the first run of a synchronous query, first call to observe() on a collection, +  or any call to find_async() will do significantly less work on the calling thread.+* Improve performance of calculating changesets for notifications, particularly +  for deeply nested object graphs and objects which have List or Set properties +  with small numbers of objects in the collection.  ### Fixed * `RealmProperty<T?>` would crash when decoding a `null` json value.   ([Cocoa #7323](https://github.com/realm/realm-cocoa/issues/7323), since v10.8.0) * `@Persisted<T?>` would crash when decoding a `null` value.   ([#7332](https://github.com/realm/realm-cocoa/issues/7332), since v10.10.0).+* User profile now correctly persists between runs.

This should probably mention that it's the profile for sync users.

ericjordanmossman

comment created time in 4 days

Pull request review commentrealm/realm-cocoa

Update core to v11.1.1

 x.y.z Release notes (yyyy-MM-dd)   This allows you to select elements in a collection with a given IndexSet (Cocoa [#7298](https://github.com/realm/realm-cocoa/issues/7298). * Add `App.emailPasswordAuth.retryCustomConfirmation(email:completion:)` and `[App.emailPasswordAuth retryCustomConfirmation:completion:]`.    These functions support retrying a [custom confirmation](https://docs.mongodb.com/realm/authentication/email-password/#run-a-confirmation-function) function.+* Improve performance of creating collection notifiers for Realms with a complex schema. +  This means that the first run of a synchronous query, first call to observe() on a collection, +  or any call to find_async() will do significantly less work on the calling thread.

The wording on this needs to be adjusted a little. find_async() isn't something we have in Cocoa and we don't distinguish between sync and async queries like Java does, so it should be something like "the first run of a query or first call to observe() on a collection will do significant less work".

ericjordanmossman

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

PR merged realm/realm-core

Fix the sync metadata Realm schema

https://github.com/realm/realm-core/pull/4244 changed the schema without bumping the schema version, which breaks opening any existing sync metadata Realms. It also left a bunch of pointless unused things in the schema that should be removed.

+70 -37

1 comment

7 changed files

tgoyne

pr closed time in 4 days

push eventrealm/realm-core

Thomas Goyne

commit sha 17b48a27665e5cfeea4d3b400837cd9898a6669a

Fix the sync metadata Realm schema https://github.com/realm/realm-core/pull/4244 changed the schema without bumping the schema version, which breaks opening any existing sync metadata Realms. It also left a bunch of pointless unused things in the schema that should be removed.

view details

Thomas Goyne

commit sha 94bcb9a23c68c60ff8fc2daa14bfdf91321757c2

Add a test which verifies we can use old metadata realms

view details

Thomas Goyne

commit sha f0647b0a7388d8846db56db3b2fe77fdafddd7e7

Merge pull request #4820 from realm/tg/sync-metadata-realm-schema Fix the sync metadata Realm schema

view details

push time in 4 days

delete branch realm/realm-core

delete branch : tg/sync-metadata-realm-schema

delete time in 4 days

pull request commentrealm/realm-core

Fix the sync metadata Realm schema

I've added a test which verifies that we can open metadata realms from 11.0 and will also hopefully catch similar problems in the future.

tgoyne

comment created time in 4 days

push eventrealm/realm-core

Thomas Goyne

commit sha 94bcb9a23c68c60ff8fc2daa14bfdf91321757c2

Add a test which verifies we can use old metadata realms

view details

push time in 4 days

push eventrealm/realm-core

Thomas Goyne

commit sha 0988e90f670d678bd8b59181bf02970349a05a95

Add more notifier benchmarks

view details

Thomas Goyne

commit sha bd448a6964d33ef14a7d5ea8331db7d84faaa1ab

Eliminate some quadratic runtime in DeepChangeChecker::find_related_tables()

view details

Thomas Goyne

commit sha c92e86e8ccec597a6259a4c4e800d611a8757606

Move the check for the maximum search depth to a better spot When we reached the maximum search depth we proceeded to retrieve the linked object for every outgoing link and then do nothing with it, which is pointlessly slow. Instead check if we're at the maximum depth before processing the columns.

view details

Thomas Goyne

commit sha 8981b895c91c7706dd4ee4d744e3481311c989be

Eliminate some double-checking of Table validity _get_alloc()'s comment correctly notes that _get() is a place where it's safe to call as we check the Table before calling _get(), but _get() didn't actually use it.

view details

Thomas Goyne

commit sha 97a5660a140d519fd526ef250d0029e832840598

Improve performance of deep modification checking over collections Creating the accessor object for collections is fairly expensive and involves a bunch of memory allocations. For empty collections this is >99% of the runtime of change checking, and it remains significant even for fairly sizeable collections.

view details

Thomas Goyne

commit sha d6ff428f2082e2b7d7c837293b656e66a584e289

Merge pull request #4816 from realm/tg/notifier-optimizations Improve performance of some notifier things

view details

push time in 4 days

delete branch realm/realm-core

delete branch : tg/notifier-optimizations

delete time in 4 days

PR merged realm/realm-core

Improve performance of some notifier things

Prompted by a report of a performance regression in notifier performance in v11, I wrote a few new benchmarks and optimized some stuff. I haven't yet reproduced the regression the user reported, but I did find a regression in notifier creation perf (which is moderately important as it happens on the main thread) and found some room to optimize things which might be similar to what the user was hitting.

It may be easiest to review this by looking at the commits individually as they're each doing fairly distinct things.

Test v10.8.1 master This PR
Create notifier 409 us 12.5 ms 333 us
Chained object links (depth 0) 25 us 22 us 24 us
Chained object links (depth 1) 314 ms 337 ms 10 ms
Chained object links (depth 2) 10 ms 11 ms 380 us
Chained object links (depth 3) 375 us 400 us 25 us
Chained object lists (depth 0) 24 us 22 us 23 us
Chained object lists (depth 1) 2.4 s 3.5 s 30 ms
Chained object lists (depth 2) 80 ms 116 ms 1 ms
Chained object lists (depth 3) 2.74 ms 3.9 ms 64 us

The 100x speedup there is not particularly representative of anything realistic, but it should provide a meaningful speedup even without 99 empty lists in each object.

+352 -151

0 comment

11 changed files

tgoyne

pr closed time in 4 days

push eventrealm/realm-core

Thomas Goyne

commit sha 91531ff91386e0325e82481b1990295d06aab915

Add a test which verifies we can use old metadata realms

view details

push time in 4 days