text:
Feature: enable monitoring_prom feature in CI actions

This enables the prometheus feature flag in the CI tests. This way, the test coverage we have for the prometheus metrics will run in CI.

 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.

@kantai i had to revert this, since the --feature flag is not usable with --archive flag.
i've been testing the --feature flag for monitoring_prom in the build step, but so far i have 2 tests that are reliably failing. not sure why, but it's complaining about bitcoin.
i'll open an issue and share some details there with you

authors: CLAassistant kantai wileyj

repo: stacks-network/actions


text:
Upgrade Flutter to version 3.10.0 or higher

Can I upgrade Flutter to version 3.10.0 or higher? Thank you.

Yes, please.
Latest version 3.10.6 would be appreciated.
You can prepare it almost entirely on your forked repositories (in your conf/local.conf just keep overrides to URL's which points to LibertyGlobal). Later on we could easily transfer all your newly created branches to us (git SHAs will be preserved).

source: gharchive/issue

authors: dongfengweixiao dwrobel

repo: stagingrdkm/meta-rdk-flutter

license_type: permissive

license_source: github-api


text:
⚠ GitLab Server has degraded performance

In bcb7f85, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 7856 ms

Resolved: GitLab Server performance has improved in 99e06a9.

repo: stamateas/upptime

license: MIT


text:
Use console.Symbols.INSPECT for debug output

I'm just watching your talk introducing stampit. One criticism someone raises is that identifying the type of the object in debug output is more difficult than in more classical inheritance. I wonder if, given the code is written in ES6 now, console.Symbols.INSPECT can be used to address this concern?

Hello @wheresrhys
I'd like to understand your concern in full. Would you please answer few questions?

identifying the type of the object in debug output

In JavaScript what do you mean by 'type of the object'? The typeof operator?
(I'll be asking more questions later.) :)

How do you see the usage of the console.Symbols.INSPECT? Code samples maybe?

For anyone, who's not familiar with console.Symbols.INSPECT, please have a good time reading this: http://blog.keithcirkel.co.uk/metaprogramming-in-es6-symbols/

About 35:50 in to this https://vimeo.com/69255635 it's the issue raised by the audience member - I think he does a better job of outlining the problem than any typing by me would. I just happened to be reading the blog you linked to just before watching the video so it jumped out as a possible solution.

Hm, mate, I think we have solved the typeof issue with stampit v2.
Check this out: https://github.com/stampit-org/stampit/blob/advanced_examples/ADVANCED_EXAMPLES.md#self-aware-objects---instancegetstamp-2-ways
Here is your business logic stamp:
const User = stampit(/* bla bla bla whatever */);

Here is the behavior you can compose to any other stamp (like the one above).
const SelfAware = stampit.init(({ instance, stamp }) => {
  instance.getStamp = () => stamp;
});

const SelfAwareUser = User.compose(SelfAware);

And here is how it works now:
const user = SelfAwareUser();
assert.strictEqual(user.getStamp(), SelfAwareUser); // All good

Is it the behavior you were looking for?

"more difficult than in more classical inheritance"

instanceof lies in classical inheritance. Anybody depending on it is making a mistake. The fact that it doesn't work for stamp instances is a feature, not a bug.

:+1: @koresar

@wheresrhys Were your question answered? Please, feel free to express your concerns. We love to hear those.

Closing. The issue starter is not active.

authors: ericelliott koresar wheresrhys

repo: stampit-org/stampit

license: mit

license_source: bigquery


text:
system_functor missing f_ initiliazation

Summary:
system_functor in algebra_system.hpp missing f in init line
Description:
Reproducible Steps:
This bug causes failure of torsten library's generalOdeModel_test unit test.
Additional Information:
Provide any additional information here.
Current Version:
v2.17.0

How do you run the torsten unit test?
On Wed, Dec 20, 2017 at 10:58 AM, Yi Zhang notifications@github.com wrote:

Summary:
Please provide a short couple sentence summary.
system_functor in algebra_system.hpp missing f in init line
Description: Reproducible Steps:
This bug causes failure of torsten library's generalOdeModel_test unit
test.
Additional Information:
Provide any additional information here.
Current Version:
v2.17.0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/issues/696, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F-FyeXiC4j8JiHMrdkh-s4c_qrOrks5tCS6xgaJpZM4RImH2
.

I'll check in a minimal test to reproduce the failure

Welcome to the project and thanks for reporting.  Feel free to just submit a pull request with a unit test and fix.

authors: bob-carpenter syclik yizhang-cae

repo: stan-dev/math


text:
replace boost lgamma with std, fixes #1063

Summary
Replace Boost implementation of lgamma in prim/scal/fun with standard library version.
The goal is to solve #1063 so this works with g++ 7.3.
Tests
The makefiles are currently broken;  see #1068.   I don't believe our CI tests 7.3 and I can't test it without resolving #1068, so I'm tossing it up in a PR.
Also, there is some issue with lgamma not being thread safe in POSIX, but I'm not sure what that means;  see lgamma specification.

The description of the std::lgamma implementations is pretty clear, there's a shared global so concurrent calls will get non-deterministic garbled results.  Unless we want to chase down whether the implementations relevant to us are thread-safe we should stick to boost::lgamma and just set the relevant boost policies to fix issue #1063

I actually just made this change as part of #1067 with the diff for the lgamma function here: https://github.com/stan-dev/math/pull/1067/files#diff-6d2e0c5e89ad16a152ce65335ca2e93c
From reading the issues above it looks like the NaN return for lgamma(0) is not wanted, and the return should be the default (inf)? Or leave the boost implementation as-is (with the change to policy) for thread safety?

In my opinion, Boost's default policy of returning NaN for lgamma(0) is
crazy. But particularly in statistical applications, the argument to lgamma
is usually constrained to be non-negative anyway, in which case returning
Inf is definitely the right limiting behavior.
On Mon, Nov 19, 2018 at 10:49 AM Andrew Johnson notifications@github.com
wrote:

I actually just made this change as part of #1067
https://github.com/stan-dev/math/pull/1067 with the diff for the lgamma
function here:
https://github.com/stan-dev/math/pull/1067/files#diff-6d2e0c5e89ad16a152ce65335ca2e93c
From reading the issues above it looks like the NaN return for lgamma(0)
is not wanted, and the return should be the default (inf)? Or leave the
boost implementation as-is (with the change to policy) for thread safety?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/1069#issuecomment-439939895, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADOrqokxCyvOutR2OQJojVSOG6SgIcyXks5uwtL7gaJpZM4YoYMZ
.

@andrjohns --- please don't stack multiple, independent functionality changes into a single PR.  I already have a PR addressing lgamma.
I'm still unclear on the POSIX implications of std::lgamma not being thread safe.  I thought @bgoodri would know how this all fits together.

I should have been clearer, the replacement of boost::math::lgamma with std::lgamma was already a part of my PR replacing boost::math functions with std:: functions, when I submitted it (only beat you by a day though). I didn't change an existing PR to make this replacement.
If you'd prefer to handle lgamma separately to the other boost::math:: functions, I can remove it from my PR

No, if you're dealing with them all at once, that's fine.
In the future, if you could add a note that you're going to be creating a PR for an issue, it'll cut down on duplicated work.  Luckily, this was only an hour or so's worth of work.
Before this gets merged, we need to answer the threading question about lgamma.

source: gharchive/pull-request

authors: andrjohns bgoodri bob-carpenter sakrejda


text:
Cleanup/generalize metaprograms with parameter packs

Summary
This is an attempt to cleanup and generalize 4 metaprograms with parameter packs.
Tests
There are 2 new tests added (there were none for is_var_or_arithmetic)
test/unit/math/rev/scal/meta/is_var_or_arithmetic.cpp
test/unit/math/prim/scal/meta/is_var_or_arithmetic.cpp
Side Effects
Hopefully none.
Checklist

[x] Math issue #1122

[x] Copyright holder: Rok Češnovar, Univ. of Ljubljana

[x] the basic tests are passing

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

@seantalts the
C:\Rtools\mingw_64\bin\ar.exe: unable to rename 'lib/sundials_4.1.0/lib/libsundials_nvecserial.a'; reason: Permission denied error is happening again.

Yikes. I restarted that phase and used icacls to try to set permissions
even harder this time. I have no other ideas left, except possibly making
the Jenkins user an administrator, which seems bad. For now let's just
restart the job phase when this happens and I'll try to hire someone who
knows these things better than I do.
On Sun, Mar 3, 2019 at 7:35 AM Rok Češnovar notifications@github.com
wrote:

@seantalts https://github.com/seantalts the
C:\Rtools\mingw_64\bin\ar.exe: unable to rename
'lib/sundials_4.1.0/lib/libsundials_nvecserial.a'; reason: Permission denied
error is happening again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/1132#issuecomment-468997262, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7DL_p3W_w4cA53yAw9Ow11Z_PfXvks5vS3slgaJpZM4bZz1O
.

This is now ready for review. I added a few comments that will help anyone that will review this/use this.

I believe I made all the changes and comments requested. Ready for re-review.

authors: rok-cesnovar seantalts


text:
remove finite diffs impl in stan/model/util.hpp

Use the new finite diffs implementations instead.

util.hpp was broken down ages ago

repo: stan-dev/stan


text:
stan parser grammars refactor - add functions to var_origin, encapsulate allowed access

Summary:
Refactor Stan grammar rules and associated semantic actions to better encapsulate logic needed for context-dependent rules, e.g., assignment to a variable, or access to random number generator.
Description:
As part of bugfix/2145, the stan::lang::var_origin object was changed to a struct.  Add functions to this struct that check for different kinds of allowed access.  Currently, this logic is spread across semantic actions associated with grammar rules and many rules pass around flags indicating current program scope.  If possible, this information should be maintained by the var_origin struct.
Current Version:
v2.14.0

fixed via PR https://github.com/stan-dev/stan/pull/2228


text:
Updated the ruby code to new version

I changed the ruby code to be aligned with and working with 2.4.0

Updated the travis file

Corrected the fluentd dependency

Narrowed the version to 2.4.x

Would it be possible to merge the latest pull request?  I have fixed up everything.


text:
Add 'The Souls of Black Folk' and 'Cane' to wanted ebooks

The Souls of Black Folk is an incredibly influential book, and has a more or less permanent place in Project Gutenberg's top 50 most downloaded books.
Cane  is not as well known, but is considered a classic modernism, and is a good example of work from the Harlem Renaissance.
I put both these in the moderate difficulty section, since both are relatively short, but Souls starts each chapter with a song, complete with music notation, and Cane has a lot of poetry and somewhat interesting formatting.

I would put Cane as advanced. It has lots of formatting and unique structure and spelling. Can you tweak that?

Sure, done.

Thanks!

authors: acabal mgbennet

repo: standardebooks/web


text:
Rethink the Checkpoint Loading function

As part of my goal to rethink the TrainerState abstraction #420, I'm trying to figure out how best to encapsulate checkpoint loading.
Checkpoint saving is easy: you have a PyTree of data and we pass it to serialize_leaves_tensorstore. The only subtlety is that we only serialize the is_trainable parts of the model (so that we only serialize the lora adapter weights and not the whole model.)
Deserializing is a bit more complex, because it's coupled to initialization. In order to deserialize something, we need to know the shape, so we have to at least do an eval_shape on the initialization code. So at a minimum we need something like this:
def initialize(): ...

if checkpoint_exists:
   shape = filter_eval_shape(initialize)
   state = load_checkpoint(...)
else:
    state = jit(initialize)()

So far so good, but our initialization story is more complicated when we think about model initialization.
We can initialize a model 3 ways: from scratch, from a levanter checkpoint, or from a HF checkpoint.
Unfortunately the last two are very different codepaths and probably will be for some time. (The HF checkpoint codepaths support manipulating the array shapes in the checkpoint to Levanter's model structure, but we don't do that currently for Levanter's internal checkpoints.) So now the flow looks like:
def initialize_model(): ...
def initialize_state(model): ...

if state_checkpoint_exists:
    model_shape = eval_shape(initialize_model)
    state_shape = eval_shape(initialize_state, model_shape)
    state = load_checkpoint(...)
else:
    if lev_model_checkpoint_exists:
        model_shape = eval_shape(initialize_model)
        model = load_checkpoint(...)
   elif hf_checkpoint:
        model_shape = eval_shape(initialize_model)
        model = load_hf_checkpoint(...)
   else:
        model = jit(initialize_model)()

   state = jit(initialize_state)(model)

Not terrible, but 2 things:

atm we keep the hf_checkpoint stuff away from the main trainer class, so we can't directly use this code.
We also need to support "partial checkpoint" initialization for stuff like llama, where some buffers are rematerialized from scratch when we load the model.

(2) makes the flow look like this:
def initialize_model(): ...
def initialize_state(model): ...

# if run in jit, this won't waste non-symbolic work as long at the compiler does its job of DCE
def full_init(init_fn, partial_result):
    partial_result = filter_out_any_abstract_shapes(partial_result)
    return eqx.combine(partial_result, init_fn()):

if state_checkpoint_exists:
    model_shape = eval_shape(initialize_model)
    state_shape = eval_shape(initialize_state, model_shape)
    partial_state = load_checkpoint(...)

    state = jit(full_init)(lambda : initialize_state(initialize_model()), partial_state)
else:
    if lev_model_checkpoint_exists:
        model_shape = eval_shape(initialize_model)
        partial_model = load_checkpoint(...)
   elif hf_checkpoint:
        model_shape = eval_shape(initialize_model)
        partial_model = load_hf_checkpoint(...)
   else:
        partial_model = eval_shape(initialize_model)

   model = jit(full_init)(initialize_model, partial_model)
   state = jit(initialize_state)(model)

Ok, we're getting there.
I was trying to make a method like
def load_or_initialize(init_fn, path):
   shape = eval_shape(init_fn)
   if exists(path):
       partial_result = load_checkpoint(shape)
   else:
       partial_result = shape

   return jit(full_init)(init_fn, partial_result)

But that doesn't end up composing b/c we can't do i/o inside jit, so we can't do something pretty like:
# DOESN'T WORK

def maybe_init_state_from_model_ckpt(init_model):
     model = load_or_initialize(init_model_maybe_from_hf, path)
     state = initialize_state(model)
     return state

state = load_or_initialize(maybe_int_state_from_model_ckpt, ...)

Sad :(

I think what we do is make load_or_initialize(...), push the initial_state out of Trainer (which we want to do anyway), if you need this fancy two stage init, you just have to check for checkpoint existence yourself.

fixed in #496

repo: stanford-crfm/levanter


text:
Add a way to specify password/user for benchmarking scripts…

…also tweaks to parameter storage
@deepakn94 could you take a look?

I moved configurations into their own .json files, i hope you don't mind

What's the behavior like if the USER environment variable isn't set?
Otherwise, LGTM.

I didn't test that, I'll add a fail safe to default to postgres. but USER is set automatically on linux and Mac, so that shouldn't be a problem.

I actually set the default to None, in that case dbUser will be ignored in the config file.

Alright, sounds good. Thanks!

repo: stanford-futuredata/macrobase


text:
export call-pstn-full and sfb-viewbox icons

Description
This PR exports call-pstn-full and sfb-viewbox icons

changes look fine to me - @codepretty, could you, please, take final look on the names of the exported  icons?

@thewulf7, icons were checked against spec, there is nothing blocking this PR - lets merge recent master into this branch, resolve CHANGELOG conflicts and merge right after 👍

repo: stardust-ui/react


text:
Add clippy script.

This change is

.github/workflows/ci.yml line 30 at r1 (raw file):

      - run: |
          cargo +nightly-2022-11-03 fmt --all -- --check
          cargo clippy --all-targets --all-features

it seems that it didn't work.
Code quote:
cargo clippy --all-targets --all-features

.github/workflows/ci.yml line 30 at r1 (raw file):
Previously, ilyalesokhin-starkware wrote…
it seems that it didn't work.

acutally, nvm

repo: starkware-libs/blockifier


text:
Move AirExt and component visitors to inner module.

This change is

#445  👈
dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @alonh5 and the rest of your teammates on  Graphite

repo: starkware-libs/stwo


text:
using ssm_state and conv_state during training

Currently, from the way the library is written conv_state and ssm_state are only used when generating one step at a time using the InferenceParams. It would be useful to use these during training with the selective scan. An example use case would be when you want to train on documents larger than available memory, while this would cause a stop gradient between chunks of the document it would be useful for avoiding context fragmentation at inference time.
Are there any plans to enable this? If not, how difficult would it be to add this to the scan kernel? For the causal conv I guess you can just keep a cache of the last 3 activations.

Agree it's a useful feature, it's on the roadmap!

@albertfgu Would states be differentiable? I would rather like to not stop the gradient during training unlike @robflynnyh

Not sure, it's a lot of extra work to make it differentiable through the final state. And that's also not necessary for the main use case that we wanted to support (continuing training on the next state). What use case are you thinking of?

I'm thinking of backpropagation through time on multiple chunks (e.g. 4) instead of fitting full sequence in one huge window

I'm thinking of backpropagation through time on multiple chunks (e.g. 4) instead of fitting full sequence in one huge window

Would that take the same amount of activation memory as computing the full sequence?

Hmm yeah, my bad

Are there any convenient ways to set up the initial state? I want to use TBPTT to train mamba on a longer context window, so there is no need to make initial/final states of each chunk differentiable.

Unfortunately not right now. It will hopefully be ready within a few weeks.

Unfortunately not right now. It will hopefully be ready within a few weeks.

Just checking to see if this is still in progress. I was going to start working on this myself, but I would hate to spend a couple weeks figuring it out just for an official implementation to come out at the same time.

Not sure, it's a lot of extra work to make it differentiable through the final state. And that's also not necessary for the main use case that we wanted to support (continuing training on the next state). What use case are you thinking of?

@albertfgu I think differentiable initial states is a critical feature for investigating state initialization. For example, we would be able to perform prefix tuning for mamba (similar to tuning KV-cache in Transformers).

authors: albertfgu ejmejm robflynnyh sentialx sustcsonglin tridao woominsong

repo: state-spaces/mamba


text:
[nitro] Tweak readme

The quoted contract would not actually compile.

Could these reference snippets of code in the repo in the future? (like embed a github UI)

authors: geoknee snario

repo: statechannels/monorepo


text:
Getting ArgumentNullException when running

Wanted to give this theme a go, so decided to follow the instructions and I'm getting the following error.

[ERRO] Archives/Process » ForEachDocument » Error while executing module ExecuteConfig in Archives/Process: Value cannot be null. (Parameter 'patterns')
[ERRO] Archives/Process » ForEachDocument » Document [C:/Users/drmathias/repos/ThemedBlog/src/ThemedBlog/input/theme/input/index.cshtml]: Exception of type 'Statiq.Core.ExecuteModulesException' was thrown.
[DBUG] Exception while executing pipeline Archives/Process: System.ArgumentNullException: Value cannot be null. (Parameter 'patterns')
at Statiq.Core.FilterSources..ctor(IEnumerable1 patterns)    at Statiq.Web.Pipelines.Archives.<>c__DisplayClass0_0.<.ctor>b__1(IDocument archiveDoc, IExecutionContext ctx)    at Statiq.Common.Config.<>c__DisplayClass13_01.b__0(IDocument doc, IExecutionContext ctx)
at Statiq.Common.Config1.<>c__DisplayClass10_0.<<op_Implicit>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at Statiq.Common.Config1.GetAndTransformValueAsync(IDocument document, IExecutionContext context, Func2 transform)    at Statiq.Common.ParallelConfigModule1.<>c__DisplayClass8_1.<b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Statiq.Common.ParallelAsyncExtensions.ParallelSelectManyAsync[TSource,TResult](IEnumerable1 items, Func2 asyncSelector, CancellationToken cancellationToken)
at Statiq.Common.ParallelConfigModule1.ExecuteContextAsync(IExecutionContext context)    at Statiq.Common.Module.ExecuteAsync(IExecutionContext context)    at Statiq.Common.Module.ExecuteAsync(IExecutionContext context)    at Statiq.Core.Engine.ExecuteModulesAsync(ExecutionContextData contextData, IExecutionContext parent, IEnumerable1 modules, ImmutableArray`1 inputs, ILogger logger)

Steps to reproduce:

Follow steps at https://statiq.dev/web/#quick-start
git submodule add https://github.com/statiqdev/CleanBlog.git theme
Created my-first-post.md at input/posts/

I think I see the problem, might need to update the instructions to make this clearer: the theme folder should be alongside the input folder (not under it). If you've got the theme folder inside the input folder try moving it out and let me know if that works.

I see, you did write that, just I didn't read it properly. Thanks.

authors: daveaglick drmathias

repo: statiqdev/CleanBlog


text:
Update a PUBLISHED subset

Bug
It should be possible to update name, validUntil, shortDescription, description, createdBy, administrativeDetails.administrativeType('ANNOTATION').values.
The change has to affect all published versions of the subset.
Solution A:

write a patch to the last version and pick this data up for the earlier versions.
write a patch to each existent version to avoid merge;

Example:
Storage:
[
{ name: A, version: 1.0.0, DRAFT },
{ name: A, version: 1.0.1, OPEN},
{ name: A, version: 2.0.0, OPEN},
{ name: B, version: 2.0.1, OPEN }, /updated name/
{ name: C, version: 3.0.0, DRAFT },
]
GET /versions
[
{ name: B, version: 1.0.1, OPEN },
{ name: B, version: 2.0.0, OPEN },
{ name: C, version: 3.0.0, DRAFT },
]

Solution:
In GET /versions
After the final list of most recent major versions is built
Find the newest version that is OPEN, and apply the name stored in this version to each previous version.

@alina-lapina validUntil is different for each major version of a subset, and so should not be overwritten. The createdBy might also be different for each major version: The fact that organization A made major version 1 is not changed by the fact that organization B makes major version 2? The description and short description should maybe also be different from version to version, because the version contains different things and so a different description is appropriate. The description might also contain info on why a new version was made, and so it should not be applied to the old versions as well. The only value that I believe should truly overwrite all versions is "name", because we agreed on that with Anne Gro. Do you agree?

validUntil is not version dependent, It is one for the whole subset. It has to be flexible. It can also be null.
Version's validity period is based on verisionValidFrom and next version's versionValidFrom or, if last version, subset's validUntil.
Read a discussion here https://github.com/statisticsnorway/gsim-raml-schema/pull/29

createdBy

The createdBy might also be different for each major version:
The fact that organization A made major version 1 is not changed
by the fact that organization B makes major version 2?

It's interesting. We need Anne Gro's opinion here.

authors: alina-lapina drageset

repo: statisticsnorway/klass-subsets-api


text:
feat: add option to fetch multiple layers at once

Current Implementation
The current api statsigServer.getLayerSync(user, layerName, new GetLayerOptions()) allows pulling one layer at a time
Problem
In an api server, it is sometimes beneficial to fetch multiple layers at once and add them to the request context. So that it is can be easily used in different api handlers.
Solution
Add an api to fetch multiple layers at once ex: statsigServer.getLayersSync

It should be easy enough to write a method that takes in an array of layer names, and returns the layers for each of those - I dont think the SDK needs to add support for this as a top level API as you can currently compose the exposed API into this type of method if you need it.
It also seems like you might be overfetching data in some cases and want to leave the layer fetching to the particular callsite, adding caching for that if there are multiple callsites.  Again, all implementation details for your own webserver.

authors: tore-statsig vignesh-sc

repo: statsig-io/java-server-sdk

license: ISC


text:
[RFC]: add fs/stat

Description
This RFC proposes adding the package @stdlib/fs/stat for inspecting details of files asynchronously and synchronously.
var stat = require( '@stdlib/fs/stat' );
var statSync = require( '@stdlib/fs/stat' ).sync;

Related Issues
None.
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

Hi, @kgryte . I found this can be used by other packages in @stdlib/fs. Can I try working on this?

repo: stdlib-js/stdlib


text:
[RFC]: Add @stdlib/random/array/cauchy

Description
This RFC proposes adding support for creating an array containing pseudorandom numbers drawn from a Cauchy distribution. This is the array creation analog of @stdlib/random/base/cauchy.
Package: @stdlib/random/array/cauchy
Alias: cauchy
Related Issues
None.
Questions
No.
Other

A package with a similar implementation/API design is @stdlib/random/array/beta.

Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

can you please assign me this work?

Of course, thanks for attempting this! Implementation should be very similar to @stdlib/random/array/beta; for documentation of distribution parameters, @stdlib/random/base/cauchy is a good reference.

authors: Planeshifter ayesha-firdaus kgryte


text:
Fixer 3.0 Support

Implementing support for the latest major version.
https://github.com/FriendsOfPHP/PHP-CS-Fixer/releases/tag/v3.0.0

@bubba-h57 Hello, please avoid using app_path() n config.php. It does not support Lumen.

repo: stechstudio/Laravel-PHP-CS-Fixer


text:
Show status of live reload in status bar

Beep beep

Implemented by https://github.com/steelbrain/steel-flint/pull/12

repo: steelbrain/steel-flint


text:
timoni bundle apply is consistently timing out

For example:
╰─❯ SOMEAPP_CLAIM="claim-GcXZo1u7sf793zpSuYnQ" timoni bundle apply -f someapp.cue --runtime-from-env --force --overwrite-ownership
3:18PM INF b:someapp > applying 1 instance(s)
3:18PM INF b:someapp > i:someapp > applying module timoni.sh/someapp version 0.0.6
3:18PM INF b:someapp > i:someapp > upgrading someapp in namespace someapp
3:18PM INF b:someapp > i:someapp > ConfigMap/someapp/someapp-21ca602d configured
3:18PM INF b:someapp > i:someapp > Service/someapp/someapp configured
3:18PM INF b:someapp > i:someapp > Service/someapp/someapp-udp configured
3:18PM INF b:someapp > i:someapp > Deployment/someapp/someapp configured
3:18PM INF b:someapp > i:someapp > PersistentVolume/someapp-config configured
3:18PM INF b:someapp > i:someapp > PersistentVolume/someapp-media configured
3:18PM INF b:someapp > i:someapp > PersistentVolumeClaim/someapp/config configured
3:18PM INF b:someapp > i:someapp > PersistentVolumeClaim/someapp/media configured
3:18PM INF b:someapp > i:someapp > Ingress/someapp/someapp configured

Even though everything is gets reconciled and working ok... it eventual times out and I get this:
3:23PM ERR [timeout waiting for: [PersistentVolume/someapp/someapp-media status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, Service/someapp/someapp status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, Service/someapp/someapp-udp status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, PersistentVolumeClaim/someapp/config status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, Ingress/someapp/someapp status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, PersistentVolume/someapp/someapp-config status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, ConfigMap/someapp/someapp-21ca602d status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, PersistentVolumeClaim/someapp/media status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline, Deployment/someapp/someapp status: 'Unknown': client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline], storing instance failed: client rate limiter Wait returned an error: contextdeadline exceeded]
This also happens when I use timoni apply not just when doing it as a bundle.

I guess the PV is stuck, can you check your cluster and see if that's the case, describing the applied objects with kubectl should tell you.

All the stuff I deploy with Timoni includes PVs, because I need to direct them to a hostPath. So I haven't tested on anything without PVs yet. But:
╰─❯ SOMEAPP_CLAIM="claim-GcXZo1u7sf793zpSuYnQ" timoni bundle apply -f someapp.cue --runtime-from-env
7:27PM INF b:someapp > applying 1 instance(s)
7:27PM INF b:someapp > i:someapp > applying module timoni.sh/someapp version 0.0.6
7:27PM INF b:someapp > i:someapp > upgrading someapp in namespace someapp
7:27PM INF b:someapp > i:someapp > ConfigMap/someapp/someapp-21ca602d unchanged
7:27PM INF b:someapp > i:someapp > Service/someapp/someapp unchanged
7:27PM INF b:someapp > i:someapp > Service/someapp/someapp-udp unchanged
7:27PM INF b:someapp > i:someapp > Deployment/someapp/someapp unchanged
7:27PM INF b:someapp > i:someapp > PersistentVolume/someapp-config unchanged
7:27PM INF b:someapp > i:someapp > PersistentVolume/someapp-media unchanged
7:27PM INF b:someapp > i:someapp > PersistentVolumeClaim/someapp/config unchanged
7:27PM INF b:someapp > i:someapp > PersistentVolumeClaim/someapp/media unchanged
7:27PM INF b:someapp > i:someapp > Ingress/someapp/someapp unchanged
Since it's already installed and running fine, running it again shows that everything is unchanged. But it's still spinning waiting for 9 resource(s) to become ready... and then timing out as above. Meanwhile, my PVCs report status as bound, no events, and my PVs report the same.

And interestingly a timoni status -n someapp someapp shows a long previous installation:
╰─❯ timoni status -n someapp someapp
7:33PM INF i:someapp > last applied 2024-08-23T20:22:42Z
7:33PM INF i:someapp > module oci://ghcr.io/philipsd6/timoni-someapp:0.0.2
7:33PM INF i:someapp > digest sha256:b8a1f598b8fb0e5f4fba39d8c690d04b8fb23d17a25c9cf3a3da04e8febd7b7c
7:33PM INF i:someapp > container image someappinc/pms-docker:beta
7:33PM INF i:someapp > ConfigMap/someapp/someapp-21ca602d Current - Resource is always ready
7:33PM INF i:someapp > Service/someapp/someapp Current - Service is ready
7:33PM INF i:someapp > Deployment/someapp/someapp Current - Deployment is available. Replicas: 1
7:33PM INF i:someapp > PersistentVolume/someapp-config Current - Resource is current
7:33PM INF i:someapp > PersistentVolume/someapp-media Current - Resource is current
7:33PM INF i:someapp > PersistentVolumeClaim/someapp/config Current - PVC is Bound
7:33PM INF i:someapp > PersistentVolumeClaim/someapp/media Current - PVC is Bound
7:33PM INF i:someapp > Ingress/someapp/someapp Current - Resource is current

Run the apply of 0.0.6 with --wait=false, this should update the instance state accordingly.

Well yes, that does let it work without timing out, but it's a bit like:
Patient: Doctor, my arm really hurts when I bend it this way, do you have any advice?"
Doctor: Don't bend it that way.

The timeout comes from an applied resource that doesn't become read, you need to describe each applied resource and see which one is stuck. One you figure out which one fails, we can then look into how to improve the health check code to report it.

It seems that the resource type that is causing the issue is my PersistentVolumes. When I apply a bundle that uses PVs, I eventually get this:
9:13AM ERR [timeout waiting for: [Deployment/nodered/nodered status: 'InProgress', PersistentVolume/nodered/nodered-nodered status: 'Unknown'], storing instance failed: client rate limiter Wait returned an error: context deadline exceeded]

But as I said, everything is in the correct state, including the PVs -- they are properly bound to the PVCs:
⏎╰─❯ kubectl get pv nodered-nodered -o json | gron | grep -i status
json.status = {};
json.status.lastPhaseTransitionTime = "2024-08-27T21:46:45Z";
json.status.phase = "Bound";

╰─❯ kubectl -n nodered get pvc nodered -o json | gron | grep status
json.status = {};
json.status.accessModes = [];
json.status.accessModes[0] = "ReadWriteOnce";
json.status.capacity = {};
json.status.capacity.storage = "1Gi";
json.status.phase = "Bound";

repo: stefanprodan/timoni


text:
Add [QUANTOM Corp. quantomfinancial.org] #custodian GAOFMM…K5NQTM

Address: GAOFMMR7E6RFFPAKR7C6TQO5GRKQVHLLQWDVBL2ZAHQUW2LJ33K5NQTM
Tags: custodian
Title: QUANTOM Corp.  Domain: quantomfinancial.org
Requested by @luckinsi

@luckinsi Thank you for your input. I know that the token got tagged as "custodian" instead of "malicious" yesterday. I have asked @orbitlens to change the tag to the intended "malicious" instead of "custodian".
Yesterday they minted 100 scam tokens that:
-were up to the edge infringing on the rights of every brand and trademark used.
-the word quantum is intentionally spelled wrong,
-the website is just a template with no working links except to someone else's telegram channel
-the domain was also registered with NameCheap and will most likely get shut down for not following their pretty clear AUP.
-there is no working TOML for these tokens
As you may or not know the idea of the new Quantum Financial System QFS is a well known and a concept used in many scams targeting many good conservative people following some of those influencers.
Please continue to help shine the spotlight on malicious activity on the Stellar Blockchain. If you have further input feel free to reopen this issue.
Looking Towards The Future With You,
Rob TheCryptoHobbyist

@luckinsi I also just found out the email is either fake or just not working.

On Sat, Jan 14, 2023 at 4:38 PM CryptoHobbyist @.***>
wrote:

@luckinsi https://github.com/luckinsi I also just found out the email
is either fake or just not working.
—
Reply to this email directly, view it on GitHub
https://github.com/stellar-expert/public-directory/issues/349#issuecomment-1382925421,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5IAW3CR4DXBPXK4KICQ6O3WSMMD3ANCNFSM6AAAAAAT3KRBVA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ok thanks , i love all your reviews
Can i send you more to check for me

@luckinsi We are always trying to shine the spotlight onto any scams.

repo: stellar-expert/public-directory


text:
Rename standalone mode to custom mode

I propose we rename the standalone mode to something else. ~I don't have a great alternative suggestion, but~ I think the current name is problematic, ambiguous, and misleading.
The term 'standalone' is used in stellar-core as a configuration option where-by core will run without peers. This is useful for testing when peers aren't required.
When I use the standalone mode of this docker image, what we're really targeting is having a custom development network. Whether or not that custom development network has peers or not is really independent to why I'm using this mode. I usually do not need to have peers disabled, and I might want to have peers enabled if I was wanting to create a multi-node custom network using the quickstart image, for development purposes.
Also, since the move to captive core the standalone mode doesn't always operate stellar-core in its standalone mode since standalone must be disabled to use captive core.
In an effort to make the quickstart image as useful as possible as a development tool I think we can pretty safely remove the use of the stellar-core standalone feature, since having it enabled/disabled is largely unnecessary and of little impact when the feature is disabled/enabled arbitrarily based on other settings like whether captive-core is in use. I think we should consider renaming the quickstart image's standalone mode to something more meaningful or representative of its intended use. Possibly calling it the dev mode, or better yet, the custom network mode.
cc @acharb @MonsieurNicolas @bartekn

what this image is supposed to help with

@MonsieurNicolas Could you expand on what this image's original intended use case was that you're referring to?

what this image is supposed to help with

@MonsieurNicolas Could you expand on what this image's original intended use case was that you're referring to?

Maybe a question for Jesse?
Original scope was:

make it easy for application developers to try out their code on their local machine without having to hit testnet
same but also with Horizon changes

Then it quickly morphed into "spinning up a node that can talk to testnet/public network" even though this is not scalable (and no effort was made to make it reliable).

Original scope was:

make it easy for application developers to try out their code on their local machine without having to hit testnet
same but also with Horizon changes

👍🏻 Great, I think I'm on the same page then with what you capture as the original intent. I'd like to continue to encourage that existing intent, as I've used this image specifically for that over the last 6 months and found it to be the most reliable way to share changes for both core+horizon together in a working format that someone with minimal experience can run.

Then it quickly morphed into "spinning up a node that can talk to testnet/public network" even though this is not scalable (and no effort was made to make it reliable).

Hopefully if we improve the documentation for running stellar-core and horizon in production people will gravitate towards that.
🤔 I was thinking of proposing to remove the pubnet and testnet capabilities of this image, but it is actually really useful to be able to test that this image works for those environments, as a way of validating the image is a working representation of a node. Maybe we just remove pubnet though? Testnet is probably enough for validating the image. I've opened https://github.com/stellar/docker-stellar-core-horizon/issues/305 to further discuss the idea of removing pubnet capabilities.

cc @jcx120

I'd like to continue to encourage that existing intent

I've opened a PR clarifying the intent in the readme: https://github.com/stellar/docker-stellar-core-horizon/pull/306.

authors: MonsieurNicolas leighmcculloch

repo: stellar/docker-stellar-core-horizon


text:
Postgresql wont run with fatal error

hi, with PostgreSQL 9.4 it used to work fine, but when I rebuilt the image today and ran it , it kept failing with the following fatal error..no other other specific info in the log ..any idea why the PostgreSQL wont run? bin path and data directory are all correct
2018-06-10 17:25:45,979 CRIT Supervisor running as root (no user in config file)
2018-06-10 17:25:45,988 INFO RPC interface 'supervisor' initialized
2018-06-10 17:25:45,988 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2018-06-10 17:25:45,988 INFO supervisord started with pid 7
2018-06-10 17:25:46,991 INFO spawned: 'postgresql' with pid 19
2018-06-10 17:25:46,993 INFO spawned: 'stellar-core' with pid 20
2018-06-10 17:25:46,995 INFO spawned: 'horizon' with pid 21
2018-06-10 17:25:47,007 INFO exited: postgresql (exit status 1; not expected)
2018-06-10 17:25:48,057 INFO spawned: 'postgresql' with pid 45
2018-06-10 17:25:48,058 INFO success: stellar-core entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-06-10 17:25:48,058 INFO success: horizon entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2018-06-10 17:25:48,074 INFO exited: postgresql (exit status 1; not expected)
2018-06-10 17:25:50,157 INFO spawned: 'postgresql' with pid 82
2018-06-10 17:25:50,174 INFO exited: postgresql (exit status 1; not expected)
2018-06-10 17:25:53,310 INFO spawned: 'postgresql' with pid 137
2018-06-10 17:25:53,327 INFO exited: postgresql (exit status 1; not expected)
2018-06-10 17:25:53,353 INFO gave up: postgresql entered FATAL state, too many start retries too quickly

that didnt do it..still exactly same error

Can you copy the postgres log here?

Login to your docker container: docker exec -it [container name] /bin/bash
supervisorctl
tail postgresql

log is blank..this is strange
horizon                          RUNNING   pid 20, uptime 0:19:37
postgresql                       FATAL     Exited too quickly (process log may have details)
stellar-core                     RUNNING   pid 19, uptime 0:19:37
supervisor> tail postgresql
supervisor>

having similar issues

I have the same issue. Stellar was working for some time, now I try to run the container shows same errors that are above discusses. Getting absolutely the same behaviour.

@bartekn why did you close the issue if it's not solved? Could you please reopen it as many people are getting the same error. I am using last docker image call stellar/quickstart

I have the exact same issue after trying to restart my testnet node after the network reset. Cannot run a node as I get
INFO exited: postgresql (exit status 2; not expected)
INFO spawned: 'postgresql' with pid 44
INFO success: stellar-core entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
INFO success: horizon entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
INFO exited: postgresql (exit status 2; not expected)
INFO spawned: 'postgresql' with pid 82
INFO exited: postgresql (exit status 2; not expected)
INFO spawned: 'postgresql' with pid 136
INFO exited: postgresql (exit status 2; not expected)
INFO gave up: postgresql entered FATAL state, too many start retries too quickly
terminated - TODO: send SIGTERM to children

running tail postgresql shows an empty log.

hey guys, if I remembered it had something to do conf file not in the right place or wasn't getting the path the specified..I dont have the setup anymore sorry know that's not very helpful

Same story after updating to the latest version....
 supervisorctl
horizon                          RUNNING   pid 22, uptime 0:01:50
postgresql                       FATAL     Exited too quickly (process log may have details)
stellar-core                     RUNNING   pid 21, uptime 0:01:50

supervisor> tail postgresql

supervisor>

@bartekn

just connect your docker container with the command below

docker exec -it [container name] /bin/bash
supervisorctl
tail /var/log/supervisor/postgresql-stderr---supervisor-*.log

it will shows exact problem that you faced.
my problem is below, so i think same as yours.
"FATAL:  could not create lock file "postmaster.pid": No space left on device"

same problem was after copying the stellar data directory.
You need to fix the owner of the postgres data directory:
root@b5ee7ed62aab:/# ls -l /opt/stellar/postgresql total 8 drwx------ 19 **postgres** **postgres** 4096 Sep 27 09:53 data drwxr-xr-x  2 root     root     4096 Sep 27 08:54 etc
I have had:
root@b5ee7ed62aab:/# ls -l /opt/stellar/postgresql total 8 drwx------ 19 **root** **root** 4096 Sep 27 09:53 data drwxr-xr-x  2 root     root     4096 Sep 27 08:54 etc
solution:
in conteiner enter
chown -R  postgres:postgres /opt/stellar/postgresql/data

authors: bartekn kiahmed matricore minherc murphyjohn r3lik skinderis


text:
services/bridge: use new horizon /operations endpoint parameter to get memo

In Horizon v0.19, you can now get transaction information when querying for operation details. Bridge server should be updated to take advantage of this so that multiple calls to horizon are not required to get the memo associated with an operation.

services/bridge has been deprecated and removed.

authors: bartekn poliha

repo: stellar/go


text:
CLI: Add outside-in tests using assert_cmd

We're reaching the point where not having tests in this repo is going to start to hurt, especially approaching new releases.
The assert_cmd crate is a very helpful tool for writing tests for CLIs that work outside-in, by actually executing the binary with arguments and asserting on the stdout, stderr, and file system.
There's an example of an assert_cmd using test that I wrote recently here:
https://github.com/leighmcculloch/cargo-set-rust-version/blob/21e011eaa52dcc8857f60cf0b4dcca7815b06faa/tests/update.rs#L5-L35

I am working on adding a few integration tests

repo: stellar/soroban-cli


text:
Update Frontend

closes #157
here is a media file to show what i have done. i just wanted to be sure i have approval

Hello @Ugo-X
Thanks for all the efforts you've made so far in the last tasks to redesign the UI/UX and for enhancing responsiveness for the DApp.
After reviewing your submission, it was found that despite there being a lot of text and descriptions, the main objective of the tasks had not been met. The primary goal was to make the Dapp front end cooler by enhancing its visual appeal and intuitiveness.
By "cool," we mean a new sleek design that is compelling, standing out with the ability to engage users with a visually exciting Dapp. In that sense, we specifically refer to aspects such as a cohesive color scheme, intuitive navigation, animations that are really dynamic, and a fresh layout that is user-friendly. It is unfortunate that the current delivery lacks what the intended design improvements sought to create.
We were looking for a clear and tangible redesign aligned with these modern design principles, to qualify for the award and really bring the overall user experience to life.
If you need any further clarification or guidance on what's expected, please feel free to reach out. We appreciate your understanding and are looking forward to further contributions from you.
Best regards,
Julian

Hello @Ugo-X
Thanks for all the efforts you've made so far in the last tasks to redesign the UI/UX and for enhancing responsiveness for the DApp.
After reviewing your submission, it was found that despite there being a lot of text and descriptions, the main objective of the tasks had not been met. The primary goal was to make the Dapp front end cooler by enhancing its visual appeal and intuitiveness.
By "cool," we mean a new sleek design that is compelling, standing out with the ability to engage users with a visually exciting Dapp. In that sense, we specifically refer to aspects such as a cohesive color scheme, intuitive navigation, animations that are really dynamic, and a fresh layout that is user-friendly. It is unfortunate that the current delivery lacks what the intended design improvements sought to create.
We were looking for a clear and tangible redesign aligned with these modern design principles, to qualify for the award and really bring the overall user experience to life.
If you need any further clarification or guidance on what's expected, please feel free to reach out. We appreciate your understanding and are looking forward to further contributions from you.
Best regards, Julian

Alright, this was not meant to be the design, just a mockup. Given all the details you just described, I will put out a PR before the week runs out. Thank you.

Great thanks!

Closing this one out!
Unfortunately this one does not meet the criteria for the bounty but regardless thanks again for the awesome work! I hope to see you at the next hackathon!

https://www.figma.com/proto/JY2dP1yA8tRWLcf4Apavqf/Untitled?node-id=1-2&t=5nNkSMXgy3p52PvT-1&scaling=scale-down-width&content-scaling=fixed&page-id=0%3A1

repo: stellar/soroban-example-dapp


text:
fix bindings error enum not showing message or docs

What
Fixes https://github.com/stellar/stellar-cli/issues/1346
Why
Bindings genered from something like this:
/// Represents the different kinds of errors that can occur in the application.
pub enum Error {
    /// The requested item was not found.
    NotFound = 1,

    /// The operation was not permitted.
    NotPermitted = 2,

was showing this:
export const Errors = {
  1: {message:""},
  2: {message:""},

Now it will properly put a message and docstring:
/**
 * Represents the different kinds of errors that can occur in the application.
 */
export const Errors = {
  /**
   * The requested item was not found.
   * /
  1: {message:"NotFound"},

  /**
   * The operation was not permitted.
   * /
  2: {message:"NotPermitted"},

Known limitations
none

Looks like a test / lint is failing. Could you fix?

Fixed, now it just looks like unrelated tests are failing.

authors: BlaineHeffron leighmcculloch

repo: stellar/stellar-cli


text:
Feature Request: Extend Send method to send a claimable balance if destination has no trust-line

What problem does your feature solve?
Doesn't block source account from sending an asset to a destination account that doesn't have a trust-line established for that asset.
What would you like to see?
When the source account attempts a send (make payment) operation to a destination account that doesn't have a trust line established for that asset it should instead attempt a claimable balance operation for that account.

I think this issue is still relevant, but the user must have a method of specifying that making claimable balances is acceptable. We wouldn't want the payment to be sent to an account controlled by an application that doesn't support CB's.

repo: stellar/stellar-demo-wallet


text:
add links to the admin guide in the node hw requirements table

Follow-up to the discussion in #686. This is a quick-n-simple PR to add links to the relevant admin guides in the table of hardware requirements.

Preview is available here:http://developers-pr712.previews.kube001.services.stellar-ops.com

authors: ElliotFriend stellar-jenkins

repo: stellar/stellar-docs


text:
Fix JSON RPC documentation link to json-rpc.cpp source

Fix broken link to json-rpc.cpp example in the docs.

Thanks!

authors: pentatonick stephenberry

repo: stephenberry/glaze


text:
Create Decodable objects after LEFT OUTER JOIN

I am wondering if there is a way to init my decodable object after I do left outer join two (or more) Tables. The problem I am facing is that when I join two tables, the column names automatically get prefixed with Table's name. Thus, when I do Customer(from: row.decoder()) this fails as my CodingKeys do not include my Table's name upfront. Is there any way to achieve this without renaming them (CodingKeys)?

I'm facing kind of the opposite issue. I want the CodingKeys to be prefixed with their table_name. But, at decode time, the decoder claims that it can't find the right key.
class A {

    let pokemonID: Int

    enum CodingKeys: String, CodingKey {
        case pokemonID = "pokemon.id"
    }

    init(decoder aDecoder: Decoder) throws {
        let values = try! aDecoder.container(keyedBy: CodingKeys.self)
        self.pokemonID = try! values.decode(Int.self, forKey: .pokemonID)
    }
}

func fetch() -> [A] {
    let tablePokemon = Table("pokemon")
    let tableEncounters = Table("encounters")
    let colPokemonID = Expression<Int>("pokemon_id")
    let colID = Expression<Int>("id")

    let query =
        tablePokemon.join(tableEncounters,
                          on: tablePokemon[colID] == tableEncounters[colPokemonID])
                    .filter(tablePokemon[colID] == 1)

    return try! self.connection.prepare(query).map { row in
        return try! row.decode()
    }
}

Error:
Fatal error: 'try!' expression unexpectedly raised an error: No such column `"pokemon.id"` in columns ["\"encounters\".\"encounter_slot_id\"", "\"encounters\".\"id\"", "\"encounters\".\"location_area_id\"", "\"encounters\".\"max_level\"", "\"encounters\".\"min_level\"", "\"encounters\".\"pokemon_id\"", "\"encounters\".\"version_id\"", "\"pokemon\".\"base_experience\"", "\"pokemon\".\"height\"", "\"pokemon\".\"id\"", "\"pokemon\".\"identifier\"", "\"pokemon\".\"is_default\"", "\"pokemon\".\"order\"", "\"pokemon\".\"species_id\"", "\"pokemon\".\"weight\""]

Aside from the garbled mess of escape quotes, pokemon.id plainly appears in the list of columns in the error. I have no idea why this doesn't work. If I reduce the CodingKey to just id, naturally it fails because id is ambiguous (both pokemon and encounter have id). If I change the CodingKey to pokemon_id, it works because it finds pokemon_id on encounter -- even though I didn't namespace it.
I must have some kind of fundamental misunderstand of how this decoding happens and what values should appear in my CodingKeys. Right now, I'm at an impasse because values like id, identifier, and pokemon_id are used over and over in nearly every table. As it stands right now, I have no idea how to decode those columns after a join.

You may want to check https://github.com/groue/GRDB.swift and its associations: https://github.com/groue/GRDB.swift/blob/master/Documentation/AssociationsBasics.md
They make decoding joined tables a breeze

Please ask on StackOverflow for this kind of questions (we are tracking bugs on GitHub)

@NathanFallet I think this is potential shortcoming of the library, not a usage clarification. Row allows us to access namespaced columns by unprefixed name, provided there is no ambiguity. However, the SQLiteDecoder appears to define its set of available keys by only the namespaced version. If you cannot use `Codable`` with any kind of join, it's probably worthless.

authors: NathanFallet groue justinmeiners nalexander50 p-nicolaou


text:
Need assistance with BM71 firmware update with host uC

Hello,
My name is James Kimber and I am a student at The University of Akron, and I have a design project with a team of 3 other students and we have committed to creating a transmitter and receiver to do what we need it to do (not important) and we committed to using PIC24 uC's for both transmitter and receiver and BM71's for bluetooth communication between them. We are trying to update the firmware on the BM71's to the RN4870/RN4871 firmware so that we can use RN4870/RN4871 firmware to write script so that they will pair and bond automatically. (we know how to script them) We have successfully done this by updating the firmware using the firmware update tool through usb to computer, but we do not have the luxury of being able to use the update tool now that we have the PIC uC's and BM71's attached to our PCB's. How could we code the uC to update the BM71 firmware directly. We have reached out to Microchip, with no luck, and we are desperate. Please, PLEASE help.

I have not touched this in a LONG time, and when I did. The feature only partially worked.. I will gladly share the source that I had though.. Beyond providing you source, I don't think I have much more to offer.

BM71_flash_commands.c
``c
//------------------------------------------------------------------------------
//  Copyright(c)2018 Murphy Technology as an unpublished work.
//
//  The information contained herein is confidential property of Murphy Technology.
//  All rights reserved.  Reproduction, adaptation, or translation without the
//  express written consent of Murphy Technology is prohibited, except as allowed
//  under the copyright laws.
//------------------------------------------------------------------------------
#include <stdint.h>
#include <stdbool.h>
#include "BM71_flash_commands.h"
#include "BM71_flash_data.h"
#include "BM71.h"
#include "delay.h"
#include "debugAPI.h"
#include "driver_init.h"
#include "configAPI.h"
/-------------- DEFINITIONS -------------------------------------------------/
/-------------- TYPEDEFS ----------------------------------------------------/
/-------------- FUNCTION PROTOTYPES -----------------------------------------/
static bool OpenFlashMemory(void);
static void SetBufferAddress(uint16_t address, uint8_t lowByte, uint8_t highByte);
static bool Send128Bytes(uint16_t address, const uint8_t *data);
static bool Read128Bytes(uint16_t address);
static bool EndFlashMemoryAccess(void);
static bool EraseFlashMemory(void);
static uint8_t GetSizeOfMemBlock(void);
static bool SendConfigToEEPROM(void);
static bool CheckConfig(void);
static bool CompareEmptyMemory(uint16_t address);
static bool CompareMemory(uint16_t address, const uint8_t *expectedData);
static void SendFlashCommand(const uint8_t sendPacket, uint8_t sendSize, uint8_t recievePacket, uint8_t readSize);
/-------------- VARIABLE DEFINITIONS ----------------------------------------/
//Load the memoryBlock array from the "bluetooth_flash_data.h" header so we can read it here
extern const flash128_t memoryBlock[16];
///OPEN FLASH MEMORY
const uint8_t open_Transmit[17] = {0x01,0x05,0x04,0x0D,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00};
const uint8_t open_Response[21] = {0x04,0x0F,0x04,0x00,0x01,0x05,0x04,0x04,0x03,0x0B,0x00,0xFF,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x00};
///READ COMMAND
const uint8_t read_Transmit[19] = {0x02,0xFF,0x0F,0x0E,0x00,0x10,0x01,0x0A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x80,0x00,0x00,0x00};
const uint8_t read_Response[19] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x86,0x00,0x10,0x01,0x82,0x00,0x00,0x00};
///ERASE ALL FLASH
const uint8_t erase_Transmit[19] = {0x02,0xFF,0x0F,0x0E,0x00,0x12,0x01,0x0A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x00,0x20,0x00,0x00};
const uint8_t erase_Response[27] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x0E,0x00,0x12,0x01,0x0A,0x00,0x00,0x00,0x00,0x40,0x03,0x00,0x00,0x20,0x00,0x00};
///WRITE COMMAND
const uint8_t write_Transmit[19] = {0x02,0xFF,0x0F,0x8E,0x00,0x11,0x01,0x8A,0x00,0x03,0x00,0x00,0x40,0x03,0x00,0x80,0x00,0x00,0x00};
const uint8_t write_Response[19] = {0x04,0x13,0x05,0x01,0xFF,0x0F,0x01,0x00,0x02,0xFF,0x0F,0x06,0x00,0x11,0x01,0x02,0x00,0x00,0x00};
//CLOSE FLASH MEMORY
const uint8_t close_Transmit[7] = {0x01,0x06,0x04,0x03,0xFF,0x0F,0x00};
const uint8_t close_Response[14] = {0x04,0x0F,0x04,0x00,0x01,0x06,0x04,0x04,0x05,0x04,0x00,0xFF,0x0F,0x00};
/*******************************************************************************

Description: See the FLASH MSB and LSB address inside the write buffer.

*******************************************************************************/
static void SetBufferAddress(uint16_t address, uint8_t lowByte, uint8_t highByte)
{
//Set the MSB and LSB of the 2 byte address in the output buffer at the specified indexes
BM71_writeBuffer[lowByte] = (uint8_t) address;
BM71_writeBuffer[highByte] += (uint8_t) (address >> 8);
}
/*******************************************************************************

Description: BM71 command to open the flash for reading and writing.

*******************************************************************************/
static bool OpenFlashMemory(void)
{
SendFlashCommand(open_Transmit,sizeof(open_Transmit),BM71_readBuffer, sizeof(open_Response));
for(uint8_t i = 0; i < 19; i++)
{
    if(BM71_readBuffer[i] != open_Response[i])
    {
        return false;
    }
}
return true;

}
/*******************************************************************************

Description: Writes 128 bytes of data at the address specified.

*******************************************************************************/
static bool Send128Bytes(uint16_t address, const uint8_t *data)
{
//Clear the buffers
BM71_clearWriteBuffer();
BM71_clearReadBuffer();
//We first add the 19 byte write command to the beginning of the buffer
BM71_loadWriteBuffer(write_Transmit, sizeof(write_Transmit));

//We then update the buffer with the specified address to write 128 bytes to
SetBufferAddress(address, 11, 12);

//Place the data to be written after the command
for (uint8_t i = sizeof(write_Transmit); i < 147; i++)
{
    BM71_writeBuffer[i] = *data++;
}

SendFlashCommand(BM71_writeBuffer, 147, BM71_readBuffer, sizeof(write_Response));
//Check that the BT device responded with the
for(uint8_t i = 0; i < 19; i++)
{
    if(BM71_readBuffer[i] != write_Response[i])
    {
        return false;
    }
}
//If the response from the Bluetooth device was what was expected then return a true
return true;

}
/*******************************************************************************

Description: Reads out 128 bytes of data at the address specified from the

BM71 FLASH.
*******************************************************************************/
static bool Read128Bytes(uint16_t address)
{
//Clear the buffers
BM71_clearWriteBuffer();
BM71_clearReadBuffer();
//Populate the read command in the buffer
BM71_loadWriteBuffer(read_Transmit, sizeof(read_Transmit));
//Update the address of the read command in the buffer
SetBufferAddress(address, 11, 12);
//Send the read command
SendFlashCommand(BM71_writeBuffer, sizeof(read_Transmit), BM71_readBuffer, sizeof(BM71_readBuffer));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != read_Response[i])
{
return false;
}
}
//If the response from the Bluetooth device was what was expected then return a true
return true;
}

/*******************************************************************************

Description: Higher level command which sends 128 bytes, and then reads it back

to verify the data was written correctly to the BM71 flash.
*******************************************************************************/
static bool Write128BytesToFlash(uint16_t address, const uint8_t *data )
{
//Write data to the BM71
if(!Send128Bytes(address, data))
{
return false;
}
//Read the data back out
if(!Read128Bytes(address))
{
return false;
}
//Verify that the data we just read back matches what we wrote
for(uint8_t i = sizeof(read_Response); i < 128; i++)
{
//We compare byte by byte between the two buffers
if(BM71_readBuffer[i] != *data++)
{
//if the data does not match, we return a false
return false;
}
}
//If all data matched, we return a true.
return true;
}

/*******************************************************************************

Description: Close access to the BM71 FLASH.

*******************************************************************************/
static bool EndFlashMemoryAccess(void)
{
//Send the close access to the flash memory command and check the response
SendFlashCommand(close_Transmit,sizeof(close_Transmit),BM71_readBuffer, sizeof(close_Response));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != close_Response[i])
{
return false;
}
}
return true;
}
/*******************************************************************************

Description: Erase all flash memory of the BM71 in preperation of writing new

config.
*******************************************************************************/
static bool EraseFlashMemory(void)
{
SendFlashCommand(erase_Transmit,sizeof(erase_Transmit),BM71_readBuffer, sizeof(erase_Response));
for(uint8_t i = 0; i < 19; i++)
{
if(BM71_readBuffer[i] != erase_Response[i])
{
return false;
}
}
brd_MsDelay(25);
return  true;
}

/*******************************************************************************

Description: Get the size of the configuration data that needs to be written
to flash.
*******************************************************************************/
static uint8_t GetSizeOfMemBlock()
{
//Divide the full size of the data memory by the block size to calculate how many blocks are in the struct
return sizeof(memoryBlock) / 130u;
}

/*******************************************************************************

Description: High level function that checks the size of the config to be

written and then begins writing all of the config blocks.
*******************************************************************************/
static bool SendConfigToEEPROM(void)
{
uint8_t sizeOfMemoryBlock = GetSizeOfMemBlock();
//cycle through each row/index in the "memoryBlock" array and update the
//flash memory.
for(uint8_t i = 0; i < sizeOfMemoryBlock; i++)
{
//each row has 128 bytes, so we set bytes to 128. We also send the address
if(!Write128BytesToFlash(memoryBlock[i].address, memoryBlock[i].data))
{
return false;
}
}
return true;
}

/*******************************************************************************

Description: Check if the config currently in FLASH matches the config we have

in firmware.
*******************************************************************************/
static bool CheckConfig(void)
{
uint8_t sizeOfMemoryBlock = GetSizeOfMemBlock();
bool isAddressInBlock;
uint8_t index = 0;
//This is a normal for loop, except we are using address instead of i
//address is also a 16bit word, not an 8 bit word because the
//bluetooth's addresses are all 16 bits.
//Since we are reading/writing 128 bytes at a time, we increment by
//0x0080 each iteration of the for loop. NOT the number 80, but 128 in hex.
//This causes us to have the address of the next 128 bytes in the memory each
//iteration of the for loop.
//Also, according to the BM71's documentation, the last address in the BM70's
//EEPROM is 0x1FF0. This is why we only loop to it then stop.
for(uint16_t address = 0x0000; address <= 0x1FF0; address += 0x0080)
{
//Reset address is found in the flash block flag
isAddressInBlock = false;
  //Reset the starting index location that we will start from when
  //searching the flash memory block
  index = 0;

  //Search through the Flash Block for the address, WHILE
  //we have not reached the end of the memory block's last index
  //AND
  //We have not found the memory address in the block

  //If we find the address, or we reach the end of the indexes
  //in the memory block then stop looking.
  while((index < sizeOfMemoryBlock) &&  !isAddressInBlock)
  {
      //if the current index of the memory block has the same
      //address as the one we are looking for set the isAddressInBlock flag true.
      if(memoryBlock[index].address == address)

          //Set the flag that the address was found in the memory block
          isAddressInBlock = true;
      //If the memory address was not found at the current index, then increment it
      //to the next index and keep looking
      else index++;
  }

  //If the address was found in the memory block
  if(isAddressInBlock)
  {
      //Then check that the 128 bytes after that address match the specified
      //bytes in the memory block
      if(!CompareMemory(address, memoryBlock[index].data))
          //if the 128 bytes did not match, then return with a false
          return false;

      //If the bytes did match, do nothing and continue testing the rest of
      //the memory
  }
  //Else if the address was not found in the flash memory block
  else
  {
      //Then assume that the 128 bytes after this address should be in the
      //erased state "0xFF". Check that all the following 128 bytes are
      //set to "0xFF". If the address is not found in the memory block it
      //is to be assumed it is a fully erased block.
      if(!CompareEmptyMemory(address))

          //If the 128 bytes did not all return as "0xFF" then there is
          //a data mismatch, and return as false.
          return false;

      //If all of the 128 bytes are blank then do nothing and continue testing
      //the rest of the memory
  }

}
//If we reach this point, then we have checked all of the flash memory and
//everything matched (Since we did not return false yet), so return true.
return true;
}

/*******************************************************************************

Description: Verify that the the data in FLASH has been cleared properly.

*******************************************************************************/
static bool CompareEmptyMemory(uint16_t address)
{
if(!Read128Bytes(address))
{
return false;
}
//If the 128 bytes returned from the BM71 is not all set to 0xFF (Not Empty)
//we return a false
//
//We start at i = sizeof(read_Response) to skip the response command sent back. We only care
//about the data returned, not the response command.
//
//We also use i < sizeof(BM71_readBuffer) to make sure we read all the way to the end of the buffer
//to read the full 128 bytes.

for(uint8_t i = sizeof(read_Response); i < sizeof(BM71_readBuffer); i++)
{
    if(BM71_readBuffer[i] != 0xFF)
    {
        return false;
    }
}
//If the values all matched then return true;
return true;

}
/*******************************************************************************

Description: Compare the data that we just read from the BM71 with what we

expected as a response.
*******************************************************************************/
static bool CompareMemory(uint16_t address, const uint8_t *expectedData)
{
BM71_clearReadBuffer();
Read128Bytes(address);
//If the 128 bytes returned from the BM71 does not match the 128 bytes passed
//into the *expectedData array then return false
//
//We start at i = sizeof(read_Response) to skip the response command sent back. We only care
//about the data returned, not the response command.
//
//We also use i < sizeof(BM71_readBuffer) to make sure we read all the way to the end of the buffer
//to read the full 128 bytes.
for(uint8_t i = sizeof(read_Response); i < sizeof(BM71_readBuffer); i++)
{
if(BM71_readBuffer[i] != *expectedData++)
{
return false;
}
}
//If the values all matched then return true;
return true;
}

/*******************************************************************************

Description: Low level function for writing a command to the BM71 over UART.

*******************************************************************************/
static void SendFlashCommand(const uint8_t *sendPacket, uint8_t sendSize, uint8_t recievePacket, uint8_t readSize)
{
//Make sure the RX ring buffer is empty
usart_async_flush_rx_buffer(&BT_UART);
BM71_clearReadBuffer();
while(io_write(&BT_UART.io, (const uint8_t)sendPacket, sendSize) == ERR_NO_RESOURCE)
{
; //Wait until the UART is ready to write more data
}
//Wait a bit before checking the buffer for any response
brd_MsDelay(20);
//Read out the response into the receive packet
io_read(&BT_UART.io, recievePacket, readSize);
}
/*******************************************************************************

Description: Main function used to read the flash memory. Verify that it

matches what we have stored in our flash. If not, then we begin the process

of deleting the BM71 flash, and then writing the new config.
*******************************************************************************/
bool BM71_checkAndUpdateFlash(void)
{
bool retVal = false;
uint8_t bluetoothConfigVersion = 0xFF;
// Get the Bluetooth Version stored in the NVM Device Config
bluetoothConfigVersion = config_getBluetoothConfigVersion();
// If the config version is 0xFF, that means this is a new device.
// Set the config version to 0x00
if(0xFF == bluetoothConfigVersion)
{
config_setBluetoothConfigVersion(0x00);
// Get the Bluetooth Version stored in the NVM Device Config
bluetoothConfigVersion = config_getBluetoothConfigVersion();
}
if(bluetoothConfigVersion < BLUETOOTH_CONFIG_VERSION)
{
// Config version stored in NVM is less than the version indicated by the FW.
// Attempt to update the BM71 configuration.
//First enter test mode so we can access the BM71 Memory
BM71_ResetToTestMode();
  DEBUG_println(BLE, "New Bluetooth config available..\n\r");
  retVal = OpenFlashMemory();
  if(retVal)
  {
      DEBUG_println(BLE, "Comparing against current BM71 config..\n\r");
      retVal = CheckConfig();
      if(retVal)
      {
          DEBUG_println(BLE, "Bluetooth Config is up to date!\n\r");
          config_setBluetoothConfigVersion(BLUETOOTH_CONFIG_VERSION);
      }
      else
      {
          DEBUG_println(BLE, "BM71 config is out of date. Starting update... \n\r");
          retVal = EraseFlashMemory();
          if(retVal)
          {
              retVal = SendConfigToEEPROM();
              if(retVal)
              {
                  DEBUG_println(BLE, "New config applied successfully!\n\r");
                  config_setBluetoothConfigVersion(BLUETOOTH_CONFIG_VERSION);
              }
              else
              {
                  DEBUG_println(BLE, "Failed to apply new config\n\r");
              }
          }
          else
          {
              DEBUG_println(BLE, "Failed to erase flash memory.\n\r");
          }
      }
      EndFlashMemoryAccess();
  }
  else
  {
      DEBUG_println(BLE, "Failed to open flash memory!\n\r");
  }

}
else
{
DEBUG_println(BLE, "Bluetooth Config is up to date!\n\r");
retVal = true;
}
return retVal;
}

@jkimber09 I've went ahead and my repository public where I was attempting to use the BM71. It can be found at the link below.
https://github.com/stephendpmurphy/OctaneMate.Firmware
You should focus on the folder called ble within the source. Specifically the BM71_flash_commands.* and BM71_flah_data.h files.
Best of luck.

repo: stephendpmurphy/stephendpmurphy


text:
initial codecov setup

add codecov github workflow and badge to readme

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@f190033). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             main        #6   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?         3
  Lines           ?        33
  Branches        ?         2
========================================
  Hits            ?        33
  Misses          ?         0
  Partials        ?         0

Continue to review full report at Codecov.

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

authors: codecov-commenter stephenkilbourn

repo: stephenkilbourn/modern-python


text:
Is there a way to remove comments/ratings from everywhere?

I'm new to Mezzanine (and fairly new to Python). I'm looking to get away from Drupal and use something python-based.
Is there a way to disable comments/ratings from mezzanine completely? eg. in templates and in admin panel? From my research, this is the only thing I've found: http://bitofpixels.com/blog/disabling-mezzanine-comments/ – I also found another article saying this is not supported (although it was from 4 years ago).
I'm wondering if that link is my best option at this time (although that still leaves me with comment links in admin panel). I'm still learning the ropes so I may be missing something obvious. Thank you.

Please direct questions to the mailing list.

authors: ryneeverett zefoo

repo: stephenmcd/mezzanine


text:
Fix: Django 2 (Python 3) Tests

In #1886 was shown that only two tests are failing for Django 2+. The first is fixed in #1887. This is fix for the second one.
Because Django 2 is Python 3 only some of the compatibility shims in Django for converting byte strings to unicode strings was removed and code which uses the old behaviour will no longer works. Generally In Python 3 always native (unicode) strings will be used or bytes will be converted to strings with appropriate encoding.
For that reason I'm disabling test_bytes_conversion test which uses old Django's automatic conversion from bytes to unicode. When this test is disabled under Python 3 then the failing test test_settings under Django 2+ now pass correctly.
This is needed for #1749

Thank you

authors: stephenmcd vstoykov


text:
How do I handle multiple MFTextfield which are placed horizontally as well as vertically?

How do I handle such scenario as error label overlaps below textfield?

@hardikamal how's your constraints? I did it by just setting a bottom constraint to the TextField below.

repo: stephsharp/MaterialTextField


text:
*: use a polyfill for timezones

@yuliadub this might fix the Android timezone issue - I will need to build local APKs and test it out.

Can't hurt to try, we can revert later ...

repo: stevekuznetsov/avalanche-forecast


text:
Properly emit errors so they can be listened for

Hi!
With the current way gulp-stylus handles the promise returned by accord, errors won't be emitted on the stream, preventing simple things like:
var stylus = require("gulp-stylus");
gulp.task("stylus", function() {
  return gulp.src("./src/styles/*.styl")
    .pipe(stylus())
    .on("error", function(err) { /* Log the error or do something else with it */ });
    .pipe(gulp.dest("../public/styles"));
});

Instead, errors are always logged with Potentially unhandled rejection [2] prepended and there's no straightforward way to handle them programmatically.
This pull request matches the style recommended in the accord stylus documentation by using .catch first (important!) and then using .done rather than .then (required for the error to be emitted).
Note that this means errors will be thrown by default, unless an .on("error", ...) handler is provided. If this isn't desirable, maybe there's a better way that doesn't throw by default but still allows listening for the "error" event in the stream, but I couldn't find one.

merged, thanks

authors: elisee stevelacy

repo: stevelacy/gulp-stylus


text:
convert TimeSeries into Series

Apparently Pandas has depreciated TimeSeries, but all of the functionality is contained in Series.

I should also modify get_usgs to return data as a Series instead of a DataFrame. the 'name' attribute should be able to act as a key (dv01585200 or iv01585200, for example) to match with filenames if the data gets saved, or to match up with metadata that might get collected, or to match up with a baseflow timeseries for the same site.

Would it be an option to work with DataFrames as base for the hydropy datatype (currenty the .data  of the attribute is a dataframe)  of the HydroAnalysis class?
Henc, a dataframe as the .data attribute provides the option (but also difficulty) to dervive infromation of multiple gauges time series at the same time (e.g. get_peaks should provide the peaks for all of them).
Or should we opt for a Series as base, making all the methods work for a single gauge time series and make a separate class for the 'multiple-gauges' option?

This is a good question!  It never occurred to me to use the Series, so when I saw your usage of it, I thought it was such a good idea that I immediately wanted to use it too.
I've also been thinking that it would be nice to have a data format that allowed you to save the baseflow time series along with the discharge timeseries.  But that leads to the question: Should the discharge and baseflow each make a column in a dataframe, and then each additional site could add an additional dataframe to create a Panel?  Or should the baseflow go into the Panel, and each site is a new column in a dataframe?
I think to answer this we would have to try each, and see which is easiest to implement, and which is easiest for the user.  If I can find some time, I have started playing around with this idea.  I will post a branch as soon as I can....  ⌚ ☹

I found some time to work on this some more.
Here is the solution I am trying:
Analysis is a new class that holds multiple sites. I do this in two ways (we can choose which is best, or keep them combined)
1. a list of Stations (see below)
2. a pandas Panel. Each 'item' is a dataframe that corresponds to a single Station.
Station is a new class that holds data for a single site. To keep different types of data separate, I started with two types of data: dailymean, and realtime (instantaneous values collected every hour or less)
HydroAnalysis is the class that you created to hold a DataFrame. I use this to hold dataframes inside of the Station class.

Some first thoughts on this, but I think it needs to destilate a bit more:

I would not keep baseflow calculations (or other derivative calculations) inside the same DataFrame as flow data, this would be hard to properly book keep (lots of stuff with titles) while creating different classes when domain knowledge grows. Moreover, maybe it is not needed at all.
Using Series in a custom dtype to handle a variable (i.e. flow) time series and inherit this for multiple variables/stations/... would probably be missing all the benefits pd.DataFrames is providing. So, I would keep the pandas DataFrame as part of the 'core' class. The question is what the different columns are defining: variables (flow, rain,...), different stations (LP64A, LP64B,..) or different derived variables (baseflow,...)?
First, I was trying to keep the HydroAnalysis agnostic of the 'type' of time series (it can be flow, but also baseflow for a single site) on which you can apply different procedures (find peaks, etc...). The technical fact that a specific algorithm (e.g. get_baseflow function operating on HydroAnalysis when you can actually store baseflow as well seems strange (should be ewpert knowledge?). Hence, the question is how far this 'agnostic' idea would work and as the aim is to enable domain knowledge in this package, the datatypes we develop should probably be specifically designed for discharge (or another datatype for specific for rain).

As a first braindump: I would think of a following setup:
* HydroAnalysis -> general 'base' class (on which the other are built) containing a pd.DataFrame inside the data attribute of the class and different metadata/bookkeeping/other attributes, cfr. the current HydroAnalysis. The most important rule would be to keep a single type of variable in one hydroanalysis instance (either flow, rain,...).  The idea is to keep this base class agnostic of the domain (rain, flow) and the functions it provides would be useful to ALL types of data. I'm thinking of the current subset-selections like peaks, seasons, other time-fragments,...  The different columns would - in my opinion - still be different station identifiers, but I'm very open to discussion on this point. The reason I'm thinking of this is just experience from previous projects: I collect time series of a variable for a certain period from different stations in a dataframe and I want to perform the same types of analysis (peaks, baseflow,...) on each of them (each column). By structuring it like this, we gain from the full Pandas power. On the other hand, when only one station, everything keeps working, it just is a single column. I can be wrong, but the support for Panels is I think decreasing in Pandas. Additionally, we could keep the station names in the class as an attribute to make this more clear + it would be possible for the user to drag with it other data (e.g. metadata on the measurement conditions) that is not affected by the analysis, but can be used by the user for ad-hoc/custom operations he/she want to perform (keeping user freedom beyond package functions). In short: HydroAnalysis: base class, contains 1 variable type, columns represent stations
* FlowAnalysis: A class that inherits on the HydroAnalysis, but that adds methods that are only relevant for flow (discharge). So, apart from the general stuff from HydroAnalysis, flow functions are added here and also additional atrributes, e.g. this class contains an additional DataFrame (with the same station name headers) containing the baseflow.
* RainAnalysis: cfr flowanalysis, ut specificly for rain,...

AnotherthingAnalysis: ...
* Analysis: An analysis typically contains multiple types of variables (flow, rain, chemical variables,...). So inside the Analysis different variables are stored and managed + the interrelation of these stations. In other words, it aggregates FlowAnalysis, RainAnalysis,...

Some methods will need both flow and rain, and these could be specified on the Analysis level.
As I said, more an opinion for the moment, looking forward to feedback on this. When doing it like this, we could for the moment focus on HydroAnalysis and FlowAnalysis and create sufficient methods for these.
An interesting point you make is the dailymean, and realtime as different examples for storing. Actually, I do think we should not make this as different custom datatypes, as this kind of logic is highly captures by Pandas itself. The frequency is stored inside a DateTimeIndex. Moreover, Pandas makes the difference between instantaneous TimeStamps and Period (http://pandas.pydata.org/pandas-docs/stable/timeseries.html#overview). So, using DataFrames basically supports both as such. However, some methods won't work on all frequencies and all spans. Hence, I think we should provide this kind of 'logic' to the methods (e.g. some decorators that can be reused to specify and check if the current timeseries frequency/characteristics comply to the method requirements.
What do you think?

@mroberge, with respect to the usage of Panels: https://github.com/pandas-dev/pandas/issues/13563

Sorry that I've been away...
I like your idea. After stepping away for a while and coming back to the problem, I have a much stronger feeling that keeping everything simple is the best approach. My system tried to automate too many things. It is better to trust the user, and let them decide what they want to do with the software.
As you say above, how should we organize the dataframe? Each column could either be a different variable or a different station. By having each column be a different station, you could perform a baseflow separation on the dataframe and produce a new dataframe with baseflow, and each column corresponds to a different station from the original dataframe. I like this approach because:

there is less stuff for us to keep track of (like you said above)
the dataframe doesn't need to know what it is holding. It can hold any type of timeseries.
this is more like a functional programming approach. Each function we run on a dataframe returns a new dataframe instead of modifying the dataframe that we send it. For example, a functional approach to baseflow separation would return a baseflow dataframe. My previous (bad) idea was to modify the dataframe by adding a new baseflow column. This is bad. What happens if you try to do another baseflow separation? How do you tell the function not to try to separate the column with the baseflow? Bad.

As far as the different Analysis  ( FlowAnalysis and RainAnalysis), perhaps we just keep them all together for simplicity's sake for now. Maybe later we can make different types of analysis available for different types of data, but for now I regret ever trying to save the user from making bad choices.

I just fixed the TimeSeries issue, but before I close it, there is a lot of discussion going on here that should be preserved somehow...

authors: mroberge stijnvanhoey

repo: stijnvanhoey/hydropy


text:
Variants don’t apply styles correctly with keys like “1/2”, “3/4"

Bug report
Describe the bug
variants don’t apply styles correctly with rules like:
const failVariants = css({
  display: "grid",
  gap: "16px",
  padding: "8px",
  variants: {
    fraction: {
      "1/4": { gridTemplateColumns: "1fr 3fr" },
      "1/2": { gridTemplateColumns: "1fr 1fr" }
    }
  }
});

To Reproduce
CodeSandbox Example
Expected behavior
variants work with keys like, 1/4, 1/2.
Additional context
I know this article exists for naming theme tokens, but I’m not sure if those rules are meant to apply to variants too.

This is by design at the moment: https://stitches.dev/docs/tokens#naming-convention

Yep, I saw that and the linked discussion in https://github.com/stitchesjs/stitches/issues/493#issuecomment-801241038, but as far as I can tell that only applies to theme tokens? Do these conventions apply to variants too?

Ah, sorry, my bad. I agree with you, seems like a bug, the class is generated correctly, but the styles aren't attached 👍

That's pretty much is a duplicate of https://github.com/stitchesjs/stitches/issues/923 and https://github.com/stitchesjs/stitches/issues/731
You can see more read more discussion about it in the latter
Will be closing this issue for now as we have #932 to track it.

authors: LexSwed hadihallak my-slab

repo: stitchesjs/stitches


text:
Documentation for sequencing types

I modified the badge tooltips on the databrowser (the black popup that occurs when a user mouse overs the WSG, WES, BAM, etc buttons in the table) so the tooltips have clickable links. For now, only file type badges have links because we only have documentation on file types. It would be useful to have helpful documentation for sequencing types as well.

Clay, is there any sj cloud specific information on sequence types worth including in the documentation? If we'd prefer to tooltips to have links we could just link to wikipedia for sequence types.

@claymcleod - If you want, I can help draft text for the sequencing types.

We have some data here already: https://www.stjude.cloud/docs/guides/data/types-of-data/. We should probably link to those headings (for instance, with BAM, just link to the overarching header, not the WGS/WXS/RNA-Seq specific headings).
@adthrasher, yes, I would really appreciate that. With anything that is lacking, would you mind taking a look and updating the information? Up until this point, we have taken a "lazy evaluation" approach to these sections :).

I would link to the guide for the data types from within the tooltips (for WGS, WES, and RNA-Seq) on the data page. The description of how each data type was generated is probably more useful to a user than a description of the sequencing methods.
One issue with doing that is we have "WES" as the abbreviation for whole-exome on the data page and we use "WXS" in the documentation.

I agree with Andrew on the first point.
And the data browser and other parts of the documentation use "WES", so I think we should go with that one. I'm working on documentation today, so I'll go ahead a change the data types page to agree.

authors: adthrasher aswistak-stjude claymcleod mtreadwa

repo: stjude/sjcloud-docs


text:
UART RTS Issue

I was having an issue overflowing the UART RX FIFO (16 byte deep) when using hardware handshaking (RTS/CTS). After connecting a logic analyzer to the UART bus, I found the RTS output is asserted/de-asserted at the wrong times.  It only de-asserts when receiving a byte instead of when the RX FIFO is almost full -- i.e., RTS should be de-asserted when no room is left in the input buffer/FIFO.
Just for a test (not a final or robust solution), I changed line 549 (in neorv32_uart.vhd) from:
uart_rts      <= (not rx_engine.rtr)  when (ctrl(ctrl_rts_en_c) = '1') else '0'; -- output is low-active

To:
uart_rts      <= rx_buffer.half  when (ctrl(ctrl_rts_en_c) = '1') else '0'; -- output is low-active

This de-asserts RTS when the RX FIFO is half full.
This solved my RX FIFO overflow issue.
Note: using the FIFO not full flag for RTS is not good enough. On my setup when RTS is de-asserted, my Windows machine would still send up to two more characters before stopping it's UART TX traffic. As shown, below:

Again, my "solution" above is not the best; really this line should be changed:
rx_engine.rtr <= '1' when (rx_engine.state = S_RX_IDLE) and (ctrl(ctrl_en_c) = '1') else '0';

An almost full flag (or just the half-full flag) from the FIFO should be used instead of the FSM S_RX_IDLE test. Also, I'm not sure if a RX FIFO depth of 1 would work at all, with RTS, if the sender can "skid" two characters past RTS de-asserting.
Thanks,
Brian

I rarely use the RTS signal, but if I do then I also use a huge UART FIFO. Hence, I did not notice this behavior so for. Anyway, thanks for the hint!

RTS should be de-asserted when no room is left in the input buffer/FIFO.

That makes sense!
So it should be de-asserted when the RX FIFO is full.

Note: using the FIFO not full flag for RTS is not good enough. On my setup when RTS is de-asserted, my Windows machine would still send up to two more characters before stopping it's UART TX traffic.

I have seen this behavior on my machine, too.

Again, my "solution" above is not the best; really this line should be changed: [...]
An almost full flag (or just the half-full flag) from the FIFO should be used instead of the FSM S_RX_IDLE test. Also, I'm not sure if a RX FIFO depth of 1 would work at all, with RTS, if the sender can "skid" two characters past RTS de-asserting.

You are right.
Since we do not have an "almost full" flag, the half full flag seems to be the best solutions:
  -- Enough space in RX buffer (+ margin) for a new char? --
  rx_engine.rtr <= '1' when (rx_buffer.half = 0) and (ctrl(ctrl_en_c) = '1') else '0';

Also, I'm not sure if a RX FIFO depth of 1 would work at all, with RTS, if the sender can "skid" two characters past RTS de-asserting.

This is a very special corner case. With a RX FIFO size of 1 the RTS signal will be asserted when the FIFO is empty. I think this okay, but there should be a note regarding this in the documentation.

The half full flag solution would be adequate.  Although, I think the code should be:
  -- Enough space in RX buffer (+ margin) for a new char? --
  rx_engine.rtr <= '1' when (rx_buffer.half = '1') and (ctrl(ctrl_en_c) = '1') else '0';

since RTR (Ready To Receive) is low active.

authors: stnolting vhdlnerd


text:
recurrence

Any idea when weekly recurrence is going to be supported?

found the issue, you get the message is not implemented if you fail to provide the day of week array for the weekly reminder, Why you need to specifiy a DOW when setting something to be weekly given you already have the start date I do not know


text:
Change title to networking

Signed-off-by: Maggie Chen magchen@redhat.com
https://github.com/stolostron/backlog/issues/24926

/test lint-check-unittests-sonarcloud

/test lint-check-unittests-sonarcloud

/test lint-check-unittests-sonarcloud

repo: stolostron/console


text:
Fix displaying Kyverno policies on same cluster but multiple namespaces

Now namespaced Kyverno policies count towards one cluster violation in the "Discovered policies" table and the per cluster view now shows per namespace.
The violation status is now shown in the related resources table of Kyverno policies.
This also adds a missing namespace filter for namespaced policies in the search query for related items. The namespace row is now provided for namespaced policies in the template details page.
Additionally, this fixes the policy report YAML links from the policy template details page.

/cc @yiraeChristineKim

/retest

@yiraeChristineKim sorry, I had forgotten to update one of the tests after the %2F change.

No worry!

authors: mprahl yiraeChristineKim


text:
update mgh api version.

missing part of https://github.com/stolostron/multicluster-global-hub/pull/193
Signed-off-by: morvencao lcao@redhat.com

/test test-e2e

/LGTM

authors: morvencao yanmxa

repo: stolostron/multicluster-global-hub


text:
Add ACM - OpenShift Virtualization Overview dashboard

This PR add the "ACM - OpenShift Virtualization Overview" dashboard that shows details related to the OpenShift Virtualization operator and Virtual machines.
Signed-off-by: Shirly Radco sradco@redhat.com

Hey @sradco do you have access to an instance with this dashboard loaded/metrics collected?

Hey @sradco do you have access to an instance with this dashboard loaded/metrics collected?

@moadz I created the PR based on https://github.com/sradco/acm-multi-cluster-kubevirt-dashboard, which includes a screenshot of the dashboard. Do you require an instance with it running?

/ok-to-test

/retest-required

/retest-required

authors: moadz sradco


text:
Removed "React" references

Issue:
What I did
Removed React references so it more accurately reflects support for other frameworks.

Thank you @nblackburn!, I'm surprised this has one unnoticed for so long.
I'll redeploy end of the day.

@ndelangen Haha, i was a surprise to me too!

authors: nblackburn ndelangen

repo: storybooks/storybook


text:
CLI: Use actions in sample stories for vue + fix them in SFC_VUE template

Issue: #1866
Looks like linkTo was used instead of action by mistake
How to test
cd lib/cli/test/snapshots/vue
yarn
yarn storybook

Merge when ready

authors: Hypnosphi ndelangen