text:
entity_ref get_component_with_type is slow

What problem does this solve or what need does it fill?
I'm trying to get components data from EntityIds(Vec<Entity>) with world.get(entity).... I'm experience some "unexpected" performance drop (in compare to Vec<Rc>).
Looking at the code of World::get<T: Component>(&self, entity: Entity) ... there is so much indirection... Getting component index from hashmap,  then bursting through 3 indirections to get component "Column", and one branch between storage type.
What solution would you like?
Is it possible to somehow .... prefetch/cache that archetype table_row/column?
That's just too much... Thats waaaay slower then just cache misses with Rc.
Additional context
I use Vec<Entity> not that often... But sometimes you just have to use it ....

AFAIK, Query s do this sort of caching :)

@TheRawMeatball Nice! Now if only there where "queriable" collection of entities....

@TheRawMeatball Or you meant world.query(...).get(entity) ?

The second, but not quite like that - you need to construct the query with the components you're interested in first, and store it alongside the list. It'll do some of those indirections at build time, and then you can use get to go fast :)

So... From system query it should already work?
// For example
fn my_system(
    datas: Query<(&Data)>
)
{
    for entity in entites{                  // entities = Vec<Entity>
        let data = datas.get(enity);
    }
}

Looking up an Entity's component vs looking up a value in a Vec will never be "identical" because we will always need indirection to determine (1) whether or not the entity has that component and (2) where that component exists. Vec lookup is the "upper limit" that ECS impls strive for (but will never reach ... its a logical guarantee).
That being said it should still be "approximately" the same cost as Vec lookups if you cache things like TypeId -> dens_component_index lookups, which we already do for Queries. And iteration will be very close to Vec iteration because these lookup costs only need to happen once instead of per-entity.

So... From system query it should already work?

Yup QueryState, which is used by System Queries and returned by world.query(...) , already caches everything that it (reasonably) can.

But.... Looks like get_unchecked_manual called by query.get() reconstructs Fetch and Filter State on each call (I'm not sure which exact implementation is called, but looks like there is some branches in Fetch::init).
Clearly, there is no such overhead for iteration...
P.S. Is component pointers stable for alive entities?

We don't reconstruct Fetch and Filter State in get_unchecked_manual. We pass the cached state into Fetch and Filter instances. Fetch:init does do the work of looking up pointers to storages, but this cannot be assumed to be stable. Any time a new component or entity is added, that could trigger a reallocation of the array, which would invalidate the pointer. Caching that pointer would be very unsafe.

For a given world borrow and set of entity lookups using that borrow, we can assume it is stable because nothing can add/remove entities or components during that time. But we can't store that in QueryState, which exists outside of a given World borrow.
We might be able to cache the Fetch and Filter instances inside of System Queries though (because components cannot be added / removed in a way that invalidates these pointers when the system is running). I can't assert that is valid off the top of my head though.

I see, thanks.
I think I need to benchmark this more thoroughly... At first glance looks like accessing resource is way faster then accessing component.
Will return with results.

At first glance looks like accessing resource is way faster then accessing component.

This makes sense because we can skip the "entity location lookup" and move right to the "component storage lookup". However in practice they should still be pretty similar. Keep in mind that we're talking about very small / inexpensive operations here. Things like "an extra array lookup" will register on benchmarks, even though that is an extremely cheap operation in the grand scheme of things.

Definitely let us know if you find any optimization potential! We're already very competitive on ECS benchmarks, but faster is better!

Reporting in.
In-system Query::get 5-6 times slower then Arc.
https://github.com/tower120/bevy/commit/33a73fa51abf7ea44439eb8f99893b8630d967a3
entity                  time:   [136.58 us 137.07 us 137.57 us]
                        change: [-4.5581% -3.5928% -2.7019%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  2 (2.00%) high mild
  3 (3.00%) high severe

box unique              time:   [20.592 us 20.669 us 20.752 us]
                        change: [+1.2907% +1.7769% +2.3090%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 6 outliers among 100 measurements (6.00%)
  6 (6.00%) high mild

arc mutex               time:   [166.39 us 166.87 us 167.42 us]
                        change: [+0.1934% +0.6981% +1.2190%] (p = 0.01 < 0.05)
                        Change within noise threshold.
Found 8 outliers among 100 measurements (8.00%)
  3 (3.00%) high mild
  5 (5.00%) high severe

arc unsafe              time:   [25.175 us 25.265 us 25.365 us]
                        change: [-1.1272% -0.5776% -0.0209%] (p = 0.04 < 0.05)
                        Change within noise threshold.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

If you want, I can make PR with that benchmark.

Query::get performance also has a big impact on bevy_rapier performance, because it stores the rigid bodies, colliders and other related data directly in bevy ecs and does a lot of random access with Query::get when processing physics

According to one of the rapier contributors on their discord, bevy_rapier is about twice as slow as rapier with built-in data structures.

I also benchmarked query.for_each vs vec.for_each.
https://github.com/tower120/bevy/commit/4d97e6fba47d9238e418ae087c8c2c1ab1963e9c
It appears that Vec traverse 3-4 times faster then query...
entity iter             time:   [190.90 us 191.37 us 191.85 us]
                        change: [-2.9586% -2.6283% -2.2918%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

vec iter                time:   [59.864 us 59.994 us 60.179 us]
                        change: [-2.4671% -1.8886% -1.3690%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 9 outliers among 100 measurements (9.00%)
  1 (1.00%) low severe
  1 (1.00%) low mild
  1 (1.00%) high mild
  6 (6.00%) high severe

So it may make sense to pack few lightweight systems into one more heavy-weight... Frankly I did not expect that difference...

There is branch inside archetype_fetch - match self.storage_type. It is inside each iteration... Maybe if change api somehow to have separate loops for each storage_type - so less work left to do inside tight loop...

I also benchmarked query.for_each vs vec.for_each.

Your query iteration benchmark uses a parallel SystemStage for running the query. I suspect a lot of the time is spent on the scheduling and caching done by that, rather than the iteration itself.

@FeldrinH Thanks! I'll try change it now.

@FeldrinH Changed to SystemStage::single_threaded() difference is marginal, if any.

Just took a look. Lets start with:
entity_iter
First: there is a methodology issue. This is an apples-to-oranges comparison because you're running the entire scheduling infrastructure for the Query benchmark and comparing that to a single raw vec iterator. The scheduling infrastructure is cheap to run, but it will still register in a small way for benchmarks like this.
Additionally, even after accounting for that, this is still apples to oranges because the Vec benchmark doesn't do change detection. Functionally, change detection performs the same as iterating and writing to another component (because it needs to fetch the tracking state and write to it when Mut<Point> is mutated).
After disabling change detection (currently a manual process of commenting out the relevant code, but will ultimately be configurable per-component once we switch to #[derive(Component)]) I get:

Then, after removing the Schedule/Stage/System in favor of iterating a raw Query, I get:

After righting the scales, we are actually faster than iterating a raw Vec (by an extremely small margin). Despite the fact that we provide way more functionality than a simple Vec, we still come out on top because the extra work required to accomplish that functionality amortizes to zero.
The test:
fn entity_iter_raw_query_bench(criterion: &mut Criterion) {
    // Setup world
    let mut world = World::default();
    let mut query = world.query::<&mut Point>();

    // // Setup test entities
    for i in 0..ENTITIES_COUNT {
        world.spawn().insert(Point {
            x: i as u32,
            y: i as u32,
        });
    }

    // Run systems
    criterion.bench_function("entity iter", |b| {
        b.iter(|| {
            query.for_each_mut(&mut world, |mut point| {
                point.x += 1;
                point.y += 1;
            })
        })
    });
}

Additionally it seems like there is a general misunderstanding about how relevant numbers like 2x are in this context. Thanks to the cache friendly nature of both implementations, we are talking about extremely small timescales here. The second you start doing anything meaningful inside these iterators, that work will dwarf the iteration costs. We get a ~30% increase in cost, just by throwing in some more ops:
    criterion.bench_function("entity iter", |b| {
        b.iter(|| {
            query.for_each_mut(&mut world, |mut point| {
                point.x += (10 - point.y).pow(4);
                point.y += 1;
            })
        })
    });

Doing any amount of work on these scales registers in a big way.
From the perspective of a game engine, the benefits of change detection far outweigh the 2x cost (by enabling us to optimize / skip expensive operations each frame and opening up extremely useful coding patterns). The cost won't meaningfully register for anything but the most resource constrained benchmarks and in the very near future you will be able to easily opt out for those scenarios.
Lets segue into the next benchmark:
entity_get
After accounting for change detection, here are the results:

box_unique is ~4.4x faster than entity. First, even if this was an apples to apples comparison, these numbers would be acceptable because as we've previously covered, we're working on very small timescales here. We are also quite competitive when compared to other ECS implementations. So why isn't box_unique a fair comparison to ECS get(Entity) operations?
Lets compare the inner loops of the two benchmarks:

box: iterate an array of boxes and deref each box

for each item (a box), to find the component we need to do the following:

deref a pointer

entity: iterate an array of entities and look up each entity in the

for each item (an entity), we need to:

map it to a location in an archetype (this is an array lookup, which is a pointer offset then a pointer deref)
validate that the location is a valid entity (comparison and a branch)
get the pointer to the storage for a specific component in the archetype (a sparse set lookup, which amounts to two array lookups, which equals two pointer offsets and two pointer derefs)
get the component from the storage pointer (which amounts to a pointer offset and a pointer deref)

This amounts to the totals:

box: 1 pointer deref
entity: 4 pointer derefs and 4 pointer offsets

And that doesn't even account for the extra branching to ensure Entity and sparse set lookups are valid. In total, the 4.4x number makes perfect sense!
If you don't think too hard about it, it sure seems like we're doing a lot of unnecessary work. We should just use Boxes! What were we thinking?
Lets do some small (zero cost) refactors so we can start building our Box ECS:

Box indices are now Entity(usize)
PointBoxes is now Components<T> { components: [Box<T>; BOXES_COUNT] }  (in practice this would actually be a Vec<T> for faster iteration)

Now lets pretend we want Entity(0) to have component [A, B] and Entity(1) to have [B]. How will we will we record this?
Here is the simplest path forward:
Use an option (or null pointer) to indicate that a specific item in the array exists. (ex: Vec<Option<T>> or [MaybeUninit<Box<T>>; BOXES_COUNT]). This is known as a "Sparse Array". But now we've created a couple of problems relative to PointBoxes:

All Component<T> arrays must be sized to accommodate the entire entity space. They are no longer "densely packed". If Component A has 10 entities and Component B has 2 entities, both arrays need to be length 10.

This memory usage problem can be fixed by storing only valid components in a dense Vec<T>, then having another Vec<Option<usize>> array to determine whether or not the entity has component T and where it is located in the dense Vec. This is called a "Sparse Set" and is a popular ECS variant.

When looking up an entity's component, we now need to branch to determine whether or not the entity has that component.
When iterating multiple "sparse arrays", we no longer have linear component iterations (we need to "either hop around" the arrays using sparse sets or do the extremely expensive operation of checking each component index individually for each component)

Ex: The specs ECS "vec storage" is basically a sparse array. I had benchmarks handy that compare its entity lookups to Bevy's

Funnily enough, specs is about 4x faster than bevy_system, which makes since given what we just talked about / the performance of your box benchmark!
However sparse sets have significant downsides:

If you want to do multiple component lookups for an entity, you need to branch for each component type.
Iterating sparse sets (especially when iterating the entities from multiple components at the same time) is expensive. Way more branching and hopping around in a cache unfriendly-way. This is slow (when compared to linear dense vec iterators).

The solution to this is "archetypal ecs".
Entities belong to a specific archetype, with per-archetype storages that are densely packed and perfectly aligned.
This adds the indirection of finding the archetype, but it means:

You only need to find the archetype once. After that, you already have the component storage locations and you don't need any more branching to check if the storages contain the components. This means that the more components you add to query.get(entity), the faster it gets relative to sparse sets.
Iterating can be a cache friendly linear scan. No need to hop around sparse sets!

Archetypal and Sparse Set ECS are the two most popular ECS implementations. They are a result of the best minds in the business putting their heads together and making informed compromises. They each have their tradeoffs, but they provide functionality that a simple Vec<T> cannot. It is literally a limitation in the laws of physics. You cannot have the flexibility of ECS without more branching and indirection. If you want the performance of an array, you are stuck with the rigidity of an array. If you think you can do better ... awesome! Just be aware that this is an extremely competitive space and that we are extremely competitive in this space (https://github.com/rust-gamedev/ecs_bench_suite). Don't expect to find anything but small / marginal wins (or wins that come at the cost of other benchmarks / features).

Just took a look. Lets start with:.....

@cart is this write up in a dev blog somewhere? I learned so much just reading it.

@cart is this write up in a dev blog somewhere? I learned so much just reading it.

Not currently. I might ultimately consolidate this and other things like the Bevy ECS V2 description (which is basically a blog post by itself). But that takes time and I've got renderer code to write right now :smile:

Thank you for explanation.
Previously, I worked with one custom ECS... As far as I remember, it had almost same performance as vec for components iteration; and 1.5-2.5 (depending on memory fragmentation, I guess) slower on component get by entity vs unique_ptr access.
Surely it was not that feature-reach as bevy-ecs. I describe it just in-case, that could help enhance bevy-ecs.
I don't understand every bit of bevy-ecs architecture, so I can't say where exactly difference. So I better tell how that ECS worked. Lets call it CUSTOM_ECS.
But looks like main difference in how entity-thing treated...
CUSTOM_ECS is archetype based ecs; systems run in manually defined sequence one-by-one. We used multithreading only as paralell-foreach inside system.
All emplaces/erases scheduled and executed at the end of the system. (actually, maybe emplace postponing was unnecessary...)
            Archetype A+B+C

                Entity 0    Entity 1    ...     Entity N
Component A                                                 <- std::vector<A> technically implemented as std::vector<uchar>

Component B

Component C

Entity       Rc<EntityImpl>

Emplace
As simple as vector.push_back
Erase
Components column from back moved in place of erased one. All components pop_back(). Moved-in EntityImpl updated. Erased EntityImpl zeroed(marked as null).
struct World{
    std::vector<Archetype> archetypes;
    std::vector<ComponentData> components;
}

struct EntityImpl{
    uint archetype_id;
    uint entity_index;
}

Entity
Entity is shared_ptr<EntityImpl> (Well, actually in-house implementation without weak references "overhead"). Since enity's components can be moved in memory only between systems run, it is safe to update EntityImpl whenever entity moved due to erase or archetype change.
Traverse through required set of components (only have/don't have was supported).
Found archetypes that satisfy condition, and run through required component vectors.
Basically:
for (auto& archetype : archetypes)
for (auto& component : archetype.components()[component_id])    // but for several components at once
    closure(component)

Get component by entity.
Now interesting part.
Each component have associated table - archetype_id to components row pointer. It updated whenever archetypes changes. (We actually never delete empty archetypes automatically)
// instead of std::vector everything worked with plain array T* . vector here for clarity.

using Components = std::vector<uchar>;
struct ComponentData{
    // Even if table go big - It'll be still small enough to fit L1 cache. Table have high chances to remain in cache if we getting entity often (like in loop).
    vector<Components*> components_pointers;    // index = archetype_id. I think 4000 archetypes is a reasonable max.
}

using Entity = shared_ptr<EntityImpl>;
Component& get_component(ComponentData& component_data, const Entity& entity_){
    const EntityImpl& entity = *entity_;
    auto&/*vector<Component>*/ components_row = component_data.components_pointers[entity.archetype_id]; // table fetch + reinterpret_cast (now showed here).
    return components_row[entity.entity_index];     // as you can see "only" 3 indirections
}

ComponentData& components_A = world.GetComponentData<ComponentA>();      // this do hash-map lookup to associate Component "type_id" with world's ComponentData
for const Entity& entity ....{
    components_A.get_component(entity)
}

It is "unsafe" version - meaning you know entity's components exists.

I see! Thanks for sharing. That looks pretty similar to how our archetypal storage works (and the general call pattern).  But there are some cool ideas here that we aren't currently using! The main differences:

Rather than looking up Archetype->Table->Column (we currently use a sparse set with the component id to find the column), it looks up the archetype table row inside the "component metadata". This skips an indirection. We've discussed doing this at various points in the past, but haven't gotten around to it yet. It gets a little bit more complicated for us because multiple archetypes can point to the same table, which means theres a little bit more "fixup" work required when resizing table columns (but thats doable). This is definitely something worth thinking more about + benchmarking. I know @BoxyUwU's ECS did something like this (but maybe bitsets in the component metadata?) and I think @SanderMertens does something like this in flecs? It also would help cut down on sparse set usage, which per-archetype can get pretty memory hungry when it isn't paged.
The archetype location is 'cached' inside of the Entity(Rc<EntityImpl>) and there appears to be no "entity id value' decoupled from Archetype/Location. This enables skipping the "pointer offset" when looking up entity locations, but it is still a random pointer access to find the location (and therefore indirection). Of course, an entity cannot actually be identified by those two values (because the can change across updates), so I'm assuming the "pointer value" is treated as the "entity value decoupled from archetype location". I have some questions / comments:

How does world.despawn(entity) work in relationship to Entity(Rc<EntityImpl>>)? In rust, the location wouldn't be freed up until the final Rc is dropped. How does your implementation ensure that an Entity stored in a list floating around somewhere isn't pointing to a previously "despawned" entity? Is it a weak pointer that needs to be "upgraded" to a strong pointer?
If "entity ids decoupled from archetypes" are "pointer values", then spawning new entities would involve a bunch of small individual allocations of Entity(Rc<EntityImpl>) or synchronized access to some Vec<EntityImpl>. If done in parallel, we need some synchronized storage of these pointers to ensure that we update locations in the event that they change.

Whenever you'll do that - my advice - use pointer to row start, not just row's index.
Entity points to column in table. It consists from archetype index + column index (of address offset, if you like). Archetype is table for us.

... and there appears to be no "entity id value' decoupled from Archetype/Location.
What do you mean?

Of course, an entity cannot actually be identified by those two values (because the can change across updates)
That two values changes too during update - that's the whole idea for keeping them in heap.

How does world.despawn(entity) work in relationship to Entity(Rc>)? In rust, the location wouldn't be freed up until the final Rc is dropped. How does your implementation ensure that an Entity stored in a list floating around somewhere isn't pointing to a previously "despawned" entity? Is it a weak pointer that needs to be "upgraded" to a strong pointer?

As soon as entity will be despawned, value of EntityImpl zeroed. So one can check if it is still valid, since in list stored shared_ptr (pointer to heap), not actual value. There were no weak pointers. Technically Entity stay alive until there is at least one value of it... The very data in heap changed (with zeros, or with new location if entity moved across archetype tables).
// between system runs!
void despawn(shared_ptr<EntityImpl> entity){
    // do actual components erase from storage
    entity->archetype_id = 0;
    entity->entity_index  = 0;
}
bool is_null(shared_ptr<EntityImpl> entity){
   return  entity->archetype_id == 0;
}

IOW, we does not prolong components lifetime with Rc. We prolong Entity lifetime in heap with Rc.

If "entity ids decoupled from archetypes" are "pointer values", then spawning new entities would involve a bunch of small individual allocations of Entity(Rc) or synchronized access to some Vec. If done in parallel, we need some synchronized storage of these pointers to ensure that we update locations in the event that they change.

I don't understand what you mean saying "pointer values", if that means form of smart-pointer pass-by-value, like shared_ptr, then yes.
Allocations was surprisingly fast... And when allocated one-by-one dense in memory too...
All structural changes to archetype table was done outside system run. They were scheduled, then executed. (I don't know how bevy_ecs Commands exactly work, but looks similar to that). Systems run sequentially (not in parallel as in bevy). So parallelism is not a thing for table alteration.

The initial reason for keeping entity_location data in heap, was to get rid of  entity_id -> actual_entity_location table. It looked like there is no benefits for having LUT complexity, and that is essentially the same as heap allocated entity_location data.

I think I can make smaller version of that ECS, if that helps...
It was derivative from https://github.com/tower120/ecs_mt . But that version is outdated. And does not actually use Rc.
EntityImpl/entity_data just stored in non-movable memory area. So instead of Rc, pointer is used in entity:
https://github.com/tower120/ecs_mt/blob/master/include/tower120/ecs/entity.hpp
So, in that version, there is no way to tell if that entity alive or no.

This discussion has been educational and useful, but I'm going to close this out as it's not particularly actionable. If there's specific take-aways or action items, new issues are very welcome.

authors: FeldrinH TheRawMeatball alice-i-cecile cart mirkoRainer tower120


text:
Mesh LOD Support

What problem does this solve or what need does it fill?
To reduce the amount of geometry that needs to be rendered in any given frame, it's common to have multiple scaled versions of a mesh that are used at certain distances from the camera.
What solution would you like?
A MeshLevelOfDetail component or something similar that will contains multiple Handle<Mesh>s that are either replace the handle in the component slot or changes how the mesh extraction system works depending on how close to a camera it is.
What alternative(s) have you considered?
Manually doing this.
Additional context
GLTF has no support for LODs at the current moment. Some ideas on how to best support this on the asset loading side might be needed.

I think it would be wise to look at Unreal's Nanite LOD system for inspiration.

I think it would be wise to look at Unreal's Nanite LOD system for inspiration.

I would throw-in following deep dive into the Nanite as reference for people planing to explore the topic.
Nanite deepdive article

Shouldn't this be closed as HLODs have already been merged?

Seems like this should be kept open for now since the HLOD pr (#12916) states the following:

This feature differs from proper mesh LODs, which can be implemented later.

source: gharchive/issue

authors: Affinator EmiOnGit bonsairobo james7132 jobpaardekooper

repo: bevyengine/bevy

license_type: permissive

license_source: github-api


text:
Add convenience function to set every dimension's address mode

This adds a fn set_address_mode(&mut self, address_mode: AddressMode) on SamplerDescriptor to set address_mode_u, address_mode_v, and address_mode_w to the same AddressMode. This is just a convenience function to avoid having to copy and paste three setters every time.

Looks good to me. Thanks!

Looks good to me. Thanks!

source: gharchive/pull-request

authors: Restioson cart


text:
More detailed errors when resource not found

Quick fix for #1846
Got scared of the other "Requested resource does not exist" error at line 395 in system_param.rs, under impl<'a, T: Component> SystemParamFetch<'a> for ResMutState<T> {. Someone with better knowledge of the code might be able to go in and improve that one.

Got scared of the other "Requested resource does not exist" error at line 395

I believe you can make the panic! message be the same as the other one you implemented. (e.g, utilizing system_state.name)

bors r+

@therealstork please respond in #2373 for the relicense to MIT/Apache 2.0. Thanks!

authors: DJMcNab NathanSWard cart therealstork


text:
Text pipeline benchmark

Objective
Simple text pipeline benchmark. It's quite expensive but current examples don't capture the performance of queue_text as it only runs on changes to the text.

Doesn't work, text isn't recomputed on changes to Text2dBounds.
Just working on the fix.

Definitely pretty artificial, but it's nice to be able to isolate these things.

It's weird I was worried I was being silly PRing this as it is really trivial, but it actually seems to cover some important edge cases that were hiding bugs.


text:
add web pages

Adding web pages for ultimatjob site as requested on the issues we opened.
This is how you navigate in the html pages:

ultimate job- home page
ultimate job- sign up
personal area (here the user will be able to search for his jobs)
available jobs (here the jobs that fit the user will appear)

also, there is a sign in page for users who already have an account- after that page they will be navigated to page 3.
This PR will solve the issues above:
#41 #42 #43 #44 #45

I think you upload also beyond tutorial files

I think you upload also beyond tutorial files

yes by mistake, i deleted them from the PR now, thanks

Nice work Erez

authors: BarBenNaim Yarboa erezdav22

repo: beyond-io/ultimatejob

license: MIT


text:
mapper4 There seems to be a problem

I tried to run some roms that support mapper4 mmc3, but some roms are gray screen. I found a similar project on github, but I don't know how to improve jsnes with it.
rom parameter:MMC3 rom: 16 PRG bank(s), 32 CHR bank(s)
project address:NesJS mmc3 Mapper

是有这个问题，我在弄"加纳战机"的时候，没有声音没有图像。
谷歌翻译：
There is this problem. When I was working on the "Ghana fighter", there was no sound and no picture.

@ZhaoTonggang 兄弟，我看你实现了几个mapper，我对这块不太熟悉，你能帮忙看看mapper 115 吗，我发现115和4很像，我尝试用4来代替，可以出现声音，但声音有点慢。
谷歌翻译:
Brother, I see that you have implemented several mappers, I am not familiar with this piece, can you help me to see mapper 115, I found that 115 is very similar to 4, I tried to use 4 instead, the sound can appear, but the sound is a little bit slow.
/**
* Mapper 115
*
* @description http://wiki.nesdev.com/w/index.php/INES_Mapper_115
* @example
* @constructor
*/
Mappers[115] = function(nes) {
			this.nes = nes;
	};

Mappers[115].prototype = new Mappers[4]();

A few years later, but I found a possible fix for the mapper 4. Here is the PR https://github.com/bfirsh/jsnes/pull/452

I have a similar problem I can't find anything that runs downloaded roms on Chromebook except emulator js wich can't run everything.

authors: ItsLixy ZhaoTonggang allowing lrusso

repo: bfirsh/jsnes

license_source: bigquery


text:
filter by multiple collectors

Current API only support filter messages from a single collector. We should include support for multiple collectors .

This is already supported. collector_id supports taking comma-separated strings for multiple collectors.
updated the documentation and examples here: https://github.com/bgpkit/bgpkit-broker/commit/17ef388c6ab314d7f96efd37a3e5855e07e6f12a

repo: bgpkit/bgpkit-broker


text:
Only match first name in package.json

This ensures that the following package.json extract would just give the
prompt "foo" rather than "foo\nbar".
{
  "name": "foo",
  "author":
  {
      "name": "bar",
  }
}

Fix of PR #273

Great call, @andjscott!

authors: andjscott bhilburn


text:
Watchlist broken

need to clean up async code

fixed very long time ago

repo: bicepguy/PyAlphaVantage

license: mit


text:
Choose names to replace Activity/Entity/Agent in the BIDS-Prov skeleton

(This issue is opened following progress made on the specification at the OHBM Brainhack.)
Problem Statement
In the BIDS-Prov skeleton, we are currently referring directly to PROV terms (Activity/Entity/Agent).
Those should be replaced by subtypes that will be specific to BIDS-Prov (but generic enough to encompass any type of object).
Rationale
As a starting point "Activity" could be replaced by "Processing" as discussed w/ @ssaneei and Michael Dayan. "Entity" by "InputOutput" and "Agent" by "SoftwarePackage"?
Minimal example
{
"@context": "https://purl.org/nidash/bidsprov/context.json",
"BIDSProvVersion": "1.0.0",
"records": {
	"SoftwarePackage": [
  	{
    	...
  	}
	],
	"Processing": [
  	{
    	...
  	},
  	...
  	}
	],
	"InputOutput": [
  	{
    	...
  	},
  	{
    	...
  	},
	]
  }
}
}

Log of related discussion on Gdoc:

I wonder whether we want to "recycle" NIDM-W

authors: cmaumet tiborauer


text:
FOI: http://wiki.cogpo.org is down ATM so linkchecker would report issues

I have emailed about the issue to Jessica Turner  and Angela R. Laird, hopefully they bring the beast back.

CogPo wiki is back up!

Thanks @angielaird!

authors: angielaird effigies yarikoptic

repo: bids-standard/bids-specification


text:
Template variable error: 'dict object' has no attribute 'result' when rendering...

I'm getting the below kind of errors in my home-assistant.log
ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'result' when rendering '{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}'
ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'result' when rendering '{%if value_json.result.mqtt.connected%}online{%else%}offline{%endif%}'
ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'result' when rendering '{%if value_json.result.mqtt.connected%}online{%else%}offline{%endif%}'
ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'dict object' has no attribute 'result' when rendering '{{value_json.result.sys.available_updates.get("stable",{})|to_json}}'

Versions:

Home Assistant: 2024.6.2
Shellies Discovery GEN2: shellies_discovery_gen2.py version 2.30.0
Shelly device firmware: 1.3.2

Shellies Discovery GEN2 automation:
- id: shellies_announce_gen2
  alias: "Shellies Announce Gen2"
  trigger:
    - platform: homeassistant
      event: start
  variables:
    device_info_payload:  "{{ {'id': 1, 'src':'shellies_discovery', 'method':'Shelly.GetConfig'} | to_json }}"
    device_ids:  # enter the list of device IDs (MQTT prefixes) here
      - shellyplus1-a8032ab7fbb0
      - shellyplus1-a8032abafd1c
      - shellyplus1-7c87ce58cb34
      - shellyplus1-7c87ce558428
      - shellyplus1-3c610572c824
      - shellyplus1-7c87ce56475c
      - shellyplus1-7c87ce555ac0
      - shellyplus1-7c87ce55840c
      - shellyplus1-08b61fd12ac4
      - shellyplus1-08b61fd0c2d8
  action:
    - delay: 00:00:30
    - repeat:
        for_each: "{{ device_ids }}"
        sequence:
          - service: mqtt.publish
            data:
              topic: "{{ repeat.item }}/rpc"
              payload: "{{ device_info_payload }}"

- id: shellies_discovery_gen2
  alias: "Shellies Discovery Gen2"
  mode: queued
  max: 999
  trigger:
  - platform: mqtt
    topic: shellies_discovery/rpc
  action:
  - service: python_script.shellies_discovery_gen2
    data:
      id: "{{ trigger.payload_json.src }}"
      device_config: "{{ trigger.payload_json.result }}"
  - service: mqtt.publish
    data:
      topic: "{{ trigger.payload_json.result.mqtt.topic_prefix }}/command"
      payload: "status_update"

Shelly device MQTT settings:

Debug log:

debug.log attached

debug.log

Show me please your device script (Scripts section in the device web panel) and the payloads that the device sends to the MQTT broker.

TCPDump (PCAP - shelly.zip) attached. Hope this helps. Or can you explain me how to get hands on the payload?
This is what the script looks like:
Script name: shellies_discovery_gen2_script_20240216
Script
let topic_prefix = null;
let installed_version = null;

Shelly.call("MQTT.GetConfig", {}, function (config) {
    topic_prefix = config.topic_prefix;
});

function SendDeviceStatus() {
    let _device_info = Shelly.getDeviceInfo();
    installed_version = _device_info.ver;
    Shelly.call("Shelly.GetStatus", {}, function (status) {
        status.sys.installed_version = installed_version;
        MQTT.publish(topic_prefix + "/status/rpc", JSON.stringify(status));
    });
};

[shelly.zip](https://github.com/user-attachments/files/15905427/shelly.zip)

MQTT.setConnectHandler(SendDeviceStatus);
let UpdateTimer = Timer.set(1800000, true, SendDeviceStatus);

Or can you explain me how to get hands on the payload?

I mean screenshot from MQTT Explorer (wait 10 minuts and take a screenshot).

OK. I will provide you a screenshot asap.

I checked the script code and it does not contain JSON paths like those in your errors:
value_json.result.sys.available_updates.stable
value_json.result.mqtt.connected

The script uses those paths:
value_json.sys.available_updates.stable
value_json.mqtt.connected

So the source of the errors is not Shellies Discovery Gen2.

You can find the cause of errors by searching in MQTT Explorer if MQTT Discovery was used to configure the device

This is the filtered tree view:
192.168.0.102
>homeassistant
>>binary_sensor
>>>shellyplus1-a8032ab7fbb0-firmware
>>>config = {"name": "ShellyGarage Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-a8032ab7fbb0-firmware", "qos": 0, "dev": {"cns": [["mac", "A8:03:2A:B7:FB:B0"]], "name": "ShellyGarage", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Robotics", "…
>>>shellyplus1-a8032abafd1c-firmware
>>>config = {"name": "ShellyTuinhuis Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-a8032abafd1c-firmware", "qos": 0, "dev": {"cns": [["mac", "A8:03:2A:BA:FD:1C"]], "name": "ShellyTuinhuis", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Robotics…
>>>shellyplus1-7c87ce58cb34-firmware
>>>config = {"name": "ShellyBadkamerDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-7c87ce58cb34-firmware", "qos": 0, "dev": {"cns": [["mac", "7C:87:CE:58:CB:34"]], "name": "ShellyBadkamerDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Ro…
>>>shellyplus1-7c87ce558428-firmware
>>>config = {"name": "ShellyDaanDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-7c87ce558428-firmware", "qos": 0, "dev": {"cns": [["mac", "7C:87:CE:55:84:28"]], "name": "ShellyDaanDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Robotics",…
>>>shellyplus1-3c610572c824-firmware
>>>config = {"name": "ShellyRienDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-3c610572c824-firmware", "qos": 0, "dev": {"cns": [["mac", "3C:61:05:72:C8:24"]], "name": "ShellyRienDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Robotics",…
>>>shellyplus1-7c87ce555ac0-firmware
>>>config = {"name": "ShellyZithoekRDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-7c87ce555ac0-firmware", "qos": 0, "dev": {"cns": [["mac", "7C:87:CE:55:5A:C0"]], "name": "ShellyZithoekRDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Ro…
>>>shellyplus1-7c87ce56475c-firmware
>>>config = {"name": "ShellyZithoekLDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-7c87ce56475c-firmware", "qos": 0, "dev": {"cns": [["mac", "7C:87:CE:56:47:5C"]], "name": "ShellyZithoekLDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Ro…
>>>shellyplus1-7c87ce55840c-firmware
>>>config = {"name": "ShellyPoort Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-7c87ce55840c-firmware", "qos": 0, "dev": {"cns": [["mac", "7C:87:CE:55:84:0C"]], "name": "ShellyPoort", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Robotics", "cu…
>>>shellyplus1-08b61fd12ac4-firmware
>>>config = {"name": "ShellyOntbijthoekDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-08b61fd12ac4-firmware", "qos": 0, "dev": {"cns": [["mac", "08:B6:1F:D1:2A:C4"]], "name": "ShellyOntbijthoekDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allte…
>>>shellyplus1-08b61fd0c2d8-firmware
>>>config = {"name": "ShellyLivingDBE Firmware", "val_tpl": "{%if value_json.result.sys.available_updates.stable is defined%}ON{%else%}OFF{%endif%}", "en": "true", "uniq_id": "shellyplus1-08b61fd0c2d8-firmware", "qos": 0, "dev": {"cns": [["mac", "08:B6:1F:D0:C2:D8"]], "name": "ShellyLivingDBE", "mdl": "Shelly Plus 1", "sw": "20240522-112837/1.3.2-g34c651b", "hw": "gen2 (SNSW-001X16EU)", "mf": "Allterco Roboti…
>>button
>>>shellyplus1-a8032ab7fbb0-update_firmware
>>>config = {"name": "ShellyGarage Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-a8032ab7fbb0\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-a8032ab7fbb0-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_templa…
>>>shellyplus1-a8032abafd1c-update_firmware
>>>config = {"name": "ShellyTuinhuis Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-a8032abafd1c\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-a8032abafd1c-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_temp…
>>>shellyplus1-7c87ce58cb34-update_firmware
>>>config = {"name": "ShellyBadkamerDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-7c87ce58cb34\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-7c87ce58cb34-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_t…
>>>shellyplus1-7c87ce558428-update_firmware
>>>config = {"name": "ShellyDaanDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-7c87ce558428\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-7c87ce558428-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_templ…
>>>shellyplus1-3c610572c824-update_firmware
>>>config = {"name": "ShellyRienDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-3c610572c824\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-3c610572c824-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_templ…
>>>shellyplus1-7c87ce555ac0-update_firmware
>>>config = {"name": "ShellyZithoekRDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-7c87ce555ac0\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-7c87ce555ac0-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_t…
>>>shellyplus1-7c87ce56475c-update_firmware
>>>config = {"name": "ShellyZithoekLDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-7c87ce56475c\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-7c87ce56475c-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_t…
>>>shellyplus1-7c87ce55840c-update_firmware
>>>config = {"name": "ShellyPoort Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-7c87ce55840c\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-7c87ce55840c-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_templat…
>>>shellyplus1-08b61fd12ac4-update_firmware
>>>config = {"name": "ShellyOntbijthoekDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-08b61fd12ac4\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-08b61fd12ac4-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "valu…
>>>shellyplus1-08b61fd0c2d8-update_firmware
>>>config = {"name": "ShellyLivingDBE Update Firmware", "cmd_t": "~rpc", "payload_press": "{\"id\":1,\"src\":\"shellyplus1-08b61fd0c2d8\",\"method\":\"Shelly.Update\",\"params\":{\"stage\":\"stable\"}}", "en": "true", "uniq_id": "shellyplus1-08b61fd0c2d8-update_firmware", "qos": 0, "avty": [{"topic": "~online", "payload_available": "true", "payload_not_available": "false"}, {"topic": "~status/rpc", "value_tem…

authors: bieniu roofburner


text:
Adding Starbucks portal and portal scraper

Fixed. Thanks @amouly for the tip.

Why would you do all this work? you can simply install Chrome extension and download the file of that website:
https://chrome.google.com/webstore/detail/singlefile/mpiodijhokgodhhofbcjdecpffjipkle/related

lol. Never tried sneaking company website logins before. So ya, I never saw this extension. I'll try that. Thanks.

I think there is a file limit on the portal size, not sure exactly what it is, but, this file is much larger than the other portals.

Ya... I'll remove as much js as I can 🧐

Limit is 20kb

I thought it was js carried over, but it's the images embedded with base64...

Down to 48.2KB, still too big 😢 Maybe something like tinyimg can help...

Seems impossible to halve this 😒 lol. I'll try some more in a bit.

Got it to 19KB but couldn't keep the logo. Still looks good with the rest of the elements I could keep. Made a tool to help squash the html.
https://github.com/RocketGod-git/evilportal-htmlsquash

authors: RocketGod-git RogueMaster amouly


text:
Update advanced usage docs for 0.9

Similar to #234.
Note that only https://github.com/bigchaindb/bigchaindb-driver/commit/0ce630daf23bfddc453ee04d31655fc19d6a5d38, https://github.com/bigchaindb/bigchaindb-driver/commit/1675ae588051a0296c6568d27facbe8fd8b854ee, and https://github.com/bigchaindb/bigchaindb-driver/commit/88df45c7859665dbbe58ddf1615eafe1d0ffde5b contain non-whitespace changes.
Note: I've avoided changing the sections with todo (e.g. hashlocks, thresholds, timelocks, etc) aside from modifying any direct access to a transaction that had become obsolete (see https://github.com/bigchaindb/bigchaindb-driver/commit/88df45c7859665dbbe58ddf1615eafe1d0ffde5b).

Preview:

Codecov Report

Merging #235 into master will not impact coverage.

@@          Coverage Diff           @@
##           master    #235   +/-   ##
======================================
  Coverage    98.4%   98.4%
======================================
  Files           9       9
  Lines         188     188
======================================
  Hits          185     185
  Misses          3       3

Continue to review full report at Codecov.

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

authors: codecov-io sohkai

repo: bigchaindb/bigchaindb-driver


text:
BigchainDB installs but won't connect to RethinkDB

I'm using a Vagrant instance to test BigchainDB. I made sure all the dependencies are installed. The start command isn't working; it gives me the following output:
vagrant@vagrant-ubuntu-trusty-64:~$ rethinkdb --version
rethinkdb 2.3.5~0trusty (GCC 4.8.2)
vagrant@vagrant-ubuntu-trusty-64:~$ bigchaindb --version
bigchaindb 0.6.0
vagrant@vagrant-ubuntu-trusty-64:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"

vagrant@vagrant-ubuntu-trusty-64:~$ bigchaindb start
INFO:bigchaindb.commands.bigchain:BigchainDB Version 0.6.0
INFO:bigchaindb.config_utils:Configuration loaded from `/home/vagrant/.bigchaindb`
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/rethinkdb/net.py", line 271, in __init__
    self._socket = socket.create_connection((self.host, self.port), timeout)
  File "/usr/lib/python3.4/socket.py", line 512, in create_connection
    raise err
  File "/usr/lib/python3.4/socket.py", line 503, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/bigchaindb", line 11, in <module>
    load_entry_point('BigchainDB==0.6.0', 'console_scripts', 'bigchaindb')()
  File "/usr/local/lib/python3.4/dist-packages/bigchaindb/commands/bigchain.py", line 305, in main
    utils.start(parser, globals())
  File "/usr/local/lib/python3.4/dist-packages/bigchaindb/commands/utils.py", line 95, in start
    func(args)
  File "/usr/local/lib/python3.4/dist-packages/bigchaindb/commands/bigchain.py", line 165, in run_start
    db.init()
  File "/usr/local/lib/python3.4/dist-packages/bigchaindb/db/utils.py", line 94, in init
    conn = get_conn()
  File "/usr/local/lib/python3.4/dist-packages/bigchaindb/db/utils.py", line 18, in get_conn
    bigchaindb.config['database']['port'])
  File "/usr/local/lib/python3.4/dist-packages/rethinkdb/net.py", line 661, in connect
    return conn.reconnect(timeout=timeout)
  File "/usr/local/lib/python3.4/dist-packages/rethinkdb/net.py", line 572, in reconnect
    return self._instance.connect(timeout)
  File "/usr/local/lib/python3.4/dist-packages/rethinkdb/net.py", line 430, in connect
    self._socket = SocketWrapper(self, timeout)
  File "/usr/local/lib/python3.4/dist-packages/rethinkdb/net.py", line 337, in __init__
    (self.host, self.port, str(ex)))
rethinkdb.errors.ReqlDriverError: Could not connect to localhost:28015. Error: [Errno 111] Connection refused

That means that either rethinkdb is not running or is not running on localhost:28015

@Flaise Are you still having issues connecting BigchainDB with RethinkDB on vagrant? It might be worth trying our docker settings, checking that those work for you, and then diffing for what's different between the docker config and your vagrant config.
I'm not familiar with provisioning vagrant instances, but it's important to note that on Docker, we need to expose a number of ports from the RethinkDB instance and tell BigchainDB to connect to them (e.g. here and here).

Version 0.6.0 is working fine. I didn't realize at the time that there were extra steps involved in starting RethinkDB (and that there was an explanation in a part of your documentation other than the quick start).

Awesome :).

I didn't realize at the time that there were extra steps involved in starting RethinkDB

Just curious, was step B on the quickstart page confusing because it wasn't clear that you had to keep the rethinkdb daemon up?

Am still getting this error even though my rethinkDB is up and listening on 28015. Any help would be much appreciated.
Error:
_

File "/usr/local/lib/python3.5/dist-packages/rethinkdb/net.py", line 271, in init
self._socket = socket.create_connection((self.host, self.port), timeout)
File "/usr/lib/python3.5/socket.py", line 711, in create_connection
raise err
File "/usr/lib/python3.5/socket.py", line 702, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/bigchaindb", line 11, in
load_entry_point('BigchainDB==0.7.0', 'console_scripts', 'bigchaindb')()
File "/usr/local/lib/python3.5/dist-packages/bigchaindb/commands/bigchain.py", line 332, in main
utils.start(create_parser(), sys.argv[1:], globals())
File "/usr/local/lib/python3.5/dist-packages/bigchaindb/commands/utils.py", line 96, in start
return func(args)
File "/usr/local/lib/python3.5/dist-packages/bigchaindb/commands/bigchain.py", line 182, in run_start
db.init()
File "/usr/local/lib/python3.5/dist-packages/bigchaindb/db/utils.py", line 156, in init
conn = get_conn()
File "/usr/local/lib/python3.5/dist-packages/bigchaindb/db/utils.py", line 75, in get_conn
db=bigchaindb.config['database']['name'])
File "/usr/local/lib/python3.5/dist-packages/rethinkdb/net.py", line 661, in connect
return conn.reconnect(timeout=timeout)
File "/usr/local/lib/python3.5/dist-packages/rethinkdb/net.py", line 572, in reconnect
return self._instance.connect(timeout)
File "/usr/local/lib/python3.5/dist-packages/rethinkdb/net.py", line 430, in connect
self._socket = SocketWrapper(self, timeout)
File "/usr/local/lib/python3.5/dist-packages/rethinkdb/net.py", line 337, in init
(self.host, self.port, str(ex)))
rethinkdb.errors.ReqlDriverError: Could not connect to localhost:28015. Error: [Errno 111] Connection refused

_
RethinkDB Terminal

Loading data from directory /home/innovationlab/rethinkdb_data
Listening for intracluster connections on port 29015
Listening for client driver connections on port 28015
Listening for administrative HTTP connections on port 8080

I think we've seen this before and I think the solution was to:

update RethinkDB to the latest version (see https://rethinkdb.com/docs/install/ ) and
update the rethinkdb Python package to the latest version: pip install --upgrade rethinkdb

@jln1989 are you running rethinkdb in a virtual machine or container?
And is rethinkdb and bigchaindb running on the same machine? If not you need to change the ~/.bigchaindb config file with the correct host for the database

@ttmc : I have installed the rethinkDB today morning and version is

rethinkdb 2.3.5~0xenial (GCC 5.3.1).

I have run the second command you have given me and it gives me "it has already been updated"
@r-marques : Am running rethinkdb and bigchaindb are running on the same machine only.
Thanks in advance guys. Am a newbie to rethink/bigchaindb and any help would be great.

I am closing this for now.
@jln1989 if you are still having problems we can re open this.

authors: Flaise jln1989 r-marques sohkai ttmc

repo: bigchaindb/bigchaindb


text:
Problem: No wait when getting value from queue

Solution: Random failure of test tests/test_events.py::test_event_handler_raises_when_called_after_start seem to be because of get_nowait which returns way to quickly even when the queue
has data.

Could you say a bit more? When you described this to me in person, you said that get_nowait() was returning the wrong exception?

Codecov Report

Merging #2423 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #2423   +/-   ##
=======================================
  Coverage   88.43%   88.43%
=======================================
  Files          39       39
  Lines        2275     2275
=======================================
  Hits         2012     2012
  Misses        263      263

authors: codecov-io kansi ttmc


text:
Drop python 2 support for pyadam

Python 2 will not be maintained past 2020 (https://pythonclock.org/). Many modules already have dropped support.

Would you like to triage this to the next release milestone (0.31.0, tentatively scheduled for mid-January)?

Sgtm!

repo: bigdatagenomics/adam


text:
Sass support

Are you planning to add Sass support soon? If not, can we do that?

Hey @gokaygurcan, There isn't any plan for Sass support at the moment, purely due to our internal workflow. If you were looking to, feel free to fork Turret and add Sass support.

Good to know, thanks! Then i'm starting to work on Sass port ;)

I look forward to it!

authors: gokaygurcan scottdejonge

repo: bigfishtv/turret


text:
HelperTest_Controller AbsoluteLink method needs updating

Hi, similar issue to https://github.com/bigfork/silverstripe-oauth-login/issues/28
Declaration of Bigfork\SilverStripeOAuth\Client\Test\Helper\HelperTest_Controller::AbsoluteLink() must be compatible with SilverStripe\Control\RequestHandler::AbsoluteLink($action = '')

Thanks
James

Fixed in 2.2.2, thanks

authors: MrJamesEllis kinglozzer

repo: bigfork/silverstripe-oauth


text:
🛑 Domestic Moving Rate is down

In a392041, Domestic Moving Rate (https://preview.agoyu.com/ajax/agoyu/mover/domestic-rates/vehicle-rates/list) was down:

HTTP code: 521
Response time: 80 ms

Domestic Moving Rate is restart service.

Domestic Moving Rate is restart service.

Resolved: Domestic Moving Rate is back up in 0651276.

repo: biginvn/upptime


text:
TypeError raised by Vue app drag select

The following error is raised when attempting to "paint" cells:
AgGridDragSelect.vue:105 Uncaught TypeError: Failed to execute 'getComputedStyle' on 'Window': parameter 1 is not of type 'Element'.
    at VueComponent.isItemSelected (AgGridDragSelect.vue:105:1)
    at eval (AgGridDragSelect.vue:169:1)
    at Array.filter (<anonymous>)
    at VueComponent.onMouseMove (AgGridDragSelect.vue:168:1)

This was working in v0.13.4, but currently not. The component itself has not been updated in 10 months, so I suspect a change in the parent component, or maybe some dependency issue..

Fixed. This was caused by an undocumented breaking change in SODAR Core v0.13.0. I will back-document that in the next update.

repo: bihealth/sodar-server


text:
visible field doesnt work

I'm submitting a ...  (check one with "x")
[ x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
visible attr is not taken into account
Expected behavior
visible attr should be taken into account
Reproduction of the problem
Add [visible]="true" and see if it shows up
What is the motivation / use case for changing the behavior?
I dont know
Please tell us about your environment:
not important

Smart Modal version: 0.8.x
latest

Angular version: 2.0.x
ang 5

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
chrome

Language: [all | TypeScript X.X | ES6/7 | ES5]

Hi @therepo90,
Thanks for your interest in Ngx-Smart-Modal, indeed there is a bug concerning the visible modal attribute. We'll take some time to fix it.
You are free to participate in the project by contributing with a pull request 🤟

Hi all! I'm currently working on a fix branch to fix current issues. I add this one to the list.
Stay tuned! 🖖

Hi @lkostrowski, I'm refactoring / fixing some stuff in the library and I would like to know if you've done something about this issue. I'm testing several ways to fix that, as this thread shows: https://stackoverflow.com/questions/38571812/how-to-detect-when-an-input-value-changes-in-angular .
Let me know if you have any suggestion or in-progress work. 😉
Cheers 🖖

Hi
Sorry, haven't had time for that and we basically implemented our own modal.
I'm working now on refactoring it and I think about making it kind of "controlled component", which will only receive view-related inputs and visible: true/false.
It could emit events which will be taken by some global service for communication (showing overlay and other actions). Anyway - modal will be stateless and controller will be moved to parent component

As said in the description by @therepo90 and after thinking about it, there's no need to make visible an @Input. The service support this job and opening/closing a modal could be done directly with the built-in methods.
It seems [visible] options is not used and does not offer a useful service for users. Toggling the visibility of a modal could be done with modal built-in toggle() method or with the service.
To avoid breaks, it will stay as an option until the next major release, but it will be undocumented in the next release.

authors: khylias lkostrowski maximelafarie therepo90

repo: biig-io/ngx-smart-modal


text:
Command.Options does not include inherited options

Inherited options should only be used for subcommands

Move logic from mapping extensions to Command to ensure
inherited options are added to subcommands

obsolete Inherited for AssignToExecutableSubcommands
as a more descriptive name for Option and
OptionAttribute

update help, removing the clunky footnote concept.
since there will only be confusion when a default
command also has interceptor options, adding a new
options section is clear enough.

leaving the term Inherited in the tests and comments
as it is more terse than AssignToExecutableSubcommands
and added Inherited term to the xml docs to make
the connection easier to see.

this is the last feature update for v3.

closes #176

repo: bilal-fazlani/commanddotnet


text:
settings: Fix xdp bug on our side

Since future setting keys might be fixed we allow both value(value(x)) and value(x).

We don't have the CI infra to make sure xdp is actually running so far, so the test is not useful as is.

repo: bilelmoussaoui/ashpd


text:
滚动条丑and遮挡置顶按钮for windows

滚动条已修复，需要等下次发版！

authors: bilibili-ayang pkptzx

repo: bilibili-ayang/ChatGPT-Desktop


text:
how to build the route training input from the routes

Hi binghong
I am currently confused about building AI inputs from the routes like
['Cc1ccc(C(=O)N2CCC(c3ccc(-c4cnn(C)c4)cc3)CC2)cc1NC(=O)c1ccc(NC(C)C)nc1>>Cc1ccc(C(=O)N2CCC(c3ccc(-c4cnn(C)c4)cc3)CC2)cc1NC(=O)c1ccc(Cl)nc1.CC(C)N', 'Cc1ccc(C(=O)N2CCC(c3ccc(-c4cnn(C)c4)cc3)CC2)cc1NC(=O)c1ccc(Cl)nc1>>O=C(Cl)c1ccc(Cl)nc1.Cc1ccc(C(=O)N2CCC(c3ccc(-c4cnn(C)c4)cc3)CC2)cc1N', 'Cc1ccc(C(=O)N2CCC(c3ccc(-c4cnn(C)c4)cc3)CC2)cc1N>>Cn1cc(-c2ccc(C3CCNCC3)cc2)cn1.Cc1ccc(C(=O)O)cc1N'].
I had a look at the code at the trainer.py and the .pt data file, the training input was fps, values, r_costs, t_values, r_fps, r_masks from the training routes data. Could you share the information (code better) about how can I buld the the AI input from the routes data.

The routes are stored in the following format:
[reaction #1, reaction #2, ... reaction #N]
Each reaction is a string in the following format:
'product_smiles>>reactants_smiles(separated by .)]'
For the fields in the training set, they are:
positive training example:
fps: fingerprint of the target molecule
values: ground truth cost of the target molecule
negative training example:
r_values:  sum of reactant values in a negative reaction sample
r_costs:    negative reaction cost
t_values:  ground truth cost of the target molecule
where r_values are computed using r_fps and r_masks
r_fps:   reactants of the fingerprints
r_masks:  r_fps are of different lengths, we pad the list of r_fps into a fixed size matrix, r_masks are 0/1 masks used to filter out the padded 0s (see https://github.com/binghong-ml/retro_star/blob/master/retro_star/trainer/trainer.py#L43 for usage)

The routes are stored in the following format:
[reaction #1, reaction #2, ... reaction #N]
Each reaction is a string in the following format:
'product_smiles>>reactants_smiles(separated by .)]'
For the fields in the training set, they are:
positive training example:
fps: fingerprint of the target molecule
values: ground truth cost of the target molecule
negative training example:
r_values:  sum of reactant values in a negative reaction sample
r_costs:    negative reaction cost
t_values:  ground truth cost of the target molecule
where r_values are computed using r_fps and r_masks
r_fps:   reactants of the fingerprints
r_masks:  r_fps are of different lengths, we pad the list of r_fps into a fixed size matrix, r_masks are 0/1 masks used to filter out the padded 0s (see https://github.com/binghong-ml/retro_star/blob/master/retro_star/trainer/trainer.py#L43 for usage)

authors: binghong-ml eacwecwecd


text:
update 08_data.md

修改一处很小的笔误, 多了一个“用”字.

LGTM

authors: bingohuang ziyitony

repo: bingohuang/effective-go-zh-en


text:
notification sort

love the product and just have a recommendation... can a setting be added to sort the notifications per subscription the opposite way ?  right now... it's newest at the top forced.   I would like the newest at the bottom like everything else I use.  Thanks for the consideration!

Web or Android? I suppose both?

I was thinking android (I don't really use the web app in this case) but imagine it'd be useful for both :)

authors: binwiederhier x-tk

repo: binwiederhier/ntfy


text:
Empty bind mounted directories and no server.yml?

ntfy works and all is fine, but my bind mounted directories are empty, is it normal?

here is my docker-compose.yml
services:

  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    hostname: ntfy
    env_file: .env
    restart: unless-stopped
    command:
      - serve
    volumes:
      - ./ntfy_cache:/var/cache/ntfy
      - ./ntfy_etc:/etc/ntfy
    expose:
      - 80:80

networks:
  default:
    name: caddy_net
    external: true

I tried adding user: root just to see if its not permission issue, but no change.
I am kinda confused on this, as when I down it and recreate the stuff is there... but apparently its saved by browser and in another browser its not there.
Interesting, though something is not right about this if I would want to go with users and passwords

ntfy works and all is fine, but my bind mounted directories are empty, is it normal?

This is normal. The Docker instructions have a big fat "info" box that says that "Docker image does not contain a /etc/ntfy/server.yml file".

I am kinda confused on this, as when I down it and recreate the stuff is there... but apparently its saved by browser and in another browser its not there.

When you're not logged into the web app (you need enable-login: true to allow that), everything is stored in the browser storage. This is similar to the Android app, for which everything is stored on the device. The account sync feature will allow syncing between devices. That will come soon-ish.

Thanks!

authors: DoTheEvo binwiederhier


text:
add support for selecting lines of text files with Mac line endings '\r'

There's three kinds of line endings:
unix '\n'
DOS '\r'\n'
Mac '\r'
Currently, preston supports unix/DOS, but when selecting a line in a file with Mac line endings (like with TaxoDros), nothing shows up:
e.g.,
preston cat 'line:hash://sha256/6cf7b4e856bce735b7e687d7cb76210a567d2e7f2e58d779a41cde75f05c9fd3!/L58651-L58661'

tells preston to select line L58651 - L58661 of content with id hash://sha256/6cf7b4e856bce735b7e687d7cb76210a567d2e7f2e58d779a41cde75f05c9fd3 .
currently, no result is returned, even though,
preston cat 'hash://sha256/6cf7b4e856bce735b7e687d7cb76210a567d2e7f2e58d779a41cde75f05c9fd3' | tr '\r' '\n' | tail -n+58651 | head -n11

produced:
.TEXT;
garcia et al., 2020
.A Garcia-Cancino, M.D., Gonzalez-Cabrera, J.,
Sanchez-Gonzalez, J.A., & Arredondo-Bernal, H.C.,
.J 2020
.S Biological and Population Parameters, as well as
Oviposition Preference, of Two Pupal Parasitoids
of Drosophila suzukii (Diptera: Drosophilidae) in Mexico.
.Z J. Entomol. Sci., 55(1):87�97.
.K ocr++ / DOI:10.18474/0749- 8004-55.1.87
.P Garcia et al., 2020.pdf

Suggest to add support for mac line endings when selecting files for inclusion.

with recent changes, the desired result was obtained -
preston cat 'line:hash://sha256/6cf7b4e856bce735b7e687d7cb76210a567d2e7f2e58d779a41cde75f05c9fd3!/L58651-L58661' | tr '\r' '\n'

yielding
.TEXT;
garcia et al., 2020
.A Garcia-Cancino, M.D., Gonzalez-Cabrera, J.,
Sanchez-Gonzalez, J.A., & Arredondo-Bernal, H.C.,
.J 2020
.S Biological and Population Parameters, as well as
Oviposition Preference, of Two Pupal Parasitoids
of Drosophila suzukii (Diptera: Drosophilidae) in Mexico.
.Z J. Entomol. Sci., 55(1):87�97.
.K ocr++ / DOI:10.18474/0749- 8004-55.1.87
.P Garcia et al., 2020.pdf

Note that running preston in server mode using
preston s

produced the following result in a web browser

repo: bio-guoda/preston


text:
Fixes issue 97

Aligns with the updated BCO API.

This Closes #97

@HadleyKing this is the other PR to support changing to /DRAFT for draft pulls.  Seems to work in my testing, although will need additional testing when merged with everything in case I've missed something.

repo: biocompute-objects/portal


text:
Using int64 PyRanges is buggy

I need to test the whole codebase with values larger than 2,147,483,647 to see that it works as expected.
Known places that are buggy: pyranges.random, pyranges.cluster and possibly more :/

Should be fixed by updating sorted_nearest, bamread and ncls to newest versions. Would love to hear if anyone still has problems :)

repo: biocore-ntnu/pyranges


text:
redbiom nice display of 504

After doing some more tests with qiita/redbiom, I realized that if you retrieve a lot of results, the server will send a 504 (timeout) and this wasn't being caught by JS. Obviously, this is not a solution but the solution is something that might take some discussion of how to better implement + implementation time. So for the time being this PR adds a "nice" error message.
If timeout:

if something else,

Additionally, decided to improve the show_loading by adding a flag to show some extra text: "This task might take a long time (up to 5 minutes), please do not close this page.". This feature is currently only being used by redbiom but this might be useful for others in the future. Note that 5 min is just a number based on what I was seeing in my tests.

Codecov Report

Merging #2311 into release-candidate will not change coverage.
The diff coverage is n/a.

@@                Coverage Diff                @@
##           release-candidate   #2311   +/-   ##
=================================================
  Coverage               93.8%   93.8%
=================================================
  Files                    163     163
  Lines                  18581   18581
=================================================
  Hits                   17430   17430
  Misses                  1151    1151

Continue to review full report at Codecov.

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

authors: antgonza codecov-io

repo: biocore/qiita


text:
🐛 Some ignore pattern generate ignored file error

Environment information
CLI:
  Version:                      1.5.0
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           linux

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v21.5.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/10.2.5"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 false

Workspace:
  Open Documents:               0

What happened?
Execute the following script and observe the error:
$ git clone https://github.com/bare-ts/bare.git
$ cd bare
$ npm ci
$ npx biome format --verbose --error-on-warnings --diagnostic-level=warn .
./tests-corpus/index.test.js format ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ The file ./tests-corpus/index.test.js was ignored.

Compared 20 file(s) in 7ms
Skipped 1 file(s)

The configuration is:
{
  "files": {
    "ignoreUnknown": true
  },
  "formatter": {
    "indentStyle": "space",
    "ignore": ["./tests-corpus/*"]
  },
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "
  }
}

If I change formatter.ignore from ./tests-corpus/* to ./tests-corpus the bug seems fixed.
Expected result
No error should be thrown.
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

With version 1.4.1 I had
  "files": {
    "ignore": ["localization.ts"]
  }

After updating to version 1.5.0, it did not ignore the file anymore, reporting lint errors in that file. After I changed the ignore pattern to **/localization.ts, it ignores the file again, but now prints
[widget-common]: src/js/localization.ts lint ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[widget-common]:
[widget-common]:   × The file src/js/localization.ts was ignored.

The exit code is still 0, so the lint is successful.

This is very confusing for junior devs. In a rare case when setting up a linter can decrease productivity instead of increasing it.
Seriously, what is the logic behind these huge warnings? These are not accidental ignores, the paths are explicitly ignored in the config. Imagine if Git was printing after every pull/push/merge/commit/etc this:
Warning: node_modules/ is ignored.
Warning: .svelte-kit/ is ignored.
Warning: .vite.config.ts-timestamp-xyz is ignored.
...

@notramo
The reason why you see more diagnostics than before is because we had reports where users didn't understand why certain files weren't checked.
Even though we document that on our website, the reports were still coming.
Given the previous statement, and given that now you see too many diagnostics, what do you think we should do? What do you suggest?

If the assets/do-not-modify.json is ignored, and Biome receives assets/do-not-modify.json explicitly, then show the warning, but if receives assets/, then do not.
But even in this case, it can be useful, so I'm not sure if it should be implemented.
However, there is an use case where the current behavior is problematic. When used with lefthook, it's simpler to not copy the entire ignore list from biome.json to lefthook.yml.
biome:
    glob: 'assets/js/**.{ts,json,js}'
    run: bun run biome check --apply {staged_files}

For this use case I would recommend adding --no-ignored-file-warning.

So how do we ignore those warnings?

They are harmless. Use --diagnostic-level=error to show only the ones with error severity

They are harmless. Use --diagnostic-level=error to show only the ones with error severity

I'm unable to silence these warnings. The format command doesn't support --no-ignored-file-warning
# *.pb.ts is ignored
biome format --diagnostic-level=error .
./google/type/money.pb.ts format ━━━━━━━━━━━━

  ✖ The file ./google/type/money.pb.ts was ignored.

The reason why you see more diagnostics than before is because we had reports where users didn't understand why certain files weren't checked.
Given the previous statement, and given that now you see too many diagnostics, what do you think we should do? What do you suggest?

I expect linters to output nothing or a short success message if there are no errors. If I wanted to figure out why biome was ignoring files, I'd first look to increase the log level to DEBUG.
I think emitting warnings is a short-term solution. Most folks will turn them off because it's too noisy. Once the warnings are disabled, we're at the same staring point. In the long term, users still won't understand why biome is ignoring files since they'll have the warnings disabled.
Since the problem is that users don't understand why biome ignores files and open support tickets, maybe this can be solved in the ticket template?

This should be fixed in the last patch release (v1.5.1). Could anyone confirm that they no longer get errors?

Tested on 1 project, it's fixed for our use case.

I can confirm the latest patch resolves the issue for us, thanks! ❤

Sorry, I configured as below and when I run yarn biome lint, files and subfolders in src/common are not ignored? Is anyone having the same problem?
{
  "$schema": "https://biomejs.dev/schemas/1.8.2/schema.json",
  "files": {
    "ignore": ["dist/**", "node_modules/**", ".vscode/**", "scr/common/**"]
  },
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentWidth": 2,
    "indentStyle": "space",
    "formatWithErrors": true
  }
}

Sorry, I configured as below and when I run yarn biome lint, files and subfolders in src/common are not ignored? Is anyone having the same problem?

"scr/common/**" -> "src/common/**"

@Sec-ant Oh thanks you so much

@Sec-ant Any way, I don't want to ignore the file in biome.json, but I want to comment right in that file, but currently I only know the comment // biome-ignore lint/suspicious/noExplicitAny: <explanation> to ignore a line, how do can I ignore biome check in the entire file by commenting. Many thanks

how do can I ignore biome check in the entire file by commenting.
That's a feature we don't have yet

Here is my problem
Currently I am configuring as below in the biome.json file
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    },
    "include": ["src/**", "tests/**"],
    "ignore": ["src/common/**"]
  }

If I run the command yarn biome lint on the terminal there is no problem. But I want to set up a pre-commit with husky, I will run the command yarn biome lint to make sure what I commit is valid, however if I edit any file outside the src folder or tests it will lead to an error. The path was not found because the yarn biome lint command ignored it. Do you have any suggestions to solve this problem?

You can use --no-errors-on-unmatched.
Next time you can consult the CLI reference page: https://biomejs.dev/reference/cli/#biome-lint

authors: Conaclos Sec-ant blutorange ematipico gunta jschaf leo-longtran longhoccongnghe notramo przemyslawzalewski

repo: biomejs/biome


text:
chore: update schema definition

Summary

previously MR: #2397

Property jsxRuntime is not allowed:
But terminal output told me need to use jsxRuntime

The schema for jsxRuntime is not match on the Doc or the prompt on terminal, so I decide to update to the correct definition.🙏
Test Plan

We should update the serde attributes not directly the schema?

authors: Conaclos Mayandev


text:
Graphs cut off legend

From https://biosimulations.org/projects/BIOMD0000000010_tellurium_Negative_feedback_and_ultrasen

The legend in the upper right is cut off.

:tada: This issue has been resolved in version 9.52.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: biosimulations-daemon luciansmith

repo: biosimulations/biosimulations


text:
symengine causes a linear constraint to be recognized as a quadratic one, causing an error

For future reference: With symengine installed the constraints added by the following function are evaluated to be quadratic, raising an error, without symengine they work perfectly. A sample error message:
NotImplementedError: Quadratic constraints (like forward_pos_2DHGLCK: 0.0 - dist_2DHGLCK - 100000.0*(1 - direction_2DHGLCK) - (1.0*2DHGLCK - 1.0*2DHGLCK_reverse_2bd8f) <= -0.72) are not supported yet.

def adjust_fluxes2model(model, observations, uncertainties=None, linear=True,
                        big_m=1E05):
    """
    Minimize the distance to observed fluxes accounting for multiple directions.

    If your observations include uncertainties the objective function, i.e.,
    minimizing the distance to the observations, is weighted by the inverse
    of the uncertainties.

    Parameters
    ----------
    model : cobra.Model
        The metabolic model
    observations : pandas.Series
        The observed fluxes. The index should contain reaction identifiers.
    uncertainties : pandas.Series, optional
        The uncertainties of the individual measurements, e.g., standard
        error. The index of the series should correspond at least partially
        to the ``observations``.
    linear : bool, optional
        Whether to minimize the linear or quadratic distance.
    big_m : float, optional
        Big M method value. This is used to resolve greater than inequalities
        and should be an adequately large number.

    Returns
    -------
    cobra.Solution

    """
    flux_col = "flux"
    weight_col = "weight"
    if uncertainties is None:
        data = observations.to_frame().join(Series([], name=weight_col))
    else:
        uncertainties.name = weight_col
        data = observations.to_frame().join(uncertainties)
    data.columns = [flux_col, weight_col]
    # replace missing and zero values
    data.loc[data[weight_col].isnull() | isinf(data[weight_col]) |
             (data[weight_col] == 0), weight_col] = 1
    prob = model.problem
    to_add = list()
    new_obj = list()
    with model:
        model.objective = prob.Objective(prob.Zero, direction="min", sloppy=True)
        for rxn_id, flux, weight in data[[flux_col, weight_col]].itertuples():
            try:
                rxn = model.reactions.get_by_id(rxn_id)
            except KeyError:
                LOGGER.warning("'%s' not found in the model. Ignored.", rxn_id)
                continue
            direction = prob.Variable("direction_" + rxn_id, type="binary")
            dist = prob.Variable("dist_" + rxn_id)
            forward_pos = prob.Constraint(
                flux - rxn.flux_expression - big_m * (1 - direction) - dist,
                ub=0, name="forward_pos_" + rxn_id)
            forward_neg = prob.Constraint(
                rxn.flux_expression - flux - big_m * (1 - direction) - dist,
                ub=0, name="forward_neg_" + rxn_id)
            reverse_pos = prob.Constraint(
                (-flux) - rxn.flux_expression - big_m * direction - dist,
                ub=0, name="reverse_pos_" + rxn_id)
            reverse_neg = prob.Constraint(
                rxn.flux_expression - (-flux) - big_m * direction - dist,
                ub=0, name="reverse_neg_" + rxn_id)
            if linear:
                new_obj.append((dist, 1 / weight))
            else:
                raise NotImplementedError("Need to set quadratic coefficients.")
#                new_obj.append((dist * dist, 1 / weight))
            to_add.extend([direction, dist, forward_pos, forward_neg,
                           reverse_pos, reverse_neg])
        model.add_cons_vars(to_add)
        model.objective.set_linear_coefficients({v: f for v, f in new_obj})
        solution = model.optimize(raise_error=True)
    return solution

Sympy does automatic expansions for certain types of nested expressions, e.g. coef * (var1 - var2). Symengine does not appear to do this at all, instead expressions are structured exactly as they are formulated. The problem can be easily fixed by uncommenting line 466 in optlang.interface. However this will have a negative impact on general performance. At the very least it should only be done when optlang._USING_SYMENGINE is true - since symengine is so fast it may actually not have a huge effect there.
@Midnighter If you have some cobrapy benchmarks, can you maybe check how this would impact performance with symengine?

I will gather some stats.

authors: KristianJensen Midnighter

repo: biosustain/optlang


text:
🛑 Personal m3u is down

In 9a38a20, Personal m3u (https://personalm3u.onrender.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Personal m3u is back up in d5e920f after 16 minutes.


text:
Validation failed: active is not defined in blueprints

Hi, I get this error anytime I save the configuration page:
Validation failed: active is not defined in blueprints
A workaround is to use "validation: loose" (instead of strict) in blueprints.yaml
I tried removing line "active: true" in file facebook-feed.yaml, but it did not solve the problem
best regards

sorry for the late reply. I#ll will have a look into that.

authors: bjoernbohr xchardon

repo: bit-it/facebook-feed


text:
PlatformIO registry

Did you register AnimatedGIF on PlatformIO?
https://platformio.org/lib/show/10952/AnimatedGIF/
If you did, do you mind using pio package publish to publish the latest release?
If you didn't you may run into the same issue I did, where someone registered your GitHub username in PlatformIO and registered your libraries, and now there's no obvious way to publish updates to your own library without making a duplicate registry entry under a different username, while the original out of date registry still has priority.  (Annoying!)
I ended up accidentally adding a duplicate registry entry for AnimatedGIF as I thought pio package publish would know to update the existing registry entry for AnimatedGIF, and not create a duplicate.  I used pio package unpublish and I think it's in the process of being removed.  At least "AnimatedGIF" no longer shows up when I search for libraries under my username.

I don't use PlatformIO, so I have no skin in that game. I saw some of my Arduino libraries listed in there and thought that there was some automated process which pulls them in from the Arduino library manager. I just have too many things going on to start working with a new dev system and tools.

I hear you, I said the same thing until I started using the WLED project and found it was a much better experience compiling that large project with their PlatformIO configuration than with the Arduino IDE.  I haven't switched over yet, I'm still compiling my other projects with Arduino, but I see the appeal and will likely move more of my projects there slowly over time.
If you do ever want to claim your "bitbank2" name on PlatformIO, you can see it was surprisingly painless for me to claim "pixelmatix":
https://community.platformio.org/t/how-to-handle-someone-registering-my-library/19195

Thanks for the info. I may do this in the near future.


text:
Malwarebytes

I don't think this is a problem, just an information item.
Recently, I installed a product called MalwareBytes  on my Windows 7 machine.
That program popped up an alert and blocked the resolver IP addresses when SimpleDnsCrypt reached out on the internet.
So, within MalwareBytes settings I "excluded" (whitelisted) these three  .EXE files:
SimpleDnsCrypt.exe
dnscrypt-proxy-secondary.exe
dnscrypt-proxy.exe
and so I no longer get those alerts.  Hopefully, I have not introduced a security hole!!!
Alternatively, I could have whitelisted just the resolver IP addresses, but since I am traveling frequently, I may change my selected resolvers.  So, I thought to just whitelist those EXE files.
This story is mentioned here just as an FYI to others who may be using these two programs.

Maybe the amazing @hasherezade could help have this fixed?

Which resolver were you using?
The detections should not occur anymore.

Well, I am in a different location now, and of course using a different ISP (here it is a wireless ISP through a shortwave radio on a 50 foot antenna mast).
But I have not yet changed the resolvers.   Therefore, I believe I was using

D0wn Resolver US 107.181.187.219
Secondary OpenNIC Anycast 185.121.177.53

So later today I will go into Malwarebytes and clear the whitelist.  Then I will report back here.

Thanks - I've checked again and those IP are not detected.
fr33tux
https://fr33tux.org - https://toolslib.net
GPG : 8E7F 8550 9FBD 9ED8 E68F ACB9 18E8 99E6 80C4 FF62
XMPP: fr33tux@jabber.otr.im
On March 30, 2017 11:29:34 AM PDT, AlphaCzerwinski notifications@github.com wrote:

Well, I am in a different location now, and of course using a different
ISP (here it is a wireless ISP through a shortwave radio on a 50 foot
antenna mast).
But I have not yet changed the resolvers.   Therefore, I believe I was
using

D0wn Resolver US 107.181.187.219
Secondary OpenNIC Anycast 185.121.177.53

So later today I will go into Malwarebytes and clear the whitelist.
Then I will report back here.

Thank you Jerome.  I have not seen any alarms since I removed the whitelist in Malwarebytes.  I will try a few different resolvers but I believe you have fixed it.

repo: bitbeans/SimpleDnsCrypt


text:
Async support?

As a networking-related dependency, this would be a great candidate for making it async.

As I mentioned at https://github.com/bitcoindevkit/bdk/issues/66 I guess it would also make it possible to add Tor support using arti-client.

@oleonardolima I think just make it possible to switch up any transport layer using a trait. Probably tokio::AsyncRead etc.

Good, that makes sense. I'll try to take a look at it after adding the support on rust-esplora-client

@oleonardolima FYI I hand-wrote an async client with a few methods that were required for my project. I may be able to publish it as it may serve as a starting point.

@Kixunil Cool! Thanks, that would be really helpful and a great starting point.

I just finished here thinking to trying to use arti_client with rust-electrum-client but noting that is async based while this is not.
Even some temporary hack like SyncIoBridge seems not easily applicable here, because the stream is not handled splitted (reparated Read/Write)

@RCasatta yeah, IIRC that's why I ended up writing my own and as I did I found that the whole thing is quite involved.
@oleonardolima sorry to keep you waiting this long I will try soon.

@Kixunil No worries, I'm still working on fedimint and rust-esplora-client tor support at the moment, but let me know when you do it.

It's out now: https://github.com/Kixunil/async-electrum-client

update: I'll probably start working on this during this week, using the @Kixunil work as a starting point.
Do you have any other approach in mind @RCasatta ?

Do you have any other approach in mind @RCasatta ?

No

@oleonardolima  curious, are you still actively working on this?

@jurvis I'm not currently working on this, other issues took priority, although it's still on my list. Is it a pressing issue/feature that you need?

@oleonardolima not pressing, just asking! do you have a draft branch going somewhere?

authors: Kixunil RCasatta jurvis oleonardolima

repo: bitcoindevkit/rust-electrum-client


text:
Are you sure BitcoinXT-0.11E.dmg is tagged correctly?

It's late, maybe i'm losing it, but when I try launching this i'm getting 0.11D as the version. I'll try again tomorrow as a sanity test.

i noticed when i wasn't getting any logs with debug=thin, just built from source and now working as intended. I will double check the .dmg tomorrow, probably just user error, but if someone could just double check this for me i'd feel better.

repo: bitcoinxt/bitcoinxt


text:
请问可以添加自行设置精度功能吗？

感觉1d的看起来不太爽啊。。。。。。然而我又不会C#。。只好麻烦作者大大了

check v3.0

authors: bitdust marionette-curtain

repo: bitdust/EarthLiveSharp


text:
Fix problem with ListFiles producing an unwanted Newline character when zero files are matched

In this PR I tried to fix #110
Here I take into consideration whether any files are matched at all or not and then ListFiles() only produces an output if files are matched.
To fix the issue with the ListFiles function, you would need to handle the case where the provided path argument refers to a single file instead of a directory. Currently, the function assumes that if an error occurs while reading the directory, it's because the path matches exactly one file. However, this assumption is incorrect in some cases.
In the updated code:

We use os.Stat to check whether the path argument refers to a directory or a file.
If it's a file, we return it as the output by creating a new Pipe and using Echo to set its content to the file path.
If it's a directory, we proceed with the original logic of walking through the directory and appending file paths to the matches slice.

By making these changes, the ListFiles function will correctly handle both directory and file inputs.

Hi, @MrTbag! Thanks for the contribution—it's most welcome!
I'm not sure if I'm completely clear on the problem that this is fixing—could you help me out by supplying a couple of test cases that fail without this change?

authors: MrTbag bitfield

repo: bitfield/script


text:
Network error: read ECONNRESET

I'm having some issues connecting my Grass Valley T2 to companion computers.  The current auto generated IP address of the Grass Valley is 10.20.30.200. I'm able to ping the IP address from my iMac so I know it's there and responsive. However when I go to connect the IP to my software it's generating this error. "Network error: read ECONNRESET"
I really have no idea why I can't connect. The connection point flashes OK and turns green but then triggers an error. The connection retry's about every 2 seconds and this patterns continues.
If anyone has any suggestions please let me know. I have seen almost no communiction about this so either no one is doing it or I'm the only one having the issue!

Writing back on behalf of my colleague, Nate.  The software works fine.  We had to fix 2 issues in configuration.
Our channel name for the connection was "vtr1".  This was correctly pointing to our "R1" recorder.  But on the R1 we had to make sure the "Remote" option (button) was chosen in the GUI. This allowed us to send commands to the "R1"
For our "P1" and "P2" players, we created two new connections in Companion.  One set the channel value to "vtr2" (which pointed to the "P1").  The other set the channel to "vtr3" which pointed to the "P2".  All commands then worked correctly from Companion.


text:
Fix BitDatePicker component style issue (#1842)

this closes #1842

@maryamhdr plz review

authors: msynk sajadkardel

repo: bitfoundation/bitframework


text:
Bug: eqMac froze and quite when using FaceTime and outputting through external monitor's speaker

Disclaimer:
Please go through existing issues to avoid creating duplicates. If you found a similar issue please post a comment there. If you are uncertain your issue is related to others then create the issue. Obvious ignorance of this rule might get you blocked from posting new issues. Please tick the box below to show that you have followed the guideline.

[o] I have checked for a similar issue and sure it hasn't been reported before.

Describe the bug
Specs:
M1 Mac mini
Mac OS 11.2
Using a webcam (built in mic) for FaceTime.
Using eqMac for controlling external monitor's speaker volume. However, when using eqMac with FaceTime would have following issues:

No freezing nor forced quit, but external monitor isn't outputting sound. But Mini's built-in speakers has no problem.
Seconds later, system freeze a bit and then eqMac forced quit.

Steps to Reproduce

Use external monitor as output device via eqMac
Start a FaceTime video call

Expected behaviour
External monitor speaker should work without issues
Setup information:

Audio device used for playback: Monitor EW3270U's speaker
Audio transmission interface: usb-c to usb-c (thunderbolt 3)
macOS Version: 11.2
eqMac Version 0.3.7
eqMac UI Version 1.2.2

Happened to me as well.

MacOS 11.2.3

repo: bitgapp/eqMac


text:
View/Show: Multiple receive addresses

Task description
Ability to show multiple receive addresses
Use case: say you need to get multiple invoices paid but want to avoid address reuse

https://xd.adobe.com/view/602d9858-3e03-4223-8178-b620d5c79a7a-357e/screen/81b76356-0ff5-40e5-b3dd-667d8ac7d3c4/
scroll for next screen

Closing as it was replaced by #5188

authors: ben-kaufman cakesoft-swati summikhan11

repo: bithyve/bitcoin-keeper