Topology proposals and system construction

General question--how should topology proposals be organized, and how should they be matched with System construction?
Currently, under the small molecule scheme, there is:

Transformation

SmallMoleculeTransformation

SingleSmallMolecule
SmallMoleculeProteinComplex

So, it's grouped by the task of constructing systems. However, @jchodera points out that it's wise to group by the type of proposal (again, using small molecules as an example):

Transformation

SmallMoleculeTransformation

LibrarySmallMoleculeTransformation
SyntheticAccessbilityTransformation
...etc.

Thoughts on this?

I like grouping this by type of proposal:
* Transformation
   * SmallMoleculeTransformation
      * SmallMoleculeLibrary
      * CombinatorialLibrary
      * ReactionAwareSynthesis
   * PolymerTransformation
      * PointMutation
      * PeptideLibrary

These classes should focus on manipulating the Topology object and creating the atom mapping between old and new Topology objects
We can separate out the system building machinery into a helper SystemBuilder tool that uses the Topology to create a modified System.  We're nearly done making changes to the OpenMM ffxml handler and AMBER forcefields that will allow us to resurrect the old YANK SystemBuilder for this purpose.

Yeah, the more I think about this, the more I like grouping by type of proposal. Scientifically, it seems to make more sense.

The design should maximize code reuse (or minimize code duplication). There are certainly opportunities for experimentation within these classes to improve efficiency. This could either be done with adding more class options or through subclasses, though class options may be easier.  We should think about how we might want to specify these options at runtime, perhaps through a YAML file as with YANK.
We will also need sampler drivers:

MCMCSampler - samples with fixed log weights g_k
SAMSSampler - adjusts weights g_k to produce marginal distribution that matches imposed pi_k

Once we write these components, it should be easy to confine most of our scientific tinkering to various design/optimization classes that run multiple SAMSSamplers (via MPI?) and do their thing by using the online g_k estimated to update the target pi_k that is fed back to the samplers.

Would it help to flesh out the APIs for these things further, or is it pretty straightforward?

It would probably help to do that. If anyone has a suggestion, feel free to either post it here or open a PR. After I finish the current PR in the next few days, I am happy to modify my current topology proposal stuff to conform to the consensus.

Let's brainstorm a bit on how we want to use this for a few use cases:

Computing all binding free energies for molecules in a library
Identifying the best binders from a combinatorial library
Identifying resistance mutants to a given compound
Identifying compounds that optimally bind a target but not an antitarget using reaction-aware synthesis

What about something like this?
Computing binding free energies for all molecules in a library.
# Initialize a forcefield engine, which will also be able to parameterize small molecules in addition to polymer residues.
ffxmls = ['amber99sbildn.xml', 'gaff.xml', 'tip3p.xml', 'ions.xml']
forcefieldplus = ForceFieldPlus(*ffxmls)
gaff_typer = GAFFSmallMoleculeParameterizer('gaff.xml')
forcefield.addExtension(gaff_typer) # parameter assignment for small molecules

# Load a protein-ligand system with a reference ligand bound.
from simtk.openmm.app import PDBFile
pdb = PDBFile('abl-imatinib.pdb') # load a file where all residues have already been modeled and all atoms have been added to the ligand

# Solvate the complex.
from simtk.openmm.app import Modeller, ForceField
modeller = Modeller(pdb.topology, pdb.positions)
forcefield = ForceField(*ffxmls)
modeller.addSolvent(forcefield, model='tip3p', padding=10*angstroms, neutralize=True, ionicStrength=50*millimolar)

# Create a system.
system = forcefieldplus.createSystem(pdb.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=9*angstroms, rigidWater=True, removeCMMotion=False)

# Load the small molecule library, a SmallMoleculeTransformation subclass.
# Maybe it is better to call this a ProposalEngine instead of a Transformation?
library = SmallMoleculeLibrary(filename='library.mol2')

# Add the reference ligand to the compound library and tell the Topology object which part of the system it should be sampling.
topology = TopologyPlus(pdb.topology) # an enhanced version of the OpenMM Topology object
reference_ligand = topology.select('resname MOL')
library.addMolecule(reference_ligand.asOEMol()) # add the reference compound to the library
library.setMoleculeToSample(reference_ligand) # tell it which part of the Topology object it should be sampling

# Create a sampler to automatically determine their free energies
sampler = SAMSSampler(system=system, topology=topology, positions=modeller.positions, proposal_engine=library)

This postulates we create two additional classes that behave like more functional versions of OpenMM classes:

ForceFieldPlus: Like ForceField, but allows the addition of extensions that can type other parts of the Topology object
TopologyPlus: Like Topology, but useful

We may be able to get these into OpenMM proper, but we don't need to worry about that for now.

Whoops---this only handles the case where there is a single simulation (the complex), which doesn't correspond to any of our design problems.  Let me think about how to flexibly generalize this to the case where we have SAMS deal with the ligand-in-complex and ligand-in-solvent simulations at the same time.

Hm, I like the proposed extensions to ForceField. I think a useful version of Topology would be great, but at least for my present applications, I don't think it's completely necessary at the moment.
I think that this part:
topology = TopologyPlus(pdb.topology) # an enhanced version of the OpenMM Topology object
reference_ligand = topology.select('resname MOL')
library.addMolecule(reference_ligand.asOEMol()) # add the reference compound to the library
library.setMoleculeToSample(reference_ligand)

is very useful, but I think we can accomplish it in another way (for the near term, at least). For instance, do we need the atom selection DSL? Could we have instead: reference_ligand = topology.residues['MOL']?
Also, why not just have the library initially include the starting molecule, and just set the sampler's initial state that way? Currently, the idea is that inside the sampler we'd instantiate the Transformation (+1 on changing the name to ProposalEngine, btw, I'm just using the current name for clarity), and when we call transformation.propose(...) we pass to it the current system, topology, positions. We do need to correctly set the initial SMILES string, so there may be some use for something that perceives the initial molecule.
I also don't think that we necessarily want the library object to keep the state--instead, the Sampler should do that, and call library.propose(current_state...). Otherwise, it's possible that a bug could make things out of sync...
In general, my thinking thus far is:

I really like the proposed ForceField extensions and think that's the priority here.

We probably want something to perceive the ligand in the initial simulation to avoid the potential bug of someone mis-specifying the initial molecule.

I don't think the selection DSL is particularly necessary for us, since simple queries can be addressed in a dict style paradigm, and more complex queries can be made nicely in Python as long as TopologyPlus is a somewhat pythonic object.

I don't think that the Transformation or ProposalEngine should contain the logic for estimating free energies or other analyses. I actually think that might be better left to an Analysis class (which would also allow easier flexibility in terms of mixing and matching proposals and analysis methods).

More thoughts to come later, but that is my initial reaction.

I think a useful version of Topology would be great, but at least for my present applications, I don't think it's completely necessary at the moment.

Excellent point.  If we can specify residue spans we can get away with that.  We just have to make sure it works more or less straightforwardly for selecting the entity to be modified in all of the applications above.

Also, why not just have the library initially include the starting molecule, and just set the sampler's initial state that way?

The library on disk may not contain the molecule in the X-ray structure if we're using a molecule set form ZINC or eMolecules.  We needed a simply way to add whatever molecule is already present and set it as the current ligand, so I suggested one way to do it.  We can certainly go with other ways!
In thinking about how to extend this to multitarget design, we may need to add a separate ligand for each cocrystal structure (both of which should be in the whole pool?) and allow each MCMCSampler or SASASampler to have its own residue selection for which part of the topology object is being replaced by the SmallMoleculeLibrary proposed transformations.  Each sampler should also separately track which state is currently active.  I'm not sure if that means we would have a single SmallMoleculeLibrary object that could be associated with multiple samplers (this seems ideal for memory savings, but could be a problem if we distribute the samplers to multiple nodes) or a separate instance of SmallMoleculeLibrary associated with each sampler.

We do need to correctly set the initial SMILES string, so there may be some use for something that perceives the initial molecule.

Yeah, this should probably be part of the call like library.setMoleculeToSample()---it could match the molecule to one in the library and set the metadata to be the current SMILES string.
Do you want to use an integer index representation of which state is active in order for SASASampler to simply work in the compact space of integer indices [0,states), or would you rather use some more general key system so that it can adjust free energies based on, say, SMILES strings as keys to a dict of relative free energies?

I also don't think that we necessarily want the library object to keep the state--instead, the Sampler should do that, and call library.propose(current_state...). Otherwise, it's possible that a bug could make things out of sync...

I think your suggestion of having the sampler keep track of the state is the best approach.

I don't think that the Transformation or ProposalEngine should contain the logic for estimating free energies or other analyses. I actually think that might be better left to an Analysis class (which would also allow easier flexibility in terms of mixing and matching proposals and analysis methods).

Excellent point.  If SASASampler keeps track of relative free energies with general keys (which could be SMILES, peptide sequences, etc) we can always have accessors to in the ProposalEngine subclasses that query more information about these keys and just have an Analysis object do that when printing reports.

It looks like we will need a whole set of Design and Analysis drivers---one to run the simulations and couple the SASASampler chains via updates to `$\hat{\pi}_k$, and one to do the analysis afterwards.
Maybe something like this?
# Construct a target function for multi-target design to bind to Abl but not Src.
# Keys specify SASASampler objects, and values are exponents in the computation of target weights.
# \hat{\pi}_k = Z_{Abl L_k} / Z_{Src L_k}
targets = { abl_sampler : 1.0, src_sampler : -1.0 }
# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(targets, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

Would there be use for other variants of MultiTargetDesign, or is this general enough for what we want?

Also tagging @andrrizzi (who is working on streamlining system setup) and @juliebehr (who will need to build her mutational design platform with this framework(.

Could we have instead: reference_ligand = topology.residues['MOL']?

Does this capability exist now, @pgrinaway, as a parmed or mdtraj thing?  Or is this functionality we would implement?

I think we might need to implement it. AFAIK parmed and mdtraj offer a ResidueList or a generator, respectively (as well as a method that allows residue access by index in mdtraj).

mdtraj does have the atom selection syntax, though.

Here's a more complete version of the above example.  Still not perfect, but improving.
Computing binding free energies for all molecules in a library
# Initialize a forcefield engine, which will also be able to parameterize small molecules in addition to polymer residues.
ffxmls = ['amber99sbildn.xml', 'gaff.xml', 'tip3p.xml', 'ions.xml']
forcefieldplus = ForceFieldPlus(*ffxmls)
gaff_typer = GAFFSmallMoleculeParameterizer('gaff.xml')
forcefield.addExtension(gaff_typer) # parameter assignment for small molecules

#
# Set up sampler for protein:ligand complex
#

# Load a protein-ligand system with a reference ligand bound.
from tools import StructureHelper
complex = StructureHelper(rcsbid='2HYY', chains=['A'], addMissingResidues=True, addMissingHeavyAtoms=True, protonateLigand=True) # convenience function for some modeling steps, returning parmed.Structure

# Identify the reference ligand
reference_ligand = complex[':STI']

# Solvate the complex.
from simtk.openmm.app import Modeller, ForceField
complex_modeller = Modeller(complex.topology, complex.positions)
forcefield = ForceField(*ffxmls)
complex_modeller.addSolvent(forcefield, model='tip3p', padding=10*angstroms, neutralize=True, ionicStrength=50*millimolar)

# Create a system for the ligand in complex
complex_system = forcefieldplus.createSystem(complex_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=9*angstroms, rigidWater=True, removeCMMotion=False)

# Load the small molecule library, a SmallMoleculeTransformation subclass.
# Maybe it is better to call this a ProposalEngine instead of a Transformation?
library = SmallMoleculeLibrary(filename='library.mol2')

# Add the reference ligand to the compound library
library.addMolecule(reference_ligand.topology) # add the reference compound to the library

# Create a SAMS sampler for the complex.
# Note that we tell the SAMSSampler which atoms to tell the ProposalEngine to use in constructing its first proposal
# SAMSSampler needs to keep track of these atoms because it will know whether a proposal is accepted or rejected, while the ProposalEngine doesn't keep track of this information (though we may want it to)
complex_sampler = SAMSSampler(system=complex_system, topology=complex_modeller.topology, positions=complex_modeller.positions, proposal_engine=library, proposal_atom_selection=reference_ligand.topology)

#
# Set up sampler for ligand in solvent
#

# Solvate the reference ligand.
from simtk.openmm.app import Modeller, ForceField
solvent_modeller = Modeller(reference_ligand.topology, reference_ligand.positions)
solvent_modeller.addSolvent(forcefield, model='tip3p', padding=10*angstroms, neutralize=True, ionicStrength=50*millimolar)

# Create a system for the ligand in complex.
solvent_system = forcefieldplus.createSystem(solvent_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=9*angstroms, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the ligand in solvent.
# Note that we tell the SAMSSampler which atoms to tell the ProposalEngine to use in constructing its first proposal
# SAMSSampler needs to keep track of these atoms because it will know whether a proposal is accepted or rejected, while the ProposalEngine doesn't keep track of this information (though we may want it to)
complex_sampler = SAMSSampler(system=solvent_system, topology=solvent_modeller.topology, positions=solvent_modeller.positions, proposal_engine=library, proposal_atom_selection=reference_ligand.topology)

#
# Create the design sampler
#

# Construct a target function for maximizing ligand binding to Abl
# Keys specify SASASampler objects, and values are exponents in the computation of target weights.
# \hat{\pi}_k = Z_{Abl L_k} / Z_{L_k}
targets = { complex_sampler : 1.0, solvent_sampler : -1.0 }
# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(targets, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

Updated the above a bit.  This scheme relies on duck typing: ForceFieldPlus behaves like ForceField; parmed.Topology behaves like Topology, etc.  We make use of parmed.Structure for selections.

Here's what target/antitarget ligand design would look like using this approach (tagging @steven-albanese):
# Parameters
cutoff = 9*angstroms
padding = cutoff + 1*angstrom
ionic_strength = 50*millimolar

# Initialize a forcefield engine, which will also be able to parameterize small molecules in addition to polymer residues.
ffxmls = ['amber99sbildn.xml', 'gaff.xml', 'tip3p.xml', 'ions.xml']
forcefieldplus = ForceFieldPlus(*ffxmls)
gaff_typer = GAFFSmallMoleculeTyper('gaff-type-definitions.xml')
forcefield.addExtension(gaff_typer) # parameter assignment for small molecules

#
# Load protein:ligand complex structures
#

from tools import StructureHelper
abl_complex = StructureHelper(rcsbid='2HYY', chains=['A'], addMissingResidues=True, addMissingHeavyAtoms=True, protonateLigand=True)
abl_ligand = abl_complex[':STI']
src_complex = StructureHelper(rcsbid='1Y57', chains=['A'], residues=range(270,524), addMissingResidues=True, addMissingHeavyAtoms=True, protonateLigand=True)
src_ligand = abl_complex[':MPZ']

#
# Set up the library
#

# Load the small molecule library, a SmallMoleculeTransformation subclass.
library = SmallMoleculeLibrary(filename='library.mol2')

# Add the reference ligands to the compound library
library.addMolecule(abl_ligand.topology)
library.addMolecule(src_ligand.topology)

#
# Set up sampler for abl:ligand
#

# Solvate the complex
abl_modeller = Modeller(abl_complex.topology, abl_complex.positions)
abl_modeller.addSolvent(forcefieldplus, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
abl_system = forcefieldplus.createSystem(abl_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
abl_sampler = SAMSSampler(system=abl_system, topology=abl_modeller.topology, positions=abl_modeller.positions, proposal_engine=library, proposal_atom_selection=abl_ligand.topology)

#
# Set up sampler for src:ligand
#

# Solvate the complex
src_modeller = Modeller(src_complex.topology, src_complex.positions)
src_modeller.addSolvent(forcefieldplus, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
src_system = forcefieldplus.createSystem(abl_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
src_sampler = SAMSSampler(system=src_system, topology=src_modeller.topology, positions=src_modeller.positions, proposal_engine=library, proposal_atom_selection=src_ligand.topology)

#
# Create the design sampler
#

# Construct a target function for maximizing ligand binding to Src but not Abl
# Keys specify SASASampler objects, and values are exponents in the computation of target weights.
# \hat{\pi}_k = Z_{Src L_k} / Z_{Abl L_k}
target_samplers = { src_sampler : 1.0, abl_sampler : -1.0 }
# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(target_samplers, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

We could probably even layer helper functions on top of this to set up the target samplers, like this:
# Specify targets with a dict
targets = [
    { name : 'Src', weight : +1, rcsbid : '2HYY', chains : ['A'], ligand_selection : ':STI' },
    { name : 'Abl', weight : -1, rcsbid : '1Y57', chains : ['A'], residues : range(270,524), ligand_selection=':MPZ' },
    ...
]

# Create all the target samplers using same options for all samplers.
options = { 'ionic_strength' : 50*millimolar, 'nonbondedMethod':app.CutoffPeriodic, ... }
target_samplers = CreateTargetSamplers(targets, options)

# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(target_samplers, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

Thinking about how @juliebehr's mutational resistance problem would look.
Instead of SmallMoleculeLibrary, we would have a class like PointMutation that is a subclass of PolymerProposal and is able to rebuild Topology objects containing polymers by allowing one or more residues to be substituted for another.
PolymerProposal objects would need to take the following information:

a ForceField object (or the ffxml files directly) containing the residue definitions, so that it understands how to change one Topology object into another by substituting residues

PointMutation objects would also need information about:

the wild-type sequence, which could either be specified or obtained from the Topology file
which chain in the Topology file it would be modifying
some parameters specifying how many point mutants away from the wild-type sequence are allowed
some specification of how mutations are to be proposed (e.g. single-nucleotide vs single-amino acid changes)

This could potentially look like this:
# Parameters
cutoff = 9*angstroms
padding = cutoff + 1*angstrom
ionic_strength = 50*millimolar

# Initialize a forcefield engine, which will also be able to parameterize small molecules in addition to polymer residues.
ffxmls = ['amber99sbildn.xml', 'gaff.xml', 'tip3p.xml', 'ions.xml']
forcefieldplus = ForceFieldPlus(*ffxmls)
gaff_typer = GAFFSmallMoleculeTyper('gaff-type-definitions.xml')
forcefield.addExtension(gaff_typer) # parameter assignment for small molecules

#
# Retrieve reference wild-type sequence from UniProt
#

from tools import UniProtHelper # new tool we build from Ensembler code or BioPython

# Isoform IB is dominant; we will work with only the a truncated form of the kinase domain.
wt_sequence = UniProtHelper.retrieveSequence(id='ABL1_HUMAN', isoform='IB', span=(229,500))

#
# Load Abl:imatinib and Abl:ATP structures and identify the kinase in each
#

from tools import StructureHelper
# Abl:imatinib structure
# We need to specify exactly which sequence and residue span we want to build/retain to make sure kinase is same in both structures
inhibitor_complex = StructureHelper(rcsbid='2HYY', chains=['A'], addMissingResidues=True, addMissingHeavyAtoms=True, protonateLigand=True,
    reference_sequences = {'A' : wt_sequence }, retain_residue_spans={'A' : (229,500)} ) # tricky since ligand is in chain A as well
inhibitor_kinase = abl_complex['::A'] # chain A
# Abl:ATP structure
atp_complex = StructureHelper(rcsbid='2G1T', chains=['A','E'], addMissingResidues=True, addMissingHeavyAtoms=True, protonateLigand=True,
   reference_sequences = {'A' : wt_sequence }, retain_residue_spans={'A' : (229,500)} )
# chain E is a non-hydrolyzable ATP analogue that must be substituted with a real ATP
atp_complex.substituteLigand(source=atp, dest=atp_complex['::E'], method='shape-overlay') # we would need to write this function
atp_kinase = atp_complex['::A'] # chain A

#
# Set up the proposal engine
#

# Create a point mutation proposal object, which is a subclass of the polymer transformation proposal class
# In this case, allow up to two point mutations from the "wild-type" sequence represented by the sequence in `abl_kinase` topology, allowing all natural amino acid substitutions anywhere
# See below for many other variations on what we may want from this API.
from perses.mutations import PointMutationEngine, NaturalAminoAcids
mutation_engine = PointMutationEngine(reference_sequence=wt_sequence, forcefield=forcefieldplus, allowed_residues=NaturalAminoAcids, max_point_mutants=2)

#
# Set up sampler for Abl:inhibitor
#

# Solvate the complex
inhibitor_modeller = Modeller(inhibitor_complex.topology, inhibitor_complex.positions)
inhibitor_modeller.addSolvent(forcefieldplus, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
inhibitor_system = forcefieldplus.createSystem(abl_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
inhibitor_sampler = SAMSSampler(system=inhibitor_system, topology=inhibitor_modeller.topology, positions=inhibitor_modeller.positions, proposal_engine=mutation_engine, proposal_atom_selection=inhibitor_kinase.topology)

#
# Set up sampler for Abl:ATP
#

# Solvate the complex
atp_modeller = Modeller(atp_complex.topology, atp_complex.positions)
atp_modeller.addSolvent(forcefieldplus, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
atp_system = forcefieldplus.createSystem(atp_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
atp_sampler = SAMSSampler(system=satp_system, topology=atp_modeller.topology, positions=atp_modeller.positions, proposal_engine=mutation_engine, proposal_atom_selection=atp_kinase.topology)

#
# Create the design sampler
#

# Construct a target function for identifying mutants that maximize ATP binding but minimize inhibitor binding
# Keys specify SASASampler objects, and values are exponents in the computation of target weights.
# \hat{\pi}_k = Z_{Abl_k:ATP} / Z_{Abl_k:I}
target_samplers = { atp_sampler : 1.0, inhibitor_sampler : -1.0 }
# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(target_samplers, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

Some notes:

Chain selection still needs to be implemented in ParmEd.

And we could probably once again think of a way to simplify this with a helper function:
# Set up the proposal engine
from perses.mutations import PointMutationEngine, NaturalAminoAcids
mutation_engine = PointMutationEngine(reference_sequence=wt_sequence, forcefield=forcefieldplus, allowed_residues=NaturalAminoAcids, max_point_mutants=2)

# Specify targets with a dict
# This isn't quite where we need it to be, but might be close.
targets = [
    { name : 'Abl:inhibitor', weight : -1, rcsbid : '2HYY', chains : ['A'], proposal_selection='::A:229-500', target_sequences = {'A' : wt_sequence } },
    { name : 'Abl:ATP', weight : +1, rcsbid : '2G1T', chains : ['A','E'], proposal_selection='::A:229-500', target_sequences = {'A' : wt_sequence } },
    ...
]

# Load the small molecule library, a SmallMoleculeTransformation subclass.
library = SmallMoleculeLibrary(filename='library.mol2')

# Create all the target samplers using same options for all samplers.
options = { 'forcefield' : forcefieldplus, 'ionic_strength' : 50*millimolar, 'nonbondedMethod':app.CutoffPeriodic, ... }
target_samplers = CreateTargetSamplers(targets, proposal_engine=library, options=options)

# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(target_samplers, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

We'd have to think hard about the setup pipeline aspect of things (@andrrizzi), since this needs to be flexible enough to let us:

Specify where to take template structural data from (RCSB, PDB file, mmCIF)
Specify what target sequence(s) we want to model---which may differ in sequence and/or length from the template data---and which parts of which chains should provide templates for which targets. This is complicated by the fact that both protein and ligand are in chain 'A' in 2HYY but in separate chains in 2G1T.  The target sequence(s) may be manually specified, come from UniProt, or be specified in the PDB file either via the DBREF/SEQRES section or the resolved span of residues.
Specify target pH for protonation state modeling of polymers
Specify how the ligand is to be replaced (e.g. ROCS shape overlay) if we need to do so
Specify how to fully protonate the ligand and select the appropriate protonation state.

Finally, here's an example for the MHC:peptide:TCR use case:
# Parameters
cutoff = 9*angstroms
padding = cutoff + 1*angstrom
ionic_strength = 50*millimolar

# Initialize a forcefield
ffxmls = ['amber99sbildn.xml', 'tip3p.xml', 'ions.xml']
forcefield = ForceField(*ffxmls)

#
# Load MHC:peptide:TCR structure
#

from tools import StructureHelper
# We just need to build any missing atoms/residues from the SEQRES
complex = StructureHelper(rcsbid='1AO7', chains=['A','B','C'], addMissingResidues=True, addMissingHeavyAtoms=True)
# Identify components
mhc = complex['::A']
tcr = complex['::B']
peptide = complex['::C']

#
# Set up the proposal engine
#

# Create a point mutation proposal object, which is a subclass of the polymer transformation proposal class
# In this case, we use a library of sequences to define the accessible space of sequences
library = SequenceLibrary(filename='sequence-library.fasta')
library.addSequence(peptide) # make sure the peptide sequence is included

#
# Set up sampler for MHC:peptide:TCR
#

# Solvate the complex
complex_modeller = Modeller(complex.topology, complex.positions)
complex_modeller.addSolvent(forcefield, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
complex_system = forcefield.createSystem(complex_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
complex_sampler = SAMSSampler(system=complex_system, topology=complex_modeller.topology,
    positions=complex_modeller.positions, proposal_engine=library,
    proposal_atom_selection=peptide)

#
# Set up sampler for peptide in solvent
#

# Solvate the peptide
peptide_modeller = Modeller(peptide.topology, peptide.positions)
peptide_modeller.addSolvent(forcefield, model='tip3p', padding=padding, neutralize=True, ionicStrength=ionic_strength)

# Create a system
peptide_system = forcefield.createSystem(peptide_modeller.topology, nonbondedMethod=CutoffPeriodic, nonbondedCutoff=cutoff, rigidWater=True, removeCMMotion=False)

# Create a SAMS sampler for the complex.
peptide_sampler = SAMSSampler(system=peptide_system, topology=peptide_modeller.topology,
    positions=peptide_modeller.positions, proposal_engine=library,
    proposal_atom_selection=peptide.topology)

#
# Create the design sampler
#

# Construct a target function for identifying peptides that maximize the MHC:peptide:TCR ternary complex affinity
# Keys specify SASASampler objects, and values are exponents in the computation of target weights.
# \hat{\pi}_k = Z_{MHC:peptide_k:TCR} / Z_{peptide_k}
target_samplers = { complex_sampler : 1.0, peptide_sampler : -1.0 }
# Set up the design to run in parallel via MPI.
designer = MultiTargetDesign(target_samplers, mpicomm=MPI.COMM_WORLD)
# Run the designer engine
designer.run()

Chain selection still needs to be implemented in ParmEd.

FWIW, the selection syntax handles chain IDs just fine.  For example: struct[('A','B'),:10,:] will select all atoms in residues 1 to 10 of chains A and B.  I'd suggest this route rather than waiting for the mask syntax grow chain selection IDs.

Thanks, @swails!

At one point, @pgrinaway suggested we might be able to use the small molecule graph-based (MCSS) topology mapping scheme even for peptide or protein transformations.  While I don't think this will work if fed things which are not small molecules, I wonder if this could actually do the trick if we constrain this to work residue-by-residue.
What we really need is a way to take a Topology object, program one or more residue mutations (which could be small molecules, amino acids, nucleic acids, etc.), an end up with a new Topology and an atom mapping from old to new atoms.
For subsituting a small molecule with another small molecule, MCSS could be used to propose several candidate matches, and one of the matches selected according to some criteria (with ties selected randomly).
For a residue with one or more bonds to other residues, however, this is no so simple.  We could, however, work residue by residue and perform this operation.  Bonds to other residues could either be truncated or replaced with special atoms (e.g. X, Y, Z...) and forced to match.  The same MCSS scheme could then be used on a residue-by-residue basis.
The templates for each residue could be pulled from a ForceField object, which maintains a representation of all known residue topologies.  New small molecule templates can also be added to the ForceField as they are generated.
We could imagine an API for this either being a static factory that operates on Topology objects
from perses import TopologyTools
residues = [ residue for residue in topology.residues() ]
substitutions = { residues[10] : 'GLY', residues[20] : 'LEU', residues[100] : 'benzene' }
[new_topology, atom_mapping] = TopologyTools.substituteResidues(topology, forcefield, substitutions)

where this repeatedly calls substituteResidue() and updates the atom mapping.  Not sure if it would be best if atom_mapping maps atom indices or actual Atom objects (from which atom indices can be extracted).
We could also imagine this might just be a feature of an enhanced TopologyPlus class:
[new_topology, atom_mapping] = topology.substituteResidue(residue, new_resname)

or
residues = [ residue for residue in topology.residues() ]
substitutions = { residues[10] : 'GLY', residues[20] : 'LEU', residues[100] : 'benzene' }
[new_topology, atom_mapping] = topology.substituteResidues(residue_substitutions)

(I think @juliebehr may have used a similar scheme in constructing her overlay of amino acids.)

Any comments on what needs to be done first or fleshing out a more specific API or skeleton for some of these components?

My thoughts on the API + the work division:

Regarding the Sampler-facing topology proposal API, save for a potential name change, I think it should remain as it is. I like the idea of the TopologyTools class, which would be very useful in the implementation of the the polymer topology proposal classes. I think from the point of view of the Sampler classes, the topology proposal API should be very simple.

For the Sampler, I have an initial suggestion, though it may need more thought:

mcmc_sampler = MCMCSampler(topology_engine, geometry_engine, ncmc_engine)

#inside a SAMS sampler?
#should we do something like this:
mcmc_sampler.sample_x(1000) #run 1000 steps of integration in configuration space
mcmc_sampler.sample_k(1) #attempt to jump to a new state (compound/mutation/whatever)

#update the weights
current_k = mcmc_sampler.current_k
weights_new = self._update_weights(current_k) #get a vector of updated weights
mcmc_sampler.weights = weights_new #set via property setter

Then maybe for the external interface of the SAMSSampler (pretending we are inside a method
that uses the SAMSSampler):

sams_sampler = SAMSSampler(system=peptide_system, topology=peptide_modeller.topology,
    positions=peptide_modeller.positions, proposal_engine=library,
    proposal_atom_selection=peptide.topology)

#I wonder if it would be useful to be able to specify a protocol for drawing samples of
#configurations and states, such as:
protocol = {n_iterations : 100, x_update_per_iteration : 100, k_update_per_iteration : 1}

sams_sampler.run_mcmc(protocol)
sams_sampler.adjust_weights() #do we need an explicit call to this?
current_targets = sams_sampler.targets
current_weights = sams_sampler.weights

#update the target weights. Other SAMSSamplers that would be required here left out for simplicity
new_targets = self._update_target_weights(current_targets, current_weights...)

I generally like the rest of the API as presented. I'm also satisfied with the assignment of tasks here. In general, I love MCMC and SA, so I'm happy to work on any of those things.

Regarding the Sampler-facing topology proposal API, save for a potential
name change, I think it should remain as it is. I like the idea of the
TopologyTools class, which would be very useful in the implementation of
the the polymer topology proposal classes. I think from the point of view
of the Sampler classes, the topology proposal API should be very simple.

Remain as in the proposal here or the currently implemented code?

For the Sampler, I have an initial suggestion, though it may need more
thought:
mcmc_sampler = MCMCSampler(topology_engine, geometry_engine, ncmc_engine)
#inside a SAMS sampler?
#should we do something like this:
mcmc_sampler.sample_x(1000) #run 1000 steps of integration in
configuration space
mcmc_sampler.sample_k(1) #attempt to jump to a new state
(compound/mutation/whatever)
#update the weights
current_k = mcmc_sampler.current_k
weights_new = self._update_weights(current_k) #get a vector of updated
weights
mcmc_sampler.weights = weights_new #set via property setter

What if we have classes that were intended to interoperate:

MCMCSampler - sample positions using composition of MCMC moves. This is
essentially already written and living in repex. We could ingest it or make
it into its own package to facilitate reuse and testing.
ExpandedEnsembleSampler - sample positions with MCMCSampler, state with
some form of Gibbs sampling, according to fixed weights (that can be
changed via a public API). Discrete states might be arbitrary keys or
integers.
SAMSSampler - uses an ExpandedEnsembleSampler and adjusts the weights
dynamically according to one of the strategies in Z Tan's paper. Can also
be split out because multiple projects can use it.

This way, we have a basic API for each part of the sampler chain and
encapsulates the behavior relevant to the immediate algorithm inside the
relevant class, rather than having, say, Gibbs sampling and weight
adaptation mixed into the same thing.
Things I am less sure of: would SAMSSampler create an
ExoandedEnsembkeSampler under the hood (in which case it may need to relay
options to the constructor) or is it best to have the caller pass in an
ExpandedEnswmbleSampler? Same thing with MCMCSampler. If we have the caller
pass the sampler, it gives us more flexibility in subclassing each of these
to change their behavior.

Then maybe for the external interface of the SAMSSampler (pretending we
are inside a method
that uses the SAMSSampler):
sams_sampler = SAMSSampler(system=peptide_system,
topology=peptide_modeller.topology,
positions=peptide_modeller.positions, proposal_engine=library,
proposal_atom_selection=peptide.topology)

This looks pretty good. Is there a way to generalize the SAMSSampler
further, or would that just cause too much trouble?

#I wonder if it would be useful to be able to specify a protocol for
drawing samples of
#configurations and states, such as:
protocol = {n_iterations : 100, x_update_per_iteration : 100,
k_update_per_iteration : 1}

We could have some options we could set for each of the samplers through
either an API or an options dict.

sams_sampler.run_mcmc(protocol)
sams_sampler.adjust_weights() #do we need an explicit call to this?
current_targets = sams_sampler.targets
current_weights = sams_sampler.weights
#update the target weights. Other SAMSSamplers that would be required
here left out for simplicity
new_targets = self._update_target_weights(current_targets,
current_weights...)
I generally like the rest of the API as presented. I'm also satisfied
with the assignment of tasks here. In general, I love MCMC and SA, so I'm
happy to work on any of those things.

Great!

My phone screwed up the previous comment, so here's a new try:

Regarding the Sampler-facing topology proposal API, save for a potential name change, I think it should remain as it is. I like the idea of the TopologyTools class, which would be very useful in the implementation of the the polymer topology proposal classes. I think from the point of view of the Sampler classes, the topology proposal API should be very simple.

Remain as in the proposal here or the currently implemented code?

For the Sampler, I have an initial suggestion, though it may need more thought:
mcmc_sampler = MCMCSampler(topology_engine, geometry_engine, ncmc_engine)
#inside a SAMS sampler?
#should we do something like this:
mcmc_sampler.sample_x(1000) #run 1000 steps of integration in configuration space
mcmc_sampler.sample_k(1) #attempt to jump to a new state (compound/mutation/whatever)
#update the weights
current_k = mcmc_sampler.current_k
weights_new = self._update_weights(current_k) #get a vector of updated weights
mcmc_sampler.weights = weights_new #set via property setter

What if we have classes that were intended to interoperate:

MCMCSampler - sample positions using composition of MCMC moves. This is essentially already written and living in repex. We could ingest it or make it into its own package to facilitate reuse and testing.
ExpandedEnsembleSampler - sample positions with MCMCSampler, state with some form of Gibbs sampling, according to fixed weights (that can be changed via a public API). Discrete states might be arbitrary keys or integers.
SAMSSampler - uses an ExpandedEnsembleSampler and adjusts the weights dynamically according to one of the strategies in Z Tan's paper. Can also be split out because multiple projects can use it.

This way, we have a basic API for each part of the sampler chain and encapsulates the behavior relevant to the immediate algorithm inside the relevant class, rather than having, say, Gibbs sampling and weight adaptation mixed into the same thing.
Things I am less sure of: would SAMSSampler create an ExpandedEnsembleSampler under the hood (in which case it may need to relay options to the constructor) or is it best to have the caller pass in an ExpandedEnsembleSampler? Same thing with MCMCSampler. If we have the caller pass the sampler, it gives us more flexibility in subclassing each of these to change their behavior.

Then maybe for the external interface of the SAMSSampler (pretending we are inside a method
that uses the SAMSSampler):
sams_sampler = SAMSSampler(system=peptide_system, topology=peptide_modeller.topology,
positions=peptide_modeller.positions, proposal_engine=library,
proposal_atom_selection=peptide.topology)

This looks pretty good. Is there a way to generalize the SAMSSampler further so we could use it for the SAMS paper for parallel tempering and alchemical solvation free energy calculations too, or would that just cause too much trouble?

#I wonder if it would be useful to be able to specify a protocol for drawing samples of
#configurations and states, such as:
protocol = {n_iterations : 100, x_update_per_iteration : 100, k_update_per_iteration : 1}

We could have some options we could set for each of the samplers through either an API or an options dict.

sams_sampler.run_mcmc(protocol)
sams_sampler.adjust_weights() #do we need an explicit call to this?
current_targets = sams_sampler.targets
current_weights = sams_sampler.weights
#update the target weights. Other SAMSSamplers that would be required here left out for simplicity
new_targets = self._update_target_weights(current_targets, current_weights...)
I generally like the rest of the API as presented. I'm also satisfied with the assignment of tasks here.
In general, I love MCMC and SA, so I'm happy to work on any of those things.

Great!

For example, we could have
from thermodynamics import ThermodynamicState
thermodynamic_state = ThermodynamicState(system=test.system, temperature=298*u.kelvin)
# Create a sampler state.
sampler_state = SamplerState(system=test.system, positions=test.positions)
# Create a move set specifying probabilities fo each type of move.
move_set = { HMCMove(nsteps=10) : 0.5, LangevinDynamicsMove(nsteps=10) : 0.5 }
# Create MCMC sampler
mcmc_sampler = MCMCSampler(thermodynamic_state, move_set=move_set)
# Create Expanded Ensemble sampler
expanded_ensemble_sampler = ExpandedEnsembleSampler(mcmc_sampler, log_weights=log_weights)
# Create an SAMS sampler
sams_sampler = SAMSSampler(mcmc_sampler, log_target_probabilities=log_target_probabilities)

Remain as in the proposal here or the currently implemented code?

Currently implemented code (though the innards will change with the OpenMM parameterization stuff, I like the simple interface of topology_engine.propose(current_state)). The other objects you mentioned to assist are great, but they might just be used inside a TopologyEngine.

What if we have classes that were intended to interoperate:
MCMCSampler - sample positions using composition of MCMC moves. This is essentially already written and living in repex. We could ingest it or make it into its own package to facilitate reuse and testing.
ExpandedEnsembleSampler - sample positions with MCMCSampler, state with some form of Gibbs sampling, according to fixed weights (that can be changed via a public API). Discrete states might be arbitrary keys or integers.
SAMSSampler - uses an ExpandedEnsembleSampler and adjusts the weights dynamically according to one of the strategies in Z Tan's paper. Can also be split out because multiple projects can use it.
This way, we have a basic API for each part of the sampler chain and encapsulates the behavior relevant to the immediate algorithm inside the relevant class, rather than having, say, Gibbs sampling and weight adaptation mixed into the same thing.

I've been mulling this over for a while now. At first I was a bit unsure, but I think that this might be the way to go. Regardless of the state k, we'll likely want to propagate x with the same MCMC steps. And a modification of the k update could be accomplished by subclassing ExpandedEnsembleSampler. I'm +1 on this

Things I am less sure of: would SAMSSampler create an ExpandedEnsembleSampler under the hood (in which case it may need to relay options to the constructor) or is it best to have the caller pass in an ExpandedEnsembleSampler? Same thing with MCMCSampler. If we have the caller pass the sampler, it gives us more flexibility in subclassing each of these to change their behavior.

I would vote for having the caller pass the sampler, for the flexibility reasons cited. I'd like to make these components as independent as possible so that we can mix and match.

This looks pretty good. Is there a way to generalize the SAMSSampler further so we could use it for the SAMS paper for parallel tempering and alchemical solvation free energy calculations too, or would that just cause too much trouble?

Well, if we're passing in an ExpandedEnsembleSampler, we could subclass that and have the k update be equivalent to updating the temperature, lambda, or whatever, and it should still work as expected. So I don't think that's too much trouble at all.
Going to post this and then comment on the repex stuff.

Well, if we're passing in an ExpandedEnsembleSampler, we could subclass that and have the k update be equivalent to updating the temperature, lambda, or whatever, and it should still work as expected. So I don't think that's too much trouble at all.

Yeah, this might be the best way, since I think each of these scenarios is pretty different.
We could have
ExpandedEnsembleSampler - base class
* TopologyExpandedEnsemblerSampler - sample over different topology proposals
* SimulatedTemperingSampler - sample over different temperatures
* AlchemicalSampler - sample over different alchemical states?

Ok, I think that repex MCMC sampler code is really nice, so I'm +1 on using it here. As to bringing it into the repo, I am fine with that as well, but I suppose it depends on future plans for repex.

My thoughts exactly regarding the subclasses of ExpandedEnsembleSampler.

Ok, I think that repex MCMC sampler code is really nice, so I'm +1 on using it here. As to bringing it into the repo, I am fine with that as well, but I suppose it depends on future plans for repex.

What about breaking it into a separate mcmc or openmm-mcmc repo?

OK, want me to do it or do you?

I can do it. Should we then make repex dependent on it?

Yes!

@pgrinaway if this class structure looks good, can you and @juliebehr take a stab at implementing a skeleton on Friday?  We should really get something basic up and running just to make sure we haven't forgotten something important with the design.  Then we can come back to concentrating on the sampler contents.

The class structure looks fine to me. I think I'm misunderstanding something about your request, though.
I have opened a new issue with a description of what I think the near-term goals and work are in #65.

Closing this since discussion seems to have ended here. We can certainly talk more about it later, and we'll have the closed issue to reference at that point.


Remove identifier from JsonWebKey

I wonder if we could maybe have a SpecializedCryptoPublicKey interface for JWK, COSE, etc., keys, to parallel the SpecializedCryptoAlgorithm interface...

I wonder if we could maybe have a SpecializedCryptoPublicKey interface for JWK, COSE, etc., keys, to parallel the SpecializedCryptoAlgorithm interface...

These are mostly used as containers for specific use cases and the serialization is the key part. Also: serialization is where JWK is nice and smooth and CoseKey serialization is the what a the perceptive issues of a schizophrenic would look like it if you could translate it to kotlin code. Hence, this might me overkill

Not part of this PR anyway, I'll play around with it.

Not part of this PR anyway, I'll play around with it separately.

After all the signers are implemented, i presume ;-)


LICENSE.md deleted

It appears the license file was dropped. If you could, please publish a new maintenance version with a license file. (if still applicable?)
original issue: https://github.com/basarat/typescript-collections/issues/14
offending commit: https://github.com/basarat/typescript-collections/commit/d000acf3a1a13bc969372aaf67ecee7e78abe5a0

Added back.


SASS-1534: Added utilities benefits flows

Description

Added utilities benefits flows

https://jira.tools.tax.service.gov.uk/browse/SASS-1534
Checklist PR Reviewer
Before Reviewing

[ ]  Have you pulled the branch down?
[ ]  Have you assigned yourself to the PR?
[ ]  Have you moved the task to “in review” on JIRA?
[ ]  Have you checked to ensure all dependencies are up to date?
[ ] Have you checked to ensure its been rebased against the current version of master?

Whilst Reviewing

[ ]  Have you run the tests?
[ ]  Have you looked at the JIRA story to make sure all Acceptance Criteria has been met?

After Reviewing

[ ] Have you checked for merge conflicts or any changes in the current master that may affect the current pull request? i.e. does it need another rebase?
[ ]  Have you checked to make sure there are no builds in the pipeline before you merge?
[ ]  Have you moved the task to “in pipeline” on Jira?

Checklist PR Raiser
Before creating PR

[ ]  Have you run the tests?
[ ]  Have you addressed warnings where appropriate?
[ ] Have you rebased against the current version of master?

Needs to be merged after https://github.com/hmrc/income-tax-employment-frontend/pull/176 is merged


[skywalking-ui]Application log can't append to webapp.log

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ ] Question or discussion
[x] Bug
[ ] Requirement
[ ] Feature or performance improvement

__
Bug

Which version of SkyWalking, OS and JRE?
SkyWalking：5.0.0-alpha
JRE: 1.8.0_131
OS: CentOS release 6.7 x64
Storage: elasticsearch 5.5
What happen?
You can set '--logging.file=xxxx ' in webappService.sh

Same as https://github.com/apache/incubator-skywalking/issues/931


hc fails to start plugins on macOS

This issue seems to reliably manifest itself when running hc check if another instance of hc check is running

Hm. This is true for you even after the tuning we did yesterday for macOS spawn timing?

Yes this is triggering with the latest version of main. To add more detail, the plugins are able to all bind to the ports handed to them by hc, but the function call  PluginServiceClient::connect(format!("http://<IP_ADDRESS>:{port_str}")).await in hipcheck/src/plugin/manager.rs  fails with a generic transport error from tonic

Exciting! I think this is probably a race condition on automatic port assignment in macOS. We'll want to dig in further, and this does evince the need to establish some sort of exclusion through locking the shared resources (repo cache, plugin cache) that Hipcheck has; alongside avoiding a data race on port assignment from the OS.


Lot of missing travel times - TimeService

Around 10 to 20 % of my requested travel times are missing a duration (-1 response from the TimeService server), even when I greatly enhance the max_routing_time ( up to twice what I know is as a correct threshold to reach the POI !).
Can you give me pointers to how to reduce the miss % rate to an acceptable threshold such as 3-4% ?
Is it possible to be because of the location of target POI ? (too far from a road, network, etc.)
I'm using the "/westcentraleurope/v1/time" endpoint.
Thank you.

Could you provide sample CURL requests? What I see so far is that maxRoutingTime is written wrong. But in general this should not happen.

@gerbsen oh, you are right, I messed up with the key maxRoutingTime. The behavior is weird though because the results without routing duration are consistent request after request.
I, [2018-02-23T10:25:29.167112 #10359]  INFO -- : post https://service.route360.net/westcentraleurope/v1/time?key=XXXXXXXXXXX
D, [2018-02-23T10:25:29.167196 #10359] DEBUG -- request: User-Agent: "Faraday v0.9.2"
Content-Type: "application/json"
D, [2018-02-23T10:25:29.167253 #10359] DEBUG -- request: {"sources":[{"lat":45.744603,"lng":4.868566,"id":493,"tm":{"transit":{}}},{"lat":45.746439,"lng":4.837311,"id":492,"tm":{"bike":{}}}],"targets":[{"id":158423,"lng":4.850937626291677,"lat":45.70209923753786},{"id":158419,"lng":4.802279066989881,"lat":45.756125604993585},{"id":158422,"lng":4.812897456345151,"lat":45.7306247683139},{"id":158421,"lng":4.824739469218514,"lat":45.7788725616154},{"id":158428,"lng":4.8814542164548556,"lat":45.70434417140896},{"id":158418,"lng":4.828342216087872,"lat":45.76981789250719},{"id":158420,"lng":4.837566104268735,"lat":45.73366934338188},{"id":158426,"lng":4.851726189477652,"lat":45.772982235691835},{"id":158427,"lng":4.82588465717846,"lat":45.74896950864248},{"id":158424,"lng":4.868978156414506,"lat":45.75347043122545},{"id":158425,"lng":4.869734321237862,"lat":45.7340765031768}],"max_routing_time":4800,"pathSerializer":"compact"}
I, [2018-02-23T10:25:29.623158 #10359]  INFO -- Status: 200

gives me 3 results without duration, whereas:
I, [2018-02-23T10:26:23.934156 #10588]  INFO -- : post https://service.route360.net/westcentraleurope/v1/time?key=XXXXXXXXXX
D, [2018-02-23T10:26:23.934242 #10588] DEBUG -- request: User-Agent: "Faraday v0.9.2"
Content-Type: "application/json"
D, [2018-02-23T10:26:23.934308 #10588] DEBUG -- request: {"sources":[{"lat":45.744603,"lng":4.868566,"id":493,"tm":{"transit":{}}},{"lat":45.746439,"lng":4.837311,"id":492,"tm":{"bike":{}}}],"targets":[{"id":158423,"lng":4.850937626291677,"lat":45.70209923753786},{"id":158419,"lng":4.802279066989881,"lat":45.756125604993585},{"id":158422,"lng":4.812897456345151,"lat":45.7306247683139},{"id":158421,"lng":4.824739469218514,"lat":45.7788725616154},{"id":158428,"lng":4.8814542164548556,"lat":45.70434417140896},{"id":158418,"lng":4.828342216087872,"lat":45.76981789250719},{"id":158420,"lng":4.837566104268735,"lat":45.73366934338188},{"id":158426,"lng":4.851726189477652,"lat":45.772982235691835},{"id":158427,"lng":4.82588465717846,"lat":45.74896950864248},{"id":158424,"lng":4.868978156414506,"lat":45.75347043122545},{"id":158425,"lng":4.869734321237862,"lat":45.7340765031768}],"maxRoutingTime":4800,"pathSerializer":"compact"}
I, [2018-02-23T10:26:24.853497 #10588]  INFO -- Status: 200

gives me none :)
I'm closing this for now as I will investigate the %miss rate on a large number of results, and I'll come back to you if necessary.
Thanks !


Ensure new line for sub-lists

Description
This PR adds trailing spaces within each step in the How it works section of the Add feature layers sample README to ensure sub-list items exist on new lines.
For example, compare:

Swift - https://developers.arcgis.com/swift/sample-code/add-feature-layers/#how-it-works
Kotlin - https://developers.arcgis.com/kotlin/sample-code/add-feature-layers/#how-it-works

Linked Issue(s)
n/a - quick fix
Screenshots

Before
After

Hey @CalebRas, here's another formatting update I caught that should be fairly trivial to review.
Would you like me to open a PR to get this fix in v.next, or would you prefer to handle that?

Hey @CalebRas, here's another formatting update I caught that should be fairly trivial to review. Would you like me to open a PR to get this fix in v.next, or would you prefer to handle that?

I make another PR for v.next using your branch. Thanks for finding this!

v.next PR: #275

URL to README for this PR: README


useSelections

This is a proposal to port the withSelections HOC from react-item-select.
Usage
import { useSelections } from 'react-use';

const Demo = () => {
  const { handleSelect, isItemSelected } = useSelections();

  return (

        {items.map(item => (

              <input name="first" type="checkbox" checked={isItemSelected(item.id)} onChange={handleSelect(item.id)} />

              {item.name}

        ))}

  );
};

It is interesting but that would be one hook that handles checkbox controls in this library, but there are other controls as well and I believe there are libraries dedicated to form handling. I don't think we had plans to do form handling hooks.

Although, as I say that, here we had some discussion about forms: https://github.com/streamich/react-use/issues/63
But nothing came out of it, yet.

@streamich I do not view this as a form handling hook. Item selection is common in scenarios that do not use forms. Checkboxes might not have been the best example because they are typically used in forms.
Here are some examples of how I use this in its HOC form: https://react-item-select.now.sh/


Module parse failed: Unexpected token (394:7)

Failed to compile.

./node_modules/react-arborist/dist/module.js 394:7
Module parse failed: Unexpected token (394:7)
File was processed with these loaders:
 * ./node_modules/react-scripts/node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
|     };
|
>     el?.addEventListener("keydown", cb);
|     return () => {
|       el?.removeEventListener("keydown", cb);

I had the same problem. I figured out that webpack was not able to parse/resolve those arrow functions in this package and caused this problem. So removing those arrow function syntax or pass 'react-arborist' to babel loader in webpack config will solve this.

What is the environment you're using react-arborist in?

I have
Node: 16.15.0
Webpack: 5.5.1
React: 17.0.1
Electron: 11.0.1
Typescript: 4.0.5

I am not sure really.

Upgrade @babel/preset-env in package.json to the most recent version.

Similar issue here. Not sure what to make of it.

v3.0.2

For people who have the same issue
delete node_modules and change package.json
https://github.com/facebook/create-react-app/issues/9468#issuecomment-694191642

I can probably fix this in the way I bundle the app. I need to lower the version of javascript that this package outputs.


Closures being handled like arguments?

Maybe this would be another proposal, where different functions could be identified uniquely based on their source location, arguments and closures despite a new Function instance is created.
If so, closures could be handled like arguments in the sense that if the value of a closure is modified, a memoized function would have to re-evaluate?
This would be the real game changer IMHO as things like
import { useEffect } from "react";

function MyComponent({x}) {
  useEffect(
    ()=>doSomethingWith(x),
    [x]
  );
}

could simply be
import { useEffect } from "react";
function MyComponent({x}) {
  useEffect(
    ()=>doSomethingWith(x)
  );
}

Specifically in this react sample, that would minimize user errors in identifying closures in effects, but generally this could be valuable for other libraries that make use of memoized functions that depend on closures.
I understand the arguments to be immutable tuple or records, so I suppose the closure would need to be such (or else converted to a symbol as is described in the proposal).

Since that would require being informed by syntax, it would need a solution that was also syntax - which means the current API a form couldn’t ever have this ability, and a syntax form would have a much harder road in the committee.


gracefully deal with SSR errors

May need to make it prettier before being accepted, but...
bankai start:

bankai build:
16:57:30 ✨  Compiling & compressing files

16:57:30 ✨  created: client/dist
16:57:30 ✨  created: client/dist/manifest.json
16:57:30 ✨  created: client/dist/assets/bestbuy-logo.png
16:57:30 ✨  created: client/dist/assets/headerFooterIcons.ttf
16:57:30 ✨  created: client/dist/assets/stars.png
16:57:30 ✨  created: client/dist/manifest.json.gz
16:57:30 ✨  created: client/dist/manifest.json.deflate
16:57:30 ✨  created: client/dist/manifest.json.br
16:57:32 ⚠  Server Side Rendering Skipped due to error: window is not defined
16:57:32 ✨  created: client/dist/f87876b8465faae9/bundle.css
16:57:32 ✨  created: client/dist/bd682d0267e05d42/bundle.js
16:57:33 ✨  created: client/dist/f87876b8465faae9/bundle.css.gz
16:57:33 ✨  created: client/dist/bd682d0267e05d42/bundle.js.gz
16:57:33 ✨  created: client/dist/index.html
16:57:33 ✨  created: client/dist/index.html.gz
16:57:33 ✨  created: client/dist/f87876b8465faae9/bundle.css.deflate
16:57:33 ✨  created: client/dist/index.html.deflate
16:57:33 ✨  created: client/dist/bd682d0267e05d42/bundle.js.deflate
16:57:33 ✨  created: client/dist/sw.js
16:57:33 ✨  created: client/dist/index.html.br
16:57:33 ✨  created: client/dist/sw.js.gz
16:57:33 ✨  created: client/dist/sw.js.deflate
16:57:33 ✨  created: client/dist/sw.js.br
16:57:33 ✨  created: client/dist/f87876b8465faae9/bundle.css.br
16:57:33 ✨  created: client/dist/bd682d0267e05d42/bundle.js.br

I think this approach.  Surfaces errors in a friendly way to users in both modes.


Release 1.0.5

should release after recent bug fix: https://github.com/AbanteAI/mentat/commit/255d9ee18e680d1c3ff8bd2ca9e0f77de0dc255f

Oops I never merged this. Releasing now before I post a video with /run command which hasn't been released yet.


[Paddle] Add parallel support

Add the following parallel rules:

TP
DP
PP
Group sharding (FSDP)

@jeng1220 Could you take a look?

This PR needs to wait for #361, and refactoring a bit.

/te-ci

/te-ci

@Tom-Zheng #361 has been merged, could you resolve the conflicts and make the necessary refactors?

@ksivaman @timmoon10  This PR is ready for review. Would you please take a look?
cc: @jeng1220

@ksivaman @timmoon10 This PR is ready for review. Would you please take a look?
cc: @jeng1220

Check tensor shapes per GPU carefully if sharding is enabled. To ensure that the every tensor shape per GPU meets the expectation.

/te-ci

/te-ci

@ksivaman @timmoon10 This PR is ready for review. Would you please take a look?
cc: @jeng1220

Check tensor shapes per GPU carefully if sharding is enabled. To ensure that the every tensor shape per GPU meets the expectation.

Done

LGTM.
@zlsh80826 please help to trigger CI.

/te-ci

It looks reasonable to me, although we're seeing some test failures related to the MNIST example and the Transformer layer. It's strange since I wouldn't expect this PR to have affected them.

It is due to randomness and is fixed now.

/te_ci

@zlsh80826 Would you help rerun CI?

/te-ci


Added temporary odict pytree registration

Description:

Added temporary odict pytree registration

combine_state_for_ensemble can work on torchvision segmentation models

Related to https://github.com/pytorch/functorch/issues/445#issuecomment-1050946177
Logs :
python -u check_combine_state_for_ensemble_on_tv_segm_models.py

Torch: 1.12.0.dev20220223+cu111
torchvision: 0.13.0.dev20220223+cu111
Functorch: 0.2.0a0+c8b640c

-- Check fcn_resnet50 model
/usr/local/lib/python3.8/dist-packages/torch/nn/functional.py:1279: UserWarning: There is a performance drop because we have not yet implemented the batching rule for aten::dropout. Please file us an issue on GitHub so that we can prioritize its implementation. (Triggered internally at  /ft/functorch/csrc/BatchedFallback.cpp:83.)
  return _VF.dropout_(input, p, training) if inplace else _VF.dropout(input, p, training)
-- Check fcn_resnet101 model
Output does not match reference: -237.7958221435547 vs -237.7958984375
-- Check deeplabv3_resnet50 model
-- Check deeplabv3_resnet101 model
Output does not match reference: -285.8777770996094 vs -285.8778076171875
-- Check deeplabv3_mobilenet_v3_large model
-- Check lraspp_mobilenet_v3_large model

@zou3519 can we merge this PR, CI is sucessful but not updated here:

GitHub rate limited us while adding a commit status of success: API rate limit exceeded for user ID 6422482

merged!


Using angular-builds, getting: Generic type 'Type' requires 1 type argument(s). -><EMAIL_ADDRESS>

I think this is due to this commit: https://github.com/angular/angular/commit/b96869afd2bdd3ad8c5b7477da647af628e383aa
So Type needs to be updated to Type<any>

#39

Fixed in v2.0.0


Dispatch Stimulus events

This project is incredible. Thank you for tackling such a tough UX problem.
As I am using it, I found myself really wanting to hook in to some type of callback system.  That said, since it is all stimulus based, it would be awesome if you called dispatch when different events occurred.
FWIW, currently, I am having to use a Mutation Observer.

You should be able to hook in to hw-combobox:preselection, hw-combobox:selection, and hw-combobox:removal. Relevant source code

Amazing!  Worked perfectly. Thank you so much.
For such a new project, it is remarkably well thought through.

For future readers, the exact syntax is:
<!--In your view somewhere -->
<div data-controller='example' data-action='hw-combobox:selection->example#handleEvent'>
  <%= f.combobox … %>
</div>

// Example Stimulus controller `example_controller.js`
import { Controller } from "@hotwired/stimulus";

export default class extends Controller {
  handleEvent(event) {
    const selectedValue = event.detail.value; // This will be the `value` of the selected option
  }
}


Integration of Atom, RSS, and JSON Feed Support into ActivityPods Framework

Summary:
This issue proposes the integration of Atom, RSS, and JSON feed support into the ActivityPods framework. Implementing these feed formats will enable the framework to syndicate updates (e.g., new offers, requests) in a standardised and widely supported manner, enhancing content distribution capabilities and interoperability with other systems and applications.
Background:
Atom, RSS, and JSON feeds are mostly widely used standards for the distribution and syndication of content on the web. By supporting these formats, ActivityPods can provide users and developers with a powerful tool to publish and consume updates in a structured, efficient, and platform-agnostic way. This feature would be particularly beneficial for applications that rely on timely updates and content sharing across different platforms.
Rationale:
Enhanced Content Distribution: Feed support will facilitate broader distribution of content generated within ActivityPods, such as new offers or requests, making it more accessible to users and external applications.
Interoperability: By adhering to these well-established standards, ActivityPods will improve its interoperability with a wide range of feed readers, aggregators, and other web services.
User Engagement: Feeds provide a straightforward way for users to stay informed about updates without the need to constantly check the platform, potentially increasing user engagement and retention.
Developer Ecosystem: Offering feed support can enrich the developer ecosystem around ActivityPods by enabling developers to build innovative applications and services that leverage real-time updates from the platform.

I Damon, thanks for your feature request!
We will be speaking about it in our meeting tomorrow 15:00CET. The meetings are open to everyone, so if you are curious, you're welcome to join :) https://bbb.paquerette.eu/b/ass-t8y-gvd-pwg
From what I can tell right now, it seems to be a mid-size effort issue. Since we are quite busy at the moment, I can't tell how we go with it but I suppose, tomorrow I can give you more information about how we'll be going forward with this.
Best, Laurin


OpenCombine organization?

I'm currently maintaining a few forks of open-source libraries that make those compatible with OpenCombine: GRDBOpenCombine and its dependency OpenCombineExpectations. I'd appreciate any input and contributions to these forks, and maybe some coordinated effort to push a more sane support for "polyfill" libraries in future versions of Swift. If the latter happens, we probably even could upstream changes from these forks to their origin repositories.
Either way, it would make sense to maintain these forks, proposals, and related helper projects under one umbrella OpenCombine organization with an open list of maintainers. This would make the project more visible and I hope attract more attention and contributors. I'm not sure if existing OpenCombine organization is the one previously created for this purpose, if not maybe something like OpenCombineHQ could work as a name just as well.

Good idea! Yep, I created that organization exactly for this purpose.

@MaxDesiatov do you want me to do anything regarding this issue?

I was just wondering whether you have any plans with regards to the organization, are you going to transfer the repository to it?

I guess I am.

Awesome!

Huh. CircleCI has stopped working because of the transfer. I've contacted their support, let's wait what they say.

Yeah, I had a similar issue with Codecov when I was transferring my repos to an org, the repo never showed up there under the new org, so I couldn't get a new Codecov token. The only thing that helped me with Codecov was logging out, clearing all cokies and logging in again. Not sure if it's the same thing with Circle CI though.

The thing with CircleCI is that I've been using a free plan for macOS builds, which one can only obtain by writing to their support. The Linux builds are fine.

GitHub Actions supports Xcode 10.3 on macOS, so just in case CircleCI is not fixed, I hope you would consider GHA. GHA also seems much faster as it allows some parallelism for open-source repositories.

AFAICT GitHub Actions only support macOS Catalina. For testing on iOS 9.3 (and 32 bits) we have to use macOS Mojave, because on Catalina Xcode doesn't allow us to download SDKs that old.
I'd be happy to use GHA, but I'm not ready to give that up.

Mojave is also supported on Azure Pipelines, just in case.

The CI’s up and running again, folks at CircleCI were very helpful.


Feature/paginate

Pagination ^-^
#114

Pass _start/_end query params to adapters inside router
minor state redesign for a new "page" variable and reset it on every "selectedStatuses" update
view powered by react-paginate

@s-r-x why this was deleted? bull-board is not showing all jobs


feat: updated static card UI

Looks good to me, will pull and check it once. Is the Instagram connection working without errors?


When to release AEC recipes?

Now speechbrain has Speech Enhancement and Multi-microphone Beamforming, would you have the plan to develop AEC?
Thanks

We don't have the resources to do it right now. So please, if interested, propose a PR to provide AEC recipes to the community.


Missing dependency immer

Does immer need to be added to dependencies or peerDependencies?

https://github.com/dkershner6/use-set-as-state/blob/50eda4ffc1ab5a7c7f1641eee280ac26360f0d5f/package.json#L67
Any peerDependency of a package must be installed as a dependency of the consuming project.


AX41-NVMe / Ubuntu / pvresize failure

Good evening,
I wish to request help with the Ubuntu guide, as all the commands work until it is asked to resize the pv, which results into an error being reported.
Command from guide used:
root@rescue ~ # pvresize /dev/mapper/cryptroot
Error:
WARNING: Device /dev/mapper/cryptroot has size of 000 sectors which is smaller than corresponding PV size of 000 sectors. Was device resized?
WARNING: One or more devices used as PVs in VG vg0 have changed sizes.
/dev/mapper/cryptroot: cannot resize to 000 extents as 000 are allocated.
0 physical volume(s) resized or updated / 1 physical volume(s) not resized.
The triple zeroes have to be replaced with their actual numbers.
It should be noted I did not differ from the guide save for the LVM configuration.
PART /boot ext3 1024M
PART lvm vg0 all
LV vg0 swap swap swap 8G
LV vg0 root / ext4 all
Info: Hetzner Dedicated Server / AX41-NVMe
CPU: AMD Ryzen 5 3600
RAM: 64 GB DDR4 ECC (modified to ECC)
Storage: 2x512GB NVMe SSDs
Distribution: Ubuntu 20.04.3 "Focal Fossa" LTS (with installimage)
Rescue System: Debian 11.1 Minimal (standard)
Updated: Yes, Ubuntu was updated with apt prior to applying LUKS.
RAID: Yes, Software RAID-1
If you wish to know any other details, please ask.
I hope you (or other contributors) can help me out to resolve this issue.
Kind regards,

Also tried the guide in other issues: https://seeseekey.net/archive/122144/
But BusyBox refuses to recognize cryptroot-unlock so it doesn't improve the situation at all.
(Tried numerous things, at wit's end)


Outdated files in the dev-1.17-ko.7 branch

This is a Bug Report
Problem
Outdated files in the upstream/dev-1.17-ko.7 branch.
58 files to be modified

[ ] content/en/_index.html 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/concepts/architecture/nodes.md 1 file changed, 3 insertions(+), 1 deletion(-)
[ ] content/en/docs/concepts/configuration/assign-pod-node.md 1 file changed, 9 insertions(+), 8 deletions(-)
[ ] content/en/docs/concepts/containers/runtime-class.md 1 file changed, 3 insertions(+)
[ ] content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md 1 file changed, 16 insertions(+), 13 deletions(-)
[ ] content/en/docs/concepts/overview/kubernetes-api.md 1 file changed, 10 insertions(+), 9 deletions(-)
[ ] content/en/docs/concepts/overview/what-is-kubernetes.md 1 file changed, 6 insertions(+), 3 deletions(-)
[ ] content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md 1 file changed, 21 insertions(+), 4 deletions(-)
[ ] content/en/docs/concepts/services-networking/connect-applications-service.md 1 file changed, 3 insertions(+), 5 deletions(-)
[ ] content/en/docs/concepts/services-networking/dual-stack.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/concepts/services-networking/endpoint-slices.md 1 file changed, 2 insertions(+)
[ ] content/en/docs/concepts/services-networking/ingress.md 1 file changed, 8 insertions(+), 6 deletions(-)
[ ] content/en/docs/concepts/services-networking/service.md 1 file changed, 5 insertions(+), 13 deletions(-)
[ ] content/en/docs/concepts/storage/volume-pvc-datasource.md 1 file changed, 4 insertions(+)
[ ] content/en/docs/concepts/storage/volumes.md 1 file changed, 32 insertions(+)
[ ] content/en/docs/concepts/workloads/controllers/cron-jobs.md 1 file changed, 2 insertions(+), 1 deletion(-)
[ ] content/en/docs/concepts/workloads/controllers/daemonset.md 1 file changed, 5 insertions(+), 1 deletion(-)
[ ] content/en/docs/concepts/workloads/controllers/deployment.md 1 file changed, 2 insertions(+)
[ ] content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md 1 file changed, 2 insertions(+), 1 deletion(-)
[ ] content/en/docs/concepts/workloads/controllers/replicaset.md 1 file changed, 17 insertions(+), 1 deletion(-)
[ ] content/en/docs/concepts/workloads/controllers/replicationcontroller.md 1 file changed, 2 insertions(+)
[ ] content/en/docs/concepts/workloads/controllers/statefulset.md 1 file changed, 5 insertions(+)
[ ] content/en/docs/concepts/workloads/pods/pod.md 1 file changed, 3 insertions(+), 1 deletion(-)
[ ] content/en/docs/home/_index.md 1 file changed, 8 insertions(+), 1 deletion(-)
[ ] content/en/docs/reference/glossary/annotation.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/reference/glossary/cluster.md 1 file changed, 8 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/container-env-variables.md 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/deployment.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/reference/glossary/image.md 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/ingress.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/reference/glossary/init-container.md 1 file changed, 3 insertions(+), 4 deletions(-)
[ ] content/en/docs/reference/glossary/kube-proxy.md 1 file changed, 8 insertions(+), 6 deletions(-)
[ ] content/en/docs/reference/glossary/kube-scheduler.md 1 file changed, 10 insertions(+), 5 deletions(-)
[ ] content/en/docs/reference/glossary/kubelet.md 1 file changed, 1 insertion(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/replication-controller.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/reference/glossary/selector.md 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/taint.md 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/glossary/volume.md 1 file changed, 3 insertions(+), 2 deletions(-)
[ ] content/en/docs/reference/kubectl/cheatsheet.md 1 file changed, 6 insertions(+), 3 deletions(-)
[ ] content/en/docs/reference/using-api/api-overview.md 1 file changed, 8 insertions(+), 8 deletions(-)
[ ] content/en/docs/reference/using-api/client-libraries.md 1 file changed, 1 insertion(+)
[ ] content/en/docs/setup/_index.md 1 file changed, 3 insertions(+), 3 deletions(-)
[ ] content/en/docs/setup/best-practices/multiple-zones.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/setup/learning-environment/minikube.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/setup/production-environment/tools/kops.md 1 file changed, 1 insertion(+), 3 deletions(-)
[ ] content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md 1 file changed, 8 insertions(+)
[ ] content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md 1 file changed, 101 insertions(+), 50 deletions(-)
[ ] content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md 1 file changed, 2 insertions(+), 2 deletions(-)
[ ] content/en/docs/tasks/run-application/horizontal-pod-autoscale.md 1 file changed, 2 insertions(+)
[ ] content/en/docs/tasks/tools/install-minikube.md 1 file changed, 6 insertions(+)
[ ] content/en/docs/tutorials/_index.md 1 file changed, 2 deletions(-)
[ ] content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html 1 file changed, 8 insertions(+)
[ ] content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html 1 file changed, 1 insertion(+), 6 deletions(-)
[ ] content/en/docs/tutorials/services/source-ip.md 1 file changed, 125 insertions(+), 85 deletions(-)
[ ] content/en/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md 1 file changed, 1 insertion(+), 1 deletion(-)
[ ] content/en/docs/tutorials/stateless-application/guestbook.md 1 file changed, 1 insertion(+), 1 deletion(-)

0 files to be renamed
4 files to be deleted

[ ] content/en/docs/concepts/cluster-administration/federation.md
[ ] content/en/docs/tutorials/online-training/_index.md
[ ] content/en/docs/tutorials/online-training/overview.md
[ ] content/en/includes/federated-task-tutorial-prereqs.md

Proposed Solution
Use git diff to check what is changed in the upstream. And apply the upstream changes manually
to the content/ko of upstream/dev-1.17-ko.7 branch.
For example:
# checkout `upstream/dev-1.17-ko.7`
...
# check what is updated in the upstream
git diff upstream/dev-1.17-ko.6 upstream/dev-1.17-ko.7 -- content/en/_index.html
# apply changes to content/ko
vi content/ko/_index.html
...
# commit and push
...
# make PR to `upstream/dev-1.17-ko.7`

Pages to Update
/language ko

/assign

/close


Is SPHttpClientBatch still in beta as of SPFx 1.6?

Category

[x] Question
[ ] Typo
[ ] Bug
[ ] Additional article idea

Is SPHttpClientBatch still in beta as of SPFx 1.6 and is it expected to go GA in 1.7?
Observed Behavior
The SPHttpClientBatch class along with ISPHttpClientBatchOptions and ISPHttpClientBatchCreationOptions are only available when an SPFx 1.6 project is created with the --plusbeta flag
Steps to Reproduce
Install/Update to the SPFx 1.6 generator

Create a new project with yo @microsoft/sharepoint
Observe that SPHttpClientBatch and other batching classes are not available from the @microsoft/sp-http package
Now create a new project with yo @microsoft/sharepoint --plusbeta
Observe that SPHttpClientBatch and other batching classes are available.

+1

Yes, experienced the same and was wondering as some sources (AC's blog, SIG call) said it would be GA already with 1.6.0

+1

My understanding is that batch support, according to the docs & from chat during the bi-weekly JS/SPFx SIG call, is GA, not preview. However, as of v1.6.0 you need to include the -plusbeta version of the packages... so... it's not clear.

Batch options are still in preview also with 1.7 and not GA'd. We are working a long-term solution. We will be covering few options on upcoming community calls for the right solution to get your input.


How to dynamically match route against Open API Specification file?

I am trying to match the incoming request path against the swagger definition.

openapi: 3.0.0
paths:
  "/users/{id}":
    {operations}
  "/users/{id}/profile":
    {operations}

You can iterate the paths, and make a route for each path. The pseudocode would be like
local router, err = Router.new({
  {
    paths = { "/users/{id}" },
    handler =  $operations
  },
  {
    paths = { "/users/{id}/profile" },
    handler = $operations
  },
})
if not router then
  error("failed to create router: " .. err)
end

local operations = router:match(request_path)
if operations then
  -- request_path can be matched
  -- execute method evaluation if necessary
end


Doesn't Work

Doesn't work. Nice try Microsoft.

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

ID: 5835d670-bb0f-1f70-5ca3-118343cce487
Version Independent ID: fd9788d6-6c38-cc25-7790-1095a1f46067
Content: Create Android app with Xamarin.Android
Content Source: hub/android/xamarin-android.md
Product: dev-environment
Technology: windows-android
GitHub Login: @hickeys
Microsoft Alias: hickeys

It looks like there's no actionable feedback here, so I'll go ahead and close the issue. Please open a new issue if you have specific feedback about the documentation that you'd like us to address. For creating new apps for Android, we'd recommend trying the new .NET Android project type, replacing Xamarin.Android. https://visualstudio.microsoft.com/vs/android/


How do I apply this filter?

I seem to be getting stack overflows.
The rule in English would read something like ...
The user has access to the current EffectivePermissions row in the db if ...

The current user is directly mentioned in the row
One of the other rows also linked to the page grants the user full admin rights (all of CRUD)

builder.Filter(
    "UserEffectivePermissions",
    (EffectivePermissions perm, string user) =>
        perm.User.Email == user ||
        perm.Page.EffectivePermissions.Any(ep => ep.User.Email == user && ep.Read && ep.Create && ep.Update && ep.Delete),
    () => context.AuthInfo.Name
);

I seem to be getting stuck on stack overflows ... is there a way to refer to related sets of rows in filters like I am trying to do or is there a better way to do this?

The way you have that defined, there is no way to avoid the recursion.  Every time "EffectivePermissions" is involved with a query, it's going to invoke that filter...which invokes it again since you are accessing it with "perm.Page.EffectivePermissions".
The way you have that set up seems odd to me though.  It looks like there are Read, Create, Update, Delete properties on it.  Yet, you are only checking them via "perm.Page.EffectivePermissions".  Shouldn't you be checking those properties in "perm"?  Or maybe you just need to store those properties into a different table (such as "PageEffectivePermissions" - which would solve the recursion problem.

My scenario is sort of hard to explain without getting in to the CTE that computed the rows but lets try ...
So I have this table that represents the "EffectivePermissions" of all users on all Pages in a tree of web pages that make up a web site.
The rows I want the user to have access to are all the ones where ...
the current user is named directly (by relationship, the first clause of the query, this bit works) .
or
the user has in the set of EffectivePermissions rows also linked to the same page as the current one "admin rights".
In other words ... for the current page, the user can see their set of effective permissions (which will always be 1 row) but if they can administer the page they can retrieve all users permissions for that page.
so ...

perm == the current EffectivePermissions entity being filtered.
perm.Page == the page that the EffectivePermissions were computed for.
perm.Page.EffectivePermissions == the set of EffectivePermissions rows for that page.

...
If I understand you correctly I've hit a wall with recursion being the issue here because even inside the filter I can't refer to another entity in the same set so another way to reproduce this situation might be something like this type of filtering scenario ...
 builder.Filter("FooPairs", (Foo foo) =>  foo.RelatedFoo != null);
That's a bit of a pain for me :(
Could I perhaps call a sproc in a filter to do this computation for me?
If so ... do you happen to have an example?

I have a similar problem for users ...
So I have a users table and a roles table,  would like to filter all users from the users table where the current users is not in a role that contains that user.
This results in the same problem ... I was kinda hoping that the dynamic filters would work by modifying the  underlying IQueryable or perhaps by allowing a normal "query" but it seems there are more limitations I have not understood in how this stuff works.

Ok i worked round this by simplifying the rule here and then adding the logic to the code sat on top of the context instead of in the context, not perfect but a reasonable half way negotiation.


Feature/more log

Please Add logtype debug + static method Log.debug, Log.info that auto instantiate the log object


Fronius Wattpilot: support authenticated charging

Is your feature request related to a problem? Please describe.
Currently I think about how to fix the following issue. When I connect a car to the charger, it immediately starts charging. After a while evcc sees a differenct between desired state and current state and stops charging. I'd rather have the car not charging on connect.
The only way I found is to enable authorization of the car. That means the charge can only be started either by a RFID or in the App.
Describe the solution you'd like
If the implementation in evcc would support to start charging when car auth is required, the charge would only start after it is allowed by evcc.
In addition, evcc could check if the auth was granted externally (e.g. by the wattpolit app or by RFID) and use this as trigger to switch from "PV" to "NOW". This way, I could simply enforce charging by RFID without the need to set a charge goal in evcc.
Describe alternatives you've considered
EVCC could poll the charger more often, so that charging is stopped immediately after a car is plugged. That would work but the user experience is not that good.
Additional context
I have 2 wattpilot and would be able to test an implementation.

Closing here since we fully depend on upstream. Happy to take a PR.

Da sich "upstream" dem Thema schon angenommen hat (https://github.com/evcc-io/evcc/discussions/6992, danke @mabunixda ), fände ich es git, den Request solange offen zu lassen, bis da ein Update oder ein "geht nicht" vorliegt.


user_groups: Do not remove the user group row if user can join again.

We now do not remove the user group row immediately from "Your groups" panel when user is removed from the group, if the user can join that group again by themselves. This makes the behavior similar to what we have for streams.

Screenshots and screen captures:

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Merged, thanks @sahil839!


Getting error when trying to install the package

Hi,
I tried to install the package using pip install git+git://github.com/google/matched_markets.git but I am getting the following error:
error: could not create 'build': File exists
Do you know what might be the cause?
Thanks!

@ludmila-kuncarova you can refer to this thread
It's a different package from google, but the reason should be the same: they only support installation on linux

This appears to be a common issue, with many suggested updates to make packages compatible with Mac OS.
Curious if anyone could suggest a solution that works with the current version of this package.

Looks like a similar issue to https://github.com/pachyderm/python-pachyderm/issues/20
I got it to build on my local machine by changing BUILD to another name (e.g. BUILD_VERSION)


Duplicate duplicates!

There's a double use of duplicates in the sanitize function in timeline.
Also removing duplicate times is not as useful as removing duplicate cycles.

I would say the latter is essential, as it causes missed events in ADwin.

quite right; expressed badly


Local density function for multi-phases rheology given volume fractions

There was an in-place function     compute_density!(rho, Mat_tup1, PhaseRatio, args) to do this but we are missing the one to do it locally, which is more convinient for our codes. To avoid name redunancy and ambiguity, I think is better to use a different name for local volume fractions kernels, e.g.  compute_density_ratio(PhaseRatio, rheologies, args) here.

fair - does this allocate.

No :)
julia> @btime  compute_density_ratio($PhaseRatio, $rheologies, $args)
  5.200 ns (0 allocations: 0 bytes)


Use new shorthand syntax for unwrapping optionals

Use new shorthand syntax for unwrapping optional values
Motivation:
Using new shorthand syntax would make the code easier to read. Since we have the support to add the shorthand syntax for guard let and if let, it makes the code more readable.
Modifications:
Instead of using if let value = value, used if let value same goes for guard let.
Result:
There is no change of any logic. Just improved the better syntax of unwrapping optionals.

@swift-ci smoke test


Typecheck script broken

...which I discovered while debugging another problem. I've fixed one test input, but need to run to a meeting. I wanted to make you aware of this problem @LoiNguyenCS (see the CI output from the task that checks whether the expected outputs compile for details).

I am working on fixing these.

@LoiNguyenCS I've fixed all of the issues except for the following two, which a simple change to the test can't fix - I think there's something wrong with how we're handling interfaces:
./com/example/Foo.java:3: error: Foo is not abstract and does not override abstract method doSomething(int) in Baz
class Foo implements Baz<String> {
^
1 error
Running javac on interfacewithgenerictype/expected issues one or more errors, which are printed above.
./com/example/Foo.java:3: error: Foo is not abstract and does not override abstract method doSomething(int) in Baz
class Foo implements Baz<String> {
^
1 error
Running javac on interfacewithunsolvedsymbols/expected issues one or more errors, which are printed above.

I tried adding an override of the doSomething(int) method in the input version of Foo (which I think is required to make Foo compile - actually, Foo should implement all of the interfaces!), but it's not preserved in the output in Foo (only in the interface Baz). Can you look into this one?

Professor,
I think this bug comes back to the problem of handling overriding. For interfaces, we believe a method is overriding a method signature if they have the same return type, name, and number of parameters. This leads to some method signatures not removed even if they are not overridden by any target methods.

I think this bug comes back to the problem of handling overriding. For interfaces, we believe a method is overriding a method signature if they have the same return type, name, and number of parameters. This leads to some method signatures not removed even if they are not overridden by any target methods.

I agree. However, the output still needs to compile, and the current approach doesn't guarantee that. I think in these cases we either need to make sure that the extra interface methods have default implementations or that the overrides are also preserved. I'm not sure exactly how to accomplish that, which is why I'd like you to look into it.

I think in these cases we either need to make sure that the extra interface methods

Since we can't know which interface methods are extra, I think we can make a default implementation for all the interface methods that are not removed.

Since we can't know which interface methods are extra, I think we can make a default implementation for all the interface methods that are not removed.

As I can't make changes to this branch and the CI won't run unless I am merging something into the main branch, I will make another PR to implement this solution to the main branch.

I think this PR is good for merging.

@LoiNguyenCS this still needs an approval from you before it will auto-merge


Cannot receive email

Thanks for the great project.
I set up mailin on the server and it is listening port 25, but when I send an email from gmail, there's no response. Does anyone encounter the same or similar issue?

Do you have your DNS records pointing to the domain?

I was wondering if you had any good resources on pointing the DNS to the domain. Is it possible to run mailin on local host?

I'm facing the same issue. Setup DNS correctly, but still not receiving any emails

I have a sub domain (mail.mydomain.com) with his MX record pointing to the server IP address... I'm also able to use SMTP services to test (and validate) the server.
I works... But when I send an email from Gmail, outlook or any real email provider, there is no error, no message, no reaction from mailing.
I'm listening to port 465 and tested with 2525 also


Update to .net core 2.2

Preview1 contains no breaking changes in the validation infrastructure.

What's the reason for adding this additional TargetFramework? You shouldn't have to add new versions of one platform as long as you don't use any features of it. Anyone using netcoreapp2.2 can import packages that target netcoreapp2.1.

Hi, you are correct.
The target framework is not being changed for FluentValidation.AspNetCore.
This is solely a change to the unit test project so the tests can be run against multiple platforms.

sounds good - thx for the explanation! 👍


Fix missing borrow in pathext comparison

Fixes #48
Our Windows CI broke just after 4.2.3 released, due to 67652769a6a1013e1d6ba9084b36cabb30ca4aad:
error[E0308]: mismatched types
   --> C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\which-4.2.3\src\finder.rs:161:65
    |
161 | ...                   if s.as_bytes().first() == Some(b'.') {
    |                                                       ^^^^
    |                                                       |
    |                                                       expected `&u8`, found `u8`
    |                                                       help: consider borrowing here: `&b'.'`

@harryfei Should the CI be extended to also build-test Windows?

Oh, sorry for that.

#50 fixed this.

4.2.4 published.


Resources array MUST be present (even if empty)

I am consider making the resources entry a requirement for a valid datapackage.json - though allowing it to be the empty array.

+1

+1
I can draft this and also update the schema.

@danfowler i've already done this - just need to push.


[MINOR][CORE]spark.diskStore.subDirectories <= 0 should throw Exception

What changes were proposed in this pull request?
this pr add check this spark.diskStore.subDirectories > 0.This value need to be checked before it can be used.
How was this patch tested?
N/A
Please review http://spark.apache.org/contributing.html before opening a pull request.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Test build #4611 has started for PR 24024 at commit 2ab405a.

Test build #4611 has finished for PR 24024 at commit 2ab405a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #4614 has started for PR 24024 at commit 2ab405a.

Test build #4615 has started for PR 24024 at commit 2ab405a.

Test build #4618 has started for PR 24024 at commit 2ab405a.

Test build #4618 has finished for PR 24024 at commit 2ab405a.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Test build #4622 has started for PR 24024 at commit 2ab405a.

Test build #4624 has started for PR 24024 at commit 2ab405a.

Test build #4627 has started for PR 24024 at commit 2ab405a.

Test build #4632 has started for PR 24024 at commit 2ab405a.

Test build #4632 has finished for PR 24024 at commit 2ab405a.

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

Merged to master