Refactor the plugin API

This is a major redesign of the plugin API. This aligns Bulwark's plugin API to the WASI 0.2 types.
Redesign goal
Parameterize the handlers so that plugin developers no longer have to make awkward function calls to pull in values that make more sense as parameters. (e.g. get_request()) Similarly, handlers now have return values that make their intended output more explicit. A secondary goal is enabling future performance improvement by allowing WASM instances to be recycled instead of having to create and tear them down on every request.
Major changes in this PR

wasmtime updates necessary for WASI 0.2 (supercedes #191)
updated WIT definitions for the new API design
refactored external processor, extracting a new ProcessorContext with a lifetime that lines up with the request/response cycle
refactored integration tests to make them less flaky

Caveats

This PR does not implement instance recycling even though enabling it is one of the PR's goals. This will happen in a follow-up PR.
Even though the wasi:http/outgoing-handler API is wired up and implemented, it doesn't seem to be getting exposed correctly in the compiled .wasm output. I don't know why, but I'm inclined to treat it as a bug to fix after this PR lands rather than as part of it, unless the cause of the bug gets spotted during review. This PR has already been in-progress for way too long.

Summary by CodeRabbit

New Features

Introduced a new job to check ABI files for up-to-dateness in the CI workflow.
Updated adapter documentation for compatibility with new wasmtime releases.
Introduced the build crate for Bulwark's plugins, enhancing plugin build and error handling processes.
Added functionality for managing plugin information and interactions, including WASI contexts, I/O buffers, and Redis connections.
New interfaces added for handling configuration settings, I/O event handling, random data generation, network operations, HTTP requests and responses, and Redis interactions.

Enhancements

Improved error handling across various modules.
Enhanced functionality and organization of conversion implementations between different types related to plugin configurations and decisions.
Updated testing structure and added functions for building and executing plugins.

Refactor

Restructured the Plugin implementation and related methods for creating and managing Decision instances.
Removed direct access to the headers module for improved encapsulation.
Renamed and redefined handler functions in the WASM SDK.
Converted modules to public and adjusted service initialization for greater accessibility and clarity.

Documentation

Updated README files across various crates to reflect new features and changes.

Chores

Added and updated .gitignore rules across several directories.

I noticed as I was wrapping this PR up that Bulwark gives slightly unintuitive scores for single-plugin configurations. Based on the numbers, I think it might be a result of a decision combination with an extra value that's not associated with any plugin output at all? Not sure if this PR introduced it or if it existed prior, but it should get fixed, even though actual impact is likely negligible.

The most important part of this change was the updates to the files in the wit/ directory. The wit-bindgen macro derives traits from these files, which are then implemented in the PluginContext.

I did see a TODO mentioning overflow checks. It would probably good to just validate values to be in the specific expected range of 0..u64::MAX as early on as possible, which I'm guessing would be in the guest environment.

I'm assuming you're referring to this comment:
// TODO: handle overflow errors by expiring everything on overflow and returning nil?

That's related to the possibility that we could increment a counter enough that the counter overflows. However, I just tested it out and Redis already guards against overflows natively. We just have to handle that error:
(error) ERR increment or decrement would overflow


UTxOW witnesses in conway

In the conway ledger era, the UTxOW rule will need to gather authorization for:

[x] DReps and CC that use script credentials (so script witnesses)
[x] signatures for votes: SPOs, DReps, and the CC

This was implemented a while ago


Cannot read property 'apply' of undefined

This happens when I specify the requestError function. Tested it in a new create-react-app with https://github.com/github/fetch.
import fetchIntercept from 'fetch-intercept';

const unregister = fetchIntercept.register({
  requestError: (error) => {
    return Promise.reject(error);
  },
  responseError: (error) => {
    // catches bad error here
    return Promise.reject(error);
  },
});

fetch('http://google.com');

// Unregister your interceptor
unregister();

Looking at the source, _ref.request is undefined.
	  reversedInterceptors.forEach(function (_ref) {
	    var request = _ref.request; // request is undefined
	    var requestError = _ref.requestError;

	    if (request || requestError) {
	      promise = promise.then(function (args) {
	        return request.apply(undefined, _toConsumableArray(args));
	      }, requestError);
	    }
	  });

Same issue here.

Temporary workaround should be defining a request function at least as empty:
{
  request: () => {},
  requestError: () => {},
}

Looked at the tests and figured out that requestError is pointless without request interceptor because requestError would only catch errors from interceptors?


Add set up and troubleshoot instruction

I've had v2022.11.10 installed on Lapce v0.2.4
In $GOPATH/bin is gopls v0.10.1
But it's not working
I've tried to set server path, but it's not works too
And nothing related on log except
[2022-11-24][20:01:36][wasmtime::linker][WARN] command module exporting '__heap_base' is deprecated
[2022-11-24][20:01:36][wasmtime::linker][WARN] command module exporting '__data_end' is deprecated

Can you provide any instructions to this thing?
Both for setting up and troubleshooting
Also, where can I change gopls settings (I prefer gofumpt to gofmt)?
System: openSUSE Tumbleweed

Should be fixed


Fail to create window on Sierra 10.12

I've tried running a simple example which is available on learnopengl.com and it seems like the window creation called through glfwCreateWindow() fails because of the first responder on Cocoa.
I've tried downloading the most recent version of the code from the repo - which seemed to address the problem - and recompiled the library locally, but still it doesn't seem to work properly and this is the output I get from the function call mentioned above.
2016-11-27 19:33:40.726198 GLFW[37260:6137830] [General] ERROR:
Setting <GLFWContentView: 0x102a26000> as the first responder for window
<GLFWWindow: 0x10071d510>, but it is in a different window ((null))!
This would eventually crash when the view is freed. The first responder will be set to nil.
(
	0   AppKit                              0x00007fff798a69a4 -[NSWindow _validateFirstResponder:] + 566
	1   AppKit                              0x00007fff790979eb -[NSWindow _setFirstResponder:] + 31
	2   AppKit                              0x00007fff7913f66a -[NSWindow _realMakeFirstResponder:] + 406
	3   AppKit                              0x00007fff7913f480 -[NSWindow makeFirstResponder:] + 123
	4   libglfw3.3.dylib                    0x00000001000ab8fd _glfwPlatformCreateWindow + 617
	5   libglfw3.3.dylib                    0x00000001000a7427 glfwCreateWindow + 486
	6   GLFW                                0x0000000100001003 main + 99
	7   libdyld.dylib                       0x00007fff9056b255 start + 1
	8   ???                                 0x0000000000000001 0x0 + 1
)
Failed to create GLFW window
Program ended with exit code: 255

@umberto-sonnino What does glfwGetVersionString return?

@elmindreda I get this:
3.2.1 Cocoa NSGL chdir menubar retina dynamic

Set an error callback to get a better idea of why creation fails.

The problem seems to be the following:
65543 NSGL: The targeted version of macOS only supports forward-compatible contexts for OpenGL 3.2 and above
Thus it fails in creating the window

@umberto-sonnino Are you setting the forward-compatible context hint to true?
If not, that's the source of your problem. See https://github.com/glfw/glfw/issues/904#issuecomment-262812712, https://github.com/glfw/glfw/issues/832#issuecomment-239379009 and https://github.com/glfw/glfw/issues/812#issuecomment-234724790.

@shurcooL
Yeah I had set the flag, but still it doesn't seem to work properly. I'll try to figure out if something is not set up properly with the dylib

maybe its related to the issue #883. I'm having the same problem using the version 3.2.2.

I get the same error message to stdout, but it creates a window and everything seems to work normally besides the message.

@eberlitz There is no version 3.2.2.

@AndersenTobias Are you getting the first-responder message or the forward-compatible context message?

This first-responder message:
[General] ERROR: Setting <GLFWContentView: 0x10200be90> as the first responder for window <GLFWWindow: 0x100538e60>, but it is in a different window ((null))! This would eventually crash when the view is freed. The first responder will be set to nil.

@AndersenTobias That has been fixed in master.

Is it all right to close this now?

@elmindreda
Yeah sure! Thank you

can I know where to fix it? I got the same error of 'Setting <GLFWContentView: 0x100608aa0> as the first responder for window <GLFWWindow: 0x10070c810>, but it is in a different window ((null))! '

@lilyyyyyy2015 Just clone this repository, compile and use. That issue was fixed since the latest release.


Set INFOPLIST_FILE for resource bundles

Regressed with e141dec0e76244bf72c11d7b4e38d2d1629ad9e5.

Confirmed this fixes our RTE - thanks very much @brentleyjones!


Don't use the real home directory for tests.

@jds106

Looks good.

http://junit.org/junit4/javadoc/latest/org/junit/rules/TemporaryFolder.html


Unable to set Window Title in XAML

Describe the bug

In WinUI3preview3, unable to build a project if set the Window Title in XAML.
Steps to reproduce the bug

Create a new Blank App, Packaged (WinUI in Desktop)
Change the content of MainWindow.xaml to add the following on line 8

<Window
    x:Class="App68.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App68"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    Title="my app"
    mc:Ignorable="d">

Build the solution
See an  exception:

MainWindow.xaml(8,5): XamlCompiler error WMC0612: The XAML Binary Format (XBF) generator reported syntax error '0x09C4' : Property Not Found

Remove the change in the XAML file and set the window Title in the constructor. e.g.:

    public MainWindow()
    {
        this.InitializeComponent();
        this.Title = "my app";
    }

Run the app and see the title displayed correctly.

Expected behavior

It should be possible to set the Window Title in XAML.
Screenshots

Version Info

NuGet package version:  Microsoft.WinUI 3.0.0-preview3.201113.0

Windows app type:

UWP
Win32

Yes

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2020 Update (19041)
Yes

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context

@ocalvo FYI, who was it that finished up the title bar work in winui3?

⚠ Still a bug in Preview 4. @StephenLPeters

Still broken in WinUI 3 production, Project Reunion 0.5.7.

Still Broken.

still not fixed

Still not fix in Reunion 0.8

Still broken in 1.0-experimental1. @marb2000 We're not going to ship 1.0 with the inability to set the window title right? RIGHT? 😂

@riverar "inability' might be a little much. I mean it is technically possible:
        [DllImport("Microsoft.UI.Windowing.Core.dll", CharSet = CharSet.Unicode)]
        private static extern IntPtr GetWindowIdFromWindowHandle(IntPtr hwnd, out Microsoft.UI.WindowId result);

        private static void SetTitle(string title, Window window)
        {
            var handle = WinRT.Interop.WindowNative.GetWindowHandle(window);
            IntPtr whatIsThisReturnValueEvenFor = GetWindowIdFromWindowHandle(handle, out var windowId);
            var appWindow = Microsoft.UI.Windowing.AppWindow.GetFromWindowId(windowId);
            appWindow.Title = "New window title";
        }

However is this an acceptable amount of code to manage your window, in a v1.0 release? (hint: The answer isn't yes).
I'm worried people will take one look at WinUI and see that basic window management APIs are more or less non-existent (or as shown above overly complicated to use), and write off WinUI before it even had a chance.

@dotMorten 🤠 Thankfully we can this.Title = "Floop"; but it's pretty ridiculous that this still blows up XAML with an obscure error.

There is an (ugly) workaround though. In your Window sub class add this:
        /// <summary>
        /// Gets or sets the window title.
        /// </summary>
        public new string Title
        {
            get => base.Title;
            set => base.Title = value;
        }

However I'm worried that the lack of window management APIs and Title can't even be set from XAML as we're used to is going to be extremely off-putting to users. Is the amount of code you need to write acceptable, just to do basic management of your window, in a v1.0 release? (hint: I don't think the answer isn't yes).
I'm worried people will take one look at WinUI and see that basic window management APIs are more or less non-existent (or as shown above overly complicated to use), and write off WinUI before it even had a chance.

@dotMorten 🤠 It's pretty ridiculous that this still blows up XAML with an obscure error. But agreed. 👍

I had started writing WinUIEx as a temporary stop-gap to the lack of Windowing APIs, but hadn't bothered completely finishing it up or publishing a nuget, because I naturally assumed basic Windowing APIs would be in 1.0, and I was also reluctant because the entire implementation just feels like one giant band-aid. It seems like I need to do bring this all the way to at least close some of these obvious gaps for 1.0.

Still... present in Preview 1. They got less than two months to fix this.

Don't think this is getting fixed any time soon, now that there's a workaround. 😞

It's still broken. I'm currently using the constructor method for temporary fix.
this.Title = "App Title";

Unfortunately, per the latest engineering plan, the bug fix won't make the v1.0 Stable release (GA) and was moved to v1.1

It is really off putting to still invest into WinUI stack instead of WPF, when such basic features don't make it to  1.0.
One more hurdle since Windows 8 rewrites roller coaster started.

This is ridiculous as a so basic function doesn't work on the official version 1.0.

Yep, just decided to try UWP and WinUI but this thing is just horrible to work with. Back to good ole win32 it is

Not sure if directly related but when using MAUI blazor app template targeting Windows, title doesnt seem to work either from setting in xaml or ctor of mainpage.

Similar to what olabacker found, when using a .NET MAUI App template targeted on Windows the title won't appear when defined either in MainPage.xaml or in MainPage.xaml.cs.
I tried adding dotMorten's snippet to MainPage.xaml.cs and setting the property in the constructor, but still no title appeared.  As this template produces a WinUI app, presumably it's the same problem.
Apps for scientific data processing can use upwards of 50 forms and dialogs in old Windows Forms app speak, having a form or window title is essential otherwise the user won't know where they are or how what they are seeing relates to documentation..

The bug which could not die.   Maybe in 1.1?

 You can't even set title in WinUI3 app?

I have set it programatically in App.xaml.cpp and it worked. Seems like a XAML only issue.

Which is exactly what the first post says. But yeah, that's just one of the wonderful experience developers get when they try out WinUI.

Just tried with the latest v1.1.0-preview1 and still doesn't work. And to make matters worse, the error message is extremely unhelpful with no indication about what property or where:

1>MainWindow.xaml(8,22): XamlCompiler error WMC0612: The XAML Binary Format (XBF) generator reported syntax error '0x09C4' : Property Not Found

Perhaps MainWindow Title was purposefully left for a while out so engineers would have practice implementing WinUI3 properties. Is it a coincidence that the main bind sample is the Title property?  :-)
https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property
I use C++ coming from C# XAML, so I'm finding this to be a great exercise. :-)

Still broken a year and a half later...

Welp still not fixed. I think we'll have to wait about at least 5 more years for this issue to be fixed cause apparently there are other 2.7k current open issues.

@soobakjonmat I agree this is annoying. But it is by no means a showstopper like many other issues. You can still set it in code behind or use something like WinUIEx’s WindowEx to do it.

A (better) alternative is to use Win32 directly and have full control.

@soobakjonmat I agree this is annoying. But it is by no means a showstopper like many other issues. You can still set it in code behind or use something like WinUIEx’s WindowEx to do it.

Yeah I'm just saying that it's probably gonna take a while to get it fixed. I'm using this.Title =  so no problem there.
And while reading my own comment again, it does sound sarcastic and apologies for that. I guess I was a bit grumpy while I was writing that comment cause I haven't slept all night.

Maybe it's worth mentioning that the workaround for C++ looks like this:
MainWindow::MainWindow()
{
    InitializeComponent();
    this->Title(L"Your Window Title");
}

Still not working without workaround...

I think we have been making a XAML title assumption for WinUI based on WPF experience. Code samples here imply that Title in XAML is not intended and by leaving it out of XAML, we are led to discover the Title Bar capabilities:
https://learn.microsoft.com/en-us/windows/apps/develop/title-bar?tabs=wasdk
I.e.: I think that we have a "Works as intended" status here.

I think it’s a reasonable assumption. What I think went wrong here is the window is a non-WinUI window without the WinUI stuff in it (like inheriting from Dependency Object, understand styling etc). WinUI should make its own Window type that wraps the underlying Windows App SDK window and provide a proper developer experience that’s expected in 2022. I don’t buy the argument that it is as designed and existing expectations aren’t valid - if you want people to move over you need to provide an experience at least on par. The entire Window class is a mess to work with and needs something designed properly for the xaml developer.

I see your point. Perhaps the idea is to abstract the concept of "app look and feel" and provide a somewhat lower-level app UI shell while providing more power and control to the engineers/designers. Thus, a company can create a product app brand UI shell (outer framework) XAML template. I do like the idea of more control. Easy enough to make a template with a Title property and Title Bar is example. Perhaps one of us here could make a basic template with Title property and offer it as the standard wrapper that you mention. I can keep it mind and if I offer one, I'll mention here. Open source has its advantages but also might require a bit of a shift in mindset. :-)

WinUI is the future of Windows desktop development.  And this is STILL broken.
Microsoft needs to double the size of its WinUI development team.
WinUI desktop applications are the future of software development as I point out in my website:
https://WinUI3.org

Agreed, this is only a small annoyance, but such a simple feature to be reported and still broken after almost two years is scary.
Makes one think about Microsoft commitment to WinUI3.
So far I haven't hit a roadblock. Yes many minor bugs, a workaround here and there, but nothing remarkable. But it looms large the possibility of finding a major bug in the future that Microsoft won't address.

The ability to set the Title was added in WinAppSDK 1.3, but there was an issue with it.  That issue has been fixed in 1.3.1 that is now available.

@bpulliam Don't you mean v1.3.230502000 ? Congrats on 171000 builds in a month :-D

Well played :)

For those reading this and are confused like I was, Windows App SDK 1.3 Preview 1 (referred here as 1.3.1) shows up on NuGet as 1.3.230228005-preview1 for whatever silly reason. You'll want to add that to your project to pick up this change.

So, I tried this and it doesn't seem to work. Did either of you try it?

@riverar 1.3.1 = 1.3.230502000 (built May 2, 2023), not preview1 (1.3.230228005-preview1 built Feb 28, 2023).  Its about 2 months newer :).

Ah, was going off the documentation which has no mention of 1.3.1, sigh.

Wow it works. The end of an era!

Ah, was going off the documentation which has no mention of 1.3.1, sigh.

The docs have been updated (https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-131-13230502000).  Thanks for the heads-up

How is one supposed to teach developers to use WinUI 3 when the first steps with application requires searching for weird C++ code hacks?
Window sizes were solved in .NET Framework 1.0

Ah, was going off the documentation which has no mention of 1.3.1, sigh.

The docs have been updated (https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-131-13230502000). Thanks for the heads-up

They say there: "Fixed issue causing apps to crash when setting the Window Title in XAML, a new capability added in 1.3.0. For more information, see GitHub issue #3689."

But setting ExtendsContentIntoTitleBar still gives the same error.

WindowsAppSDK 1.5.3, unpackaged c#/c++
This doesn't work when setting DisableXbfGeneration=true or using XamlReader::Load().
MainWindow.xaml
<?xml version="1.0" encoding="utf-8"?>
<Window
    x:Class="App1.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Title="hello">

    <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" VerticalAlignment="Center">
        <Button x:Name="myButton" Click="myButton_Click">Click Me</Button>
    </StackPanel>
</Window>

error
Failed to assign to property 'Microsoft.UI.Xaml.Window.Title'. [Line: 10 Position: 5]

Program fails at https://github.com/microsoft/microsoft-ui-xaml/blob/2a60e27c591846556fa9ec4d8f305afdf0f96dc1/dxaml/xcp/core/core/elements/CWindow.cpp#L73

At this line https://github.com/microsoft/microsoft-ui-xaml/blob/2a60e27c591846556fa9ec4d8f305afdf0f96dc1/dxaml/xcp/core/core/elements/CWindow.cpp#L70
When DisableXbfGeneration=false, type of args.m_value is valueString.
When DisableXbfGeneration=true, type of args.m_value is valueObject.


webpubsub beta.5

fix https://github.com/azure/azure-sdk-for-java/issues/24814

apiview
https://apiview.dev/Assemblies/Review/68e52134d2a9468b9566bdedfd2b787c?diffRevisionId=3d4c2040994a4da0bc380c286e6f1174&doc=False&diffOnly=False

API changes have been detected in com.azure:azure-messaging-webpubsub. You can review API changes here


slugbuilder: Bump buildpacks

https://github.com/cloudfoundry/staticfile-buildpack/compare/f3586855...7dc23e00
https://github.com/heroku/heroku-buildpack-ruby/compare/4bf28114...526dfadc
https://github.com/heroku/heroku-buildpack-nodejs/compare/7e0ef6a8...e14c33b6
https://github.com/heroku/heroku-buildpack-clojure/compare/fe550950...16d2e8fe
https://github.com/heroku/heroku-buildpack-python/compare/61d3d958...129ce5f0
https://github.com/heroku/heroku-buildpack-java/compare/c085def3...13dee501
https://github.com/heroku/heroku-buildpack-scala/compare/f5b90f5c...91d0cfc4
https://github.com/heroku/heroku-buildpack-php/compare/402c2691...044a2899
https://github.com/heroku/heroku-buildpack-go/compare/fa0679c3...70f622b4

LGTM


PackageId:Microsoft.VisualStudio.Setup.Configuration;PackageAction:Install;ReturnCode:1603;

This issue has been moved from a ticket on Developer Community.

[severity:I'm unable to use this version]
I had VS2019 installed and tried to add the Python library. That produced an error and I tried to update to version 16.XXX which produced an error. Now I try to install VS2022.

Original Comments
Feedback Bot on 4/24/2023, 06:34 PM:
(private comment, text removed)

Original Solutions
(no solutions)

This looks like a VS setup issue, transferred the issue to the setup team.


bundler: Add utilities to handle swc helpers.

swc_bundler:

Add HelperLoader and HelperResolver.

I found that self-referential functions like
function foo() {
    if (Math.random() > 0.5) {
        foo()
    }
}

is not dropped. I will merge this issue after making dce handle to case above.

@kitsonk I noticed that including only required helpers using dead code elimination requires lots of work, so I'll add explicit handling of helpers to swc_bundler.


[KYUUBI #491] Add Spark nightly build CI

Why are the changes needed?
This patch add Spark nightly build CI
How was this patch tested?
github action CI passed

Thanks for your first contribution and welcome! Just left some minor comments.

@yaooqinn Thanks! And I noticed that we have two CI configuration: github action and travis, I'm not sure why we need all them.
Maybe we will remove the travis( or github action) config in future? So I'm not sure should I also add this CI in travis?

Maybe we will remove the travis( or github action) config in future?

I've been asked many times about this. Personally, I am not fully trusting the stability of free CI providers(with a grateful heart off course). As we don't want to block PRs because of CI flakiness, as long as one side passes, we can merge the PR.
As you can see the Github Action environment is not stable these days, I also see these errors in the Spark project too.

So I'm not sure should I also add this CI in travis?

yes. As I am not 100% sure you can pass Github Action for now

Greate, and thanks for your explanation, make sense.

As I am not 100% sure you can pass Github Action for now

now I'm 100% sure I can't pass the github action : ( raise the issue here: https://github.com/yaooqinn/kyuubi/issues/496

My bad, I forgot to let you know about this property -Dmaven.plugin.scalatest.exclude.tags=org.apache.kyuubi.tags.DataLakeTest

seems we do need :kyuubi-common,:kyuubi-ha too

seems we do need :kyuubi-common,:kyuubi-ha too

and kyuubi-zookeeper, the ./build/mvn clean install -pl :kyuubi-spark-sql-engine,:kyuubi-common,:kyuubi-ha,:kyuubi-zookeeper -Pspark-3.2-snapshot -Dmaven.plugin.scalatest.exclude.tags=org.apache.kyuubi.tags.DataLakeTest had been passed in my loca env.

Using `mvn` from path: /usr/bin/mvn
awk: cmd. line:2: (FILENAME=- FNR=1) fatal: attempt to access field -1
Error: Process completed with exit code 1.

[1] https://github.com/yaooqinn/kyuubi/pull/495/checks?check_run_id=2303522554#step:10:45
Looks like some github action ci error happens in here, I'm not familar with it, could you take a look?
Note: the lastest code still passed in my locl env.

seems caused by https://github.com/yaooqinn/kyuubi/pull/488, will check it.

we can skip dependency check for this job with if statement  or set it like Check License  separately

Thanks, merged to master for v1.2.0


Run "small hitbox change" logic on image manipulation

Move the logic of "not changing the hitbox if it's a small change" out of setImage() and into setHitbox() so we can use it if the sprite has its image manipulated.

@livcheerful do I need to take this to release?

@abchatra this is something @jwunderl suggested as a result of this change in the release https://github.com/microsoft/pxt-common-packages/pull/1133/files
I think this is a good change to take so future games won't have weird bugs

Yeah, Abhijith and I were talking while figuring out merging some other stuff.
For future reference / reasoning for this change:
A while ago in .setImage we added logic to prevent tiny changes to the hitbox - this fixed issues where there was a sprite with an animation that changed it's dimensions by ~1 or 2 pixels and would cause it to clip into the wall.
The change to add .setHitbox / detect mutations in the image fixed cases where a sprite's image was changed after being set, but added a new path for setting this hitbox. This change just merges the paths for creating / setting hitboxes, so that mutating a sprite's image and setting to a new image will result in the same hitbox / behave consistently


config-ui: can not add connections

Describe the bug
After clicking 'add a connection' in GitHub/GitLab...
To Reproduce
Steps to reproduce the behavior:

Go to config-ui, enter any data source, for instance, GitHub
Click on 'Add connection'
See the form

Screenshots
I can't input value or create connection.

@Startrekzky This is a non-issue, how did you access this page? Did you manually type an add connection URI in the browser path? GitHub is not multi-source and therefore cannot support multiple connections. This page is disabled and not accessible by GitHub.

This due to nginx resolver must be FQDN when deployed to k8s, causing config-ui unable to talk to devlake service (the problem appears only on new k8s instance)
I had fixed the instance on k8s, need some more work to finish up the PR.
However, I notice the offline prompt doesn't seem to be working when server side responsed 502?


Methodological doubt about stores sessions data after login

I know passport work this way: the strategies are different authentication mechanisms, so when the user submits their credentials, the request will be passed to Passport’s authenticate() middleware and invoke which ever Strategy we have configured for that request route. These credentials (req.body.username and req.body.password) are passed into our Strategy and subjected to verification. If verified, the user will be serialized into the session and logged in to the application, if not verified the Strategy will return an error and the authenticate()middleware redirects to our designated failure location. Something like this.

My question is.... At the time of login , I understand that you can store more information than the username and password . But after that how I keep other information in the session like the last page the user visited, the last option he chooses in certain search, i mean, information that can be accumulated during the session?. Using the serialization function?. Or i have to create my own methods POST, UPDATE, etc; for that?.
Info obtained:
http://toon.io/understanding-passportjs-authentication-flow/
https://orchestrate.io/blog/2014/06/26/build-user-authentication-with-node-js-express-passport-and-orchestrate/

+1 Here. I'm actually just trying to access the authentication token from the client side in a mocha test, but this answer will clearly solve my issue too.
Docs are not very clear at this point. I don't even know if it's being sent in a cookie (can't find it) or in the postdata (neither)...
I'm trying to develop some cool stuff (cool enough for a newbie like me) that I will introduce you as soon as it worth it).


isstools v3.0.0 and xas v0.0.1 packages

Tagged the version of ISS packages. Need to have them at the beamline during the deployment 19-2.

xas was tested to build locally, worked fine. isstools depends on that, so I wasn't able to test it via a separate Docker container. Hopefully, it will be built fine. Merging to check it.


Suggestion: Allow lambdas for parse option

We noticed an inconsistency in how Facebook responds to OAuth requests during callbacks.
When sending an access token, Facebook responds with a Content-Type of text/plain while the body is actually application/x-www-form-urlencoded encoded. That's why mkdynamic/omniauth-facebook hardcodes the parse option to :query.
During error conditions however, Facebook responds with application/json and the body being a JSON encoded Hash giving more information about the error encountered. Due to the need for hardcoding the parser to query for the normal responses (as Facebook misreports the content type), the error responses are now no longer parsed correctly.
To test this, simply attempt two OAuth requests against facebook. One using correct application credentials (thus receiving the form encoded response) and one using a wrong application secret (thus receiving a JSON encoded error response).
Currently, I don't see a clean way to institute different parsing behaviours for different responses without monkey-patching. One has to either always rely on the reported content type or always use the same parser as defined via the parse option. I would thus like to suggest having the latter accept lambdas which would get passed the entire response (incl. headers) and return :query, :json, etc. as appropriate. The behaviour for non-lambda values would remain the same, thus ensuring backward compatibility.
Let me know what you think; I'd be happy to send a pull request.

Documented in https://github.com/oauth-xx/oauth2/wiki/Examples#omniauth-facebook


license

what is the license of the repo?  thank you

Thank you for reaching out and for your interest in the project's license.
We've added the MIT License.


Add support for GNOME 46

I recently upgraded my Ubuntu version and with that came GNOME 46 and since then the extension no longer works.
I looked around and made the extension work by migrating new functionalities using this documentation. However, I am really struggling to get the preferences working.
I am new to this maintaining world and would like to help by suggesting my edit to add support for GNOME 46 but I am not sure exactly what the procedure is for public projects like this. Let me know how I can help!

I kept trying to get the preferences to work and for some reason Gtk keeps giving me a an error saying that it can't precompile the prefs.ui file because there is an error on line 1 character 1 (See below). I can't understand why I get this error because it is the exact same file that works with GNOME 42 and there are no mentions of this having changed in any version in between in the documentation. Any one knows how I could fix this?


Fix segfault in the Breadcrumbs system

The segfault occurred because a pointer to a component is invalidated by the creation of new components. This doesn't always happen, but if a component type had 99 items, and we take get a pointer to a component, as soon as new components of the same type are created, the underlying std::vector containing the component gets expanded invalidating our pointer. The underlying std::vector gets expanded every 100 components.
To test, run the attached world (extension is .txt because github doesn't allow .sdf files). It should crash after 2 sim seconds.
debug_breadcrumbs_crash.txt

The segfault occurred because a pointer to a component is invalidated by the creation of new components. This doesn't always happen, but if a component type had 99 items, and we take get a pointer to a component, as soon as new components of the same type are created, the underlying std::vector containing the component gets expanded invalidating our pointer. The underlying std::vector gets expanded every 100 components.

This feels like an issue we should resolve in ECS, correct? I could image this biting us and others in the future. If this is the case, could you create an issue for it?

I can create an issue, but I'm not sure what can be done because this is inherent to using a contiguous data container for the components. We can move to using something like std::list, but that defeats the performance benefits of ECS.


Jest unmock config

Exists a config to pass a list of files to not mock? Example.: I have a folder called helpers to my tests and i need use jest.unmock for each helper and components files.... like this.:
jest.unmock("../../../components/Table/Main")
jest.unmock("../../../components/Table/Head")
jest.unmock("../../../components/Table/Body")
jest.unmock("../../../components/Table/Row")
jest.unmock("../../../components/Table/Cell/Head")
jest.unmock("../../../components/Table/Cell/Data/Main")
jest.unmock("../../../components/Table/Cell/Data/Title")
jest.unmock("../../factories/components/base-factory")
A config that receives a list of unmock files will be helpful. Like: unmock: ['/helpers', '/components']

Yes, see unmockedPathPatterns. Please note this is not a help forum. Please read the documentation and API docs carefully and ask questions on stackoverflow. Thank you!


Broken template handling between 0.53 and 0.57.2

We're currently running https://kubernetes.io on Hugo 0.53.
We noticed behavior similar to #5615 when the deprecationwarning.html shortcode renders in deprecated versions. Consequently, we opened a pull request to upgrade Hugo from 0.53 to 0.57.2.
Upgrading to 0.57.2 fixes the #5615 behavior, but breaks template handling for all pages across the site.
Note that k/website:#16104 changes only the site's Hugo version.
For comparison:

Production build (0.53)
Preview build (0.57.2)

The Kubernetes API
The Kubernetes API

This is related to https://github.com/gohugoio/hugo/releases/tag/v0.55.0
I'm pretty sure that I created a PR in your repo with a backward-compatible patch. I don't think that PR was merged.
In any case, the newer Hugo version is tested to work fine with the Kubernetes site.

@bep

I'm pretty sure that I created a PR in your repo with a backward-compatible patch. I don't think that PR was merged.

It looks like the backwards-compatible fixes did merge, but you asked us to delay upgrading to 0.55.3.

In any case, the newer Hugo version is tested to work fine with the Kubernetes site.

Given the extent of breakage in previews for a PR k/website:16104 that only upgrades the Hugo version, this doesn't seem quite accurate.

that only upgrades the Hugo version, this doesn't seem quite accurate.

Before I released Hugo 0.55 I diffed the output of the Kubernetes site before/after and they came out identical.
I just tested the Kubernetes site with the version in https://github.com/kubernetes/website/pull/13680 with the latest Hugo and it works fine. You're right that it doesn't work with the current Kubernetes master, but that must just mean that someone has somehow undone the fixes that I applied.
In any case, I don't think we can do anything about it on the Hugo side of it, so I suggest you continue this discussion on the Kubernetes issue tracker.

that must just mean that someone has somehow undone the fixes that I applied.

It turns out we needed to cherry-pick the commit into the release-1.13 branch. We only merged the 0.55 backwards compatibility commit to master when it pointed to release-1.14 and later.
So, you are correct and all is good now. 🙇

Great. Now that you're getting the Hugo version up to date, you may want to consider using the new Hugo Modules to split the website and content into versionable modules, and possibly also split content per language, to possibly get something that's easier to manage.


Make adjustments necessary to support strong-mode compliance for over_react

In order for over_react to become strong mode compliant, a few changes are necessary in the wrapper:

In react.Component:

Remove public props and state fields in-favor of private fields with public getters and setters.

This is so that over_react can add strong typing to props and state within UiComponent / UiStatefulComponent, respectively without generating Dart analyzer errors.

Type the props / state arguments of lifecycle methods as Map

I also cleaned up a few analyzer errors showing in this repo as well.
FYA @greglittlefield-wf @jacehensley-wf @clairesarsam-wf @trentgrover-wf

@greglittlefield-wf all feedback addressed except for using the @virtual annotation - which for some reason, doesn't seem to work.

+1

@greglittlefield-wf ready for a final pass.

@greglittlefield-wf feedback addressed

+1, awesome stuff!

@trentgrover-wf this is ready for a merge + tag.


Skate 5: Questions

👋  I have a couple of 5.x questions not sure where to ask them, feel free to close if this is not the right place:

Why does the props helper doesn't have a function type? Not exactly sure how to declare a prop (of type function) other than using props.any

Can someone explain me why/how is that if I define a prop called lets say name, why is this.name and this.props.name pointing to the same thing? Is this expected? If so, what should I be using? Setting/Reading directly from this.name or this.props.name?
Seems like sometimes if I set thing using this.props.name doesn't pick it up but when I do this.name directly it does, super confused with this one.

How can I define a property in the constructor (not as a prop) but when it changes, trigger the renderCallback()? Currently I can't make it trigger renderCallback unless I make it a prop. Usage: I have a "private" property that I don't really want to "expose" (I know that everything is exposed anyway) but I would like whoever uses my components to just read trough the props and expect those to be passed down (kinda like reading docs) and I don't want to confuse them having that "private" state property.

To avoid ^ I tried defining a prop using a Symbol as a name, but everything crashed, is there a way to do this?

Is there any docs on how to setup some basic testing with Jest?

Note: Using preact renderer if that matters
PS: Thanks so much for these mixins, I'm so happy using them.

It might be a good idea to have this. We're definitely open to a discussion / PR here. I'm wondering if values should be "undefinable" or "nullable"?

props is a getter that returns an object of names / values for all props that are defined on the element. It's also a setter itself, but the object it returns doesn't react to changes, so you must set (elem.props = {}).

The second part to this is that when you want to get the names of all the props (own and inherited up the chain) you have to write a lot of code to go up the proto chain using getOwnPropertyNames etc. Using props you can just do something like Object.keys(this.props).
Public API to the consumer is properties on the element (elem.name). However, internal to the component, feel free to use props.
We're also likely to introduce a concept of state so it can be tracked and used separately from props. It would simply be a props entry, but is great for tracking internal state.

This is the reason I want to introduce an idea of state. Currently you have to make it part of props.

This is a bug. Symbols should work and this is the ideal way to do it.

See https://github.com/skatejs/ssr#running-in-jest. If you have any questions feel free to ask them in that repo if it's unrelated to Skate.

PS: Thanks so much for these mixins, I'm so happy using them.

That's so great to hear.
Let us know what you think about using a state prop.

It might be a good idea to have this. We're definitely open to a discussion / PR here. I'm wondering if values should be "undefinable" or "nullable"?

Expanding this question, whats the current "best approach" for this? I'm guessing just not defining the prop but just setting it directly in the component?
Since I would love for my users to just read my defined props and know what to send, it would be ideal to have a function type.
Can you explain to me about values should be "undefinable" or "nullable"? Do you mean like what should be the default value if the user doesn't pass anything to it? like if it should be null or noop?

We're also likely to introduce a concept of state so it can be tracked and used separately from props. It would simply be a props entry, but is great for tracking internal state.

This in combination with Symbols would be ideal in my use case, would love to keep a bit of separation between internal / props.

https://extranet.atlassian.com/pages/viewpage.action?pageId=3506394081

Yes, exactly this. Also, If they pass null, should it also be coerced to a noop?

This in combination with Symbols would be ideal in my use case, would love to keep a bit of separation between internal / props.

The thing about this is that if we use state, then it's public. If we use a symbol, it's not really any different than a consumer doing the same thing. I guess except that we might have it included with a base mixin, but is abstracting that away worth it? Maybe as it would illustrate best practice by having it included in the lib.

Interesting, I was actually referring about having state and then me as a consumer setting state names with symbols, not that all state should be symbols.
But now that you mention it being part of a mixing ... it might be useful, that would abstract away creating the symbols and assigning them to state keys. Not sure if the abstraction is worth it but it would be a nice to have. Maybe an opt-in mixin?

I was talking about state being a symbol itself:
Theoretical implementation
export const state = Symbol();
export const withState = (
Base: Class
): Class => class extends Base {
static props = {
[state] = props.object
}
}
Theoretical usage
import { state, withComponent } from 'skatejs';
// withComponent would automatically mixin withState
export default class extends withComponent() {
static props = {
name: props.string
}
renderCallback() {
const name = this.state.name || this.props.name;
return Hello, ${name}!;
}
}

I was talking about state being a symbol itself:

Thats even better, I like this a lot.
The only difference I see is that we would have to use it with this[state].name if I'm understanding this correctly.

The only difference I see is that we would have to use it with this[state].name if I'm understanding this correctly.

Yep.


Strange problem with kernel headers

One needs to install kernel headers to compile a kernel module (aircrack-ng/8812au v5.3.4) :
sudo apt-get install raspberrypi-kernel-headers
With a regular 2018-10-09-raspbian-stretch-lite, this command creates these directories :
/usr/src/linux-headers-4.14.71+
/usr/src/linux-headers-4.14.71-v7+

Then the driver can be compiled and works.
But with our script built image, these directories are created :
/usr/src/linux-headers-4.14.79+
/usr/src/linux-headers-4.14.79-v7+

Then the driver can be compiled but can't be loaded (modprobe: ERROR: could not insert '88XXau': Exec format error).
So I can't understand why the 4.14.79 kernel headers are installed in place of 4.14.71, with our built image ??
I hope someone will be able to solve this mysterious issue ...

The script is probably pulling the latest Raspbian which is 2018-11-13 (with kernel 4.14.79) since a few days, but the kernel sources are 'hardcoded' to 4.14.71 and thus the mismatch.

The image builder has the image defined in the config file in the root.
The current master version has 2018-10-09 as the image and the SHA for the kernel headers is 4f30a5365296658d66ef8a9f878a25d229e2d5fa which should correspond with the headers used in this image. (they do for me)
What you are doing is pulling the latest kernel headers on an image with a different kernel and headers installed. The right course of we want the new RTL88xx on the image is to build it DURING the creation of the image, that's how the system is designed to work. Not to modify the generated image itself. Then we are back to manually altering images and distributing different images.
I know you really want this to work and so do i, but as @rodizio1 confirmed, neither 5.2.2 or 5.3.4 works without issues. Once we settle on which version is the 'least bad' i will make sure the generated image compiles with that version. There really is no need to keep trying to post-integrate other drivers.
I originally used the 5.3.4 because it was the latest and was then urged to move back to 5.2.2 because this would be more stable. If something has changed in that situation i will move back to 5.3.4.

I know what you mean, and I agree with you.
The script is very well done, and I don't want to ask you to modify it only for my test.
I don't know if we should move from 5.2.20 to 5.3.4, but I want to test 5.3.4 with my AWUS1900. @rodizio1 did test only with AWUS036ACH ...
If I don't see any improvement with AWUS1900 and 5.3.4, I well tell you we have any interest to move to it ...
Many thanks for the great job you did, and will do.
Don't give up !
Yves

I finally succeed in compiling the 5.3.4 kernel module !
I did need to copy the /usr/src/linux-headers-4.14.71-v7+ from the  regular 2018-10-09-raspbian-stretch-lite to my built image. Then I had to create the good symlink in /lib/modules/...
I know that's not a clean way, but that's the only one I did find ...
Nevertheless I think that it's not normal that with the built image a wrong version of kernel headers are installed by sudo apt-get install raspberrypi-kernel-headers. This not occurs with a regular raspbian image ...
So something must be wrong somewhere !
But I know that's not so important, and not a priority to fix it.

I've understood and could fix this issue :
Just commenting these 3 lines
# sudo rm -rf /var/lib/apt/lists/*
# sudo apt-get clean
# sudo apt-get update

It will be in my next PR.

I will reply to just this one issue, but thank you very much for your efforts, i have merged the PR!

Before removing sudo apt-get update not only kernel headers and sources were pointing to next raspbian version (4.14.79), but it was also true for all packages. And I could see many uninstalled packages in apt logs (/var/log/apt).
Now we have 0 uninstalled packages, and this could perhaps resolve others issues ??
We'll see ...


Unable to deploy nextjs app located in monorepo with yarn workspaces

Describe the bug
I have a monorepo setup with yarn workspaces, based on this monorepo starter with nextjs, tamagui and expo.
I want to deploy the nextjs app as a hybrid app using Azure Static Web App.
From Oryx I get the following error:

In the starter repo, they write this for Vercel deployment:

Deploying to Vercel

Root: ./apps/next
Install command to be yarn set version berry && yarn install
Build command: leave default setting
Output dir: leave default setting

I have tried similar setup in the GitHub workflow file
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_JOLLY_DUNE_0C5557303 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: 'upload'
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: 'apps/web' # App source code path
          api_location: '' # Api source code path - optional
          output_location: '' # Built app content directory - optional
          ###### End of Repository/Build Configurations ######
        env:
          TAMAGUI_TAGET: 'web'
          PRE_BUILD_COMMAND: 'yarn set version berry && yarn install'

Note: In my monorepo, the nextjs app is under apps/web and not apps/next as the monorepo starter.
To Reproduce
Steps to reproduce the behavior:

Create the starter
Setup Deploy to Azure Static Web App
Configure the workflow
See error

Expected behavior
From what I can see and understand, Oryx doesn't know about the .lock file from the root. I try to go to the root and run yarn build as the build command in the starter repo does.
I also tried to sneak in yarn install in the build script, which gave this:

I have seen some other issues regarding yarn workspaces, but that seems to be related to the api. Am I configuring the deployment correctly?

I found a discussion with similar setup, will continue the conversation there.


Support custom database label for sql.db tracing

Right now, when using xray.SQLContext(driver,DSN), in order to open a DB connection with tracing, the DSN is parsed and the dbname of the DSN is used to inject into the Capture function, used under the hood to trace the calls.
Exemple in the QueryContext method :
err = Capture(ctx, stmt.attr.dbname, func(ctx context.Context) error {
			stmt.populate(ctx)
			var err error
			result, err = stmt.Stmt.Query(dargs)
			return err
		})

However, in the case where two Databases hold the same dbname, but are different databases with different DSN (different host, different tables...) XRay will think it is the same database in the service map.
It would be really helpful to be able to set a custom label (that can default to attr.dbname).
I can contribute to make that feature happen, but I really dont know what is the best way to achieve this.

Hi @cgstag ,
Thanks for opening this issue. We are looking into this issue to see what could be the best way to address this issue. Meanwhile if you have any ideas please post here so that we can also discuss that. Thank you for the patience!

Hello @bhautikpip , has this topic been discussed internally ?
I think the quickest / easiest way would be instead of using the dbname to just use the entire dsn or a combination of host + dbname. Another way is to provide another constructor with Options, and providing the display label as one of the options.
I tried to play around DSN parameters but not only is it dependant on the drivers used, it also can mess up the parsing altogether, so I think its a no go.

Hi @cgstag ,
I agree with you. dbname@host looks simpler and makes sense to me. I looked at the implementation of X-Ray Java SDK  and
X-Ray .NET SDK. X-Ray Java SDK uses schema specific part as uri and .NET SDK uses dbname@datasourcename. I think we can go ahead with dbname@host  for golang SDK. In the providing another constructor with Options approach customer would have to set that right? I believe if we can resolve this without adding any kind of configuration overhead on customer side then it would be nice. Feel free to post any other thoughts and submit a PR. I would be happy to review!

Hi @cgstag ,
X-Ray Go SDK v1.3.0 is released and includes this enhancement (https://github.com/aws/aws-xray-sdk-go/pull/273) which probably solves naming issue when using 2 databases with same name but different hosts in the case of known DSL so closing this issue. Feel free to open new issue if you find any issues. :)


Make safeDockerTag in the jenkins build script actually safe

The docker tag documentation
says that a docker tag must be valid ascii, contain only lowercase, uppercase,
digits, underscore, dash and period characters.  It can't start with a dash or
a period, and it can only be 128 chars long.  Our previous version only replaced
slashes with underscores so didn't entirely guarantee the tag was safe.
Discovered when I used a + in the branch name for alphagov/whitehall#3471

I'm getting some failures on Jenkins related to this change:
https://ci.integration.publishing.service.gov.uk/job/publishing-e2e-tests/job/run-tests-continually/36/console

Oh! It worked in an online groovy console.  I'll revert and try again.


[UX] API Implementation - Both Production & Sandbox endpoints are marked as required but can proceed leaving one field empty

Description:
Not fulfilling checklist items:
Consistency and standards-Is flow maintain the same patterns and consistency
Related task:
Create API
Issue:
Both Production & Sandbox endpoints are marked as required but can proceed leaving one field empty
Proposed Solution:
Add validation by make both fields required
Suggested Labels:
UX, Improvement, 2.1.0

This is fixed in APIM 3.0.0


on Start and 'Forever' seem more natural at the top of the blocks list

Logically, 'on start' feels like it belongs at the top of the 'Basic' list (at least considering top-to-bottom left-to-right reading systems).
Instead it's near the bottom.

Could we sort the 'Basic' blocks differently please?
I think to me the most logical order is
On Start
Forever
Show LEDs
Show Number
Show String
Clear Screen
Pause

Given that the 'On Start' block is always present, I'm comfortable with the current order in beta. Happy for you to close @abchatra if you'd like to...

Thanks


Dynamically add tab_item after window creation

Hey there,
I'm trying to create an application that has a tab item for each opened file, for example. Currently, the only way I can see to declare tabs is during the initial declaration of the app, but I do not see any way to add new items or edit the tabs after the app is initialized.
Here's a skeleton of the code I'm working on:
require 'glimmer-dsl-libui'
include Glimmer

open_files = []

menu('File') {
  menu_item('Open work file...') {
    on_clicked do
      file = open_file
      unless file.nil?
        open_files.push file
        # somehow convince main to re-initialize the tabs?
      end
    end
  }
}

main = window('File Tabs') {
  tab {
    open_files.each do |filename|
      tab_item filename
    end
  }
}

main.show

Any help would be appreciated.

You must use the .content {} method to re-open the tab content and add new tab items in. The .content {} method works on all GUI controls.
Here is the code updated to add tab items properly and also open the file content inside the tab item:
require 'glimmer-dsl-libui'
include Glimmer

open_files = []

menu('File') {
  menu_item('Open work file...') {
    on_clicked do
      file = open_file
      puts file
      unless file.nil?
        open_files.push file
        @tab.content { # re-open tab content and add a new tab item
          filename = File.basename(file)
          tab_item(filename) {
            non_wrapping_multiline_entry {
              text File.read(file)
            }
          }
        }
      end
    end
  }
  quit_menu_item
}

main = window('File Tabs', 900, 600) {
  @tab = tab {
    open_files.each do |filename|
      tab_item(filename)
    end
  }
}

main.show

Tab 1
Tab 2
Tab 3

Cheers!


Add support for Disk Drive (like original file explorer)

Add support for formatting a disk drive. Plus, I want this panel.

We are exploring adding a disks widget to the homepage, merging with #366.


Q: ArchiveType vs CompressionType

Hi!
I can't understand how to choose a format. When I create a stream I use ArchiveFactory.Create(ArchiveType.Zip) but then I have to choose CompressionType :
_zipStream = ArchiveFactory.Create(ArchiveType.Zip);
_zipStream.SaveTo(PackageStream, new WriterOptions(CompressionType.GZip));

why? How do ArchiveType and CompressionType relate to each other?
Moreover this code throws SharpCompress.Common.InvalidFormatException: Invalid compression method: GZip.
Zip archive can't have GZip compression type?
I found out that ArchiveType.Zip is compatible with CompressionType.Deflate. But it's weird API.

You've got it it seems.  Yes, GZip is slightly weird and isn't supported on Zip as detailed here: https://github.com/adamhathcock/sharpcompress/wiki/Supported-Formats
Yes, it is slightly weird because it's trying to be powerful.  If you've got suggestions on how to fix the API, then please let me know.

Ok, got it.
ArchiveType determines a subset of compression types.
Well, I'd suggest some default SaveTo:
interface IWritableArchive {
  void SaveTo(Stream stream, WriterOptions options = null);
}

if no WriterOptions was specified then the lib will choose some default based on its ArchiveType.

You can also just put CompressionType in directly as it's implicitly converted.

Ok, that's nice.
But I meant to allow skipping CompressionType at all: zipArchive.SaveTo(stream)

Yeah that's fine too.

but it doesn't work ) there's no such method in IWritableArchive

Looks like this https://github.com/adamhathcock/sharpcompress/blob/master/tests/SharpCompress.Test/Zip/ZipArchiveTests.cs#L269


fix(GlobalHeader): Regression fixes

Overview

fixing visual regression bugs for the global header
portal app pr
monolith pr

PR Checklist

[ ] Related to designs:
[X] Related to JIRA ticket: WEB-1827
[X] I have run this code to verify it works
[ ] This PR includes unit tests for the code change

🚀 Styleguide deploy preview ready!https://61e07f02eeb0f32d0596da08--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.da878e.0@codecademy/gamut-illustrations@0.21.1-alpha.da878e.0@codecademy/gamut-kit@0.6.41-alpha.da878e.0@codecademy/gamut-labs@28.6.4-alpha.da878e.0@codecademy/gamut-patterns@0.7.4-alpha.da878e.0@codecademy/gamut-styles@12.1.2-alpha.da878e.0@codecademy/gamut-tests@3.0.3-alpha.da878e.0@codecademy/gamut@43.0.1-alpha.da878e.0@codecademy/markdown-overrides@0.7.3-alpha.da878e.0@codecademy/monaco@0.5.30-alpha.da878e.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e087e8cbbee60077c6dc1d--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.61daec.0@codecademy/gamut-illustrations@0.21.1-alpha.61daec.0@codecademy/gamut-kit@0.6.42-alpha.61daec.0@codecademy/gamut-labs@28.6.5-alpha.61daec.0@codecademy/gamut-patterns@0.7.4-alpha.61daec.0@codecademy/gamut-styles@12.1.2-alpha.61daec.0@codecademy/gamut-tests@3.0.3-alpha.61daec.0@codecademy/gamut@43.1.1-alpha.61daec.0@codecademy/markdown-overrides@0.7.3-alpha.61daec.0@codecademy/monaco@0.5.31-alpha.61daec.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e19bc480dabc2dbe2872f1--gamut-preview.netlify.appDeploy Logs

I'm not sure if some of these are due to storybook but seeing this in mobile ---

Every time I open the profile menu, the profile link is active -

looks like the notification popover is slightly cut off and should be pushed down a little!

I think the log in button being purple (hyper) was a design choice; did we intentionally change that?

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.0bae7e.0@codecademy/gamut-illustrations@0.21.1-alpha.0bae7e.0@codecademy/gamut-kit@0.6.42-alpha.0bae7e.0@codecademy/gamut-labs@28.6.5-alpha.0bae7e.0@codecademy/gamut-patterns@0.7.4-alpha.0bae7e.0@codecademy/gamut-styles@12.1.2-alpha.0bae7e.0@codecademy/gamut-tests@3.0.3-alpha.0bae7e.0@codecademy/gamut@43.1.1-alpha.0bae7e.0@codecademy/markdown-overrides@0.7.3-alpha.0bae7e.0@codecademy/monaco@0.5.31-alpha.0bae7e.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e1bb3dc131a84aeb970a4a--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.e926a6.0@codecademy/gamut-illustrations@0.21.1-alpha.e926a6.0@codecademy/gamut-kit@0.6.42-alpha.e926a6.0@codecademy/gamut-labs@28.6.5-alpha.e926a6.0@codecademy/gamut-patterns@0.7.4-alpha.e926a6.0@codecademy/gamut-styles@12.1.2-alpha.e926a6.0@codecademy/gamut-tests@3.0.3-alpha.e926a6.0@codecademy/gamut@43.1.1-alpha.e926a6.0@codecademy/markdown-overrides@0.7.3-alpha.e926a6.0@codecademy/monaco@0.5.31-alpha.e926a6.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e1c3432224af0093fda864--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.e028a4.0@codecademy/gamut-illustrations@0.21.1-alpha.e028a4.0@codecademy/gamut-kit@0.6.42-alpha.e028a4.0@codecademy/gamut-labs@28.6.5-alpha.e028a4.0@codecademy/gamut-patterns@0.7.4-alpha.e028a4.0@codecademy/gamut-styles@12.1.2-alpha.e028a4.0@codecademy/gamut-tests@3.0.3-alpha.e028a4.0@codecademy/gamut@43.1.1-alpha.e028a4.0@codecademy/markdown-overrides@0.7.3-alpha.e028a4.0@codecademy/monaco@0.5.31-alpha.e028a4.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e1e66daf98a21eb887e40b--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.3762e8.0@codecademy/gamut-illustrations@0.21.1-alpha.3762e8.0@codecademy/gamut-kit@0.6.42-alpha.3762e8.0@codecademy/gamut-labs@28.6.5-alpha.3762e8.0@codecademy/gamut-patterns@0.7.4-alpha.3762e8.0@codecademy/gamut-styles@12.1.2-alpha.3762e8.0@codecademy/gamut-tests@3.0.3-alpha.3762e8.0@codecademy/gamut@43.1.1-alpha.3762e8.0@codecademy/markdown-overrides@0.7.3-alpha.3762e8.0@codecademy/monaco@0.5.31-alpha.3762e8.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e8454f56bc9f470753385c--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.ad4bfe.0@codecademy/gamut-illustrations@0.21.1-alpha.ad4bfe.0@codecademy/gamut-kit@0.6.42-alpha.ad4bfe.0@codecademy/gamut-labs@28.6.5-alpha.ad4bfe.0@codecademy/gamut-patterns@0.7.4-alpha.ad4bfe.0@codecademy/gamut-styles@12.1.2-alpha.ad4bfe.0@codecademy/gamut-tests@3.0.3-alpha.ad4bfe.0@codecademy/gamut@43.1.1-alpha.ad4bfe.0@codecademy/markdown-overrides@0.7.3-alpha.ad4bfe.0@codecademy/monaco@0.5.31-alpha.ad4bfe.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e84f632966d653873d8137--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.fa70ff.0@codecademy/gamut-illustrations@0.21.1-alpha.fa70ff.0@codecademy/gamut-kit@0.6.42-alpha.fa70ff.0@codecademy/gamut-labs@28.6.5-alpha.fa70ff.0@codecademy/gamut-patterns@0.7.4-alpha.fa70ff.0@codecademy/gamut-styles@12.1.2-alpha.fa70ff.0@codecademy/gamut-tests@3.0.3-alpha.fa70ff.0@codecademy/gamut@43.1.1-alpha.fa70ff.0@codecademy/markdown-overrides@0.7.3-alpha.fa70ff.0@codecademy/monaco@0.5.31-alpha.fa70ff.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e8582b37b184613dd352c9--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.6f8079.0@codecademy/gamut-illustrations@0.21.1-alpha.6f8079.0@codecademy/gamut-kit@0.6.42-alpha.6f8079.0@codecademy/gamut-labs@28.6.5-alpha.6f8079.0@codecademy/gamut-patterns@0.7.4-alpha.6f8079.0@codecademy/gamut-styles@12.1.2-alpha.6f8079.0@codecademy/gamut-tests@3.0.3-alpha.6f8079.0@codecademy/gamut@43.1.1-alpha.6f8079.0@codecademy/markdown-overrides@0.7.3-alpha.6f8079.0@codecademy/monaco@0.5.31-alpha.6f8079.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61e86586a29d0f0a24193f2f--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.ac420f.0@codecademy/gamut-illustrations@0.21.1-alpha.ac420f.0@codecademy/gamut-kit@0.6.42-alpha.ac420f.0@codecademy/gamut-labs@28.6.5-alpha.ac420f.0@codecademy/gamut-patterns@0.7.4-alpha.ac420f.0@codecademy/gamut-styles@12.1.2-alpha.ac420f.0@codecademy/gamut-tests@3.0.3-alpha.ac420f.0@codecademy/gamut@43.1.1-alpha.ac420f.0@codecademy/markdown-overrides@0.7.3-alpha.ac420f.0@codecademy/monaco@0.5.31-alpha.ac420f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61eed75b804f6a3d79163bcc--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.1.1-alpha.50b372.0@codecademy/gamut-illustrations@0.21.1-alpha.50b372.0@codecademy/gamut-kit@0.6.44-alpha.50b372.0@codecademy/gamut-labs@28.7.1-alpha.50b372.0@codecademy/gamut-patterns@0.7.4-alpha.50b372.0@codecademy/gamut-styles@12.1.2-alpha.50b372.0@codecademy/gamut-tests@3.0.3-alpha.50b372.0@codecademy/gamut@43.1.2-alpha.50b372.0@codecademy/markdown-overrides@0.7.3-alpha.50b372.0@codecademy/monaco@0.5.32-alpha.50b372.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61eedb9f4418303ebcb142a5--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.2.1-alpha.9e285a.0@codecademy/gamut-illustrations@0.21.1-alpha.9e285a.0@codecademy/gamut-kit@0.6.45-alpha.9e285a.0@codecademy/gamut-labs@28.7.2-alpha.9e285a.0@codecademy/gamut-patterns@0.7.4-alpha.9e285a.0@codecademy/gamut-styles@12.1.2-alpha.9e285a.0@codecademy/gamut-tests@3.0.3-alpha.9e285a.0@codecademy/gamut@43.1.3-alpha.9e285a.0@codecademy/markdown-overrides@0.7.3-alpha.9e285a.0@codecademy/monaco@0.5.33-alpha.9e285a.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f0230712e491531f29d033--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@6.2.1-alpha.c88c0b.0@codecademy/gamut-illustrations@0.21.1-alpha.c88c0b.0@codecademy/gamut-kit@0.6.45-alpha.c88c0b.0@codecademy/gamut-labs@28.7.2-alpha.c88c0b.0@codecademy/gamut-patterns@0.7.4-alpha.c88c0b.0@codecademy/gamut-styles@12.1.2-alpha.c88c0b.0@codecademy/gamut-tests@3.0.3-alpha.c88c0b.0@codecademy/gamut@43.1.3-alpha.c88c0b.0@codecademy/markdown-overrides@0.7.3-alpha.c88c0b.0@codecademy/monaco@0.5.33-alpha.c88c0b.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f03a74c7407f612e37e6de--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@7.0.1-alpha.d58f57.0@codecademy/gamut-illustrations@0.22.1-alpha.d58f57.0@codecademy/gamut-kit@0.6.46-alpha.d58f57.0@codecademy/gamut-labs@29.0.1-alpha.d58f57.0@codecademy/gamut-patterns@0.8.1-alpha.d58f57.0@codecademy/gamut-styles@13.0.1-alpha.d58f57.0@codecademy/gamut-tests@4.0.1-alpha.d58f57.0@codecademy/gamut@44.0.1-alpha.d58f57.0@codecademy/markdown-overrides@0.8.1-alpha.d58f57.0@codecademy/monaco@0.6.1-alpha.d58f57.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f03bbf4f9589756a20a688--gamut-preview.netlify.appDeploy Logs

so it's not missed -- let's make clicking the search icon close the search bar! (thats the behavior we have with other menu links int he global header, like notifications, the profile menu, + the dropdown categories like Community)
other than that, looks great in preview envs for portal + monolith
(we also need a PR for static sites!)
https://github.com/codecademy-engineering/static-sites/pulls

🚀 Styleguide deploy preview ready!https://61f16d7f5ed95bec3070894c--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://61f1df39603b5a64a834c8a7--gamut-preview.netlify.appDeploy Logs

🚀 Styleguide deploy preview ready!https://61f2cc0b8b380b10f8bc7b76--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@7.0.1-alpha.36cbca.0@codecademy/gamut-illustrations@0.22.1-alpha.36cbca.0@codecademy/gamut-kit@0.6.49-alpha.36cbca.0@codecademy/gamut-labs@29.1.2-alpha.36cbca.0@codecademy/gamut-patterns@0.8.1-alpha.36cbca.0@codecademy/gamut-styles@13.0.1-alpha.36cbca.0@codecademy/gamut-tests@4.0.1-alpha.36cbca.0@codecademy/gamut@44.1.1-alpha.36cbca.0@codecademy/markdown-overrides@0.8.1-alpha.36cbca.0@codecademy/monaco@0.6.3-alpha.36cbca.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f4186183578c0a81cd4f63--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@7.0.1-alpha.0f0d50.0@codecademy/gamut-illustrations@0.22.1-alpha.0f0d50.0@codecademy/gamut-kit@0.6.50-alpha.0f0d50.0@codecademy/gamut-labs@29.2.1-alpha.0f0d50.0@codecademy/gamut-patterns@0.8.1-alpha.0f0d50.0@codecademy/gamut-styles@13.0.1-alpha.0f0d50.0@codecademy/gamut-tests@4.0.1-alpha.0f0d50.0@codecademy/gamut@44.1.1-alpha.0f0d50.0@codecademy/markdown-overrides@0.8.1-alpha.0f0d50.0@codecademy/monaco@0.6.3-alpha.0f0d50.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f420953cab7ef97ff405b0--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-icons@7.0.1-alpha.766019.0@codecademy/gamut-illustrations@0.22.1-alpha.766019.0@codecademy/gamut-kit@0.6.51-alpha.766019.0@codecademy/gamut-labs@29.2.2-alpha.766019.0@codecademy/gamut-patterns@0.8.1-alpha.766019.0@codecademy/gamut-styles@13.0.1-alpha.766019.0@codecademy/gamut-tests@4.0.1-alpha.766019.0@codecademy/gamut@44.2.1-alpha.766019.0@codecademy/markdown-overrides@0.8.1-alpha.766019.0@codecademy/monaco@0.6.4-alpha.766019.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61f42d2e7147991b56ca3126--gamut-preview.netlify.appDeploy Logs


Llama3-70B with AWQ performance issue

System Info
I am currently testing TensorRT LLM  Version 0.11.0.dev2024052800 and nvidia-modelopt version 0.11.2 on 8 x H100 GPUS
Who can help?
I am trying to test the performance improvement of LLama3-70B-Instruct model with AWQ over baseline FP16 on 8 x H100 GPUs, but I observed till batch size 4 AWQ performed better than FP16 but after that performance degraded. Please find below sample result on generationTokensPerSec

I am using C++ benchmark script provided in repo.
Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[X] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
Below code used for building engine in FP16
python convert_checkpoint.py --model_dir /code/tensorrt_llm/Meta-Llama-3-70B-Instruct/
--output_dir ./tllm_checkpoint_8gpu_tp8
--dtype float16
--tp_size 8
trtllm-build --checkpoint_dir ./tllm_checkpoint_8gpu_tp8
--output_dir ./tmp/llama/70B/trt_engines/fp16/8-gpu/
--gemm_plugin float16
--paged_kv_cache disable
--context_fmha enable
--gpt_attention_plugin float16
--max_batch_size 64
--max_input_len 2048
--max_output_len 2048
--strongly_typed
Below code used for building engine in AWQ
python quantize.py --model_dir /code/tensorrt_llm/Meta-Llama-3-70B-Instruct/
--dtype float16
--qformat int4_awq
--awq_block_size 128
--output_dir ./quantized_int4-awq
--calib_size 32 --tp_size 8
trtllm-build --checkpoint_dir ./quantized_int4-awq --output_dir ./tmp/llama/70B/trt_engines/int4_AWQ/8-gpu/ --gemm_plugin float16
--paged_kv_cache disable
--remove_input_padding enable
--context_fmha enable
--max_batch_size 64
--max_input_len 2048
--max_output_len 2048
--strongly_typed
For Benchmarking I ran C++ benchmark with bash script shared in repo
Expected behavior
AWQ should performance than FP16 for all batch size (tested from 1-64). I have tested the same setup on A100 and observed AWQ perform better in all batchsize
actual behavior
Till batchzie 4 AWQ perform better than FP16 but after that performance degraded. I have shared the result on generationTokensPerSec
additional notes
N/A

This seems reasonable since it is mostly memory bound when bs is small and should be compute bound when the batch size is large.
AWQ does not save computational overhead but even increases it. It merely reduces memory transfer.
A more ideal method of acceleration would be FP8 or SmoothQuant?

@hijkzzz  - But TRT-model-optimizer benchmark.md shows AWQ INT4 doing better on larger batch size  on H100 ?

link from where I got the image - https://github.com/NVIDIA/TensorRT-Model-Optimizer/blob/main/benchmark.md

@Tracin  for viz.

@canamika27 Hi, can you share the full raw data please? batch size / input len / output len / tokens per sec etc.

@Tracin  -- Sure
For benchmarking I used same bash script given in repo https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/performance/perf-overview.md
in_out_sizes=("1:128,128" "4:128,128" "8:128,128" "16:128,128" "32:128,128" "64:128,128")
for in_out in ${in_out_sizes[@]}
do
batch_size=$(echo $in_out | awk -F':' '{ print $1 }')
in_out_dims=$(echo $in_out | awk -F':' '{ print $2 }')
echo "BS: $batch_size, ISL/OSL: $in_out_dims"
mpirun -n 4 --allow-run-as-root --oversubscribe ./cpp/build/benchmarks/gptSessionBenchmark --engine_dir /tmp/llama/70B/trt_engines/int4_AWQ/8-gpu/ --warm_up 1 --batch_size $batch_size --duration 0 --num_runs 5 --input_output_len $in_out_dims

done
Please find the result below

I am currently testing TensorRT LLM Version 0.11.0.dev2024052800 and nvidia-modelopt version 0.11.2 on 8 x H100 GPUS

@canamika27 Hi, after check with team, data in Modelopt doc is not compared under same tp_size. Specifically, for batch_size=2, AWQ and FP8 use tp_size=1 and compared with FP16 tp_size=2. For batch_size=32 and 64, AWQ and FP8 use tp_size=2 and FP16 uses tp_size=4.

@Tracin  -- Thanks for the information, so can the tp_size=8 causing performance degradation for AWQ model ? so for quantized or fp8 model we need to run on lower tp_size as compared to FP16

@Tracin -- Thanks for the information, so can the tp_size=8 causing performance degradation for AWQ model ? so for quantized or fp8 model we need to run on lower tp_size as compared to FP16

This is a trick.

@Tracin -- I tried AWQ with tp_size=1 and FP16 with tp_size=1 & tp_size=2 (for llama3-8B) still I am getting low throughput at batch size>=8. How to reproduce the results shared in TensorRT-Model-Optimizer benchmark.md (https://github.com/NVIDIA/TensorRT-Model-Optimizer/blob/main/benchmark.md)


[Feature request] Inspect noEmitOnError compiler option

Ref https://github.com/ds300/react-native-typescript-transformer/issues/13#issuecomment-310994943
Preferred behaviour would be that the transformer reports errors through packager as normally happens while developing with React Native.

Sorry for the delay on this. I hope to have time for it on Saturday.

It just occurred to me that there is a flaw in this plan: changes to a file might produce type errors in another, unchanged file, which won't be reported when transpiling on a module-by-module basis. There's no easy way to solve this that I can see. We'd have to use a more holistic incremental approach like tsc --watch does, but triggering recompiles on-demand from the transformer rather than through watching the file system. But there might be hard-to-resolve issues in doing that, for example: does TS still emit helper functions in every module when compiling incrementally? If not, perhaps a change in one file might result in more than one file being re-emitted, and then what? RN is not set up to handle that kind of situation.
Or maybe we could use the incremental system for error reporting and use standard module transpilation for emitting code like we do now. That would be less performant but it would probably have more straightforward semantics and implementation.
🤔

To simplify the feature request, what if it only reports these errors on the initial packager/transformer run?
If it means keeping the the transpilation more performant, which honestly is even more important, I could live with it only catching isolated errors on the initial run. And having to restart the packager in order to do a thorough check again.
Granted, that may be confusing behaviour to some people?

Yeah I'm not crazy about that idea. I think it would make for poor DX. I'll try to determine how easy it will be to piggy back on tsc's incremental compilation features first, and whether we can (or need to) do anything about the multiple-module-emit situation, and if it looks like it would be too much work maybe then we could consider something more straightforward but less good.

One thing which is quite straightforward indeed (since it involves me not doing any work :D) is to just run tsc --noEmit --watch yourself. Or is there some special benefit you get from having one/both of:

red screen errors in the app
error reports being emitted on the packager's stdout

Well, for my specific case, it is because I'm working a bit with devs who are used to statically typed languages like C#. They are used to the app breaking on compilation if something is wrong. And the same is true in cases where they have used TypeScript.
So it's more about keeping a familiar and non-confusing workflow.
The main goal I had in mind, when using TypeScript with RN, was easy onboarding with the app projects. So thats why I prefer making the transformer default via rn-cli.config.js. Less commands to learn, and we don't venture too far away from the usual workflow.
Was hoping the same could be applied to errors as well. Make the app break on errors like they are used to, and make it default behaviour so there's less to remember other than just running the app.
I see your point about just running tsc --noEmit --watch though (which is what I do myself).

Just checking back here. What we ended up doing was using husky for precommit and prepush hooks, and running tsc --noEmit in those cases.
Works fine for us, and should be a good workaround. You can close this issue if you want.

Cool, thanks for the update. Glad you found something that worked for you.

I was googling for hours as well. When using typescript I would have expected yellow and red screens in the app for warnings and errors as well. For example if you create-react-app and create typescript project, then your webpage is covered with error when there is something wrong in code. With this in react-native it swallows all up :(

I was googling for hours as well. When using typescript I would have expected yellow and red screens in the app for warnings and errors as well. For example if you create-react-app and create typescript project, then your webpage is covered with error when there is something wrong in code. With this in react-native it swallows all up :(

Have you found a solution?


Reveal value of secrets

Feature Description
It should be possible to see the value of secrets after creating them. This can help with debugging e.g. to see which API Key is used. This should of course only be possible after a the User clicks on e.g. "reveal value" button like in GitLab.
Screenshots
No response

I agree, I'm always annoyed by GitHub not allowing it, too.
However, we certainly need to be extra careful about whether the permissions for this are met because no one who isn't an owner may see the value of a secret:
Setting a secret is far less destructive than viewing a secret.

It could be theoretically shown to admin by requesting password or code from 2fa

From a strict security perspective, this is a no-go

that's security-by-obscurity...  You can always reveal the value of secrets by printing them in a workflow  (which is much more insecure than a "show secret" button because job logs might be public).


Refactor codify structs to use KubeObject and GoName

Add KubeObject and GoName to the rest of the structs in the codify package with appropriate changes the templates.

This depends on #50, will rebase after it's merged.
Will add additional patches to complete the refactor soon.

By 50, I mean #47. (oops)

Testing fails, currently get
Error during codify: unable to auto format code: <nil>"

Need to debug this more.


Dispatcher Errno Fix

This changes the dispatcher macros to:

Handle errnos correctly
Use different errno handlers for syscalls such as mmap which return addresses.

LGTM


Added missing event info to the trackEvent() function.

closing due to unresolvable merge conflicts and deleting the branch. will rerun docworks and try again.


Use max(eth_gasPrice, recommended) Gas when submitting transactions

[ ] should use max(eth_gasPrice, recommended) in UI as default vs solely one from provider otherwise will be too slow

Split this into two parts
#8841 - Upon first trade there should be a popup modal that says if you want to set your gas price to something different than the default, you should do so in account settings at the top right if you want to (with an image of it) and not to do so in your wallet otherwise it’ll cause your trade to fail.

@matt-bullock need modal

This is merged into 2.1.9


Added Update Custom checkbox

Update Custom enables newly created custom times to overwrite previously existing custom timers of the same name, rather than adding to the list.

needs a version bump to merge, on the off chance any issue arises


[Docs] change related fields to release v1.8.1

this commit requires an update with new recent PR merges, right?


Solving shape mismatch problems

Solve the shape mismatch problem mentioned in issue #12[https://github.com/ChristophReich1996/Involution/issues/12]

Hi @DeH40, thanks for your pull request :) This approach definitely solves the issue but is somewhat handcrafted and not stated in the original paper (or am I mistaking?). What do you think about adding a flag to the constructor for enabling the average pooling? Something like force_shape_match: float=False? So then one can either use the fixed version or the original "paper version".

You are right, it is true that the operation is not mentioned in the original paper, but there are some problems with the original method that make it unusable for some special use cases.I think it is necessary to add a switch that allows the user to decide whether to force reshape to use Involution.


Calling steal.config() with no arguments should work

Using v0.7.0, we can no longer use steal.config() with no arguments to get the whole config; it now throws an error instead. This feature is used internally by canJS to support the '//' prefix for URLs with can.view so that feature no longer works.

Thanks for the report. What previous version were you using where this worked?

It seems I was using the older version of StealJS at 3.3.0pre - 2013-02-06.

That makes sense, I was pretty sure the steal.config() form is not supported in current Steal. The reason is we no longer have an underlying config object, config is set directly on the System object.  I think there's an open bug in Can to make // work with new steal.

Ah, that must be https://github.com/bitovi/canjs/issues/1159.

Yep! I'm going to close this issue since that tracks the problem. Contribution very welcome.


Use -o wide when getting pods for the cluster-operator-status job

What type of PR is this?
cleanup
What this PR does / Why we need it?
Use -o wide when getting pods for the cluster-operator-status job.
This will help diagnose node specific problems quicker because we will know which node each pod is running on.
Which Jira/Github issue(s) does this PR fix?
Resolves #
Special notes for your reviewer
Pre-checks (if applicable)

[ ] Validated the changes in a cluster
[ ] Included documentation changes with PR

/lgtm


Size of Recommender Model

I am looking at ways that I can reduce the size of a recommender model I am working on. You can assume I want to train a model for recommending topics to readers. Using one dataset which has 6452 observations of (TopicID, UserID), there are 342 unique topics and 3281 unique users. The size of the model that was trained by using tc.recommender.create is 442 KB which is fine.
Now I have a larger dataset with 3,549,113 observations, 2174 unique topics and 251,514 unique users, the size of the model is 32.2 MB which is really large for my application. I was wondering if you have any recommendations on what the different things that I can try are to reduce the size of the model.
One thing I had in mind was to let say only try to make recommendations for the top topics (623 out of 2174), therefore removing all the observations for topics which are not among top 623. That resulted in 3,395,846 observations with 245,963 users and 623 topics and the size of the model becoming 28.8 MB, just a small decrease in size.
Next thing, I am going to try is to remove all the observations by users who have only read one topic. Meaning if a user has only one row in the observations I am going to remove the data (that one row) for that user. Does this make sense to you? Would this make the model less effective? Any thoughts on this approach that I yet have to try to see how much it will reduce the size of the model?

@dogahe - To make sure we provide you with useful information, please provide some additional details:
1 - Which recommender model type are you using? Is it ItemSimilarityRecommender?
2 - Are you concerned about the size of the output file when you call model.save(...) or model.export_coreml(...)?

Hi @TobyRoseman - Yes, I believe based on the fact that data has only the two mentioned columns it picks ItemSimilarityRecommender. I am concerned about the size of the .mlmodel which is the output of model.export_coreml

Even doing what I asked you if it makes sense to do only reduces the size of the model to 24.7 MB. I still would like to hear your thoughts on whether " remove all the observations by users who have only read one topic." affects the performance of recommendation? Even though for my case does not reduce the size of the model by too much. Also I would like to hear if there is anything you can suggest for me to do to reduce the size of the model?

HEy @dogahe, if you go create the item similarity recommender directly (using tc.recommender.item_similarity_recommender.create), it has one additional parameter, only_top_k, which controls the size of the item similarity graph stored.  Decreasing this decreases the amount of storage required for the model but it may also decrease the accuracy.  By default it's 64, but you can probably drop that to 20 or 30 and still get decent results (check it in detail), which would cut the model size in half.

@hoytak Thanks for the suggestion, however, the effect of changing only_top_k from default only_top_k = 64 to only_top_k = 4, is to reduce the size of the model from 32.3 MB to 30.2 MB. I am still waiting for other suggestions if somebody here has any? Thanks a lot.

This is weird.  I think I know what's going on, and it may be a bug.  Let me investigate.

Confirmed.  This is a bug.  The export routines are not dropping the user indexing tables from the archive.  Fix in the works.


[WIP] Lookout v2 API

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c54fc77). Click here to learn what that means.
 Consider uploading reports for the commit 28ed7db to get more accurate results

Additional details and impacted files
@@            Coverage Diff            @@
##             master    #1847   +/-   ##
=========================================
  Coverage          ?   16.69%
=========================================
  Files             ?      229
  Lines             ?    77261
  Branches          ?        0
=========================================
  Hits              ?    12900
  Misses            ?    63437
  Partials          ?      924

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


[HUDI-836] Implement datadog metrics reporter

Add a new metric reporter type for Datadog
Implement reporting support for Datadog http api

Committer checklist

[x] Has a corresponding JIRA in PR title & commit

[x] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #1572 into master will decrease coverage by 0.56%.
The diff coverage is 2.73%.

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

@yanghua This is ready for review. Also manually tested the implementation and was able to collect metrics in Datadog.

@vinothchandar I'm thinking of writing another short blog to introduce Datadog support with the new configs. Sounds good?

@vinothchandar I'm thinking of writing another short blog to introduce Datadog support with the new configs. Sounds good?

@xushiyan Absolutely good idea, IMO, not only blog but also documentation of config option.

@yanghua Right. I'll make another PR to update the configs docs, too.

Just observed weird CI failure...first time seeing OOM there. Trying with some settings in
https://github.com/apache/incubator-hudi/pull/1595

@xushiyan absolutely... please go ahead!

@yanghua @vinothchandar The travis tests is flaky; i can pass the tests locally. Please go ahead review the PR; I'll do some checkings on the CI failure later. Thank you.

@xushiyan I think the metrics tests are hard coding the ports and running into issues? I ran into one such issue locally.. PR brewing..

@vinothchandar @yanghua CI is passing now... I don't seem to have tests failing; it seemed just sometimes travis got freaked out...

@yanghua Once this is approved, I'll then update this docs update PR https://github.com/apache/incubator-hudi/pull/1603 with Chinese version. Thanks.

@yanghua Once this is approved, I'll then update this docs update PR #1603 with Chinese version. Thanks.

OK, will review soon.

@yanghua In the last commit, I added a new config class HoodieMetricsDatadogConfig just for datadog related configs and reverted previous change to HoodieMetricsConfig. I think it'd be better to refactor the configs of 2 other reporter types in a separate PR to minimize risks. If the new config class looks good, I'll do a separate PR for the other two, probably with some test cases, too.

@yanghua I kept getting OOM; have to set surefire with more heap.. do you prefer me do another MINOR PR to increase the heap?

@yanghua I kept getting OOM; have to set surefire with more heap.. do you prefer me do another MINOR PR to increase the heap?

Yes, It would be better to change it on a single PR.

@yanghua I kept getting OOM; have to set surefire with more heap.. do you prefer me do another MINOR PR to increase the heap?

Yes, It would be better to change it on a single PR.

OK created https://github.com/apache/incubator-hudi/pull/1623
Does the latest change look good? If yes, I can refactor the configs as it's done in this PR. Thanks.

@xushiyan I have no other concerns.

Note: blocked by #1623

@yanghua CI passed. Also updated #1603 for the newly added config. Thanks.

Will do a final check.

@vinothchandar If you are busy with other things. Can we merge it firstly? Then, iterate later.

Sorry folks.. Got delayed ..  This looks fine at a high level.. I was mulling if using http-client directly will cause any issues for us.. but seems ok..
If something comes up, we can fix forward..

@xushiyan may be we need to doc this or write a small post?

@xushiyan may be we need to doc this or write a small post?

Yes @vinothchandar will do the post soon. Config docs update is in #1603 . As for http-client, I have been using this implementation in production, looking good so far. Will definitely test it with more scenarios.


Sell / Sold per day

Hi,
I would like to ask you, how can I get "sell" or "sold" value for actual day? It is value in kWh what I sell to distribution network. SEMS portal has this value.
Value e_day_exp is not good for it.

There is no such "daily" register for grid boundary (meter) measurements.
There is only 'meter_e_total_exp' - you need to calculate daily difference manually.


Fix/rag ai openai

Hey, I just made a Pull Request!

This PR fixes the CI issues encountered with #68
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

@vmahe35 This PR complements #68 to enable the release of the new packages.
Thanks again for your contribution.


Better map marker distribution

Fixes #11 :)

Whoops! Would you please fix?

Hey guys, wouldn't it be better to keep a single pin on the map with a counter indicating how many users are there? Then when you click the pin you could see a list of users. It would definitely perform better once thousands of users are registered (which will happen very soon imo).

I agree with @zoltanpeto. That would be the best course of action both for usability's sake and performance. I can imagine performance would take a big hit once more than a few 100 users have added a location to their profile, especially on lower end PCs.

Yeah, that's definitely something we should do as well. I know that there is a plugin for gmaps which does exactly this. We need the randomization anyway because that doesn't help with that as soon as you zoom in.

@fwartner Ready to merge now :)

Seems your PR was not really clean.. ^^

Yeah, I already noticed it, didn't occur with my test data :/
I'm on it

May it depends on the amount of users.. (?!)

Please ASAP! :D

Yeah, just roll back please for the moment :)
Could you provide a dump of the user table? That way I can test with the data that's showing the problem.

Will give it to you on slack.