text:
Split runtime so version are individually typed + add missing count to Authorization

Description

Refactored the runtime api to make it more similar to the approach taken by the Polkadot api. see this as a reference example
added missing count parameter to the Authorization type

Breaking Changes
none
JIRA Link
N/A
Checklist

[ ] Updated the Readme.md (if required) ? N/A

:tada: This PR is included in version 5.12.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: F-OBrien prashantasdeveloper

repo: PolymeshAssociation/polymesh-types


text:
handleClickOutside is called when clicked inside

I've been using react-onclickoutside for quite a while throughout the project, however in one particular case it glitches and calls handleClickOutside() when I click somewhere inside the wrapped component.
Here is a screenshot of React dev-tools. There is an expanded click event in the console window, which triggered an "outside" event and the target of this event is the wrapped element.

I've tried to debug this myself, but this led me to nowhere.

hm, a minimal PoC would be kind of necessary here. No luck at all reducing?

I tried reducing outside of the project, but no luck. As soon as I have a PoC I link it to the issue.
If you don't want having hanging issues, you can close this one for now, we can reopen then.

hanging issues are cool, if someone else runs into the same problem and they have a PoC that works then there's a place for them to tack it on and everyone interested in solving it will get the notice =)

I had a similar issue with one of my components and it was caused by the component returning null under specific circumstances (the component could be shown or hidden). I was able work around the issue by not returning null in the render method and setting the display property to none instead.

@kiejo awesome! I absolutely forgot about this part in trying to reduce. This component was rendering null in some cases.

Good to hear you found a solution, although it feels like a stop-gap measure at best:
Using CSS to control the UI is the opposite of what a "Reacty" solution should be: you really should be returning null in your UI code because React doesn't actually care about the exact render engine; your users should see what your render() chain generates, so relying on CSS to "hide" something is making your UI explicitly tied to the DOM, which React is supposed to actually make irrelevant.
(following React's "if it's not in the UI, don't generate it" philosophy. CSS is for styling what you can see, not for hiding what you shouldn't - any data that you "would lose by removing that UI" is just component state, and isn't lost in the slightest if you do stateful components right; rendering them instead of returning null at some later point should immediately render that part of your UI with the state preserved and presented correctly to the user)

Good to hear you found a solution, although it feels like a stop-gap measure at best, because it hacks around how UIs are supposed to work in React.

I agree and the intent of my comment was to provide a workaround and to help find out what the actual underlying issue is. The library should definitely not force users to change their CSS just to make the library work. So this issue still needs to be solved.

Using CSS to control the UI is the opposite of what a "Reacty" solution should be.

I also agree that in most cases React is being used in the wrong way if CSS is used to control which components to render. Nevertheless, I think there are specific cases in the context of React where hiding components using CSS instead of returning null can be a better option. Here is what Ben Alpert from the React team has to say about this topic:

In most cases it's better to not render the field at all, so that React doesn't need to consider it and no DOM nodes are created. (If you're frequently toggling between a field being shown or not, hiding it temporarily can be a better option so that it doesn't need to be recreated constantly,...).

https://discuss.reactjs.org/t/conditional-rendering-or-toggling-hidden-classes/2535

Yeah, good thread - though it's important to note that "frequently" basically means "several times a second". The cost of DOM node insertion is substantial, but not so substantial as to create a sluggish UI (at least not on modern browsers, not even mobile ones, provided we're talking IOS8+, android 6+, etc)

I had a similar issue, and tried writing a minimal PoC.
https://jsfiddle.net/xkgwuxhb/4/

Porting code from @yzgw's example over for analysis here:
const Popup = onClickOutside((props) => {
	if (props.hidden === true) {
		return null;
	}
	return
toolbox
;
});

class Widget extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      showToolbox: false
    };
  }
  render() {
    return (

	      <button onClick={this.showToolbox}>show toolbox</button>
        <Popup hidden={!this.state.showToolbox} handleClickOutside={this.hideToolbox} />

workspace

    );
	}
  showToolbox = (event) => {
    console.log("showToolbox");
  	this.setState({
    	showToolbox: true
    });
  };
  hideToolbox = (event) => {
    console.log("hideToolTools");
  	this.setState({
  		showToolbox: false
  	});
  };
}

ReactDOM.render(<Widget />, document.getElementById("container"));

further reduced example still showing this bug:
class BasePopup extends React.Component {
  constructor(props) {
    super(props);
  }
	render(props) {
    return this.props.hidden? null :
toolbox
;
	}
  handleClickOutside(evt) {
	  this.props.hide();
	}
}

const Popup = onClickOutside(BasePopup);

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      hideToolbox: true
    }
  }
  render() {
		return (

	      <button onClick={e => this.show(e)}>show toolbox</button>
        <Popup hidden={this.state.hideToolbox} hide={e => this.hide(e)} />

    );
	}
  show(event) {
  	this.setState({ hideToolbox: false });
  }
  hide(event) {
  	this.setState({ hideToolbox: true });
  }
}

ReactDOM.render(<App/>, document.getElementById("app"));

Analysis shows that the type of code provided by @yzgw fails due to not having an initial DOM node to hook into. By returning null in the render function when the component is first mounted, the HOC's componentDidMount handler cannot actually find a DOM node to use as reference node for the chain of elements inside of which an event is triggered.
The solution to this problem is to not make the component responsible for rendering itself as null, but to make the parent responsible for rendering the component at all. In this particular case, Popup should simply always render itself in the assumption it is visible, and Widget/App is responsible for deciding whether or not to even show the Popup at all.
A most-minimally rewritten jsbin showing this working just fine: https://jsfiddle.net/jkjnwhys/
A code example:
const Popup = onClickOutside((props) => {
  // if a render call occurs, the implication is that this component is visible.
  return
toolbox
;
});

class Widget extends React.Component {
  ...
  render() {
    // here we decide whether or not the Popup component should be seen by our user or not.
    return (

         <button onClick={this.showToolbox}>show toolbox</button>
        { !this.state.showToolbox ? null : <Popup handleClickOutside={this.hideToolbox} />}

workspace

    },
    ...
}

this issue has been addressed in v5.8.0 both in code, in console log warnings, and in a documentation update to the README.md

Hey, i seem to be having the same issue, but my component is (or atleast should not be) returning null, im trying to make a jsfiddle to encapsulate the issue, but cannot, also the link to the readme that you mention no longer works. do you have ny pointers that might guide me on my quest?

What version of the library do you use?

Im using 6.5.0

Your version shouldnt suffer from the mentioned problem with rendering null. This got fixed and that's why that link to the README isnt working anymore - the note got removed as outdated.
Could you recreate ur issue on something like codesandbox.io or share your repository so I could test it on the live code? Also please describe your issue in more details - beyond "i seem to be having the same issue", because that is not specific enough and in fact the issue might be different for you.

source: gharchive/issue

authors: Andarist Pomax kiejo kuzzmi vjustov yzgw

repo: Pomax/react-onclickoutside

license: MIT

license_type: permissive

license_source: github-api


text:
conditional preventDefault

when user clicks a button outside the current panel, a confirmation dialog will appear, if the user click yes, it should trigger the default action of this button click, otherwise stay where it is.
The current code only notify it is being click outside without triggering button default behavior

please include some code (reduced to minimal form) to show off this problem.

authors: Pomax ysFraedom


text:
Set $lib property on events sent

Customer request: https://posthog.slack.com/archives/C02G72Y6E9H/p1633004561010400
Not sure how to best test/deploy this, support @Twixes ?

I just did the same thing ha! For segment you just need to do things in their interface which I just did.

Ack, gonna let you guys handle it!

@Twixes @timgl what's the latest on this? Was a version with this fix uploaded already or...?

@Twixes So turns out you have to set up a meeting with segment during which they take your integration offline for new people(!) and then you can make the necessary changes. I'll try to schedule this with them.

source: gharchive/pull-request

authors: macobo timgl

repo: PostHog/posthog-segment


text:
simpleblob to v0.2.6

simpleblob to v0.2.6 (and run go mod tidy)
Introduces use of Content-MD5 header in S3 uploads in order to ensure end-to-end integrity.
See #65

Forgot to update lighningstream docs for the new disable_send_content_md5 config option. Will re-submit PR

repo: PowerDNS/lightningstream


text:
PowerShell-7.0.2.win-arm64.msix Fails to Install

The msix for ARM64 (PowerShell-7.0.2.win-arm64.msix) will not install on Windows ARM64 Device. Not sure if anyone else has this issue. I am using OS from fast ring.  Error I see when install is: 'This app package is not supported for installation by App Installer because it uses certain restricted capabilities.'

The MSIX installer must currently be installed via Add-AppXPackage -Path $msixPath from an administrative PowerShell session. 🙂

I just need to run Add-AppXPackage -Path PowerShell-7.0.2.win-arm64.msix  Or is there some other installer that I need?
Richard Meadows
From: vexx32mailto:notifications@github.com
Sent: Monday, June 15, 2020 9:05 AM
To: PowerShell/PowerShellmailto:PowerShell@noreply.github.com
Cc: Richard Meadowsmailto:richard_meadows_7@msn.com; Authormailto:author@noreply.github.com
Subject: Re: [PowerShell/PowerShell] PowerShell-7.0.2.win-arm64.msix Fails to Install (#12966)
The MSIX installer must currently be installed via Add-AppXPackage -Path $msixPath from an administrative PowerShell session. 🙂
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/PowerShell/issues/12966#issuecomment-644225558, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AI5HOOGCQGBGV5N37VP7MVLRWZBD3ANCNFSM4N6H34CA.

If you want to use the MSIX, yeah that should work as far as I'm aware. 🙂
If you prefer, you can also grab the regular MSI installer which is a little easier to work with. ^^

I have tested with Add-AppxPackage and it seemed to work. If it does not please let me know. Please also include the OS version details.

That worked.   Thank you.
Richard Meadows
From: Aditya Patwardhanmailto:notifications@github.com
Sent: Monday, June 15, 2020 11:49 AM
To: PowerShell/PowerShellmailto:PowerShell@noreply.github.com
Cc: Richard Meadowsmailto:richard_meadows_7@msn.com; Authormailto:author@noreply.github.com
Subject: Re: [PowerShell/PowerShell] PowerShell-7.0.2.win-arm64.msix Fails to Install (#12966)
I have tested with Add-AppxPackage and it seemed to work. If it does not please let me know. Please also include the OS version details.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/PowerShell/issues/12966#issuecomment-644313603, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AI5HOOCWCBYPFONR5ZJRQXDRWZUMHANCNFSM4N6H34CA.

Thanks for confirming. Closing the issue.

repo: PowerShell/PowerShell


text:
"Unable to modify the shortcut"

Steps to reproduce
Right-click title bar of PowerShell 7.1.2 (or any 7.x.x version) and choose Properties.  Make any number of changes in any of the tabs, then click OK.
Expected behavior
The expectation is that these settings would be saved.
Actual behavior
An error occurs:
---------------------------
Error Updating Shortcut
---------------------------
Unable to modify the shortcut:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PowerShell\PowerShell 7 (x64).lnk.
Check to make sure it has not been deleted or renamed.
---------------------------
OK
---------------------------

I have seen solutions around the internet which involve steps like creating a new shortcut to the existing shortcut, yada yada (stuff that shouldn't be necessary).
Environment data
>$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.2
PSEdition                      Core
GitCommitId                    7.1.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Still exists in latest release.

PowerShell msi is installed on system, not user. It is how MSI works. The shortcut is protected by OS permissions.
You can create a custom shortcut and modify its properties.

It is hideous, regardless of if it is MSI's fault.  Someday, this will be realized and the issue will be addressed somehow.  Maybe I'm wrong, certainly seems like this issue is pretty specific to PowerShell, just can't think of another program to compare with because, nothing else needs to modify the shortcut to save these kinds of basic preferences.
So sick of that answer.  It's a garbage feature, period.  Windows terminal addresses this by taking over for it in this area.  That alone is enough to point out it could be addressed some other way, rather than blaming MSI.

If you use personal device you can change manually permissions on the shortcut file.

If you use personal device you can change manually permissions on the shortcut file.

It is an personal pc and it still doesn't let me create a shortcut that it recognize to be edited

Didn't realize @iSazonov teed this up for closure.  Great.  Oh well, moving on again.  Someday... It maybe Microsoft will just revive Windows PowerShell again and fix things there.

PowerShell msi is installed on system, not user. It is how MSI works. The shortcut is protected by OS permissions. You can create a custom shortcut and modify its properties.

I had this general problem too.
Thank you for the tip @iSazonov, it can be used as a temporary workaround.

Another workaround:

Drag and drop (copy) the shortcut from %ProgramData%\Microsoft\Windows\Start Menu\Programs\PowerShell to some place that does not require admin to edit stuff.

I chose target %USERPROFILE%\Desktop.

Edit the shortcut, I wanted to change font and did it from right click -> properties -> font.
Drag and drop while holding SHIFT (overwrite) your modified shortcut from  %USERPROFILE%\Desktop back to %ProgramData%\Microsoft\Windows\Start Menu\Programs\PowerShell.

Will ask for admin permissions.

authors: JeremyTBradshaw ZeldrexK0DE anton-x-t iSazonov o-l-a-v


text:
Powershell 5.1 not accepting keyboard input when using the Remote Resktop HTLM5 Web Client

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Install the latest RDS HTML5 client on a RDS deployment as specified here: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin

Open a web browser session and start an RDS session.
Start powershell
keyboard input not working
start Powershell ISE
keyboard input works fine

The only key input that is accepted is the enter key or Ctrl+ combinations.
Expected behavior
test

Actual behavior
nothing happens

Error details
No response
Environment data
Name                           Value
----                           -----
PSVersion                      5.1.20348.1366
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.1366
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Visuals
No response

@brolifen this repo is not for PowerShell 5.1 related issues so is very unlikely to get any traction from the team at all & as such I believe this is an issue that should be submitted to the Windows Server Team instead as it is an issue with RDS

authors: brolifen kilasuit


text:
Replace powershell.version by code gen

Make $PSVersionTable semantic friendly and replace powershell.version file by code generation

Currently we don't use th file.

authors: iSazonov vors


text:
WIP: Add support for Cert:\Service certificates

PR Summary
Add support for managing service certificate stores using the Cert:\Service$serviceName$storeName syntax. This expands on the existing set of locations CurrentUser and LocalMachine and also sets up the code to support future store locations like User.
PR Context
Windows supports certificates to be stored in a service context which can be used by services like NTDS to store a certificate used for LDAPS. Currently the Cert provider only supports the CurrentUser and LocalMachine locations and dotnet does not offer a managed way to open any other locations. This adds the capability to manage stores for another service under Cert:\Service\$serviceName, for example Get-ChildItem -Path Cert:\Service\NTDS\My will enumerate all the certificates in the Personal\My store for the NTDS service.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

This still needs tests and some doc updates. I prefer not to work on this unless I know the PowerShell team is at all interested in the changes here. If not I won't spend any more time on it.

@jborean93 I've asked the Engines WG to make a call

I personally like this and ready to review.
/cc @SteveL-MSFT

I think it's a great enhancement for the certificate provider, and we should take this one.

Cmdlet-WG will be reviewing this (and others) on Wed

Docs PR for this new feature https://github.com/MicrosoftDocs/PowerShell-Docs/pull/9932. This should be ready for a proper review now.

@adityapatwardhan I've fixed up the CodeFactor errors.

@jborean93 May I ask why you decided to close this PR? This feels like a good enhancement in my opinion.

In fact, the Engine WG talked about this PR in the meeting of 3/20/2023, but I forgot to post a comment for the conclusion. I apologize that. The Engine WG agreed that we should accept this PR.

Ping on this one, I've addressed as much as I can on the last review so wanting to try and progress this one some more.

can you make this an experimental feature?

I understand the suggestion to designate this as an experimental feature, but I'm not fully convinced of its necessity at this stage. Currently, the new feature operates on an opt-in basis, simply by adding an extra directory entry in the provider path. Introducing it as an experimental feature might inadvertently make it harder for users to discover. Additionally, it could potentially complicate the codebase, requiring various conditional statements to manage support for the feature across different areas it affects.
From a developer's standpoint, I've encountered challenges with implementing experimental features in the past, particularly concerning documentation and testing procedures. It's been a somewhat frustrating experience, as each pull request seems to handle things slightly differently. Perhaps we could spend some time outside of this PR to explore improving the documentation and general workflow when it comes to experimental features. This will help not just myself but developer's and also give maintainers a nice easy way to request new features be implemented as an experimental feature.

@jborean93 Please add "formal" excremental feature const for the feature.
@SteveL-MSFT Have you already fork release branch? If so I suggest to merge PR with formal  excremental feature. (It's unnecessarily difficult to really isolate the new code.)

Just making sure that was a typo for experimental and not some other concept I haven't heard off.
I'm not sure I'm willing to make the changes to do so, it'll be a lot of work and end up making the code even harder to understand. I also don't really have the drive to dig through the code once again to try and separate it out with the numerous runtime checks that would be required. If an experimental feature is needed to merge this in that's perfectly fine, I just need to know whether to keep this open or close it.

@jborean93 I corrected the typo.
I'm not suggesting splitting the code. I only suggest adding a new name to the list of experimental features.

I'm not suggesting splitting the code. I only suggest adding a new name to the list of experimental features.

Not sure what you mean by this sorry? Adding a new name to me sounds like adding the new feature under an experimental flag which essentially means splitting the logic to handle the pre and post change state.

authors: SteveL-MSFT daxian-dbw iSazonov jborean93


text:
Update format-hex tests to include -TestCase parameter

Addressing issue #3382 'Use -TestCases parameter in FormatHex.Tests.ps1'.

Replaced the 'foreach' with the -TestCases parameter in the test helper functions.

@MiaRomero - the assignee of a PR is the person responsible for merging to master - and only maintainers can do that merge. We assign issues to regular contributors, but not the PR.

@JamesWTruher or @Francisco-Gamino - Do you guys have any other concerns or comments?

@miaromero - We need to add you to the Microsoft organization. I just noticed that you are not a member yet.

@JamesWTruher fixed the >1 issue.   The way it was before was not actually testing the contents of the second file so when I corrected it, those tests failed because the output was on two lines.  I changed the input text to avoid the hassle of having two lines of output in the second expected result (then had to create a file with longer text to test the buffer underrun).

Thanks @adityapatwardhan for the comments - fixed all the Match to MatchExactly.

authors: MiaRomero lzybkr mirichmo


text:
PowershellStandard 7?

Powershell Standard 7.0.0 Preview was pushed to Nuget 5 days ago, but there are no related commits here. Has this open source development been moved or abandoned? What's the deal?
https://www.nuget.org/packages/PowerShellStandard.Library/7.0.0-preview.1
@joeyaiello @rjmholt @TylerLeonhardt

@JamesWTruher @SteveL-MSFT

@JustinGrote just running a bit behind, it's there now. I've merged the branch that was used to release the preview.

authors: JamesWTruher JustinGrote rjmholt

repo: PowerShell/PowerShellStandard


text:
xCluster: Race condition with xWaitForCluster

Details of the scenario you tried and the problem that is occurring
This is the expected way of doing things which usually works:

xCluster on first node
xCluster DependsOn xWaitForCluster on all other nodes

I'm building 1+4 node clusters (all in one subnet) and in these configurations with a lot of nodes a race condition occurs where xWaitForCluster believes the cluster is ready but xCluster will fail randomly during Test-Resource with a "The name used to access the cluster is not currently available" message.
So the create works, and one or two add nodes will pass, and the rest will fail. This is rectified about 10-15 minutes when DSC re-runs the configuration but that's as long again as building the entire lab.
I can only imagine there is a short window where the cluster exists but the add to node isn't functional just yet. I replaced xWaitForCluster with WaitForAll on the first node's cluster - this seemed to work more reliably for single-subnets but for multi-subnets (which might briefly take the cluster offline when you add the subnet) it can also fail.
Suggested solution to the issue
What would you think about adding a RetryIntervalSec defaulting to 10 and RetryCount defaulting to 0 on the xCluster resource? This can attempt to retry whatever operation it is doing in case of a transient failure like it flipping on and off during other node's operations, avoids throwing transient errors to the DSC logs and waiting for the entire process to re-run.
The operating system the target node is running
Windows Server 2012
Version and build of PowerShell the target node is running
WMF 5.1
Version of the DSC module that was used ('dev' if using current dev branch)
dev

Yes, that sounds like it could work. But I think we could leave out the default value of those two new parameters, and only do the retry test if either of those are in PSBoundParameters. If either of them are not assigned, an error can be thrown indicating that both must be set. Or if either are not wet hen we could set it to a default value (in the code, and not on the parameter).
I think, if a parameter is not used in a configuration we should avoid having it set to a default value. 🤔

authors: codykonior johlju

repo: PowerShell/xFailOverCluster

license: mit

license_source: bigquery


text:
Transparent pixels count as good pixels

Problem:
Transparent pixels count as good pixels.
Thus, models with a lot of transparent pixels appear to be half finished, when in reality, its almost erased.
Normal behavior:
Transparent pixels should not be counted as good or bad pixels, just ignored in the pixel count.

I unfortunately can't compile the project on my computer despite having installed Visual Studio 2019 with a version higher than 16.0.30804.86 (as stated on PxCT.sln), and .net5 (as stated on PxCT.csproj).
I also tried a bit with Visual Studio Code without success.
I also never did C#, so it's not easy to debug.
Anyway, from the code reading, I understod that you made a typo in "MainViewModel.cs", line 473.
You indeed count the total pixel number in "pixelCount", and you check for the transparency in order not to include the transparent pixels in the count (and that's exactly what should be done).
The only problem is that you use the canvas itself as a source "currentColorId" (which never have any transparent pixels) instead of the template "targetColorId".
So, I think changing line 473 from
                    pixelCount += currentColorId != -1 ? 1 : 0;
to
                    pixelCount += targetColorId != -1 ? 1 : 0;
should solve the issue.
What do you think?

repo: Pownylover/PxCT


text:
LooperThreadTest.testDefaultUncaughtExceptionHandler failing

Exceptions in a LooperThread don't seem to be falling through to the default UncaughtExceptionHandler as expected. This failure happens at https://github.com/Pr0methean/BetterRandom/blob/9a4f3a1e1f8a5bf8e88cbcd3b1e62b29ba31fd4c/betterrandom/src/test/java/io/github/pr0methean/betterrandom/util/LooperThreadTest.java#L147 when that test case is enabled.

Fix released in 1.0.1.


text:
Refactor to extract hard coded dom selectors to config variable

Description
Since the google change its selector classNames from time to time to avoid scraping. The hard coded selectors are extracted to be passed as an env variable which can be configured and passed as time of execution with appropriate values.
Tasks Done

Extract the selectors to configurable env variable

Issue Covered
#4

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

repo: Prabeshpd/web-scraper-script


text:
Shouldn't swap branch after deliver

When we run a deliverwe're immediately taken to the default integration branch

The expected behaviour is more that we stay on the branch - I know it's renamed, but never the less -I would rather stay on it.
Setting me back to the integration branch makes me loose te files I just edited - and if I have jekyll or sass running in watch mode - it start rebuilding again.
I know @JKrag shares my opinion on this one.

I agree that this is also the behavior I want in the end. It will also make git phlow web take me to the current issues, so I for example can see that issue being closed properly and click on my commit.
So when I run git phlow deliver of any kind, I want to stay on the renamed delivered branch.
That way of working also support our fast feedback loop, where I just need to grab a cup of coffee while the integration process run, and then it is verified or deployed. So when I start my next task with workon and the integration branch is updated before merging I get that feature I just delivered.
I would be odd to be taken immediately to the integration branch where my feature isn't found yet.

I disagree. I would expect git phlow deliver to take me back to the integration branch. Because then I am ready to type my next git phlow workon command.

@martinmosegaard and you realize the taking you back to the integration branch will reset your code changes back to something before your changes? Also that if you have a debugger or say jekyll process running it will rebuild?
No matter if you are on the integration branch or stays on the delivered branch, you're ready to do the next git phlow work at any time.
So you still disagree? Isn't it just a matter of taste?

Regarding resetting the code changes: I assume they have been delivered (pushed to remote) so I can forget about them.
Regarding debugger/jekyll, that has not been a use case for me, but conceptually, I would still start a new debugging session. Because I am done with the previous issue and ready to work on the next issue, so I no longer need to debug anything related to the previous issue.
Regarding your last point, I thought it was best to do git phlow workon from the integration branch. As I understood it, the ideal is to always branch off from the integration branch (not from another feature branch)?
If I depend on my previous issue, the PIP integration should put in on master within a couple of minutes anyway. I can probably use that time to think about the next issue to work on.
Still, it could be a matter of taste :)

we can make this a flag in stead? eg. git phlow deliver --local --stay for staying on the delivery branch?

This has many different consequences and sets of scenarios.
Where can I find the user stories or the spec that we are trying to implement?
Which branch you work on your next task on has consequences for the following scenarios:

Successful integration with more than one commit squashed
Failed integration
Will end up in different scenarios depending on what the merge strategy is on the ci server

Basically my point is that this will not only have workflow consequences it will also have history consequences.
This also corresponds to the are we trying to say "You only need these five commands to work efficiently" or are we trying to supplement already Git skilled people.
What branch you are on after delivering and doing workon has big impact on how to resolve the rainy-day scenarios.
If we suppose that I'm isolating my work on a feature branch, feature branch on top of feature branch should not be wanted. Also what happens if I try to deliver on a feature branch of a feature branch, after having the first feature branch integrated. Might give a nasty rebase :)

@RandomSort Our thought was that staying on the delivered branch should make it less confusing for the user (as it prevents all the users nice work from disappearing in front of their eyes).
workon would still create new branches from [master] as always, so we are not suggesting "feature branch off of a feature branch" cases.
@groenborg and I have just brainstormed a new feature (coming as a new issue later today) that would support something like git phlow workon <xyz> --wait. This would stay here on your previous work, and wait for your delivered changes to arrive on master before creating a branch for the next issue. In this way you could continue editing your live blog immediately. (yes, this issue might need some grooming and POC, but lets take that discussion on the upcoming issue).

@martinmosegaard It is not so much about debugging, but about
a) automatic rebuilding of my entire project because my files change when i deliver, and
b) my changes are gone, so I can not continue work based on these. Lets say issue 13: create a new function and issue 14: use this new function. The moment I deliver 13, the function will be gone, and I have to wait for it to "come back". This is very annoying, also for live blogging and frequent sharing during report writing.

But if it bases the workbranch on master then your changes Will still
"disappear"?
Den 24. nov. 2017 3.24 PM skrev "Simon Grønborg" notifications@github.com:

It would make sense to change the default behaviour of git phlow, so it
does not change workspace whenever you run deliver. Given how workon
works (creating a branch from origin/master), it does not make any
difference in terms of how git behaves because the branch you are on have
no effect on the workspace you create. It imply boils down to the user
experience.
in @lakruzz https://github.com/lakruzz case and @JKrag
https://github.com/jkrag case where they use the workflow for blogging
and Jekyll related work, it is a bad experience because Jekyll recompiles
😞, for my work it can be a irritating because I do not get to continue
my work which in fact is possible given the non-disruptive behaviour of
workon.
In edge cases it can make sense to change branch, but that would be case
where the delivered changes are non-continuous.
Therefore I will conclude that we will solve this problem by using a
--home flag that will take the user home if they want to wait to update
their own master branch with the integrated changes from GitHub.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Praqma/git-phlow/issues/264#issuecomment-346839402,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjjq5PNPviMfwH1Qb0VyNM5iveDrSwUks5s5tGQgaJpZM4P7orH
.

@RandomSort That depends a lot on when you do the workon. You can continue reading your code/text for a few minutes (without rebuild) and then do the workon when the changes have been integrated. As far as I can judge, you could even start working, making local changes, before you do workon to create the new feature branch. This might have to require a temporary stash-unstash, but that could easily be incorporated in the tool. My favourite git up extention for instance does this  every single time a update.
Also have a look at #286 and #285 which would potentially enable you to do a blocking wait for the changes, all while still keeping your workspace intact to avoid confusion and rebuild.

Thanks for all the input - issue is on hold until we have defined how we actually want our phlow to work.

I will make the decision that we do not switch branch.. The way the tool works makes it that solution work really well.

@groenborg you're not going to implement this issue... you added labels It is not in scope.

authors: JKrag RandomSort buep groenborg lakruzz martinmosegaard

repo: Praqma/git-phlow


text:
Number 0 is rendered as blank for 'html' column type

While binding data to the table, number 0 is not rendered on the table for <px-data-table-column  type="html">  It's displayed as a blank space. As a temporary work around, I had to bind the number as a string, with which sorting became an issue. I wanted the column to be html type specifically. Please fix it.

Fixed in v2.1.4

authors: randyaskin sachinkantipudi

repo: PredixDev/px-data-table


text:
Corrected the spliced index in _removeFile

This is to fix an issue with the _removeFile() function in v1.2.3 with the following actual/expected behavior:
Actual Behavior:

With four items uploaded into the px-file-upload, clicking the X icon on the third removed the first in the list.
With six items uploaded, clicking the X icon on the final item in the list removed the first one.

Expected Behavior:

When multiple files are uploaded and the X icon is clicked, the file corresponding to that X icon is removed. E.g. if you click the X for the third file in the list, it removes the third file.

The fix was to get the index from e.model.__data__ when splicing the files array, so that the expected index is removed.

Thanks for the PR, Mike. I've fixed this in v1.2.5 in a slightly different way by using the Polymer API for event retargeting. Good catch.

repo: PredixDev/px-file-upload


text:
Error configuring base job template

Configuring base job template with this command (source) is throwing errors in the latest version of prefect-worker:
helm install prefect-worker prefect/prefect-worker -f values.yaml --set-file worker.config.baseJobTemplate=base-job-template.json
Error: INSTALLATION FAILED: values don't meet the specifications of the schema(s) in the following chart(s): prefect-worker: - worker.config.baseJobTemplate: Invalid type. Expected: object, given: string
The command works for version 2024.4.4201250

hey @cchentola - thanks for raising this issue!
Apologies, there was an update to our values schema, where we nested the user-provided baseJobTemplate into an additional baseJobTemplate.configuration key after https://github.com/PrefectHQ/prefect-helm/pull/340, but did not update the docs accordingly
I've opened this PR to reflect this change here: https://github.com/PrefectHQ/prefect-helm/pull/368
to move past this, you can update your command line arg like so:
helm install prefect-worker prefect/prefect-worker -f values.yaml \
  --set-file worker.config.baseJobTemplate.configuration=base-job-template.json

Thanks for looking into this!

authors: cchentola parkedwards

repo: PrefectHQ/prefect-helm


text:
All notifications disabled in BO

When same notifications are enabled in BO (Advanced parameters > Admin > Notifications) and in the module, there are no problems because the notification of the module disappear when I click on the notification bell in BO.
Consider that I just want notifications for new customers and don't want the notification bell displayed in BO. I disable all notifications in Advanced parameters > Admin and keep enable only notifications for new customers in the module.
But notifications will never be reseted and will continue to increase because I can't click on the bell.
The solution I see will be to delete the notification when I go to the page (customers, messages, orders) in BO
To be confirmed by Alex.D
ping @clementdaubeuf

Fixed by #6


text:
insertion data export revisions

added a deploy note about importing updated manifests to get corrected page labels from figgy
order canvases by item and label so that insertions within a work will group together

questions:

All book type values are book because only books can have insertions. Drop the field and note in the dataset readme?
the id field doesn't really look like an id to me; what if we call it label? (do we need an id?)

Codecov Report

Merging #282 (bdcc067) into develop (abc7523) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop     #282   +/-   ##
========================================
  Coverage    96.08%   96.08%
========================================
  Files           99       99
  Lines         5290     5290
========================================
  Hits          5083     5083
  Misses         207      207

I was just eyeballing the column and missed the journal article. I'll leave it.
Agree an id would be useful, will figure out something I can use.

Wait! we need to exclude pk 243.

authors: codecov-commenter kmcelwee rlskoeser

repo: Princeton-CDH/derrida-django


text:
Added protocol load class, command, tests, and initial usage

Summary Change Description
Added ProtocolLoader utility class, primarily for loading Animal Treatments defined in the animal and sample template file.
Logic is similar to Tissue Loader, but does not use a separate command, but rather was integrated into the existing animal/sample loading command.
I left off the multi_working tag, because I did not think it was currently relevant, but let me know if it is required.
Affected Issue Numbers

Resolves #523

Code Review Notes

Uncertain what would happen if the template is munged, missing that sheet, lacks any rows, etc.
It uses the similar pattern as tissue loading, which has an additional layer/database for validation, which I don't really know if strictly necessary or advisable.
Also copies some "space"/"tab" conditional logic for the name that the tissues loader was using, that I don't really understand the basis of, but I left it in case it was potentially important.
Because of the way protocols/treatments are loaded, first-come/first serve preferentially, you might have to re-order the loading of studies to get the "right" protocol description loaded first.  Either that, or edit all the data files.

There are probably 2 ways to test this:
1. ./manage.py load_animals_and_samples --animal-and-sample-table-filename tracebase-rabinowitz-data/serine-glycine-free-glucose-infusion/animals_samples_treatments.xlsx --skip-researcher-check or any animal and sample xlsx that contains a Treatments worksheet as of c420e0a , that functionality was reverted
2. python manage.py load_study STUDY_LOADING.YAML , where STUDY_LOADING.YAML contains a protocols key with a value of a file path to an animal and sample xlsx that contains a Treatments worksheet or a generic TSV-file containing protocols (name, category, description)
3. python manage.py load_protocols --protocols=FILE , or where file is a animal and sample xlsx that contains a Treatments worksheet or a generic TSV-file containing protocols (name, category, description)
Outstanding Issues
NOTE: an executive decision probably needs to be made regarding the following code (keep or discard this historical functionality/assumptions of auto-insertion of name-only animal treatments)
https://github.com/Princeton-LSI-ResearchComputing/tracebase/blob/def86001ba1358bdb2c3bdd21806f3012730a50f/DataRepo/utils/sample_table_loader.py#L305-L327
UPDATE: It was decided to remove that logic.  Protocols must already be in the database, before loading animals/samples.
FURTHER: an executive decision probably needs to be made on the mechanism of updating the auto-generated descriptions of treatments (historically produced by the aforementioned code), either by the command script (with an additional/optional argument), or if the plan is to always drop the database and re-load with new data (including a pre-load of "fixed" protocols.tsv [same name, updated description]).
UPDATE: It was decided to not update protocol's description, after the fact. (via this code, anyway)
TESTING META:
I could use some assistance with getting some validation/view tests to pass
./manage.py test --tag=protocol_loading_broken
----------------------------------------------------------------------
Ran 9 tests in 24.332s
FAILED (errors=1)
./manage.py test --exclude-tag=protocol_loading_broken --tag=multi_working
----------------------------------------------------------------------
Ran 316 tests in 2699.428s
OK

I think it might be somehow failing on a couple missing "blank" samples, but I have not found the source file, or reason (yet).
Checklist

[x] All issue requirements satisfied (or no linked issues)
[x] Linting passes.
[x] Migrations created & committed (or no model changes)
Tests

[x] Tests implemented (or no code changes)
[x] All multi_working tag tests pass locally
[ ] All example load tests pass (remotely) (or their failures predated and are unrelated to this branch)
[x] @tag("multi_working") added to newly passing test functions/classes (or no newly passing tests)
[ ] @tag("multi_broken"), @tag("multi_unknown"), or @tag("multi_mixed") removed from newly passing test functions/classes (or no newly passing tests)

I think this error was addressed in another PR, and was not added in this PR.

Is this still in draft? I was just about to review and noticed the draft label.

I don't have strong feeling about it.  I think it is fine to looks at review/comment on/ find protocols texts, etc.

Primarily checked in, incase I need to pull it to him over the next couple days (or if someone want to take a look at it)

BTW, the "test dependencies" are a result of the "no longer automatically insert animal treatments" issue tweak

Still trying to find this last test's failure solution, but people can start reviewing

FYI, I'm starting a review of this PR.

I think this is ready to review again, if there is anything that is still blocking.  The Validation tests are the primary stopper, for me, but  perhaps Rob might be better suited to take it from here, with regards to that code.

Removed the incorrect usage of the --database flag, then found that the protocols file being used in the database setup was missing the default msrun protocol that is generated in the accucor load used in the test.  Tests passed locally.  I expect they'll pass on GH as well... Logging off.

@lparsons - I altered my review.  I didn't check if all my non-blocking issues were addressed and choose just to go with John's decision.  I see though that with today's merges, there is a conflict.  I'll take a look and see if I can resolve them.  If I can, I'll push an update.  John's off today.
I think that my changes address your concerns as well, but I'll request your review, in case you want to have a look.

The only conflict appears to have been the removal of protocol view tests.  I think I got that right.  I accepted the change where these were deleted in main:
<<<<<<< HEAD
    def test_protocol_list(self):
        response = self.client.get(reverse("protocol_list"))
        self.assertEqual(response.status_code, 200)
        self.assertTemplateUsed(response, "DataRepo/protocol_list.html")
        self.assertEqual(
            len(response.context["protocol_list"]), self.ALL_PROTOCOLS_COUNT
        )

    def test_protocol_detail(self):
        p1 = Protocol.objects.filter(name="Default").get()
        response = self.client.get(reverse("protocol_detail", args=[p1.id]))
        self.assertEqual(response.status_code, 200)
        self.assertTemplateUsed(response, "DataRepo/protocol_detail.html")
        self.assertEqual(response.context["protocol"].name, "Default")

    def test_protocol_detail_404(self):
        p = Protocol.objects.order_by("id").last()
        response = self.client.get(reverse("protocol_detail", args=[p.id + 1]))
        self.assertEqual(response.status_code, 404)

=======
>>>>>>> main

Is that right, or did I get it backwards?

Well, it seems the merge didn't really work.  There's a linting error about Protocol not being defined.  Might have th un-merge and wait for John to resolve it.

Turns out there is a bit more work to do get this branch working with existing main (it's been branched for about three weeks). I've put my initial attempt in the treatments-loading-merge branch. Will create a PR to merge that into this branch and include a list of issues to resolve.

@jcmatese: @hepcat72 was able to implement his suggestions to fix the test code and I have resolved the conflicts with main. Ball is back in your court... 🏀

Should I merge this then? Is there anything that is a mission critical blocker?

Looking back at the reviews, I see three blocking issues:

"... the presence of the --database option in the initialize_databases method in the view_tests" - @hepcat72
Fix the code so the tests pass (or modify the tests if that is required) - @lparsons
Identify the remaining tasks to ensure that the validation web interface reads the treatments in the same way we would when loading new study data. Create an issue for this. - @lparsons

I believe that 1 and 2 have been resolved, so once we have the tasks to fix the validation interface identified in an issue, I think we're ready to merge.

I believe that 1 and 2 have been resolved, so once we have the tasks to fix the validation interface identified in an issue, I think we're ready to merge.

I think those were all taken care of? [ placeholder issue ]

#577 seems a bit light on details, but if that is sufficient for you, I'm good with us merging this PR and getting started on that issue.

Should I merge this then? Is there anything that is a mission critical blocker?

Looking back at the reviews, I see three blocking issues:

"... the presence of the --database option in the initialize_databases method in the view_tests" - @hepcat72
Fix the code so the tests pass (or modify the tests if that is required) - @lparsons
Identify the remaining tasks to ensure that the validation web interface reads the treatments in the same way we would when loading new study data. Create an issue for this. - @lparsons

I believe that 1 and 2 have been resolved, so once we have the tasks to fix the validation interface identified in an issue, I think we're ready to merge.

If I understand item 3 correctly, it nearly does, but as I think about it, from implementing my suggestions yesterday, the way it's now handled leaves side-effects.  In fact, it might have been wrong"ish" to add protocols the same way tissues and compounds are handled.  The sample-table loader gets/creates treatment protocols and the accucor loader gets/creates msrun protocols (though all I see is the default).  Maintaining protocols in this way does allow us to catch discrepancies (if in fact the loading code checks it - I did not verify this), but I think each validation leaves its additions in the validation database (which I don't think happens with tissues/compounds) so that the next test will be checked against what was added in the previous check.  That's not good.
If to rectify that, we don't pre-load protocols, then we don't get the benefit of checking against existing records...  Perhaps there's a middle-ground, where each test is preceded by a copy from the default DB to the validation DB (or a load of a comprehensive protocols file)?

I would prefer we have the issues worked out before we merge this. I'm open for a discussion after 2 PM today or we can talk on Monday.

#577 seems a bit light on details, but if that is sufficient for you, I'm good with us merging this PR and getting started on that issue.

Yeah, I have not fleshed it out yet, but I will eventually. I with "reference in new issue" was more fully featured.  Like, let me copy/paste from the origin page and apply one of the templates.  And don't leave the current page FGS.

I would prefer we have the issues worked out before we merge this. I'm open for a discussion after 2 PM today or we can talk on Monday.

I haven't tried the page out, but I see no real breaking issue with it the way it is.  The only thing I envision would not be ideal is seeing errors about inconsistent protocols, but even with that, I don't think the sample and accucor loaders even make those checks.  They just blindly get or create.  What is the problem as you see it?

we don't necessarily need to merge it, if people are hesitant or think it is not pressing.  I still have doubts that the nan replacement and strip() are having the desired output on the incoming protocols data frame, but I am trying that now.

What is the problem as you see it?

The problem is that I don't feel like anyone actually knows the implications of this PR on the validation page and what steps will be needed to fix them. Once we merge this, we are committed to either fixing the validation or removing it. Our deadline for this milestone is next week, which we can push a bit if we need, but I don't want to push it too far.

we don't necessarily need to merge it, if people are hesitant or think it is not pressing. I still have doubts that the nan replacement and strip() are having the desired output on the incoming protocols data frame, but I am trying that now.

To me, this signifies that we don't have appropriate tests in place. @jcmatese , can you create a test protocols file and write a few tests that will cover the issues you remain uncertain about?

What is the problem as you see it?

The problem is that I don't feel like anyone actually knows the implications of this PR on the validation page and what steps will be needed to fix them. Once we merge this, we are committed to either fixing the validation or removing it. Our deadline for this milestone is next week, which we can push a bit if we need, but I don't want to push it too far.

I mean, I'm pretty confident in my assessment and the validation page tests pass, but if it makes you feel any better, I can run a few manual validations just to have a look at it on the page.  Is there a specific test case you're concerned would cause a problem?
As I was telling John on slack, the validation page is just a wrapper of the sample and accucor load scripts.  It just reports the errors that come out of those loads to the users.  It makes a couple arbitrary choices about decresing the severity level of certain errors, but every error is always reported.  And the current tests do not show that any new errors are coming out of the tests...

Researchers are expected to submit animal treatments as part of the animal and sample sheets.  Those need to be loaded into the validation database before validating the animals and samples will load. The steps to make that happen should be outlined somewhere. Once they are sufficiently determined, then I think we can move forward. I don't foresee that functionality as being too hard to implement, but I think we should have a good idea of how it will work before we commit something (this PR) that will cause new submissions that should be valid, to fail validation.

To me, this signifies that we don't have appropriate tests in place. @jcmatese , can you create a test protocols file and write a few tests that will cover the issues you remain uncertain about?

I will check in what I was working with, but I don't ahead the code fixes, yet (was just starting when I got distracted by HTSEQ).

Researchers are expected to submit animal treatments as part of the animal and sample sheets. Those need to be loaded into the validation database before validating the animals and samples will load.

OK, having just reviewed the sample table loader code, I see what you mean now.  All the script does is a get and raises an error if it's not there.

The steps to make that happen should be outlined somewhere. Once they are sufficiently determined, then I think we can move forward.

Alright.  The steps are straightforward.  Just run the new protocol loader script in this PR in exactly the same way we load tissues and compounds (i.e. without the --database and without the --validate options).  It will load into both databases by default, which is the desired behavior.  And the treatment load files are all in the PR, correct?

I don't foresee that functionality as being too hard to implement, but I think we should have a good idea of how it will work before we commit something (this PR) that will cause new submissions that should be valid, to fail validation.

The remaining issue is expected novel treatments.  Since there's no run of the protocol load on the submitted sample file, the validation page's run of the sample load would stop at the first novel treatment.

I think those errors should be buffered and reported at the end
The validation wrapper should not handle treatment protocols like tissues and compounds (i.e. treat them as pre-loaded).  This means that it should mimic the sample loader code

self.loading_mode should be removed
There should not be a second call to load_database
The protocol table should not be skipped during the clearing of the validation database

I believe the validation could probably call psuedocode load_protocols(protocols="submitted_animals.xlsx", database="validator"), and assuming pre-existing protocols are already there, and new ones in the sheet would be loaded (but not in production), then that same workbook could attempt the loading of animals and samples in validator, which it presumably already does?

Doing a manual test in the shell, BTW, I see that it does check the consistency WRT name and description, so that's good:
LoadingError: Errors during protocol loading :
 Error in row 3: ["Protocol with name = 'Default' but a different description already exists: Existing description = 'For protocol's full text, please consult Michael Neinast.' New description = 'For protocol's full text, please consult anonymous.'"]

However, given the code that I know is in the accucor loader, it generates an MSRun protocol with the name 'Default' and a description that includes the researcher.  That will be a problem.

However, given the code that I know is in the accucor loader, it generates an MSRun protocol with the name 'Default' and a description that includes the researcher. That will be a problem.

Yah, I mainly focused on the animal treatments, and generic loading of any protocols, but did not touch msrun loading at all.

Scratch that.  I just double-checked.  It uses "protocol_input", which I assume is from the spreadsheet.  I think I was remember debug output from a test, not what's in the code.  So it should be OK.

OK, I'm playing around with the validation page and I do see issues having to do with an operation on the incorrect database (creating links From FCirc to Tracer using records from the different databases).  Should be easy to fix.  Regardless, whichever way we decide to treat protocols in the validation database, I don't think that there exists significant issues WRT this PR.  I do think that we should do as I recommended above though.

authors: hepcat72 jcmatese lparsons


text:
Quick validation database fix

Summary Change Description
This PR does 2 main things to make the validation interface functional on a temporary basis (until issue #580 is implemented):

Put calls to full_clean behind a conditional, so that it only runs on the default database (because without an override of the default database router, it can only be made to run on the default database)
Creates a mixin class with a method named get_using_db that can be used to apply the current database to fresh database queries (see its single current usage in infusate.py)

Note, it also eliminates a stupid try block I previously implemented that probably was a work-around to issues I didn't fully understand at the time.  All it does is remove the top try/except and everything else below it just moves up an indent level.
Affected Issue Numbers

Resolves #579

Code Review Notes
See the description.  Also, you can read more about what I did in this stack post.
Checklist

[x] All issue requirements satisfied (or no linked issues)
[x] Linting passes.
[x] Migrations created & committed (or no model changes)
Tests

[ ] Tests implemented (or no code changes)
[x] All multi_working tag tests pass locally
[x] All example load tests pass (remotely) (or their failures predated and are unrelated to this branch)
[x] @tag("multi_working") added to newly passing test functions/classes (or no newly passing tests)
[x] @tag("multi_broken"), @tag("multi_unknown"), or @tag("multi_mixed") removed from newly passing test functions/classes (or no newly passing tests)

I want to get out of here for trick or treaters and I don't want to wait on the tests, so I'm going to request reviews. If there's a test failure, I'll fix it tomorrow.

OK, they finished. I looked at the test failures. I'll go into draft and fix it tomorrow.  [Note, if my PR is in DRAFT, it means "don't review".  If I take it out of draft, it means it's ready for review. Basically, if the code is changing, reviews are a waste, because it's stale code.]

Ready for review @lparsons @jcmatese @fkang-pu

Alright, not as straightforward as I'd thought.  The merge-in of main has caused test failures on the new code in this branch.  I have a test run going on an edit of this branch to vet the entire concept of this "fix".  This is all the more reason to hide the validation page in #587 until #580 is implemented.


text:
C++ highlighting doesn't handle raw string literal correctly

For example:
std::string Func() {
  return R"raw(
# 0: Thing 0
# 1: Thing 0
)raw";
}

I created a PR #1254 that fixes this issue.

@lshamis Thank you for reporting this issue. It should be fixed now.

repo: PrismJS/prism


text:
Autolinker doesn't match URLs with "@" in them

Information:

Prism version: all
Environment: browser

Does the latest version of Prism from the download page also have this issue?
Yes
Description

Example
https://drupal-bootstrap.org/api/bootstrap/docs!Theme-Settings.md/group/theme_settings/8.x-3.x#cdn-custom
Temporary solution
  // Fix "url-link" regular expression to allow @ symbols.
  // @see https://github.com/PrismJS/prism/issues/1841
  for (var lang in Prism.languages) {
    if (Prism.languages.hasOwnProperty(lang)) {
      for (var key in Prism.languages[lang]) {
        if (Prism.languages[lang].hasOwnProperty(key)) {
          if (key === 'url-link' && Prism.languages[lang][key] instanceof RegExp) {
            Prism.languages[lang][key] = /\b([a-z]{3,7}:\/\/|tel:)[\w\-+@%~/.:=&]+(?:\?[\w\-+@%~/.:#=?&!$'()*,;]*)?(?:#[\w\-+@%~/.:#=?&!$'()*,;]*)?/;
          }
          if (Prism.languages[lang][key].inside && Prism.languages[lang][key].inside['url-link'] instanceof RegExp) {
            Prism.languages[lang][key].inside['url-link'] = /\b([a-z]{3,7}:\/\/|tel:)[\w\-+@%~/.:#=?&]+/;
          }
        }
      }
    }
  }

Thank you for reporting!

authors: RunDevelopment markcarver


text:
Buggy movement on snow

This makes a lot of sense. The bot thinks it's stuck in a block, (the snow) so it constantly hops forward instead of walking forward and removes snow layers on ledges before climbing up them.
I would have thought the bot would ignore them because the snow has no collision. However, pathfinder checks the bounding box of the block when handling pathfinding, not the collision shape. So even transparent blocks like snow, torches, and tall grass are seen as obstacles to the bot.

In mc-data we have a script to make sure that all blocks that have a collision shape is of type 'block' and the others are 'empty'.
Snow has a collision shape so it is considered as a block (the bot can walk on it).
All transparent blocks like torch, tall grass etc.. don't have a collision shape so they have their bounding box set to 'empty'. (ex: https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/blocks.json#L12990) so its not seen as an obstacle.
What we are missing however is in the movement generation of the pathfinding to consider the real height of the blocks (atm its a post-process). The same bug causes also some issues with the bot trying to jump on fences. I think it would be easier to solve when we have the modular move generation. (if we can add special conditions)

Yeah, that's fair. I imagine the actual block collision shapes could be sampled for that purpose. It would be helpful to eventually provide that information to the movement system to allow for sub-block movements, such as knowing that it could squeeze between two fence posts. But, that's extremely far down the line. xD

issue still happens, the bots still just jump wildly around on snow

a decent-ish workaround would be to count a single snow layer as an empty block
it wouldnt be pretty but its better than having a broken bot when in a snow biome

Would be a solution since normal, single-layer snow has no collision. So It would work in 99% of use cases. Better 99% accurate than 0% accurate.

maybe this is related to the soulsand bug, can you check if its fixed now @TheDudeFromCI ?

maybe this is related to the soulsand bug, can you check if its fixed now @TheDudeFromCI ?

I checked and: nope
video on progress: https://streamable.com/pouvcx

Found the bug. Should be fixed now.

Oh sorry, was asleep. Thanks for testing it for me.

https://streamable.com/mtpels still buggy but now less buggy
great progress but still glitchy

It appears the original bug was fixed, but there are a few other existing bugs with block bounds. For the most part, though, it's a lot better.

Ok there are 2 bugs in the video, one is reported here https://github.com/PrismarineJS/mineflayer-pathfinder/issues/65
The other is it thinks it is 1 block above the snow so it can jump on the slab. Non-blocks are a pain to handle, we need to think of a proper way to to handle them, it is too hacky right now.

just throwing out an idea:
a "database(?)" with all the blocks that are a pain to handle and when the bot encounters one, it can check for special procedures to get over it
maybe for a wall, it could "build an imaginary" slab(just for pathing calculations) over the wall so it paths correctly

@MrAlexEsisteGia All block types already contain collision shape data. You could simply retrieve the information by reading the collision shape. Pillaring over walls, for example, if the collision extends above the block.

@MrAlexEsisteGia All block types already contain collision shape data. You could simply retrieve the information by reading the collision shape. Pillaring over walls, for example, if the collision extends above the block.

what about lilypads or single snow layers?
they have I think a collision shape that is under the actual block
or ladders, those need some entirely different code to work (I think?)

Single layer of snow don't have a collision shape https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/blockCollisionShapes.json#L185
Instead it is the collision shape of the block bellow that collide with the player. As it must sit on a full block, it works.
Lilybads do have a collision shape https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/blockCollisionShapes.json#L249
and it doesnt extend outside the block: https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.16.1/blockCollisionShapes.json#L1171

authors: Bottinator22 Karang MrAlexEsisteGia TheDudeFromCI

repo: PrismarineJS/mineflayer-pathfinder


text:
Read projections

Hello,
currently, I want to provide read projections to my domain. In which way I should implement this? Should I use 1) DomainAggregator which is considered as deprecated and if so, can you please post some working code snippet how it works? Or should I use 2) Persistence query module. I am currently using MongoDB journal plugin which currently does not support live event streams, so I don't know how to implement projections using persistence query. What approach do you currently use in your application? Thanks

After I studied  DomainAggregator I thing it will be sufficient to use it currently. Can you help me please with wiring with all this together (DomainAggregator, DomainAggregatorView, DomainAggregatorView)?
I understand, that DomainAggregatorCommitter should be mixed in to Aggregate ... but when? When defining aggregate or when instantiating it in AggregateFactory#props?
Next, DomainAggregatorCommitter needs reference to DomainAggregator, so another question is, where DomainAggregator should be created, because it needs persistenceId of Aggregate. Similar question is about DomainAggregatorView ... where should it be created and persistenceId should be passed in?
Some code snippet or test would be very helpful, thank you very much

Personally, I would stay away from using the DomainAggregator class. I wanted to recover all events in a journal independant manner. On the Akka mailing list, I have read about the idea of duplicating all persisted events in a single persistent actor in order to recover using PersistentView. This was a quick and eady solution to allow me to rebuild my projection model on restart. There are a few problems with this approach however.

Persisted events can get lost between an aggregate and the aggregator, meaning projected state will always be out of sync
All events are stored twice, wasting precious space
Current setup does not work in a clustered environment. A ClusterSingleton needs to be used to ensure the DomainAggregator is only updated on a single node
Less usefull when persisting your projections. I tried keeping them in memory for a while because I believed this allowed me to develop quickly, but actually it slowed me down because I spent time worrying about the wrong things
PersistentView is now deprecated. Although the query can be simulated using PersistenceQuery. One drawback I found is that very few journal plugins support PersistenceQuery yet

To anwer your question, you can mixin the trait directly in the actor. However, by doing so, you're mixing aggregate concerns with the overall need to recover, which is more an aspect of the system under development. I prefer to mixin the DomainCommitter trait in the AggregateFactory
On our projects, I prefer to publish events, so that projections can pick them up and update their persisted state. You can do this in-process or using a message broker. This way, there is less need to recover the complete state all the time. For that scenario, I am simply quering the journal storage directly. All dependencies are already in the project and I found that simply quering directly and using Akka serialization to recover all persisted events is much easier than trying to do this in a journal independent way.
Note that this library is still under heavy development. API changes are likely as I am learning better ways to do things. We are using this library ourselves in multiple projects, but then again. I hope to reach stability in the API somewhere mid 2016. There are a lot of interesting implementations for doing DDD with Akka (some in the README.md), which are worth checking out and learning from.

Thanks for your response. I was reading through persistence query documentation at the weekend and I would like to play with it a little. My idea is to have one actor which will first query all persistenceIds and for each persistenceId it queries all events and it will send them to specific aggregateView actor. Read journal I am using at the moment doesn't support live stream version of these queries yet, so I would implement some kind of polling myself. Also I would need to add one persistent actor to store some kind of Map[PersistenceId, LastEvetNr] to be able to process only new events at startup or when polling.
AggregateView will handle events and construct/update view state and persist it to read database. After some time of inactivity it should be stopped. When new events arrives it should be of course started.
What do you thing about this approach? Do you see any drawbacks? Thanks

Closing this as Aggregate Views shoudn't be used. Currently, we use another durable event stream where all events are duplicated. They are reliably published to this stream using ReliableDelivery and are only confirmed when written to this stream. You can think of Couchbase or Kafka to make this work, which can then be used for full recovery without the need to do any magic in the aggregate.

authors: andrekampert dohnala

repo: Product-Foundry/akka-cqrs


text:
Setup guide

Would be lovely, if the readme has a guide on how to setup/run the project locally

Yes, I agree -- not sure yet when I'll do this, but it's definitely something I should make!

Easy initial fix is to put a blank settings.php file in the root directory so that people can fill in the blanks to get most of the way there

Easy initial fix is to put a blank settings.php file in the root directory so that people can fill in the blanks to get most of the way there

How do I run the application?

authors: ProfZijlstra anubra266 okumujustine


text:
良いところ診断の結果に優しさを追加したい。

以下の結果を追加したい
'###userName###のいいところは優しさです。あなたの優しい雰囲気や立ち振る舞いに多くの人が癒やされています。'

いいよ！これから対応します

bf0769f で対応しました


text:
Hami2.4.0 with Ascend，Metrics - deviceuuid 咨询

Ascend310P-0不符合uuid的语义，在不同的node上有可能重复
建议使用

/assign

authors: lengrongfu ymbZzz

repo: Project-HAMi/HAMi


text:
NoiseSchedules cosine seems wrong and lead to division by 0

I wanted to use a DDPMScheduler with a cosine scheduling and obtained images filled with nan when sampling images.
I quickly inspected the code and found that it was caused by a division by 0 in  the step function of the class DDPMScheduler right here :
pred_original_sample_coeff = (alpha_prod_t_prev ** (0.5) * self.betas[timestep]) / beta_prod_t
current_sample_coeff = self.alphas[timestep] ** (0.5) * beta_prod_t_prev / beta_prod_t

beta_prod_t being equal to 0 at step 0 when using cosine scheduler because it comes from :
alpha_prod_t = self.alphas_cumprod[timestep]
alpha_prod_t_prev = self.alphas_cumprod[timestep - 1] if timestep > 0 else self.one
beta_prod_t = 1 - alpha_prod_t

alphas_cumprod calculated like so in this case :
x = torch.linspace(0, num_train_timesteps, num_train_timesteps + 1)
alphas_cumprod = torch.cos(((x / num_train_timesteps) + s) / (1 + s) * torch.pi * 0.5) ** 2
alphas_cumprod /= alphas_cumprod[0].item()

Thus, alpha_cumprod[0] = 1 and beta_prod_t = 1 - 1 = 0
I saw no issue reporting this, maybe I am using it wrong. :man_shrugging:
I tried using DDPMScheduler(num_train_timesteps=1000, schedule="cosine") in the 2d_ddpm_compare_schedulers.ipynb and got nan filled images as result.

Hi there,
In the cosine schedule the alpha/beta are calculated with clipping, so beta_prod_t is not 0 when t=0 as far as i can see:
    x = torch.linspace(0, num_train_timesteps, num_train_timesteps + 1)
    alphas_cumprod = torch.cos(((x / num_train_timesteps) + s) / (1 + s) * torch.pi * 0.5) ** 2
    alphas_cumprod /= alphas_cumprod[0].item()
    alphas = torch.clip(alphas_cumprod[1:] / alphas_cumprod[:-1], 0.0001, 0.9999)
    betas = 1.0 - alphas
    return betas, alphas, alphas_cumprod[:-1]

however there are documented problems with the cosine scheduler, see discussion here
@sRassman reports better results if you try using leading timesteps here could you try that and see if it fixes it for you?

ah yes nice spot - it seems like we should be making sure alpha cumprod is calculated from the clipped alphas before we return it from the cosine scheduler

Hi
I came across the same issue of receiving Nans with Cosine due to devision by zero.
I looked to see if there is an open issue about it and here it is.
Are there immediate plans to fix this? How do you suggest to handle it right now?
Thanks
oded

Dear Oded,
Note that the MONAI Generative Models repository will be soon archived because the code has been integrated in MONAI core (https://github.com/Project-MONAI). Could you check if using the latest version of the schedulers from MONAI core leads to the same error?
If so, we will look at it immediately.
Otherwise, please use that alternative repository.
Thank you very much!
Virginia

Hi  Virginia
If I understand correctly the code here:
https://github.com/Project-MONAI/GenerativeModels/blob/main/generative/networks/schedulers/scheduler.py
has been replaced with:
https://github.com/Project-MONAI/MONAI/blob/dev/monai/networks/schedulers/scheduler.py
The cosine function is exactly the same so I don't expect any difference.
I rewrote the code to work and I urge you to fix this issue. It may give
much value.
Thanks
Oded
On Mon, Sep 23, 2024 at 11:05 AM Virginia Fernandez <
@.***> wrote:

Dear Oded,
Note that the MONAI Generative Models repository will be soon archived
because the code has been integrated in MONAI core (
https://github.com/Project-MONAI). Could you check if using the latest
version of the schedulers from MONAI core leads to the same error?
If so, we will look at it immediately.
Otherwise, please use that alternative repository.
Thank you very much!
Virginia
—
Reply to this email directly, view it on GitHub
https://github.com/Project-MONAI/GenerativeModels/issues/489#issuecomment-2367493105,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APGGBDEX64D2DRGWMW6N7NDZX7DTTAVCNFSM6AAAAABHYBKQBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGQ4TGMJQGU
.
You are receiving this because you commented.Message ID:
@.***>

Dear Oded
Thanks.  We will look into it.
Could you please open an issue in MONAI core describing the problem so that we can have a look at the problem from there and trace it?
Thanks!
Virginia

authors: Leirbag-gabrieL OdedRotem314 marksgraham virginiafdez

repo: Project-MONAI/GenerativeModels


text:
551 Fix premerge py version issue

Fixes #551
Description
This PR does the following three changes:

fix the python version issue in permerge cpu test
update two bundles to support black 24.1
update weekly cpu test to enable new bundles tests

Status
Ready
Please ensure all the checkboxes:

[x] Codeformat tests passed locally by running ./runtests.sh --codeformat.
[ ] In-line docstrings updated.
[ ] Update version and changelog in metadata.json if changing an existing bundle.
[ ] Please ensure the naming rules in config files meet our requirements (please refer to: CONTRIBUTING.md).
[ ] Ensure versions of packages such as monai, pytorch and numpy are correct in metadata.json.
[ ] Descriptions should be consistent with the content, such as eval_metrics of the provided weights and TorchScript modules.
[ ] Files larger than 25MB are excluded and replaced by providing download links in large_file.yml.
[ ] Avoid using path that contains personal information within config files (such as use /home/your_name/ for "bundle_root").

Hi @wyli , @KumoLiu , I had some experiments, I think we can avoid removing "/opt/hostedtoolcache/Python" to ensure the python version is what we need for CI test.
related job: https://github.com/Project-MONAI/model-zoo/actions/runs/7676654654/job/20924453064?pr=552#step:7:41

/build

/build

weekly cpu test is checked (https://github.com/Project-MONAI/model-zoo/actions/runs/7690667917)

/build

repo: Project-MONAI/model-zoo


text:
dicom

Please use MONAI's Discussions tab
For questions relating to MONAI usage, please do not create an issue.
Instead, use MONAI's GitHub Discussions tab. This can be found on the MONAI repository's main page (not the tutorials) next to Issues and Pull Requests along the top.

Closing this as it is an empty issue.

authors: rijobro shahriar-faghani

repo: Project-MONAI/tutorials


text:
Official OcclusionSensitivity example is not workable

Dear Sir,
The example of OcclusionSensitivity in your example is not workable(https://docs.monai.io/en/latest/visualize.html?highlight=OcclusionSensitivity).
Run:
densenet 3d
from monai.networks.nets import DenseNet
from monai.visualize import OcclusionSensitivity
model_3d = DenseNet(spatial_dims=3, in_channels=1, out_channels=3, init_features=2, growth_rate=2, block_config=(6,))
occ_sens = OcclusionSensitivity(nn_module=model_3d, n_batch=10, stride=2)
occ_map, most_probable_class = occ_sens(torch.rand(1, 1, 6, 6, 6), class_idx=1, b_box=[-1, -1, 2, 3, -1, -1, -1, -1])
Error:

TypeError                                 Traceback (most recent call last)
 in
5 model_3d = DenseNet(spatial_dims=3, in_channels=1, out_channels=3, init_features=2, growth_rate=2, block_config=(6,))
6 occ_sens = OcclusionSensitivity(nn_module=model_3d, n_batch=10, stride=2)
----> 7 occ_map, most_probable_class = occ_sens(torch.rand(1, 1, 6, 6, 6), class_idx=1, b_box=[-1, -1, 2, 3, -1, -1, -1, -1])
TypeError: call() got an unexpected keyword argument 'class_idx'
When I deleted 'class_idx', I still had an error:

ValueError                                Traceback (most recent call last)
 in
5 model_3d = DenseNet(spatial_dims=3, in_channels=1, out_channels=3, init_features=2, growth_rate=2, block_config=(6,))
6 occ_sens = OcclusionSensitivity(nn_module=model_3d, n_batch=10, stride=2)
----> 7 occ_map, most_probable_class = occ_sens(torch.rand(1, 1, 6, 6, 6), b_box=[-1, -1, 2, 3, -1, -1, -1, -1])
/environment/python/versions/miniconda3-4.7.12/lib/python3.7/site-packages/monai/visualize/occlusion_sensitivity.py in call(self, x, b_box)
297
298             # Generate sensitivity images
--> 299             sensitivity_ims_list, output_im_shape = self._compute_occlusion_sensitivity(x, b_box)
300
301             # Loop over image for each classification
/environment/python/versions/miniconda3-4.7.12/lib/python3.7/site-packages/monai/visualize/occlusion_sensitivity.py in _compute_occlusion_sensitivity(self, x, b_box)
218             raise ValueError(
219                 "Stride and mask size should both be odd or even (element-wise). "
--> 220                 + f"stride={self.stride}, mask_size={self.mask_size}"
221             )
222
ValueError: Stride and mask size should both be odd or even (element-wise). stride=[1 2 2 2], mask_size=[ 1 15 15 15]
I have used the corresponding version Monai.

Hi, which tutorial is this? We use occlusion sensitivity in our covid classification tutorial, and as far as I can tell, this is currently running successfully (see today's cron log).
Could you try running the notebook as-is, without any modifications? You'll also need to make sure that you're using a verion of monai and monai-tutorials that are from the same time. E.g., you could use 0.4.0 for both, or 0.5.0 of monai and master of monai-tutorials (since we haven't quite released 0.5.0 of monai-tutorials yet).

Hi, which tutorial is this? We use occlusion sensitivity in our covid classification tutorial, and as far as I can tell, this is currently running successfully (see today's cron log).
Could you try running the notebook as-is, without any modifications? You'll also need to make sure that you're using a verion of monai and monai-tutorials that are from the same time. E.g., you could use 0.4.0 for both, or 0.5.0 of monai and master of monai-tutorials (since we haven't quite released 0.5.0 of monai-tutorials yet).

Dear Dr Richard Brown,
Thank you for your prompt reply. I am sorry. It is not from the tutorial and maybe I should ask the question here. But the problem is pasted on MONAI official documentation (see: https://docs.monai.io/en/latest/visualize.html?highlight=OcclusionSensitivity)
It is here:    It is for the use of 3d OcclusionSensitivity.

I ran the code and used the correct version of Monai (0.5.0). I did not revise anything but got an error. I ran:
densenet 3d
import torch
from monai.networks.nets import DenseNet
from monai.visualize import OcclusionSensitivity
model_3d = DenseNet(spatial_dims=3, in_channels=1, out_channels=3, init_features=2, growth_rate=2, block_config=(6,))
occ_sens = OcclusionSensitivity(nn_module=model_3d, n_batch=10, stride=2)
occ_map, most_probable_class = occ_sens(torch.rand(1, 1, 6, 6, 6),  b_box=[-1, -1, 2, 3, -1, -1, -1, -1])
See the following figure:

I have read your covid classification tutorial. It is very good. Do you have any tutorials aimed at 3d visualization using
OcclusionSensitivity or CAM? I am looking for your tutorials and cannot find them.  Thank you.


text:
maxLength in text

1 maxLength should simply prevent adding more characters (rather than showing a "too long" warning).
2 It will be better if the length of the text-box would be according to the maxLength. It is odd when I limit the length of the response to 30 characters, but the text-box is much longer.

@baranan
There is a usability issue here. If users attempt to insert a response and nothing happens, they'll feel that something is broken.
Also, it is not straightforward to shorten the input in accordance with the maxLength (The same lenght can have multiple text widths and it gets out of hand quite quickly...). If you want a narrower input, simply use the inline property #72.

ok. So prevent adding and show also a warning, but allow researchers to ask for removing that warning (no-warning).

Do you mean the same-line feature?  (the link from #72 is not clear. It might have been better if the message that closes the issue explicitly documented what new feature was added). It doesn't sound like a perfect solution because it will probably be fine for some lengths and too much/too little for other lengths. Perhaps add another property to set the size/length of the text-area.

allright
Yes, I mean the same line feature. Setting the width explicitly is begging for trouble. I highly recommend to avoid it.

And if we don't mess with the width, can we at least set the number of lines?

@baranan: This is one option, but the idea is that it depends on the question how long the answer is expected to be. Sometimes we want only a word, sometimes 10, sometimes three lines and sometimes a whole essay. So the whole idea is that it would help researchers if they can control the size of the input box.
I see, you want a textarea input. Moving that discussion to #95

authors: baranan eladzlot

repo: ProjectImplicit/PIquest


text:
CI generated online documentation

Workflow has been added to generate documentation and deplot to gh-pages whenever a new release with a version number is generated (goes to stable documentation) and when master branch is updated with a push or PR.

This works! Thank you so much @anchal-physics !!

You're welcome. Please note that stable online documentation would only be generated once you create a tagged release with version number. Currently this link on the README page is broken.

No, I can not publish them to Julia registry yet since IMASDD is a dependency and it is not available at Julia registry. So I need IMASDD published before I can publish other packages.

Let's publish all of them then. Have you looked into how that works? I have not.

Yesh, I have. You need to install registrator bot to your repository which are a few clicks. Then open a new issue and comment following to it:
@JuliaRegistrator register()

I have already tried it on https://github.com/ProjectTorreyPines/GGDUtils.jl/issues/47 and that's how I know that IMASDD needs to be registered first.
source: https://julialang.org/contribute/developing_package/#step_5_register_your_package


text:
Dokumentation FA - Storyelement - 2D NPC Darstellung

User Story
Als Benutzerrolle möchte ich Funktionalität sodass Wert für den Nutzer
Akzeptanzkriterien

[ ] Akzeptanzkriterium

Definition of Ready

[ ] User Story ist klein genug für Sprint
[ ] User Story ist für jeden beteiligten Entwickler klar verständlich
[ ] User Story Aufwand ist geschätzt
[ ] User Story hat Akzeptanzkriterien
[ ] User Story hat einen Mehrwert für das Produkt oder die Entwicklung
[ ] User Story Ursprung ist bekannt (Stakeholder)
[ ] User Story ist Release zugewiesen

Definition of Done

[ ] Alle Akzeptanzkriterien sind erfüllt
[ ] ZenHub Tasks sind gecheckt
[ ] Wiki ist gecheckt
[ ] Anforderungen mit IDs sind erstellt
[ ] Glossar verlinkt und gegebenenfalls erweitert
[ ] Aktivitätsdiagramm (falls nötig) ist erstellt
[ ] Unit-Tests sind zugewiesen
[ ] Fehlende Unit-Tests sind dokumentiert
[ ] Review wurde durchgeführt

#891

authors: AdLer-Lukas Lizardguard


text:
Method for ignoring a local server asset or file

Would be useful to have some Router logic that determines whether a link is a local server asset or file, such as a link to a PDF or ZIP file located on the same domain.

@jasonbarone - This commit seems a viable fix for this: a8198592ebea28563dff978f530237ace0b52dd2. Go ahead and test it out. If you're using PageController, you'll want to just trash that node_module and re-install it to pull the latest Router version into it - 0.2.6.

Thanks looks like this works great so far!

@jasonbarone I've pushed some updates that make this solid. I ran into some issues with it myself since I had only tested on my localhost. Once I got it on a domain with a .com it was breaking. Latest version of Router is 0.3.3. PageController had some updates as well, v0.3.11 now, so an npm update on that should pull in all the latest modules for that. If that doesn't work, rm -rf node_modules/properjs-pagecontroller && npm install properjs-pagecontroller.

authors: jasonbarone kitajchuk

repo: ProperJS/Router


text:
mzXML parsing doesn't support mzML source files

Hi guys,
The translateSourceFileTypeToNativeIdFormat() function doesn't translate the MS_mzML_format flag (source). This may cause errors when trying to load mzXML  files that were generated from mzML files by some tools (e.g. FileConverter from OpenMS).
A workaround is to 'convert' the output mzXML to another mzXML, which changes the parent format to mzXML, which can then be parsed by translateSourceFileTypeToNativeIdFormat().

Hmm, there's no clearly correct approach here. The goal for this function is to recover vendor-specific nativeIDs from mzXML's single scan numbers to make it somewhat round-trip-able. But the nativeID format for an mzML file cannot be determined without looking inside the mzML (or having that extra information encoded in the mzXML). So I've committed a cop-out fix.

I see ... thanks for the details and the fix!
Out of curiosity: I am not fully sure what it means to lack the nativeID information here, and what this means for the possibility to 'safely' convert between mz(X)ML files.
Thanks,
Rick

Some vendors have spectrum ids that can be practically treated as single numbers, and some do not. For the ones that do, ProteoWizard tries to interpret mzXML scan numbers as those ids. For example, Thermo has a nativeID format like controllerType=0 controllerNumber=1 scan=123 because PDA spectra can have the same scan numbers as MS spectra but will be on a different controllerType. But because it's rare to find a RAW file with PDA spectra and mzXML doesn't support PDA spectra anyway, we can assume that mzXML files with a Thermo RAW parentFile should have their scan numbers translated back into Thermo nativeIDs. But if the conversion chain loses track of the fact the original vendor file was a Thermo RAW file, we can't do that translation.

Hi Matt,
That makes sense, many thanks for your explanation.

authors: chambm rickhelmus

repo: ProteoWizard/pwiz


text:
Can not search commands

Searching commands causes an exception (case for search was moderator)
note: test other searches

Could not reproduce, will monitor

repo: Psychoboy/PenguinTwitchBot


text:
MCTS能否考虑预测信息的多模态性？

本人完成防御性驾驶motion planning的一部分。现在后续准备通过修改您的MCTS的代码，在决策层考虑预测的多模态性。您认为是否可行？

我其实并不确定你要怎么做，MCTS是一种经典的树搜索算法，“在决策层考虑预测的多模态性“ 我理解更多是从如何建树出发，而不是从搜索方法出发

我目前的想法是将MDP问题拓展到POMDP问题或者直接将每个state的obstacle 轨迹添加一个已知的概率(置信度)，然后直接利用distance的cost乘该概率，您认为是否可行？

理论上可行，实际上很多也是这么做的

收到

authors: PuYuuu chaiyanana


text:
Precompile selectors for goquery

Just propousal, precompile selector such as base[href] using cascadia so you will be able to use FindMatcher

Hello Mike,
Yes, that makes total sense, there are 2 selectors used by gocrawl that should be pre-compiled indeed. Happy to merge a PR that would change this, if you or anyone else is interested.
Thanks,
Martin

https://github.com/PuerkitoBio/gocrawl/pull/68

authors: mikefaraponov mna

repo: PuerkitoBio/gocrawl