Applied ~100 suggested code fixes + 2 refactorings

Code fixes:

Consecutive braces must not have blank line between them (1 x)
Convert to file-scoped namespace (~70 x)
Index can be simplified (1 x)
Mark assemblies with NeutralResourcesLanguageAttribute
Member 'xy' does not access instance data and can be marked as static (2 x)
Naming rule violation: Missing prefix: '_' (1 x)
Null check can be simplified (4 x)
Substring can be simplified (5 x)
Use framework type (~10 x)
Use pattern matching (1 x)
Use 'StringBuilder.Append(char)' instead of 'StringBuilder.Append(string)' (2 x)
Use 'switch' expression (2 x)
Using directives must be placed outside of a namespace declaration (3 x)

Refactorings:

Convert to raw string (2 x)

Thanks for this, but note the failing CI build. Also this might take me a bit to review due to the size, so please forgive any delays.

I am using a current version Visual Studio 2022 with C# 11. It looks like the build system on Github is using an older version of C#.

Yes, that's correct. We currently have to target .NET 5 still as support for .NET 6 in IKVM is still in progress. Fortunately there's been some great activity on that project in that regard (including macOS arm64 support), but we might have to wait on that to be complete.

FYI, IKVM's current version runs perfectly fine in .NET 6 and beyond, including 8. The assemblies need to compile targeting 3.1. But 3.1 assemblies run in later CLRs just fine.

With the exception of some features depending on CLR support, the C# version does not depend on the Framework version. I use C# 11 features with .NET 4.x with no problems.

There are several aspects to this conversation and everyone is correct in certain ways 😄
Here's the build output of the CLI app targeting .NET 5 and built with the .NET 7 SDK:
~/git/JavaToCSharp on master λ dotnet build --property WarningLevel=0 /clp:ErrorsOnly ./JavaToCSharpCli/JavaToCSharpCli.csproj
MSBuild version 17.5.0+6f08c67f3 for .NET

Build succeeded.
    9 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.65
~/git/JavaToCSharp on master λ dotnet --version
7.0.202

Here's the output when the projects target .NET 6 and upgrading IKVM to the latest 8.6.2:
~/git/JavaToCSharp on feature/net6 ● ~1 λ dotnet build --property WarningLevel=0 /clp:ErrorsOnly ./JavaToCSharpCli/JavaToCSharpCli.csproj
MSBuild version 17.5.0+6f08c67f3 for .NET
/Users/paulirwin/.nuget/packages/ikvm.msbuild/8.6.2/buildTransitive/netstandard2.0/IKVM.MSBuild.Tasks.targets(25,9): error MSB4044: The "IkvmGetReferenceAssemblies" task was not given a value for the required parameter "ToolPath". [/Users/paulirwin/git/JavaToCSharp/JavaToCSharp/JavaToCSharp.csproj]

Build FAILED.
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.96

I've tried adding the JDK image and that didn't seem to help. @wasabii if you have any guidance here that would be appreciated.
I can get it to build targeting .NET 6 while keeping IKVM on v8.1, but when I run the unit tests I get this exception:
Error Message:
   System.TypeLoadException : Could not load type 'System.Reflection.Emit.MethodToken' from assembly 'mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
  Stack Trace:
     at com.github.javaparser.JavaParser.parse(InputStream in, Charset encoding, Boolean considerComments)
   at com.github.javaparser.JavaParser.parse(InputStream in)
   at JavaToCSharp.JavaToCSharpConverter.ConvertText(String javaText, JavaConversionOptions options) in /Users/paulirwin/git/JavaToCSharp/JavaToCSharp/JavaToCSharpConverter.cs:line 32
   at JavaToCSharp.Tests.IntegrationTests.TestCommentsCanBeConverted(String filePath) in /Users/paulirwin/git/JavaToCSharp/JavaToCSharp.Tests/IntegrationTests.cs:line 16

When targeting .NET 5, the unit tests currently fail on macOS but that's because of a \r\n vs \n line ending difference that I need to fix, not because of an error like the above. The unit test code successfully runs, just an assertion fails. I am assuming they pass on Windows currently but haven't put in the effort to validate that recently.
So I am clearly missing something to say that IKVM on .NET 6 works as-is, at least with this project... I was hoping that the IKVM .NET 6 upgrade would solve that. Maybe fixing the ToolPath error that I don't get on IKVM v8.1 would resolve all of this without having to wait on that?
So that is why we can't upgrade the projects to .NET 6 currently in order to support some of those newer language features. If there are compiler features that don't require .NET 6 runtime support that you'd like to use in the meantime I'm certainly open to that and will merge this PR once the CI build succeeds.
Thanks again y'all for your help in improving this project!

Searching for "ToolPath" in IKVM issues brought me to this one, which is bringing back some memories that I've seen this before: https://github.com/ikvmnet/ikvm/issues/271
It seems like we might need to reopen this? It is definitely failing on macOS arm64 for me.

I'm a little unclear about what you mean by "Was it using IKVM at all?" - the JavaToCSharp project depends on IKVM as a library because the dll (in the lib folder) built from the jar depends on IKVM. So there's no way for us to not use IKVM at all, AFAIK.
If you mean are we using IKVM to build the DLL upon build, the answer is no. I'm using the precompiled DLL. Is there a backwards-compatibility issue at play here because of the version of IKVM the DLL was compiled with?
If there were no backwards compatibility concern, I would infer that we could run IKVM fine on osx-arm64, which I believe is what I'm attempting to do here. Let me know if my understanding is incorrect, thanks!

Well there is def a backwards compatibility issue. Assemblies generated with one version of IKVM shouldn't be used along with another version of IKVM. The generated assemblies consume types within the runtime and base class library. And that API hasn't been stable.
You can generate the assembly on one machine and move it to osx-arm64 and it should work fine. It's just the build tools: ikvmc, and the MSBuild integration, can't work.

The whole thing also apparently works fine on OS X inside Rosetta, or so I've heard.

Thanks for confirming that suspicion. I'll attempt to rebuild the dll on a Windows x64 machine against latest IKVM.
Also, I'd be happy to help test your macOS arm64 work when it's ready for testing, just let me know. Thanks again for your hard work on that project!

Remember: you gotta build at least two. One for .NET framework, and another for Core.
And consider building these by hand a hack that you have to fix later. Once we get the build tools working on OS X, you should switch to using them. And, if your dependent library is on Maven, you should use IKVM.Maven.Sdk instead. But you need OS X ARM64 support to run all that on OS X ARM64.

The only compilation errors related to my pull request are due to using raw string literals in a unit test. Those could easily be converted back to verbatim strings. The advantage of raw string literals is that the multi-line string can be indented nicely along with the code.
This is the source (shortened with "..."):
public class ConvertInterfaceTests
{
    [Fact]
    public void Verify_Method_Param_Types_Use_New_Interface_Name_Types()
    {
        var javaCode = """
            import com.github.javaparser.resolution.Context;
            import com.github.javaparser.resolution.Test;
...
            """;
        var options = new JavaConversionOptions { StartInterfaceNamesWithI = true };
        options.WarningEncountered += (_, eventArgs)
                                          => Console.WriteLine("Line {0}: {1}", eventArgs.JavaLineNumber, eventArgs.Message);
        var parsed = JavaToCSharpConverter.ConvertText(javaCode, options);

        var expectedCSharpCode = """
            using Com.Github.Javaparser.Resolution;
            using System;
...
            }
            """;

        Assert.Equal(expectedCSharpCode, parsed);
    }
}

This unit test itself also fails. The produced output has an additional "using System.Collections.ObjectModel;" which is not expected.
Since I did not change these usings, another pull request or commit must have added it.

Would you mind fixing the unit test as part of this PR? That would be greatly appreciated!

Actually scratch that, I'll fix the unit test as part of the .NET 6 upgrade. I have those building and running in the Actions build now.
Thanks for your help @wasabii, I will have .NET 6 support merged soon.

@OJacot-Descombes Are you planning on resubmitting a PR in a separate branch? I look forward to improving the code with your PR. My apologies for any inconvenience around the .NET 6 upgrade 😦

Oh sorry, I missed that with the separate branch.
A new build error is appearing on github because of a failing unit test. The same test runs fine on my system (why?):
[xUnit.net 00:00:00.96]     JavaToCSharp.Tests.ConvertInterfaceTests.Verify_Method_Param_Types_Use_New_Interface_Name_Types [FAIL]
  Failed JavaToCSharp.Tests.ConvertInterfaceTests.Verify_Method_Param_Types_Use_New_Interface_Name_Types [696 ms]
  Error Message:
   Assert.Equal() Failure: Strings differ
                                     ↓ (pos 247)
Expected: ···"\n    {\r\n        bool IsArray();\r\n    }\r\n\r"···
Actual:   ···"\n    {\r\n        boolean IsArray();\r\n    }"···
                                     ↑ (pos 247)
  Stack Trace:
     at JavaToCSharp.Tests.ConvertInterfaceTests.Verify_Method_Param_Types_Use_New_Interface_Name_Types() in D:\a\JavaToCSharp\JavaToCSharp\JavaToCSharp.Tests\ConvertInterfaceTests.cs:line 60


Removed Google Analytics

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Needed for https://github.com/rust-lang/rust/issues/47347 . Please consider merging this, @steveklabnik especially now as the GDPR is in force. Thanks!

@steveklabnik thanks for having a look. Could you consider merging https://github.com/rust-lang/blog.rust-lang.org/pull/253 as well? That'd be awesome :)


moment.duration(65, 'days').days(); gives 4

I'm not sure what's going on, but I've set up a very simple example. Basically the one in the title:
Here's a failing test: https://jsfiddle.net/yp1Lebnh/1/

It works properly according to the documentation:

As with the other getters for durations, moment.duration().days() gets the days (0 - 30).
moment.duration().asDays() gets the length of the duration in days.

Wow. Okay, I didn't expect it to be THAT smart. :D


Fix account deletion.

@keybase/react-hackers, this is ready for review. We no longer need this because the person deleting their account goes through a checklist in order to activate the delete button:

Fixes https://github.com/keybase/keybase-issues/issues/3620


Jenkins chart museum is down from last 2 hour

https://chartmuseum.build.cd.jenkins-x.io/ should be highly available, because the entire deployment process is braking if the Jenkins chart museum goes offline, because of the expose controller dependancy.

We have a HA chartmuseum at http://chartmuseum.jenkins-x.io. You should
upgrade the platform jx upgrade platform, the CLI jx upgrade cli and
the build templates (if using serverless jx upgrade addon jx-build-templates)
On Tue, Dec 4, 2018 at 8:17 AM Vyshakh P<EMAIL_ADDRESS>wrote:

[image: screen shot 2018-12-04 at 1 47 02 pm]
https://user-images.githubusercontent.com/20730186/49428082-2078a780-f7cb-11e8-86cc-7d50286c99cb.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jenkins-x/jenkins-x-platform/issues/4408#issuecomment-444010459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJoQQ_plNGrPbj6aYIhlbiLtz0wbA0Zks5u1i-ZgaJpZM4ZAIOR
.


This may be an influential bug in the structure host_info

🐞 Bug Report
Affected Services [REQUIRED]

 The issue is located in:
pkg/types/host_info.go
Is this a regression?

 Yes, the previous version in which this bug was not present was: ....
Description and Minimal Reproduction [REQUIRED]
🔥 Exception or Error

// GetHostURL returns the complete URL for the host-info configuration
func (info *HostInfo) GetHostURL() string {

	protocol := info.Protocol
	if info.Protocol == "" {
		protocol = defaultMsgProtocol
	}
	return fmt.Sprintf("%s://%s:%d", protocol, info.Host, info.Port)
}

the defaultMsgProtocol "tcp" does change the info.Protocol, it just be assigned to the local variable protocol, I guess this may cause serious bug if anyone uses this feature.
🌍  Your Environment
Deployment Environment:
EdgeX Version [REQUIRED]:
Anything else relevant?

@Pluviophile225 , local variable protocol is used in the URL string retuned. This function is not indented to modify the passed in info data.

what kinds of serious bugs or usage you are refering to?  please write down more statement or examples.

close this issue due to no response


[BUG]

I am using vuejs for frontend and laravel backend and i am trying to incorporate vue-formio for dynamic form creation. But nothing seems to work as i am getting an error when i create a new component. Am i doing something wrong?.
In the console i am getting something like
"app.js:161137 Uncaught TypeError: Object prototype may only be an Object or null: undefined
at setPrototypeOf ()
at ./node_modules/vue-formio/lib/components/Form.js.__extends (app.js:161137)"
FYI: i am using vue version 2.5.7

I am importing the FormBuilder component to use inside of another project and I'm getting the same error.

I'm getting the same error with the Types at: node_modules/vue-formio/lib/components/Form.js:7:9 using:

vue-formio: 3.0.2
vue 2.6.6
typescript: 3.4.3

I am trying to use this lib with no success. I have only followed the tutorial on the README file, but it does not work,

We have upgraded vue.js which should resolve these issues. Can you try retesting on the latest vue version?

I have tried it and still it's not working. still getting same error, i tried even to use the latest version of vuejs.
Here is the test code i used, i just copied from the README file explanations.
`

`
Here is the error from the console

I can confirm the same results as @nyirongojr. I got the same errors after having bumped both formiojs and vue-formio libraries to version 4.

<template>
  <div class="form-builder-render">
    <form-builder :form="formschema" :options="{}" />
  </div>
</template>
<script>
import { FormBuilder } from 'vue-formio'
export default {
  name: 'App',
  components: { FormBuilder },
  props: {
    formschema: { type: Object, default: () => {} }
  }
}
</script>
<style lang="scss" scoped>
</style>

Check that you also have ~font-awesome/scss/font-awesome, ~bootswatch/dist/yeti/variables, ~bootstrap/scss/bootstrap, ~bootswatch/dist/yeti/bootswatch, ~formiojs/dist/formio.full.css
somehow included in your css.
I have not tried this with fresh project, so there might be a package that could solve this issue.

@Sefriol am still getting same error
app.js:148844 Uncaught TypeError: Object prototype may only be an Object or null: undefined
at setPrototypeOf ()
at ./node_modules/vue-formio/lib/components/Form.js.__extends (app.js:148844)
at app.js:148876
at Object../node_modules/vue-formio/lib/components/Form.js (app.js:149051)
at webpack_require (app.js:20)
at Object../node_modules/vue-formio/lib/components/index.js (app.js:149207)
at webpack_require (app.js:20)
at Object../node_modules/vue-formio/lib/index.js (app.js:149233)
at webpack_require (app.js:20)
at Module../node_modules/babel-loader/lib/index.js?!./node_modules/vue-loader/lib/index.js?!./resources/js/components/Club/Form.vue?vue&type=script&lang=js& (app.js:2720)
I don't know what i am missing to make this work

It might be a babel or webpack issue.. Check that you have atleast these in your devdependancies:
  "devDependencies": {
    "@babel/core": "7.0.0",
    "@babel/register": "7.0.0",
    "@vue/cli-plugin-babel": "3.5.3",
    "@vue/cli-plugin-eslint": "3.5.1",
    "@vue/cli-plugin-unit-jest": "^3.9.0",
    "@vue/cli-service": "3.5.3",
    "@vue/test-utils": "1.0.0-beta.29",

since it seems that you are using an old version of babel. (i.e. I think "@babel/core": "7.0.0" replaces old "babel-core").

I had same issue when importing my custom vue component for jest unit tests. My custom component is importing form builder components from vue-formio.
It turns out it is a Vue - typescript compatible issue. I was able to fix the issue by building the vue-formio module with esModuleInterop:true  option in tsconfig.json.  For more information please check out StackOverflow thread

https://github.com/formio/vue-app-starterkit
Did you use this as a base? It should have that attribute on. I'm personally running just a normal node stack so I cannot comment much on the ts implementation.

I am using vue-formio and it is missing that attribute. I tried adding esModuleInterop:true and build the project which fixed the following error
at setPrototypeOf ()``` error when imported into other vue components.

@randallknutson any help in getting this bug fixed would be greatly appreciated. I can provide the pull request for the changes needed. thank you in advance.

I'm running into this bug and I'm not using typescript at all. Can we reopen this or do we need to file a new one because I don't think is resolved. I'm going to try what @vijji did above to see if solves it for me but right now it's a bit of a blocker.

I can confirm @vijji change resolves the issue for me too. I opened a PR to this project for it:
https://github.com/formio/vue-formio/pull/33

@nyirongojr any particular reason you closed this? Seems like without #33 merged it still exists 😕

I am experiencing the same error as well. I was able to resolve the error by formatting Form.js line 144:
From:
var namespace = _this.options.namespace || 'formio';
To:
var namespace = _this.hasOwnProperty('options') ? _this.options.namespace : 'formio';

i had the same problem and @lailapfit  fix resolved for me!

If anyone needs to add the changes into their build, checkout this fix by using patch-package!


Support md.to_parquet

Is your feature request related to a problem? Please describe.
to_parquet could be added to Mars DataFrame.

The package is not usable in the real world without this support. Supporting multiple engines including pyarrow can also matter.

The package is simply not usable in the real world for dataframe manipulation without this support. Supporting multiple engines including pyarrow can also matter.

Thanks, we'd love to hear the voice from users, I have elevated the priority from P1 to P0, we will implement this feature ASAP.

@hekaisheng That's great. Just to be sure, I assume this was tested with pyarrow=2.0.0 which was released recently.

@hekaisheng That's great. Just to be sure, I assume this was tested with pyarrow=2.0.0 which was released recently (as opposed to only pyarrow=1.*).

Yes, our CI is tested with pyarrow 2.0.


Remove the workaround for swift-package-manager-#8111.

Remove the workaround for https://github.com/swiftlang/swift-package-manager/issues/8111. The issue has been resolved and Windows correctly exports symbols from dynamic library targets.
Checklist:

[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.

@swift-ci test

@swift-ci test

@grynspan @stmontgomery I wonder if this caused Source Compatibility Suite regressions - https://ci.swift.org/job/swift-main-source-compat-suite-debug/989/artifact/swift-source-compat-suite/

I suppose it's possible, but looking at the failures, they don't seem related. It looks like the testing module simply isn't being built, whereas our change here (combined with the follow-up 840c82289e2c0ecc98605c7fc9fda787053c95b8 patch) just makes the library build as a DLL on Windows. There should be absolutely no visible change on non-Windows systems.

I see, so it must be something about ScanDependencies or something related to that.

I'm not willing to rule this change out entirely since the follow-up commit might have been delayed making it into a toolchain. But I would definitely look at ScanDependencies first if only to rule it out.

Sounds good, thank you!


time formatting

Would be useful if time output in mseed2text printed nanoseconds instead of microseconds.
Also, perhaps the output time should be more ISO friendly, like YYYY-DDD instead of YYYY,DDD. See "Ordinal Dates" in ISO8601.
Maybe add Z to be clear date is UTC.
Change:
             start time: 2012,001,00:00:00.000000

to
             start time: 2012-001T00:00:00.000000000Z

Note mseed2json already does some of this:
    "StartTime": "2012-01-01T00:00:00.000000000Z",

but might be good if it used day of year instead of month day since that is what is stored in the header?

1- This is a SEED-defined time string: start time: 2012,001,00:00:00.000000
2- This is a compliant variation of ISO 8601: 2012-001T00:00:00.000000000Z
3- This is RFC 3339, and ISO 8601, compliant time string: 2012-01-01T00:00:00.000000000Z
ISO 8601 is a broad standard that includes lots of variations on date-time strings.
RFC 3339 is a refinement of ISO 8601 (and RFC 2822) that defines a subset, specifically, most used, and the one were familiar with: https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6.
Personally I find variation 2 a bad option, it needs to be read very careful by eyeballs to understand it's an ordinal.
I've recently been steering towards RFC 3339, option 3, as that seems the most sane, in terms of smaller scope and clarity, options.  Importantly it is also what is needed for JSON Schema, which does not support all of ISO 8601, which is why it's in the JSON above.  The only downside is that these are not the values stored in miniSEED, which uses the ordinal (day of year) values.  It's very nice to see the values that are supposed to be in the data directly for diagnostics.  This leads to the mix use being reported and (obviously) I haven't reconciled them in my mind yet.
One option would be to add the RFC 3339 format the the places where the SEED format is printed, redundant but hopefully clearer?
start time: 2012,001,00:00:00.000000 (2012-01-01T00:00:00.000000Z)

For humans I agree 3339 seems the clearest, my old eyeballs don't really like option 2 either.  Maybe instead of repeating the whole time string, go with 3 but add just the day of year, so something like:
start time: 2012-01-01T00:00:00.000000000Z (day: 001)

or even just
start time: 2012-01-01T00:00:00.000000000Z (001)

Another option, since this is just a textual representation of the record, is two lines, so:
start time: 2012-01-01T00:00:00.000000000Z
      year: 2021 day-of-year: 1 hour: 0 min: 0 sec: 0 nano: 0

First is for humans, second is for diagnostics? That would also mean that the decimal digits in the seconds could be 3,6,or 9 digits to have fewer zeros?

Fixed in libmseed commit: https://github.com/EarthScope/libmseed/commit/a7cea36bde0508d65c00f32a488de046e503c94b
The time string generated in msr3_print() is now this format:
             start time: 2022-06-05T20:32:38.123000Z (156)

How do you feel about printing microsecond vs nanoseconds when extra digits are zero?
With latest commit, it looks like the format prints micros even though precision is only to milliseconds. Looks like it will print nanos if they are not 000.
Maybe it would be good to either always print full nanos (maybe too verbose, but more closely shows actual data) or trim ending zeros to one of milli, micro or nano precision?

It's a balance of a few things.
The highest resolution in SEED 2.4 is microseconds, whereas the minimum specified resolution is 0.0001 (tenths of milliseconds).  So the choice in this software stack was to print microseconds and not bother with milliseconds.  I'd like to continue that.
Nanoseconds are going to be an exception for most data most of the time, i.e. they will be zeros, and so not usefully included, plus they are visually noisy.


Accuracy drops during extended training.

Hi,
I've built the following quaternion CNN using the methods provided.
  class QLeNet_300_100(nn.Module):
      def __init__(self):
          super().__init__()
          self.fc1 = layers.QLinear(196, 75)
          self.fc2 = layers.QLinear(75, 25)
          self.fc3 = layers.QLinear(25, 10)
          self.abs = layers.QuaternionToReal(10)

      def forward(self, x):
          x = torch.flatten(x, 1)
          x = F.relu(self.fc1(x))
          x = F.relu(self.fc2(x))
          x = self.abs(self.fc3(x))
          return x

When training the model for an extended duration on the MNIST dataset, the accuracy suddenly drops to nearly 10%, which is what we would expect from an untrained model, and doesn't improve any further. An image of the accuracy values as training progresses is attached.

The same issue also persists when using the methods in Parcollet's original repo. I would appreciate some insight into why this might be happening. If you need additional info, I can provide the code to recreate this issue.
Thanks,
Sahel

Thanks a lot for the interest in our work!
Yes if you may kindly provide the full code we will look into it ASAP!

Hi,
Thanks for the quick reply. I'm attaching the file.

This looks like a learning rate problem! I tried running your code with a learning rate of 0.05 and had no problems.

We did! Actually that's what we are working on right now, as soon as we find a configuration with a noticeable improvement over real NN's we will update the repo.


professor team composition

PRofessors need the additional ability to:

create teams on behalf of the students (currently can't create teams)
add students to existing teams from a list (currently need to enter user ID, which is the lakerID before the @oswego.edu and type it in)

Confirm requirements and will be working on adding these feature soon.

not urgent. can leave it for Spring '23.

Instructor elevated privileges

create teams on behalf of students , the professor cannot create empty teams and hence has to add one student to the team
Add existing students to the team (including checks for team size)


Adding feature which can download the iflow as zip file.

Adding feature which can download the iflow as zip file. This is already part of snapshot step but it willl help if it can be added as individual action feature

@itstushar22 - could you elaborate on your use case? What is the zip file subsequently used for?

@engswee  Like CPI linting.

@itstushar22 - understood. You can add steps in your pipeline to zip the content before running cpilint. Personally, I don't see any value in committing the zip file into the Git repo


Prediction explanations: add support for stacked ensemble

We'll need XGBoost #1890 to have support first, so all estimators used in the ensemble work with shap.

@freddyaboulton and I chatted about this. This will take a lot of work.

I am thinking that if we assume the metalearner is a linear method, we could put together a solution for this where we sum the contributions from each input pipeline. Would be easiest if we roll our own ensemble impl first in #1930

Resolved as part of the work in #2971.


Bug in documentation "Angular 2 Input Mask - Getting started" section.

On page "Angular 2 Input Mask - Getting started" is bug in example code.
https://github.com/text-mask/text-mask/tree/master/angular2
FormsModule and TextMaskModule is declared in imports array
BUT it should be declared in declarations array instead.
(reason: https://stackoverflow.com/a/45032201/806456 )

I am sorry, my fault. Please close this issue, its not valid at all.


Merge Experiment/restructure to develop

Restructure into microstrain and mip libraries
Split C and C++ sources
Metadata

It might be worth updating the package contact info, it still says Parker (CMake)

Re-enable the Linux ARM builders in the Jenkinsfile

src/cpp/microstrain/
extras/scope_helper.h/cpp - change namespace to microstrain (also closing bracket comment on the namespace)
src/c/microstrain/
common/device_models.h/c - change namespace to microstrain (also closing bracket comment on the namespace)
common/loggin.h - macros using MIP instead of MICROSTRAIN

Are we sticking with external includes wrapped in <> instead of ""? A few MicroStrain SDK include headers in the MIP SDK would need updating/ Also, a few places has system includes above MIP/MicroStrain includes. I'd say move those below our includes to prevent any issues

Not sure if this should be separate, but the licenses in the examples say HBK MICROSTRAIN instead of MICROSTRAIN BY HBK. We should update those


Multivariate Time Series Classification

Hi, I am trying to do a Multivariate Time Series Classification with PatchTST. Can someone provide me with an example?

I am trying to do Multivariate Time Series Classification using PatchTSTForClassification, but I am getting the following error.
ValueError: pooling operator None is not implemented yet
As a referral, I am following https://github.com/huggingface/notebooks/blob/main/examples/patch_tst.ipynb.

I am trying to do Multivariate Time Series Classification using PatchTSTForClassification, but I am getting the following error.
ValueError: pooling operator None is not implemented yet
As a referral, I am following https://github.com/huggingface/notebooks/blob/main/examples/patch_tst.ipynb.

I also happen to have this idea. Is the patch method currently used for multivariate time series classification?

thank you very much

I also have this idea. how to fix it? thank you.

Can you try to set pooling_type='mean' in PatchTSTConfig? That should work for classification task.

thank you very much. I will try it.


*: Refactor codebase with linters/formatters and upstream patterns

Lots of TODOs still pending (that will be done in separate PRs), but this does the following.

Bump prom client, and add rules to use similar upstream patterns for instrumentation
Deprecate ioutil
Make all errors consistent and move completely to github.com/efficientgo/core/errors
Add bingo and several linters/formatters
Deprecate fake.NewClient
Fix a bunch of lint problems (although many still exist within tests)

/retest tests-unit

/test test-unit

/retest

Errors

I would avoid adding the new error package

I understand the reason for the new error package and not wanting to depend on small package, but there are a few of reasons, why I think it is generally better than combination of stdlib fmt.Errorf and errors.New,

Wrapping errors with fmt.Errorf needs a %w which is super easy to forget to do, and easy to miss in review. I think we can construct some linter rule for it using some custom lint tools (faillint, golangci-lint don't do this I think), but that's extra check to maintain. Due to the nature of such a single arg function, it is prone to inconsistent wrapping.
Relying on errors.New for new errors and then fmt.Errorf for wrapping doesn't look clean, and increases cognitive load.  I'd rather prefer using single package consistently for everything.

Regarding the stack trace, I don't see why we would need it. I mean, if so, it is a symptom of bad error handling that is not descriptive enough in the stack.
I don't like depending on those small libs while the stdlib does the job.

I get what you're saying about non-descriptive errors @thibaultmg, but I'd argue stack traces aren't exactly to describe the error or "cause" of the error, but rather to highlight the specific code path that the error resulted from, which is extremely useful when debugging issues with complex codebases like this one. And stacktraces are useful enough that people even created o11y signal from it i.e profiling. I'd rather have stacktraces and not use it, rather than not have stacktraces but need it. 😅 Wdyt?

And if anything, we maintain efficientgo/core, so there isn't much worry about governance.
Bingo

and bingo

Curious about this, why do we want to avoid bingo? Is it the extra files or something else you noticed @thibaultmg?
Logging
Also, I have an outstanding question apart from errors, which is logging. Seems like this repo uses go-kit/log (which we use upstream quite a lot in Prometheus and Thanos), and klog which is the standard k8s logger, quite a lot. Also, Kubebuilder-based operators usually use zapr which is what obo uses. I'd like to move to one consistent logger. What do you think we should use here then? My personal pick would be go-kit/log as we can do multiple formats and filter via log level, and it's the one current team is most familiar with. But what do you think @thibaultmg @philipgough? 🙂

/retest

On error handling, I heavily agree with @thibaultmg's point.

I do not think adding a %w is easy to forget and miss in review. In fact, it becomes instinct after a few uses. Some of us in the team might see it as easy to forget only because we lack experience with the standard library's error wrapping. It's a matter of getting acquainted with the habit (less things to keep inside our heads = cognitive_load--).
I don't think fmt.Errorf implies in extra cognitive load -- where would such load come from? It might not look clean for some, which is fair, but not a good reason to rely on a 3rd party library. In fact, we are better off using the Golang's standard library way, which can be improved over time. The Go team will take care of the backwards compatibility and migration for us.
Extra: by using the official error wrapping of Go, in the future we might get stacktraces for free and won't need a 3rd party package for this. To me it's fine to use a 3rd party package for stacktraces if they prove helpful. More than once I already caught myself with a stacktrace that didn't help me pinpoint the issue.

On Bingo, I also agree with @thibaultmg's point.

It's not about "why avoid Bingo?" it's about "why use Bingo if go install is enough"? Bingo comes from a time where go install didn't exist. Nowadays we have a proper solution from the Go team which they will evolve over time together with all the rest of the toolchain. It's much more likely that a Go developer already knows go install (less things to keep inside our heads = cognitive_load--) than Bingo.
It's not only about how many files Bingo adds to the project, but also how much maintenance is required to upgrade tooling (more things to keep inside our heads = cognitive_load++). Meanwhile, go install is just a few lines in a README, Makefile or Shell script -- to upgrade something I change the version number and that's all. Also note that the commands in Bingo and go install have slightly different syntax sometimes (more things to keep inside our heads = cognitive_load++).

Overall, my opinion is: I like to stick with the standard library whenever possible. We should all be very familiar with it. When not possible, let's look for tools that are "de-facto" standards in the community. There are many good reasons for this, including but not limited to:

By using the standard library and "de-facto" standard packages, we reduce onboarding time and cost of codebase because we will be using constructs that are familiar to every Go developer (less things to keep inside our heads = cognitive_load--). On the maintainership side, we don't have to create and maintain a package for this. The less code we have to maintain (less things to keep inside our heads = cognitive_load--), the more we can focus on what matters most.
We see that the standard library is constantly evolving, getting new features and incorporating feedback from people using it. The Go team has been doing a great job at this and keeping backwards compatibility. It's a bad idea to lock ourselves out of it or push the responsibility of adopting updates to the standard library to someone else.

Hey,

Relying on errors.New for new errors and then fmt.Errorf for wrapping doesn't look clean, and increases cognitive load. I'd rather prefer using single package consistently for everything.

I think it is more of a matter of what tools you are used to. Because for me, it is this errors.Wrap that increases the cognitive load. I have to check the package to understand why it's there.
Regarding the stack trace, this can be added when debugging with 3 lines of code. And it happens rarely. So adding a specific dependency for that doesn't seem worth it to me.

Curious about this, why do we want to avoid bingo? Is it the extra files or something else you noticed

I admit it brings useful things to the table. But I don't think we need it enough to not use go install. We could isolate these dev bins in a .bin dir in the package and have all tools consume these deps from here. The other useful things is the ability to selectively add deps. We could have one make target by dep. To me there are few things that bingo brings that cannot be done with standard tooling plus some small conventions.

Also, I have an outstanding question apart from errors, which is logging.

I don't have strong opinions on this. In my personal projects I use zerolog which I like.
Overall I totally agree with @douglascamata remarks about the benefits of using the standard lib as much as possible. This is what I strive for in my projects. But again, It is not a blocker if the majority of the team enjoys these tools 😉

Bingo is not a blocker. You have already integrated it, let's go with that. After, I don't think anybody will spend time changing it just for the sake of removing it.
Still good to remove the errors package 😄 .

That being said, I also do not feel strongly about blocking any alternatives to bingo in the context of this repo. So @thibaultmg / @douglascamata if you feel like bingo is causing you more difficulties or is hindering you in any way, please feel free to raise a follow-up to this PR with an alternative. 🙂

It's not about difficulties of Bingo. As I said before, it's more about using a non-standard tool when a standard one that can achieve the same things already exists. Bingo is far from a standard tool -- besides Thanos and grpc-middleware, only some other Red Hat projects are using it. Everyone else out there has figured how to live without it and it's not difficult. We can achieve with go install everything that Bingo does and the only "manual work" will be to add a variable in a Makefile (done once per lifetime of the project, not a burden at all).
Not a blocker for me too.

/retest test-unit

/test test-unit


rancher-vcluster addon HEP [skip CI]

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:

HEP for rancher-vcluster addon.
Solution:

Related Issue:
https://github.com/harvester/harvester/issues/2679
Test plan:

the vcluster is deployed to a stateful set which has a pvc backing it for persistence.
i am not yet sure what is likely to happen when we upgrade a single node cluster. for clusters with multiple nodes i see no issues.

when pvc is used by vcluster addon, could pvc be configured with it's size and the related storageclass?
we enhanced the storage network, when setting it, all pvcs are checked to be detached ( rancher-monitoring is stopped, vm is stopped), also disable vcluster ?

the default size is 5g. It is not configurable at the moment and only hosts the etcd backend.

@guangbochen @ibrokethecloud
We need to estimate the etcd size of a traditional Rancher deployment. Expand the PV size needs some additional work. A proper pre-defined PV size for vcluster to host Rancher, will be a good start.
The PV related info should also be added to HEP.
Meanwhile, storage-network is another point to check, as vCluster will be like rancher-monitoring, it uses PV but is not VM.
For upgrading in the single-node or two-node cluster, could there be potential conflicts? seems the related analysis is needed in HEP, and also please @bk201 double check.

BTW: vcluster is new in Harvester, how to trouble-shooting the k8s in k8s, could be added to HEP or Harvester doc chapters like https://docs.harvesterhci.io/v1.0/troubleshooting/harvester .

@w13915984028 i tried a single node cluster upgrade with rancher-vcluster addon enabled and had no issues with the upgrade.

@ibrokethecloud it may not be fully related to the HEP, but please check below code:
https://github.com/harvester/harvester/blob/master/pkg/controller/master/storagenetwork/storage_network.go#L730


Export/Import as .html file

Would be nice if LinkHub could export/import links as .html file format.
Reason:
Most browsers export bookmarks as .html format. As bookmarks are nothing but links, folders with titles users could simply import them to LinkHub without adding them manually.

Would be nice if LinkHub could export/import links as .html file format.
Reason:
Most browsers export bookmarks as .html format. As bookmarks are nothing but links, folders with titles users could simply import them to LinkHub without adding them manually.

https://console.jumpcloud.com/login/admin

Hello @AmrDeveloper, is this issue still actual? I could implement it on a different branch and offer a pull request with this feature

Sure feel free to implement it and make sure it not crash if user edited the html in wrong way

Implemented in 1.6.0


Update architecture doc when netmon lands

When https://github.com/kata-containers/runtime/pull/534 lands, we need to add details of the network monitor to the architecture document.

cc @mvincerx


Update "Review Operation Information" Page: Selecting Annual Report, Simple Report or Partial Year Reporting

Description:
Follow-up to #324
Need to confirm where data is being pulled from. Need API work.
As part of the "Review Operation Information" page (#196) users will need to have the option to select "simple report" or "partial year reporting".
Selecting either of these options means they will need different or additional forms in their reporting workflow.
The workflow for simple reporting is capture here #285
Ticket for building the Partial Year Reporting form is #350
WIREFRAME
Acceptance Criteria:
Given that I am an Industrial Reporter and I'm on the Review Operation Information page
The default selection for "report type" should be Annual Report.
Given I am an Industrial Reporter on the Review Operation Information page and I need to fill out a simple report,
When I select the "simple report" checkbox (tbd) for my report type,
Then the system will only show me the forms required for a simple report workflow.
Given I am an Industrial Reporter on the Review Operation Information page and I am a partial-year regulated operation,
When I select the "partial year regulated operation" checkbox (tbd) for my report type,
Then the system will include the "regulated operation - partial year" page so that I can include it in my annual report submission.
Development Checklist:

[ ] Checklist item
[ ] Checklist item
[ ] Checklist item
[ ] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

Confirm with BA what term to use for Partial Year. As per our last discussion, they agreed on 'Regulated Operation - Partial Year'

To discuss with team and BA

@ayeshmcg to write dev checklist

@patriciarussellCAS  What's the rules for a simple report? Is it something we can derive from the registration information?

@patriciarussellCAS added an 'attn business area' tag for:

the text explaining what a simple report is
confiriming the fields on the simple report?

@patriciarussellCAS whats the tbd for in "When I select the "simple report" checkbox (tbd) for my report type," ?

@zoeyli-46  & @pbastia  Tiegan is working on final language to display when they select a simple report. For now, you could put the following, and we'll update it later when needed. That way we aren't blocked from making these updates to Operation Info page.
" Regulated or Reporting Operations should file a Simple Report if their emissions have dropped below 10,000 tCO2e. They will continue to report using the Simple Report form until they stop Schedule A activities or stay under 10ktCO2e for three years. This does not apply to Opt-ins."
As for confirming the data fields: We have wireframes for simple reports, but the data fields still need final signoff. We will prioritize this after the regulated operation workflow is done.

Update simple report description as mentioned in
https://github.com/bcgov/cas-reporting/issues/394

To test,
Go to
https://cas-bciers-frontend-dev.apps.silver.devops.gov.bc.ca/reporting/reports/1/review-operator-data
when, you will be able to see label for report type, options for report type, helper text for simple report, registration puspose field. When simple report is selected - activities and products are removed.


MINOR: Add missing @Test annotations to miscellaneous tests

It seems like we missed adding @Test annotations to some test methods and therefore did not execute them on unit test suites.

I found these through the following regex in the Find in Path IntelliJ window:
^\s*\n\s*((?!@Test)\s+)\s+public void (test|should)

cc @soondenana

@hachikuji there is one more test that is not passing but I didn't have time to investigate. I opened https://issues.apache.org/jira/browse/KAFKA-9589 for it

there is one more test that is not passing but I didn't have time to investigate. I opened https://issues.apache.org/jira/browse/KAFKA-9589 for it

Should we add @Test, @Ignore and some comments to it? The comments related to KAFKA-9589 are useful to readers who are tracing this flaky and avoid readers from creating duplicate jira ticket.

@stanislavkozlovski any thoughts on the comments above?

I checked and all of these got fixed in the meantime, so closing this PR.


Night CI 2022-12-19: Failed

action url: https://github.com/spidernet-io/spiderdoctor/actions/runs/3734899139

GitHub issue, not reproduce


✅ fix: 🐛 Two-stack Queue completed

📥 Pull Request
Description
This pull request adds a comprehensive guide to implementing a queue using two stacks with a lazy transfer approach. The key changes include the algorithm overview, implementation details, usage example, complexity analysis, and a flowchart for better understanding.
Documentation and Implementation:

Added a new markdown file docs/Queue/Two-Stack-Queue.md that includes a detailed guide on implementing a two-stack queue with explanations of key operations and their complexities.
Provided a complete C implementation of the two-stack queue, including stack operations and queue operations such as enqueue, dequeue, and isQueueEmpty.
Included a usage example in C to demonstrate the functionality of the two-stack queue.
Added a flowchart to visualize the enqueue and dequeue operations and the transfer process between stacks.

✅ Fixes #1663
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] Documentation update

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] Any dependent changes have been merged and published in downstream modules

@ajay-dhangar can you review this PR, and assign it to me with proper labels too


hyphen in script causes error

I'm using Nuxt with Snipcart. Snipcart requires you to include their script tag in the head. I receive an error as a result of the "-" in data-api-key. If I remove the hyphens, then I can compile fine.
`Syntax Error: Unexpected token, expected , (45:85)
43 |   head: {
44 |     script: [

45 |       { src: 'https://cdn.snipcart.com/scripts/2.0/snipcart.js', id: 'snipcart', data-api-key: 'APIKey' }
|                                                                                ^
46 |     ]
47 |   },
48 |   layout: 'default',`

Sorry, just realised I can quote the keys


feat: add install script

PR Description
add bash script to install midea_ac_lan
Reason & Detail
Related issue
fix #X

@chemelli74  what's the hardcode version info? could you help to confirm ?
there is only a command example with version tag for help, it can be used for version rollback.

@chemelli74 what's the hardcode version info? could you help to confirm ?
there is only a command example with version tag for help, it can be used for version rollback.

Sorry misread from mobile.
Please add a clear info on top is an example.


⚠ Bofrost.de has degraded performance

In da3e849, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1362 ms

Resolved: Bofrost.de performance has improved in aadfdc8 after 13 minutes.


Create Environmental Science Libraries in Python using the Workflow Paradigm for HPC

Idea
Workflow architectures have fundamentally changed the way data is processed. Amazon, Facebook, Twitter, Google, LinkedIn, Wolfram Alpha, and others rely on these systems to provide the enormous scaling that enables them to provide shopping, newsfeed, video streaming, computational, search, and other bandwidth intensive services to so many concurrent users.
However, social media and internet oriented services are not the only ones which can benefit from the powerful parallelization and scaling paradigms provided by workflow systems. Climatology, meteorology, and other environmental sciences are all fundamentally empirical, relying on increasingly vast amounts of observational data to feed hybrid physical/statistical models in order to make analyses, forecasts, and predictions.
These sciences have traditionally relied on computationally intensive modeling, performed using low-level parallelization techniques such as MPI on native languages like C and Fortran. There is a surfeit of these libraries, which are extremely fast and perform exceedingly well, but there are a few detrimental issues with them due to their existing implementation:

As native libraries, they often require specific hardware and compilers just to get them to build.
Out of core computation is also an issue; because they use MPI, they generally require very, very expensive onsite hardware to run on, such as supercomputers, to work efficiently.
The source is often opaque, relying on complex state and memory management, procedural spaghetti, and legacy patterns, which makes it difficult to develop or refactor as new data is introduced or the models change.

All of these issues, along with others, can be solved, at least to some level, by the use of workflow systems. Workflow systems allow users to write in modern expressive languages, like clojure, python, go,  java, etc., they can leverage cheap, scalable, cloud technologies that are well supported by the industry, and they can be distributed on virtual machines, ignoring hardware requirements.
While there have been some published research efforts into applying new workflow based techniques to these domains, the efforts are surprisingly few. There are some projects, such as dask distributed, which focus on datatypes typical of the environmental domain (NetCDF), but they are relatively rare to the entire software industry. Comprehensive libraries that leverage these techniques are even more rare, and comprehensive environmental science libraries that leverage workflow techniques, while being declarative, composable, reusable, free, and open source are, for all practical purposes, non-existent.
The goal of this project will be to explore distributed workflow systems as an alternative to traditional HPC by creating a practical suite of environmental science libraries, that solve real, existing domain problems. At the end of this term, we hope that this library will then form the basis for a new paradigm in environmental data management, to be used by the community at large.
A lightweight workflow system called Ephemeral, built in pure python, will be provided and serve as the engine for development and testing of the library. Ephemeral leverages the Future construct of python's asyncio library, along with task and segment branching (automated parallelization), to provide powerful asynchronous operations. Dask distributed is already integrated into the engine, allowing large scale distribution of data parallelization (e.g., large NetCDF) across a scalable cluster.
Jobs are submitted to Ephemeral as declarative JSON specification maps, which allow high reuse of functions without writing existing code, as long as outputs match inputs. When complete, the library produced by this project will be able to be lifted out of Ephemeral, to be used in any workflow system that can support the packages used in its production.
Students interested in this project will be provided with the workflow system and a list of challenging, out of core, real world job pipelines (algorithms, processes, forecasts, analyses, etc.) that are used right now by practicing scientists at NOAA and NASA, and that would benefit from being implemented in python using distributed workflow techniques.
The student would be responsible for taking the job description and turning it into a functional, generic library of tasks using as much skill and creativity as possible. There will be many ways to solve or implement any job, and that, we believe, will be half the fun of the project.
Students will learn and/or gain experience with the fundamentals of workflow engines, parallelization, declarative, functional, and asynchronous programming, immutability, distributed systems, and HPC theory. A scientific and engineering mentor will be available to provide guidance on structure, patterning, or scientific theory during development.
The specific list of mentors and projects are still TBD.
Skills needed

Strong python skills
Interest in environmental or physical science
Interest in distributed and/or out of core computing
Knowledge of or interest in NetCDF data format
Knowledge of or interest in parallelization techniques
Proficiency in data structures
Proficiency in algorithmic techniques as applied over spatial data
Proficiency in functional techniques such as map/reduce, comprehensions, generators
Proficiency in code pattern techniques such as closures and recursion

Mentors
Ryan Berkheimer, Senior Software Engineer, GST, NOAA NCEI
Max Banas, Geologist, Virginia DMME DMLR
Others: TBD

Hello! I would be extremely interested in contributing to this topic. Please help me get started.

Hi @aarifsk - Thanks for your enthusiasm and interest! Student applications will begin being accepted March 12th. To help you think about forming your application -
This project will deal with the development of generic, python based, scientific libraries for domain specific applications that leverage network-distributed workflow systems (such as Spark, Storm, Luigi, Onyx, Dask Distributed, etc.) as an alternative to processor/hardware bound supercomputing libraries like MPI and OpenMPI.
The advisor-offered example project we are currently focusing on is a library for stream analysis. This library would be composed of modules for

raster/DEM based stream watershed delineation, using other raster and vector layers such as manmade features and/or known land use features to provide accuracy to delineation
catchment sub-basin delineation based on a given watershed basin and higher order stream features
flow profiles of streams based on delineations, precipitation data, and land cover data
nutrient and/or chemical transport/density profiles of streams

Solutions to getting these analyses are of course readily available, but the approach of using distributed systems is not thoroughly studied, and traditional programs that handle these issues are generally one of - proprietary, CPU bound, coupled to hardcoded inputs, coupled to a rigid GUI based tool, error prone, or obtuse. A reusable, easy to use streams library that leveraged Dask distributed (or another workflow system) would be valuable to many ESIP communities. We think this would be a great POC for this project, because the domain is well studied and there is lots of literature and resources available for development.
The advisor example project can be chosen as your focus, but we would also like to help with other libraries if you have a domain you'd rather work on, for example, Aerospace related processing of satellite data, or weather forecasting. The library should be of interest to the ESIP community and should attempt to solve a problem that traditionally requires HPC methods. If you have a domain specific idea and want to know if it would work, feel free to ask about it prior to the application period and I'd be happy to brainstorm about your idea and discuss how it would fit.
 The project will provide a very simple workflow engine called Ephemeral - which wraps Dask distributed, and allows it to work with other tasks in the workflow patterns. The library is decoupled from Ephemeral itself, and then will be reusable in any workflow engine that allows python code to be executed.
The student will gain a mastery of current workflow methods, concepts, patterns, and state of the art by working on this project. Additionally, the end product will leverage Dask distributed (essentially distributed xarray) which is a workflow engine in its own right. But the focus of this project as we see it, is not workflow engine development, but library development.
Our goal is to leverage a simple workflow engine to allow our selected students to develop libraries that are decoupled from the workflow engine they are developed in. This will allow the libraries to be reused in community projects without tying them to their development.
Imagine a cloud based commercial application that is using an AWS stack with a lambda control layer taking library service requests for certain area stream delineations, and that has many concurrent users. Our library should be able to be used with this commercial products own architecture - that may need to handle spinning up lots of different instances and using some sort of Kafka type message queue.
Now imagine a scientist at the health department developing a model on forecasting when certain streams are expected to cause a health problem for some nutrient, that needs to run many models at once, but only has one user. They may need to be able to programmatically control model parameters but do not care about concurrent users.
I hope this helps answer your questions for beginning, and guides you toward putting together a great application for this project!

Hello,
My name is Harshit Chouhan. I am from IIT kharagpur, India. I want to be a part of this organisation for gsoc 2018 by contributing to this project .I wouldk like to know the current status of the project and can you guide me through the process.

@RBerkheimer, this sounds cool, and potentially collaborative with the pangeo project that was presented at the ESIP summer meeting., which is using Jupyterhub with xarray and dask on kubernetes to crunch multidimensional science datasets in a scalable way.    There is a 3 minute demo of the pangeo project here that blew me away, and more details on Matthew Rocklin's blog.

@Harshit-54 Thanks for your interest! It would be great to have you aboard. I've been working with a couple other students prepare their applications, and I'd be happy to help you as well. Application submission officially begins March 12th and runs a couple of weeks.
I'm preparing ephemeral for release to interested people this week, just finalizing license choice and updating the readme. I'll host it on my bitbucket and put a link to it here, so you can work through that system and get a feeling for our development harness. Ephemeral provides us a way to declaratively layout our libraries, run them against parallelized input sets (for testing purposes), and cleanly decouples the system from the library code.
Of course as I mentioned earlier, ephemeral is a development environment designed to make our development lives easier toward our chosen library, and is not an enterprise workflow engine like Onyx, Spark, or Storm. But our ultimate goal is to produce a detached, standalone library for the community to plug in to their own choice of workflow system, and help you all master workflow systems and principles over the course of that work.
Right now other students that have already reached out have begun researching domain knowledge related to the streams processing library I proposed - although you aren't limited to that choice, you can submit your own. We are also forming our mentoring team and reviewing interested people as well as the needs of you all, the students.
So, just let me know specifically what questions you need help with when forming your submission. If you plan on going with the streams library project, you should begin researching domain data available that we will use, such as the national hydrography dataset on AWS, satellite imagery data, and begin to think about how we will ingest, prepare, and consume these data sources in our workflow. Also, you could begin sketching out specific library modules, like delineation from arbitrary points, or upstream flow, or anything really - and then look at how these things are already integrated into existing solutions, like BASINS or MODFLOW or some esri software like arcpy.
@rsignell-usgs pangeo looks really great - I'm going to explore more and potentially communicate with that dev team about possible collaborations. I was bummed that I couldn't make it to this past summer meeting. I remember two years ago, at the frontiers in big data session, seeing a JPL team present Pyspark in jupyter notebooks to do distributed computations against NetCDF, and that was great as well. Thanks for the heads up!

@RBerkheimer , excellent.  The Pangeo team is excellent and inclusive, so I'm sure they would be interested in hearing about what you are up to.   FYI, the full Pangeo talk at ESIP Winter Meeting is here:
https://www.youtube.com/watch?v=mDrjGxaXQT4

Hi,
I am javed ali from IIT KHARAGPUR, I am intersted in this project. Could someone please guide me?


Prometheus stuck in installing charm software

Bug Description
Solutions QA team has a failed run when deploying COS layer (latest/stable:11) on top of microk8s v.1.29.0, prometheus charm stayed in maintenance state with the message: "installing charm software", until it timed out after
From the logs, no indication of the root cause of the error was found.
Failed run:
https://solutions.qa.canonical.com/testruns/25f56cba-e9c3-4ca2-abd5-c807b6d8b902
Logs:
https://oil-jenkins.canonical.com/artifacts/25f56cba-e9c3-4ca2-abd5-c807b6d8b902/index.html
To Reproduce
On top of MAAS 3.3.5, we bootsrtap a juju 3.3.1 controller, we deploy microk8s v.1.29 and the COS on latest/stable.
Environment
This test was ran on virtual machines on our lab3-litleo
Relevant log output
prometheus/0     maintenance  idle                        installing charm software

Additional context
No response

Hey @kaskavel ,
Would you be able to re-run this?, as we're trying to reproduce this on stable but can't.

We have another occurrence of this bug in a similar deployment in Solutions-QA labs, although with different versions of MAAS (3.4.0), Juju (2.9.46), and microk8s (1.28.7).


Turbolinks and render_async don't play nice together

Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.

What are we trying to do?

Get things which render with render_async to populate when following links.

What feature or behavior is this required for?

The most immediate impact is the activity feed -- to see this in action:

visit the authenticated root. See the activity log at the bottom. Lookin' good!

Click a patient link

Click the Case Manager link in the top left corner to return to the dashboard

Oh snap, no activity log!

How could we solve this issue? (Not knowing is okay!)

I believe this is because turbolinks and render_async don't play terribly nicely together. I bet there's some magic we can do to make them work nicely -- data-no-turbolink or something? Worth digging thru the turbolinks docs.

Anything else?

Stems from #1226

Fixed via #1239


Should WinUI 3 establish a new convention of using .winui extension instead of .xaml?

Discussion: Should WinUI 3 establish a new convention of using .winui extension (or other) instead of .xaml extension?
I'm wondering whether this will make easier to distinguish between WPF XAML and WinUI XAML in XAML Islands scenarios, make possible dev tools apply different scheme colors,  have different icons on tools and file explorer, etc..

What about simply .ui?

Could this distinction be helpful for non-island cases as well, or would it be more confusing?
Or if this is primarily to help distinguish between e.g. WPF and WinUI Xaml in the same solution then what about a convention like .winui.xaml, .winui.xaml.cs? That would probably make it easier to use existing tools.

Would this be for XAML Islands scenarios or everywhere? For every other scenario I don't see what would be the value of this, beyond creating confusion and forcing people to migrate (and probably break backwards compatibility for a lot of tooling like older versions of VS). A convention like "whatever.winui.xaml" would probably be less destructive, but I still only see it being useful in the scope of an Island, not everywhere else.

Changing the tittle given I don't want to scope down the discussion to just XAML Islands.

I say keep using .xaml. The scope (and the name) of WinUi might change to include other platforms beside windows (Maybe through UnoPlatform?). What happens if the name of the project changed?

I lean more towards NO. Microsoft has been doing too many renames for products and services sometimes to the detriment of the product/service or their users (opinion). This is yet another rename.

Would this be for XAML Islands scenarios or everywhere? For every other scenario I don't see what would be the value of this, beyond creating confusion and forcing people to migrate (and probably break backwards compatibility for a lot of tooling like older versions of VS). A convention like "whatever.winui.xaml" would probably be less destructive, but I still only see it being useful in the scope of an Island, not everywhere else.

Everywhere

I think XAML should stay .xaml but if something new were to show up either to replace or be useful alongside traditional XAML, then a .winui extension could be useful for that. #804 :)

This request totally confuses me … I had to read this issue twice to comprehend what was going on... This will REALLY fragment the xaml ecosystem more than the different dialects ever did..
Lost for words right now...

@liquidboy well that's at least one clear piece of feedback in favor of not making this change :)  Thanks for lending your voice.
I like the idea from @jesbis, perhaps we could add a *.islands.xaml that helps to more easily distinguish the difference between XAML files that are running in an Islands context vs. not.
Curious: would it be better to have .islands.xaml that only applies to XAML files in an Island, or just to use .winui.xaml as an overall extension everywhere?  I'm not sure which one I like better of those two ideas.

My vote is for ".islands.xaml" or similar to be the recommended (but not strictly enforced) pattern in islands, and everywhere else .xaml files are still .xaml files. That way we avoid unnecessarily impacting people that do not use islands.

My biggest concern comes from all of the tooling. I have no problem with the different extension, but this means that every tool that relies on the .xaml file extension will need to update (I am thinking of things like R#, XamlStyler, etc). The tooling support around xaml already feels like it is struggling, and this looks like it would likely make it worse.
My $0.02

Perhaps the issue title should be changed to something like:
Should XAML files included for Xaml Islands, have a different file extension with WinUI 3 projects?

I'm strongly in favor of keeping .xaml in there. Maybe you go .ui.xaml or .xaml.ui but the technology is strong and it keeps help available. On the other side, unfortunately xaml has some stigma around it after wpf performance pitfalls, silverlight, and windows phone, so a cleaner filename could help turn the corner. I still love xaml, but we don't need more confusion on technology names unless it's clearly thought out.

I think it's a good idea to have it simply as .ui since if winui ever becomes cross platform (like many windows stuff has), it will be more suited.

.winui.xaml

So that means we'll have .winui.xaml.cs files? yikes..

Use json format. It is 2020.

JSON is harsh and not very friendly to work with.

Use json format. It is 2020.

JSON format is for computers to read, not for humans. It's hard to read and doesn't look nice.

I think the .winui will make the beginner give up. Because we will think we should learn a new language. And now we have WinForms and WPF and UWP and SL and ASP and ASP.NET Core. We should spend more and more time to learn it but not inherit. I do not think we should always make the new technology.
Sorry, I and many of my friends do not like to learn new things.  If we do not expect to be the minority,  that we should make the technology can be inherited and can be reused and compatible.

In my opinion, a more elegant solution to "which XAML is which" would be to depend on the default xmlns namespace, as suggest by @grokys in this comment: https://github.com/AvaloniaUI/AvaloniaVS/issues/95#issuecomment-541078633
We didn't do this with UWP, but perhaps we can change it for WinUI.

In my opinion, a more elegant solution to "which XAML is which" would be to depend on the default xmlns namespace, as suggest by @grokys in this comment: AvaloniaUI/AvaloniaVS#95 (comment)
We didn't do this with UWP, but perhaps we can change it for WinUI.

You could introduce the equivalent of a Doctype, as with HTML?

You could introduce the equivalent of a Doctype, as with HTML?

Perhaps, but we shouldn't have to. The default namespace should be what sets each different platform apart (they do in code-behind after all)

The tooling support around xaml already feels like it is struggling, and this looks like it would likely make it worse.

@keboo this hits home for me real hard, and is something I'm pushing hard for us to fix and do right.
The fact that we are in a world where we can't tell them apart (for the islands scenario) is a product of how the tooling has evolved over the years. Everything is completely separate, and it's nearly impossible to rationalize differences between the different dialects. I want to change this, and start making XAML parsing and compilation something that can be easily shared across all XAML dialects, where in this example, WinUI and WPF are using the same fundamental engine. The tooling should be plugin-able as declared by the default namespace and can be customized where needed.

The platform would currently understand when XAML is being used within an Island situation, but what I read into the ask of this issue, is a way for the developer to tell and understand how the .xaml file will be consumed within a WinUI 3.0 project.
As for XAML tooling in general, it needs a total re-do of the design time experience IMO.  Expression Blend was the last time XAML design and development felt top tier.
Because of the nature of XAML, it is both a written form, and a visual form.  Visual XAML design has taken a backseat to bring Intellisense to a good quality.  If there could be a robust, performant, and easy to both prototype and polish XAML design experience - that could reinvigorate the community.
A plugin approach, which does not require a lot of work for control or toolkit vendors to do, whilst still giving a good design time, tool pallette, element property experience - could be very helpful.  As XAML moves into other non-traditional form factors, the design workflow needs to be considered.  Two Pane views (Neo and Duo), non-window hosted XAML surfaces, Shell integrations, mixed framework projects (xaml islands, GDI and WinUI mixes), Hololens Spatial 3D, Rotating Surface Hubs, etc.

But maybe declarative markup is no longer the ideal way to handle it.  Or maybe there should be more separation between XAML content, and XAML styling?  As with HTML and CSS?
WinUI feels like a good opportunity to not only carry over things as they are, but also to plan for the next decades to come.

No. I don't see the point. It doesn't solve anything.
If anything, it creates issues with editors that already know the xaml extension.
I work with wpf, uwp and forms xaml every single day and I've never been confused due to the extension.

Isn't the whole point of Xaml that it's easier for tooling? Can't tooling figure this out with relying on the ancient idea of file extensions?

I mean generally, if nothing is changing in the UI framework, i.e. It's still XAML, don't do it.
If it was a completely new UI framework, then I'd not see a problem.
I also don't know why you'd want to differentiate XAML components for islands either with the proposed islands.xaml. Would it do anything different in tooling or is it just for readability in a solution?

My first thought is that I absolutely don't like this idea. But maybe I don't see the real problems it can solve, and maybe I don't get the point.
If there's a file with xaml in it, I want it to be a .xaml file. In the past, it never came to my mind that I want to have a UWP .xaml file to be named differently from a WPF .xaml file.
The next thing is that a framework name in a file-extension doesn't seem to be a good idea, as framework names might change, and XAML is 4ever XAML.
So, my opinion is: Definitely stay with .xaml.
But what are the options with a .xaml file extension?
Another .islands.xaml file extension? That would mean that the file extension is used not only to describe the format, but also the contents of a file. Mhm... But the advantage of this one is that you can make it optional for a developer. If they want to use it, they can call their files .islands.xaml and the tooling will pick that up with different icons etc.
Another default-namespace is also a valid option. But that would mean for the tooling that it has to look into every .xaml file to find out what kind of file it is. And it would also mean that the XAML dialects are again diverged a bit because of another root namespace.
But now a completely different thought:
If I got it right, all these changes are only really helpful for the XAML Island case where you mix platforms in the same solution, right? Because if you just use WinUI, you know every XAML file uses WinUI. I'm not sure if XAML Islands will be a main scenario for WinUI or not. In the past when WPF was introduced, we had also WPF and WinForms interop, and to be honest, I've rarely seen developers using WPF controls in their WinForms applications. Instead, they continued to use WinForms in WInForms and they started new projects with WPF instead of WinForms. And maybe the same could be true for WinUI 3, and I think it will be the case. XAML Islands is a great way to modernize, but in my experience, developers will only do it if they definitely need a control from WinUI in their WPF/WinForms app. If not, they continue on the old stack and they start new apps on the new stack. Note that this doesn't have to be the truth, it's just my experience. :-)
That means we're talking about changing a file name for a scenario that might not be the main scenario for the platform. And I guess that's why I think it's not worth it. What if a WPF/UWP/Silverlight/Windows Phone developer creates a new WinUI 3 project? They will think

Why the heck did they change the .xaml file extension to ...?

Please don't remove the .xaml file extension.

Please don't go changing extensions!
Many years ago we started using the .paml extension in Avalonia but in the end went back to .xaml  because of the problems it caused: there is already tooling in IDEs to handle XAML (no matter how janky, at least it's something!).
If we're going to expect every XAML dialect to have their own file extension then every project that wants to use XAML is going to have to write 100% of the tolling from scratch - even things like the tooling for renaming files is going to need to be rewritten each time to also rename codebehind classes etc.
As @stevenbrix mentioned above, there is a perfectly good way to tell which dialect of XAML a file is using which is the default namespace at the top of the file. As a first step, make the tooling respect this.
Then open up the XAML language service, provide an API for interacting with a designer and everyone can benefit ;)
Pretty please ;)

One more reason not to: UWP already struggle with adoption issues. Renaming it sells it as yet another technology, rather than "it's more or less the same thing as wpf".
There are already bigger issues with WinUI 3.0 breaking changes that's significantly going to hurt the existing uwp ecosystem. Don't add yet another thing that's different.
It's still xaml, just hitting different API sets, just like c# is still c# even I use it for different UI framework. Code and the APIs I can use change, but it's still the same language.

I vote no, I see no benefits, just added confusion.

One more reason not to: UWP already struggle with adoption issues. Renaming it sells it as yet another technology, rather than "it's more or less the same thing as wpf".
There are already bigger issues with WinUI 3.0 breaking changes that's significantly going to hurt the existing uwp ecosystem. Don't add yet another thing that's different.
It's still xaml, just hitting different API sets, just like c# is still c# even I use it for different UI framework. Code and the APIs I can use change, but it's still the same language.

Ha, I had the same thought with C#. If we call the .xaml files .winui, we should call the .cs files .wincode to make it consistent. :-)
Maybe I'm still missing something, but to me it causes more confusion and I don't see the real benefits of it.

My 2 cents, stick with .xaml, please.

What if you want to share Small XAML snippets between WPF and WinUI? I’m guessing there must be SOME overlap, no? It would make shared projects less useful... or is there really a huge difference? If it is mostly the same similar XAML then keep the same extension. If the format is MOSTLY different than transitional XAML then it might be somewhat more acceptable to change the extension. The real question then is how close is the format to the original?

XAML is also used in Xamarin which targets not only Windows but iOS, Android, macOS...
Replacing .xaml by .winui will create a situation where Xamarin will keep .xaml for XAML files (why one would use .winui for iOS or Android ?) and Windows targets like UWP/WPF... will move to .winui for XAML files.
TL;DR one file format/convention two names (.winui for Windows, .xaml for Xamarin),  to me it's confusing.

Extension should be .xaml as syntax of content it's xaml, another extension would only create confusion.
I vote for something like .winui.xaml

stay with ".xaml" , Its powerful

I have to say, Microsoft has an issue of pathological naming!
And this one really tops them all.

No

If you need to have UWP XAML and WPF XAML within the same project file, use a new Custom Tool instead.
This way, the tool will detect if the XAML file is using UWP XAML or WPF XAML and sends them to the correct compiler via msbuild targets.
Even better way is to standardize XAML language, so that we can develop a common compiler, binary format and framework lib.
That's how I would do it!

Since you are asking, no don't do it.
If tooling can't read the file to see the difference, then WORSE CASE should be a non-required convention of ".winui.xaml" or the like. Again the key being NOT-REQUIRED . Just xaml extension files should work fine but maybe missing some enhanced tooling.

While I understand the idea behind this, I think is a bad solution.
First, WinUI is the framework commercial name, not the file format. What if someone decides version 4 need to change the name to UniversalUI or something else? You would end with a framework name different from the file extension, different from the file format. It could be a nightmare.
Second, it could breaks compatibility with existing tools and documentation. Future devs could not have clear that WinUI files are internally xaml so they would not find xaml documents as relevant ones.
Third, it would fragment more the UI languages used in Microsoft products. I really thing we need to go more to a standard in Xaml, so the product is not so important. C# is the same for Xamarin, Net Core, Windows 10 or WPF, why XAML need to be different?
Let people arrange their projects and organize the code so it is not confusing for them.

Use json format. It is 2020.

@rickydatta Even in 2020 the web uses HTML instead of JSON to define user interfaces. There are many reasons why markup languages like HTML and XAML are great to define UIs. JSON is great for several things, but imo not for defining UIs. When you use JSON for a UI and you try to build features like data binding, static resource references etc., you'll see it gets quite unreadable. But it's offtopic here, so let's leave it. If you want JSON, please create a new issue and let's see how the community reacts to it. :-)

I really tried to avoid commenting here as most of this has already been said, but I've given in. Sorry. I'm weak.
Don't do this. Just don't.
If you want to make a change, there needs to be a clear set of benefits that outweigh the negatives.
What are the potential benefits?

It would avoid possible confusion for people who have some .xaml files that entirely contain WinUI controls and some .xaml files that don't.
Help enable tooling to determine how to work with the potentially different content of .xaml files.

That's it.
I've reread this entire thread three times, and I can't see any other potential benefits listed here.
What are the potential down-sides?

It would introduce confusion.
-- "What is this new extension?" "What do I need to open it?" "How is it different to ...?" "Why did they change it?"
-- What extension do you use for a file that only contains some WinUI controls, when mixing existing UWP XAML and WinUI3 elements? Or does this very suggestion imply that this capability will be going away? (See, just by making the suggestion to change a file extension, you're already introducing more confusion and FUD. If things like file extensions may still change, perhaps I should wait on looking at WinUI, in any capacity, until it's more stable. Several people have told me to investigate Flutter. Perhaps a better future for me lies there.)
-- My understanding of one of the selling points of Xaml Islands in existing WPF apps was that it meant the ability to reuse existing skills and knowledge in working with XAML. This change suggests it's not just XAML, so it's another thing that must be learned, and so is another potential barrier to adoption.)

It's unnecessary.
-- If people want to break up files within a solution they can already do this in multiple ways: different projects; different directories; prefixes or suffixes on file names; using multiple/sub-extensions; or nesting files within the VS Solution explorer. It's not clear how a new extension or forcing everyone to use multiple/sub extensions is better than any of these options.
-- [Default] Namespaces within the file already tell tooling what dialect of XAML is in use and what should be possible with it. (There may be some otherwise undocumented issue in this area which means this isn't possible, but if that's the case, then more information is needed on why changing the file extension is the best solution for that problem.)

It ignores history.
-- I've previously worked with solutions that contained projects targeting WPF, Silverlight, and Windows Phone. They all used different XAML dialects but I never once got confused about which was in use or what I could do within a file. I've worked with solutions that contain XAML for UWP and Xamarin.Forms but not experienced the confusion predicted in the assumption behind this issue. I've also spoken to many other developers with similar solutions, and I've never heard anyone else say that using different extensions would help them.
-- Of all the criticisms that I've heard about there being different dialects of XAML, confusion based on file naming has never been one of them.
-- Developers generally don't like it when you tell them how they should name and structure files and projects without very good reason. It can be much better to document guidance and recommended/suggested practices for scenarios such as working with projects that contain files with similar contents.
-- One big reason that the wider use of multiple extensions on a file has never taken off is that File Explorer (or anything that lists the contents of the file system--including OS provided pickers and dialog) can bring more confusion when they (are configured to--which is the default) hide known file extensions. This can make MyClass.winui.xaml look like MyClass.winui which then leads to questions and confusion about what the file is, where it came from, why it's being shown, etc.
-- Adding multiple/sub extensions increases file length and so increases the chances of running into MAXPATH related issues. Maybe one day this won't be an issue, but we're not there yet. I'd hate to see developers forced to give their files (and classes, as the two are typically kept in sync) less descriptive names because the tooling now needed an extra six characters for the extension(s).

It creates more work for tooling developers. (Both within and external to Microsoft.)
-- More case to handle.
-- More scenarios to document and test.
-- Less time spent on bug fixes and new features. With current XAML tooling perceived as being lacking behind other technologies and slow to create custom tooling for, why do anything that makes building new tooling slower?

It risks setting a very bad precedent.
-- If this happened, why would it not then be appropriate to replace all current .xaml files with .wpf, .uwp, .xamarinforms, etc.? Or .xaml2006, .xaml20009, .xaml-uwp5 if the underlying namespace, rather than where they're used is the key issue? There would be a minimal potential benefit (as in this case), but it would be seen by many as the way that Microsoft suggests naming files. (I wouldn't be surprised if someone didn't make such proposals just on seeing the discussion here.)
-- I'm not aware of (but happy to be corrected about) any MS provided tooling handling files differently based on sub-extensions but doing this would likely force Visual Studio (and others?, including Windows Shell?) into needing to be able to handle these scenarios. Then, once the capability is there I can imagine the temptation to introduce a wide range of complex but otherwise unnecessary naming suggestions being proposed and introduced being too much for some developers, leading to confusion for the rest of us.

In summary, the proposal would bring confusion and more work for a theoretical benefit in limited circumstances. If you did this, I'd give up on Windows development.

Thanks to everyone for lending your voice. We heard you! We collected enough feedback, so we can firmly say that changing the .xaml extension is a non-go.
It is not our intent to fragment the ecosystem or break 3rd party tools (and there are a lot). We agree that XAML is the language, and WinUI 3 is a UI Framework that uses XAML. For all these reasons, and other ones, make sense to continue using the xaml extension.
Our team still have to do some homework and evaluate other alternatives that we should consult with the community later.  For instance:

Do nothing. XAML Islands dev experience will be as it: XAML files in a different project (perhaps this is not a big deal). WInUI 3 will use the same namespace, and it doesn't matter because it will be the only XAML language used on the project.

Use namespaces to differentiate between UIs based on XAML. Today, WPF XAML and UWP XAML use the same namespaces, perhaps WinUI 3should use a different namespace like Xamarin Forms is doing ( "http://xamarin.com/schemas/2014/forms"), so the compilers, tools, and designers can differentiate files. On the flip side, this will create dialects, although this is happing today.  In theory, this will facilitate devs to copy and paste XAML examples from docs/blogs, although unfortunately, there are a lot of samples that don't include namespaces.

Do something, but just for Islands. No need to differentiate at all the UI frameworks. We can use conventions. For instance, in the future, a WPF app with XAML Island can contain XAML files in a specific folder (islands folder?). This is similar to the UWP localization (Strings/en-US/Resources.resw).

Thank you again for your feedback. I will open new discussions when we mature more ideas.

Including a snippit or doctype style line for an island file, should be enough for the tooling.

If like the .ui.xaml idea because it is a good compromise. It is still a valid XAML extension, and can also help select the correct editor and icons. It is also more efficient than opening and parsing XAML files just to find a type.

@marb2000 WinUI 3 is a UI Framework that uses XAML

Should be: WinUI 3 is a UI Framework that can use XAML. Since it doesn't require the use of XAML and doesn't need a dependency on the XAML language.

We agree that XAML is the language

That's good, and a lot of namespaces that are called XAML need to be renamed in WinUI: anything that doesn't have to do with the XAML language.

The de-emphasis of UWP has been painful to witness.  Now, when you do a search on channel 9 for UWP content, you get Xamarin content.  It's such an obvious ploy.  Please stop trying to morph UWP into something else!  Re-invest, double down, and make it work.  UWP does not need a course correction, it needs a the Xamarin and Office teams to get on board.

@Noemata Is it an office note?


Using filters to prune out irrelevant data

The url from hltv.org lists all of the csgo players, even from tier 3-4 + which aren't quite relevant when compared to higher tier professionals.
It'd be better if a ranking filter is added to prune the dataset somewhat.

i want to work on this issue. kindly assign me this issue.

@sbk2k1 me and @aarshgoel1502 are working together for this issue

Sure!


there is something wrong when I ran "demo"

When I ran the code "python demo.py --cfg cfgs/maskrcnn.yml --path data/demo/test.jpg",
It can get the key point of plate,but it can not recognize the plate.
File "demo.py", line 54, in
rec_res = chars_recognize(vis_image)
File "/Users/test/code/OCR/EasyPR-python/lib/recognizer.py", line 28, in recognize
return eval('recognize' + _methods[method])(src)
File "/Users/test/code/OCR/EasyPR-python/lib/recognizer.py", line 34, in _recognize_easypr
dir_name = find_last(cfg.OUTPUT_DIR, 'chars')
File "/Users/test/code/OCR/EasyPR-python/lib/utils/find_last.py", line 13, in find_last
dir_names = next(os.walk(output_dir))[1]
File "/Users/test/anaconda2/envs/pr/lib/python3.5/os.py", line 371, in walk
scandir_it = scandir(top)
TypeError: scandir: illegal type for path parameter

我把路径给写死了，现在可以运行了

Hello,I also encounter the same problem as you.How did you solve?


Allow wzprof to run without dwarf

Regression from #46. By turning this error into a warning, we allow wzprof to be used on modules that don't have DWARF, such as those produced by golang/go, and still provide meaningful results (though laking line-level profiles, and source code display).
cc @codefromthecrypt

Looks good. It might be better to say "dwarf not available" instead of the first warning, but hey, it works!
$ GOOS=wasip1 GOARCH=wasm gotip build -o math.wasm math.go
$ wzprof -sample 1 -memprofile /tmp/profile math.wasm
2023/05/19 07:02:02 warning: symbolizing wasm module: dwarf: decoding dwarf section info at offset 0x0: too short
3
$ go tool pprof -http :4000 /tmp/profile


Add two css parameter and keyword allowing customisation

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.
Please provide enough information so that others can review your pull request:
Explain the details for making this change. What existing problem does the pull request solve?
Unit Tests
Code formatting
Closing issues

Released as 2.3.4


tesis

Extension Name: python
Extension Version: 0.2.3
OS Version: Windows_NT x64 10.0.17134
VSCode version: 1.28.0

We have written the needed data into your clipboard. Please paste:

@BryanPadilla please close this yourself - this issue is not useful at all as it has no content about an actual issue, just the version numbers


Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Source
What is your build target?
Linux
Did you edit anything in this build? If so, mention or summarize your changes.
no

It isn't a bug. It was never meant to fully kill you, at least my coding of it wasn't (I made the script during development). It's only supposed to take some of your health, but let you continue with the song if you get hit.

i would have to take a second look, but I'm mostly sure it does not take any health. i don't fully remember.

Checked on Linux and seems to be good there :man_shrugging:
https://github.com/pahaze/Mistful-Crimson-Morning/assets/69173292/f6d46e1a-0b2a-49a6-9a6d-8bde4f1a18ef


Add fallback if metadata server cannot be resolved

I'm currently trying to run a docker repository server van cannot edit the hosts file. Adding this fallback can serve as a hack until the hosts file is setup correctly. see #6 and #7

Looks like these changes eventually got added; closing this PR.


Streamline CA and cert handling

Currently, the service broker is generating its own CA and cert which is presented while communicating with any client trying to communicate with the broker:
https://github.com/appscode/service-broker/blob/master/chart/service-broker/templates/cluster-service-broker.yaml#L1-L5
This means that the client needs to have this CA in its trust store, which might not be desirable in some cases.
We need a better mechanism of handling certs, e.g one approach might be to provide an option to pass custom CA cert while performing the installation.

I have the same problem  too .


draw_elements_with_f64 offset parameter shouldn't be a float

Hey, unless I'm missing something it seems like draw_elements_with_f64's offset shouldn't be a float but rather a usize or u32 or something like that..?

Since the offset is an offset into the buffer of data.
Or am I missing something?
Cheers!

Well I guess I need to learn how to read 🤷♂  . Looks like there are other methods (although I'm still not sure why you'd need an f64 offset
https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.WebGlRenderingContext.html#method.draw_elements_with_i32

Javascript doesn't support 64-bit integers natively, so when the WebIDL defines a u64/i64 parameter (like offset there) the bindings generator compromises by emitting a version taking a u32/i32 and a version taking an f64. The u32/i32 version is usually all you need but an f64 can hold exact integers up to 53 bits so it can support a much wider range of values.


Backport HSEARCH-3433 to branch 5.11 - Upgrade to Hibernate ORM 5.4.0.Final

https://hibernate.atlassian.net//browse/HSEARCH-3433

Pull Request Test Coverage Report for Build 1

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 83.91%

Totals

Change from base Build 7:
0.0%

Covered Lines:
23775

Relevant Lines:
28334

💛  - Coveralls