text:
STY: Maths formatting

This issue is linked to #14330
To be able to use tools (like, but not limited to Black), we need to define how we, as the scientific community and not just SciPy, want mathematical equations to be rendered.
The goal of this issue is to document and establish a strict set of rules to write maths. The rules must be coherent, extensive and opinionated (one way to do something, unambiguous wording) so they can be integrated in a tool (that tool may be Black).
I think such a document is missing from the scientific community and my hope is that we can all agree on something :smiley:
To quickstart things here are some ideas:
Formatting Mathematical Expressions
To format mathematical expressions, the following rules must be followed. These rules respect and complement the PEP8 (relevant sections includes id20and id28)

If operators with different priorities are used, add whitespace around the operators with the lowest priority(ies).
There is no space before and after **.
There is no space before and after operators *,/. Only exception is if the expression consist of a single operator linking two groups.
There a space before and after -, +. Except if : (i) the operator is used to define the sign of the number; (ii) the operator is used in a group to mark higher priority.
When splitting an equation, new lines should start with the operator linking the previous and next logical block. Single digit, brackets on a line are forbidden. Use the available horizontal space as much as possible.

# Correct:
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
dfdx = sign*(-2*x + 2*y + 2)
result = 2 * x**2 + 3 * x**(2/3)
y = 4*x**2 + 2*x + 1
c_i1j = (1./n**2.
         * np.prod(0.5*(2.+abs(z_ij[i1, :])
                        + abs(z_ij) - abs(z_ij[i1, :]-z_ij)), axis=1))

# Wrong:
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
dfdx = sign * (-2 * x + 2 * y + 2)
result = 2 * x ** 2 + 3 * x ** (2 / 3)
y = 4 * x ** 2 + 2 * x + 1
c_i1j = (1.
         / n ** 2.
         * np.prod(0.5 * (2. + abs(z_ij[i1, :])
                          + abs(z_ij) - abs(z_ij[i1, :] - z_ij)), axis=1))

I am -1 on any such attempt to enforce such strict, extensive, and opinionated rules. PEP8's recommendations are the right level for developer guidelines, IMO. I'm not sure that such algorithmically-complete rules exist that are simultaneously both terse enough to be implementable and also don't create unreadable horrors in specific circumstances.
Now, if you want to develop an auto-formatting algorithm that uses whitespace in mathematical expressions more readably than black, that's great! Develop it somewhere and see if people like it. I might even use it if it's opt-in, especially if I can use it through my editor over the current selection of lines, not the whole file.

@tupui I think the +/- part would benefit from "unary"/"binary" terminology.
And can you explain what you mean by

(ii) the operator is used in a group to mark higher priority.

(in the same place)?
And why in
         * np.prod(0.5*(2.+abs(z_ij[i1, :])

there is no whitespace around the binary plus?
And is using 1., 2. a conscious choice or just force of habit? If this style guide takes off, taking a stance on the likes of 1. and .1 might be necessary.

That's an example of a (possibly-useful) ambiguity that can be used to make things more readable insofar as they communicate some subtle high-level semantics. That kind of ambiguity would be unavailable to algorithmic auto-formatters.
If the goal is to define rules that can be used to build an algorithmic auto-formatter, I recommend just going and implementing the algorithms and using the implementation as the object of discussion. Human brains just aren't good at predicting what the algorithm is going to do in all of the important cases just from the human-readable rules. Making a quick implementation gives us something concrete to discuss, we can throw real examples at it in bulk and evaluate the results quickly, and the process of implementation will make manifest all of the ambiguities.

As an outsider in scipy-dev, I resisted commenting on #14330.  Here, however, you seem to be aiming to codify how the wider scientific community (probably restricted to "scientific python"?) writes math.

The goal of this issue is to document and establish a strict set of rules to write maths.

Why is a strict set of rules beyond "valid Python" necessary?  The gaol appears to be aimed at reformatting working Python code that someone wrote, and quite likely someone else reviewed or has read,  and likely someone else else modified.  Scipy has a lot of contributors - lots of people have read the code. The clarity of the math cannot have been too bad or objectionable.  If there isolated cases where it needs fixing, I'm pretty sure you do not need an "established strict set of rules" to clean up the code.

The rules must be coherent, extensive and opinionated (one way to do something, unambiguous wording)

The Zen of Python uses "should" and "obvious" when talking about "one way to do something". It does not mandate that there can be only one way to do something.

so they can be integrated in a tool (that tool may be Black).

Why would you want to do that?  A key feature of Python is that the code is readable, and hard to make impenetrable to a reasonably knowledgable person.  Never mind which "strict set of rules" is needed, why is any strict set of rules needed? Why is any code re-formatting tool needed?
When writing Python code with even a modest amount of care, you can be pretty sure that someone else (maybe yourself in 2 years) will be able to read and (at least sort of) understand what it tries to do.  This notion that whitespace between operators or mixing of single and double quotes in a codebase will somehow cause cognitive dissonance or start formatting arguments is somewhat hard for me to even comprehend. Do such things actually happen, ever with Python?  There were tabs/spaces arguments, are there "1 or 0 whitespaces around '+'" arguments?
Are people confused by single quotes?
Is there evidence that code formatting is a problem?  What fraction of scipy, numpy, scikit-xxx PRs have had significant discussions (let alone "controversies") about Python formatting? How many of those are not resolved by "let's be sensible and mostly follow PEP8 when we can"?
I must say that when I first heard of Black I thought it might have been an elaborate hoax.  It appears to misread the intent of the namesake quote about automobiles:  At the time, there was one choice of color, and the question was whether to expand that choice.  The quote was expressing: "don't focus on styling, focus on features and performance".  Instead, Black asserts that variation in the formatting of working, valid Python code is a problem that needs fixing, focusing attention on the styling of already highly readable and working code at the expense of features and performance.  It creates a problem where none existed.
The intention of Black is that PRs to fix bugs or add features will be held and more work demanded of the contributor in order to meet styling rules.  The feature might be accepted, but only if it fits the style.  Discrepancies end not in argument but in acquiescence (or perhaps in disgust -- pay attention to the ones who walk away).  The intention of Black is that acquiescence ends any debate (was there any?). It enforces uniformity without exception or nuance, expelling non-compliant contributions when necessary.   Many of us in the sciences are trying to fully internalize notions of belonging, access, equity, diversity, and inclusion.  Would formatting of code submitted by the visually impaired be disadvantaged by these rules?  Would it make screen readers more accurate?  How does Black improve the community?  The approach taken by Black is deliberately and proudly polarizing, basically for the sake of being proud about being polarizing.  Let's have a little less of that, please.
If one wanted to follow the engineering wisdom from the Ford quote, they would be careful about formatting new code, try to be consistent and readable, but certainly not fix what ain't broke, and focus on features and performance over styling.  They would be sensible. They probably would not even engage in this conversation.  My apologies for not being strong enough to hold my tongue.

To format mathematical expressions, the following rules must be followed. These rules respect and complement the PEP8 (relevant sections includes id20and id28)

PEP8  is a guide, not a mandate. It says
"If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator:"
Somehow this got turned into 4 mandatory rules (with one exception!) about how much whitespace there will be around all binary operators.  I did no read that as "Use your own judgment as long as you agree with me".
I think my main objection to this comes down to that line that reads "#Wrong" there, just above all the working code.  That is code that is "not-PEP8 compliant",  it is not "Wrong".   The calculated values will not change.  Is anyone confused by this code?  If you're in there working on or reviewing the code and want to make it a bit more PEP8-ish, sure go ahead.  If it looks readable, it is readable.  If you decide that whitespace around a '+' sign isn't needed in something like np.sin(array[2*i+1, :]), well, maybe that's OK sometimes.
Sorry for the length.

Thanks @newville that's an opinionated but balanced take. I am probably the last person to defend Black, but I think you have taken its use and the problem it promises to solve a bit differently than intended. What black offers is a non-negotiable set of code standards. This becomes particularly effective when many coders have to touch the same codebase frequently. Some come from Java-like background who don't mind going off to the second screen horizontally and others coming from different backgrounds working on the same Python code.
The amount of time wasted on code reviews on that regard in terms of business hours is immense where one says I don't like pep8 line length the others say other things etc. Here the black use is pretty much justified since instead of bringing your developers to a common understanding, the team delegates the code structuring to Black and agrees to not discuss it. Then everything is Black'ened and whatever comes out of it hopefully makes sense. And quite often it does the sensible thing. Code reviews get saner (as much as it can, I mean we are talking about devs here). Now what we have accomplished is that we have adopted the standard of the core devs of Black and we are done.
However, as many people quickly found out in the past (including us after using it about 4 months) is that this standard is not written by scientific or number crunching people. And its strict standard often does not go together with say numpy standard or pandas .function(args).function(args) chains. That's a typical complaint and I think it is justified. So I'm not a fan of Black in that regard since it makes arrays wonky and uglier (IMO).
The discussion here is whether we should delegate code formatting to Black and be done with it. However, its choices as mentioned above especially about ** and operator precedence is almost always wrong for human eyes. For example, in the correct formatting above, instead I would have written it as
c_i1j = (1./(n ** 2.) * np.prod(0.5 * (2. + abs(z_ij[i1, :])
         + abs(z_ij) - abs(z_ij[i1, :] - z_ij)), axis=1))

because it is obvious that it would be a long line hence at least try to make it obvious by breaking it at a sensible point and not bring in strange staircase formatting. And Black starts to fail more often than not in the unary ops in terms of readability. But in any case you can see what was and is now in scikit-learn https://github.com/scikit-learn/scikit-learn/pull/18948 conversion.
Some lines are clearly disgusting in the "after" state to see but I tend to like the the relaxed 88 character line length since 79 is a bit too much in terms horizontal space constraint in my opinion but we won't need black to have that kind of relaxation.

Thank you @newville for expressing your sentiment on this.
As @ilayn pointed out, the goal is to same everyone endless discussions about styling.
Sure the PEP8 was written as a guide and even starts with A Foolish Consistency is the Hobgoblin of Little Minds. Still, over the decades we have seen that this guide was used as an authoritative way to write Python. And we could argue that it served the Python community well in general.
Having a common way of writing things across projects has an under rated value. Here I am not advocating to change the face of maths in all Python scripts used in science. I am more asking to reflect on how to write maths in large libraries such as SciPy and NumPy. The difference is paramount. For the developers having to navigate across these different projects, I think there is a great value having common practices. It enables faster onboarding of new contributors, removes lots of churn. Of course, long time contributors might not agree as they have years of experience navigating around these and other projects.
Newcomers, students, and as you rightfully noted, people with disabilities, would greatly benefit from a common ground. Having a unified language help lower the barriers and tools can be written to help them. Imagine if Black (or anything else) was used by every single project, you could more easily design tools that could read and write code for visually impaired people. Plus, things like that can/should be linked to pre-commit hooks. So no matter what you do, when you code will appear in the PR it will have the expected style without you having to do anything.
Yes, it removes the developer own style, sensitivity. But I will argue that we should not be able to see its mark in such large open source project. As developers, we read code all day long, and having to do this contextual change is not free, it can also lead to misreads, bugs. We certainly do not want to have a different developer style for every single files. You can make the parallel with standards in industry or rules in our society. It's not because the big think that everyone is depending upon is very strict on some aspects, that you have to do the same for your own project and are not free anymore.
Lastly, I would also note that we currently have tons of hard rules which involve so much more thinking and manual actions. Things like input validation, proper way to test, documentation, CI, etc. Here we are mostly talking about spacing that a machine would do for us so we don't have to talk about it.

the goal is to save everyone endless discussions about styling.

AFAICT, we largely do not have endless discussions about styling in the actual code reviews. We only have endless discussions about styling when someone proposes to use black.

Newcomers, students, and as you rightfully noted, people with disabilities, would greatly benefit from a common ground.

Citation needed. I have seen no evidence that the level of formatting that black and company provide any measurable benefits in this regard.
I've laid down this marker before, and I think it satisfies all of the evidenced benefits that you want from black: my ideal auto-formatting tool is one that leaves style-conforming code alone and only fixes up code that deviates. Somehow the benefits of some kind of auto-formatter got conflated with requiring a canonicalizing auto-formatter. black is not the only possible solution.
At minimum, a tool like darker can be fruitfully used by contributors to apply auto-formatting just to their contribution. All of the benefits with respect to the easing of writing code apply just as much to darker as to black. I recommend that you implement your preferred math styling rules in a way that can be plugged into that, and we can evaluate the results concretely rather than spinning out more endless discussions about styling in the abstract.

my ideal auto-formatting tool is one that leaves style-conforming code alone and only fixes up code that deviates.

It looks like autopep8 might fit that bill.

Let me jump in here, since apparently there's two things being mixed:

do we want/need a code formatter like black?
is it possible to code up with consistent guidelines for writing math?

This issue is not about 1, only about 2. No change to any SciPy way of working is proposed
What black does today for math is bad, really bad. Something like hypot2 = 2 * x + 3 * y ** 2 is code no numerical Python person would write by hand. PEP 8 also falls well short here, it for example is completely silent on the power operator. So the question is: is it possible to do better than black and PEP 8. I'm pretty the answer is yes, the question is just how much better. Once we have the answer, at least there's something to point tool authors to. Maybe black et al. can implement it, maybe not. If they did, it would be helpful.

This issue is linked to #14330

Yes, this is about 1. A change to the SciPy way of working has been proposed. This particular issue is a sub-discussion in response to a specific objection to that proposal.
I agree that there are useful attempts at improving auto-formatting for mathematical expressions. I don't think it's all that helpful to try to hash them out here if we're foreclosing the idea of changing the SciPy way of working. Just go implement it somewhere and ask for feedback on the mailing list.

FWIW, I circulated a project idea among students locally. Will see if
anything comes out of this. No definite ETA at the moment, but we'll
definitely report back if anything worth comes out if this.
вт, 6 июл. 2021 г., 17:06 Robert Kern @.***>:

This issue is linked to #14330 https://github.com/scipy/scipy/pull/14330
Yes, this is about 1. A change to the SciPy way of working has been
proposed. This particular issue is a sub-discussion in response to a
specific objection to that proposal.
I agree that there are useful attempts at improving auto-formatting for
mathematical expressions. I don't think it's all that helpful to try to
hash them out here if we're foreclosing the idea of changing the SciPy way
of working. Just go implement it somewhere and ask for feedback on the
mailing list.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/issues/14354#issuecomment-874791531, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQI6SCBCVV3WWL3UHFFLXDTWMEXTANCNFSM473GMY5A
.

This issue is linked to #14330

Yes, this is about 1. A change to the SciPy way of working has been proposed. This particular issue is a sub-discussion in response to a specific objection to that proposal.

Not it is not at 1, Ralf is correct. I am sorry if I mislead you with linking to this issue. But read what I wrote in the description and the further reply. I am only asking to write some guidelines for mathematical equations. It had some conditional, I just added a bit more.

I agree that there are useful attempts at improving auto-formatting for mathematical expressions. I don't think it's all that helpful to try to hash them out here if we're foreclosing the idea of changing the SciPy way of working. Just go implement it somewhere and ask for feedback on the mailing list.

Sorry but I do not have the expertise (and time. I already followed this path a few times after you suggested this and I just lost time here...) to implement all the ideas that I have. And in this case, there might be existing tools doing the job and they might just need some directions. This is the goal of this issue, to agree on how we should write maths. Then whatever we do with this document is extra. It can start as a general PEP8-ish on our contributing guide up to something used by auto formatting tools.

The description is very focused on defining rules for black-like tools, not only guidelines. If that is no longer the intent, you may wish to amend the wording (preserving the old version for reference, of course).

To be able to use tools (like, but not limited to Black),
a strict set of rules to write maths.
The rules must be coherent, extensive and opinionated (one way to do something, unambiguous wording) so they can be integrated in a tool (that tool may be Black).

Those are worthwhile goals because the state of those tools is pretty pathetic for math expressions. But to formulate rules that work within the constraints of algorithmic auto-formatters, you really need to work from code first. The problem that these auto-formatters face is much more constrained than just a human-readable style guide that we can add to our contributor docs. It seems like these ought to be synergistic goals, that making progress on one will gain you progress on the other whichever order you do them, but I think the similarities are deceptive; there are conflicts due to the different constraints on who/what is performing the style recommendations. So there are two tracks that you can go down: build an auto-formatter that produces output that you like, and writing human-level style guides.
If you want to make progress on the former, I think you have to start with code. There's no benefit to having long discussions here on scipy/scipy about it. Just go build it and ask for feedback from our community on the mailing list. Until you are proposing that scipy use that tool, it's not really on-topic here on the issue tracker.
If you want to make progress on the latter, that's definitely on-topic here, but I think you need to relax the "extensive and opinionated so they can be integrated in a tool" constraints.

@tupui @rgommers

Let me jump in here, since apparently there's two things being mixed:
1 do we want/need a code formatter like black?
2 is it possible to code up with consistent guidelines for writing math?
This issue is not about 1, only about 2. No change to any SciPy way of working is proposed

@rgommers  Um, yes it is.  And not only for SciPy but "we, as the scientific community and not just SciPy".   The goal is very clearly stated as defining how math is rendered so that tools like Black may be used.  It is not isolated to point 2.

This issue is linked to #14330

Yes, this is about 1. A change to the SciPy way of working has been proposed. This particular issue is a sub-discussion in  response to a specific objection to that proposal.

Not it is not at 1, Ralf is correct. I am sorry if I mislead you with linking to this issue. But read what I wrote in the description and the further reply. I am only asking to write some guidelines for mathematical equations. It had some conditional, I just added a bit more.

Huh?   The message sent to the mailing list on 1 July (https://mail.python.org/pipermail/scipy-dev/2021-July/024924.html) has a subject line of "[SciPy-Dev] Code formatting: black".
Issue #14330 is titled "MAINT/STY: use Black formatting" and opens with "I propose to apply Black on our code base."
This issue begins:
This issue is linked to #14330

To be able to use tools (like, but not limited to Black), we need to define how we, as the scientific community and not just SciPy, want mathematical equations to be rendered.

Now you both say that this is not about using Black to reformat Scipy or other scientific code and apologize if some of the links might mistakenly lead someone to conclude that?
I think that if you are concerned about consistency, there may be somewhere closer to home that may need more attention than code formatting.

So clearly the issue description wasn't as focused as it should have been. @tupui discussed this with me, that's why I knew the goal was (2). I even pre-read what he wrote (but not thoroughly enough), so I'm partly to blame for it being unclear.
From initial discussion on gh-14330 it's clear that many people are -1 on using black because its math formatting is terrible. So that's on hold / rejected, unless math formatting can be fixed. There's no point continuing that discussion. Clearly using black is blocked. I'm happy to comment on the PR saying exactly that. We can also just close that PR.
By the way, I have no clear preference about any of this. I've only ever used black once, and it wasn't ideal. I'm happy to give it a chance though, if and only if all blocking concerns have been resolved.

Since this issue has obviously derailed, I suggest also closing this one and starting fresh. It's cleaner than trying to amend the initiating issue description and resuming an essentially new discussion mid-thread.
I still think it's questionable that the scipy/scipy issue tracker is the best place to have the amended discussion. Maybe the SPEC Discourse is a more appropriate venue?

Since this issue has obviously derailed, I suggest also closing this one and starting fresh. It's cleaner than trying to amend the initiating issue description and resuming an essentially new discussion mid-thread.

Agreed, let's close it.

I still think it's questionable that the scipy/scipy issue tracker is the best place to have the amended discussion. Maybe the SPEC Discourse is a more appropriate venue?

That does sound like a good suggestion. We never had a place like that, but we do now - it'd be good to try and start using it. There's still little traffic on that Discourse, but we can point people to it on the mailing list.

Sounds like a good idea, agreed.
Thank you all for the discussion. In future I would hope we could have discussions with a productive outcome and less emotions.

This would have been a good transfer to discussions had we had enabled it by the way

authors: adeak ev-br ilayn newville rgommers rkern tupui


text:
import scipy.optimize calling

Describe your issue.
Thank you very much your development of scipy.
If you know solution, please tell me.
The error occurred when just import scipy.optimize on pypy where installed scipy etc.
$ pypy3
Python 3.9.12 (05fbe3aa5b0845e6c37239768aa455451aa5faba, Mar 29 2022, 08:15:34)
[PyPy 7.3.9 with GCC 10.2.1 20210130 (Red Hat 10.2.1-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import scipy.optimize
terminate called after throwing an instance of 'pybind11::error_already_set'
  what():  IndentationError: ('unexpected indent', ('<string>', 2, 1, '        class pybind11_static_property(property):\n', 2))
Aborted
root@48933591bab3:~#

The pypy was installed based on official pypy docker image.
Env:

MacOS: catalina
Docker: 4.7.0 (77141)
PyPy 7.3.9, 7.3.8 (both)
pybind11                      2.9.2

Reproducing Code Example
import scipy.optimize

Error message
terminate called after throwing an instance of 'pybind11::error_already_set'
  what():  IndentationError: ('unexpected indent', ('<string>', 2, 1, '        class pybind11_static_property(property):\n', 2))
Aborted

SciPy/NumPy/Python version information
PyPy 7.3.9, Scipy 1.8.0, Numpy 1.22.3

It looks like there may have been a bug in PyPy; see https://github.com/conda-forge/pypy-meta-feedstock/issues/25. Please upgrade PyPy, SciPy (to 1.9.3), and open a new issue with a title that identifies the problem, e.g. "BUG: import scipy.optimize fails on PyPy" . (That said, I'm not sure if we support PyPy right now, so I can't guarantee that it will be addressed.)

source: gharchive/issue

authors: HirotsuguMINOWA mdhaber

repo: scipy/scipy

license_type: permissive

license_source: github-api


text:
ENH: Modifies shapiro to return a named tuple

Performs a change in the return of shapiro function, returning now a named tuple ShapirotestResult, which has "statistic" and "pvalue" as indexes. This modify was made to turn the function return similar to other functions like scipy,stats.normaltest and scipy.stats.ttest_ind.
Previously we had to create two objects, something like stats, p = scipy.stats.shapiro (x). Otherwise, we would have to access these values by index(using [0] or [1]), which makes understanding more difficult to someone who does not know exactly the behavior of the function.
With this implementation, we were able to make shapiro_test = scipy.stats.shapiro (x) and, for example, get the p-value with shapiro_test.pvalue.
The function description has also been updated.

@w-rfrsh Please test your added feature into scipy/stats/tests/test_morestats.py

@w-rfrsh Please test your added feature into scipy/stats/tests/test_morestats.py

Done :D

LGTM now, merged. Thanks @w-rfrsh

source: gharchive/pull-request

authors: EverLookNeverSee rgommers w-rfrsh


text:
ENH: interpolate: add input validation to check input x-y is strictly increasing for fitpack.bispev and fitpack.parder

Reference issue

fix #8565
What does this implement/fix?
Some scipy users are confusing this fitpack error message.
https://github.com/scipy/scipy/blob/1d10a4afe95cdd4bcae80db5f312c466d9921d4e/scipy/interpolate/fitpack2.py#L910
like:

#8565,
https://github.com/cmbant/CAMB/issues/40
python - Unable to use `scipy.interpolate.RectBivariateSpline` with `matplotlib.pyplot,plot_surface` - Stack Overflow,
python: How to pass arrays into Scipy Interpolate RectBivariateSpline?

The reason of this error message is the input data is invalid, which is validated in fitpack.bispev
https://github.com/scipy/scipy/blob/2a9e4923aa2be5cd54ccf2196fc0da32fe459e76/scipy/interpolate/fitpack/bispev.f#L45-L50
and in fitpack.parder (when derivative is calculated)
https://github.com/scipy/scipy/blob/5f4c4d802e5a56708d86909af6e5685cd95e6e66/scipy/interpolate/fitpack/parder.f#L50-L54
This restriction offers that input array x and y needs to be strictly increasing, but the python code does not check it and just showing the FORTRAN error code.
Actually, the doc stated that "If grid is True: The arrays must be sorted to increasing order.", but it seems that some users do not recognize it.
So, I added the input validation for these fitpack functions to check input x-y is strictly increasing and its test.
I think there is no backward compatible breaking because the new validation throws ValueError as before.

Thanks @AtsushiSakai , @tylerjereddy, merged.

Hey, just wanted to say thank you, I just hit that issue and I'm really happy to see it's already been tackled! :)

authors: AtsushiSakai StanczakDominik ev-br


text:
ENH: stats: add support for masked arrays for circular statistics functions

Reference issue
Towards #14651
What does this implement/fix?
Adds support for masked arrays in stats.circmean, stats.circvar, and stats.circstd

It looks like a lot of code that deals with NaNs is now unused and can be removed, right?

Removed the unnecessary code @mdhaber.

There seems to be something in the decorator's handling of masked arrays that promotes the dtype (or at least masked arrays are promoting from 32 to 64 for all three of these functions). Could your next PRs be to address this (if it is a bug in the decorator) and #19350 (comment)?

Yeah, will try to get a PR up tomorrow!

Hi @tirthasheshpatel , can you open that PR? SciPy 1.12 is scheduled to branch in about 2 weeks, and it's important to get that in. It would also be nice if we could get most of the remaining low-hanging fruit in there.

There seems to be something in the decorator's handling of masked arrays that promotes the dtype (or at least masked arrays are promoting from 32 to 64 for all three of these functions).

It doesn't seem to be decorator's fault:
In [1]: from scipy import stats

In [2]: import numpy as np

In [3]: stats.circmean(np.ones(5, dtype=np.float32), _no_deco=True).dtype
Out[3]: dtype('float64')

Interestingly, that's also because NumPy treats arrays and scalars differently when it comes to dtype promotion:
In [4]: (np.float32(9.) * 2.).dtype
Out[4]: dtype('float64')

In [5]: np.ones(5, dtype=np.float32) * 2.
Out[5]: array([2., 2., 2., 2., 2.], dtype=float32)

Might be an issue for a lot of function because of this behavior.

Right I actually found that, too. Glad we come to the same conclusion. If it's not the decorator's fault, don't worry about it for now.
But there is still https://github.com/scipy/scipy/pull/19350#issuecomment-1758711603.

authors: mdhaber tirthasheshpatel


text:
MAINT/DOC: stats: fix lint errors

Reference issue
Towards gh-19490.
What does this implement/fix?
Appeases the linter for all current errors related to stats, to stop potential future CI fails.
Additional information
Alternatively, we could use noqa, or even make the linter ignore these files, if that seems more appropriate.

I don't think this needs a commit ignore. It's a meaningful improvement to not redefine these functions once per iteration.

authors: lucascolley mdhaber


text:
MAINT: signal: lombscargle docstring tweaks

Reference issue
Closes https://github.com/scipy/scipy/issues/2162
Also addresses passing in inputs as lists, per https://github.com/scipy/scipy/issues/8787
What does this implement/fix?
Tweaks to the docstring to make the measurement baseline requirement more explicit, as well as other minor corrections.
Additional information
A few other minor corrections are being made that were noticed while updating the text suggested in the referenced issue.

@DietBru You had suggested in https://github.com/scipy/scipy/pull/21277#discussion_r1694270980 that I could use _rename_parameter() to rename the misleading x parameter to t in the function. Since I'm going for broke on refinements at this point, could I go ahead and commit that change here? Also, if so, does dep_version need to be specified?

@tylerjereddy Not sure when the cutoff date is, but this might also be worthwhile to get into 1.15.0.

Would you be able to tackle https://github.com/scipy/scipy/issues/8787#issuecomment-2421424091 here too?
I think because it's important to get these changes merged it would be best if renaming of arguments is left to a different pr as there might be more discussion required for that.

Would you be able to tackle #8787 (comment) here too?
I'll take a look at it today.

I think because it's important to get these changes merged it would be best if renaming of arguments is left to a different pr as there might be more discussion required for that.
Understood.

I can reproduce the error in https://github.com/scipy/scipy/issues/8787 , but I haven't yet figured out the solution.

I think this might be related to the "nyquist frequency" (not exactly the same thing for uneven sampling). I'm going to investigate further to see if I can test for this ahead of time instead of just throwing divide by zero error.

Yup. It is, but I don't see any way to test for this ahead of time, short of doing all of the calculations ahead of time.
All of the sample times are multiples of 1000 s, which leads to a "nyquist" frequency of 0.0031415926535897933 rad/s. One of the freqs (freq[0]) is exactly 5x this (0.015707963267948967 rad/s), and causes D to equal zero. However, if you take some smaller or larger multiple of the "nyquist", the D is always very small (< 1e-16), but not zero. So this is just a random numerical fluke.
As long as at least one sample times isn't a multiple of 1000, or as long as none of the freqs are 5x the "nyquist" it won't fail.

Very dumb solution. But it works. Just add these lines:
# at beginning
eps = np.finfo(freqs.dtype).eps

# when calculating D
D = CC * SS - CS * CS + eps

@neutrinoceros @jakevdp @mhvk @dhomeier @pllim Would one of you mind checking if the final commit causes any issues with astropy's tests? I was looking for a robust solution to the inputs given in the referenced issue (https://github.com/scipy/scipy/issues/8787). And this was the smallest, most robust, way to prevent any possible divisions by zero.

Huh, so you were able to reproduce gh-8787; I guess it is platform-dependent. I'd suggest adding the test and running that on CI separately to show that CI was sensitive to the failure to begin with, otherwise the unit test does not really demonstrate the fix.
If you can reproduce that, what about gh-13812? I had the file analyzed for safety before opening it; seemed OK, and did seem to contain just two CSV files.
Looks like there was also some work to avoid a zero-division error in the past (gh-3787) but perhaps that is different?

otherwise the unit test does not really demonstrate the fix.

I haven't added a test specifically for this numerical issue yet.

Thanks for the ping, @adammj  . Would https://github.com/astropy/astropy/pull/17211 help?

Re: https://github.com/scipy/scipy/pull/21721#issuecomment-2423246777
Ooops... CI failed to build scipy from source.

p.s. Failed to build locally too on WSL2 via pip install git+https://github.com/adammj/scipy.git@lombscargle

@mdhaber I changed the added test to go back to the values provided in the original issue. Without the previous commit (D=eps) this test will fail. However, it passes now.

p.s. Failed to build locally too on WSL2 via pip install git+https://github.com/adammj/scipy.git@lombscargle

I managed to build locally on macOS-14.7-arm64-arm-64bit-Mach-O against OpenBLAS 0.3.28 and ran our full periodogram test suite successfully, but I don't think we have any tests pushing the precision to its limits.

Here's some results with both float64 and float32, showing the same test data, but with different frequency values.
I can only get it to fail on this one multiple (I haven't exhaustively tested this). But I wanted to show that even when the value of D < eps, that the calculations still work. It is only exactly D==0 that is the problem.

Whoops, I saw @dhomeier's comment only after running astropy's test suite myself... anyway, seconded !

@DietBru You had suggested in #21277 (comment) that I could use _rename_parameter() to rename the misleading x parameter to t in the function. Since I'm going for broke on refinements at this point, could I go ahead and commit that change here? Also, if so, does dep_version need to be specified?

It is @j-bowhay not me who made the suggestion :smiley: Hence, to I do not have any experience with _rename_parameter().
My 2 cents are to do this in a separate pull request, because reviewing a single change is always a bit easier.

_rename_parameter() to rename the misleading x parameter to t in the function. Since I'm going for broke on refinements at this point, could I go ahead and commit that change here? Also, if so, does dep_version need to be specified?

dep_version is specified if you want to deprecate and eventually stop accepting x. it is more disruptive because users will get a warning that they need to change their code to use t if they are using x, but it will allow you to remove the decorator (and its associated performance overhead) and any mention of x in the future. If this is considered worth the disruption, you would specify 1.15.0 as the version; if you're happy with leaving it in place indefinitely, you can leave it unspecified. Either way, yeah, it would be good to go in a separate PR. You would probably also want to change most existing tests that use the old name to the new name (but you'll always want to have at least one test with each to confirm that the decorator is working). Then you can post a message on the forum justifying the choices and ask for feedback there.

@DietBru here's a suggested change that makes it clear that we're just trying to prevent the divide-by-zero, not attempting to "massage" the equations for any other purpose.
I haven't found a better, more specific exception to catch this, as it's actually emitted as "RuntimeWarning: divide by zero encountered in scalar divide".
# calculate a and b
a_numerator = (YC * SS - YS * CS)
b_numerator = (YS * CC - YC * CS)
try:
    # where: y(w) = a*cos(w) + b*sin(w) + c
    a[i] = a_numerator / D
    b[i] = b_numerator / D
    #  c = Y_sum - a * C_sum - b * S_sum  # offset is not useful to return
except RuntimeWarning:
    # there can be spurious numerical issues around the "pseudo-Nyquist"
    a[i] = a_numerator / (eps * math.copysign(1.0, D))
    b[i] = b_numerator / (eps * math.copysign(1.0, D))

If I understand what you want to do then this is a 2x2 linear system perturbation
$$
\left(
\begin{bmatrix}
CC & CS \
CS  & SS
\end{bmatrix} + \epsilon I
\right)
\begin{bmatrix}
x_1 \
x_2
\end{bmatrix} =
\begin{bmatrix}
y_1 \
y_2
\end{bmatrix}
$$
with the matrix on the left is rank deficient. But adding eps to determinant does not achieve this. So it is not doing what you want to do.
Here my small objection is about inverting this array. As the general mantra says don't invert the matrix, here same applies. You can eliminate this symmetric  2x2 array (depending on which diagonal is larger) and modify the resulting corner if it is exactly 0. Then this eps modification would indeed be a perturbation to the rank deficiency.

@ilayn I think I follow. And, this makes me realize I should’ve gone looking for common acceptable solutions to these numerical edge cases.
I was looking for a way to minimize the number of calculations and conditions that don’t exist in the paper, both to prevent slowing down the loop, but also so that it’s easier for the reader to follow what the code is doing and its relation to the formulas in the paper. Basically, in this very rare case, the solution is probably nonsense. But the values nearby are fine, so I’m trying to find a fix that is “imperceptible”.
I’ll take a look for some more robust numerical solution. But I’m curious if you already have specific code in mind.

You can also solve the system;
$$
\begin{bmatrix}
CC & CS \
CS  & SS
\end{bmatrix}
\begin{bmatrix}
x_1 \
x_2
\end{bmatrix} =
\begin{bmatrix}
y_1 \
y_2
\end{bmatrix}
$$
So if $CS=0$, then it is diagonal system. If $CC = 0.0$ then we can solve $y1= CSx_2, y_2=CSx_1 + SSx_2$, which is consistent. If $CC \neq 0$, then we "Gaussian eliminate" the second row with $-CS/CC$ hence solve triangularized systems. This is what LU solvers do anyways and how they detect exact 0.0s if any.

So that's a problem, there are no zeros in the equation/matrix (for this specific example from the linked issue).
CC =  0.09549150370681751
SS =  0.9045084962931825 (always 1-CC)
CS = -0.29389262737712285

It just works out that D is calculated to be 0 in the equation D = CC * SS - CS * CS. However, if I create a matrix and ask numpy for the determinate, it is not 0 (but smaller than eps).
M = np.array([[CC, CS], [CS, SS]], dtype=a.dtype)
np.linalg.det(M)  # returns -1.4257357797566966e-17

Instead of re-inventing the wheel, I can just use scipy's LU solver. But, in this case, it's not doing anything special, per se, it's just that due to numerical differences in the paths (types and order of operations) it works out.
if D != 0:
    a[i] = (YC * SS - YS * CS) / D
    b[i] = (YS * CC - YC * CS) / D
else:
    # If D==0, this is a rare numerical issue that can occur around the
    # "pseudo-Nyquist". Use LU solver.
    lu, piv = lu_factor(np.array([[CC, CS], [CS, SS]], dtype=a.dtype))
    ab = lu_solve((lu, piv), np.array([YC, YS], dtype=a.dtype))
    a[i] = ab[0]
    b[i] = ab[1]

Comparing the results between the two branches for everywhere that D != 0, they are the same within 1.8e-12.

Sorry  for leading you into wrong direction earlier, by not reading carefully :sweat_smile:. If $D$ is too close to zero, a ValueError should be raised.
This can be justified by looking into the derivation from Lomb. The $i$-ith measurement equation is
$$
y_i = a\cos(2\pi f t_i) + b\sin(2\pi f t_i) + v_i
$$
and the target function is
$$\begin{aligned}
J &= \frac{1}{2}\sum_i \Big|y_i - a\cos(2\pi f t_i) - b\sin(2\pi f t_i)\Big|^2 \
&= \frac{1}{2}\sum_i \Big(y_i^2 - 2y_i\cos(2\pi f t_i)a - 2y_i\sin(2\pi f t_i)b + \cos^2(2\pi f t_i) a^2- \sin^2(2\pi f t_i)b^2
+ 2ab\cos(2\pi f t_i)\sin(2\pi f t_i)\Big)\
&= \frac{1}{2}\left(\sum_i y_i^2 - 2a YC - 2b YS - ab CS + a^2 CC + b^2 SS \right)
\end{aligned}$$
This let's us write
$$\frac{d}{da}J = a\sum_i \cos^2(2\pi f t_i) + b\sum_i\cos(2\pi f t_i)\sin(2\pi f t_i) - \sum_i y_i\cos(2\pi f t_i) =: a CC + b CS - YC\stackrel{!}{=} 0 $$
$$\frac{d}{db}J = b\sum_i \sin^2(2\pi f t_i) + a\sum_i\cos(2\pi f t_i)\sin(2\pi f t_i) - \sum_i y_i\sin(2\pi f t_i) =: b SS + a CS - YS\stackrel{!}{=} 0 $$
which results in
$$
\begin{bmatrix}
CC & CS \\ CS & SS
\end{bmatrix}\begin{bmatrix}
a \\ b
\end{bmatrix} =
\begin{bmatrix}
YC\\ YS
\end{bmatrix}
$$
of which the symbolic solution for $[a\ b]^T$ is implemented, with $D$ being the determinant of the left-hand matrix.  So if $D$ is zero,  $[a\ b]^T$ is undetermined.
scipy.linallg.solve could be used for a simple implementation. Perhaps something like this (did not verify if correct):
AA, bb = np.array([[CC, CS], [CS, SS]]), np.array([YC, YS])
try:
    xx = solve(AA, bb)
except LinAlgError, LinAlgWarning:
    raise ValueError("Could not find solution ...")
a[i], b[i] = xx[0], xx[1]

Just to clarify: I checked that the symbolic solution of the vector matrix equation is what is implemented. I am not sure anymore, if the derivation by minimizing $J$ is correct...

Sorry for leading you into wrong direction earlier, by not reading carefully 😅. If D is too close to zero, a ValueError should be raised.
This can be justified by looking into the derivation from Lomb. The i -ith measurement equation is
y i = a c o s  ( 2 π f t i ) + b s i n  ( 2 π f t i ) + v i
and the target function is
J = 1 2 ∑ i | y i − a c o s  ( 2 π f t i ) − b s i n  ( 2 π f t i ) | 2 = 1 2 ∑ i ( y i 2 − 2 y i c o s  ( 2 π f t i ) a − 2 y i s i n  ( 2 π f t i ) b + c o s 2  ( 2 π f t i ) a 2 − s i n 2  ( 2 π f t i ) b 2 + 2 a b c o s  ( 2 π f t i ) s i n  ( 2 π f t i ) ) = 1 2 ( ∑ i y i 2 − 2 a Y C − 2 b Y S − a b C S + a 2 C C + b 2 S S )
This let's us write
d d a J = a ∑ i c o s 2  ( 2 π f t i ) + b ∑ i c o s  ( 2 π f t i ) s i n  ( 2 π f t i ) − ∑ i y i c o s  ( 2 π f t i ) =: a C C + b C S − Y C = ! 0 d d b J = b ∑ i s i n 2  ( 2 π f t i ) + a ∑ i c o s  ( 2 π f t i ) s i n  ( 2 π f t i ) − ∑ i y i s i n  ( 2 π f t i ) =: b S S + a C S − Y S = ! 0 which results in
[ C C C S C S S S ] [ a b ] = [ Y C Y S ]
of which the symbolic solution for [ a b ] T is implemented, with D being the determinant of the left-hand matrix. So if D is zero, [ a b ] T is undetermined.
scipy.linallg.solve could be used for a simple implementation. Perhaps something like this (did not verify if correct):
try:
    a[i], b[i] = solve([[CC, CS], [CS, SS]], [YC, YS])
except LinAlgError, LinAlgWarning:
    raise ValueError("Could not find solution ...")

I think we need to slightly careful in adding a linalg.solve I would image it's significantly slower than inverting the system by hand.

I think we need to slightly careful in adding a linalg.solve I would image it's significantly slower than inverting the system by hand.

Good point—would have to be verified. If the penalty is not to great, it is an elegant way of avoiding thinking about condition numbers.

I think you all are going to hate me, but I think going with the fully vectorized version and using the tau offset (so that I can remove the offending CS variable), makes it much easier to prevent the rare division by zero errors. I tested this against the current version in all possible combinations and the numerical differences are miniscule. It also (on my machine) passes all of the tests.

I would potentially consider splitting this pr in two, the handling of lists and docstring changes could probably be merged quickly (and the list handling is needed before the next release)

Done. Reverted this PR to only the docstring and asarray changes. I wasn't sure of the best way to continue with the discussion and code changes that were discussed for 8787, but I assume I'll have to do some work on the other branch once this one gets accepted.

The test failure seems unrelated.
Looks good to me for merging—unless @j-bowhay has a different opinion.

authors: DietBru adammj dhomeier ilayn j-bowhay mdhaber neutrinoceros pllim


text:
BUG: stats: fix nan result from multivariate_normal.cdf (#7669)

This pull request fixes nan results from multivariate_normal.cdf when the distribution is bivariate (Issue #7669). The underlying Fortran code in mvn.mvnun uses a dedicated function to handle the bivariate case and causes problems when called with negative infinity as the lower bound. As a solution, I replaced mvnun with mvndst and do the preprocessing of mvnun in Python. I also added an additional test for the bivariate case.

Isn't the problem actually that mvnun does not set the infin flags correctly?
Here's a simpler fix doing that: https://github.com/asnelt/scipy/pull/1
It seems to solve the issues without the more complicated Python code changes.

Just some supporting evidence:
I wanted to see if the changes might affect what I have in statsmodels sandbox, but I was avoiding mvnun (maybe because it didn't work for me) and use mvndst directly with equivalent adjustments to infin, AFAICS
https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/distributions/extras.py#L1064

In it goes, thanks all!

authors: asnelt josef-pkt pv rgommers


text:
Typos & Bad Links

Typos in "Tutorial"

"Gaubao" should be "Guabao".

"non-egative" should be "non-negative".

We should press \ to input Unicode characters.

Bad Links in "GCL Overview"

The link in leads to "https://scmlab.github.io/guabao/pages/pages/4-references.html", but it should lead to "https://scmlab.github.io/guabao/pages/4-references.html".

Thank you for your interest in this project and for spotting these typos! Sorry that it took so long to respond --- we were preparing a paper on Guabao and were too occupied.
I believe that these issues are fixed now.
If you have used Guabao and found bugs/errors, feel free reporting them here:
https://github.com/scmlab/gcl
Thank you again!

repo: scmlab/guabao

license: MIT


text:
Add support for SRUpy library

see #5

A final few comments and then all that needs doing is making the tests run. For that you just need the EUROPEANA_API_KEY secret in your fork, with your API key.

Sorry, I don't know why this fails. In my fork it validates just fine ...

I see. Very weird. Ah well. In that case I shall merge.

authors: alueschow scmmmh

repo: scmmmh/polymatheia


text:
Fully migrate to the Flask backend

[ ] NodeJS codebase should be removed after fully migrating to Flask

@Anmolbansal1 Can we remove the NodeJS codebase now?

repo: scorelab/fact-Bounty


text:
Remember install

Remember the installation status of packages across app restarts

Codecov Report

Merging #25 into master will decrease coverage by 5.51%.
The diff coverage is 46.01%.

@@            Coverage Diff             @@
##           master      #25      +/-   ##
==========================================
- Coverage   65.54%   60.03%   -5.52%
==========================================
  Files          24       24
  Lines         595      663      +68
  Branches       25       31       +6
==========================================
+ Hits          390      398       +8
- Misses        199      257      +58
- Partials        6        8       +2

Impacted Files
Coverage Δ

src/app/core/services/electron.service.ts
15.38% <0%> (ø)
:arrow_up:

src/app/core/services/mocks.ts
81.81% <100%> (+1.81%)
:arrow_up:

src/app/core/services/thunderstore.service.ts
50% <33.33%> (-22.1%)
:arrow_down:

src/app/core/services/database.service.ts
59.37% <35%> (-29.52%)
:arrow_down:

src/app/core/models/package.model.ts
43.24% <36.36%> (-3.19%)
:arrow_down:

src/app/core/services/package.service.ts
43.51% <40.54%> (-1.49%)
:arrow_down:

...selection/package-table/package-table.component.ts
56.79% <46.15%> (-2.12%)
:arrow_down:

...election/package-table/package-table-datasource.ts
45.71% <72.22%> (-0.19%)
:arrow_down:

...selection/packages-page/packages-page.component.ts
72.72% <75%> (-15.51%)
:arrow_down:

src/app/shared/selection-changeset.ts
82.6% <0%> (-17.4%)
:arrow_down:

... and 4 more

Continue to review full report at Codecov.

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


text:
Get crop coordinates on original image

Hello! Thank you for making and sharing cropit!!
For a project, I needed to only get the cropping coordinates on the original image. I needed to know the two (x1, y1) (x2, y2) points on the original image that would give me the selected part of the image. However, I couldn't manage to do this with the methods available in cropit by itself. It would be great to have a method that would give you these values because otherwise they're kind of tricky to obtain.
This is what I ended up doing (its not perfect and probably will only work with the settings I'm currently using):
var zoom = imgCropper.cropit('zoom');
var offset = imgCropper.cropit('offset');
var previewSize = imgCropper.cropit('previewSize');

var exportzoom = 1 / zoom;
var xstart = Math.abs(Math.floor(offset.x * exportzoom));
var ystart = Math.abs(Math.floor(offset.y * exportzoom));

var xend = Math.floor(exportzoom * previewsize.width) + xstart;
var yend = Math.floor(exportzoom * previewsize.height) + ystart;

Well, I guess that's all, let me know if you'd like to add a feature like this to cropit and I'd be happy to contribute.

This solution works well with the PHP ImageMagick crop method if you require compatibility with older versions of IE.

authors: Naph rafadev

repo: scottcheng/cropit

license: mit

license_source: bigquery


text:
Style the Machine Edit page

Step 1: @ryantg Create a mockup.
Step 1 status: Incomplete.

Details are in the mockup (I just wrote notes rather than actually mocked it up).
This feels like weak style suggestions on my part... but still I hope it really helps the page become more readable. We'll see.
Shit, I need to look at a location that has high scores, and then suggest style changes to that.

Should all be addressed here:
https://github.com/scottwainstock/pbm-ios/commit/738043d07ddde7c3695f95ac0c82716637d1d0cd

Small adjustment: When I said to indent the "Updated on" four spaces, can you change that to TWO spaces?
High scores:
333,333,333
Scored on: Nov 29, 2016 by tzr
Details: New line for the "Scored on" with a two space indent. Color #888888 for that line.

Here's yer formatting:
https://github.com/scottwainstock/pbm-ios/commit/e665c73380e07fe3c476db6a94192be3a097c09c

I'll be the judge of that.

authors: RyanTG scottwainstock

repo: scottwainstock/pbm-ios


text:
fix nc capabilities re to allow for namespaced tags

Junos uses namespaced tags in their hellos. this caused no matches for capabilities in scrapligo
the following re allows namespaced tags as shown here https://regex101.com/r/w1M6Lp/1

LGTM!

authors: carlmontanari hellt

repo: scrapli/scrapligo


text:
Handle exceptions in commands

The execute_command() method in the command classes should handle exceptions related to the arguments or the input config file.

Closed with PR #22

authors: AlexMathew scrappleapp

repo: scrappleapp/scrapple


text:
Safe to include token?

Sanity Studio is a client side application, so anything we put into it must be non-sensitive. If I enter my imageshop token into the config, it'll show up in the client bundle, which in turn will make it available to any attacker that looks through that bundle.
In other words, if we include the imagebank token, it's available to "everyone".
Is there a way to avoid this? And if not, do you offer a read-only token, that only lets us read from our database? We would hate waking up one morning with a bunch of nasty photos in our library being uploaded from an attacker.

Administrators in Imageshop can themselves issue tokens and change access rights for token. It is possible to prohibit uploading for the token, which will make them in effect read only and no files can then be uploaded or replaced with the token. If you in addition restrict the token only to interfaces which are public or a special interface intended only to be used with web images, the risk is minimal. It is recommended to restrict the access of the token as much as possible. Read more here about how to issue tokens in Imageshop.

Thank you for reporting :) fixed in 1.3.0

authors: hognescreentek peec selbekk

repo: screentek/Sanity


text:
Create script backup

Save snapshots of the Firebase database and users.

Done in 1.3

repo: scriptPilot/app-framework


text:
OVERLAPS word is not highlighted

Describe the bug
overlaps word is not highlighted (used in postgres)
To Reproduce
Test query:
SELECT "huddles".* FROM "huddles" INNER JOIN "huddle_guests" ON "huddles"."id" = "huddle_guests"."huddle_id" WHERE "huddle_guests"."user_id" IN (2) AND "huddles"."cancelled_at" IS NULL AND ("start_date", "end_date") OVERLAPS ('2021-08-21 08:50:00.000', '2021-08-21 09:35:00.000')

Expected behavior
Should be highlighted same as keyword.
Screenshots

Versions
sql-highlight: 4.0.0
node: 16.0.0

Yup, sounds like a fair point. I'll merge your PR right away. Thanks!

@scriptcoded thank you ❤

authors: scriptcoded vladshcherbin

repo: scriptcoded/sql-highlight


text:
🛑 Github Insights is down

In 26eee9e, Github Insights (https://github-insights.atanas.info) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Github Insights is back up in 3e7b1f9.

repo: scriptex/uptime


text:
Change scss-lint executable to scss_lint

see https://github.com/brigade/scss-lint/commit/c1e311b495cfd189f63aa8cc821ca036b47a9fe9 - this is now the proper executable per Gem name standards

I read the link you pointed me to, and I reached a different conclusion.  Syntastic cares about executables rather than gem names, and as of 5b2dbfd the executable is still named scss-lint.  When / if that changes, please post a new PR with proper version checks and fallbacks for backwards compatibility.  Until then, sorry but no.

repo: scrooloose/syntastic

license: WTFPL


text:
Initial Site Administration

[Migrated from Assembla ticket 2 - reported by @reid-spencer on 2014-10-11 16:31:24.000]
Scrupal will provide an administration module that allows the various modules that are running to be configured. All meta information and even instance content can be modified with the administration interface, given the appropriate access rights.
This initial version of administration will:

Permit each site's title, default theme, and initial (home) page to be configured.
Not address authorization issues at this time

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-07 00:53:43.000]
VariantRegistry - InProgress #2

Move the more complicated node classes out of API into Core
Provide VariantRegistry for registration of storable variant classes
Add test cases to deal with auto-generated BSONObjectID _id field
Minor code cleanup in Context, BSONHandlers
Extract HtmlHelpers from Node.scala to its own source file
Put _id field in each Node case class so it is included by the BSONHandler
Provide VariantRegistry instances for Site and Node subclasses

Committed to: scrupal:master
Commit: [[r:bc521434f4b6aa69e51426d95c8e53a2c8e5b276|scrupal:bc521434f4]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-07 06:04:17.000]
Start On Admin App - InProgress #2

Make PathMatcherToAction a base class of PathToAction
Define PathToNodeAction as a subclass of PathMatcherToAction
Also make PathToNodeActionFunction for more general action construction
Utilize PathToNodeAction to remove redundant code
Define an AbstractHtmlNode node class so we can use arbitrary Html generation templates
Implement a rudimentary version of AdminApp and some templates to go with it.
Handle a None.get situation in ActionProviderController

Committed to: scrupal:master
Commit: [[r:193f46b9f4ab3b93a3776e41709530ef2680cf8e|scrupal:193f46b9f4]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-08 04:25:03.000]
Make Admin Site Based - InProgress #2

Replace Scrupal & Site sections with Database and Configuration
Fix the title to indicate the site and user
Put Revolver on the root project where the main program is
List the enablement in configuration

Committed to: scrupal:master
Commit: [[r:2d07d06e98ee5675d4dd1cb551f66e0fdc71d167|scrupal:2d07d06e98]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-15 22:32:33.000]
Generalize Routing - InProgress #2

Make the ActionProviderController unaware of Entities and only deal with ActionProvider
Split various traits out of ActionProvider and generalize it
Separate the notion of a DelegatingActionProvider with subordinates from PathMatcherToActionProvider with a set of PathMatcherToActions
Move ActionProvider stuff to its own compilation unit.
Adjust the dependent classes as necessary.
Implement a NodeProvider object for providing Node content as a result.
All this in an effort to make the admin interface very responsive and flexible when the OPA is written.

Committed to: scrupal:master
Commit: [[r:76f785c543bce49ca309298f480c293d362e5ff6|scrupal:76f785c543]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-16 04:58:56.000]
Fix Bugs In JSON Conversion - InProgress #2

Issues with ReactiveMongo .equals methods thwarted equality tests

Committed to: scrupal:master
Commit: [[r:25f98fa1254d3d8f18f89a553b7d6260d5e21e27|scrupal:25f98fa125]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-12 13:50:31.000]
Improve Registrable Safety - InProgress #2

Use a typed self in Registrable so asT method is not needed.
Use early initialization to ensure that id and _id get defined early enough.
Simplify the class hierarchy so conglomerates like VariantStorableRegistrable are not needed.
Make abstract base classes require an id parameter to simplify subclass construction.

Committed to: scrupal:master
Commit: [[r:1c06f9f4a7e23f7f2433febe6051556e14d4db4e|scrupal:1c06f9f4a7]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-08 22:24:25.000]
Implement BSON<->JSON conversion - InProgress #2

Make scrupal-db depend on play-json which we use for the conversions
Add a SONConversion file to scrupal-db to do the conversion
Add a SONConversionSpec file to test the conversions
Upgrade project files to 14.0.2 version of IDEA

Committed to: scrupal:master
Commit: [[r:a6b279a41710690727fbb4cf72d33e947bda57f9|scrupal:a6b279a417]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-09 00:25:16.000]
Fix a typo - InProgress #2

Make an error message readable.

Committed to: scrupal:master
Commit: [[r:b35b4314ff454bf9573c1f8f8fafaea138be7692|scrupal:b35b4314ff]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-20 22:55:32.000]
MINOR Reorganization - InProgress #2

Merge scrupal-http into scrupal-core
Remove scrupal-js
Fix references to scrupal-api
Merge scrupal-api and scrupal-http documentation into and scrupal-api

Committed to: scrupal:master
Commit: [[r:e46b790db94901607dca901e429333c9ae22c0d3|scrupal:e46b790db9]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-20 00:27:48.000]
MAJOR Reorganization - InProgress #2

Abandon Twirl in favor of Scalatags: replace Twirl templates, remove dependencies, adjust documentation
Merge scrupal-core back into scrupal-api
Simplify HTML layout.
Break apps, types, nodes and entities out to separate packages

Committed to: scrupal:master
Commit: [[r:a636bd1b9131ec632220006b07618cdff729df54|scrupal:a636bd1b91]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-17 04:27:01.000]
Get correct name for Site - InProgress #2
Committed to: scrupal:master
Commit: [[r:93d57cf50e32e3f551f2e0cc602cfd00e2c7836b|scrupal:93d57cf50e]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-17 04:27:03.000]
Initial OnePageApp Implementation - InProgress #2

Change project to include Scala.js
Incorporate scalajs-angular
Incorporate scalajs-dom
Incorporate scalatags
Adjust project settings in .idea
Fix a bug in spray marshaller for OctetsResult (wrong content type)
Implement a very rudimentary OnePageApp placeholder that loads angularjs

Committed to: scrupal:master
Commit: [[r:a46e3a1f4aa2ed3df02e1a7688d54ad1249b468d|scrupal:a46e3a1f4a]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-18 16:38:09.000]
Baby Steps Toward Scalatagsification - InProgress #2

Use scalatags 0.4.3-M1
Use scalajs 0.6.0-M2
Update dependencies to use scalajs 0.6.0-M1/M2
Use sbt 0.13.7
Add a Scalatags errors module for HTTP fragments for generating errors
Add Scalatags pages for NotFound and Forbidden HTTP results
Make Alert generate Scalatags instead of Twirl
Provide a "kinds" accessor on VariantRegistry
Allow the kinds of Sites to be obtained using VariantRegistry.kinds

Committed to: scrupal:master
Commit: [[r:22a09293c82dae0cdddabc25f9e058f53907d5b7|scrupal:22a09293c8]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-17 04:27:02.000]
Improvements to Type - InProgress #2

Remove the defunct asT methods
Add RegexType to validate a regular expression pattern
Add SelectionType to validate a selection from a Seq[String]
Other minor corrections

Committed to: scrupal:master
Commit: [[r:53a898bf58a0e197f2bcb51b795ad53ecde7bee6|scrupal:53a898bf58]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-17 19:49:13.000]
Convert Twirl templates to Scalatags - InProgress #2

Simplify our HTML life.

Committed to: scrupal:master
Commit: [[r:ad691dc75b04cfd56494c03ffda9bee4c00acadf|scrupal:ad691dc75b]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 01:55:35.000]
Fix Startup Boot Issues - InProgress #2

Make scrupal.core.http.Boot have a "run" method instead of doing its work in the constructor.
Invoke that run method in scrupal.core.Boot after we've opened the Scrupal object.

Committed to: scrupal:master
Commit: [[r:bc8bc1f6d96df8eb24e7bd4329c938c70fca004d|scrupal:bc8bc1f6d9]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-21 12:46:06.000]
Get Ready For JS in scrupal-opa - InProgress #2

Fix IntelliJ's issue with scala-js plugin
Remove jrebel_project.xml
Remove scrupal-js-build.iml
Remove libraries that are no longer used.

Committed to: scrupal:master
Commit: [[r:1eef46562b0d5f9eb9e1997be147f33e47c7a302|scrupal:1eef46562b]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 01:54:11.000]
Fix Startup Logging - InProgress #2

Use akka-slf4j with logback-classic

Committed to: scrupal:master
Commit: [[r:956ffd9d98b396ec11f19c339ccad8e42c6a9c75|scrupal:956ffd9d98]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-21 02:32:17.000]
Dependency Version Refresh - InProgress #2

Upgrade versions of: Play, angularjs, angular-ui,
Remove cruft from dependencies

Committed to: scrupal:master
Commit: [[r:b590290e69a8f19663a64fa4949450f66c62ee45|scrupal:b590290e69]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-22 01:24:12.000]
Get "Hello World" OPA Working - InProgress #2

Lots o' fixes

Committed to: scrupal:master
Commit: [[r:552fa8ebff30c50d314dd193cc53febf7b0b10c4|scrupal:552fa8ebff]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 01:52:50.000]
Trivial change- InProgress #2

Remove an unnecessary "val" from a case class argument.

Committed to: scrupal:master
Commit: [[r:e3de913089a9a730ee65c77cb9622b39d4530c41|scrupal:e3de913089]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 01:56:32.000]
Rename Project vals - InProgress #2

Append _proj to the project values in the build to make it clear they are projects.

Committed to: scrupal:master
Commit: [[r:8581773815db99b69ab5ac273bd6ef293c252188|scrupal:8581773815]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 06:04:19.000]
Start Implementation Of Forms - InProgress #2

Add utility functions in core.html.forms for generating form related HTML tags
Enhance the coding module for Fields, FieldSets and Forms in api.Forms
Augment the FormsSpec test cases to handle changes in api.Forms
Implement more extractors in BSONSettingsInterface and subclasses
Be more strict about accepted paths in WelcomeSite and OnePageApp
Move ConfigWizard from scrupal.config to scrupal.core.apps

Committed to: scrupal:master
Commit: [[r:5d2bfed813dc1004da2c6fb79933bec8fa13a35a|scrupal:5d2bfed813]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 22:32:00.000]
Prepare To Separate scrupal-opa - InProgress #2

IntelliJ can't handle a Scala.js module in a Scala project
Prepare the repository to split scrupal-opa module to its own repository.
This patch allows IntelliJ to build and run Scrupal again.
It also consolidates all OnePageApp things into scrupal-opa.

Committed to: scrupal:master
Commit: [[r:70c1ca953734c1e211f9ae1e703a4499de9db90e|scrupal:70c1ca9537]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 02:06:54.000]
Fix assets_path - InProgress #2

Paths were for 0.1-SNAPSHOT but we're building 0.2-SNAPSHOT

Committed to: scrupal:master
Commit: [[r:91a5c58bae03ab2e03e4ab5b68b6fa6f6214252e|scrupal:91a5c58bae]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-24 02:06:09.000]
Configure Akka Logging - InProgress #2

Use the SLF4J logger with its filters.

Committed to: scrupal:master
Commit: [[r:cf3ef6f3779cba39151a1f4fda29136f32d182db|scrupal:cf3ef6f377]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 18:31:34.000]
OPA Experimentation - Inprogress #2

Get RequireJS integrated
Attempt to initialize Scrupal controller
Add BSON and EntityService as TODO reminders
Extract OPAPage to the scrupal-opa module

Committed to: scrupal:master
Commit: [[r:c9ab4aea02e01f5f268405f678e76f86e34ee35b|scrupal:c9ab4aea02]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 16:52:11.000]
Add More Form Testing - InProgress #2

Make sure a form can render itself correctly
Check a few field types for rendering
Make SelectionField sort its options by key
Fix TimestampType to utilize sane max value for DateTime
Add an UnspecificQuantity_t to SelectionType for fuzzy logic quantities

Committed to: scrupal:master
Commit: [[r:9414484829cc483be975216dd1ce073ca10177f1|scrupal:9414484829]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 23:54:36.000]
OPA Experimentation - Inprogress #2

Get RequireJS integrated
Attempt to initialize Scrupal controller
Add BSON and EntityService as TODO reminders
Extract OPAPage to the scrupal-opa module

Committed to: scrupal.scrupal-opa:master
Commit: [[r:2:6bd0f96f4294fc3e115ab2bda2ad593687f279e6|scrupal.scrupal-opa:6bd0f96f42]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 23:54:34.000]
MINOR Reorganization - InProgress #2

Merge scrupal-http into scrupal-core
Remove scrupal-js
Fix references to scrupal-api
Merge scrupal-api and scrupal-http documentation into and scrupal-api

Committed to: scrupal.scrupal-opa:master
Commit: [[r:2:fc9937b40022c1818eb0a080dddfbe73203774cc|scrupal.scrupal-opa:fc9937b400]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 23:54:37.000]
Prepare To Separate scrupal-opa - InProgress #2

IntelliJ can't handle a Scala.js module in a Scala project
Prepare the repository to split scrupal-opa module to its own repository.
This patch allows IntelliJ to build and run Scrupal again.
It also consolidates all OnePageApp things into scrupal-opa.

Committed to: scrupal.scrupal-opa:master
Commit: [[r:2:6381bac8c1e59d900333248c69cde31c13861029|scrupal.scrupal-opa:6381bac8c1]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 23:54:35.000]
Get "Hello World" OPA Working - InProgress #2

Lots o' fixes

Committed to: scrupal.scrupal-opa:master
Commit: [[r:2:41a0f082cd5650a3ed8cb77e6eca6af2277aee9b|scrupal.scrupal-opa:41a0f082cd]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-28 22:39:46.000]
Reinstate WelcomeSite - InProgress #2

When no sites are available, WelcomeSIte should be shown
Even if the schema fails and throws an error, make WelcomeSite available

Committed to: scrupal:master
Commit: [[r:e73d392d9d42604893fb155f78c9b4e2d6eac20a|scrupal:e73d392d9d]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 04:49:52.000]
Minor Cleanup in Type class - InProgress #2

Remove import cruft
Use def in trait, not val

Committed to: scrupal:master
Commit: [[r:108330f1a8296f7ef9b545271cfd5e1fc1ebaf6f|scrupal:108330f1a8]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-29 00:40:09.000]
Get Documentation Working Again - InProgress #2

Create a BootstrapPage for pages that use JQuery and Twitter Bootstrap
Remove crufty libraries and modules from .idea directory
Fix some documentation.
Remove the scrupal-opa directory as it is now its own git repository
Remove dependencies we should not use in scrupal
Remove last vestiges of scala.js in this project.

Committed to: scrupal:master
Commit: [[r:1f2e8d4f74561c5ed398312263b3949bd9583e54|scrupal:1f2e8d4f74]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 04:47:24.000]
Fix DataCache Load - InProgress #2

Load the data cache after all the sites have been loaded

Committed to: scrupal:master
Commit: [[r:d6f7104cb1dfd0e67b36ba550f67f2d76a839194|scrupal:d6f7104cb1]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-03 00:50:18.000]
Form Rendering & Posting - InProgress #2

Make forms generate a default value from the field defaults
Make forms provide actions for displaying the form and accepting results
Generalize code that implements ActionProvider to allow for method as well
Add an HTML5Validator test object and use it to validate form output
Make request a required field in Context, not an option
Remvoe application from the Context as it is too detailed
Fix form validation code to work properly.
Make WelcomeSite have a name distinguishable by the Scrupal it is instantiated from (helps with testing)
Move NodeSite to the scrupal.core.sites package
Adjust spray routing to utilize the new ActionExtractor and ActionProvider hierarchy
Minor fixes to ScredisCache
Fix error message reporting to the browser to include the payload/entity

Committed to: scrupal:master
Commit: [[r:4c74a543d4152b9646b05ad4421711363d7ad469|scrupal:4c74a543d4]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-03 19:18:50.000]
Teach Validation to Associate Errors With BSONValue - InProgress #2

In order to render field errors correctly we have to know what value an error goes with
Create sealed trait, ValiationResults which encapsulates the various kinds of results
Create simple, compoound, type-based and exception ValidationResult classes
Revise all validation code to use these new classes.
Adjust Form class hierarchy a little to be more clear.

Committed to: scrupal:master
Commit: [[r:2c55ced3f3486e25ef19ca2798b05a021a7c5898|scrupal:2c55ced3f3]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 04:50:40.000]
Fix import cruft in forms.scala - InProgress #2
Committed to: scrupal:master
Commit: [[r:25381e2b7e9c2b0ada5e554b6437fcae1e0c80d8|scrupal:25381e2b7e]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-03 19:16:12.000]
Speed Up Editing - InProgress #2

Change Scala plugin and compiler settings to make IDEA stop crashing.

Committed to: scrupal:master
Commit: [[r:8d7a84efb9b4e94063c68ef464089f61a6cc726c|scrupal:8d7a84efb9]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 04:54:26.000]
Minor Code Rearrangement - InProgress #2

Break NodeAction classes out to scrupal.core.actions.NodeAction
Going forward, new independent action object will be created in that module
Move scrupal.api.PathMatcher to ScrupalPathMatchers so as not to conflict with spray object
Minor documentation improvements to ActionProvider

Committed to: scrupal:master
Commit: [[r:c8c94dd7ba4a33f092b1e0e1098a89f36e19c557|scrupal:c8c94dd7ba]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 05:24:34.000]
Form Improvements - InProgress #2

FormItems are no longer individually Storable
FieldItems can declare whether they render inline with label or on a separate line and whether they prefix the label or not
Make ResetField and SubmitField be FieldItems so they can be included.
Make Form an Enablee and TerminalActionProvider to provide an action for processing the data
Implement Form.wrap to Twitter Bootstrapify each form field
Copy the DBForm from ConfigWizard to AdminApp and add the SubmitField
Simplify the SIteSelectionForm at top of admin page
Make the AdminApp's TempaltePage actually render a full BootstrapPage
Make BoostrapPage wrap its contents in a "container" div

Committed to: scrupal:master
Commit: [[r:bd4da7fc6ed632f969d5e742d50afc4623a6a35c|scrupal:bd4da7fc6e]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2014-12-30 07:05:05.000]
Prepare For Publishing - InProgress #2

Fix the organization name
Fix a few documentation links

Committed to: scrupal:master
Commit: [[r:0e4622389a539be7ef2b67eb7483c3b2517cb074|scrupal:0e4622389a]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-07 20:00:14.000]
Remove .idea cruft - InProgress #2

Do not, any longer, track the libraries and modules in .idea directory.
SBT importer now regenerates these accurately for a given user.
Differences between users will exist.
This will shorten our commits to just what's relevant.

Committed to: scrupal:master
Commit: [[r:64ac79cfc5b78df278d61368a9d8e90b53d2b642|scrupal:64ac79cfc5]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-07 19:01:34.000]
Update Dependencies - InProgress #2
Committed to: scrupal:master
Commit: [[r:a88389b92077a8e0c482892840f603adc31cc76b|scrupal:a88389b920]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-08 01:09:02.000]
Remove modules from GIT - InProgress #2

These files change to frequently and are developer dependent.

Committed to: scrupal:master
Commit: [[r:b0fac909d359930f20f57e6b0f31dbec196d69e5|scrupal:b0fac909d3]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-07 01:42:17.000]
Validate Forms - InProgress #2

Add a new Disposition for "Unacceptable" input.
Implement the AcceptFormAction to process Spray's FormData content and validate it
Have each type of field decide what is and isn't a value and decode it.

Committed to: scrupal:master
Commit: [[r:71a70b40a23fe79ecf26f09ca874be149812ae21|scrupal:71a70b40a2]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-14 19:00:38.000]
Add Logging Helpers- InProgress #2

Utilities for changing logging levels dynamically and having a memory appender
Also initialization of logging

Committed to: scrupal:master
Commit: [[r:0b26326a229d03597a64432ad9b5c12ad5a9af82|scrupal:0b26326a22]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-07 20:00:49.000]
Validate Forms - InProgress #2

Better error message generation (fix line feeds)

Committed to: scrupal:master
Commit: [[r:0b1027ebfbb59a95470bf61977980f219ec6ffb1|scrupal:0b1027ebfb]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-06 20:57:39.000]
Teach Validation to Associate Errors With ValidationLocation - InProgress #2

Defined ValidationLocation as the location where a validation error could occur.
Revise ValidationResults classes to contain a ValidationLocation object.
Revise Validator methods to take a ValidationLocation.
Start to implement BSONSettings with an AtomicReference[BSONDocument] as the value
Make Forms.Container implement the index and get method of ValidationLocation to select the right field
Further simplify the Forms class hierarchy
Remove BasicModule as it was only used for testing and redundant with FakeModule

Committed to: scrupal:master
Commit: [[r:5015e33970e821fb7a608ecb6d53b8a6ee8813a7|scrupal:5015e33970]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-17 03:30:11.000]
Make Admin Page Display Modules/Apps - InProgress #2

Fix a bug in HTML generation
Simplify Scrupal.load

Committed to: scrupal:master
Commit: [[r:43d776af96f1ab1247e27d9c88aa3605fcfbd28a|scrupal:43d776af96]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-14 19:00:37.000]
Improve Enablement Errors - InProgress #2

Add an "enablementName" member to Enablee for enablement specific name
Use enablementName in error messages

Committed to: scrupal:master
Commit: [[r:0281bcbd006c9b38039513f1837da94111563834|scrupal:0281bcbd00]]

[Migrated from comment on Assembla ticket 2 - comment by @reid-spencer on 2015-01-14 19:00:39.000]
Fix IDEA project - Inprogress #2

Remove remnant modules and libraries
Set code style settings, etc.

Committed to: scrupal:master
Commit: [[r:3dfbbfb795798047ad7d9f64e86ac3ceedca408d|scrupal:3dfbbfb795]]

repo: scrupal/scrupal


text:
build few useful dataset as examples

https://squidpy.readthedocs.io/en/latest/api.html

bento.datasets.load_dataset("merfish") could be good here. It has points and shapely polygons.

bento.datasets.load_dataset("merfish") could be good here. It has points and shapely polygons.

update, there is no image, shoudl change logic for only points...

authors: giovp ivirshup

repo: scverse/napari-spatialdata


text:
Add docstring for scanvi unlabeled category

[x] Closes #2091
[x] Tests added and passed if fixing a bug or adding a new feature
[x] All code checks passed.
[x] Added type annotations to new arguments/methods/functions.
[x] Added an entry in the latest docs/release_notes/index.md file if fixing a bug or adding a new feature.
[x] If the changes are patches for a version, I have added the on-merge: backport to x.x.x label.

meeseeksdev backport to 1.0.x

repo: scverse/scvi-tools


text:
[BUG] GUI trainer "v_1_1.wav" does not match any known standard input files

Just tried the NAM GUI trainer and got the error in the title. Maybe the lengthy path  - will retry with a shorter one too

Training via CLI with the dry & wet files in the root folder works fine.

Can you paste the full file names?

He is using other tha v1_1_1.wav and thats why ui is not complying.
There was question in the fb for this that could there be like checkbox in advanced settings that you could then use any input source with gui?
Thanks and by the way nice work.

I get the same error with v1_1_1.wav
I get a md5 hash that differs from the one in nam/train/core.py. If I add the md5 hash to versions it lets me use the file and starts training.

I've added "weak matching" in #220, which should allow folks to "hack" the training file without getting themselves into too much trouble. Will be in the next release 👍🏻

authors: 2-dor PrimalNerd jolappi sdatkinson

repo: sdatkinson/neural-amp-modeler


text:
关于缓存问题

我在列表页面用的 ajax上拉刷新 ，点击进入详情，然后使用缓存机制，然后点击去，里面的js 全部缓存了，不执行了，返回还是之前浏览的位置，如果不使用缓存机制，都可以，返回还得从头加载，我想实现，点击后里面不使用缓存，返回使用缓存，感觉这个是bug，  很烦恼，为此，让换框架，不知道描述清楚了吗， 感觉缓存机制 必须两个页面都缓存，我想让一个页面缓存 不可以的，

我也遇到这个问题，不清楚是不是因为使用方式不对？ 请问你解决了没？

解决了，微信搜someet服务号 就是用的sui做的，你可以参考一下

authors: justdmm wshudong

repo: sdc-alibaba/SUI-Mobile


text:
Skip updating git dependencies if short hash match

This change ensures that short hashes are taken into consideration when
evaluating if the required version of the dependency is already
installed.
The previous implementation only skipped update of a git
dependencies if the revision specified in the pyproject.toml matched
the full hash of the installed package.
Resolves: #1157
Pull Request Check List
This is just a reminder about the most common mistakes. Please make sure that you tick all appropriate boxes.  But please read our contribution guide at least once, it will save you unnecessary review cycles!

[x] Added tests for changed code.
[ ] Updated documentation for changed code.

Note: If your Pull Request introduces a new feature or changes the current behavior, it should be based
on the develop branch. If it's a bug fix or only a documentation update, it should be based on the master branch.
If you have any questions to any of the points above, just submit and ask!  This checklist is here to help you, not to deter you from contributing!

Looks good to me 👍 Thanks!

authors: abn sdispater

repo: sdispater/poetry


text:
Update build configuration

The build configuration of this project is outdated and may no longer work.
This pull request will be merged automatically if there are no conflicts.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: sealsystems/node-consul


text:
Use Rlock when Get

Use Rlock when Get

@Laisky I submitted a PR (https://github.com/Laisky/fast-skiplist/pull/1) to your branch which would add a bench test to this PR.
@sean-public Parallel bench test shows throughput improvement of RLock is very significant for concurrent access.
name               old time/op    new time/op     delta
IncSet-12             277ns ± 8%      277ns ± 7%       ~     (p=0.780 n=10+10)
IncGet-12             154ns ± 2%      164ns ± 2%     +6.09%  (p=0.000 n=10+10)
DecSet-12             173ns ± 3%      175ns ± 5%       ~     (p=0.724 n=10+10)
DecGet-12             160ns ± 3%      166ns ± 1%     +3.69%  (p=0.000 n=10+9)
IncGetParallel-12     263ns ± 1%       39ns ± 5%    -85.35%  (p=0.000 n=8+10)

name               old speed      new speed       delta
IncSet-12          16.4TB/s ± 9%   16.4TB/s ± 8%       ~     (p=0.780 n=10+9)
IncGet-12          58.9TB/s ± 3%   48.1TB/s ± 2%    -18.31%  (p=0.000 n=10+9)
DecSet-12          40.3TB/s ± 9%   40.4TB/s ± 4%       ~     (p=0.968 n=9+10)
DecGet-12          54.5TB/s ± 2%   45.4TB/s ± 9%    -16.82%  (p=0.000 n=9+10)
IncGetParallel-12  17.0TB/s ± 1%  836.3TB/s ±10%  +4817.85%  (p=0.000 n=8+9)

name               old alloc/op   new alloc/op    delta
IncSet-12             61.0B ± 0%      61.0B ± 0%       ~     (all equal)
IncGet-12             0.00B           0.00B            ~     (all equal)
DecSet-12             61.0B ± 0%      61.0B ± 0%       ~     (all equal)
DecGet-12             0.00B           0.00B            ~     (all equal)
IncGetParallel-12     0.00B           0.00B            ~     (all equal)

name               old allocs/op  new allocs/op   delta
IncSet-12              3.00 ± 0%       3.00 ± 0%       ~     (all equal)
IncGet-12              0.00            0.00            ~     (all equal)
DecSet-12              3.00 ± 0%       3.00 ± 0%       ~     (all equal)
DecGet-12              0.00            0.00            ~     (all equal)
IncGetParallel-12      0.00            0.00            ~     (all equal)

I just noticed this comment in math/rand. RLock might not be appropriate.
// The default Source is safe for concurrent use by multiple goroutines, but
// Sources created by NewSource are not.

https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/math/rand/rand.go;l=12

Parallel bench test shows latency and throughput improvements of RLock are very significant for concurrent access.

If the "new times" listed are using RLock, there's notable performance slowdowns in IncGet-12 and DecGet-12. I know there's no synthetic benchmark for this already extant and, further, all synthetic benchmarks have serious shortcomings, but I believe that in a very common workload with a blend of, say, 20% writes and 80% reads all in parallel, there would be worse performance for writes because they are waiting for all of the pending read locks to free.
Just thinking out loud here 🤔

@sean-public You might actually be right about that...
https://gist.github.com/kevburnsjr/a66c19a16d2ae9d74cd501a8b9b3c6b4
cpu: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
BenchmarkIncSet-12               4232509               277.1 ns/op      15272328.16 MB/s              61 B/op          3 allocs/op
BenchmarkIncGet-12               8680887               163.1 ns/op      53221254.06 MB/s               0 B/op          0 allocs/op
BenchmarkDecSet-12               7107218               179.5 ns/op      39584672.41 MB/s              61 B/op          3 allocs/op
BenchmarkDecGet-12               8546569               166.6 ns/op      51298366.60 MB/s               0 B/op          0 allocs/op
BenchmarkParallel/readpct-0-12           3960511               307.9 ns/op             1 B/op          1 allocs/op
BenchmarkParallel/readpct-20-12          4383126               291.3 ns/op             0 B/op          0 allocs/op
BenchmarkParallel/readpct-50-12          4119375               313.9 ns/op             0 B/op          0 allocs/op
BenchmarkParallel/readpct-80-12          3813206               340.5 ns/op             0 B/op          0 allocs/op
BenchmarkParallel/readpct-100-12        33822919                37.14 ns/op            0 B/op          0 allocs/op
PASS
ok      fast-skiplist   27.501s

Results
name                     old time/op    new time/op    delta
IncSet-12                   268ns ± 3%     273ns ± 4%     ~     (p=0.286 n=5+5)
IncGet-12                   153ns ± 0%     161ns ± 1%   +5.73%  (p=0.008 n=5+5)
DecSet-12                   171ns ± 3%     170ns ± 3%     ~     (p=0.548 n=5+5)
DecGet-12                   156ns ± 0%     163ns ± 1%   +3.94%  (p=0.008 n=5+5)
Mixed/readpct-0-12          172ns ± 1%     172ns ± 1%     ~     (p=0.690 n=5+5)
Mixed/readpct-20-12         173ns ± 0%     174ns ± 1%     ~     (p=0.603 n=5+5)
Mixed/readpct-50-12         172ns ± 0%     175ns ± 1%   +1.97%  (p=0.008 n=5+5)
Mixed/readpct-80-12         163ns ± 1%     169ns ± 0%   +3.77%  (p=0.008 n=5+5)
Mixed/readpct-100-12        155ns ± 1%     162ns ± 2%   +4.46%  (p=0.008 n=5+5)
Parallel/readpct-0-12       311ns ± 1%     306ns ± 1%   -1.58%  (p=0.008 n=5+5)
Parallel/readpct-20-12      312ns ± 0%     290ns ± 1%   -7.19%  (p=0.008 n=5+5)
Parallel/readpct-50-12      306ns ± 0%     313ns ± 2%   +2.41%  (p=0.008 n=5+5)
Parallel/readpct-80-12      288ns ± 1%     337ns ± 1%  +16.90%  (p=0.008 n=5+5)
Parallel/readpct-100-12     258ns ± 0%      37ns ± 0%  -85.66%  (p=0.008 n=5+5)

name                     old speed      new speed      delta
IncSet-12                17.1TB/s ± 6%  17.0TB/s ± 4%     ~     (p=0.841 n=5+5)
IncGet-12                58.9TB/s ± 1%  52.0TB/s ± 1%  -11.64%  (p=0.008 n=5+5)
DecSet-12                41.6TB/s ± 3%  41.0TB/s ± 9%     ~     (p=1.000 n=5+5)
DecGet-12                56.2TB/s ± 0%  50.6TB/s ± 0%   -9.85%  (p=0.016 n=4+5)

name                     old alloc/op   new alloc/op   delta
IncSet-12                   61.0B ± 0%     61.0B ± 0%     ~     (all equal)
IncGet-12                   0.00B          0.00B          ~     (all equal)
DecSet-12                   61.0B ± 0%     61.0B ± 0%     ~     (all equal)
DecGet-12                   0.00B          0.00B          ~     (all equal)
Mixed/readpct-0-12          1.00B ± 0%     1.00B ± 0%     ~     (all equal)
Mixed/readpct-20-12         0.00B          0.00B          ~     (all equal)
Mixed/readpct-50-12         0.00B          0.00B          ~     (all equal)
Mixed/readpct-80-12         0.00B          0.00B          ~     (all equal)
Mixed/readpct-100-12        0.00B          0.00B          ~     (all equal)
Parallel/readpct-0-12       1.00B ± 0%     1.00B ± 0%     ~     (all equal)
Parallel/readpct-20-12      0.00B          0.00B          ~     (all equal)
Parallel/readpct-50-12      0.00B          0.00B          ~     (all equal)
Parallel/readpct-80-12      0.00B          0.00B          ~     (all equal)
Parallel/readpct-100-12     0.00B          0.00B          ~     (all equal)

name                     old allocs/op  new allocs/op  delta
IncSet-12                    3.00 ± 0%      3.00 ± 0%     ~     (all equal)
IncGet-12                    0.00           0.00          ~     (all equal)
DecSet-12                    3.00 ± 0%      3.00 ± 0%     ~     (all equal)
DecGet-12                    0.00           0.00          ~     (all equal)
Mixed/readpct-0-12           1.00 ± 0%      1.00 ± 0%     ~     (all equal)
Mixed/readpct-20-12          0.00           0.00          ~     (all equal)
Mixed/readpct-50-12          0.00           0.00          ~     (all equal)
Mixed/readpct-80-12          0.00           0.00          ~     (all equal)
Mixed/readpct-100-12         0.00           0.00          ~     (all equal)
Parallel/readpct-0-12        1.00 ± 0%      1.00 ± 0%     ~     (all equal)
Parallel/readpct-20-12       0.00           0.00          ~     (all equal)
Parallel/readpct-50-12       0.00           0.00          ~     (all equal)
Parallel/readpct-80-12       0.00           0.00          ~     (all equal)
Parallel/readpct-100-12      0.00           0.00          ~     (all equal)

authors: Laisky kevburnsjr sean-public

repo: sean-public/fast-skiplist


text:
Add pom.xml and application.properties files, and create main and test classes

Just a start

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late!
jondoescoding, @ryolambert, @zhaohaihao, @raiyanmook27, @m3ngyang, @NikhilBhutani, @neuromaster, @KennyBoate, @Symyon, @Tagman, @darelover, @Mennodeg, @leondelaimy, @exponentialdata, @satyamakgec, @barcahead, @js928, @Kallaran, @OlypsisAli, @drapala, @wojciechmarek, @iyanuashiri, @Silassentinel, @oguzatas, @rheaplex, @randomishwalk, @daviddwlee84, @ddaws, @johnnypeck, @soultreehouse, @hacker-DOM, @Moniet, @zyftc0, @WaS-Studio, @cclhsu, @samirettali, @seckincengiz, @napalm911, @youngzhenhao, @13yobbh, @decanus, @Ilyasali012, @enzoferey, @LinZhengHong, @0xDSousa, @Delegat43, @foreandr, @Mjbz336, @javiermontescarrera, @eliemugenzi

authors: jhonnybail seanmayer

repo: seanmayer/demeter-service


text:
Avoid .git folder rsync delete

When no target folder given, the .git folder gets deleted so the bash script cannot commit.
Excluding existing .git folder avoid that issue 🙂

Thank you!

authors: seanmiddleditch yannbertrand

repo: seanmiddleditch/gha-publish-to-git


text:
IllegalAccessError is thrown when Jest tries to access internal deepCopy method com.google.gson.JsonObject class

I am using Jest client to work with Elasticsearch from inside Spark application. While it runs as expected when executing Spark in local mode, it fails in cluster mode with the following exception:

Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.gson.JsonObject.deepCopy()Lcom/google/gson/JsonObject; from class com.google.gson.GsonUtils
at com.google.gson.GsonUtils.deepCopy(GsonUtils.java:8)
at io.searchbox.core.SearchResult.extractHit(SearchResult.java:114)
at io.searchbox.core.SearchResult.getHits(SearchResult.java:82)
at io.searchbox.core.SearchResult.getHits(SearchResult.java:63)
at io.searchbox.core.SearchResult.getHits(SearchResult.java:59)

There was a commit cdd62a816a01b0d9d11262792e685396ab208e74 made on Dec 26, 2015 that introduced GsonUtils class that simply calls package level deepCopy method of com.google.gson.JsonObject class by simply defining GsonUtils in com.google.gson package. It seems like a not very good practice to access internal methods. It may cause problems when using multiple classloaders (just like with Spark example above).

See the discussion that lead me to create that utils class here: https://github.com/google/gson/issues/760

Do you think it's a good idea to still call non public methods through defining gson package in Jest? Isn't it better to use some other way to clone objects that does not cause any exceptions?

See the discussion that lead me to create that utils class here: google/gson#760
I am confused. You prefer to allow exceptions to one additional dependency?

As you mentioned the issue occurs only under certain environments ("when using multiple classloaders (just like with Spark example above)") which I would guess is not the prominent use case for this library. This decreases the severity of the exception in the big picture. On the other hand you are suggesting to introduce a new dependency which will come with it's own baggage of possible bugs and maintenance needs, which makes it a "load" (or debt if you will) on the whole project.
Considering the above pro/con comparison it makes more sense (at least maintenance-wise) to not take this suggested fix into the project.
And to answer your question, no I don't think the existing utils class is a good solution, it is simply a workaround. I'd be more than happy to replace it with a similarly light weight solution.

Makes sense. I have found another solution to this problem. Please, see pl https://github.com/searchbox-io/Jest/pull/353

authors: kramer yuriyfilonov

repo: searchbox-io/Jest