How to resolve these errors?

Hi, @englercj I came here from: https://github.com/pixijs/pixi-ui/issues/16
Basically, I am trying to create .tsd for pixi-ui, but I see the errors below. How can I solve?
> npm install tsd-jsdoc
> npm install<EMAIL_ADDRESS>> node_modules\.bin\jsdoc -t node_modules/tsd-jsdoc -r src
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Button", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.CheckBox", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "bool". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Container", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.Container", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.DynamicText", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "DynamicTextStyle". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.DynamicText", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.InputBase", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.InputBase", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.ScrollBar", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Object". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.ScrollingContainer", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.ScrollingContainer", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.SliceSprite", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "PIXI.Texture". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Slider", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Object". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "callback". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "callback". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.SortableList", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "PIXI.UI.Ease". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.SortableList", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Sprite", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "PIXI.Texture". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.Sprite", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Stage", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.Text", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "PIXI.TextStyle". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.Text", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.TextInput", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Boolean". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "PIXI.TextStyle". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Array". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "String". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.TilingSprite", using memberof "PIXI.UI". No such name found.
[TSD-JSDoc] Unable to resolve type name "PIXI.Texture". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "PIXI.UI.TilingSprite", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "Number". No type found with that name, defaulting to "any".
[TSD-JSDoc] Failed to resolve base type of "UIBase", no object found with name "PIXI.UI.UIBase".
[TSD-JSDoc] Unable to resolve memberof for "PIXI.UI.UISettings", using memberof "PIXI.UI". No such name found.

Unable to resolve type name ...

This means the jsdoc refers to a type that we didn't find anywhere. Generally this is because the jsdoc uses a type name that they didn't define. Or it is a built-in type that we don't support yet.
Specifically for Number I think what we look for is number so that might be the issue. Similarly for Boolean vs boolean, and String vs string, etc. You can see the built-in list here: https://github.com/RyanCavanaugh/dts-dom/blob/64dc5608ba9d497137614eebc90d4866d254e081/lib/index.ts#L561-L570
Other errors like this one:

Unable to resolve memberof for "PIXI.UI.Button", using memberof "PIXI.UI". No such name found.

Are saying that the jsdoc for we looked for a container (namespace, class, etc) called PIXI.UI and found nothing. So the jsdoc has a memberof tag that points to something that was never defined anywhere.

@englercj Thank you for your response.
I am new to JSDoc, so please help me here. For the Number/String/Boolean issue, should pixi-ui be fixed to use number/string/boolean for their docs?

Yes, either the jsdocs need to change or this lib needs to fix #16 or the other fix for this lib I mentioned.

What about Object/Array? I get the error below even if I use lower-cased object/array:
[TSD-JSDoc] Unable to resolve type name "object". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "array". No type found with that name, defaulting to "any".

Also, pixi-ui references some types from pixijs, and gets the error below:
[TSD-JSDoc] Unable to resolve type name "PIXI.Texture". No type found with that name, defaulting to "any".
[TSD-JSDoc] Unable to resolve type name "PIXI.TextStyle". No type found with that name, defaulting to "any".

How do I let tsd-jsdoc know about those types?

What about Object/Array? I get the error below even if I use lower-cased object/array:

Just like the error mentions, those types are not recognized, and so it falls back to any. Like mentioned in #16 built-in js types do not resolve currently. Either define the object explicitly with a typedef like this or change it to any or ignore the warning.

Also, pixi-ui references some types from pixijs, and gets the error below:
How do I let tsd-jsdoc know about those types?

This library isn't magic, it can only output information about what it knows about. It reads jsdoc and outputs equivalent typescript. If there is no jsdoc that tells the lib what PIXI.Textrure means, it can't output that type. So, tell it what the type is or use something else that it knows about.

So issues addressed here is already on #16 so I'm closing this one.


feat: add libs in data json

add new libs in project
yo
Upload.js
Viewer.js
spruce
Astral.js
Vasille

Hi, I can't add

Astral.js
Vasille
because they have very low usage (<100 downloads per week on npm).

year_created for upload.js appears to be wrong, should be 2021

libs tweaked and removed.

Merged.


Update .htaccess

Also allowlist google calendar.
follow up for #30394

R: @svetakvsundhar

Ah, I think its addressing the below; sounds good.

actually removing these frames may be a more appropriate course of action.


package add works in second run despite errors

how to reproduce

start 3bot server
add a malfunctioned package. this will fail
add it again. this will install the package (change its state to installed)

fixed on branch https://github.com/threefoldtech/jumpscaleX_core/tree/development_fixPackageAdd commit https://github.com/threefoldtech/jumpscaleX_core/pull/686/commits/4e9c7011301eadeff3c2746e963803f15621c682

Verified


Text rendering breaks across different monitor scale factors unless Texts are mutably queried

Bevy version
bf053218bf394abc27897bd90aa338bb3cd580f9
Operating system & version
Windows 10.
What you did
Constructed this variation of the ui.rs example:
use bevy::{prelude::*};

fn main() {
    App::build()
        .insert_resource(Msaa { samples: 4 })
        .insert_resource(WindowDescriptor {
            width: 800.,
            height: 600.,
            title: "usoo".into(),
            ..Default::default()
        })
        .add_plugins(DefaultPlugins)
        .add_startup_system(spawn_ui.system())
        .run();
}

fn spawn_ui(
    mut commands: Commands,
    asset_server: Res<AssetServer>,
    mut materials: ResMut<Assets<ColorMaterial>>,
) {
    commands.spawn_bundle(UiCameraBundle::default());

    let blank_mat = materials.add(Color::NONE.into());
    let dark_gray_mat = materials.add(Color::rgb(0.15, 0.15, 0.15).into());

    commands
    .spawn_bundle(NodeBundle {
        style: Style {
            size: Size::new(Val::Percent(100.0), Val::Percent(100.0)),
            justify_content: JustifyContent::SpaceBetween,
            ..Default::default()
        },
        material: blank_mat,
        ..Default::default()
    })
    .with_children(|parent| {
        // left vertical fill (content)
        parent
        .spawn_bundle(NodeBundle {
            style: Style {
                size: Size::new(Val::Percent(40.0), Val::Percent(30.0)),
                align_items: AlignItems::FlexEnd,
                ..Default::default()
            },
            material: dark_gray_mat,
            ..Default::default()
        })
        .with_children(|parent| {
            let text_bundle = TextBundle {
                style: Style {
                    margin: Rect::all(Val::Px(5.0)),
                    ..Default::default()
                },
                text: Text::with_section(
                    "Text Example",
                    TextStyle {
                        font: asset_server.load("fonts/FiraMono-Medium.ttf"),
                        font_size: 24.0,
                        color: Color::WHITE,
                    },
                    Default::default()
                ),
                ..Default::default()
            };

            parent.spawn_bundle(text_bundle);
        });
    });
}

What you expected to happen
This code launches a new window on my primary monitor, which has a scale factor of 2.5 (3840x2160):

Upon moving the window to my secondary monitor, which has a scale factor of 1.0 (1920x1080), I expect the following result (screenshot taken after applying a workaround, discussed below):

What actually happened
Instead, the result upon dragging the window to the secondary monitor with scale factor 1.0 shows the text incorrectly scaled:

Additional information
While attempting to implement a manual fix by adding a system that automatically scaled text font sizes based on the window scale factor, I stumbled across an unexpected workaround for the issue. Adding the following system fixes text scaling -- it's the smallest possible system I could find that fixes the issue.
// (in App::build())
        .add_system(poke_text_sections_to_fix_window_scale_factors.system())
// and the system:

/// For some reason, text scaling can be fixed as the window auto-adjusts to the scale factor of the current monitor by poking the text components *mutably*.
///
/// This may be from some kind of ordering issue with an internal system that checks for window scale factor changes, or some lazy-state bug that is fixed via mutable access?
fn poke_text_sections_to_fix_window_scale_factors(
    query: Query<&mut Text>
) {
    query.for_each_mut(|mut text| {
        for _section in &mut text.sections { }
    })
}

I believe #1132 may be related to this issue; it's the most recent change I can find related to text scaling. My best guess is that adding a system that mutably runs a query on Text components either updates lazy state necessary for "automatic" text scaling to kick in, or possibly changes the order of Text system updates to allow automatic text scaling to function correctly.

By mutably dereferencing the Text, you're triggering change detection and causing it to be re-rendered by the text system.

So it seems like the bug is "Text isn't re-rendered when scale factor changes."

Nice analysis! A bandaid for this is likely very quick, but this smells like we have bad component boundaries and I'd like to see if we can resolve the root cause as part of the UI focus area for 0.6.


Cauldron Stews feature not working

It seems cooking stews and soups in a cauldron doesn't work. I can't right-click a boiling cauldron with any of the special stew items.

How many are you using? A full cauldron takes two, as stated in JEI.

Whoops


[SUPPORT] Poor parallelism in BLOOM indexing stage with Hudi 0.12.3

Tips before filing an issue

Have you gone through our FAQs?

Join the mailing list to engage in conversations and get faster support at<EMAIL_ADDRESS>

If you have triaged this as a bug, then file an issue directly.

Describe the problem you faced
Hello, Recently we migrated our datasets from Hudi 0.8 to Hudi 0.12.3 and started experiencing slowness in indexing stage in some tables during upserts.
After looking into spark steps, we found out that there was one particular stage where Hudi set a very low value parallelism for a indexing stage (stage 32 in the screenshoot) and ended up causing long duration and shuffle spill which further slowdown the stage. We set hoodie.bloom.index.parallelism=2000 however, it doesn't seem to affect the parallelism of that particular stage.
In Hudi 0.8, Hudi used to use a much larger value for parallelism for this stage, and we never experienced slowness in indexing stage.
Can you please help us understand if there is any Hudi configuration we should use to increase the parallelism for the stage?
We also tried setting hoodie.copyonwrite.record.size.estimate to a very small value and found that it seems help forcing Hudi to use a larger parallelism for indexing, but the effect it's very inconsistent as we still see small values being set for the stage across upsert jobs.
Environment Description

Hudi version : 0.12.3

Spark version :  3.1.3

Hive version : 3.1.3

Hadoop version : 3.3.3

Storage (HDFS/S3/GCS..) : S3

Running on Docker? (yes/no) : no

EMR: 6.10.0

Additional context
Hudi configs
hoodie.metadata.enable: true
hoodie.metadata.validate: true
hoodie.cleaner.commits.retained: 72
hoodie.keep.min.commits: 100
hoodie.keep.max.commits: 150
hoodie.datasource.write.payload.class: org.apache.hudi.common.model.DefaultHoodieRecordPayload
hoodie.index.type: BLOOM
hoodie.bloom.index.parallelism: 2000
hoodie.copyonwrite.record.size.estimate: 1
hoodie.metadata.enable: true
hoodie.datasource.write.table.type: COPY_ON_WRITE
hoodie.insert.shuffle.parallelism: 1500
hoodie.datasource.write.operation: upsert
hoodie.datasource.hive_sync.partition_extractor_class: org.apache.hudi.hive.MultiPartKeysValueExtractor
hoodie.datasource.write.keygenerator.class: org.apache.hudi.keygen.ComplexKeyGenerator

@ChiehFu Do you know if any particular reason why it's taking only 3 tasks. Can you paste the full UI for one of the job. Need to check how many tasks it create for Tagging stage.

@ad1happy2go  I am not sure why it only had 3 tasks. This particular upsert job upserted 328,550 records.

@ChiehFu The tasks in tagging step depends n how many partitions are there in input DataFrame.
By any chance are you getting large zipped files in source? You can do repartition before write to hudi.
df.repartition(10000).write.format....

@ChiehFu We should derive based on input data size. Too many partitions will create extra tasks and create extra overhead time. Are those 2 tsv files gzipped. If yes that is causing the job only have 3 tasks. gzip is unsplittable format.

@ad1happy2go  I see, thanks for the explanation. Let me double check on the file format and get back to you.
In addition, we has this table running in Hudi 0.8 for over a year and this didn't seem to be an issue (low parallelism) until we upgraded the table to Hudi 0.12. Was it because the way how parallelism is derived was changed in Hudi 0.12?

@ad1happy2go Those two files were plain tsv files without compression.

@ChiehFu In older versions of hudi we do use the configs but it newer versions we derive it from input DataFrame. Your two files are 115 MB so they ideally make those number of partition (2-3) only as block size is 128 MB.
You can try setting sql.files.maxPartitionBytes to a lower value so that it can make more partitions.

@ad1happy2go got it, thanks for the clarification.
I tried repartitioning the input df by 100 and observed the parallelism of both tagging and indexing stages were set to 100 as well which significantly speeded up the indexing performance.
I submitted another issue where slowness was observed in writing stage with S3 storage with Hudi 0.12.3, could you please take a look when you have a chance? https://github.com/apache/hudi/issues/10121


support c-style hex escape sequences in strings

To support funky characters in string literals, C supports escaping them as using \x followed by their ASCII value in hex.  For example, \n can instead be written as \xa or \xA, and space can be written as \x20.  We should support this.  For now, I'll disallow unprintable characters in Chisel printf.

I'm hitting up against an assertion error regarding this issue in my code base:
    // chisel3/internal/firrtl/IR.scala
    line 182:  require(x.toInt >= 32) // TODO \xNN once FIRRTL issue #59 is resolved

Not sure if this is a separate issue, but %s is no longer supported, even though rocket.Str is still around?
[INFO] Starting High Form Check
Exception in thread "main" firrtl.passes.PassExceptions:
firrtl.passes.CheckHighForm$BadPrintfException:  @[fetch.scala 200:13]: [module FetchUnit]
  Bad printf format: "%s"
firrtl.passes.CheckHighForm$BadPrintfIncorrectNumException:  @[fetch.scala 200:13]:
  [module FetchUnit] Bad printf format: incorrect number of arguments

I use this everywhere. :(

Firrtl does not have a String type, without that I'm not sure it's possible to create Strings in that way unfortunately :(
You could obviously rewrite simple examples as:
when (br_unit.brinfo.valid) {
  printf("BrPred V\n")
} .otherwise {
  printf("BrPred -\n")
}

Of course this does not scale very well at all if you want to chain a lot of similar things together.
Thoughts on whether and how Strings should/could be supported in Firrtl @azidar, @aswaterman ?

For simple things, like that example, use %c? If the string args themselves
are constants, this could be done in Scala and doesn't require a firrtl
change.
On Tuesday, July 26, 2016, Jack Koenig<EMAIL_ADDRESS>wrote:

Firrtl does not have a String type, without that I'm not sure it's
possible to create Strings in that way unfortunately :(
You could obviously rewrite simple examples as:
when (br_unit.brinfo.valid) {
printf("BrPred V\n")
} .otherwise {
printf("BrPred -\n")
}
Of course this does not scale very well at all if you want to chain a lot
of similar things together.
Thoughts on whether and how Strings should/could be supported in Firrtl
@azidar https://github.com/azidar, @aswaterman
https://github.com/aswaterman ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/firrtl/issues/59#issuecomment-235324630, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA-7wr4BI4QZbqKIe1fLZ2rPAF0zDiqVks5qZjXdgaJpZM4HV-Uu
.

Yeah I forgot about %c, that would work fine. You could also probably build a super hacky string library around it using Vecs as strings.

Chisel could turn %s into a sequence of %c if the widths of the strings are
forward-inferable (a reasonable restriction IMO)
On Tue, Jul 26, 2016 at 10:34 AM, Jack Koenig<EMAIL_ADDRESS>wrote:

Yeah I forgot about %c, that would work fine. You could also probably
build a super hacky string library around it using Vecs as strings.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/firrtl/issues/59#issuecomment-235344336, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA-7wjNhyM49zAMhl2qjIMNzJXFB8WYWks5qZkUlgaJpZM4HV-Uu
.

Here is the git diff for BOOM required to work around not having native "%s" support:
https://github.com/ucb-bar/riscv-boom/commit/642c118cc6bc2c94fe394157845dca6facdf5bd3
It's not life threatening, but it's a sizable hit to readability of my output files.

Firrtl does not have a String type, without that I'm not sure it's possible to create Strings in that way unfortunately :(

It seems like this is easier to handle on the Scala side. Please reopen the issue if there is still a need for supporting strings in firrtl.


Use outside of a compose app

About this issue
Hi! We have no interest in using Compose, whereas your library seems to mandate the use of Compose.
Also, unfortunately for us, your library seems to be one of the only libraries for rendering markdown that's decently maintained.
Perhaps we are missing how to use it without compose (Markdown(text) does not work, outside of a composable function), or is there plans to support non compose Android apps?
Details

[x] Used library version 0.12.0
[ ] Used platform
[ ] Used support library version
[x] Used gradle build tools version 8.2.2
[x] Used tooling / Android Studio version Android Gradle Plugin 8.2.2
[ ] Other used libraries, potential conflicting libraries

Checklist

[x] Searched for similar issues
[x] Checked out the sample application
[x] Read the README
[x] Checked out the CHANGELOG
[x] Read the FAQ
[x] Checked out the MIGRATION GUIDE

Good day @androidacy-user and thank you for raising this question.
There are no plans to have a view-only variant of this library as its main target was compose (and even compose multiplatform apps).
For using it in a view-based app I can only refer to this resource: https://developer.android.com/jetpack/compose/migrate/interoperability-apis/compose-in-views
You will also need to provide a material2 or material3 compose theme to make it look as you want.
I hope that helps.


How to use resolve.rc file with desktop shortcut?

I've been trying a myriad of different syntaxes to add the environment variable
RESOLVE_RC_PATH=./resolve.rc
to the bash line in the desktop file and so far nothing is working.
(I need internet access to the container for use with a network library. )

So in ~/.local/share/applications/resolve.desktop try changing this line:
 Exec=bash -c "cd $HOME/containers/resolve && ./resolve.sh"

to
 Exec=bash -c "cd $HOME/container/resolve && env RESOLVE_RC_PATH=$HOME/container/resolve/resolve.rc ./resolve.sh

See if that works for ya!  (depending on your directory names, you may need to make adjustments)

Aha! That syntax does work. I had not tried using 'env' within the quotes of the bash line but it makes sense.
It would be great if this little tidbit was on the main instructions page.

Or maybe just put it there by default?  Anyone have any opinions?

Added a pr for this, so gonna close


Provide color-blind compatible CSS stylesheet for site and docs

A user has informed us that the site's background and font color combination make the site unreadable to people with red-green color-blindness.
I therefore propose that we add an alternative stylesheet to allow users to view the site.

I changed the CSS stylesheet to be more readable for those who have red-green color-blindness.


exp/ingest/ledgerbackend: Wrap metaPipe in bufio.Reader

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.
[ ] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[ ] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[ ] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
Wraps metaPipe in stellarCoreRunner in bufio.Reader. This improves the speed of reading from a meta pipe.
Why
In https://github.com/stellar/go/commit/936bc3adad5fd2abded25cbfcd404106e410caed we removed bufio.Reader based on an observation that it slows down reading from a pipe. However, after running a CPU profiler on reingestion code to debug another change I realized that a lot of time is spent on reading from a pipe in methods like xdr.Decoder.DecodeInt or xdr.Decoder.DecodeUint (that read just 4 bytes):

When reingesting 1000 ledgers all executions of this method take 17% of entire run time! It was clear that there's an overhead time connected to reading from a pipe. After wrapping meta pipe in bufio.Reader the speed of reingestion of the same range improved by 25% (this isn't affected by Stellar-Core init time, the timer starts after PrepareRange is done).
Before:
INFO[2020-06-30T12:03:44.671+02:00] Reingestion done     duration=74.352344343 from=29999000 pid=44533 service=expingest to=30000000

After:
INFO[2020-06-30T12:06:14.829+02:00] Reingestion done     duration=55.449094814 from=29999000 pid=45181 service=expingest to=30000000

The change in https://github.com/stellar/go/commit/936bc3adad5fd2abded25cbfcd404106e410caed solves the problems with reflection used in XDR decoder being slow. This commit mitigates issues with overhead time added when reading from a pipe.
Known limitations
It's worth checking if there is a similar speed improvement on linux systems (I'm running MacOS), it can be system dependent.

@2opremio because you have more in-depth info about this, do you want to check before I merge?

I did, I just didn't approve because Tamir slr had.


Add option to sort search results

Right now, the API seems to do no sorting at all; it just takes the complete list of icons, and filters out those which don't match the query and filter options, this leaves for some weird search results though.
You would expect if one searched "home", for all icons named "home" to come first, icons that are almost "home" (like "homes" or "add-home") to come second, and so forth, but this is not the case. Instead, the icons are ordered exactly as they are originally listed (presumably alphabetically, separated by icon sets). So, I think it would be useful to either add an option to sort the icons by relevancy or have that be the default.
I thought about doing this client side, but then you can run into cases where there might be an icon named "home" that is past the 999 icon mark (and is completely missed), even though that should be one of the first results.
Assuming you think this is a viable option, I could also attempt a pull request.

Problem is, many icon sets use theme prefixes/suffixes, like home-outline, which is a home icon, so if sorting alphabetically, home-outline would be shown after something like home-add, which would not be a desired icon.
Current algorithm prioritises full keywords, so first it shows everything that contains home with either - or nothing before/after it, so icons like home, home-outline are shown first. Then icons with 1 added character before/after it, like homes, then 2 and so on.
You do have a very good idea, but need to figure out how to take into account prefixes/suffixes.

Thanks a lot for noticing bug in docs! I've fixed it, metadata docs now have correct documentation for prefixes and suffixes properties. Refresh page to see new docs. themes key is deprecated and no longer used in any icon set.
Themes are used for icon sets where all icons belong to some theme. Material Symbols is not one of those sets, even though it does contain icons that end with outline and other viable suffixes. Google Material Icons is a good example because it includes 5 distinct variations of icons. Icons in Material Symbols are mostly just ports of old Google Material Icons, so they have suffixes.

I'm also noticing the search has problems with unseparated words in names, like how simple icons names their icons. If you search Google Drive, the icon from Simple Icons doesn't show because the search is not looking for googledrive (with no dashes). The googledrive from Articons also doesn't show up in the search because it doesn't have dashes.

Fixed in next branch. I'll probably put new version with fix on servers this weekend.

Found a solution, which seems to work fine.
Idea is to extract prefixes/suffixes from icon set + known prefixes/suffixes, add icon name length to each icon based on name - length of longest matched suffix/prefix. This results in home and home-outline having same length of 4 due to -outline' being a suffix, home-addhaving length of 8. When searching, sort results by that length, sohome-outlinewould appear beforehome-add`.
There is a small downside with such approach though. When searching for arrow left, first result is mdi:format-pilcrow-arrow-left because it is an alias of mdi:rtl, so it has length of 3 while matching arrow-left. These weird results are rare though.

Thanks for all the help! I just tried out the new search from the API and it works just as expected. This, along with the unseparated words fix, significantly improves the search :tada:.

Yes, difference is huge. Didn't expect that.
This probably is the best issue so far, wouldn't have even considered changing search engine without it. Thank you very much!
I'll put new version on servers this weekend. It requires removing servers from network, which increases load on other servers, so better to do it at weekend when load is lowest.

One more thing I'm noticing, maybe this has to do with having multiple words, but searching adobe after (and even adobe after effe) pulls up most of the expected icons, except for the one from simple icons (adobeaftereffects). When I search adobe after effects (it has to be the full exact name), it does show the simple icons version.
This has already been a huge help, so if it's too much work, we can just leave it.

Fixed

Awesome, thanks! I'll go ahead and close this issue.


Dynamic font size in display label

Currently display_label is hard coded Times 20 font. When characters to be displayed exceeds 17, initial characters are sliced off to prevent breaking of display_label (TLabel) widget (grid : row=0, column=0, columnspan=4).
A better approach would be to reduce the font size when characters to be displayed exceeds the width of display_label.
Note: Currently resizing the window in disabled. So the width of display_label is constant.

Is this issue solved?

@akshaysonawaneS This issue is open. Please feel free to share your ideas on this issue.

Is anyone working on this issue? I would like to work on it.

@vartikably, no one is currently working on this issue. Do proceed to work on this.
Let me know if you want to be assigned to this issue :nerd_face:

@maddypie wanted to know clear a doubt regarding this issue:
Till what limit the size should be reduced?

@vartikably, Keep it a maximum of 17 characters in Times 20 font.


Switching to IdentityDivision ADAL for Upstream Feeds

Tito made a change to consolidate all of the dependencies in one upstream feed.
See: https://msazure.visualstudio.com/One/_git/AD-MFA-phonefactor-phoneApp-android/pullrequest/2206322?path=%2FPhoneFactor%2Fapp%2Fbuild.gradle&_a=overview

Thanks @rpdome . Are you planning to do this for all other repos too ?

It would also be good to update the Readme.md to reflect this change

@kreedula https://github.com/AzureAD/ad-accounts-for-android/pull/1185


Initialize application

The TeamsApplication component should take care of all the necessary initialization of the application. This initialization would provide the application with the context information that the Teams SDK provides applications with the getContext SDK function.

Implemented.

Implemented.


Unknown command: bot

Running npx medplum bot deploy <bot-name> gives error Unknown command: bot

I tried npx medplum --version, npx medplum -v, npx medplum help - none of them work...
Looking at<EMAIL_ADDRESS>I see:
"name": "@medplum/cli",
"version": "2.0.13",

Running npm i does not change anything.

Just to clarify: it was working just fine, and after trying in a few days - i start to see that error. However I didn't change anything on my side and the error looks weird.
My medplum is behind a VPN, so if I don't use VPN, I see error FetchError: request failed, that means the command actually exists. But if I use VPN and it suppose to work - error is Unknown command: bot which drives me crazy...
Can I enable debug or something?

Hi @art1c0 - I believe the feature  you are looking for was released in version 2.0.16, in this PR.
You can find the commands supported in version 2.0.13 here.

@rahul1 thank you for the hint!
Actually the reason is here: https://github.com/medplum/medplum-demo-bots/blob/b0e8edbfeb0f8884aeb8f161dc4883632ca76a49/package.json#L17
Fixed version to 2.0.13 that does not support command described in the docs here https://www.medplum.com/docs/bots/bots-in-production

Ah i see @art1c0 . Thank you for the pointer! We've updated that package.json with the latest version of the CLI library, so the documentation and repo should be in sync. Sorry for the inconvenience!
https://github.com/medplum/medplum-demo-bots/pull/134


Any plans to make it compatible with other keyboards ?

@powerlemming
If you request a keyboard you want to use, I'll add it. Or, you can even add it by yourself. Please look at https://github.com/yskoht/keymapviz/pull/3 .

I welcome your contribution! Please send me any pull request :)

Could you give me guidelines as to what exactly I must add/include/change ?

@powerlemming
https://github.com/yskoht/keymapviz/blob/master/CONTRIBUTING.md


Clean the implementation of isAutoHeightEnabledForWidget

[ ] Using flags for a specific purpose is difficult in terms of readability.
[ ] Create a new function which does this special computation that is done today using the flag.
[ ] Refactor any references.

Originally posted by @marks0351 in https://github.com/appsmithorg/appsmith/pull/19082#discussion_r1086240821

hey @riodeuno I want to work on this issue so can you please elaborate it more

Can you assign that to me ?

heyy can you assign me that issue

@mudgil09 I'll be happy to assign this to you.
@YoussefAbdellatif I apologise for not getting to this sooner. Please check out one of the other Good First Issue tagged issues. I'll be happy to assign them to you.

@mudgil09 are you working on this issue

@nikhil-babar While we wait for @mudgil09 to respond. Would you like to try resolving this? Please let me know, and I can assign this to you.

Yes, please assign me this issue. It would be my first open source contribution

Done. I have assigned this to you.


console-discord?

What is console-discord?

@suprix where you can host your discord bot and your server at the same time.

o nice


docs: Array Type: fix link to list functions

I noticed the link is leading to the wrong page.

Thanks!


Babel resolver Needed server side

#963

Can we have more info on this?

Haven't looked into the root cause yet. But this was the origin issue #962

@timneutkens could you give me some re-producible steps. So, I can check this properly.

@arunoda

download the with-router example
revert my changes in #963
Run the example

This has been resolved.


feat: New @ohif/viewer project structure + routes

OHIF-116
Description
This PR creates a "new" @ohif/viewer project structure and adds basic route navigation for Study List / and Viewer /viewer/:id.
More cleaning in the project can be done later, such as package.json and/or webpack config. The purpose with this PR was just to have a fresh viewer to start the new implementation.

@dannyrb @galelis
As already discussed, I've reverted this branch to work on the same structure we currently have in platform/viewer doing just clean up to have a fresh project to start implementing the next steps.
A new PR Review is needed. Thanks :)


Bounding boxes don't match node visuals

When selecting nodes, it seems to be that the "hitbox" for the nodes are way bigger than the visuals for the node:

This is especially annoying when trying to select a connection that connects to the same node (yeah that's actually useful in chigraph, think looping):

That's true. The node's shadow belongs to the bounding box as well


It was not possible to find any compatible framework version Preview 7

I recently attempted to install Preview 7 on a machine and after installing, I get this message when I run dotnet --info
 pwsh> dotnet --info
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '3.0.0-preview7-27912-14' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Program Files\dotnet\
  - Installing .NET Core prerequisites might help resolve this problem:
      https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
      2.2.6 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Host (useful for support):
  Version: 2.2.6
  Commit:  7dac9b1b51

.NET Core SDKs installed:
  2.1.801 [C:\Program Files\dotnet\sdk]
  2.2.401 [C:\Program Files\dotnet\sdk]
  3.0.100-preview7-012821 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Looks like the SDK installs, but the runtime does not. If I try to run a repair, I get this error

and fatal error on the repair failed screen 0x80070643. Here is the log file
[21CC:27DC][2019-08-12T09:44:01]i001: Burn v<IP_ADDRESS>18, Windows v10.0 (Build 18956: Service Pack 0), path: C:\Users\islevin\AppData\Local\Temp\{8525C570-7761-4F74-8AA4-17AA5739A9BD}\.cr\dotnet-sdk-3.0.100-preview7-012821-win-x64 (1).exe
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETHOME_X86' to value '[ProgramFilesFolder]dotnet'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETHOME_X64' to value '[ProgramFiles64Folder]dotnet'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETHOME' to value '[DOTNETHOME_X64]'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'BUNDLEMONIKER' to value 'Microsoft .NET Core SDK 3.0.100 - preview7'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETSDKVERSION' to value '3.0.100-preview7-012821'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETRUNTIMEVERSION' to value '3.0.0-preview7-27912-14'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'ASPNETCOREVERSION' to value '3.0.0-preview7.19365.7'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'WINFORMSANDWPFVERSION' to value '3.0.0-preview7-27912-14'
[21CC:27DC][2019-08-12T09:44:01]i000: Initializing string variable 'DOTNETHOMESIMILARITYCHECKOVERRIDE' to value ''
[21CC:27DC][2019-08-12T09:44:01]i009: Command Line: '"-burn.clean.room=C:\Users\islevin\Downloads\dotnet-sdk-3.0.100-preview7-012821-win-x64 (1).exe" -burn.filehandle.attached=588 -burn.filehandle.self=552'
[21CC:27DC][2019-08-12T09:44:01]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\islevin\Downloads\dotnet-sdk-3.0.100-preview7-012821-win-x64 (1).exe'
[21CC:27DC][2019-08-12T09:44:01]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\islevin\Downloads\'
[21CC:27DC][2019-08-12T09:44:01]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401.log'
[21CC:27DC][2019-08-12T09:44:01]i000: Setting string variable 'WixBundleManufacturer' to value 'Microsoft Corporation'
[21CC:41EC][2019-08-12T09:44:01]i000: Setting numeric variable 'WixStdBALanguageId' to value 1033
[21CC:41EC][2019-08-12T09:44:01]i000: Setting version variable 'WixBundleFileVersion' to value '<IP_ADDRESS>21'
[21CC:27DC][2019-08-12T09:44:02]i100: Detect begin, 11 packages
[21CC:27DC][2019-08-12T09:44:02]i000: Setting numeric variable 'DotnetInstallLocationExists_x64' to value 1
[21CC:27DC][2019-08-12T09:44:02]i000: Setting numeric variable 'DotnetInstallLocationExists_x86' to value 1
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'DotnetInstallLocationExists_x64' evaluates to true.
[21CC:27DC][2019-08-12T09:44:02]i000: Setting string variable 'DOTNETHOME_X64' to value 'C:\Program Files\dotnet'
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'NOT DotnetInstallLocationExists_x64' evaluates to false.
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'DotnetExeExists_x64' evaluates to false.
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'DotnetInstallLocationExists_x86' evaluates to true.
[21CC:27DC][2019-08-12T09:44:02]i000: Setting string variable 'DOTNETHOME_X86' to value 'C:\Program Files (x86)\dotnet'
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'NOT DotnetInstallLocationExists_x86' evaluates to false.
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'DotnetExeExists_x86' evaluates to false.
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_hostfxr_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_host_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: windowsdesktop_runtime_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: netstandard_targeting_pack_2.1.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_apphost_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: aspnetcore_targeting_pack_3.0.0_preview7.19365.7_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: windowsdesktop_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: dotnet_sdk_internal_3.0.100_preview7_012821_win_x64.msi, state: Present, cached: Complete
[21CC:27DC][2019-08-12T09:44:02]i101: Detected package: AspNetCoreSharedFramework_x64, state: Present, cached: None
[21CC:27DC][2019-08-12T09:44:02]i052: Condition 'WixBundleInstalled OR ((NOT (DOTNETHOME_X64 ~= DOTNETHOME_X86)) OR DOTNETHOMESIMILARITYCHECKOVERRIDE)' evaluates to true.
[21CC:27DC][2019-08-12T09:44:02]i199: Detect complete, result: 0x0
[21CC:27DC][2019-08-12T09:44:03]i200: Plan begin, 11 packages, action: Repair
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_000_dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_hostfxr_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_001_dotnet_hostfxr_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_host_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_002_dotnet_host_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_windowsdesktop_runtime_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_003_windowsdesktop_runtime_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_004_dotnet_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_netstandard_targeting_pack_2.1.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_005_netstandard_targeting_pack_2.1.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_apphost_pack_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_006_dotnet_apphost_pack_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_aspnetcore_targeting_pack_3.0.0_preview7.19365.7_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_007_aspnetcore_targeting_pack_3.0.0_preview7.19365.7_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_windowsdesktop_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_008_windowsdesktop_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_dotnet_sdk_internal_3.0.100_preview7_012821_win_x64.msi' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_009_dotnet_sdk_internal_3.0.100_preview7_012821_win_x64.msi.log'
[21CC:27DC][2019-08-12T09:44:03]i052: Condition 'VersionNT64 AND (NOT OPT_NO_SHAREDFX)' evaluates to true.
[21CC:27DC][2019-08-12T09:44:03]i000: Setting string variable 'WixBundleLog_AspNetCoreSharedFramework_x64' to value 'C:\Users\islevin\AppData\Local\Temp\Microsoft_.NET_Core_SDK_3.0.100_-_preview7_(x64)_20190812094401_010_AspNetCoreSharedFramework_x64.log'
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_hostfxr_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_host_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: windowsdesktop_runtime_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: netstandard_targeting_pack_2.1.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_apphost_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: aspnetcore_targeting_pack_3.0.0_preview7.19365.7_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: windowsdesktop_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: dotnet_sdk_internal_3.0.100_preview7_012821_win_x64.msi, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: No, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i201: Planned package: AspNetCoreSharedFramework_x64, state: Present, default requested: Repair, ba requested: Repair, execute: Repair, rollback: None, cache: Yes, uncache: No, dependency: Register
[21CC:27DC][2019-08-12T09:44:03]i299: Plan complete, result: 0x0
[21CC:27DC][2019-08-12T09:44:03]i300: Apply begin
[21CC:27DC][2019-08-12T09:44:03]i010: Launching elevated engine process.
[21CC:27DC][2019-08-12T09:44:04]i011: Launched elevated engine process.
[21CC:27DC][2019-08-12T09:44:04]i012: Connected to elevated engine.
[1FE0:4E2C][2019-08-12T09:44:04]i358: Pausing automatic updates.
[1FE0:4E2C][2019-08-12T09:44:04]i359: Paused automatic updates.
[1FE0:4E2C][2019-08-12T09:44:04]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ec370edb-3a7c-4ba7-9181-5440be546ec5}, resume: Active, restart initiated: No, disable resume: No
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{AF8250BF-4F90-485A-BBB4-9045A1F6F22F}v24.0.27912\dotnet-runtime-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:4E2C][2019-08-12T09:44:05]i301: Applying execute package: dotnet_runtime_3.0.0_preview7_27912_14_win_x64.msi, action: Repair, path: C:\ProgramData\Package Cache\{AF8250BF-4F90-485A-BBB4-9045A1F6F22F}v24.0.27912\dotnet-runtime-3.0.0-preview7-27912-14-win-x64.msi, arguments: ' ARPSYSTEMCOMPONENT="1" DOTNETHOME="C:\Program Files\dotnet"'
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_hostfxr_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{57183144-29FB-44D2-96F6-A48A95F61CB1}v24.0.27912\dotnet-hostfxr-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_host_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{C25212B6-08CD-40FD-ACC2-6226021259CC}v24.0.27912\dotnet-host-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: windowsdesktop_runtime_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{F2B79D48-ECFF-4AC9-BC3E-8A956BB9BD8F}v24.0.27912\windowsdesktop-runtime-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{A8184A62-4A41-4E8A-A062-4315B5844CCF}v24.0.27912\dotnet-targeting-pack-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: netstandard_targeting_pack_2.1.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{1A8086D8-7D30-48A5-9697-F0FD46275114}v24.0.27912\netstandard-targeting-pack-2.1.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_apphost_pack_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{37E8A4EE-D54D-4A2F-9BB3-7968290AF65F}v24.0.27912\dotnet-apphost-pack-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: aspnetcore_targeting_pack_3.0.0_preview7.19365.7_win_x64.msi at path: C:\ProgramData\Package Cache\{958360C9-CA9B-3E69-B6CC-27A1DFBFB408}v<IP_ADDRESS>\aspnetcore-targeting-pack-3.0.0-preview7.19365.7-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: windowsdesktop_targeting_pack_3.0.0_preview7_27912_14_win_x64.msi at path: C:\ProgramData\Package Cache\{61825133-7EC5-4AA7-8AC3-DAC98E0E3A83}v24.0.27912\windowsdesktop-targeting-pack-3.0.0-preview7-27912-14-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: dotnet_sdk_internal_3.0.100_preview7_012821_win_x64.msi at path: C:\ProgramData\Package Cache\{1A9C4CE3-DA05-4969-AA9F-FA372306713A}v12.0.12821\dotnet-sdk-internal-3.0.100-preview7-012821-win-x64.msi.
[1FE0:3F88][2019-08-12T09:44:05]i304: Verified existing payload: cab7E2DC32E1D6EFC9552C82AF7F0F2C489 at path: C:\ProgramData\Package Cache\{1A9C4CE3-DA05-4969-AA9F-FA372306713A}v12.0.12821\dx64-1.cab.
[1FE0:3F88][2019-08-12T09:44:05]e000: Error 0x80070002: Failed to find payload: AspNetCoreSharedFramework_x64 in working path: C:\Users\islevin\AppData\Local\Temp\{B83A5F8D-283E-4063-BBD8-D757A04A9900}\AspNetCoreSharedFramework_x64 and unverified path: C:\ProgramData\Package Cache\.unverified\AspNetCoreSharedFramework_x64
[1FE0:3F88][2019-08-12T09:44:05]e000: Error 0x80070002: Failed to cache payload: AspNetCoreSharedFramework_x64
[21CC:2E6C][2019-08-12T09:44:05]e314: Failed to cache payload: AspNetCoreSharedFramework_x64 from working path: C:\Users\islevin\AppData\Local\Temp\{B83A5F8D-283E-4063-BBD8-D757A04A9900}\AspNetCoreSharedFramework_x64, error: 0x80070002.
[21CC:2E6C][2019-08-12T09:44:05]e349: Application requested retry of payload: AspNetCoreSharedFramework_x64, encountered error: 0x80070002.  Retrying...
[1FE0:4E2C][2019-08-12T09:45:59]i301: Applying execute package: AspNetCoreSharedFramework_x64, action: Repair, path: C:\ProgramData\Package Cache\{1D8E1EF4-2D42-3B1D-97B2-099AF85F20A3}v<IP_ADDRESS>\AspNetCoreSharedFramework-x64.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" DOTNETHOME="C:\Program Files\dotnet"'
[1FE0:4E2C][2019-08-12T09:46:01]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[1FE0:4E2C][2019-08-12T09:46:01]e000: Error 0x80070643: Failed to execute MSI package.
[21CC:27DC][2019-08-12T09:46:01]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[21CC:27DC][2019-08-12T09:46:01]w348: Application requested retry of package: AspNetCoreSharedFramework_x64, encountered error: 0x80070643. Retrying...
[1FE0:4E2C][2019-08-12T09:46:04]i301: Applying execute package: AspNetCoreSharedFramework_x64, action: Repair, path: C:\ProgramData\Package Cache\{1D8E1EF4-2D42-3B1D-97B2-099AF85F20A3}v<IP_ADDRESS>\AspNetCoreSharedFramework-x64.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" DOTNETHOME="C:\Program Files\dotnet"'
[1FE0:4E2C][2019-08-12T09:46:05]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[1FE0:4E2C][2019-08-12T09:46:05]e000: Error 0x80070643: Failed to execute MSI package.
[21CC:27DC][2019-08-12T09:46:05]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[21CC:27DC][2019-08-12T09:46:05]w348: Application requested retry of package: AspNetCoreSharedFramework_x64, encountered error: 0x80070643. Retrying...
[1FE0:4E2C][2019-08-12T09:46:08]i301: Applying execute package: AspNetCoreSharedFramework_x64, action: Repair, path: C:\ProgramData\Package Cache\{1D8E1EF4-2D42-3B1D-97B2-099AF85F20A3}v<IP_ADDRESS>\AspNetCoreSharedFramework-x64.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" DOTNETHOME="C:\Program Files\dotnet"'
[1FE0:4E2C][2019-08-12T09:46:10]e000: Error 0x80070643: Failed to run maintanance mode for MSI package.
[1FE0:4E2C][2019-08-12T09:46:10]e000: Error 0x80070643: Failed to execute MSI package.
[21CC:27DC][2019-08-12T09:46:10]e000: Error 0x80070643: Failed to configure per-machine MSI package.
[21CC:27DC][2019-08-12T09:46:10]i319: Applied execute package: AspNetCoreSharedFramework_x64, result: 0x80070643, restart: None
[21CC:27DC][2019-08-12T09:46:10]e000: Error 0x80070643: Failed to execute MSI package.
[1FE0:4E2C][2019-08-12T09:46:10]i351: Removing cached package: AspNetCoreSharedFramework_x64, from path: C:\ProgramData\Package Cache\{1D8E1EF4-2D42-3B1D-97B2-099AF85F20A3}v<IP_ADDRESS>\
[1FE0:4E2C][2019-08-12T09:46:10]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ec370edb-3a7c-4ba7-9181-5440be546ec5}, resume: ARP, restart: None, disable resume: No
[1FE0:4E2C][2019-08-12T09:46:10]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ec370edb-3a7c-4ba7-9181-5440be546ec5}, resume: ARP, restart initiated: No, disable resume: No
[21CC:27DC][2019-08-12T09:46:10]i399: Apply complete, result: 0x80070643, restart: None, ba requested restart:  No

Thanks for contacting us, @isaac2004.
@livarcocc who would be best positioned to look into this?

@isaac2004 It's odd that there's no 3.0 runtime listed. I have that same SDK version installed and see the following runtime in the output when I run dotnet --list-runtimes:
Microsoft.AspNetCore.App 3.0.0-preview7.19365.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

@johnbeisner to take a look.
@isaac2004 did you manually delete files from the program files folder by any chance?

I did yes... I imagine that is an issue?

Looks like the issue was on my side, I deleted some folders I was not supposed to, thanks @livarcocc for helping me out!

@isaac2004
What did you deleted ?
I have the same issue.

Repair throw this error 4 times
Uninstall take like 100ms, probably fail and does nothing saying everything is ok
Install after "uninstall" take like 100ms, probably fail and does nothing saying everything is ok

Is there any tool that could be ran to fully cleanup any registered Component or whatever to make the installer properly installed ?

I get the same thing installing core 3 after having had the preview installed.

I'm also receiving this issue now, when trying to install the new SDK 3.0.100 (x64) version of dotnet core

I had the same issue today, but after installing x86 (as well as x64) it worked

@livarcocc @isaac2004
should it be re opened ?
i escaped from that issue because i had to change my computer so i'm kinda lucky to be honest
this sounds like an issue from one of the preview installation depending on if it was installed from VsUpdate or dot.net
As people are hit by this even after the release, it would be lovely to have a tool that fully erase all disk / cache / regedit / etc ... if any single dotnet sdk at once
As when the bug hit me the "installation" did nothing and said "installed in 0.5sec"
it sounds like a silent throw in the installation process or uninstall
having a dumb listing and "wipe them all" script to do a full clean could help solving this

Hello,
I have the exact same problem is it possible to reopen this issue ?

Thanks for contacting us, folks. This issue was Preview 7 specific. If you're observing similar issues with 3.0 SDK (RTM) please file a new issue and provide as many details as possible for us to investigate.

Well the issue is that once you get the preview7 bug you cannot install further sdk ;)
that's the big issue
as said i was lucky at work because i received a new laptop
based on the date of the new issue here i supposed they had preview7 install but can't update to 3.0.100 because the cleanup seems no to go that well
(again i'm guessing for them because when i had the issue i could not install preview8 or preview9 later on)

I'm seeing this issue also

I am seeing this issue also, after trying to repair the 3.0.1 .NET Core after installing the 3.1 Preview

@mkArtakMSFT
Very sorry to ping you again but it does not seems limited to 3.0.100-preview
Should it be reopened / title changed or new issue ?

No problem, @tebeco. Go ahead and file a new issue and provide a new repro, if possible with relevant details, so we can investigate it.

@mijunk
@victorprocure
@cihlen
@moleskeen
@kmiller77
@mgoldshteyn
I suggest that one of you open a new issue ;)
My laptop was formatted so I don’t have any diagnostic data to feed there but I could re explain there all attempt I made
I also suggest you describe what version you had installed before updating the SDK
And if you updated through Vs2019 or manually

https://github.com/aspnet/AspNetCore/issues/15169


Use semantic-release and automate releases in Github Actions

Now that right version of docker-pyinstaller is available on Docker hub, it should be possible to automate the release process with
semantic-release.

Done :tada:


Remove node access from virt-handler

What this PR does / why we need it:
As of today a virt-handler has "full" access to all Nodes. Therefore installing Kubevirt means that every node will have a service account that can be miss used to influence the scheduling of other Pods, potentially with a more privileged service account.
This PR introduces ShadowNode CRD, intended for internal use for virt-handler. The virt-handler will keep read access to nodes but will lose write access. Write will be "proxied" through ShadowNode object and write to the actual Node  will be done by virt-controller who will filter what type of labels and annotations will be proxied.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
There are a few cons to the approach. Creating 1:1 shadow nodes to nodes and therefore increasing the #api calls we do and storage we take.
Because we "proxy" the node updates we now depend on the availability of virt-controller and we increase the work required by virt-controller. In the worst case, we can see heartbeat timeout more in corner cases. The latency of sync increases because we remove the "test" on the node.
For less critical issues, right now we remove any .* kubevirt.io .* label and annotation. This might break a few cases where we or others use these labels to enhance scheduling or other functionality.
Release note:
NONE

/test ?

/test pull-kubevirt-e2e-k8s-1.25-sig-compute
/test pull-kubevirt-e2e-k8s-1.26-sig-operator

/test pull-kubevirt-e2e-k8s-1.26-sig-compute
/test pull-kubevirt-e2e-k8s-1.25-sig-compute-migrations
/test pull-kubevirt-e2e-k8s-1.26-sig-operator
/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-e2e-k8s-1.26-sig-storage

/retest

This PR introduces ShadowNode CRD, intended for internal use for virt-handler. The virt-handler will keep read access to nodes but will lose write access. Write will be "proxied" through ShadowNode object and write to the actual Node will be done by virt-controller who will filter what type of labels and annotations will be proxied.

This idea sounds like you're putting a shim between the RBAC policy and RBAC controller, similar to the way the scheduler is broken down to pluggable steps.   This might be a useful KEP.

/cc

There are a few cons to the approach. Creating 1:1 shadow nodes to nodes and therefore increasing the #api calls we do and storage we take. Because we "proxy" the node updates we now depend on the availability of virt-controller and we increase the work required by virt-controller. In the worst case, we can see heartbeat timeout more in corner cases.

I noticed that virt-handler is now pushing the heartbeat to the shadow node, but the controller side still seems to take the heartbeat timestamp on the node as the source of truth and there is really just a "mirror" injected?
If that is not what is happening already, I would suggest the following:

there should be no reason anymore for us to put annotations on the node. Everything which is now an annotation on the node should only be used internally by virt-controller, and the virt-controller (especially node.go) can now directly read the heartbeat from the shadow node. As such there is not increase of likelyhood of seeing heartbeat issues. The shadow node also has a proper status section now. A heartbeat annotation would be a great fit for a status condition. Finally we can shape the API :)
there shold only be a need to synchronize labels for scheduling purposes to the real node
Since we can't start VMs if virt-controller is down, there should not be really a con left. If virt-controller is down, true nothing gets synced, but also nothing can start anyway.

The latency of sync increases because we remove the "test" on the node.

I may figure out what you mean when finally having checked the whole PR, but could you outline what you mean by that?

For less critical issues, right now we remove any .* kubevirt.io .* label and annotation. This might break a few cases where we or others use these labels to enhance scheduling or other functionality.

*.kubevirt.io/ is our domain. Synchronizing on it should be fine. I can also see that some people may have chosen to use our label domain as well, but I think owning such a label domain is a well enough established convention to delete unknown labels.

I am btw. also very keen on not having to continue to periodically update an annotation on the node. I have over the years quite a few issues around that. Not that we do anythying wrong or uncommon here, actually always other controllers were the root cause (like too long reconcile periods, just overriding annotations, ...) but less surface which can cause issues is great.

This idea sounds like you're putting a shim between the RBAC policy and RBAC controller, similar to the way the scheduler is broken down to pluggable steps. This might be a useful KEP.

@rthallisey I will update the PR description with some alternatives. Generally speaking, a Kubernetes solution for this problem could be delivered in a year or two(Note this problem is not specific to Kubevirt). Therefore I think this is a viable short-term improvement/fix.

@rmohr PTAL, I noticed we do miss rolback e2e test. Please double-check check this has a chance to work.

Note for me: I need to update the description outlining the approach.

Out for a week. Will review next week.

/hold
Seeing DaemonSet killing all DSes. Somehow I triggered some edge cases.

@xpivarc o/
Is there a design doc or something similar outlining the solution ?

@xpivarc o/
Is there a design doc or something similar outlining the solution ?

There is nothing online available. Do you have any concerns? Would you like to see one?

@xpivarc o/
Is there a design doc or something similar outlining the solution ?

There is nothing online available. Do you have any concerns? Would you like to see one?

I don't have any concerns at the moment, but I spent 0 seconds thinking about this problem.
I would like to see one. Isn't that the common practice for a new feature ? You're even adding a new CRD IIUC.

@xpivarc o/
Is there a design doc or something similar outlining the solution ?

There is nothing online available. Do you have any concerns? Would you like to see one?

I don't have any concerns at the moment, but I spent 0 seconds thinking about this problem.
I would like to see one. Isn't that the common practice for a new feature ? You're even adding a new CRD IIUC.

Not necessary, we usually do a design document/proposal only for bigger features. This is more of a "bug" fix, an internal change that does not have user-facing changes. I can draft something up if there is a need for it.

Flake is not related - see https://github.com/kubevirt/kubevirt/pull/10417

@maiqueb @lzang I have created a design doc https://github.com/kubevirt/community/pull/246

@lzang I hope I answered all of your comments. I will rebase this PR in the upcoming days.

@lzang PTAL

@xpivarc overall looks good to me as long as the upgrade case is tested, i.e there is a transitional period where both nodes and shadownodes are updated before the virt-controller is updated.

@xpivarc overall looks good to me as long as the upgrade case is tested, i.e there is a transitional period where both nodes and shadownodes are updated before the virt-controller is updated.

The upgrade is covered by the existing test.

/hold cancel

@xpivarc this PR came up for discussion in couple of sigs (sig-scale and sig-api). Because this is a somewhat larger change and affects multiple CRDs (nodes, shallownodes), I wonder if we need a design doc explaining the advantage from the change, seemless upgrades and scale impact from the change
/cc @EdDev @mooperd

@xpivarc this PR came up for discussion in couple of sigs (sig-scale and sig-api). Because this is a somewhat larger change and affects multiple CRDs (nodes, shallownodes), I wonder if we need a design doc explaining the advantage from the change, seemless upgrades and scale impact from the change
/cc @EdDev @mooperd

I have updated the description.

@xpivarc would you be interested in running through this PR with me in a call? I'd really like to understand the attack surface more and what exactly these changes are intended to mitigate.

@xpivarc would you be interested in running through this PR with me in a call? I'd really like to understand the attack surface more and what exactly these changes are intended to mitigate.

This PR is targeting https://github.com/kubevirt/kubevirt/security/advisories/GHSA-cp96-jpmq-xrr2. If you have any questions you can find me on Kubernetes Slack under @Luboslav Pivarc

Thanks @xpivarc. I am a bit confused about this line:
If a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs.
Please could you clarify it? If a node is compromised then all virt-handler processes can be compromised via the Service Account? A kind of cluster wide privilege escalation?

Thanks @xpivarc. I am a bit confused about this line:
If a malicious user has taken over a Kubernetes node where virt-handler (the KubeVirt node-daemon) is running, the virt-handler service account can be used to modify all node specs.
Please could you clarify it? If a node is compromised then all virt-handler processes can be compromised via the Service Account? A kind of cluster wide privilege escalation?

You possibly could because you could obtain a Service account with exec rights.

I agree with @alaypatel07  @xpivarc this change seems to be signifincant enough to have a deisng proposal in order to undertsand the motivation, and specifically tradeoffs with other implmenetations.
/hold
Until we have the design.

I agree with @alaypatel07 @xpivarc this change seems to be signifincant enough to have a deisng proposal in order to undertsand the motivation, and specifically tradeoffs with other implmenetations.
/hold
Until we have the design.

AFAIK, the PR already references a design proposal.
@xpivarc , it is at the moment marked as "draft". Do you think it is ready for review or you need to invest in it a bit more?

I agree with @alaypatel07 @xpivarc this change seems to be signifincant enough to have a deisng proposal in order to undertsand the motivation, and specifically tradeoffs with other implmenetations.
/hold
Until we have the design.

Please, see the description.

@xpivarc , it is at the moment marked as "draft". Do you think it is ready for review or you need to invest in it a bit more?

un-drafted, I am happy to work on it more if anybody finds it as not good enough.

/uncc

Please, see the description.

Sorry, I was nt expressive enough: Let's hold until we have a merged design.

Replaced by https://github.com/kubevirt/kubevirt/pull/11982


Element hide exception doesn't work if rule contains ~domain

Steps to reproduce

Add these rules:

##body
~adguard.com#@#body

Go to - https://example.org/

Expected behavior
Website should be displayed correctly (shouldn't be "blank").
Actual behavior
Website is blank.
It looks like that generic exception doesn't work if there is ~domain in the rule.
AdGuard for Windows Version 7.11 nightly 12 (build 4048, CL 1.10.80)

@AdamWr Actual behavior can be achieved with rules:
##body
adguard.com#@#body

tilde is redundant here
https://kb.adguard.com/en/general/how-to-create-your-own-ad-filters#exceptions-2


Update and release OTel agent integration distro 0.13.0

This issue is blocked by: https://github.com/newrelic/opentelemetry-exporter-java/issues/145
This project (newrelic-opentelemetry-integration-java) needs to be updated to use the OTel dependencies listed below and we need to release version 0.13.0 of this artifact.
The newrelic-opentelemetry-javaagent module needs to be updated to use the OTel java agent dependency:

io.opentelemetry.javaagent:opentelemetry-javaagent:0.13.1

The custom module needs to be updated to use the New Relic OTel exporter dependencies:

com.newrelic.telemetry:opentelemetry-exporters-newrelic:0.13.1
com.newrelic.telemetry:opentelemetry-exporters-newrelic-auto:0.13.1

The smoke-tests module needs to be updated to use the OTel dependencies:

io.opentelemetry:opentelemetry-proto:0.13.1
io.opentelemetry:opentelemetry-api:0.13.1

Steps:

Update the dependencies used in the newrelic-opentelemetry-javaagent and custom modules. Both can be done here.
Update the dependencies used in the smoke-tests module.
Update the CHANGELOG
Cut a new Github release

Success criteria:

This project (newrelic-opentelemetry-integration-java) builds with the OTel artifacts described above
Before release, verify that the version of this artifact correctly matches the version to be released
A new newrelic-opentelemetry-integration-java artifact is released and published to maven
The CHANGELOG is updated
After release, submit a PR to bump the snapshot version for the next release
All tests pass and the agent distro has been verified to work with the example application

@jasonjkeller  I'm getting the following error when trying to build.  It is for setting the version of the exporter dependency to 0.13.1
Could not GET 'https://oss.jfrog.org/artifactory/oss-snapshot-local/com/newrelic/telemetry/opentelemetry-exporters-newrelic/0.13.1/opentelemetry-exporters-newrelic-0.13.1.pom'. Received status code 409 from server:

Could not resolve com.newrelic.telemetry:opentelemetry-exporters-newrelic-auto:0.13.1.

If I try 0.13.0 instead for the exporter, it works and builds.  Maven shows 0.13.0 as latest still.
Have you seen this error before?

@jasonjkeller  I'm getting the following error when trying to build.  It is for setting the version of the exporter dependency to 0.13.1
Could not GET 'https://oss.jfrog.org/artifactory/oss-snapshot-local/com/newrelic/telemetry/opentelemetry-exporters-newrelic/0.13.1/opentelemetry-exporters-newrelic-0.13.1.pom'. Received status code 409 from server:

Could not resolve com.newrelic.telemetry:opentelemetry-exporters-newrelic-auto:0.13.1.

If I try 0.13.0 instead for the exporter, it works and builds.  Maven shows 0.13.0 as latest still.
Have you seen this error before?

@XiXiaPdx Sorry, I forgot to update this story yesterday based on some findings. Initially the plan was to release version 0.13.0 and 0.13.1 of these artifacts but that changed because the OTel SDK had a borked version that they published.
TL;DR You should use 0.13.0 for both of these artifacts as those are the versions that were published:

com.newrelic.telemetry:opentelemetry-exporters-newrelic:0.13.0
com.newrelic.telemetry:opentelemetry-exporters-newrelic-auto:0.13.0

@XiXiaPdx Sorry, I forgot to update this story yesterday based on some findings. Initially the plan was to release version 0.13.0 and 0.13.1 of these artifacts but that changed because the OTel SDK had a borked version that they published.
TL;DR You should use 0.13.0 for both of these artifacts as those are the versions that were published:

com.newrelic.telemetry:opentelemetry-exporters-newrelic:0.13.0
com.newrelic.telemetry:opentelemetry-exporters-newrelic-auto:0.13.0

Currently blocked by a failing smoke test, this is failing

Currently blocked by a failing smoke test, this is failing

Currently blocked by a failing smoke test
https://github.com/newrelic/newrelic-opentelemetry-integration-java/blob/1db1cc252c864f3fc221740d96b6eb4c43ff21b3/smoke-tests/src/test/java/com/newrelic/telemetry/BundleTest.java#L47
no metrics were reported
java.lang.AssertionError: no metrics were reported
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at com.newrelic.telemetry.BundleTest.testMetricsAndSpans(BundleTest.java:47)

Expected behavior:
Before trying to update dependencies (so running with version 0.12.0), the test passes and the expected metric processedSpans is produced.
Current behavior:
After updating dependencies, the test fails and the logs indictate an empty metric batch:
22:38:23.333 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:331 +0000] [IntervalMetricReader-1] DEBUG com.newrelic.telemetry.metrics.MetricBuffer - Creating metric batch.
22:38:23.335 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:333 +0000] [Thread-3] DEBUG com.newrelic.telemetry.metrics.MetricBatchSender - Skipped sending of an empty metric batch.
22:38:23.335 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:334 +0000] [Thread-3] DEBUG com.newrelic.telemetry.TelemetryClient - Telemetry - MetricBatch - sent

I think the issue is with the test and not with the artifact.  After updating dependencies, I did build a 0.13.0 snapshot jar and tested it in spring-petclinic.  I can see the processedSpans metric being generated and reported.
It is a mystery why the test is failing. So far, I’ve tried tripling the timeout here and that didn’t do anything.
https://github.com/newrelic/newrelic-opentelemetry-integration-java/blob/1db1cc252c864f3fc221740d96b6eb4c43ff21b3/smoke-tests/src/test/java/com/newrelic/telemetry/MockEdge.java#L29

Currently blocked by a failing smoke test
https://github.com/newrelic/newrelic-opentelemetry-integration-java/blob/1db1cc252c864f3fc221740d96b6eb4c43ff21b3/smoke-tests/src/test/java/com/newrelic/telemetry/BundleTest.java#L47
no metrics were reported
java.lang.AssertionError: no metrics were reported
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at com.newrelic.telemetry.BundleTest.testMetricsAndSpans(BundleTest.java:47)

Expected behavior:
Before trying to update dependencies (so running with version 0.12.0), the test passes and the expected metric processedSpans is produced.
Current behavior:
After updating dependencies, the test fails and the logs indictate an empty metric batch:
22:38:23.333 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:331 +0000] [IntervalMetricReader-1] DEBUG com.newrelic.telemetry.metrics.MetricBuffer - Creating metric batch.
22:38:23.335 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:333 +0000] [Thread-3] DEBUG com.newrelic.telemetry.metrics.MetricBatchSender - Skipped sending of an empty metric batch.
22:38:23.335 [docker-java-stream--1415956929] INFO  com.newrelic.telemetry.Bundle - STDERR: [opentelemetry.auto.trace 2021-01-28 06:38:23:334 +0000] [Thread-3] DEBUG com.newrelic.telemetry.TelemetryClient - Telemetry - MetricBatch - sent

I think the issue is with the test and not with the artifact.  After updating dependencies, I did build a 0.13.0 snapshot jar and tested it in spring-petclinic.  I can see the processedSpans metric being generated and reported.
It is a mystery why the test is failing. So far, I’ve tried tripling the timeout here and that didn’t do anything.
https://github.com/newrelic/newrelic-opentelemetry-integration-java/blob/1db1cc252c864f3fc221740d96b6eb4c43ff21b3/smoke-tests/src/test/java/com/newrelic/telemetry/MockEdge.java#L29

We're not going to make any more updates to the exporter.  We are providing an OTLP endpoint that will support traces, and (shortly) metrics. OR, another alternative is to use the OpenTelemetry Collector.
We were maintaining our exporters until a New Relic OTLP endpoint was ready.  We've reached a point that is close enough to allow customers to migrate to that preferred solution (for use cases where customers do not want to deploy a Collector) rather than adopting this temporary stop-gap.


Cannot run rails console production on server.

Cannot run rails console production on server.
root@myserver:/u/apps/stageapp_production/current# bundle exec rails console production
bin/rails:3:in require_relative': cannot load such file -- /u/apps/stageapp_production/shared/config/boot (LoadError)     from bin/rails:3:in'

@cvandermeer Hi, you can run the console by this command: RAILS_ENV=production bin/rails console.

I get the same error. Issue with ruby or rails perhaps?
bin/rails:3:in require_relative': cannot load such file -- /u/apps/stageapp_production/shared/config/boot (LoadError) 	from bin/rails:3:in '

@cvandermeer Did it work?

No, instead of using rails console production, i used a seed to create a new user.
The command above gives me this error message:
Looks like your app's ./bin/rails is a stub that was generated by Bundler.
In Rails 4, your app's bin/ directory contains executables that are versioned
like any other source code, rather than stubs that are generated on demand.
Here's how to upgrade:
bundle config --delete bin    # Turn off Bundler's stub generator
rake rails:update:bin         # Use the new Rails 4 executables
git add bin                   # Add bin/ to source control
You may need to remove bin/ from your .gitignore as well.
When you install a gem whose executable you want to use in your app,
generate it and add it to source control:
bundle binstubs some-gem-name
git add bin/new-executable
/opt/rbenv/versions/2.1.2/lib/ruby/2.1.0/irb/completion.rb:9:in require': cannot load such file -- readline (LoadError) 	from /opt/rbenv/versions/2.1.2/lib/ruby/2.1.0/irb/completion.rb:9:in <top (required)>'

+1 I'm having this issue as well.  Seems to be related to a recent update as this server environment has been working fine until very recently.

Are you using Capistrano 3 by any chance? I had the same error and this is fixed by this: http://stackoverflow.com/questions/26151443/capistrano-3-deployment-for-rails-4-binstubs-conflict

I am actually, thanks i will look into this.

It worked!

Great! I suspected Capistrano when I noticed 'shared' in the relative path error. Glad you got it fixed.

@richhollis +1 for stackoverflow link, thanks

@cvandermeer I came here from a completely different issue with the same error in 2017 and wanted to share that your comment on 1/20/17 is what resolved it for me. Thanks!


Fix errors in _variables.scss

Add missing import for _assert-ascending mixin.
Use map-get function to get values from the theme-colors map.

These were the minimal fixes I needed to add to get the example in the sass_builder repo working with the latest version of this package.

I just upgraded to version 4.1.3, is this change still needed?

Yeah I just tested and I get the same errors with the updated version. The import and map-get calls are still a problem.
I can push a rebased version of these changes if you like.

what version of sass_builder are you using?
I will merge it, I just don't want to have to edit this file every time bootstrap adds a new version

I'm using the latest version. Oh interesting, you are right, those lines are in the original version too.
https://github.com/twbs/bootstrap/blob/v4-dev/scss/_variables.scss
I wonder how they compile the css so that it works. I might have some time to look into that tomorrow.

Actually I think I found the issue. The example was only import the _variables.scss. If you import the main entry point (bootstrap.scss) everything works fine.
I'll close this PR. Sorry for the noise.


enable continuous reconciliation for all basic deployers

How to categorize this PR?

/area ops-productivity
/kind enhancement
/priority 3
Which issue(s) this PR fixes:
Part of #239
Release note:

TODO

/test


Blob fields not supported

Hello again, I would like to continue reporting some bugs or possible improvements.
After generating backend, panels does not load (js error) if database has any blob fields.  If I edit controller and comment blob fields, the problem is solved.
Regards

Hi, I have patched code to solve de problem, no it's able to handle blob fields.  Updated on my forked version of project ...  could be possible to apply changes on main copy?

Please create a pull request (https://help.github.com/articles/using-pull-requests/) .


1.18.2 rendering overlay crash

When I play the game with this + better combat installed in my custom modpack there's a 80% chance or such of the game crashing. Here's the latest crash log below.
https://pastebin.com/vg9qqB2E
Minecraft 1.18.2

It does not contain any relevant information for this library.
It might caused by Corail Tombstone.
If you're still sure playeranimator is responsible for the crash, please contact me somewhere (kosmx.dev)

It seems like a mod conflict, as disabling this allows it to run with Corail and vice versa. Never the less I'll make a post on the relevant hub.


Flexible Pricing: learners shouldn't be able to enter flexible pricing codes

Summary
Currently because we use discounts as the abstraction to provide flexible pricing, these discounts have discount codes that are able to be manually entered by a learner. Since these codes show up on the checkout page when a learner gets their flexible pricing applied, they're easily discoverable.

Acceptance Criteria

[ ] I'd suggest adding a boolean field to Discount that indicates whether it can be manually applied on the checkout page. Default it to False for some added safety.
[ ] Update the discount APIs to reject discount codes that can't be manually applied
[ ] Update the frontend to display an appropriate error message

Instead of adding a flag, could we make the flexible pricing coupon unique per user?