text:
AttributeError: 'TQDMCallback' object has no attribute 'on_train_batch_begin'

I get
AttributeError: 'TQDMCallback' object has no attribute 'on_train_batch_begin'

when trying to use keras-tqdm with LSTM.

Getting that too. Any luck?

Nope, no luck.
Sorry, misclicked.

It seems that the library is just outdated. Even when I tried to fix it, it doesn't seem to work. I will look for an updated solution for the problem that got me here.

Solved-ish by creating a progress bar callback, tho I'd love to get an actual fix..
Here's my code if you're still looking:
import time
import sys
import tensorflow as tf
import math

class progBarCallback(tf.keras.callbacks.Callback):
    def setEpochSize(self, es):
        self.epoch_size = es
    def on_epoch_begin(self, epoch, logs={}):
        self.done = 0
        self.cur_epoch = epoch
        printProgBar(epoch, 0, self.epoch_size)
    def on_batch_end(self, batch, logs={}):
        self.done += self.params["batch_size"]
        printProgBar(self.cur_epoch, self.done, self.epoch_size)

def printProgBar(batch, amount, biggest, args=[]):
    fraction = amount / biggest
    num = math.floor(fraction * 50)
    print("\rEpoch " + str(batch + 1) + " [", end="", flush=True)
    for i in range(num - 1):
        print("=", end="")
    if(num > 0):
        print(">", end="")
    for i in range(50 - num):
        print("_", end="")
    print("]", end="")
    for arg in args:
        print(" " + str(arg), end="")
    print(" " + str(amount) + "/" + str(biggest), end="")

Example Usage:
progBar = progbar.progBarCallback()
progBar.setEpochSize(len(x_train))
model.fit(x_train, y_train,
          epochs=1,
          batch_size=1000,
          verbose=0,
          callbacks=[progBar])

Unfortunately, it seems that Keras removed the callback argument from the evaluate function, so this works only for training.

Thanks, very kind of you to share!

Dude, I dunno if you're still into that, but the solution is very stupid. Keras decides if it allows updating the progress bar by checking a function named sys.stdout.isatty() which is false in PyCharm (I hope you are using PyCharm, that's how I got the error), so all I had to do is to go into \Lib\site-packages\keras\utils and add or True to the if statement. (Line 355 for me, if self._dynamic_display or True.

No, I'm actually using Jupyter Notebook. Maybe this could help. Thanks a lot!

This is a simple workaround to use until fixed:
from keras_tqdm import TQDMNotebookCallback

# keras, model definition...
cb = TQDMNotebookCallback()
setattr(cb,'on_train_batch_begin',lambda x,y:None)
setattr(cb,'on_train_batch_end',lambda x,y:None)

model.fit(X_train, Y_train, verbose=0, callbacks=[cb])

I also went through the same problem, @gsportelli 's method can temporarily help, thanks!

This is a simple workaround to use until fixed:
from keras_tqdm import TQDMNotebookCallback

# keras, model definition...
cb = TQDMNotebookCallback()
setattr(cb,'on_train_batch_begin',lambda x,y:None)
setattr(cb,'on_train_batch_end',lambda x,y:None)

model.fit(X_train, Y_train, verbose=0, callbacks=[cb])

This temporal fix does not update the widget for me. A workaround is:
from keras_tqdm import TQDMNotebookCallback

cb = TQDMNotebookCallback()
cb.on_train_batch_begin = cb.on_batch_begin
cb.on_train_batch_end = cb.on_batch_end

model.fit(X_train, Y_train, verbose=0, callbacks=[cb])

@ipazc that workardound works but not when fitting a generator in multiprocessing mode. I guess there must be something more complex to it.

Note that for more modern versions of Tensorflow, you may be forced to patch more attributes. I needed to do this, when using Tensorflow 1.14 with tf.keras having version 2.2.4.
    tqdm_cb = TQDMCallback()
    tqdm_cb.on_train_batch_begin = tqdm_cb.on_batch_begin
    tqdm_cb.on_train_batch_end = tqdm_cb.on_batch_end
    tqdm_cb.on_test_begin = lambda y: None
    tqdm_cb.on_test_end = lambda y: None
    tqdm_cb.on_test_batch_begin = lambda x, y: None
    tqdm_cb.on_test_batch_end = lambda x, y: None

authors: Braintelligence espears1 gsportelli ipazc omer54321 singngai zaccharieramzi

repo: bstriner/keras-tqdm


text:
Assign returned values in correct order

This is basically a copy of PR #154, which is now obsolete due to refactorings. It also adds a test case for this issue.

Looks good to me

looks good!

source: gharchive/pull-request

authors: jakesyl kallerosenbaum philipglazman

repo: btcsuite/btcutil

license: isc

license_type: permissive

license_source: bigquery


text:
hdkeychain: Update NewMaster to accept network.

This changes the NewMaster function to accept the network the generated extended master key is associated with.  This could previously be done by calling SetNet on the returned extended key, but that approach is more error prone since it is easy for a caller to forget to do it or never know they should to begin with.
Closes #65

Since the API is changing, should you drop SetNet, or is it still useful somehow?

It's still useful in some circumstances.

OK, and OK on the PR.

ACK

Reviewed 2 of 3 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from the review on Reviewable.io

authors: cjepson dajohi davecgh


text:
Just FYI this seems to be no longer working.

Getting provider not supported in console from firebase.js line 29.
Clean install simple
changed to our credentials
yarn: yarn run dev

Interesting the reduxSagas branch works.   More what i was looking for....

source: gharchive/issue

license: mit


text:
输出图片背景设为黑色

请问测试想要将输出图片除了检测分割目标之外其他的背景设为单一色（黑色）应该怎么处理呢

这个只能说看一下前传的部分，绘图那里改😂

authors: bubbliiiing yilifan

repo: bubbliiiing/yolact-pytorch

license: MIT

license_source: github-api


text:
How do I use fly with rollup and babel?

I would like to use fly, since it's easier to understand than gulp or grunt.
And babel is awesome
But now I want to package it for the web, I haven't tried rollup yet, but it looks like it could be a good fit for bundling all the transpiled modules into one bundle.
But since rollup takes a "entry point" I'm not sure how it fits with fly?
https://github.com/rollup/rollup-plugin-babel

Hi Leon
I am not so familiar with using Rollup yet, so I can't tell you what's really needed. In the meantime while I figure this out, you are most welcome to jump in and come up with a workflow. Perhaps a plugin would be needed?
Best

Rollup doesn't take raw data as an input, but a reference to a "main" file.
So .source(...glob) doesn't really fit.
gulp does this by having an option object on the .src([...], { read: false }) which makes the globed file paths getting passed instead of the raw data.
there are a couple of scenarios where you would want to pass along the filenames instead, so maybe we should add a .sourceFiles(...glob)?

@leon .source takes files not data, is not that what we need here?

rollup has this api
import { rollup } from 'rollup';
import babel from 'rollup-plugin-babel';

rollup({
  entry: 'main.js',
  plugins: [
    babel({
      exclude: 'node_modules/**',
      sourceMap: true
    })
  ]
}).then(...)

And If I where to write a .filter plugin, how would I pass the main.js?
I'm not sure how to call rollup correctly, it is promise based, but you haven't got an example on how to write a plugin which uses promises.

@leon I was sending you in the wrong direction. I think you should take a look at fly-eslint and fly-mocha.
Another one that can point you in the right direction would be fly-browserify.

Thanks I'll have a look :)

I messed around with this for a while and couldn't get anything working.
@bucaran @Rich-Harris I believe the problem here is that the Rollup API expects a filename entry point (e.g. main.js) while the Fly API only exposes every globbed file with Fly.prototype.unwrap. unwrap works with Browserify, since Browserify has an add method to add an arbitrary number of files.
Any ideas for how to make Fly work with Rollup?  I'm happy to contribute once the direction is clear.

There's a plugin that lets you use multiple entry points, which may help: https://github.com/eventualbuddha/rollup-plugin-multi-entry
Also, plugins give you complete control over the loading process, so if necessary you can (for example) load modules from memory, or from a stream of some sort. Happy to try and help figure out the best workflow if you can point me in the right direction! Feel free to ask questions on the Rollup issue tracker or on Gitter if that's preferable

Hey all, I'm curious if someone would like me to take a crack at this? I think I've got the hang of fly's API now and I'm quite curious about Rollup!

Sure!  @lukeed Thoughts?

I actually was making a fly-rollup plugin this weekend. I halted on it in favor of fly-browserify... but maybe I'll open it back up

I was able to get basic rollup support by using this filter in my flyfile:
    .filter((data) => {
      return this.unwrap((files) => {
        return rollup.rollup({
          entry: files[0].toString(),
          plugins:[]
        }).then(function(bundle) {
          var result = bundle.generate({
            sourceMap: 'true',
            format: 'es6'
          });
          return {
            code: result.code,
            map: result.map,
            ext: '.js'
          }
        })
      })
    })

You just have to import rollup at the top of the flyfile. I just wanted to share. Maybe someone can use this info to build a proper fly-rollup plugin at some point.

@ambrooks Your filter works well~
I'm using fly-esnext .
I found If I do import rollup from 'rollup' in flyfile, node says rollup is undefined.
With const rollup = require('rollup') , it works.
Does anyone have an idea about this ?

@frantic1048 Try:
import { rollup } from 'rollup';

I just builded a fly-rollup plugin with help of @ambrooks 's filter, you can take a look at it. ヾ(ﾟ∀ﾟ○)ﾂ

Nice LICENSE.

New license called "DAFUQ" for "do whatever dafuq you wanna do"

authors: Rich-Harris ambrooks brj bucaran frantic1048 girvo leon lukeed s3ththompson

repo: bucaran/fly


text:
add a test for LoadFilesIntoCache

Also move the function itself to the Cache type, since I think it makes more sense there.
Also add a NumFiles() method to the Cache interface to make the test easier (will probably also use it in the upcoming status page.
This should go in after my other PR.

thanks <3 LGTM

authors: buchgr nicolov

repo: buchgr/bazel-remote


text:
make small annotations easier to see

In some cases annotators will add some small noisy / erroneous annotations a bit randomly, they're currently quite difficult to see (which makes QC quite difficult), example:

has in fact 5 annotations, not 3, one is a tiny rectangle at the top, another is barely visible and is inside page 2.
Some possible fixes are:

showing (in small font) the number of annotations on each image (even checked), so that this kind of case is easier to detect (it will also improve things for #41)
making the colors a bit different maybe?
have a way to not display the thumbnails and instead just the annotations. I'm on a laggy Internet today so thumbnails don't load very fast, and I realize that not having the thumbnails is sometimes quite helpful, so maybe there could be a button "display annotations only" somewhere in the UI that could be toggled for the whole directory?

N.B.: we should also probably add a mechanism to ignore those in the post processing

or maybe we can add a warning in the UI (with the same warning UI as usual) for cases where there's a huge difference between the largest and the smallest annotations (like a factor of 100 in area), or when there are duplicate boxes

here's the same image without the thumbnails, easier to debug for that case:

added #annotations / expected as a first step: https://scamqc.bdrc.io/?folder=demo%2FW1KG8718-I1KG8739%2F

then there could be a warning when more than expected (which could not be bypassed by checking the image? wdyt?)
also yes there could be a different color for annotations "100x" smaller
(not sure where to put the "no thumbnail" option yet but I'll find a way!)

this is a great start, thanks a lot!

small annotations (with area < 100x the largest) get a warning:

warning now stays when image checked but too much annotations:

this is great, thanks a lot!

fixed keeping small annotation orange when image checked: https://scamqc.bdrc.io/?folder=demo%2FW1KG8718-I1KG8739%2F

added menu entry (in Filter images) to toggle thumbnail loading:

this is great, thanks a lot! One small thing: in rare cases some annotations are meant to be small like annotations that have a tag, is it possible to disable this feature for tagged annotations? Thanks!

done: https://scamqc.bdrc.io/?folder=demo%2FW1KG8718-I1KG8739%2F
(added a specific color for tagged annotations as well, and display separately in annotation count near image name)

This is perfect, thanks!

authors: berger-n eroux

repo: buda-base/scam


text:
Support MarshalAppend to reuse bytes slices

Use MarshalAppend proto methods to reuse the byte slices for serialization. Applied to internal codecs for proto and protojson.
Deprecate Annotate to use AnnotateSymbol method instead.
Running unary benchmark shows small win in allocs.
BenchmarkConnect/unary-8                     492           2070973 ns/op        14702083 B/op        248 allocs/op
BenchmarkConnect/unary-8                     606           1985378 ns/op         5429867 B/op        233 allocs/op

Currently using the unreleased proto api changes to get https://github.com/protocolbuffers/protobuf-go/commit/05cbe34333f74f33d637c3531da5b98ed35b15e1 for protojson.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Made a small change to allow the buffers in the pool to grow if they're not large enough; this change looks good to me now. @emcfarlane can you take a look and ensure that it's still ok with you? I'd like to get this into the next release if possible, since we're already planning to release some performance improvements.

authors: CLAassistant akshayjshah emcfarlane

repo: bufbuild/connect-go


text:
ES Module shipped in a CommonJS package?

Hey! Love the direction of this library and just did a huge refactor to convert all of our grpc calls to using connect query!
I'm in the middle of fixing up our tests and got this message from vistest:
Module /Users/greg/code/phc/location-fe/node_modules/@bufbuild/connect-query/dist/src/index.js:14 seems to be an ES Module but shipped in a CommonJS package. You might want to create an issue to the package "@bufbuild/connect-query" asking them to ship the file in .mjs extension or add "type": "module" in their package.json.

I'm not sure what the best path forward for you lib is, but I thought I would let you know about the warning.
Vitest also posted a work around, so I think I'm fine for now:
As a temporary workaround you can try to inline the package by updating your config:

// vitest.config.js
export default {
  test: {
    deps: {
      inline: [
        "@bufbuild/connect-query"
      ]
    }
  }
}

Cheers and thanks for all the work! 🎉

Oh dear... not sure why this happened actually. Sorry, i may have posted prematurely, the error message was so confident!
I used this library to make an internal library for our product, but node_modules may have gotten dirty during development. Cleaned everything out and it seems to be working as it should.
sorry for the noise!

I guess this issue found its way to me again, but this time in the node side of things.
For context, we are generating a library from our protos for both connect-web and connect-query in the same repo. This became problematic when the node service (which is full esm) needed to import bits.
It appears fixed for us by just adding "type": "module" to the package.json, but I don't fully understand the implications of doing that...
The connect-web library is causing no issues 🤷

for sure: yes.  I put up a PR, but this seems like something that's reasonable to ship soon.  Should have been there in the first place, really.  Thanks for your patience!  The team was at JS World, so hence the silence.  Just got back today, though, so we're right on it!

Learning how ESM works has been... tough 🙃 But we are in the process of adopting Buf everywhere we can, so this has been exciting to try things out as they are built!

@dimitropoulos Is there any progress here? We are facing the same issue and vitest inlining is not helping.

@dimitropoulos chiming in that using 0.2.0-alpha.0 and setting this nextjs config value resolved the ESM/CJS issues I was having. Not exactly relevant to vite but hoping it may help someone else.

@nickadamson have you tried running tests after you set @bufbuild/connect-query in transpilePackages? In our case, after transpiling/inlining the package <TransportProvider /> was not able to pass the custom transport to the child hooks. So every call to fooBar.useQuery required an explicit transport setting, which works, but should pick one from TransportProvider.

Thanks for working through this! Finally got some time to update our own libs and wanted to check back in.
I was still running into an issue until in my own client lib that building, I made the exports use the .js extension, then everyone is happy 🤷
Thanks again for all your work!

authors: dimitropoulos mckelveygreg nickadamson sher

repo: bufbuild/connect-query


text:
got error if attaching custom data in bugsnap.notity

got error if attaching custom data in bugsnap.notity
bugsnag: latest version
platform: ios simulator
react-native: 0.38.0

Thanks for the report, @iwater. Custom data should be serializable to JSON (numbers, strings, arrays, etc). Can you share the custom data used, or at least the structural layout so I can reproduce the problem?

@iwater I reproduced this by not setting a sub object to a pair:
client.notify(new Error('foo'), (report) => {
    report.metadata.test = "value";
});

Where as this works:
client.notify(new Error('foo'), (report) => {
    report.metadata.test = {"key": "value"};
});

Exception '-[NSTaggedPointerString countByEnumeratingWithState:objects:count:]: unrecognized selector sent to instance 0xa000068637465665' was thrown while invoking notify on target BugsnagReactNative with params (
{
apiKey = 2f1180ca5280a4ed2e250db57******;
errorClass = TypeError;
errorMessage = "Network request failed";
metadata =         {
arguments =             {
type = map;
value =                 {
body =                     {
type = string;
value = "{"source":{"headers":{"Authorization":"Basic bnVsbA=="},"url":"http://fackurl/products_04/\"},\"target\":\"products_04\",\"continuous\":true}";
};
headers =                     {
type = map;
value =                         {
Accept =                             {
type = string;
value = "application/json";
};
Authorization =                             {
type = string;
value = "Basic YWRtaW46cGFzc3dvcmQ=";
};
"Content-Type" =                             {
type = string;
value = "application/json";
};
};
};
method =                     {
type = string;
value = POST;
};
params =                     {
type = map;
value =                         {
};
};
};
};
type =             {
type = string;
value = fetch;
};
};
severity = warning;
stacktrace = "onerror@http://localhost:8081/index.ios.bundle?platform=ios&dev=true&minify=false:3…m=ios&dev=true&minify=false:3813:6\ncallFunctionReturnFlushedQueue@[native code]";
user =         {
};
}
)
RCTFatal + 104
-[RCTBatchedBridge callNativeModule:method:params:] + 1209
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.481 + 1470
_dispatch_call_block_and_release + 12
_dispatch_client_callout + 8
_dispatch_queue_serial_drain + 236
_dispatch_queue_invoke + 1073
_dispatch_queue_override_invoke + 683
_dispatch_root_queue_drain + 720
_dispatch_worker_thread3 + 123
_pthread_wqthread + 1299
start_wqthread + 13
above is my error shown, expect some information was modified, like apiKey, url etc.

authors: duncanhewett iwater kattrali

repo: bugsnag/bugsnag-react-native


text:
fix(rust): keep migrating legacy storage data but not on startup

This is an attempt to fix some restart issues that we observed with Ockam Orchestrator. In this PR:

the code for migrating legacy data has been put back
however it is only activated once when we enroll a member and not at start-up in order to avoid triggering a LMDB exception

@davide-baldo yes, this is actually silly. I think I need to better understand exactly what is not working at the moment. Closing this for now

repo: build-trust/ockam


text:
Support Xcode injected bundles in other bundles

Fixes #1320.

Yes, this works perfectly on my end - also fixes the issues that I was facing. 🎉 All Tsan dylibs are being copied.

authors: brentleyjones chiragramani


text:
How Do I Use the .jar Package to Migrate the Compiled Buildfarm to Different Types of CPUs?

In the /app-buildfarm/worker directory, I got these files:
''' buildfarm-shard-worker
buildfarm-shard-worker-class.jar
buildfarm-shard-worker-class.jar-0.params
buildfarm-shard-worker-class.jar-1.params
buildfarm-shard-worker.jar
buildfarm-shard-worker.jar_manifest_proto
buildfarm-shard-worker-native-header.jar
buildfarm-shard-worker.repo_mapping
buildfarm-shard-worker.runfiles
buildfarm-shard-worker.runfiles_manifest
'''
I've only used the executable "buildfarm-shard-worker" to start buildfarm-workers, and never used the .jar packages. Can these .jar packages properly used in place of "buildfarm-shard-worker"? How do I use them?
Could you please give me some guidance? It would be great to get a reply ：)

Those are simply the files required to launch the worker, embedded in a container root, and all, including the jar files, are used to run. Using "the .jar" file will not gain you anything specifically.
The title of your issue seems to imply a specific intent. Can you describe what problem you're trying to solve?

Thank you for your reply！
I successfully deployed the buildfarm cluster on x86, but encountered some difficulties on ARM, as it seems that the ARM toolchain still needs to be adapted. Considering that they are all Java code, can we directly apply the. jar developed from x86 to ARM environment? How should I do it？
发自我的iPhone
------------------ Original ------------------
From: George Gensure @.>
Date: Sun,Oct 20,2024 4:28 AM
To: buildfarm/buildfarm @.>
Cc: RosyCheek @.>, Author @.>
Subject: Re: [buildfarm/buildfarm] How Do I Use the .jar Package to Migratethe Compiled Buildfarm to Different Types of CPUs? (Issue #1899)
Those are simply the files required to launch the worker, embedded in a container root, and all, including the jar files, are used to run. Using "the .jar" file will not gain you anything specifically.
The title of your issue seems to imply a specific intent. Can you describe what problem you're trying to solve?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

By the way, I encountered the following problem when using bazel to compile buildfarm on ARM:
'''
ERROR: /app-buildfarm/.cache/e39f79732b8e64d60a97aef9f772a647/external/rules_java~5.5.1~toolchains~remote_java_tools/BUILD:372:11: error loading package '@rules_java~5.5.1~toolchains~remote_java_tools//java_tools/zlib': Unable to find package for @[unknown repo 'rules_license' requested from @rules_java~5.5.1~toolchains~remote_java_tools]//rules:license.bzl: The repository '@[unknown repo 'rules_license' requested from @rules_java~5.5.1~toolchains~remote_java_tools]' could not be resolved: No repository visible as '@rules_license' from repository '@rules_java~5.5.1~toolchains~remote_java_tools'. and referenced by '@rules_java~5.5.1~toolchains~remote_java_tools//:singlejar_cc_bin_main'
'''
Either way, my main goal is to build a buildfarm cluster on the arm environment.

You cannot build on x86_64 and run on arm64, as the host's toolchain is used for some JNI stuff (like blake3.c and friends).

This is now supported in v2.12.0 released last Friday. The OCI images are multi-arch. You can build and push like this:
bazel run //container:public_push_buildfarm-server -- --tag latest --repository myregistry.com/path/buildfarm-server
bazel run //container:public_push_buildfarm-worker -- --tag latest --repository myregistry.com/path/buildfarm-worker

authors: RosyCheek jasonschroeder-sfdc werkt

repo: buildfarm/buildfarm


text:
Incorrect exit code 0

Agent: v3.13.0 on Ubuntu.
I think the following step should fail:
- label: "Test command "
  commands:
    - "false && echo \"echo false\""
    - "echo \"hello\""

But it exits with status 0.
Both
- label: "Test command "
  commands:
    - "false"
    - "echo \"hello\""

and
- label: "Test command "
  commands:
    - "false && echo \"echo false\""

correctly exit with 1.

Hi @worxli, if you run your agent with --debug it should show you what shell is being used to invoke the commands, it sounds like it might not be the default of /bin/bash -e -c?

Hmmm, actually I think I can repeat the issue.

> $ /bin/bash -e -c "false && echo \"echo false\"\necho \"hello\""
hello

Very strange. 🤔

I'll investigate and get a fix out @worxli! Thanks for the report.

The simplest reproduction i can find is:
$ bash -e -c "false && :; echo end"
end

Ok, i see what the problem is now. set -e is more subtle than i realised:
It only cares about the return value of "simple statements" (i.e. statements that don't contain && or ||), or the last part of a &&/|| chain.
See https://stackoverflow.com/questions/25794905/why-does-set-e-true-false-true-not-exit for more context.
In this case, false && : - the last part (:) is never evaluated, so set -e ignores the line.
IOW, this isn't buildkite's fault :)
What could be improved, though, is changing one of the examples given in the docs:
steps:
  - commands:
    - "npm install && npm test"
    - "moretests.sh"
    - "build.sh"

(which is something we had looked at to make sure what we were doing was valid)

You're right @kormat, it does look like that is how bash works 🤷🏼♂ Very confusing! I'm not sure there is much we can do about it.
I'm going to close this one, as I reckon it's down to shell behaviour. Feel free to disagree if you have any suggestions!

authors: kormat lox worxli

repo: buildkite/agent


text:
Switch to less-diverged branch of ECR scan plugin

Context
Update our ECS scanning Buildkite plugin to a version that's closer to upstream:
Depends on https://github.com/buildkite/ecr-scan-results-buildkite-plugin/pull/11

Switch to updated plugin (closer to upstream)
Change format of ignore list, because upstream's parallel implementation is slightly different to ours
Add fail-build-on-plugin-failure flag, to preserve our current plugin behaviour

Hi @duckalini , this looks fine to, but as I'm not expert, I'll wait for someone in Platform to review this first.
Otherwise, if you have trouble getting this review, let me know—I can then approve it so you can merge this in.

authors: duckalini gilesgas

repo: buildkite/docs


text:
Ensure powershell scripts fail when executable fails

We have to explicitly test the exit status after running executables because powershell doesn't automatically fail when an executable's exit status is non-zero.
We've deployed these changes to our own Windows Buildkite packer template and it really increases the confidence that the powershell scripts haven't silently failed.

Ugh, so gross 😢
Are you sure there isn't an alternative?

Other than not use Powershell? Not that we've found. We got this guidance from a "Windows expert" (for whatever that's worth). But, for context, think of Powershell as a programming language, not a scripting one. You gotta tell Go when to exit, and with what error code.

At least here we don't have to handle nil :trollface:

Cool, let's merge this in. Is what it is!

authors: jeremiahsnapp lox tduffield

repo: buildkite/elastic-ci-stack-for-aws


text:
Add support for oid types

This PR closes #88.
Added support for oid types.

https://www.postgresql.org/docs/11/datatype-oid.html

Ran deno fmt against decode.ts and tests/data_types.ts.

https://travis-ci.com/buildondata/deno-postgres/builds/151413237
Oh, deno fmt --check fails...
Should I fix this problem in this PR?

Yikes, Deno is very outdated and now uses a new formatter. I've opened a PR to bump version: https://github.com/buildondata/deno-postgres/pull/90

Thanks @bartlomieju!
I'll rebase this on master.

Released in v0.3.7
https://github.com/buildondata/deno-postgres/releases/tag/v0.3.7

@bartlomieju Thanks!

repo: buildondata/deno-postgres


text:
Move 'forceLowerCase' to options - fixes #12

Addresses my issue regarding case sensitivity. This would simply add the flag to the options, defaulting to case-sensitive, which I would feel to be the most sensible value. If you disagree I'd be more than happy to change it back to default-lowercase if it meant getting this PR through. I plan to use this project quite heavily in a CLI for Buttercup.pw.

Nice, looks good to me 💯

authors: bukinoshita perry-mitchell

repo: bukinoshita/autocomplete-cli


text:
🛑 VODA-DRC is down

In e59d319, VODA-DRC ($SECRET_SITE1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: VODA-DRC is back up in 3d9230d after 1 hour, 35 minutes.

repo: buluma/uptime


text:
Support Controlled Tabs

Is your feature request related to a problem? Please describe.
I need to know which tab is active, so I can do something(fetch data for instance) when tab is in active state
Describe the solution you'd like
If tabs support the controlled state, I guess I can use the selectedId to know which tab is active
Describe alternatives you've considered

provide context store that I can get selectedId and use it to know which tab is active
provide a hook that returns whether tabId is active or not

Hey, sorry about the late reply. Ideally, it would be nice to create a pattern like Tabs.State or Tabs.useState just like we do for our Modals so you can choose to control the state. I'll need to add this in. I think it would also be nice to add a prop to defer mounting of a tab panel until the tab is clicked too, which may be a nicer solution to fetch data for a particular tab.

Thanks!! those will be very helpful features!!

authors: jxom sam-chuang

repo: bumbag/bumbag-ui


text:
Bundle Install Issue

I've been using Rails for about a year now. I just cloned a repository that I've been asked to take over. After cloning, I ran rake db:setup, per the README instructions. I received an error that version 2.3.1 wasn't installed. I used rbenv to install 2.3.1, than I set it up locally. I tried rake db:setup again and received the following error : LoadError: cannot load such file -- bundler/setup. Ran gem install bundler and tried running rake db:setup. I got this error: Could not find rake-12.0.0 in any of the sources Run bundle install to install missing gems. So I ran bundle install and got this.
--- ERROR REPORT TEMPLATE -------------------------------------------------------
Error Report
Questions
Please fill out answers to these questions, it'll help us figure out
why things are going wrong.

What did you do?
I ran the command /Users/joymccaffrey/.rbenv/versions/2.3.1/bin/bundle install

What did you expect to happen?
I expected Bundler to...

What happened instead?
Instead, what happened was...

Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?
I tried...

Have you read our issues document, https://github.com/bundler/bundler/blob/master/doc/contributing/ISSUES.md?
...

Backtrace
RuntimeError: Unable to find a spec satisfying qa (>= 0) in the set. Perhaps the lockfile is corrupted?
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/spec_set.rb:39:in `block in for'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/spec_set.rb:24:in `loop'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/spec_set.rb:24:in `for'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/spec_set.rb:79:in `materialize'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/definition.rb:199:in `missing_dependencies'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/installer.rb:219:in `block in resolve_if_need'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/ui/shell.rb:127:in `with_level'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/ui/shell.rb:86:in `silence'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/installer.rb:216:in `resolve_if_need'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/installer.rb:78:in `run'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/installer.rb:24:in `install'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/cli/install.rb:70:in `run'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/cli.rb:186:in `block in install'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/settings.rb:100:in `temporary'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/cli.rb:185:in `install'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/vendor/thor/lib/thor.rb:369:in `dispatch'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/cli.rb:20:in `dispatch'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/vendor/thor/lib/thor/base.rb:444:in `start'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/cli.rb:10:in `start'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/exe/bundle:35:in `block in <top (required)>'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/lib/bundler/friendly_errors.rb:121:in `with_friendly_errors'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.15.1/exe/bundle:27:in `<top (required)>'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/bin/bundle:23:in `load'
  /Users/joymccaffrey/.rbenv/versions/2.3.1/bin/bundle:23:in `<main>'

Environment
Bundler   1.15.1
Rubygems  2.5.1
Ruby      2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin16]
GEM_HOME  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0
GEM_PATH  /Users/joymccaffrey/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0:/Users/joymccaffrey/.gem/ruby/2.3.0
Git       2.11.0
Platform  x86_64-darwin-16
OpenSSL   OpenSSL 1.0.2l  25 May 2017

Bundler settings
gem.test
  Set for the current user (/Users/joymccaffrey/.bundle/config): "rspec"
gem.mit
  Set for the current user (/Users/joymccaffrey/.bundle/config): "false"
gem.coc
  Set for the current user (/Users/joymccaffrey/.bundle/config): "false"

Gemfile
Gemfile
source 'https://rubygems.org'

gem 'devise'
# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '~> 5.0.0'
# Use postgresql as the database for Active Record
gem 'pg', '~> 0.18'
# Use Puma as the app server
gem 'puma', '~> 3.0'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 5.0'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# Use CoffeeScript for .coffee assets and views
gem 'coffee-rails', '~> 4.2'

gem 'carrierwave'

gem 'rmagick'

gem 'fog'

gem 'twitter'
gem 'json'

# See https://github.com/rails/execjs#readme for more supported runtimes
# gem 'therubyracer', platforms: :ruby

# Use jquery as the JavaScript library
gem 'jquery-rails'
# Turbolinks makes navigating your web application faster. Read more: https://github.com/turbolinks/turbolinks
gem 'turbolinks', '~> 5'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.5'
gem 'font-awesome-rails'

# Use Redis adapter to run Action Cable in production
# gem 'redis', '~> 3.0'
# Use ActiveModel has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use Capistrano for deployment
# gem 'capistrano-rails', group: :development
gem 'faker', '~> 1.6'
gem 'angular-rails-templates'
gem 'roo'
# gem 'searchkick'

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug', platform: :mri
  gem "rspec-rails", "3.5.0"
  gem "factory_girl_rails", "~> 4.0"
  gem 'pry-rails'
  gem 'dotenv-rails'
  gem 'shoulda-matchers', '~> 3.1'

end

group :test do
  gem "capybara", "2.7.1"
  gem "database_cleaner"
  gem 'phantomjs', :require => 'phantomjs/poltergeist'
  gem 'poltergeist'
  gem 'teaspoon-jasmine'
  gem 'launchy', '~> 2.4'

end

group :development do
  # Access an IRB console on exception pages or by using <%= console %> anywhere in the code.
  gem 'web-console'
  gem 'listen', '~> 3.0.5'
  # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
end

# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]

Gemfile.lock
GEM
  remote: https://rubygems.org/
  specs:
    CFPropertyList (2.3.4)
    actioncable (5.0.1)
      actionpack (= 5.0.1)
      nio4r (~> 1.2)
      websocket-driver (~> 0.6.1)
    actionmailer (5.0.1)
      actionpack (= 5.0.1)
      actionview (= 5.0.1)
      activejob (= 5.0.1)
      mail (~> 2.5, >= 2.5.4)
      rails-dom-testing (~> 2.0)
    actionpack (5.0.1)
      actionview (= 5.0.1)
      activesupport (= 5.0.1)
      rack (~> 2.0)
      rack-test (~> 0.6.3)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.2)
    actionview (5.0.1)
      activesupport (= 5.0.1)
      builder (~> 3.1)
      erubis (~> 2.7.0)
      rails-dom-testing (~> 2.0)
      rails-html-sanitizer (~> 1.0, >= 1.0.2)
    activejob (5.0.1)
      activesupport (= 5.0.1)
      globalid (>= 0.3.6)
    activemodel (5.0.1)
      activesupport (= 5.0.1)
    activerecord (5.0.1)
      activemodel (= 5.0.1)
      activesupport (= 5.0.1)
      arel (~> 7.0)
    activesupport (5.0.1)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (~> 0.7)
      minitest (~> 5.1)
      tzinfo (~> 1.1)
    addressable (2.5.0)
      public_suffix (~> 2.0, >= 2.0.2)
    angular-rails-templates (1.0.2)
      railties (>= 4.2, < 6)
      sprockets (>= 3.0, < 5)
      tilt
    arel (7.1.4)
    bcrypt (3.1.11)
    buftok (0.2.0)
    builder (3.2.2)
    byebug (9.0.6)
    capybara (2.7.1)
      addressable
      mime-types (>= 1.16)
      nokogiri (>= 1.3.3)
      rack (>= 1.0.0)
      rack-test (>= 0.5.4)
      xpath (~> 2.0)
    carrierwave (1.0.0)
      activemodel (>= 4.0.0)
      activesupport (>= 4.0.0)
      mime-types (>= 1.16)
    cliver (0.3.2)
    coderay (1.1.1)
    coffee-rails (4.2.1)
      coffee-script (>= 2.2.0)
      railties (>= 4.0.0, < 5.2.x)
    coffee-script (2.4.1)
      coffee-script-source
      execjs
    coffee-script-source (1.12.2)
    concurrent-ruby (1.0.4)
    database_cleaner (1.5.3)
    debug_inspector (0.0.2)
    devise (4.2.0)
      bcrypt (~> 3.0)
      orm_adapter (~> 0.1)
      railties (>= 4.1.0, < 5.1)
      responders
      warden (~> 1.2.3)
    diff-lcs (1.2.5)
    domain_name (0.5.20161129)
      unf (>= 0.0.5, < 1.0.0)
    dotenv (2.1.1)
    dotenv-rails (2.1.1)
      dotenv (= 2.1.1)
      railties (>= 4.0, < 5.1)
    equalizer (0.0.11)
      qa
    erubis (2.7.0)
    excon (0.54.0)
    execjs (2.7.0)
    factory_girl (4.8.0)
      activesupport (>= 3.0.0)
    factory_girl_rails (4.8.0)
      factory_girl (~> 4.8.0)
      railties (>= 3.0.0)
    faker (1.7.2)
      i18n (~> 0.5)
    faraday (0.10.1)
      multipart-post (>= 1.2, < 3)
      qa
    ffi (1.9.14)
    fission (0.5.0)
      CFPropertyList (~> 2.2)
    fog (1.38.0)
      fog-aliyun (>= 0.1.0)
      fog-atmos
      fog-aws (>= 0.6.0)
      fog-brightbox (~> 0.4)
      fog-cloudatcost (~> 0.1.0)
      fog-core (~> 1.32)
      fog-dynect (~> 0.0.2)
      fog-ecloud (~> 0.1)
      fog-google (<= 0.1.0)
      fog-json
      fog-local
      fog-openstack
      fog-powerdns (>= 0.1.1)
      fog-profitbricks
      fog-rackspace
      fog-radosgw (>= 0.0.2)
      fog-riakcs
      fog-sakuracloud (>= 0.0.4)
      fog-serverlove
      fog-softlayer
      fog-storm_on_demand
      fog-terremark
      fog-vmfusion
      fog-voxel
      fog-vsphere (>= 0.4.0)
      fog-xenserver
      fog-xml (~> 0.1.1)
      ipaddress (~> 0.5)
    fog-aliyun (0.1.0)
      fog-core (~> 1.27)
      fog-json (~> 1.0)
      ipaddress (~> 0.8)
      xml-simple (~> 1.1)
    fog-atmos (0.1.0)
      fog-core
      fog-xml
    fog-aws (1.1.0)
      fog-core (~> 1.38)
      fog-json (~> 1.0)
      fog-xml (~> 0.1)
      ipaddress (~> 0.8)
    fog-brightbox (0.11.0)
      fog-core (~> 1.22)
      fog-json
      inflecto (~> 0.0.2)
    fog-cloudatcost (0.1.2)
      fog-core (~> 1.36)
      fog-json (~> 1.0)
      fog-xml (~> 0.1)
      ipaddress (~> 0.8)
    fog-core (1.43.0)
      builder
      excon (~> 0.49)
      formatador (~> 0.2)
    fog-dynect (0.0.3)
      fog-core
      fog-json
      fog-xml
    fog-ecloud (0.3.0)
      fog-core
      fog-xml
    fog-google (0.1.0)
      fog-core
      fog-json
      fog-xml
    fog-json (1.0.2)
      fog-core (~> 1.0)
      multi_json (~> 1.10)
    fog-local (0.3.1)
      fog-core (~> 1.27)
    fog-openstack (0.1.18)
      fog-core (>= 1.40)
      fog-json (>= 1.0)
      ipaddress (>= 0.8)
    fog-powerdns (0.1.1)
      fog-core (~> 1.27)
      fog-json (~> 1.0)
      fog-xml (~> 0.1)
    fog-profitbricks (3.0.0)
      fog-core (~> 1.42)
      fog-json (~> 1.0)
    fog-rackspace (0.1.2)
      fog-core (>= 1.35)
      fog-json (>= 1.0)
      fog-xml (>= 0.1)
      ipaddress (>= 0.8)
    fog-radosgw (0.0.5)
      fog-core (>= 1.21.0)
      fog-json
      fog-xml (>= 0.0.1)
    fog-riakcs (0.1.0)
      fog-core
      fog-json
      fog-xml
    fog-sakuracloud (1.7.5)
      fog-core
      fog-json
    fog-serverlove (0.1.2)
      fog-core
      fog-json
    fog-softlayer (1.1.4)
      fog-core
      fog-json
    fog-storm_on_demand (0.1.1)
      fog-core
      fog-json
    fog-terremark (0.1.0)
      fog-core
      fog-xml
    fog-vmfusion (0.1.0)
      fission
      fog-core
    fog-voxel (0.1.0)
      fog-core
      fog-xml
    fog-vsphere (1.6.0)
      fog-core
      rbvmomi (~> 1.9)
    fog-xenserver (0.2.3)
      fog-core
      fog-xml
    fog-xml (0.1.2)
      fog-core
      nokogiri (~> 1.5, >= 1.5.11)
    font-awesome-rails (4.7.0.1)
      railties (>= 3.2, < 5.1)
    formatador (0.2.5)
    globalid (0.3.7)
      activesupport (>= 4.1.0)
    http (2.1.0)
      addressable (~> 2.3)
      http-cookie (~> 1.0)
      http-form_data (~> 1.0.1)
      http_parser.rb (~> 0.6.0)
    http-cookie (1.0.3)
      domain_name (~> 0.5)
    http-form_data (1.0.1)
    http_parser.rb (0.6.0)
      qa
    i18n (0.7.0)
    inflecto (0.0.2)
    ipaddress (0.8.3)
    jbuilder (2.6.1)
      activesupport (>= 3.0.0, < 5.1)
      multi_json (~> 1.2)
    jquery-rails (4.2.2)
      rails-dom-testing (>= 1, < 3)
      railties (>= 4.2.0)
      thor (>= 0.14, < 2.0)
    json (2.0.2)
    launchy (2.4.3)
      addressable (~> 2.3)
    listen (3.0.8)
      rb-fsevent (~> 0.9, >= 0.9.4)
      rb-inotify (~> 0.9, >= 0.9.7)
    loofah (2.0.3)
      nokogiri (>= 1.5.9)
    mail (2.6.4)
      mime-types (>= 1.16, < 4)
    memoizable (0.4.2)
      thread_safe (~> 0.3, >= 0.3.1)
    method_source (0.8.2)
    mime-types (3.1)
      mime-types-data (~> 3.2015)
    mime-types-data (3.2016.0521)
    mini_portile2 (2.1.0)
    minitest (5.10.1)
    multi_json (1.12.1)
    multipart-post (2.0.0)
    naught (1.1.0)
      qa
    nio4r (1.2.1)
    nokogiri (1.7.0)
      mini_portile2 (~> 2.1.0)
    orm_adapter (0.5.0)
    pg (0.19.0)
    phantomjs (2.1.1.0)
    poltergeist (1.12.0)
      capybara (~> 2.1)
      cliver (~> 0.3.1)
      websocket-driver (>= 0.2.0)
    pry (0.10.4)
      coderay (~> 1.1.0)
      method_source (~> 0.8.1)
      slop (~> 3.4)
    pry-rails (0.3.4)
      pry (>= 0.9.10)
    public_suffix (2.0.5)
    puma (3.6.2)
    rack (2.0.1)
    rack-test (0.6.3)
      rack (>= 1.0)
    rails (5.0.1)
      actioncable (= 5.0.1)
      actionmailer (= 5.0.1)
      actionpack (= 5.0.1)
      actionview (= 5.0.1)
      activejob (= 5.0.1)
      activemodel (= 5.0.1)
      activerecord (= 5.0.1)
      activesupport (= 5.0.1)
      bundler (>= 1.3.0, < 2.0)
      railties (= 5.0.1)
      sprockets-rails (>= 2.0.0)
    rails-dom-testing (2.0.2)
      activesupport (>= 4.2.0, < 6.0)
      nokogiri (~> 1.6)
    rails-html-sanitizer (1.0.3)
      loofah (~> 2.0)
    railties (5.0.1)
      actionpack (= 5.0.1)
      activesupport (= 5.0.1)
      method_source
      rake (>= 0.8.7)
      thor (>= 0.18.1, < 2.0)
    rake (12.0.0)
    rb-fsevent (0.9.8)
    rb-inotify (0.9.7)
      ffi (>= 0.5.0)
    rbvmomi (1.9.4)
      builder (~> 3.2)
      json (>= 1.8)
      nokogiri (~> 1.5)
      trollop (~> 2.1)
    responders (2.3.0)
      railties (>= 4.2.0, < 5.1)
    rmagick (2.16.0)
    roo (2.7.0)
      nokogiri (~> 1)
      rubyzip (~> 1.1, < 2.0.0)
    rspec-core (3.5.4)
      rspec-support (~> 3.5.0)
    rspec-expectations (3.5.0)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.5.0)
    rspec-mocks (3.5.0)
      diff-lcs (>= 1.2.0, < 2.0)
      rspec-support (~> 3.5.0)
    rspec-rails (3.5.0)
      actionpack (>= 3.0)
      activesupport (>= 3.0)
      railties (>= 3.0)
      rspec-core (~> 3.5.0)
      rspec-expectations (~> 3.5.0)
      rspec-mocks (~> 3.5.0)
      rspec-support (~> 3.5.0)
    rspec-support (3.5.0)
    rubyzip (1.2.0)
    sass (3.4.23)
    sass-rails (5.0.6)
      railties (>= 4.0.0, < 6)
      sass (~> 3.1)
      sprockets (>= 2.8, < 4.0)
      sprockets-rails (>= 2.0, < 4.0)
      tilt (>= 1.1, < 3)
    shoulda-matchers (3.1.1)
      activesupport (>= 4.0.0)
    simple_oauth (0.3.1)
    slop (3.6.0)
    spring (2.0.0)
      activesupport (>= 4.2)
    spring-watcher-listen (2.0.1)
      listen (>= 2.7, < 4.0)
      spring (>= 1.2, < 3.0)
    sprockets (3.7.1)
      concurrent-ruby (~> 1.0)
      rack (> 1, < 3)
    sprockets-rails (3.2.0)
      actionpack (>= 4.0)
      activesupport (>= 4.0)
      sprockets (>= 3.0.0)
    teaspoon (1.1.5)
      railties (>= 3.2.5, < 6)
    teaspoon-jasmine (2.3.4)
      teaspoon (>= 1.0.0)
    thor (0.19.4)
    thread_safe (0.3.5)
    tilt (2.0.5)
    trollop (2.1.2)
    turbolinks (5.0.1)
      turbolinks-source (~> 5)
    turbolinks-source (5.0.0)
    twitter (6.0.0)
      addressable (~> 2.5)
      buftok (~> 0.2.0)
      equalizer (= 0.0.11)
      faraday (~> 0.10.0)
      http (~> 2.1)
      http_parser.rb (~> 0.6.0)
      memoizable (~> 0.4.2)
      naught (~> 1.1)
      simple_oauth (~> 0.3.1)
    tzinfo (1.2.2)
      thread_safe (~> 0.1)
    uglifier (3.0.4)
      execjs (>= 0.3.0, < 3)
    unf (0.1.4)
      unf_ext
    unf_ext (0.0.7.2)
    warden (1.2.6)
      rack (>= 1.0)
    web-console (3.4.0)
      actionview (>= 5.0)
      activemodel (>= 5.0)
      debug_inspector
      railties (>= 5.0)
    websocket-driver (0.6.4)
      websocket-extensions (>= 0.1.0)
    websocket-extensions (0.1.2)
    xml-simple (1.1.5)
    xpath (2.0.0)
      nokogiri (~> 1.3)

PLATFORMS
  ruby

DEPENDENCIES
  angular-rails-templates
  byebug
  capybara (= 2.7.1)
  carrierwave
  coffee-rails (~> 4.2)
  database_cleaner
  devise
  dotenv-rails
  factory_girl_rails (~> 4.0)
  faker (~> 1.6)
  fog
  font-awesome-rails
  jbuilder (~> 2.5)
  jquery-rails
  json
  launchy (~> 2.4)
  listen (~> 3.0.5)
  pg (~> 0.18)
  phantomjs
  poltergeist
  pry-rails
  puma (~> 3.0)
  rails (~> 5.0.0)
  rmagick
  roo
  rspec-rails (= 3.5.0)
  sass-rails (~> 5.0)
  shoulda-matchers (~> 3.1)
  spring
  spring-watcher-listen (~> 2.0.0)
  teaspoon-jasmine
  turbolinks (~> 5)
  twitter
  tzinfo-data
  uglifier (>= 1.3.0)
  web-console

BUNDLED WITH
   1.12.5

--- TEMPLATE END ----------------------------------------------------------------
Unfortunately, an unexpected error occurred, and Bundler cannot continue.
First, try this link to see if there are any existing issue reports for this error:
https://github.com/bundler/bundler/search?q=Unable+to+find+a+spec+satisfying+qa+(>%3D+0)+in+the+set.+Perhaps+the+lockfile+is+corrupted%3F&type=Issues
If there aren't any reports for this error yet, please create copy and paste the report template above into a new issue. Don't forget to anonymize any private data! The new issue form is located at:
https://github.com/bundler/bundler/issues/new
Please help. :)

Your lockfile appears to be corrupted -- it is indeed missing the qa specification in the list of specs

Great! I assume you're referring to the Gemfile.lock, where there are a number of references to qa. And by specification do you mean a version number following it? And if so, which one, and how do I uncorrupt it? Or is it missing a qa specification in the Gemfile.lock, and if so, how do I add it? And how would this have happened? This is the first time I'm looking at this project's code. Thanks for your help!

And how would this have happened?

Old versions of Bundler were buggy and somehow didn't put all the specs in the Lockfile. I haven't seen this happen with versions of bundler >= 1.13 so I don't know the specifics

I'm closing this for now. If you're still experiencing your original issue or have any more questions don't be afraid to re-open this ticket.

@colby-swandale - I am seeing the same issue with bundler 1.15.0 in AWS Elastic Beanstalk environment.  I created a sample Rails app (eg. rails new sample) added .ebextensions/01_infra.config with the following environment variables being set just to satisfy the environment enough to get running:
option_settings:   aws:elasticbeanstalk:application:environment:     SECRET_KEY_BASE: <key>     RAILS_SKIP_MIGRATIONS: true
And when I deploy I can see the following in the log file:
/opt/rubies/ruby-2.3.4/lib/ruby/gems/2.3.0/gems/bundler-1.15.0/lib/bundler/spec_set.rb:39:in 'block in for': Unable to find a spec satisfying byebug in the set. Perhaps the lockfile is corrupted? (RuntimeError) 	from /opt/rubies/ruby-2.3.4/lib/ruby/gems/2.3.0/gems/bundler-1.15.0/lib/bundler/spec_set.rb:24:in 'loop' 	from /opt/rubies/ruby-2.3.4/lib/ruby/gems/2.3.0/gems/bundler-1.15.0/lib/bundler/spec_set.rb:24:in 'for' 	from /opt/rubies/ruby-2.3.4/lib/ruby/gems/2.3.0/gems/bundler-1.15.0/lib/bundler/definition.rb:218:in 'specs_for' 	from ./check-for-gem.rb:27:in '<main>'
Doing some debugging, it looks like the call to Bundler.definitions.groups isn't returning the expected results.  However, if I downgrade the bundler to 1.13.6 it seems to work.  What is the difference between 1.13.6 and 1.15.0 in how Bundler determines the groups?

@anthony-vin65 please open a new issue with the details of your problem.

@anthony-vin65 @colby-swandale I'm also having this issue with AWS ElasticBeanstalk today, after upgrading to their latest Ruby Puma Amazon Linux image. Did Anthony open a new issue for this one yet?
Anthony - you said you were able to downgrade to 1.13.6 to solve the problem.
Colby - Elastic Beanstalk is failing in a script they've provided called check-for-gem.rb:
#!/usr/bin/env /opt/rubies/ruby-current/bin/ruby
#==============================================================================
# Copyright 2014 Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Amazon Software License (the "License"). You may not use
# this file except in compliance with the License. A copy of the License is
# located at
#
#       https://aws.amazon.com/asl/
#
# or in the "license" file accompanying this file. This file is distributed on
# an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or
# implied. See the License for the specific language governing permissions
# and limitations under the License.
#==============================================================================
require 'bundler'

Dir.chdir '/var/app/ondeck'
groups = Bundler.definition.groups

begin
    Bundler.definition.resolve_with_cache!
rescue Bundler::GemNotFound
    Bundler.definition(true).resolve_remotely!
end

gems = Bundler.definition.specs_for(groups).collect(&:name)
exit 0 if gems.include? ARGV[0]

Tweaking that slightly I get:
irb(main):014:0> groups.map { |g| Bundler.definition.specs_for([g]).count rescue "#{g} failed" }
=> [197, 11, "development failed", "test failed"]

Whereas on an older AWS ElasticBeanstalk box running bundler 1.12.1 I get:
irb(main):005:0> groups.map { |g| Bundler.definition.specs_for([g]).count rescue "#{g} failed" }
=> [197, 11, 1, 1]
irb(main):007:0> groups.map { |g| Bundler.definition.specs_for([g]).collect(&:name).first rescue "#{g} failed" }
=> ["rake", "i18n", "bundler", "bundler"]

ie. it looks like the change in behaviour is that bundler always used to count itself in the definiton for empty groups, but now it doesn't and fails on empty groups.
Test and Development groups are "empty" because of:
$ cat .bundle/config
---
BUNDLE_DISABLE_SHARED_GEMS: "true"
BUNDLE_WITHOUT: "test:development"

I think?

Sorry to dump this comment on a closed issue. Hopefully @anthony-vin65 has opened his new issue and these details can be copied over to that one if they're still relevant.
Thanks!

@kaoru A new issue was never opened, it would be appreciated if you opened a new issue with the details of your problem. You can follow Bundler's ISSUES guide for more information.

@colby-swandale I've managed to reproduce the issue with a small example, and opened an issue here: https://github.com/bundler/bundler/issues/6017

I did rbenv install 2.6.1 as per instructions on how to install rails on Mojave.  I checked it's version, etc.  Then cd'd to my rails-devise-user directory cloned from GitHub.  It worked on a High Sierra laptop.  Now, I type rails -v and it says: version 2.3.1 is not installed.  It is specified in the Gemfile.  I then do: rbenv install 2.3.1.  It installs.  Then type rails -v and get
rbenv: rails: command not found
The `rails' command exists in these Ruby versions:
2.6.1
What is going on?  On the high sierra laptop, that command works fine?

authors: anthony-vin65 chijoy colby-swandale kaoru segiddins woo37830

repo: bundler/bundler


text:
update path already exists error message to not be specific to symlinks

If i'm attempting to install my gems into a folder that conflicts with a file that already exists, Bundler will raise the following error:
Could not install to path `vendor` because of an invalid symlink. Remove the symlink so the directory can be created.

But this error will be raised even if its just a regular ol file and not a symlink. IMO its a better user experience to drop the symlink mention and ask the user to simply move or rename the file.
Example:
Could not install to path `vendor` because a file already exists at that path. Either remove or rename the file so the directory can be created.

👍🏻

@homu r+

:pushpin: Commit 213704c has been approved by indirect

:hourglass: Testing commit 213704c with merge e7b9f2f...

:sunny: Test successful - status

authors: colby-swandale homu indirect segiddins


text:
Change deprecation from bundle list to bundle show

What was the end-user problem that led to this PR?
I understand that bundle show will be removed in Bundler 2.0, not bundle list.
https://github.com/bundler/rfcs/pull/6/files#r125875779
In the current message, there is a possibility of misleading the command which will be removed in Bundler 2.0.
What was your diagnosis of the problem?
I think that it is better to display bundle show instead of bundle list in the deprecated warning.
What is your fix for the problem, implemented in this PR?
Change the deprecated warning from bundle list to bundle show.
Why did you choose this fix out of the possible options?
I thought that changing the console message was a simple and effective change to the end user.

@colby-swandale please review?

This looks fine but @indirect are we ok to change an existing deprecation message?

Yeah, I think this is fine... printing a deprecation message doesn't count as semver imo 👍🏻
@koic thanks!
@bundlerbot r+

Thank you all!

authors: colby-swandale indirect koic segiddins


text:
列表中带查询条件的是没有实现吗

点击查询，没有传查询条件

实现了呀，可以参考这个demo或代码，有个别页面的搜索条件只是摆设而已，并没有将实际的查询条件当做参数传递

看到了，但有个问题，如果查询条件是'RangePicker',怎么能将开始和结束日期拆成两个字段传值呢

你在调用接口之前，手动改一下参数就好了呀！这个应该不算大问题吧？如果觉得这样麻烦的话，后续我考虑一下 看看怎么支持多字段比较好

到api接口时，怎么把一个字段拆成两个字段传值呢

😢啊这...你看这样行吗？
  const loadData = async (params) => {
  const [field1, field2] = params.目标字段
   const  _params = {
       ...params,
       field1,
       field2
   }
    const { data } = await getLolHeroList(params);
    tableData = data.list;
    return data;
  }


text:
Refactor, test and document eviction mechanisms

We need to refactor, test and document the existed eviction mechanisms.
Fix #7 and #8 firstly.

On the topic of your eviction mechanisms, I wanted to ask about a particular eviction policy. I want to look into upgrading a particular LRU cache node in my application to be distributed instead of single node. But currently it relies on an LRU which supports value types that provide a Size() method. And the eviction policy can do MaxSize. Have you considered this policy as a feature?

Hi @justinfx. I understand your case. Implementing that feature is not hard and it's definitely useful. Olric evicts keys when a DMap object exceeds the given size limit. Is that useful for you? Would you like to explain the details of your use case?

Thanks for the reply! Well the item count of the cache is actually not what I need, since my concern is the total "cost" which in this case is RAM. So I am caching images and I only want to cache up to, say, 4GB of the most recently accessed items, and I want it to evict least recently used to bring the side under the target.
This is what I am using:
https://godoc.org/github.com/vitessio/vitess/go/cache
You can see that the Value that goes into the cache defines a Size() and then the cache can have a max size.

Design note: Every node stores some part of a DMap. So every node tracks the size of its own DMap part and evicts the keys when the given size exceeded. There is no central node to decide evict the keys.

It would be completely acceptable to have the cost apply per node as opposed to the entire cache. I cant speak for other uses of a "cost" but specifically for RAM, it would make sense for a node.

Thanks for the reply! Well the item count of the cache is actually not what I need, since my concern is the total "cost" which in this case is RAM. So I am caching images and I only want to cache up to, say, 4GB of the most recently accessed items, and I want it to evict least recently used to bring the cost under the target.
This is what I am using:
https://godoc.org/github.com/vitessio/vitess/go/cache
You can see that the Value that goes into the cache defines a Size() and then the cache can have a max size.

I'll review that package and implement the feature in a convenient way.

@justinfx
Hi, I have implemented the feature you requested. I'm still iterating over eviction code and the documentation is not up-to-date. However it works fine most of time. If you want to give a try, I would like to assist you. You may help me improve the implementation and fix possible design flaws at an early stage.
Thanks in advance.

Thanks! I'm going to have some time over this holiday to have a play. Are there any links to the added api and test examples? I did a quick search and found this:
https://github.com/buraksezer/olric/blob/feature/issue-9/dmap_eviction_test.go#L175
How does one specify the size cost when putting an items?
The comment on that test link suggests that the configured max size is split across the number of partitions? With that implementation would I be able to accurately limit a node in the cluster to 4G or is it going to depend on how many partitions are distributed?

Olric uses MaxInuse property to limit memory usage of a DMap instance. MaxKeys controls maximum key count on a DMaps.

The comment on that test link suggests that the configured max size is split across the number of partitions?

Yes, it is. DMaps are evenly distributed among partitions. So if you set MaxInuse as 4G for a DMap instance while your partition count is 271, used memory(inuse) by a chunk of the DMap should be around 15M.  So MaxInuse property is global.
If you have a cluster which consists of 6 nodes, every node should have ~45 partitions. And every partition has its own DMap chunk which consumes ~15M in RAM. So every node consumes 675M of RAM.
You should know that Olric uses an append-only file with a hash table as storage engine. It allocates ~30M to store your ~15M DMap instance. So the actual memory cost is much more different.  You can use olric-stats command to see statistics about DMaps on different partitions.
olric-stats -p 69
PartID: 69
  Owner: olric.node:3320
  Previous Owners: not found
  Backups: not found
  DMap count: 1
  DMaps:
    Name: olric-load-test
    Length: 1374
    Allocated: 1048576
    Inuse: 47946
    Garbage: 0

With that implementation would I be able to accurately limit a node in the cluster to 4G or is it going to depend on how many partitions are distributed?

With the current state of the implementation, you can limit Inuse property of partitions and nodes. As you can see in the output of olric-stats, Allocated space is much more different than Inuse.  As you know, the memory is controller by Go runtime and there is other parts of the storage engine which consumes memory. So the actual memory is used by the process should be totally different than the sum of Allocated properties of partitions.
I prepared the configuration files to test the algorithm with 2 nodes: https://gist.github.com/buraksezer/83e1a43f972c1c5bab3aa8b774bcb16c
There are two config file in this gist. Run Olric nodes on your localhost like the following:
olricd -c olricd1.yaml

# on a different terminal

olricd -c olricd2.yaml

Then, you can run olric-load to test your setup:
olric-load -a localhost:3320,localhost:3321 -k 1000000 -c put -s msgpack

This command calls Put command on the cluster 1M times. olric-stats can be used to analyze internal status of Olric nodes:
olric-stats -a localhost:3320

This scenario assumes that your preferred deployment way is client-server mode. If you want to use embedded-member mode, please let me know. Memberlist configuration can be tricky, but the source code of olricd can be used to seed your application.
If you have any further questions, please don't hesitate to ask.
Thanks for your contribution.

Thanks for the clarification.
My goal is to use it embedded in my distributed caching service and be able to scale up from 1-2 to more depending on load. I'm concerned with the current implementation of the max cache size being a factor of the number of partitions across the available nodes, that it would be difficult to effectively utilise the available Max ram on the node since it would always have to be configured based on the total node count. If I have 2x 4G nodes and I set a max inuse that can make sure to use 3G of each node, then I scale to 3 nodes, do I have to redo the math and restart the embedded caches?

Good catch! I reviewed the algorithm. Here is my proposal:
User's perspective: I may have any number of Olric nodes and I want to ensure that a DMap on the cluster should not consume more than 3G in-use memory for every host. So my distributed map instance consumes n*3G at maximum on the cluster. The cluster may scale up or down. That's not matter.
How to implement that feature: Keys on a DMap are evenly distributed among partitions and partitions manage their own resources. So before deciding to evict a key, the algorithm needs to know the currently hosted partition count on the node. If you have 2 nodes with 271 partitions, the nodes have 135 partitions and every partition responsible for its own DMap chunk. So when we want to evict a key, we need to calculate MaxInuse/currentPartitionCount to determine maximum memory limit for a chunk. In the case of MaxInuse=3G, the chunks on partitions cannot exceeds ~23M.
It's easy to implement. Could you please review the proposal for your case?
Thank you!

I wanted to first say thank you for your level of responsiveness and willingness to consider my feedback on these user-facing design decisions, even when I am only a prospective user at this point. I really appreciate your open source contribution and your positive and welcoming attitude on your project.
From the user perspective, the proposal does sound like it matches my expectation. I will be a bit redundant in reiterating some of the proposal points, just to reenforce that we are on the same page. I think this proposal is good because from the users point of view, they likely care much less about the combined cluster size and the individual partition count at any point in time, and really the concern is how much of the current node resources can be applied to the caching. Setting a MaxInuse=3G for one specific node instance configuration is the ideal way to go, since it would allow me to scale the cluster up and down while preserving the desired resource target limits.
At this stage I am still running a particular service on a pair of VMs, each with a fixed amount of ram, so I set my configuration for the single caching front-end to a specific fraction of the available ram. Even when I finally get this service switched to a kubernetes deployment with dynamic scaling, it will be beneficial to be able to associate the MaxInuse value with a since pod instance, so that the container scheduler can consider that metric as part of the scaling factor.
Thanks! Once this feature is available, I will have a go at embedding it into my service. For more context about my service, there is a single api frontend which contains the embedded LRU cache, and then scalable distributed workers which do the cache-filling process as needed. My goal had been to keep the cache embedded, which is why it is still a single frontend. But once I can use olric, it means I can embed it into the api frontend and run more than one behind a load balancer and gain the ability to do rolling restarts/upgrades without losing the cache, since ideally it would replicate again.

You're welcome. I have been building Olric for almost 2 years and It's a pleasure to see that someone intents to use it in production.

it means I can embed it into the api frontend and run more than one behind a load balancer and gain the ability to do rolling restarts/upgrades without losing the cache, since ideally it would replicate again.

At this point, I should share more information about the replication algorithm. Olric implements a quorum based approach to replicate key/value pairs across the cluster. Let's take look at the following sample.
You have ReplicationFactor=2, WriteQuorum=1 and ReadQuorum=1. With this configuration, every partition has 2 replicas on different hosts. When you want to write a key, Olric finds the replication owners. One of them the partition owner which manages the whole process.  It tries to write the given key/value pair on its own storage and the backup host. Only one successful write operation is enough to assume the whole operation is successful. In write operation, a timestamp is stored along with the key/value pair. This timestamp is used to reconcile different versions of keys and it's provided by the clients.
When you want to read a key, Olric finds the replication owners and tries to read the given key on those hosts. Then sorts the responses and selects the recent one. This is called Last Write Wins policy. Only one successful read operation is enough to assume the whole operation is successful.
In the case of node departure, Olric doesn't try to create new replicas for missing partitions. If a replica node is still available, your keys are still available. If you set ReadRepair=true,  Olric creates new copies to satisfy ReplicationFactor=2 when you call read command on the keys.
Read repair logic runs for every read request, if it's enabled. So possible inconsistencies in partitions are repaired by read repair mechanism. It currently works synchronously. We may improve it in a future milestone.
For an embedded LRU cache deployment, it's good to set ReplicationFactor=1, WriteQuorum=1 and ReadQuorum=1. It means that when you restart a node, some part of the data will miss. But this setup will be very fast.
I recommend set to ReplicationFactor=2, WriteQuorum=1 and ReadQuorum=1, if you want redundancy.
Here is some benchmark data I remember that I had set ReplicationFactor=2, WriteQuorum=1 and ReadQuorum=1 for this test. It tries to set 1M keys by using msgpack as serialization format.
I may miss some of the details, please don't hesitate to ask about design and implementation details.
Keep in touch!

I have implemented the new MaxInuse algorithm. You can test it by pullingfeature/issue-9 branch. As I explained previously, olric-stats or raw Stats command can be used to monitor in-use memory by partitions and DMap instances.
I'm also planning to implement MaxAllocated logic to prevent getting run out of memory panics. Please see this https://github.com/golang/go/issues/14162 and this https://github.com/golang/go/issues/16843

Hey @justinfx. I wonder whether you used Olric in your project. Thanks!

Hi. Sorry for not providing any feedback. It has been a busy start of the year after I returned from holidays. I would really like to be able to try integrating this work within the next 2 weeks. Thanks!

I've started trying to integrate olric to replace my local LRU cache. I still don't have it working yet, but here is my initial feedback...
If I set CacheConfig.MaxInuse value it seems that I also have to set all the required default fields like Read/Write Quorum as well, or olric will fail saying:
failed to construct LRU cache: 3 errors occurred:
        * cannot specify ReadQuorum less than or equal to zero
        * cannot specify WriteQuorum less than or equal to zero
        * cannot specify MemberCountQuorum smaller than MinimumMemberCountQuorum

There is no config.NewDefaultConfig(), where I can adjust the settings I want without having to know which other ones also need to be set.
Olric.Start() is a blocking call, so I need to start it in a goroutine. But then I don't really have a nice way to know when it is started. If I try to create my db.NewDMap too quickly I get "cannot be reached cluster quorum to operate". So I have to sleep for a second first. I suppose I could loop on calling Ping() until it succeeds, but that is also not so great. Might be nice if there were an optional Started func() callback field. I could optionally set a callback function to know when it is ready. I think nats.io server offered something similar for when you are embedding their gnatds, starting it, and need to block until its ready to proceed.
As mentioned in the README, the memberlist config is a bit complicated and I don't fully understand if I need to establish 2 ports per node, or if any of it can be emphemeral (:0). I have to do something like this for my single node test:
	m1, _ := olricconfig.NewMemberlistConfig("local")
	m1.BindAddr = "127.0.0.1"
	m1.BindPort = 5555

	ocfg := &olricconfig.Config{
		Cache: &olricconfig.CacheConfig{
			TTLDuration: 3 * 24 * time.Hour,
			MaxInuse:    conf.Int("maxCacheMB") * 1024 * 1024,
		},

		MaxJoinAttempts: 10,
		ReplicationMode: olricconfig.AsyncReplicationMode,

		// TODO: olric doesn't allow for creating a default config.
		// Have to fill in required field if setting some fields.
		Name:              "127.0.0.1:5556",
		ReplicaCount:      1,
		WriteQuorum:       1,
		ReadQuorum:        1,
		MemberCountQuorum: 1,
		MemberlistConfig:  m1,
	}

And where I am currently stuck is that I don't seem to be getting olric to save my keys. When I do a Get for the first time, the cache miss causes this log output:
2020/02/20 14:37:53 [ERROR] Failed to get key from local storage: key not found => dmap_get.go:61

I then have some logging to ensure the Put is being called, but it never seems to increment the length counter in the partition stats, and future Get continues emitting the key is not found. I feel like I might have gotten something wrong in the configuration.
Last few notes are things I currently can't do with olric that I was able to do in my local LRU.
For my cache invalidation logic, I was able to take a key prefix and iterate all the keys in the cache, to evict the ones that match the prefix. Olric doesn't provide a way to get the list of keys. Does this have any value to you as a feature?
And for stats collection I used to be able to get some time stats on the oldest cached item (and I would track the newest manually) so I could report the cache ages. Not sure if this is valuable to you.
Thanks!

Hi @justinfx I have just created a gist for you to test Olric with two members in a single process. I hope that it will help to fix the problem.
Here is the code: https://gist.github.com/buraksezer/66f6e02bce8cebd9cfba8b5aaf2976a1
You should note that Olric currently needs to know at least one member of the cluster to join. So I added the following line to your config struct for the second node:
Peers:             []string{"127.0.0.1:5555"},
You should see the following lines on the console:
tardis:future buraksezer$ go run olric.go
Awaiting for background goroutines
2020/02/20 08:17:12 [INFO] Join completed. Synced with 0 initial nodes: 1 => olric.go:345
2020/02/20 08:17:12 [DEBUG] memberlist: Stream connection from=127.0.0.1:55539
2020/02/20 08:17:12 [DEBUG] memberlist: Initiating push/pull sync with: 127.0.0.1:5555
2020/02/20 08:17:12 [INFO] Join completed. Synced with 1 initial nodes: 2 => olric.go:345
2020/02/20 08:17:12 [INFO] Node joined: 127.0.0.1:6667 => routing.go:368
2020/02/20 08:17:12 [INFO] AdvertiseAddr: , AdvertisePort: 7946 => olric.go:409
2020/02/20 08:17:12 [INFO] Cluster coordinator: 127.0.0.1:5556 => olric.go:412
2020/02/20 08:17:12 [INFO] Node joined: 127.0.0.1:5556 => routing.go:368
2020/02/20 08:17:12 [INFO] Routing table has been pushed by 127.0.0.1:5556 => routing.go:489
2020/02/20 08:17:12 [INFO] Routing table has been pushed by 127.0.0.1:5556 => routing.go:489
2020/02/20 08:17:12 [INFO] The cluster coordinator has been bootstrapped => olric.go:322
2020/02/20 08:17:12 [INFO] AdvertiseAddr: , AdvertisePort: 7946 => olric.go:409
2020/02/20 08:17:12 [INFO] Cluster coordinator: 127.0.0.1:5556 => olric.go:412
2020/02/20 08:17:12 [INFO] Routing table has been pushed by 127.0.0.1:5556 => routing.go:489
2020/02/20 08:17:12 [INFO] Routing table has been pushed by 127.0.0.1:5556 => routing.go:489
{num: 0 0} main.customType
{num: 1 1} main.customType
{num: 2 2} main.customType
{num: 3 3} main.customType
{num: 4 4} main.customType
{num: 5 5} main.customType

An automatic discovery mode may be implemented in 0.3.x milestone by using service discovery components of Kubernetes, AWS, or Consul.
NewDefaultConfig is a great idea. I'm going to implement it along with a config validation feature.
I'm going to prepare a detailed answer for rest of the comment.
Thank you very much for the feedback!

Might be nice if there were an optional Started func() callback field.

Good idea. I'll investigate the ways of implementing this in a clear way.

Last few notes are things I currently can't do with olric that I was able to do in my local LRU.
For my cache invalidation logic, I was able to take a key prefix and iterate all the keys in the cache, to evict the ones that match the prefix. Olric doesn't provide a way to get the list of keys. Does this have any value to you as a feature?

Prefix scan is impossible to implement. Because Olric uses the builtin map to index hashed keys on to log files (they are actually byte slices in the process heap). A prefix scan requires O(n) time to run. In future, we may implement a pluggable storage engine for that kind of future.
Would you like to explain your cache invalidation logic?  Olric doesn't need a prefix scan to evict keys.

And for stats collection I used to be able to get some time stats on the oldest cached item (and I would track the newest manually) so I could report the cache ages. Not sure if this is valuable to you.

Could you please give more details for this? Cache stats are absolutely valuable for me. I can implement that feature before the release, if it's urgent to you.

I then have some logging to ensure the Put is being called, but it never seems to increment the length counter in the partition stats, and future Get continues emitting the key is not found. I feel like I might have gotten something wrong in the configuration.

Stats command is not distributed. The nodes return their own stats. If the Put call hits the node1 and you call Stats command on node2, you cannot see increment the length counter in the partition stats.
A distributed version is possible. We also need to add a new command to return the current list of members in the cluster.

Thanks for the gist example. It confirms that I need to be explicit with the ports.

Would you like to explain your cache invalidation logic? Olric doesn't need a prefix scan to evict keys.

I don't need olric to perform the prefix scan. I format my cache keys as combination of properties. When a certain asset has changed in my external system I want to evict all variations of the cached data for that asset. The asset id in this case is the prefix of the key. So I was able to just iterate the keys in the cache, string match, and optionally evict.
An example would be if I were caching "foo::green" and "foo::red". Then I find I need to invalidate "foo", so there are 2 keys that need to be evicted.

Cache stats are absolutely valuable for me. I can implement that feature before the release, if it's urgent to you.

They actually weren't critical stats. Just reporting something I used to be able to report on. They were just timestamps tracking the age of cached items. So I could see how old the oldest item in the cache was.

Stats command is not distributed.

Good to know! It wasn't obvious because of how the stats report members and partitions and dmaps. But now I understand that they only reflect the data on the given reporting node. So I would have to iterate the member list with a client connection to see how much of the total distributed cache is being used.
However this doesn't help with my blocking problem. I'm not even testing multi nodes yet. So I haven't gotten to configuring two nodes. I simply can't even get it to store the key on the single node so I figured I must have configured something wrong. The stats on the same node don't report a length.

However this doesn't help with my blocking problem. I'm not even testing multi nodes yet. So I haven't gotten to configuring two nodes. I simply can't even get it to store the key on the single node so I figured I must have configured something wrong. The stats on the same node don't report a length.

As far as I understand, you are trying to run a single node but it fails constantly. Could you please the logs? I tried to run a single node with the config you provided, it runs well:
https://gist.github.com/buraksezer/3da18131736336685399e6391c50bd14
The output of olric-stats -a 127.0.0.1:5556:
Total length of partitions: 10
Total partition count: 271
Total Allocated: 10485760
Total Inuse: 1018
Total Garbage: 0

I just noticed a bug. If you create an Olric node with nil config, it tries to bind an ephemeral port and propagate 127.0.0.1:0 as it's address. Then the TCP client fails to dial it. I'll fix it as soon as possible.

I don't need olric to perform the prefix scan. I format my cache keys as combination of properties. When a certain asset has changed in my external system I want to evict all variations of the cached data for that asset. The asset id in this case is the prefix of the key. So I was able to just iterate the keys in the cache, string match, and optionally evict.

Olric can handle too many different DMaps on the same cluster. Does creating different DMaps for the asset ids solve the problem? Then, you can call Destroy on the DMap to vanish its content.
https://github.com/buraksezer/olric#destroy

I could likely use multiple dmaps. Is it ok to have 10k+ dmaps in the distributed system?

I simply can't even get it to store the key on the single node so I figured I must have configured something wrong

I've managed to resolve this. The problem was that I hadn't been properly printing the error that was being generated by the Put. The error was actually that the gob encoding failed because my cache value did not have any exported fields. This was because my previous lru cache was local in memory and would simply store whatever ìnterface{}` you gave it. I needed to go and refactor my cache types to use exported fields.

I could likely use multiple dmaps. Is it ok to have 10k+ dmaps in the distributed system?

It's too big. I didn't try this scenario before but background workers may fail and every DMap preallocates some memory. So you need too much memory to handle 10k+ DMaps in a Olric cluster.

For my cache invalidation logic, I was able to take a key prefix and iterate all the keys in the cache, to evict the ones that match the prefix. Olric doesn't provide a way to get the list of keys. Does this have any value to you as a feature?

I'm going to work on the possibility of implementing an iterator for DMaps. I'm not sure that it's a good idea.
Is it ok to change the cache design to handle the prefix problem?

Thanks for clarifying about the dmaps. Specifically I am caching image previews for assets. There could be different size transformations and options for the same asset, hence I may have multiple cached variations for one asset. And then I may be caching many thousands of assets. When I find out an asset has changed, all of its variations have to be evicted.
I'm totally fine to try out changes to the cache api if you are putting in the time to try and add iterators. Thanks!

I'm totally fine to try out changes to the cache api if you are putting in the time to try and add iterators. Thanks!

The iterator implementation can only provide an eventually consistent view of a DMap. It's also an O(n) operation like Redis' KEYS * Is that OK for you?

Hey @justinfx, what is the average size of the values? and what is the average RAM of your nodes?
As you know, DMaps are distributed among partitions. Chunks on the partitions should be relatively small (between 50MB-100MB) for a smooth operation in the case of node join or departure. Default partition count is 271 in Olric. I think that it is a good choice for clusters of up to 50 nodes and ~25–30 GB of data. 271 * 100MB = 27.1GB.  If you need to store more than 27GB, please increase the partition count.
Prime numbers are preferred for unique distribution of keys. Here is some Math about this:

https://cs.stackexchange.com/a/64191
https://www.quora.com/Does-making-array-size-a-prime-number-help-in-hash-table-implementation-Why

Eventually consistent key iteration is likely fine. I imagine that each of the nodes will equally be receiving external notifications so each of them will end up seeing at least their local keys which meaning everything should still get evicted.
My service converts and caches smaller preview representations of source assets/images. So they are definitely less than 1mb per value and usually less than 200k. Because it has been a simple LRU I have only been running a single 8G in memory cache node. But I would like to scale that to 3 nodes and have the ability to roll out upgrades without losing the cache. That is, I want to upgrade one at a time and let the cache rebalance. Currently when I upgrade I just lose the cache and let it start cold again.

Could you please share the key count in your cache? I assume that you have 100M keys in the cache and need to iterate over that DMap. I need to do some calculations to design a prototype.
I consider adding a regex field to the iterator function to reduce network traffic. What do you think?

I'm willing to build something like that:
dm, err := db.NewDMap("mydmap")
if err != nil {
	// handle error
}

q, err := dm.Query(olric.Q{"$onKey": {"$regexMatch": "/foo.?"}})
if err != nil {
	// handle error
}

q.Range(func(key string, value []byte) bool {
	err = dm.Delete(key)
	if err != nil {
		// handle error
	}
})

Currently there is no secondary index to query keys($onKeys) or fields in values($onValues). In this preliminary version, it will do full DMap scan in a distributed manner. Later on we can implement a secondary index to query keys and values.

Could you please share the key count in your cache?

It would currently be less than 50k keys with my low available total ram. I would also be fine to set a max keys as an upper limit once I am able to expand further.
A regex system and the query options seem really cool. I'm sure it would save alot of network chatter by filtering on the remote side.
One suggestion after looking at your prototype query api. It might be a good idea to provide key-only iterators. Because in my case it would be a waste to transmit all those values when I only want to delete the keys.

Hey @justinfx I have just implemented the initial version of the distributed query subsystem. It works fine. I'm still iterating over the code. Here is a sample for you.
Sample output:
EVEN NUMBERS:
=============
KEY: even:000000006, VALUE: 6
KEY: even:000000002, VALUE: 2
KEY: even:000000000, VALUE: 0
KEY: even:000000008, VALUE: 8
KEY: even:000000004, VALUE: 4

ODD NUMBERS:
=============
KEY: odd:000000005, VALUE: 5
KEY: odd:000000009, VALUE: 9
KEY: odd:000000003, VALUE: 3
KEY: odd:000000001, VALUE: 1
KEY: odd:000000007, VALUE: 7

EVEN NUMBERS WITHOUT VALUES:
============================
KEY: even:000000006, VALUE: <nil>
KEY: even:000000002, VALUE: <nil>
KEY: even:000000000, VALUE: <nil>
KEY: even:000000008, VALUE: <nil>
KEY: even:000000004, VALUE: <nil>

ITERATOR ON DMAP:
=================
KEY: odd:000000005, VALUE: 5
KEY: odd:000000009, VALUE: 9
KEY: odd:000000003, VALUE: 3
KEY: even:000000006, VALUE: 6
KEY: even:000000002, VALUE: 2
KEY: even:000000000, VALUE: 0
KEY: even:000000008, VALUE: 8
KEY: odd:000000001, VALUE: 1
KEY: even:000000004, VALUE: 4
KEY: odd:000000007, VALUE: 7

A snippet:
	// Find even numbers and ignore the values
	q3, err := dm.Query(
		query.M{
			"$onKey": query.M{
				"$regexMatch": "even:",
				"$options": query.M{
					"$onValue": query.M{
						"$ignore": true,
					},
				},
			},
		},
	)
	if err != nil {
		log.Printf("Failed to run query on even numbers %v", err)
	}
	defer q3.Close()

	fmt.Println("EVEN NUMBERS WITHOUT VALUES:")
	fmt.Println("============================")
	err = q3.Range(func(key string, value interface{}) bool {
		fmt.Printf("KEY: %s, VALUE: %v\n", key, value)
		return true
	})

You can call standard DMap API functions in Range.
It's on feature/issue-18 and this is the first commit. Please share your ideas about the query language and its implementation. I hope it's good enough to handle your case.
Thanks!

I think this ticket has achieved the original request, which was the improvements to the evicition mechanisms. I don't want to take this ticket off topic with all of the other great features and fixes you have started. So I will just comment on them in their specific issues.
Just to clarify, I have been testing the max size eviction, the Start function callback, and the query key range iterator. All working great so far.
Thanks!

Just to clarify, I have been testing the max size eviction, the Start function callback, and the query key range iterator. All working great so far.

Thank you very much for your feedback. It was very valuable. Please don't hesitate to create an issue on GitHub for bugs and feature requests.

authors: buraksezer justinfx

repo: buraksezer/olric


text:
error in config file

language-markdown disable language-gfm, ok that ist what we want.
but with every opening atom there is a new line in my config file
disabledPackages: [
  "language-gfm"
  "language-gfm"
  "language-gfm"
]

after deinstall language-markdown the problem is solve

Hi @KaiBueker,
Thanks for the research on this one. That is indeed something I only have to do once ;) Should be an easy fix.

Fixed, and will be part of the next patch.

authors: KaiBueker burodepeper

repo: burodepeper/language-markdown


text:
Position#move isn't available on blank position

If the editor handles a cursor key when the editor doesn't have focus, then editor.cursor.offsets returns a blank range, with blank position objects. These blank positions don't have a move method and sadness occurs:

Should we just put a guard checking that this.cursor.hasCursor() at the top of handleKeydown?

@rlivsey Yes, that's a good catch. Exiting early on no cursor sounds like the right move. I will address this soon, but happy to take a PR in the meantime.

I'm looking at this and will fix it today

authors: bantic rlivsey

repo: bustlelabs/mobiledoc-kit


text:
Add min/maxSize support for px values

If your UI is designed to be reasonably sized within specific dimensions, having access to limit size with pixel values is essential.
Currently implementing with CSS values only works in 2-column/2-row setup,
Thanks for working on this component for all of us! <3

I understand why that would be convenient in some cases but I don’t think it’s something I want to support- because it would require changing the public api in a non obvious way: This library doesn’t control its own outer dimensions, so it couldn’t prevent panels from expanding/contracting past a certain point as its own width/height changed.
You should be able to accomplish this using minSize/maxSize and a min/max external height/width though!

Copying from https://github.com/bvaughn/react-resizable-panels/issues/48#issuecomment-1368106118 in case others see this issue.

Here is an example of what I mean:
https://codesandbox.io/s/react-resizable-panels-forked-m5qf69?file=/src/App.js
  const MIN_SIZE_IN_PIXELS = 100;

  const [minSize, setMinSize] = useState(10);

  useLayoutEffect(() => {
    const panelGroup = document.querySelector('[data-panel-group-id="group"]');
    const resizeHandles = document.querySelectorAll(
      "[data-panel-resize-handle-id]"
    );
    const observer = new ResizeObserver(() => {
      let height = panelGroup.offsetHeight;

      resizeHandles.forEach((resizeHandle) => {
        height -= resizeHandle.offsetHeight;
      });

      // Minimum size in pixels is a percentage of the PanelGroup's height,
      // less the (fixed) height of the resize handles.
      setMinSize((MIN_SIZE_IN_PIXELS / height) * 100);
    });
    observer.observe(panelGroup);
    resizeHandles.forEach((resizeHandle) => {
      observer.observe(resizeHandle);
    });

    return () => {
      observer.disconnect();
    };
  }, []);

...I don’t think it’s something I want to support- because it would require changing the public api in a non obvious way...

Just thought of: if changing the api in a non obvious way is the issue, how hard would it be to support the css rules min-width & max-width which it what I went for initially (<Panel style={{maxWidth}}/>). Currently in a multi-panel view this work except for the unintended consequence that a neighboring panel shrinks/grows after the constrained panel hits its limit. If you think you can figure it out - that'd be great! I will work with your example above however :) Thank you again.

<Panel style={{maxWidth}}/>

I think the problem with this is similar to the problem with external width/height props– either can change without PanelGroup/Panel re-rendering or being aware. (Example: an external stylesheet could define this style.)
So handling it fully would go from being something triggered only by pointer events to something that could be triggered by a lot of external things.
I don't think I want to try to support that level of complexity 😄

I think I have a possible solution for the pixel-based constraints; see https://github.com/bvaughn/react-resizable-panels/pull/176

❤ → ☕ givebrian.coffee

authors: abrman bvaughn

repo: bvaughn/react-resizable-panels