Investigate new syntax.

Story definition
See final version https://github.com/proofit404/stories/issues/627#issuecomment-808525479
from stories import Failure, I, Result, State, Success

from app.repositories import create_subscription, load_category, load_profile

class Subscribe(
    I.find_category,
    I.find_profile,
    I.check_balance,
    I.persist_subscription,
    I.show_subscription,
):

    def find_category(self, state):
        state.category = load_category(state.category_id)
        return Success()

    def find_profile(self, state):
        state.profile = load_profile(state.profile_id)
        return Success()

    def check_balance(self, state):
        if state.category.cost < state.profile.balance:
            return Success()
        else:
            return Failure()

    def persist_subscription(self, state):
        state.subscription = create_subscription(
            category=state.category, profile=state.profile
        )
        return Success()

    def show_subscription(self, state):
        return Result(state.subscription)

subscribe = Subscribe()

state = State(category_id=1, profile_id=1)

result = subscribe(state)

print(result)  # -> Subscription object

Good things:

State becomes a separate object (it always was that way conceptually)
Recursive wrap function is not necessary anymore (steps and nested stories has the same interface now)
User can't define multiple stories in the same class (that forces to use composition more).
Multiple state contracts could be attached to the same story in different use cases.
Stories are no longer methods but a complete class
We could hide story steps from result classes so there is no way to unit-test methods (force to unit-test whole stories instead)

Bad things

We need to deny subclass from stories manually
We need to deny mixins manually

State contract
from stories import Argument, State, Variable

class SubscribeState(State):
    category_id = Argument()
    profile_id = Argument()
    category = Variable()
    profile = Variable()
    subscription = Variable()

Good things

Does not couple specific entity classes (through contract definition) to the story definition. It'll become more like an interface than a direct link to the entity class.
State contracts could be composed using SubscribeState & DiscountState expression.

Bad things

It's unclear how Expect declaration of multiple variables should look like?
Rules based on nesting of state contracts will not work anymore (because state contract is flat now).

we can't understand if argument is required or not. See https://github.com/proofit404/stories/issues/627#issuecomment-806235589
#581 requires knowledge if we are in the branch of the conditional or not. See https://github.com/proofit404/stories/issues/627#issuecomment-805941999
#625 we will unable to understand which story declares private variable and what not. See https://github.com/proofit404/stories/issues/627#issuecomment-805952184

Composition & expression won't be that useful with dependencies.Package. See https://github.com/proofit404/dependencies/issues/495 https://github.com/proofit404/dependencies/issues/496 https://github.com/proofit404/dependencies/issues/497

Failure protocol
...

Bad things

I have no idea how to make failure reason works. At all. The problem lays in the level of result classes are hard coded and imported directly from stories library. So there are no easy way to influence them outside of story definition. I.e. we can't use the same tricks as we do with State object. See https://github.com/proofit404/stories/issues/627#issuecomment-803674101

Usage with dependencies
from dependencies import Injector, Package

from rest_framework import Responce, ViewSet

services = Package("app.services")

class Call:

    def __init__(self, story, state_class):
        self.story = story
        self.state_class = state_class

    def __call__(self, **kwargs):
        return self.story(self.state_class(**kwargs))

class Subscription(Injector):
    subscribe = Call
    story = services.Subscribe
    state_class = services.SubscribeState

class Users(ViewSet):
    def create(self, request):
        result = Subscription.subscribe(**request.data)
        return Responce({"detail": "ok", "result": result})

Good things:

Client code (view sets) will work exactly the same way.

Bad things:

Requires 3 lines instead of one in old style.
Requires additional Call object.

Conditionals
from stories import I, switch, unless, when

class Action(
    I.one,
    when("foo") > I.two,
    I.three,
):
    def one(self, state):
        ...

    def three(self, state):
        ...

class Action(
    I.one,
    unless("foo") > I.two,
    I.three,
):
    def one(self, state):
        ...

    def three(self, state):
        ...

from enum import Enum, auto

class X(Enum):
    member1 = auto()
    member2 = auto()

class Action(
    I.one,
    switch(
        "foo",
        X.member1 > I.two,
        X.member2 > I.three,
    ),
    I.four,
):
    def one(self, state):
        ...

    def four(self, state):
        ...

Delegates
state = State()
calculate_discount(state)
subscribe(state)

Good things:

Delegates implementation and concept will be way simpler in comparison to original design.

This issue makes me think more about if we need markers at all:

Success - used all the times (could be ommited)
Result - return something meaningful from the story (could be replaced with return statement)
Failure+call - short cut for raise BusinessLogicException
Failure+run - return something error code from the story (could be replaced with return statement as well).
Next - workaround for lack of conditionals

Maybe we could rethink our return statements from story steps.
One possible way could be tornado style result, cancel functions which works on top of internal exceptions.

So to my understanding this issue would be split into at least 4 milestones:

New syntax using I base class.
State object instead of keyword arguments
Abandon execution strategies call and run.
Abandon Success and Failure markers.

An alternative approach would be ground up rewrite of the library.
Over time stories grown too much technical debt.
Accompanying libraries like dependencies and generics has way higher quality control.
Half of the tickets related to missed documentation with old style functionality.
We still missing a lot of useful features.
End goal of this ticket makes half of the tickets (about 70) irrelevant.
So, we would create a new milestone and dedicate branch to it.
After we reimplement existing functionality in a new syntax we would merge milestone branch to master.
That way users will not see unfinished version of a new library in place where old semi-complete library was.

See milestone and branch.

Roadmap:

[ ] Close superseded milestones
[ ] Correct left milestones
[ ] Close superseded issues without milestones

In relation to new flat state approach:
In current version of the contract we treat @arguments as variables which allowed to be set anywhere. Any other variable only allowed to be set inside the story we attached contract to.
There is a consequence of such approach: different branches of same conditional statement can't declare variable with same name.
The new state approach we took - is a flat state.
In that situation we can't understand how we relate to conditionals or to the stories composition.
I want to suggest following approach to the things.

Any variable could be assigned by any story in the composition, not only one which define it in the contract. So we allowed to repeat variables with the same name in different state declaration.
We concatenate expectations from variable validators. All of them still needs to normalize value to the same type and value.
The only thing thatArgument change in comparison to Variable - allow to pass variables to the State(...) constructor. Variables could only be assigned to state. Arguments could be both passed and assigned.
Singular Expect would be replaced with Variable.

Consequences of new appoach: branches in conditionals does not need additional semantic to check variables.

In relation to private variables:
Different stories would like to have different private variables.
A variable with the same name defined in different stories could have different validators attached to them which will normalize to different values.
This semantic requires understanding in what story what variable was defined.
A new flat state approach would be unable to determine these structure.
As we suggested in the #474 - the best practice to follow is immediate encapsulation of responses from different services in the some domain object.
That makes private variables in stories less valuable than I initially thought.
I would like to remove private variables proposal and suggest to users not to store garbage in the state of domain process.

In relation to passed story arguments verification:
Lets imagine we have this picture:
story = C1(
    B1(
        A1(),
        A2(),
    ),
    B2(
        A3(),
        A4(),
    ),
)

state_class = (
    C1State & B1State & A1State & A2State & B2State & A3State & A4State
)

state = state_class() # error

In that case, we will not be able to determine difference between c1v1 (required in the state constructor) and a1v1 (could be set by steps).
In reality, if we have tests the very first one would show us we missed parameters.
But still it's PITA to work with.

Updated version
from stories import I, State, Story

from app.repositories import create_subscription, load_category, load_profile

class Subscribe(Story):
    I.find_category
    I.find_profile
    I.check_balance
    I.persist_subscription

    def find_category(self, state):
        state.category = self.load_category(state.category_id)

    def find_profile(self, state):
        state.profile = self.load_profile(state.profile_id)

    def check_balance(self, state):
        if state.category.cost > state.profile.balance:
            raise Exception

    def persist_subscription(self, state):
        state.subscription = self.create_subscription(
            category=state.category, profile=state.profile
        )

subscribe = Subscribe(
    load_category=load_category,
    load_profile=load_profile,
    create_subscription=create_subscription,
)

state = State(category_id=1, profile_id=1)

subscribe(state)

print(state)

PoC
class Step:
    def __init__(self):
        self.collected = []
    def __getattr__(self, name):
        self.collected.append(name)

class StoryType(type):
    def __prepare__(name, bases):
        return {'I': Step()}
    def __new__(cls, name, bases, namespace):
        print(namespace['I'].collected)
        del namespace['I']
        return type.__new__(cls, name, bases, namespace)

class Story(metaclass=StoryType):
    pass

I = None # make flake8

This issue will be kept until we create pull request from the milestone branch to the master.

Contrib package extraction would be a side effect of work no this feature.

Cancellation
I came to the conclusion - it should not be implemented in the first place.
It's concept is based around cancellation of steps.
But we should focus on domain processes.
In that case conditionals and separate story should be closer to expert thinking.

Our new release & develop branch approach does not require dedicated issue to merge develop into release.
This issue contains a log of 3 weeks of thinking on the problem.
Final result was decomposed into milestone tickets.
So, this issue could be closed safely.

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis.


routinator-0.9.0-rc1 and "server --detach" operation -- fails to start properly?

I have been running routinator 0.8.2 for a while, and have also tested 0.8.3, and they both work fine on the platform I use, NetBSD/amd64 9.0.  However, trying to upgrade to routinator 0.9.0-rc1 results in a routinator which doesn't appear to start properly.  It seems as if there is only one active thread in the process, and it fails to respond to the ports it's listening on, and appears to have deadlocked against itself.  Attaching a debugger reveals:
hugin# gdb work/routinator-0.9.0-rc1/target/debug/routinator
GNU gdb (GDB) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from work/routinator-0.9.0-rc1/target/debug/routinator...
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/pkgsrc/wip/routinator-0.9.0-rc1/work/routinator-0.9.0-rc1/target/debug/routinator.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) attach 2329
Attaching to program: /usr/pkgsrc/wip/routinator-0.9.0-rc1/work/routinator-0.9.0-rc1/target/debug/routinator, process 2329
Reading symbols from /usr/lib/librt.so.1...
Reading symbols from /usr/libdata/debug//usr/lib/librt.so.1.1.debug...
Reading symbols from /usr/lib/libpthread.so.1...
Reading symbols from /usr/libdata/debug//usr/lib/libpthread.so.1.4.debug...
Reading symbols from /usr/lib/libgcc_s.so.1...
Reading symbols from /usr/libdata/debug//usr/lib/libgcc_s.so.1.0.debug...
Reading symbols from /usr/lib/libc.so.12...
Reading symbols from /usr/libdata/debug//usr/lib/libc.so.12.213.debug...
Reading symbols from /usr/lib/libm.so.0...
Reading symbols from /usr/libdata/debug//usr/lib/libm.so.0.12.debug...
Reading symbols from /usr/libexec/ld.elf_so...
Reading symbols from /usr/libdata/debug//usr/libexec/ld.elf_so.debug...
[Switching to LWP 1 of process 2329]
0x00007a8639442a6a in _sys___nanosleep50 () from /usr/lib/libc.so.12
(gdb) where
#0  0x00007a8639442a6a in _sys___nanosleep50 () from /usr/lib/libc.so.12
#1  0x00007a8639e0a933 in pthread_cond_wait_nothread (abstime=<optimized out>,
    cond=0x7a863a0281d0, mutex=0x7a863a0281a0, self=0x7a863a4ad800)
    at /usr/src/lib/libpthread/pthread_cond.c:440
#2  pthread_cond_timedwait (cond=0x7a863a0281d0, mutex=0x7a863a0281a0,
    abstime=<optimized out>) at /usr/src/lib/libpthread/pthread_cond.c:150
#3  0x0000000115887a51 in <parking_lot_core::thread_parker::imp::ThreadParker as parking_lot_core::thread_parker::ThreadParkerT>::park (self=0x7a863a0281a0)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot_core-0.8.3/src/thread_parker/unix.rs:77
#4  0x0000000115892f03 in parking_lot_core::parking_lot::park::{{closure}} (
    thread_data=0x7a863a0281a0)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot_core-0.8.3/src/parking_lot.rs:611
#5  0x0000000115890701 in parking_lot_core::parking_lot::with_thread_data (
    f=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot_core-0.8.3/src/parking_lot.rs:183
#6  parking_lot_core::parking_lot::park (key=134716917455400, validate=...,
    before_sleep=..., timed_out=..., park_token=..., timeout=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot_core-0.8.3/src/parking_lot.rs:576
#7  0x0000000115884a33 in parking_lot::raw_mutex::RawMutex::lock_slow (
--Type <RET> for more, q to quit, c to continue without paging--
    self=0x7a863a029a28, timeout=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot-0.11.1/src/raw_mutex.rs:262
#8  0x000000011581e7fb in <parking_lot::raw_mutex::RawMutex as lock_api::mutex::RawMutex>::lock (self=0x7a863a029a28)
    at /usr/pkgsrc/wip/routinator/work/vendor/parking_lot-0.11.1/src/raw_mutex.rs:72
#9  0x000000011576a349 in lock_api::mutex::Mutex<R,T>::lock (
    self=0x7a863a029a28)
    at /usr/pkgsrc/wip/routinator/work/vendor/lock_api-0.4.4/src/mutex.rs:207
#10 0x000000011576c6ca in sled::threadpool::Queue::send (self=0x7a863a029a20,
    work=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/threadpool.rs:62
#11 0x000000011576e2ad in sled::threadpool::spawn (work=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/threadpool.rs:209
#12 0x00000001157c0890 in sled::pagecache::iterator::scan_segment_headers_and_tail::{{closure}} (idx=2)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/pagecache/iterator.rs:341
#13 0x00000001157753cd in core::iter::adapters::map_try_fold::{{closure}} (
    acc=(), elt=2)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/adapters/mod.rs:912
--Type <RET> for more, q to quit, c to continue without paging--
#14 0x000000011581a371 in core::iter::traits::iterator::Iterator::try_fold (
    self=0x7f7fff170078, init=(), f=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/traits/iterator.rs:1888
#15 0x000000011577d845 in <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold (self=0x7f7fff170078, init=(), g=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/adapters/mod.rs:938
#16 0x000000011577107e in <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::try_fold (self=0x7f7fff170078, init=(), f=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/adapters/mod.rs:2945
#17 0x0000000115774220 in core::iter::traits::iterator::Iterator::find (
    self=0x7f7fff170078, predicate=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/traits/iterator.rs:2231
#18 0x0000000115770e56 in <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next (self=0x7f7fff170078)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/adapters/mod.rs:2927
#19 0x000000011575d501 in alloc::vec::Vec<T>::extend_desugared (
    self=0x7f7fff1700e0, iterator=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/alloc/src/vec.rs:2388
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x0000000115764938 in <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::spec_extend (self=0x7f7fff1700e0, iter=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/alloc/src/vec.rs:2311
#21 0x00000001157693e9 in <alloc::vec::Vec<T> as alloc::vec::SpecFromIterNested<T,I>>::from_iter (iterator=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/alloc/src/vec.rs:2096
#22 0x000000011576522b in <alloc::vec::Vec<T> as alloc::vec::SpecFromIter<T,I>>::from_iter (iterator=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/alloc/src/vec.rs:2119
#23 0x000000011576ab49 in <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter (iter=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/alloc/src/vec.rs:1959
#24 0x000000011577485b in core::iter::traits::iterator::Iterator::collect (
    self=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/traits/iterator.rs:1670
#25 0x00000001156b3de1 in <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter::{{closure}} (i=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/result.rs:1490
#26 0x0000000115775f92 in core::iter::adapters::process_results (iter=...,
    f=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/adapters/mod.rs:2916
--Type <RET> for more, q to quit, c to continue without paging--
#27 0x00000001156b3c86 in <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter (iter=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/result.rs:1490
#28 0x0000000115774779 in core::iter::traits::iterator::Iterator::collect (
    self=...)
    at /work/lang/rust/work/rustc-1.49.0-src/library/core/src/iter/traits/iterator.rs:1670
#29 0x00000001157bf8cf in sled::pagecache::iterator::scan_segment_headers_and_tail (min=162529280, config=0x7f7fff1722f8)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/pagecache/iterator.rs:337
#30 0x00000001157c1e45 in sled::pagecache::iterator::raw_segment_iter_from (
    lsn=162910740, config=0x7f7fff1722f8)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/pagecache/iterator.rs:478
#31 0x000000011571b410 in sled::pagecache::snapshot::read_snapshot_or_default (
    config=0x7f7fff1722f8)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/pagecache/snapshot.rs:448
#32 0x00000001156d3b37 in sled::pagecache::PageCache::start (config=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/pagecache/mod.rs:588
#33 0x00000001157ae0aa in sled::context::Context::start (config=...)
--Type <RET> for more, q to quit, c to continue without paging--
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/context.rs:44
#34 0x0000000115821704 in sled::db::Db::start_inner (config=...)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/db.rs:70
#35 0x00000001156a01ee in sled::config::Config::open (self=0x7f7fff174380)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/config.rs:354
#36 0x00000001151ed441 in sled::db::open (path=0x7f7fff174648)
    at /usr/pkgsrc/wip/routinator/work/vendor/sled-0.34.6/src/db.rs:25
#37 0x00000001151e4e4e in routinator::engine::Engine::open_db (
    cache_dir=0x7a863a497000, fresh=false) at src/engine.rs:162
#38 0x00000001151e516a in routinator::engine::Engine::new (
    config=0x7f7fff17a548, update=true) at src/engine.rs:207
#39 0x00000001151d9aa6 in routinator::operation::Server::run (self=...,
    process=...) at src/operation.rs:526
#40 0x00000001151d4fbe in routinator::operation::Operation::run (self=...,
    config=...) at src/operation.rs:170
#41 0x00000001151d3811 in routinator::_main () at src/main.rs:34
#42 0x00000001151d39e9 in routinator::main () at src/main.rs:38
(gdb) i thread
  Id   Target Id                Frame
* 1    LWP 1 of process 2329 "" 0x00007a8639442a6a in _sys___nanosleep50 ()
   from /usr/lib/libc.so.12
(gdb)

I've configured routinator to enable the web server on port 9556, and while I can connect to it, that's probably only the OS allowing the TCP connection, because it's unresponsive if I type "GET /status HTTP/1.0" followed by two newlines.
A little more trial and error appears to reveal that it's the --detach flag which is the culprit: start routinator without it, and there is multiple threads started, and activity logged on stdout and/or stderr.  However, that's not the way I like to run this in production...
Any ideas what might be causing this?

Sounds like this is an issue related to multi-threading and forking. Previously we didn’t do anything “suspicious” before forking, but now we open the database before forking to make sure it looks all right.
Since I don’t have a NetBSD box around, can you perchance try the server-no-engine-init branch to see if that fixes the issue?

We’ve now had reports that this also happens on Linux. Those reports also indicate that the change in the server-no-engine-init fixes the issue at least on Linux.


Examples for using DrawContext

I can't seem to comprehend how I'm supposed to use the DrawContext (or where do I get uiDrawContext ptr for instancing new DrawContext). Quick example could help

@LeoTindall this is blocked on the area mod not being exported from controls::, even though the source file exists. is this because it's incomplete/doesn't compile or something along those lines?

No, it's not exported because it's not sufficiently documented, mostly because there are no examples. It's a totally circular dependency relationship there.

Hi @barzamin would you mind to share what you discovered? I tried hard to make a simple example but had no luck. Thank you! :)

@Pomettini my code is super WIP and requires changes to iui internals to work, but i'll try to post it in the next few days


App / COMPUTING RESOURCES section is confusing

I've seen at least 3 lab members getting confused about "App / COMPUTING RESOURCES". They don't know why their submission is not getting executed (it's busy), and some thinks that their App is not enabled on the resource. The table seems to be interpreted as all registered resource - instead of where Apps are enabled. The "resource is busy" message shown is not getting across.
We need to redesign this section, and probably make it more intuitive by having some kind of visual feedbacks / graphs.

I've replaced the table with a bit more graphical display. I've also improved various status messages to be more clear on the resource registration status.


fix typo in build.sh: simlify -> simplify

Wow, can't believe I left that in there. The current release has wrong executable name as well :)
I'll tag a 1.1 at some point, there has been some other fixes as well.


Auto-completions spec conformance for the RawTemplateExpression

Description:
$title

Auto completions are inline with the spec, hence closing the issue


./hack/test-example.sh ./examples/default.yaml hangs on Sending HMP loadvm command

$ ./hack/test-example.sh ./examples/default.yaml
...
INFO[0000] [hostagent] Sending QMP system_powerdown command
INFO[0001] [hostagent] QEMU has exited
TEST| [INFO] Restarting "default"
INFO[0000] Using the existing instance "default"
INFO[0000] Attempting to download the nerdctl archive    arch=x86_64 digest="sha256:3bb5f5358ee2c3bd9097e0bf37649c1775e2449094e75acf629f129ec2c7915f" location="https://github.com/containerd/nerdctl/releases/download/v1.4.0/nerdctl-full-1.4.0-linux-amd64.tar.gz"
INFO[0000] Using cache "/Users/suda/Library/Caches/lima/download/by-url-sha256/7f7d5c10ef2e2b350e26ceca17d2e3a7ce9993c867ce53f0a1114aa0264bfb4b/data"
INFO[0001] [hostagent] Starting QEMU (hint: to watch the boot progress, see "/Users/suda/.lima/default/serial.log")
INFO[0002] SSH Local Port: 60022
INFO[0002] [hostagent] Waiting for the essential requirement 1 of 5: "ssh"
INFO[0021] [hostagent] The essential requirement 1 of 5 is satisfied
INFO[0021] [hostagent] Waiting for the essential requirement 2 of 5: "user session is ready for ssh"
INFO[0033] [hostagent] Waiting for the essential requirement 2 of 5: "user session is ready for ssh"
INFO[0034] [hostagent] The essential requirement 2 of 5 is satisfied
INFO[0034] [hostagent] Waiting for the essential requirement 3 of 5: "sshfs binary to be installed"
INFO[0034] [hostagent] The essential requirement 3 of 5 is satisfied
INFO[0034] [hostagent] Waiting for the essential requirement 4 of 5: "/etc/fuse.conf (/etc/fuse3.conf) to contain \"user_allow_other\""
INFO[0034] [hostagent] The essential requirement 4 of 5 is satisfied
INFO[0034] [hostagent] Waiting for the essential requirement 5 of 5: "the guest agent to be running"
INFO[0034] [hostagent] The essential requirement 5 of 5 is satisfied
INFO[0034] [hostagent] Mounting "/Users/suda" on "/Users/suda"
INFO[0034] [hostagent] Mounting "/tmp/lima" on "/tmp/lima"
INFO[0035] [hostagent] Waiting for the optional requirement 1 of 2: "systemd must be available"
INFO[0035] [hostagent] Forwarding "/run/lima-guestagent.sock" (guest) to "/Users/suda/.lima/default/ga.sock" (host)
INFO[0035] [hostagent] The optional requirement 1 of 2 is satisfied
INFO[0035] [hostagent] Not forwarding TCP <IP_ADDRESS>:53
INFO[0035] [hostagent] Waiting for the optional requirement 2 of 2: "containerd binaries to be installed"
INFO[0035] [hostagent] Not forwarding TCP <IP_ADDRESS>:53
INFO[0035] [hostagent] Not forwarding TCP [::]:22
INFO[0035] [hostagent] The optional requirement 2 of 2 is satisfied
INFO[0035] [hostagent] Waiting for the final requirement 1 of 1: "boot scripts must have finished"
INFO[0035] [hostagent] The final requirement 1 of 1 is satisfied
INFO[0035] READY. Run `lima` to open the shell.
TEST| [INFO] Make sure proxy setting is updated
TEST| [INFO] FTP_PROXY: expected=FTP_PROXY=my.proxy:8021 got=FTP_PROXY=my.proxy:8021
TEST| [INFO] Testing online snapshots
INFO[0000] Sending HMP savevm command
INFO[0000] Sending HMP info command
TEST| [INFO] snapshot list: expected=snap1 got=snap1
INFO[0000] Sending HMP loadvm comman
(hangs up here)

Lima: 79a126a
QEMU: 8.0.0
Host: macOS 13.4 (Intel)

Wonder if the VM hangs, or if it is only networking?
Could run the machine with a display perhaps (locally)

Apparently only the slirp networking is down. serial.sock is alive.

Trying with the announce_self QMP command, after the loadvm

Workaround

https://github.com/lima-vm/lima/pull/1676


Help needed with NameSpaceRuleChecker

Hello,
I have managed to successfully test several of the checkers using an intentionally vulnerable test application I developed, but so far, I have had no luck with this checker.
The scenario is as follows:

customer1 can POST messages to /customers/customer1/messages
customer2 can do the same to /customers/customer2/messages

They can GET a message back (that has a specific messageID) using, e.g.:

customer1 (who has posted message 1) from /customers/customer1/messages/1
customer2 (who has posted message 2) from /customers/customer2/messages/2

I have implemented a bug that allows customer2 to access messages from customer1, e.g., GET /customers/customer1/messages/1 works. As I understand this checker, this should be detectable.
Compiling and testing works. The OpenAPI config is correct. restler test works correctly and the messageID returned by POST is associated with the corresponding GET request. The test application uses JWTs that have been configured correctly and restler uses the tokens correctly. I've also enable the checker using --enable_checkers namespacerule.
The program that returns the two JWTs is as follows (the first one is of customer1, the second of customer2):
#!/usr/bin/env python
import sys
sys.stdout.write("{'customer1':{}, 'customer2':{}}\n")
sys.stdout.write("Authorization: Bearer eyJhbGciOiJIUzI1...\n")
sys.stdout.write("Authorization: Bearer eyJhbGciOiJIUzI1....\n")

I'm unsure about the metadata that must be returned as the first line. I suppose that they should include the URL-part that identifies the customer-specific areas, but I cannot find any information about this (Authentication.md does only provide little information).
I added logging to the application that prints the JWT used in the requests from restler. They only use the first token, never the second, so it appear this checker is never invoked at all.
Any help would be appreciated, thanks!

Hi Marc,
Thanks a lot for your thorough writeup.  This checker had been moved out of the default fuzzing strategy and thus neglected in testing.  There looks to be a bug rendering this checker inoperable at the moment. I'll get it fixed today.
Thanks again!


volume

right now using just quote_volume: https://github.com/oxarbitrage/udf-bitshares-wrapper/blob/master/wrapper.py#L209
need to ask @svk or @abitmore what will be the calculation to send the right volume to the wrapper and implement.

was changed to base_volume according to some conversations i have with some traders in telegram main bitshares channel. closing by now.


Where can I get an alpha package

What would you like to be added:
Hi there, I want to test the mac package before it release , but I don't want to build it from src.
So I want lens add download link for alpha version in Releases page
Why is this needed:
I can check the fitness between alpha package and my k8s environment
Environment you are Lens application on:

Kubernetes distribution: Rancher
Desktop OS: Mac OS

You can go to user preferences and change the release channel from "stable" to "alpha".


Add a JUnit output formatter compatible with Jenkins

Added the parameter --junit to bats which output into JUnit XML format, the purpose was to integrate the report into Jenkins
I had to add the suite name into the extended report format so I can classify tests by file
I added --extended parameter to bats command so you can run the test suite once and format the output into several format (ie: pretty for the console and junit into a result.xml file)

Please advise if you see anything to change!

This is awesome!

As noted by the Travis build, the tests fail with this PR.
I was interested in merging this PR into my harschware/cactus branch (which is where I keep a merge of all the PRs I'm interested in, since PRs are not being merged into the sstephenson/bats repo for sometime now).
The main thing I'm interested in from this PR was the timing information, since I see you added it to the TAP test status lines, for extended syntax.  But after looking at the code I don't think it work well as a starting point for my purpose.  I am looking to test duration in millseconds to the TAP output via YAML extension.
Be aware that the TAP13 specification does not provide for a way to indicate time, but the issue of supporting that in the spec has been discussed.  No TAP14 spec exists today, but it essentially comes down to two methods being discussed.
add # time=NNN to the test line
add YAML to the test. e.g.
1..1
ok YAML time with duration
duration_ms: 45293

...
The YAML extension is supported by Jenkins TAP Plugin (https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin), incidentally JUnit isn't strictly required to use BATS in Jenkins if you use the TAP plugin instead of JUnit.
Not all TAP consumers respect the YAML extension, but at minimum tap4j does.
I will probably want to at minimum, ammend the extended format in BATS to include time in milliseconds rather than seconds.  When it comes time to merge our two PRs to this repo (if ever) there will be a slight divergence there.

See PR #177 for details about TAP with YAML extension.

Here is the fix for tests.
Your work looks great, I didn't found any way to calculate the time in milliseconds in pure "bash", I used this framework because it's highly portable, for example the usage of the command date is different on AIX and on Solaris 10, so I simplified the problem by displaying the time in seconds.
Suggestions are welcome :)

What's the status of this?
FYI, Solano CI parser does not support TAP, sadly, so having a JUnit formatter is the only alternative.
@sstephenson or @mislav, is this project still being looked at? Thanks for your great work!

If you start using automated validation tools early on, you can increase tremendously the efficiency of your testing. Your end user wouldn't need to find the bugs themselves. I learned this from this article: http://blog.testproject.io/2017/01/04/why-use-automated-validation-tools-early/

Any news on this? Would love to see this gets in.

Would also like this in. PR Contributor did the work and fixed the tests.

I rather feel that supporting multiple output formats is outside the role of bats.
TAP output is (or is becoming?) a near lingua-franca of test report formats. TAP can be consumed and converted to virtually any other format (dot, spec, xunit, etc)
If all that is desired is TAP consumption by jenkins/hudson, I would advocate for the TAP plugin: https://wiki.jenkins.io/display/JENKINS/TAP+Plugin
Separately, though, I would advocate for any other test report formats to consume the TAP output on STDIN, and transform to the desired output by piping. For example: https://github.com/aghassemi/tap-xunit (which could be used as-is to convert Bats' TAP output to xunit without needing the option supported in bats.)
As it stands, the current formatter could be shipped as a standalone TAP converter that just receives Bats' TAP output. Creating a separate bats-xunit project would be a fine repo for future inclusion in a potential bats-core github org. I just don't think it should necessarily be bundled within bats itself.

Hey hey, any update on this PR? i'd love to see this merged to be able to have junit output for jenkins blue ocean


Add support for smaller chunk allocations

Adds a new flag, --storage.tsdb.max-block-chunk-segment-size, which control the max size (and thus allocation size) of chunks files in a block. Specifically useful for small prometheus instances where the existing 512MiB allocation size is often many times the actually required space, requiring inflated resource claims to store even tiny amounts of data.
@codesome sounds like your wheelhouse since most of the change is in tsdb, sorry if this should go to someone else.

cc @codesome WDYT about this?

I think that it might be more wise to disable the preallocation instead of changing the size? WDYT @bwplotka ?

The reason is that the full chunk segment is rarely fully allocated (if ever).

The files are preallocated. So I guess the entire file size is reserved on disk?

Thanks for this PR, but I don't think this is as easy as changing chunk segment size.
The reason is that the full chunk segment is rarely fully allocated (if ever). Also, the question is do you mean block or WAL segment? If block then this PR looks like only build block chunk segment smaller, which means existing block chunks AND WAL chunk segments are unchanged 🤔
I think for this kind of constraint resource environment, you should use coming soon Prometheus agent more (which will use https://github.com/grafana/agent existing code) 🤗
WDYT?
I am just saying that even with 1MB segment chunk size: firstly Prometheus will be super slow, secondly you will allocate more for index and other stuff anyway, so agent OR some more strict allocation constraints are necessary, not block data format.

So the underlying problem is that we try to preallocate a max size chunk when starting the next block. This is totally reasonable behavior, but this also means that you need disk space sufficient to hold your data + 1 max size chunk. For large deployments that extra chunk is a rounding error, but if your entire instance only needs ~40MB otherwise, that's a lot of extra disk space you have to take.
This came up for us because we're starting to encourage teams internally to spin up their own prometheus instances (and handle cross querying via Thanos), but most teams only need a few MB of storage for their actual data, but are taking half a gig each to work around this. Multiply that times several hundred and it's a material amount of space.

The *ChunkSize is confusing since we call a compressed unit of samples as Chunk, and as Bartek pointed out *ChunkSegmentSize makes sense as a file. But since we have other chunk files (like Head chunks m-map file), I would like to explicitly call it *BlockChunkSegmentSize everywhere (including changes required in comments where you are referring it).
We should have some minimum size for this flag else an erroneous value could spit out many empty files until the OS runs out of inodes. I would keep min as 1MB.

I'll adopt this naming convention. I really don't like the chunk segment naming convention since everywhere else in the code and docs we refer to WAL segments and block chunks. The only place "chunk segment" is used is in chunks.go where it's incredibly confusing because it implies that a chunk can have multiple segments which isn't how it actually works (unless the docs are wrong and I'm misreading the code)
I'm out today, but will work on making the requested changes tomorrow.

it implies that a chunk can have multiple segments which isn't how it actually works

In the context of blocks, "chunks" actually means the chunks directory which has multiple files. An actual chunk is just few hundred bytes at max.

it implies that a chunk can have multiple segments which isn't how it actually works

In the context of blocks, "chunks" actually means the chunks directory which has multiple files. An actual chunk is just few hundred bytes at max.

Right, based on the documentation around the storage system (and reading the code the last few days) that's exactly what I'd expect "chunks" to mean, and a "chunk" would be one file in the chunks directory for some block. Which is why calling those files "chunk segment" is so confusing, it implies that each of those file are made up of multiple segments rather than being one segment each.
Thus the preference for "block chunk" as the name here. "Block chunk segment" is going to be very confusing to anyone trying to figure out what the flag does if they've read the storage docs but not the actual contents of chunks.go. If you feel strongly about the name then I'll defer to your judgement, but I'd fairly strongly prefer not to propagate the "chunk segment" term anywhere else (I'd really like to rip it out of chunks.go so it's not so misleading to new readers, but that's way outside of the scope of this change).

Alternatively, if you feel strongly about using "block chunk segment" rather than "block chunk", would you accept a patch to storage.md to stop calling a file in the chunks directory a "chunk" and instead call them chunk segments? I really just care that we don't have a command line flag using terminology that clashes with the documentation.

We have been calling the storage files as segments (example WAL segments) and sometimes explicitly "files". So to be consistent, I would choose to call "block chunk segment" when we are referring to a file.

would you accept a patch to storage.md to stop calling a file in the chunks directory a "chunk" and instead call them chunk segments?

Yeah definitely. But am I missing something? Because I see storage.md calling it "chunk files" explicitly which I would leave as it is.

"chunk segment" means a part of one of those file rather than an entire file

Yeah that is another confusion. But since we have been using "segment" for a file for a long time now in this project, I would keep it same to avoid any more confusion in many other places.

We have been calling the storage files as segments (example WAL segments) and sometimes explicitly "files". So to be consistent, I would choose to call "block chunk segment" when we are referring to a file.

would you accept a patch to storage.md to stop calling a file in the chunks directory a "chunk" and instead call them chunk segments?

Yeah definitely. But am I missing something? Because I see storage.md calling it "chunk files" explicitly which I would leave as it is.

Maybe I read that strangely, but "chunk files" to me means "chunks, represented as files" not "file full of chunks". Especially since the directory is called "chunks" which would usually mean that each file in it is a "chunk". I'd like to change that to say "chunk segment files" so that when someone reads the flag and goes "what's a chunk segment?" they actually find the answer in the docs.

Swapped to the "max block chunk segment size" naming convention. Will have a patch for better tests tomorrow.

@codesome @bwplotka did you see the update here?

I think all the feedback has been addressed at this point if people don't mind taking another look. Please let me know if you'd like further changes.

friendly ping @codesome

@nberkley
Thanks for implementing this feature. When executing prometheus -h flag storage.tsdb.max-block-chunk-segment-size is not shown.
prometheus -h | grep storage.tsdb
      --storage.tsdb.path="data/"
      --storage.tsdb.retention=STORAGE.TSDB.RETENTION
                                 "storage.tsdb.retention.time" instead. Use with
      --storage.tsdb.retention.time=STORAGE.TSDB.RETENTION.TIME
                                 "storage.tsdb.retention". If neither this flag
                                 nor "storage.tsdb.retention" nor
                                 "storage.tsdb.retention.size" is set, the
      --storage.tsdb.retention.size=STORAGE.TSDB.RETENTION.SIZE
      --storage.tsdb.no-lockfile
      --storage.tsdb.allow-overlapping-blocks

Is this by intention or just forgotten? Would be great if that could be added, this helps a lot. Found that flag on https://promlabs.com/blog/2021/05/16/whats-new-in-prometheus-2-27

I've long since paged the context for this out of my head, but, if I recall correctly, most of the tuning flags around this type of stuff that should only really be used for corner case deployments are hidden from the help message to reduce cognitive load for typical users, so I opted to also hide this one to follow that precedent. I have no strong opinions on this either way if someone were to try to add it to the help message.

It makes sense to hide seldom used configuration options for the average user. And it needs then a documentation were all flags can be found. On https://prometheus.io/docs/prometheus/latest/configuration/configuration/ is written

To view all available command-line flags, run ./prometheus -h.

That is why I was asking here. I could only find the linked blog article documenting this flag. Do you know a documentation site were all flags are explained? I would then submit a pull request to change To view all available command-line flags, run ./prometheus -h. accordingly.


Running tests within a transaction

A common pattern for testing code in the Ruby world (using RSpec) is to run each of your app's tests within a transaction, and then rollback the transaction once the test is done. That way each test is run in an isolated environment and isn't filling up a db with junk.
Is there a way to do this with Knex? I've spent a few hours trying to make it work with mocha. The following don't seem to work:
beforeEach(function (done) {
  knex.raw("start transaction").then(function () {
    done();
  });
});

afterEach(function (done) {
  knex.raw("rollback").then(function () {
    done();
  });
});

or
var trx;
beforeEach(function (done) {
  knex.transaction(function (newTrx) {
    trx = newTrx;
    done();
  });
});

afterEach(function (done) {
  trx.rollback().then(function () {
    done();
  });
});

I apologize if this question is naïve but I'm new to knex.

you don't event have to rollback since not commiting is an automated rollback.
What I learned today after hours of debugging is that mysql does not rollback auto_increment columns :(

@JonAbrams you have to take care that all queries that are executed during the test are run within this transaction.
describe('stuff', () => {
  var trx = knex;
  beforeEach(function (done) {
    knex.transaction(function (newTrx) {
      trx = newTrx;
      done();
    });
  });

  it('should work', function () {
    return trx('table_name').insert(data);
  });
});

@JonAbrams Thanks!
The problem is when you need to test code that opens its own transaction. (Transactions within transactions are not allowed in postgresql 😢 )

@flushentitypacket See the above comment maybe it can help you?

@flushentitypacket knex has implemented nested transactions with save points (should work also with postgres)

I have switched to Sequelize after having so much issues with knexjs. I am now a happy Sequelize user :)

@soubhikchatterjee good for you, I hope it suits well for your needs 🙂 In my opinion knex is way too low level library to be used directly in app development anyways.

@flushentitypacket I figured out a way to do this with similar code as shown by @JonAbrams
describe('Test suite', async () => {
  let trx;

  beforeEach(async () => {
    trx = await knex.transaction();
  });

  afterEach(() => {
    trx.rollback();
  });

  it('Individual test', async () => {
    const bar = trx('sometable').insert({ non_default_property: 'foo' }).returning('*');
    console.log('bar:', bar);
  });

You can pass the transaction (trx) to functions that need to make use of it.


#1: add support for horses in database initialization

Adding in horse

/paulo - can you please review this pull request?

/paulo - can you check now?


Exit/status code is always 0

I can run tslint on a file that has failures and the exit status is non-zero and the exit status for a file with no failures is 0, both as they should be:
rpatterson@rpatterson:~/src/work/newcontext/Soltra/argos/argos-ui$ ./node_modules/.bin/tslint
...
src/app/....ts[63, 56]: missing whitespace
$ echo $?
2
$ ./node_modules/.bin/tslint src/app/...ts
$ echo $?
0

But running tsconfig-lint with a config that includes the same files and reports the same failures has an exit status of 0:
$ ./node_modules/.bin/tsconfig-lint
Linting 28 files
...
src/app/...ts[63, 56]: missing whitespace

Done with 63 failures.
$ echo $?
0

This makes using tsconfig-lint in CI is much more difficult than it need be.

This should be the default behavior in v0.10.0

Doh!  Sorry I forgot to check if I was running the latest.
On Tue, Mar 22, 2016 at 8:39 AM, Will Johnston<EMAIL_ADDRESS>wrote:

Closed #6 https://github.com/wjohnsto/tsconfig-lint/issues/6.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/wjohnsto/tsconfig-lint/issues/6#event-598891041

I just published it :), your sanity can be saved!


mpi4py issue with large k-eigenvalue simulations in Lassen

On Lassen, MCDC breaks after the first eigenvalue cycle if the number of histories per cycle is larger than 1e5 and numba is enabled.
#     k        k (avg)
 ==== ======= ===================
 1     1.43481
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
Traceback (most recent call last):
  File "/usr/WS1/northroj/SMR/mcdc/c5g7td/inffuel/input.py", line 78, in <module>
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    mcdc.run()
  File "/usr/WS1/northroj/miniconda3/MCDC/mcdc/main.py", line 41, in run
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1438, in mpi4py.MPI.Comm.recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 341, in mpi4py.MPI.PyMPI_recv
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '_'.
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\xba'.
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\x00'.
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\x00'.
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
OverflowError: BINBYTES exceeds system's maximum size of<PHONE_NUMBER>854775807 bytes
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\x0f'.
  File "mpi4py/MPI/msgpickle.pxi", line 306, in mpi4py.MPI.PyMPI_recv_match
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\xfe'.
  File "mpi4py/MPI/msgpickle.pxi", line 152, in mpi4py.MPI.pickle_load
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\x00'.
_pickle.UnpicklingError: invalid load key, '\x00'.
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: unexpected MARK found
  File "mpi4py/MPI/msgpickle.pxi", line 141, in mpi4py.MPI.cloads
_pickle.UnpicklingError: invalid load key, '\x9f'.

@spasmann: was this like any of the issues you had seen?

I've also encountered this issue, typically when running on the ND cluster. But I just ran the Takeda-1 problem with N=2e5 with 2 MPI processes and seem to get the same issue, although the output is somewhat different.
 #     k        k (avg)
 ==== ======= ===================
←[K 1     0.41197================] 100%
Traceback (most recent call last):
  File "C:\Users\Sam\Documents\Github\MCDC\examples\eigenvalue\takeda_1\input.py", line 192, in <module>
Traceback (most recent call last):
  File "C:\Users\Sam\Documents\Github\MCDC\examples\eigenvalue\takeda_1\input.py", line 192, in <module>
    mcdc.run()
  File "c:\users\sam\documents\github\mcdc\mcdc\main.py", line 45, in run
    mcdc.run()
  File "c:\users\sam\documents\github\mcdc\mcdc\main.py", line 45, in run
    loop_main(mcdc)
    loop_main(mcdc)
  File "mpi4py/MPI/Comm.pyx", line 1839, in mpi4py.MPI.Intracomm.Exscan
  File "mpi4py/MPI/Comm.pyx", line 1839, in mpi4py.MPI.Intracomm.Exscan
  File "mpi4py/MPI/msgbuffer.pxi", line 874, in mpi4py.MPI._p_msg_cco.for_exscan
  File "mpi4py/MPI/msgbuffer.pxi", line 874, in mpi4py.MPI._p_msg_cco.for_exscan
ValueError: mismatch in send and receive MPI datatypes
ValueError: mismatch in send and receive MPI datatypes

Tested the other mpi modules on Lassen. spectrum-mpi/2019.06.24 didn't run at all, and spectrum-mpi/2020.08.19 and spectrum-mpi/test-rolling-release got similar errors to the rolling release.


Bug in "Target the Parent of an Element Using jQuery"

Challenge http://www.freecodecamp.com/challenges/waypoint-target-the-parent-of-an-element-using-jquery has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
I solved the whole thing and the error is still there saying "Your left-well element should have a red background." when it is red already and the code is correct too, please check it!!

Hi @parthm17, next time open an issue with a normal title. And provide more information on your issue.

As from your description and after checking the Waypoint, it seems everything is fine.
In the "challenge" it is asked to use "#target1" as jQuery selector and "parent()" as a function/method to select the parent element of the "target1" element, here "#left-well" it is.
There is also an example in the description provided, try to follow that, and then click the "Run Code" button or press "Ctrl + Enter" to see if it works or not.

@MarufSarker is totally right and I think he can't pass the test due to improper use of parent() function. The problem is that many of our campers don't read instructions attentively. There are a lot of duplicate issues closed similar to this one so I'll close this too, but @parthm17 feel free to reopen it if you steel have a problem.


BeanRecordFieldExtractor is poorly named

This is related to #234 , the BeanRecordFieldExtractor extracts fields from the payload of a record and the record object. It should be renamed to BeanFieldExtractor

implemented in f824576ed98de3cd37d9dcd97030c846ff33e433


re-exporting delcaration file should not generate export javascript code

When TypeScript generates an export from a .d.ts file, the generated .js file will be invalid and throw errors about the file not existing.

TypeScript Version:  4.0.3

Search Terms:
re-export all from declaration file
export type *
export *
Code
tsconfig.json
{
    "compilerOptions": {
        "alwaysStrict": true,
        "baseUrl": ".",
        "declaration": true,
        "esModuleInterop": true,
        "importHelpers": true,
        "module": "commonjs",
        "moduleResolution": "node",
        "target": "es6"
    }
}

foo.d.ts
export interface Foo { }

bar.ts
export * from './foo'

Expected behavior:
bar.js
"use strict";

bar.d.ts
export * from './foo';

foo.d.ts
export interface Foo { }

Actual behavior:
bar.js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const tslib_1 = require("tslib");
tslib_1.__exportStar(require("./foo"), exports);

bar.d.ts
export * from './foo';

Note:
On a separate issue, I can not figure out a way to export tell TypeScript to copy the foo.d.ts file to the outDir when compiling.

A module declaration file is a file that represents a module that actually exists. Writing foo.d.ts when no foo.js module exists is telling the compiler a lie and it will believe you. It sounds like you just want to write a foo.ts file instead, and possibly not make it a module either (hard to say based on what's in here).

@RyanCavanaugh Is there no way to write helper types in a separate file without that file being compiled, but still providing it in an NPM package? For example, if I were to create a very complex type, I'd rather move it to a different file, but I also don't want that file to have an associated .js file.
I thought this was a feature of typescript, especially with the new import type {} from ''; syntax.


fix(dialog): Adding dark theme to dialog

PR Checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

The current dialog ignores theme provider's theme setting and force light theme on all dialogs.
What is the new behavior?
The new change will read the theme from theme provider and change the colors to appropriate colors.
Other information
There is one accessibility check failing on dark theme, but it's because of the <a> tag color. I assumed that <a> tags should be replaced with ps-design-system-link, and that'd make it accessible. Let me know if I should change the <a> tag color to --ps-colors-primary-action-text-dark-theme in storybook.
Thanks! 🙏🏼

This was a branding decision for the pre-2022 brand and this change will create a massive breaking change for all the teams and overall product (from skills to flow). The Flow team also very specifically requires a white dialog until they move to the v2 branding.
This library is also officially in maintenance mode which means we are not adding any new features. We are only merging bug fixes or a11y enhancements.
Closing.


Question: Can you output ESM?

Haven't dove deep but spun up a quick test with the following input and the output contains an IIFE and does not contain ESM exports.
app/entry.browser.ts:
export const message = "Hello, World!";
console.log(message as string);

repack.config.js:
const path = require("node:path");

module.exports = {
	entry: {
		"entry.browser": "./app/entry.browser.ts",
	},
	output: {
		filename: "[name].js",
		path: path.resolve(__dirname, "public/build"),
		enabledLibraryTypes: ["module"],
		library: {
			type: "module",
		},
	},
	optimization: { minimize: false },
};

fixed in #2803

@hardfist this fixes support for ESM in the same way that webpack supports ESM which is a big win.  However after talking with @valorkin and @ScriptedAlchemy, we would like to see a way to output an ESM target for library authoring similar to how Rollup preserveModules works. That would allow us to do things like this for Angular.

support preserveModules is another feature request that needs to be discussed, I think this feature request is solved right now.

Close for having https://github.com/web-infra-dev/rspack/pull/2803


[T4A6][W13-B2] Bernard Koh

Ready for Review

@bernardified
Some comments added. Please ack & close the PR after reading comments.


Frontend

I've written the socket library and edit the chat interface

Temporal merge to test connection between different parts


[WIP] Create federal senate app

What is the purpose of this Pull Request?
Start the Federal Senate app.
It's a simple PR so that other contributions can happen simultaneously and get close to what we have in the chamber_of_deputies app
What was done to achieve this purpose?
I created a new django app federal_senate, a Reimbursement model based on the csv from serenata-toolbox project with some fields based on Reimbursement from chamber_of_deputies.
How to test if it really works?
Run the migrations and the tests docker-compose run --rm django python manage.py test jarbas/federal_senate/
Who can help reviewing it?
Anyone =)

Fixes #431

Hello, @giovanisleite. We're in a Serenata Sprint and there are a bunch of people willing to help. What is missing to this PR so it can be merged? We can help move it forward :smile_cat:

Hey @cuducos and @sergiomario, I checked out @giovanisleite branch and run it locally. It seems it's missing only register the new app models to the Dashboard. What do you think merging it to allow others work on this? This way we do not lose the work/contribution made by Giovani and enable new contributions to have the Senate on Jarbas.

Hello, @giovanisleite. We're in a Serenata Sprint and there are a bunch of people willing to help. What is missing to this PR so it can be merged? We can help move it forward

Sorry, I didn't see this message earlier.
This PR is part of the solution for #431, the first part to be exactly (Create Federal Senate app & Reimbursement model based on serenata-toolbox csv)

Now the new app is registered on the dashboard!


Fix append without duplicates

Fixes the bug mentioned in #81

Awesome, fixing the weird edge cases!


tensorflow.python.framework.errors_impl.ResourceExhaustedError: OOM

Hi,
I'm sorry about asking this, but I have no idea to solve this problem when run train.py. the following is error message:
System information

OS Platform and Distribution: Windows 10
TensorFlow version: 1.2
CUDA/cuDNN version:
Cuda compilation tools, release 9.1 and cuDNN 8.0 with the NVIDIA Quadro M500M
GPU memory: 2G
Python version**: Python 3.6.2 |Anaconda 4.4.0 (64-bit)|

Error Message:
Found GPU! Using channels first as default image data format.
Traceback (most recent call last):
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 1361, in _do_call
return fn(*args)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 1340, in _run_fn
target_list, status, run_metadata)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\framework\errors_impl.py", line 516, in exit
c_api.TF_GetCode(self.status.status))
tensorflow.python.framework.errors_impl.ResourceExhaustedError: OOM when allocating tensor with shape[32,256,35,35] and type float on /job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc
[[Node: mixed0/concat = ConcatV2[N=4, T=DT_FLOAT, Tidx=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](activation_5/Relu, activation_7/Relu, activation_10/Relu, activation_11/Relu, gradients/global_average_pooling2d/Mean_grad/Maximum_1/y)]]
Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.
     [[Node: GradientDescent/update/_2290 = _Recv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_4395_GradientDescent/update", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/device:CPU:0"]()]]

Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File ".\train.py", line 235, in
[global_step, mean_xentropy, train_op, update_brier])
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 905, in run
run_metadata_ptr)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 1137, in _run
feed_dict_tensor, options, run_metadata)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 1355, in _do_run
options, run_metadata)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\client\session.py", line 1374, in _do_call
raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.ResourceExhaustedError: OOM when allocating tensor with shape[32,256,35,35] and type float on /job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc
[[Node: mixed0/concat = ConcatV2[N=4, T=DT_FLOAT, Tidx=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](activation_5/Relu, activation_7/Relu, activation_10/Relu, activation_11/Relu, gradients/global_average_pooling2d/Mean_grad/Maximum_1/y)]]
Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.
     [[Node: GradientDescent/update/_2290 = _Recv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_4395_GradientDescent/update", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/device:CPU:0"]()]]

Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.
Caused by op 'mixed0/concat', defined at:
File ".\train.py", line 133, in
include_top=False, weights='imagenet', pooling='avg', input_tensor=x)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\applications\inception_v3.py", line 216, in InceptionV3
name='mixed0')
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\layers\merge.py", line 665, in concatenate
return Concatenate(axis=axis, **kwargs)(inputs)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\engine\topology.py", line 258, in call
output = super(Layer, self).call(inputs, **kwargs)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\layers\base.py", line 696, in call
outputs = self.call(inputs, *args, **kwargs)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\layers\merge.py", line 174, in call
return self._merge_function(inputs)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\layers\merge.py", line 380, in _merge_function
return K.concatenate(inputs, axis=self.axis)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\keras_impl\keras\backend.py", line 2083, in concatenate
return array_ops.concat([to_dense(x) for x in tensors], axis)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\ops\array_ops.py", line 1175, in concat
return gen_array_ops._concat_v2(values=values, axis=axis, name=name)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\ops\gen_array_ops.py", line 777, in _concat_v2
"ConcatV2", values=values, axis=axis, name=name)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\framework\op_def_library.py", line 787, in _apply_op_helper
op_def=op_def)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\framework\ops.py", line 3271, in create_op
op_def=op_def)
File "D:\ProgramData\Anaconda3\lib\site-packages\tensorflow\python\framework\ops.py", line 1650, in init
self._traceback = self._graph._extract_stack()  # pylint: disable=protected-access
ResourceExhaustedError (see above for traceback): OOM when allocating tensor with shape[32,256,35,35] and type float on /job:localhost/replica:0/task:0/device:GPU:0 by allocator GPU_0_bfc
[[Node: mixed0/concat = ConcatV2[N=4, T=DT_FLOAT, Tidx=DT_INT32, _device="/job:localhost/replica:0/task:0/device:GPU:0"](activation_5/Relu, activation_7/Relu, activation_10/Relu, activation_11/Relu, gradients/global_average_pooling2d/Mean_grad/Maximum_1/y)]]
Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.
     [[Node: GradientDescent/update/_2290 = _Recv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device_incarnation=1, tensor_name="edge_4395_GradientDescent/update", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/device:CPU:0"]()]]

Hint: If you want to see a list of allocated tensors when OOM happens, add report_tensor_allocations_upon_oom to RunOptions for current allocation info.

modify system information : TensorFlow version: 1.6

ResourceExhaustedError means that you should decrease the batch size. But you found that out already. I'll close this issue for now.


Plugin API to tell IntelliJ about grails.artefact.* traits?

Since recent versions of Grails uses traits for most artefacts is there an API to tell IntelliJ that class FooController is actually class FooController implements Controller
You can see if I explicitly set this in CE it shows both this plugin and the trait as well:

If possible this would reduce the amount of code needed to track what magic grails adds to it's artefacts.

Additional check added to Controller completion and reference providers. Since now the plugin is not enhancing Controller classes implementing grails.artefact.Controller trait anymore.

Oh, that's not what I was suggesting (sorry, probably wasn't clear).
I was suggesting that if there was a way for this plugin to just tell IDEA that any class that ends in *Controller actually had the trait Controller then there would be a lot less to code.

Ok, I see. Sounds interesting. Remaining question is where (in which extension point) such enhancement should be implemented.


Update Helm Chart to add more flexibility

When deploying for my use-case I have refactored couple of places in the chart:

OAUTH machinery in explicitly enabled/disabled instead of relying on interlink usage of the socket. It might be IP connectivity without OAUTH but NetworkPolicies or even ServiceMesh instead.
DataRootFolder is not just static path but a volume mount definition instead. This offers a flexibility to define whatever volume your infra is required to get it working: hostPath, nfs, PVC, etc.
Plugin container fixes (main one: mount plugin config instead of interlink config)
More conditionals to avoid mounting unnecessary volumes or defining unnecessary environment if feature is disabled

Hope you can find it useful.
P.S. I didn't bump the chart version in PR.

ok, If I recall it correctly should be the edge case the one you tested.
Let me try the in-cluster and tunneled oene. If everything still works I'll merge the PR

Thanks @dciangot! Sorry I had overlooked all previous github emails in my mailbox. It was actually both in-cluster and edge I was playing with.


⚠ sandbox-api.piste.gouv.fr healthcheck has degraded performance

In f477607, sandbox-api.piste.gouv.fr healthcheck (https://sandbox-api.piste.gouv.fr/cassation/judilibre/v1.0/healthcheck) experienced degraded performance:

HTTP code: 200
Response time: 4736 ms

Resolved: sandbox-api.piste.gouv.fr healthcheck performance has improved in 28e64a8.


Update xxhash to v2

Updates dependency xxhash to version 2.

Thanks for the contribution, sorry for letting it sit without response.
I've merged main and am going to check it in here assuming tests pass:
https://github.com/dolthub/go-mysql-server/pull/2189


Scroll through expanded node is not stable on Safari

Hello,
sometimes (each ~5 touch scroll), when I scroll demo on https://angular2-tree.readme.io/docs from iOS Safari it starts scrolling a whole page (not a tree viewport).
Demo: https://www.dropbox.com/s/wcl95p7zh5di68c/tree.mov?dl=0 (0:18)
Is it a known issue?

Can you reproduce here:
https://plnkr.co/edit/u5fMmaM14rJ0aqG3k240?p=preview

Closing this issue due to inactivity. Please open a new issue if the problem still exists.


4.0 doesn't display action required

Hi @dvingerh
On 3.x version when there is a problem with account, pyinstalive indicates what's going on, like "challenge_required", "login_required", etc.
On 4.0 version it doesn't indicate anything, and acts as if everything is fine even if it's not the case.
If you can fix it, thanks in advance.
Here's how it looks like with the same account:

[I] PYINSTALIVE (SCRIPT V3.2.4 - PYTHON V3.7.5) - 07-13-2022 10:00:00 AM
[I] Successfully logged into account:
[I] Checking following users for any livestreams or replays.
[E] Could not finish checking following users: challenge_required

[I] PYINSTALIVE (SCRIPT V4.0.2 - PYTHON V3.8.10) - 07-13-2022 10:00:00 AM
[I] An existing login session file was found:
[I] Checking the validity of the saved login session.
[I] Successfully logged in using account:
[I] The login session file will expire on:

install version 3.2.4


Remove baseURL

is no longer needed, remove from code + all related functions no longer needed

Removed in 1a0a1d94c0b28e9e61a0cbc983f05d634824bdc5


Character Hierarchy

Establish a basic character hierarchy model.
Character should be the top level object and contain a health attribute with valid values of -1, and between 0 and 1.  -1 indicates the character is invincibile
Player should sublcass Character and will represent the player character
Enemy should sublcass Character and will be the base class for all enemy characters

I'm extending the the Phaser.Sprite as the underlying class for 'Character'. I'm following the suggested way to implement the inheritance instead of forcing other coding style on Phaser.


FinOps Hub version

My finops hub version shows 0.3, but on the website it says updated version is 0.2 and it is mentioned to upgrade. Can you someone clarify pls if there is separate doc and instructions for 0.3.
the new powerbi reports that I dowloaded are not working.

0.3 is the latest. Where do you see 0.2?

@saleemmy Are you still facing issues?

Yes, some of the views are showing blank. The commitments report shows lower savings in May compared to previous months, though I purchased more savings plan and RIs. Not sure what changed in the calculations. Also the RI and SP costs show as blank under subscriptions or resource groups. The RI and SP would be distributed across the applied resources.

@saleemmy Thank you for the update and providing more details on the issues you're experiencing.
From your initial report, it seems like there are two main concerns:

FinOps Hub Version Discrepancy:
Question: Are is the version that you are using? 0.2 or 03? You can check that by going to the Storage Account, then open the config container and check the settings.json file.
PowerBI Report Issues:
There are no changes in the calculation between one month to another. Which tab are showing blank results?

Do you have any Microsoft person (Cloud Solution Architect, for example) already working with you?

@saleemmy, I'm going to close this since we haven't heard back in over a month. If you get a chance to share details, we can open it again. Just want to clean up the list a bit.


Boxless Table#renderCsv

By convention, we sort of assume that things inside the cake are not part of the binary compatibility signature, so I'm versioning this as feature. Let the arguments commence!
This is a complete reimplementation of renderCsv in the style of renderJson, which doesn't suffer from this issue. Apparently the old renderCsv paged the entire dataset into a single String! Woot. Ostensibly, this was done to handle situations where the dataset was heterogeneous divided by slice boundaries (and thus invisibly at the start of the stream). However, as evidenced by the old (incorrect) test assertions, even this situation was improperly handled! Basically, it was broken, and it would cause crashes if we used it on large datasets.
Oh, and it actually paged the dataset into memory twice: once to build a bunch of Array[String] objects, and then once to produce the big String-o-doom. And that's not counting the incremental slice paging. It was bad.
The new one avoids boxing, allocation, and polymorphism in the hot path at the expense of considerable ugliness. It also uses a cute trick to avoid accidental over-specialization on the PIC of a critical path function, which makes things look a bit uglier than they need to. Also I wish we had untagged unions in Scala. I didn't comment things over-aggressively, but I did try to add some explanation when things were particularly bizarre.
The new renderCsv takes a parameter, assumeHomogeneous, which governs whether or not we make an unsafe assumption about the nature of the dataset. If the parameter is true, we'll use the schema of the first slice to dictate the full rendering. This is very likely to be the case in production! However, this assumption is unsound since we could have a dataset which is heterogeneous such that the first slice has an entirely different schema than the second slice. Column headers need to be emitted at the start, as do column separators within rows. In order to deal with this scenario (which probably won't happen in production anyway), we traverse the dataset twice in the false case. We use the first traversal to infer the schema, and then the second traversal to actually emit. This also changes some of the semantics of the data structures and bounds checks within the hot path (changing Array[Column] to Array[Array[Column]], for example).
Anyway, requesting a review from @edmundnoble as well, just to get a second pair of eyes on this incredibly hairy piece of code that I wrote in a rush mid-road-trip.

[ch427]

Oh, pro-tip for the reviewers: the diff is extremely difficult to read in linear form due to the fact that I had to move around large chunks of code and the entire implementation shifted from ColumnarTableModule to Slice. Sorry.
I highly recommend reviewing in side-by-side view, ignoring whitespace.

@alissapajer Yeah I don't really get it. I'm going to try running it locally as soon as I have a computer with which to do so. I tried clearing the PR caches and it didn't help.

@djspiewak FYI I haven't forgotten about this, just planning to have the repl PR up first

@rintcius That's fine, we just can't let this sit for very long due to the extensive changes to Slice. It's going to become conflicted in a hurry. If you don't have time to deal with it now, feel free to assign it to someone else.

@djspiewak I'm not a fan of how we pass around assumeHomogeneous and subsequently check it with an if statement in a handful of places. It makes the code a harder to reason about than if we were to factor out the commonalities between the the cases and then write separate functions.
I understand this was written hastily. But this function will be called after every preparation since csv is the only rendering option we're offering, and so we have to get it right. We do have to carefully choose how we spend our time during the next few days, but I would like to see this code path reorganized.
Though will all that said, which assumption were we planning on using in production? I don't see how we could ever assumeHomogeneous = true in production because if that turns out to be an incorrect assumption, the csv will also be incorrect and likely unreadable by any upstream applications. assumeHomogeneous is a nice feature to have when we absolutely know for sure we are homogeneous, but we won't know that in production (at least not currently), meaning we always have to be pessimistic and set it to false. So should we just omit this flag entirely now to keep the code simpler?

@alissapajer Actually we're almost always going to know that we're homogeneous in production because of the column picker. That's why this flag exists, and why it will generally default to true. Originally, it didn't get passed around everywhere. Instead, it was handled entirely within Table#renderCsv in the construction of the schema. However, it was less efficient to manage the differing codepaths within Slice#renderCsv without the boolean (since it would have required more frequent type tests).
The decision to keep everything in a single function mostly has to do with concision and also having as much overlap between the codepaths as possible. That overlap allows us to lean more heavily on the existing tests, rather than having to exhaustively test each function independently. There might be a way to reorganize this such that we still get good test reuse and minimal repetition without the current type union obfuscation, but I'm not 100% convinced of it. The dependencies between the code paths are more intrinsic than they initially seem.

@djspiewak how does the column picker tell us anything about homogeneity? There still very well might be holes in the data. Does the column picker force the user to fill in those holes with some value (default or derived)?

@alissapajer I believe holes are fine in assumeHomogeneous, it's just that type unions are not.

To clarify, if both the String and Boolean types are selected from a projection, it gets put into the table builder as two separate columns. There's no way to build a heterogeneous column in the output table.

@djspiewak so if a user selected both the String and the Boolean values from projection foo.bar.baz, then they would be required in the column picker to create two distinct columns (each with its own name of course).

I hadn't appreciated that subtlety about the column picker before. It's actually (among other things) a tool that separates out type unions (i.e. turns heterogeneous columns into homogeneous columns).

I'm trying to absorb all of this right now, it seems at least somewhat straightforward but could really use more comments describing the procedure, especially around the more meaty parts (Slice.scala).

@djspiewak let's say we have called this function assuming homogenous data, and that assumption is correct. But the data in one column foo.bar is extremely sparse, and in the first slice there aren't any values in foo.bar. But there are values in subsequent slices. Then won't we assume that the foo.bar column doesn't exist and end up with incorrect CSV?
Could we solve this by allowing more columns to be added as we see subsequent slices? We'd have to hold some state as we did this. But it wouldn't be nearly as complex as the state required to merge columns in the heterogeneous case.

But the data in one column foo.bar is extremely sparse, and in the first slice there aren't any values in foo.bar.

Then we're in very serious trouble. There's no way to handle this in general aside from assumeHomogeneous = false, which does a full table scan before emitting (which in turn is a second table scan).

Could we solve this by allowing more columns to be added as we see subsequent slices?

How? We have to emit the columns first, and then every single row is aligned to that column header. We would have go back and change everything already emitted in order to add columns after the fact. This is why CSV is hard.

BTW the AppVeyor build failure is spurious and caused by cache issues that will resolve themselves once this is in master.

@djspiewak if we hit the very sparse column case, is this function going to crash? Or are we silently going to omit incorrect CSV?

@djspiewak then we should think of this as a placeholder that will get us through some alpha testing but won't hold up in the long run. If we don't implement the functionality that gets the schema during preparation soon, we can ask for the SST here. We can't afford to give our customers incorrect CSV; that seems like it would make the product untrustworthy, imo.

@alissapajer The placeholder is to use assumeHomogeneous = true. Which is like… horrible. There's not really anything we can do otherwise though. The thing though is that we pervasively have this danger in the product. If the dataset has horrible things hidden late, we're just going to miss them in most of our functionality.


Bottom of text gets cut off in block-list form inputs on Firefox

Here's a screenshot from the [docs block list page] (http://foundation.zurb.com/apps/docs/#!/block-list), using Firefox 36.0.1:

I'm amazed how complicated the math for this turned out to be.


Fixed the typo and updated the header and footer of about.html

Fixed the erros and updated about.html

Good Work @sourabhrupani  :blush:


Use sign(genWeight) instead of genWeight for MC scaling

In current version of the Pocket, the MC scaling is done with genWeight variable. This is actually not recommended. Instead, one should use the sign(genWeight) and then sum(sign(genWeight)) for the sum.
This is mainly because there was a bug/feature of Run2 UL production when for some samples there are huge genWeights (which are incorrect). More details are in this post on cms talk.
On the other hand some samples may require the actual value of the genWeight to be used, so  the framework should support both options.
Actually, I have implemented a solution. PR is coming shortly.

Completed by #125


[FLINK-28409][tests] Move FlinkContainerTestEnvironment and dependendencies into flink-connector-test-utils

FlinkContainerTestEnvironment needs to become available via Maven central to the externalized connector repositories. This PR moves it into flink-connector-test-utils module, which is already being published.
This is a trivial change that is covered by the existing tests.

@zentol thanks for the review.


Dump radosgw_keystone_config into [client.rgw.*] section

To configure radosgw it is necessary to provide some config options
related to the keystone deployment.
This change adds support for dumping into ceph.conf, in the
[client.rgw.*] section, arbitrary key=value settings using the
radosgw_keystone_config variable.

@guits @leseb @fultonj I like that this is a simple abstract structure which can be used to paste per-instance data and does not conflict with _overrides which remains functional for those who prefer it

@gfidente what's the status of this?


Resolve special paths of frontend before redirecting

Fixes https://github.com/serlo/serlo.org-cloudflare-worker/issues/73

Look how little changes in the test suite are now necessary :tada:


MapView is empty in first time, possible storage logic problem?

Issue Type
[x] Question
[ ] Bug
[ ] Improvement
[ ] Build system related
[ ] Performance
[ ] Documentation
I tryed to upgrade my app to use latest Osmdroid but now there is problem.
MapView is empty when app is stated first time.. MAPNIK is used
Step to produce
1: Starting my app
2: Allow permission to write external memory (Manifest.permission.WRITE_EXTERNAL_STORAGE)
3: Map is initalized and view is empty in debug log there is error mesage about file permission
06-28 01:28:34.573: D/OsmDroid(28661): Unable to store cached tile from Mapnik /14/9354/4273, database not available.
4: Exit from app
5: Start app again and map view is works normaly
Result: Map view seems to be empty in first start and works when start app again
Expected resutl: Map view works normaly in first start after file permissions are allowed.
Seems that latest OsmDroid not choose correct storage for write tile caches?
Followed lines are also set in my app but does not seems any effect
Configuration.getInstance().setOsmdroidBasePath(new File(Environment.getExternalStorageDirectory(), "osmdroid"));
Configuration.getInstance().setOsmdroidTileCache(new File(Environment.getExternalStorageDirectory(), "osmdroid/tiles"));
Configuration.getInstance().setUserAgentValue(Defines.userAgent);
Environment
If it's a bug, version(s) of android this affects:
Android 7.0, 8.0
Version of osmdroid the issue relates to:
5.4.1 - > 6.0.1

Is your sample code ran before the map view is created?
On Wed, Jun 27, 2018, 6:32 PM Sami Taipaleenmäki<EMAIL_ADDRESS>wrote:

Issue Type
[x] Question
[ ] Bug
[ ] Improvement
[ ] Build system related
[ ] Performance
[ ] Documentation
I tryed to upgrade my app to use latest Osmdroid but now there is problem.
MapView is empty when app is stated first time.. MAPNIK is used
Step to produce
1: Starting my app
2: Allow permission to write external memory
(Manifest.permission.WRITE_EXTERNAL_STORAGE)
3: Map is initalized and view is empty in debug log there is error mesage
about file permission
06-28 01:28:34.573: D/OsmDroid(28661): Unable to store cached tile from
Mapnik /14/9354/4273, database not available.
4: Exit from app
5: Start app again and map view is works normaly
Result: Map view seems to be empty in first start and works when start app
again
Expected resutl: Map view works normaly in first start after file
permissions are allowed.
Seems that latest OsmDroid not choose correct storage for write tile
caches?
Followed lines are also set in my app but does not seems any effect
Configuration.getInstance().setOsmdroidBasePath(new
File(Environment.getExternalStorageDirectory(), "osmdroid"));
Configuration.getInstance().setOsmdroidTileCache(new
File(Environment.getExternalStorageDirectory(), "osmdroid/tiles"));
Configuration.getInstance().setUserAgentValue(Defines.userAgent);
Environment If it's a bug, version(s) of android this affects:
Android 7.0, 8.0
Version of osmdroid the issue relates to:
5.6 - > 6.0.1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/osmdroid/osmdroid/issues/1070, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4kGRNrWvYdbTdw5kii9btlancxljIWks5uBAfugaJpZM4U6e8z
.

Osmdroid 5.1 seems last version where tile cache and permmisions work like I expteted. I donk know why above that version fails and map view opens empty after permission query. Are those some home related that part of osmbonus back is moved to osmdroid? seeems there is huge changes...

can you capture some logs? i'm pretty sure the issue is that the new versions cannot locate a writable location to store map tiles. Look for logs related to storageutils


bash_profile vs bashrc

Forgive me if this has been raised and decided, but the issue searchbox did not reveal such...
I'm wondering why this toolkit focuses on wedging into .bash_profile when .bashrc seems to be generally accepted as the starting point for interactive bash sessions?
I follow what I'd gathered to be a generally accepted practice of a trivial bash_profile which exists primarily to invoke .bashrc, whose only other entries are to configure items I'd use from cron or some remote execution tool.
(in fact I carry this a bit further, having a separate .bashrc.interactive or .bashrc.local for the truly local interactive stuff).
I'm busily hacking on my own local branch to refactor for the above, but want to step back and think about how I can give back.
(background:  I spend hours logged in as the daemon user for a particular application for administration.  I'm hoping this toolkit can help me standardize those admin environments but my prime directive is "First, do no harm" to the app's auto-customized shell environment.   I'm leaning toward an installation that requires manual sourcing for that particular environment, but elsewhere, a cleaner merge into existing startup files.)

I'm planning to modify the installer to detect the OS and choose the file to write the config:
Mac OS X  → .bash_profile
Other *nix → .bashrc
Any objections?

:+1:

Great idea! :+1:

Also Debian+derivs (Ubuntu, Mint) prefer .bash_profile, I think.

I use Debian, at home and at work, Unstable and Testing, and in both cases, the scenario is the explained in my previous comment #173 (comment).
You can check it viewing the files:
/etc/skel/.bashrc
/etc/skel/.profile

the default config files copied to the home of new created users. If .bash_profile exists .profile is ignored.
The original idea comes from @tswicegood in this comment https://github.com/revans/bash-it/issues/173#issuecomment-13499754 :sweat_smile:


dead link

[sample YAML for common SMTP inputs] was pointing to old support site

After looking at this further I think all of those sentences can just be removed. It looks like they were sending visitors to a separate section of the docs to see the example, but now we have the example embedded below.

@replicatedbart please update the pr per steves suggestion and remove those sections. thanks

removed links, please review

lgtm


toTag default use ``

types.Struct tag default use `` to ast.Struct

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (30b9777) 94.47% compared to head (572b64e) 94.47%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #251   +/-   ##
=======================================
  Coverage   94.47%   94.47%
=======================================
  Files          14       14
  Lines        6330     6338    +8
=======================================
+ Hits         5980     5988    +8
  Misses        282      282
  Partials       68       68

Impacted Files
Coverage Δ

ast.go
96.15% <100.00%> (+0.03%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Hip increase poc wifi

I believe HIP 101 had the right idea on increasing the WIFI radios rewards, it just needed to be more balanced in terms of rewards compared to the CBRS radios. I hope this new hip is what everyone wanted.

This is a copy of HIP 101, with the same original author and HIP content it appears.
And is thus invalid. A new HIP is requested. Please follow the HIP process correctly.
https://github.com/helium/HIP/blob/main/0007-managing-hip-process.md

Closing as stale


Data Table Support in GraphWidgetType

Feature scope
Custom
Describe your suggested feature
It looks like the data table type is missing from GraphWidgetType. I'm not sure if the data table is a recent widget that CW added or if there hasn't been a use case for it.
https://github.com/cdklabs/cdk-monitoring-constructs/blob/598dea1bd09df69d7d8dbc070ae9728f8629bd67/lib/common/widget/types.ts#L9-L15
It doesn't seem to be too hard to add. I can probably do a PR. I just wanted to confirm the scope first.

TableWidget was added in cdk-lib 5 months ago, so it's relatively recent.
https://github.com/aws/aws-cdk/commit/4599aa3c4502e5e5e5fb7434913f7ce9a6468547

That's fair. I don't have a strong need for it; I was just playing around with different widgets.


Matt's revised update to push and tag image to Docker Hub

I think I made all of the changes you requested. Please let me know what you think, and if it works on your end!

Run failed, reason - https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow. I'll merge and test the build with source repo.


Create umap figure with ggplot

WIP dependent on merging #28 so I can add DP features here

Ready for review after merging #28