:sparkles: feat: support realtime synchronizer model

Codecov Report

Merging #36 (ca698a8) into main (c98df26) will decrease coverage by 1.49%.
The diff coverage is 45.28%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@             Coverage Diff              @@
##               main      #36      +/-   ##
============================================
- Coverage     75.05%   73.56%   -1.49%
- Complexity      278      286       +8
============================================
  Files            32       34       +2
  Lines           994     1044      +50
  Branches         70       72       +2
============================================
+ Hits            746      768      +22
- Misses          204      231      +27
- Partials         44       45       +1

Impacted Files
Coverage Δ

...java/com/featureprobe/sdk/server/FeatureProbe.java
60.00% <ø> (ø)

...m/featureprobe/sdk/server/PollingSynchronizer.java
62.96% <ø> (ø)

...ain/java/com/featureprobe/sdk/server/FPConfig.java
51.66% <23.07%> (-8.75%)
:arrow_down:

...in/java/com/featureprobe/sdk/server/FPContext.java
63.46% <37.50%> (-3.93%)
:arrow_down:

...featureprobe/sdk/server/StreamingSynchronizer.java
53.33% <53.33%> (ø)

...probe/sdk/server/StreamingSynchronizerFactory.java
100.00% <100.00%> (ø)


TypeError when importing from 'typescript' in file

Whenever I have imports from 'typescript' module, I get type error: TypeError: Cannot read property 'type' of null. I'm not sure if it is caused by this package or is coming from somewhere else. However, when I comment out the line 'import/resolver': { typescript: { alwaysTryTypes: true } }, in .eslintrc.js file, then the file gets properly linted.
I created a small reproduction here: https://github.com/qlonik/eslint-import-resolver-typescript-repro

The error message is as following:
TypeError: Cannot read property 'type' of null
Occurred while linting /workspace/eslint-import-resolver-typescript-repro/src.ts:1
    at /workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:569:30
    at Array.forEach (<anonymous>)
    at /workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:565:32
    at Array.forEach (<anonymous>)
    at /workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:563:19
    at Array.forEach (<anonymous>)
    at Function.ExportMap.parse (/workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:477:12)
    at Function.ExportMap.for (/workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:361:25)
    at Function.ExportMap.get (/workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/ExportMap.js:316:23)
    at processBodyStatement (/workspace/eslint-import-resolver-typescript-repro/node_modules/eslint-plugin-import/lib/rules/namespace.js:67:47)

As you can see it comes from eslint-plugin-import, and if you lock "eslint-plugin-import": "~2.18.2", it will just work.
So please post the issue to eslint-plugin-import instead, and as I know it should be an issue of parsing export {}.

Thank you for filing it upstream and resolving it with the maintainer of the upstream package. I really appreciate it :)


ol.format.GeoJSON  readFeatures() fails if GeoJSON properties contains an element named "geometry"

I found a one off case where the geometry of a FeatureCollection is also located inside the "properties" and then tried to readFeatures() but this failed.  Removing the "geometry" item in properties or renaming the item to "mygeom" resolves this issue.
var searchSource = new ol.source.Vector();
    $.ajax('someURL').then(function (response) {
        var myNewGeoJSON= new ol.format.GeoJSON();
        var featuresSearch = myNewGeoJSON.readFeatures(response,
            {featureProjection: 'EPSG:4326'});

Here is an example of a BAD GeoJSON object with "geometry" in the "properties":
{
    "features": [
        {
            "properties": {
                "name_de": "Parkgarage P1",
                "geometry": {
                        "coordinates": [
                            [
                                1826772.70728665,
                                6142252.34800361
                            ]
                        ],
                "type": "MultiPoint"
            },
            },
            "geometry": {
                "coordinates": [
                    [
                        1826772.70728665,
                        6142252.34800361
                    ]
                ],
                "type": "MultiPoint"
            },
            "type": "Feature"
        }
    ],
    "type": "FeatureCollection"
}

This behaviour is somewhat expected. The best way to get your GeoJSON working is by configuring the ol.format.GeoJSON instance with a custom geometryName:
new ol.format.GeoJSON({geometryName: 'mygeom'})

This will cause your features to have the GeoJSON geometry in the mygeom property, and the other geometry in the geometry property.


Add no-change mark to plan-preview result

What this PR does / why we need it:
Which issue(s) this PR fixes:
A part of https://github.com/pipe-cd/pipe/issues/2298
Does this PR introduce a user-facing change?:

NONE

Nice
/lgtm

🚀
/approve


Add Immutable Component Support

Objective

Fixes #16208

Solution

Added an associated type to Component, Mutability, which flags whether a component is mutable, or immutable. If Mutability= Mutable, the component is mutable. If Mutability= Immutable, the component is immutable.
Updated derive_component to default to mutable unless an #[component(immutable)] attribute is added.
Updated ReflectComponent to check if a component is mutable and, if not, panic when attempting to mutate.

Testing

CI
immutable_components example.

Showcase
Users can now mark a component as #[component(immutable)] to prevent safe mutation of a component while it is attached to an entity:
#[derive(Component)]
#[component(immutable)]
struct Foo {
    // ...
}

This prevents creating an exclusive reference to the component while it is attached to an entity. This is particularly powerful when combined with component hooks, as you can now fully track a component's value, ensuring whatever invariants you desire are upheld. Before this would be done my making a component private, and manually creating a QueryData implementation which only permitted read access.

Using immutable components as an index
/// This is an example of a component like [`Name`](bevy::prelude::Name), but immutable.
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash, Component)]
#[component(
    immutable,
    on_insert = on_insert_name,
    on_replace = on_replace_name,
)]
pub struct Name(pub &'static str);

/// This index allows for O(1) lookups of an [`Entity`] by its [`Name`].
#[derive(Resource, Default)]
struct NameIndex {
    name_to_entity: HashMap<Name, Entity>,
}

impl NameIndex {
    fn get_entity(&self, name: &'static str) -> Option<Entity> {
        self.name_to_entity.get(&Name(name)).copied()
    }
}

fn on_insert_name(mut world: DeferredWorld<'_>, entity: Entity, _component: ComponentId) {
    let Some(&name) = world.entity(entity).get::<Name>() else {
        unreachable!()
    };
    let Some(mut index) = world.get_resource_mut::<NameIndex>() else {
        return;
    };

    index.name_to_entity.insert(name, entity);
}

fn on_replace_name(mut world: DeferredWorld<'_>, entity: Entity, _component: ComponentId) {
    let Some(&name) = world.entity(entity).get::<Name>() else {
        unreachable!()
    };
    let Some(mut index) = world.get_resource_mut::<NameIndex>() else {
        return;
    };

    index.name_to_entity.remove(&name);
}

// Setup our name index
world.init_resource::<NameIndex>();

// Spawn some entities!
let alyssa = world.spawn(Name("Alyssa")).id();
let javier = world.spawn(Name("Javier")).id();

// Check our index
let index = world.resource::<NameIndex>();

assert_eq!(index.get_entity("Alyssa"), Some(alyssa));
assert_eq!(index.get_entity("Javier"), Some(javier));

// Changing the name of an entity is also fully capture by our index
world.entity_mut(javier).insert(Name("Steven"));

// Javier changed their name to Steven
let steven = javier;

// Check our index
let index = world.resource::<NameIndex>();

assert_eq!(index.get_entity("Javier"), None);
assert_eq!(index.get_entity("Steven"), Some(steven));

Additionally, users can use Component<Mutability = ...> in trait bounds to enforce that a component is mutable or is immutable. When using Component as a trait bound without specifying Mutability, any component is applicable. However, methods which only work on mutable or immutable components are unavailable, since the compiler must be pessimistic about the type.
Migration Guide

When implementing Component manually, you must now provide a type for Mutability. The type Mutable provides equivalent behaviour to earlier versions of Component:

impl Component for Foo {
    type Mutability = Mutable;
    // ...
}

When working with generic components, you may need to specify that your generic parameter implements Component<Mutability = Mutable> rather than Component if you require mutable access to said component.
The entity entry API has had to have some changes made to minimise friction when working with immutable components. Methods which previously returned a Mut<T> will now typically return an OccupiedEntry<T> instead, requiring you to add an into_mut() to get the Mut<T> item again.

Notes

I've done my best to implement this feature, but I'm not happy with how reflection has turned out. If any reflection SMEs know a way to improve this situation I'd greatly appreciate it. There is an outstanding issue around the fallibility of mutable methods on ReflectComponent, but the DX is largely unchanged from main now.
I've attempted to prevent all safe mutable access to a component that does not implement Component<Mutability = Mutable>, but there may still be some methods I have missed. Please indicate so and I will address them, as they are bugs.
Unsafe is an escape hatch I am not attempting to prevent. Whatever you do with unsafe is between you and your compiler.
I am marking this PR as ready, but I suspect it will undergo fairly major revisions based on SME feedback.
I've marked this PR as Uncontroversial based on the feature, not the implementation.

The behavior of implementing Component before this change and the behavior of implementing  Component + ComponentMut after this change should be identical. Do I understand that correctly?

Yes a pre-this-PR Component is identical to a this-PR Component + ComponentMut. Component contains all the implementation details it had previously, but now only implies an immutable type. Mutability is now explicitly stated by implementing ComponentMut. But for the derive macro, Component + ComponentMut are implemented by default (since that is the most typical use-case). To opt-out of mutability in the derive macro, you add #[immutable].

Small nit: I would prefer #[component(immutable)] to keep all component attributes together. It also follows #[world_query(mutable)].

Of note, FilteredEntityMut::get_mut_by_id is (so far) the only safe method I have found that can bypass immutable components. I did want to add the immutable flag to ComponentDescriptor, but propagating that information proved very challenging. If anyone has a suggestion for how to integrate ComponentMut and ComponentDescriptor in the least impactful way I would be greatly appreciative.

Why do you prefer the ComponentMut: Component design over a Mutable + Component design? I have a mild preference for the latter because I think it'll be easier to extend to resources.

Don't have time to look over this fully, but I like this. I also prefer the version without the trait bound on component.
Just so I am sure this can be used as I want, if we make parent/children immutable, how do we preserve the existing hierarchy commands api? Will we use unsafe within the commands to get mutable access, or go properly immutable with only clones and inserts?

Just so I am sure this can be used as I want, if we make parent/children immutable, how do we preserve the existing hierarchy commands api? Will we use unsafe within the commands to get mutable access, or go properly immutable with only clones and inserts?

I was wondering if it would make sense to have mutable component access require a key type. Then crates could keep that type private to simulate immutability while still being able to mutate the component themselves.
Not sure if that's possible and I don't know how well it fits with this approach, but possibly an option (though I’m going to guess far more complex and involved).

or go properly immutable with only clones and inserts

It would be this. Either through Parent's on insert hook or a command.

We'll have to make Children immutable too, won't we? That will mean some extra vec cloning, so might want to look at an immutable vector impl. But I'm content with that answer. We can deal with the costs if it turns out to be a problem.

Why do you prefer the ComponentMut: Component design over a Mutable + Component design? I have a mild preference for the latter because I think it'll be easier to extend to resources.

The three reasons for me were:

With reflection, we'd need a name for the trait that represents the mutable trait methods, and I'm not sure if we can do ReflectComponentMutable
For updating where conditions it was slightly cleaner to write ComponentMut than Component + Mutable
When we do extend this to resources, we'd have to use a separate trait anyway, because there are types that implement both Resource and Component, which would create a conflict on the common Mutable

It's probably fine to keep this component-only for now, considering that relations don't currently support hooks (so the applications are pretty minimal).

We'll have to make Children immutable too, won't we? That will mean some extra vec cloning, so might want to look at an immutable vector impl. But I'm content with that answer. We can deal with the costs if it turns out to be a problem.

This shouldn't be required. The data is only immutable while it is stored on the entity, so remove/mutate/insert can be used to avoid any cloning. If that pattern is cumbersome we could add a component_scope method like resource_scope, except with ownership of the component.

This shouldn't be required. The data is only immutable while it is stored on the entity, so remove/mutate/insert can be used to avoid any cloning. If that pattern is cumbersome we could add a component_scope method like resource_scope, except with ownership of the component.

Wouldn't this create unnecessary archetype moves? I feel like cloning is probably faster. But that's getting off topic.

You could even do a mutate_via_reinsertion API, which could work on immutable components. Very clean, and no archetype moves. Easy followup though.

What happens if you ask for a &mut C on an immutable C in a system? Is it the compile error where your function doesn't implement system?

Compiler error. The QueryData implementation is not provided for immutable components.

There's some discussion on Discord around the name immutable. These components are mutable, but only when outside of the ECS. Once stored on an entity they become immutable. To clarify this, an alternative name is being bikeshedded. My personal preference is for frozen, as that has the same implications as immutable, with the added possibility of "thawing" (remove to mutate)

For posterity, frozen gets my vote as well, but "restricted components" is a safe fallback.

I'd love if there was a trait like ComponentNonMut. bevy_mod_index would want to use that as a bound for components that can be reliability tracked with hooks now that mutations can be prevented.

We could maybe add an unsafe trait ComponentNonMut: Component { } to cover that usecase. We would then have to make ComponentMut unsafe too, since they're mutually exclusive. The derive macro could hide these details tho.

Unfortunately Rust's trait system doesn't play very nice with that sort of negative bound. If we had both MutableComponent and ImmutableComponent as traits, there's nothing stopping users from implementing both. I agree that both forms would be useful though.
Would an associated type work here?
impl <C: Component<Mutable=true>> Index {} seems pretty workable, and I don't think it's much worse / less clear than the current design. It would also bypass the nasty reflection problems of the current approach.

Using an associated type on Component allows resolving the reflection DX issues previously introduced by this PR. Additionally, we can now offer a marker trait ComponentImmutable which is effectively !ComponentMut.

After further iteration, the ComponentMut and ComponentImmutable traits have been removed, opting instead for matching against the associated type Mutability.
/// Work with a component, regardless of its mutability
fn get_component<C: Component>(/* ... */) { /* ... */ }

/// _Only_ allow mutable components
fn get_component_mut<C: Component<Mutability = Mutable>>(/* ... */) { /* ... */ }

/// _Only_ allow immutable components
fn get_component_immutable<C: Component<Mutability = Immutable>>(/* ... */) { /* ... */ }

I think that my only remaining major request is that this has a test suite for dynamic components. Once that's done I'll do a final polish pass on this at the start of 0.16.

I really like how this PR is turning out. I'm a fan of the associated type idea.

As an aside, I added #[component(immutable)] to Name to see if anything broke, and to my pleasant surprise it just worked without any knock-on effects. Bevy already treats Name as some immutable data, so making it "official" is a 1-line PR once this is merged. I haven't included that in this PR just to keep the scope as small as it can be.

The associated trait magic with sealed logic types is very cute, I like it. Is the issue with FilteredEntityMut::get_mut_by_id resolved or still outstanding?

Thanks! And yes that issue is resolved. The move to an associated type made enough information available on Component for me to have immutability be a bool on ComponentDescriptor.


Export-Excel columns positioning issue

Hello,
i would like to use the Export-Excel function to fill a custom Excel file, but i have some problems with the columns positioning in the output file.
The attached "example.xlsx" is an example of my starting file, for which i cannot modify the structure. The original file I need to fill, would be a xlsm file with some macros and much more columns (162), but the end result is the same.
The column headers i need to reference are the ones on row 5
What i would like to do is appending data to the Excel file starting from row 6
I'm trying to use some sample code like this:
$excelOutput = [PSCustomObject][Ordered]@{
    Header_1  = 'String1'
    Header_2  = 'String2'
    Header_4  = 'String3'
    Header_6  = 'String4'
    Header_8  = 'String5'
    Header_10 = 'String6'
} | Export-Excel "<path_to_excel_file>" -Append -WorksheetName 'MySheet' -StartRow 6

If I execute this, i would expect to find my data on row 6, under the correct column headers.
Instead my data is (correctly) on row 6, but moved to the right exactly 2x the number of column headers, so 20 columns to the right in this case (see attached file "example_output.xlsx", data is on row 6, starting from column AE)
I also tried to play with -StartRow 5, -StartRow 6 and the -NoHeader attributes, but the end result is always similar.
If i remove rows 1 to 4 from the Excel file, leaving only the column headers, my sample script (without -StartRow 6 of course) is working as expected.
I also have another custom Excel file with a similar structure, for which i get the same result.
I'm using version 7.4.1 of the ImportExcel module.
Am I doing something wrong or is this a bug within the module?
Thanks.
example.xlsx
example_output.xlsx

Please could you post a small PS script that repos this

Please could you post a small PS script that repos this

the PS command I'm using is in my first message. If you use that command with the excel file i provided (example.xlsx), you should be able to reproduce the issue.
The only difference with my script is that i have some variables for some of the values, but the problem occurs even with plain strings like in my example

The -Append works based on the dimensions of the sheet. My guess is the button does not factor into the # of rows.
Start with a simpler worksheet, just headers at in row 1, and then experiment from there.

The problem is not the first row with the button.
The problem is that the data appended to the excel file is shifted to the right by several columns (see the attached "example_output.xlsx"), exactly 2x the number of columns, which i find it quite suspicious.
It seems to me that the different rows with different headers are messing with your module, causing it to misbehave.
I also cannot modify the worksheet since it's a template used in my company for some compliance process

Don't know. The data did not to the right when I ran it.
You can always use Open-ExcelPackage & Close-ExcelPackage, and place the data exactly where you need it. Finer grained control, and more work for you.


app.js not found after deploying

Project works fine locally but after deploying on server i get
Not Found

The requested URL /vendor/wink/app.js was not found on this server.

server can't also see /vendor/wink/light.css
any solution ?

It works after changing in views/layout.php
{{mix('app.js', 'vendor/wink')}}

to
{{ url('vendor/wink/app.js') }}


contracts: allow muliparty challenges

fixes: #569
Currently the agent will try to challenge any claim where the claimer is leading and not honest. I haven't found a useful if condition to check the non-fill condition we discussed.
Still Todo

Check docs for update

Note, that it is not possible anymore, that any address can call withdraw in the case that the challengers win. This is due to that the challengers will withdraw their own partial stake.
We should think about exposing a functionality in the contract where anybody can call withdraw on behalf of an address. But I leave that for another PR.

Gas profile difference:
                                    /tmp/before │ /tmp/after   │ difference │
FillManager
   ├─ constructor            - avg:     813,250      813,247           -3
   ├─ fillRequest            - avg:      93,686       93,683           -3
   ├─ invalidateFillHash     - avg:      48,684       48,684            0
   ├─ addAllowedLP           - avg:      44,221       44,236          +15
   └─ removeAllowedLP        - avg:      20,119       20,119            0
MintableToken
   ├─ constructor            - avg:     694,990      694,990            0
   ├─ mint                   - avg:      50,688       50,685           -3
   └─ approve                - avg:      43,661       43,688          +27
OptimismProofSubmitter
   ├─ constructor            - avg:     550,890      550,895           +5
   ├─ addCaller              - avg:      44,798       44,795           -3
   └─ submitProof            - avg:      24,020       24,020            0
RequestManager
   ├─ constructor            - avg:   1,988,923    2,032,740      +43,817
   ├─ createRequest          - avg:     212,149      212,232          +83
   ├─ claimRequest           - avg:     137,768      139,570       +1,802
   ├─ withdraw               - avg:      69,493       63,759       -5,734
   ├─ withdrawExpiredRequest - avg:      57,663       57,663            0
   ├─ challengeClaim         - avg:      57,405       61,512       +4,107
   ├─ setFinalizationTime    - avg:      42,602       42,602            0
   ├─ withdrawbeamerFees     - avg:      22,403       22,403            0
   └─ updateFeeData          - avg:      17,063       16,992          -71
ResolutionRegistry
   ├─ constructor            - avg:     546,165      546,165            0
   ├─ addCaller              - avg:      65,111       65,114           +3
   ├─ resolveRequest         - avg:      37,053       37,059           +6
   └─ invalidateFillHash     - avg:      22,839       22,839            0
Resolver
   ├─ constructor            - avg:     698,931      698,931            0
   ├─ addCaller              - avg:      65,134       65,136           +2
   ├─ addRegistry            - avg:      65,124       65,128           +4
   ├─ resolve                - avg:      23,468       23,468            0
   └─ resolveNonFill         - avg:      22,964       22,964            0
TestCrossDomainMessenger
   ├─ constructor            - avg:     237,338      237,338            0
   ├─ setLastSender          - avg:      42,635       42,635            0
   └─ setForwardState        - avg:      25,705       25,569         -136

still to be changed

the challenger dictionary
the require withdrawnAmount

I would really prefer if commit 8b201f83bb2537303add8a73a791f55909cd8f8a (contracts: allow muliparty challenges) were split up so that

the contract changes are in their own separate commit, as the commit message already indicates
the agent changes are in their own separate commit
the tests are in their own separate commit

Not only would that have made the review a bit easier, but also it would be helpful for future debugging and history inspection.

I would really prefer if commit 8b201f8 (contracts: allow muliparty challenges) were split up so that

the contract changes are in their own separate commit, as the commit message already indicates
the agent changes are in their own separate commit (ecdb9da looks like it would be perfect for squashing into that commit)
the tests are in their own separate commit

Not only would that have made the review a bit easier, but also it would be helpful for future debugging and history inspection.

I'm sorry but I really see that commits are split exactly how you describe it. The only changes in tests or in the agent are adaptions "the interface of the contract" namely the event variable names. I really doubt that future debugging would be improved by separating that into different commits. But we can disagree on this.

the agent changes are in their own separate commit (ecdb9da looks like it would be perfect for squashing into that commit)

Also this is really not perfect to squash it together. Adapting the interface and adaptaing to a new feature is somthing completely different.


Explain risks of disabling Safe Browsing

It seems that you disabled Google Safe Browsing, and I understand why people might want to do that. However, it's already designed with privacy protection in mind: it uses a local bloom filter to determine whether a URL might be dangerous, and only asks the servers if the bloom filter says "maybe". Even then, only hashes of the URL are transmitted whenever possible. This way, it leaks very little information, but provides good security benefits. Most users should probably have it enabled.
There's a good explanation at https://github.com/amq/firefox-debloat/issues/3

only asks the servers
Considering the aim of this project, I can see why its disabled.
The main principle of this browser is that it will block any kind of connection to Google. As it is with other Google services, you'll lose a bit of convenience by not using them.

I think its likely that most users of ungoogled-chromium are also using add-ons like uBlock Origin, which already provides blocklists for malware domains.

Well, who is the public of ungoogle-chromium? Phishing sites are designed to deceive, and they deceive power users, too. Safe Browsing also blocks sites serving malicious content (like exploit kits, where you don't even have to click anything to get infected). Isn't the privacy and information security impact of a malware infection worse than sending a few hashes of partial URLs to Google?

The main principle of this project is that it will block any kind of connection to Google. As it is with other Google services, you'll lose a bit of convenience by not using them.
If it were only convenience you lost, then I wouldn't have filed this issue. This has a direct security impact on your users, and you're exposing them to risks without explaining what they are. I'm merely asking you to explain these risks, to make sure that users know what to expect.
Adblockers don't update often enough to provide the same level of protection, and if you're not preinstalling one, then you can't expect everyone to have one.

Well, who is the public of ungoogle-chromium?

@Eloston should respond this one, but IMO the average user of ungoogled-chromium are power users who actively filter their browsing with extensions (such as uBlock Origin and uMatrix). They rather use a Chromium-based browser instead of Firefox or one of its forks because its way more responsive.

Phishing sites are designed to deceive, and they deceive power users, too. Safe Browsing also blocks sites serving malicious content (like exploit kits, where you don't even have to click anything to get infected).

I've yet to see someone using uBlock Origin and/or uMatrix to get infected through phishing sites. Based on what you say "they deceive power users"? As anecdotal as it its, I've yet to see a normal, tech-illiterate user get infected with a proper adblock being installed.

If it were only convenience you lost, then I wouldn't have filed this issue. This has a direct security impact on your users, and you're exposing them to risks without explaining what they are. I'm merely asking you to explain these risks, to make sure that users know what to expect.

I agree with you in this instance. Having a page explaining how safe browsing works would have no harm.

Adblockers don't update often enough to provide the same level of protection, and if you're not preinstalling one, then you can't expect everyone to have one.
Source on this? What adblock are you using? uBlock Origin's default lists are updated almost every day.

Also, you're right in the sense that I cannot prove everyone using ungoogled-chromium is also using an Adblock. But I also highly doubt they aren't.

Well, who is the public of ungoogle-chromium?

@9Morello pretty much got it. Users who understand the benefits of this project must already have a deeper understanding of the web and web browsers than an average internet surfer. These users are probably doing things to reduce their risk of being attacked, whether it be install extensions like uBlock Origin or disable plugins like Flash or Java. They could even run certain web applications within a VM when they need these features.
I'll add a section to the FAQ and README to inform users about the safe browsing situation.

Thank you! I think this is helpful.


[TB] Week of Mar 8

[ ] Investigate why travel distance is zero for all transit modes.

Deliverable: Pushed markdown file noting the data issue (and reason if found) for future users of the data.
Estimated: 3 hours.
Actual:

[ ] Review Amine's revised distribution fitting code based on long-format data

Deliverable: Comments on the updated PR (#44)
Estimated: 2 hr.
Actual:

[ ] Review Hassan's code to simulate data for a single, latently confounded utility equation.

Estimated: 2 hr.
Actual:

[ ] Weekly meeting.

Estimated: 2 hr.
Actual:

@timothyb0912 I just wanted to check in with you about the status of task one in your list. Any luck?

@bouzaghrane I have not looked a single second at it. It's my midweek task, so I'll have it done by tomorrow morning and tag you on it.


Linter + Formatter Fontend

We need a formatter and linter and maybe even configs etc. in the frontend

Linter: ESLint
Autoformatter: Prettier

We'll use a prettier-eslint config to make them play nice with eachother/


Fixing deprecations in notdatadog service

This is to remove two modules that will be deprecated in Python 3.12: smptd and asyncore.
asyncio is the recommended replacement for asyncore. I tried implementing a UDP server using just asyncio, but it would crash after working for a while, and I really wasn't sure if I was using the library correctly. So I broke down and introduced a dependency on asyncudp. This is a pretty small library really only maintained by 1 person. I think this is fine for a library that's only installed in development, but if you disagree, let me know, and I can rework this PR to not use it.
With these changes, these are some example logs from the notdatadog container (when METRICS_OUTPUT='true'):
warehouse.2fa.total_users_with_totp_enabled:0|g
warehouse.2fa.total_users_with_webauthn_enabled:0|g
warehouse.2fa.total_users_with_two_factor_enabled:0|g
warehouse.task.complete:1|c|#task:warehouse.packaging.tasks.compute_2fa_metrics
warehouse.task.run:36|ms|#task:warehouse.packaging.tasks.compute_2fa_metrics
warehouse.db.session.finished:1|c
pyramid.request.duration.route_match:0.134033203125|ms
pyramid.request.duration.traversal:1.874267578125|ms
warehouse.db.session.start:1|c
pyramid.request.duration.view:6.902587890625|ms|#route:admin.sponsor.list
pyramid.view.duration:23|ms|#route:admin.sponsor.list,view:warehouse.admin.views.sponsors.sponsor_list
pyramid.request.duration.template_render:32.0166015625|ms|#route:admin.sponsor.list
pyramid.request.duration.total:40.794921875|ms|#route:admin.sponsor.list,status_code:200,status_type:2xx
warehouse.db.session.finished:1|c
pyramid.request.duration.route_match:0.199951171875|ms
pyramid.request.duration.traversal:0.9560546875|ms

Closes https://github.com/pypi/warehouse/issues/12779

Grrr, git is not playing nice with me. I'll re-open this PR tomorrow.

Created https://github.com/pypi/warehouse/pull/12821 to replace this one.


[Search v2] [App] Create search results page

Details

This PR adjusts the header of the Search page to display the custom query. The header displays the user's query when the route param isCustomQuery is set to true. This PR covers also adding the Filters button to the header.
Fixed Issues

$ https://github.com/Expensify/App/issues/45028
PROPOSAL:
Tests

[ ] Verify that no errors appear in the JS console

Navigate to the url with the isCustomQuery route param set to true, for example: https://dev.new.expensify.com:8082/search?q=type%3Aexpense status%3Aall&isCustomQuery=true
Verify if the header is displayed correctly

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

https://github.com/user-attachments/assets/8b8ca54d-cb4e-4182-ac24-fa239e5a0b80

Android: mWeb Chrome

https://github.com/user-attachments/assets/263e1041-6735-43a8-a65c-66863dcc4eb4

iOS: Native

https://github.com/user-attachments/assets/c47b46e5-e7ab-47a1-9e53-677f1f00b79c

iOS: mWeb Safari

https://github.com/user-attachments/assets/bc9501c4-e10e-42ef-84d3-4783b2fa00e3

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/f6583d16-dd75-41df-b5e4-7be97c808d4e

MacOS: Desktop

https://github.com/user-attachments/assets/70bc34c8-4382-4ca9-ab3e-3bb6454db198

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@WojtekBoman 👋 Hi, I noticed some discrepancies while reviewing the PR ⬇
Tests state:

Navigate to the url with the isCustomQuery route param set to true, for example: https://dev.new.expensify.com:8082/search?q=type%3Aexpense status%3Aall&isCustomQuery=true
Verify if the header is displayed correctly

While (1.) works as expected functionaloty-wise, when it comes to (2.) -> I found some UI related discrepancies (cc @Expensify/design) when compared to the design doc which I think are within scope for this PR (correct me if I'm wrong):

[ ] 1. Wide Layout - Filter labels are lowercase and missing spaces
Note: This can only be seen on wide layout (Web / Desktop).

Design Doc
PR
PR - Narrow layout (correct)

[ ] 2. Narrow Layout - Incorrect filter dropdown icon color and padding between icons and text
Note: This can only be seen on narrow layout (mWeb / Native).

Design Doc
PR
------ Current Staging ------ (incorrect as well)

[ ] 3. Narrow Layout - Filter button icon not centered on native app
Note: This can only be seen on narrow layout and only on iOS & Android: Native. Click on pictures below to get zoomed-in version.

Design Doc
PR - iOS
PR - Android

[x] 4. Narrow Layout - Filter dropdown opens search selection modal (this one is probably NAB but I wanted to bring this up because I wasn't sure)
Note: This can only be seen on narrow layout.

Video
https://github.com/user-attachments/assets/cda3ffab-4aeb-45dd-bdd7-1c293d4a981d

Is ^ this supposed to work this way ? Asking since it makes sense to have the small Filters button on the right side which opens the Filters page, but clicking the wider filter select dropdown button -> I'd expect to open the Filters page and not the Search page selection modal as this select dropdown button normally does:

♻ Once the above discrepancies are addressed / resolved, I will be able to complete the reviewer checklist and Approve.
cc @luacmartins

@ikevin127
Regarding the first point, I relied on these designs from figma: https://www.figma.com/design/YHaWaw3F0PgxqI0tXHJVeY/Search-v1-v3?node-id=3942-24214&t=192BImUkKvmas9Ks-0

cc: @shawnborton
I'll take a look at the rest of your comments 🫡

But taking these in turn...

Filter labels are lowercase and missing spaces

What do you think @luacmartins?

Incorrect filter dropdown icon color and padding between icons and text

Given that the app currently does not use a green icon for this, maybe we can ignore this for now:

Narrow Layout - Filter button icon not centered on native app

Yeah, we should have a specific component that is for buttons that do not have any labels and just have an icon. Let's make sure we're using that here.

Narrow Layout - Filter dropdown opens search selection modal (this one is probably NAB but I wanted to bring this up because I wasn't sure)

That looks correct to me.

highlight the current page that is selected in the bottom sheet

What would the "current page" mean in that instance, @shawnborton ?
Also, I'm not sure if it's been reported, but the bottom sheet is missing the scrim/overlay:

Here's a partial mock with scrim/overlay:

What would the "current page" mean in that instance, @shawnborton ?

Basically this mock here where we add the current filtered view as an item in the Search navigation bottom sheet:

What would the "current page" mean in that instance, @shawnborton ?

Basically this mock here where we add the current filtered view as an item in the Search navigation bottom sheet:

I understand that this button should close the modal when we tap it, right?

I'm not quite following - do you mind rephrasing?

Ah okay cool, thanks for clarifying and yes, what you are showing above looks correct to me. It would just close out the modal.

Also one thing I noticed... it looks like the button isn't wide enough to match the content below it, I bet that's just some leftover margin you were using when the filter button is present:

Also one thing I noticed... it looks like the button isn't wide enough to match the content below it, I bet that's just some leftover margin you were using when the filter button is present:

Good catch! Thanks for noticing that, I'll fix that :)

Looking good. Left a few comments
BUG: Other filters don't show up in the supertitle. For example, manually changing the URL to /search?q=type%3Aexpense%20status%3Aall%20category%3AUncategorized&isCustomQuery=true still shows the canned search, instead of type:expense status:all category:Uncategorized

@luacmartins I've solved this issue, but another one appeared. For now I use regex to remove sortOrder and sortBy from the input, but with that solution the header text is lowercase, I could capitalize this text by splitting the text by an empty space but it will lead to issues when we have a two words value of the param. To me, we should loop through the AST tree and parse the values stored there to the capitalized text. I'll try to take a look at it tomorrow, if it's urgent to merge this PR, can we create a follow-up?

Filter labels are lowercase and missing spaces

What do you think @luacmartins?

IMO we should leave the query unaltered, i.e. with lowercase keys and no commas between them, e.g. type:expense status:all category:travel. This is what users will be typing into the search bar input later on, so changing this input might educate them to use the wrong syntax later on.

To me, we should loop through the AST tree and parse the values stored there to the capitalized text.

We should use SearchUtils.getFilters and pick only the filters that are needed, i.e. everything in SYNTAX_FILTER_KEYS and type and status in SYNTAX_ROOT_KEYS https://github.com/Expensify/App/blob/410a6f21524ddc1a4f85fbf9f922c6bc21d7e502/src/CONST.ts#L5289-L5310

Also, I'm not sure if it's been reported, but the bottom sheet is missing the scrim/overlay:

@dubielzyk-expensify That's only happening on local dev due to StrictMode, I debunked it in https://github.com/Expensify/App/pull/46096#issuecomment-2252097059.

I've prepared a more complex query to test how it would work:
type:expense status:all category:Uncategorized,Categorized category!=wrongCategory,wrongCategory2 amount>200 amount<1000 date>02-05-2020 date<04-05-2022
@shawnborton Could you take a look if it looks good or if something needs to be improved?

@ikevin127 All comments have been resolved :) Could you recheck it?

@WojtekBoman we have conflicts 😞 Otherwise, looks good to be merged

@luacmartins Solved :)

@WojtekBoman :hero:

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/luacmartins in version: 9.0.15-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/roryabraham in version: 9.0.15-9 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add Russian translation maintainers

Hi everyone,
I wanted to take part in the translation documentation into Russian.
I have some experience of translation experience. I participated in translation of the official PHP documentation, various books and articles. As for React, this is a translation:

The Road to learn React book
Partial translation of React documentation (repo - https://github.com/js-ru/react-ru)
Two tutorial repositories, react-from-zero and react-developer-roadmap

Therefore, I would like to have an official Russian translation of React documentation in near future.
As a maintainer, I indicated  tentatively @gaearon, because, as I understand it, he is interested in Russian translation (I hope this is still the case), as well as two people who have stated their desire to participate in the translation, @another-guy and @Heegiiny. I don't know them, but I expect that they will write in this PR to confirm their involvement.

Yeah, I want to participate. My translation experience is not so wide, but I translated some technical guides and used react in my projects.

I won’t have time to dedicate full effort to maintaining the translation myself but I’d like to be involved in early stages (to review first couple of pages and set the tone/principles for the doc).

@tesseralis Leaving for you to merge

@lex111 @tesseralis I do confirm I'm willing to help with translation.
Since this is going to be my first real open-source contribution, I can pick up any task where I'm helpful. I assume that an existing React repo member will define the body of work and the priorities.

@lex111 I've created a repo for you! You should have received an invite to join the react organization. Happy translating :)

@tesseralis thank you! :100:


Fix datetime decoding when time units are 'days since 0000-01-01 00:00:00'

This fixes #521 using the workaround described in Unidata/netcdf4-python#442.

Sorry, this branch history is too messy. Forget it, starting over.


[Delivers #133061925] Rabbit v2

RabbitMQ express plugin
RabbitMQ interface (facade) version 2

publish - enable exchange publishing
sendToQueue - enable direct to queue publishing

RabbitMQ connection pool

Current coverage is 95.93% (diff: 100%)

Merging #17 into master will increase coverage by 2.46%

@@             master        #17   diff @@
==========================================
  Files             4          8     +4
  Lines           153        172    +19
  Methods           3          5     +2
  Messages          0          0
  Branches         15         11     -4
==========================================
+ Hits            143        165    +22
+ Misses           10          7     -3
  Partials          0          0

Powered by Codecov. Last update 2ddfcc9...9bf99e7

:shipit:


Improve docs around fetch content and rapids-cmake overrides

Description
Improves documentation for rapid-cmake cpm override to explicitly state that it will override FetchContent
Checklist

[x] I am familiar with the Contributing Guidelines.
[x] The documentation is up to date with these changes.

/merge


Update City texture when buildings are build or size increases

[ ] show districts (as placeholders / areas)
[ ] show wonders / buildings
[ ] show some houses (based on city size)


Remove flakiness of the writeLargeFile test

This test writes to 100% of the worker capacity, but the reserver does not allow 100% utilization. The async reserver sometimes evicts blocks, which causes problems with this test.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/5614/
Test PASSed.

alluxio-bot, merge this please


install androguard on windows

How to install and run androguard on windows

i read this

Use pre-built executables (Windows only). Get the Microsoft Visual C++ 2008
Redistributable Package, and download pre-built executables: currently, only
androsim.exe is pre-built.

and i can't install it

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 6 Jan 2014 at 12:42

Can any one give me installation of androguard steps.


Improve the responsiveness of hero section

The website looks weird when viewed on a mobile device. I would love to make it's hero section responsive.

Are you working on it?

Yeah, sorry I had my exams so got caught up in that but working on this now.

Yeah, sorry I had my exams so got caught up in that but working on this now.

Sure!
Take your time.

Hey @AyushSarode, I was working on making the hero section responsive but there's no way for me to actually do it without significantly restructuring the HTML and CSS. This will essentially mean rewriting the whole section again and I don't think I can do it. So please assign this to someone else.

Sorry, I closed this issue by mistake.


Design System > Component > Create new component for Transfer List and Aspect ratio

Design System > Component > Create new component for Transfer List and Aspect ratio
Design link : https://v4.mui.com/components/transfer-list/#transfer-list

https://ui.shadcn.com/docs/components/aspect-ratio
Aspect ratio functionality to be added on any storybook component that has an image : Carousel, and illustration.
Do check the other components if I have missed any and add the aspect ratio functionality on it.

Fixed on stage


Adding e2e test coverage

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[x] Other: adding test coverage

What is the current behavior?
Currently this extension has a set of simple unit tests. Unfortunately there is no assurance that the functionality works across operating systems. Also the tests are run within Travis which has been ceased.
What is the new behavior?
This patch adds a simple e2e test to ensure that the server starts and a browser is able to connect and receive files. It also moves the test execution to GitHub Action.
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information
I am the maintainer of WebdriverIO and recently started building VSCode extensions, e.g. Marquee. I've experienced that there wasn't good tooling for e2e test scenarios that are sometimes needed for complex extensions like yours.

@ritwickdey any comments?


Handle origin modules (Rpc Version 1.0 & Protocol Version 1.0)

Fixes #1051
This PR is ready for review.
Risk
This PR makes no API changes.
Summary

See Bug Fixes

Changelog
Bug Fixes

Fixed issue in TransportManager that had unreachable code by overriding the previous method of receiving Legacy mode notifications
Fix issue where the RAI was being sent with max version of RPC sepc the lib could handle, but modules will only accept 1.0.0
Added format method calls to two RPCs that have mandatory parameters but v1.0 of the RPC spec didn't have the params

CLA

[x] I have signed the CLA

Codecov Report

Merging #1054 into hotfix/4.8.1 will decrease coverage by 0.02%.
The diff coverage is 0%.

@@                Coverage Diff                 @@
##             hotfix/4.8.1    #1054      +/-   ##
==================================================
- Coverage           45.77%   45.75%   -0.03%
  Complexity           3682     3682
==================================================
  Files                 433      433
  Lines               20212    20224      +12
  Branches             2177     2180       +3
==================================================
  Hits                 9253     9253
- Misses              10496    10508      +12
  Partials              463      463

Impacted Files
Coverage Δ
Complexity Δ

...smartdevicelink/proxy/rpc/DisplayCapabilities.java
73.91% <0%> (-7.04%)
20 <0> (ø)

...n/java/com/smartdevicelink/proxy/SdlProxyBase.java
6.46% <0%> (-0.01%)
16 <0> (ø)

...rtdevicelink/proxy/rpc/SoftButtonCapabilities.java
76% <0%> (-14.48%)
10 <0> (ø)

Continue to review full report at Codecov.

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


Fixes #29

Let me fix the version problem causing lint failure in another branch and then merge it here.

Let's merge #35 first and then I'll resolve conflicts and merge this one as well.


It's strange, with 840000 lora is still black picture, is it my computer which piece of the setting problem

Diagnostics-1715051942.log

@nullquant

I've realized that my default Vincennes chart is black as well，haha

Diagnostics-1715062183.log
@nullquant

I added a dtype switch to BrushNet loader. Try to change it to different values.

ok,thank you


[Discovery] Support Spark SQL "VERSION AS OF ..." / "TIMESTAMP AS OF" in tables

Spark SQL added support for VERSION AS OF 1 / TIMESTAMP AS OF '2023-08-01 13:42 sometime around 3.3.  Delta Lake is listed as the use-case for this, but a comment there claims Iceberg also works.
Can we support this syntax?  Can we use it to support more general ref expressions?

@ozkatz FYI


Fix crash for 'Add volume' modal dialog

📝 Description
missing optional chaining operator causing the 'Add volume' modal dialog to crash
🎥 Demo

Please add a video or an image of the behavior/changes

/lgtm


Figure out nice way to include references

Right now they will render as they do in the tex - like [@ref] and ideally we would have a nicer way to do this.

Done!


auto-(dis)assemble from various tools using spirv-dis/as

As this isn't exactly an "issue", please feel free to delete if it's a breach of protocol.  I wasn't sure where else to put it, and I thought these might be handy for some people using SPIRV-Tools.
To allow the "less" pager (under *nix, BSD, and possibly cygwin) to transparently invoke spirv-dis on SPIRV binary files:
Place a script like this somewhere handy, and make it executable (chmod +x):
#!/bin/bash

case "$1" in
    *.spv) spirv-dis --raw-id "$1" 2>/dev/null;;
    *) exit 1;;
esac

exit $?

Then point the LESSOPEN variable to it, like so:
export LESSOPEN='|~/bin/lesspipe.sh "%s"'

Assuming spirv-dis is in your search path, you can now directly "less -R my_module.spv" on a binary and see it in a handy human readable form.  The -R is to preserve ANSI colors; you can add --no-color to the script if you don't like that.
To use spirv-dis and spirv-as to automatically (dis)assemble a SPIR-V binary file when loading or saving from emacs:
Place these lines into your .emacs file.  Then loading a binary will show the human readable asm in asm-mode in the editor buffer.  You can edit it within the constraints of validity, and when you re-save the file it will be assembled back to a SPIR-V binary.  Again you'll need the tools in your search path.  Handy for making hand tweaks to binary modules.
;; Handle auto-(dis)assemble of SPV binaries on save/load
(add-to-list 'jka-compr-compression-info-list
             '["\\.spv"
               "Assembling SPIRV" "spirv-as" ("-o" "-")
               "Disassembling SPIRV" "spirv-dis" ("--no-color" "--raw-id")
               t nil "\003\002\043\007"])

(add-to-list 'auto-mode-alist '("\\.spv\\'" . asm-mode))

These are good ideas!
I made https://github.com/KhronosGroup/SPIRV-Tools/pull/364 to capture the less feature.  Please take a look.  It adds a spirv-lesspipe program that gets installed appropriately.
The only funny bit is the people might have different preferences for default flags.  E.g. I didn't keep the --raw-id flag in the script, and others might not regularly use -R.   But it's a reasonable default.
Please take a look and provide a +1 on that MR if you like it.
As for the Emacs trick.  Is there a norm for sharing  emacs script file like that?  We could modify SPIRV-Tools to install a file in something like /etc/emacs.  I'm a vim guy so I don't know.  Feel free to make a pull request to add the file and install target.  Or a PR to just update the README with instructions like you've got above.

Looks good - comments left in the PR.
Agreed about the flags.  I suppose it could be handled with an optional env variable that'd set them if given, but I don't know how much effort it's worth.
About the emacs blurb: to install it in a system location, it can be put into /etc/emacs/site-start.d/, at least on Debian flavored distributions.  I'm rather fuzzier about redhat derivations.  However, there is a bit more fiddling about required: the file must be named beginning with two digits, such as 50spirv-tools.el, and be given as follows.  Per your suggestion I'll put together a PR with it + copyright message, though it might take me a few days to get to it.
;; Handle auto-(dis)assemble of SPV binaries on load/save
;; This requires spirv-as and spirv-dis be in $PATH.

(require 'jka-compr)

(add-to-list 'jka-compr-compression-info-list
             '["\\.spv\\'"
               "Assembling SPIRV" "spirv-as" ("-o" "-")
               "Disassembling SPIRV" "spirv-dis" ("--no-color" "--raw-id")
               t nil "\003\002\043\007"])

(add-to-list 'auto-mode-alist '("\\.spv\\'" . asm-mode))

(jka-compr-update)

Keeping this open in case anybody wants to add vim support.  :-)

@dneto0 I was not aware of this issue, I made vim-spirv a couple of months ago. Its implemented as a vim plugin so I'm not 100% sure it belongs in this project, although I'm open to that. Might be better off with a link in the documentation.

@kbenzie vim-spirv looks cool.   It's quite a bit more substantial than the emacs support.  I think vim-spirv should not be in this project.  But it would be good to point to it from the same part of this project's README that describes the emacs support: https://github.com/KhronosGroup/SPIRV-Tools#utility-filters
I encourage you to submit a PR to update this project's README.
You should also submit a PR to update the SPIR-V resources page https://github.com/KhronosGroup/Khronosdotorg/blob/master/api/spir/resources.md
Hm. That doesn't mention the emacs filter either.  It should, and I encourage your change adds references to both.


SameDiff sdvariable.getShape() returns null

The SDVariable.getShape() returns null for some of the cases such as,

if the shape is defined using int[] array or interger values, instead of long[] array when initializing the sdvariables

after certain operations are performed on the sdvariables (such as SameDiff.reshape() etc).

Therefore, in such occasion there is no way of finding out the shape of SDVariables, until the network is evaluated/executed properly.
Aha! Link: https://skymindai.aha.io/features/ND4J-151

Can you provide some code to reproduce the integer array issue?
I've tried the following on both 1.0.0-beta2 and snapshots, and I'm getting the expected shapes.
        SameDiff sd = SameDiff.create();
        SDVariable v1 = sd.var("v1", new int[]{1,2,3});
        System.out.println(Arrays.toString(v1.getShape()));

        SDVariable v2 = sd.one("v2", new int[]{1,2,3});
        System.out.println(Arrays.toString(v2.getShape()));

        SDVariable v3 = sd.zero("v3", new int[]{1,2,3});
        System.out.println(Arrays.toString(v3.getShape()));

As for the second one: v4 shape here is fine, v5 is null. If you are referring to v5, then this is a known issue - basically we need to implement offline shape inference: https://github.com/deeplearning4j/deeplearning4j/issues/6148
        SDVariable v4 = sd.var("v4", new long[]{1,2,3});
        SDVariable v5 = sd.reshape(v4, 6);
        System.out.println(Arrays.toString(v4.getShape()));
        System.out.println(Arrays.toString(v5.getShape()));

No longer relevant given API changes for this method


support URLs as packages, fix #272

Hi,
This PR adds a is_url_requirement util, which is used to let pip find the right dependencies for a package, as if the package was editable.

Hi,
Thanks for the review :)
I tried to address your comments, but after that I noticed that there are other PR working on a similar goal, thanks to the label. What should we do about that ?

Thanks for the comeback.
For the other PRs, I intended to go through them, check what each did, and cross-check them to check if one of them covered a corner case another one didn't and making sure we got the best fix/solution at the end.
I'll get on re-reviewing this as soon as I got time to. Also, if you want to go ahead and make that cross-check right yourself, that will certainly help out.

If I understand correctly,  #405 should handle urls like https://github.com/django/django/archive/master.zip#egg=django but it doesn't (see https://github.com/jazzband/pip-tools/pull/405#issuecomment-350464378), and #372 supports only vcs urls.
I checked with django's zip, and it puts django==2.0 in requirements.txt, no matter which branch was in requirements.in.
Therefore, I think that this PR handles more cases, and correctly, but I should add two tests instead of one:
test_url_package & test_url_package_vcs, in order to check the same things as in test_editable_package & test_editable_package_vcs

I did some more tests with the PR and noted something: The URLs in the resulting requirements.txt are not "pinned" in any way. This means that if someone puts git+https://github.com/jazzband/pip-tools.git@master#egg=pip-tools in the requirements.in, it stays as-is in the requirements.txt. master is not converted to the SHA of the current HEAD of master. We can't have that in the requirements.txt: When the HEAD of master will change, the requirements.txt will become invalid, as if we had any unpinned dependencies in it.
The behavior of pip is that if you do
pip install git+https://github.com/jazzband/pip-tools.git@master#egg=pip-tools
then pip freeze will give something like
click==6.7
first==2.0.1
pip-tools==1.11.1.dev3+ga2446fa
six==1.11.0

which gives the "version" of pip-tools on master at that moment. But pip looses the "source" of the dependency in that case, which is not ok in our case. That means pip-tools might need its own logic to determine the SHA (and implement a logic for the various supported VCS, git is not the only one out there). We might be able to reuse the logic that pip has that pins the SHA when installing with -e.
(This suddenly seems to explain why only the editable mode was ever supported in pip-tools with VCS URLs)
It looks like there's a fair amount of stuff that needs to be dealt with for this feature.

I see, you're right.
I don't see any easy solution right now :/

I'll add my 2c here as this one is more recent activity and tests (although I prefer the simplicity of the older attempt https://github.com/jazzband/pip-tools/pull/372)
I was digging around the pip-tools src because of the same frustrations here.
Would it be sufficient if piptools...:

checked if the constraint.link.egg_fragment had the right information for a pinned version u'package-name==1.2.3'
downloaded the archive using _vendored.pip.download.unpack_url

def unpack_url(link, location, download_dir=None,
only_download=False, session=None, hashes=None):

look at setup.py in the extracted folder and grab the requirements from there (I couldn't find a function for doing this)
add the requirements to the generated requirements.txt file
add the CVS/URL requirements to requirements.txt so pip would install it as it normally would
now pip-sync should have what it needs to check if a pinned package is installed at the right version or not

Don't have much experience with python package managers so my comment may come across as naive, but feel free to correct me if I'm wrong.

This work was included in #807 -- thanks!


A11y_AzureDataStudio_Newquery_LabelsorInstructions: Visual label is not provided for "Select database" dropdown.

"[Check out Accessibility Insights!] - Identify accessibility bugs before check-in and make bug fixing faster and easier."
#GitHub Tags:
#A11yMAS; #A11ySev2; #A11yTCS; #DesktopApp; #SH-AzureDataStudio-Linux-Jul2021; #Azure Data Studio; #WCAG3.3.2; #Linux; #Closed; #Regressed:05-15-23;
Environment Details:
Application Name: MySQL extension for Azure Data Studio
Application Version: 1.42.0-insider
Operating System: Ubuntu 20.04.2 LTS
GNOME Version: 3.36.8
ORCA: 42.2-1ubuntu1
Distributor ID: Ubuntu
Description: Ubuntu 22.10
Release: 22.10
Codename: kinetic
Repro Steps:

Launch Azure Data Studio application.
TAB to "Servers" and select any server from the list and hit ENTER on 'Connect' button.
TAB to "File" and hit ENTER key. TAB to "New Query" and hit ENTER key.
TAB to "Select database" and observe that Visual label is not provided for "Select database" dropdown.

Actual Result:
Visual label is not provided for "Select database" dropdown.
Expected Result:
Appropriate visual label should be provided for "Select database" dropdown.
User Impact:
Screen reader users will not the purpose of the dropdown and will not get information about it.
"Please do not close this bug. This bug should only be closed by TCS, C+AI Accessibility or the Divisional Driver."
Attachment:

Primary Bug: https://github.com/microsoft/azuredatastudio-mysql/issues/178

@VijayaBharathyA Please use the latest insider build to verify the fix.

Verified this issue in the latest Azure data studio- Insider (Version: 1.45.0 Insider).
Issue is fixed, hence closing the bug.


Main is now 16

it will probably fail as the 15 branch isn't ready yet

auto merge as serge is off


Replace quickcheck with qcheck

The latter is a fork of the former, which adds const generics and a bunch of other quality of life and performance improvements that aren't in the original crate due to it being unmaintained.
I'm maintaing the fork here: https://github.com/cloudhead/qcheck
Signed-off-by: Alexis Sellier<EMAIL_ADDRESS>

@cloudhead where is the donate link? :)


error: expected std.io.Writer interface value

Description
I got the error
error: expected `std.io.Writer` interface value, found `std.io.writer.Writer(std.fs.file.File,std.os.WriteError,std.fs.file.File.write)`

with the example from the README page for the toWriter function:
const std = @import("std");
const json = @import("json");

const Point = struct { x: i32, y: i32 };
const point = Point{ .x = 1, .y = 2 };

pub fn main() anyerror!void {
    const stdout = std.io.getStdOut().writer();

    // {"x":1,"y":2}
    try json.toWriter(point, stdout);
}

I get a similar error with toSlice
I guess this is about Zig version? Any workaround to stay on 0.9.1?
How to Reproduce the Bug
Zig 0.9.1
Additional Context
full error:
.\.gyro\json-getty-zig-github.com-9f451bd8\pkg\src\ser.zig:128:17: error: expected `std.io.Writer` interface value, found `std.io.writer.Writer(std.fs.file.File,std.os.WriteError,std.fs.file.File.write)`
                @compileError(err);
                ^
.\.gyro\json-getty-zig-github.com-9f451bd8\pkg\src\ser.zig:16:39: note: called from here
    comptime concepts.@"std.io.Writer"(@TypeOf(writer));
                                      ^
.\.gyro\json-getty-zig-github.com-9f451bd8\pkg\src\ser.zig:41:28: note: called from here
    return try toWriterWith(value, writer, getty.default_st);
                           ^
.\src\main.zig:11:22: note: called from here
    try json.toWriter(point, stdout);
                     ^
.\src\main.zig:7:29: note: called from here
pub fn main() anyerror!void {

I guess this is about Zig version?

Yeah. The type names for std types changed in stage2, which is why you're getting that error even though you're correctly passing in a std.io.Writer.

Any workaround to stay on 0.9.1?

If you're using Gyro, you can specify which version of Getty JSON to grab. In this case, I think 0172f55d90e16b50e2da4549578e632c87382352 is the latest version that would work. It uses a pre-stage2 version of Getty so everything should be fixed for you (probably... It maaaaay rely 0.10 stuff but I don't think that's the case).
```
deps:
  json:
    git:
      url: "https://github.com/getty-zig/json.git"
      ref: 0172f55d90e16b50e2da4549578e632c87382352
      root: src/lib.zig
```

If you're using Zigmod, you can do something similar I believe. Although, now that I've looked, the zigmod.yml is way out-of-date and needs to be updated 😅
```
dependencies:
  - src: git https://github.com/getty-zig/json
    version: commit-0172f55
```

If you're building from source, then you can just grab the aforementioned commit and build that.

Hope that helps!

Indeed, with the commit ID you provided, this example works. I wonder how much I'd lose having such an old version.
I also commented out this line on the last commit and it worked:
https://github.com/getty-zig/json/blob/main/src/ser.zig#L16
Thanks a lot!


Setting Figma stroke for individual side will render in compose for all sides

Hi! We took a look and we don't currently support setting strokes for individual sides. We'll be looking into what it will take to support this.

This is fixed in the upcoming 0.24 release -- resolving the ticket.


Update aar version dependencies

Update aar versions to the latest TIKI Flutter SDK done in https://github.com/tiki/tiki-sdk-flutter/issues/123

Emulator tests

Emulator example app
https://user-images.githubusercontent.com/8357343/214892319-06bd540a-d481-4283-865f-fbe7419ea43e.webm

physical device tests


snap: Fix snap build with kernel fragments

Signed-off-by: Ganesh Maharaj Mahalingam<EMAIL_ADDRESS>

@egernst @devimc @grahamwhaley

/test

@egernst @devimc @chavafg I ran the test suite 4 times locally and i was not able to reproduce the issue.
this is the output from the last run.
[4] Checking CPU cgroups in the host
[4] /home/ganeshma/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:110
[4]   checking whether cgroups can be deleted
[4]   /home/ganeshma/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:130
[4]     with a running process
[4]     /home/ganeshma/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:131
[4]       should be deleted
[4]       /home/ganeshma/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:132
[4] ------------------------------
[4] docker exec check stdout forwarded using exec
[4]   should displayed it
[4]   /home/ganeshma/go/src/github.com/kata-containers/tests/integration/docker/exec_test.go:61
[4] Running command '/usr/bin/docker [docker run --cidfile /tmp/cid705408909/D7GDm1wdduJmjNUghwf6h8ysl00tF4 --runtime kata-runtime -td --name D7GDm1wdduJmjNUghwf6h8ysl00tF4 busybox sh]'
[6] [bash -c printf "g\nn\n\n\n\nw\n" | fdisk /tmp/dd689310252]
[6] Timeout: 120 seconds
[6] Exit Code: 0
[6] Stdout:
[6] Welcome to fdisk (util-linux 2.31.1).

Any thoughts on the next steps ?

/test
as what I see in the CI logs is a test fail, that I suspect could be sporadic, so let's re-trigger...
[1] • Failure [5.304 seconds]
[1] Checking CPU cgroups in the host
[1] /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:110
[1]   checking hosts's cpu cgroups
[1]   /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:191
[1]     container with cpu and cpuset constraints
[1]     /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:192
[1]       shold have its cgroup set correctly [It]
[1]       /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:193
[1]
[1]       Expected error:
[1]           <*os.PathError | 0xc00010e5a0>: {
[1]               Op: "open",
[1]               Path: "/sys/fs/cgroup/cpu/docker/kata_8de29f587942cdfaab89789147dc32475d62e1b70be70b9b3f8e490afb9dd61f/cpu.shares",
[1]               Err: 0x2,
[1]           }
[1]           open /sys/fs/cgroup/cpu/docker/kata_8de29f587942cdfaab89789147dc32475d62e1b70be70b9b3f8e490afb9dd61f/cpu.shares: no such file or directory
[1]       not to have occurred
[1]
[1]       /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:203
[1] ------------------------------
[1]
[1]
[1] Summarizing 1 Failure:
[1]
[1] [Fail] Checking CPU cgroups in the host checking hosts's cpu cgroups container with cpu and cpuset constraints [It] shold have its cgroup set correctly
[1] /tmp/jenkins/workspace/kata-containers-packaging-ubuntu-18-04-snap-PR/go/src/github.com/kata-containers/tests/integration/docker/cgroups_test.go:203
[1]
[1] Ran 12 of 13 Specs in 231.147 seconds
[1] FAIL! -- 11 Passed | 1 Failed | 0 Pending | 1 Skipped --- FAIL: TestIntegration (231.15s)
[1] FAIL

/retest

fixed snap CI , please take a look https://github.com/kata-containers/packaging/pull/441

@ganeshmaharaj  rebase  :smile:

@devimc done. :)

/test

Thanks @devimc for catching this. Closing this PR as @devimc has a cleaner fix for the same.


(Feature) Step 3 - CSV File Upload Improvements

Closes #1179

Black Duck Security Report
Merging #1207 into integration/#1082-new-design will not change security risk.
Click here to see full report

@mariano-aguero
Validator detects incorrect minCap for line with incorrect maxCap

@mariano-aguero
Warning message: if warning contains one error then the text should be in singular form '...  is wrong' (instead ... are wrong )

@mariano-aguero
If mincap is fractional then warning text should contains:

phrase Actual value is ...
word integer instead number

@mariano-aguero
Why not  to add ta phrase actual value is..  to each  incorrect line in this  warning message if  it has already added in similar case with wrong mincap?

@dennis00010011b
All feedback reported was fixed, Greetings

@mariano-aguero
Error messages are duplicated  if line has no minCap or maxCap

@dennis00010011b all errors belong to that line. Do you want the errors to be grouped by line?

@mariano-aguero
Follow messages are dublicates.  'The line number 5 need a minCap'  and  'The line number 5 has an incorrect mincap. Must be an integer. Actual value is empty'
I think should be only one of them  (second)

@dennis00010011b

Follow messages are dublicates. The line number 5 need a minCap and The line number 5 has an incorrect mincap. Must be an integer. Actual value is empty
I think should be only one of them (second)

I did a simulation with your test file, I attached a capture.

It seems to work fine.
I suggest a few changes:
1- It may be good to change
- The line number 1...
- The line number 2...
- The line number 3...

etc.

For a simpler and less cluttered
- Line #1...
- Line #4...
- Line #6...

etc.

I might be nitpicking, but I think that "Current value is..." is more adequate than "Actual value is..."

@gabitoesmiapodo
Wording fixed here https://github.com/poanetwork/token-wizard/pull/1207/commits/d7bfa0fc477f47ad41d641b220cce66c571bab75
Greetings


lib: clean up PR and CI url parsing logic

Put the PR URL parsing logic in links.js and reuse it
Differentiate PR and commit jobs in preparation for https://github.com/nodejs/node-core-utils/pull/161
Updates a few CI link patterns

cc @nodejs/automation


Organize Image Files into Folders for Better Readability

What's wrong with the existing documentation

Image files are currently not stored in separate folders, causing clutter and reducing code readability.
This makes it harder for developers to navigate and maintain the codebase.
By organizing images into folders, we can improve code structure and accessibility for both developers and users.

Benefits:

Improved readability and organization
Easier maintenance and updates
@anuragverma108

Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@anuragverma108 please assign this task to me


Update apt::source to match with new method

puppetlabs-apt recently did some changes that brings warnings when we
run puppetlabs-rabbitmq, because we need to update the way we consume
apt module.
$include_src is deprecated and will be removed in the next major
release, please use $include => { 'src' => false } instead
$key_source is deprecated and will be removed in the next major release,
please use $key => { 'source' =>
http://www.rabbitmq.com/rabbitmq-signing-key-public.asc } instead.
This patch aims to update the way we use puppetlabs-apt to match with
upstream and avoid warnings in our catalog.

Does this require a bump in metadata.json, or will it still work with apt 1.8.0?

@hunner yes, but 2.x.x has been released in 2015-04. I suppose people update their manifests from time to time? Maybe I'm wrong. Feel free to merge it or not.
FWIW, Puppet OpenStack CI is running 2.2.x serie:
https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile#L117-L119

I want to merge this, but it would require a 6.0.0 release of rabbitmq. While we're at it, what other changes do we want to make to the module?

Could you also increase the lower bound of puppetlabs-apt in metadata.json to >= 2.0.0? Since it won't work with 1.8.x

@hunner done

:+1:

hi @EmilienM , could you please rebase?

@eputnam done.

Merged in #497


Frankelycp patch 1

There are several files in the request, along with file.zip. It must not be there. Please remove file.zip and make pull request again.  I have to close this request without merging. Thank you for your understanding.


Wingtips-to-lightstep bikeshedding

Codecov Report

Merging #90 into master will increase coverage by 2.04%.
The diff coverage is 96.77%.

@@             Coverage Diff              @@
##             master      #90      +/-   ##
============================================
+ Coverage     96.32%   98.37%   +2.04%
- Complexity     1030     1049      +19
============================================
  Files            62       62
  Lines          2534     2529       -5
  Branches        339      340       +1
============================================
+ Hits           2441     2488      +47
+ Misses           76       27      -49
+ Partials         17       14       -3

Impacted Files
Coverage Δ
Complexity Δ

...ightstep/WingtipsToLightStepLifecycleListener.java
79.83% <96.77%> (+41.12%)
29 <11> (+19)
:arrow_up:

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 5f26621...9d9e55f. Read the comment docs.


CLI tool available?

I want to be able to run files and stdin through particular grammars and semantic operations that will generate files or print results to stdout. I've started building my own tooling for doing this with my own work, but wanted to check to see if something already existed and I didn't find anything in a cursory search through the repositories posted here.
Example:
cat model | run_operation RM_PGSQL toPostgreSQL > schema.ddl

Where RM_PGSQL refers to a grammar and toPostgreSQL refers to a semantic action (or derivative).
Does something like this exist, or is a common solution planned?
My apologies if I have missed something.

Hi Blake,
I think that's worth a shot and we could put something like that in bin. There currently is a script in this directory - es5bench - that does something similar: Parse dist/ohm.js against the ES5 grammar and compile it to JS code (using examples/ecmascript/compile.js). It's not a semantics but I don't see why it couldn't be.

I agree that it would be useful to have something like this!
On Thu, Mar 3, 2016 at 2:47 PM, mroeder<EMAIL_ADDRESS>wrote:

Hi Blake,
I think that's worth a shot and we could put something like that in bin
http://../blob/master/bin. There currently is a script in this
directory - es5bench http://../blob/master/bin/es5bench - that does
something similar: Parse dist/ohm.js against the ES5 grammar and compile
it to JS code (using examples/ecmascript/compile.js
http://../blob/master/examples/ecmascript/compile.js). It's not a
semantics but I don't see why it couldn't be.
—
Reply to this email directly or view it on GitHub
https://github.com/cdglabs/ohm/issues/71#issuecomment-192003144.

It looks like this was done.
$ npm install ohm-js -g
$ ohm-js $opts

No, it actually is still in the pipeline (something that takes grammar, semantics, operation/attribute name and input and processes it).

I also had a need for this, and recently released https://github.com/robertothais/ohm-cli.
It currently only supports validating grammars and recognizing inputs. I'd like to add support for semantic actions soon. Any feedback is welcome.

I'm going to close this as we now have an "official" CLI tool.


A Vagrantfile based on debian/jessie64

After encountering many issues trying to start middleman server from your Vagrantfile, I decided to fork your Vagranfile and base it on the debian/jessie64 and the last version of Ruby (2.4.0)
In addition, the ability of overiding "provisioning names" is not supported in version 1.6.5 and below, which is the official jessie ppa version (https://www.vagrantup.com/docs/provisioning/shell.html#name). So I suggest to remove them in order to maximize linux versions support.
Perfectly works on debian/jessie and vagrant 1.6.5.
I let you check. Regards.
Benjamin.

Thanks for contributing! Is there any advantages to using Debian for this instead of Ubuntu, and if so, is there any reason to keep the old Vagrantfile around if we have this new and improved one?

Hey, @BenC- I've patched up the existing Vagrantfile in #710. I encountered issues too!

Hi Lord, thank you for your answer.
Multiple reasons to use Debian over Ubuntu :

Most of production servers run on Debian for security and statility reasons because any packages has been tested thoroughly, and using your target env is always recommended
De facto, services and packages are generally less recent than those in ubuntu, ensuring a maximization of slate compatibility. (backward compatibility generaly ensure that what is running on Debian will also work on Ubuntu).

I've also added rsync so that autoreload is supported on vagrant with a
vagrant rsync-auto
If you do not mind, this Vagrantfile can replace the original one.

up

Sorry for the delay — I'm waiting till I get a free chunk of time to test the two Vagrantfiles and make a decision.


encase return Left/Nothing when null / undefined / NaN

I'm finding that despite using encase, I'm still encountering nulls (they are pervasive in JS libraries).  Would it to possible to make encase even stricter, and return Left/Nothing if the result is null, undefined or NaN?

This suggest sounds sane from a consistency standpoint. We have toMaybe which does something like this null stuff. And toMaybe looks very similar to what an encase0 would look like:
encase3 :: (a -> b -> c -> d) -> (a -> b -> c -> Maybe d)
encase2 :: (a -> b -> c)      -> (a -> b -> Maybe c)
encase  :: (a -> b)           -> (a -> Maybe b)
toMaybe :: (a?)               -> (Maybe a)

I think this sounds like a good idea, but I think others probably have a better idea of whether or not it actually is.

I'm of the opinion that exceptions and "bogus" values should be handled separately for maximum flexibility and ease of understanding. Consider the following functions:
-- ! indicates a function which may raise an exception
f :: String -> Integer !
g :: String -> Nullable Integer
h :: String -> Nullable Integer !

We can create safe versions of these functions using encase, toMaybe, or both:
//    fʹ :: String -> Maybe Integer
const fʹ = S.encase(f);

//    gʹ :: String -> Maybe Integer
const gʹ = S.compose(S.toMaybe, g);

//    hʹ :: String -> Maybe Integer
const hʹ = S.compose(R.chain(S.toMaybe), S.encase(h));

From the definition of hʹ we can infer that h may raise an exception or return null/undefined. Were we to provide a function which handled both failure conditions, the definition of hʹ could become S.<name>(h), but the reader would then wonder whether h throws, returns null, or both.
Additionally, some functions can legitimately return null. The result of JSON.parse('null'), for example, is null, so S.encase(JSON.parse, 'null') should evaluate to Just(null).
While encase and toMaybe have a common goal, they are solving different problems. I suggest we keep them separate.
@JAForbes and @joneshf, do you find these points compelling?

@davidchambers your point is compelling! :)
But I think I disagree.  I think S.encase(JSON.parse, 'null') should evaluate to Nothing
Functions that legitimately return null are probably attempting to signal something semantically equivalent to Nothing anyway.
I am all for composing granular functions though.  Maybe I am not considering some genuine use cases for null?
But I do like your composition example.  It is certainly easy to do which is comforting.

Functions that legitimately return null are probably attempting to signal something semantically equivalent to Nothing anyway.

Absolutely. toMaybe is useful in these cases.
JSON.parse('null') is not one of these cases, though. JSON.parse throws if applied to a string which is not valid JSON, but 'null' is valid:
JSON.parse('null');
// => null

JSON.parse('undefined');
// ! SyntaxError: Unexpected token u

Admittedly, null is unlikely to be the result we're hoping to see. In order to make the result well typed we would need to filter it. This is the reason parseJson takes a type representative as its first argument (and will take a predicate instead once #191 is merged).
The current definition of encase is very clear, as the function does only one thing. I don't think we should get into the business of guessing which values are "bogus". null? Sure. undefined? I'd say so. NaN? Probably. -1? Who knows?
The nice thing is that the Maybe type supports filter and reject. For example:
> R.reject(Number.isNaN, S.Just(NaN))
Nothing

I'll close this issue, but feel free to comment further.


Add ability to specify default docker registry auth credentials

Hello!
We provide k8s cluster for many applications in our company.
Our users (people who deploy and run applications inside cluster) use it as a black box.
When dockerhub introduced limits on the number of requests, we configured authorization at the level of each cluster node (specifying its settings here - /.docker/config.json), as described in the official k8s documentation.
For us it is a good solution because this doesn't affect our users (they don't need to specify the credentials).
At this point, we already had k8s-image-availability-exporter installed.
We began to notice that k8s-iae is facing into dockerhub limits.
Having looked at k8s-iae code we realized that the only way to make it work with the docker registry using authorization is to specify ImagePullSecrets for all pods in the cluster.
The library that is used for retrieving image data use by as default auth data from $HOME/.docker/config.json.
We mounted the docker config json to /root/.docker/config.json.
But it didn't no help.
The way with setting ImagePullSecrets for all pods looks like an overhead in our case.
It would be nice if k8s-iae has the ability to pick up the default authorization configuration for the docker registry.
For example, the application reads the contents of the file /.docker/config.json or /root/.docker/config.json from inside the container, which is mounted using the secrets mechanism.
This default credentials are used as fallback if other credentials are not specified in ImagePullSecrets from spec.
P.S.
We read in k8s-iae docs that it does not support container registries that should be accessed via authorization on a node.
We would also like to hear your opinion on this situation.
How do you think, how we can continue to use k8s-iae without forcing all users to specify ImagePullSecrets in their manifests and without compromising docker hub auth credentials?

We also noticed that if the env DOCKER_CONFIG is not specified the DefaultKeychain is not loaded.
Now we are trying to run k8s-iae with this env var and with docker config json as mounted volume.

We changed mount point of docker config to /.dockercfg and it seems working.
Closing the issue.

/close


[FEAT] UI UX not at all friendly need to update

Is your feature request related to a problem? Please describe.
When I asked my father to use this app, he had confusions where to start and what to do after getting to the website.
Describe the solution you'd like
A clear and concise description on how to go through and use the application by any means.
Describe alternatives you've considered
Better placeholder, tooltips , or a popup menu giving a description how to use the app.

/assign