Samllogout #1570

Further to the class cast exception (issue #1570) in AbstractSAML2MessageReciever, the abstract receiver is still attempting to resolve an endpoint as if it were dealing with a request to an ACS.
This causes an exception where the URL of a logout request is not found in the list of configured ACS endpoints.
Caused by: org.pac4j.saml.exceptions.SAMLException: Assertion consumer service with destination http://test.sp:9000/callback?client_name=SAML2Client&logoutendpoint=true could not be found for spDescriptor org.opensaml.saml.saml2.metadata.impl.SPSSODescriptorImpl@433f19c9 	at org.pac4j.saml.context.SAML2MessageContext.getSPAssertionConsumerService(SAML2MessageContext.java:126) 	at org.pac4j.saml.profile.impl.AbstractSAML2MessageReceiver.receiveMessage(AbstractSAML2MessageReceiver.java:64) 	at org.pac4j.saml.logout.impl.SAML2LogoutProfileHandler.receive(SAML2LogoutProfileHandler.java:36) 	at org.pac4j.saml.credentials.extractor.SAML2CredentialsExtractor.extract(SAML2CredentialsExtractor.java:59) 	at org.pac4j.core.client.BaseClient.retrieveCredentials(BaseClient.java:66) 	at org.pac4j.core.client.IndirectClient.getCredentials(IndirectClient.java:143) 	at org.pac4j.core.engine.DefaultCallbackLogic.perform(DefaultCallbackLogic.java:85) 	at org.pac4j.play.CallbackController.lambda$callback$0(CallbackController.java:54) 	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) 	... 8 common frames omitted

@timforsyth Thanks for the fix
@mmoayyed Are you in line with the fix?

Sure, looks fine.

Thx


IFFE module target

Would anyone be interested in a PR for bundling ES6 modules into single IFFE-scoped files? (a la rollup.js) This would allow bundling for those who don't wish to rely on AMD/System, and remove at least one build step in many scenarios.
(Apologies if duplicate. Search/FAQ didn't come up with anything. If additional details are desired, I can put those together as well)
Example below (modified from rollupjs's website):
//main.ts (source)
import * as x from './maths';
var z : number = 3;
console.log( x.cube( 5 ) + z );

//maths.ts (source)
//variable namespacing could be accomplished by appending, as seen here, or via internal IFFEs
var z : number = 0;

export function square ( x : number ): number {
	return x * x + z;
}

//unreferenced functions intelligently culled
export function cube ( x : number ): number {
	return x * x * x + z;
}

//main.js (outFile)
(function () {
	'use strict';

	//variable namespacing could be accomplished by appending, as seen here, or via internal IFFEs
	var z$1 = 0;

	//unreferenced functions intelligently culled
	function cube ( x ) {
		return x * x * x + z$1;
	}

	var z = 3;
	console.log( cube( 5 ) + z );

}());

looks like a duplicate of https://github.com/Microsoft/TypeScript/issues/4434

Thanks, closing.

See also #6319 which would allow you to use rollup to generate your final bundle.


HW2: Rebased and Fixed Conflicts

Update baa2159.md
Update readme link
Move to projects -> python
move to projects -> python
Update baa2159.md
remove unnecesary files
link and folder restructure

Last branch I used gave me issues with rebasing so I did it from scratch.


PMID:38442865

New term : microtubule bundles present in increased numbers during mitotic M phase
A physical cellular phenotype observed in the vegetative growth phase of the life cycle in which cells contain more microtubule bundles than normal during the mitotic cell cycle.
New term : microtubule bundles present in normal numbers
A physical cellular phenotype in which cells contain a normal number of microtubule bundles.
New term : normal punctate cytoplasmic protein localisation
A cell phenotype in which a protein is localized to discrete regions in the cytoplasm, visible as foci or dots by microscopy, to the same extent as observed in normal (wild type) cells.

Added
microtubule bundles present in increased numbers during mitotic M phase
def:
A physical cellular phenotype in which cells contain more microtubule bundles than normal during mitotic M-phase.
(with logical def)
'has part' some
('has extra parts of type'
and (exists_during some 'single-celled organism vegetative growth phase')
and (towards some 'microtubule bundle'))
and
normal protein localization to cytoplasmic puncta (changed slightly and used American spelling, ontology convention)
is this OK?


Accept "domains" when filtering

There's an issue with the filtering because these two searches are empty:

https://justdeleteme.xyz/#www.youtube.com
https://justdeleteme.xyz/#youtube.com

while this works:

https://justdeleteme.xyz/#youtube

It'd be great to use the domains array on the website’s search as well in order to find them easily, not just by name.
Originally posted in https://github.com/jdm-contrib/jdm/issues/1772#issuecomment-1721545567

I'd love to see some "exact" searches as well.
For example https://justdeleteme.xyz/#github.com should only show GitHub.com, not BountySource (which I don't know why appears)

Maybe a dedicated search could be added: https://justdeleteme.xyz/?domain=github.com

Bountysource's URL is on github, that's probably why


WIP: New kernels for ACE models

This PR provides experimental implementations of ACE models to provide a fast but flexible implementation of a variety of ACE models to be tested, including trACE-like models, different tensor formats, out nonlinearities (e.g. FS). At the same time it provides a blueprint for implementing non-trivial models using the kernels provided by P4ML.

[x] transfer most important envelopes from ACE1.jl
[x] transfer most important transforms from ACE1.jl
[x] implement learnable radial basis
[x] implement splined radial basis (non-learnable)
[x] interfaces for sphericart, and P4ML kernels
[x] a first ACE model with learnable radials / trace capabilities
[x] gradient w.r.t. positions
[x] gradients w.r.t. params
[x] grad_params_forces (reverse-over-reverse)
[x] basis(energy)
[x] basis(grad)
[x] jacobians
[x] test correctness of energy, forces, virials
[x] test correctness of pullback_EFV
[x] Pair potential
[x] an example of linear parameter estimation (regardless of accuracy)
[x] an example of nonlinear parameter estimation (regardless of accuracy)
[x] evaluating some energies, forces, virials with the fitted potentials (even if crap)

I think we are very close to being able to merge now. I propose to fix the "bug" below + implement some examples demo-ing usage and then merge and tag so people can start to play, file issues, and integrate the new functionality properly with ACEpotentials.
Possible Bugs?

[x]  The standard Lux printout doesn't show the correct number of parameters. This is probably because I store the weights as arrays of arrays rather than high-dimensional tensors. We can revisit this.

Recording a TODO list:

The radial basis currently has maxn = maxq, which is of course ridiculous, but it doesn't prevent functionality testing so I'll leave it for now.
The pair potential basis currently uses random trace-like mixing. Should implement a one-hot initialization of the rbasis weights and this could be taken as the default for the pair basis.
the tensor operations A -> AA -> B should be wrapped into a separate type rather than hard-coded. This will give better structure and allow easier experimentation with different formats. The question is whether to leave A outside or inside.
purify 2b
general rational transforms, both frozen and learnable, to unify everything we have. Explore Polynomials and StaticPolynomials packages to manage the algebra.
Implement sparse_ace_spec as commented in models/utils.jl
discuss whether we ever want to allow complex SH again?
adapt the architecture to enable different tensor formats for A and AA
Give the Rnlzrr basis the option of initializing in different ways, in particular just using the polynomials (which only makes sense for a single species...)
Give the Rnlzrr basis the option of freezing the coefficients, and hence making the model linear.
How to incorporate smoothness priors. Ideally we should just incorporate them through a rescaling the A basis (or possible the Rnl, Ylm bases)
Outer nonlinearities such as FS, MLP, or a BOP-like thing.
pushforwards of main kernels for faster jacobians and basis_derivatives
weird stuff going on with units. to be discussed and cleaned up. Should we enforce usage of units? Could prevent mabny bugs!
writing models to and from files...

@jameskermode  --  FYI, this is becoming a first draft of what I was planning. There are a few steps missing before I would appreciate help with testing and polishing the user-interface. But I'm not very far away.

@tjjarvinen and @TSGut  -- the new implementation of ACE models is an opportunity to try out more efficient batching. As soon as you have a neighbourlist ready that can provide atomic environments in batches of 16, 32, ..., we can write an alternative evaluator and see how much we gain.

@tjjarvinen  -- I think this is also an opportunity to switch to Bumper.  Maybe take a look at this PR before our next meeting.

@CheukHinHoJerry  -- I implemented the approach that Avik Pal suggested for reverse-over-reverse. It's stunning how well this works. Take a look at pullback_2_mixed' in models/ace.jl` when you have a moment. The performance is also fantastic.

@cortner when appropriate I'd like to contribute some further tests or examples to get a feel for this new stuff. Would it make sense to start by converting this tutorial, which is long overdue to be moved to this repo? Do you have a better idea?

Updating/testing tutorials is also something I/others in my group can help with

@wcwitt -- I think that would be a great start. Let me finish the three remaining bullet points. At that point we should have feature parity with ACE1 - purification + much more incl trACE-like and learnable radials.
One question I'd like your feedback on (CC @jameskermode) is whether we should move everything to AtomsBase + AtomsCalculators or whether it is better to stick with JuLIP for a little while.

I haven't really kept up to date with AtomsCalculators but as far as AtomsBase is concerned I'd be supportive of making the switch now rather than having to re-engineer ACEpotentials again in the near future.

Updating/testing tutorials is also something I/others in my group can help with

I will need a bit more help than that. I will also need help testing different parameter estimation approaches. There are exponentially many variants in my head and I'm not sure where to go with that. I'll document that at some point and we can then discuss how to go about this.

@cortner I'm happy to help do some benchmarking for the parameter estimation, once docs are roughly there.

@cortner I'm happy to help do some benchmarking for the parameter estimation, once docs are roughly there.

thanks @thomas-rocke - yes, Tom and others in my group will be very happy to explore these parameter options.

It's definitely happening. My question is only whether we should try to force the issue by not even providing the option of using JuLIP anymore.

Could we try it and see what we miss?

To add status on AtomsBase and  AtomsCalculators.

ACEmd is working with AtomsBase and AtomsCalculators, with ACE1 backend
I have ASE interface for AtomsCalculators working (tested with ACEmd), meaning ASE interface is ready
AtomsBase training relies on an ACEfit extension that is located in ACEmd - this need to be moved to either to ACEfit or to where ever the new ACE code resides

Pair potential still uses JuLIP in the background or has that been switched to new AtomsCalculators? Same for one body potential?

Maybe there should be a separate PR for totally migrating to AtomsBase? I think we should at least advertise it a bit more before it happens.
Also, it sounds to me that there are quite a lot of utilities for fitting/IO in ACEmd right now (e.g. new ASE interface, save_ace_model …). Given that Molly is still not of major usage, should a majority of those be moved to ACEpotential in the near future?

Also please let me know when it is time to move the purification code. I could help with that.
@wcwitt Maybe I can also help with writing some examples if you don’t mind? I will have to get familiar with the new kernel too.

Please let me know when it is time to move the purification code. I could help with that.

I think it may be unrealistic to provide the full purification for this setting. But we should implement the purify-2B only. Not quite ready for it, but relatively soon.

@jameskermode @wcwitt  --  AtomsBase forces units on everything. As a matter of principle I find this problematic. I want to be allowed to work with non-dimensional models sometimes. And it's a pain when designing a good interface.
But for ACEpotentials this may well be a good thing. I don't know. It has some interesting consequences. E.g. training weights must get units now otherwise you can't add up loss terms.  E.g. this calculation
wE^2 * E^2 / length(at)
               + wV^2 * sum(abs2, V) / length(at)
               + wF^2 * sum(_norm_sq, F)

if E, V have units angstrom and F has unit eV/A, will only work if wE, wV have units 1/eV and wF has unit A/eV.  It's also interesting that this shows clearly that we are adding up things that shouldn't really be added (this has always bothered me...)

ACEmd implementation that also uses AtomsBase does not use units for training weights. Basically you can just strip the units in the first step and then you are good to go unitless.
The big plus with units is of course is that units force correctness checks into the code and this can be a good thing.

 It feels like a hack and makes code unreadable. I claim that if that is necessary then there is a problem with the overall design.

In trying to fix the unit tests I modified the test environment and now get the following:
(ACEpotentials) pkg> test
     Testing ACEpotentials
ERROR: can not merge projects

Why do we even need the test environment? Why can't we just work with a single Project.toml? I find the separate test environment annoying to work with, since everytime I try to activate parent... in VSCode in a test file it activates the test env instead of the root env which I actually want?

@jameskermode , @wcwitt  and anybody else who would like to contribute.  This is far from done, but it is now at a stage where anybody can jump in and help.  I cannot spend my summer bringing this to feature parity with original ACEpotentials, but I can certainly help. If there is enough interest to commit to this, then now is the time to discuss how to proceed.

Why do we even need the test environment?

I think this is recommended when the tests have additional (heavy) dependencies. I can't recall at this point, but it may have been a @tjjarvinen contribution, so he may have a view

I am wondering how to organize the next steps of development.
(1) ignore all version control and continue the current branch as a development branch without versions.
(2) just merge into main and continue to develop new experimental features without exporting
(3) Create a new branch v0.6 off of main where we do only maintenance / bugfixes, then merge the PR into main and tag it as v0.8.x versions (and eventually 0.9.x and so forth).
Any views on this?

@tjjarvinen  - thank you for fixing the two examples at the end of the tutorial. Can you please explain why this substitution resolved the problem with the optimizer?
#at_new = AtomsBuilder._set_positions(at, reinterpret(SVector{3, Float64}, results.u) * u"Å")
at_new = FastSystem(
   bounding_box(at),
   boundary_conditions(at),
   reinterpret(SVector{3, Float64}, results.u) * u"Å",
   atomic_symbol(at),
   atomic_number(at),
   atomic_mass(at)
)

No it did not fix it. I just didn't have your version of AtomsBuilder, so the commented line did not work for me, and I had to have something else. So, I made the same using standard AtomsBase.

I think this is recommended when the tests have additional (heavy) dependencies. I can't recall at this point, but it may have been a @tjjarvinen contribution, so he may have a view

Yes this it is mainly. It is a recommendation from Julia v1.2 onwards. The old way of not having test/Project.toml is deprecated and will be removed with Julia v2.

For the development, I would create a tag on the main branch before we merge anything. In fact we have no tags for release versions at all. It would be really good to create them.
I am in favor of branching v0.6 and continuing the development in main branch. For this we need to make sure we have documentation for v0.6. To this we need to tags, so that documenter saves the documentation in different folders. This is very important!

Great, I will start playing with this! First step for me will be to confirm I can run the tutorial, and then I'll try to expand towards what is needed for increasingly real applications. I'm happy with branching out a v0.6 branch and continuing this development in main as @tjjarvinen suggests. Once things stablise we can then make a new release.

Where is a good place to coordinate activity on this? Happy to use this PR, or we could setup a Slack or Zulip channel instead (with a preference for Slack for me).
After some faffing around with dependencies (SparseArrays, StaticArrays, AtomsBase missing from doc/src/newkernels/Project.toml, I'll check in a fix) I got the example running. After 3000 Adam steps for the non-linear opt the loss and gradient are still rather large:
  3000     1.001428e+07     1.763535e+08
 * time: 5545.555037021637

but this is sufficient to get more reasonable MAEs after the linear fit:
[ Info: MAE(train) = 0.06140387518964288
[ Info: MAE(test) = 0.08700835512433414

The MD still explodes.
I am wondering if it would make sense to do a linear fit of the expansion coefficients before the non-linear optimisation, and start the non-linear opt from there with the aim of restrict it to improving the radials and species embedding. Of course this risks getting stuck in local minima and losing the benefits of SGD/Adam.

I'll check in a fix

@cortner I don't have write access to this repo, could you add that? Or I can do a PR into this one if you prefer.

now done. sorry for the delay.  I'll wait for your commit and will then merge this into main as discussed so we can manage further improvements through a sequence of PRs.

I am wondering if it would make sense to do a linear fit of the expansion coefficients before the non-linear optimisation, and start the non-linear opt from there with the aim of restrict it to improving the radials and species embedding. Of course this risks getting stuck in local minima and losing the benefits of SGD/Adam.

I think there are quite a few options here worth exploring. Note also that I'm unsure how good a dataset TiAl actually is. I think we should switch to something else. E.g.  If anybody wants to suggest a sequence of good datasets that we trust? I am thinking e.g.

Cuo et al
PRX Silicon and maybe Ralf's Cu
TiO2 (Artrith, 2016), I tried this with linear ACE and got poor results
Anybody have a 3-4 component alloy?
the "classical" molecular benchmarks rMD17, 3BPA etc?

I am wondering if it would make sense to do a linear fit of the expansion coefficients before the non-linear optimisation, and start the non-linear opt from there with the aim of restrict it to improving the radials and species embedding. Of course this risks getting stuck in local minima and losing the benefits of SGD/Adam.

I think there are quite a few options here worth exploring. Note also that I'm unsure how good a dataset TiAl actually is. I think we should switch to something else. E.g.  If anybody wants to suggest a sequence of good datasets that we trust? I am thinking e.g.

Cuo et al
PRX Silicon and maybe Ralf's Cu
TiO2 (Artrith, 2016), I tried this with linear ACE and got poor results
Anybody have a 3-4 component alloy?
the "classical" molecular benchmarks rMD17, 3BPA etc?

@YangshuaiWang and I are playing with 2-5 component alloy and also 3BPA.

Changes pushed, thanks.
I can also add a 3-component FeCrNi alloy (or 4-components including spin up and spin down Fe as two species) from this recent paper.

This is now merged. Thank you to those who were following. I will file a separate issue outlining the long TODO list which will be addressed in separate PRs, and where we can also discuss.
Just to be 100% clear, I do NOT expect the current version to fit a useful potential out of the box (see also James' comment about 3000 Adams iterations). The next few weeks / months will be to fine-tune the codes and defaults to make that possible.


return group name instead of full path name for legacy API

[x] Closes Issue #68
[ ] Tests added
[x] Changes are documented in CHANGELOG.rst

It's a small fix to align legacy API with netcdf4-python. I'll merge in a couple of days.


[#302] Send notification to group members when discussion is created

Team/Project/Office implements HasMembers contract
New event DiscussionCreated triggered on creation of Discussion model
Created listener for new event
Created notification class implementing the notification content
Registered route to show discussion detail (just stub for now)
Created tests for new feature

Codecov Report

Merging #367 into dev will decrease coverage by 0.63%.
The diff coverage is 61.53%.

@@             Coverage Diff             @@
##                dev    #367      +/-   ##
===========================================
- Coverage     83.13%   82.5%   -0.64%
- Complexity      291     300       +9
===========================================
  Files            98     101       +3
  Lines           937     960      +23
===========================================
+ Hits            779     792      +13
- Misses          158     168      +10

Impacted Files
Coverage Δ
Complexity Δ

app/Models/Discussion.php
80% <ø> (ø)
5 <0> (ø)
:arrow_down:

app/Http/Controllers/DiscussionController.php
100% <ø> (ø)
4 <0> (ø)
:arrow_down:

app/Providers/EventServiceProvider.php
100% <ø> (ø)
1 <0> (ø)
:arrow_down:

app/Models/Team.php
100% <100%> (ø)
1 <1> (ø)
:arrow_down:

app/Events/DiscussionCreated.php
100% <100%> (ø)
2 <2> (?)

app/Models/Office.php
100% <100%> (ø)
1 <1> (ø)
:arrow_down:

app/Listeners/NotifyDiscussionParticipants.php
100% <100%> (ø)
2 <2> (?)

...pp/Notifications/DiscussionCreatedNotification.php
33.33% <33.33%> (ø)
4 <4> (?)

app/Models/Project.php
50% <33.33%> (-50%)
2 <2> (+1)

... and 2 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 ffa3583...72c1613. Read the comment docs.


COSMOS QA: MRC with Contextual Commonsense Reasoning

Paper

P1: It's a very humbling experience when you need someone
to dress you every morning, tie your shoes, and put your hair
up. Every menial task takes an unprecedented amount of effort.
It made me appreciate Dan even more. But anyway I shan't
dwell on this (I'm not dying after all) and not let it detract from
my lovely 5 days with my friends visiting from Jersey.

Q: What's a possible reason the writer needed someone to
dress him every morning?

A: The writer doesn't like putting effort into these tasks.
B: The writer has a physical disability.
C: The writer is bad at doing his own hair.
D: None of the above choices

Done.


Push To Master: HGSC latent feature arithmetic

Notebook and results from a latent feature analysis using TCGA HGSC subtype labels

coming right up :pizza:

Thanks @danich1 - I updated the notebook, nbconverted a .py, and fixed the .tsv files

Thanks @jaclyn-taroni - I added a function here and I agree that it clears up some redundancy

Thanks @danich1 and @jaclyn-taroni for your comments and suggestions. I believe I have addressed them all.
Most importantly, while wrapping up responding to your comments, I encountered a critical indexing bug when loading the weight matrix previously (13b3dcc). Specifically, I was one node off when determining important genes. For example, instead of considering genes for node 56 (for the nodes when they're between 1 and 100), I was analyzing genes for node 55 (for nodes when they're between 0 and 99). @danich1 pointed this out this indexing in pull request #56 (discussion here) and @jaclyn-taroni suggested using a previously output weight matrix rather than generating them specifically for each node, which may have avoided this issue in the first place.
This will require a completely updated interpretation of HGSC features, including updated pathway analyses, and an updated biorxiv submission. I also need to check the pathway analyses for the sex specific and melanoma specific nodes. Although because the sex specific genes were obvious, I do not suspect this is the case for that analysis.
Luckily this bug was caught before the PSB resubmission. The importance of code review in action!

cc @cgreene for this issue :point_up: we will need to update the biorxiv once all the PSB reviewer comments are addressed.

I am definitely glad that you found this before publication. That would have put things into a retraction situation. We will need to update bioRxiv. It seems this is likely to result in substantial changes.
We will need to get this back to PSB as soon as possible so that they can look carefully at it to determine whether or not they can still publish it.
Even if they don't publish it, the outcome is still far better than a retraction. Definitely a win - though potentially a painful one.

We will need to update bioRxiv. It seems this is likely to result in substantial changes.

Definitely a win - though potentially a painful one.

Agree that finding this now rather than later is much preferred. But the update will not result in substantial changes and should not be as painful as initially perceived. It will definitely result in a correction, but only to interpretation of findings in one subsection. I confirmed that this error does not persist in any other analysis.

We will need to get this back to PSB as soon as possible so that they can look carefully at it to determine whether or not they can still publish it.

I will continue with the response to reviewers and will draft a cover letter including the responses and explanation of the correction. I do believe now that the correction will be minor.
I will merge this in and move forward on the response. Thanks!


potential app crash when loading claim

Haven't verified it yet, but from a user report:
I typed "efekt" and than tapped "Efekt Setnej Malpy" channel and then app crashed.

Can reproduce (in app store version)


Playlist shuffle highlights wrong track

Issue description
When playlist shuffle is enabled, clicking next plays the next track in the shuffle list but highlights the next track sequentially (even if that's not the one playing).
Environment

What's My Browser Support link: https://www.whatsmybrowser.org/b/EZWH3
Amplitude.js Version: 5.2.0

Steps to reproduce the issue

Visit https://521dimensions.com/open-source/amplitudejs/docs/examples/multiple-playlists.html
Enable Shuffle on the first playlist/player
Show the playlist/queue (by clicking on the top right icon of the player)
Click play
Click next

What is expected?
Track playing is some random track, e.g. Terrain. The bottom of the player shows the correct track is playing, but if you look at the queue it shows track two is playing. See screenshot.
Link to where issue can be reproduced
https://521dimensions.com/open-source/amplitudejs/docs/examples/multiple-playlists.html
Additional details / screenshots

In the above screenshot, Terrain is the correct random next track but notice that the highlighted track is track number two rather than Terrain.
Code
https://github.com/521dimensions/amplitudejs/blob/072fa4ee1f5d7d0711a50397a631bd63e043322c/src/visual/containerElements.js#L79-L94
Line 90 looks like the code that would highlight the correct track, but it won't be executed because if this else block is executed (all of the above code, starting on Line 79) then config.active_playlist != null && config.active_playlist != '' is always going to be true (because if it wasn't, the if block on Line 41 would be executed instead). Thus, Line 85 will always be executed and ends up selecting the wrong track if playlist shuffle is enabled. I'm going to guess (and in my tests this fixed the problem) that Line 84 should be if (... && direct) or just if (direct), following the same logic as in the non-playlist code a few lines earlier:
https://github.com/521dimensions/amplitudejs/blob/072fa4ee1f5d7d0711a50397a631bd63e043322c/src/visual/containerElements.js#L45-L57

Hi @floft I want to work on this issue, can you please assign me this.


How to type a factory function that returns selector?

https://github.com/reduxjs/reselect#q-how-do-i-create-a-selector-that-takes-an-argument
const expensiveItemSelectorFactory = (minValue: string): ? => {
  return createSelector(
    shopItemsSelector,
    items => items.filter(item => item.value > minValue)
  )
}

You shouldn't have to declare a return type manually here. Let TS figure that out :)

Also if for some reason you wanted to change this type or be more explicit, you can hover the createSelector call in any TypeScript language service editor to see the type it returns.
This could be closed.

you can use typeof in typescript to grab the type of the variable.


Occupancy descriptions are limited to 32 characters

The name fields in 1.4.3 allowed 32 characters and the description fields in 1.4.3 allowed 64. Currently, 2.0 is failing to import occupancies when the file has a description more than 32 characters. Sometimes nothing imports and sometimes it's a partial import. The import screen stays blank instead of showing what was brought in.
If we aren't able to change the importer to allow for 64 characters, can we please make the whole import fail and throw an error letting the user know what the issue is?
Attaching URS curves. both are exactly the same but with different max characters in the description.
length maybe max 37.txt
length maybe max 32.txt

@Brennan1994 this is a problem with the importer project.
Of course we can have very many characters in the description. It is just that Bob's code is choking on the description length.

Example of long description successfully saved to the HEC-FDA Version 2.0 study database:

@BrittCorley can you please confirm that the files you provided import and export into and out of 1.4.3 successfully?

yep they work


GameObjects and Components should implement disposable

GameObjects and components do not implement disposable. GameObjects should implement disposable which then call dispose on all of its components so that modelInstances for model components are disposed, etc..

After taking a closer look, this does not seem to be needed at this point. GameObjects and components are not holding reference to items that need to be disposed. ModelInstances are not disposable. Models are but we would not want to dispose a model that is being used for other modelInstances.


Contributors and Discord Server

Fontsource is actively growing and there's lots planned for the future! Unfortunately, I'm not able to be as active as I used to be which has led to progress slowing down. Having more contributors to help out with Fontsource would be awesome.
If you're comfortable with TypeScript and have an interest in this project, feel free to join our Discord server. We're coding in public so you can involve yourself whenever you want, and we're more than happy to guide you around the code if you have any questions.

Question: was I banned? I don't know why I'm not in the server anymore?

I'm one of the "Maintainers" on Discord, and it does indeed look like you were banned. It says there was no reason provided; and I have no idea whether it was on purpose or not. I'm sure @ayuhito would be able to tell us, though.


Convert kube-prometheus to jsonnet

This PR implements the kube-prometheus stack as jsonnet code.
@ant31 @fabxc @mxinden
/cc @metalmatze

What would we need to do to convert our current kube-prometheus stacks to jsonnet after this goes through?

@ScottBrenner we will still keep the manifests currently present in manifests/ if people still want to work with the bare manifests, but it will always be a bare minimum of things. In fact they are from now on generated by example-dist/base/kube-prometheus.jsonnet. The idea is that people take exactly that jsonnet file and do all the additions they want, that way these files don't have to support any possible customization, as it is necessary with helm, but instead just a minimum common example and then people can add whatever they want with jsonnet. At that point upgrading to new kube-prometheus versions is just a button push away as your changes are code and are automatically applied :slightly_smiling_face: .


Detectnet fine tuning

Hello Sir,
First I appreciate about your provided information.
My question is basically about DetectNet.

You have provided 3 trained models. may I ask you where can I download them? I mean ped-100, multiped-500, facenet-120.

Do you have any more trained model rather than above mentioned ones?

I use DIGITS 5.1, and I decide to find tune model instead of training from scratch. Then may I ask you which _.prototxt should be used in accompany with CaffeModel? I mean deploy.prototxt or original.prototxt or solver.prototxt or train_val.prototxt?

Okay, I solved the first question, but please help me with second and third.

Hi, you can find the original DetectNet and training guide in included with DIGITS here:.  https://github.com/NVIDIA/DIGITS/tree/master/examples/object-detection
On Jan 9, 2017 5:03 AM, Hesam Moshiri<EMAIL_ADDRESS>wrote:
Hello Sir,
First I appreciate about your provided information.
My question is basically about DetectNet.

You have provided 3 trained models. may I ask you where can I download them? I mean ped-100, multiped-500, facenet-120.

Do you have any more trained model rather than above mentioned ones?

I use DIGITS 5.1, and I decide to find tune model instead of training from scratch. Then may I ask you which _.prototxt should be used in accompany with CaffeModel? I mean deploy.prototxt or original.prototxt or solver.prototxt or train_val.prototxt?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/dusty-nv/jetson-inference/issues/27, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AOpDK5W_FS6jST-BJSd9UQlyWEbObxYHks5rQgXhgaJpZM4LeGBZ.

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Hello,
Yes, I know about that but I feel they have not revealed everything. if the intention is to fine tune the model, some layers must be renamed but they did NOT.


Need example of .env file for making DB connection

I'm a novice, but I got as far as the last step of the setup, i.e. python manage.py migrate
I get this error, which I assume means that the .env file I created is not formatted correctly (I placed it in app root where manage.py is located).
I would assume that when you follow the step-by-step prompts to set up the project (I am on Windows), there is a specific formatting of the .env  that's expected.  Also, in case this matters, I downloaded the latest PostgreSQL (which is 14.7) as I assumed all minor versions of v14 would work. If this is not the case, please let me know.
Here is my current .env file. Can you tell if this is not what's required:
PostgreSQL
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_DB=my_app
POSTGRES_USER=postgres
POSTGRES_PASSWORD=my_pass

i hardcoded the db values into the base.py and that worked.

Your .env is only read when READ_DOT_ENV_FILE=True. See https://github.com/cookiecutter/cookiecutter-django/blob/54d78f733ef97e3077418affa54cac7b74dbb35d/{{cookiecutter.project_slug}}/config/settings/base.py#LL13C1-L13C18 for the implementation.
If you need more help you can open an discussion.

Thank you for getting back to me. The value was set to True, but that didn't work. It worked when I hardcoded the DB credentials into the base.py file. It is possible that the .env file had the wrong key/value pair, e.g. was "POSTGRES_HOST" the right key? I also ran the following commands in Powershell on Windows, which may or may not have made a difference:
setx DB_NAME "my_app"
setx DB_USER "postgres"
setx DB_PASSWORD "my_pass"
setx DB_HOST "localhost"
setx DB_PORT "5432"

The correct names can be found here: https://github.com/cookiecutter/cookiecutter-django/blob/master/{{cookiecutter.project_slug}}/.envs/.local/.postgres
You can try setting the default of the line I mentioned in my previous post to True while testing.

Very helpful, thank you!


Vulcan Shaper binary

I'm interested in using the rust-skia project via skulper in a project I am working on. Unfortunately I would like to use the harfbuzz wrapper in skia but it looks like there are no binaries for windows which contain both the vulcan and shaper features. Further for some reason I can't build the project locally. I run into strange errors and after looking at the dependencies I'm not sure building the skia library locally is really an option.
Is there any way I could take advantage of the CI infrastructure already in place to build a shaper and vulcan enabled binary and use that? Thanks in advance either way!

I looked at the pipelines and made what might be the necessary change in a PR which is linked above. I don't know how to test to see if this works though. Any help?

Fixed by https://github.com/rust-skia/rust-skia/pull/227

I run into strange errors and after looking at the dependencies I'm not sure building the skia library locally is really an option.

I hope it's not too much to ask to run the build again and create an issue in the rust-skia repository  with the error messages attached. I'd really like to take a look.


Missing Azure Site Recovery header

Phase 2 highlights the three tools to use for migration:
Azure Migrate
Azure Site Recovery
Azure Database Migration Service
But this does not have a section header for Azure Site Recovery and kind of talks about it in the Azure Migrate section.

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

ID: 4ec4ba22-6c84-8ff4-cd28-edb539877792
Version Independent ID: 3f38a5c4-7064-ba17-6b89-59658aa746e1
Content: Scale a migration to Azure - Cloud Adoption Framework
Content Source: docs/migrate/azure-best-practices/contoso-migration-scale.md
Service: cloud-adoption-framework
Sub-service: migrate
GitHub Login: @BrianBlanchard
Microsoft Alias: brblanch

Thanks for reporting - this issue is under review.  This is a Microsoft Internal DevOps Bug ID AB#275406

Closed in a pr to be released in the next few days


Add FAQ to use CSS modules

Hi I would like to suggest adding a FAQ entry to describe briefly which modifications should be done to package.json and the webpack.config.xxx.js files to handle css modules properly.
Thanks.

PR welcome. :)

Does #236 help at all? I have proposed this before and had it working successfully. Unfortunately, it has been a while so I am unsure if it was properly transforming names like you stated.

Thanks @kwelch your fork help me realized taht I was using the wrong property... I used localIndentName  instead of localIdentName!

I am going to open this as I still believe this is something that would be useful for the docs and that PR I proposed would be a good starting point on what changes are necessary.

I'm not sure of how to create the FAQ, but the below should work, in-case anyone needs it.
{
        test: /(\.css|\.scss|\.sass)$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              importLoaders: 1,
              modules: {
                localIdentName: '[name]__[local]___[hash:base64:5]',
              },
            },
          },
          {
            loader: 'postcss-loader',
            options: {
              plugins: () => [require('autoprefixer')],
              sourceMap: true,
            },
          },
          {
            loader: 'sass-loader',
            options: {
              sassOptions: {
                includePaths: [path.resolve(__dirname, 'src')],
              },
              sourceMap: true,
            },
          },
        ],
        include: /\.module\.css$/,
      },
      {
        test: /(\.css|\.scss|\.sass)$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              sourceMap: true,
            },
          },
          {
            loader: 'postcss-loader',
            options: {
              plugins: () => [require('autoprefixer')],
              sourceMap: true,
            },
          },
          {
            loader: 'sass-loader',
            options: {
              sassOptions: {
                includePaths: [path.resolve(__dirname, 'src')],
              },
              sourceMap: true,
            },
          },
        ],
        exclude: /\.module\.css$/,
      },


Could not build wheels for insightface (on Windows)

When I tried to command in windows:
pip install insightface==0.7.3
I meet the problem below:
Processing d:\bingoyes\hallo\insightface-0.7.3.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Installing backend dependencies ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (1.26.4)
Requirement already satisfied: onnx in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (1.16.1)
Requirement already satisfied: tqdm in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (4.66.4)
Requirement already satisfied: requests in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (2.32.3)
Requirement already satisfied: matplotlib in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (3.9.0)
Requirement already satisfied: Pillow in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (10.3.0)
Requirement already satisfied: scipy in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (1.13.1)
Requirement already satisfied: scikit-learn in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (1.5.0)
Requirement already satisfied: scikit-image in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (0.23.2)
Requirement already satisfied: easydict in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (1.13)
Requirement already satisfied: cython in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from insightface==0.7.3) (3.0.10)
Collecting albumentations (from insightface==0.7.3)
  Using cached albumentations-1.4.8-py3-none-any.whl.metadata (37 kB)
Collecting prettytable (from insightface==0.7.3)
  Using cached prettytable-3.10.0-py3-none-any.whl.metadata (30 kB)
Requirement already satisfied: PyYAML in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from albumentations->insightface==0.7.3) (6.0.1)
Requirement already satisfied: typing-extensions>=4.9.0 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from albumentations->insightface==0.7.3) (4.12.2)
Collecting pydantic>=2.7.0 (from albumentations->insightface==0.7.3)
  Using cached pydantic-2.7.4-py3-none-any.whl.metadata (109 kB)
Collecting albucore>=0.0.4 (from albumentations->insightface==0.7.3)
  Using cached albucore-0.0.10-py3-none-any.whl.metadata (3.1 kB)
Requirement already satisfied: opencv-python-headless>=<IP_ADDRESS> in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from albumentations->insightface==0.7.3) (<IP_ADDRESS>)
Requirement already satisfied: networkx>=2.8 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-image->insightface==0.7.3) (3.3)
Requirement already satisfied: imageio>=2.33 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-image->insightface==0.7.3) (2.34.1)
Requirement already satisfied: tifffile>=2022.8.12 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-image->insightface==0.7.3) (2024.5.22)
Requirement already satisfied: packaging>=21 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-image->insightface==0.7.3) (24.1)
Requirement already satisfied: lazy-loader>=0.4 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-image->insightface==0.7.3) (0.4)
Requirement already satisfied: joblib>=1.2.0 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-learn->insightface==0.7.3) (1.4.2)
Requirement already satisfied: threadpoolctl>=3.1.0 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from scikit-learn->insightface==0.7.3) (3.5.0)
Requirement already satisfied: contourpy>=1.0.1 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (1.2.1)
Requirement already satisfied: cycler>=0.10 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (0.12.1)
Requirement already satisfied: fonttools>=4.22.0 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (4.53.0)
Requirement already satisfied: kiwisolver>=1.3.1 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (1.4.5)
Requirement already satisfied: pyparsing>=2.3.1 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (3.1.2)
Requirement already satisfied: python-dateutil>=2.7 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from matplotlib->insightface==0.7.3) (2.9.0.post0)
Requirement already satisfied: protobuf>=3.20.2 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from onnx->insightface==0.7.3) (4.25.3)
Collecting wcwidth (from prettytable->insightface==0.7.3)
  Using cached wcwidth-0.2.13-py2.py3-none-any.whl.metadata (14 kB)
Requirement already satisfied: charset-normalizer<4,>=2 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from requests->insightface==0.7.3) (3.3.2)
Requirement already satisfied: idna<4,>=2.5 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from requests->insightface==0.7.3) (3.7)
Requirement already satisfied: urllib3<3,>=1.21.1 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from requests->insightface==0.7.3) (2.2.1)
Requirement already satisfied: certifi>=2017.4.17 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from requests->insightface==0.7.3) (2024.6.2)
Requirement already satisfied: colorama in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from tqdm->insightface==0.7.3) (0.4.6)
Requirement already satisfied: tomli>=2.0.1 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from albucore>=0.0.4->albumentations->insightface==0.7.3) (2.0.1)
Collecting annotated-types>=0.4.0 (from pydantic>=2.7.0->albumentations->insightface==0.7.3)
  Using cached annotated_types-0.7.0-py3-none-any.whl.metadata (15 kB)
Collecting pydantic-core==2.18.4 (from pydantic>=2.7.0->albumentations->insightface==0.7.3)
  Using cached pydantic_core-2.18.4-cp310-none-win_amd64.whl.metadata (6.7 kB)
Requirement already satisfied: six>=1.5 in c:\users\bingoyes\.conda\envs\hallo\lib\site-packages (from python-dateutil>=2.7->matplotlib->insightface==0.7.3) (1.16.0)
Using cached albumentations-1.4.8-py3-none-any.whl (156 kB)
Using cached prettytable-3.10.0-py3-none-any.whl (28 kB)
Using cached albucore-0.0.10-py3-none-any.whl (8.4 kB)
Using cached pydantic-2.7.4-py3-none-any.whl (409 kB)
Using cached pydantic_core-2.18.4-cp310-none-win_amd64.whl (1.9 MB)
Using cached wcwidth-0.2.13-py2.py3-none-any.whl (34 kB)
Using cached annotated_types-0.7.0-py3-none-any.whl (13 kB)
Building wheels for collected packages: insightface
  Building wheel for insightface (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for insightface (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [215 lines of output]
      WARNING: pandoc not enabled
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build\lib.win-amd64-cpython-310
      creating build\lib.win-amd64-cpython-310\insightface
      copying insightface\__init__.py -> build\lib.win-amd64-cpython-310\insightface
      creating build\lib.win-amd64-cpython-310\insightface\app
      copying insightface\app\common.py -> build\lib.win-amd64-cpython-310\insightface\app
      copying insightface\app\face_analysis.py -> build\lib.win-amd64-cpython-310\insightface\app
      copying insightface\app\mask_renderer.py -> build\lib.win-amd64-cpython-310\insightface\app
      copying insightface\app\__init__.py -> build\lib.win-amd64-cpython-310\insightface\app
      creating build\lib.win-amd64-cpython-310\insightface\commands
      copying insightface\commands\insightface_cli.py -> build\lib.win-amd64-cpython-310\insightface\commands
      copying insightface\commands\model_download.py -> build\lib.win-amd64-cpython-310\insightface\commands
      copying insightface\commands\rec_add_mask_param.py -> build\lib.win-amd64-cpython-310\insightface\commands
      copying insightface\commands\__init__.py -> build\lib.win-amd64-cpython-310\insightface\commands
      creating build\lib.win-amd64-cpython-310\insightface\data
      copying insightface\data\image.py -> build\lib.win-amd64-cpython-310\insightface\data
      copying insightface\data\pickle_object.py -> build\lib.win-amd64-cpython-310\insightface\data
      copying insightface\data\rec_builder.py -> build\lib.win-amd64-cpython-310\insightface\data
      copying insightface\data\__init__.py -> build\lib.win-amd64-cpython-310\insightface\data
      creating build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\arcface_onnx.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\attribute.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\inswapper.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\landmark.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\model_store.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\model_zoo.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\retinaface.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\scrfd.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      copying insightface\model_zoo\__init__.py -> build\lib.win-amd64-cpython-310\insightface\model_zoo
      creating build\lib.win-amd64-cpython-310\insightface\thirdparty
      copying insightface\thirdparty\__init__.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty
      creating build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\constant.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\download.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\face_align.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\filesystem.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\storage.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\transform.py -> build\lib.win-amd64-cpython-310\insightface\utils
      copying insightface\utils\__init__.py -> build\lib.win-amd64-cpython-310\insightface\utils
      creating build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d
      copying insightface\thirdparty\face3d\__init__.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d
      creating build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\io.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\light.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\render.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\transform.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\vis.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      copying insightface\thirdparty\face3d\mesh\__init__.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh
      creating build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\io.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\light.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\render.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\transform.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\vis.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      copying insightface\thirdparty\face3d\mesh_numpy\__init__.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh_numpy
      creating build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\morphable_model
      copying insightface\thirdparty\face3d\morphable_model\fit.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\morphable_model
      copying insightface\thirdparty\face3d\morphable_model\load.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\morphable_model
      copying insightface\thirdparty\face3d\morphable_model\morphabel_model.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\morphable_model
      copying insightface\thirdparty\face3d\morphable_model\__init__.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\morphable_model
      running egg_info
      writing insightface.egg-info\PKG-INFO
      writing dependency_links to insightface.egg-info\dependency_links.txt
      writing entry points to insightface.egg-info\entry_points.txt
      writing requirements to insightface.egg-info\requires.txt
      writing top-level names to insightface.egg-info\top_level.txt
      reading manifest file 'insightface.egg-info\SOURCES.txt'
      writing manifest file 'insightface.egg-info\SOURCES.txt'
      C:\Users\bingoyes\AppData\Local\Temp\pip-build-env-ibn8tcr3\overlay\Lib\site-packages\setuptools\command\build_py.py:207: _Warning: Package 'insightface.thirdparty.face3d.mesh.cython' is absent from the `packages` configuration.
      !!

              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'insightface.thirdparty.face3d.mesh.cython' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.

              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'insightface.thirdparty.face3d.mesh.cython' is explicitly added
              to the `packages` configuration field.

              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).

              You can read more about "package discovery" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

              If you don't want 'insightface.thirdparty.face3d.mesh.cython' to be distributed and are
              already explicitly excluding 'insightface.thirdparty.face3d.mesh.cython' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.

              You can read more about "package data files" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html

              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************

      !!
        check.warn(importable)
      C:\Users\bingoyes\AppData\Local\Temp\pip-build-env-ibn8tcr3\overlay\Lib\site-packages\setuptools\command\build_py.py:207: _Warning: Package 'insightface.data.images' is absent from the `packages` configuration.
      !!

              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'insightface.data.images' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.

              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'insightface.data.images' is explicitly added
              to the `packages` configuration field.

              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).

              You can read more about "package discovery" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

              If you don't want 'insightface.data.images' to be distributed and are
              already explicitly excluding 'insightface.data.images' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.

              You can read more about "package data files" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html

              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************

      !!
        check.warn(importable)
      C:\Users\bingoyes\AppData\Local\Temp\pip-build-env-ibn8tcr3\overlay\Lib\site-packages\setuptools\command\build_py.py:207: _Warning: Package 'insightface.data.objects' is absent from the `packages` configuration.
      !!

              ********************************************************************************
              ############################
              # Package would be ignored #
              ############################
              Python recognizes 'insightface.data.objects' as an importable package[^1],
              but it is absent from setuptools' `packages` configuration.

              This leads to an ambiguous overall configuration. If you want to distribute this
              package, please make sure that 'insightface.data.objects' is explicitly added
              to the `packages` configuration field.

              Alternatively, you can also rely on setuptools' discovery methods
              (for example by using `find_namespace_packages(...)`/`find_namespace:`
              instead of `find_packages(...)`/`find:`).

              You can read more about "package discovery" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

              If you don't want 'insightface.data.objects' to be distributed and are
              already explicitly excluding 'insightface.data.objects' via
              `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
              you can try to use `exclude_package_data`, or `include-package-data=False` in
              combination with a more fine grained `package-data` configuration.

              You can read more about "package data files" on setuptools documentation page:

              - https://setuptools.pypa.io/en/latest/userguide/datafiles.html

              [^1]: For Python, any directory (with suitable naming) can be imported,
                    even if it does not contain any `.py` files.
                    On the other hand, currently there is no concept of package data
                    directory, all directories are treated like packages.
              ********************************************************************************

pp -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh\cython
      creating build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\Tom_Hanks_54745.png -> build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\mask_black.jpg -> build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\mask_blue.jpg -> build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\mask_green.jpg -> build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\mask_white.jpg -> build\lib.win-amd64-cpython-310\insightface\data\images
      copying insightface\data\images\t1.jpg -> build\lib.win-amd64-cpython-310\insightface\data\images

      creating build\lib.win-amd64-cpython-310\insightface\data\objects
      copying insightface\data\objects\meanshape_68.pkl -> build\lib.win-amd64-cpython-310\insightface\data\objects
      copying insightface\thirdparty\face3d\mesh\cython\mesh_core_cython.c -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh\cython
      copying insightface\thirdparty\face3d\mesh\cython\mesh_core_cython.cpp -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh\cython
      copying insightface\thirdparty\face3d\mesh\cython\mesh_core_cython.pyx -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh\cython
      copying insightface\thirdparty\face3d\mesh\cython\setup.py -> build\lib.win-amd64-cpython-310\insightface\thirdparty\face3d\mesh\cython
      running build_ext
      building 'insightface.thirdparty.face3d.mesh.cython.mesh_core_cython' extension
      error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for insightface
Failed to build insightface
ERROR: Could not build wheels for insightface, which is required to install pyproject.toml-based projects

You need Microsoft visual studio community installed with the additional windows c++ build tools selected in the app to be installed

Since there has been no further feedback, this issue will be closed. If needed, please reopen it.


the method browser.Load(url)  can not navigator the url

the code:
public class BaseResourceRequestHandler : ResourceRequestHandler
{
protected override void OnResourceLoadComplete(IWebBrowser chromiumWebBrowser, IBrowser browser, IFrame frame, IRequest request, IResponse response, UrlRequestStatus status, long receivedContentLength)
        {
             browser.Load("http://www.xxx.com"); //but it is not navigator to http://www.xxx.com
    }

}

if i  use the code below   will be ok
public partial class FrmAddUser : Form{
private void button1_Click(object sender, EventArgs e)
{
this.browser.Load("http://www.xxx.com");
}
}

Call Load directly on the frame. If calling http://cefsharp.github.io/api/84.4.x/html/M_CefSharp_IFrame_LoadUrl.htm directly doesn't work you'll have to raise the issue upstream.
IBrowser doesn't have a Load method from memory,  surprised if your code would even compile.
Make sure you are testing with version 84.

Call Load directly on the frame. If calling http://cefsharp.github.io/api/84.4.x/html/M_CefSharp_IFrame_LoadUrl.htm directly doesn't work you'll have to raise the issue upstream.
IBrowser doesn't have a Load method from memory, surprised if your code would even compile.
Make sure you are testing with version 84.

i'm sure the vision 84.4.1. i exchange the method and use the code below instead but it dosn't to navigator http://www.xxx.com
public class BaseResourceRequestHandler : ResourceRequestHandler
{
protected override void OnResourceLoadComplete(IWebBrowser chromiumWebBrowser, IBrowser browser, IFrame frame, IRequest request, IResponse response, UrlRequestStatus status, long receivedContentLength)
        {
             frame.LoadUrl("http://www.xxx.com"); //but it is not navigator to http://www.xxx.com too
    }

}

I'm not sure if that's meant to work, best to ask on https://magpcss.org/ceforum/index.php as it's outside of our control.

this folder lines the stupid ... a folder where they put what they do not want to answer ...

this folder lines the stupid ... a folder where they put what they do not want to answer

@arcanisgk As stated above I don't know the answer and have provided a link for the appropriate place to ask. CefSharp is just one of many chromium embedded framework wrappers. There is a much larger community available at https://magpcss.org/ceforum/index.php
Please only comment if you have something constructive to add.

I'm not going to comment on anything else ..


Characters in canvas are cropped

Attach (recommended) or Link to PDF file here:
pdfjsError.pdf
Configuration:
I tested using https://mozilla.github.io/pdf.js/web/viewer.html

Web browser and its version: Chrome 87.0.4280.88
Operating system and its version: Mac OS 11.0.1
PDF.js version: https://mozilla.github.io/pdf.js/web/viewer.html
Is a browser extension: No

Steps to reproduce the problem:

go to https://mozilla.github.io/pdf.js/web/viewer.html
open the pdf above

What is the expected behavior? (add screenshot)

Characters in bubbles are not cropped
What went wrong? (add screenshot)

Characters in bubbles are cropped

WFM, with PDF.js version 2.7.345 in Firefox Nightly 86 on Windows.

Web browser and its version: Chrome 87.0.4280.88
Operating system and its version: Mac OS 11.0.1

This does look somewhat like platform and/or browser-specific issue, rather than a PDF.js one, since otherwise you'd sort of expect it to be consistently broken everywhere.

I can reproduce the issue with Firefox 84.0 on https://mozilla.github.io/pdf.js/web/viewer.html.
macOS Mojave 10.14.6
Firefox 84.0
PDF.js 2.7.421

Interestingly, when I change the zoom level to 50%, there is almost no cropping.

Is this still reproducible, in the latest version of Firefox on MacOS?

Yes I can reproduce with Firefox nightly on MacOS (Ventura 13.6).

Here's a reduced test case:
issue12763_reduced.pdf

In using https://mozilla.github.io/pdf.js/web/viewer.html, I can reproduce on mac with Chrome but not with Safari.
@jfkthame, do you have an idea on what could be wrong here ?


types.h: time_t as int64_t

Summary
types.h: time_t as int64_t
The following code will generate errors:
auto now = time(nullptr);
auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if (last_active_time + 60 * 1000 / 1000 <= now) {
src/ams/../controller/controller_timer.h: In lambda function: src/ams/../controller/controller_timer.h:117:57: warning: comparison of integer expressions of different signedness: 'long long int' and 'long long unsigned int' [-Wsign-compare]
117 |                 if (last_active_time + 60 * 1000 / 1000 <= now) {
ref:
https://www.gnu.org/software/libc/manual/html_node/Time-Types.html
On POSIX-conformant systems, time_t is an integer type.
Advantage:
For the most POSIX applications they assume the time_t as signed and do compare with 0.
The code will become more compatible after this modification.
Disadvantage:
year 2038 problem
Someone think time_t will be overflow when set int32_t, should think his code should open TIME64 or handle the overflow himself.
Impact
32 bit time_t is now signed
This will cause Y2038 problem, if your system has this problem, you should open TIME64 or handle the overflow.
‘ put things right once and for all ’
Testing
CI

I think it was discussed some time ago, but I don't remember about the consensus: if it should be unsigned or signed. I think signed makes sense

I think it was discussed some time ago, but I don't remember about the consensus: if it should be unsigned or signed. I think signed makes sense

ALL other POSIX OS use signed integer, and we already find the compatibility issue, so it's better to follow their convention to improve the compatibility.

types.h: time_t as int64_t
The following code will generate warnings: auto now = time(nullptr); auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if (last_active_time + 60 * 1000 / 1000 <= now) {
src/ams/../controller/controller_timer.h: In lambda function: src/ams/../controller/controller_timer.h:117:57: warning: comparison of integer expressions of different signedness: 'long long int' and 'long long unsigned int' [-Wsign-compare] 117 | if (last_active_time + 60 * 1000 / 1000 <= now) {

does getActiveTime return something which is not time_t?

I think it was discussed some time ago, but I don't remember about the consensus: if it should be unsigned or signed. I think signed makes sense

ALL other POSIX OS use signed integer, and we already find the compatibility issue, so it's better to follow their convention to improve the compatibility.

otoh it breaks compatibility with nuttx itself.
if we make it unsigned, we should deprecate 32-bit time_t, IMO.

@GUIDINGLI
can you include pros/cons and references to prior discussions in the commit message?
i think a single incomplete example of compiler warning is not enough for this kind of changes.

I think it was discussed some time ago, but I don't remember about the consensus: if it should be unsigned or signed. I think signed makes sense

ALL other POSIX OS use signed integer, and we already find the compatibility issue, so it's better to follow their convention to improve the compatibility.

otoh it breaks compatibility with nuttx itself.

Which kernel code does depend on the unsigned time_t? Anyway, we need ensure the code owned by NuttX working for time_t which could be signed/unsigned or 32/64bit. But many userspace library comes from *nix, they may never try or encounter the unsigned time_t before since all POSIX OS except NuttX define time_t to signed.
if we make it unsigned, we should deprecate 32-bit time_t, IMO.
Actually, we never ship the product which define time_t to 32bit. It's fragile and hard to handle 2038 issue with 32bit integer.

I think it was discussed some time ago, but I don't remember about the consensus: if it should be unsigned or signed. I think signed makes sense

ALL other POSIX OS use signed integer, and we already find the compatibility issue, so it's better to follow their convention to improve the compatibility.

otoh it breaks compatibility with nuttx itself.

Which kernel code does depend on the unsigned time_t?

i meant, our own 32-bit time_t is signed even if we merge this PR.

if we make it unsigned, we should deprecate 32-bit time_t, IMO.
Actually, we never ship the product which define time_t to 32bit. It's fragile and hard to handle 2038 issue with 32bit integer.

i meant we == nuttx.
i guess you meant we == xiaomi.
i agree it doesn't make much sense to ship a product with 32-bit time_t anymore.

@GUIDINGLI @acassis @xiaoxiang781216
Update time_t to int32_t & int64_t either in TIME32 or TIME64

@acassis @xiaoxiang781216 @yamt @jkivilin
If you don't have any more questions, then this PR will be merged after CI pass

@acassis @xiaoxiang781216 @yamt @jkivilin If you don't have any more questions, then this PR will be merged after CI pass

I always prefer to align the implemented define behavior with other popular POSIX OS to improve the compatibility.

@acassis @xiaoxiang781216 @yamt @jkivilin If you don't have any more questions, then this PR will be merged after CI pass

i feel a few days is too short for this kind of change. please wait for at least a week. also, please make a bold announcement with the explanation of implications (especially negative ones) on the mailing list.

i still think it's better for nuttx to keep time_t unsigned until we actually drop 32-bit time_t support.
but i can understand people prefer signed time_t.

@xiaoxiang781216 please wait before merging this PR. @yamt and #sebastien  are against this change.
I think compatibility with other OS is good, but the Y2038 BUG is a big concern here!

@xiaoxiang781216 is there some way to show the warning at end of the compilation? Maybe #warning will be ignored because people doesn't see it during the build process

Disadvantage:
None.

Are you kidding?

Please be mindful of your words.

This is putting a HUGE number of unknown projects at risk. You dont know which unknown projects are using unsigned 32 bits timestamps out there. This will be a major and dangerous regression for them.

As I said in the mail list:
You should find a better way to ‘ put things right once and for all ’, and not use the unsigned int to postpone the occurrence.

This change requires these project to be EXTRA careful about how they handle time comparisons.

Lots of bug are report on this, after the SUB they suppose result will be < 0, but compare failed caused by the time_t to unsigned.

AT LEAST, please, add an explicit #warning "32 bit time_t is now signed" that triggers when CONFIG_SYSTEM_TIME64 is not defined. Pretty please.

Accept this, added

This is putting a HUGE number of unknown projects at risk. You dont know which unknown projects are using unsigned 32 bits timestamps out there. This will be a major and dangerous regression for them.
This change requires these project to be EXTRA careful about how they handle time comparisons.

@slorquet unsigned time_t need be EXTRA careful than signed time_t since almost project only test with signed time_t due OS mapping time_t to signed type.

To move forward and keep things compatible and elegant I proposed Kconfig selectable type for time_t so its not hardcoded and so developers have a choice.
We currently discuss on the mailing list whether to split that type defaults for 32/64-bit platforms and smaller ones, or to have common single list of types to configure via Kconfig before build for time_t, and it turns out int64_t seems best default, while easy switch to int32_t or uint32_t is still available for the developer if necessary as required.
One list of choice should keep this setting crystal clear, in one place, with conscious manual selection (no hidden inconsistencies, no auto-detection, no variants, etc), configuration level selectable, no code modification, etc.
As this selection is crucial it can be printed explicitly on screen summary as part of configure process.
@codebje confirmed uding int64_t as virtual type variable should have small impact and is worth solving the 32-bit storage problem whether signed (Y2038 problem) or unsigned (build errors and on ported GNU software). Biggest impact will be on Cortex-M0, 16-bit, and 8-bit platforms.

https://godbolt.org/z/8bKj6an4z
I don't think, personally, that any of this is reason enough to worry about it. Using an int64_t for time_t is IMO a perfectly reasonable default for 32-bit and up targets. and possibly for all targets. Offering a kconfig option to support 32-bit (signed or unsigned) time_t offers an easy work-around should anyone find that the couple of percent increase in code size and execution time causes their project to fail - or if anyone is in the unfortunate situation where they depend on code that's made assumptions about size or signedness.

@slorquet proposes casting on each time arithmetics as solution to signed/unsigned problem but leaving defaults as-is.
@yamt had some objections to configuration selectable time_t types but we are waiting for precise alternative solution proposition. I guess @yamt along with @slorquet want to keep uint32_t as default not the int64_t do I get this right?
@patacongo what solution sounds best for you? :-)

@GUIDINGLI please update as the discussion in email list.

3. int64_t is the default (according to POSIX.1-2024 / IEEE Std 1003.1-2024 / The Open Group Standard Base Specifications, Issue 8 [1][2][3]).

It is not "the default", it is the exact with of time_t as specified by POSIX 2024.  It is not a choice.  It is not an option.  It is the POSIX required size.

@cederom: > 3. int64_t is the default (according to POSIX.1-2024 / IEEE Std 1003.1-2024 / The Open Group Standard Base Specifications, Issue 8 [1][2][3]).
@patacongo: It is not "the default", it is the exact with of time_t as specified by POSIX 2024. It is not a choice. It is not an option. It is the POSIX required size.

I see, so we end up with simply int64_t time_t according to POSIX.1-2024 :D

I see, so we end up with simply int64_t time_t according to POSIX.1-2024, no Kconfig selectable options :D

Petty hard to escape that interpretation.  I would have preferred a little more efficient use of memory.  Like setting aside some bits for better time resolution now that we have more bits than needed.


[TASK] Add PHP 8.2 to test maxtrix

The prophecy issue is tracked with https://github.com/phpspec/prophecy/issues/556


Added request.cookies command to fix file downloads

Added request.cookies command to only fetch the cookies without response/content.
This fixes file downloads using external libraries (for example CloudProxySharp).
It's working fine as of now.
The only thing missing is handling captchas, haven't tested it yet and don't know how it behaves.
Would like this PR to get merged, maybe someone else could try out with captcha-harvester. I'm not using it.

This is also related to #20 and should make life easier for @lululombard.
It doesn't return the file as response or serialized as json (as described here), but it returns valid cookies for the other client or library to use, without blocking the response as before, and the the client/library can handle the download itself and in a nativ way (without workarounds).
We are intercepting the response here (using Chrome DevTools Fetch API before the response-content is send to the browser, but after the cookies/response-headers are received.

I'll take a look at this on Monday, it's currently Saturday for me and I'm adding the finishing touches to a hackathon project 💀

Re: https://github.com/NoahCardoza/CloudProxy/issues/31#issuecomment-739591558
Since I don't have much time but wan't want to be the bottleneck, I'm just going to merge this. I just went over it and it seems all good so let's hope for the best.
I'll take a more in-depth look this weekend hopefully.

Thanks a lot!
The only thing left is to add documentation about this endpoint in the readme.


Orderful matcher

Hi! I am scouting out Selectrum. Coming from Ivy land, I miss ivy--regex-plus.
That matcher might seem simplistic, but I came to appreciate it as the most potent matcher I've ever used due to its specificity: it quickly winnows down the candidate list. My workflow has been to call ivy-restrict-to-matches (S-SPC) when orderless was desired, and otherwise benefit from specificity.
Maybe I could learn to work a new way by toggling between various filter methods, use hippie-expand in the minibuffer or something... I'm not sure how people get by with orderless without a lot of extra typing. Tips would be welcome!
Would you accept a PR about an orderful matcher, and where should I start?
From what I can see, it's not as simple as adding a method to prescient-filter-alist, because the query has already been split on spaces by the time that variable is consulted. We'd need to override the function prescient-filter-regexps so that, instead of returning a list of regexps, it returns a list of a single regexp that has joined the subqueries with .*? in between. Maybe an if clause that detects if prescient-filter-method contains a symbol like orderful and does this.
Here is some code, but it does not seem to work. I marked my additions with ;;.
  (push 'orderful prescient-filter-method)          ;;

  (defun prescient-filter-regexps (query &optional with-groups)
    "Convert QUERY to list of regexps.
Each regexp must match the candidate in order for a candidate to
match the QUERY.

If WITH-GROUPS is non-nil, enclose the initials in initialisms
with capture groups. If it is the symbol `all', additionally
enclose literal substrings with capture groups."
    (let ((result                                   ;;
           (mapcar
            (lambda (subquery)
              (string-join
               (cl-remove
                nil
                (mapcar
                 (lambda (method)
                   (if-let ((func (alist-get method prescient-filter-alist)))
                       (funcall func subquery with-groups)
                     ;; Don't throw error if function doesn't exist, but do
                     ;; warn user.
                     (message
                      "No function in `prescient-filter-alist' for method: %s"
                      method)))
                 (pcase prescient-filter-method
                   ;; We support `literal+initialism' for backwards
                   ;; compatibility.
                   (`literal+initialism '(literal initialism))
                   ((and (pred listp) x) x)
                   (x (list x))))
                :test #'eq)
               "\\|"))
            (prescient-split-query query))))
      (if (member 'orderful prescient-filter-method) ;;
          (list (string-join result ".*?"))          ;;
        result)))                                    ;;

Alright, I gave the "initialisms" method a spin and it's wonderful. I'll close the issue because I can live with this. Maybe someone else can reopen it.
In case you want a blurb in the README for people like me, I'll take a stab.
Blurb
"But I don't want orderless matching!" So basically, the default prescient-filter-method at this time is '(literal regexp initialisms). When you can't narrow down your candidates e.g. the search ess tr includes ess-tracebug but might promote string-lessp as the first candidate, a frustration if you were used to ivy--regex-plus, but at this point you can extend the query to ess tr et, because "et" is an initialism for "ess-tracebug". Try it! Similarly, the "regexp" method helps if you used to search for org files by appending "org", let's say with the query d org which includes diary-2020.org but now also includes organize.md or something, well you can extend the query to d org$ which fixes the issue. The dollar sign $ signifies the end of the string.

Excellent, glad to hear you found an approach that works for you! I'm also definitely not opposed to making the orderful behavior customizable, if that turns out to be desirable after all.


[BUG] Mobile category tile differs from the designs

The spacings are different (its visible especialy on mobile category page) + multiline is allowed in components while its not on designs

https://github.com/DivanteLtd/storefront-ui/pull/1555


The number of columns in your data file does not match the LAMMPS atom_style you selected.

Dear Andrew
When I generated the system. data file for the newest version, I got the error " The number of columns in your data file does not match the LAMMPS atom_style you selected. Use the -atomstyle

Hi Tue Le
I few days ago I posted an update (v2.20.0) which makes some moderately large changes to the code.  While this new version of moltemplate is able to pass the automated tests I designed, it's possible that I introduced some new bugs.  (On the other hand, 2020-7-26 is a long time ago.)  Either way I take this report seriously.  But I need more information to address this problem.
If you are running into this problem using one of the moltemplate examples, please tell me which one.  On the other hand, if this is a file you created or modified, can you send all of the LT (.lt) files for the system you are trying to build.  (If you are using the -pdb, -xyz, or -raw arguments, then also include those files as well.)  Please tell me the files you used and the steps you used (the commands you typed into the shell) so I can reproduce your problem.
Thanks for reporting.

Dear Andrew
Here is my file. The problem is only the file name "Chitosan.lt". In the old version, there was no error, but I got the error with the new version. Thank you for considering the error.
Chitosan.zip

Thanks for sending those files.  The bug was indeed introduced recently.  I think I fixed the bug.  Try the latest version of moltemplate (v2.20.1) and let me know if it helps.  I haven't uploaded it to the moltemplate.org website yet, but you can get it from github.
Reports like yours really help.  Thank you!

I'm closing this bug.  But if you run into trouble, please reopen it.
Thanks again.
-Andrew


Catalog(Page) pagination

Today adopters with 5k+ might encounter issues when viewing the /catalog page.
The issues are related to how the entities are fetched by the frontend. By default (almost) all the entities present in the database are fetched and returned in one shot.
This means that in some cases the loading time of the CatalogPage is high. This issue has been pointed out by dozens of adopters. In some cases the issue wasn’t only affecting loading time of the CatalogPage, but has affected the entire usability of the UI. Since a lot of UI components depend on having all the entities downloaded and available in the frontend, in some cases the UI freezes or becomes unresponsive.
In order to fix the issue mentioned above, pagination on the catalog’s entities needs to be enforced.
At the moment, the entities are fetched from the GET /entities endpoint, which returns an array of results.
The endpoint supports offset pagination, meaning that on each request, it is possible to provide offset, limit and cursor.
However, whenever a request is sent, only the array of results is sent back to the caller, while all the pagination data gets discarded. Due to this limitation, it is not possible to send subsequent requests to the same endpoint, meaning that it isn’t possible to use pagination.
Having a fully supported paginated endpoint is crucial to provide a good user experience of the CatalogPage.
Proposed solution
In order to not introduce breaking changes to the current endpoint, I propose to create a new version of the /entities endpoint which returns a paginated response of the entities.
I’ve been investigating the proposed solution and I came to a conclusion: this wouldn’t be enough.
Unfortunately, during the years, a lot of logic has been built on top of the CatalogPage.
As a result, a lot of filters depend on having all the entities available on the frontend in order to work properly.
So, together with the new endpoint, all the frontend filters need to be rebuilt.
Some of them were fairly easy to fix, like owners, lifecycle and tags.
Others, like starred or owned entities, were a bit more complicated.
During the last (6) months I’ve been working on this and I reached out to a good solution, proving that it is possible to make the CatalogPage work with 30k+ entities.
The amount of work has been massive. However I think it is possible to split the work into small pull requests, in order to ship this as soon as possible.
I will use this issue to track the work that needs to be done, in order to implement a better Catalog Page.

[ ] Create new paginated entities endpoint #12246
[ ] Decoupling filters from having all the entities available in the frontend
[ ] Build pagination on top of EntityListProvider and DefaultCatalogPage

https://user-images.githubusercontent.com/8433119/175358148-dcac96a3-a0bf-4573-91ef-d5d6734768ca.mov

In order to fix the issue mentioned above, pagination on the catalog’s entities needs to be enforced.

Maybe not enforced, but at least better supported. Enforcing is more a matter of protecting the backend than enabling the proposed frontend speedups.

At the moment, the entities are fetched from the GET /entities endpoint, which returns an array of results. The endpoint supports offset pagination, meaning that on each request, it is possible to provide offset, limit and cursor. However, whenever a request is sent, only the array of results is sent back to the caller, while all the pagination data gets discarded. Due to this limitation, it is not possible to send subsequent requests to the same endpoint, meaning that it isn’t possible to use pagination.

Not quite accurate.

It does support two different pagination methods: offset/limit, and cursor based.
The cursor based one happens to at this point be implemented in terms of offset/limit under the hood as a shortcut, but that's opaque to the user; if we made it smarter under the hood nothing would have to change from the calling side
Pagination info is actually returned in the response, but in terms of a Link response header, not in the body - so callers can absolutely perform pagination already today, with both methods

Having a fully supported paginated endpoint is crucial to provide a good user experience of the CatalogPage.

Yep indeed but it's so far been more about how capable the filtering and sorting is.
Let me also add one intermediate step that I've mentioned in the past. Instead of going the full way to getting the perfect situation in place where the backend can mirror the filter state and get precisely one ideal page... The frontend could "stream" in data by issuing a number of paginated backend requests, filling up an internal buffer until there's enough data to show just the first page in the frontend. When client filtering has been applied, maybe it had to load 200 entities from the backend in two 100-entity pages until it had the requisite 20 matching ones to display. Then it sends that to the table, which has a much, much smaller amount of data to process and bother React with. Then when the user goes to page two, we stream in more pages until we have 40 matching ones to display, etc. This solution is obviously not perfect when there are very very few or even zero matches, because we have to make a lot of backend requests still. But those will at least be using all of the backend-capable filters (e.g. kind matching); it's only the client-only filters that have to be applied afterwards.

any progress of this issue

any progress of this issue

We're looking at merging on of the pieces of this here: https://github.com/backstage/backstage/pull/12246

Is this done yet? I know work was happening on it up above, but it looks like this was auto-closed rather than properly closed

work happening as we speak 😄

Surprisingly: any progress of this issue 🤔😄

Surprisingly: any progress of this issue 🤔😄

progress are tracked in some checkboxes at the end of the description 😄

Bump: Very interested in this

Yeah the catalog frontend still isn't properly leveraging the backend's pagination capabilities. Essentially it still calls the old APIs that were there before pagination support was added

Any updates on this one? My catalog page is almost unusable at times because of this issue.

I believe this was fixed by #21202 but it needs a prop to be added to the page at this point. See https://backstage.io/docs/releases/v1.21.0#catalog-pagination

Oh sorry there may have been some follow-up actions left at the top still - reopening

Count insights of the records should be enabled also

Is there a plan to think about / work on server side sorting?

Is there a plan to think about / work on server side sorting?

Server side sorting is done backend side. What is currently missing is the ability to sort entities properly when clicking on a column of CatalogTable.


Allow product to only provide one of the queries

See issue for details. Making this change per a discussion in our weekly sync on 04/10.
Closes #98

/verified

/verified

/lgtm

/verified


add ternary search

Sure , I will do that.
"search/init.py"
"tests/test_search.py"
Yes?

Sure , I will do that.
"search/init.py"
"tests/test_search.py"
Yes?


Uart Flow Control

I have been looking at the serial implementation for some time now, and I wonder is there a plan to expand it to allow Hardware flow control? I am a rust novice, and have no experience working on the implementation side of an HAL.
In my mind, I could use the PAC to activate hardware flow control, and continue using the rest of the crate serial library provided normally. I am unsure if I might be missing something here or if this would cause other issues.
Alternativey, is someone already working on this, or does anyone have advice as to where to get started adding it to the HAL. I wouldn't want to go against the design principles, but the only example I found was in https://github.com/stm32-rs/stm32l4xx-hal. It has quite a few differences in structure, and would probably require refactoring throughout the rest of the implementation. Is there a way around this?
Sorry for the rambling nature of the issue, but I am not sure where to start.
Edit: I took a look at how the initialization of the function works, and I believe that if I set the Hardware Flow control in the relevant UART before starting the rest it will work correctly. I will edit again when I've confirmed this.

Hello @FlippievanDyk ,
The Rust Embedded Book gives a nice illustration on what PACs and HALs are doing. Ideally, the HAL is abstracting on the PAC to control the hardware and you don't need to use the PAC at all.
I'm not sure what you mean by "hardware flow control", but if your goal is to simply get the uart running, check out the example on USB and the recent  example on DMA and Serial.
Hope that helps.

Hi @strom-und-spiele
Hardware flow control refers to the CTS and RTS pins. These are typically used to ensure that a high speed UART's buffer are ready to receive and ready to send. As you say, the HAL abstracts the HAL so that the PAC is not required. However, at present the HAL does not seem to be able to control those pins.
I have looked at the DMA example, and got it running, but my application is going to require the CTS/RTS pins to function properly.
That said, I've looked at the library,  and I have been able to set the uart up to my satisfaction, however it was hardcoded and not general at all. I need more experience with macros to make it easily useable.
I have multiple things to juggle at the moment, hopefully I can look at this properly soon.

Thanks for clearing that up.
To summarize: the f3xx-hal is obfuscating the grouping of the pins in a huge macro. Whereas the l4xx-hal introduces a  new trait and impl it for different pin groupings.
I also found my self implementing the RTS/CTS pins for an earlier application by hand. I guess the way it is implemented in l4xx has a better DX.
I'd suggest adding this to https://github.com/stm32-rs/stm32f3xx-hal/issues/122.