Login Screen user can slide back to it

I have my navigation setup using React Navigation, which works fine, however, I have a login screen/view once user logins they can slide back to that screen is there a way to disable that or am I doing it wrong.
My router
// Native tab navigation
export const TabsNavigation = TabNavigator({
    Home: {
        screen: Home,
        navigationOptions: {
            tabBarLabel: 'Home',
            tabBarIcon: ({ tintColor }) => <Icon name="home" size={28} color={tintColor} type={"font-awesome"} />
        },
    },
    Photos: {
        screen: Photos,
        navigationOptions: {
            tabBarLabel: 'Photos',
            tabBarIcon: ({ tintColor }) => <Icon name="camera" size={28} color={tintColor} type={"font-awesome"} />
        },
    },
    SiteDiary: {
        screen: SiteDiary,
        navigationOptions: {
            tabBarLabel: 'Site Diary',
            tabBarIcon: ({ tintColor }) => <Icon name="cog" size={28} color={tintColor} type={"font-awesome"} />
        },
    },
});

// Main navigation StackNavigator
export const MainScreenNavigator = StackNavigator({
    Login: {
        screen: Login,
        navigationOptions: {
            title: "Login",
            headerLeft: null
        },
    },
    ResetPassword: {
        screen: ResetPassword,
        navigationOptions: {
            title: "Reset Password",
            headerLeft: null
        },
    },
    Drawer: {
        screen: MainDrawerNavigator
    },
    Home: {
        screen: TabsNavigation,
        navigationOptions: {
            title: "Home",
            headerLeft: null,
        }
    }
});

My index file
class App extends Component {
    render() {
        return <MainScreenNavigator />
    }
}

export default App;

Here is the issue

I could recommend you to split your router into two parts. SignedIn (StackNavigator with Tabs) part and SignedOut part (Login, SignUp etc.)

For the SignedOut part (Login, SignUp etc.) just use StackNavigator and how would you load between the different parts?

Look at my solution
class Layout extends Component {
	render() {
		const { userId } = this.props;

		return <View style={{ flex: 1 }}>
			<StatusBar
				backgroundColor={ AppColors.brand.primary }
				barStyle="light-content"
			/>
			{ userId ? <SignedIn /> : <SignedOut /> }
		</View>
	}
}

Sorry, this is not clear, a bit incomplete can you send the router?

Here you are:
SignedOut.js
export default StackNavigator({
	Login: {
		screen: Login,
		navigationOptions: {
			title: "Sign In"
		}
	},
	...
});

SignedIn.js
export default StackNavigator({
	Tabs: {
		screen: Tabs,
	},
	}, {
		initialRouteName: 'Tabs',
	}
);

const AppNavigator = ({ auth }) => {
  if (auth.isLogin) {
    return <MainNavigator />;
  }
  return <LoginNavigator />;
};

Here is my solution.
export const App = props => <View style={{flex: 1}}>{props.isLogin ? <Main/> : <Login/>}</View>;

@helloyou2012 and @jinziyi your example is the same as mine.

@jurajkrivda yes, I just make it clear 🙂

@jurajkrivda thanks, this is really great appreciate the help, once a user logins how do you navigate to the correct view I had the following
this.props.navigation.dispatch(navigateActionHome)
// Navigation
const navigateActionHome = NavigationActions.navigate({
    routeName: 'Home',
    params: {},
    action: NavigationActions.navigate({ routeName: 'Home'})
})

But it's not working with the changes

props.navigation.navigate('Home');

@jurajkrivda that doesn't do anything here is my updated code
Router.js
// Drawer Navigation
export const MainDrawerNavigator = DrawerNavigator({
    Home: {
        screen: Home,
        navigationOptions: {
            drawer:{
                label: "Home",
            }
        },
    },
    Logout: {
        screen: Logout,
        navigationOptions: {
            drawer:{
                label: "Logout",
            }
        },
    }
});

// Native tab navigation
export const TabsNavigation = TabNavigator({
    Home: {
        screen: Home,
        navigationOptions: ({ navigation }) => ({
            tabBarLabel: 'Home',
            headerLeft : <DrawerIcon navigation={navigation} />,
            tabBarIcon: ({ tintColor }) => <Icon name="home" size={28} color={tintColor} type={"font-awesome"} />
        }),
    },
    Photos: {
        screen: Photos,
        navigationOptions: {
            tabBarLabel: 'Photos',
            tabBarIcon: ({ tintColor }) => <Icon name="camera" size={28} color={tintColor} type={"font-awesome"} />
        },
    },
    SiteDiary: {
        screen: SiteDiary,
        navigationOptions: {
            tabBarLabel: 'Site Diary',
            tabBarIcon: ({ tintColor }) => <Icon name="cog" size={28} color={tintColor} type={"font-awesome"} />
        },
    },
});

// Main navigation StackNavigator
export const MainScreenNavigator = StackNavigator({
    Home: {
        screen: TabsNavigation,
        navigationOptions: {
            title: "Home",
            //headerLeft: null,
        },
    }
});

// Public navigation StackNavigator
export const PublicScreenNavigator = StackNavigator({
    Login: {
        screen: Login,
        navigationOptions: {
            title: "Login",
            headerLeft: null
        },
    },
    ResetPassword: {
        screen: ResetPassword,
        navigationOptions: {
            title: "Reset Password",
            headerLeft: null
        },
    }
});

index.js
class App extends Component {
    render() {
        const { userId } = this.props;
        return <View style={{ flex: 1 }}>
            <StatusBar
                barStyle="light-content"
            />
            { userId ? <MainScreenNavigator /> : <PublicScreenNavigator /> }
        </View>
    }
}

export default App;

Login, paricle
 // Use Api Utils to handle fetch status check, known issue with fetch api
                .then(ApiUtils.checkStatus)
                .then(response => response.json())
                .then((res) => {
                    alert(`Success!`)
                    AsyncStorage.setItem('jwt', res.token)

                    // Redirect to home screen
                    //this.props.navigation.dispatch(navigateActionHome)
                    this.props.navigation.navigate('Home');
                })
                .catch(() => {
                    alert('There was an error logging in.');
                })
                .done()
        } else {
            // Form validation error
            alert('Please fix the errors listed and try again.')
        }

If anyone uses Recompose
import { compose, branch } from 'recompose';

const withUser = connect(state => ({ userId: state.user.id }));

const displaySignedIn = branch(
  (props) => props.userId,
  renderComponent(SignedIn),
);

export default compose(
	withUser,
	displaySignedIn
)(SignedOut)

@jurajkrivda thanks very much I got it working

Never mind I was unable to get it to work, I'm not sure your example is correct. Once I login I can't get it to navigate to the correct view.

The issue is with the following code
{ userId ?  :  }
Once the app is loaded it only loads one of the navigation  or  if so it never loads the other nav and you can't navigate to it
I'm not sure how you it working on your app

I recommend you use Redux for holding the user state and then you can easily do switch between layouts. You don't need navigate to the Home page after AsyncStorage.setItem('jwt', res.token)

Btw this is more sexy:
try {
	const status = await ApiUtils.checkStatus;
	await AsyncStorage.setItem('jwt', status.token);
	...
} catch (e) {
	console.log
}

I'm not sure why there are such complicated suggestions in this thread but the API allows for this with the gesturesEnabled navigation option.
static navigationOptions = {
  gesturesEnabled: false,
}

Wanted to send out a quick update, I appreciate everyone's help and thanks. I would say that react navigation is a nightmare very disappointing. I did add redux and had the same issue as I did without it, the only to really fix it is using gesturesEnabled: false @migueloller thanks. I'm not sure this is really good more of a workaround and you lose some of the native functionality.
Also really no good examples showing complex navigation. And I would redux add more issues.
At this stage, there is no way to really have sepicatrion between different navs.

@migueloller I wasn't aware of gesturesEnabled so thanks for that. However, this interferes with the Drawer navigation. The reason I'm trying to stop the back swipe is because in the iOS Simulator I try to swipe open the drawer but it often invokes the back action instead which makes debugging difficult. I think if I could simply disable the back action for that one screen that would suffice. I don't think that option is currently available.

@MrHubble,
Yeah, you can control gesturesEnabled per screen but I haven't looked at its interaction with the drawer navigation.
@AlmogRnD,
I do agree that there is a lack of resources available online to build complex navigation systems with React Navigation. Hopefully with time the documentation will get better and there will be some more resources out there on how to achieve complex navigation use cases.
For now, keeping in mind that the library isn't feature complete and looking at the source when attempting to build for complex use cases looks like the way to go. This unfortunately isn't the most desirable way but there are people working hard on this so we just have to be patient and grateful of their work.

@jurajkrivda any suggestion if without redux?

@jurajkrivda  ， How do you handle this scenario:
Index scene do not need to login, but when I navigate to a tab or another scene, login scene should show out and after login then go to the tab or scene (not navigate to home).
Need your suggestions, thanks!

For people having a hard time implementing the login. Here is a template,
https://github.com/Jerameel/ReactNativeLogin


Adds a flag to enable/disable vector contract custom kernels in LLVMCPUMmt4dVectorLoweringPass

The VectorContractCustomKernelsPatterns are being replaced by Microkernels and improvements to the DT-only path.
Adds a flag to toggle them on/off. For now they default to on.

Naive question: why not just delete the pass altogether? Really up to you, I dont care about the performance the DT-but-not-UK case much, and the whole rationale for this pass was deeply caring for DT-but-not-UK performance, to the point that we would have ad-hoc matching of vector dialect ops and rewrites into inline asm ops, back when we didn't have UK.  It was effectively a stepping stone towards UK.

Naive question: why not just delete the pass altogether? Really up to you, I dont care about the performance the DT-but-not-UK case much, and the whole rationale for this pass was deeply caring for DT-but-not-UK performance, to the point that we would have ad-hoc matching of vector dialect ops and rewrites into inline asm ops, back when we didn't have UK. It was effectively a stepping stone towards UK.

I figured others may potentially be using these so I was gonna make it optional for now? If you're the only one and you're in favor of deleting, thats is much simpler.
Thats also fine by me. I did want to take a chance to benchmark the DT only path with/without these on some internal models to ensure there are no regressions, but I can do that and then delete.
No objections.

Maybe the only person besides me who might still rely on this (for an experiment from last year that might still be live in some form) is @Max191  - WDYT?
I actually think that disabling his will help make more meaningful comparisons between UK and non-UK (ie, between DT+UK and plain-DT).  That's because this pass is a mini kernel-like approach outside of what we call UK.

Maybe the only person besides me who might still rely on this (for an experiment from last year that might still be live in some form) is @Max191 - WDYT?
I actually think that disabling his will help make more meaningful comparisons between UK and non-UK (ie, between DT+UK and plain-DT). That's because this pass is a mini kernel-like approach outside of what we call UK.

I don't have any need for it anymore. We can delete the pass

I think Kojo mentioned that there were some regressions on the DT path so we may want to keep it under a flag if that is the case. Otherwise, yes, let's remove it!

I think Kojo mentioned that there were some regressions on the DT path so we may want to keep it under a flag if that is the case. Otherwise, yes, let's remove it!

I think it is a "hack" to use ukernels in DT path. Because it is just replacing the vector.contract op with inline.asm ops. While all the work are already ported to ukernels, we should just drop the pass.

I vote for removing this pass as well. I dont think this path is serving a legitimate long term use case at all. The non-UK path is kept alive to make sure we have a pure codegen path working. This is neither here nor there. Even if it means regression on the non-UK path, at least it is more representative of the actual codegen path.

Could we remove this incrementally (i.e., land this flag)? Not sure about the purpose this was serving but unfortunately this is enabled by default and removing everything in one shot would cause random regressions. We are in the process of enabling some transformations that should make up for some of this code but having to deal with more random regressions would make this enablement more difficult.

Thank you for working on this @KoolJBlack ! I've started implementing something similar to help me with https://github.com/openxla/iree/issues/16162. This will make things much easier for me 🙏🏻

Could we remove this incrementally (i.e., land this flag)?

+1


[Bug] Unable to see popup hints in dark mode

Summary
When switching AriaNG theme to "Dark Mode", users can't see any contents when putting mouse on "hint icons". Background and contents of the hints are all black so users can see nothing.
Reproduce

Install "Aria2 for Edge" extension.
Click the icon and enter "AriaNG" page.
At the left panel, click "AriaNG Settings".
Swith "Theme" config to "Dark" mode.
There's a "Page Title" config at the main panel with a question icon.
Hover on the icon, a hint will popup.
Both background and contents of the popup are all black. Can't see anything.

Screenshots

Environment

Microsoft Windows 11 Professional 22H2 (22621.1105)
Microsoft Edge 109.0.1518.78 (Stable) (64 bit)
Aria2 for Edge 1.5.10

AriaNG v1.3.2e (c7ed84d)
Aria2 v1.36.0 (configured as a service)
WinSW v3.0.0-alpha.11 (service creator)

Additional Informations
There's nothing wrong with the latest (currently v1.3.3) version of official online AriaNG.

Duplicate #116


[ESP32] Correct Wi-Fi Network Diagnostics data

Problem

bssid attribute was read as zero
Unsupported attributes were reported as zero

Change overview

Fixed the bssid attribute value
Return CHIP_ERROR_UNSUPPORTED_CHIP_FEATURE instead of zero for unsupported attributes.

Testing

all-clusters-app/esp32 and chip-tool

fast track: platform specific change.


Test with Chromium so we don't have to add additional apt sources and install additional packages

Makes sense.


Remove unneeded Py_mod_create

While thinking about how to implement PEP 547 (direct execution using  -m switch), I have taken a look into cython and it seems that it doesn't need Py_mod_create at all.
The only thing the create slot was used for was setting of module attributes, which are accessible from the module's 'spec'.
These attributes can be easily set from the exec slot, hence, the 'Py_mod_create' slot can excluded.
In CPython issue 30403 you mention that a custom module type might also be needed for C level module globals. These can, however, be kept in the module state.

Thanks, I agree that it's reasonable to do it this way.

However, the problematic bit is that Cython modules do not currently have their module state in non-global storage, and some modules will never support that, e.g. if they depend on external libraries that have global state. That makes it an opt-in feature, not something we can enable by default.
So, all we can really do currently is to reuse the module object and prevent instantiating additional ones, i.e. prevent the library from being reinitialised. And that can be done, although in a highly hackish way, by implementing create and returning the original module instance.
I've already started looking into removing the global state, but that's not easy and will probably slow some things down. For the time being, we only have two choices: not support PEP-489 at all, or implementing Py_mod_create and preventing re-initialisation in it.

I'll therefore close this PR as "you're right, but it's not actually helpful".

I would choose not supporting PEP-489 at all until global state can be removed. The PEP itself has language to support this.
As for external libraries with global state, there will need to be a Python-wide discussion – e.g. if readline supports only one global callback, how should the Python wrapper work if it's loaded more than once?
Even on that front, the "removing global state" effort is not easy and might slow some things down. But I'd like to align that work with Cython as much as possible.


[PokemonTabletopAdventures_v3] Update: Changes default values to allow easier use

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

Changes / Description

Updates the default page for PTA3 character sheets to the configuration page
Updates the default character type to pokemon rather than trainer as the more commonly used type
Updates the default tie breaker initiative to allow a full range of decimal values
Updates the default type selection for new moves to typeless
Resolves an issue where pokemon- and hybrid-type characters were showing "Normal" for their primary type instead of "Typeless" if it was not updated

Character Sheet Info Roll20 Internal Use only.


SVD, method inverse transform

Hello,
With iris dataset, I have this problem :

I don't know why this method doesn't work
Regards,
Alexandre

Hi Alexandre,
To use the 'inverse_transform', you should use as input a relation or a vDF. What are you trying to transform?
The function does not need "mandatory parameters" because of some specific use-cases.
Badr

Hello,
I tested and it works, thank. So, the problem is the documentation : https://www.vertica.com/python/documentation_last/learn/Model/inverse_transform/
You give an example where the paremeters vdf and X are empty and in the documentation, these parameters are optionals (but they aren't).
Can you improve the documentation?
Alexandre


WTF with adding header in local_new_array_ptr.h????

Signed-off-by: trcrsired<EMAIL_ADDRESS>

Fix issue #290


Transactions tab not refreshed when sending at transaction

When sending money from another tab than the transaction tab, it is not refreshed.

Fixed https://github.com/ucoin-io/cutecoin/commit/a1f7d4448681a6e8f5844f74209077b63af244f2


[SPARK-9198] [mllib] [python] Fixed typo in pyspark sparsevector doc tests

Several places in the PySpark SparseVector docs have one defined as:
SparseVector(4, [2, 4], [1.0, 2.0])

The index 4 goes out of bounds (but this is not checked).
CC: @mengxr

Merged build triggered.

Merged build started.

Test build #37849 has started for   PR 7541 at commit e2dcb23.

Test build #37849 has finished for   PR 7541 at commit e2dcb23.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait Nondeterministic
abstract class RDG extends LeafExpression with Nondeterministic
case class Rand(seed: Long) extends RDG
case class Randn(seed: Long) extends RDG

Merged build finished. Test FAILed.

Merged build triggered.

Merged build started.

Test build #37850 has started for   PR 7541 at commit c806a65.

Test build #37850 has finished for   PR 7541 at commit c806a65.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
trait Nondeterministic
abstract class RDG extends LeafExpression with Nondeterministic
case class Rand(seed: Long) extends RDG
case class Randn(seed: Long) extends RDG

Merged build finished. Test PASSed.

LGTM

Merged into master and all branches since 1.0. Thanks!


Unsupported File Generation(?)

The contents of the folder I am trying to extract contain the following:

3,660 Unkown-File-Extensions (extracting by themselves without the rest of the folder gives no error)
62 .Resouce files (If a single one of these files are included during extraction, the error is thrown)
1 .assets,Split0 file
1 .assets.Split1 file
3 .assets files
2 folders:
1x containing the .dll assemblies
1x containing a single unkown-file-extension file named unity_builtin_extra

When I extract everything (including the .resources files) an error gets thrown:
Import: System.Exception: Unsupported file generation 16777216 for asset file '5a6a95618cea9814e8c3ca27369acb89.resource'    at uTinyRipper.SerializedFiles.SerializedFileHeader.Read(EndianReader reader)    at uTinyRipper.SerializedFiles.SerializedFile.Read(Stream stream, Action1 dependencyCallback)
at uTinyRipper.SerializedFiles.SerializedFile.Load(Action1 dependencyCallback)    at uTinyRipper.SerializedFiles.SerializedFile.Load(Parameters pars)    at uTinyRipper.FileCollection.LoadSerializedFile(String filePath)    at uTinyRipper.GameStructure.Load(List1 pathes)
at uTinyRipper.GameStructure.Load(IEnumerable1 pathes)    at uTinyRipperGUI.MainWindow.LoadFiles(Object data
I cant find any information on how to go about extracting the files properly given my scenario
Edit: Here is the link to one of the files that causes the error. FILE

That's audio resource file, it's FSB5 Vorbis Compressed. Mafaca needs the entire game files.

Wait lemme check

Here is a Google-Drive Folder containing the original apk I was working with

Simply drag&drop entire folder, UR will automatically choose appropriate files.

Simply drag&drop entire folder, UR will automatically choose appropriate files.

https://pastebin.com/6gpwvDPE
This is the error I receive when I use the entire folder via drag and drop

This one need to be fixed. I will do it later.

Fixed in 4cd9c95d4db152278e735f36031b7de5243bb3cd


Cleanup table_slice API

:notebook_with_decorative_cover: Description
This is the first PR to be merged into #1140, doing some much-needed cleanup work on the existing table_slice API that will make future changes easier.
:memo: Checklist

[x] All user-facing changes have changelog entries.
[x] The changes are reflected on docs.tenzir.com/vast, if necessary.
[x] The PR description contains instructions for the reviewer, if necessary.

:dart: Review Instructions
Commit-by-commit is best.

I rebased after the approval to get rid of the autosquash commits. I'll merge into the epic branch once the CI is green.

Rebased one further time after fixing the remaining stack-use-after-scope issues w.r.t table_slice::layout() returning by value.


Update cloudknox-product-data-sources.md

Minor updates to make the doc consistent to the current UX.

@marcelodiiorio : Thanks for your contribution! The author(s) have been notified to review your proposed change.


power rename

Description of the new feature / enhancement
need to add optin to give ability to rename files from * name or . name to other new name
Scenario when this would be used?
it is already available with normal rename and should be available with power rename
Supporting information
No response

I'm not sure I understand. Can you be more specific?

For example Using normal rename with windows if I download multiple files from whatsapp I can mark them then rename all in one time but this not available with power rename
From: Jay @.>
Sent: Friday, December 30, 2022 10:20 AM
To: microsoft/PowerToys @.>
Cc: HishamElbelasy @.>; Author @.>
Subject: Re: [microsoft/PowerToys] power rename (Issue #23008)
I'm not sure I understand. Can you be more specific?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/23008#issuecomment-1367764800, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4732C3GYSAZTPVGU5SW6NLWP2EINANCNFSM6AAAAAATMCWCLA.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

You can just select all the files from file explorer, right click and go to powerrename. Does that not work?  /needinfo

You can just select all the files from file explorer, right click and go to powerrename. Does that not work?  /needinfo

Best collages ;
Have a nice day
This is an example
@.***
In this I need to rename all the files into R(*) while * will be sequence from 1,2,3,4,5,6,….. ; how to make using powerrename
From: Clint Rutkas @.>
Sent: Sunday, January 1, 2023 3:09 AM
To: microsoft/PowerToys @.>
Cc: HishamElbelasy @.>; Author @.>
Subject: Re: [microsoft/PowerToys] power rename (Issue #23008)
You can just select all the files from file explorer, right click and go to powerrename. Does that not work? /needinfo
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/23008#issuecomment-1368299334, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4732CYNXOZRKFFIL7U5HGLWQDDKBANCNFSM6AAAAAATMCWCLA.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

without seeing a list of files / exact names, my gut sounds like the regular expression feature would be able to do this with enumeration
Here are a bunch of examples for doing this:
https://learn.microsoft.com/en-us/windows/powertoys/powerrename#examples-of-regular-expressions
does that work?  /needinfo


Add IDE formatting settings

Is it possible to add your IDE formatting settings to the project ? This would make it possible to adapt to the project coding style. We would like to provide back some MR. In that case having the same kind of formatting would be beneficial.
Which IDE are you using ?

I've added a config for the Prettier formatter (in commit c6356f3), and applied the rules we want to follow.
yarn lint checks both formatting and some code style issues using ESLint and Prettier. yarn format should fix any formatting issues in source code.


Created a UserHasActivatedAccount event

I got an app that pushes a lot of stuff to the queues when a user activates, doing it with the UserHasRegistered event presents a vulnerability so I made a new event.

Thanks, this will complete the current ones available.


Dockerfile.gpu keeps the pip package

$ docker run --rm tensorflow/tensorflow:nightly-gpu-py3 sh -c 'ls -lh /*.whl'
-rw-rw-r-- 1 root root 207M May  1 04:54 /tf_nightly_gpu-1.9.0.dev20180429-cp35-cp35m-manylinux1_x86_64.whl

This is 200MB we should get rid of.
In Dockerfile.gpu we have this:
https://github.com/tensorflow/tensorflow/blob/d0f5bc17560fc97bcc7de9164aa3b237a8d5221d/tensorflow/tools/docker/Dockerfile.gpu#L47-L56
In parameterized_docker_build.sh this block is replaced this way:
https://github.com/tensorflow/tensorflow/blob/d0f5bc17560fc97bcc7de9164aa3b237a8d5221d/tensorflow/tools/docker/parameterized_docker_build.sh#L260-L263
We don't have the RUN rm -f /_PIP_FILE_ but it doesn't really matter for the size of the image. Since the COPY is necessarily a different layer than the RUN, see my commit message here: https://github.com/tensorflow/tensorflow/commit/9da73dedfc14861a7efcd44a9943d28ced038dc5
There is no simple solution here, multi-stage builds won't help, I will spare you the black magic technique since we have another option right in front of us:
https://github.com/tensorflow/tensorflow/blob/d0f5bc17560fc97bcc7de9164aa3b237a8d5221d/tensorflow/tools/docker/Dockerfile.gpu#L53-L55
What prevents us from modifying the parameters passed to parameterized_docker_build.sh to download the pip package? I think a 200MB improvement is worth it.
cc @gunan

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
OS Platform and Distribution
TensorFlow installed from
TensorFlow version
Bazel version
CUDA/cuDNN version
GPU model and memory
Exact command to reproduce

ping @gunan @aselle

@av8ramit looks like this is a problem with the local pip package installation.
Could you take a look, we should avoid keeping the file in image if possible.

Upon further evaluation, this is not an easy fix, since not all of our builds are uploaded to GCS when we use parameterized_docker_build.sh and as you mentioned adding a RUN delete keeps it in the top layer. I'll look into this soon.

Nightlies can have the extra 200MB I think that's fine, but for releases only it might be easier to do, right?

Nagging Assignee @av8ramit: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @av8ramit: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Will take another look at this when I get cycles as it's not breaking anyone at the moment.

Nagging Assignee @av8ramit: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @av8ramit: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

I've recently proposed a change to TensorFlow that obsoletes parameterized_docker_build.sh, which should help alleviate this issue (it will be easier to maintain many slim images). If anyone following this thread is interested in making TensorFlow's Dockerfile story better for everyone, please take a look at the RFC.

@angersson will your new version fix this issue?

@av8ramit Yeah. Actually, the implementation of the proposal (linked from the proposal) does fix this.

Nagging Assignee @angersson: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 44 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 59 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 89 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 104 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @angersson: It has been 119 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

This is resolved, since our new images do not retain the pip package.


Support Self-Managed Cluster

Hi,
The Readme says this adapter is meant to be used with AKS.
Will it work with a self managed cluster (V1.11.8) provisioned by the AKS-Engine?
If not - is it possible to add support?
Thank you!

This should work with any self managed cluster that has access to Azure, so something provisioned by AKS-Engine should work well.


[SPARK-17753][SQL] Allow a complex expression as the input a value based case statement

What changes were proposed in this pull request?
We currently only allow relatively simple expressions as the input for a value based case statement. Expressions like case (a > 1) or (b = 2) when true then 1 when false then 0 end currently fail. This PR adds support for such expressions.
How was this patch tested?
Added a test to the ExpressionParserSuite.

cc @dongjoon-hyun

Test build #66232 has started for PR 15322 at commit b25c849.

Thank you for pinging me!

@hvanhovell , it looks great.
Most of cases are passed. I'm wondering if we can support the followings, too?
sql("SELECT CASE 'a'='a' WHEN TRUE THEN 1 END").show

Since the followings are passed, the above one is a minor one.
sql("SELECT CASE ('a'='a') WHEN TRUE THEN 1 END").show
sql("SELECT CASE 1=1 WHEN TRUE THEN 1 END").show
sql("SELECT CASE 1='a' WHEN TRUE THEN 1 END").show

Test build #66232 has finished for PR 15322 at commit b25c849.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/66232/
Test PASSed.

Merged build finished. Test PASSed.

Test build #66246 has started for PR 15322 at commit b6b3910.

@dongjoon-hyun I had to move a few rules around to get your example working. It was hitting the typeConstructor rule instead of the simpleCase rule;  the lesson here is that generic rules should normally get lower priority then specific ones (if they both apply).

Ah, that was the reason. Thank you so much, @hvanhovell .

Test build #66246 has finished for PR 15322 at commit b6b3910.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/66246/
Test PASSed.

Merged build finished. Test PASSed.

LGTM except a minor comment.

Merging to master/2.0. Thanks for the reviews!


pdm: missing editables module when entering devShell

I couldn't find other reports of this, so maybe I'm just holding it wrong, but after switching to the pdm module I started getting this traceback when I enter a devShell:
Traceback (most recent call last):
  File "/nix/store/kjg1yk7k0fflpzjnnpy745rb0haacii7-editable.py", line 229, in <module>
    make_editable(
  File "/nix/store/kjg1yk7k0fflpzjnnpy745rb0haacii7-editable.py", line 65, in make_editable
    editable_dist_info = make_dist_info(
  File "/nix/store/kjg1yk7k0fflpzjnnpy745rb0haacii7-editable.py", line 112, in make_dist_info
    dist_info_name = backend.prepare_metadata_for_build_editable(tmp_dir)
  File "/nix/store/nq1m0pmqh4yzncm311dj5pn8bzzn05hh-python3-3.9.19-env/lib/python3.9/site-packages/pdm/backend/__init__.py", line 87, in prepare_metadata_for_build_editable
    from pdm.backend.editable import EditableBuilder
  File "/nix/store/nq1m0pmqh4yzncm311dj5pn8bzzn05hh-python3-3.9.19-env/lib/python3.9/site-packages/pdm/backend/editable.py", line 7, in <module>
    from editables import EditableProject
ModuleNotFoundError: No module named 'editables'

I'm able to work around it by adding editables it to the app's python dependencies.

What do you mean by app's python dependencies - in the pyproject.toml or in the nix derivation somewhere?

What do you mean by app's python dependencies - in the pyproject.toml or in the nix derivation somewhere?

Never mind - I figured it out (at least for me). Place it in the mkDerivation in the module (in the example here it would be the default.nix file)

Curious, I've never had that happen before. I'll see if I can debug it later.

@JonBoyleCoding Were you just asking me to clarify, or does your response indicate that you've run into the same error?
I really was hoping someone would know what this was and just tell me I was holding it wrong, so we might be able to help run this to ground by finding a minimal repro.
I took a few quick swings at doing so this morning but haven't yet been able to isolate the cause, and I've got other fires to fight so I may not be able to revisit for a bit.

@JonBoyleCoding Were you just asking me to clarify, or does your response indicate that you've run into the same error?
I really was hoping someone would know what this was and just tell me I was holding it wrong, so we might be able to help run this to ground by finding a minimal repro.
I took a few quick swings at doing so this morning but haven't yet been able to isolate one, and I've got other fires to fight so I may not be able to revisit for a bit.

I encountered the same error and was asking if you could provide specifics on how you got around it. Thankfully I did manage to get around it for now!

Gotcha. I did something a little more targeted, but what you're saying sounds fine for a workaround.
I don't really love some specifics of the Nix half of this and will probably refactor later, but for reference I just added a new optional/dev dependency group to pyproject.toml containing only "editables". This part looks like:
[tool.pdm.dev-dependencies]
# workaround
editables = [
    "editables"
]

Back in flake.nix I appended dependencies from that group to the buildInputs for only the devShell so that editables didn't also leak into the container image. In barebones form, that looked something like:
let
  get_dev_packages = groups: with groups;
        editables.packages //
        other_group_i_need.packages;
in {
  devShells.default = (pkgs.mkShell rec {
    inputsFrom = [
      packages.blah.devShell
    ];

    buildInputs = with pkgs; [
      # ...
    ] ++ map (x: (pkgs.lib.head (pkgs.lib.attrValues x)).public) (
      pkgs.lib.attrValues (get_dev_packages packages.blah.config.groups)
    );
  });
}

Is your project public, or is it generally fairly small/simple? This may be an easy fix for @purepani if we have a minimal reproduction at hand. My project's private and somewhat large so it'll take me some time to extract something minimal from it.

I ended up getting the error today while working so I can figure it out based on that.

It will be public in a few days, but not yet. However if you've already got the error then presumably you can go forward with that.

@purepani Awesome, if you take a look! I could do as well, if you want and push a reproducer :)

I'll take a look after work today!

Looks like this may have been a bug in pdm-backend: https://github.com/pdm-project/pdm-backend/issues/242.
It was fixed in the most recent update from a few weeks ago, so I made a PR in nixpkgs to update the backend: https://github.com/NixOS/nixpkgs/pull/323292 (though I haven't tested it with
@phaer should we wait for this to be merged and hit nixpkgs or fix it here while we wait?

Looks like this may have been a bug in pdm-backend: https://github.com/pdm-project/pdm-backend/issues/242.
It was fixed in the most recent update from a few weeks ago, so I made a PR in nixpkgs to update the backend: https://github.com/NixOS/nixpkgs/pull/323292 (though I haven't tested it with
@phaer should we wait for this to be merged and hit nixpkgs or fix it here while we wait?

Even better looks like it was already commited into staging 5 days ago: https://github.com/purepani/nixpkgs/commit/d1c243dca5fc6bbeaf96282511de64c24908bcc6

So we just have to wait until https://nixpk.gs/pr-tracker.html?pr=320924 hits nixpkgs-unstable and update the inputs then :)

Yep exactly
I did test it by adding an overlay to update it, and it did work correctly so just until it gets merged(I wouldnt recommend this since it took a long time to build since it rebuilds a bunch of stuff)

This is now fixed as far as I can tell!


kie-issues#13: Make it possible to configure a commit message validation endpoint on KIE Sandbox

Closes kie-issues#13
In this PR

Added commit message validation to the commit message modal (via a request to an external service)
Added example commit message validation service in the examples directory

How to test
Set the new environment variables and run the example service:

Go to examples/commit-message-validator and run pnpm start
Go to packages/online-editor and run ONLINE_EDITOR__requireCustomCommitMessages=true ONLINE_EDITOR__customCommitMessagesValidationServiceUrl="http://localhost:8090/validate" pnpm start
Create a new commit in a workspace.

https://user-images.githubusercontent.com/10515135/215890679-5a9d68d1-3ef1-4a57-8e13-dac9110570ff.mov

Btw thanks for the GIF! It's always nice to see changes in action! :)


Installation

Sorry to bother you with this, but could someone provide a hint as how to install this software?
Thanks

@ericlesaquiles, is should install with pip install gpfit!


API rework proposal

Description of the problem
The current API is inconsistent, clunky and full of hindsight errors, so it is time we rework the API.
Desired solution for the problem
Table of Contents

General principles
Factory instead of constructor
Entity meta
Events
Entity specific events
Using the new API
Lazy properties
Binding creation
Shared bindings

General principles
In general, the API will stay close to what it is right now. We don't want to do giant changes that will cause people to adapt to a whole new architecture.
Instead, we want to take the current API and leave everything that works well as it is, remove stuff that is bad and replace it with better stuff. Also, we want to add new stuff that makes working with the API easier (e.g. Entity meta), but which is optional to use.
The new API should still feel close to the old API, but with a breath of fresh air and less questionable design decisions.
Most importantly the new API will feature something the old API never did; CONSISTENCY.
For the new API we will create guidelines for naming and general design, so that it does not end like a inconsistent mess like the current API.
Everything proposed here is just a proposal and nothing completely decided on, so if you are reading through this and find something you disagree with, please leave a comment explaining what you would change and your reasoning behind it.
Factory instead of constructor
In the current API, all alt:V entities created from user code are created via the constructor.
So the user calls const vehicle = new alt.Vehicle(...) and creates a new vehicle on the server.
Instead of allowing this use of constructors, we will instead use factories for creating alt:V entities from user code.
Instead of calling the constructor, the user will call a factory like this: const vehicle = alt.Vehicle.create(...)
This makes it more clear that the vehicle is not owned by the script itself, but by the alt:V core layer itself.
(And also this is a limitation that v8pp gives us... but that's not the actual reason for this proposal)
Entity meta
There are several types of meta data available, e.g. synced meta, stream synced meta and so on. In the current API you access them by using the .set*Meta(key, value) and .get*Meta(key) methods.
To make this a bit easier to use, the new API will provide .*meta properties for reading and writing of these meta types. For example, instead of using .setSyncedMeta("test", 123) you will be able to just use .syncedMeta.test = 123
This is just a small addition, but something that makes the API a bit nicer to use. (And also resembles .data from RageMP, which makes switching from there to alt:V easier)
Events
The event system will receive the biggest rework in the new API and will not follow the "change it but don't change it too much" approach.
Right now events are catched via alt.on(eventName, handler) which is an API that will still exist, but that API will only catch custom events, and no alt:V built-in events anymore.
Instead, the built-in events can be listened to by calling e.g. alt.onPlayerConnect(handler), which just solves a hundred headaches caused by the shared event system for built-in and custom events.
Not only will we move built-in events to a different API, but the arguments received in events will also be reworked. Currently, you receive the event arguments as normal function arguments, this has the downside that it has bad backwards compatibility, passing functions sucks and its hard to maintain.
The new event API instead will pass only one argument to the event handler, which is the event context.
The event context is an object that contains all the data of the event, and also in some cases additional data such as functions that can be called.
To get a feel how the new event API will work, lets look at this imaginary event here:
alt.onImaginaryEvent(({ player, weapon, cancel }) => {
    alt.log(`${player.name} called the imaginary event with weapon ${weapon}`);
    if(weapon === "weapon_pistol") cancel();
});

As we can see there, we use the JS object destructuring feature, which makes this a lot easier to read.
Alternatively, we could also write it like this: (But that is not recommended)
alt.onImaginaryEvent((ctx) => {
    alt.log(`${ctx.player.name} called the imaginary event with weapon ${ctx.weapon}`);
    if(ctx.weapon === "weapon_pistol") ctx.cancel();
});

This object approach makes adding new event arguments easier (better backwards compatibility), lets users choose what arguments they need and in what order they need. And additionally as previously mentioned, also allows us to attach some functions to an event.
The return values of events will be completely ignored, in the current API it is used to cancel an event, which will be replaced by the .cancel() function of the event context. This also allows us to add arguments to the .cancel() method for e.g. specifying a reason.
The event context is also used for custom events sent by the scripts themselves, but without the additional .cancel() function attached to it.
Entity specific events
Before reading this make sure to read the Events section
There are many events attached to an entity directly, e.g. playerConnect would be one of those events, so to make it easier in some situations to catch an event only for a specific entity, we will provide an API that catches that event only for that specific entity.
As an example, lets use the playerWeaponChange event here:
player.onWeaponChange(({ oldWeapon, newWeapon }) => {
    alt.log(`${this.name} switched their weapon from ${oldWeapon} to ${newWeapon}`);
});

The this context of the event handler passed here, will always be the entity itself.
Using the new API
To preserve backwards compatibility we have to make sure that this new API and the old API are both accessible, so to make this new API possible we will have to use a new import name for the API.
The old API was (and will be) accessible by importing alt-shared, alt-client and alt-server.
We will move the new API to a new import, to make a clear distinction between the legacy and new API;
It will use @altv/shared, @altv/client and @altv/server for importing the new API.
The old imports will continue to work, but the legacy API will not receive any more updates, so all new features will only be available via the new API. And there will be no guarantees for the stability of the legacy API.
Lazy properties
(Internal, this section is related to the inner workings of the module instead of the API itself)
Right now all properties provided by the API are normal getters that call C++ code, to get the current value from the SDK.
This approach is very wasteful, because there are quite a few properties which do not need to be called more than once. For example the .id property on entities is a) readonly and b) never changes for the lifetime of the entity. So calling this getter every time the user wants to access it, is wasted computation time.
Instead, the new API will use lazy getters which can always be used for properties that are readonly and never change. Lazy getters are only called once per object and the result of it is then stored directly in JS, so the next time the user accesses this property, it's like looking up a normal JS object property. This is much faster than calling into C++ code that calls the SDK getter.
Binding creation
(Internal, this section is related to the inner workings of the module instead of the API itself)
Currently, we create the bindings mostly manually, with some macros we wrote as helpers for converting JS values to C++ values etc.
 It's a pain to maintain and adding new APIs takes way too much time, when there are libraries like v8pp out there, that make binding C++ to JS much easier.
So for this API rework we will also try out v8pp for the bindings, and if it works out well use it for most (if not all) of the bindings in the reworked API.
Shared bindings
(Internal, this section is related to the inner workings of the module instead of the API itself)
While we are at it and reworking the API, we can also fix something that has been causing a headache in writing the bindings for a long time; Shared bindings.
In the current API there are shared bindings, but only for whole classes / namespaces and not for parts of classes. As an example, lets look at the Player class. It's available on both sides, but only a part of the API the Player class has is available on both sides. Right now, this API that is available on both sides is just replicated on both sides, which have their own Player class. Instead of doing this, we will have a SharedPlayer class (that is not accessible from JS code) which is in the shared side of the module, and the individual Player classes will inherit from this class.
This shared class will only have that part of the API that is actually, shared and the inherited classes implement the other parts of the API that are available for that respective side.

Looks great! However, using direct properties instead of setter / getter could introduce a confusion between script-wrapped-entity and raw protocol / mod entity. Just my 2cts.
Finally v8pp 💯

Seems to be much easier :D

I would rather love to see existing features being repaired/fixed/optimized instead of bringing non-impactful API changes for the big communities and the whole playerbase itself. I mean as a dev, I'm looking forward to it, but it will cost us time to adapt/refactor to this aswell.
From the technical point of view all of the stuff listed above seems nice and cool to have, but not really necessary.

I have to 1-up @Segfaultd.

I would rather love to see existing features being repaired/fixed/optimized instead of bringing non-impactful API changes for the big communities and the whole playerbase itself. I mean as a dev, I'm looking forward to it, but it will cost us time to adapt/refactor to this aswell.
From the technical point of view all of the stuff listed above seems nice and cool to have, but not really necessary.

Like he said, the old API stay available and work, which give you the possibility to delay changes or do it one by one, it's also a way to optimize some features, like lazy properties, less C++ calls mean (in theory) a better execution time, and sooner it come, less code you gonna have to update
I agree too with @Segfaultd, it can create some confusion

Looks great! However, using direct properties instead of setter / getter could introduce a confusion between script-wrapped-entity and raw protocol / mod entity. Just my 2cts.
Finally v8pp 💯

I assume you mean instead of having player.health we have player.getHealth() and player.setHealth(value) but I personally don't like this approach at all. I get the point that it differentiates between custom properties from scripts and built-in properties, but the additional work of writing it out seems to me to be more loss than what is gained from that.

I would rather love to see existing features being repaired/fixed/optimized instead of bringing non-impactful API changes for the big communities and the whole playerbase itself. I mean as a dev, I'm looking forward to it, but it will just takes us time to adapt/refactor to this aswell and the playerbase won't really feel the differences.
From the technical point of view all of the stuff listed above seems nice and cool to have, but not really necessary.

I get why you are saying this but you could say this forever, and then this would never happen. Its long overdue to fix the problems with the API. (Also, not only does this improve the API itself but will also massively speed up the maintaining of JS module itself, which is the thing that has drawn out most of my motivation ever since I started maintaining it)
At the end of the day, I will work on this mostly alone, and we still have other developers that will work on other alt:V things, so don't be scared that this would somehow massively slow down alt:V development.
(Also as a last point, I do this not only for the devs, but also for me, to preserve my own sanity working on this module for a longer time)

Overall I like the changes, but I feel like moving to Factories introduces a bit too much abstraction at the cost of simplicity. Traditionally Factory methods are reserved for Factory classes, which this doesn't seem to be. Some purists might dislike that Vehicles both Vehicles and their own Factories. Although personally I'd dislike this change more if there were actual Factories involved. That said I understand that your hands are also tied due to v8pp, so there is that.

Overall I like the changes, but I feel like moving to Factories introduces a bit too much abstraction at the cost of simplicity. Traditionally Factory methods are reserved for Factory classes, which this doesn't seem to be. Some purists might dislike that Vehicles both Vehicles and their own Factories. Although personally I'd dislike this change more if there were actual Factories involved. That said I understand that your hands are also tied due to v8pp, so there is that.

Yes unfortunately. v8pp brings a lot of value in maintainability, but the downside is that if you specify a constructor with it bound to a C++ class it always calls the actual C++ constructor of that class, which does not work with the way the SDK works.
Also as I said in the original post, it shows that the entity is owned by alt:V and not the script / the garbage collector itself.
An actual factory pattern doesn't really make much sense in JS due to it being so dynamic.

As an example, lets use the playerWeaponChange event here:

player.onWeaponChange(({ oldWeapon, newWeapon }) => {
    alt.log(`${this.name} switched their weapon from ${oldWeapon} to ${newWeapon}`);
});

The this context of the event handler passed here, will always be the entity itself.

It would be
player.onWeaponChange(function ({ oldWeapon, newWeapon }) {
   ...
});

because you can't bind context to arrow functions.

As an example, lets use the playerWeaponChange event here:

player.onWeaponChange(({ oldWeapon, newWeapon }) => {
    alt.log(`${this.name} switched their weapon from ${oldWeapon} to ${newWeapon}`);
});

The this context of the event handler passed here, will always be the entity itself.

It would be
player.onWeaponChange(function ({ oldWeapon, newWeapon }) {
   ...
});

because you can't bind context to arrow functions.

you can. If the internal call is bind to the caller class. There is no issue with getting the context.

It's just pseudocode to demonstrate what I mean.
Unsure if setting the this context in lambdas works when called via C++, I'll have to investigate that when I start actually working on this.

What do you think about adding enums directly into js module api, and not just typings (altv-types) so JS & TS users have full API access?
prebuild them using something like esbuild and implement it to c++ just like current JS bindings works?

I already have working solution for it in altv-esbuild

What do you think about adding enums directly into js module api, and not just typings (altv-types) so JS & TS users have full API access? prebuild them using something like esbuild and implement it to c++ just like current JS bindings works?

I already have working solution for it in altv-esbuild

import { BlipSprite, KeyCode, RadioStation } from "altv-enums"

We can do that, but only if its not directly in the alt namespace, because I don't want things that not everyone will use there. E.g. alt.Enums.KeyCode.ESC should be fine

Good work so far. I really like the meta properties approach!

It's just pseudocode to demonstrate what I mean. Unsure if setting the this context in lambdas works when called via C++, I'll have to investigate that when I start actually working on this.

Before you start investigating, think about if setting the function/lambda (if it works) context is a good design principle and general idea.
Consider the following example:
Playground Link
(you might have to configure the TSConfig settings again (Target: ESNext, JSX: None, Module: CommonJS), thanks MS).
Now, inside my object's constructor (or other methods, too), I would not be able to access MyObject's properties over the this context. As you also can see, the function context is by default undefined.
What I am saying is that by setting this to a non-default value, creates confusion - at least for me, because I would expect lambdas to be able to access the next object underlying (e.g. MyObject).
Why not going (from my POV) the more logically way by adding the player to the context/args of the event?
Then, a developer directly see's: "Aha! I can access the oldWeapon, newWeapon and player properties on the context!" by just looking up the signature and not going into the documentation at all - self describing code/signature documentation is key imo.
To summarize, I think that setting this will create too much confusion, requires "too much" background knowledge to get started (as stated above - self documenting) and would also destroy the current expected behaviour of lambdas/functions inside other objects.

How deleting entity meta will work with new way?
delete entity.syncedMeta.key?

How deleting entity meta will work with new way? delete entity.syncedMeta.key? And is it possible to do it like that?

Proxy has deleteProperty handler.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy/deleteProperty

How deleting entity meta will work with new way? delete entity.syncedMeta.key? And is it possible to do it like that?

That will be possible, yes.

Hopefully there will be less memory leaks 🤞(I know this is too naive for C++, but still)

Also a small addition so I don't forget in the future; The JS value to MValue serialization should be done (mostly) in JS, as the serialization in C++ is very slow. (That's why we have raw emits, but they are like half broken for some unknown reason)

Can you please also added in new API, access to all webview listeners, for example:
alt.getEventListeners() // is exists in current API

alt.getWebViewEventListeners() // all active webview listeners.

maybe it can be helpful to catch cheaters interface menu if is using alt.WebView!

Can you please also added in new API, access to all webview listeners, for example:
maybe it can be helpful to catch cheaters interface menu if is using alt.WebView!

webview.getEventsListeners() also exists already, please don't use this thread as a way to report bugs / suggest general new APIs.

Since I forgot to post it here; https://github.com/altmp/altv-js-module-v2
The v2 module containing the aforementioned API rework is already open source for quite some time, and all other discussions regarding the API should be done in the issues of that repository.


unable to use share in ios

Hi,
i have updated the plugin to latest 4.3.17
<gap:plugin name="nl.x-services.plugins.socialsharing" version="4.3.17" source="plugins.cordova.io"  />
using phonegap build, but still i am not able to use common share, but the same app works in android.. other than share option, i am able to use shareViaFacebook, shareViaTwitter etc in ios
code
window.plugins.socialsharing.share(msg,txd,imgtag, function() {console.log('share ok')}, function(errormsg){
console.log(errormsg);
});
above thing doesnt do anything
tested in ios 7 and ios latest 8 version

I can confirm this. Same problem here. Common share works only on Android.

@arulapj The usage of share is incorrect as it takes 6 params, the last two are the callbacks.
@osro How do you use it?

Just like in the examples. This works fine on Android, but with iOS it opens the sharing dialog but nothing is passed to the app that's it shared.
window.plugins.socialsharing.share('Message only');

That's not the same issue btw.
If you try to share that to Facebook you won't see it, so where are you sharing to?

I have tried SMS, Email, Facebook, Twitter... it just opens empty message
Like this... empty SMS message.
![Image SMS]
(https://lh3.googleusercontent.com/0jskKcX5MlVdr7KrPVfcEXkFQ_lQQ-Qhlz6T330G3E7uphXviUUWCzPvJgk3ZQudxZB0qnNU858UFoI=w1416-h838-rw)

Please show the exact line of code you're using to share, as well as the plugin version you're using.
And I mean share('the actual text..., not share(myVariable :)

Well, at the moment it's exactly like the example line :smile:
window.plugins.socialsharing.share('Message only');

PhoneGap 5.1.1-0.29.0
Plugin 4.3.19-dev I downloaded the plugin today via PhoneGap's add plugin command.
On Android it works as excepted
https://drive.google.com/file/d/0Bx8hfxonufSQckNFMVhabVlHTXc/view?usp=sharing

Sorry, missed that comment.
I just tried it on iOS 8.4 Sim (iPhone 6 and 6+) and iOS 8.4 iPhone 6 device, with a vanilla CLI project. Everything seems to be working fine.
Can you please try this project? Unzip it, go to platforms/ios and run the XCode project.

I think i'm going shoot myself :wink: Found the problem...
For some reason (probably some copy paste glitch)
I had this empty share few lines before the actual line
window.plugins.socialsharing.share('');

And seems that the iOS stops on the first one and Android goes with the last one it gets.
Sorry about the hustle, now it's working! Thanks!

Wow, nicely found :+1:


grpc design docs

What this PR does:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report

Merging #163 (c670402) into main (4c9ff2d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #163   +/-   ##
=======================================
  Coverage   45.62%   45.62%
=======================================
  Files          46       46
  Lines        1725     1725
=======================================
  Hits          787      787
  Misses        887      887
  Partials       51       51

Continue to review full report at Codecov.

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


feat: response_rewrite plugin support replace body via origin res body

Codecov Report

Merging #109 (4227bb7) into master (8f8d06f) will decrease coverage by 0.27%.
The diff coverage is 74.19%.

@@            Coverage Diff             @@
##           master     #109      +/-   ##
==========================================
- Coverage   81.15%   80.88%   -0.28%
==========================================
  Files          14       14
  Lines         971      999      +28
==========================================
+ Hits          788      808      +20
- Misses        137      142       +5
- Partials       46       49       +3

Impacted Files
Coverage Δ

cmd/go-runner/plugins/response_rewrite.go
76.47% <74.19%> (-6.14%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


updated metrics example

Signed-off-by: Srinivasan Parthasarathy<EMAIL_ADDRESS>Fixes #770

@huang195 Is this satisfactory in terms of metrics/collect docs?


Named routes for Gridsome

Description
For every page inside src/pages/  I specifically added the name (please see the image No.1) property with the names I would like to call my pages inside the website. But after inspecting the .temp/routes.js I could only see the following (please see the image No.2), only Index.vue and 404.vue has name property.
Image No.1

Image No.2

Expected result
All the routes should have the name properties
Environment

Libs:
- gridsome version: 0.6.6
- @gridsome/cli version: 0.2.1

Browser:
- [x] Chrome (desktop) version 75

For Tooling issues:
- Node version: 10.15.0
- Platform:  Windows

@hjvedvik @tomtev How can I be of an assistance for this particular problem? I would like to tackle with it...

Gridsome can't get the name value from the <script> tag without evaluating and executing it. And I'm not sure if that's a good idea. There is a PR (#756) open that suggests implementing front matter for components in src/pages. That might be a better way to set a route name for a page.

@hjvedvik Thanks for pointing me the directions, will close the issue for now. Please reopen if needed.

What about inferring the route name from the filename, like Nuxt does?

This is an issue I'm still experiencing with v0.7.23
Route names are only generated for index.vue as home and for '404.vue' as *. When using gridsome-plugin-gtm, page view events are only sent to Google Tag Manager for routes that have names. I can manually send the event on page/component mount, but it would be a huge time-saver to have auto-generated, filename-inferred routes like Nuxt does.


multiply Paulis not working

Expected Behavior
Multiply Paulis is supposed to be supported in pauli.py
Current Behavior
when testing it throws a TypeError.
TypeError: unsupported operand type(s) for %: 'list' and 'int'
Steps to Reproduce (for bugs)
from qiskit.tools.qi.pauli import Pauli
pauli_1 = Pauli([1,0,0],[0,0,0])
pauli_2 = Pauli([0,1,0],[0,0,0])
mult_pauli = pauli_1*pauli_2

Paulis are supposed to be constructed using numpy arrays, e.g.
pauli_1 = Pauli(np.array([1,0,0]),np.array([0,0,0]))
Then the multiplication works.


Update Android installer to match streamline_me.py

The Streamline layer Android installer is more capable (dynamic package query, with interactive selection). We should use that, and also allow users to specify multiple layers in a stack.

I would like to work on this issue, can you guide me here

Already being worked on in Arm, so no need for you to do anything.


compute reverse expression

Dear @infusion , @duetosymmetry
I am looking to compute the reverse on an expression.
Use case :
$ is the output value for example of a sensor and the manufacturer gives us the expr1 as formula to convert the $ to a display value for the user
But when the user wants to interact with the sensor, he needs to translate the display value to an expr2 to be sure the sensor could interpret the value.
That's my example :
The user write the expr1 and the library compute the reverse of the expr1 to expr2
expr1 = 1 + log($, 2)
expr2 = 2^($ - 1)
expr1 = sin($ / 7.43) where $ is of type INTEGER
expr2 = int(7.43 * asin($))
expr1 = $ - log($ / (e^(-$) * $^sin(1 / $)), 10)
expr2 = exercise left to the reader
Thanks in advance if you could help us to find a solution of our issue.
Best Regards
Youssef

Hi @yboujraf, the expressions you gave are all not polynomials and so they are outside of the scope of this package.

As far as I know, the math.js guys were working on something like that. I played around to build a symbolic math lib in JS, but this is a huge endeavor. Especially if you want to make the rules work on a specific field.
If you want something robust, take a look at Pythons sympy package.


[Mirror] [Hub Generated] Review request for Microsoft.Web to add version stable/2019-08-01

Mirror from https://github.com/Azure/azure-rest-api-specs/pull/8592

/azp run automation - sdk - test


feat: Adding panel description to dashboards

There are 3 category of expressions in dashboards.

Simple metrics in one panel --> Added description direct from metric docs
Arithmetic expression in one panel --> Pending for now, Need to add appropriate description
Multiple metrics in one panel --> Pending for now, Need to decide next steps

There are few counters put in ignore list, As we don't get description for them, we need to manually formed as per our need.
"Volume Access ($Activity) History",
"Volume Access ($Activity) History By Percent",
"Volume Modify ($Activity) History",
"Volume Modify ($Activity) History By Percent",
"Destination Relationships per Node",
"Source Relationships per SVM",
"Destination Relationships per SVM",
"Service Latency by Resources",
"NFSv3 Latency Heatmap",
"NFSv3 Read Latency Heatmap",
"NFSv3 Write Latency Heatmap",
"NFSv4 Latency Heatmap",
"NFSv4 Read Latency Heatmap",
"NFSv4 Write Latency Heatmap",
"NFSv4.1 Latency Heatmap",
"NFSv4.1 Read Latency Heatmap",
"NFSv4.1 Write Latency Heatmap",
"Top $TopResources Volumes by Inode Files Used Percentage",
"Top $TopResources Volumes by Number of Compress Attempts",
"Top $TopResources Volumes by Number of Compress Fail",

With current description changes, category 1 mentioned above is completed.


Improve SmokeContinuousIntegrationTest

In a preparation for continuous build using the new file system watching this is a rework of SmokeContinuousIntegrationTest. The main goal is that

Most tests continue working with the new continuous build
There are specific tests which show what doesn't work with the new continuous build.

The main difference is that tasks which we are supposed to be watching need to snapshot their inputs, and that we won't watch a project directory if it only contains missing files.

@bot-gradle test and merge

OK, I've already triggered a build for you.


[github] use Issue and Feature Request-templates

I suggest to start using the bug and feature request templates to better group, bundle issues and also to better cluster per app etc.
Include in the title the development name.
Example in my repro:
https://github.com/DDDanny/BangleApps/tree/master/.github/ISSUE_TEMPLATE
You can create test! issues there ;)

This sounds like a great idea - thanks! It'd definitely make things a lot more easier, and it's something I'd like to add to the main Espruino repo as well.
Is it possible to add some message (ideally not part of the issue!) along the lines of: "does your issue not fit in here? ask on the forum"

I just knew the old simple templates, but, yes, indeed!
By using the new docs.github BETA feature of custom yaml forms
So multiple structured forms for

category: issues/bug

general bug
specific to "Bangle app"
...

feature request

specific to "Bangle app"
...
are possible.

Furthermore it is also possible make a form for pullrequests, if this is helpfull (e.g. agree that included sources are MIT licensed g)
Here is some kind of adapted template that has nearly all the features.
A dropdown menu is posible, but that then probably all
There can be a header / hint to the forum within the form.

Link: https://github.com/DDDanny/BangleApps/issues/new?assignees=&labels=bug&template=bangle-bug-report-custom-form.yaml&title=[general%2Fapp%2Fwidget%2Fclock+e.g.+clock]+[development+object+e.g.+antonclock]+title
Hardcopy

Will this produce 2 lists or does it just force the title into a certain format.
For example  APP:   xxxx,  BANGLE:  xxxxx  FEATURE  xxxxx
Definitely the way to go.

No, all templates run to on the same "Issues" list.
Labels can be defined by the owner (defaults are bug and enhancement) - can also be bug and feature request etc.
Example: https://github.com/DDDanny/BangleApps/issues
I created one issue with bug report template and one with the feature request.
I think it would be good to start with two simple forms (with the link to the forum included)
hw version (must have) and firmware version (optional?) is maybe really good structured info.
When using checkboxes github shows tasks, so my guess is to go with a DDLB Bangle 1, Bangle 2, both and maybe extend in future...
The complicated caption with the brackets is then also no more required, simply clone the bug template and have labels app, widget, clock
There is also the possiblity to open an unstructured issue

Don’t see your issue here? Open a blank issue.

This looks great - HW and FW versions would both be great to have as I've had a lot of issues from folks that never updated firmware.
But maybe just have one big unformatted area everything else with some prompts in? If folks aren't getting it we can always change it later.
I wouldn't worry about the format of a PR at the moment though.

But maybe just have one big unformatted area everything else with some prompts in? If folks aren't getting it we can always change it later.

Did I understand correctly that :

You expect a hint to the forum
One textarea prefilled with the steps e.g. What is your hard- and firmware; What is the bug? What is expected; How to reproduce

or

You expect a hint to the forum
DDLB-Field for HW (Bangle 1, Bangle 2, both)
Input-field for FW Version with the link to the "How to update"
One textarea prefilled: What is the bug? What is expected; How to reproduce

I hope I can setup two templates latest by Sunday because I have a strong learning curve and workload @work regarding VS Code/Codium with MS Azure and Terraform...

I wouldn't worry about the format of a PR at the moment though.

Allright, I just wanted to mention that there is the possibility to have this kind of option. You can keep in mind and think about whenever you think "WTF why isn't XYZ mentioned in this PR"

The second option would be preferable I think. Thanks for this! It should be a big help!

Please check the bug form:
https://github.com/DDDanny/BangleApps/issues/new?assignees=&labels=bug&template=bangle-bug-report-custom-form.yaml&title=Short+description+and+provide+the+affected+app%2Fwidget
remark: I was not able to see my "current fwversion". I would like to place an instruction how to see it...
maybe it should be an option e.g. settings-app -> system - or I should better ask this question at the forum smile
Preview:

Sorry for the delay - looks great - thanks! Please could you do a PR? I'd have merged it myself but it looks like you're developing some other stuff in the repo.
Luckily the App Loader now shows the firmware version when connected under 'More...'. Otherwise you can check from the About app but not everyone has that

no problem for delay, you do a very well one man show! and give good hints at forum 👍
yeah i have a lot of open work in my repro - touched a lot apps...

[ ] I can provide a similiar template for a feature request

Thanks! Now I've got the format of it I can probably save you some time and tweak that one myself to add a feature request though


Assign Estimated TShirt Value to all tasks

Estimate tasks within the bounds of the standard

I added the tshirt size to all my items.


Create documentation

Documentation is going to be very important. Apart from how to using RetroHub, theme and app development need to be thoroughly documented.

Documentation issues will be tracked from now on on the docs repo


Mentorship Details page

Problem
We want to show a common place for Mentees and Mentors to review the details of their mentorship relationships.
Mentees list their mentorship relationships through the Mentorships page.
Mentors list their mentorship relationships through the Mentees page
Both of them access to the details of each of their mentorship relationships through a Mentorship Details page
Feature Description
Add Mentorship Details page, accessible when clicking on:

the View button of a MenteeCard for a mentor
the View button of a MentorCard for a mentee

Screenshots

ref #16


TextBox flickers and shows incorrect data when refreshing

Describe the bug
Changing the selection quickly in a textbox flickers. In a multi-line textbox, it might even show incorrect data for some lines temporarily.
To Reproduce
Change the selection of a text box quickly.
Watch the video:
https://user-images.githubusercontent.com/1623034/213168508-5f712837-1a70-4ece-bde5-4d2387da7bfe.mp4
Additional context
Likely caused by #9962:

Changing the pooled GlyphInfo buffer back to a new array in ShapedBuffer solves the incorrect data problem. ArrayPool is a powerful tool, but it's easy to have some kind of "use after free". Here the buffer is shared between multiple runs, but only one really owns it and can return it to the pool too early.

Removing the disposal of _glyphRun in ShapedTextRun removes the flickering. Ideally it should be disposed, but at a better time.

Resolution
I'll open a quick PR to revert those changes, then work on another one later to have more robust pooling and better lifetime management for the various text formatting objects.

As far as I can remember using ArrayPool<GlyphInfo>.Shared.Rent doesn't ensure the GlyphInfo are initialized and can have arbitrary values. The issue could come from that.

As far as I can remember using ArrayPool<GlyphInfo>.Shared.Rent doesn't ensure the GlyphInfo are initialized so they can have arbitrary values. The issue could come from that.

That's true about the uninitialized values but in this case they're initialized immediately after by the TextShaperImpl which creates the ShapedBuffer. It's the only code path creating ShapedBuffers through this constructor so you can't see an uninitialized GlyphInfo[] through it.

Ok then 👍

That and the GlyphRun problem shows that both are still used after Dispose. This require better lifetime diagnosis. Currenly anyone can get a hold of TextLine and TextRun, dispose them and still continue using them: it won't throw but will bring "memory corruption" through pooling instead of a few exceptions for incorrect use. At the very least the GlyphInfos should be reset to an empty array, but it doesn't solve all issues (namely other ShapedBuffers still referencing the array).
Pooling objects is only good when the lifetime of those objects can be clearly controlled which isn't the case here (yet!). IMHO it's important to get the correctness back first, then optimize again later :)

IMHO it's important to get the correctness back first, then optimize again later :)

Totally agree.
BTW AvaloniaEdit  extensively uses the text engine. Editor lines are virtualized so VisualLines are (re)created when they bring visible in the viewport, so fast scrolling a document stresses the text engine very well. It's a good app to rest the lifetime, just you to know.

BTW AvaloniaEdit extensively uses the text engine. Editor lines are virtualized so VisualLines are (re)created when they bring visible to the viewport, so fast scrolling a document stresses the text engine very well. It's a good app to rest the lifetime, just you to know.

I'll keep that in mind, thank you! (I've used the WPF AvalonEdit before but haven't had a chance to use AvaloniaEdit yet).
I have a few other noticeable memory decrease changes in progress that should help.

I think only implementations of IGlyphRunImpl should be disposable and managed by the renderer. Looks like deferred rendering doesn't work well with the current object lifetime management.

We should probably change DrawGlyphRun of the platform drawing context implementation to only except a platform implementation. That way it is safe to dispose ShapedBuffer because the platform implementation isn't using it.
https://github.com/AvaloniaUI/Avalonia/blob/9204b44462a352be1e05f51c577f6507e45811ad/src/Avalonia.Base/Platform/IDrawingContextImpl.cs#L94

Nice find! Indeed, other objects seem to either use the platform specific implementation or are made immutable instead. DrawGlyphRun seems like the odd exception here.
Changing that would still leave the run/buffer hole (as mentioned disposing a line can currently return a buffer to the pool that's still in use by other runs – which is quite dangerous for a public API) but it's not as urgent to fix if the rendering is correct.

Fixed by #10015


Replace Energy with Power in initialisation examples

This PR fixes the examples, which were not updated when Energy was previously replaced with Power.

Hey @camille-bouvy-frequenz , this is already merged, but could you add a test case that would have failed without this fix?


feat: add upx/upx

#1201 #6012 upx/upx: UPX - the Ultimate Packer for eXecutables
$ aqua g -i upx/upx

Close #1201

Thanks.

Released. https://github.com/aquaproj/aqua-registry/releases/tag/v3.48.0


11wCreate Aamiin12s android.yml

And experience the best way for

And experience to be able

Email address to the difference

Aamiin12s and experience the best of your website is not the difference between size you want to the same and experience I


Wiki link on readme

Every time I have to struggle a lot to find the "contribution explanation" link on the wiki. It's buried two levels deep, and is neither in the README nor in Read The Docs. I'm adding it to README to make it easier for new people to figure out what to do.

A great suggestion! Longer term, we probably want to polish up the content on that wiki page and put it into the formal documentation - the wiki page is a great solution for right now, but I think we can do much better.


Security vulnerability in xml2js. Need to upgrade to 0.5.0

Which service(blob, file, queue, table) does this issue concern?
Which version of the Azurite was used?
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
What's the Node.js version?
What problem was encountered?
There is a security vulnerability in 0.4.x versions of xml2js which azurite uses. Need to update to 0.5. If the major version of a dependency is 0, npm caret (^) rules don't apply to update minor versions. Please update manually.
Steps to reproduce the issue?
If possible, please provide the debug log using the -d parameter, replacing <pathtodebuglog> with an appropriate path for your OS, or review the instructions for docker containers:
-d "<pathtodebuglog>"

Please be sure to remove any PII or sensitive information before sharing!
The debug log will log raw request headers and bodies, so that we can replay these against Azurite using REST and create tests to validate resolution.
Have you found a mitigation/solution?

@viswanr
Thanks for raising this issue!
However, many Azurite test cases will fail with the upgrade, so we might need more time to look into the failure and fix them before upgrade xml2js.
@EmmaZhu ,
As I see, most of the failures are in Cors related cases, and failed in "@azure\storage-blob".
Would you please help to see how to fix the failure?
https://dev.azure.com/azure/Azurite/_build/results?buildId=57685&view=logs&j=a423c0c5-489d-5c33-c960-603efb6a5600&t=6241a3eb-2205-5763-b4f2-362515ea0306

Blob Cors requests test
OPTIONS request should work with matching rule containing Origion * @loki @sql:

RestError
at handleErrorResponse (node_modules@azure\storage-blob\node_modules@azure\core-http\src\policies\deserializationPolicy.ts:274:17)
at D:\a\1\s\node_modules@azure\storage-blob\node_modules@azure\core-http\src\policies\deserializationPolicy.ts:179:47
at processTicksAndRejections (internal/process/task_queues.js:95:5)

@EmmaZhu
Never mind.
I have raised a new PR to upgrade the dependency and fix the failures : https://github.com/Azure/Azurite/pull/1911

Close as the fix PR is already merged: https://github.com/Azure/Azurite/pull/1911


DOC: Work around PyQt6 linking bug

So PyQt6-6.6.0 is incompatible with PyQt6-Qt-6.6.1, 6.6.2, etc. But PyQt-6.6.1 is compatible with PyQt6-Qt6 6.6.1, 6.6.2, and 6.6.3 -- but not 6.6.0 or 6.7.0. Not sure there's a clean solution to this other than continuing to adjust our pinning


Improve rendering of test names in rich console

Gradle 4.1-rc-1 comes with this very nice view of tests being currently executed:

Executing test com.foo.bar.SomeTest

However, given the width of a terminal, it's not uncommon to see actually this:

:test: Executing test com.foo.some.very.long
:test: Executing test com.foo.some.very.long
:test: Executing test com.foo.some.very.long
:test: Executing test com.foo.some.very.long

Where the output on wide terminal would be:

:test: Executing test com.foo.some.very.long.pkg.SomeClassTest
:test: Executing test com.foo.some.very.long.pkg.AnotherClassTest
:test: Executing test com.foo.some.very.long.pkg.sub.SubTest
:test: Executing test com.foo.some.very.long.other.package.FooTest

Expected Behavior
We could make it more readable, by making the test class name more prominent. Some suggestions:

:test: Executing test SomeClassTest (com.foo.some.very.long.pkg.SomeClassTest)
:test: Executing test SomeClassTest (com.foo.some.very.long.pkg)
:test: Executing SomeClassTest (com.foo.some.very.long.pkg.SomeClassTest)
:test: Executing SomeClassTest (com.foo.some.very.long.pkg)
:test: Executing test com.foo....SomeClassTest
:test: Executing com.foo....SomeClassTest
:test: Executing test ...long.pkg.SomeClassTest
:test: Executing ...long.pkg.SomeClassTest

Context
It's worth noting that the problem may not be specific to tests. Any long display line will be truncated to the end. We could split this ticket into 2 different issues:
. make tests more readable (this specific issue)
. make the console smarter about long lines
The 2d point may require some smarts about things that are relevant, and things that can be collapsed. Then the console would automatically pick collapsible parts of the message when the width is not enough to display the full message.

I guess another option would be to only render the first letter of a package name e.g. as seen in some logging frameworks.

:test: Executing test c.f.s.v.l.p.SomeClassTest

Thinking about it more do you think we'll need the package at all? Maybe the class name is just good enough.

I like it fellas. I might advocate for your suggestion @bmuschko if it's low-risk if there's another RC.

@eriwen Changing any of the proposed solutions above should be low risk.

@bmuschko let's chat about picking this up for RC2 then :)

I feel guilty for not suggesting this sooner :p

I wish I'd thought of this, but at least we might have a chance to improve it for 4.1

I created a pull request based on the community feedback from the Twitter poll. Pull request is here: https://github.com/gradle/gradle/pull/2578

I get that the most voted option is "keep as is", but I think it doesn't
solve the problem that is explained in this ticket. It even makes it worse,
since the label is now even longer. I wouldn't be surprised most people
didn't even read the ticket when answering. On the other hand, the total of
other options is not for fully qualified class name, so I'd be in favor of
changing to:
MyTest (org.my.example)
which is the 2d most voted option (and was curiously far beyond the other
options for the first hours of the poll).
Le 24 juil. 2017 8:00 PM, "Benjamin Muschko"<EMAIL_ADDRESS>a
écrit :

I created a pull request based on the community feedback from the Twitter
poll https://twitter.com/gradle/status/888424343885160448. Pull request
is here: #2578 https://github.com/gradle/gradle/pull/2578
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gradle/gradle/issues/2547#issuecomment-317504929, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATTxQVjCHz91QOLTf5PWaXCLjeFCl5Cks5sRNvWgaJpZM4OeW3D
.

@melix I think users have their reasons for preferring the format they chose, and I feel strongly that we should stick to what was voted lest users feel slighted.
However, this doesn't prevent us from being smarter about shortening packages, or that we have to keep other parts of the format like "Executing test".
Tell you what: I have in mind an algorithm that would optimize the length of test names (by omitting package names in the middle) such that they are very likely to be fully displayed on an 80-character wide terminal. Perhaps I could have a bit of fun implementing it for Gradle 4.2 (probably too risky for RC2). That would take into account everyone's concerns I think. What do you say?

@melix I think users have their reasons for preferring the format they chose, and I feel strongly that we should stick to what was voted lest users feel slighted.

By this logic all the folks that voted for a different result will also feel slighted.
There are many ways to interpret this data. We lack context here, as we don't know why folks voted one way or the other. It could simply be that they haven't not encountered the issue in this ticket, therefore see no reason to change existing behavior.

It looks like there are a look of different opinions about this topic. How about we do leave the display as it is right now for 4.1? Then in 4.2 we can make a deliberate change based on further internal discussion and the community feedback trying out the final version.

@eriwen Where do we stand with your change on this?

@bmuschko My PR #2581 is ready for review. IIRC it has passed Stage 4 on CI. Any takers?

We solved this by abbreviating the middle in #2581. Hope you like it @melix!


Fix the bug with not passing props to wrapped element of with-rematch

as the code...

others is not a variable defined in that file 🤔

Oh I see, sorry I missed that 😄

Thanks!


ci: add helm install tests

This will help avoid issues like https://github.com/dagger/dagger/issues/7916 in the future - this took a lot of messing around to fix, so it would be good to never hit this again.

Hm - there appears to be something in our CI infra here:

Using our dagger runners (fail): https://github.com/dagger/dagger/actions/runs/10285227388/job/28462983902?pr=8116
RunContainerError: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: failed to write "a *:* rwm": write /sys/fs/cgroup/devices/kubepods/besteffort/podac92bc34-526c-43c7-af5a-a80e9fedc5c0/8ed7faec5bc845ae4599a250fdd3d1e6b982d221e018155101ff1de0ac1be9b4/devices.allow: operation not permitted: unknown
Using ubuntu-latest (success): https://github.com/dagger/dagger/actions/runs/10286345815/job/28466773136?pr=8116

Not 100% sure what would be causing this, cc @matipan @gerhard, any ideas?

I suspect that we need cgroup v2 for nesting support for: https://github.com/marcosnils/daggerverse/blob/e0bd6b9f5519c49db4b6eb0689927214720976f9/k3s/main.go#L13-L36
To get cgroup v2, we would need to switch from AL2 to either:

AL2023 https://github.com/aws/containers-roadmap/issues/1953
or Bottlerocket

We have been talking about this with @matipan a few times in the past. I propose that we create a new experimental runner group which uses this new OS. WDYT @matipan ?

Thanks @gerhard :tada: If that's going to take a bit of time, is there any reason we can't switch these jobs to use ubuntu-latest, and later change them back?
At least that way we can get the helm coverage asap!

Yes, ubuntu-latest sounds like a good short-term solution 👍

Rebased, and updated to use ubuntu-latest - I think this should be alright to merge now? cc @gerhard @marcosnils


Bump indexmap to 2.0 and update MSRV to 1.64.0

The MSRV update is required by hashbrown 0.14 which indexmap 2.0 depends on.

[x] I've included my change in CHANGELOG.md

?r @torkleyy

Codecov Report
Patch and project coverage have no change.

Comparison is base (8fa9995) 85.65% compared to head (0bec45a) 85.65%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##           master     #459   +/-   ##
=======================================
  Coverage   85.65%   85.65%
=======================================
  Files          61       61
  Lines        7760     7760
=======================================
  Hits         6647     6647
  Misses       1113     1113

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


[BUG] integration tests must not be executed if smoke test fail

Description

With the last change, integration test are executed even if smoke tests fail, see example: https://dev.azure.com/best-practices/recommenders/_build/results?buildId=46125&view=logs&j=5264e576-3c6f-51f6-f055-fab409685f20&t=b3018297-00ec-509d-8d8a-45865fb67b06
In which platform does it happen?

How do we replicate the issue?

Expected behavior (i.e. solution)

Other Comments
FYI @gramhagen

try this on spark tests, only 15min: https://dev.azure.com/best-practices/recommenders/_build?definitionId=164&_a=summary

with timeout of 3min (it should fail because the pipeline takes longer than 3min) the pipeline doesn't work properly -> https://dev.azure.com/best-practices/recommenders/_build/results?buildId=46276&view=logs&j=5264e576-3c6f-51f6-f055-fab409685f20&t=afa25a3a-cb48-5dc9-c093-b77a0626746f
I'm enforcing a test to fail: assert True == False. The pipeline doesn't fail, it appears always as working -> https://dev.azure.com/best-practices/recommenders/_build/results?buildId=46275&view=logs&j=5264e576-3c6f-51f6-f055-fab409685f20&t=b3018297-00ec-509d-8d8a-45865fb67b06
@gramhagen have you noticed this behavior? I think right now all the pipelines will pass in ADO even if some tests fail

i'm hoping it's an easy fix. I will force a test failure and see if pushing publishing to happen inside the loop will address this.


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 16:33:29 on 2023.05.09
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 2, errors out: 0
Original problem ID: 20465
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=20465

Problem has been resolved in 6m 0s at 16:39:29 on 2023.05.09
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 20465


Don't depend on spirv-cross in gfx-auxil

All backends depend on gfx-auxil, which drags spirv_cross unconditionally at the moment.

Hmm, actually Vulkan doesn't depend on gfx-auxil :/

What I was seeing is wgpu-native dragging spirv_cross via gfx-auxil on Linux...

See also - https://github.com/gfx-rs/gfx/issues/3063


Remove unneeded GLEntry variable references

This code:
GLEntry.SETCURRENTKEY("G/L Account No.","Posting Date");
GLEntry.SETRANGE(GLEntry."G/L Account No.",'1110');
GLEntry.SETRANGE(GLEntry."Posting
Date",DMY2DATE(1,1,2007),DMY2DATE(15,12,2007));
GLEntry.CALCSUMS(Amount);
Should be changed to:
GLEntry.SETCURRENTKEY("G/L Account No.","Posting Date");
GLEntry.SETRANGE("G/L Account No.",'1110');
GLEntry.SETRANGE("Posting  Date",DMY2DATE(1,1,2007),DMY2DATE(15,12,2007));
GLEntry.CALCSUMS(Amount);

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7a26e11d-7017-52d3-3189-714153e3705f
Version Independent ID: 6205913f-580d-e800-233b-98ed9091ce72
Content: SIFT and SQL Server - Dynamics NAV
Content Source: dynamics-nav/SIFT-and-SQL-Server.md
Product: dynamics-nav-2018
GitHub Login: @KennieNP
Microsoft Alias: kepontop

Thanks for the feedback! The example has been adjusted and the update will be available soon.


Default date timezone not consistent

When trying to parse time without date specified, returned date is inconsistent in different formats.
My computer date is set to: 2019.08.02 01:10 Timezone +2. It means that locally it is 2nd of August and in UTC it is 1st of August.
>>> dateparser.parse('10:10')
datetime.datetime(2019, 9, 1, 10, 10)
>>> dateparser.parse('today 10:10')
datetime.datetime(2019, 9, 2, 10, 10)

Notice that first parsed date have day in utc time and second in local time.
I believe local time zone should be used by default with option to pass timezone that user want to use.

>>> dateparser.parse('10:10')
datetime.datetime(2019, 12, 12, 10, 10)
>>> dateparser.parse('today 10:10')
datetime.datetime(2019, 12, 12, 10, 10)
>>> dateparser.__version__
'0.7.2'

Did you set up system time correctly? Because the issue is only present if your local date is different than UTC date.
At 0.7.2 I still get the bug
`>>> dateparser.parse('10:10')
datetime.datetime(2019, 12, 11, 10, 10)

dateparser.parse('today 10:10')
datetime.datetime(2019, 12, 12, 10, 10)`

I’m at UTC+1 at the moment:
>>> datetime.now()
datetime.datetime(2019, 12, 12, 14, 35, 54, 628271)
>>> datetime.utcnow()
datetime.datetime(2019, 12, 12, 13, 35, 58, 60252)
>>> dateparser.parse('10:10')
datetime.datetime(2019, 12, 12, 10, 10)
>>> dateparser.parse('today 10:10')
datetime.datetime(2019, 12, 12, 10, 10)

So there must be some other explanation.

Ok, the issue with your test is that date in UTC and locally is the same. If you are UTC+1 change time on your PC to 00:30 (30 minutes after midnight). That way locally it will be 12 of December and UTC will be 11 of December. Then do the same test.

Related to this: https://github.com/scrapinghub/dateparser/issues/307