DBTransaction with Pessimistic Locking & Optimistic Locking and Deadlock Detection

Specification
The DBTransaction currently does not have any locking integrated. It is only a read-committed isolation-level transaction.

On top of this, users have to know to use iterators and potentially multiple iterators to access the snapshot guarantee of leveldb, this is essential when iterating over one sublevel, and needing to access properties of another sublevel in a consistent way.
Right now users of this transaction is expected to use their own locks in order to prevent these additional phenomena:

Repeatable read
Phantom reads
Lost-updates

Most of this comes down to locking a particular key that is being used, thus blocking other "threads" from starting transactions on those keys.
Key locking is required in these circumstances:

Atomically reading multiple keys for a consistent "composite" read.
Atomically writing multiple keys for a consistent "composite" write.
Reading from a key, and then writing to a key a value that is derived from the read (like the counter problem)
Atomically creating a new key-value, such that all operations also creating the same new key value coalesce and accept that that it has been created (this requires all creators to lock on the same "new" key)

Users are therefore doing something like this:
class SomeDomain {
  async someMethod(tran?: DBtransaction) {
    if (tran == null) {
      await withF([
        lockBox.lock(key1, key2),
        db.transaction()
      ], async ([, tran]) => {
        return this.someMethod(tran);
      });
    }
    /*...*/
  }
}

Notice how if the transaction is passed in to SomeDomain.someMethod, then it doesn't bother creating its own transaction, but also doesn't bother locking key1 and key2.
The problem with this pattern is that within a complex call graph, each higher-level call has to remember, or know what locks need to be locked before calling an transactional operation of SomeDomain.someMethod. As the hierarchy of the callgraph expands, this requirement to remember the locking context grows exponentially, and will make our programs too difficult and complex to debug.
There are 2 solutions to this:

Pessimistic Concurrency Control (PCC)

uses locks
requires a deadlock detector (otherwise you may introduce deadlocks)
locks should be locked in the same-order, horizontally within a call, and vertically across a callgraph
transactions can be tried automatically when deadlock is detected

Optimistic Concurrency Control (OCC)

does not use locks
requires snapshot guarantees
also referred to as "snapshot isolation" or "software transactional memory"
transactions may be retried when guarantee is not consistent, but this depends on the caller's discretion

The tradeoffs between the 2 approaches are summarised here: https://agirlamonggeeks.com/2017/02/23/optimistic-concurrency-vs-pessimistic-concurrency-short-comparison/
Big database software often combine these ideas together into their transaction system, and allow the user to configure their transactions for their application needs.
A quick and dirty solution for ourselves will follow more along how RocksDB implemented their transactions: https://www.sobyte.net/post/2022-01/rocksdb-tx/. And details here: https://github.com/MatrixAI/js-polykey/issues/294#issuecomment-1106081466.
Pessimistic Concurrency Control
I'm most familiar with pessimistic concurrency control, and we've currently designed many of our systems in PK to follow along. I'm curious whether OCC might be easier to apply to our PK programs, but we would need to have both transaction systems to test.
In terms of implementign PCC, we would need these things:

Integrate the LockBox into DBTransaction
The LockBox would need to be augmented to detect deadlocks and manage re-entrant locks
Re-entrant locking means that multiple calls to lock key1 within the same transaction will all succeed. This doesn't mean that key1 is a semaphore, just that if it's already locked in the transaction, then this is fine to proceed.
Deadlock detection by ensuring that all locking calls always have a timeout, when timedout, it must then check a lock metadata table for transactions that were holding the locks that this transaction needed, and throw an exception regarding this.
Lock upgrades between read and write locks should also be considered, this means that if earlier call read-locked key1, a subsequent call can write-lock key1 (but must take precedence over other blocked readers & writers), and subsequent calls to write-lock key1 will also succeed. Lock downgrades will not be allowed.
After receiving a deadlock exception, this should bubble up to the transaction creator (or the unit of atomic operation designated as the request handler of the application to automatically retry)
All deadlocks detected are a programmer bug, but retrying should enable users to continue work. Therefore we may not do automatic retries and expect users to report the deadlock bug, and retry on their own discretion

As for optimistic transactions, we would do something possibly alot simpler: https://github.com/MatrixAI/js-polykey/issues/294#issuecomment-1106072194
Now there is already existing code that relies on how the db transactions work, namely the EncryptedFS.
Any updates to the DBTransaction should be backwards compatible. So that EncryptedFS can continue functioning as normal using its own locking system.
Therefore pessimistic and optimistic must be an opt-in.
For pessimistic, this may just mean adding some additional methods to the DBTransaction that ends up locking certain keys.
Optimistic Concurrency Control
For optimistic, this can just be an additional option parameter to the db.transaction({ optimistic: true }) that makes it an optimistic transaction.
Because OCC transactions are meant to rely on the snapshot, this means every get call must read from the iterator. Because this can range over the entire DB, the get call must be done on the root of the DB.
But right now iterator also creates their own snapshot. It will be necessary that every iterator call is iterating from the same snapshot that was created at the beginning.
Right now this means users must start their iterators at the beginning of their transaction if they were to do that.
This might mean we need to change our "virtual iterator" in DBTransaction to seek to snapshot iterator and acquire the relevant value there. We would need to maintain separate cursors for each iterator, and ensure mutual exclusion on the snapshot iterator.
When using optimistic transactions, this means every transaction creates a snapshot. During low-concurrency states, this is not that bad, and I believe leveldb does some sort of COW. So it's not a full copy. During high-concurrency states, this means increased storage/memory usage for all the concurrent snapshots. It is very likely that transactional contexts are only created at the GRPC handler level, and quite likely we would have a low-concurrency state for majority of the time for each Polykey node.
Based on these ideas, it seems OCC should be less work to do then PCC.
Additional context

https://github.com/MatrixAI/js-polykey/issues/294 - this is the overall issue tackling how concurrency works in PK, note that even if OCC was supported by DBTransaction, the usage of locks and LockBox will still apply in other areas that may only be interacting with in-memory state
https://github.com/MatrixAI/js-encryptedfs/pull/63 - the recent massive integration of the new "read committed" DBTransaction in to EFS, and its usage of LockBox
https://www.sobyte.net/post/2022-01/rocksdb-tx/ - rocksdb implementation of pessimistic and optimistic concurrency
https://www.mianshigee.com/tutorial/rocksdb-en/b603e47dd8805bbf.md - further details on rocksdb implementation, their default transaction is pessimistic and auto-locks every key that gets written to
#4 - original issue discussing how snapshot isolation should be brought into DB, but we didn't fully understand its requirements or implications
https://ongardie.net/blog/node-leveldb-transactions/ - original attempt at implementing snapshot-isolation (optimistic) transactions in leveldb

Tasks

[ ] - Prototype out the OCC system
[ ] - Prototype out the PCC system
[ ] - Test both OCC and PCC

Upon reading this http://ithare.com/databases-101-acid-mvcc-vs-locks-transaction-isolation-levels-and-concurrency/ this has clarified a few ideas that has been confusing.

The isolation levels mentioned before Read Committed, Read Uncommitted, Repeatable Read, Serializable were ideas that were first developed with "lock-based DBs", that is DBs that has no concept of snapshots and just use locks to manage concurrency.
Databases later developed "MVCC" which makes use of snapshots, this enabled "snapshot isolation" and optimistic concurrency control techniques. However DBs often retained the terminology of the above isolation levels, and the different concurrency phenomena (phantom reads, dirty reads, lost updates.. etc).
Implementations of MVCC seem to prefer the optimistic concurrency control, but you can always "reintroduce locking" into your optimistic transactions by using SELECT FOR UPDATE or SELECT FOR SHARE. So those features have always existed.
MVCC is easier to program with, you don't need to manage locks unless you really need it, and that's why FOR UPDATE and FOR SHARE still exist.
LevelDB does actually in fact implement MVCC, how ever it was not exposed to the end user, except with iterators. You cannot directly access the snapshot in LevelDB atm without iterators.
We may be able to turn our DBTransaction into an optimistic transaction by default, but also provide locking methods in case locks are necessary for special cases (such as when high concurrent pressure exists). This shouldn't affect backwards compatibility for EncryptedFS... but it will require some testing.

Re-reading:

https://ongardie.net/blog/node-leveldb-transactions/
https://www.cockroachlabs.com/blog/what-write-skew-looks-like/

This seems to mean that snapshot isolation should be easy to do.
However a new development was serializable snapshot isolation. This prevents "write skew" anomalies that exists in snapshot isolation, that currently can only be addressed by introducing locking.
I don't fully understand how to implement serializable snapshot isolation SSI, so I'll leave that for later. It seems SI is sufficient for most cases, and is how most DBs are still defaulting to.

Note, that if we had the ability to just use rocksdb, this stuff would mostly all be available for free. While leveldb does support rocksdb as the backing database https://github.com/Level/level-rocksdb, it doesn't expose any of the rocksdb transaction features discussed in https://www.mianshigee.com/tutorial/rocksdb-en/b603e47dd8805bbf.md which is unfortunate! I'm thinking that it will take more time to work out the C++ code and integration into nodejs right now (although we will have to do this soon). So I'll stick to attempting to implement this in JS/TS.

Note that we currently maintain written-data in our transaction data path. We used to call this the "snapshot". But this technically incorrect term. The snapshot is supposed to be the point-in-time state of the DB when the transaction starts. Additionally our implementation then implements COW on top of this.
This means that our transaction data path is where we are "buffering" our writes, and they are overlaid on top of the underlying DB.
In snapshot isolation, rather than overlaying on top of the underlying DB, they overlay on top of a "snapshot" of the underlying DB that was first created when the transaction started. This is only accessible via the LevelDB.iterator method which we have wrapped as DB._iterator(). Note that DB.iterator starts at the data sublevel while DB._iterator starts at the true root level.
Because DB._iterator() is not asynchronous, this can be setup during the constructor. But we have flexibility here in case we need to do asynchronous operations, either in DB.transaction()'s ResourceAcquire, or DBTransaction.createTransaction.

For detecting a write conflict at the end, I was originally under the impression that we only need to check whether the key-set being written to has a different set of values compared to transaction's snapshot.
However most of the literature on snapshot isolation instead talks about timestamps. Meaning that even if another transaction updated the value to the same value, this would still cause a write conflict.
I'm not sure why it doesn't just check if the values are different, and but maybe there's some edgecase where checking for value difference would not be enough to ensure consistency.

I want to note that our write buffer is placed in the DB (disk) itself and is therefore unbounded by memory. However our write operations are buffered in-memory and not in the DB. You might wonder why not push all write operations also into the DB transaction data path? Well because at the end you still end up reading them all in-memory to perform the write batch, so there's no advantage with putting the operations onto disk. Therefore no matter what our transaction sizes are still bounded by memory.
This does impact the scalability of large atomic operations such as those in EFS: https://github.com/MatrixAI/js-encryptedfs/issues/53.

https://www.sobyte.net/post/2022-01/rocksdb-tx/ states that RocksDB does not support SSI (serializable snapshot isolation). It only supports SI which is what we are heading towards to.
During the validation phase, it says:

rocksdb does not implement SSI, only conflict tracking for write operations, the process will be simpler than badger’s SSI, only need to check one thing, that is, at commit time, each Key in the db is not updated after the sequence number of the start of the current transaction exists.
The dumbest way to do this is to read the db once for each Key, get its most recent sequence number, and compare it to the transaction’s sequence number. If the sequence number in the db is larger, then sorry, there is a transaction conflict.
rocksdb will definitely not do something like reading IO N times for each Key in a transaction. Here is an idea, the execution time of the transaction is not long, in the conflict check scenario, you do not need to find all the historical data of the Key to make a judgment, but only the most recent data. The most recent data is MemTable, so to do the recent conflict detection, it is enough to read the data of MemTable, and there is no need to execute IO.

So rocksdb doesn't just reads the timestamp for every key that has been written, it has some optimisation making use MemTable. We don't really have anything similar to that, unless except the fact that we buffer up write operations in-memory, so if we exposed our writes with some queryable interface, this may be possible.
If we keep it simple and just read the timestamp for each key, for a large transaction, that would be alot of reads. And because we can only access this via the iterator, this means seeking our transaction iterator and performing reads off that to get the timestamp metadata. However our iterator has a "read ahead cache" controlled by the highWaterMarkBytes option. See: https://github.com/Level/classic-level#about-high-water. This doesn't exist on leveldown atm. The fillCache is a general fill cache. But this performance tuning we can worry about later.

The implementation of this can be separated into 2 phases:

The integration of the iterator as a snapshot to be used instead of the underlying DB. This means the transaction data path is used as the overlay on top of the snapshot. This impacts the DBTransaction.get and DBTransaction.iterator implementation.
The implementation of the commit write-set conflict detection. This may involve using timestamps and we need to figure out how the last updated timestamp is maintained including whether last updated timestamps are set as soon as an update is made (updated on put or when transaction is committed).

For the first phase:

The transaction will have a snapshot: DBIterator property.
DBTransaction get has to use the tran iterator. It first has to read the value from its own data overlay, then read it from the iterator.
Iterator get has to be a wrapper. Wrapper uses lock to mutual exclude operations. It must copy the original key, seek to the get key,  then await the next, compare the returned key, if matching the get key return the value, if not return undefined, seek back to the original key. Seeking back to the original key may not be necessary if derived iterators always maintain their own key.
Alternatively it can use a new method called protected snapshotGet that acquires the data from the transaction iterator, and can ensure mutual-exclusion with a lock.
Delete doesn't have to use the main iterator, it uses the tombstone as usual.
Put doesn't have to use the main iterator, it just uses the COW data overlay.
As for DBTransaction.iterator, right now it creates a virtual iterator that iterates over cow overlay and DB simultaneously. It mow must iterate over cow overlay and transaction iterator simultaneously. It may be enough to simply re-use the transaction iterator. However creation and destruction are noops for transaction iterator. However because 2 iterators or more may be created in the same transaction, it is necessary to keep reference to the seeked key. This is always used before a next() call is made.
Consider that 2 derived iterators gets used and in the middle it is also calling get() in the iterators. This means on each next iteration and each get call there is mutual exclusion on the transaction iterator. At each step the the tran iterator must be seeked to the relevant key and response checked. If all derived iterators maintain their seek key, then tran iterator doesnt need to have its seek key restored. Effectively, derived iterators end up calling snapshotGet on the tran iterator.
Actually it may be a bit more difficult than that. The next call advances the the cursor. So when we are calling next on the tran iterator, we want to know where it advanced to. Seek sets the cursor, but next advances beyond it.

For the second phase:

The DB would need the last updated counter. But does this always increment or is it a counter that resets whenever there no concurrent transactions? Or does it matter?

Based on the discussion here https://github.com/MatrixAI/js-db/commit/6107d9c3ac55767113034bcedd19b379a5181a1d#commitcomment-73269633, the lmdb-js  project exposes transactions that is combination of snapshot isolation for reads, but PCC serialisable locking for writes. It does not however have OCC snapshot isolation atm because it doesn't do write-set conflict detection.

I've started using rocksdb directly now to implement SI.
Some notes about it.

Rocksdb doesn't have SSI support, but there are projects built on top of rocksdb that does provide SSI.
SSI solves the write skew problem, a work around for solving the write skew problem is called "promotion", this is basically the usage of GetForUpdate call which does something similar to SELECT ... FOR UPDATE and it even SELECT ... FOR SHARE, it even has an exclusive boolean parameter that is by default true that I haven't tried to see what it means yet.
I've tested this promotion in tests/rocksdb/rocksdbP.test.ts and it works quite nicely.
Rocksdb offers OCC or PCC. But you cannot use both at the same time. This is different from the idea proposed above, where it should be possible to have a default layer of OCC, and opt-in PCC with locking. Since we are using OCC by default, we're using OptimisticTransactionDB in rocksdb, and we will need to do opt-in PCC locking at the JS-level and not rely on any of the locking features in rocksdb. It is likely more performant to do this anyway and not have to incur the JS-C call overhead of dealing with locks as JS async locks is just promise ordering.
RocksDB's optimistic transactions exposes a very flexible manipulation of snapshots that I didn't consider above:

Snapshots can be set at the beginning of the transaction, this only affects the Commit() call, it does not affect the Get calls
Without setting a snapshot at the beginning, the Commit() succeeds only when keys have not been written to after the first read within the transaction, this is similar to how SQL databases have worked. When set at the beginning it's instead based on when the time when the transaction was started.
We can make this simple by always setting a snapshot in the beginning, and always using that snapshot for all reads, thus enabling both consistent reads, repeatable reads, and consistent iteration in one fell swoop.
Setting the snapshot later, perhaps upon the first operation (think of this as lazy snapshot setting) might be more efficient, this is because one might start a transaction, have lots of time pass, and then start to read and write keys.
I'm not sure, but perhaps snapshot should only be set upon the first read operation. But this might be premature optimisation.
To allow flexibility in figuring out what we want to do, let's just expose snapshots themselves to the end user in JS, so we can manipulate it in JS.

The only optimisation for creating a snapshot upon registering the first lazy operation is just reducing the number of needless transaction conflicts. So if both T1 and T2 started, and you know they will conflict if they ran at the same time, but if T1 was sufficiently delayed in real time in starting their read/write operations, then it's better to delay snapshot creation to when the first operation is done.
If we can expose snapshots as first class types into JS although opaque, then this should be wieldable in JS.

Turns out RocksDB even has an operation to do this exact lazy setting of snapshot. It's called SetSnapshotOnNextOperation().
I believe we should have this set by default. However I realised that the docs don't say that it also set before Get() is called.
And if I want consistent reads, I'd need to get access to that snapshot and then set that as the option when performing the read.
So although it seems useful, I'm not sure if it's actually useful, since I'm not sure if it would be called upon the next Get() and secondly, I'd want to have that snapshot apply to the Get() or GetForUpdate() call.
I'd like to also point out that there's a ClearSnapshot() call available on the transaction, but that's apparently not the same thing as releasing the snapshot from the DB.

That SetSnapshotOnNextOperation is not what we are looking for. It's designed for setting a snapshot for controlling the commit, but does not allow any interception of the getters to get consistent reads.
In my thinking now, transactions should by default be consistent reads and consistent writes. Optimistic transactions are always consistent writes. I can't think of situations where we don't want consistent reads, if you did, you'd just use db* operations instead.
So the optimisation of setting the snapshot upon the first operation has to be done in JS-land under DBTransaction.


Unable to successfully install lll under Golang 1.5 within Travis CI

I'm trying to get a PR I've put up to successfully get thru Travis for Go 1.5:
https://travis-ci.org/antonlindstrom/pgstore/jobs/151870208
It appears this package isn't installing properly. I'm not clear whether this is an issue with your package in some way, or the gometalinter package which is installing it. Could you give some direction wrt that please?
Thank you!

bump - anyone?

Sorry abot the late reply. Looks like it is the lll package from the logs.
Will take a look at it. Thanks for reporting!
On 15 Aug 2016 21:40, "Chris Johnson"<EMAIL_ADDRESS>wrote:

bump - anyone?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/walle/lll/issues/3#issuecomment-239906113, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AALqoDBb-pkStIjKBWjLuG7ESN0i7es8ks5qgMCwgaJpZM4JjTly
.

Thanks @walle !!

Hi @wchrisjohnson I think I figured out the issue. The only build that fails is for go 1.5, this is because I'm vendoring the dependencies for lll, which is only available since go 1.6.
One thing you could try is to use/set the GO15VENDOREXPERIMENT=1 environment variable for the build on go 1.5.

Yep - this worked for me - thanks!

No problem, glad it worked out for you!


[rfc] rkt kill

There's no way to "stop" a rkt container today, it seems a general rkt kill $SIGNUM analogous to the standard unix kill(1) command would go a long way towards providing it.
The rkt kill command could deliver the specified signal or the default SIGTERM to the top-level process representing the named pod.
It's a bit awkward with systemd in stage1 though, because systemd handles SIGTERM with the following:

   SIGTERM
      Upon receiving this signal the systemd system manager serializes
      its state, reexecutes itself and deserializes the saved state
      again.
This has been brought up previously: https://github.com/coreos/rkt/pull/532#issuecomment-74742097
Does it make sense to have a general kill which delivers a signal to the pod's top-level process?  Or should we make a less general rkt stop which employs some stage1-specific stop entrypoint to Do The Right Thing?

IMHO, from a semantic point of view we should only have a stop if we have a start, analogous to the the freeze/thaw in the issues you pointed to.

I think something specific would make it more user-friendly.  This is mostly
           equivalent to systemctl start halt.target.
       SIGRTMIN+13 (kill -47)
           Immediately halts the machine.

I don't know if it worth an entrypoint with a binary just to send a signal.

well, what's appropriate for stopping lkvm?  that's where the entrypoint comes in.

naive driveby, can't we kill systemd-nspawn/lkvm process and it'll Do The
Right Thing?
On Mon, Sep 28, 2015 at 3:35 PM, Vito Caputo<EMAIL_ADDRESS>wrote:

well, what's appropriate for stopping lkvm? that's where the entrypoint
comes in.
—
Reply to this email directly or view it on GitHub
https://github.com/coreos/rkt/issues/1496#issuecomment-143893111.

By default, if --boot is used and you send SIGTERM to systemd-nspawn it will send SIGRTMIN+3 to PID 1 in the container.
I don't see any kind of similar signal handling in lkvm. There's lkvm stop though.

/cc @jellonek @ppalucki

Maybe we just send SIGTERM to the outer rkt process of the pod then, like any process manager would do.  The only reasons I can see for introducing a stop stage1 entrypoint are:

symmetry (we have a run entrypoint)
if a stage1 implementation benefits from a more graceful/involved exit path, it could be stuck in the stop.

Maybe it makes sense to have a stop entrypoint, invoke it when set, and afterwards send SIGTERM all the same to the outer rkt process of the pod.
I don't like the stop entrypoint for what it implies; the wrong thing will happen when plain SIGTERM is delivered as would be by a process manager.  So maybe it's a flawed idea, symmetry be damned.

So I think I have a related issue that would benefit from generic rkt kill --signal=HUP command.
I'm currently trying to port a haproxy docker container that uses haproxy-systemd-wrapper to gracefully reload its configuration after a HUP signal. Currently I cant see a good way to signal the master process started by rkt.

Maybe we should return the pid of the stage1 now? On an oob discussion @vcaputo told me currently pid returned by rkt status is the pid of PID1 in the nspawn container(the systemd), because we need that to enter the namespace. But as now rkt enter takes the uuid of the pod, I think we don't have to show the pid of the systemd now.

Ah that would really help.

#1699

#1699 has been merged, so it returns the pid of stage1 now.

My hunch here is to do a rkt stop and then make sure we have the right behavior wired up for each stage1. Sending a kill with an arbitrary signal won't work everywhere right now. If we do kill we would need to try and figure out what the different "rkt signals" we could send would be.

My hunch here is to do a rkt stop and then make sure we have the right behavior wired up for each stage1. Sending a kill with an arbitrary signal won't work everywhere right now. If we do kill we would need to try and figure out what the different "rkt signals" we could send would be.

Started working on this https://github.com/kinvolk/rkt/commits/iaguis/rkt-stop
It sends SIGTERM to the pid of stage1 for the nspawn and fly flavors and it calls lkvm stop ${VM} for the lkvm flavor.
It seems to work but I want to do some refactorings to get rid of flavor code messiness (e.g. all the if flavor == "kvm").

for cadvisor testing this would be nice, i.e. I'm systemd-run'ing rkt to run-prepared the containers in the background and would just like to stop the uuid

I'd also need to signal a process running inside a Rkt container. In my case that would be quay.io/coreos/dnsmasq, which reloads its hostsfile upon receiving SIGHUP.


[flutter_adaptive_scaffold] body overlaps topNavigation elevation shadow

It is common to have a topNavigation bar that has some elevation so that it drops some shadow over the body.
I'm trying to achieve that using the AdaptiveLayout from the flutter_adaptive_scaffold package (v0.0.8). However, because the body is drawn after the topNavigation, it always overlaps the shadow.
Steps to Reproduce

Add a container with elevation > 0 in topNavigation slot
Add a non-transparent body

Expected results: The elevation shadow from the topNavigation should drop on the body
Actual results: The body overlaps the shadow

Code sample
import 'package:flutter/material.dart';
import 'package:flutter_adaptive_scaffold/flutter_adaptive_scaffold.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      debugShowCheckedModeBanner: false,
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    final List<Widget> children = List<Widget>.generate(10, (int index) {
      return Padding(
        padding: const EdgeInsets.all(8.0),
        child: Container(
          color: const Color.fromARGB(255, 255, 203, 32),
          height: 400,
        ),
      );
    });

    return ColoredBox(
      color: Colors.white,
      child: AdaptiveLayout(
        internalAnimations: false,
        topNavigation: SlotLayout(
          config: <Breakpoint, SlotLayoutConfig>{
            Breakpoints.smallAndUp: SlotLayout.from(
              key: const Key('topNavigation'),
              builder: (_) => const TopNavigationBar(),
            ),
          },
        ),
        body: SlotLayout(
          config: <Breakpoint, SlotLayoutConfig>{
            Breakpoints.smallAndUp: SlotLayout.from(
              key: const Key('body'),
              builder: (_) => Center(
                child: ConstrainedBox(
                  constraints: const BoxConstraints(maxWidth: 750),
                  child: Scaffold(
                    backgroundColor: Colors.white,
                    body: GridView.count(crossAxisCount: 2, children: children),
                  ),
                ),
              ),
            )
          },
        ),
      ),
    );
  }
}

class TopNavigationBar extends StatelessWidget {
  const TopNavigationBar({
    super.key,
  });

  @override
  Widget build(final BuildContext context) {
    return Material(
      elevation: 2,
      child: ColoredBox(
        color: Colors.white,
        child: Padding(
          padding: const EdgeInsets.symmetric(vertical: 16, horizontal: 56),
          child: Row(
            children: const <Widget>[FlutterLogo()],
          ),
        ),
      ),
    );
  }
}

Thanks for the report. Seeing same behavior as reported using latest versions.

 stable, master flutter doctor -v
[✓] Flutter (Channel stable, 3.3.10, on macOS 12.2.1 21D62 darwin-x64, locale
    en-GB)
    • Flutter version 3.3.10 on channel stable at
      /Users/dhs/documents/fluttersdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 135454af32 (15 hours ago), 2022-12-15 07:36:55 -0800
    • Engine revision 3316dd8728
    • Dart version 2.18.6
    • DevTools version 2.15.0

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] VS Code (version 1.62.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

[!] Flutter (Channel master, 3.7.0-10.0.pre.45, on macOS 12.2.1 21D62
    darwin-x64, locale en-GB)
    • Flutter version 3.7.0-10.0.pre.45 on channel master at
      /Users/dhs/documents/fluttersdk/flutter
    ! Warning: `flutter` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/flutter, which is not inside
      your current Flutter SDK checkout at
      /Users/dhs/documents/fluttersdk/flutter. Consider adding
      /Users/dhs/documents/fluttersdk/flutter/bin to the front of your path.
    ! Warning: `dart` on your path resolves to
      /Users/dhs/Documents/Fluttersdk/flutter/bin/dart, which is not inside your
      current Flutter SDK checkout at /Users/dhs/documents/fluttersdk/flutter.
      Consider adding /Users/dhs/documents/fluttersdk/flutter/bin to the front
      of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision a3a0048d7d (74 minutes ago), 2022-12-18 22:44:27 -0500
    • Engine revision 3c6cab0327
    • Dart version 3.0.0 (build 3.0.0-35.0.dev)
    • DevTools version 2.20.0
    • If those were intentional, you can disregard the above warnings; however
      it is recommended to use "git" directly to perform update checks and
      upgrades.

[!] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    ! Flutter recommends a minimum Xcode version of 13.
      Download the latest version or update via the Mac App Store.
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] VS Code (version 1.62.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (5 available)
    • SM G975F (mobile)       • RZ8M802WY0X • android-arm64   • Android 11 (API 30)
    • Darshan's iphone (mobile)  • 21150b119064aecc249dfcfe05e259197461ce23 •
      ios            • iOS 14.4.1 18D61
    • iPhone 12 Pro Max (mobile) • A5473606-0213-4FD8-BA16-553433949729     •
      ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-3 (simulator)
    • macOS (desktop)            • macos                                    •
      darwin-x64     • Mac OS X 10.15.4 19E2269 darwin-x64
    • Chrome (web)               • chrome                                   •
      web-javascript • Google Chrome 98.0.4758.80

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.


Manifest analysis

As a long term goal, manifest files should be consumed and have warnings generated for possible errors.
Ideas:

Command items should have their id and classes check to make sure they map to items in the project.

Just got stung hard by this, need to look into how to do this :/ Investigate the code warnings and code fix apis.


Error when creating and managing components

I have installed ortelius on our IBM Cloud Kubernetes service. When I try to create, edit and save a new component I get the following error in the console
SyntaxError: Unexpected end of JSON input     at JSON.parse (<anonymous>)     at n.parseJSON (jquery.min.js:4)     at Qc (jquery.min.js:4)     at x (jquery.min.js:4)     at XMLHttpRequest.b (jquery.min.js:4)
It looks like this:

The component is still created but when I try to access it the UI gets stuck in some form of deadlock and never resolves

These are the console errors I get from the browser when accessing the component

I have tried different tags of the ortelius software, but no luck.
The logs from the ortelius container doesn't show anything beside the standard setup logs:
+ sudo chown -R postgres:postgres /var/lib/pgsql
+ sudo chmod -R 777 /opt/deployhub
+ pkill postgres
+ sudo test -f /var/lib/pgsql/data/pg_hba.conf
+ echo 'Database already initialized'
+ sudo chmod 700 /var/lib/pgsql/data
Database already initialized
+ sudo -u postgres /usr/pgsql-10/bin/pg_ctl start --pgdata=/var/lib/pgsql/data
waiting for server to start....2021-04-06 08:19:06.356 UTC [19] LOG:  listening on IPv6 address "::1", port 5432
2021-04-06 08:19:06.356 UTC [19] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2021-04-06 08:19:06.360 UTC [19] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-04-06 08:19:06.364 UTC [19] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2021-04-06 08:19:06.372 UTC [19] LOG:  redirecting log output to logging collector process
2021-04-06 08:19:06.372 UTC [19] HINT:  Future log output will appear in directory "log".
 done
server started
+ sleep 10
+ sudo -u postgres /usr/pgsql-10/bin/pg_ctl status --pgdata=/var/lib/pgsql/data
pg_ctl: server is running (PID: 19)
/usr/pgsql-10/bin/postgres "-D" "/var/lib/pgsql/data"
+ '[' '!' -e /opt/deployhub/logs ']'
+ sudo mkdir /opt/deployhub/logs
+ '[' '!' -e /opt/deployhub/engine ']'
+ sudo chmod -R 777 /opt/deployhub
+ sudo chown -R omreleng /opt/deployhub
+ cd /opt/deployhub/engine
+ export LD_LIBRARY_PATH=/opt/deployhub/engine/lib:/opt/deployhub/engine/bin
+ LD_LIBRARY_PATH=/opt/deployhub/engine/lib:/opt/deployhub/engine/bin
+ export PATH=/opt/deployhub/engine/lib:/opt/deployhub/engine/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/google-cloud-sdk/bin:/usr/pgsql-10/bin:/usr/local/google-cloud-sdk/bin
+ PATH=/opt/deployhub/engine/lib:/opt/deployhub/engine/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/google-cloud-sdk/bin:/usr/pgsql-10/bin:/usr/local/google-cloud-sdk/bin
++ cut -d: -f6
+++ whoami
++ getent passwd omreleng
+ HOME=/home/omreleng
+ export HOME
+ sudo cp -r '/keys/*' /root/.ssh
cp: cannot stat '/keys/*': No such file or directory
+ sudo chown -R root /root/.ssh
+ sudo chmod 755 /root/.ssh
+ '[' -e /root/.ssh/known_hosts ']'
+ cp -r '/keys/*' /home/omreleng/.ssh
cp: cannot stat '/keys/*': No such file or directory
+ chown -R omreleng /home/omreleng/.ssh
+ chmod 755 /home/omreleng/.ssh
+ chmod 600 /home/omreleng/.ssh/known_hosts
chmod: cannot access '/home/omreleng/.ssh/known_hosts': No such file or directory
+ echo Running DeployHub Processes
Running DeployHub Processes
+ java -jar /opt/deployhub/webadmin/webapp-runner.jar --path /dmadminweb /opt/deployhub/webadmin/deployhub-webadmin.war
+ perl -pe '$_ = localtime.": $_"'

Setup info

Kubernetes version: 1.19.9_1540
Image repository: quay.io/ortelius/ortelius
Image tag: master-v<IP_ADDRESS>0-ga08ed02
Istio version: 1.8

If you need more info please tell.

@hatati - let me take a look at what is happening.

Give the following image a try.  Should fix your issue.
docker pull quay.io/ortelius/ortelius:maintenance-v<IP_ADDRESS>0-gbe148b6

Awesome, domains are present again and component creation is working. I'm closing this one. Thanks for the help!


Roll Engine from c98ff298fe0e to bfd24815ce80 (4 revisions)

https://github.com/flutter/engine/compare/c98ff298fe0e...bfd24815ce80
2021-01-06<EMAIL_ADDRESS>Roll Skia from 854ee85736e3 to 2ca39919583f (2 revisions) (flutter/engine#23446)
2021-01-06<EMAIL_ADDRESS>[web] specify all defines used for html, ck, auto rendering modes (flutter/engine#23433)
2021-01-06<EMAIL_ADDRESS>Disable focused_text_field golden on Firefox (flutter/engine#23442)
2021-01-06<EMAIL_ADDRESS>Roll Dart SDK from 1c14d9bb3528 to df54886d1295 (14 revisions) (flutter/engine#23444)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Commit queue failed; closing this roll.

Commit queue failed; closing this roll.


List and Collection now for collections.abc

Minor PR to upgrade List and Collection to better fit Python collections model.  We can't complete the contract on MutableSequence due to a conflict on remove.  I could rename the Java remove to remove_ if we want to complete that one as well.

It is good not to break contracts. Would you please autopep8 your python files?

Autopep8 is complete.   So just for clarification....  would you prefer?

[ ] To rename the Java method remove to remove_ so that we can complete the Python contract for collections.abc.MutableSequence, but will confuse Java programmers.  Both Python and Java sematics are then possible (with Java programmer forced to call remove_ due to interface conflicts.)
[ ] Leave remove as is as making it have Python remove semantics would break code, but will confuse Python programmers.

As it stands the Java contract is basically a silent failure currently.  It doesn't raise a ValueError and expects someone to check the return which isn't a Python idiom.

I'm OK with confusing Java programmers. Even though JPype can be now be used bidirectional, I think most users will use it to call Java code from within Python.


Download Build Artifact Timing Out

Hello -
My Azure DevOps is hosted and my build agents are installed on a google cloud VM
I've had this build working for over a year, but last week I noticed it started failing due to one of my 'Download Build Artifacts commands'
It's the same artifact that is causing the issue each time
Last week it was intermittent where some would be okay and others would fail, but this week it is always failing
The error shown is as follows;
`` artifacts-engine: unhandled rejection error: connect etimedout <IP_ADDRESS>:443
unhandled: connect etimedout <IP_ADDRESS>:443
unhandled: connect etimedout <IP_ADDRESS>:443
artifacts-engine: unhandled: connect etimedout <IP_ADDRESS>:443
exit code 7 returned from process: file name
'C:\VSTSBuildAgent\BuildAgent02\externals\node\bin\node.exe', arguments '"C:\VSTSBuildAgent\BuildAgent02_work_tasks\DownloadBuildArtifacts_a433f589-fce1-4460-9ee6-44a624aeb1fb\0.153.1\main.js"'.
Enter Task Name: Download Build Artifact
Environment
Azure Pipeline
Agent - Private Agent - Windows Server 2016

Hi @SJHarrison1992 , we recently updated the task (version 0.153.3) with few fixes. Please let us know if the issue still exists for you.

Issue appears to be fixed, thank you


 One line above the line that raises the RuntimeError, there's a comment saying "This should never happen with the current session implementations." Clearly, it did happen. The situation doesn't bother me greatly, and I'm only mentioning this because clearly something unintended happened here.
import tensorflow as tf
with tf.Session().as_default():
tf.get_default_session()
The following four lines do not give the error:
import tensorflow as tf
sess = tf.Session()
with sess.as_default():
tf.get_default_session()
This suggests that the Session.as_default() method doesn't store  in any way that keeps it from being garbage collected.
NOTE: Only file GitHub issues for bugs and feature requests.  All other topics will be closed.
For general support from the community, see StackOverflow.
To make bugs and feature requests more easy to find and organize, we close issues that are deemed
out of scope for GitHub Issues and point people to StackOverflow.
For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
None.
Environment info
Operating System:
Mac OS X 10.11.6
Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
None.
If installed from binary pip package, provide:

A link to the pip package you installed: I don't recall the link; I installed following the standard installation instructions.
The output from python -c "import tensorflow; print(tensorflow.__version__)".

0.10.0rc0
If installed from source, provide

The commit hash (git rev-parse HEAD)
The output of bazel version

If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)
See above.
What other attempted solutions have you tried?
See above.
Logs or other output that would be helpful
(If logs are large, please upload as attachment or provide link).

Looks like an easy fix. It's in review now and should appear in the next push.

Sweet :)

still unsolved ?

@MakeWater Please open a new issue with a reproduction if you're still running into this issue. Thanks!


fetch and insert 2017 and 2018 reference observations

The priorities are SURFRAD, SOLRAD, RTC, and the Lamont ARM site. We need this for the Topic Area 2 evaluations.

everything except for RTC has been fetched


NullPointer

I have a problem , i working with intellijIdea and get below error :
Exception in thread "main" java.lang.NullPointerException
at javax.swing.ImageIcon.(ImageIcon.java:217)
at org.math.plot.components.PlotToolBar.(PlotToolBar.java:61)
at org.math.plot.PlotPanel.addPlotToolBar(PlotPanel.java:149)
at org.math.plot.PlotPanel.(PlotPanel.java:59)
at org.math.plot.PlotPanel.(PlotPanel.java:67)
at org.math.plot.Plot2DPanel.(Plot2DPanel.java:31)
at Test.main(Test.java:12)
my code:
import javax.swing.*;
import org.math.plot.*;
public class Test {
public static void main(String[] args) {
    double[] x = { 1, 2, 3, 4, 5, 6 };
    double[] y = { 45, 89, 6, 32, 63, 12 };

    Plot2DPanel plot = new Plot2DPanel();

    plot.addLinePlot("my plot", x, y);

    JFrame frame = new JFrame("a plot panel");
    frame.setSize(600, 600);
    frame.setContentPane(plot);
    frame.setVisible(true);

}

}

Hi.

Hi. I am also running into this issue. Do you have any suggestions on how to resolve it?

Check that you have images & icons in your resources declared in the project.


Unable to open Responsive web design certificate

Previously I was unable to claim Responsive web design certificate. Now the issue was resolved and certificate was added to my profile but I am unable to open the certificate as i am getting the below error.

Issue resolved after agreeing to the pledge


Event PubSub topics + linear filtering.

Although these two changes could go separatedly, I rather put them together because they are very related. Our filtering system is very inneficient at matching results. This can slow down the events API with complicated filters. Moreover, that API performs operations in linear complexity at best, and exponencial at worst, when we can do constant time at best and linear at worst.
I separated both commits and wrote explanation of the changes in each of them, but I'm copying both messages here for easy reading:
Add PubSub topics.

A TopicFunc is an interface to let the pubisher decide whether it needs to
send a message to a subscriber or not. It returns true if the publisher
must send the message and false otherwise.

Users of the pubsub package can create a subscriber with a topic function
by calling `pubsub.SubscribeTopic`.

Message delivery has also been modified to use concurrent channels per
subscriber. That way, topic verification and message delivery is not o(N+M)
anymore, based on the number of subscribers and topic verification
complexity.

Using pubsub topics, the API stops controlling the message delivery,
delegating that function to a topic generated with the filtering provided
by the user. The publisher sends every message to the subscriber if there
is no filter, but the api doesn't have to select messages to return
anymore.

Make filtering a linear operation.

Improves the current filtering implementation complixity. Currently, the
best case is O(N) and worst case O(N^2) for key-value filtering. In the new
implementation, the best case is O(1) and worst case O(N), again for
key-value filtering.

Nice! Thanks @calavera

Didn't know that we have crappy cancel function :/

@LK4D4 we can probably change it. That cancel function only calls daemon.events.Evict with the listener as an argument. I think it would be much more clean if we had an Unsubscribe function in the daemon that took the listener.
That way, the events interface in the daemon could be something like:
type eventsBackend interface {
   Subscribe(since, until int64, eventFilter filterArgs) ([]interface{}, chan interface{})
   Unsubscribe(listener chan interface{})
}

@LK4D4 that cancel crappy function is gone now :smile:  can you take a look?

LGTM

LGTM

LGTM

Gah - please be careful - your changing/breaking docker remote API when changing raw API types (which affects docker compose and other tools), and there's been no update to the docs (API or release notes) for this change:
https://github.com/docker/docker/blob/master/docs/reference/api/docker_remote_api_v1.23.md#list-containers
Old remote API format: filters={"exited":["0"]}
New remote API format: filters={"exited":{"0":true}}

@twhiteman filters are backwards compatible and the api knows how to deserialize both formats. See https://github.com/docker/engine-api/blob/master/types/filters/parse.go#L93-L115.
Please, feel free to open an issue if you bumped into problems.


Allow specifying tag in toml config file

It looks like it is currently not possible to specify a tag in the config file. I think it'd be useful if the config file format supports the equivalent of the command line interface's --tag.

@zyedidia we do have a tag param in the ConfigRepository - https://github.com/zyedidia/eget/blob/0983deab36378a1536bf9dc97d5d56f6e5dd3477/config.go#L38
does this not already work?

@dufferzafar Even if it already works (Which it very well may! I haven't tried recently), it's undocumented in the Configuration section of the README.


Fix agents with disabled avoidance getting added to avoidance simulation

Fixes that agents with disabled avoidance were getting added to avoidance simulation.
This is a small fix for 4.0 only (and 3.5+) backported from the avoidance rework (that no longer has the controlled_agent array).
The avoidance step was always only calculated for the "controlled_agents" with enabled avoidance but all agents were added to the avoidance simulation. The issue is that those "disabled" agents are still processed by the RVO avoidance in the neighbor search and stuck at their origin position. This causes problems with the avoidance calculation around that positions and also costs performance for nothing.

Thanks!

Cherry-picked for 4.0.2.


Attempting to configure DCOS_PRIVATE_REGISTRY fails

OS: OSX=10.11.4
VirtualBox=5.0.16
Vagrant=1.8.1
DCOS_CONFIG_PATH=etc/config-1.6.yaml
DCOS_PRIVATE_REGISTRY=true
Vagrant up Arguments=vagrant up m1 a1 p1 boot
I am attempting to install the DCOS 1.6 Enterprise Edition bits.   I was successful in doing so if I used a vanilla config.     After that success, I destroyed the config and set the DCOS_PRIVATE_REGISTRY env variable to true and tried again.   That resulted in the following failure:
==> m1: >>> Registering private docker registry: boot.dcos:5000
==> m1: sed: can't read /etc/sysconfig/docker: No such file or directory
It looks like the provision/bin/insecure-registry.sh script makes some incorrect assumptions about how Docker is installed on the base box....
Craig
USMA03MML11008:dcos-vagrant v625018$ export DCOS_PRIVATE_REGISTRY=true
TUSMA03MML11008:dcos-vagrant v625018$ set | grep DCOS
DCOS_CONFIG_PATH=etc/config-1.6.yaml
DCOS_PRIVATE_REGISTRY=true
_=DCOS_PRIVATE_REGISTRY
TUSMA03MML11008:dcos-vagrant v625018$ vagrant up m1 a1 p1 boot
Bringing machine 'm1' up with 'virtualbox' provider...
Bringing machine 'a1' up with 'virtualbox' provider...
Bringing machine 'p1' up with 'virtualbox' provider...
Bringing machine 'boot' up with 'virtualbox' provider...
==> m1: Importing base box 'mesosphere/dcos-centos-virtualbox'...
==> m1: Matching MAC address for NAT networking...
==> m1: Checking if box 'mesosphere/dcos-centos-virtualbox' is up to date...
==> m1: Setting the name of the VM: m1.dcos
==> m1: Clearing any previously set network interfaces...
==> m1: Preparing network interfaces based on configuration...
m1: Adapter 1: nat
m1: Adapter 2: hostonly
==> m1: Forwarding ports...
m1: 22 (guest) => 2222 (host) (adapter 1)
==> m1: Running 'pre-boot' VM customizations...
==> m1: Booting VM...
==> m1: Waiting for machine to boot. This may take a few minutes...
m1: SSH address: <IP_ADDRESS>:2222
m1: SSH username: vagrant
m1: SSH auth method: private key
m1: Warning: Remote connection disconnect. Retrying...
m1: Warning: Remote connection disconnect. Retrying...
m1: Warning: Remote connection disconnect. Retrying...
m1:
m1: Vagrant insecure key detected. Vagrant will automatically replace
m1: this with a newly generated keypair for better security.
m1:
m1: Inserting generated public key within guest...
m1: Removing insecure key from the guest if it's present...
m1: Key inserted! Disconnecting and reconnecting using new SSH key...
==> m1: Machine booted and ready!
GuestAdditions versions on your host (5.0.16) and guest (5.0.8) do not match.
Loaded plugins: fastestmirror
Determining fastest mirrors

base: centos-distro.1gservers.com
extras: mirror.stjschools.org
updates: mirror.confluxtech.com
Package kernel-devel-3.10.0-327.13.1.el7.x86_64 already installed and latest version
Package gcc-4.8.5-4.el7.x86_64 already installed and latest version
Package 1:make-3.82-21.el7.x86_64 already installed and latest version
Package 4:perl-5.16.3-286.el7.x86_64 already installed and latest version
Package bzip2-1.0.6-13.el7.x86_64 already installed and latest version
Nothing to do
Copy iso file /Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso into the box /tmp/VBoxGuestAdditions.iso
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 5.0.16 - guest version is 5.0.8
Verifying archive integrity... All good.
Uncompressing VirtualBox 5.0.16 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 5.0.8 of VirtualBox Guest Additions...
Removing existing VirtualBox non-DKMS kernel modules[  OK  ]
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox non-DKMS kernel modules[  OK  ]
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module[  OK  ]
Building the shared folder support module[  OK  ]
Building the OpenGL support module[  OK  ]
Doing non-kernel setup of the Guest Additions[  OK  ]
You should restart your guest to make sure the new modules are actually used

Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping.
An error occurred during installation of VirtualBox Guest Additions 5.0.16. Some functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
==> m1: Checking for guest additions in VM...
==> m1: Setting hostname...
==> m1: Configuring and enabling network interfaces...
==> m1: Mounting shared folders...
m1: /vagrant => /Users/v625018/work/dcos-vb/dcos-vagrant
==> m1: Updating /etc/hosts file on active guest machines...
==> m1: Updating /etc/hosts file on host machine (password may be required)...
Password:
==> m1: Running provisioner: dcos_ssh...
host: Found existing keys
==> m1: Inserting generated public key within guest...
==> m1: Configuring vagrant to connect using generated private key...
==> m1: Removing insecure key from the guest, if it's present...
==> m1: Running provisioner: shell...
m1: Running: script: Certificate Authorities
==> m1: >>> Installing Certificate Authorities
==> m1: Running provisioner: shell...
m1: Running: script: Private Docker Registry
==> m1: >>> Registering private docker registry: boot.dcos:5000
==> m1: sed: can't read /etc/sysconfig/docker: No such file or directory
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Ahh, yeah. I haven't tested that with the new docker 1.11 install. It should work if you use the previous os image with docker 1.8. But it'll need to be fixed on master.

They've made it somewhat painful, unfortunately.    The main docker.service unit file does not include the DOCKER_OPTS environment variable, so you can't just do a simple drop-in with DOCKER_OPTS setting. Instead I guess the recommendation is to override the ExecStart specification in the drop-in (or hack up the docker.service unit).

I've already done some rather hacky ExecStart mutation in the box building: https://github.com/dcos/dcos-vagrant-box/blob/master/bin/docker.sh#L27
The 1.11 docker.service file is a lot less complex than the 1.8 one. It doesn't allow configuration by multiple env vars like it used too.

Fixed: https://github.com/dcos/dcos-vagrant/commit/129b3eb08818c5915bf0ebe9c36aa280095dcfb6


Planning for Version 2

If Issue #7 is resolved as proposed (Changing the namespace of our API) it would be a breaking change and require release as version 2.0.0. That's a big step. The purpose of this issue is to decide whether to take that step and, if yes, make a general plan for it.
Initially I've made this a question for discussion. Since this library is crucial to the NUnit engine I'm inviting the @nunit/core-team to contribute their ideas in addition to the @TestCentric/gui-team. If we decide to move ahead, this will become an Epic incorporating all the individual issues needed to be resolved.
There are a number of such potential issues:

The library has not been built for two years and needs to be updated to use current tools. I'm able to build on AppVeyor using Visual Studio 2019 but not on my local system. Of course, it's possible to do small changes without building locally, but it's not a long-term solution.

Tools should be upgraded to the latest versions

The build script should be updated, possibly using TestCentric.Cake.Recipe so that more steps are automated.

All projects should to be upgraded to use the simpler SDK format and be built on VS2022.

There are currently no unit tests. That's because the history (see README.md) of this library and the fact that many (but not all) methods are unchanged from Mono.Cecil, which has its own tests. If it's going to be maintained independently in the long term, tests are needed. Fortunately, they can probably be ported from the existing engine tests.

Alternative to upgrading

Accept issue #7 as a limitation in all the runners using this package.

Solve issue #7 in some other way within each runner and (possibly) stop using this package.

I'd particularly like to hear comments from whoever is going to take over the job of leading the @nunit/engine-team, the biggest user of this library!

Did you mean to refer to issue #7 in the alternatives section, rather than #8?

Yes - corrected.

I haven't had any feedback on this issue, so I'm going ahead with the outlined approach.

Steps required to complete...

[ ] Update tools to current versions used by our other projects
[ ] #11
[ ] Update build scripts
[ ] Add tests
[ ] Resolve #7


bad blocks

2023-04-30T04:03:25Z UpdateTip: new best=00000000000000044fcb3a2461038c1b8b11a2af5a932560a3ef9ed46cf23611 height=45999 version=0x20002000 log2_work=72.24338>
2023-04-30T04:03:25Z UpdateTip: new best=000000000000000201881bad987b7afd590c04731e177d4d854f27aecee8ea5b height=46000 version=0x30c98000 log2_work=72.24425>
2023-04-30T04:05:11Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:11Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:16Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:16Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:18Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:18Z ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader:<PHONE_NUMBER>0000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad
after resyncing 6 times, the chain gets stuck on block 46000  every single time.

I am checking
On Sun, Apr 30, 2023, 9:51 AM M1neK1ng @.***> wrote:

2023-04-30T04:03:25Z UpdateTip: new
best=00000000000000044fcb3a2461038c1b8b11a2af5a932560a3ef9ed46cf23611
height=45999 version=0x20002000 log2_work=72.24338>
2023-04-30T04:03:25Z UpdateTip: new
best=000000000000000201881bad987b7afd590c04731e177d4d854f27aecee8ea5b
height=46000 version=0x30c98000 log2_work=72.24425>
2023-04-30T04:05:11Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:11Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:16Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:16Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:18Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad->
2023-04-30T04:05:18Z ERROR: AcceptBlockHeader:
Consensus::ContextualCheckBlockHeader:
00000000000000019141144b8f3a3636b3c527d94b50f40396901b94974e2a37, bad
after resyncing 6 times, the chain gets stuck on block 46000 every single
time.
—
Reply to this email directly, view it on GitHub
https://github.com/SariKuHu/Aurum/issues/3, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZRXDXTZILY5PU7UNWFONZ3XDXSGLANCNFSM6AAAAAAXQU7QHY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I should mention this is on ubuntu 20.
i managed to get aurumcoind running on linux by syncing on windows (which worked perfect) and then i bootstrap the chain in ubuntu.

Please update the version to 2.2
And today a new mandatory version will be released.
On Sun, Apr 30, 2023, 10:59 PM M1neK1ng @.***> wrote:

I should mention this is on ubuntu 20.
i managed to get aurumcoind running on linux by syncing on windows (which
worked perfect) and then i bootstrap the chain in ubuntu.
—
Reply to this email directly, view it on GitHub
https://github.com/SariKuHu/Aurum/issues/3#issuecomment-1529087797, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AZRXDXQXPIZ6BBC2TYYTOKDXD2OQ7ANCNFSM6AAAAAAXQU7QHY
.
You are receiving this because you commented.Message ID:
@.***>

ok good.
I am using the latest version 2.2.


Tor: move web endpoints to TLS/SSL

What
Login passwords transmitted without TLS/SSL over the Tor network
are a security risk if some of the nodes routing the traffic are
malicious.
Why
While the Tor network is encrypted in itself, malicious actors can run
nodes that can snoop on traffic. A password transmitted in cleartext
could allow to log in to RTL and steal your Bitcoin (if no 2FA enabled).
How
This change moves all web endpoint exposed as Tor .onion addresses
to the NGINX ports, adding TLS/SSL for additional encryption on top of
the Tor network.
The downside is that this will show a browser warning due to the
self-signed certificate.
Scope

[ ] significant change to core configuration
[ ] independent bonus guide
[x] simple bug fix

Test & maintenance
Test this pull request by adding the new services and connecting with the Tor browser. No ongoing maintenance needed.
Animated GIF (optional)

Converted to DRAFT due to some online discussions. I need to research this topic a bit more first.

Closing this PR, as it seems Tor v3 hidden services are just fine over HTTP, Potential issues arise when leaving the Tor network through exit nodes.


Websocket huge delay until it works

Hello everyone,
I have a question if someone meets this before, when I start the websocket it delays like 24hours until the private message is showed in the message board until then have to refresh the page in order to see the message sent/received

Are you using some kind of database (Doctrine ORM) for storing messages and then loading and sending all history?

Hello @vlachmilan yes

@jimiero I had a similar issue some time ago while using Doctrine with WebSocket. My problem was caused by misinterpreting Doctrine's functionality. In some methods, it caches the result and you have to then either: clear cached results, or: force Doctrine to not use cache at all.
I created a question on StackOverflow where this is discussed in more details: https://stackoverflow.com/questions/51581350/php-websocket-ratchet-doesnt-fetch-newest-data-from-doctrine
Don't know if this is your case. If not, could you share a piece of your code?


Animated Send button

This is a(n):

[ ] Update to an existing Animated Button
[ ] Any Error
[x] Proposal to the Repository
[ ] Documentation / README.md changes

Details:

this button is fully  animated . Assign this issue to me under GSSOC'23

@shraddha761 Assigned to you!
All the best 🚀

Please check #1346

Sorry for the inconvinience, but we are closing all the issues! Please open a new issue if you want to contribute anything. Also now you can create a new button from the website itself! You will get points for those too! I will add the instructions on how to create a new button soon and create an empty pr for the same to get points!


Wireframe renderer does not work for 2D data

Open Katrina
Add Wireframe Renderer
Select any 2D variable
Enable

Nothing will be drawn

This is due to clipping planes in the Z axis

If you select a 2D variable for a Wireframe Renderer, the RenderParams->_Box IsPlanar attribute is not updated and remains false. This enables the z plane clipping which can potentially not include z=0 at which 2D renderers are rendered. @clyne


chore: release  operator-chart 0.1.0

:package: Staging a new release
0.1.0 (2023-03-13)
Features

mp-spdz/operator/operator-chart/provisioner: initial commit for k8s operator based implementation (b4da582)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/carbynestack/klyshko/releases/tag/operator-chart-v0.1.0 :sunflower:


@import should trim the file name

If a line with @import contains a space after the file name the file is not found

because it searches for "../myfile.http " literally. A trim would be nice because those spaces are hard to see — and not recognizable in the error message — and it seems counterintuitive to include them if I am not missing a good reason to really include the space(s) in the lookup for the file.
If it's on purpose we should mention it in the docs https://httpyac.github.io/guide/variables.html#import-variables.

No, not intentional, but never fallen over it either. Probably because I have enabled files.trimTrailingWhitespace. I adjusted the parsing in this and a few other places.

released with v5.7.2


CBOR.encode returns incorrect value in some browser environments

Description:
CBOR.encode returns incorrect value. this in turn causes const messageHash = sha256.digest(ToBeSigned); to return the wrong hash and subsequently fail verification on valid passes.
Test matrix

local Create React App - works ✅
Stackblitz React - fails ❌
CodeSandbox React - fails ❌

Debugging
incorrect value (variable S) - CodeSandbox

Uint8Array is 1661 bytes (wrong)
correct value  (variable S) - local Create React App

Uint8Array is 314 bytes (correct)
failing code line:

reproduction link:
https://codesandbox.io/s/nzcpjs-demo-4vjgb

Cased by this https://github.com/hildjj/node-cbor/issues/164


Raise helpful error when count is used with offset or limit

Closes #133

@hanneskaeufler I don't know, do you think it would be useful down the line?

Not particularly :) But general benefits of using named exceptions apply I guess. Easier to catch, and in the tests we dont have to be as strict with the message. expect_raises Lucky::UnsupportedSql do without asserting the message is more robust against tiny changes in the message, which I like.

I get that. In that case I think Exception types for #163 would be really useful, those messages are long and testing for them is messy.
It's late for me but I'll make an Exception class for this tomorrow


fix #603

As mentioned in #603, I think it'd be best to reproduce the bug before attempting a fix.

As mentioned in #603, I think it'd be best to reproduce the bug before attempting a fix.

Ok, It's your turn.


Atom crashes if .jshintrc-file extends doesnt exist

In jshint there is an option to extend a jshintrc-file by another one http://jshint.com/docs/cli/ (look for Special options > extends). If a non-existing file is entered as the extends-parameter, jshint crashes atom (never seen this before).
Step to reproduce:

Open a new folder
Create a .jshintrc-file: ```{"extends":"../../../not/existing/at/all"}````
Create a js-file in the same folder
Open the js-file

crash

Just got this same issue, took me a while to find out why Atom was crashing.

me too.
My extended file path was fine but inside that extended file was a syntax error in that file...result => atom crash.
I used jshint command line and it reported the parse error.  Once I fixed that and jshint CL was happy no more atom crashing when opening a .js file.

Closing as this project is deprecated. 🌵


use the same paths as in the swarm repo, so that their links magically w...

...ork
Signed-off-by: Sven Dowideit<EMAIL_ADDRESS>

@fredlf @jamtur01

LGTM

LGTM


Add support for undocumented LABEL key value in addition to LABEL key=value key2=value2

We're told that docker supports an alternate, undocumented syntax for declaring image labels. This syntax supports at least one key/value pair using whitespace as the separator between the key and the value rather than an equal sign.
LABEL key value

The original report we got for semgrep is here: https://github.com/returntocorp/semgrep/issues/7211
I think it's appropriate to support this feature even though it's not documented because people are using it successfully with docker.
We need to figure out, probably by direct experimentation, whether the following is supported:

multiple space-separated pairs:

LABEL key1 value1 key2 value2

mixed-syntax pairs:

LABEL key1 value1 key2=value2

Sure enough, looks pretty widely used

And here it is in the parser

Sure enough, seems fairly widely used. Based on the parser, it looks like only LABEL key value is supported. No mutiple space-separated pairs and by extension, no mixed-syntax pairs.

If I'm reading that correctly, if the first word (space-delimited or quoted string) does not contain an =, then everything up to the first whitespace is the key and everything after the first whitespace is the value.

Nice. Here's what I tried:
# Test label assignments with these commands:
#
#   id=$(docker build . | tee log | tail -n1 | cut -f3 -d' ') && cat log && docker image inspect --format='' "$id" | grep -A 10 Labels
#

FROM debian

# All the following are valid instructions. Their effect may not be obvious.
LABEL a1=b
LABEL a2 b
LABEL a3 "b c"
LABEL "ab" c
LABEL a4 =b
LABEL a5 = b
LABEL a6 b=c
LABEL a10 "=b"
LABEL a11 b a12 c
LABEL a13 b c

# Errors:
# LABEL "a b" c
# LABEL "a7=b" "a8=c"
# LABEL a9"=b"

Output:
$ id=$(docker build . | tee log | tail -n1 | cut -f3 -d' ') && cat log && docker image inspect --format='' "$id" | grep -A 10 Labels
Sending build context to Docker daemon   2.56kB
Step 1/11 : FROM debian
 ---> 1b686a95ddbf
Step 2/11 : LABEL a1=b
 ---> Using cache
 ---> 62ba9f107457
Step 3/11 : LABEL a2 b
 ---> Using cache
 ---> c50ab8fe7d9c
Step 4/11 : LABEL a3 "b c"
 ---> Using cache
 ---> bfd73ffdbaf7
Step 5/11 : LABEL "ab" c
 ---> Using cache
 ---> e094bd167266
Step 6/11 : LABEL a4 =b
 ---> Using cache
 ---> f1aca2ae6e1a
Step 7/11 : LABEL a5 = b
 ---> Using cache
 ---> df3727083b8c
Step 8/11 : LABEL a6 b=c
 ---> Using cache
 ---> f35523f4dab8
Step 9/11 : LABEL a10 "=b"
 ---> Using cache
 ---> 5154d425bc55
Step 10/11 : LABEL a11 b a12 c
 ---> Using cache
 ---> 5d4e1bb8ac4d
Step 11/11 : LABEL a13 b c
 ---> Running in 80b219219d6a
Removing intermediate container 80b219219d6a
 ---> 913cd2ac4584
Successfully built 913cd2ac4584
            "Labels": {
                "a1": "b",
                "a10": "=b",
                "a11": "b a12 c",
                "a13": "b c",
                "a2": "b",
                "a3": "b c",
                "a4": "=b",
                "a5": "= b",
                "a6": "b=c",
                "ab": "c"
--
            "Labels": {
                "a1": "b",
                "a10": "=b",
                "a11": "b a12 c",
                "a13": "b c",
                "a2": "b",
                "a3": "b c",
                "a4": "=b",
                "a5": "= b",
                "a6": "b=c",
                "ab": "c"


[CSSimplify] Prevent invalid pack references from causing infinite loops

When matchTypesBindTypeVar detects invalid pack reference
it should reset the type to a placeholder and allow binding to go
through, otherwise, if binding comes from inference, returning
without binding would create an infinite loop because type variable
would perpetually be the best choice to attempt.

@swift-ci please test