cargo-public-api: 0.24.1 -> 0.26.0

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg build cargo-public-api

The darwin build fails and it is a regression, I imagine conditionally adding darwin.apple_sdk.frameworks.Security to buildInputs can fix the build (I don't have darwin machine right now, maybe more stuff are needed, you can follow the advice from ofborg for what is missing).

@bobby285271 like this?

@bobby285271 like this?

Let's try :sweat_drops:
@ofborg build cargo-public-api

ah, okay. Thanks for pushing that patch (and also as a --fixup commit! :tada: There are people out there that know how to do things properly :heart: :heart: :heart: Awesome!)

Looks like it works!

I'll do the rebase shortly! :tada:


Fixed dependencie randexp

This pull request close the ticket #119.

I requested a new release in https://github.com/benburkert/randexp/issues/7.


Is any way to getting uploaded photo/album URL

Is your feature request related to a problem? Please describe.
in this function .photo_upload or .album_upload is any way to getting upload url from the return?
Describe the solution you'd like
media = cl.photo_upload()
media.url
Describe alternatives you've considered
Or anyway to getting url from media_id or media_pk?
Additional context

nope

Print media.dict() and see all attributes
https://github.com/adw0rd/instagrapi/blob/master/instagrapi/types.py#L119
https://github.com/adw0rd/instagrapi/blob/master/instagrapi/types.py#L132

That is thumbnail url and video url, is there any way for getting feed url?


[DO NOT MERGE] Atomic experiments

This PR explores some possible API design variations for exposing a limited set of atomic operations in the stdlib.
We need a stable address to perform atomic operations, so we won't be able to add the obvious atomic types (e.g. a safe AtomicInt) until we introduce support for move-only types in the language. However, we should still allow people to experiment with atomics by providing a limited set of atomic operations through unsafe pointer types. To make this more practical, we should investigate ways to reliably get at the address of a stored property of an object instance.

Add FieldAccessor, a key-path based library construct to reliably get pointers to stored properties of a reference type.
final public class AtomicCounter {
  var _countStorage: Int = 0

  static let _countField = FieldAccessor(for: \Foo._countStorage)

  public func increment() -> Int {
    return Foo._countField.withUnsafeMutablePointer(in: foo) { ptr in
      _ = UnsafeAtomicInt(ptr).fetchAndAdd(1, ordering: .relaxed)
    }
}

Expose some (underscored) builtin atomic operations on UnsafeRawMutablePointer. (These all assume the pointer's alignment is suitable for such operations, and they all work with Int-sized values.) The memory ordering is baked into the method names, which makes these back-deployable to any version to the stdlib.  The struct works like a non-frozen enum with the additional restriction that representation of the cases won't ever change. (Which allows better debug performance.)
Unfortunately MemoryOrdering is a new type, so it isn't directly back-deployable; however, code reads a lot better with the levels as arguments, so it makes sense to use it in higher level APIs, which will come with availability declarations anyway.
@frozen
@available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *)
public struct MemoryOrdering {
  let _rawValue: Int

  /// Guarantees the atomicity of the specific operation on which it is applied,
  /// but imposes no ordering constraints on any other reads or writes.
  static var relaxed: MemoryOrdering { get }

  /// An acquiring load prevents subsequent load and store operations on the
  /// current thread from being reordered before it.
  static var acquiring: MemoryOrdering { get }

  /// A releasing store prevents previous load and store operations on the
  /// current thread from being reordered after it.
  static var releasing: MemoryOrdering { get }

  /// An acquiring-and-releasing operation prevents neighboring load and store
  /// operations on the current thread from being reordered across it.
  static var acquiringAndReleasing: MemoryOrdering { get }
}

_ = raw._atomicLoadWord(ordering: .acquiring)
raw._atomicStoreWord(42, ordering: .releasing)
_ = raw._atomicExchangeWord(23, ordering: .acquringAndReleasing)
_ = raw._atomicCompareExchangeWord(&expected, desired, ordering: .acquiring)
_ = raw._atomicFetchThenWrappingAddWord(1, ordering: .relaxed)
_ = raw._atomicFetchThenWrappingSubtractWord(1, ordering: .relaxed)
_ = raw._atomicFetchThenBitwiseXorWord(42, ordering: .acquiringAndReleasing)
_ = raw._atomicBitwiseAndThenFetchWord(93, ordering: .sequentiallyConsistent)
_ = raw._atomicBitwiseXorThenFetchWord(42, ordering: .acquiringAndReleasing)

Introduce a level of type safety and a tiny bit of abstraction by adding a handful of memory-unsafe atomic types. These have the same memory management concerns as an UnsafeMutablePointer; in fact they are simply wrappers around a raw pointer type.
UnsafeAtomicInt      // load, store, exchange, CAS, &+, &-, &, |, ^
UnsafeAtomicUInt     // load, store, exchange, CAS, &+, &-, &, |, ^
UnsafeAtomicUnmanaged<T>      // load, store, exchange, CAS
UnsafeAtomicUnsafeMutablePointer<T>      // load, store, exchange, CAS
UnsafeAtomicInitializableReference<T>      // atomic init, load

Other variations are possible, too.

@swift-ci test

@swift-ci test

Build failed
Swift Test Linux Platform
Git Sha - 87499bef84d05cfdf7f906eab5f482da4c9b51c0

Build failed
Swift Test OS X Platform
Git Sha - 87499bef84d05cfdf7f906eab5f482da4c9b51c0

The latest commit replaces MemoryOrdering with ordering views on the UnsafeAtomicUInt type:
let counter: UnsafeAtomicUInt = …

// TIRED
counter.increment(by: 23, ordering: .releasing)

// WIRED
counter.releasing.increment(by: 23)

This gets rid of switch statements, and reads pretty well, but it considerably increases API surface area.

While ordering views look promising, there are some major problems with them:

There is at least one useful atomic operation that needs two distinct orderings: compare and exchange with a separate ordering for the failure case. While specifying one ordering looks okay (nice, even), listing two of them looks rather weird to me:
if counter.acquiringAndReleasing.releasingOnFailure.compareExchange(
    expected: &expected,
    desired: 42
) { ... }

The API surface area for ordering views is unjustifiably large. The gyb-based implementation above generates 27 public structs with 175 public funcs. This compares unfavorably with the earlier  MemoryOrdering struct (6 structs, 53 funcs). As we add more operations, the difference will grow even further, since the views basically act as an API multiplier.
This can be partially mitigated by reintroducing MemoryOrdering as a protocol, and expressing the ordering views as generics over it. However, that approach has its own problems, especially around API design complexity. (One example: it is desirable that ordering views only provide operations that make sense for them (e.g., counter.releasing.load() shouldn't compile), but to express this in the type system, we'd need to set up a whole new protocol hierarchy.)
Additionally, making ordering views generic effectively replaces the earlier (hopefully compiler-evaluated) switch statements with (hopefully compiler-evaluated) generic dispatch -- and I'm not sure this would count as an overall improvement.

Extensibility is an issue. People should be able to define their own atomic constructs outside of the Standard Library, with APIs that match the stdlib's. Implementing ordering views is complicated and boilerplate-heavy, even when they're built around generics. Meanwhile, passing around an ordering value is easy to understand and to implement.

Things are back in motion. The last commit makes four major changes, with an eye towards getting this ready to be pitched.

First, I returned to representing memory orderings with regular arguments. However, we now have three separate ordering types based on the nature of the operation:
struct AtomicLoadOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var acquiring: AtomicLoadOrdering { get }
}
struct AtomicStoreOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var releasing: AtomicLoadOrdering { get }
}
struct AtomicUpdateOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var acquiring: AtomicLoadOrdering { get }
  static var releasing: AtomicLoadOrdering { get }
  static var acquiringAndReleasing: AtomicLoadOrdering { get }
}

This lets us enforce that each operation can only be called with orderings that it can support, which was one of the two major advantages to ordering views. (The other advantage was not relying on the optimizer's constant folding to get rid of the switch statements in the implementation. Unfortunately that's back now.)

Second, the four high-level atomic structures now include not only an unsafe pointer to the memory location that stores their value, but also an anchor reference to an object that keeps it alive. This makes them entirely safe, so they lose the Unsafe prefix and we are left with AtomicInt, AtomicUInt, AtomicUnsafeMutablePointer and AtomicUnmanaged.
Note that using these names now may turn out to be unfortunate when and if we get non-copyable types, which would potentially provide a better implementation.

Third, we introduced an Anchored protocol for things that represent values through their address, as well as an associated Anchoring property wrapper:
protocol Anchored {
  associatedtype Value

  static var defaultInitialValue: Value { get }
  init(at address: UnsafeMutablePointer<Value>, in anchor: AnyObject)
}

@propertyWrapper
struct Anchoring<Thing: Anchored> {
  var _storage: Thing.Value

  init() {
    self._storage = Thing.defaultInitialValue
  }

  init(_ value: Thing.Value) {
    self._storage = value
  }

  static subscript<Anchor: AnyObject>(
    _enclosingInstance anchor: Anchor,
    wrapped wrappedKeyPath: ReferenceWritableKeyPath<Anchor, Thing>,
    storage storageKeyPath: ReferenceWritableKeyPath<Anchor, Self>
  ) -> Thing {
    _read {
      let keyPath = storageKeyPath.appending(path: \._storage)
      let p = keyPath._directAddress(in: anchor)!
      yield Thing(at: p, in: anchor)
    }
  }
}

struct AtomicInt: Anchored {...}
struct AtomicUInt: Anchored {...}
struct AtomicUnsafeMutablePointer<Pointee>: Anchored {...}
struct AtomicUnmanaged<Instance: AnyObject>: Anchored {...}

Anchored isn't specific to atomics -- it can be implemented by anything that needs to have a stable address:
struct UnfairLock: Anchored {
  struct Value { var lock: os_unfair_lock_s }

  let _anchor: AnyObject
  let _ptr: UnsafeMutablePointer<Value>

  var defaultInitialValue: Value { Value(lock: .init()) }
  init(at address: UnsafeMutablePointer<Value>, in anchor: AnyObject) {
    _anchor = anchor
    _ptr = address
  }

  func lock() { os_unfair_lock_lock(_ptr) }
  func unlock() { os_unfair_lock_unlock(_ptr) }
}

The point of all this is that use sites get a lot more pleasant to read and write:
class Foo {
  @Anchoring(42) var counter: AtomicInt
  @Anchoring var lock: UnfairLock
}

func doSomething(foo: Foo) {
  foo.counter.wrappingIncrement()
  foo.lock.lock()
  defer { foo.lock.unlock() }
  print("I'm holding the lock right now")
}

Unfortunately, currently this has terrible performance, and it needs some compiler work to make it practical.

Constructing the key path to the underlying storage variable and extracting its address needs to be a compile-time operation. (We could previously hide the cost of doing this at runtime in FieldAccessor's initializer; Anchoring currently does it on every single access.)
New with Anchored: storing a new reference to the anchor class in a temporary anchored value must not result in any additional retain/release traffic, unless the temporary is copied out to its own thing. The _read accessor above is intended to make it easier to do this.)
The Anchoring wrapper has some serious limitations:

It uses the non-public init(_enclosingInstance:,wrapped:,storage:) feature.
The enclosing type must be a class, but this is only enforced with a runtime trap. Trying to use it outside of a class needs to be diagnosed as a compile-time error.
We should be statically requiring the storage key path to point to a stored (as opposed to computed) property. (Although currently I don't think this requirement can be violated when Anchored is used as a wrapper.)

Finally, I added some convenience operations to increment/decrement atomic integers.
extension Atomic[U]Int {
  func wrappingIncrement(
    by delta: [U]Int = 1,
    ordering: AtomicUpdateOrdering = .acquiringAndReleasing
  ) {...}

  func wrappingDecrement(
    by delta: [U]Int = 1,
    ordering: AtomicUpdateOrdering = .acquiringAndReleasing
  ) {...}
}

The intent here is that counter.wrappingIncrement() will be somewhat easier to understand than counter.fetchThenWrappingAdd(1).

@lorentey Hi, have you considered supporting atomic floats/doubles (<=64 bits) as well? They could be implemented similar to java's, where double is treated like a long for compareAndExchange and all other operations implemented using a loop and a CAS.

Can one of the admins verify this patch?

@artemredkin Sorry about the belated reply! Atomic floats aren't on my to-do list -- do you have a good usecase?
My instinct is that those wouldn't belong in the stdlib, rather they should be defined in the module that needs them. I.e., AtomicDouble can just be a custom wrapper around AtomicUInt (on 64-bit platforms at least) and use bitPattern conversions.
It would be worth discussing this when this feature gets pitched on the forums.

struct AtomicLoadOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var acquiring: AtomicLoadOrdering { get }
}
struct AtomicStoreOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var releasing: AtomicLoadOrdering { get }
}
struct AtomicUpdateOrdering {
  static var relaxed: AtomicLoadOrdering { get }
  static var acquiring: AtomicLoadOrdering { get }
  static var releasing: AtomicLoadOrdering { get }
  static var acquiringAndReleasing: AtomicLoadOrdering { get }
}

This isn't sufficient, unless AcquiringAndReleasing is the C11's seq_cst.
Typically, famously on Intel, store-release and store-seq_cst aren't the same (the former one is a plain store, the latter a lock; xchg). You need SequentiallyConsistent for all of these.
Second, please do not repeat the mistake of the C11 atomics interface, having an in-out parameter is terribly gross and painful to use, internally at Apple we tend to use for cmpxchg a variant that does:
bool cas(type_t *pointer, type_t expected_value, type_t new_value);
bool casv(type_t  *pointer, type_t expected_value, type_t new_value, type_t *previous_value);

which in swift could be two overloads: a large amount of people don't care about the reload, and the ones who do would rather be able to use a different variable for the reload.

@MadCoder This is terrific feedback, thanks. Reverting the removal of .sequentiallyConsistent is easy enough; it's nice to see confirmation that there are real life use cases for it.
I'll try replacing compareExchange with the following two methods:
func compareAndStore(expected: Int, desired: Int, ordering: AtomicUpdateOrdering) -> Bool
func compareAndExchange(expected: Int, desired: Int, ordering: AtomicUpdateOrdering) -> (swapped: Bool, original: Int)

(The names aren't great; I expect we'll have ample opportunity to come up with a better naming scheme on the forums.)
Interestingly, I originally went with the inout version specifically because it felt less annoying in toy examples, despite the obvious inconsistency with func exchange. But now I'd argue the inout variant actually reads much worse:
extension UnsafeAtomicInt {
  // BEFORE
  func myIncrement(ordering: AtomicUpdateOrdering) {
    var expected = load(ordering: .relaxed)
    while !compareExchange(
      expected: &expected,
      desired: expected + 1,
      ordering: ordering) { }
  }

  // AFTER
  func myIncrement(ordering: AtomicUpdateOrdering) {
    var done = false
    var value = load(ordering: .relaxed)
    while !done {
      (done, value) = compareAndExchange(
        expected: value,
        desired: value + 1,
        ordering: ordering)
    }
  }
}

I'd nitpick the label for the returned Bool: why name it "swapped" when the name of the operation is "exchange"?

I'm unsure of the appropriateness of having the 'load' operation on the Unmanaged atomic wrapper. This would lead to people reproducing the pre-Swift-3 weak reference bug where one thread lowers the reference count to zero while another thread is trying to increment it. Anything with a refcount of 1 shouldn't be interacted with from more than one thread at a time, and the way to encourage that with an atomic unmanaged is to restrict the operations to exchanges.

@glessard The reason I don't think this is as big as a problem as it first appears is that extracting a strong reference from an UnsafeAtomicUnmanaged requires two very explicit steps:
let _ref: UnsafeAtomicUnmanaged<Foo> = ...
let ref = _ref.load(ordering: .acquiring).takeUnretainedValue()

To me it seems obvious that the two steps aren't going to happen in a single atomic transaction.
Now of course, the UnsafeAtomicUnmanaged construct does not help at all with the problem of memory reclamation, and that is a major, major limitation. (UnsafeAtomicMutablePointer has the same issue.) These two types have essentially no room for any additional bits to implement inline refcounts or version stamps. (So they provide no ABA mitigation, either.)
My view is that the initial wave of atomics will be mostly about establishing the basics -- memory orderings and a naming scheme. A subsequent second wave will flesh out the feature by introducing actually useful atomic types (stamped pointers, atomic strong references, etc.) built around double-wide atomics.
The reason I think we need a delay here is that I expect the double-wide atomic types won't maintain a direct match between the logical value held by the atomic struct (say, a strong reference) and the in-memory representation (say, some encoding of a (reference, inline refcount, stamp) tuple), so trying to model them with unsafe pointer APIs would be unnecessarily complicated. I'd much rather wait for move-only types -- I expect those will provide a more appropriate model.

(Not to mention that it isn't clear to me exactly what set of double-wide atomic types we would need to add. I also don't know if a universal atomic strong reference would scale well enough to be more practical than a regular strong reference + an unfair lock.)

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)

Closing -- these experiments have culminated in the release of the Atomics package, at least for now.


Adding microlensing propagation effects

Just opening this to discuss adding some features that I developed for my time delays software (https://arxiv.org/abs/1902.01260). The easiest is a microlensing propagation effect, which would entail adding optional phase dependence to existing propagation effect functions. I've also enabling light curve fitting inside of SNCosmo with the parameterized light curve model from Bazin et al. 2009, which could be added as a fitting option as well.

The microlensing propagation effect could be quite interesting! You seem to be suggesting adding something along the lines of a propagation effect. Is the idea that these should use a random seed per SN to obtain different microlensing for different SN, or are you suggesting adding parameters to describe these?

Yes I've already made a microlensing propagation effect that works within the SNCosmo framework, but requires a small change that the existing (dust) effects have a phase argument that isn't used, so that the _flux function in the Model class can have a phase factor because the microlensing effect needs to be time-dependent.
What I have already is just an effect defined by a curve in time+flux for achromatic, and time+wavelength+flux for chromatic microlensing. Then a user could just define their own microlensing curve for either simulation or fitting purposes.
If you want to be able to generate these inside of SNCosmo, you could either define them using random splines (one option I have) or by actually convolving a SN expanding photosphere with a microcaustic generated by microlens. Actually simulating these curves definitely adds a degree of complication in terms of including it in SNCosmo though, the simple first thing to do is just have the effect so that a user can define a curve and include it in a model.
I toyed around with adding parameters to fit or generate these curves, but couldn't figure out a reasonable way of doing this because the effect is so stochastic. Open to ideas though!


unable to open document using PDFsharp

serachbalePDf.pdf
unable to open the attached document. It is throwing below error,
Unexpected token 'n' in PDF stream. The file may be corrupted. If you think this is a bug in PDFsharp, please send us your PDF file.
We tried to debug the issue using PDFSharp code and below are our analysis,
There were two Xref table and trailers in the PDF file. The byte position mentioned in the Last StartXref wan not pointing to the beginning of Xrefy table. it was incorrect and we fixed by removing the invalid Xref entry.
Then PDF sharp able to read correct Xref table as the position mentioned in another StartXref  was correct
The first entry in Xref table refers to total number of entries in Xref table. Each entry will be looped and the entry point will be validated.
Entries in each Xref refers to indirect object start position. Till 8th entry the start position was correct. When evaluating 9th entry the PDFSharp looks for 9 th indirect object. Indirect object can be positioned anywhere in the PDF stream.
There were no entry for object 9 - 17 in the PDF stream and we received invalid entry in XRef table error as there were no indirect object found. There were duplicate Indirect Object in the file.
We fixed by skipping this validation PDF sharp code, now we are facing error in reading trailer record stream
Attached the PDF file which has corrupt Xref table issue.

our software is expected to work with any PDF source as you can guess...

Sure. I opened this PDF with Adobe Reader and then selected File / Save as. Adobe Reader reported an error. I assume the file is corrupt and PDFsharp does not attempt to open any corrupt file.

unable to open the attached document. It is throwing below error,
Unexpected token 'n' in PDF stream. The file may be corrupted. If you think this is a bug in PDFsharp, please send us your PDF file.

I also get this error. I do not get an error when I open the file with Adobe Reader, then use File / Save as and open the resulting file with PDFsharp. So I assume the file is corrupt and PDFsharp will not be modified to handle this corruption in the near future.


[Feature] - Change winget Package Identifier

In the Winget repository, it is possible to nest folders to create a cleaner structure for searching and finding packages. Currently, the Package identifier of Microsoft.AzureCli is being used.  It would be easier for users to find azure tools if the Package identifier were changed to Microsoft.Azure.Cli

@bebound for awareness

This breaking change. If there is no big issue, I'd like to keep using the current one.
What does this mean?  It would be easier for users to find azure tools if the Package identifier were changed to Microsoft.Azure.Cli winget search azure/azurecli works.

This a breaking change. If there is no big issue, I'd like to keep using the current one.

Technically, it is no big issue. I don't see it as a breaking change for upgrades, since the new Identifier would be picked up automatically, but I do understand that some users may have hardcoded the package identifier into scripts or documentation.

What does this mean?  It would be easier for users to find azure tools if the Package identifier were changed to Microsoft.Azure.Cli winget search azure/azurecli works.

There are users who browse the winget-pkgs repository or query against it using the GitHub API in order to find packages. In the folder "Microsoft" there are more than 80 folders. Changing the identifier would move it down one level into the "Microsoft/Azure" folder, which is a better logical grouping for it.

Thank for the explanation. I can see you point, but it's not strong enough to change the identifier.


Purchase by vault with cvd enabled

Hi!
When purchasing with vault, it's look like cvd is looked up by this API but it should not.

Hey @math3os, sorry this took so long, I never got a notification for this repo. Can you explain this a bit further? I haven’t used moneris in years, so I’m curious what the actual problem is here

When we use vault, there is no CVD to provide but moneris-api still lookup for the inexistent value then return an error. I did a PR for this : #7 .

@math3os Seems to me when reading the documentation that you can indeed purchase through the vault and use CVD at the same time. Would the solution you're looking for here actually be to construct the moneris class with cvd off?
use CraigPaul\Moneris\Moneris;

...

$id = 'store1';
$token = 'yesguy';

// optional
$params = [
  'environment' => Moneris::ENV_TESTING, // default: Moneris::ENV_LIVE
  'avs' => true, // default: false
  'cvd' => true, // default: false
];

$gateway = Moneris::create($id, $token, $params);

This example from the README shows overriding the initial CVD option, perhaps that might just be the source of the problem?


Error when trying MicroService.start() with version 0.6.^ On Android in flutter.

LiquidCore : 0.6.0, 0.6.2
Android targetSDkVersion, compileSdkVersion 28
Flutter version : 1.6.3 ~ 1.9.1 (I tested all version..)
Environment : Galaxy Note FE. Pi version
I'm do not using a flutter liquidCore library.
I have been used LiquidCore Android library in flutter.
I checked that It ran on Android with  LiquidCore Android library.
But It occurred a problem within Android in Flutter with Using same LiquidCore Android library
I am so confused.  Is this a crash between flutter and liquidCore?
Here is error and Android kotlin source in flutter.
     val readyListener = EventListener { service, event, payload ->
          service.emit("ping")
      }

      val pongListener = MicroService.EventListener { service, event, payload ->
        // NOTE: This event is typically called inside of the micro service's thread, not
        // the main UI thread.  To update the UI, run this on the main thread.
        Handler(Looper.getMainLooper()).post {
          try {
          } catch (e: Throwable) {
            e.printStackTrace()
          }
        }
      }

      // Our start listener will set up our event listeners once the micro service Node.js
      // environment is set up
      val startListener = MicroService.ServiceStartListener { service  ->
        service.addEventListener("ready", readyListener)
        service.addEventListener("pong", pongListener)
      }

      val uri = URI.create("android.resource://io.gemore.channel_test/raw/liquidcore_sample")
      service = MicroService(this@MainActivity, uri, startListener)
      service?.start()

(liquidcore_sample.js file is quite simple
console.log('~~~')
setInterval(function() {}, 5000)
)
It was occurred after service?.start() invoked
E/libc++abi(20669): terminating
F/libc    (20669): Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 20734 (nodejs), pid 20669 (re.channel_test)

Build fingerprint: 'samsung/gracerltektt/gracerltektt:9/PPR1.180610.011/N935KKKU4CSI1:user/release-keys'
Revision: '17'
ABI: 'arm64'
pid: 20669, tid: 20734, name: nodejs  >>> io.gemore.channel_test <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'terminating'
x0<PHONE_NUMBER>000000  x1<PHONE_NUMBER>0050fe  x2<PHONE_NUMBER>000006  x3<PHONE_NUMBER>000008
x4  fefeff75ff666d68  x5  fefeff75ff666d68  x6  fefeff75ff666d68  x7  7f7f7f7f7f7f7f7f
x8<PHONE_NUMBER>000083  x9  00000077f407b888  x10 fffffff87ffffbdf  x11<PHONE_NUMBER>000001
x12<PHONE_NUMBER>000018  x13 000000005dd5065d  x14 000d1cdc0f42d228  x15 00009cca122580ce
x16 00000077f40b2290  x17 00000077f3ff1920  x18<PHONE_NUMBER>000000  x19<PHONE_NUMBER>0050bd
x20<PHONE_NUMBER>0050fe  x21<PHONE_NUMBER>000083  x22 ffffff80ffffffc8  x23 000000773ccbc290
x24 000000773ccbc170  x25 000000773ccbc1b0  x26 00000077f40bb000  x27<PHONE_NUMBER>000018
x28<PHONE_NUMBER>00006c  x29 000000773ccbc0e0
sp  000000773ccbc0a0  lr  00000077f3fe4d68  pc  00000077f3fe4d94
backtrace:
#00 pc<PHONE_NUMBER>021d94  /system/lib64/libc.so (abort+124)
#01 pc<PHONE_NUMBER>e97de0  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so
#02 pc<PHONE_NUMBER>e97e60  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so
#03 pc<PHONE_NUMBER>e94d24  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so
#04 pc<PHONE_NUMBER>e94cd0  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so (std::terminate()+72)
#05 pc<PHONE_NUMBER>e92288  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so (std::__ndk1::thread::~thread()+20)
#06 pc<PHONE_NUMBER>087d44  /system/lib64/libc.so (__cxa_finalize+196)
#07 pc<PHONE_NUMBER>01c698  /system/lib64/libc.so (exit+24)
#08 pc<PHONE_NUMBER>0809d4  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libliquidcore.so (FatalException(v8::Isolate*, v8::Localv8::Value, v8::Localv8::Message)+356)
#09 pc<PHONE_NUMBER>bbd420  /data/app/io.gemore.channel_test-p_OBwFOxmUZ1MywtAn2d0Q==/lib/arm64/libnode.so (v8::internal::MessageHandler::ReportMessageNoExceptions(v8::internal::Isolate*, v8::internal::MessageLocation const*, v8::internal::Handlev8::internal::Object, v8::Localv8::Value)+280)

I don't know why the problem occurs with build using gradle through github.
It doesn't work.(above error)
but I downloaded liquidcore source and build.. making .aar
and added dependency with .aar which I was builded.
It's working!!
I don't know if it's problem a gradle or flutter whatever .


Adding gps to dep

Moving a copy of gps at https://github.com/sdboyer/gps/commit/da7569e414959d639654919aaf67259c3add73f4 to github.com/golang/dep/gps
Git history preservation
All git history from gps at https://github.com/sdboyer/gps/commit/da7569e414959d639654919aaf67259c3add73f4 should be preserved.
With the exception of the following sed replacement in the git commit logs:
sed -e "s/ #/ sdboyer\/gps#/"
# git filter-branch -f --msg-filter 'sed -e "s/ #/ sdboyer\/gps#/"' 51d49055235c7e635439ac69c4650556714de37f..HEAD

Global Substitution

https://github.com/kris-nova/dep/commit/122ade36c3fde81a414ce919dc1a750293fe2f98
sed/g the following strings (somewhat blindly)

github.com/sdboyer/gps -> github.com/golang/go/gps
github.com/sdboyer/gps/internal -> github.com/golang/dep/gps/internal
github.com/sdboyer/gps/pkgtree -> github.com/golang/dep/gps/pkgtree

dep is now compiling with the gps no longer in vendor

Remove vendor/github.com/sdboyer/gps

https://github.com/kris-nova/dep/commit/9c8c70cdf9a24c3a1e6bfa0cf02ca5c9d5f40a48

Changes from code review here

https://github.com/kris-nova/dep/commit/94ba649df8c04f9bd112e16884cd8b141526bce8

Should we also remove the follow?

/gps/LICENSE
/gps/CODE_OF_CONDUCT.md
/gps/.gitignore

@sdboyer
We are getting some race conditions:

WARNING: DATA RACE
Write at 0x00c4201bbee0 by goroutine 16:
  os/exec.(*Cmd).Start()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:353 +0x6e6
  os/exec.(*Cmd).Run()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:276 +0x3c
  github.com/golang/dep/gps.(*monitoredCmd).run.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x50

Previous read at 0x00c4201bbee0 by goroutine 15:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:65 +0x452
  github.com/golang/dep/gps.TestMonitoredCmd.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd_test.go:63 +0x5e

Goroutine 16 (running) created at:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x13a
  github.com/golang/dep/gps.TestMonitoredCmd.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd_test.go:63 +0x5e

Goroutine 15 (finished) created at:
  github.com/golang/dep/gps.TestMonitoredCmd()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd_test.go:64 +0x837
  testing.tRunner()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/testing/testing.go:610 +0xc9
==================
--- FAIL: TestDeduceProjectRoot (0.00s)
	manager_test.go:448: Wrong project root was deduced;
			(GOT) github.com/golang/dep
			(WNT) github.com/golang/dep/gps
	manager_test.go:458: Wrong project root was deduced;
			(GOT) github.com/golang/dep
			(WNT) github.com/golang/dep/gps
	manager_test.go:470: Wrong project root was deduced;
			(GOT) github.com/golang/dep
			(WNT) github.com/golang/dep/gps
==================
WARNING: DATA RACE
Read at 0x00c4203c8620 by goroutine 566:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:56 +0x263
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6

Previous write at 0x00c4203c8620 by goroutine 543:
  os/exec.(*Cmd).Start()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:353 +0x6e6
  os/exec.(*Cmd).Run()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:276 +0x3c
  github.com/golang/dep/gps.(*monitoredCmd).run.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x50

Goroutine 566 (running) created at:
  github.com/golang/dep/gps.(*sourceCoordinator).getSourceGatewayFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:88 +0x4e3
  github.com/golang/dep/gps.(*SourceMgr).SyncSourceFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:399 +0x167
  github.com/golang/dep/gps.TestUnreachableSource()
      /home/travis/gopath/src/github.com/golang/dep/gps/manager_test.go:790 +0xe8
  testing.tRunner()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/testing/testing.go:610 +0xc9

Goroutine 543 (running) created at:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x13a
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6
==================
==================
WARNING: DATA RACE
Read at 0x00c4204b38f0 by goroutine 566:
  os.(*Process).signal()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_unix.go:56 +0x5a
  os.(*Process).Signal()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:55 +0x4c
  os.(*Process).kill()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_posix.go:53 +0x64
  os.(*Process).Kill()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:40 +0x38
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:57 +0x336
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6

Previous write at 0x00c4204b38f0 by goroutine 543:
  os.newProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec.go:23 +0x5d
  os.startProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_posix.go:49 +0x515
  os.StartProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:28 +0x7a
  os/exec.(*Cmd).Start()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:358 +0x6ab
  os/exec.(*Cmd).Run()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:276 +0x3c
  github.com/golang/dep/gps.(*monitoredCmd).run.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x50

Goroutine 566 (running) created at:
  github.com/golang/dep/gps.(*sourceCoordinator).getSourceGatewayFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:88 +0x4e3
  github.com/golang/dep/gps.(*SourceMgr).SyncSourceFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:399 +0x167
  github.com/golang/dep/gps.TestUnreachableSource()
      /home/travis/gopath/src/github.com/golang/dep/gps/manager_test.go:790 +0xe8
  testing.tRunner()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/testing/testing.go:610 +0xc9

Goroutine 543 (running) created at:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x13a
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6
==================
==================
WARNING: DATA RACE
Read at 0x00c4204b3900 by goroutine 566:
  sync/atomic.LoadInt32()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/runtime/race_amd64.s:206 +0xb
  os.(*Process).done()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec.go:33 +0x3e
  os.(*Process).signal()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_unix.go:64 +0x1fa
  os.(*Process).Signal()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:55 +0x4c
  os.(*Process).kill()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_posix.go:53 +0x64
  os.(*Process).Kill()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:40 +0x38
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:57 +0x336
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6

Previous write at 0x00c4204b3900 by goroutine 543:
  os.newProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec.go:23 +0x5d
  os.startProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec_posix.go:49 +0x515
  os.StartProcess()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/doc.go:28 +0x7a
  os/exec.(*Cmd).Start()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:358 +0x6ab
  os/exec.(*Cmd).Run()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/os/exec/exec.go:276 +0x3c
  github.com/golang/dep/gps.(*monitoredCmd).run.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x50

Goroutine 566 (running) created at:
  github.com/golang/dep/gps.(*sourceCoordinator).getSourceGatewayFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:88 +0x4e3
  github.com/golang/dep/gps.(*SourceMgr).SyncSourceFor()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:399 +0x167
  github.com/golang/dep/gps.TestUnreachableSource()
      /home/travis/gopath/src/github.com/golang/dep/gps/manager_test.go:790 +0xe8
  testing.tRunner()
      /home/travis/.gimme/versions/go1.7.5.linux.amd64/src/testing/testing.go:610 +0xc9

Goroutine 543 (running) created at:
  github.com/golang/dep/gps.(*monitoredCmd).run()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:47 +0x13a
  github.com/golang/dep/gps.(*monitoredCmd).combinedOutput()
      /home/travis/gopath/src/github.com/golang/dep/gps/cmd.go:84 +0x6a
  github.com/golang/dep/gps.(*gitSource).listVersions()
      /home/travis/gopath/src/github.com/golang/dep/gps/vcs_source.go:166 +0x66f
  github.com/golang/dep/gps.maybeGitSource.try.func1()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:97 +0x8b
  github.com/golang/dep/gps.(*supervisor).do()
      /home/travis/gopath/src/github.com/golang/dep/gps/source_manager.go:485 +0xfb
  github.com/golang/dep/gps.maybeGitSource.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:101 +0x417
  github.com/golang/dep/gps.maybeSources.try()
      /home/travis/gopath/src/github.com/golang/dep/gps/maybe_source.go:31 +0x112
  github.com/golang/dep/gps.(*maybeSources).try()
      <autogenerated>:196 +0xfb
  github.com/golang/dep/gps.(*sourceGateway).require()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:436 +0x3a8
  github.com/golang/dep/gps.(*sourceGateway).sourceURL()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:404 +0xc2
  github.com/golang/dep/gps.(*sourceCoordinator).setUpSourceGateway()
      /home/travis/gopath/src/github.com/golang/dep/gps/source.go:161 +0xcd6
==================
FAIL
FAIL	github.com/golang/dep/gps	89.719s

This looks like a few races in gps, wondering if we need to try to fix them in this PR, or if that is a symptom of the dep testing suite running go test -race whereas we didn't do that before?
Thoughts?

We can remove .gitignore. I'd strongly prefer that we move the code of conduct up to the top level of the repo rather than get rid of it, though that decision has...well, implications. And I guess we remove the LICENSE file? That doesn't seem quite right, though - need to consult the lawyers again, maybe :/
As for the test failures...well, that's dispiriting. I thought I'd fixed all the race conditions in gps. And the literally hundreds of times that I, and CircleCI, ran these very same tests, agreed. I'm really not sure what's suddenly different now.
On the plus side, all of these races seem to be related to monitoredCmd. So, yes, I think it's probably worth throwing a bit of effort at fixing them.

The command "test -z "$(gofmt -s -l . 2>&1 | grep -v vendor/ | tee /dev/stderr)"" exited with 1.

We'll also need to modify the gofmt test to ignore testdata/ dirs as well as vendor/.

The command "staticcheck -ignore='github.com/golang/dep/context.go:SA1019 github.com/golang/dep/cmd/dep/init.go:SA1019' $PKGS" exited with 1.

These'll need fixing, too. Just looking at the error messages, it seems like each fix should be trivial.

The command "find . -path ./vendor -prune -o -type f -name "*.go" -printf '%P

...yeah, need to figure out about if we have to put in the new license header on all of gps' files, too.

I think we should be ready to proceed here now.

WOOOOOOOOOOOOOO 🎉 🎉 🎉 🎉


SizedQueue not specified

SizedQueue behaves very much like Queue.  Shared behavior like that seems to be generally specified in a shared/queue folder where the individual objects are specified in library/queue and library/sizedqueue respectively.  The individual object specifications then use it_behaves_like for the shared behavior.
Is this the way to specify two very similar objects like this or is there another way?
This is how I plan to proceed with specifying SizedQueue unless a better way is shown.

Maybe they should be in library/thread/queue and library/thread/sizedqueue (and share in library/thread/shared) since
ruby -rthread -e 'p Queue' # Thread::Queue

(they are not part of core, rubygems loads the thread library)
mkspec (from mspec) can be used to generate the initial files:
../mspec/bin/mkspec -rthread -c Thread::Queue --base library
../mspec/bin/mkspec -rthread -c Thread::SizedQueue --base library

Using it_behaves_like is indeed the recommended way AFAIK to share specs. Sharing this way tends to make the specs harder to read and they often need to use more metaprogramming like send, but in this case it's a perfectly good use case.
And then specify in each file potential divergences from that.
(I think sharing for aliases is not ideal, but that's another discussion)

Thanks for the feedback.  :smile:
It looks like Queue and SizedQueue moved to core in 2.2.
http://ruby-doc.org/core-2.2.1/Queue.html
http://ruby-doc.org/core-2.2.1/Queue.html
I'm not sure what to do when things move around like that between versions.  Which ever place we put them, core or library, it will be wrong in some versions of Ruby.  Maybe they should be moved to the place that they belong is the most recent version of Ruby which would be core in this case.  Do you think we should move them or leave them alone?

I think they are not in core, this is probably a bug of rdoc or ruby-doc.org.
There is some ongoing discussion about it though: https://bugs.ruby-lang.org/issues/8919 but it seems it is not yet done.
Same goes for ConditionVariable by the way, which I think might be worth specifying (its behavior is rather surprising compared to typical implementations in that it allows to be associated with multiple mutexes).
$ ruby -v --disable-gem -e 'p Queue'
ruby 2.3.0dev (2015-03-21 trunk 50043) [x86_64-linux]
-e:1:in `<main>': uninitialized constant Queue (NameError)

$ ruby -v -e 'p Queue; puts $"'
Thread::Queue
...
/opt/rubies/ruby-trunk/lib/ruby/2.3.0/x86_64-linux/thread.so
...

So rubygems requires 'thread', in lib/rubygems.rb.
They get aliased in Object, so Queue = Thread::Queue but this is a separate concern.
So, definitely part of library/. If it changes we'll eventually move them.

Thanks for clarifying all that!!  I will put them under library/thread.

Completed by #59.


Snow starting in x hours

Is there a way to create a sensor for snow starting in a certain number of hours?
Edit: I see “rain 1 hour”. I need something like that, just “snow 2 hours”

Follow up: Looked through the code and it looks like you’re calling either snow or rain in 1 hour “rain 1 hour”. Maybe we could make those separate?

Hi, that sensor might be possible but sadly I don't have time for further development at the moment.
The "rain 1 hour" sensor is the amount of precipitation (rain/snow) during the last hour instead of a forecast.

To do this, I could look at the hourly forecast. Occupancy sensor for "Precipitation in X hours". Something like that?


Fix typo in docs (filenameWithoutExtension)

Description
The docs refer to task.file.filename.filenameWithoutExtension, which is undefined. The correct path is task.file.filenameWithoutExtension.
Motivation and Context
n/a
How has this been tested?
Locally.
Screenshots (if appropriate)
Types of changes

Changes visible to users:

[ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[ ] New feature (prefix: feat - non-breaking change which adds functionality)
[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
[x] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

[x] My code follows the code style of this project and passes yarn run lint.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Good spot - and thank you very much for the fix...
This is interesting to me on many levels...
tl;dr
I will accept the change - thanks!
The text is definitely a typo - but surprisingly it does actually behave as documented...
After I've merged the PR, I'll go ahead and update the bit of the Tasks automated tests that generates this text, to prevent the error coming back again next time I update the docs...
1. The documentation is machine-generated from the automated tests..
This is one of a lot of pieces in the Tasks documentation that is machine-generated and automatically tested.
Your correction is inside these lines - see the include: on the first line, and the endInclude on the last..
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/dacaf099d00431f812c4a61799d99abe503e8025/docs/Queries/Grouping.md?plain=1#L833-L847
And here is the bit of the source-code that contains the data that generates the text that later gets inserted in the docs....
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/dacaf099d00431f812c4a61799d99abe503e8025/tests/Scripting/ScriptingReference/CustomGrouping/CustomGroupingExamples.test.ts#L266-L276
2. The output of the tests looks good...
That test, run on a selection of tasks, generates this output:
https://github.com/obsidian-tasks-group/obsidian-tasks/blob/dacaf099d00431f812c4a61799d99abe503e8025/tests/Scripting/ScriptingReference/CustomGrouping/CustomGroupingExamples.test.file_properties_task.file.filename_results.approved.txt#L1-L23
So yes you're definitely correct that the text is not what was intended...
And also, looking at the files generated by running that test, is shows that the code does actually work (surprisingly...)
3. Oh the irony...
I've given a few conference lightning talks on the technique I'm using...

Code Samples that Actually Compile
Code Samples That Compile Even More Easily - Clare Macrae - CppCon 2020

So yes, the tests work and the sample in the documentation works - but it is also still not 'correct'!

Irony on irony....

And also, looking at the files generated by running that test, is shows that the code does actually work (surprisingly...)

Having updated the source code I see the changed output...
I was looking past all the undefined... The output was clearly wrong.
I will now need to search through the rest of the test output and make sure there are no more undefined that crept through!
😊


i18n(ar): Translate Sitemap integration

Description (required)
I translated Sitemap integration to Arabic.
Related issues & labels (optional)

Suggested label: i18n

First-time contributor to Astro Docs?

@tarik

Before:

After:

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any broken links you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Vercel 🥳

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File
Note
Locale

src/content/docs/ar/guides/integrations-guide/sitemap.mdx
Localization added, will be marked as complete.
ar

src/i18n/ar/ui.ts
Localization changed, will be marked as complete.
ar

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

Hey @wpplumber, this PR looks good, but since so many commits got pulled in (and I seem to not be able to update branch here) I believe the easiest way would be to copy the translation here and open another PR with only it, can you do that?

Hey @wpplumber, this PR looks good, but since so many commits got pulled in (and I seem to not be able to update branch here) I believe the easiest way would be to copy the translation here and open another PR with only it, can you do that?

Yes, @yanthomasdev.
Done.


Add ping pong and pingtimeout for ws connection

Updated JS client generation to use union types so it's no longer required to wrap within another type.


Add screenshot to testresult for XML report

[L143-L145] I have added the AddTestAttachment method in order to include taken screenshot to the report and, therefore, the screenshot will be available in XML report, generated at the end of execution. This is interesting when parsing XML to generate, for example, an HTML report.
[L278-L286] I have extracted from TakeScreenShot the generation of the full path so that I can use it in previously explained code.

Could anyone provide some input on this? If it is not desire, please comment and I will close PR

Hi @tomersalem @Roemer , could you please review this? If it is not a desired feature, let me know and I will close it. Thanks a lot

Thanks a lot, @tomersalem ! I have just updated the branch with master. I may need another review for this again, sorry.

@tomersalem It is failing some UI Test, need to check why. I hope this afternoon could be solved

@tomersalem It was failing due to ```{TestContext.CurrentContext.Test.Name}````as it contained some illegal characters. Now it's being sanitize to avoid that

Thank you for your contribution. The change has been merged.


Automated cherry pick of #8344: feat(notify): support webhook contact type

Cherry pick of #8344 on release/3.4.
#8344: feat(notify): support webhook contact type

Codecov Report

Merging #8345 into release/3.4 will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@              Coverage Diff               @@
##           release/3.4   #8345      +/-   ##
==============================================
- Coverage         6.22%   6.17%   -0.06%
==============================================
  Files              759     150     -609
  Lines           117145   21083   -96062
==============================================
- Hits              7289    1301    -5988
+ Misses          109197   19633   -89564
+ Partials           659     149     -510

Flag
Coverage Δ

#aFlag
6.17% <0.00%> (-0.06%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/cloudcommon/db/db_dispatcher.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/domain.go
2.73% <0.00%> (+0.07%)
:arrow_up:

pkg/cloudcommon/db/metadata.go
5.06% <0.00%> (-0.04%)
:arrow_down:

pkg/cloudcommon/db/metadataresource.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/namevalidator.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/project.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/scoperesource.go
0.00% <ø> (ø)

pkg/cloudcommon/db/standalone.go
1.79% <0.00%> (-0.37%)
:arrow_down:

pkg/cloudcommon/db/virtualresource.go
0.00% <0.00%> (ø)

pkg/cloudprovider/instance.go
0.00% <ø> (ø)

... and 551 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 31de731...dbc5bb1. Read the comment docs.

/lgtm
/approve


What was it like to learn CFML?

We’ve recently started a project to find the best way to design our tracks, in order to optimize the learning experience of students.
As a first step, we’ll be examining the ways in which languages are unique and the ways in which they are similar. For this, we’d really like to use the knowledge of everyone involved in the Exercism community (students, mentors, maintainers) to answer the following questions:

How was your experience learning CFML? What was helpful while learning CFML? What did you struggle with? How did you tackle problems?
In what ways did CFML differ from other languages you knew at the time? What was hard to learn? What did you have to unlearn? What syntax did you have to remap? What concepts carried over nicely?

Could you spare 5 minutes to help us by answering these questions? It would greatly help us improve the experience students have learning CFML :)
Note: this issue is not meant as a discussion, just as a place for people to post their own, personal experiences.
Want to keep your thoughts private but still help? Feel free to email me at<EMAIL_ADDRESS>Thank you!

I inadvisably dove into the Hamming exercise without taking the proper time to learn about the language, so I did not even know the difference between Arrays and Lists. That cost me a lot of time just fumbling around. Had I just read https://helpx.adobe.com/coldfusion/developing-applications/the-cfml-programming-language/using-coldfusion-variables/data-types-developing-guide.html I would have known.

Another resource is
https://modern-cfml.ortusbooks.com/cfml-language/arrays

We're closing this issue as it was part of our research for the v3 version of Exercism which has just been released.
Thanks everyone for chipping in! It has been greatly appreciated.


Update README

A README update that covers the changes made in https://github.com/timotejroiko/discord.js-light/commit/b9ce1dd4ccffb4e803db100d024364ea89543f1d

there are a lot of readme changes to be done, just waiting for discord.js to finalize v13.


Don't use hclwrite tokenizer for "literal" strings

Don't use hclwrite tokenizer for "literal" strings because it escapes and  breaks variables passthrough;
Remove "map compactor" because it contains bug.

Submission Checklist

[ ] Have you installed and run this change against pre-commit? (pre-commit install)
[ ] Are all tests passing? (make tests)
[ ] Have you written unit tests to cover this change?
[ ] Is unit test coverage still above 80%?
[ ] Have you updated all applicable documentation?
[ ] Have you followed the guidelines in our Contributing document?

This PR become a #1167


ImportError: DLL load failed while importing _C

Happens when I try to import _C

当我尝试导入 _C 时发生

I have the same problem, have you solved it?


JBPM-5609: Stunner - fix BpmnFileIndexerTest failure by increasing wa…

…it for indexing to finish.
This test was passing locally but failed on Jenkins. I can get the test to fail locally with the same error as reported on Jenkins by reducing the wait time, so I think increasing the wait time should fix the test on Jenkins.
See https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/kie-releases-7.0.x/job/031.Releasing_KIE_deployLocally-7.0.x/lastCompletedBuild/testReport/

@jlindop both
Thread.sleep(5000);
and
Thread.sleep(15000);
worked for me locally. I noticed that all other tests in commons that test indexing use
Thread.sleep(5000);
so maybe it would be worth to see if the number of bpmn files in the BPMN_FILES is causing the extra delay and if splitting it up would help? If in future you add more bpmn files to test or other test uses more we might run into this again. wdyt?

@tsurdilo There are only 7 files being indexed. I've only seen this error reported once, and the test must have passed all the other times it ran, so maybe it's a one off. I think I'll close the PR and keep an eye out for it happening again. If it does, we can split the files into groups and/or increase the wait time.

It seems the obvious solution here is to fix the test so that it does not have to rely on Thread.sleep(). I know it's not easy, but IMO worth the effort.


Launching mavros px4.launch causes Realsense T265 '/camera/odom/sample' topic's pose to drift significantly

Required Info

Camera Model
{ T265}

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
{Linux (Ubuntu 16.04)

Kernel Version (Linux Only)
(4.14)

Platform
Odroid XU4

SDK Version
{ legacy / 2.. }

Language
{C/C#/labview/nodejs/opencv/pcl/python/unity }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
For our project we use a pixhawk mini flight controller with mavros px4 connected to an Odroid XU4 with WIFI to use most of our setup offboard through ROS. The realsense t265 seems very promising as a plug and play VIO sensor, however we are experiencing a strange issue that I will try to outline as best as possible.
The realsense works well on its own. We first set it up on Windows to test, then linux to test the realsense-ros wrapper. After validating it as a potentially useful VIO sensor, we managed to get the realsense launching from our Odroid after a couple days of pain figuring out that we needed the 4.14 kernel and that not all nodes would launch unless we flashed a specific ubuntu 16.04.
After all this, we managed to launch the realsense t265 on the odroid succesfully and with fairly accurate results. We have a motion capture system that is run through a matlab script that synchronizes rigid body pose with the realsense pose and plots them together.
Our issue however, is that for some reason, the second that mavros px4.launch is launched, the pose data from 'rostopic echo /camera/odom/sample' immediately starts linearly increasing at a fast rate. It appears that the linear twist gets increased as well which could be the cause. My intuition would lead me to believe that it must be something inherent in px4, possibly the launch file or configurations. At first we thought that it could be CPU/RAM related, but we did tests to show that is likely not the case.
I've set the ekf2 to not use vision and tried Attitude Q estimator without vision and we still have the same problem immediately when mavros is launched. I also went through the px4_config.yaml and made all parameters related to vision set to false which also did not fix anything.
For a sanity check we launched mavros and the realsense on a seperate computer which worked fine (why we originally thought it may be CPU/RAM related)
I would appreciate any help and support, please let me know if you require any additional information. We hope to use the realsense VIO to fly autonomously in position hold mode.

I have the same problem when I use  raspbery pi 3b (ubuntu mate 18.04) as companion computer [.](url

)
With jetson TX2 or laptop (ubuntu 18.04) position and velocity  has been normaly changing.

I see the same issue on RPi 3B+, Jetson Nano and sometimes on Jetson TX1. This is 100% a ros wrapper issue because sdk examples work just fine. Also have of the Ros examples don't work, fail after a while or give errors...

Hi guys!
I used RPi 3B+, ubuntu mate 16.04, ros kinetic, px4 1.8.2 on pixhawk1.
And all nodes are processed in RPi, it worked well ! (position data doesn't drift, not increase)
I used LPE mode of px4, and actually tested a drone in position mode.
Actually I want to process on odroid xu4, because of RPi3 B+ low performance. odroid xu4 has better performance than RPi3 B+, so I don't think cpu is problem.
sorry for bad english :)

I believe we were able to fix our issue by changing back parameters within the px4 launch script to false for anything related to vision. At first we thought that the fix was Wifi related because we simply brought the drone from the motion capture back to the lab and were surprised to see that it was working perfectly fine with no drift. It appears rather that the Odroid required a full shutdown for the changes to take affect as now our drone works perfectly fine in both locations with different Wifi sources. I appreciate the collaborative help, perhaps our solution could also be the case for you all? We've had very good performance from the Realsense T265 over the past two weeks. Position Hold flight mode works great and the error is rather minimal even when compared with Motion Capture.

Glad to see things are working better now.  Closing out this issue.


Remove possiblity of multiple close on same fd

With all the async connects and disconnects and error handling
going on in hiredis, we need to centralize how we close our fd
and set it so it doesn't get re-closed.  Prior to this commit,
sometimes we'd close(fd), run an async error handler, then
call close(fd) again.
To stop multiple closes, we now set fd to -1 after we close it,
but that requires not passing fd as an independent argument to
functions.
This commit moves all fd usage to c->fd.  Since the context
has a fd field and all functions receive the context, it makes
more sense to use the fd inside of c instead of passing along fd
as an independent argument.
Also, by only using c->fd, we can set c->fd after we close it to
signify we shouldn't re-close the same fd again.
This does change one semi-public interface function redisCheckSocketError()
to only take (context) instead of (context, fd).  A search on github
returned zero occasions of people using redisCheckSocketError()
outside of net.{c,h} in hiredis itself.
Commit inspired by the bug report at:
https://groups.google.com/forum/#!topic/redis-db/mQm46XkIPOY
Thanks go out to Thijs for trying high-frequency reconnects on
a host that isn't there.
All tests pass.

I am using a version before this patch. But the program is just one thread. The error case just like this bug. The event handled by libevent, and the epoll_wait returns a active event, but libevent just leave there without handling.
The issue I commit https://github.com/libevent/libevent/issues/230


Problem with Content-Lenght is missing

I'm playing clonk rage but i can't play online because this happend
Content-Lenght is missing pls help me
PS: i don't speak english so well

@victor1969 can you please share the code you are using so we can understand what you're asking?

where i get the code?

@victor1969 is this an error you saw while playing a game? Why did you decide to post about it here?

i'm just trying to play online Clonk rage but says on the server list
Internet server on league.clonkspot.org
Invalid server response: Content-Length is missing!

@victor1969 unfortunately, that has nothing to do with project. There's probably somewhere else online for you to report this, though!

:(


Tweak strategy-explorer and suggestions-element so they can be reused in multiple contexts

The strategy-explorer and suggestions-element modules provide Web Components that we want to use in applications and environments beyond runtime/browser/demo*.
There are a few minor bits that need tweaking to support flexible reuse (mostly, removal of require and some minor factoring).
I mentioned in a team meeting that this code was forked in arcs-cdn. I think this was misunderstood to mean the design of functionality was altered, but really the changes were only to enable reuse as above. With this issue resolved, the code in this repo can be The Source of Truth and the arcs-cdn will contain only build artifacts.

Obsolete with much code shuffled and reworked since, AFAIK.


moniker can be discouraging

as much as love the dynamic name generation, this feels a bit too much:

maybe there needs to be a recycle button if you are using an autogenerated name to cycle away from negativity:

I'm also ok with mySketch1, mySketch2, for now...

Another option is to make / grab a dictionary of friendly & nice adjecectives.

I also like the sense of humor of automatically generated sketch names but I agree you picked a few mad ones.
I quickly composed this sketchAdjectives.txt dictionary so it should be way better now!

But adding a small "generate project name" gui element could be nice anyways :)

@ofZach can we consider this as fixed ?

yes it feels a little better with the dictionary....  curious what @kylemcdonald thinks but closing for now.

(I also added the "Recycle"/regenerate glyph icon in 2140b92 )

i looked through the new dictionary and i think it's more appropriate now. i consider this closed too.
but regarding the aesthetic of the names, i would take a different route. stop reading here unless you want to entertain the possibility of going a different route :)
myAdjectiveSketch is fun, but i see two issues:

it will necessarily repeat after ~200 calls
an adjective alone doesn't create an image for me

i did a mockup of adjectiveNoun using the 500 most common nouns and adjectives: https://gist.github.com/kylemcdonald/f6b53782f06fa3a19749
religiousEvidence
tallEffect
paleOil
tremendousSister
assistantSenate
sharpBenefit
competitiveMission
jointFall
toughAttention
dryPlan
largeStage
westernCondition
necessaryCrime
sufficientStation
activeConsumer
socialWeapon
commercialExecutive
extraMember
gladIdea
loudMeeting

another approach could be to go for the aphex twin look, and use a small markov chain. even for length 1 they're pretty fun:
char=$1
for i in `seq 8`; do
	printf $char
	char=`egrep -o $char. list-adjectives.txt | gshuf -n 1 | cut -c 2`
done
echo $char

$ echo 'abcdefghijkmnopqrstuvwxyz' | fold -w1 | xargs -L 1 ./markov.sh
arimimufi
bontociad
cablysoma
deryerall
enalignef
feredatel
glisyctiv
huameladl
iacanindo
jusorelea
knghowial
mprmiexto
nderetiap
ompompore
printrice
qutingonn
riealleti
stideflui
tesistorn
uccoarvak
vexigrfun
wnalenver
xticrruar
ypreftiem
zitinyonf

this thread is getting interesting :)
I think one of the main issues is that none of these approaches produce files that are easily sortable the same way (generally) saying sketch3, sketch4, or processings:
sketch_datea, sketch_dateb, sketch_datec...
is sortable.  I've found that I actually forget the name sometimes, and after I create it I have folders that look like this:

and it's usually somewhere in the middle, vs right at the end / easily identifiable by having the date in the name.
I guess I generally prefer a more utilitarian approach here :)  I feel like we are trying to be too cute, and it might be better to aim for most functional ?

Interesting discussions :)
But I'm wondering how many people will actually use this name-generation functionality.
I mean, is it worth paying so much attention to this little PG detail / feature ?
In my case, I'd only use it to quickly try something out, a quick OF sketch which will probably get deleted once it works (after copy/pasting it into my real project which has a "real" name).
Why would you use a randomly generated name if you have an important OF project/app in mind ?
So for me, the most important thing is that it makes me laugh on generating the sketch... so I'd go for cuteness rather then functionality.
@ofZach If you want to find back a sketch by date, Finder.app (or equivalent) can always sort files by modification/creation date rather then by name...

from experience beginners often times don't name their sketches well or at all -- personally, I'd vote for the most functional vs the cuteness of autogenerated names.  But that's more from using it now for a bit (the auto generated names are definitely fun) and finding it kind of messy / not very helpful at some point.  I promise that beginners will have folders that look like my screenshot above, I think we are doing a disservice to them with this approach vs. something more practical.
my suggestion is for RC2, add a flag to settings (where you can have the current moniker approach or the p5 appraoch) and then we can ask people to a/b test a little and get feedback from the community.

zach, i totally agree. i think we're basically at the point where getting feedback/testing is the next step in general.


Add static ServiceAccount token invalidator

How to categorize this PR?

/area security
/kind enhancement
/merge squash
What this PR does / why we need it:
With https://github.com/gardener/gardener/issues/4659, https://github.com/gardener/gardener/issues/4660, and https://github.com/gardener/gardener/issues/4661 we strive to use expiring and auto-rotating JWT tokens for our components in order to authenticate with the respective kube-apiservers.
However, even when using them, the static ServiceAccount token secrets are still generated and valid. As of Kubernetes v1.22, there is neither a way of preventing kube-controller-manager to generate such static tokens, nor a way to proactively remove or invalidate them, see https://github.com/kubernetes/kubernetes/issues/77599 and https://github.com/kubernetes/kubernetes/issues/77600.
This is where the TokenInvalidator comes into play: Since it is not possible to prevent kube-controller-manager from generating static ServiceAccount secrets, the TokenInvalidator is - as its name suggests - just invalidates these tokens.
It considers all such Secrets belonging to ServiceAccounts with .automountServiceAccountToken=false.
Special notes for your reviewer:
I have added some document which can help understanding the purpose of this TokenInvalidator.
Release note:

`gardener-resource-manager` now requires operators to provide a TLS certificate and key for its webhook server. The respective directory can be configured with `--tls-cert-dir`, bind address and port can be configured with `--bind-address` and `--port`, respectively.

`gardener-resource-manager` can now make sure static `ServiceAccount` tokens are invalidated. This might be helpful to enforce usage of Kubernetes' upstream [`ServiceAccount` Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) feature. Please consult [this document](https://github.com/gardener/gardener/tree/master/docs/concepts/resource-manager.md#tokeninvalidator) for more information.

@timebertt Could you have a final look, please? :)


Change non-null check argument of setProgressHandler method in CefApp…

…Builder to better match expected behavior

I think the non-null check is applied to the wrong target. Just a small fix.

Oh yeah, you caught me copy and pasting code :D. It is not a major issue so I will not release a new version with it, but it will be included in the next release. Thank you for reviewing the code and reporting back :)


Split Vulnerability and Save platforms

Split Vulnerability and Save platforms

could add github action for building the save-cosv-frontend ?

could you add github action for building the save-cosv-frontend ?

Added


Prettify our tutorials

[ ] Additional function parameters, change functionality or change defaults?
[ ] New estimator in cr.tl.estimators?
[ ] New kernel in cr.tl.kernels?
[ ] New gene trend model in cr.ul.models?
[ ] New plotting function in cr.pl?
[ ] Other?

Try jupytex to prettify our tutorials.

MyST Markdown can be used to add e.g. colored boxes with content. The Jupyter Book docs show quite a few example on how to use MyST Markdown and other features.

This will go into a later release. @WeilerP, can you add this to the release schedule for a later release?

This is important; you can generate nice colorful boxed both in markdown as well as in jupyter notebooks, see two scVi-tools examples below:

Pretty boxes in jupyter

Pretty boxes in markdown.

done, we have beautiful tutorials now.


fix: ensure we have a WAL to archive for every newly created cluster

We require WAL archiving to be working before taking every backup, and we control that by checking the archival status of the latest archived WAL.
For this check to be done we need to have WAL to archive, and this is not always true for new clusters.
For PostgreSQL 14 and older, this condition was granted by the archive_timeout setting but since PostgreSQL 15 the instance won't mark the first WAL as ready to archive if there is no database activity.
With this patch we always switch to a new WAL after having created a cluster, and we'll always have a WAL to archive even for newly created clusters.
Closes: #896
Signed-off-by: Leonardo Cecchi<EMAIL_ADDRESS>

I've tested this, and it doesn't work. After creating the cluster, this is the status of the pg_wal directory:
postgres@cluster-example-1:~/data/pgdata$ find pg_wal/
pg_wal/
pg_wal/000000010000000000000002
pg_wal/000000010000000000000003
pg_wal/archive_status

pg_controldata output:
pg_control version number:            1300
Catalog version number:               202107181
Database system identifier:<PHONE_NUMBER>479458843
Database cluster state:               in production
pg_control last modified:             Fri 21 Oct 2022 12:18:06 PM UTC
Latest checkpoint location:           0/2000028
Latest checkpoint's REDO location:    0/2000028
Latest checkpoint's REDO WAL file:<PHONE_NUMBER>00000000000002
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:735
Latest checkpoint's NextOID:          16386
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        726
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Fri 21 Oct 2022 12:18:01 PM UTC
Fake LSN counter for unlogged rels:   0/3E8
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
wal_level setting:                    logical
wal_log_hints setting:                on
max_connections setting:              100
max_worker_processes setting:         32
max_wal_senders setting:              10
max_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Size of a large-object chunk:         2048
Date/time type storage:               64-bit integers
Float8 argument passing:              by value
Data page checksum version:           0
Mock authentication nonce:            d149991b9a0fb96875e001e72bdc54d57996ff2d21aedffc303d52806c56f8fe

I moved the pg_switch_wal call in the backup runner and verified that it works.
postgres {"level":"debug","ts":1666357440.6566718,"msg":"Detected Barman installation","caller":"pkg/management/log/log.go:180","logging_pod":"cluster-example-1","newCapabilities":{"HasAzure":true,"HasS3":true,"HasGoogle":true,"HasRetentionPolicy":true,"HasTags":true,"HasCheckWalArchive":true,"HasSnappy":true,"HasErrorCodesForWALRestore":true,"HasAzureManagedIdentity":true,"Version":"3.2.0"}}
postgres {"level":"info","ts":1666357440.6790662,"msg":"Triggering the first WAL file to be archived","logging_pod":"cluster-example-1"}
postgres {"level":"debug","ts":1666357440.7453568,"msg":"Cached object request received","caller":"pkg/management/log/log.go:180","logging_pod":"cluster-example-1"}
postgres {"level":"debug","ts":1666357440.7467375,"msg":"Cached object request received","caller":"pkg/management/log/log.go:180","logging_pod":"cluster-example-1"}
postgres {"level":"info","ts":1666357440.838875,"logger":"wal-archive","msg":"barman-cloud-check-wal-archive checking the first wal","logging_pod":"cluster-example-1"}
postgres {"level":"info","ts":1666357443.0215104,"logger":"wal-archive","msg":"Archived WAL file","logging_pod":"cluster-example-1","walName":"pg_wal/000000010000000000000001","startTime":1666357441.1287544,"endTime":1666357443.021487,"elapsedWalTime":1.892732865}

/test


can i be a contributor?

Transferred this issue to the moisture tracking repo (it was opened in WAM2layers)

Added you. Please close the issue ones you've accepted the invite.

@damianinsua , invite is pending, so closing this issue


Fix ReSharper's "Use string interpolation expression" and "Replace if…

Hello,
This pull request is very simple and aims to reduce the technical debt. It specifically targets the "Replace if statement with null-propagating code"  rule and "Use string interpolation expression" rule reported by ReSharper.
Checklist

General Contributing

[x] Have you read the Code of Conduct and signed the CLA?

Is This a Code Change?

[ ] Non-code related change (markdown/git settings etc)
[x] SDK Code Change
[ ] Example/Test Code Change

Validation

[x] Does this code build successfully?
[x] Do all tests pass?
[x] Does Stylecop pass?

Thanks for putting this together! I'll ask the team to review this.

Hi @greg-db, is there any news regarding this pull request?

@marodev This is open with the team but I don't have an update on it yet.


Make windows binary url configurable

What this PR does / why we need it:
Today, testing a Kubernetes release requires doing a new build of ACS-Engine. We need to be able to test fixes from Windows Server, ContainerD / Docker, Kubernetes, and Azure-CNI together to improve Kubernetes conformance test results. If we have to rebuild acs-engine, then we cannot move fast enough.
The epic tracking Windows setup cleanup is #3851, be sure to check this off the list when this item is done.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #4008
Special notes for your reviewer:
This is step one in removing the use of package built by build-windows-k8s.sh.  There will be follow up PR as defined in #3851.
cc: @PatrickLang
If applicable:

[ ] documentation
[ ] unit tests
[ ] tested backward compatibility (ie. deploy with previous version, upgrade with this branch)

Release note:

Make windows binary url configurable

@PatrickLang still need to run a few test deployments but could you review to make sure this was along the lines of what your thinking?

@jackfrancis @PatrickLang ready for a review

@PatrickLang for final review/merge

@jsturtevant Thanks for the PR. Looks good save for a few comments.

/lgtm


tuf: add a method to retrieve rekor public keys

Signed-off-by: Asra Ali<EMAIL_ADDRESS>
Summary

Adds a wrapper method to get rekor public keys, to use in cosign

I expect that with this method, we can now set sign/verify opts to include RekorPubKeys, so that people can define this themselves when they cosign as a library. This is how the fulcio roots works as well.
Ticket Link

Fixes
Release Note

ping @haydentherapper or maybe this should just go in an internal cosign package?

I'd prefer this either live in Rekor or sigstore/sigstore. Given it's intertwined with TUF, I think sigstore/sigstore in the best option for now. I think tlog verification should live in Rekor, certificate verification in Fulcio, TUF, crypto/signature/PEM/etc functions in sigstore/sigstore, OCI in Cosign.

@asraa Good to close in favor of sigstore-go?


[4.2] Implement verification that noescape closures passed to Objecti…

…ve-C are not escaped
The series of commit introduces a copy_block_without_escaping block
instruction that ties a swift closure sentinel to the block that is
escaped.
SILGen emits this instruction when it generates a conversion from a
@noescape swift closure to a block.
       %noescape_closure = ...
       %wae_Thunk = function_ref @$withoutActuallyEscapingThunk
       %sentinel =
         partial_apply [callee_guaranteed] %wae_thunk(%noescape_closure)
       %noescaped_wrapped = mark_dependence %sentinel on %noescape_closure
       %sentinel_copy = copy_value %noescaped_wrapped
       %storage = alloc_stack
       %storage_address = project_block_storage %storage
       store %noescaped_wrapped to [init] %storage_address
       %block = init_block_storage_header %storage ...
       %block = copy_block_without_escaping %block withoutEscaping %noescaped_wrapped

The ClosureLifetimeFixup pass then lowers
copy_block_without_escaping into a copy_block and
is_escaping/cond_fail/destroy_value combination at a point
that succeeds the end of the block's lifetime.
As a result whenever a semantic noescape Swift closure synchronously
escapes to Objective C we will trap with an error after we return from
the Objective C call.
rdar://39682865
Cherry-pick of #16236
Commits:

Add a copy_block_without_escaping %block withoutEscaping %closure instruction

Mandatory pass will clean it up and replace it by a copy_block and
is_escaping/cond_fail/release combination on the %closure in follow-up
patches.
The instruction marks the dependence of a block on a closure that is
used as an 'withoutActuallyEscaping' sentinel.

SIL: Allow is_escaping_closure on optional closure types

SILGen: Emit withoutActuallyEscaping verification for @noescape closures stored in blocks

SIL: Add getSingleDealloc to AllocStack and remove two copies of it

I am going to introduce a third use in a follow-up

ClosureLifetimeFixup: Add support for copy_block_without_escaping instructions

Replace:
%copy = copy_block_without_escaping %block withoutEscaping %closure
...
destroy_value %copy
by (roughly) the instruction sequence:
%copy = copy_block %block
...
destroy_value %copy
%e = is_escaping %closure
cond_fail %e
destroy_value %closure

Fix DiagnoseStaticExclusivity

After the copy_block_without_actually_escaping change it might see a
mark_dependence instruction on a noescape closure.

Fixes to AccessSummaryAnalysis

The pattern we see for noescape closure passed to objective c is different:
There is the additional without actually escaping closure sentinel.

Fix test cases after SIL representation changes

Executable test case for passing a noescape closure to Objective-c which
escapes the closure.

We expect the program to crash with an explanation.

Distinguish between withoutActuallyEscaping and passing @noescape
Objective C closures when reporting that a closure has escaped

rdar://39682865

@swift-ci Please test


[Bug]: Insert service item line leads to no repair status code validation

Describe the issue
The status field in the service header is not correctly set to "in process", if you insert a service item line.
Expected behavior
The status is correctly set on the service item line.
Steps to reproduce

Set the first Service Order Status "In Process" and Initial "true".
Create a service order.
The status in the service order is "pending".
Insert a service item and validate the line.
Result: The status in the service order is still "pending".  --> wrong
Validate manually the initial value of the repair status.
Result: The status is "In Process".  --> correct
Additional context
No response
I will provide a fix for a bug

[X] I will provide a fix for a bug

@AndreiPanko / @PredragMaricic, please triage.

@JowTraser, did you mean to log this issue under the BaseApp contribution pilot? As the code you are referring to is in the BaseApp, you'd have to suggest and fix this code in the BaseApp contribution pilot: https://github.com/microsoft/businesscentralapps. For access to the pilot, please fill out the following form: https://forms.office.com/r/E9wyE5a58f.
Would you like me to move the issue to the contribution pilot for you?

Hi Jesper, JowTraser is from my team and we will try to resolve this issue within the base app and provide a fix if possible over at the pilot program.
We are not sure yet if this is an AL issue or maybe a framework issue in which case we would probably have to hand it back as a bug.
Cheers Leon


Wrong instruction for interacting with localhost node ?

In 00_Deploy_Mocks.js l.34 the instruction is "Please run 'npx hardhat console' to interact with the deployed smart contracts!
Should it be npx hardhat node instead ?

The local network should be launched before starting the deployment. Otherwise, the script will exit before reaching the instruction log line.
The npx hardhat console instruction allows the interactaction with the smart contracts. See more details here.

@fabioDMFerreira when I run npx hardhat deploy without launching local network, the script (00_Deploy_Mocks.js) runs until the end. Maybe I don't get your point ...

That's odd, you shouldn't be able to deploy to a local network if you don't have any node running. Wondering where the smart contracts are being deployed.
The correct command to interact with the deployed smart contracts is npx hardhat console. The npx hardhat node is used to launch a node in the local network.

Ok thanks for your feedback :)


Config file credential providers

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

-->
Tell us about your request
Add support for config file credential providers

[ ] IMDS
[ ] ECS
[ ] EKS
[x] WebIdentityToken
[x] STS assume role

IMDS support has landed and will go out in the next release


Follow up Question to #1392 about a ScreenShot on Web

Technology
Version

Flutter version
3.3.5

Plugin version
flutter_inappwebview: ^6.0.0-beta.7

After @pichillilorenzo helped me out in getting the Webview working on Flutter Web.... I cant seem to get a snapshot/screenshot of the InAppWebView!? Just wanted to know is a snapshot supported in Flutter Web?
Everything from my project remains the same from #1392. But when I use your below code I found on stackoverflow... I get a null error.
 Uint8List screenshotBytes = (await webViewController?.takeScreenshot())!;
                    showDialog( context: context, builder: (context) {
                      return AlertDialog( content: Image.memory(screenshotBytes),);
                    });

I also tried wrapping it in RepaintBoundary, but that failed too with null errors!? :-(
Any advice would be helpful.
Thanks.

takeScreenshot is not supported on Web! Just check the code docs of each method or event or whatever to see what is supported in which platform.
Just for reference, takeScreenshot API