Remove SF integration tests.

If we want to take the time at some point to get them back in a useful state and run them then that would
be great, but right now they don't compile, don't have great coverage at runtime and also mess with your
local databases in sometimes surprising ways.

soda-fountain #341 SUCCESS
This pull request looks good


Add --fix option to git-lint to support both formatting and linting with a single command

Added an initial set of JS and PY formatters.

Looks good to me!


Strip all the tensorflow junk attributes from the IR prior to bringing into IREE

It's really hard to read IR that originates from tensorflow due to all the attributes that get carried along. We don't need any of them once the signatures have been generated (and may not even need them for that). We should have a pass on the tensorflow integrations side that strips them all prior to lowering into IREE's core input dialects like flow.

This whole directory is kind of a mess. Cleaning it up as part of this to bring it in-line with the rest of the IREE code.


[ISSUE-908] skip unpublish for not found volume (cherry-pick to release)

Purpose
Resolves #908
Return OK status on the call NodeUnstageVolume, if CSI not found volume for umpunt.
Added mock for CRHelper
PR checklist

[x] Add link to the issue
[ ] Choose Project
[x] Choose PR label
[ ] New unit tests added
[ ] Modified code has meaningful comments
[ ] All TODOs are linked with the issues
[ ] All comments are resolved

Testing
build, e2e, reproduce issue by hand

/ci


Expanding one_of validator

Fixed typo for validation function
Validating primitive types for one_of as can't use troposphere.AWSHelperFn due to cyclic include.

@markpeek To add for 4.0 ?
Would have preferred to test against troposphere.AWSHelperFn class but then gets cyclic import.

@JohnPreston the cyclic import can be worked around by importing AWSHelperFn within the function itself. There are examples in that same file.
def sample():
    from .. import AWSHelperFn
    pass

I think the change you might be wanting is something like below. Feel free to make the change in your code, test, and push an update.
def one_of(class_name, properties, property, conditionals):
    from .. import AWSHelperFn

    if isinstance(properties.get(property), AWSHelperFn):
        return

    if properties.get(property) not in conditionals:
...

done @markpeek

I pulled your changes, split the commits into two (ecs typo and validator fix), tweaked slightly, and pushed manually.
Thanks for the fixes @JohnPreston!

Oops, let's try the link to the changes this way<PHONE_NUMBER>e92de312d3e8586e0139ccb6f8beda and 75db1661e17e7d6c36c53d269d999774a0a30e45

Thanks @markpeek
I will split the commits next time :+1:


Pro Tree has performence issue

Tree pro components has worse performence, when  load more than 2000 records, cause chrome crash

Tree pro components has worse performence, when load more than 2000 records, cause chrome crash

We recommend that you use an asynchronous loading scheme to deal with lag problems.We will optimize its performance in the future.

Tree pro components has worse performence, when load more than 2000 records, cause chrome crash

We recommend that you use an asynchronous loading scheme to deal with lag problems.We will optimize its performance in the future.

i have changed to asynchronous load it`s better now , thanks

i have changed to asynchronous load it`s better now , thanks


Update contributing informations

Looks great to me, might read back through it one more time in a bit for spelling


fix magic bees/forestry link

Magic Bees link was broken, Forestry was just curse instead of curseforge.

Thanks!


ASPNETCORE_HTTP_PORTS/HTTPS_PORTS not respected

Description
The new (to ASP.NET 8) ASPNETCORE_HTTP_PORTS/ASPNETCORE_HTTPS_PORTS environment variables are not respected by .NET Monitor.
Example:
SET ASPNETCORE_HTTP_PORTS=52327
dotnet.exe dotnet-monitor.dll collect
16:24:46 info: Microsoft.Diagnostics.Tools.Monitor.Startup[60]
      Tell us about your experience with dotnet monitor: https://aka.ms/dotnet-monitor-survey
16:24:46 info: Microsoft.Diagnostics.Tools.Monitor.Startup[76]
      Connection mode: Connect
16:24:46 warn: Microsoft.Diagnostics.Tools.Monitor.MonitorApiKeyConfigurationObserver[56]
      API key authentication is not configured. See https://go.microsoft.com/fwlink/?linkid=2187444&clcid=0x409 for more details.
16:24:47 warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Overriding address(es) 'http://*:52327'. Binding to endpoints defined via IConfiguration and/or UseKestrel() instead.
16:24:47 info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:52323
16:24:47 info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:52325
16:24:47 info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
16:24:47 info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production

It is true that http://*:52327 was ignored according to the warning. However, it should not have been ignored since the ASPNETCORE_* environment variables should take higher precedence than the command line defaults.
Regression?
No

Could it be because it's really supposed to be ASPNETCORE_HTTPS_PORT (not plural)?
I know that that the plural version is mentioned on the learn.microsoft.com page. Everywhere else that I see, though, uses the non-plural version.

The pluralization is correct. See the ASP.NET Core source code for the configuration name: https://github.com/dotnet/aspnetcore/blob/main/src/Hosting/Abstractions/src/WebHostDefaults.cs#L59


ci: add codecov for code coverage stats

looks like github bot for codecov is not working yet but some data at  https://codecov.io/gh/GoogleContainerTools/krew/commits


fix(fonts.gradle): fix react native 0.73 build errors

Fix build errors on react native 0.73.x version.
This is similar to a previous fix done for 0.72
https://github.com/oblador/react-native-vector-icons/issues/1508#issuecomment-1606108215
Commit details: https://github.com/oblador/react-native-vector-icons/commit/e9cc5898a4331f5f9b9e03e3f5345c5cda3ebf61

Would be great to see this merged! Manually editing files in node_modules is not the way. :(

One more vote for merging!

One more vote for merging!

@sizuf I ended up using patch-package in the meantime. 😬

+1 to merge it 👀

@oblador I can't replicate this problem myself, but this seems to fix a problem for lots of folks, and I can't see it doing any harm. Can you merge?

This is also affecting me from releasing with the update to RN 0.74.  A merge would be really handy as I don't like using patches in production if I can avoid it.


我的starRocks使用不了help命令

General Question

Help has not been supported since 1.19

Try searching on the https://docs.starrocks.com/


add form support for multi execution service

Summary
Add form support for multi execution services.
Add the ability to change from single to multi and vice versa.
Fixes https://github.com/finos/legend-studio/issues/943
https://user-images.githubusercontent.com/29690824/178284085-f0798711-1f60-44a4-a142-cfff70365f4c.mp4

How did you test this change?

[ ] Test(s) added
[x] Manual testing (please provide screenshots/recordings)
[ ] No testing (please provide an explanation)

I'm doing the code review, but here's some comments just from watching the video:

Let's make the key icon smaller for the list item
Let's make the input for the execution key name span the whole width
Let's make the exchange icon smaller (the ratio should roughly similar to that of Execute button). Also, Change for the button label is a bit cryptic, though the color is noticeable enough, I think we should reword
In terms of flow, I think the only thing I would change is when we swap from single -> multi is not asking for the execution key value, let's default it to execContext_1, so as to simplify the flow a bit

for the Change word. I had thought of Switch
Or maybe show 'Multiwhen in single andSingle` when in a multi.

for the Change word. I had thought of Switch Or maybe show 'Multiwhen in single andSingle` when in a multi.

Is this action really that prominent? Like we would need to have a primary button like execute just to catch people's attention? Could we be more subtle and make this a normal toggle button (like the hackermode icon?). I think it's safer for now to do that, till we got more feedback that we need to make this more in-the-face, we could do that later. What do you think?

for the Change word. I had thought of Switch Or maybe show 'Multiwhen in single andSingle` when in a multi.

Is this action really that prominent? Like we would need to have a primary button with text like execute just to draw people's attention? Could we be more subtle and make this a normal toggle button (like the hackermode icon?). I think it's safer, for now, to do that, till we got more feedback that we need to make this more in-the-face, we could do that later. What do you think?

Trouble is finding the right icon. or maybe use the icon I have with it :)

yeah, looks good to me!

Um, actually no, the icon you use is for the action switch, this is a toggle, so maybe we need to change it to something indicating multiple, branching?
Just some ideas
multiple

branching

Source: https://react-icons.github.io/react-icons/search?q=split


Add option to recompute band stats in raster ETL

See thread under https://github.com/ResonantGeoData/ResonantGeoData/pull/56#discussion_r440955214
Right now, we grab the pre-stored stats in the raster. We should add a way to re-compute the stats and any subsequent info like bins during the ingestion phase of the ETL as well as when saving/updating a BandMetaEntry
In my opinion, this is low-priority for now since the pre-stored stats should be okay for us to use for a while

The following lines of code need to be pulled out into their own task and then we can add a new admin action to do this on-demand: populate_band_statistics
https://github.com/ResonantGeoData/ResonantGeoData/blob/998a6c3995b4421c3632979a249fb78d66e1108f/rgd/geodata/models/imagery/etl.py#L89-L94

This is mostly implemented by the "reprocess" admin action (calling save()) on Image records. If we need to forcibly recompute these, I'm pretty sure getBandInformation's statistics option would enable this -- this is the method we are already using in the ETL routine:
https://github.com/ResonantGeoData/ResonantGeoData/blob/37b61f73c87eea4dedb394e7be7cd0b9cd30b2e3/django-rgd-imagery/rgd_imagery/tasks/etl.py#L39


axc.content is undefined | Cannot read property 'frameURIs'/'removeFragment' of undefined

Sometimes I get a bunch (thousands) of the following errors:
"Cannot read property 'frameURIs' of undefined"
"Cannot read property 'removeFragment' of undefined"
It causes the page to freeze, not possible to scroll, click links etc. I'm quite sure it's related to some ads.

Noticed same thing today. I thought my js is breaking. I'll just disable the accessibility then.

Just got this as well. FWIW I was working in an email CRM app.

I am also getting this error whenever I try to inspect elements for my own chrome extension tool. I am unable to view my chrome local storage. It keeps on refreshing/loading.

Bump


Do not rely on OSAL SOFTWARE_(BIG|LITTLE)_BIT_ORDER

Is your feature request related to a problem? Please describe.
These endian-indicator macros are problematic for many reasons as documented in nasa/osal#843.  The continued presence of these macros in OSAL came up again in a recent code review.
OSAL will likely stop providing these macros in the next version, because nothing in OSAL is endian-dependent.
CFE only uses these to implement CFE_MAKE_BIG16 / CFE_MAKE_BIG32 macros.
Describe the solution you'd like
Move the nonstandard logic from OSAL into CFE, because nothing in OSAL depends on it.
For backward compatibility CFE will likely still have to provide this macro for historical reasons, in case some apps use it, and because TIME uses those CFE_MAKE_BIG* macros.
Additional context
See nasa/osal#843
In CFE the logic should be put in a separate header where it can be confined/limited to the scopes where this is actually used/needed, rather than a ubiquitous header like common_types.h.  This way an #error directive if the check was inconclusive will make more sense since it won't error out on cases where we don't care (i.e. most).
Requester Info
Joseph Hickey, Vantage Systems, Inc.

Could be part of #1209


[WIP] Fix apiElements declaration

It was extending the runtime configuration, but instead needs to extend
the compile one.
This was causing dependencies declared in the runtime configuration to
appear as compile in produced metadata.
This change is however a breaking one as it will impact projects that
relied on dependencies declared in the runtime configuration to be
available for compiling dependent projects.

I was expecting something like that, so closing.


added KILL event for removing container from registry;

see https://github.com/docker/docker/issues/15438 for details
kill event comes before die event, though during graceful shutdown, service is treated as alive, while during shutdown period service should be treated as gone to not accept any more connections

@vadzappa
It should be this?
                switch msg.Status {
                case "start":
                        go b.Add(msg.ID)
-               case "die":
+               case "kill", "die":
                        go b.RemoveOnExit(msg.ID)
                }
        }


connectex: A socket operation was attempted to an unreachable error AND HNS Unspecified error

Issue seems similar to https://github.com/Microsoft/hcsshim/issues/95
There are two test cases and two different errors, but I think the underlying root cause may be the same, that's why I report both errors in the same issue.
Here's the first test case:
for i := 0; i < numTries; i++ {
	subnets := []hcsshim.Subnet{
		{
			AddressPrefix:  "<IP_ADDRESS>/24",
			GatewayAddress: "<IP_ADDRESS>",
		},
	}
	configuration := &hcsshim.HNSNetwork{
		Type:               "transparent",
		NetworkAdapterName: "Ethernet0",
		Subnets:            subnets,
	}
	configBytes, _ := json.Marshal(configuration)
	resp, err := hcsshim.HNSNetworkRequest("POST", "", string(configBytes))
	Expect(err).ToNot(HaveOccurred())

	_, err = net.Dial("tcp", "<IP_ADDRESS>:8082")
	Expect(err).ToNot(HaveOccurred())
	// sometimes errors:
	// `dial tcp localhost:80: connectex: A socket operation was attempted to an
	// unreachable network.`

	hcsshim.HNSNetworkRequest("DELETE", resp.Id, "")
}

net.Dial sometimes fails with:
dial tcp <IP_ADDRESS>:8082: connectex: A socket operation was attempted to an unreachable network.

Powershell script that kinda replicates it (but prints a different error):
1..50 | % { New-ContainerNetwork -Mode transparent -Name net1 -SubnetPrefix <IP_ADDRESS>/24 -NetworkAdaptername Ethernet0; curl <IP_ADDRESS>:8082; Remove-ContainerNetwork -Name net1 -Force; }

I sometimes get error:
curl : Unable to connect to remote server

which I believe to be a coarse error message encompassing aforementioned connectex... error.
Here's the second test case, which is very similar to the first one but we don't specify a subnet when creating a HNS network:
for i := 0; i < numTries; i++ {
	configuration := &hcsshim.HNSNetwork{
		Type:               "transparent",
		NetworkAdapterName: "Ethernet0",
	}
	configBytes, _ := json.Marshal(configuration)
	resp, err := hcsshim.HNSNetworkRequest("POST", "", string(configBytes))
	Expect(err).ToNot(HaveOccurred())
	// sometimes errors:
	// `HNS failed with error : Unspecified error`

	hcsshim.HNSNetworkRequest("DELETE", resp.Id, "")
}

This time, we get a HNS error when invoking POST request on HNS:
HNS failed with error : Unspecified error

To replicate via powershell:
1..50 | % { New-ContainerNetwork -Mode transparent -Name net1 -NetworkAdaptername Ethernet0; Remove-ContainerNetwork -Name net1 -Force; }

Which sometimes returns:
New-ContainerNetwork : Unspecified Error

The workaround is to sleep for a second after POST request, but this is unacceptable.

When creating a new vswitch via hyper-v manager, it informs you that connectivity may break. I understand similar thing is happening here: when HNS switch is being created, HNS network creation returns success, even though the system is not done dealing with all the configuration changes of vswitch and net adapters.
But as a user of HNS, I care about when the network is ready, not when it is just created. I think HNS should block until everything is up and running. If that is not possible, then I would like to know some workaround, like polling network adapters or something, so that I don't have to use Sleeps in the code.

@m-kostrzewa In our test scripts we do a similar thing to wait of connectivity before invoking new-containernetwork. Example is

function GetConnectedHostIP()
{
$connectedNics=$x=Get-NetAdapter | ?{$.Status -eq "Up"} | % {$.Name}
Get-NetIPAddress  | ? {$connectedNics.Contains($.InterfaceAlias) -and $.AddressFamily -eq "IPv4" -and !$.InterfaceAlias.Contains("HNS Internal NIC") -and !$.IPAddress.StartsWith("169") -and !$_.IPAddress.StartsWith("127")}
}
function WaitForHostConnectivity
{
for ($i=0;$i -lt 20;$i++)
{
        $ip=GetConnectedHostIP
        if ($ip -ne $null)
        {
            return $true
        }
        sleep -Milliseconds 300
}

return $false

}
WaitForHostConnectivity


"Could not find requested crate" even for a direct dependency

$ cargo new reproducer
     Created binary (application) `reproducer` package
$ cd reproducer
$ cargo add<EMAIL_ADDRESS>    Updating crates.io index
      Adding fastrand v1.8.0 to dependencies.
$ cargo crev crate diff fastrand -- -ruN
    Updating crates.io index
Could not find requested crate. Try `-u` if the crate is not a dependency.

The expected output is a diff between fastrand 1.7.0 and 1.8.0 (because 1.7.0 is the latest reviewed version at the moment).
I bisected this to commit 68656a39938cc280e99580ff063b7af93d08c7cd which added -u.

Please let us know:

Which version are you using: cargo-crev 0.23.2
How did you install crev: via cargo install
What OS/platform are you running on: Debian 11.4

Hmm... it works here with 0.23.1 ...

Interesting. A workaround is to:
cargo crev crate diff -u fastrand -- -ruN

but I'll need to look into why non-unrelated codepaths can't look it up.

Yup, adding -u works.
I was hoping you'll spot the problem immediately, but since you can't even reproduce it, I'll find time this weekend to step through it with a debugger and see what's going on.

I think this should be already fixed.

Sorry, it's GitHub acting up. I commented via email on 26th of July, but it took GitHub 1.5 months to display the comment ._.


Enable SliderBar customization by derived classes

Why not interface it? Create interfaces or abstract classes for the slider bar parts and have the SliderBar contain overridable factory methods to construct derivations of those abstract classes.

That sounds overengineered to me.

You want customization? You're going to have to render yourself to a bit of overengineering.
See: Every forms designer ever. WinForms, Qt, WPF...

You can customize this component just fine. I mean check out the corresponding osu PR


fix: Warn and continue when Sigstore TUF repository is broken

Description
Allow Fulcio and Rekor data to be None. This means we will be missing
info from the transparency log, therefore not being able to validate
correct signatures, and giving false negatives.
Warn about it, and continue.
This protects us when upstream's Sigstore TUF repository has problems.
$ ./kwctl verify --verification-config-path=./../../e2e-tests/test-data/sigstore/verification-config-keyless.yml registry://ghcr.io/kubewarden/policies/capabilities-psp:v0.1.9

2022-07-19T09:57:04.387681Z  WARN kwctl: Cannot fetch TUF repository: TufError(ParseMetadata { role: Targets, source: Error("missing field `length`", line: 24, column: 4), backtrace: Backtrace(()) })
2022-07-19T09:57:04.387762Z  WARN policy_fetcher::verify: Sigstore Verifier created without Fulcio data: keyless signatures are going to be discarded because they cannot be verified
2022-07-19T09:57:04.387771Z  WARN policy_fetcher::verify: Sigstore Verifier created without Rekor data: transparency log data won't be used
2022-07-19T09:57:04.387781Z  WARN policy_fetcher::verify: Sigstore capabilities are going to be limited
Error: Policy registry://ghcr.io/kubewarden/policies/capabilities-psp:v0.1.9 cannot be validated
No Signature Layer passed verification

Test

Tested manually, the malformed metadata is still available.
Additional Information
Tradeoff

Potential improvement

the e2e tests fail with the expected false negative. It will get fixed once the upstream TUF metadata is updated. It may be a good idea to merge and cut the release nevertheless.


Unable to get refresh token - app is undefined

This relates to #242 as I was using the example from the documentation.
I was trying this other example as assumption is that I won't be getting refresh token with the implicit flow.
However, what is unclear from the second example is your app is callbacked from Salesforce with authorization code in URL parameter with following code app.get('/oauth2/callback', function(req, res) {
What should be app.get here? Currently it is undefined and throws JavaScript exception. Is this some bower/node specific thing (citing that whole documentation is based on node)? I am trying to run this in the browser.
Many thanks.

What should be app.get here? Currently it is undefined and throws JavaScript exception. Is this some bower/node specific thing (citing that whole documentation is based on node)? I am trying to run this in the browser.

It is the code from express.js framework, one of the most popular web application framework in Node.js world (like Rails or Sinatra in Ruby)


Where and how do i find 'the boilerplate project directory'?

hello, I'm new to all this. and am completely lost. the documentation doesn't get me up and running. any help?

You can download the GH repository source, and then launch the virtual dev environment with Vagrant up the project root is in the public/ folder.

closed because inactive


no texture export

I made a simple animated cube in blender, I exported it with texture, but there was no texture in the glTF file expect material.

Please share a blend file (zips can be dragged into comments) or details about your material settings.

Here ya
https://files.fm/u/q2kmh4k2

Thank you for the answer ! I tried exporting in the same way like you did but now the exporter gave me an error:

Hm that is a bug on our part, because you are saving the .gltf to the same folder as the source image. It will be fixed, but meanwhile you can work around it by saving to another folder.


Fix grammar errors in README.md

Description

Steps to Reproduce

Expected Behavior
Actual Behavior
Screenshots

Reproduction Link

This is an empty issue with zero details.


Make registering handlebars helper available.

Hello, I am using this project with spritesmith and it has been great so far. I have the following requirement and I hope we could incorporate this into your project. I need to be able to register handlebarHelper which I can use in my  mustache templates. I always have the issue that sprite generators require an even amount of images to great normal/ and retina spritesheets. I want to be able to create normal and retina sprite sheets independent  from each other to create %placeholder for each sprite.
%s-arrow-down {
	background-image: url(../../img/spritessmith/spritesheet1x.png);
	background-position: 0px 0px;
	width: 40px;
	height: 40px;
	background-size: 120px 80px;
}

and for retina i would like to do this
%r-arrow-down {
	background-image: url(../../img/spritessmith/spritesheet2x.png);
	background-position: 0px 0px;
	width: 40px; // half of the real retina resolution  {{half px.width}}
	height: 40px; // half of the real retina resolution
	background-size: 120px 80px; // half of the real retina resolution
}

updated. -> sorry my fault  that is correct now !
now you can create a mixin which does the following
@mixin sprite(name) {
     @extend %s-{#name};
     media bla bla {
           @extend %r-{#name} !optional;
     }
}

the benefit is that I don't need the same amount of images and we have a fallback to normal in any case. I hacked your project to register a "half" helper which can be used in the templates. I could think of all sorts of things where helper could be beneficial.  You could add this to the options like
options.handleBarHelpers  : [{name:'helpername1',func:function('value'){}}] and then iterate through the array and register the helper with handlebars.registerHelper(template.name,template.func).
Cheers Thomas

During the development of moving to handlebars, I thought we were exposing the ability to register new helpers via handlebars itself but I am realizing that handlebars is being buried away.
I would prefer users to somehow invoke handlebars.registerHelper since it will avoid confusion as the helpers always become global. However, your idea is definitely good one. I will revisit this by the end of next weekend.
In the interim, I don't fully grasp your example. With retina sprites, the background size/width/height should be the same as their normal sprite equivalents. But the dimensions you are providing are half of the normal ones and 1/4 of the typical retina dimensions. Can you explain why that is?

Ok here is how I understand retina. When I work on a project I look at it always from the 1x perspective. A layout can be 320px or let's say 1024 px wide. If I throw in a retina screen everything becomes tiny IF I don't change the zoom to bring us back to 1x levels. Thankfully we don't have to worry about it as our operating system usually takes care of this. Retina means that the density of pixel increases to a point where we can't see any px at 1x dimensions. In terms of our design or layout a pixel doesn't automatically translate into 2px when I use a retina screen, it stays the same. That has implications to sprite handling. Let's I have a div which should become an icon than we usually apply a background on it in 1x size, eg 32 px. Now our element needs to receive the dimensions of 32x32px as well otherwise the icon wouldn't show properly. On a retina screen the with and height stays the same but our image becomes blurry because it gets blown up due to density change. To counteract it we have to use a higher resolution image twice size of normal. By do that our image becomes suddenly cropped in our div container. Now we need to adjust the background-size to half its original retina resolution to match the dimensions of our 1x element and voila our icon appears nice and sharp on a retina screen.
This is how I understand the retina issue. My example above reflects that understanding. I hope that makes sense.

I just realized I did a little mistake with the widths there -> it has to match the 1x properties  but i still need to half them :)

let me share a little code with you. As is said before I am using gruntsmith which uses your project, so this example is starts from the gruntsmith config :) The code below is my take on the retina issue and by no means the best solution but a good one for me. I try to use placeholders rather than classes in my scss files. classes create output when imported into multiple public scss files get duplicated all over again. The answer to this problem are %placeholder. Creating a placeholder for each icon has an added benefit that we can now extend the placeholder in case we want to use the same icon in different places. I dont like to hack stuff which is why I did the following  to do what I wanted initially.
module.exports = function(grunt) {

	var handlebars = require('./bower_components/handlebars/handlebars');
	var fs = require('fs');

	// Project configuration.
	grunt.initConfig({
		sprite:{
			x1: {
				cssTemplate: function (data) {
					var fileData = fs.readFileSync('scss/spritesmith/spritesmith-retina-mixins.template.mustache','utf8');
					var handlebarstr = handlebars.compile(fileData);
					return handlebarstr(data);
				},
				src: 'img/spritessmith/1x/*.png',
				dest: 'img/spritessmith/spritesheet1x.png',
				destCss: 'scss/spritesmith/_sprites1x.scss',
				cssSpritesheetName:'sprites1x',
				imgPath: "/app/img/spritessmith/spritesheet1x.png"
			}
			,x2: {
				cssTemplate: function (data) {
					var fileData = fs.readFileSync('scss/spritesmith/spritesmith-retina-mixins.template2.mustache','utf8');
					handlebars.registerHelper('divide',function(value){
						return parseInt(value) / 2 + 'px';
					});
					var handlebarstr = handlebars.compile(fileData);
					return handlebarstr(data);
				},
				src: 'img/spritessmith/2x/*.png',
				dest: 'img/spritessmith/spritesheet2x.png',
				destCss: 'scss/spritesmith/_sprites2x.scss',
				cssSpritesheetName:'sprites2x',
				imgPath: "/app/img/spritessmith/spritesheet2x.png"
			}
		}

	});

	grunt.loadNpmTasks('grunt-spritesmith');
	grunt.registerTask('default', ['sprite']);
};

here is my 2x template ->
${{spritesheet_name}}: (
	{{#sprites}}
	{{name}}: (
		offset-x: {{divide px.offset_x}},offset-y: {{divide px.offset_y}},width: {{divide px.width}},height: {{divide px.height}},total-width: {{divide px.total_width}},total-height: {{divide px.total_height}},image: '{{{escaped_image}}}'
	),
	{{/sprites}}
);
{{#each sprites}}
%{{../spritesheet_name}}-{{name}} {
	@media only screen and (-webkit-min-device-pixel-ratio: 2),only screen and (min--moz-device-pixel-ratio: 2),only screen and (-o-min-device-pixel-ratio: 2/1),only screen and (min-device-pixel-ratio: 2),only screen and (min-resolution: 192dpi),only screen and (min-resolution: 2dppx) {
		background-image: url({{{escaped_image}}});
		background-position: {{divide px.offset_x}} {{divide px.offset_y}};
		background-size: {{divide px.total_width}} {{divide px.total_height}};
	}
}
{{/each}}

@mixin {{spritesheet_name}}-size($image) {
	background-size: map-get(map-get(${{spritesheet_name}}, $image), 'total-width') map-get(map-get(${{spritesheet_name}}, $image), 'total-height');
}
@mixin {{spritesheet_name}}-width($image) {
	width: map-get(map-get(${{spritesheet_name}}, $image), 'width');
}
@mixin {{spritesheet_name}}-height($image) {
	height: map-get(map-get(${{spritesheet_name}}, $image), 'height');
}
@mixin {{spritesheet_name}}-position($image) {
	background-position: map-get(map-get(${{spritesheet_name}}, $image), 'offset-x') map-get(map-get(${{spritesheet_name}}, $image), 'offset-y');
}
@mixin {{spritesheet_name}}-image($image) {
	background-image: url(map-get(map-get(${{spritesheet_name}}, $image), 'image'));
}
@mixin {{spritesheet_name}}($image, $size: true) {
	@include {{spritesheet_name}}-image($image);
	@include {{spritesheet_name}}-position($image);
	@include {{spritesheet_name}}-size($image);
	background-repeat: no-repeat;
}

I skip the 1x template as its the same without the media query and width and hight applied. To use this you need one mixin
@import "../spritesmith/sprites1x";
@import "../spritesmith/sprites2x";

@mixin retina-sprite($name,$suffix:"sprites"){
	@extend %#{$suffix}1x-#{$name};
	@extend %#{$suffix}2x-#{$name} !optional;
}

If you now need to support 3x retina images like on the new Imap you can create a new grunt task which deals with the 3x images and the handlebar helper deals with the 3x conversions. We used compass for sprite generation in pretty much all our projects and it was chore, its just not fast enough and I believe spriting doesnt belong in the same package of the sass compiler. its suppose to compile sass and thats it.Thats why I love this external grunt solution.

Your updated original example, now has the same values that the retina ability of grunt-spritesmith already performs. I might be missing something but what is wrong with using the existing variables and functions?
Here is a documentation on our retina parameters:
https://github.com/Ensighten/grunt-spritesmith/tree/4.5.3#retina-parameters
An example usage for retina:
https://github.com/Ensighten/grunt-spritesmith/tree/4.5.3#retina-spritesheet
An example of the SCSS template:
https://github.com/twolfson/spritesheet-templates/tree/9.4.1#scss_retina
An article explaining everything more in depth:
http://twolfson.com/2015-04-21-retina-sprites-are-here!

as i said before I don't like the way that I am forced to have an equal amount of sprites for 1x and 2x. especially during the dev period things change at a rapid pace and some asset extraction lags behind and those situations create delays. The retina gruntsmith solution requires exactly that. I also wanted to create placeholder which actually exist in my scss file. Sure I can run an each loop which runs through the sprite array and creates them on the fly, but its expensive and i dont want to do that every time I change something in one of my scss files. Creating existing placeholders takes a bit of the burden of the compiler, and fast compiling performance sits pretty high on my main requirements list.  Thats pretty much the reason why I did this way. I hope it makes sense

Sorry, I must have missed the mention of frustration with equal sprites for 1x and 2x sprites. You seem to be bending over backwards for this solution. We strongly recommend to not regenerate sprites as part of the normal build process due to its cost; it should be reserved only when the sprites change as the results will always be the same.
Have you considered committing the generated spritesheets to the repo (as people normally done when managing them by hand) or leveraging grunt-newer?
https://github.com/tschaub/grunt-newer
If you take that approach, then you can generate placeholder upscaled images (as you mentioned) via a grunt task and only generate them when your assets change:
https://github.com/excellenteasy/grunt-image-resize
I am still going to be adding handlebars helper support. However, I would also like to get you in a less painful configuration =)

Hey twolfson thx for thinking this through. My example here is made due to very specific requirements which unfortunately couldn't be met by the package. Believe me I tried the retina solution and because of that I put this example together. I know, calling the task on the grunt call isn't super efficient. Setting up a file watcher should work too and newer is definitely a way to go as well. And on a side note, the configuration isn't painful at all :).

Sorry for the slow reply. I was more talking about the effects of the configuration (e.g. performance) than the configuration itself. I will be taking a look at adding in helper registration to handlebars by the end of next weekend.

We went with a format similar to the originally proposed data. There was an option to expose a function on grunt-spritesmith as a library but that breaks grunt conventions.
We allow helper registration via cssHandlebarsHelpers which is an object that is a key-value pair mapping of names to their helper functions. For your case, we would use:
sprite:{
    x1: {
        cssTemplate: 'scss/spritesmith/spritesmith-retina-mixins.template.mustache',
        src: 'img/spritessmith/1x/*.png',
        dest: 'img/spritessmith/spritesheet1x.png',
        destCss: 'scss/spritesmith/_sprites1x.scss',
        cssSpritesheetName:'sprites1x',
        imgPath: "/app/img/spritessmith/spritesheet1x.png"
    },
    x2: {
            cssTemplate: 'scss/spritesmith/spritesmith-retina-mixins.template2.mustache',
            src: 'img/spritessmith/2x/*.png',
            dest: 'img/spritessmith/spritesheet2x.png',
            destCss: 'scss/spritesmith/_sprites2x.scss',
            cssSpritesheetName:'sprites2x',
            imgPath: "/app/img/spritessmith/spritesheet2x.png",
            cssHandlebarsHelpers: {
                divide: function (value) {
                    return parseInt(value) / 2 + 'px';
                }
            }
        }
    }
}

This has been released in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>A gulp.spritesmith release will be occurring shortly.


Double return bug

There are cases where extracted F* files in libcrux-ml-kem have redundant third return value where just double are supposed to be at the receiving side. This breaks lax-check of affected F* files.
Here is an example of this bug https://github.com/cryspen/libcrux/blob/dev/libcrux-ml-kem/proofs/fstar/extraction/Libcrux_ml_kem.Ntt.fst#L34
It's fixed manually here https://github.com/cryspen/libcrux/blob/dev_ml_kem_lax/libcrux-ml-kem/proofs/fstar/extraction/Libcrux_ml_kem.Ntt.fst#L34
Workaround: add () at the end of your function, see the comment below.

Thanks for the issue!
I spent a few hours on that, I don't have a fix yet.
I think this issue shows up mainly in functions that ends with a loop.
A workaround is to add a () at the end of the function, e.g.:
fn f(n: &mut usize) {
    for _ in 0..10 {
        *n += 1;
    }
}

becomes:
fn f(n: &mut usize) {
    for _ in 0..10 {
        *n += 1;
    };
   ()
}

@W95Psp this is overdue for a while now. What's the status and plan to get it fixed?

I removed the due date and set the priority to low. We have a workaround, and loads of other things to do, so let's pick that whenever we have time.

I found a few other instances of this. I think this has to have a higher priority since the bug and its fix are quite obscure.

My reproducer:
fn f(n: &mut usize) {
    for _ in 0..10 {
        *n += 1;
    }
}

works now, let's find another reproducer or close otherwise

Looks like this is working for the cases in libcrux as well 🥳
Let's link the PR that fixed it. Are there tests? If not we should add some and close this issue with that.

I'm still seeing this in the ML-DSA code in libcrux.
Here's an example https://hax-playground.cryspen.com/#fstar+tc/de59826b83/gist=b2613b7c8515f901ecc1a2bd77339e17


[SR-69][Sema] Improved quality of diagnoses messages

In the specific case of sr-69, and in a bunch of other code where errors arise involving generic function application, better type constraint failure diagnoses are being masked by the overly conservative implementation in evaluateCloseness(). If the actual arg types didn’t exactly match the parameter types, we’d always diagnose a non-specific arguments-don’t-match error instead of allowing discovery of better errors from the constraint system.
This commit adds more cases where evaluateCloseness will return CC_ExactMatch, specifically in application of functions with one or more arguments of a single archetype, like func min<T: Comparable>(T, T) -> T. It verifies that the actual argument type isSubstitutableFor() the archetype, and that all such arguments are of the same type. Anything more complicated than that still has the previous behavior of not matching at all.
I think the final answer here ought to be to make a constraint system with type variables for any archetypes, add appropriate constraints to the actual args and then see if the system can solve all the argument constraints at once. That’s because the next most complicated set of things to handle in the stdlib are things like func -<T: Strideable>(lhs: T, rhs: T.Stride) where generic argument types depend on each other. I tried attacking that, but it was too big of a bite for me to manage all at once. But there are FIXME’s here to try that again at some point.
New tests for SR-69 are at the end of deduction.swift, and the rest of the test changes are generally improved deduced diagnoses. I think the changed diagnoses in materializable_restrictions.swift is the only one which is worse instead of better, and that’s just because the previous general message mentioned inout basically accidentally. Opportunity for further improvement (a new diagnosis maybe) there.
Validation tests run and passed.

Wow, this is fantastic, thank you for working on this.  Here are some nit-picky comments:

Instead of:
paramType->getKind() == TypeKind::Archetype

Please use this, it is a bit more idiomatic (generalizes to dyn_cast etc)
paramType->is()

It looks like line 1240 got 4 spaces of indentation instead of 2.

In this:

    // Since we've 'bound' singleArchetype and it is now potentially wrong,

         // this is then the second mismatch -- give up right away.

         return { CC_ArgumentMismatch, {}};

we're losing the resolution of "CC_ArgumentNearMismatch".

As a followup commit, it probably makes sense to move evaluateCloseness to being a method on CalleeCandidateInfo.  Earlier in the compiler this wasn't feasible, but it looks like it is now and will allow avoid having to pass in CS & argsHaveTrailingClosure.

@lattner Okay, cleaned up ->is() and the spacing. (and squashed.)
There is no actual behavioral change for near mismatches, since argumentMismatchIsNearMiss() also does isEqual() comparisons to the ArchetypeType paramTypes and so would always return false for these args.

Oh, and thank you for the wonderful FIXME comments! (Here specifically, and throughout the project generally.) I spent awhile tracing things down to here and when I found them had the somewhat mixed feeling of "oh, if only I'd not wasted my time in the debugger and had seen this earlier" combined with "well, at least I really know this is the right place to fix things".

Oops! The ->is() change caused a couple additional tests to be effected, since it does desugaring of the type before testing so the generic checks got hit a little bit more often. Changed a couple more expected-error results, committed, squashed.

It occurred to me that I was being dumb about the near mismatches thing and hadn't got what you almost surely meant, which is that you can compare the mismatching arg for near miss'ness to the type that you bound the archetype to. I was concentrating on exact matches and not worrying about improving other closeness results. Did that here as a separate commit (and threw in making it into a member) to check that that's what you intended to tell me.
And as long as this is now trying to be smarter about partial matching of generics as well as exact matching, changed the logic a bit so that if an arg type isn't substitutable it doesn't 'bind' it at all. So (with non-Comparable struct A) min(A(), 3) becomes a one arg mismatch just like min(3, A()).
If this looks good to you there will be more test result changes to make before merging.

Producing single argument mismatches involving generics causes some gross looking error messages if the generic mismatches get put into the same closeness bucket as non-generic mismatches.
E.g. var v71 = true + 1.0 used to produce error: cannot convert value of type 'Bool' to expected argument type 'Double’, but would now end up with binary operator '+' cannot be applied to operands of type 'Bool' and 'Double’ overloads for '+' exist with these partially matching parameter lists: (Double, Double), (T, T.Stride), (T.Stride, T).
Resolve this by adding CC_OneGenericArgumentNearMismatch and CC_OneGenericArgumentMismatch, that are similar but ever so slightly not as close as a mismatch involving non-generic functions. This gets back the original error message in cases like the above, because there is only one declaration of + which partially matches and is non-generic, and the generic partial matches are now farther away.
But now single arg mismatches and nearness work for single-archetype generic functions, as in the additions to the SR-69 test at the end of deduction.swift.

Sounds good, thanks for working on this!


Feature/candidates grid car role cards

What does this PR do?

This PR reestructures the candidates carousel component using material-ui carousel, also the grid is used to images. Open positions Cards was changed into Roles cards adding images and changing the content of the component.

Related issues
#79
Merge Checklist:

[ ] The branch is up-to-date (i.e. rebased) with the base branch
[ ] No code style issues

Looks very good!
There are some small UI/UX tweaks:
Carousel:

Please put some sort of black gradient over the carousel so words can be seen better (try 62%-80%).
Make the animation merge to black when changing between the images

Role cards

Get rid of the black border
Make them fit in the window
Fix the mechanics and marketing descriptions, you can find them here.

Other details

Get rid of the "CandidatesInfo" component.
Change the banner's content to its updated description.

PS: The carousel's height does not follow the window's height, but it actually looks pretty good; I'll talk with the design team so we can decide if it stays like that.
Again, very good job, everything looks great!

I made some changes related to the comments. Thanks


OLS-137: Feedback aggregator

Description
Feedback aggregator
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[x] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #OLS-137
Closes #

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

/hold

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.41%. Comparing base (fccd088) to head (94c21f4).
Report is 28 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #775      +/-   ##
==========================================
- Coverage   94.72%   94.41%   -0.32%
==========================================
  Files          53       53
  Lines        1896     1916      +20
==========================================
+ Hits         1796     1809      +13
- Misses        100      107       +7

/retest

/retest

/retest

/unhold

@tisnik can you give us an example of the output this generates?  (the "report")?

@tisnik can you give us an example of the output this generates? (the "report")?

Sure, it is taken from feedbacks we already have in the bucket (test feedbacks, of course):
User ID,Conversation ID,Question,LLM response,Sentiment,Feedback
c1143120-551e-4a47-ad47-2748d6f3c81c,00000000-0000-0000-0000-000000000000,testy test,bla,1,
11111111-551e-4a47-ad47-2748d6f3c81c,00000000-0000-0000-0000-000000000001,testy test,bla,1,that is awesome
22222222-551e-4a47-ad47-2748d6f3c81c,00000000-0000-0000-0000-000000000002,testy test,bla,2,that is really awesome

do we have clusterid info available?

do we have clusterid info available?

yes, is is part of path to object in Ceph:
Contents of bucket 'QA-OLS-ARCHIVES':
archives/compressed/5b/5b96fffa-9da9-41ae-9994-a6616aab8d34/202404/08/073607.tar.gz
archives/compressed/71/71993a2b-a5fd-452a-b591-73c7c28c1858/202404/11/153617.tar.gz
archives/compressed/98/98e88e5c-917f-4eec-9279-aac3c730c984/202404/18/110842.tar.gz
archives/compressed/e0/e01b2944-7829-4b82-8e32-c8903a55f048/202404/10/131622.tar.gz
archives/compressed/e5/e55f5cf1-367a-44e3-b95e-1816476c353f/202404/08/094419.tar.gz
archives/compressed/eb/ebccba00-7c78-41f5-a9eb-66b2dfbed564/202404/08/124111.tar.gz
archives/compressed/eb/ebccba00-7c78-41f5-a9eb-66b2dfbed564/202404/08/131312.tar.gz

seems worth including

/retest

seems worth including

@bparees not it is included as can be seen in description (and on today's demo too)

/lgtm
/approve

/approve


Pinot doesn't return most data in the metadata JSON Property when tables are created

Submitting the following table config:
{
  "tableName": "test_table",
  "tableType": "OFFLINE",
  "tenants": {
    "broker": "DefaultTenant",
    "server": "DefaultTenant"
  },
  "segmentsConfig": {
    "segmentPushType": "APPEND",
    "retentionTimeUnit": "DAYS",
    "retentionTimeValue": "10",
    "replication": "2",
    "schemaName": "test_schema",
    "minimizeDataMovement": true,
    "timeColumnName": "date_str",
    "timeType": "DAYS"
  },
  "tableIndexConfig": {
    "loadMode": "MMAP"
  },
  "metadata": {
    "test_value": "123"
  },
  "routing": {
    "segmentPrunerTypes": [
      "time",
      "partition"
    ],
    "instanceSelectorType": "replicaGroup"
  },
  "instanceAssignmentConfigMap": {
    "OFFLINE": {
      "tagPoolConfig": {
        "tag": "DefaultTenant_OFFLINE",
        "poolBased": false
      },
      "replicaGroupPartitionConfig": {
        "replicaGroupBased": true,
        "numReplicaGroups": 2,
        "numInstancesPerReplicaGroup": 10,
        "minimizeDataMovement": true
      }
    }
  }
}

Then make a request to the Pinot API: GET /tables/test_table?type=OFFLINE
You'll see that the metadata key is missing:
  "tableName": "test_table",
  "tableType": "OFFLINE",
  "tenants": {
    "broker": "DefaultTenant",
    "server": "DefaultTenant"
  },
  "segmentsConfig": {
    "segmentPushType": "APPEND",
    "retentionTimeUnit": "DAYS",
    "retentionTimeValue": "10",
    "replication": "2",
    "schemaName": "test_schema",
    "minimizeDataMovement": true,
    "timeColumnName": "date_str",
    "timeType": "DAYS"
  },
  "tableIndexConfig": {
    "loadMode": "MMAP"
  },
  "metadata": {},
  "routing": {
    "segmentPrunerTypes": [
      "time",
      "partition"
    ],
    "instanceSelectorType": "replicaGroup"
  },
  "instanceAssignmentConfigMap": {
    "OFFLINE": {
      "tagPoolConfig": {
        "tag": "DefaultTenant_OFFLINE",
        "poolBased": false
      },
      "replicaGroupPartitionConfig": {
        "replicaGroupBased": true,
        "numReplicaGroups": 2,
        "numInstancesPerReplicaGroup": 10,
        "minimizeDataMovement": true
      }
    }
  }
}

However, if you make the same request to create a table it will be included:
{
   ...
   "metadata": {
       "customConfigs": {
            "test_value": "123"
       }
   },
   ...

Given the way the documentation is currently written this is a bug.
This is because the TableCustomConfig.java is expecting a JSON Property called customConfigs.  However, this level of nesting seems unnecessary.
https://github.com/apache/pinot/blob/a130cb2b1e465ad9ad3bdb4428a32fef5bf54cdd/pinot-spi/src/main/java/org/apache/pinot/spi/config/table/TableCustomConfig.java#L32

Good finding!
Currently the only usage for this customConfigs is a deprecated key generate.inverted.index.before.push.
We can either fix the documentation, or pull this map one level up so that it is more intuitive.
@jackjlli Do you use other properties within the customConfigs internally?

Hi guys, I've checked the internal usage of this custom configs. Currently there are quite a few configs which are being used in that custom config map. I think the easier approach is to fix the documentation. Otherwise, there will be some non-trivial effort to put this map one level up (e.g. migrating all the existing table config, making code change, etc).

Sounds good. Updated the documentation. We may revisit this in the future.

I can't remember what the documentation said previously, but I had interpreted the metadata field to be used for arbitrary custom key/value pairs to be added to the table.
Would it be reasonable to leave customConfigs where it is but also make it possible that additional metadata fields at the top level could be included?  That would make it possible to store custom attributes for individual tables inside of metadata instead of necessarily needing to nest inside of customConfigs.

Would it be reasonable to leave customConfigs where it is but also make it possible for additional metadata fields at the top level to be included? That would make it possible to store custom attributes for individual tables inside of metadata instead of necessarily needing to nest inside of customConfigs. It also wouldn't require doing anything to pull things currently stored in customConfigs up.

I don't think it is possible unless we do manual ser-de for that JSON field, which is quite complicated. If we want to make metadata an arbitrary key-value store, we need to define metadata field as a map, but that means there is no way to set customConfigs as an inner map of it.


[NucleoF030R8 - Emblocks offline] HardFault when using wait() with Serial

Hi,
I'm unable to run the simple nucleo_printf example program. In the online IDE it runs fine, but when using the sources in a offline compiler (emblocks 2.3) the program stops and hangs at the wait(1) statement. If i remove the serial comands the program run fine, but i'm unable to debugger (it runs fine until the wait() and never exit) In both cases if i check the stack it is stoped in the HardFault_Handler. This is the stack:

NR
Address
Function
File
Line

0
0800396C
HardFault_Handler
startup_stm32f0xx.S
200

1
FFFFFF9
< signal handler called >

2
080015DE
NVIC_SetVector
cmsis_nvic.c
47

3
0800366A
us_ticker_init
us_ticker.c
110

4
080036C6
us_ticker_read
us_ticker.c
123

5
0800158C
wait_us
wait_api.c
28

6
08001558
wait
wait_api.c
20

7
08003898
main
main.cpp
18

The project was done with the mbed source from the trunk in git

the project is here: https://www.sendspace.com/file/auywkt
and the issue on the mbed site here: http://developer.mbed.org/users/mbed_official/code/mbed-src/issues/10

To be closed


can you provide the running config of 65b models?

Hi, I'd like to run a 65B llama with LOMO, what config should I use to run the training on a 8*RTX 3090 machine?
It would be very nice if you add config/args_lomo.yaml and config/ds_config.json for 65b models.
Thanks.

Hi. You can change model_name_or_path in config/args_lomo.yaml to the corresponding name or path of 65b model to do that.

I have the same problem, llama 65B model with 8 * V100, hit oom, any other parameter should be set ?
args:
# model
model_name_or_path: '/data/home/scv9622/run/LLaMA/65B_hf'
# data
dataset_name: 'multirc'
refresh: false
data_tag: 'base'
train_on_inputs: false
data_max_length: 1024
# training
# trainer
tag: 'lomo'
output_dir: 'outputs'
overwrite_output_dir: true
deepspeed: 'config/ds_config.json'
do_train: true
do_eval: false
evaluation_strategy: 'epoch'
per_device_train_batch_size: 16
per_device_eval_batch_size: 2
learning_rate: 0.03
weight_decay: 0
num_train_epochs: 10
lr_scheduler_type: 'linear'
warmup: 0.1
clip_grad_norm: 1.0
save_strategy: 'no'
save_total_limit: 0
seed: 42
#bf16: true
remove_unused_columns: false
load_best_model_at_end: false
metric_for_best_model: 'acc'
group_by_length: false
#report_to: 'wandb'
dataloader_pin_memory: false
gradient_checkpointing: true
predict_with_generate: true

{

    "bf16": {
        "enabled": false
    },
    "fp16": {
        "enabled": true
    },
    "zero_allow_untested_optimizer": true,
    "zero_force_ds_cpu_optimizer": false,

    "zero_optimization": {
        "stage": 3,
        "overlap_comm": true,
        "contiguous_gradients": true,
        "sub_group_size": 1e8,
        "stage3_max_live_parameters": 1e8,
        "stage3_max_reuse_distance": 1e8,
        "stage3_gather_16bit_weights_on_model_save": true
    },

    "gradient_accumulation_steps": 1,
    "steps_per_print": 2000,
    "train_micro_batch_size_per_gpu": 2,
    "wall_clock_breakdown": false
}

message details:
"torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 968.00 MiB (GPU 0; 31.75 GiB total capacity; 25.87 GiB already allocated; 805.75 MiB free; 29.64 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF"

Sry that I misunderstood your question.
batch_size 16 and data_max_length 1024 is not suitable for 65B model on RTX 3090, because the activation is too large.
Maybe you can set batch_size to 1 or shorten data_max_length? :)

thx, I succeed run 65B  model with batch_size=1 and data_max_length=835, it costs  47min each epoch（26G gpu memery 、 8*v100 node with nvlink).  to achieve the performance as has been noted by the paper，is the 3090 Gpus had nvlink?
Finally, we successfully train the 65B model using 8 RTX 3090 GPUs, achieving a throughput of 4.93 TGS. Utilizing such a server configuration and LOMO, the training process on 1000 samples, each containing 512 tokens, requires approximately 3.6 hours.

Glad to hear that!
To speed up, you can turn off loss scaling (e.g. use BF16) and use grad clip instead of grad norm (set clip_grad_norm in config to None and clip_grad_value to 1.0 or somewhat) to save the extra computation.

thx, I succeed run 65B model with batch_size=1 and data_max_length=835, it costs 47min each epoch（26G gpu memery 、 8*v100 node with nvlink). to achieve the performance as has been noted by the paper，is the 3090 Gpus had nvlink?
Finally, we successfully train the 65B model using 8 RTX 3090 GPUs, achieving a throughput of 4.93 TGS. Utilizing such a server configuration and LOMO, the training process on 1000 samples, each containing 512 tokens, requires approximately 3.6 hours.

hi, I run 65B llama model  with batch_size=1, and data_max_length=512, (32G gpu memory, 8 * V100 node), but failed. could you tell me your successful config info ?
I try it with 65B/33B on lomo / lomo+lora, all failed.

this is my args_lomo.yaml file

this is my ds_config.json file

thx, I succeed run 65B model with batch_size=1 and data_max_length=835, it costs 47min each epoch（26G gpu memery 、 8*v100 node with nvlink). to achieve the performance as has been noted by the paper，is the 3090 Gpus had nvlink?
Finally, we successfully train the 65B model using 8 RTX 3090 GPUs, achieving a throughput of 4.93 TGS. Utilizing such a server configuration and LOMO, the training process on 1000 samples, each containing 512 tokens, requires approximately 3.6 hours.

hi, I run 65B llama model with batch_size=1, and data_max_length=512, (32G gpu memory, 8 * V100 node), but failed. could you tell me your successful config info ? I try it with 65B/33B on lomo / lomo+lora, all failed.
this is my args_lomo.yaml file  this is my ds_config.json file

Solved here. #28


item2id.json

Hello, I am very interested in your work. Did you upload the item2id.json file? I can't find it. Thanks.

Thanks for your interest! We have uploaded it.

Hello, Could you please upload all_objects_meta.npy, generate_VisSpaQA.py, finetune_SPRING.sh? Thanks!

I have uploaded all_objects_meta.npy. As for the two later python files, generate_VisSpaQA.py is current generate_MQA_fromILG.py while finetune_SPRING.sh is train_simmc2.sh. If you have any other questions, you are welcome to tell me.


Update Nimbus-JWT dependency

There are some security issues in the version of Nimbus-JWT being pulled in. The version needs updating in chapter 5/6 and also updating in the repo.

Updated.


Add telemetry for jedi startup

Right now we only know when jedi completes symbol analysis but we don't know if it has successfully started up

Closing it as stale since #11995 was implemented (https://github.com/microsoft/vscode-python/pull/15419)


Rename my_sum to my_add in docs

Why do you keep the name sum_kernel?

Fixed, just overlooked it.

jenkins, test this please.

Jenkins CI test (for commit c738bc77ceeb267f58d2b63bdc4f132b7c978dc9, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

The Jenkins failure (TestConvolutionND_param_16.test_backward_gpu_nobias) is irrelevant to the PR.


Revolution bug in cosmic dance example

The example in https://github.com/Wikunia/Javis.jl/pull/352 here -> https://github.com/Wikunia/Javis.jl/blob/master/examples/cosmic_dance.jl#L45-L51 is a bit incorrect.
If you see the gif https://github.com/Wikunia/Javis.jl/blob/master/examples/gifs/cosmic_dance.gif?raw=true earth completes 1 revolution around the sun(365 days) before venus (224.7) which seems a bit odd.
I think the actions should be something like
    act!(earth, Action(anim_rotate_around(12.5 * 2π* (224.7 / 365), O)))
    act!(venus, Action(anim_rotate_around(12.5 * 2π , O)))

This doesn't affect the pattern formed in any way though.
Pinging @Ved-Mahajan .

@Sov-trotter you are indeed correct.
It was a mistake on my part. Thanks a lot for pointing it out!
Is this something that you can fix or should I make a PR?

Since this is relatively simple. I think it'd be better to tag this issue as a good first issue. Or if you can make a pr, that'd be good?

@Ved-Mahajan - it would be great if you could make a PR! Happy to review. 😄


Fixed and reorganized tests in hibernate-jcache

Signed-off-by: Jan Schatteman<EMAIL_ADDRESS>

Still looking into issues with this PR; I removed the extension from BaseUnitTestCase from one (or several) Tests, and that provokes at least one of those to hang, which was previously caught by the Timeout Junit Rule.

Hi @jrenaat, try to add @BaseUnitTest to the tests where you have removed extends BaseUnitTestCase

I have ignored the RefreshUpdatedDataTest for the sybase and hsqldb environments, because it simply hangs 8db locking issues?), but now running into another ~170 tests failing in sybase (not apparently related to the changes in hibernate-jcache).
Locally, only two fail (consistently), and this can only be reproduced by running all hibernate-core tests (i.e. not by running the failing test individually); the exception message is "Converting org.hibernate.exception.JDBCConnectionException to JPA PersistenceException : Error calling Driver#connect" --> connections not being closed somewhere?

This should be fine. I guess this is just a temporary issue.


Fixes #1702

Overview
Omits returning the cacheSize field when fieldOptions.CacheSize == 0 and/or fieldOptions.CacheType == "none".
I think we should not omit that field though, just return 0.
Fixes #1702
Pull request checklist

[ ] I have read the contributing guide.
[ ] I have agreed to the Contributor License Agreement.
[ ] I have updated the documentation.
[ ] I have resolved any merge conflicts.
[ ] I have included tests that cover my changes.
[ ] All new and existing tests pass.

Code review checklist
This is the checklist that the reviewer will follow while reviewing your pull request. You do not need to do anything with this checklist, but be aware of what the reviewer will be looking for.

[ ] Ensure that any changes to external docs have been included in this pull request.
[ ] If the changes require that minor/major versions need to be updated, tag the PR appropriately.
[ ] Ensure the new code is properly commented and follows Idiomatic Go.
[ ] Check that tests have been written and that they cover the new functionality.
[ ] Run tests and ensure they pass.
[ ] Build and run the code, performing any applicable integration testing.

@yuce I agree with you. I don't think we need to omit the value.
Now that I think about the situation I was seeing, it seems like the problem may be with the fact that a field was created with cacheType of none and cacheSize of 50,000. So perhaps the problem is further upstream. I don't think we should allow it to get into that situation in the first place. I'll try to figure out how I got it in that state.


Improve compiler single-file run syntax

Now the compiler passes all arguments after the first filename to the program.
This allows crystal to be used as #!/usr/bin/env crystal and have arguments work correctly.

Does this mean executing like this doesn't work anymore?
$ crystal foo.cr --release

No big deal although I use it many times when I run something, press "up" to recall and add parameters. Now they have to be added before the file name. But this is actually a breaking change for any script out there.

Resolves https://github.com/crystal-lang/crystal/issues/6291

Does this mean executing like this doesn't work anymore?

Yes, this changed. Ideally crystal --release foo.cr would work, but that's not possible currently.
crystal run foo.cr --release still works.

In my mind #!/usr/bin/env crystal makes no sense because it will recompile the program every where.
What I do with my scripts: I compile them once, in release, and put them in /usr/local/bin. Then they run extremely fast.
Of course others don't need to do this... but I guess people are using Crystal as a scripting language, which boots fast, which is not.

It is ok for few cases. For example, CI scripts would need to be recompiled each time anyway.
We don't always need compile time speed matching scripting languages (some compiles to bytecodes before running).

some compiles to bytecodes before running

compiling to bytecode is miles faster than type checking
By the way, I use flags at the end all of the time. It's just so convenient to add or remove flags from the end than to go right after the build or run command and modify them there.
Can we now introduce a crystal shell_wrapper or something like that that works in this way, but leave the current way as is?

If you want flags at the end, you can use crystal run with that.

Just for reference: There's also https://github.com/Val/crun for shebang integration. Also does some cool things like caching the compiled binary IIUC.
I'm not sure whether this change is worth it. I can see the general use case for shebang, but is it really so useful to pass arguments? I use #!/usr/bin/env crystal a lot for one-off programs and it works fine if you don't need CLI arguments. And I feel when youthe program needs arguments, the intention is to re-use it which would greatly benefit from building en executable once instead of compiling on every run.
Against this questionable usefulnes there is the downside of restricting the way compiler arguments can be used. And IMO the latter is very commonly used and the fact that people are used to that pattern would make it hard if it breaks because you have to switch your own behaviour. Arguments with shebang programs have never worked. Making it work would be great, but it's IMO not a huge loss if it doesn't.

Oh.. I wasn't aware of crun. I was going to suggest something similar. Erlang also has a escript command to compile and run in a single step: https://erlang.org/doc/man/escript.html

I retract my comment above. If it's useful for some then I see no problem.
That said, for example in go if you pass arguments after the filename to build you get an error saying that the options must come before the filename. We should probably do the same.

Most of the time, for a little script, you don't need compiler arguments. If you do need them, then you can just add run to the command.

I was always confused with unexpected semantics with crystal [file] compared to crystal run [file], which is properly documented with crystal run --help. I always use the latter now.
crystal --help returns crystal [command] [switches] [program file] [--] [arguments], crystal file.cr -- --release should work then.
BTW I was never a fan of crystal myfile.cr, adding the 4 characters  run was never a big deal for me :smile:

Just rebased this and fixed the spec failure.
Would be neat if this could be in 0.35.0, I think the semantics are an improvement, even if they're not perfect.

Could we get this in for 0.35.0?

I'm ok with this change, but why is the behaviour different from crystal run? crystal --help says run is the default command. Doesn't that mean that doing crystal foo.cr and crystal run foo.cr should be exactly the same? It's not the case already and this makes the difference even larger. Is there a good reason to keep this difference? If we want to encourage using Crystal as a script engine, at least we should add some caching like crun. Is there any reason not to add those semantics to current run command? Should we have a script command instead and make that the default? Too many questions? :)

Should we have a script command instead and make that the default? Too many questions? :)

I like this, it might help clarify the semantics! But, is this required for merging this PR?
Adding script caching is something I certainly considered too. I think the fact that crun exists means that people want this functionality, but having it as a separate executable you have to install makes it impractical to use. So I thought the compiler could do some of what crun does.

is this required for merging this PR?

That's what I was wondering. Because this PR might promote using just crystal and that would force us to keep that behaviour to not break compatibility with existing scripts in the future. So, for example if we later decide to have both run and script, what's the default? If we keep run, then scripts should be written with crystal script then. So, to answer your question, I don't know yet. This seems simple, but it requires some more analysis.

It's pretty clear that it'd be script as the default if we add it, to not break things. It's just a question of whether we want these semantics (which you seem OK with), and whether it's possible to keep those semantics moving forward (with script it seems to be).
Using #!/usr/bin/env crystal script will not work, because linux passes only a single argument to the program, so env will simply try and find /usr/bin/crystal script, and fail. Yep, it's stupid, but this is why no other language uses subcommands: it doesn't work.

Do we count compiler commandline behaviour as part of the 1.0 guarantee? So can this be merged after 1.0 or not?

@RX14 that is a good question as a user of crystal I would hope the CLI interface was consistent between versions.

@RX14 I think we should make everything as a guarantee after 1.0 as much as possible. So, command line parameters should be forward compatible, at least until 2.0. To answer your question, we should merge this before 1.0.
So, to clarify, after this PR is merged:

crystal foo.cr arg will pass arg as argument (will never try to understand it as compiler parameter)
crystal run foo.cr arg will parse arg as compiler parameter (will never pass as argument)

I would agree with that behaviour. Could you please open an issue to create crystal script later and adjust --help output to clarify that the default is an alias of script and not run?

Maybe we need a spec to ensure the single file mode allows compiler flags before the file, right?
$ crystal -Dflag foo.cr arg

I understand that that flag won't be able to be used in the shebang. Should we discuss how the compiler flags can be passed in that scenario?
Other than that, I agree with what @waj said.

Maybe this is not known, but you can do:
crystal foo.cr bar.cr

that will consider both files for compilation and produce a single executable.
Does this PR change that behavior? I'm not saying that it's a good idea to keep that (I only use that when wanting to run multiple specs, but doing crystal spec file1.cr file1.cr works and is better because I can specify line numbers too). I'm just asking whether the above use case is still supported, or bar.cr is considered as another argument.

I think having run and script is very confusing. How do you explain the difference in easy words, and why run and script do different things? Can script be implicit? Why is it needed if crystal file.cr already works?

The current compiler syntax is a mess.
$ echo 'puts "hi"' > foo.cr
$ echo 'puts "world"' > bar.cr
$ crystal run foo.cr bar.cr
hi
world
$ crystal foo.cr bar.cr
hi

Adding crystal -Dfoo file.cr (assuming you want semi-arbitrary options) would take a lot more work than this PR takes, which is why I didn't add it to this PR.
crystal run foo.cr arg already passes arg as a parameter - it passes anything which doesn't start with a - as an argument, and everything which starts with a - it tries to parse. This is inconsistent but I left the behaviour as-is for compatibility. I changed only crystal file.cr as it was lesser used, and the only option which is usable for shebangs because of what I mentioned above.
I agree with all of you that this area of the compiler has serious flaws and needs review, but it needs a lot more work than can comfortably fit in this PR, and so I'd like to merge an improvement...

Here is the current logic the compiler uses to determine whether to half-emulate crystal run: https://github.com/crystal-lang/crystal/blob/c2113aadc078ec9a8ac7b7969a298c63503a7581/src/compiler/crystal/command.cr#L116
I'm really not sure how to add options to this, since crystal -Dfoo run foo.cr turning into crystal run -Dfoo run -- foo.cr is not what we want at all.

crystal run foo.cr arg already passes arg as a parameter - it passes anything which doesn't start with a - as an argument, and everything which starts with a - it tries to parse. This is inconsistent but I left the behaviour as-is for compatibility

I don't think we should leave this inconsistency right before 1.0. Is it easy to fix? Everything after the filename should be an argument to the program, and everything before the filename should be an argument to the compiler (according to what seems to be desired).

No @asterite , because crystal run foo.cr --release is desired.
Also, for mixing compiler and program args you use crystal run foo.cr --release -- args and play nice with the possibility of multiple files.
Ok @RX14, we can leave compiler flags for later in script if it is an implementation detail. It will be another feature to the command and can be added later.
I think that adding crystal script will serve for simplicity to express what is the default command.

Just as a summary (@waj made one, but I think this is more complete):

if you run crystal foo.cr bar.cr --release -- a then:

foo.cr is compiled
["bar.cr", "--release", "--", "a"] is passed to the program (not to the compiler)
in this form there's no way to specify compiler arguments

if you run crystal run --no-debug foo.cr bar.cr --release -- a then:

foo.cr and bar.cr are both compiled (leading to a single binary)
["--no-debug"] is passed to the compiler
["--release"] is passed to the program

in this form there's no way to specify compiler arguments

Note: adding this isn't a breaking change after 1.0, luckilly

Note: adding this isn't a breaking change after 1.0, luckilly

Though it's not clear how it would be done (or even if it's needed at all).


Term 3 integration: unpredictable reactions to throttle\brake commands

I've collected a list of issues with throttle\brake commands of integration project simulator. Issues were reported by me and other teams\students.
The car doesn't move even if throttle=100 is published in /vehicle/throttle_cmd
Sequence like throttle 5. throttle 5. brake 0. brake 0. leads to car is not moving
If i send eg throttle 0.2 only once And then send throttle 0.0 once or at some frequency, whatever, car is still increasing speed.
I’m seeing very weird behaviour when trying to make the car brake. To come to full stop from speed of ~20mph car needs about 100metres  and 20 sec.
My car is just not moving VirtualBox + Mac. One out of 100 times it does move but it drives straight of the road.

@awbrown90 I believe all issues stem from two features of the simulator:

it doesn't continuously apply input until new one arrives, but only applies it momentarily and then goes to neutral until new input arrives
it doesn't process only most recent input, but holds a queue of all inputs, leading to very erratic behaviour when network delays make inputs queue fill up

Here's a description of sample issues I am seeing, copied from slack:
Around waypoints 6400~6600 some of the runs car first slows down a bit for a few seconds then start accelerating by itself despite controller quickly reacting and applying 0 throttle and max brake. What I suspect is happening is that some communication delay blocks all throttle and steering commands coming into simulator and once delay goes away all queued up commands are being applied to simulator in very short successions. @awbrown90 - can you please confirm or deny whether simulator continues to apply inputs until new inputs arrive? Because it really looks like it doesn’t and instead applies them only momentarily and at pace at which they arrive - leading to behaviour I’m running into.
I have logs showing target velocities are constant and sensible, waypoints are smooth and sensible, errors driving my steering and throttle controllers are correct and inputs to car are sensible too. Simulator is simply not responding to inputs in real time. Quite sure you are having a problem with 10 secs worth of old queued up inputs being applied in like 1 sec. By the time fresh inputs that reacts to these changes get to have a saying, car is already off the road.

I am not able to make the car brake at all, even if I stop all throttle commands and apply max brake - the car continues to accelerate.
Do you think it is related somehow?

If car reacts to steering commands while ignoring brake, then likely not. But I hear about many people having same problem as you do on Slack. For us braking "sort of works", but takes huuuge amount of time and distance - something of the order of 200 metres and 15sec to brake from 20mph to stop.

Turns out the steering is not working either, and the speed keeps increasing even though I publish throttle=0 so looks like the throttle command is ignored as well.
I checked the queue theory and tried to run the server at 1Hz, 10Hz, 50Hz, 100Hz, 200Hz and saw absolutely no difference in behavior between all of these.

@gpavlov2016 In that case are you sure your ROS is actually connecting to simulator?

By the way live help said that this could be caused by lack of RAM or CPU or GPU. Here is my setup macOS Sierra 2.5GHz Core i7, 16GB, Nvidia GeForce GT 750M, SSD. Used to run both simulator and VM - udacity provided image over Virtualbox.

I'm using 2017 Macbook Pro with 3.1 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3 and Radeon Pro 560 4096 MB, giving full resources to VM. If this isn't enough, what is?

Having the same issue with 3.1 GHz Intel Core i3, 16GB, Geforce GTX 1060. I am not using the VM at all, but still get those nasty lag which make really difficult to get consistent result or any result at all.

I found some workarounds on Slack that helped work around these issues, so I think it's worth posting them here. The changes in this commit improved performance a lot:
https://github.com/jdleesmiller/CarND-Capstone/commit/33dae9248a73feab9b577dd135116b6575e85788

At waypoint 6665, the images being sent to the controller double in data length. This causes server.py to max CPU utilization (even if all sio events are commented) and extreme FPS drop in both the controller and the simulator. Also occurs at the beginning of track near the speed limit signs. In both these areas, the additional trees lead to complexity in the images transmitted. To prevent this bottleneck, the scene needs to be simplified or the image size needs to be capped.


ignore offers from wrong publishers

I was wearing my hacker hat this weekend (alright, I usually wear it) and realized that I don't think we are picky enough in the Azure app deployments we trust. Anybody could create an offer and name it terra-dev. This PR adds another restriction that an Azure app deployment must be from a configured publisher.

Thanks for doing this.


ZAP over TOR Support

With the upgrade to LND 0.9.0 - somhow the connection over TOR is not working anymore in iOS- see: https://github.com/LN-Zap/zap-iOS/issues/333
For a manual try follow: https://github.com/openoms/bitcoin-tutorials/blob/master/Zap_to_RaspiBlitz_through_Tor.md

Would this issue be the reason the QR code does not come up when trying to generate it to scan in Zap?
I have been playing with this for days, to no avail.
Everything else seems to work OK, but I get no joy when trying to connect any wallet - no QR code is displayed on either the PI or laptop

@lordgivemestrength if no QR code shows up on trying to connect any of the wallets this #1001 seems not to be your issue. Can you open a new issue and try to give more detail on your problem?

Doing some tests and writing down the results. So with LND 0.9.2 connecting with:

iOS (appstore) IP based --> works

iOS (appstore) over TOR --> gives this error:

iOS (testflight mainnet) over TOR --> gives this error:

pusching the error to v1.6

Can confirm I receive the same error (could not connect to server. (unknown error 1)) on 1.5

I see this error as well :(

I also see this error. Has anyone tried any of the other mobile apps? Does fully noded work well?

There is no movement on the ZAP repo on this issue, we remove the TOR option again for now with v1.6 release. As an alternative way v1.6 will have IP2TOR bridge subscription services ... so you can run your node behind tor but rent a public IP+Port that can ce used to connect apps like Zap. See #1194

Switched ZAP over TOR for Android back on based on request:
https://github.com/rootzoll/raspiblitz/issues/1308

The issue looks to be fixed soon on the Zap side as well: https://github.com/LN-Zap/zap-iOS/issues/333
Will need testing once appears in the App store

Will we need to update Raspiblitz to test once the new version of Zap appears in the Apple store?

Appears to work, try for yourself:

I readded the option to connect Zap iOS over Tor to the Raspiblitz fpr v1.6: https://github.com/rootzoll/raspiblitz/issues/1308

Someone should update this page to show it working again

Someone should update this page to show it working again

done


Category link channel entry to listing page with sprig filter

Hi,
Thank you for the wonderful plugin.
I have a category filter called news-category on the listing page news. This is built via sprig.
The news-category filter has categories: events, clients, ...
On this page everything works as desired.
Once you click on an entry. You arrive at an entry page with the content of the news article. Here you will also see the category linked to the entry.
My goal: If you click on the category 'events' for example, you should be redirected to the listing page news where the filter is automatically presorted to 'events'.
So I don't want one to be redirected to another category listing page.
My questions:

To do this I would have to replace the category url with the listing page url. But I am not so sure how to create this news listing page url.
My entry pages for all news articles are built via a channel. The listing page news is a structure template. How can I create a link on the entry page to this overview page? My website is multilang, so I would prefer not to enter the url manually but work through the ID of the listing page. Is there some code for this to get the url from an entered ID of a structure page?

I searched online and I tried:
{% set listing = craft.section.getSectionById(3363) %} {{ cat.title }}
and
{% set listing = craft.section.getEntryTypes('newsOverview') %}
{{ cat.title }}

But it doesn't work

I was thinking to pass the 'category.id' through the url. And to include it on the news listing page inside the filter:
Something like, if a slug id is passed in. Then add it into the array newsCat. But afterward you can still deselect through the filter the passed in slug id.
Do you guys happen to have an example or more documentation on this? Or do you have another solution?
Thank you very much
Greetings,

This really isn't Sprig specific. You can use routes or multiple other Craft concepts to achieve this, so I suggest you work through the Craft docs or ask in one of the official support channels.


Request to Remove Internal Logging from Library

I would like to bring up an issue regarding the use of an internal logger within the library. It's generally advised that libraries should avoid directly writing logs. This practice can lead to several challenges, such as cluttered log outputs and potential conflicts with the application's own logging strategy.
https://github.com/search?q=repo%3Astartreedata%2Fpinot-client-go+log.Error+NOT+path%3Aexamples%2F+NOT+path%3AREADME.md&type=code
Thank you for your work on this project, and I hope this suggestion contributes positively to its development.

Thanks @ryancurrah for reporting this!
Agreed that the logger should be separated.
In terms of improving this, what we can do is:

Create a Logger interface

type Logger interface {
    Debug(args ...interface{})
    Info(args ...interface{})
    Warn(args ...interface{})
    Error(args ...interface{})
}

Implement default Logger interface for NoLogger and LogrusLogger

import (
    "github.com/sirupsen/logrus"
)

// LogrusLogger is an adapter for the logrus logger to satisfy the Logger interface.
type LogrusLogger struct {
    *logrus.Logger
}

func (l LogrusLogger) Debug(args ...interface{}) {
    l.Logger.Debug(args...)
}

func (l LogrusLogger) Info(args ...interface{}) {
    l.Logger.Info(args...)
}

func (l LogrusLogger) Warn(args ...interface{}) {
    l.Logger.Warn(args...)
}

func (l LogrusLogger) Error(args ...interface{}) {
    l.Logger.Error(args...)
}

Use the adapter during init the client:

// Initialize logrus logger
pinotClient, err := pinot.NewFromZookeeper([]string{"localhost:2123"}, "", "QuickStartCluster")
pinotClient.setLogger(LogrusLogger{Logger: logrus.New()})

Logger interface is sufficient, I would also lean towards compatibility with the slog logging interface https://go.dev/blog/slog.


Pod cannot reach a service in another cluster through mcgateway, HTTP 503 error

Describe the bug
I have a service in clusterB, a dummy http server, and when I try to access from a pod in clusterA I get the error upstream connect error or disconnect/reset before headers. When I look into the sidecar logs of the pod in clusterA I find this:
[2018-11-08T14:21:02.721Z] "GET /HTTP/1.1" 503 UC 0 57 2 - "-" "curl/7.61.0" "1d780586-03d5-9bdf-b2be-37a0d017f0e5" "liveness.testing.svc.cluster.local" "ELB-IP-assigned-to-mcgateway-service-clusterB:15443" outbound|80||liveness.testing.svc.cluster.local - service-ip-on-clusterA:80 <IP_ADDRESS>:37374 -

I got nothing on the mcgateway of the clusterB though. Where I am getting this error from?
Expected behavior
I get a response from the service in clusterB accessing through the mcgateway on that same cluster.
Steps to reproduce the bug
Install these resources in clusterA:
apiVersion: v1
kind: Namespace
metadata:
  name: testing
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Service
metadata:
  name: liveness
  namespace: testing
  labels:
    app: liveness
spec:
  type: ClusterIP
  ports:
  - port: 80
    name: http
  selector:
    app: liveness
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: remote-endpoint-for-liveness
spec:
  hosts:
  - liveness.testing.svc.cluster.local
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: STATIC
  location: MESH_INTERNAL
  endpoints:
  - address: <Amazon-ELB-IP>
    ports:
      http: 15443
---
apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    istio-injection: enabled
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: curl
  namespace: development
  labels:
    app: curl
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: curl
    spec:
      containers:
      - name: curl
        image: byrnedo/alpine-curl
        command: ["tail", "-f", "/dev/null"]

Install these other resources on clusterB:
apiVersion: v1
kind: Namespace
metadata:
  name: testing
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Service
metadata:
  name: liveness
  namespace: testing
  labels:
    app: liveness
spec:
  type: ClusterIP
  ports:
  - port: 80
    name: http
  selector:
    app: liveness
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: liveness
  namespace: testing
  labels:
    app: liveness
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: liveness
    spec:
      containers:
      - name: liveness
        image: jasonrm/dummy-server
        args:
        - -port=80
        ports:
        - containerPort: 80
          name: http
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: liveness-gateway
  namespace: testing
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: liveness
  namespace: testing
spec:
  gateways:
  - liveness-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: liveness
        port:
          number: 80

Run on clusterA:
kubectl exec -n development <CURL-deployment-POD> curl liveness.testing.svc.cluster.local
Version on both clusters
Kubernetes 1.11
Istio 1.1.0-snapshot2
Installation
Using helm charts, adding the secret for Citadel with the intermediates CA issued by the same root CA, with the following values:
global.mtls.enabled: true
global.multiCluster.connectUsingGateway: true
gateways.istio-mcgateway.enabled: true
security.selfSigned: false
Environment
Amazon through GiantSwarm

@rshriram I saw you worked on this multicluster approach in #8992, any clue? am I missing anything?

Closing issue since it worked well with the new multicluster approach using gateways https://github.com/istio/istio/commit/ce90c45dfe8aaf46315aca1b31ddbc2d12a4d090


Passing invalid value in from-asid header

Description: This is a negative test. It will verify Asynchronous Reliable response with passing invalid from-asid in header value.
Test Data:
Content-Type: application/json
Interaction-Id :"REPC_IN150016UK05"
sync-async : true
from-asid :invalid_asid123
Expected result: either 400 bad request or 500 internal server error
Actual Response - we are getting 200 OK with response body
Note: when we are changing header value for sync-async ="True" (Capital "T") instead of passing "true"(small "t"),
in this case we are getting 202 Accepted response.

@sonalnegivarma this header is optional for the async requests, please retry for synchronous only in the latest release.

@michael-kainos  Retested this defect. It is reproducible at my end -
Test Data:
Content-Type: application/json
Interaction-Id :"REPC_IN150016UK05"
sync-async : true
from-asid :invalid_asid123
Expected result: either 400 bad request.
Actual Response - we are getting 200 OK with response body
Note: Previously when we are changing header value for sync-async ="True" (Capital "T") instead of passing "true"(small "t"), in this case we are getting 202 Accepted response.
But now, in both the cases it is giving 200 OK response.
@michael-kainos  Could you please look into this. I have added screenshot in JIRA ticket as well -
https://medicaldirector.atlassian.net/browse/NHST-107

@sonalnegivarma
I have investigated and this is the expected response for all requests as the header is not required.
for the async reliable request, the 3rd and 4th 'extension 'nodes in the xml body is where the ASID can be updated and tested.
Please retry with this information and ignore the header

@michael-kainos
We are assuming that when sync-async is true we need to pass the from-asid in the header key.
Reference - https://medicaldirector.atlassian.net/wiki/spaces/NHS/pages/728400908/MHS+adaptor+functional+tests+plan

Hi @michael-kainos,
Looks like there is some misunderstanding here about synchronous request:
according to the documentation when setting sync-async = true, the request is synchronous.
I'll tag you in where it was mentioned.

Hey @michael-kainos  Thanks for confirming this. I have retested this defect.
Test data -
Content-Type: application/json
Interaction-Id :"REPC_IN150016UK05"
wait-for-response : true
Expected result: 200 OK
Actual Response - 200 OK
Additional details and Screenshot has been added to JIRA ticket - https://medicaldirector.atlassian.net/browse/NHST-107


Constrain types for multi-match at compile time

Fixes #4

cc @xendk

@jgaskins :+1:
Works like a charm.


Code release under MIT or BSD or Apache license?

Hi,
Is there any plan to release the source code under MIT/BSD/Apache licenses?
Br
Anuraj

Hello, @anuraj-rp thanks for your interest. Unfortunately, we don't know our PI's criteria. Maybe it would be better to send an e-mail to our advisor if you need this code for your business.

Hi,
Not needed for business. Just that it is more common now to make open source releases under MIT/BSD/Apache and hence asked the question
Thank you


Upgrade our rest-assured dependencies from 3.1.1 to 4.3.1

Task Description
We need to upgrade our rest-assured dependencies from 3.1.1 to 4.3.1.
Tasks
The following tasks will need to be carried out:

[ ] Update the version in the strongbox-parent project.
[ ] Apply any required code changes, or dependency excludes.
[ ] Test and confirm that there are no issues with the core projects (strongbox, strongbox-web-integration-tests, etc) after upgrading.

Task Relationships
This task:

Relates to: #1852 , #1853

Help

Check our article on how to upgrade dependencies and plugins.
Our chat
Points of contact:

@carlspring
@sbespalov
@steve-todorov

How to complete this I have done the necessary changes.

Hi @carlspring, can I take on this issue?

Apologies for the late reply, yes, you can give this a go! :)

Note, that branch issues/1649 already updates rest-assured to version 4.2.0 in strongbox/stronbox-parent#62. This in going to lead to merge conflicts one way or another. Maybe this issue should wait for strongbox/stronbox-parent#62.

Good observation! We've tried to limit the number of things that have been upgraded on the issues/1649 branch. However, we don't currently have a timeframe of when it will be merged into the master and it could still be a while before that happens.
It would probably be a good idea to upgrade this on the master for now.
We could discuss this on our chat channel, if you like.

@carlspring I noticed this issue doesn't have an assignee, but based on the comments, I'm wondering if it's taken?

@ecawlfield : I don't believe anyone else is looking into this!

Note, that branch issues/1649 already updates rest-assured to version 4.2.0 in strongbox/strongbox-parent#62. This is going to lead to merge conflicts one way or another. Maybe this issue should wait for strongbox/strongbox-parent#62.

@ecawlfield : Could you please use the same versions as in the issues/1649 branch? Thanks! :)

As in upgrade to 4.2.0 instead of 4.3.1?

You know what...? Perhaps the better thing to do would be to:

Create a pull request for the master, make sure it works with 4.3.1 and
We'll create another pull request against the issues/1649 branch and test it there as well

It shouldn't be all that much extra work and we can thus make sure both branches will be on the same version.

Well, I was getting a build error after upgrading to 4.3.1, so it was sort of stalled at the "make sure it works" part. If it's not a mistake I've introduced, I was thinking there might be some other changes needed for this upgrade?

"I was getting a build error" doesn't really tell us much about the error you're facing.

Ah, I'm sorry--I put it in the chat earlier, and thought you'd probably seen it already. It was this one:
  [INFO] BUILD FAILURE
  [INFO] ------------------------------------------------------------------------
  [INFO] Total time:  07:19 min
  [INFO] Finished at: 2020-10-25T18:09:54-07:00
  [INFO] ------------------------------------------------------------------------
  [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile (default-testCompile) on project strongbox-rest-client: Compilation failure
  [ERROR] /C:/Users/thatm/Desktop/strongbox/strongbox-rest-client/src/test/java/org/carlspring/strongbox/rest/client/MockMvcRequestSpecificationProxyTarget.java:[41,8] org.carlspring.strongbox.rest.client.MockMvc RequestSpecificationProxyTarget is not abstract and does not override abstract method accept(org.springframework.http.MediaType...) in io.restassured.module.mockmvc.specification.MockMvcRequestSpecification

@ecawlfield, since the dependency upgrade is over a major version, there are some breaking changes in the interface to be expected. This is one of them. The interface MockMvcRequestSpecification got a new method which is not implemented in Strongbox's code, yet. You will have to add that.
You can have a look at the commit 8313414b71 which includes the update to the new RestAssured version on another branch. Unfortunately, it is all lumped together into one commit, so finding the changes needed for this dependency update is a bit detective work. Have a look at this diff for your problem.

Like @flaix said, there will be some detective work required. Have a look at this. Since all of this has already been done against the issues/1649 branch, you could backport it to the master, get it to work and then upgrade to the slightly newer (latest) version for both branches. There shouldn't be much work involved.

@ecawlfield, just note, that you will usually not need all the changes from one diff to solve a problem. That is because the commit changed lots of things, so the changes needed for the dependency upgrade will often be mixed with other changes in one file. For the problem you encountered above, you will need all changes from that diff for that one file.
Later you will come across another compilation error in a different file, for which you can find the solution in another diff, but this time you only need two of the hunks from that diff to solve the error.

@ecawlfield, I dunno how you're getting along with the fixes, but maybe this is a last tip that could prove useful. Sometimes the fix for a problem is not in the same file as the file the compiler error is reported for. This is often true if the compiler complains that it cannot find a class file. This can happen  when dependencies are missing.

Wow, thanks for all the help!

Let us know if we can be of any other assistance to make you succeed.

I am no longer working on this issue; it's up for grabs.

@ecawlfield ,
Thanks for letting us know!
@flaix , @ptirador ,
Are you interested in picking this up? :)

@carlspring There is already a PR raised. It was tested with version 4.3.0 , will try it with 4.3.1

@carlspring I have raised separate PR for master and issues/1649, pls review the changes.

Thanks, @anki2189 !
As mentioned in our private chat, the pull against the master will be merged. The one against the issues/1649 branch will be tested in Jenkins and, if it passes, it will be closed. @sbespalov will then pick it up from the master when he next rebases his branch (issues/1649) in order to avoid noise in the rebase.


Learn shader-school and webgl-workshop

https://github.com/stackgl/shader-school
https://github.com/stackgl/webgl-workshop

https://github.com/greggman/webgl-fundamentals


Nuget Package Creation - v3.1.12

Bump Selenium version '4.8.2' -> '4.9.0'.
Nuget package creation - v3.1.12.

Codecov Report
Patch and project coverage have no change.

Comparison is base (15c48a2) 100.00% compared to head (bce516e) 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##              main       #51   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           84        84
  Branches         6         6
=========================================
  Hits            84        84

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

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