[Package Issue]: Microsoft.Teams detecting installer as the program itself

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Multiple installed packages found.
Brief description of your issue
Winget seems to view the Teams Machine-Wide Installer as an instance of Teams itself. Could possibly explain https://github.com/microsoft/winget-pkgs/issues/61420
Steps to reproduce
winget upgrade
Actual behavior
Name                            Id                            Version       Available     Source
------------------------------------------------------------------------------------------------
Microsoft Edge WebView2 Runtime Microsoft.EdgeWebView2Runtime 102.0.1245.30 102.0.1245.33 winget
Windows Terminal                Microsoft.WindowsTerminal     1.12.10982.0  1.13.11431.0  winget
Microsoft Teams                 Microsoft.Teams               <IP_ADDRESS>63  <IP_ADDRESS>69  winget
WinDirStat                      WinDirStat.WinDirStat         Unknown       1.1.2         winget
Microsoft Teams                 Microsoft.Teams               <IP_ADDRESS>74    <IP_ADDRESS>69  winget
5 upgrades available.

Expected behavior
just one instance of Teams in the list
Environment
Windows Package Manager v1.2.10941
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.1706
Package: Microsoft.DesktopAppInstaller v1.17.10941.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Screenshots and Logs

I get same error. Also, the upgrade is not able to be done.
C:\Users\alan>winget upgrade --all
Name                         Id                      Version    Available    Source
-----------------------------------------------------------------------------------
Teams Machine-Wide Installer Microsoft.Teams         <IP_ADDRESS>70 <IP_ADDRESS>68 winget
1 upgrade available.

(1/1) Found Microsoft Teams [Microsoft.Teams] Version <IP_ADDRESS>68
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
Installer failed with exit code: 1638
Installer log is available at: C:\Users\alan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-Microsoft.Teams.<IP_ADDRESS>68-2022-10-05-11-01-51.799.log
Another version of this application is already installed.

always update error.

on me, this happens when I use --scope=machine option.
For example: I use winget install -e -i --id=Microsoft.Teams --source=winget --scope=machine to install it. However, this installs installer to "C:\Program Files (x86)\Teams Installer" but not the app. This is the problem. The machine install manifest should be removed...

Is this really that hard to fix?

Even worse now, since there are Microsoft Teams classic, the new Teams (aka Teams 2.0) and "Teams Machine-Wide Installer." Lucky that the personal version of Teams does not join in such confusion.

I work for Microsoft as a Cloud Solution Architect:  my use case are some older Windows 10 personal home machines which both show this message.  I was noticing that the winget downloads code (presumably the update) but that the update does not install.  Hopefully there will be a resolution, perhaps to not signal that an update should be applied.


Created and updated docs for 1.21-19

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve

/lgtm


Consider snapshotResolver in Jest

Should likely be treated the same as testResultsProcessor and such. Docs.

:rocket: This issue has been resolved in v3.5.1. See Release 3.5.1 for release notes.


IsKeyPressed() incorrect after fullscreen status change

When changing the fullscreen status of the game, the list of keys reported by IsKeyPressed() (and related functions) does not "forget" the keys that were being pressed when the status change happened.
Meaning, if keys were depressed during the status change and then released after the status change, Ebiten will still report those keys as being pressed. (Pressing those keys again after releasing them will reset their reported state correctly.)
Using the minimum test case listed below, which can use the F key to toggle fullscreen, the following conditions result in incorrect values:

Press and hold F until the fullscreen status changes (very short presses will be fine)
Press and hold any keys while changing the fullscreen status with F
Press and hold any keys while changing the fullscreen status with the window's native fullscreen button (tested on MacOS)

Minimum test case:
package main

import (
	"fmt"

	"github.com/hajimehoshi/ebiten/v2"
	"github.com/hajimehoshi/ebiten/v2/ebitenutil"
	"github.com/hajimehoshi/ebiten/v2/inpututil"
)

type Game struct {
}

func (g *Game) Update() error {
	if inpututil.IsKeyJustPressed(ebiten.KeyF) {
		ebiten.SetFullscreen(!ebiten.IsFullscreen())
	}
	return nil
}

func (g *Game) Draw(screen *ebiten.Image) {
	ebitenutil.DebugPrint(screen, fmt.Sprintf("Pressed keys: %v", inpututil.PressedKeys()))
}

func (g *Game) Layout(outsideWidth, outsideHeight int) (int, int) {
	return 1280, 720
}

func main() {
	ebiten.SetWindowResizingMode(ebiten.WindowResizingModeOnlyFullscreenEnabled)
	ebiten.SetWindowSize(1280, 720)
	ebiten.SetWindowTitle("Key Test")
	ebiten.RunGame(&Game{})
}

(SetWindowResizingMode() is not required to reproduce the bug, it just permits testing the native button.)

Ebiten v2.3.5
MacBook Pro (Retina, 15-inch, Mid 2015); Intel Iris Pro 1536 MB
MacOS 12.4 (Monterey)

Confirmed. Thank you for reporting this!

So I think GLFW doesn't work well with macOS's fullscreening 🤔

(I'm trying my best to familiarize myself with Ebiten's codebase. It seemed like it was a GLFW function not returning correctly. Glad to see that might be correct.)
I don't really see this being a big deal, except when you use a key to activate fullscreen. That seems like it would be more of an issue in situations where Ebiten gets used to make a non-game utility.
I use F as a shortcut for fullscreening in testing and it took me by surprise when it wouldn't exit fullscreen sometimes, that's all. I don't think I would run into this in production.

It seemed like it was a GLFW function not returning correctly. Glad to see that might be correct.

Yes. Ebitengines adds some hack to GLFW for the native fullscreen, and there should be some inconsistency there. I'll try to fix this.

https://github.com/hajimehoshi/ebiten/issues/2053 also hinted at this being an issue.

Confirmed that keyUp event is not fired when the key is released during the window transition to fullscreen. Hmm, I think this is an issue in GLFW.

Can we use https://developer.apple.com/documentation/coregraphics/1408768-cgeventsourcekeystate?language=objc ?

Note the result of glfwGetKey and CGEventSourceKeyState are slightly different for some mapped keys. For example, CapsLock can be a control key, but this might be a left control key and a right control key. This depends on APIs.

Perhaps, CGEventSourceKeyState doesn't digtinugish left and right control keys...

I think I'll revert the change as

The current method cannot treat right modifier keys correctly
Unpaired keyup and keydown are very common (especially on browsers) and this is not a serious issue


Possibility to turn of quoting of cookies

I am currently using Guzzle for interfacing with a webservice, where i need a session cookie that contains a "=" sign.
Unfortunately this webservice does not support quoted cookie values, which is done in the CookieJar::getCookieValue() method.
Possible solutions:

Don't escape because of a = sign
Allow overwriting the getCookieValue() method, by modifying the call in CookieHeader::withCookieHeader() to utilize late static binding.

For now i had to completely re-implement the CookieJarInterface, for my use case to work.

Hm... I'm open to changing the behavior here.
I wonder if we should be quoting at all. What does the cookie spec say? I wonder what other HTTP implementations do... For example, Firefox, Chrome, other PHP packages, etc.

While using the webservice through either Firefox or Chrome, neither of them escapes the cookie data.
The RFC does allow escaping, but i think the correct way would be to only escape if the server also sends it escaped.

Thanks. I'm be open to changing it to match other prominent implementations.


Correct method documentations

I'm not sure how method documentations are written/generated, but the Swift parameters are camelCased while the documentation parameters are underline_separated, which makes the documentation not show up in xCode.
Here's an example:

Ok this is a bug in generator from last update where we changed parameters and method naming to camelCase as per Swift naming standard, we are in the process of rewriting the library completely so we can’t fix it right now, do you agree @zmeyc?
Sent with GitHawk

@cipi1965 We were generating docs from TG docs, but since we switched to schema it's impossible to sync docs now. So we can only document a few of our own methods... Best we can do is to link to original TG methods if they have anchors.

@zmeyc since documentation links are simply https://core.telegram.org/bots/api#type-or-method-name we could at least set in in our generation? And document our non-generated methods


Crash on exeption-free release build in luaD_throw (MSVC)

Hi,
Unfortunately - another problem with MSVC.
If I try to build example below with argument /Ob2 (Inline Function Expansion - Any Suitable) and any level of optimization, then programm will crash on calling longjmp in luaD_throw.
#define SOL_NO_EXCEPTIONS 1
#define SOL_SAFE_REFERENCES 1
#define SOL_SAFE_USERTYPE 1
#define SOL_SAFE_FUNCTION_CALLS 1
#define SOL_SAFE_FUNCTION 1
#define SOL_SAFE_NUMERICS 1
#define SOL_SAFE_GETTER 1

#include "sol.hpp"
#include <iostream>

std::string testFunc( std::string str )
{
	return std::string( "hello " ) + str;
}

int main()
{
	sol::state lua;
	lua.open_libraries( sol::lib::base );

	lua["testFunc"] = &testFunc;

	lua.script( R"(
			function f ()
                -- call a function with wrong arguments
                -- to trigger lua_error
                testFunc()
			end
		)" );

	sol::protected_function f( lua["f"] );

	sol::protected_function_result result = f();
	if ( result.valid() )
	{
		// Call succeeded
		std::cout << "call succeeded" << std::endl;
	}
	else
	{
		// Call failed
		sol::error err = result;
		std::string what = err.what();
		std::cout << "call failed, sol::error::what() is " << what << std::endl;
	}
}

Worth noting that /Ob2 and /O2 are typical flags for release build in Visual Studio.
As far as I tested - this is only reproducible with MSVC (tested on VS2019 and VS2015).
GCC/Clang is free from that "bug" (godbolt examples with high optimation inlining - https://godbolt.org/z/fGd4zf and https://godbolt.org/z/fs3GTs).
Environment:
Lua 5.3.5 (build as C-library)
Sol 3.2.1
MSVC compiller (tested with versions 19.00.24215.1 and 19.24.28316)
Workaround:
Decrease optimization level to /Ob1 (Inline Function Expansion - __inline only).
Thank you for this library and thanks in advance for any comments.

I cannot seem to reproduce this error while building on Visual Studio 2019, x64, in Release mode.
Do you have any other information for me?

Nevermind, that was debug mode. NOW I go into an unstoppable freeze!

Okay, I got it to work by doing the following:

Specifying the flags /EHc- and /EHs- explicitly.
Rebuilt everything under RelWithDebInfo and Release builds

That is, I turned off exception handling at the compiler level, since that seems to be what you want. If you were trying to build an exceptionless sol2 with exceptions Enabled in the compiler, uh... I'm not sure what I can do to support that configuration. Lua will always call longjmp, and its probable that it will smash your stack in the process of doing so (because longjmp does not respect local variables and friends).
Either way, I don't think there's anything I can do to help you here beyond telling you not to use the no-exceptions flag in sol2 unless you mean it.

Thanks a lot for this research - I was not aware that you can choose stack unwinding strategy in MSVC.


Switch window.location.origin for a calculated Script path

window.location.origin gets the website name, but not the path under which the document is placed, so it worked for https://infotexture.github.io, but not https://infotexture.github.io/dita-bootstrap/, this change finds the relative path from the script itself so the correct path is always used.
Should have done more testing.

Glad you caught this.
The changes here seem to prevent the search results overlay from appearing when viewing the output from a local folder.
The initial implementation worked locally when the local output folder was passed with
--lunr.search=/path/to/out/dita-bootstrap-lunr-test/
Do your changes here assume the URL will begin with http as opposed to a local file:/// URL like this: file:///path/to/out/dita-bootstrap-lunr-test/html/search-box.html ?

@infotexture - yes - fetch() will fail due to CORS policy
index.html:1 Access to fetch at 'file:///.../js/preview.json' from origin 'null' has been blocked
by CORS policy: Cross origin requests are only supported for protocol schemes: http, data,
isolated-app, chrome-extension,  chrome, https, chrome-untrusted.

Since file: isn't on that list it won't work.

For example, the Search Box page is served at search-box.html, but the search results overlay links to /js/search-box.html, which throws a 404 error.

- http://[::]:8000/js/search-box.html#search-box
+ http://[::]:8000/search-box.html

Fixed 8c7160a


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/708 is merged into live branch.
Auto archive content to https://github.com/VSC-Service-Account/docs-archive-test-target.git

Docs Build status updates of commit 307765a:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch Release_Archive_master_2021-01-25-07-43-24 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 307765a:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch Release_Archive_master_2021-01-25-07-43-24 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Add a Reset To Defaults function

Allow users to reset to factory defaults.
Deal with null patterns issue identified in #111

I just struggled with this. For quick future reference for others, delete this file and restart VS:
%AppData%/VSColorOutput/vscoloroutput.json


cannot access and cannot call method on mixed|null

Larastan Version: 0.7.6
--level used: 8
Pull request with failing test:

Description
Hello friends,
can someone help me with this
issue1 : Cannot access property $token on mixed.
issue2: Cannot call method extension() on array<int, Illuminate\Http\UploadedFile>|Illuminate\Http\UploadedFile|null.
Laravel code where the issue was found

code for issue 1: $token = DB::table('password_resets')->where('email', $request->email)->first()->token;
code for issue 2: $filename = time().'.'.$request->file('avatar')->extension();

issue 1: Larastan knows only Models, raw database queries are really mixed.

Ah, it should be stdClass

it's coming up with this when keep stdClass inplace of stdObject
PHPDoc tag @var for variable $result contains unknown class App\Http\Controllers\Admin\stdClass.

stdClass is in the global namespace so you should use it like /** @var \stdClass $result */

yes, it's working
thank you so much for the help and quick response
you guys are rock


TrialResult addition

Implemented the addition operation for TrialResults. Only valid when measurement keys and parameter settings are the same. This will make combining smaller jobs as a part of #2107 easier.

Note that we get 1 trial result per point in a sweep, that is, running a sweep returns a List[cirq.TrialResult]. We'd only need to split and then recombine individual trial results if you request so many reps that a single trial exceeds job limits, say you ask to run a single circuit many millions of times. In typical cases, the "recombining" step will just be concatenating lists of trials results, one list from each chunk.
That said, I guess it's fine to have a recombination operation for individual trial results to handle this case, but I'd suggest not using __add__ for this. TrialResult is a thin wrapper around a numpy array (or dataframe) of measurement results, and for numpy arrays addition is element-wise, rather than doing concatenation like here. If we extend TrialResult to capture data from a sweep (so we don't need to wrap it in a list as we do now), I think we should avoid calling this concatenation operation "addition". Numpy uses "vstack" for this; I think "concatenate" would also be reasonable.

@maffoo I think it's acceptable to define addition to mean concatenation here. I would personally never have expected adding trial results to do a pointwise addition instead of a concatenation.


Downloaded chapters not appearing as so

Steps to reproduce
I'm not sure how to reproduce it. My downloaded chapters are still downloaded, and ones that I download after the fact are shown with the white checkmark properly. Just the ones I downloaded before the update appear as not downloaded.

Expected behavior
I expect to hit the download button and for the chapter to download and show the loading animation in the circle to the right of the chapter title.
Actual behavior
Downloads post-update are perfectly fine. Downloads I've had since before the update yesterday have lost their white check mark and are not seen by the app as downloaded. When I try to hit the arrow in the circle, nothing happens. When I try to delete the chapter and redownload it, the app already sees it as not downloaded and I can't do anything.
Crash logs
No response
Mihon version
0.17.1
Android version
Android 14
Device
Sony Xperia 1 V
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have gone through the FAQ and troubleshooting guide.
[X] I have updated the app to version 0.17.1.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

That did it, thank you!


Swaylock does not behave properly when there are multiple displays

I have two monitors connected to my computer, and have noticed two issues with swaylock:

If I start swaylock while the first monitor is focused, swaylock displays only on that monitor and not on the second one.
If I start swaylock on the second monitor, it displays on both, but upon entering an incorrect password, "wrong" is displayed only on the first monitor.

I can reproduce the first issue, but not the second.
Den 26. apr. 2016 19.46 skrev "Ian D. Scott"<EMAIL_ADDRESS>
I have two monitors connected to my computer, and have noticed two issues
with swaylock:

If I start swaylock while the first monitor is focused, swaylock
displays only on that monitor and not on the second one.
If I start swaylock on the second monitor, it displays on both, but
upon entering an incorrect password, "wrong" is displayed only on the first
monitor.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/SirCmpwn/sway/issues/605

Similar issue for me. I have 3 monitors, if i lock when the first monitor is focused the third monitor is not "locked". If I change the focus to the second or third monitor them everything is locked.
I don't face the second problem with the incorrect password. If I can help in some way let me know.

More on this; I was checking what could create this behave; so far looks something mess with the window; if I put some prints here:
 void shell_surface_configure(void *data, struct wl_shell_surface *wl_shell_surface,
                          uint32_t edges, int32_t width, int32_t height) {
        printf("shell_surface_configure\n");
        struct window *window = data;
        window->width = width;
        window->height = height;
        printf("window wayland width:%d height:%d\n", window->width, window->height);
 }

When the lock fails (doesn't cover all screens) I have this:
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:960 height:1057
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:640 height:1057
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:480 height:1057
shell_surface_configure
window wayland width:1920 height:1080
shell_surface_configure
window wayland width:1440 height:900

When I do the lock from another monitor (not the primary) it works and I got this:
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:1440 height:859
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:1440 height:859
shell_surface_configure
window wayland width:0 height:0
shell_surface_configure
window wayland width:1440 height:859
shell_surface_configure
window wayland width:1440 height:900
shell_surface_configure
window wayland width:1920 height:1080
shell_surface_configure
window wayland width:1440 height:900

So far I cannot explain what's going on, @SirCmpwn any idea?

Not sure. TBH I suspect wlc issues. Summoning @Cloudef: maybe you could implement the swaylock protocol in orbment and see if it's reproducable?

@ids1024 still a problem?

With the latest git of wlc and sway, I seem to no longer have the first problem, but the second issue remains.

Thanks for the update.


Bug 2253429: exporter: Don't delete exporter service on daemon deletion

Description of your changes:
The exporter service and service monitor should not be deleted if an individual daemon is being removed from a node. As long as the exporter is enabled with v18 and newer, the exporter service and service monitor should exist. Clusters were seeing their metrics stop collection when the exporter service and service monitor would disappear, especially when multiple clusters are configured.
Which issue is resolved by this Pull Request:
Resolves #https://bugzilla.redhat.com/show_bug.cgi?id=2262307
Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide).
[ ] Skip Tests for Docs: If this is only a documentation change, add the label skip-ci on the PR.
[ ] Reviewed the developer guide on Submitting a Pull Request
[ ] Pending release notes updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

/bugzilla refresh

/lgtm


Conversion to dotnet core 3

Will there be any plans to convert this project to aspnet core 3? Specifically to useof endpoint routing (conflicts with MCV defaults from dotnet core 2.X ways)

Soon 😀

I already started the process on my side. Not yet fully happy (WIP) but I might also prepare a PR for this :-)

Hold fire for the minute. I am updating it now and going through some of the outstanding tickets.

Done! And now available on master. I'll release a new version this week.
I'd like to use the endpoint routing with something like MapIdentityManager, but for now, it's working. I'll open a separate ticket to track that.
If you get a chance to take a look at it, let me know if everything works as expected.


Request capabilities does not overwrite global browser capabilites

Describe the bug
You can define caps for your DesktopWebDriverRequest by setting
DesktopWebDriverRequest request = new DesktopWebDriverRequest();
request.getDesiredCapabilities().setCapability(CapabilityType.PROXY, proxy);

This does not overwrite existing caps if a proxy cap is set by
WEB_DRIVER_MANAGER.setUserAgentConfig(Browsers.chrome, new ChromeConfig() {
    @Override
    public void configure(ChromeOptions options) {
        options.setProxy(defaultProxy);
    }
});

Expected behavior
The proxy caps setting from the request should overwrite the global browser caps, but ...
Actual behavior
... it does not.

This is fixed with Selenium 4 branch. In Selenium 4 the destination capability container for creating a new session is browser option object.
All caps are merged into browser options (https://github.com/telekom/testerra/blob/fc8e57387a960b271d1318f97a5edaf6d0a05831/driver-ui-desktop/src/main/java/eu/tsystems/mms/tic/testframework/webdrivermanager/DesktopWebDriverFactory.java#L178)
The merge method was update in Selenium 4, so no browser specific caps are lost any more. --> Cannot fixed with Selenium 3.

This is original Testerra 1 behaviour, where global capabilities are built into the capabilities very last. I think the reason was the Selenoid grid plugin integration (video support).
Changing this may break backwards compatibility.

The global capabilities are deprecated. The plan is to remove that feature. We only should have for configuration that order

test.properties
WEB_DRIVER_MANAGER.setUserAgentConfig
DesktopWebDriverRequest

But removing the globals has no impact to Selenoid connector. I have to change the merging of Selenoid caps in https://github.com/telekom/testerra-selenoid-connector/blob/cfb79e8d9f872ddb9106cdf52d4e849aa5168a07/src/main/java/eu/tsystems/mms/tic/testerra/plugins/selenoid/webdriver/SelenoidCapabilityProvider.java#L58 like I have done for the old global caps: https://github.com/telekom/testerra/blob/01db43af1f61b171b1b93cee813484387378be6e/driver-ui/src/main/java/eu/tsystems/mms/tic/testframework/webdrivermanager/WebDriverCapabilities.java#L96.
BTW there is also a merge issue in Selenium 3 which cannot handle caps like ChromeOptions, but Selenium 4 can. So I want to change this behaviour with Selenium 4 (#292)


Disclaimer shows when not set on server

Disclaimer is showing when it should not.

Fixed as part of ngageoint/mage-ios-sdk@eadb88d49e6b82db2fbc2175869a341cf731c810


Simulation Mode

I am doing a presentation about SMS hijacking and want to do a demo. I found SigPloit and it caught my attention. I have set up a Kali VM with static IP <IP_ADDRESS> and I have SigPloit running on it. I'd like to understand how to run a simulation to get output similar to the eighth page of the document at http://cysecure.org/560/online/project/sigploit_brianSteiner_joyGeorge_louisEscoto_emmanuelSefa.pdf, i.e., I'd like to simulate the interception of an SMS message. I think something has changed since that PDF file was made though because there doesn't seem to be anything in Testing/Server/Attacks/Interception that creates the ***      Intercepting          *** banner.
I have a second Kali VM with static IP <IP_ADDRESS> and Sigploit set up and both VMs can ping each other, in case I need a second VM (I got the impression I do from reading https://github.com/SigPloiter/SigPloit/issues/113).
How do I perform a simple simulation of an SMS interception? Thanks for any help.

Hello @sb2483  have you use the hackrf hardware?

No I haven't but I know what you're talking about. I don't have $300 to
drop on it though. Is it needed to run simulation mode?
On Thu, Jul 1, 2021, 9:23 AM Tom @.***> wrote:

Hello @sb2483 https://github.com/sb2483 have you use the hackrf
hardware?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SigPloiter/SigPloit/issues/230#issuecomment-872291082,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEDMROJJCGC4KKQFCLUQV3TVR26RANCNFSM47OTWSGQ
.

I think is because of the absence of the hardware, what do you think?

I don't think so but it could be. I can't imagine why hardware would be
needed for a simulation, but there's no documentation for how to stimulate
a client so I truly have no idea. Some simple instructions for "how to be a
client" when a stimulated server is running would be ideal.
On Thu, Jul 1, 2021, 2:43 PM Tom @.***> wrote:

I think is because of the absence of the hardware, what do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SigPloiter/SigPloit/issues/230#issuecomment-872503887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEDMRKZX6REOQHHPGIPEQLTVTAPVANCNFSM47OTWSGQ
.

Okay, I have a project am working on also, will keep you posted then

@sb2483 Did the issue resolved..??

No, no progress has been made in this issue. To recap, I do have the
simulated server running through the UpdateLocation.jar. I see in the
parameters there is a "hello world" test message, but I don't know how to
"send" it so it shows up in the "intercepted" output on the server.
On Fri, Jul 2, 2021, 7:34 AM ShitalBorganve @.***>
wrote:

@sb2483 https://github.com/sb2483 Did the issue resolved..??
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SigPloiter/SigPloit/issues/230#issuecomment-872964065,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEDMRIKT4Y5ZQACYSQAXUDTVWW5FANCNFSM47OTWSGQ
.

Hackrfone not working properly, I suggest using live parameters for it
Sent from ProtonMail mobile
-------- Original Message --------
On Jul 1, 2021, 3:23 PM, Tom wrote:

Hello @.***(https://github.com/sb2483) have you use the hackrf hardware?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


CB: Verify default bucket exists upon mount

Currently the Couchbase connector relies on the default bucket existing with anonymous access. CB's Java SDK requires a bucket when issuing queries. We should verify that it exists upon mount to avoid later confusion.
In its absence the repl offers the mildly useful Quasar error: Passwords for bucket "default" do not match. while the REST api offers the less useful 500 { "error": { "status": "Physical filesystem error.", "detail": { "message": "java.util.concurrent.TimeoutException" } } }.
Alternately configuration could be offered for specifying a bucket name and credential for use with queries.

In light of recent events and recommendations we should offer configuration.


Redundant src directory

Remove an extra level of src

Can't move the src folder because it needs to be in the same folder as the other folders and files, like "run", "gradle", "bin", etc.


Load Balancer - Gzip compression

Our backend has gzip compression enabled. We use the Load balancer to have SSL termination. The load balancer servers the content as decompressed. It should server the content gzip compressed.
We are using Rancher v0.47.0. Same with v0.46.0. Tried with Load-balancer rancher/agent-instance:v0.5.0 and rancher/agent-instance:v0.6.0.

@jloisel It's not obvious to me why this wouldn't work.  Are you absolutely sure your client you are testing with is sending the Accept-Encoding: gzip, deflate header?

Hi Darren, yes the client is an AngularJS UI which sends Accept-Encoding: gzip, deflate in every request. We tested the same client in the following conditions:

configured to hit backend on plain HTTP: receives gzipped content,
configured to hit load-balancer with SSL certificate: receives decompressed content.

The load-balancer is configured to serve the content on port 443 with the configured SSL certificate (provided by a valid certification authority). Our backend is a Spring boot web application with embedded Tomcat 8.0.28, we enabled gzip compression with the server.compression.enabled=true property in application config.

Gzip compression works fine in haproxy when enabling it by manually editing the haproxy.cfg within the container. I added the following lines in the default section:
 compression algo gzip
 compression type application/json

These settings are lost when restarting the container, as expected.

@jloisel support for custom parameters in haproxy "defaults" section will get enabled in the next release; here is the PR:
https://github.com/rancher/cattle/pull/1081

Awesome! :+1:

This does not make any sense... The default behavior of haproxy is to pass on the Accept-Encoding header and if the backend server compresses it the compressed response is sent back to the client.  I just tested this with the current release and it works with both regular and SSL listeners.
By setting compression algo gzip you are forcing haproxy to compress and rewrite the response.  It is apparently not compressed coming out of your backend @jloisel, or it would be working already.  So there has to be something like Spring disables it based on one of the headers that vary when going through haproxy.
It is generally much more desirable to have your backend do the compression because it can be written out compressed in the first place instead of read and written again.  Also you can only have many backend containers but onlyone balancer per public host IP/port.

@vincent99 You are right. We were comparing the behavior between staging and production environment which had different compression settings. Compression wasn't enabled on application/json in production.
There is a reason why we want to enable Gzip within HAProxy: the response time is much higher (130ms average) when enabling gzip on our backend than with in HAProxy (65ms). Gzip compression is much more efficient on LoadBalancer level. It's simply because HAProxy is a compiled C program while our backend is Java.
Gzip disabled on both Tomcat and HAProxy:

Gzip enabled on Tomcat backend only:

Finally, Gzip enabled in HAProxy only:

Gzip compression with HAProxy is as fast as serving uncompressed content. On the other side, gzip compression with Tomcat is almost 25% slower (response time > 1sec vs 850ms). Of course, i've run each at least 10 times and took only the fastest one.

With rancher-server v0.50 you can now just add
compression algo gzip
compression type text/html "text/html; charset=utf-8" text/html;charset=utf-8 text/plain text/css text/javascript application/x-javascript application/javascript application/ecmascript application/rss+xml application/atomsvc+xml application/atom+xml application/atom+xml;type=entry application/atom+xml;type=feed application/cmisquery+xml application/cmisallowableactions+xml application/cmisatom+xml application/cmistree+xml application/cmisacl+xml application/msword application/vnd.ms-excel application/vnd.ms-powerpoint image/svg+xml

To global section in LoadBalancer. And then compression will be enabled on all hosts by default. Check the mime types, so everything that is worth compression is compressed.

Thanks, we'll do it when we upgrade to v0.50.0.

Going to close as this is now available as of v0.50.0. @jloisel I'd recommend using the latest (v0.51.0) whenever you decide to upgrade. Or if you want to only upgrade to the v0.50.x series, please use v0.50.2 as it has some hot fixes.


Added GOTO window!

https://github.com/wootguy/bspguy/issues/13

@wootguy this is correct or in bspguy coordinates are different from Valve Hammer Editor?

Now problems fixed?

Yes)) Now fixed ?

Now fixed!


When serverSide is true and using pagination, not able to override filterData values

Expected Behavior

When serverSide is true and using pagination, I should be able to override the filterData arrays so that I can filter the table with values that are not showing on the current page. I should be able to fill those values with a collection of distinct values that I retrieve from my datasource.
Current Behavior

The filterData values are being filled only with data displayed from the current data values. If using serverSide pagination, there are most likely values that should be included in the filter lists that are not showing on the current page.
Steps to Reproduce (for bugs)

Your Environment

Tech
Version

Material-UI

MUI-datatables

React

browser

etc

@hurt426
So basically what we need is, a way to supply our own filterData instead of auto-generated from mui-datatables, right?
Maybe I can try add this.

Maybe columns->options->filter instead of only true/false can accept array of strings and generate the filter menu from these strings. How does it sounds @gregnb ?

This is now available in the latest release. There are two column options filterList and filterOptions.  I have removed the filterList from the root level options and now they must be provided per column.
Look at the README for an example. Thanks for all your patience.

Hello friends how are you ? I am using mui-datatables, I am adapting it to the React Hooks, I already bring data from my server and I am testing the paging but the paging buttons do not enable them and I do not know why? If you recognize the number of pages that I bring from my API ... if you can help me, I appreciate it. I leave you my source code.

import React, { useState, useEffect } from "react";
import ReactDOM from "react-dom";
import reqwest from "reqwest";
import { CircularProgress, Typography } from "@material-ui/core";
import MUIDataTable from "mui-datatables";
export default function Example(props) {
const [page, setPage] = useState(1);
const [count, setCount] = useState(1);
const [data, setData] = useState([["Loading Data..."]]);
const [isLoading, setIsLoading] = useState(false);
useEffect(() => {
getData();
});
// get data
const getData = (page = 1) => {
setIsLoading(true);
reqwest({
  url: `http://localhost:3000/api/musers/${page}`,
  method: "get",
  type: "json",
}).then((data) => {
  setCount(data.total);
  setData(data.data);
  setIsLoading(false);
});

};
const changePage = (page) => {
setIsLoading(true);
getData(page);
setPage(page);
// this.xhrRequest(http://localhost:3000/api/musers/${page}).then((res) => {
//   this.setState({
//     isLoading: false,
//     page: page,
//     data: res.data,
//     count: res.total,
//   });
// });
};
/*********************** Cargar data ************************ */
/*********************************************************** */
const columns = ["ID_Users", "FirstName", "LastName", "Email"];
//   const { data, page, count, isLoading } = this.state;
const options = {
filter: true,
filterType: "dropdown",
responsive: "stacked",
serverSide: true,
count: count,
page: page,
searchBox: true,
pagination: {
next: "Next Page",
previous: "Previous Page",
rowsPerPage: "Rows per page:",
displayRows: "off",
},
onTableChange: (action, tableState) => {
console.log(action, tableState);
// a developer could react to change on an action basis or
// examine the state as a whole and do whatever they want
  switch (action) {
    case "changePage":
      changePage(tableState.page);
      alert(page);
      break;
  }
},

};
return (

<MUIDataTable
title={

ACME Employee list
{isLoading && (
<CircularProgress
size={24}
style={{ marginLeft: 15, position: "relative", top: 4 }}
/>
)}

}
data={data}
columns={columns}
options={options}
/>

);
}


⚠ Bofrost.fr has degraded performance

In 67001fb, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1442 ms

Resolved: Bofrost.fr performance has improved in 6def81f after 6 minutes.


[Umbrella] Meet the OpenSSF's best practices reqts for the "Passing" badge

Many OSS projects, including Flagger and Flux, apply the Open Source Security Foundation (OpenSSF)'s best practices to gain/retain user trust and as part of their project governance activities.
TODOs:

[x] Do spike to document which criteria TF Controller already fulfills
[x] Application filed using generic bot email for team
[x] Add badge to Readme: ; #892
[x] Create security.md for TF Controller with details for users to submit vulnerability info/reports. (See Flagger example)
[x] Test suite to cover most (or ideally all) the code branches, input fields, and functionality.
[x] Add linter ("The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language.")
[x] The project MUST address warnings (applying linter would take care of this)
[ ] use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. ("This criterion does not suggest enabling assertions during production; that is entirely up to the project and its users to decide. This criterion's focus is instead to improve fault detection during dynamic analysis before deployment.")

AC: Receive the Passing badge.
To discuss: whether we want to make fulfillment of these reqts a condition of the v0.16.0 release. Will need to assess required effort.

One story: Run the tool to find gaps and turn them into stories

We have now received the OpenSSF best practices Passing badge.


Remove SimpleTokenCredential from @azure/core-auth

The SimpleTokenCredential class is an anti-pattern which we don't want to encourage, and is contrary to the Azure SDK Guidelines as it does not allow for refreshing of the token.

DO NOT persist, cache, or reuse tokens returned from the token credential. This is CRITICAL as credentials generally have a short validity period and the token credential is responsible for refreshing these.

This class could be implemented by someone easily on top of TokenCredential, but it is not a type we should expose from our libraries.

fyi @daviwil

@schaabs - I notice we're using this in the tests. Is there another credential we should use for testing in its place?

@jonathandturner we can define this class in the tests themselves, it should not be in the public surface area of the library.

This is resolved by @willmtemple in #5608


Terminar Fila - "Are you sure you want to quit?" Screens not comply with design

When clicking on "Terminar Fila", the background of mobile is fuzzy and the desktop design does not comply with design.

@JNuno007 Ainda há um problema, pois está a exibir scroll horizontal.


[Question]: how to add a warning for "password"?

I want to add warning for every time a variable is being declared with the name "password", but I don't know how should I go about doing it. I looked at similar pull request (here) commits  to what I want to do. I kind of got the hang of how the project is structured but don't understand how it works, or basically how linters work.
I would appreciate if someone would explain how I can do it. The pull request is about 200 lines across 14 different files and I can barely wrap my head around lua.

The PR you linked is probably a bad reference since it was one of the most elaborate change set to land since it was about the syntax of the language itself. I suggest just looking at the code itself and picking one of the simpler lints, particularly about variable names.
What did you have it mind for how this would look? Obviously calling a variable password isn't going to be worthy of a warning for all code bases. Were you thinking about perhaps a new lint with a configurable blacklist of names to to allow in variables?

Yes, an option to be able to blacklist certain names for variables would be quite what I was thinking of.
Although at this point I have to tell you that I took a project from my professor for my bachelor's degree: adding a new feature to a linter.
My professor advised me to start by adding a warning for every time a variable is declared with the name "password".
So you can understand the whole reason why I'm doing this to learn about this linter.
Also, I chose this linter since I wanted to learn lua(the syntax is decipherable to me) and that the original project that this one was forked from seemed abandoned, but I don't understand why people are using that one like flycheck or zerobrane studio.

The original repository this was forked from is abandoned because the owner passed away a few years back. It was widely in use before that, so any projects still using it probably just haven't updated. You should poke them about that. This is the canonical version.
If you just want to finish your homework you can probably short circuit things and hack it in somewhere variable names are checked for something else. We'll be pretty un-interested in actually merging such a new feature though.
A blacklist on the other hand could serve many practical purposes. Such a configurable blacklist could be configured for your use case but also more widely adopted and we could actually get your new feature merged upstream.
I suggest you look into how the current allowed globals list works and add some sort of blacklist modeled after the inverse logic of the globals which is a whitelist. Then poke around and make sure it runs on all variables, not just ones identified as global.

sorry for keeping this issue and you hanging @alerque
I was waiting to hear my professor's feedback on our conversation before going any further.
His opinion is that first I should learn about the ast parser of this linter and second, how it is doing tree construction(node building). This way, I would have a proper understanding of this project, and I wouldn't have to cobble together a solution.
I have looked at src/luacheck/parser.lua, although I don't have enough understanding of what most of it is doing, so I have to work on that.
I'm gonna leave this issue open for any possible future PR.

so one question... how to traverse

So one question... how to traverse the AST tree in this linter?
I did some reading about abstract syntax trees and got to the conclusion that in most languages, parsers that give you the AST will also give you the methods to traverse the AST tree. Since linters have parser as a fundamental component for them to operate(and for this project my assumption is that the parser is in ./src/luacheck/parser.lua), I'm curious if there is a cli option to enable something that would print the syntax tree of the given lua code?
Should I just stick to reading parser.lua file to understand the way this linter parses code into a tree or there is a simpler way like astexplorer already available?

Luacheck works by running a series of stages, you can view them and the order in src/luacheck/stages/init.lua. After the parser is run, the bulk of the logic for processing the AST is contained in linearize.lua. So far as I can tell, luacheck doesn't have an option to export the AST, although it's fairly straightforward to pretty print the generated AST. The project can't directly use AST Explorer, since its current output doesn't use its format.
On the original request here:
The straightforward and correct (IMHO) way to handle this would be to set password as being a read-only global, which I would expect to disallow ever creating a variable with that name. HOWEVER, that is not what luacheck actually does. Luacheck doesn't appear to care if a local variable shadows the name of an existing read-only or read-write global. This is unlike local variables, where luacheck does alert that a variable is being shadowed:
local password = "password"
print(password)
local password = "password"
print(password)

test.lua:3:7: variable password was previously defined on line 1

@ParsaNobahari @alerque Do either of you object to this method of allowing a blacklist for local variables? If not, mind if I change this issue's title to describe what I'm talking about here?
@ParsaNobahari If you want to grab this issue, what I've described is actually considerably simpler, and possibly too simple for your purposes, depending on whether you're wanting a use case that will require you to write a new module that itself traverses the AST. (You can see an example of a new module that traverses the AST in #65 and #67; I think that in practice the conclusion there was that it was too complex, and in particular handling each type of AST node and including proper testcases wound up being several thousand lines of code; I would expect that level of additional complexity and size would be very concerning for a straightforward feature like this blacklist request.) Instead, this should be a new error type, possibly (?) emitted by linearize.lua's existing AST traversal for local variable declarations. One question here is how to handle the interaction with the config; currently luacheck caches all possible errors/warnings, and preserves the cache across config changes; configs are used at the end, in filter.lua, to remove some specific errors/warnings. This seems like it would be a really bad interaction, as we'd need to report every local as possibly shadowing a config global, before we can access the config. Unfortunately I don't see another way, without ripping out luacheck's current caching behavior, which maybe we ought to do.

first of all, I want to thank you for taking your time and looking into the matter @arichard4
second, I want to apologize for the late reply. I don't want to stall people and my time is not more valuable than others, but this is the last year of my higher education, and I haven't had it busy like this in any other semester.

Luacheck works by running a series of stages, you can view them and the order in src/luacheck/stages/init.lua.

I assume this is what you mean by that:
stages.names = {
"parse",
"unwrap_parens",
"linearize",
"parse_inline_options",
"name_functions",
"resolve_locals",
"detect_bad_whitespace",
"detect_compound_operators",
"detect_cyclomatic_complexity",
"detect_empty_blocks",
"detect_empty_statements",
"detect_globals",
"detect_reversed_fornum_loops",
"detect_unbalanced_assignments",
"detect_uninit_accesses",
"detect_unreachable_code",
"detect_unused_fields",
"detect_unused_locals"

}

So far as I can tell, luacheck doesn't have an option to export the AST, although it's fairly straightforward to pretty print the generated AST.

True. This is what I've done for just that(I wrote this in src/luacheck/stages/init.lua):
local function format_any_value(obj, buffer)
    local _type = type(obj)
    if _type == "table" then
        buffer[#buffer + 1] = '{"'
        for key, value in next, obj, nil do
            buffer[#buffer + 1] = tostring(key) .. '":'
            format_any_value(value, buffer)
            buffer[#buffer + 1] = ',"'
        end
        buffer[#buffer] = '}' -- note the overwrite
    elseif _type == "string" then
        buffer[#buffer + 1] = '"' .. obj .. '"'
    elseif _type == "boolean" or _type == "number" then
        buffer[#buffer + 1] = tostring(obj)
    else
        buffer[#buffer + 1] = '"???' .. _type .. '???"'
    end
end

local function format_as_json(obj)
    if obj == nil then return "null" else
        local buffer = {}
        format_any_value(obj, buffer)
        return table.concat(buffer)
    end
end

local function print_as_json(obj)
    print(format_as_json(obj))
end

print_as_json(ast)

The straightforward and correct (IMHO) way to handle this would be to set password as being a read-only global, which I would expect to disallow ever creating a variable with that name. HOWEVER, that is not what luacheck actually does. Luacheck doesn't appear to care if a local variable shadows the name of an existing read-only or read-write global. This is unlike local variables, where luacheck does alert that a variable is being shadowed:
Do either of you object to this method of allowing a blacklist for local variables?

No but I would like to  know that where would you be setting password as being a read-only global?

mind if I change this issue's title to describe what I'm talking about here?

Honestly, if it's going to fuel this feature merged into the linter and you're really stoked about it, you can... idk... give this comment a rocket emoji(why not). Just comment the name please. Thank you.
But your implementation though, I'm interested.

I think that in practice the conclusion there was that it was too complex, and in particular handling each type of AST node and including proper testcases wound up being several thousand lines of code; I would expect that level of additional complexity and size would be very concerning for a straightforward feature like this blacklist request.) Instead, this should be a new error type, possibly (?) emitted by linearize.lua's existing AST traversal for local variable declarations. One question here is how to handle the interaction with the config; currently luacheck caches all possible errors/warnings, and preserves the cache across config changes; configs are used at the end, in filter.lua, to remove some specific errors/warnings. This seems like it would be a really bad interaction, as we'd need to report every local as possibly shadowing a config global, before we can access the config. Unfortunately I don't see another way, without ripping out luacheck's current caching behavior, which maybe we ought to do.

Although I myself am in a rush for adding the feature, one way or another, maybe it shouldn't be as complex as thousands of lines. Is it possible to add this to filter.lua so that it would filter in the variable names given by the config? My understanding from your comment is that filter.lua ONLY filters out errors/warnings and does not filter in. Can you explain the issue that would occur? What do you mean by configs?

So I finished my project and I hacked something acceptable for my professor.
With that out of the way, I wanted to see if my implementation would be acceptable to merge into this project, and if so I would add a cli argument for file input for variable names. But since my code is not so good, I can only dream so.
tl;dr I made a new stage
local vars = {}
local stage = {}
local handle_node
local blacklist_vars = {"pass", "denied"}

local vars = {}
local stage = {}
local handle_node
local blacklist_vars = {"pass", "ass"}

stage.warnings = {
    ["33"] = {message_format = "blacklist detected {name}", fields = {"name"}},
}

local function detect_blacklist(chstate, nodes, word)
   local items = {}
   for i in ipairs(vars) do
      for j in ipairs(word) do
         if vars[i] == word[j] then
            table.insert(items, vars[i])
            print(vars[i])
            local num_nodes = #nodes

            for index = 1, num_nodes do
               local node = nodes[index]

               if type(node) == "table" then
                  chstate:warn_range("33", node, { name = word[j] })
                  break
               end
            end
         end
      end
   end
   return items
end

local function check_nodes(chstate, nodes)
   for _, node in ipairs(nodes) do
      if type(node) == "table" then
         handle_node(chstate, node)
      end
   end
end

function handle_node(chstate, node)
   if node.tag == "Id" then
      if #vars == 0 then
         table.insert(vars, node[1])
         print("new entity", node[1])
      else
         local bool = false
         for i in ipairs(vars) do
            if vars[i] == node[1] then
               bool = true
            end
         end
         if bool == false then
            table.insert(vars, node[1])
            print(node[1])
         end
      end
   else
      check_nodes(chstate, node)
   end
end

function stage.run(chstate)
   check_nodes(chstate, chstate.ast)
   detect_blacklist(chstate, chstate.ast, blacklist_vars)
end

return stage

stage.warnings = {
    ["33"] = {message_format = "blacklist detected {name}", fields = {"name"}},
}

local function detect_blacklist(chstate, nodes, word)
   local items = {}
   for i in ipairs(vars) do
      for j in ipairs(word) do
         if vars[i] == word[j] then
            table.insert(items, vars[i])
            print(vars[i])
            local num_nodes = #nodes

            for index = 1, num_nodes do
               local node = nodes[index]

               if type(node) == "table" then
                  chstate:warn_range("33", node, { name = word[j] })
                  break
               end
            end
         end
      end
   end
   return items
end

local function check_nodes(chstate, nodes)
   for _, node in ipairs(nodes) do
      if type(node) == "table" then
         handle_node(chstate, node)
      end
   end
end

function handle_node(chstate, node)
   if node.tag == "Id" then
      if #vars == 0 then
         table.insert(vars, node[1])
         print("new entity", node[1])
      else
         local bool = false
         for i in ipairs(vars) do
            if vars[i] == node[1] then
               bool = true
            end
         end
         if bool == false then
            table.insert(vars, node[1])
            print(node[1])
         end
      end
   else
      check_nodes(chstate, node)
   end
end

function stage.run(chstate)
   check_nodes(chstate, chstate.ast)
   detect_blacklist(chstate, chstate.ast, blacklist_vars)
end

return stage

note:

right now, it is reading the blacklisted node names from blacklist_vars and it can be replaced by a cli argument.
it also detects library keywords like string and io.
it's printing the nodes that it finds for now for debugging purpose.
other things that I found out that get detect are: pairs/ipairs, table, print
Although for most of these other false positives that would get detected, I'm assuming there can be whitelisted when the code is looking for the actual blacklisted words inside of the stage if the blacklist is only going to be for variable names.

If you guys think that this is something of worth, I would take the time for working further on it and maintaining after it has been added.


Add complex crowdsale example

Add an example contract that inherits from CappedCrowdsale, FinalizableCrowdsale, RefundableCrowdsale as documentation on how to do it.

See #295 as well.

Awesome @jakub-wojciechowski! I was going to add an example as part of #333 but I'll let you do it.

@jakub-wojciechowski Do you have an ETA? Let me know if I can help.

Sorry for the little delay @frangio. I'm just relocating to another country. Let me know if you have any comments.

Ohh I already have done that with my personal project, I will dig into it after defcon


fix: Final aggregation should not bind to the input of partial aggregation

Which issue does this PR close?

Closes #156.
Rationale for this change

We now bind aggregate expressions to the input of partial aggregate for HashAggregate no matter what the mode is.  However, the output of partial aggregate is not same as its input. This incorrect binding will cause unmatched column index. Currently it doesn't expose issues because we don't check the index of bound reference in native side, and the bound columns in aggregate expressions are not used.
However, this is a potential bug and causes some issues when starting to check the index of bound reference.
What changes are included in this PR?

This patch adds the check of the index of bound reference. The aggregate expressions of final aggregation are not bound to the input of partial aggregation anymore but sent to native side as unbound expressions.
How are these changes tested?

cc @huaxingao

cc @sunchao

Merged. Thanks.


Passing in Parameters

Sorry if this is a simple question, but how do I pass in parameters to the CQL engine (/cql/evaluate)?
eg, I have a parameter in my CQL like:
parameter "MyString" String
and I want to pass in this string when I execute the CQL.
Thanks!

Hi @jduke99 , there is a setParameter method on the context, so when you've established the context for the engine, you can set parameters prior to evaluating.

@brynrhodes I'm a co-worker of @jduke99, and primarily, this is actually an issue with cql_execution_service. The service doesn't allow for parameter passing. I have a pull request I need to push up to that repository that can handle this issue, and it would be great to have it accepted!

@MikeRileyGTRI , that would be fantastic, thank you!


GUI on Silicone Mac

Is it possible, to use the GUI somehow on Apple Silicon Mac (MBP 2023 M2 Pro).
When installing the depencies i am getting errors relating to PyQT5.
It seems like PyQT5 is not nativly supported on Silicon Mac's.
I am not into Python right now, but updating to PYQT6 should work on Silicon.
Does by any chance someone have a working/valid workaround?
Br

Personally I don't have experience with Macs, but you should look for answers on PyQt related forums. Or try it with PyQt6, maybe that works.

Thanks for the fast response. Usually im also not that much into Macs, but i recently got one for developing outside the house thats why i have to struggle with such things now. On my Windows Laptop/Desktop everything works fine.
I will try to get it to work somehow, and will post the solution here, if i am able to get it to work.


NoSuperfluousPhpdocTagsFixer now handles null in every position...

… instead of last only.
This fixes #3849

Note: my commit can be squashed when merging :)

thanks @dmvdbrugge and @julienfalque :+1:


[BugFix] Fix capitalization issue in struct field name

Fixes https://github.com/StarRocks/starrocks/issues/27171
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[x] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:disappointed: fail : 1 / 2 (50.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/catalog/StructType.java
1
2
50.00%
[210]

https://github.com/StarRocks/starrocks/pull/27313 this PR include this PR. So close this PR.

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0


Web UI login takes a lot of time and fails on heavy load

I noticed, web ui login takes a lot of time. On heavy load (long checking torrents queue) there fails something and no login is possible.
Secondly I noticed, that used memory of porla doubles on each login. I didn't take a deeper look, but it looks like, porla is forking the whole process for getting a new JWT. This would be a lot overhead and could lead to unsuspected behaviour on memory limited machines.

We should also be able to implement server relief

Well, might be all right. But doubling the memory (in my case from 700M to 1,5G) for just creating a simple JWT is insane.

I'm not familiar with libsodium, so I've no opinion about the memlimit. But in general creating a new JWT should be below 1 second and shouldn't take the same memory as the main process.

Otherwise it would be better to look for another solution and don't use libsodium if it's to complicated.

I agree - the default limit that libsodium uses (and we) for what they call sensitive is ~1gb. So the numbers you see makes sense. I wasn't aware of this and I haven't ran into any issues with it since I haven't really tested in a memory constrained environment, but I can see why it's an issue 😃
Changing to the minimum limit they have documented (~8kb) both reduces the memory usage by a factor of a lot, and also makes issuing a JWT much much faster. A win I would say.
I'll put up a pull request for this later tonight!

That sounds all fine. Thanks for checking and investigating.
I started to use Porla in my prod environment. It's by far the best client I've ever tested although it's still in beta. :)

Of course, and I'm happy to hear!

The memlimit is now configurable and also defaults to the minimum value. Since it is stored as a part of the password hash, you need to recreate your user account in Porla.
Just do sqlite3 /path/to/porla.sqlite "delete from users" then refresh the web UI and you will end up at the setup page again.

Just tested with your fix and it works like a charm.
No memory increasing anymore and web ui login is very fast now. :)
Good job and thanks as usual for fast fixing.


Move from manual javac to java_common.compile

Hi,
I'm trying to tackle moving from a manual javac to java_common.compile as discussed in https://github.com/bazelbuild/bazel/issues/970#issuecomment-284335067.
Should we just return two jars? If so any preference to the names? Do you think anyone counts on it being one jar? We can unzip and jar both of them back together but it's messy.
Other than that it looks pretty straightforward to me by just obliterating all javac references, calling java_common.compile at the end of _compile( and propagate the providers out

I think we will have re-architect the rules or have one output. We at least have to combine to make the _deploy.jar. But if we emit two jars then targets that consume this one will have to add both jars to their inputs (since the whole idea is to use this when there are circular dependencies).
We already have jar creation code, we can just make it work for jar concatenation without unjarring first. It's slightly more IO but I bet not st all the slow part compared to scalac.

the problem with joining the jars is that currently this happens in the worker and the java_common will happen at skylark level.
AFAIU we have two options:

Do the jar concatenation in bash on skylark
Change the worker to be able to get two types of requests and add a concat jars request type
Call JarCreator (or a variant) plainly without a worker after java_common and start a new jvm.

I think #1 sounds least expensive performance wise since IINM this problem isn't jvm related but just archive manipulation.
WDYT?

The problem with bash is that you have to jump through all kinds of hoops
to make it a reproducible jar (same order contents, no timestamps).
It would be nice to have a C++ implementation or jar in bazel that did the
right thing.
On Thu, Mar 9, 2017 at 06:25 Ittai Zeidman<EMAIL_ADDRESS>wrote:

the problem with joining the jars is that currently this happens in the
worker and the java_common will happen at skylark level.
AFAIU we have two options:

Do the jar concatenation in bash on skylark
Change the worker to be able to get two types of requests and add a
concat jars request type
Call JarCreator (or a variant) plainly without a worker after
java_common and start a new jvm.

I think #1 https://github.com/bazelbuild/rules_scala/pull/1 sounds
least expensive performance wise since IINM this problem isn't jvm related
but just archive manipulation.
WDYT?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285401597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdsZzBp9hG4I6so4Dto0lr8C9ZxRyks5rkCfygaJpZM4MYE9b
.

Right...
So wdyt about having the worker support two type of commands?
On Thu, 9 Mar 2017 at 18:38 P. Oscar Boykin<EMAIL_ADDRESS>wrote:

The problem with bash is that you have to jump through all kinds of hoops
to make it a reproducible jar (same order contents, no timestamps).
It would be nice to have a C++ implementation or jar in bazel that did the
right thing.
On Thu, Mar 9, 2017 at 06:25 Ittai Zeidman<EMAIL_ADDRESS>wrote:

the problem with joining the jars is that currently this happens in the
worker and the java_common will happen at skylark level.
AFAIU we have two options:

Do the jar concatenation in bash on skylark
Change the worker to be able to get two types of requests and add a
concat jars request type
Call JarCreator (or a variant) plainly without a worker after
java_common and start a new jvm.

I think #1 https://github.com/bazelbuild/rules_scala/pull/1 sounds
least expensive performance wise since IINM this problem isn't jvm
related
but just archive manipulation.
WDYT?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285401597
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAEJdsZzBp9hG4I6so4Dto0lr8C9ZxRyks5rkCfygaJpZM4MYE9b
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285405707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF_thWbYDqxvKD6L6Bf4LGmAADgL_ks5rkCsSgaJpZM4MYE9b
.

I think that could be fine. Since it is still related to compiling scala.
So, we could add some optional args to the scalac worker to just act as a jar concatenator.

Ok, any tips on how I should do that? Never worked with protobuf and the
current worker protocol feels a bit implicit to me.
On Thu, 9 Mar 2017 at 19:17 P. Oscar Boykin<EMAIL_ADDRESS>wrote:

I think that could be fine. Since it is still related to compiling scala.
So, we could add some optional args to the scalac worker to just act as a
jar concatenator.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285417447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF_TWYmWcvWyysTGBaYD1H2FXBYZNks5rkDQrgaJpZM4MYE9b
.

you can look at the current invocation code. We have abstracted all the
protobuf out. You get a list of arguments that we then decode to pass to
scalac.
You will just need to add a new argument to our key-value approach.
On Thu, Mar 9, 2017 at 8:14 AM Ittai Zeidman<EMAIL_ADDRESS>wrote:

Ok, any tips on how I should do that? Never worked with protobuf and the
current worker protocol feels a bit implicit to me.
On Thu, 9 Mar 2017 at 19:17 P. Oscar Boykin<EMAIL_ADDRESS>wrote:

I think that could be fine. Since it is still related to compiling scala.
So, we could add some optional args to the scalac worker to just act as a
jar concatenator.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285417447
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABUIF_TWYmWcvWyysTGBaYD1H2FXBYZNks5rkDQrgaJpZM4MYE9b
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-285433518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdh2fg5DZjugfC-XkBpcziokPtYPNks5rkEF4gaJpZM4MYE9b
.

How far along are you with this approach?
Basically, I really need the java-scala sandwich so I was contemplating splitting this work in half. One step just uses java_common.create_provider on the current scalac (invoking javac) output and emits a java provider as well as/instead the current scala provider. It is this step that I am tempted to work on (basically immediately unless you are well-progressed on this part).
The other step is moving the javac use inside scalac to be java_common.compile with the merge step proposed here.

I don't think anyone has started, but I think everything in bazel 0.4.5 is ready to do what we need. I don't think the calling javac is the main issue, if you ask me. The current situation is not bad there in my view. The bigger issue is making scala libraries that java libraries can depend on, which again, 0.4.5 should support.

I was going to start today but you can take it. No problem.
On Tue, 28 Mar 2017 at 2:40 Stephen Twigg<EMAIL_ADDRESS>wrote:

How far along are you with this approach?
Basically, I really need the java-scala sandwich so I was contemplating
splitting this work in half. One step just uses java_common.create_provider
on the current scalac (invoking javac) output and emits a java provider as
well as/instead the current scala provider. It is this step that I am
tempted to work on (basically immediately unless you are well-progressed on
this part).
The other step is moving the javac use inside scalac to be
java_common.compile with the merge step proposed here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-289618257,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF0_Q1EYO_HFc9qrum5_BaIpVKJ-Zks5rqEj2gaJpZM4MYE9b
.

What do you all think between scala_library emitting both a scala provider and java provider (and then preferring the scala_provider when available) versus just emitting a java provider.
Main thought is that the latter is simpler is simpler overall; however java_common.create_provider only has two inputs: compile and runtime jars. But, then the java provider can present transitive_deps, transitive_exports, transitive_runtime_deps, transitive_source_jars so need to trace how it builds all that information.
As a first pass, my plan was to do the compile based on the ijar from all dependencies. Then, the provider is created with compile jars = generated ijar (or real jar for macros) + transitive_exports only plus runtime jars = real jar + runtime jars of all deps.
PS: I may also dig through the Skylark/Bazel sources to get details on where it is actually storing this information from java_library. A cursory look indicates that some experimentation is likely needed. For example, transitive_exports looks like it is actually tracing up through rules that define "exports" as an attr. (See JavaExportsProvider.) Thus, it may be possible to skip adding transitive_exports to compile jars....

What do we need in a scala provider not in the java provider? It seems to me if we can just use the java provider we are dogfooding more, since all builds will exercise the same code path, not just java -> scala dependencies.
I assumed that the for the provider we pass only our direct compile and runtime jars and internally it builds up the transitive deps. The exports are an issue, though it sounds like. We really need to have exports support. source_jars don't make quite as much sense, since clearly we are not giving java sources, but we can create a scala source jar (though I don't know why one needs those).
Anyway, as a first pass, scala and java providers can be fine I think if we can't support exports. If we can't do what we want to do, we should probably file issues/send PRs to fix sooner than later.

Won't we lose extra_information if we only use the java provider?
On Wed, Mar 29, 2017 at 1:59 AM P. Oscar Boykin<EMAIL_ADDRESS>wrote:

What do we need in a scala provider not in the java provider? It seems to
me if we can just use the java provider we are dogfooding more, since all
builds will exercise the same code path, not just java -> scala
dependencies.
I assumed that the for the provider we pass only our direct compile and
runtime jars and internally it builds up the transitive deps. The exports
are an issue, though it sounds like. We really need to have exports
support. source_jars don't make quite as much sense, since clearly we are
not giving java sources, but we can create a scala source jar (though I
don't know why one needs those).
Anyway, as a first pass, scala and java providers can be fine I think if
we can't support exports. If we can't do what we want to do, we should
probably file issues/send PRs to fix sooner than later.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-289930806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF-ue0Y_HCUxyIaUq0wmAEVb7I5HEks5rqZC4gaJpZM4MYE9b
.

I don't think so. The provider is one item in the return struct. See here:
https://bazel.build/blog/2017/03/07/java-sandwich.html

We will need to retain the scala provider for now because java_common.create_provider (and accessing target[java_common.provider]) return a JavaProvider, which is essentially a blackbox that only internal rules and actions can make full use of. To custom Skylark rules, it only exposes some default fields and transitive_runtime_deps.
For reference, .java actually returns a JavaSkylarkApiProvider, which can only be constructed by native rules (and they usually do so in parallel with a JavaProvider).
I think JavaProvider is still under some churn since it contains a set of providers that are a subset of the providers in JavaSkylarkApiProvider. For example, exports are in JavaSkylarkApiProvider but not JavaProvider, so we will need to do the previously discussed faking of them. It would be nice if JavaProvider took a superset of the data JavaSkylarkApiProvider took and then any rule (built-in or Skylark) would automatically add a java=JavaSkylarkApiProvider to any other rule that has a JavaProvider declaredProvider.
PS: Amusingly, it looks like java.transitive_deps actually already includes java.transitive_exports even though java_library claims an export isn't necessarily included as a dep for that library's compilation.
PPS: Sorry this took longer than projected. Beyond standard work 'distractions', spent a bit of time on the jdk issue and doing a post-mortem. Also, wanted to spend some time sort-of-deeply looking into the bazel internals to see what certain fields were actually doing.

Upon deeper analysis of the java rules implementation in Bazel (as well as tests), we will be able to 'sandwich' for a deps|runtime_deps attribute in java_library, etc. but not for exports. This is because deps is configured to reject if both the dep rule type is not in a whitelist and the dep does not provide a JavaProvider. However, exports is configured to simply reject any dep not in the whitelist.
Also, the current use of transitive_deps for java in collect_jars is technically too permissive, since it is capturing that target (good), that target's transitive exports (good), and that target's transitive dependencies (bad). Unfortunately, transitive_exports just returns a set of labels (which are slightly fancy strings). It might be possible to get the transitive_exports as artifacts by taking transitive_deps and filtering out all artifacts whose owner (generating label) is not in transitive_exports. However, it is supposedly possible for owner to be 'blank' but maybe it is only blank for when it is just a file. Fortunately (as an amusing interaction of restrictions), exports is further restricted to ONLY be rule labels (whereas deps could be files like a deploy jar) so it is possible that one can assume anything in transitive_deps that is coming from an export must have been from a generating rule!
PS: Unsure where else to have this discussion but it is somewhat off topic. I am mostly trying to point out relevant issues for you all to consider/debate while I experiment with this.... Also, note that this is all subject to change as they refine the proposal in the sandwich blog. create_provider isn't documented yet so it is possible there will still be some iteration. (Just looking at the internals indicates there is a lot of potential for simplification/removal of redundancies....)

First of all I think this is a relevant place to have this discussion.
I think that maybe issue #970 in bazel itself will be an even more relevant
place since Iirina who is working on this issue is monitoring the issue and
needs feedback on what we are missing to continue forward.
I think we should retain the scala provider for now and see if we can get
the sandwich to work with the current API. Following that we should give
her the feedback of what we need and why.
On Thu, 30 Mar 2017 at 7:45 Stephen Twigg<EMAIL_ADDRESS>wrote:

Upon deeper analysis of the java rules implementation in Bazel (as well as
tests), we will be able to 'sandwich' for a deps|runtime_deps attribute in
java_library, etc. but not for exports. This is because deps is configured
to reject if both the dep rule type is not in a whitelist and the dep does
not provide a JavaProvider. However, exports is configured to simply reject
any dep not in the whitelist.
Also, the current use of transitive_deps for java in collect_jars is
technically too permissive, since it is capturing that target (good), that
target's transitive exports (good), and that target's transitive
dependencies (bad). Unfortunately, transitive_exports just returns a set of
labels (which are slightly fancy strings). It might be possible to get the
transitive_exports as artifacts by taking transitive_deps and filtering out
all artifacts whose owner (generating label) is not in transitive_exports.
However, it is supposedly possible for owner to be 'blank' but maybe it is
only blank for when it is just a file. Fortunately (as an amusing
interaction of restrictions), exports is further restricted to ONLY be rule
labels (whereas deps could be files like a deploy jar) so it is possible
that one can assume anything in transitive_deps that is coming from an
export must have been from a generating rule!
PS: Unsure where else to have this discussion but it is somewhat off
topic. I am mostly trying to point out relevant issues for you all to
consider/debate while I experiment with this.... Also, note that this is
all subject to change as they refine the proposal in the sandwich blog.
create_provider isn't documented yet so it is possible there will still be
some iteration. (Just looking at the internals indicates there is a lot of
potential for simplification/removal of redundancies....)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290301137,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF5sMlRjg9Hn8Zy2C5zeutJV9h3jOks5rqzNjgaJpZM4MYE9b
.

Thanks for he update. Indeed 970 and raising issues we find seems
important. Looks like we are not quite as close as I had hoped to a
solution here.
On Wed, Mar 29, 2017 at 18:55 Ittai Zeidman<EMAIL_ADDRESS>wrote:

First of all I think this is a relevant place to have this discussion.
I think that maybe issue #970 in bazel itself will be an even more relevant
place since Iirina who is working on this issue is monitoring the issue and
needs feedback on what we are missing to continue forward.
I think we should retain the scala provider for now and see if we can get
the sandwich to work with the current API. Following that we should give
her the feedback of what we need and why.
On Thu, 30 Mar 2017 at 7:45 Stephen Twigg<EMAIL_ADDRESS>wrote:

Upon deeper analysis of the java rules implementation in Bazel (as well
as
tests), we will be able to 'sandwich' for a deps|runtime_deps attribute
in
java_library, etc. but not for exports. This is because deps is
configured
to reject if both the dep rule type is not in a whitelist and the dep
does
not provide a JavaProvider. However, exports is configured to simply
reject
any dep not in the whitelist.
Also, the current use of transitive_deps for java in collect_jars is
technically too permissive, since it is capturing that target (good),
that
target's transitive exports (good), and that target's transitive
dependencies (bad). Unfortunately, transitive_exports just returns a set
of
labels (which are slightly fancy strings). It might be possible to get
the
transitive_exports as artifacts by taking transitive_deps and filtering
out
all artifacts whose owner (generating label) is not in
transitive_exports.
However, it is supposedly possible for owner to be 'blank' but maybe it
is
only blank for when it is just a file. Fortunately (as an amusing
interaction of restrictions), exports is further restricted to ONLY be
rule
labels (whereas deps could be files like a deploy jar) so it is possible
that one can assume anything in transitive_deps that is coming from an
export must have been from a generating rule!
PS: Unsure where else to have this discussion but it is somewhat off
topic. I am mostly trying to point out relevant issues for you all to
consider/debate while I experiment with this.... Also, note that this is
all subject to change as they refine the proposal in the sandwich blog.
create_provider isn't documented yet so it is possible there will still
be
some iteration. (Just looking at the internals indicates there is a lot
of
potential for simplification/removal of redundancies....)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290301137
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABUIF5sMlRjg9Hn8Zy2C5zeutJV9h3jOks5rqzNjgaJpZM4MYE9b
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290302351,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdvKzyl0zrZz-IcCaAsgHpUR_QjqTks5rqzXTgaJpZM4MYE9b
.

I think the Bazel People are strongly committed to closing it so once we
have concrete issues I'm sure they will be handled pretty fast.
On Thu, 30 Mar 2017 at 8:01 P. Oscar Boykin<EMAIL_ADDRESS>wrote:

Thanks for he update. Indeed 970 and raising issues we find seems
important. Looks like we are not quite as close as I had hoped to a
solution here.
On Wed, Mar 29, 2017 at 18:55 Ittai Zeidman<EMAIL_ADDRESS>wrote:

First of all I think this is a relevant place to have this discussion.
I think that maybe issue #970 in bazel itself will be an even more
relevant
place since Iirina who is working on this issue is monitoring the issue
and
needs feedback on what we are missing to continue forward.
I think we should retain the scala provider for now and see if we can get
the sandwich to work with the current API. Following that we should give
her the feedback of what we need and why.
On Thu, 30 Mar 2017 at 7:45 Stephen Twigg<EMAIL_ADDRESS>wrote:

Upon deeper analysis of the java rules implementation in Bazel (as well
as
tests), we will be able to 'sandwich' for a deps|runtime_deps attribute
in
java_library, etc. but not for exports. This is because deps is
configured
to reject if both the dep rule type is not in a whitelist and the dep
does
not provide a JavaProvider. However, exports is configured to simply
reject
any dep not in the whitelist.
Also, the current use of transitive_deps for java in collect_jars is
technically too permissive, since it is capturing that target (good),
that
target's transitive exports (good), and that target's transitive
dependencies (bad). Unfortunately, transitive_exports just returns a
set
of
labels (which are slightly fancy strings). It might be possible to get
the
transitive_exports as artifacts by taking transitive_deps and filtering
out
all artifacts whose owner (generating label) is not in
transitive_exports.
However, it is supposedly possible for owner to be 'blank' but maybe it
is
only blank for when it is just a file. Fortunately (as an amusing
interaction of restrictions), exports is further restricted to ONLY be
rule
labels (whereas deps could be files like a deploy jar) so it is
possible
that one can assume anything in transitive_deps that is coming from an
export must have been from a generating rule!
PS: Unsure where else to have this discussion but it is somewhat off
topic. I am mostly trying to point out relevant issues for you all to
consider/debate while I experiment with this.... Also, note that this
is
all subject to change as they refine the proposal in the sandwich blog.
create_provider isn't documented yet so it is possible there will still
be
some iteration. (Just looking at the internals indicates there is a lot
of
potential for simplification/removal of redundancies....)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<

https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290301137

,
or mute the thread
<

https://github.com/notifications/unsubscribe-auth/ABUIF5sMlRjg9Hn8Zy2C5zeutJV9h3jOks5rqzNjgaJpZM4MYE9b

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290302351
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAEJdvKzyl0zrZz-IcCaAsgHpUR_QjqTks5rqzXTgaJpZM4MYE9b
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290303005,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF27RZCjXGWTmURcvgcD9WxcN-as3ks5rqzc4gaJpZM4MYE9b
.

On the plus side, after typing that out and doing the analysis both here and there, I have a much stronger idea for how to execute the scala build rules using JavaProvider....

👍🏾
Correct me if I'm wrong but I think our game plan is:

Change the rules to return both java and scala providers.
Move from manual javac to java_common.compile and merge the previous
provider with the new one.
Try to see what is left to drop the scala provider in favor of only the
java provider.

Wdyt?
On Thu, 30 Mar 2017 at 11:29 Stephen Twigg<EMAIL_ADDRESS>wrote:

On the plus side, after typing that out and doing the analysis both here
and there, I have a much stronger idea for how to execute the scala build
rules using JavaProvider....
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290339859,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF9xIoKCFguOtrFai2sE_E8vpibZ5ks5rq2f5gaJpZM4MYE9b
.

That sounds about right. The listing of items was targeted mainly at 3, although you will not yet be able to say a scala_library is an exports of a java_library.

Sounds like a plan.
On Wed, Mar 29, 2017 at 23:28 Stephen Twigg<EMAIL_ADDRESS>wrote:

That sounds about right. The listing of items was targeted mainly at 3,
although you will not yet be able to say a scala_library is an exports of a
java_library.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-290354467,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEJdkPL5RIS7MZ8oCife8grcSke5fNfks5rq3WhgaJpZM4MYE9b
.

This is going well. As part of it, I have been trying to reforge the scala provider to look more like the java provider (partly as a projection towards the future and partly so I/you don't have to maintain a mental distinction). Basically, the attribute has 3 fields:

outputs = the struct of all the files the target output (actually not used anymore)
compile_jars = the set of all jars exported by the rule for use in dependent compiles (ijar + exports). This ends up being naturally recursive on exports, which is perfect.
transitive_runtime_jars = the set of all jars needed on the runtime classpath when running this jar (real jar + exports + runtime_deps + deps).

I am going to present (without proof but can be supplied if possible) that this structure very closely micmics how native.java_library uses its JavaProvider. (The fields in JavaSkylarkApiProvider are a red-herring and only made available to Skylark but not used by native rules.) A key takeaway is that java_library does not distinguish between jars from itself and jars from exports when sending stuff to the next rule.
The transition has been fine except in twitter_scrooge.bzl:
The gen_scrooge_srcjar rule would provide transitive_compile_exports as a union of transitive_compile_exports in its deps. However, those the deps (if coming from a scala_library) would only have a transitive_compile_exports from their own exports, not including its own ijar.
Since the new scala provider (and eventually JavaProvider) just has compile_jars, it doesn't differentiate between the ijar and jars added to compile from exports. Thus, the compile_jars from a gen_scrooge_srcjar now would include the ijars from its direct dependencies. Is this OK? (I am not totally familiar with what twitter_scrooge is doing and thus unclear with what makes sense to expose to its dependents). Note that runtime jar propagation will not change at all and still acts perfectly fine.
There are a couple of workarounds if old behavior is needed (up to including adding a separate field to the attr just for this case). Although, the old behavior did seem odd where it was both exporting its dependencies at all and then further only exporting parts (the dependencies exports).

As a quick amendment, I did some digging and found that scrooge_scala_srcjar is immediately used in the macro scrooge_scala_library. The scrooge_scala_library was then relying on the original deps and also the result of scrooge_scala_srcjar. In fact, the changes would allow us to drop the dependency on deps in the scala_library, since scrooge_scala_srcjar would already include them.
Regardless, after futher thinking (before the scrooge_scala_library discovery), there are many ways to restore the old behavior if desired. The fastest is to put exports into the scala provider: it would just be the union of all compile_jars from exports (and not be used by any other rules). A 'better' solution might be to exploit aspects to 'cheat' and allow scrooge_scala_srcjar to grab the exports from its direct dependencies. This would avoid needing a one-off field in the scala provider (and allow a java_library to work/provide exports when in deps as well).

Scrooge is really important (critical currently) for us at Stripe. That said, I am very happy to make is more idiomatic with java (and scala) rules in bazel if we can. There are many current things that are probably just implementation details.
As long as the tests pass, we are probably fine. Our use case is generally to make a thrift_library which is just a bundle of thrifts with some meta-data and then use the scrooge_scala_library to generate the compiled code.
In fact, srcjar support was added to the scala rules explicitly for scrooge.

@johnynek as long as you are using scrooge_scala_library and not relying on peculiar behaviors of specifically gen_scrooge_scala_srcjar, then you should see no difference as the scala_library of scrooge_scala_library was already masking all the weird things gen_scrooge_scala_srcjar was doing with the scala provider.

Please see https://github.com/sdtwigg/rules_scala/commit/9c8f7201c1539fda0bc432264f01cde1a2f40adc
as a WIP commit for the proposal. The major structure is done and mostly just needs minor polish here and there.
That commit works with bazel test -- ... -test_expect_failure/.., and bash test_run.sh
However, not quite sending out for PR because I want to ensure the current tests are actually covering all the cases.
That said, if any of you want to test drive that commit on any projects to see if it breaks anything, go right ahead (as that may help accelerate my debugging). Keep in mind that with that commit a scala_library can be a dependency for deps and runtime_deps of java_library but have https://bazel-review.googlesource.com/#/c/9671/ out to get it to work on everything else.

awesome!
is this gerrit change the last one pending? I saw you had several CLs active

No, there are so a couple cleaning up various odds and ends but that is one
of the two key ones.
On Apr 5, 2017 1:54 AM, "Ittai Zeidman"<EMAIL_ADDRESS>wrote:

awesome!
is this gerrit change the last one pending? I saw you had several CLs
active
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/164#issuecomment-291797255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA9_-PbqvWgfDlgAOOPRfPKeBkLn0Cceks5rs1bEgaJpZM4MYE9b
.

Thanks for the update @sdtwigg.

Just to add another motivation to this issue apart from rule hygiene- I just spent a long time trying to debug a "problem" with rules_scala only to find that my simple java code didn't compile (was missing an import). Since intellij doesn't support scala I use sublime for my rules_scala development and I can miss some trivial things like a missing import. The current error messages are really not helpful and just say an error occurred with javac.
I'm guessing java_common.compile will handle this much better so that's my added motivation.

ok just hit on an actual blocking motivation- strict_scala_deps is unusable for us since javac fails with the trimmed classpath.
java_common.compile supports strict java deps.
I've started work on it and it's unclear if I have access to the jar outputs (regular and ijar) so I'll merge them.
I've posted a question on bazel-discuss.

closed by #269 reopen if not. Nice work @ittaiz !