73 Matching Annotations
  1. Jan 2020
    1. Providers can be nested to override values deeper within the tree.

      inheritance vs composition. inheritance model requires overriding. composition model means you shouldn't have to override, but be orthogonal in your design that you can reach out to

    2. Context provides a way to share values like these between components without having to explicitly pass a prop through every level of the tree.

      prop analogue of state, for sticking data laterally prop:context::state:hook

    1. However, instead we recommend to split state into multiple state variables based on which values tend to change together.

      since the data is supposed to be this granular at the component level anyway, that the need to store it in a manner that requires manual merges, shouldn't arise.

    2. Note how we have to merge these fields into the previous state object manually:

      it is a manual merge. merge importantly.

    1. Multiple State Variables

      isn't state then behaving as an open union here?

    2. at the top level

      iow, in the namespace immediately inside the component. not in namespaces inside other such immediate namespaces.

    3. Effects

      What are effects? side effects in this react world. First of all, it is not something that's called in by the react runtime at some lifecycle points. It's not something that we call in other arbitrary places. We tell these things to the react runtime and it is responsible for scheduling those methods to run as a function of lifecycle methods.

    4. clean up

      looks like this clean up is bidirectional it is executed both before a subsequent remount, and after an unmount.

      in the purefunctional paradigm, this should be a rather defensive act only, and unnecessary, because it should be guaranteed, that there are no untracked state mutating side-effects being called, anywhere in the program, so if the clean up has been called once at the unmount, a subsequent remount shouldn't require cleanup. because we are in functional land.

      it's like called at every unmount. but also called before every subsequent re render. but this is memoizable.

    5. ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange)

      isn't this problematic here. chat api is a third party thing. we only know what api to call, and what information to provide. now, chatapi can be called by multiple components.

    6. stateful logic

      does it mean that a logic, iow, a method, depends on some state-type. stateful logic is state dependent logic, maybe its argument is a state.

    7. null

      use Option

    8. returning a function

      who will execute this function when? will react run this function after flushing the changes to the dom? there must be some wisdom to the choice of not calling the cleanup methods inside the effect itself. is the effect not fit enough to do the cleanup inside itself

      or is it just that the api designers have provisioned this api to promote its straight forward use, without performing much acrobatics inside. otherwise i'd have to pass information along insides, when is the functioned deemed complete so that i know that i have to run the cleanup method. eg, what if we just write a zio bracket as the effect. it will do the cleanup inside itself.

      isn't it obviously easier to just return a cleanup function that we know will be called after every call has returned in the current effect. maybe cheaper than propagating information about the finishment of the effect.

      i think it's more to do with behavioural.

    9. can’t be done during rendering

      effects can't be done during renderings.

    10. reuse stateful behavior

      what is a reusable stateful behaviour precious?

    11. you do it in the same order during every render


    12. initial state argument

      what happens to that argument, once we reset the state? is it GC'd??

    13. stateful logic

      What's the definition of stateful logic?

    1. The default behavior is to enter the new key/data pair, replacing any previously existing key if duplicates are disallowed, or adding a duplicate data item if duplicates are allowed (MDB_DUPSORT).
    1. Handles should only be closed by a single thread, and only if no other threads are going to reference the database handle or one of its cursors any further. Do not close a handle if an existing transaction has modified its database. Doing so can cause misbehavior from database corruption to errors like MDB_BAD_VALSIZE (since the DB name is gone).
    2. This flag must not be specified if the database was opened with MDB_DUPSORT.


    3. transaction ends

      which if it does, if the transaction does end, all those reservations might be just simply dropped.

    4. next update operation

      to the same key you mean?

    5. given

      where do you actually give this size?

      oh. in the data field itself.

    6. enter the new key/data pair only if it does not already appear in the database.

      should be enter the new key/data pair only if the key does not already appear in the database.

    7. Don't flush system buffers to disk when committing a transaction.

      commit is still in memory then. say an environment is double the size of ram. i open it with mdb_nosync flag.

      attn: the os can flush dirty buffers into disk, still.

    8. Do not mix processes with and without MDB_WRITEMAP on the same environment
    9. This function must not be called from multiple concurrent transactions in the same process.
    10. parent

      there's nothing like a child transaction. there's always parent transaction. isn't it like reverse order thinking? i have created a transaction, and to put it in line with another transaction, i'll have to think, what would come before it. but no, this has no bearing on the order we conjure for a nesting of transactions.

    11. The transaction handle is freed

      dead now.

    12. allocates

      it's just an allocation of memory, eugene. you might as well imagine that nothing is being written in it. that is the task of mdb_env_open(..), to write essential data in this allocated memory, so that the handle, this environment handle can be used in subsequent db operation methods, like mdb_txn_begin, etc.

    13. Returns

      Unit. in scala land. mdb_env_open is a function that smells a lot of mutations. this function, just does mutations.

      probably this method writes data in MDB_env

    14. must be called

      good usecase for zio brackets

    15. Store items into a database.

      is this misleading? because it is not until, the txn here is committed, that the changes from mdb_put are propagated across the environment.

      while the description reads

      Store items into a database.

      which isn't what's happening. the write might be happening in the copy-on-write area, but the description could be more precise.

    16. and a thread may only have a single transaction at a time

      even though a single transaction in a thread, can have multiple transactions nested within it, via the parent txn argument.

    1. circuit notifies

      given it notifies, only at the end of a successful action handling, this is transactionality as well playing out here. when all the registered views will be notified only after all the changes have been applied, doesn't matter all nodes modified or just one, they'll see only quantum state jumps.

    2. (model, action) => model

      does this imply transactionality as well? it's the responsibility of the function to return to us with a handle to the new model. looks transactional because whatever the function does, is hidden from us. when we will always be exposed only complete and consistent state handles, no matter how many keys differ in both, maybe it is a totally complete rewrite, or maybe it was just one node change, but it appears as a single state jump. hence, it's fair to say that this is transactional.

      and obviously, since actions are executed synchronously, one after the other, the next action, will see the state which was just left behind by successful handling of the last action. and this is transactional as well. that the next observer sees only quantum state jumps, no matter how many nodes are modified. could be complete rewrite, could be just one node changed, but whatever the next observer will see, it will have a cent % of the changes applied.

    3. exact same

      you could also provide a restructured app, with the same information. you serialized an old model and you deserialize a new model. it's possible.

    1. Avoid aborting a process with an active transaction

      could brackets help here if we always make sure to abort all the active transactions?

    1. tied

      ?? what does it mean to 'tie' ...

    2. a single transaction can open multiple databases

      What can it mean to have a single transaction open multiple databases?

    3. Transactions may be read-write or read-only, and read-write transactions may be nested.

      If the environment itself is open in readonly mode, can a transaction be created within that env in read-write mode?

    4. Transactions are always required, even for read-only access.

      Why does reading data has to conform to semantics of a transaction?

    1. readers run with no locks

      What does this mean?

    2. writers cannot block readers, and readers don't block writers

      but writers block other writers. is it?

    3. higher

      higher compared to what? can we write to the db-file in read-only mode?

    4. The memory map can be used as a read-only or read-write map.

      So can the same memory map be opened in read-write mode in processA and in read-only mode in processB?

    5. Writes are fully serialized; only one write transaction may be active at a time

      But what if two write attempts intend to modify entirely different areas of the mmap? Can't the writes then be done parallelly/concurrently?




    1. zipWith

      it's documentation reads something interesting

      Sequentially zips this effect with the specified effect using the specified combiner function.

      meaning what?

      Let's pay attention to types. The current zio instance, already has it's REA types. If we look at the signature of zipWith, it is,

      final def zipWith[R1 <: R, E1 >: E, B, C](that: => ZIO[R1, E1, B])(f: (A, B) => C): ZIO[R1, E1, C]

      this signature uses the REA types, so any such zipWith invocation would be aware of its REA types. based on that, we encode some requirement on the types of the parameter to this method, ie, the that and f argument to this method, in the type bounds that we express in the [ ] next to zipWith.

      we don't normally observe this, but the new R1E1BC types, are also parameters to this function, taken from the types of that and f.

      whatever R1E1BC type is, it must fulfil the [ ] encoded constraint, which is

      [R1 <: R, E1 >: E, B, C]

      there are no bounds on B and C, they can be any arbitrary type. basically the f: (A, B) => C

    2. n

      whenever we, in the runtime of a program running sometime later, kick this method off, since it is recursive, this represents a good model of an actually executing repetition, it's like a wheel that will turn some numbers of time, depending on its argument, n, and give us back a description of a program that would give us, unexceptionally, a long value, upon running.

    3. UIO[Long]

      Instead of just a naked Long, what we will get back, is a structure with some additional abstractions laid in front of some reference(s) of type Long.

    4. fib

      if fib was not a UIO, but a primitive type - a naked Long, then at this point, at the execution of fib, we already have a computation going along and following its way down into the tree to be executed, being built in the runtime, as this fib is triggered.

      when the RT is UIO[Long], we have a containment around it and it's these containers that we are connecting, and rewiring things inside, as we go along, because the given instructions are about building just the descriptions, of the program, that would be executed later, and not about executing the program itself.

      we are interested in kicking off the execution of the program, until the end, and first, we are interested in wiring things to our heart's content.

      so these descriptions to rewire inner components, return much more instantaneously, because it is just rewiring, and not execution.

    5. :

      imagine this, like two boxes facing each other, to the left is n and to the right is correspondingly returned effect. we can also imagine the static type of UIO[Long] across all these instances, along with imagining what inside the box, what, in the instance, would be different from each other.

    6. some operation

      some operation perhaps of a client library that i'm using

    1. Databases must always be opened with the same flags once created.

      Can a case not arise where a dbi needs to be re-opened with different DbiFlags?

      What if an Dbi is reopened with different flags nevertheless? Will the api throw?

    2. but only ever one write transaction

      Is one scoped to one lmdb environment?

    3. there must not be two concurrent transactions opening the same database
    4. Transactions can be nested

      so does this means that, if one transaction has many transactions under it, nested like a linked list, the completion of the topmost level transaction can happen only when all the nested transactions have committed.

    5. A transaction always applies to the whole environment (representing the database file), and never to individual named databases.

      so a transaction can span multiple databases, ie, provide us transactionality guarantees across multiple named databases inside an lmdb environment.

    6. mdb_dbi_open(transaction, "databasename", MDB_DUPSORT | MDB_CREATE, &dbi)

      MDB_DUPSORT | MDB_CREATE<br> ↑ bitwise OR'ing different flags together in the C api

    7. There should only ever be one environment open per database-file per process.

      So can't a process open multiple lmdb-files? (iow, lmdb-environment) ?

      It's understandable that there is no need to open the same env-file more than once per process.

    8. Do not use LMDB datbases on remote filesystems.


    1. Creating a GraphQL API with Caliban is as simple as creating a case class

      is this capable of exposing an entire api to a service, via just a giant case class?

    1. it's good practice to annotate your stashes with a description

      but not needed if the branchname identifies the feature/work itself and there is only one stash per branch

    2. By default, stashes are identified simply as a "WIP" – work in progress – on top of the branch and commit that you created the stash from

      if i see branchname in stash list, i know the it is the wip on that branch

    1. Programmatic Structural Types

      How does this name, encode the semantics? How is this name, self-explanatory?

    2. resolved

      is this something like resolvers in graphql?

      is this basically, inserting an indirection in between selecting a field and having it resolved? because previously, selecting a field meant you just get back what it points to. now, would selecting a field mean, executing some logic, and then arrive at what to return?

  2. Dec 2019
    1. React does not guarantee that the state changes are applied immediately.

      React does not guarantee that the requested state changes are applied immediately.

  3. May 2019
    1. server-side repositories

      that means the server will run those computations, eg github?

    2. detached HEAD

      When HEAD contains a commit hash instead of a symbolic ref.

    1. git pull is the more aggressive alternative, it will download the remote content for the active local branch and immediately execute git merge to create a merge commit for the new remote content.

      On design of this statement: it breaks some atomicity principle for constructing statements. For someone making a highlight, that statement is not atomic. It includes is the more aggressive alternative, it which is not relevant to the highlight's intent.

      Alt1: git pull will download the remote content for the active .... for the new remote content. From a minimalist's perspective, it is void of extraneous qualifications that are subjective, ie, the more aggressive alternative.

  4. Nov 2018
    1. it should always return this value

      Sounds like the program should always return itself. Is this grammatically ambiguous?

    1. asynchronous boundary

      What could an asynchronous boundary be?