Refactor binding regex to small scanner to allow custom expressions to be defined

Previous related issues
At the moment all bindings are parsed using a regex. A frequent request for 1.0 is expansion of other expressions:

Ternary operator in binding expressions (#4038)
Feature Request: Support !! in bindings (#3188) and Double negation support (#2343)
Some default computed bindings methods (#2237)

There was a previous effort to extract a separate library for expression at https://github.com/Polymer/polymer-expressions/tree/2.0-preview
How not to bloat the library
The general argument for not including this expressions is: it bloats the library. I completely agree with this statement. Therefore to provide flexibility for parsing the bindings, it would be nice to find a solution that 1. does not add bloat, but 2. is customizable to the users need. With the ability to define your own base class in Polymer 2.0, custom bindings could be a lot easier.
Proposed solution
To make this work, I did some hacking but got stuck quite fast. The main issue is that the regex is at the moment very limiting and you can't easily override/extend/modify this regex on runtime. All functions in the annotations file are static and have no instance attached.
Therefore it would be nice to replace the regex with a very simple scanner that verifies that a binding exists (e.g. between {{}} or [[]]). Then it will extract everything between the bindings and pass these values on. The values are pre-processed when the constructor of the custom element is run, which invokes a static method called processBindingValue. The default implementation of Polymer.Element uses parts of the original regex to parse strings, numbers, variables and function calls.
Now the benefit of this approach is that users can override the method and supply their custom parsing. Since ES6 classes are used, super.processBindingValue can be invoked to fallback to the implementation defined in Polymer.Element. Users can then also mix in multiple behaviors with their own binding parsers to compose multiple expressions at once.
Benefits of this approach
Since ES6 classes are used, the user can really easily override the base method defined in Polymer.Element. Most of the users won't and therefore there should not be any performance degradation. Users can opt-in, but have fully control on how they want to parse the bindings.
CC @sorvell this issue was a result of our discussion at the Polymer summit last monday.

How do you plan on building library?
I have been string tenplating and binding a month or so and have been looping patterns in get sets
The strings allow the on the fly
Quirky [janky code] binds and decision making
But in the last two days I have been experimenting with placing the event handler in a property "touchDom"
And then chaining other gets and sets on same pattern and for same usage as ternary without the "bind every time" issue
I saw the possibility late in a long sleepless code cycle, Inawake testing have not had time/define properties on my Mac has been janky with this in descriptors
To see if it will work
But in theory it should be a better approach
Gets sets plus returns of template strings then amalgammated in master prototype object
In theory
Would offer modular Dom and value binding omni directionally build the Dom and be repetitive and simple.
As we both know, however, we don't live in theory.
You're welcome to any of my work
And am willing to do grunt work that aligns in purpose
Let me know
I"lol pass some pvt Pens so you can see what I am up to
Sent from my iPhone

On Oct 20, 2016, at 5:02 PM, Tim van der Lippe<EMAIL_ADDRESS>wrote:
Previous related issues
At the moment all bindings are parsed using a regex. A frequent request for 1.0 is expansion of other expressions:
Ternary operator in binding expressions (#4038)
Feature Request: Support !! in bindings (#3188) and Double negation support (#2343)
Some default computed bindings methods (#2237)
There was a previous effort to extract a separate library for expression at https://github.com/Polymer/polymer-expressions/tree/2.0-preview
How not to bloat the library
The general argument for not including this expressions is: it bloats the library. I completely agree with this statement. Therefore to provide flexibility for parsing the bindings, it would be nice to find a solution that 1. does not add bloat, but 2. is customizable to the users need. With the ability to define your own base class in Polymer 2.0, custom bindings could be a lot easier.
Proposed solution
To make this work, I did some hacking but got stuck quite fast. The main issue is that the regex is at the moment very limiting and you can't easily override/extend/modify this regex on runtime. All functions in the annotations file are static and have no instance attached.
Therefore it would be nice to replace the regex with a very simple scanner that verifies that a binding exists (e.g. between {{}} or [[]]). Then it will extract everything between the bindings and pass these values on. The values are pre-processed when the constructor of the custom element is run, which invokes a static method called processBindingValue. The default implementation of Polymer.Element uses parts of the original regex to parse strings, numbers, variables and function calls.
Now the benefit of this approach is that users can override the method and supply their custom parsing. Since ES6 classes are used, super.processBindingValue can be invoked to fallback to the implementation defined in Polymer.Element. Users can then also mix in multiple behaviors with their own binding parsers to compose multiple expressions at once.
Benefits of this approach
Since ES6 classes are used, the user can really easily override the base method defined in Polymer.Element. Most of the users won't and therefore there should not be any performance degradation. Users can opt-in, but have fully control on how they want to parse the bindings.
CC @sorvell this issue was a result of our discussion at the Polymer summit last monday.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

This is something that could be handled by #3369


Update publish.yml

Proposed changes
Removed publish in github packages, only npm publishing left.
Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist

[x] I have read the CONTRIBUTING doc
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in downstream modules

Codecov Report

Merging #72 (82f5384) into main (cfd3e94) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #72   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           60        60
  Lines          666       666
  Branches        99        99
=========================================
  Hits           666       666

Continue to review full report at Codecov.

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


spa-http-server fallback doesn't works with proxy setting

spa-http-server's --push-state option works as long as proxy option (--proxy) is not set.
Need ideas if anyone has used it with proxy setting.

https://www.npmjs.com/package/spa-http-server is a fork of http-server and is out of date. Consequently, this isn't a bug with http-server. Sorry.


Validation Methods

It would be great to have some convenience methods to validate that there is a translation, to mimic validated_presence_of
Im thinking if you only need a translation:
validates_presence_of_translation :title

and if you need to have a translation in a fixed amount of locales:
validates_presence_of_translation :title, locales: [:en, :fr]

@ObjColumnist Seems reasonable. Would you be able to PR some tests?


added autonumbering for playlists

Added optional automatic numbering of the files created by Playlisl.download_all.
This is done by using a generator function that yields a filename prefix, which is passed to Stream.download.

Coverage decreased (-0.03%) to 85.253% when pulling d5e450b7aa4f07343726ea9a484012a082d0794b on johnvanderholt:master into 0ad0926e08598c1c85582e87ff64c1e09ddbbaf2 on nficano:master.

Coverage decreased (-0.03%) to 85.253% when pulling d5e450b7aa4f07343726ea9a484012a082d0794b on johnvanderholt:master into 0ad0926e08598c1c85582e87ff64c1e09ddbbaf2 on nficano:master.

so the project won't build anymore on python 3.4. it seems to be a bug related to the pipfile.lock the thing is i didn't change the pipfile.lock between now and my last working commit.
could someone more familair with the project like @nficano  take a closer look at this.

this is the error i got:
THESE PACKAGES DO NOT MATCH THE HASHES FROM Pipfile.lock!. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.     pluggy==0.6.0 from https://files.pythonhosted.org/packages/ba/65/ded3bc40bbf8d887f262f150fbe1ae6637765b5c9534bd55690ed2c0b0f7/pluggy-0.6.0-py3-none-any.whl#sha256=e160a7fcf25762bb60efc7e171d4497ff1d8d2d75a3d0df7a21b76821ecbf5c5 (from -r /tmp/pipenv-1lhacawa-requirements/pipenv-qfd5nzwg-requirement.txt (line 1)):
so it appears that the pluggy package that it downloaded has a different hash than was in the Pipfile.lock. which seems really weird since it's the exact same version that it used in working builds like here https://travis-ci.org/nficano/pytube/jobs/365242847.
still weird though that it's only happening in python 3.4 though.
on top of that i checked the master branch commits and it appears that nobody else touched Pipfile.lock either.
basically i'm not quite sure what the problem is, but it seems to be related to the package hash.


Add RequestTelemetry.TryGetRequestBody, RequestTelemetry.TryGetResponseBody, DependencyTelemetry.TryGetRequestBody and DependencyTelemetry.TryGetResponseBody

Is your feature request related to a problem?
It's a bit cumbersome to read and add the request/response body to the RequestTelemetry.Properties (and DependencyTelemetry.Properties).
Describe the solution you'd like.
Similar to how a lot of objects are avalible for the end user in DependencyTelemetry.TryGetOperationDetail(String, Object) it would be very helpful to also be able to be able to access the request/response body in a similar fashion.
Describe alternatives you've considered.
Doing it "manually" works, but would be nice to only having to handle the privacy-part of the issue.
Additional context.

Need to evaluate if similar concept can be extended to Requesttelemetry as well. We have quite large number of customers asking for mechanism to read request/response body. While it can't be done by SDK by default (privacy etc.), if we populate the request/response objects in this way, users can access it in initializer and add to telemetry as desired.
@cijothomas in a comment

Not stale


AirPose crashes as SteamVR opens

I'm on Windows 21H1, SteamVR 1.19.7

I downloaded the python code and the printed exception from the try/except block  is "(232, 'WriteFile', 'The pipe is being closed.')", could this be caused because I am running SteamVR inside a secondary drive through Symlink (It woudn't have installed in any drive other than Steam's installation otherwise)?


Savegame?

Hello everybody,
I just updated my Android system and the actual score of the 2048 was dropped, i.e. the game starts at the beginning.
Does the game have some kind of a savegame functionality somewhere?

If I remember correctly it saves the scores in the local storage of the webview, so it's possible the score was lost because of the update. If anyone provides a pull request with a fix for this functionality i'll gladly merge it.

Thank you for your answer! Fortunately, I made a backup before updating. Do you know where I can find the local storage of the webview?

I assume it is in /data/data/com.uberspot.a2048/databases (?).

Amaze File Manager says that there is no file in that directory :-(

@uberspot can i pick up this issue ? if the issue is not staled or resolved yet ?

Go for it. :+1:


invenio-deposit on invenio 3.1

I've just installed the invenio-deposit module and I need Help on how to use it.
Question: Can I have a use case for this module ?
Many thanks for your cooperation.

The module is not yet released and support. On top, it is somewhat difficult to start with on your own, so I don't recommend starting out with it. We're planning refactoring of it during autumn/spring for the InvenioRDM project.


Add Account Deletion and Change Password to CLI Commands

What this PR does / why we need it:
Added functionality allowing users to delete accounts, change passwords, etc., through the CLI. Additionally, grouped related commands such as login, logout, account deletion, and password change under the same user folder for better organization.
Which issue(s) this PR fixes:
fixes #982
Special notes for your reviewer:
I've been trying to do all the security implementations. If I've missed anything, please let me know. Plus, I'm wondering where the printout code is in the code for the terminal. I'm thinking about using the golang.org/x/crypto/ssh/terminal package to cover it up when a user enters a password. (checked)
Replaced the deprecated golang.org/x/crypto/ssh/terminal with golang.org/x/term to securely handle password input in the terminal.
Does this PR introduce a user-facing change?:
Users need to start with yorkie user ~ when they want to perform actions like login, logout, account deletion, and password change via the CLI.
Additional documentation:
example)

Checklist:

[x] Added relevant tests or not required
[x] Didn't break anything

Summary by CodeRabbit
Summary by CodeRabbit

New Features

Introduced methods for users to delete their accounts and change their passwords directly through the application.
Added command-line interface (CLI) commands for changing passwords and deleting accounts, enhancing user management capabilities.
Implemented a structured command framework for managing user accounts, improving organization and usability.

Bug Fixes

Improved error handling during account management processes to enhance user experience.

These changes empower users with greater control over their accounts while ensuring secure and intentional actions are taken.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@sigmaith I will review this PR after it is ready for the review.

No, it's an opportunity for me to grow if you review it in detail!


Set companion profile per character

Each of my characters have their own special pet and mount. For example, my Monk uses Squeakers as his special mount. I've written backstories for all of them and how they met the character, and i bound them to the pet/mount. However, i was wondering if there was a way to bind that to a certain character only. Like my Dreadwake is bound to my mage character as that's his special mount (Like Jania Proudmoore) but I'll also use my Dreadwake on other characters when applicable (if i'm RP'ing as a pirate mainly) but the backstory of the mount will confuse others, as it's written for a different character.

Currently profiles are set account-wide but there could be a system where you only link a companion profile when a specific character profile is active.

Duplicate of #55.


bugs in the new editing experience

Just making notes here, these things will be fixed soon. These are issues I encountered while writing my first blog post using the new editing experience.

there is nothing in the toolbar for headings or other element selections
when I tried using source view to manually add headings source view is grayed out and read only

these are now fixed in the latest nugets


add pls NAI Diffusion V4 Curated Preview

add pls NAI Diffusion V4 Curated Preview

It is planned, like the other models before. Just have to look at how everything is formatted in the request.


Native item container support

Originally in GitLab by @saethone
Native support for item containers such as backpacks and belt pouches, with weight tracking and visibility of items from the item tab (including collapsing and expanding to view inside, instead of opening a separate item sheet as is the case currently through the support of another module)
(example of a backpack in pathfinder 2e system)

@arbron is this still in progress? Last update seems to be from july 2023. If you are busy with other stuff, I could try and see if I can do it

@arbron is this still in progress? Last update seems to be from july 2023. If you are busy with other stuff, I could try and see if I can do it

It is still in progress, and should be ready for 2.5, but thank you for the offer


Add C# distribtest for alpine linux

Add alpine 3.9 C# distribtest - a workaround mentioned here https://github.com/grpc/grpc/issues/18428#issuecomment-535041155 is necessary, but at least it things work with it.

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,020,494      Total (=)      2,020,494

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,175,630      Total (<)     11,175,633

 No significant differences in binary sizes

Corrupt JSON data (indicates timeout or crash):
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.new: 10
    bm_call_create.BM_IsolatedFilter_ClientChannelFilter_NoOp_.counters.old: 10

[microbenchmarks] No significant performance differences

Let's leave this open.

This is blocked because as of now protoc binary cannot run on alpine linux.

Added a workaround that makes both protoc and grpc work fine on Alpine 3.9 - it's worth adding a test to avoid further regressions.

Adhoc distribtest run: https://sponge.corp.google.com/invocation?id=51a25ff8-e1bb-467a-8efc-4f1e6326f131&searchFor=

The C# distribtests are green:
https://source.cloud.google.com/results/invocations/1b7ff29a-d440-4fa8-9b20-b50bb607b9d0/targets/github%2Fgrpc/tests

Known failures:
https://github.com/grpc/grpc/issues/20425
https://github.com/grpc/grpc/issues/20421


[Tutorials] MLSUM dataset fails in zeroshot data annotation tutorial

from datasets import load_dataset

mlsum = load_dataset("mlsum", "es", split="test[0:500]")

/usr/local/anaconda3/lib/python3.7/site-packages/datasets/utils/file_utils.py in get_from_cache(url, cache_dir, force_download, proxies, etag_timeout, resume_download, user_agent, local_files_only, use_etag, max_retries, use_auth_token)
    592             raise FileNotFoundError("Couldn't find file at {}".format(url))
    593         _raise_if_offline_mode_is_enabled(f"Tried to reach {url}")
--> 594         raise ConnectionError("Couldn't reach {}".format(url))
    595
    596     # Try a second time

ConnectionError: Couldn't reach https://gitlab.lip6.fr/scialom/mlsum_data/-/raw/master/MLSUM/es_train.zip

Now it is working, sometimes I experience some timeouts when using datasets, not sure if there is anything we can do from our side.
I will close this issue for now.


angular-confirm requires jQuery

I am using Webpack with bootstrap 4 which is working fine. After I installed angular-confirm I am only receiving this message 'angular-confirm requires jQuery'.

ok so I was

Ok I had to adjust my Webpack config to include jQuery globally.
new webpack.ProvidePlugin({
$: 'jquery',
jQuery: 'jquery'
}),


docs: remove code block from admonition

Description
This removes the code blocks that were added in #863 as it does not look good inside the admonitions.
Screenshot (if UI-related)
To-Dos

[ ] Successful build pnpm build
[ ] Translation keys pnpm i18n:extract
[ ] Database migration (if required)

Issues Fixed or Closed

Fixes #XXXX

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

v2.0.0
GitHub release

Your semantic-release bot :package::rocket:


Abstraction between representations and calculations/evolutions

From our conversation in #102

The following point is realted to pyiron, but required to get nice solutions for ironflow:
It would be good to have for some pyiron constructs an alternative formulation. An example is

    job.calc_md(temperature=300)  # previous
    job.calc = calculator.md(temperature=300)   # alternative

Such a formulation would allow us to easily create generic modules, e.g. for MD that can be used as input for VASP, LAMMPS, etc.
The same applies to job.server etc.

Yep. I will probably hack-and-slash something to this effect after I get the book-keeping (CI, pypi release, conda-forge release) all sorted out. My current vision is that things like the Lammps node can only ever run a static calculation (or no running of these nodes??) and that they otherwise need to be passed as input to MD, minimimization, NEB, VC-SGC, etc. calculators.
This is thus a little bit different from what you suggest here, something more like:
md = pr.atomistics.calculator.MD('my_md_run')
md.temperature = 300
md.n_steps = 1000

lammps = pr.atomistics.representation.Lammps('lammps_reference')
lammps.structure = pr.atomistics.structure.bulk('Fe').repeat(4)
md.representation = lammps

md.run()

In a perfect world I imagine that the calculator would then see if the representation has native support for this type of calculation, e.g. lammps has calc_md so we would basically just be using the calculator as a wrapper interface for that -- but then if the representation doesn't allow it that the calculator either falls back on a python-coded version of the algorithm, or throws an error (probably when the representation is assigned, so we fail as early as possible).
This is definitely best implemented right in the heart of pyiron, but I think it will be productive to play around with the idea here in ironflow where I'm just making it look like that's what the underlying model is. That will give us some freedom to experiment with different architectures/interfaces without breaking anything anyone else cares about.

I was a bit verbose here, but there's a summary at the end.

Thanks for your quick and very constructive reply @liamhuber. Just a few thoughts regarding the calculator.MD idea. At a first glance it looked to me like your suggested version makes things more complex than what we have now. In the example given by you a single line
 job.calc_md(temperature=300)

would be replaced by 4 lines. In a jupyter notebook version (or general in a python script) I would not like to have it (or at least I would prefer to keep our present single line approach as one possible option).

@JNmpi I'm certainly open to leaving wrapper methods on different objects that allow the user to set multiple attributes in one line. Another idea would be to allow users to set attributes directly in the instantiation, e.g.
job = pr.atomistics.job.Lammps('my_lammps_job', structure=pr.atomistics.bulk('Al'), potential='my_fav_mendelev_pot')

But honestly, that above example demonstrates why I'm not totally comfortable with how we use calc_md, calc_minimize as they currently exist -- everywhere else we require setting input on a per-property basis. At the very least we should try to make the interfaces more uniform across different applications, whether that forbidding anything other than direct attribute setting, or adding multi-attribute setter methods where they're missing, e.g.
def GenericDFTJob(AtomisticGenericJob).define_representation(
    energy_cutoff: float = None,
    kpoint_mesh: list[int]: None,
    ...
) -> None:
    ...

However, for a visual node based approach your pseudo code would work very well. We reduce the number of inputs to the LAMMPS node and make the MD module generic. The workflow would then look like:
structure -> LAMMPS -> MD

Based on this concept we could/should also convert other inputs into the LAMMPS job into nodes. Specifically, we could have the following flow:
  structure -> LAMMPS -> POTENTIAL -> MD -> SERVER

The advantage of this flow would be that the potential module has all the critical information (i.e. LAMMPS and structure). This construct is much cleaner than the original one, since we do not have to test that one input (structure) is there to generate another input (potential).
The same applies to SERVER, where the info regarding the queue, number of cores etc. are provided. Our present LAMMPS job could be regarded as a macro node of this workflow, which collects all the input parameters of the inputs of the various nodes in the macro object, i.e., structure, potential etc.

From a philosophical perspective I think this is absolutely the right way to do it. But I would call it Representation rather than Potential, and these would be things like LJ, EAM, ACE, GGA, etc. However, I'm not convinced this linear hierarchy actually solves the need to test one input against the other. If I build up a graph of Structure -> Lammps and then put down an EAM node and send Lammps->EAM, the EAM node still needs to internally compare the library of Lammps EAM files to the structure carried by the Lammps object and provide me with some sort of drop-down menu to choose a specific EAM file -- but we run into exactly the same case that it's possible for no such valid file to exist.
I would also need some sort of protection that I couldn't pass a Vasp->EAM, nor Lammps->GGA. And I can pass Lammps->ACE, but can I pass Gromacs->ACE, even though ACE potentials are classical and Lammps and Gromacs are both classical engines?
Practically, I think this setup will wind up feeling a bit counterintuitive, since developers will need to keep potentials up to date with which engines they support (instead of engines with which potentials are possible), and since users will need to thing "I want to run a GGA calculation" (instead of "I want to run a VASP calculation").
As a bit of an aside, I also think it might be a bit awkward putting Server at the end of the chain. In my mental model, the object at the end of the end of the chain is the thing we call run on and the thing whose output we're interested in. We absolutely could have that be the server, but then we'd either need to dynamically create output for the server (e.g. by directing to the calculation output), or explicitly dig deeper like server.calculation.output. Since our server object is quite simple (queue, cores, walltime), I think it's nice to use this as input to the calculation rather than the other way around. Plus, we might often use the same server settings for multiple calculations, but it's quite rare to feed the same calculation to multiple server settings, so re-usability is nicer with the server as input.

These thoughts also show that for supporting the two very different approaches for workflows (visual node based one vs command like python based one) different code constructs are needed.

To the extent that the visual scripting approach will probably want to flatten some inputs out instead of having many smaller nodes (a sort of macro as you suggest), I agree -- in command line it's nice to have something like job.server.cores, but graphically we probably just want node.cores instead of forcing the user to instantiate a server-type node. Beyond that, I still think that both the graphical and command based interfaces would benefit from the same underlying architecture/code construct.
From my perspective there are a handful of interdependent pieces for an atomistic calculation:

A structure -- positions, species
A model -- basically a potential file, be it EAM, GGA pseudopotential, etc.
An engine -- which applies the model to the structure, and has any number of other parameters (e.g. kmesh in the case that it's an engine running a DFT model)

These are the necessary pieces for converting positions and species into forces and energies. Those can then be used to do any number of physical "calculations".
Finally, for very practical reasons we also need to specify the computational resources for the engine and/or calculation, let's just keep calling these the "server".
Right now, unfortunately, IMO we have the worst possible setup -- namely we have a mixture of two setups! Sometimes, we mangle the engine and calculator right together, EngineCalculator(HasStructure, HasModel), e.g.:
engine_calculator = pr.atomistics.vasp('mangled')
engine_calculator = [1, 1, 1]  # engine options
engine_calculator.potential = 'PAW-PBE'  # model
engine_calculator.structure = pr.atomistics.structure.bulk('Cu')  # structure
engine_calculator.calc_md(temperature=300, n_steps=10)  # implicit calculator
engine_calculator.server.cores = 4 # server
engine_calculator.run()  # Let's us know this object is the king, the thing that holds the output we want

Other times we break them apart, Calculator(HasEngine); Engine(HasModel, HasStructure), e.g.:
engine = pr.atomistics.Lammps('separated_engine')
engine.structure = pr.atomistics.structure.bulk('Cu')  # structure
engine.potential = engine.list_potentials()[0] # model

calculator = pr.atomistics.PhonopyJob('separated_calculator')
calculator.ref_job = engine  # In this case, the calculator will update the structure for the engine
calculator.some_options = "something, whatever"

I like this second setup better, although obviously if the engine has some sort of built-in and very efficient tool for running the calculation it's desirable to use that under the hood.
Summary
In the abstract, these are the main architectures floating around my head now:

What we have now: sometimes EngineCalculator(HasStructure, HasModel, HasServer) but other times Calculator(HasEngine, HasServer); Engine(HasStructure, HasModel, HasServer).

Representation = Engine or nothing (i.e. entangled with calculation)
Pros:

We already have it and it's working
Calculations that are supported by the engine are easy to run and very computationally efficient
Easy to write new calculations as long as they're supported by the engine (e.g. extending Lammps with calc_vcsgc)

Cons:

Totally different interfaces depending what sort of calculation you're running
The primacy of the engine discourages abstraction, so sometimes (often?) the same model property gets different pyiron names in different engines
Infrastructure for building new calculators is not very developer friendly (cf. the ongoing debate about differences between ParallelMaster/SerialMaster/interactive jobs)

What I think you suggest here: Server(HasCalculator); Calculator(HasModel); Model(HasEngine); Engine(HasStructure)

Representation = Model, Engine is basically just a choice among codes that support this Model
Pros:

Putting the model at a higher level than the engine is a good reflection of the physical reality

Cons:

Server reusability issues above, but this can be solved by switching to Calculator(HasModel, HasServer)...
SUBJECTIVE: IMO less intuitive for users and developers, who need to think about which engines will support their desired model instead of choosing an engine to use and then selecting a model it supports

My favourite so far: Calculation(HasEngine, HasServer); Engine(HasModel, HasStructure)

Representation = Engine, Model is basically just a choice of potential files (or equations, e.g. for LJ) that are supported by this Engine
Pros:

Calculation takes primacy, encouraging abstraction and (hopefully) making new calculations easy to implement
Implementing abstract python-level calculations (NEB, phonons, etc) would mean new engines can automatically be used for all manner of physics
SUBJECTIVE: Intuitive for users who probably come in thinking "I want to run a VASP calculation in pyiron" or similar

Cons:

Need some under-the-hood magic for calculations to take advantage of engines' built-in-routines where available (e.g. minimization, MD)
Less physical than the one above, since the Engine takes precedence over the Model

@liamhuber, thanks for your thoughts and detailed description. I definitely also see the need to unify the syntax for providing/modifying input and parameters. I would also opt that users can chose among multiple options, i.e., they should be able to use a construction they prefer. To put this into pseudo code:
job.calc_md(temperature=300, n_print=100)

should be identical to something like:
job.set.calc.md(temperature=300, n_print=100)

This approach could be easily generalised to structures, potentials etc.
job.set.structure.bulk('Al')

I also like your suggestion:
job = pr.atomistics.job.Lammps('my_lammps_job', structure=pr.atomistics.bulk('Al'), potential='my_fav_mendelev_pot')

To unify the input we could allow the following constructs simultaneously:
job.input.incar['encut'] = 100

job.input.incar.encut = 100

job.input.incar(encut=100)

Thanks also for your detailed thoughts and discussion regarding the structure of the engineCalculator. I fully see your point when you define a node like EAM for a specific set of potentials. What I had in mind was to create a generic potential node that receives all its information it needs from the calculator, i.e., sometehing like:
 def potential(job):
        return job.list_potentials()

Thus, when replacing one job (i.e. Lammps by VASP) or one structure by another one the list gets updated. In the worst case no potential exists, but this could be easily handled. Since the structure is an input into job this construct would be a true functional object, i.e., changing within one node an input will have no impact onto another one (which it presently has). The sequence would then be:
  structure -> LAMMPS -> POTENTIAL -> MD (-> SERVER)

I fully agree that we may/should still provide a macro node that groups all the inputs together like we have it now.
To formalise this discussion, a node should be purely functional, i.e., node(i1, i2) should rely on independent input i1 and i2, not on something like i1 is a function of i2, i.2. i1=i1(i2). Having this notation of a node being a pure function and a workflow being a sequence of these functions would make it easier to check the validity of certain constructs.
In this way I also have a slight preference for constructing first the full job (in this case MD) and sending this object then to the server (SERVER). A possible scenario would be that depending on the job type (i.e. LAMMPS vs. VASP) we could easily assign different resources.
The above discussion are just a quick summary of my thoughts and I am happy to get your insights.

Input syntax unification
I'll make a new issue for this over on base or atomistics summarizing and linking this discussion.
Nodes

To formalise this discussion, a node should be purely functional

This is a really superb point. I wasn't thinking about it clearly in those terms, but I completely agree. I'm not sure I agree on the definition of functional though:

a node should be purely functional, i.e., node(i1, i2) should rely on independent input i1 and i2, not on something like i1 is a function of i2, i.2. i1=i1(i2)

From my perspective this is simply a matter of certain input combinations being (in)valid, which is totally fine in a functional paradigm. From my perspective, our current Lammps node then just provides a helpful UI layer on top of this functional node so that the user can avoid these impossible combinations.
For me what is important with functionality is that the node produces the same output given the same input, regardless of how many times it's executed. A corollary to that is that the node is node modifying some sort of global (or at least super-self) state. Here our Lammps node needs some work, since right now I think we can modify the input, hit "run", and the job will just re-load itself! But that has to do with input locking or setting delete_existing_job=True rather than the fact that the potential input is conditional on the structure input.

The sequence would then be:
  structure -> LAMMPS -> POTENTIAL -> MD (-> SERVER)

...
In this way I also have a slight preference for constructing first the full job (in this case MD) and sending this object then to the server (SERVER). A possible scenario would be that depending on the job type (i.e. LAMMPS vs. VASP) we could easily assign different resources.

It's definitely possible for this setup to align with my definition for functional nodes, but I'm not sure it's the most efficient. For instance, POTENTIAL does need to see an Atoms object; I'm not totally comfortable with POTENTIAL peeking at LAMMPS.input.structure, but avoiding this would require that the structure get copied (including when we serialize the graph state) in LAMMPS.output.structure.
I have an even deeper concern with the idea of "sending [the MD job] to the server". From my perspective it would be un-functional if SERVER.execute() updated MD.output. Again, this is avoidable if SERVER doesn't touch the MD object itself, but internally makes a copy of anything it needs to copy (like using a ref job) and writes all of the job's output to its own output field. In principle this is possible, and I'm not 100% closed to putting SERVER at the very end, I just think that we would need to then do a bunch of work to make sure that the SERVER.output formats nicely and is usable, regardless of what type of calculation we pass to SERVER.input.calculation.

@liamhuber, thanks for formalising the discussion. Below a few thoughts to the various issues:

a node should be purely functional, i.e., node(i1, i2) should rely on independent input i1 and i2, not on something like i1 is a function of i2, i.2. i1=i1(i2)

From my perspective this is simply a matter of certain input combinations being (in)valid, which is totally fine in a functional paradigm. In this view, our current Lammps node then just provides a helpful UI layer on top of this functional node so that the user can avoid these impossible combinations.

I realize that my notation was insufficient. The main point I wanted to make is that i1 is not only an input of i2 but also of the node n1 itself, i.e.
i2 = i2(i1, n1)

To be specific, the potential depends not only on the structure, but also on the calculator, i.e., whether Lammps, VASP etc. are used. To prevent that the input depends on the node in which it is used was the starting point for my thoughts. The question whether an input i1 depends on the node itself or not depends on the abstraction level. If we want to just use code specific input we don't need it. However, for generic constructs like MD or MD we need to know the node (code) type to translate the generic input into a code specific one. Whenever we have such a situation (which imo is the case for any generic input) we need to resolve the implicit node dependence into an explicit one, i.e.:
n1(i1) -> n2(i2)

In our case n1 would be the calculator (LAMMPS, VASP etc.) and n2 the potential.
These considerations address also your second point:

It's definitely possible for this setup to align with my definition for functional nodes, but I'm not sure it's the most efficient. For instance, POTENTIAL does need to see an Atoms object; I'm not totally comfortable with POTENTIAL peeking at LAMMPS.input.structure, but avoiding this would require that the structure get copied (including when we serialize the graph state) in LAMMPS.output.structure.

In practice, the potential node does not need to peek into structure, but that node1 provides a function to create the input for node 2. Again for the case of the potential this would be simply the list_potentials() function. n2 would be the a high level container that allows the user to select only potentials that are consistent with the code described by node n1.
When thinking about this I don't see a difference to the MD node. If we would use the LAMMPS specific notation/input file we could use the same argument as for the specific potential, i.e., it would be an input and not a separate MD module.

Thanks for clarifying, @JNmpi! The explicit example with a Potential node as basically just a container was super helpful. Actually I am slowly becoming convinced that there is no fundamental implicit dependence going on either way, although I agree that such implicit dependence would be bad and we need to be careful not to add it where it doesn't need to be. So I think both the "implicit" case where Lammps takes a potential as an input and the "explicit" case where the Potential node exists by itself are fundamentally equivalent.
Suppose, in the case that the Lammps node directly takes structure and potential as inputs, that we enter a Cu structure and an Al potential, this is simply an invalid combination of  input and the node won't generate a valid output object. If the potential input is explicitly provided on the graph, e.g. from the output of a String node or something, then it's game-over and the Lammps node won't generate output. On the other hand, if that input port is open, then we could be (and currently are) user-friendly and update this to the 0th choice of available potentials for the current structure. I have to confess, this is really getting close to the line for "functional node". In principle the node should not carry any internal state, and my argument here is that whether or not it has a particular port connection is external graph state. Even this level of hand waving is, in principle, avoidable by leaving the node input in the "last state" and just letting the output fail, and then forcing the user to select a new, valid potential. Automatically updating the (not connected) input effectively just skips over that last human-involved step, so I'm comfortable with it.
The catch is, I don't see a big difference with the "explicit" version where it's broken down to Structure -> Engine -> Potential. In practice, the Potential node really has two inputs: available_choices and choice_index. So if we first feed it an engine that has many choices, select one with a high index, and then feed it a smaller set of choices from a different engine, then we're in exactly the same place we were before -- technically the node output is now broken (e.g. forced to be None), and in practice it's very user-friendly to just update choice_index to 0.
So in both cases it's always possible to recover a sort of "pure functionality" by simply letting the nodes break when one input updates to be incommensurate with another one, but in both cases there is a user-friendly "hand-wavingly functional" approach where (iff the node input in question is not explicitly wired to another node's output) we automatically update the input to something useful.
The good news is that if both the "implicit" and "explicit" topologies really are equivalent in this way, we can just be super pragmatic in choosing how we implement it. In this case, I think the connection between a Lammps classical potential and a Vasp pseudo-potential is actually quite weak, and I'd just keep them split up as inputs to their respective engines. (Otherwise what would we do with, e.g. Wien2k? It feels like these codes, but wouldn't make sense as input to a Potential node.)
Ryven itself is not fundamentally functional at all; for instance when we naively set up the BulkStructure node, if you had a cubic Al cell, and tried to update the species to Mg, then the input does change to Mg but the output fails and stays as an Al cell. Since the initial cell could have been any (cubic) structure, you get (semi)arbitrary output with the same input element=Mg, cubic=True. I fixed this by re-setting the output to None when the structure generation raises an error. I think this is a pattern we should adopt more widely.
In the latest branch (#131) I am now explicitly doing type checking on ports, and added an attribute all_input_is_valid to nodes, which makes it easier to write nodes in this way. E.g., just adding if not self.all_input_is_valid: SET_ALL_OUTPUT_TO_NONE at the end of update already covers over a lot of non-functional cases.
Right now this type checking is still very primitive based on classes and values, but soon I'll start on the NumFocus "ontologicalization" work and we'll see how much power we can milk out of it.

Thanks @liamhuber. I fully agree that the two cases are fundamentally equivalent. Since both have there pros and cons we should provide both options to the user. This approach would follow the python philosophy - provide all modern concepts of computer languages, rather than forcing users into a certain paradigm (e.g. functional only). In this way the users can come up with best practice examples and decide what works best for them.
It may be helpful to remember how we got into this issue: It started with your idea to put MD after the Lammps job. I first didn't like it, since it makes the code in the jupyter notebook longer and less compact. However, the more I thought about it the more I realised that this is the way to go when attempting to replace specific input by generic (input) modules. While these generic modules are great for our workflow concepts it is probably a good idea to provide also the more compact input option to please the more application oriented users.
I thought also a bit about use cases where one or the other formulation would be more useful. A particular important use case for workflows are parametric studies, where loops over various input values have to be performed. For the potential case, a specific scenario would be to go over all available potentials for a given atomic structure. In the formulation
structure -> AtomicCalculator -> Potential

one could add an optional input all. If this parameter is set to True the Potential node would create and run all corresponding (e.g. Lammps) jobs. In this respect the Potential node is not only a container for list_potentials but is derived from something like a ParallelMaster, i.e., it can create and run these jobs.
Directly related to the above thoughts it may be helpful to implement a new data type Batch or BatchData. If a job creating node receives as input such a variable it would create a bunch of parallel jobs. An example would be a batch of structures (e.g. our structure container) or the above discussed set of potentials. The advantage of this approach would be that we don't need any explicit loops or indexing, i.e., we get away with easy and intuitive graphs. The possibility to avoid explicit indexing is similar to what numpy is doing and is the basis for very compact and well structured code.
To summarise the  above thoughts, the following workflow example would be possible:
Batch(StructureContainer) -> Batch(AtomicCalculators) -> Batch(Potentials)

would create and run a three dimensional set of jobs going over all structure, atomic calculators as well as available potentials for each calculator, without having to setup a single for loop.

@JNmpi super! I think we are basically in agreement. It was helpful for me to go through this in detail though -- I was not even thinking in terms of "functional" nodes, but even if we present users with fancy UI that hides this aspect, it will still be helpful to design (most if not all) nodes from a functional perspective.
I think we're still on slightly different pages with Potential, but I feel this is more of a difference of opinion in the underlying ontology than in ironflow; your point about being able to parametrically scan over potentials is very well taken. I think we can defer most of that to a future discussion on atomistics ontology.
I really like the Batch idea. It's quite similar to something that I worked on over in pyiron_contrib.protocol, where we had List vertices to wrap other vertices -- the input parameters would then either be singular values which were sent to the wrapped node direct, or list-like parameters with the same length as the number of node children that got broadcast to each child separately. Here we want users to be able to build batched nodes directly from the GUI instead of in code, which differntiates it from the old Protocol work and the way you describe it is better for this context.


Refactor options.

Fixes https://github.com/googlegenomics/dataflow-java/issues/114
Other minor but related cleanup including:

simplified OutputDatasetId for CalculateCoverage pipeline
got rid of now obsolete non-gRPC version of JoinNonVariantSegmentsWithVariants
fixed all code with warning "local variable definition hides another field or variable"

Also confirmed that integration tests pass.

@dloy PTAL

LGTM


Some questions

Hi， @jaeyoungjo99
Thank you for open-sourcing such an amazing piece of work. As I’m studying the code, I have some questions and would like to discuss them with you:

Why is the lidar_time_delay processing necessary? After processing, the LiDAR timestamp is no longer accurate. Since the delayed time is used for distortion correction and EKF state updates, won't this have an impact on the results?
In the function Run() of the EKF, the current state is updated to the latest system time through RunPrediction(cur_timestamp).  However, during observation, it seems that the time difference between the observation data and the current system state is not considered. Could this be an issue? Specifically, when performing observation with PCM estimation results, although the PCM calculation result is compensated, the LiDAR data used to estimate PCM has undergone lidar_time_delay processing. Is this approach reasonable?

Looking forward to your reply.
Best regards!

Thank you for your question.

First, lidar_time_delay is a parameter to deal with the ros time delay that occurs when the sync system between the lidar sensor driver and the system is not established. In our system, a delay of about 30ms occurred empirically and was applied.

Basically, the EKF system I have configured operates based on the current time. Therefore, of course, the data used in RunGnssUpdate() must be synchronized with the current EKF system time. Therefore, the GnssTimeCompensation function in https://github.com/jaeyoungjo99/ELiMaLoc/blob/f89294b3714f19cda3a94e8f49ccf17dbf635f23/src/app/localization/ekf_localization/src/ekf_localization.cpp#L176C9-L176C29 compensates for the time delay of this observation.

Additionally, to explain the function, the interpolated position data through the CV model is used for Gnss Update by the amount of delayed dt based on the ekf state closest to the observation.

Hi， @jaeyoungjo99
Thank you for your patient reply. I have a few more questions:

How can I obtain the time difference between the LiDAR sensor and the system?
I noticed that in the CallBackPcmOdom, the PCM results are compensated, but in CallBackNavsatFix, no compensation is performed. Could there be a time difference between the GPS observation and the current EKF state?

Hello @chengwei0427

The time delay between the lidar and the IMU (or system) was actually tuned empirically(no tool).

The position data received via GPS was assumed to have no delay.

Thank you for your patient answers. My questions have all been resolved, and I will close the issue. Thanks again!


Does rust doc search support Regex expression

I assume this is about searching inside documentation, not searching crates?
Crate-search is built inside docs.rs, the search inside the documentation is inside rustdoc.
So this is either an already existing or new issue for https://github.com/rust-lang/rust ( where rustdoc issues are tracked), cc @GuillaumeGomez

I now want to search for objects in the document that contain the end of Read. How should I search


Include/Exclude only some declarations.

Hey !
One of my project reference two d.ts files, one I want in the doc, the other I don't want (because it's the whole node's declaration...).
Is there a way to do that right now ?
If not, that could be a really nice features to have, imo.

Hi Florent, nice to hear from you. You can use the --externalPattern argument to achieve something like that. This option allows you to specify a pattern (parsed using minimatch, same as grunt uses, see https://github.com/isaacs/minimatch for details) that marks files a being external. You can exclude external files by specifying the the --excludeExternals flag.

Alright, so after a lot of trials with the patterns, I was indeed able to exclude one declaration file from being documented !
Just for reference, my cmd line looks like this:
typedoc --out docs/ api/ [...] --includeDeclarations --excludeExternals --externalPattern **/*node*
The pattern exclude the file which name contains "node" in the api/ folder.
Great job on typedoc by the way, really useful stuff, and the default themes are nice.
Many thanks !

Thank you very much, great to hear!


added level 1 SMGs from combat 2.0

@1sourcecontrol. before I go crazy with a bunch of data entry, we need to settle on a format that we think is easy for players to consume. Does this look good? How do we want the file structure to look? Do we want to put level 5 weapons in with the level 1 weapons? Do we want to put all of the weapons in the same massive document? Will that be easy to read on github? Will that be easy to print out?

Alright, I took your commit and played with it a bit.
I'm not sure if it was on purpose but you missed some information and didn't write down some other information, so I corrected all that. Don't forget to look at column V in the spreadsheet, it has any extra notes on the weapons.
I'm hoping we can condense the information a bit more and take advantage of some of the unused whitespace. My vote is for all the weapons together in the same .txt, or splitting the weapons up by class. We could even put a couple weapon classes in the same .txt. Such as, carbines and automatic rifles.
If we split the weapons up by level, then people will have to compare multiple text docs instead of finding all of their info in one place.
I have a screenshot, it has indent = 8 on github. We should be careful to make sure it's easy to tell when one weapon ends, and another begins.
screenshot 1:

:open_mouth:  What did I miss?

I don't have the time atm to explain, but if you compare the screenshot i gave and your commits, you'll see the missing data.. stuff like accuracies and burst fire

K. This week is going to be a bit tight with the turnaround from Vegas to DC. I'll use this format when I get the chance.

Made changes to match your format. Added missing burst info.

Not to be looking over your shoulder while you work, cuz I don't know how you like to develop (multiple commits, etc.) But I see some number mistakes (name of a gun and ranged miss chance), and a lot of spacing-formatting problems.

How's that? IF there are still mistakes, please mark them up. I'd like to get through this a little more quickly; it's blocking other work and we're a little behind the deadline to play this in winter.

How 'bout that?

Ok, so to make sure we are on the same page, this is from my notepad++:

This is from google chrome:

This is from Internet Explorer:

I take it you are using Firefox and it looks different?

Left is my text editor, right is Firefox. What is going on?

Ok, so you do see the tab changes. That's good.
As you surmised, I believe the tab size is the problem. When you are editing a file, you can change the tab size as well as word wrap. (Word wrap didn't look as clean so I didn't bother). I think all our .txt's on CX are 8 size tabs

I think we'll get the best readability if we make sure that most of the text is tabbed the same, like the format picture I showed at the very beginning


Add Utteranc.es as a commenting engine

Since you've gone and done the hard work of updating the commenting stuff to allow for different engines, if you'd like I can whip up a PR for https://utteranc.es
It claimes to be a;

A lightweight comments widget built on GitHub issues. Use GitHub issues for blog comments, wiki pages and more!
Open source.
No tracking, no ads, always free.
No lock-in. All data stored in GitHub issues.
Styled with Primer, the css toolkit that powers GitHub.
Dark theme. 🌘
Lightweight. Vanilla TypeScript. No font downloads, JavaScript frameworks or polyfills for evergreen browsers.

If anyone is here hoping to find a quick answer to the question of how to just add utterances, see my comments towards the bottom of this great blog post on the topic: https://masalmon.eu/2019/10/02/disqus/
Basically:     just replace everything in layouts/partials/comments.html with the code snippet from utterances.
Source: http://rmflight.github.io/post/comments-enabled-via-utterances/
Commit adding Utteranc.es to my site (so simple): https://github.com/rbind/robinlovelace/commit/4eb251f807640cf449cc3fed25dec51c3ab90f3b

If anyone is here hoping to find a quick answer to the question of how to just add utterances, see my comments towards the bottom of this great blog post on the topic: https://masalmon.eu/2019/10/02/disqus/
Basically:     just replace everything in layouts/partials/comments.html with the code snippet from utterances.
Source: http://rmflight.github.io/post/comments-enabled-via-utterances/
Commit adding Utteranc.es to my site (so simple): https://github.com/rbind/robinlovelace/commit/4eb251f807640cf449cc3fed25dec51c3ab90f3b

I had created a PR to add this to the repo but was directed to make a plugin.  https://github.com/wowchemy/wowchemy-hugo-modules/pull/1364  That code may help others either make a plugin (I got lost there) or add it manually to their site.

I had created a PR to add this to the repo but was directed to make a plugin.  https://github.com/wowchemy/wowchemy-hugo-modules/pull/1364  That code may help others either make a plugin (I got lost there) or add it manually to their site.


Recommend approach to "apply" CronWorkflow

Summary
We'd like to deploy our CronWorkflows as part of a CD process. What's the recommended approach to "apply" a CronWorkflow, where they may or may not exist? A couple of draft options:
Delete & create
e.g. argo template delete --all; argo template create workflows/*.yaml
This is fine, but if there's an error in one of them, it'll leave it deleted rather than unchanged.
There's also some corner case that the workflow trigger falls between the delete and create.
kubectl
e.g. kubectl apply -f workflows/*.yaml
I think this fulfills the goal, but it returns a non-zero exit code of error: from {}-workflow-: cannot use generate name with apply if there are non-cron or template objects.
I'd have thought given Argo's focus on declarative approaches, this would be a 'golden path', so I hesitated to use a non-argo command. Or is this the recommended approach/
Thanks again for the superb tool!

First, to apply CronWorkflows you should use argo cron create, not argo template create. (same with delete)
How about using Argo CD for this? Argo CD will automatically apply your CronWorkflow objects to the cluster based on changes on a Git repo.
Otherwise, maybe an argo replace command will be needed. I'll discuss with the team.

Thanks @simster7 !
Do you know off-hand what command Argo CD uses? I'm certainly open to using it; to the extent it's calling a standard command, that would make allow some of the functionality without committing to the whole product.

Do you know off-hand what command Argo CD uses?

Not sure off hand, sorry. Feel free to ask there :)


[Event Request] Table 36 - Sales Header - OnBeforeAssistEdit event cannot return true/false

Hi Team, in case of using OnBeforeAssistEdit event on sales header, if I need to escape standard code using OnBeforeAssistEdit with IsHandled equals to TRUE, I'm not able to set true or false to the procedure's return parameter

Thank you

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Exclude directories on full sync example

Hi.
first of all, thanks a lot for the great repo!
I am struggling with the syntax for excluding certain directories with the full sync.
I think that I should be using the ftp-mirror-options property. So far I have tried, without success, exclude, --exclude, --exclude-glob, --exclude-glob=.
Thanks a lot in advance for your support!

Could you provide examples of the exclude options that you have tried with mirror.

Could you provide examples of the exclude options that you have tried with mirror.

My last try was like this:
          ftp-mirror-options: |
            --exclude-glob=.git/*
            --exclude-glob=.git*/*
            --exclude-glob=build/*
            --exclude-glob=data/*
            --exclude-glob=node_modules/*

Try this:
ftp-mirror-options: "--exclude-glob=.git/* --exclude-glob=.git*/* --exclude-glob=build/* --exclude-glob=data/* --exclude-glob=node_modules/*"

That did the trick.
Thanks a lot for the help!


Option: maxUses & Validator function

Added the ability to specify a validator function when constructing a new phantom-pool, leveraging the underlying generic-pool implementation of that functionality. (Also fixed a typo in the package description.)

In my project, I'm using the validator function in conjunction with a uses counter on each instance. The validator rejects the instance once the use counter exceeds a specified maximum limit. Previously, we've seen some memory bloat in phantomjs over time, hence the use limit.

Seems like a good idea! I'm wondering if you could add your validator function as well so that people could use it like so:
import createPhantomPool, { useCounterValidator } from 'phantom-pool'
const pool = createPhantomPool({ validate: useCounterValidator })

There are a couple other relevant pieces of code that would have to be incorporated:
Something needs to increment the use counter on each acquire/use. I currently do this by overriding the use function and incrementing a custom property on the instance, since the package otherwise doesn't track the number of uses in each instance. That could be easily folded directly in, if desired.
function useWithUseCounter(fn) {
  return pool.use((instance) => {
    instance.uses = _.get(instance, 'uses', 0) + 1;
    return fn(instance);
  });
}

The validator function just compares the use count on the instance to a provided maximum value.
I was trying to keep this project generic, so I didn't try to fold these in. Thoughts?

I think it's a common enough problem that it should somehow handled by this module, possibly by default. Maybe we should just add a maxUses parameter that activates the counter/validator logic?

Sounds good to me. I'll do that and put up a different PR.

I added the maxUses parameter, on by default. I kept the optional validator function as well, defaulting to always returning true.

I decided to have it track .uses even if maxUses is turned off (by setting to 0). Seems like it still might be useful for debugging purposes.

Looks good! Thanks :)

What's your plan for merge and release? Once this is merged, I'll just point to the commit until there's a new release to use.

Sorry for the delay. It should be available in<EMAIL_ADDRESS>


Add Cloudflare Warp routing

Proposed Changes
I consider this as WIP as there is definitely room for improvements. Feel free to criticize. 😉
warp_enable: true
warp_routing:
  - <IP_ADDRESS>/24
  - <IP_ADDRESS>/24
warp_reset: true

This PR introduces three new (optional) configuration options.
warp_enable: true Will add the necessary options to json.config to allow warp functionality. Furthermore if warp_routingisn't specified, the existing network interfaces will be read and routing will be set up for cloudflare tunnel.
If warp_routing: trueis set, the given hosts will be used for routing and host interfaces will be ignored.
warp_reset: true will remove all warp related add-on configuration options and delete all tunnel related routes.
Open points:

Config options check (e.g. warp_routing is set and warp_enable isn't...)
How and which routes to delete? For now I delete all routes assigned to the tunnel before setting the configured ones up. Is there a more common way?
...

Related Issues

closes #62

Good suggestions, I will implement the changes.


DOC correct gamma function in docstrings in scipy.stats

docstrings in continuous_distributions.py:
Use \Gamma instead of \gamma to denote the Gamma functin Special.gamma as discussed in #8816. Only occurence of \gamma left is in ncf_gen where it denotes the log of \Gamma.
for chi and chi2, this overlaps with #8865.

Not clear why python 2.7 build fails:
The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over). The job has been terminated
The following test is indeed repeated until the job is terminated:
scipy/sparse/tests/test_base.py:4581: in _check_resiliency

I get the same error in a PR of mine(gh-8737). I think gh-8885 may have fixed it, disabling FutureWarning and PendingDeprecationWarning.  May require a rebase to pick up the change.

@pvanmulbregt : thanks for the hint, after the rebase, the build for 2.7 worked.
now there is an unrelated error for 3.6:

Error: Failed to download resource "gcc"

now there is an unrelated error for 3.6:

that looks like an intermittent CI issue, I've restarted the build

@rgommers hm, now it fails due to an import error.

@rgommers hm, now it fails due to an import error.

that seems to be due to the rebuild not being a full build, and us having bumped LAPACK to 3.4.0. Let's just ignore that one, it's unrelated to this PR.

Okay merging. Thanks @chrisb83 and @pvanmulbregt


New transform system broke pymc tests

I didn't have time to figure out the source of the problem, but the test suite in PyMC started to fail multiple places with aeppl 0.0.16:
https://github.com/pymc-devs/pymc/pull/5185/checks
https://github.com/pymc-devs/pymc/pull/5159/checks

Here is a PyMC snippet that behaves differently between aeppl 0.0.16 and 0.0.15
import pymc as pm
import numpy as np
data = pm.floatX(np.zeros(10))
with pm.Model() as m:
    p = pm.Beta("p", 1, 1)
    obs = pm.Bernoulli("obs", p=p, observed=data)
print(pm.logpt(obs).eval({p.tag.value_var: pm.floatX(np.array(0.0))}))

I couldn't get a MWE using aeppl directly yet.

Please, do not create generic PyMC issues in this repository.  Create an issue in PyMC and work out the AePPL-specific problem/question(s) then create an issue in this repository for those.

Here is the problem. Aeppl's rvs_to_values is still checking for value_var in tag and this screws up the replacements with the new transforms.
import aesara.tensor as at
import aeppl
import aeppl.transforms

p = at.random.beta(1, 1)
obs = at.random.bernoulli(p)

p_val = p.type()
obs_val = obs.type()

tr = aeppl.transforms.TransformValuesOpt({p_val: aeppl.transforms.LogOddsTransform()})

p.tag.value_var = p_val
logp = aeppl.factorized_joint_logprob({obs: obs_val, p: p_val}, extra_rewrites=tr)

logp[obs_val].eval({p_val: 0, obs_val: 0})

You can the right result if p.tag.value_var = p_val is ommited

Do we still (or ever needed) to work with the .tag attributes in aeppl?

Do we still (or ever needed) to work with the .tag attributes in aeppl?

No, not here at least.


Bundled up gradle plugin (something to make you aware of)

I wanted to allow users a bit more control over their build so I wrapped up your tool in a gradle plugin that I'll continue to develop as time goes on.
https://github.com/JLLeitschuh/ktlint-gradle
@shyiko I'm happy to add you as a contributor if you are interested.

@JLLeitschuh Nice :+1:! Let me know when it's finished and published to Maven Central (jcenter or whatever your poison is). Add I'll gladly add a link to the readme.md.

@shyiko I'm happy to add you as a contributor if you are interested.

Thank you for the offer but I think there is no need. Fork button is one click away ;)


Improve styling of loading spinner in file selector modal

Tasks

[ ] Decrease size of loading spinner to properly fit in file selector modal.

Use case
No response
Related Pull request
No response

Is this maybe related to #528? What do you think about having some guidelines how loading should be done/how to deal with waiting times?