Scroll/Reveal when there are multiple cursors

VSCode Version: 1.1.1
OS Version: Windows 10

Steps to Reproduce:

Create two or more cursors in a document
Move the cursors down using the down arrow key until the cursors go outside of the editor
If there is only one cursor, the document scrolls to keep the cursor visible but it doesn't if there are multiple cursors

I think that https://github.com/Microsoft/vscode/issues/55780 would also help this problem (but they are certainly not mutually exclusive).

the issue still exists in 1.29.1

Just wanted to say this is possibly the most annoying bug for me right now, it really disrupts my workflow since doing multiple cursors operations and then undoing is very common. Please give this importance >_<

still an issue in 1.32.2

@builder7777 Rather than noticing that this issue still isn't fixed (which is obvious, it's still open 😛), I think that the VS Code team would welcome a pull request.
If you don't have time to do so (I don't), you can :+1: this issue and ask other people to do so.

Hello, I'm in trouble with this issue too.
I investigated the code and found this is because of here:
https://github.com/Microsoft/vscode/blob/1afeb46cc4f2856ed6d0759fff85b13647c7ab83/src/vs/editor/common/controller/cursor.ts#L431-L436
Then, I looked for where this code came from and found that it was the very first commit of this repo:
https://github.com/Microsoft/vscode/commit/8f35cc4768393b25468416829e980d7550619fb1#diff-f8aa0da950270e2d56baecaf5819a4c5R871
but cannot find the reason from any commit messages.
I tested and confirmed that this issue would be resolved if the else-clause shown above is removed.
I want to fix this and commit it, but don't know whether it's OK. There should be some discussions on such a fundamental behavior.
How do you think, @alexandrudima ?

The issue still exists.

almost 4 years later, still here in version 1.41.1.

I finally created a PR for this issue.
I hope it will be merged, or at least, a discussion will start.

With bc5d1b1d0559ab081df847b5ce84ca1621d158e2, I have pushed a change that in the multicursor case, a conceptional rectangle/bounding box is computed around all the cursors.
If the bounding box fits in the viewport, it is revealed, but if the bounding box does not fit in the viewport, the editor does not scroll.

Still doesn't work for me. Can someone confirm that it is fixed?

@borishere Are you using insiders? Stable does not have that change yet.

@alexdima I'm using a stable version. Thanks for clarification.

Still doesn't work for me too


Fix generate argument parsing

Fixes #80
Argp calls the parse_options() function for each argument, therefore the logic to reject the append flag on a PK was evaluated for other arguments. Move the append flag reject logic outside of the argument parser, since it only needs to be evaluated once anyway, after all arguments have been read.

While solving the above, I noticed that the positional format specifier argument parsing logic was fairly... lacking. It led to some confusing error messages, as the original test case was using the old -a 0 syntax for specifying the append header. The 0 was treated as a positional argument, and therefore was expected to be in the c:a format. Since it was not, it overwrote the previously valid c:a format specifier with NULLs, leading to an error in the format specifier, NOT in an unexpected argument.
The second commit addresses this, by adding some immediate enforcement of the format specifier, returning an error if it does not fit, or if another positional argument is supplied.

Updated:

re-added the check
added test cases to hopefully catch these in the future
added a new commit that allows the test framework to more properly catch exits via SIGSEGV, SIGABRT, etc


Chapter 5: unused but set variable

In one of the code snippets in chapter 5 there is this line of code (page 18, Version 1.54):
vec3 p = r.point_at_parameter(2.0);

There is a write to variable p  but no read. It is an unused variable. Delete this code line!

Duplicate of #14


The height of the panel should automatically expand

Should have the same behaviour as the current "Open Editors" panel.
But is not implementable at the moment:

[x] https://github.com/microsoft/vscode/issues/122283

The old linked was not completely settled. Here is the new one:

[ ] https://github.com/microsoft/vscode/issues/163043


Dropdown menu :smile: :rocket:

Simple dropdown menu
Demo html page dropdown

@1fabiopereira Thanks for that work.
Please submit it to the enhancement branch so I can test it.

OK ! already put in the correct place, excuse my lack of attention


[PDI-12593] SFTP Target Directory with Variables

Use KettleVFS for the target file in SFTP Get job entry, so that target files that use variables in the path are parsed correctly

@matthewtckr, your changes seem to fix PDI-12891 as well. I implemented the same approach, but haven't written test yet (postponed it until tomorrow). I can grab your changes or wait until this PR is merged - what do you prefer?

@akhayrutdinov I'm not sure how exactly to unit test this without adding dependencies or refactoring the SFTPClient constructor and other several downstream classes that make use of SFTPClient.  I was crossing my fingers hoping that you'd have a good unit test example that I could use here.
If this is affecting the FTPS and SFTP classes, I'll have to investigate later whether this same issue occurs in other FTP/SFTP job entries, and open additional JIRAs as appropriate.

@akhayrutdinov Thanks again for the integration test.  I've incorporated and squashed the commits together for this pull request.


Implement DiscoverClasses()

Discovers existing classes from the resctrl filesystem. Supports
discovering classes with a different prefix than the control interface
was initialized with. Monitoring groups still retain the original prefix
given at initialization time. This makes it possible discover and use a
configuration created/managed by some other tooling while still managing
monitoring groups isolated in a namespaced manner.
Depends on #20

Codecov Report

Merging #21 (261ee59) into main (82f290c) will increase coverage by 0.08%.
The diff coverage is 75.67%.

@@            Coverage Diff             @@
##             main      #21      +/-   ##
==========================================
+ Coverage   77.64%   77.73%   +0.08%
==========================================
  Files           6        6
  Lines         926      952      +26
==========================================
+ Hits          719      740      +21
- Misses        138      141       +3
- Partials       69       71       +2

Impacted Files
Coverage Δ

pkg/rdt/rdt.go
66.32% <75.67%> (+1.38%)
:arrow_up:

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 82f290c...261ee59. Read the comment docs.


Allow for out-of-source-tree build

Requires: https://github.com/space-wizards/RobustToolbox/pull/3408
Allows for the build prefix to be changed (redirecting all the the bin and obj directories).
For additional details see PR on SS14: space-wizards/space-station-14#13355
I suppose I'll leave this PR as a draft until the RobustToolbox PR is accepted and this repo is updated to use a version including it.

Oh hey, this likely fixes an error I've been getting with the debugger/doing stuff in a workspace. Nice.


Slate interface in 0.40.0 change removes selection.startKey

The latest slate change removes the selection.startKey value and replaced with selection.start.key
The util function isSelectionInTable (and several others) will always return False. This was deprecated in 0.37.0 and removed in 0.40.0
https://github.com/ianstormtaylor/slate/blob/master/packages/slate/Changelog.md

There is a long list of deprecations that were removed, startKey is just the one that was most visible. I downgraded Slate to version 0.39.0 and the table plugin works as expected.

I also encountered the same problem, I hope the author can find time to solve

See https://github.com/GitbookIO/slate-edit-table/pull/88/files#diff-04c6e90faac2675aa89e2176d2eec7d8

Indeed we're currently focusing our efforts elsewhere. We are taking a break with upgrading Slate versions until we resolve our more urgent matters, sorry about that. Thank you @CameronAckermanSEL for suggesting this alternative


GEODE-8759: Update Redis documentation to reflect current unsupported…

… command state

[X ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ X] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ X] Is your initial contribution a single, squashed commit?

[ X] Does gradlew build run cleanly?

Make sure INFO and HSTRLEN commands are listed in the "Unsupported" section of the documentation and not the "Unimplemented" section. A few minor alphabetization tweaks.

@ringles Please could you rebase this PR instead of merging develop in. It's showing a bunch of non-related commits and probably not running through CI because of conflicts.

Correct git rebase error, discard PR.


Rancher OS stopped working after upgrading to v1.4.0 from v1.2.0

RancherOS Version: (ros os version)
v1.2.0
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
AWS(ECS Enabled AMI)
I just ugraded with sudo ros os upgrade to update to v1.4.0 and instance kept failing to reboot. I couldn't even get logs from the instance on AWS management console.
I created another EC2 instance(and EBS volume), and to make my services work again, I copied files used in my docker containers from older EBS volume.
EDIT:
I've tried the same thing with another instance and version 1.3.0 instead of 1.4.0. This time, the instance booted successfully.
I then upgraded RancherOS to v1.4.0 from v1.3.0, and got the same problem. It seems that this problem is only present on v1.4.0.
I have been using t2.micro instance type, which has 1GB of RAM. Is this relevant?

We added more features in 1.4, which caused it to need more memory when booting up.
For aws, t2.small is needed.

But t2.small would be overkill for our use case. Should I stick to v1.3.0 for now? Or would it be possible to configure RancherOS to use swap, so that it can complete booting with only 1GB of RAM?
Will memory usage go down in future releases?
I'd like to know why RancherOS refused to write something to system log. I could get error messages from system log when I tried the same with t2.nano and Rancher OS v1.2.0.

I think it would be better to mention memory requirement change somewhere. If I could get warning before upgrading with commands, that would be much better.
Isn't there easy way to rollback when upgrading fails? I created another instance to solve this, because I couldn't even SSH into it.
I should have created EBS snapshot for rollback, though.

Current memory requirements are mentioned here: https://rancher.com/docs/os/v1.x/en/#hardware-requirements

I hope this to be resolved in v1.5.0.
https://github.com/rancher/os/issues/2392


Middleware for Auth

is there any middleware on router to check on every API call if this user logged in or not?

Yes, use passport.authenticate('jwt') as a middleware. If user is not authenticated it will not allow him to access the route and send 401 status code. If he is, it will give you also the req.user to get his data. To pass the authentication the JWT token must be in header named authorization.
Example of route
auth.get('/test', passport.authenticate('jwt') , (req, res) => {   res.status(200).json({ message: 'Only authenticated user can see this message', auth: req.isAuthenticated(), user: req.user }) })


"RNCWebView" was not found in the UIManager

Bug description:
I am very badly struck in react-native-webview linking. Where I have ended up in this particular issue which is again very common issue and already reported in this forum. But the solution doesn't work in my case.
To Reproduce:
I followed this documentation (https://github.com/react-native-webview/react-native-webview/blob/master/docs/Getting-Started.md#2-link-native-dependencies) and properly setup.
Expected behavior:
Given source page without error
Screenshots/Videos:

Environment:
I am getting this issue in android.

OS:
OS version:
react-native version: "~0.63.4",
react-native-webview version: "^11.2.3",

@software3daerospace  were you able to fix this?

you need to reinstall your on the device or emulator after running npm install --save react-native-webview so that it has the new native code. I can't believe no one helped you with this.


BUG, VIZ saving an animated topomap fails

import mne
path = mne.datasets.kiloword.data_path()
fname = path + '/kword_metadata-epo.fif'
evoked = mne.read_epochs(fname).average()
fig, anim = evoked.animate_topomap()
anim.save("topo.gif")

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/jona/miniconda3/lib/python3.6/site-packages/matplotlib/animation.py", line 1174, in save
    writer.grab_frame(**savefig_kwargs)
  File "/Users/jona/miniconda3/lib/python3.6/contextlib.py", line 99, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Users/jona/miniconda3/lib/python3.6/site-packages/matplotlib/animation.py", line 232, in saving
    self.finish()
  File "/Users/jona/miniconda3/lib/python3.6/site-packages/matplotlib/animation.py", line 358, in finish
    self.cleanup()
  File "/Users/jona/miniconda3/lib/python3.6/site-packages/matplotlib/animation.py", line 395, in cleanup
    out, err = self._proc.communicate()
  File "/Users/jona/miniconda3/lib/python3.6/subprocess.py", line 863, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/Users/jona/miniconda3/lib/python3.6/subprocess.py", line 1525, in _communicate
    selector.register(self.stdout, selectors.EVENT_READ)
  File "/Users/jona/miniconda3/lib/python3.6/selectors.py", line 351, in register
    key = super().register(fileobj, events, data)
  File "/Users/jona/miniconda3/lib/python3.6/selectors.py", line 237, in register
    key = SelectorKey(fileobj, self._fileobj_lookup(fileobj), events, data)
  File "/Users/jona/miniconda3/lib/python3.6/selectors.py", line 224, in _fileobj_lookup
    return _fileobj_to_fd(fileobj)
  File "/Users/jona/miniconda3/lib/python3.6/selectors.py", line 39, in _fileobj_to_fd
    "{!r}".format(fileobj)) from None
ValueError: Invalid file object: <_io.BufferedReader name=18>

Same in notebook, ipython, REPL.

This looks like a matplotlib bug, can you see if you can replicate with a simple mpl snippet instead?

You mean manually creating an animation where I loop over time steps for a topomap?

No not even a topomap, a script with only plt calls (nothing from MNE). In other words, can you get any matplotlib animation to save? Is the problem specific to MNE topomaps, or are all mpl animation saves broken for you?

Oh no, I can in principle save animations with matplotlib's animation functionality.

Okay so we do something with our plotting that does not work for them then. The question is what is it? The traceback you pasted has only matplotlib in the traceback so I'm not sure how best to debug.
FWIW this works on my machine (modified to use a smaller time snippet so it does not take forever):
import mne
path = mne.datasets.kiloword.data_path()
fname = path + '/kword_metadata-epo.fif'
evoked = mne.read_epochs(fname).average()
evoked.crop(0, 0.1)
fig, anim = evoked.animate_topomap()
anim.save("topo.gif")

I get:

But I get this message:
MovieWriter ffmpeg unavailable; trying to use <class 'matplotlib.animation.PillowWriter'> instead.

So maybe it's a matplotlib corner case bug where MNE code is used with the ffmpeg writer?

It works for me if I use writer='imagemagick' in the save call - and that seems to be the case universally. So not MNE related.


What happened to metrics-runtime?

This is not really an issue but I cannot use discord as it asks me for a mobile phone number to confirm my account.
What happened to the sources for https://docs.rs/metrics-runtime/0.13.1/metrics_runtime/ ?
I'd like to use the log exporter but cannot find it in this repo. Trying to find the latest version so I can use it in my cargo.toml, but seems it has been abandoned?
Thanks

They still exist in this repository, under tags for the specific release.  For example, version 0.13.1 of metrics-runtime has a corresponding tag in the repository called metrics-runtime-v0.13.1.
At a higher level: yes, metrics-runtime is abandoned.  Users are encouraged to use or switch to metrics where possible, although metrics-exporter-log is also abandoned so there's no direct path to switch in your case.

Any particular reason for it to be abandoned? Or just because not enough people use it? Or maintainers don't use it so they don't want to maintain it?
Thanks


Using VLLM with a Tesla T4 on SageMaker Studio (ml.g4dn.xlarge instance)

Hi everyone. I'm trying to use vLLM using a T4, but I'm facing some problems.
I'm trying to run Mistral models using vllm 0.2.1
With the following code, I receive a ValueError: Bfloat16 is only supported on GPUs with compute capability of at least 8.0. Your Tesla T4 GPU has compute capability 7.5.
from vllm import LLM, SamplingParams

prompts = [
    "Hello, my name is",
    "The president of the United States is",
    "The capital of France is",
    "The future of AI is",
]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)

llm = LLM(model="TheBloke/Mistral-7B-Instruct-v0.1-AWQ", quantization='awq', dtype='bfloat16', gpu_memory_utilization=0.5)

If I use another dtype or remove the quantization parameter, I get an OOM error.

You should use 'half' or 'float16' dtype, since T4 doesn't support 'bfloat16'.

I get na OOM error by either using half or float16

Hey @esmeetu, I tried to run the following code using half
llm = LLM(model="TheBloke/Mistral-7B-Instruct-v0.1-AWQ", dtype='half', gpu_memory_utilization=.95)

And I received the following error: KeyError: 'model.layers.0.mlp.down_proj.qweight'

@paulovasconcellos-hotmart Add quantization parameter in your code.

I ran with quantization parameter and max_model_len and it worked!
llm = LLM(model="TheBloke/Mistral-7B-Instruct-v0.1-AWQ", quantization='awq', dtype='half', gpu_memory_utilization=.95, max_model_len=8192)
Do you think I can increase max_model_len when using a T4?

@paulovasconcellos-hotmart Of course, you can increase that param gradually until you got oom error, finally you will know how much model length your T4 can support.

I try to do nearly the same and always get CUDA memory errors.
python -m vllm.entrypoints.openai.api_server --model TheBloke/dolphin-2.1-mistral-7B-AWQ --tensor-parallel-size 1 --dtype half --gpu-memory-utilization .95

run  from git-installation or as docker has the same result:
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 224.00 MiB (GPU 0; 7.79 GiB total capacity; 7.37 GiB already allocated; 79.81 MiB free; 7.38 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF

the machine has 4 x 3070 8GB, UBU 20.04
I also tried with and without tensor-parallel-size 1/2, no avail.

I'm having an issue running the openai-mock server on colab (ngrok tunneled to a public url).
It just keeps loading without actually deploying the server.


PDBs not overwriting function recognizer functions

Functions that begin with j_ are named during auto analysis when they are simple jump wrappers around other functions. Currently the PDB parser is not checking whether existing symbols are AUTO type or not resulting in these functions not being properly renamed when the PDB information is loaded.

For a reproduction, see attached sample at offset 0x140004c0a after loading the PDB.
sample.zip

Fixed 2.2.2517


Installing deb, broken link to readme.

When installing deb package on Ubuntu, package manager gives link to website which points to this broken readme link.

Thanks.


colab training error !

all other scripts works fine but i get an error when runing training
python -m scripts.finetune_diffusion --pretrained_model_name_or_path=stabilityai/stable-diffusion-2-depth --instance_data_dir=images/teapot_processed --instance_prompt="a photo of a teapot" --lr_warmup_steps=0 --max_train_steps=10000 --scale_lr --output_dir tuned_models/teapot_model --eval_path=configs/texture_transfer/eval_data.json
/content/TEXTurePaper/scripts/finetune_diffusion.py:16: FutureWarning: Importing DiffusionPipeline or ImagePipelineOutput from diffusers.pipeline_utils is deprecated. Please import from diffusers.pipelines.pipeline_utils instead.
from diffusers.pipeline_utils import ImagePipelineOutput
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "/content/TEXTurePaper/scripts/finetune_diffusion.py", line 930, in
main(args)
File "/content/TEXTurePaper/scripts/finetune_diffusion.py", line 493, in main
accelerator = Accelerator(
File "/usr/local/lib/python3.10/dist-packages/accelerate/accelerator.py", line 382, in init
trackers = filter_trackers(log_with, self.logging_dir)
File "/usr/local/lib/python3.10/dist-packages/accelerate/tracking.py", line 736, in filter_trackers
raise ValueError(
ValueError: Logging with tensorboard requires a logging_dir to be passed in.

You can see that the raised error is specifically from the accelerator initialization, try to specify a logging sir or remove the log_with option


[Feature Request]: Translations and date format for different cultures in date picker

Requirements before reporting

[X] No duplicated issue reported
[X] I have checked the latest version if the feature exist there

Type of feature request
Functionality
What is your feature request?
The text that appears on the date picker to have support for translations. Also the format of the date to be adapted to different styles depending on the culture.

Background
We have customers in different countries and all the labels in our application have translations depending on their country. It would be good to also have these date picker have translations.
Idea
Maybe add a property for culture.
Goals and objectives
Have the texts in the date picker translated in different languages. Have the date format adapted to different cultures.
Timeline
It's not urgent, but a nice feature to have.
Resources
No response
Contact information
<EMAIL_ADDRESS>

Hi @cristinaneculita, unfortunately, this is not under our control. It depends on the regional and language settings of user's operating system and browser.


Strong Lens systems: lenspop, lensed SNe

@dannygoldstein @tcollett What's the plan for making the strong lens systems for DC2? In Twinkles the sprinkler worked by finding a CatSim galaxy and then turning that into a background source galaxy, replacing it in the instance catalog by 2 or 4 images of itself, arranged around a suitable lens galaxy. If you are given a source galaxy redshift, can lenspop generate plausible values for all the rest of the system's parameters? What about the lensed SNe - any issues with predicting them?
@danielsf Is it possible/straightforward to realize the exact same supernova in 2 or 4 places, with different peak times?

Can one of you capture this discussion in the planning document?
Probably in Section 5 under CatSim and maybe under remaining tasks? Thanks!
On 11/13/17 11:15 AM, danielsf wrote:

@drphilmarshall https://github.com/drphilmarshall It should be
possible to do what you describe. It will take a few days of work. The
supernova simulations are a little more complicated than other
simulations because we actually have a time-varying SED model for the
supernovae. Either @rbiswas4 https://github.com/rbiswas4 or I could
do what you ask pretty easily.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LSSTDESC/DC2_Repo/issues/40#issuecomment-343989961,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMQ9jLNWKCbb9fYQQ4Tp0ljEy2kVs5drks5s2HlGgaJpZM4QbWEh.

Scott, would you mind takin g care if this please? You should add your name
to then author list too, last time I looked Chris was looking pretty lonely
:-) Thanks!
On Nov 13, 2017 09:22, "Katrin Heitmann"<EMAIL_ADDRESS>wrote:

Can one of you capture this discussion in the planning document?
Probably in Section 5 under CatSim and maybe under remaining tasks? Thanks!
On 11/13/17 11:15 AM, danielsf wrote:

@drphilmarshall https://github.com/drphilmarshall It should be
possible to do what you describe. It will take a few days of work. The
supernova simulations are a little more complicated than other
simulations because we actually have a time-varying SED model for the
supernovae. Either @rbiswas4 https://github.com/rbiswas4 or I could
do what you ask pretty easily.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LSSTDESC/DC2_Repo/issues/40#issuecomment-343989961,

or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AMQ9jLNWKCbb9fYQQ4Tp0ljEy2kVs5drks5s2HlGgaJpZM4QbWEh>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LSSTDESC/DC2_Repo/issues/40#issuecomment-343992107,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArY9xYvza33bQ-MmDfZ61Qbe8jtV8Zzks5s2HrhgaJpZM4QbWEh
.

Sure thing

What are the constraints we must obey in this process?
Can we only use galaxies generated by CatSim (and move them around), or can we generate galaxies after CatSim is run and place them into images?  E.g., can we  pre-select lens galaxies generated by catsim (ellipticals) and then plant source galaxies behind them drawn from the galaxy redshift distribution truncated at the lens redshift (not generated by catsim, but added in after the fact).
Once the source and lens galaxies are in place it is easy to generate the glSNe. Host galaxy location is drawn from the host galaxy surface brightness profile, and the SN parameters (mainly absolute magnitude, but we can also put in parameters like x1 and c governing SN Ia diversity if desired) can be drawn from measure distributions that can be optionally conditioned on host galaxy type

You can inject new galaxies into the simulations.  Doing that while taking CatSim galaxies (if you wanted to preserve the number of galaxies in the simulation) is harder, but also possible.  This sounds a lot like the work @jbkalmbach did on the Twinkles sprinkler.  I recommend talking to him about how generalizable the sprinkler is (i.e. can it be connected to a different population of sources than just the OM10 lens catalog).

Thanks Scott - if we inject new galaxies into the simulation, will that affect our ability to apply weak lensing shear and convergence as described in #2 ?
Danny

Ah.  Yes, that probably would be more difficult.  As I understand it, we will just have lensing parameters sampled at the sites of galaxies already existing in the catalog.  If you put a galaxy where one did not exist before, we would have to come up with some kind of interpolation scheme, assuming that was a valid thing to do, which I'm not sure it is.  The safest bet if you want to make use of the lensing shear maps coming out of the Cosmological Simulations group is to replace existing galaxies with your lensed systems.

Related to that question, if we injected new galaxies into the images, what information would we have to supply -- just observational parameters like sersic n, R_E, brightness, etc., or physical parameters such as masses?

Observational parameters would be enough.
The parameters expected by PhoSim are documented here
https://bitbucket.org/phosim/phosim_release/wiki/Instance Catalog
If you don't have exactly what PhoSim expects, it is pretty easy within CatSim to calculate parameters on-the-fly using parameters that you do have.

@danielsf, @dannygoldstein: Regarding shear, we are already using an interpolation scheme to put shears at any given point. So this is not really that much extra work --.

@salmanhabib Is the code and data supporting that interpolation (or, at least, its API) publicly available somewhere so that we can write something in CatSim that calls it?

@danielsf Not right now, but we could certainly do that.

@jbkalmbach can you give us a sense of the current status of the sprinkler and what would need to be done to connect it to a non-OM10 catalog?
Danny Goldstein
http://astro.berkeley.edu/~dgold

From: Salman Habib<EMAIL_ADDRESS>Sent: Monday, November 13, 2017 3:09:35 PM
To: LSSTDESC/DC2_Repo
Cc: Danny Goldstein; Mention
Subject: Re: [LSSTDESC/DC2_Repo] Strong Lens systems: lenspop, lensed SNe (#40)
@danielsfhttps://github.com/danielsf Not right now, but we could certainly do that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/LSSTDESC/DC2_Repo/issues/40#issuecomment-344090389, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACpC4DiBsDOPB6hcS7wOp2XnrM_rrFafks5s2MwugaJpZM4QbWEh.

One small comment: by following the Twinkles approach to sprinkling and
matching CatSim galaxies to lenspop  sources (rather than
lenses/deflectors) I think the weak lensing effects provided will be more
meaningful. Still only as accurate as the external shear / convergence
approximation (rather than a full multi-plane ray tracing) but maybe good
enough for some interesting tests? If you inject galaxies at some new
redshift you'd need to interpolate the shear and convergence to that
redshift as well as that position - and if you match the deflectors, you
won't capture the weak lensing effect of mass structure behind the lens.

Hey Bryce, what's your take on adapting the Sprinkler to a non-OM10
catalog? I guess as long as the required columns are there, its just some
plumbing to read the new file, right? Great if you can post a link to the
relevant notebook that shows the Sprinkler in action, for the SL leads to
take a look at. Thanks!

Hi all, sorry about the delay in responding. Yeah, plugging in a new catalog should be no problem. There is an optional parameter in the sprinkler to plug in your own catalog file:
class sprinkler():
    def __init__(self, catsim_cat, om10_cat='twinkles_lenses_v2.fits',
                 density_param=1.):

As long as it is formatted similar to OM10 it should be fine.

@jbkalmbach and @drphilmarshall Is this still outstanding?

I think we have done everything we are going to do on this issue for DC2.  I do not believe we have tried running a non-OM10 catalog through the sprinkler.  If that is still of interest, it should probably be its own issue in the Twinkles repo.


Fix in-memory databases on android

Proposed fix for Issue #157
I was not able to test this on iOS: The new unit tests might fail there.

Awesome Thanks for the PR!

Merged and published into 2.6.1


Docstring lint change

Remove D202, D204 from ignored linting codes & relint the repository
Closes #199

This has been synced to master and opened for review in advance of the upcoming Pride season.
Existing PRs will need to be relinted when updated for current review comments.

Updated to address pre-commit's misconfiguration resulting in it not actually using any of our flake8 plugins.
Fix null bytes error with the .snakes draw command. Closes #218


[Add]: LeetCode Problems 2400 - 2499

@Ajay-Dhangar can i work on this?

@Ajay-Dhangar submitted PR.


JDK1.8 json format

Follow up issue  : https://github.com/orientechnologies/orientdb/pull/2983
create function toJSON,
toJSON :

try {
return JSON.parse("{"@rid":"#51:2051"}");
} catch(e) {
}

Runing under JDK1.7
[
{
"@rid": "#51:2051"
}
]
Runing under JDK1.8
[
{
"@type": "d",
"@version": 0,
"value": {
"@rid": "#51:2051"
}
}
]

Please can we get this reopened or a new ticket created to implement luigis proposals.

I like the "same for all results" approach - keeping things consistent between results with regards to the envelope makes it easier for developers to understand/diagnose/inspect values.

Luigi's proposal gives developers the option for implementing whatever response structure you like. The existing envelop approach does not and also creates major and un resolvable inconsitencies between functions which return db.queries and functions which return custom built lists.

In order to minimise back compatability issues, can we add a flag on Ofunction to signal how to serialise the function response. if this flag is missing then the old style is used, if the flag is there then the new style should be used. We could also havea global default properties as to whether new functions should use this flag by default, and also whether or not it should forced on existing functions as well.

I was trying my hand at javascript functions in orient and let me just say I am majorly disappointed. I want to do something simple like load some results and inspect their properties. I can't figure out how to do that. It appears that if I look at a record in the JS function it's completely empty. However if I return it from the function it's all filled out with data, WTF?  Also in the Studio testing functions that do things like queries across edges I don't get anything back, yet calling the same function with the same param on the rest api I get data, WTF? Consistency would be nice, but it seems you are consistent about one thing, being inconsistent.

@optimuspaul it's hard to help you without any example... Could you provide what is working via REST and not in Studio? Something I can copy & paste on an empty db.

@lvca of course you are right. Here is an example:
I have two vertex classes, eos_object and eos_fingerprint.
make some stuff
create vertex eos_object content {"uid": "2424"}
create vertex eos_fingerprint content {"fingerprint": "aaa"}
create edge E from #12:4 to #13:5  --- of course make those id's match yours.

I have a function object_ping, with one parameter fingerprint
var gdb = orient.getGraph();
try {
  return gdb.command("sql", 'select uid, @rid as rid, out(eos_fingerprint).@rid as out_rid, out(eos_fingerprint).fingerprint as fingerprint from eos_object where out(eos_fingerprint)[fingerprint] IN ?', [fingerprint]);
} catch(e) {
  return {"status": "ERROR", "error": e.toString()};
}

in the studio, on the function page, when I test the function with "aaa" as the fingerprint to check I get 0 results. But on the rest API I get:
{
"result": [
{
"@type": "d",
"@rid": "#-2:0",
"@version": 0,
"uid": "2424",
"rid": "#12:4",
"out_rid": [
"#13:5"
],
"fingerprint": [
"aaa"
],
"@fieldTypes": "rid=x,out_rid=z"
}
]
}

When I run select object_ping("aaa") in the browse tab I do get:
[{"@type":"d","@rid":"#-2:0","@version":0,"uid":"2424","rid":"#12:4","out_rid":["#13:5"],"fingerprint":["aaa"],"@fieldTypes":"rid=x,out_rid=z"}]

Which does't seem quite right, is that json? Why didn't it make it look like other results?


Beginning with version 2.7 of [Bug Report], Cascader cascade selector dynamically loads data, and data is not rendered, as is the case with official examples.

Element UI version
2.8.2
OS/Browsers version
mac 10.14.4/chrome 74.0.3729.131
Vue version
2.6.10
Reproduction Link
https://codepen.io/keep2zero/pen/RmReVO
Steps to reproduce
查看 动态加载次级选项
What is Expected?
数据动态渲染
What is actually happening?
不渲染数据

cc @Leopoldthecoder 官网的文档貌似没有更新，本地运行看到的文档已经没有这个问题了。


Change puzzle

since its solution is already shown. Or hide the solution. https://learn.scrypt.io/en/courses/Build-a-Tic-tac-toe-Game-with-sCrypt-614c387bc0974f55df5af1e5/lessons/2/chapters/2

Also add comments
signer.getBalance().then(balance =>
  // UTXOs belonging to transactions in the mempool are unconfirmed
  setBalance(balance.confirmed + balance.unconfirmed)
);

Update now we have two keys.

https://learn.scrypt.io/en/courses/Build-a-Tic-tac-toe-Game-with-sCrypt-614c387bc0974f55df5af1e5/lessons/2/chapters/4


[Enhancement] backoff routine load job scheduling when all kafka brokers are down

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:disappointed: fail : 0 / 11 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/runtime/routine_load/data_consumer.cpp
0
2
00.00%
[339, 342]

:large_blue_circle:
src/runtime/routine_load/data_consumer.h
0
9
00.00%
[92, 93, 121, 122, 133, 134, 135, 136, 171]

[FE Incremental Coverage Report]
:disappointed: fail : 18 / 50 (36.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/common/KafkaAllBrokersDownException.java
0
2
00.00%
[42, 43]

:large_blue_circle:
com/starrocks/load/routineload/RoutineLoadTaskScheduler.java
4
12
33.33%
[208, 209, 210, 211, 401, 402, 406, 408]

:large_blue_circle:
com/starrocks/common/util/KafkaUtil.java
13
35
37.14%
[185, 186, 187, 188, 189, 192, 193, 195, 198, 214, 221, 223, 225, 230, 231, 232, 233, 235, 236, 238, 239, 242]

:large_blue_circle:
com/starrocks/common/Config.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:disappointed: fail : 0 / 4 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/runtime/routine_load/data_consumer.cpp
0
4
00.00%
[319, 350, 362, 398]

@mergifyio rebase

[BE Incremental Coverage Report]
:disappointed: fail : 0 / 4 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/runtime/routine_load/data_consumer.cpp
0
4
00.00%
[319, 350, 362, 398]

[BE Incremental Coverage Report]
:disappointed: fail : 0 / 4 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/runtime/routine_load/data_consumer.cpp
0
4
00.00%
[319, 350, 362, 398]

[FE Incremental Coverage Report]
:disappointed: fail : 5 / 20 (25.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/common/util/KafkaUtil.java
0
5
00.00%
[235, 236, 237, 249, 250]

:large_blue_circle:
com/starrocks/common/KafkaAllBrokersDownException.java
0
2
00.00%
[19, 20]

:large_blue_circle:
com/starrocks/load/routineload/RoutineLoadTaskScheduler.java
4
12
33.33%
[208, 209, 210, 211, 401, 402, 406, 408]

:large_blue_circle:
com/starrocks/common/Config.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:disappointed: fail : 0 / 4 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/runtime/routine_load/data_consumer.cpp
0
4
00.00%
[319, 350, 362, 398]


Removed ^ from package.json to not get errors on test, dist updated

Added build, fixed package json with exact version

Thanks again, I don't know why I've not pushed the build version on the update. Busy day @work :D
I want to check the new true version to update the test, but for now it's better to fix the version.


geryed out a screenshot

I have now made some changes to the md file. please push the changes now to test if the images are updated. thank you.


Allow partial consolidation of nodes with blocking PDBs

Description
What problem are you trying to solve?
We run clusters with relatively large nodes (~100 pods), significant autoscaling of deployments, and some slow pod start up/termination times.
After we update a Nodepool we monitor the status of the nodes and wait for all drifted nodes to be replaced as part of our continuous delivery (CD) pipeline.  This makes the speed Karpenter removes drifted nodes from our clusters significant as it can block our CD pipelines for long periods of time.
Currently Karpenter will only consolidate a drifted node if all the pods are evictable (no PDBs are blocking) (source).
Karpenter also runs one disruption command at a time which can lead to the duration between drift reconciliations being many minutes.
This often results in a situation where Karpenter checks too infrequently and the odds of a single PDB blocking consolidation are so high that it takes many hours for large nodes to be valid consolidation candidates.  It would be preferable for us if we could drain all the pods which are currently evictable and then wait for PDBs to allow the eviction of the remaining pods.
This will require changes to the API to configure this.  The sensible place would be adding it to the disruption section of the NodePool spec keeping it in line with the Disruption Controls design.
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    evictionPolicy: FullNodeOnly || BestEffort  # FullNodeOnly requires all pods to be evictable

How important is this feature to you?
We currently have a hacky work-a-round where we kubectl drain drifted nodes as kubectl drain does evicts pods as they become evictable.  We would prefer a proper implementation in the controller.
I am interested on working on this if there is agreement the feature is useful and we can agree on the API.

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

I think this ties into some of the discussion that's been taking place in #1047. I definitely see the use case here and think this falls under a broader story we've been discussing: ensuring cluster operators have mechanisms to disrupt nodes regardless of pod level configuration (PDBs, the karpenter.sh/do-not-disrupt annotation, etc).
Making sure I understand your use case, you want drifted nodes to be immediately eligible to begin draining. The drain should occur without violating PDBs. It is acceptable for nodes to remain on the cluster partially drained for an indefinite period of time to ensure this. Does this sound about right?
I want to draw particular attention to that last point, it being acceptable for nodes to remain partially drained indefinitely. This has been something we've been hesitant to enable, hence the current behavior where we wait until we know the node can be disrupted successfully. One option I posed over in #1047 is enabling this immediate drain behavior if and only if the corresponding NodeClaim had a terminationGracePeriod set (#834). This would ensure that we don't get in a state where a node can be draining indefinitely since the terminationGracePeriod sets an upper bound on node lifetime once the drain begins. Does something like this address your use case or is it important for PDBs to never be violated, even if this could result in partially drained nodes remaining on the cluster indefinitely?

Thanks for the response Jason,

Making sure I understand your use case, you want drifted nodes to be immediately eligible to begin draining. The drain should occur without violating PDBs. It is acceptable for nodes to remain on the cluster partially drained for an indefinite period of time to ensure this. Does this sound about right?

Yeah, this is correct.

Does something like this address your use case or is it important for PDBs to never be violated, even if this could result in partially drained nodes remaining on the cluster indefinitely?

It is important for us that PDBs are never violated.  We are happy with nodes left in a partially drained state indefinitely.  We have alerting which will highlight this to us so that we can investigate why the PDB is blocking the full drain.
We could theoretically set the terminationGracePeriod to a very large duration to give us plenty of time to investigate manually but would prefer an option where a forced termination was never a possibility.

It is important for us that PDBs are never violated. We are happy with nodes left in a partially drained state indefinitely. We have alerting which will highlight this to us so that we can investigate why the PDB is blocking the full drain

I'm actually curious if #623 would help you as well here and if you even need a disruptionToleration? In reality, the disruption toleration duration is there to force removal of nodes by a given time, but it sound like you do still want some form of graceful termination, so you are really looking for us to stop scheduling pods (or at least weigh-away from scheduling to the nodes that are drifted). FWIW, if we go with the PreferNoSchedule taint here (which is what we are leaning toward), I'm not sure how much this will help if your entire NodePool gets drifted at once, since all nodes will be treated the same.

Karpenter also runs one disruption command at a time which can lead to the duration between drift reconciliations being many minutes

Which version are you running? With the changes introduced in v0.34.0, this should no longer be the case. We should be able to run at a much higher parallelism and you should see us react much quicker to drift events. Have you tried the disruption budget changes? Do you think that these changes might help mitigate your existing problem?


Design Meeting Notes, 9/25/2020

Object Spreads and Union Types
https://github.com/microsoft/TypeScript/issues/40754
https://github.com/microsoft/TypeScript/pull/40755

One set of users: have been working with long builds, throw 8GB at it

Recent change: more gigs, compilation "seems to never terminate".

They have a huge object type written like
const cssProps = {
    ...{yadda && {
        backgroundColor: "...",
        color: "...",
        // ...
    }}
    // ... 100 more of these
}

This ends up creating a MASSIVE union type based on making a conditional property.

The users don't want a union, they just want a big old blob of optional properties.

We could just "recognize the pattern" and provide a "weaker" type (i.e. one type with lots of optionals instead of a union where every other union member makes the property undefined).

In 3.8, we added this logic, but only for single-property objects. We were afraid to do this too broadly.

Other workarounds?

as CSSProperties
Some helper function.

Can we leverage a contextual type?

Well the heuristic can't just look and say "do I have a union?"

Some feel like we should just always do this.

Could also say that, when performing a spread, "do I have a conditional type where the property type is optional? If so, create an optional property."

One option might be to provide a quick fix to write the all-optional property object type when the expression is too complex.

Sounds like we always want to use the all-optional properties, but can't do that for 4.1.

Sounds like we also need a limiter for 4.1 though.

throw Types
https://github.com/microsoft/TypeScript/pull/40468

If a throw type "ever comes to pass", it becomes an error.
In principle, really like the idea to convey reasons of why conditional types didn't actually work.

"Signaling nevers, or nevers with a reason."

Issue: "if it ever gets evaluated" leaks implementation details of instantiation.

Our type system's instantiation semantics aren't strictly evaluated, but it's not always lazily evaluated either!

Basically non-strict is the best you can say.

Lots of places where instantiation can also be surprising (e.g. looking at constraints).

Surprising how well errors can be tied back to specific locations.

That's currentNode, we've had that for a while, works decently well.
Though could end up with instantiation anywhere, so...

Potential performance problem?

When you use these instead of never in the tail, you end up with more types.
Could potentially intern these though, not necessarily the biggest concern.

Would be ideal if this built on never, especially because of unioning semantics.

Sometimes you don't want that either.

It sounds like there are really two things:

a signaling never type
a signaling "poison" type

the anti-any

Conclusion: like the idea, not necessarily this as the future direction. Two potential directions of "signaling never" and  signaling "anti-any".

Conditional Assignability

[[Look how our type helpers look like parser combinators now.]]

But you can only trigger the inference on these type aliases for literals by writing them in call positions.

What if you could?
// Concept
type Digit = match S extends string =>
  S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;

Mental model:

When relating a type Foo to a Digit, S is bound to Foo, and is then related to that.
The relationship succeeds when the source matches the constraint (string) and the type then evaluates to true.
When used as a source type, the type is the constraint.

Out of time.

Code sample from @ahejlsberg
type Digit = match S extends string =>
    S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;

type Digits = match S extends string =>
    S extends `${Digit}${infer R}` ? R extends '' | Digits ? true : false : false;

type Decimal = match S extends string =>
    S extends `${'' | '+' | '-'}${Digits}` ? true
    S extends `${'' | '+' | '-'}${Digits}.${Digits}` ? true :
    false;

type Extent = match S extends string =>
    S extends `${Decimal}${'px' | 'pt'}` ? true : false;

One outer commentary to help the mental model on this one - for any type T, you can conceptually roll it up to
match S extends T => true

Again, this is just a concept. Not committed, syntax not tied down.

Conditional assignability can be already used for function parameters case.
declare enum digit { digit = '' }

type Digits = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

type Digit<D> = D extends Digits ? D : digit

declare function doSomethingWithDigit<D>(digit: Digit<D>): any

// OK
const a = doSomethingWithDigit('1')

// Argument of type '"a"' is not assignable to parameter of type 'digit'.ts(2345)
const b = doSomethingWithDigit('a')

It will be great to see this feature on the type level. But we also need to be able to handle cases when our type depends on another. So I suggest make this conditional types generic.
type LensKey<O extends Object> = match S extends string =>
   // Traversal case
  O extends ReadonlyArray<any> ? S extends '[]' ? true
    : S extends keyof O ? true : false

declare function getLens<O extends Object, K extends LensKey<O>> (obj: O, key: K): any

Would conditional assignability be a better place to surface 'throw types'?
The conditional assignability concept directly hooks into the definitions of type relations, so would this be a better place to add helpful information?
Every match type can have some doc string that is optionally used by the type-checker when the match expression evaluations to false. For example:
type NonZero = match N extends number => [N] extends [0] ? false : true
               reason `Non-zero number expected.`;

function checkedDivide(x: NonZero): number {
    if (x === 0) throw new Error('')
    return 5 / x
}

checkedDivide(0) // error. 0 is not assignable to NonZero: Non-zero number expected.

type Uncallable = match N extends never => false
                  reason `This function should never be called`

function dontCallMe(arg: Uncallable) { }

As an aside. What happens in this case?
type AntiAny = T extends never => false;
const x: AntiAny = undefined as any as AntiAny;

Looks like conditional assignability makes #17428 irrelevant, while also providing a way to partially (or even completely) solve #14400, which is very good news.

@Raiondesu this behaviour can be already done using plain TypeScript.
type Cast<X, Y> = X extends Y ? X : Y

declare const getValidator: <V>() => <U>(input: Cast<U, V>) => typeof input

interface Foo {
  bar: 'baz'
}

const validateFoo = getValidator<Foo>()

// OK
validateFoo({
  bar: 'baz',
  test: 1
})

// Error
validateFoo({
  baz: 'bar'
})

And you also can use enum declarations as named never type like here

declare enum digit { digit = '' }

type Digits = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

type Digit<D> = D extends Digits ? D : digit

declare function doSomethingWithDigit<D>(digit: Digit<D>): any

// OK
const a = doSomethingWithDigit('1')

// Argument of type '"a"' is not assignable to parameter of type 'digit'.ts(2345)
const b = doSomethingWithDigit('a')

But the main problem of such approach is parameters inference using infer keyword
// [digit: digit] or [digit: never] if you used never type
type P = Parameters<typeof doSomethingWithDigit>

Type P is absolutely useless here because you can not assign anything to this.
It can be solved by your suggested match syntax with types returned, but for non generic type cases only. Generic parameters will be still inferred as unknown. Thus, we come to the conclusion that the main problem here is not the syntax itself, but the lack of higher-order types.

@awerlogus, the behaviour you described in the first example is exactly what bothers people in #14400 (see last few comments there). This is undesirable boilerplate code that mangles libraries' APIs, and people rightfully complain about it.
I agree, however, with defining the core problem as a lack of HOTs (as more and more workarounds for them seem to pop-up in TS over time).
To some extent. As modifications to conditional assignability, that I proposed earlier, fix the problem of inference, because there are suddenly no captured generic types for TS to miss on inference if "conditional assignables" are used in their place.
The core problem I was trying to solve there was TSs inability to simply validate (not restrict!) and forward type information without capturing it in some sort of a generic parameter, which is, I think, the whole reason behind #17428 ("if TS can only do that using generics, let's make everything generic!").
So, naturally, conditionally assignable types immediately seemed to me like a simpler solution to this problem. Albeit, with slight modifications to the originally discussed functionality.
I do understand I might be overthinking this, but after all, if conditionally assignable types "already" capture the matched type (somehow, outside of generics) to validate it - why refuse to use it to the end anyway?

While I really like the concept of the conditional assignability, I think a major issue is how you match one against the other; i.e.:
type Digit = match S extends string =>
  S extends "0" | "1" | "2" | "3" | 4" | "5" | "6" | "7" | "8" | "9" ? true : false

type Bit = match S extends string =>
  S extends "0" | "1" ? true : false

type Test = Bit extends Digit ? true : false;

Unrelatedly, this would give us many advanced types:
type Complement<T> = match U extends any => U extends T ? false : true;
type StrictSubtype<T> = match U extends T => T extends U ? false : true;
type NonUnion<T = any> = match U extends T => IsUnion<U> extends true ? false : true;

type UniqueSymbol = StrictSubtype<symbol> & NonUnion<symbol>;

// Utility, works sans this change
type IsUnion<T> = (T extends any ? (x: (x: T) => T) => any : never) extends (x: infer U) => any ? U extends (x: any) => infer V ? [T] extends [V] ? true : false : false : false;

Looking at the digits example from Anders' snippet.

type Digit = match S extends string =>
   S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;
type Digits = match S extends string =>
   S extends `${Digit}${infer R}` ? R extends '' | Digits ? true : false : false;

And it leaves me thinking...
Without this syntax, users might solve this problem as follows.

Define a type which iterates over a string and gives us a boolean, representing whether the string is solely of digits.

type AreDigits<S extends string> = S extends `${infer C0}${infer CRest}`
  ? C0 extends  '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
    ? CRest extends ""
      ? true
      : AreDigits<CRest>
    : false
  : false;

Build up higher-level predicates.

type IsFloat<S extends string> = S extends `${infer L}.${infer T}`
  ? AreDigits<L> extends true
    ? AreDigits<T> extends true
      ? true
      : false
    : false
  : false;

// etc ...

... with this approach, we run into three issues:

We cannot recurse over strings which are greater than 16 chars in length.
The AreDigits and HasDecimal types aren't portable––aka., library developers can't let consumers supply their own predicates to library-exposed generic types.
Predicates can't be used within patterns.

I'm curious why the solution is new syntax, instead of solutions to those three sub-problems?
For instance:
type Src = "Hello 254.931";

type FloatPlaceholder = _<IsFloat>;

type MatchResult = Src extends `${infer L}${FloatPlaceholder}`
  ? Src extends `${L}${infer Float}`
    ? Float
    : never;
   : never;

declare const matchResult: MatchResult; // `"254.931"`

Here, the underscore is an intrinsic utility type, which accepts a boolean-returning generic type. The result can then be used within a pattern.
Seems this approach might take less effort to grok.
Then again, I'd imagine there are performance considerations of which this is lacking.
Still, I'd love to hear about why conditional assignability is the preferred route!

@harrysolovay ATM, they don't have any official HKT support (though I would love for them to add this). I think the approach they're considering taking is basically the same as yours, but with a syntactical approach rather than a utility type approach. With the syntactic appraoch, you could write type FloatPlaceholder = match S extends string => IsFloat<S>, and, with HKT support, you could also write the utility type (type _<T<U>> = match U extends any => T<U>).
While I definitely think they should add HKTs (which could "easily" be accomplished with a Call<TFunc, TParams> utility, like in Flow), IMO the conditional assignability is too complex / (different from everything else) to be magicked away in an intrinsic type.
Also, is there another issue for the conditional assignability that should be commented upon, rather than cluttering up these meeting notes?

Not sure if this conversation calls for another issue, or if it should exist in Discord, or when / if GitHub discussions will be enabled for this repo. Hopefully a TS team member can provide guidance as to what is the correct forum for this discussion. Until then, I doubt we're imposing by commenting here (although sorry if we are!).

While fully-fledged HKTs would be nice, that's not what I'm suggesting. Yes, it's similar in the sense that there's some deferred evaluation of generic types. Yet there's a more-specific way to satisfy this use case: the ability to turn a string-accepting, boolean-producing generic type into a pattern placeholder.
Even if we had this ability, conditional assignability may be more ergonomic and preferable.

While fully-fledged HKTs would be nice, that's not what I'm suggesting. Yes, it's similar in the sense that there's some deferred evaluation of generic types.

I don't think "deferred evaluation of generic types" actually has any meaning in typescript as it stands; you can't use generic types as types without supplying the type parameters.

Yet there's a more-specific way to satisfy this use case: the ability to turn a string-accepting, boolean-producing generic type into a pattern placeholder.

I don't think these were supposed to be limited to strings; I think that the use cases are just more obvious with strings.
Regardless, I think it would be a significant anti-pattern to have HKT-esque support for one specific built in utility type (or HKT support only for returning booleans). If they are resistant to adding general HKT support, it can be syntactic (as they've been discussing), similar to how they've implemented e.g. object maps.
I think I may be misunderstanding what you are suggesting; are you suggesting an alternative to conditional assignability, or an alternate syntax for it?

@tjjfvi thank you for pointing out that this is not limited to string literals.
I'm suggesting new syntax may not be necessary.
type Digit = match S extends string =>
  S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;

vs.
type IsDigit<S extends string> =
  S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;

type Digit = ConditionalAssignability<IsDigit>;

Users are already familiar with generic and conditional types. I'm curious why introducing new syntax is necessary? Why not just introduce an intrinsic utility type for turning a predicate such as IsDigit into its conditional-assignability counterpart?
On another note, I'd like to know more about what this means?:

But you can only trigger the inference on these type aliases for literals by writing them in call positions.

Does this mean that one cannot pass a conditional assignability to a generic type? Aka., is the following invalid?:
type Digit = match S extends string =>
  S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;

type MeetsConstraint<E, C> = E extends C ? "The constraint `C` is met!" : "No!";

type Result = MeetsConstraint<"1", Digit>; // expecting "The constraint `C` is met!"

If so, that would be unfortunate.

Another random thought on this proposal:
AFACT, the way this is written, conditionally assignable types could violate the "axiom" that if A is assignable to X and B is assignable to X, then A | B is assignable to X.
type IsUnion<T> = (T extends any ? (x: (x: T) => T) => any : never) extends (x: infer U) => any ? U extends (x: any) => infer V ? [T] extends [V] ? true : false : false : false;
type NonUnion<T = any> = match U extends T => IsUnion<U> extends true ? false : true;

type TestAssignablility<A, B> = A extends B ? true : false;

// Equivalent to `[true, true, false]`?
type Test = [TestAssignability<"A", NonUnion>, TestAssignability<"B", NonUnion>, TestAssignability<"A" | "B", NonUnion>];

Do any other types currently behave this way?

@DanielRosenwasser I'm sad to see that this issue has been closed. I don't mean to impose by asking, but I'm curious if/why the team isn't pursuing conditional assignability. To me, it seemed like an extraordinary feature that would open countless doors to future DXs.

@harrysolovay DanielRosenwasser just closed 49 design note issues, so I doubt it was anything specific.

Yeah, but also is this what you're looking for? #30639

@DanielRosenwasser No, I think they were referring to the "Conditional Assignability" mentioned in the design notes

// Concept
type Digit = match S extends string =>
  S extends '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' ? true : false;


disable.bind disables button but inner content is still clickable

When the disabled.bind condition is met, the button is not clickable but the  within the button still calls click.delegate when clicked.
<button disabled.bind="totalCount <= (currentPage * perPage)" click.delegate="nextPage()"></button>

Wondering if we need to add special handling for click and disabled here:
https://github.com/aurelia/binding/blob/master/src/event-manager.js#L6
Quick workaround is to use click.trigger instead of click.delegate in this case.

Thanks for the workaround.  Should the click.delegate one be an open issue?

Not sure- lets leave this open so @EisenbergEffect has a chance to look at it.

Also ran into this :)

:+1:

We'll add this to the documentation along with some other delegate vs trigger info that I've been tracking here

related to #263

@jdanyow Any thoughts on this?

only what I had mentioned here: https://github.com/aurelia/binding/issues/163#issuecomment-137216716

I think we could do this in a point release as well, do you agree?

yep

Any update on this? I'm having this issue and even using click.trigger won't solve the issue. Looks like the disabled property works well with button elements but not with labels or other inputs

@srfabio labels/other elements don't have a disabled state, only buttons, inputs, etc.
You could check for the condition in the function you execute instead

@sickboy Okay, but since I'm using bootstrap labels and inputs can also have a disabled property which should prevent events. The same code works well (jsfiddle) outside the aurelia application

Any ETA on this?

+1 for this, click.delegate still triggers a disabled button, even with text, latest version of Aurelia.

This is a really interesting problem. I'm currently working on handling this and related issues in a component library we're building, and its actually fairly complex. The disabled state is an especially  fun one, because not only should it prevent pointer events from reaching the disabled element or children of that element, but it should also affect which element has input focus.
Preventing pointer events
Preventing pointer events on disabled elements and their children is easy, at least in modern browsers.
All it takes is a single line of CSS:
[disabled] { pointer-events: none; }

https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
Of course, this assumes Aurelia would reflect the value of the disabled property to the DOM by adding/removing the disabled attribute. Unfortunately this is not the current behavior, but I'm hoping that will be implemented as a result of https://github.com/aurelia/binding/issues/347#issuecomment-242106920.
Until then, I guess a workaround might be to apply a class name:
<button disabled.bind="disabled" class="${disabled ? 'disabled' : ''}">

.disabled { pointer-events: none; }

But what about focus?
But this is where it gets fun, because what about the case where an element is disabled programatically while that element, or one of its children, has input focus? Ideally, that element, or its focused child, should then immediately loose focus - it would makes no sense to keep focus on a disabled element, as that would allow you to keep typing into e.g. a textbox, even after it, or its parent element, had become disabled.
Diving deeper into this, we realize that a disabled element, and it's children, should also have its tabindex attribute set to -1, in order to prevent it from receiving keyboard focus if the user presses the tab key. And of course, when the element is re-enabled at a later time, all those tabindex attributes should be restored to their original values.
How we currently handle this stuff
I realize this may be getting away from the original topic, but for those curious or in search of inspiration, the approach we're currently taking in the prototype of our component library, is to create behaviors which may be attached to a custom element - one of those is the DisabledBehavior shown below, which handles both the attribute and focus issues described above.
Here we define a behavior as a class that can have the same lifecycle methods (i.e created, bind, attached, detached, unbind) as the view model it is attached to, as well as propertyChanged methods for any @bindable properties on the view model. We then apply some magic to automatically ensure those methods are invoked on both the view model and any behaviors attached to it - including wiring up observers so any propertyChanged methods defined on the behaviors are automatically invoked whenever the value of the corresponding property on the view model changes.
Oh, and we also auto-unsubscribe event listeners when on detached.
The DisabledBehavior, which relies on [disabled] { pointer-events: none } in CSS to prevent the pointer events:
export class DisabledBehavior extends Behavior
{
    private _tabIndex: string;

    public constructor(viewModel: any, element: Element)
    {
        super(viewModel, element);
    }

    public attached(): void
    {
        super.attached();

        this.addEventListener("disable", this.disable, false, window);
        this.addEventListener("enable", this.enable, false, window);
        this.addEventListener("enable", this.interceptEnable, false);

        this.disabledChanged();
    }

    public detached(isAutoDetach?: boolean): void
    {
        if (!isAutoDetach)
        {
            throw new Error("This behavior does not support explicit detachment.");
        }

        super.detached();
    }

    public disabledChanged(): void
    {
        let event = this.viewModel.disabled ? "disable" : "enable";
        this.element.dispatchEvent(new CustomEvent(event, { bubbles: true, cancelable: true }));
    }

    private disable(event: Event): void
    {
        let target = event.target as Element;

        if (target === this.element)
        {
            console.log("disabled", this.element);

            this.setBooleanAttribute("disabled", true);

            this.disableKeyboardFocus();
        }
        else if (target.contains(this.element))
        {
            console.log("parent disabled", this.element);

            this.disableKeyboardFocus();
        }
    }

    private enable(event: Event): void
    {
        let target = event.target as Element;

        if (target === this.element)
        {
            this.setBooleanAttribute("disabled", false);

            if (!event.defaultPrevented)
            {
                console.log("enabled", this.element);

                this.enableKeyboardFocus();
            }
            else
            {
                console.log("enabled (parent disabled)", this.element);

                this.disableKeyboardFocus();
            }
        }
        else if (target.contains(this.element))
        {
            console.log("parent enabled", this.element);

            this.enableKeyboardFocus();
        }
    }

    private interceptEnable(event: Event): void
    {
        let target = event.target as Element;

        if (target !== this.element && this.viewModel.disabled)
        {
            event.preventDefault();
        }
    }

    private disableKeyboardFocus(): void
    {
        this.element.blur();

        if (this.element.hasAttribute("tabindex"))
        {
            this._tabIndex = this.element.getAttribute("tabindex");
            this.element.setAttribute("tabindex", "-1");
        }
    }

    private enableKeyboardFocus(): void
    {
        if (this._tabIndex != null)
        {
            this.element.setAttribute("tabindex", this._tabIndex);
            this._tabIndex = null;
        }
    }
}

The Checkbox custom element using this behavior:
import {autoinject, bindable, bindingMode} from "aurelia-framework";
import {Control} from "../../form-controls";
import {DisabledBehavior} from "../../behaviors/disabled-behavior";
import {FocusedBehavior} from "../../behaviors/focused-behavior";
import {PressedBehavior} from "../../behaviors/pressed-behavior";
import {CheckedBehavior} from "../../behaviors/checked-behavior";

@autoinject
export class Checkbox extends Control
{
    public constructor(element: Element)
    {
        super(element);

        this.attachBehavior(DisabledBehavior);
        this.attachBehavior(FocusedBehavior);
        this.attachBehavior(PressedBehavior);
        this.attachBehavior(CheckedBehavior);
    }

    @bindable({ defaultBindingMode: bindingMode.twoWay })
    public disabled = false;

    @bindable({ defaultBindingMode: bindingMode.twoWay })
    public focused = false;

    @bindable({ defaultBindingMode: bindingMode.twoWay })
    public pressed = false;

    @bindable({ defaultBindingMode: bindingMode.twoWay })
    public checked = false;
}

I can't say yet whether it is the best solution, but it's working pretty well for us so far - we're just getting started though. I'd actually love to have some kind of framework support for a behavior concept like this - maybe a @behaviors(DisabledBehavior, ...) decorator on the view model class?
What do you say, @EisenbergEffect? ;-)
Anyways, I just wanted to highlight the challenges related to that innocent looking disabled state, as I think this is about more than just preventing click events, and should probably be handled accordingly :-)

today I have add below code to a textarea disabled.bind="isDisableEdit"
expectation was disable textarea when isDisableEdit is true. its work fine in chrome and firefox
but in IE(version 11) it always disable
so I check the html and it was like below
<textarea disabled="" ...
disabled="" attribute makes textarea disable. So any know a way to fix this issue

@ashanvabs - this is a separate issue from the one reported here. Anyway...
I don't have this problem on IE 11. Maybe you're using an old version of Aurelia? I'm using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

I'm using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

What is the status of this issue? I just ran into this today and was surprised to find this to be such an old issue. Using click.trigger fixed it for me, but I think it would make sense for click.delegate to also work in this context. At the very least it is some weird and confusing behavior.

eventually one comes to this place

+1 for this issue.

I think you should use click.trigger instead. See https://aurelia.io/docs/binding/delegate-vs-trigger#delegate-vs-trigger

Thanks, works fine.

Just in case it helps anyone else, we're now using the inert attribute to disable complex elements. This attribute allows us to mark entire subtrees within the DOM as inert, which not only disables pointer events, but also prevents keyboard navigation to elements within those subtrees.
It's not quite a standard yet, but Google provides a polyfill that works really well.
https://github.com/GoogleChrome/inert-polyfill

Is there any concrete solution to this problem?

Is there any concrete solution to this problem?

Use click.trigger instead of click.delegate.

Does not work for me.

Is there any concrete solution to this problem?

Use click.trigger instead of click.delegate.

Does not work for me.

Do you have a repo of this we can look at.  We use it successfully in hundreds of places throughout our app, so there's something else going on here.

Is there any concrete solution to this problem?

Use click.trigger instead of click.delegate.

Does not work for me.

Do you have a repo of this we can look at. We use it successfully in hundreds of places throughout our app, so there's something else going on here.

Unfortunately I don't, the repository belongs to the company I work for. In any case, if someone is looking for a short, straight answer, the following worked for me:
Wrap the content of your button around a div with a custom class, e.g.:
<button disabled.bind="totalCount <= (currentPage * perPage)" click.delegate="nextPage()">

</button>

And then apply the following rule to that class:
.btn-content {
    pointer-events: none;
}

@diegopaiva1, the example you have still uses click.delegate instead of click.trigger.  change this:
<button disabled.bind="totalCount <= (currentPage * perPage)" click.delegate="nextPage()">

 </button>
to this:
<button disabled.bind="totalCount <= (currentPage * perPage)" click.trigger="nextPage()">

 </button>

@diegopaiva1, the example you have still uses click.delegate instead of click.trigger. change this: <button disabled.bind="totalCount <= (currentPage * perPage)" click.delegate="nextPage()">

 </button>
to this: <button disabled.bind="totalCount <= (currentPage * perPage)" click.trigger="nextPage()">

 </button>
The difference is where the event handler is attached. With click.delegate you get a single event handler attached to the document that dispatches any bound event to it's appropriate handler. This is a useful performance improvement where you might have a foreach with thousands of rows and potentially thousands of attached events. Event bubbling is a problem for this method however. With click.trigger, the event handler is bound directly to the element. In this case, bubbled events never reach the event handler.

I know that. I copied OP's button on my example. But, like I said earlier, click.trigger did not solve my problem, as the event continued to be fired even though the button was disabled. Maybe it is a browser issue, IDK. I am using Google Chrome 98.0.4758.102.

@diegopaiva1, got it.    It might be because a button only allows inline elements as children.  You might try changing the div to a span and see if that helps.


Build/Debug on server

How to Build/Debug C/C++ program on server using vscode

VSCode has an offical C++ extension from Microsoft. You can find it here.
This extension supports debugging for Windows (PDB, Mingw/Cygwin), OS X and Linux applications.
You can build applications with an task runner in VSCode. See the documentation here and here for C++.


chore: replace nearprotocol.com with near.org

fixes near/devx#217
Using ripgrep:

for f in $(rg -l nearprotocol\.com); do sed -i '' 's/nearprotocol.com/near.org/' $f; done

for f in $(rg -l DevNet); do sed -i '' 's/DevNet/testnet/' $f; done

for f in $(rg -l wallet\.near\.org); do sed -i '' 's/wallet.near.org/wallet.testnet.near.org/' $f; done

Merging this without review, as it's a small change. It is probably a waste of people's time to review it.


Additional argument for specifying PORT(s)

Installing multiple sidechains per host for various reasons can have port conflicts.
Let's make sure they're not hardcoded. Node and explorer ports.

noticed that app.js has a --port parameter we can use
Also mentioned in the Readme that could use an update.


amp platform start command fails to execute

After pulling AMP images using the command amp platform pull, executing amp platform start -v fails.
│[15:16] nviswanathan@ITEM-AX40155:amp (master u=) $ amp platform start -v
Warning: no valid configuration file (.amp.yaml) found in home or current directory
Starting AMP platform
Create network amp-infra
Start error: Error response from daemon: datastore for scope "global" is not initialized
Service influxdb already stopped
Service registry already stopped
Service kapacitor already stopped
Service telegraf-haproxy already stopped
Service haproxy already stopped
Service amp-log-worker already stopped
Service grafana already stopped
Service amplifier already stopped
Service etcd already stopped
Service amp-ui already stopped
Service nats already stopped
Service elasticsearch already stopped
Service amp-agent already stopped
Service telegraf-agent already stopped

However, executing docker swarm init before running amp platform start -v command fixes this issue.

yes, amp commands can work only on a running swarm platform, like the previous script 'swarm' we used to start amp.

But with the previous swarm script, there was no need to explicitly execute docker swarm init before doing a swarm start
As per the tests in #455 docker swarm init is not included
make install
stop amp: amp platform stop
remove all images and containers
execute: amp platform pull -v : pull all images needed for amp (-v: to have details)
execute: amp platform monitor in another console to monitor amp
execute: amp platform start -v in the first console
execute: amp platform status it returns 'running'
execute: make test
execute: amp platform stop

yes, you're right. Looking closer, swarm script initialized swarm. It's not the role of amp commands right now. Not the same responsibility.
Swarm cluster should be ready before executing any amp commands. For instance, using the installation agent/scripts. like the Nicolas's project "amp-swarm-deploy".
For local dev environment, I propose to update the documentation adding the fact that a docker swarm init is needed before using amp. What do you think?

I agree with Francois. amp commands should assume there is already a swarm cluster up and running (regardless it's a local swarm like we have in development mode, or a multi-node swarm cluster deployed with amp-swarm-deploy for instance) .
We should definitely update the documentation about this.

Fixed by #483


Enable darkmode on datetimepicker ios

Overview
Support for https://github.com/react-native-community/datetimepicker/pull/199
Test Plan
Before:

After:

mind pinging back when the PR is merged?

No problem!

I think you can invert the border of the modal, because the black background isn't noticeable because the black border, it looks like one thing

Open to PRs to get it as close as possible to the native dialog version 👍

Closing because the related PR was closed as well. Feel free to ping me if we should reopen it.


add width and height to OG metaimage

According to Facebook:

Use og:image:width and og:image:height Open Graph tags to specify the image dimensions to the crawler so that it can render the image immediately without having to asynchronously download and process it.

I usually do this manually using:
<meta property="og:image:width" content="{{ page.search_image.width }}" />
<meta property="og:image:height" content="{{ page.search_image.height }}" />

So,  I thought I can add it directly to templates/wagtailmetadata/parts/tags.html.

Good pickup! Just one small change then I can merge this in


add noisy_dense support ...

Hello,
I have created support for noisy dense since 5 Aug. It was published in https://github.com/tensorflow/tensorflow/pull/42069, but reviewers told me that it must be in tensorflow/addons repository instead of tensorflow/tensorflow. Meantime, somebody created a very similar implementation of this.
Here is my original post from tensorflow/tensorflow PR:

Hello,

I implemented NoisyNet layers into Keras API. It's useful for users, that experiments with reinforcement learning algorithms (NoisyDQN or NoisyA3C). For more information, I made a description of those layers in the code.

Links
Noisy Networks for Exploration

@leonshams
You are owner of some files modified in this pull request.
Would you kindly review the changes whenever you have the time to?
Thank you very much.

Hi @markub3327! So we won't remove our current layer and maintainer just because you had a previous PR on tensorflow/tensorflow, but I understand the frustration since you spent a lot of time on the contribution. Luckily Addons encourages multiple maintainers! Please submit a new PR where you add yourself as a maintainer for the noisy layer and we'd love to have your help.


add a ref to access nativeElement

fields:[
 {
  key:"test",
  type:"input",
  ref:"test"  //adds <input #test >, so we can access this input from our component via @viewChild()
]

not sure if that possible with angular, to get the nativeElement of the input you may rely on the field id instead:
document.querySelector(`#${field.id}`)

but what I mean is to access the element in your component file. not in DOM tree
example:
//my.component.html
<form #formRef>
 <input #elementRef>
</form>

//my.component.ts
class MyComponent {
  @ViewChild("formRef", { static: false }) formRef;
  @ViewChild("elementRef", { static: false }) elementRef;
  test;

//now we can access formRef & elementRef, for example:
onSubmit(){
 //do some stuff to submit the form, or send the data to the server
 this.formRef.reset();
 this.test = this.elementRef.nativeElement.value;
 }
}

Currently, there is no straight way to implement this feature, sorry about that 🙏!
Blocked by:

https://github.com/angular/angular/issues/8563
https://github.com/angular/angular/issues/33233

I don't talk about dynamically rendering the template, I talk about a feature already supported by Angular
https://itnext.io/working-with-angular-5-template-reference-variable-e5aa59fb9af

I know exactly what you were talking about 😃, we create field components dynamically using ComponentFactoryResolver which AFAIK angular doesn't recognize by ViewChild (correct me if I'm wrong).

Is there a solution available for this now? I need to reference some of my fields (ng-select, ionic inputs...) in a reusable subform...


Allowing glTFs to be loaded that don't have uvs and normals

Issue
Bevy will panic when rendering a glTF mesh that doesn't have UVs and normals
Fix
UVs and normal attributes will now be filled up with zeros.
Generally I think it is a better approach to fill up missing attributes with zeros. That will make it easier to deal with different meshs from render side.
Risks
It is now mandatory for the mesh to contain a position attribute. I really can't think of a case were a mesh wouldn't contain that, but may someone else has. 🤔

This is a nice temporary fix, but I think I would actually prefer it if loaded GLTFs only contained the attributes that have been specified.
The Mesh type was designed to be flexible in terms of vertex buffer attributes. You can pass in a VertexBufferDescriptor and it will output a gpu buffer that matches the format. The missing piece is that currently it will only do that for attributes that are in the Mesh.
I think we should extend Mesh to (optionally) fill in missing attributes with zeros.

get_vertex_buffer_bytes is the method where this would happen.

Okay, so something like this:
pub enum MissingVertexAttributeBehaviour{
    /// Attribute doesn't need to contain meaningfull data. Example: VertexColor
    DefaultValue(VertexAttributeValues //TODO),
    /// Attribute is optional, but must contain meaningfull data.
    /// Example: eg. SecondaryUV for lightmaps which can also be the PrimaryUV
    /// Cool Trick?: instead of cloning the fallback buffer, bind it to the same slot as the missing one
    FallbackAttribute(Cow<'static, str>),
    /// attribute is required. Example: VertexPosition
    Panic,
}

Or do you think thats too verbose?

Hmm I think short term I'd prefer something simpler like this.
fn get_vertex_buffer_bytes(&self, vertex_buffer_descriptor: &VertexBufferDescriptor, fill_in_missing_attributes: bool) -> Result<Vec<u8>, MeshToVertexBufferError> {
  / * existing logic here, but fill in missing attributes with zeros */
}

If later consumers decide that its overly limiting, we can revisit it. But I'm guessing this will be "good enough".

okay, new commit online 🙂

haha i totally forgot we were already generating arrays filled with zeros :smile:


Animation timeline advances a step when keyframing from the inspector.

Win10 64-bit commit: 8d75ea755cb933a5c4a0f9ec296e8b8c34ef9999
When clicking a keyframe in the inspector, it will step the time line forward.  There was some work on the past done on this, but the advancing I believe is intended only for advancing "frame" properties on Sprites and AnimatedSprites, etc.
The commit that causes this is:  5f2f1089086ad64636efc2a4096e55e4483c927a
A related commit is: 127940bd55751fa33394da2f9536c63bffe18398
I missed it earlier, since I mostly work from the toolbar keyframes, which are not affected, but found it today keyframing less common properties in the inspector.

@DualMatrix I think these two things need to be combined in some way.  A condition to only advance steps when keyframing "frame" properties.  Advancing the timeline on the other types makes things very difficult, as you might have to keep dragging back the time slider when changing and rekeying multiple tracks with keyframes on the same time position.

I don't really see why it would be preferable for it to only advance when animating frame properties. Could you explain why it's useful to advance for frame properties but not for others?

It is useful when editing frame properties, since manually moving the time marker would change the frame back to its keyframed (unincremented) value.

Sure, I think there is only one, but it is very time saving.
It's useful for quickly keyframing spritesheets with a lot of frames.  Assuming the spritesheet frames go in order, a user can can pick the starting frame of an animation in the sprite frame property in the inspector.  Choose the animation, the starting time, and then just rapidly click the keyframe button without leaving the inspector.
This will get all the frames of the spritesheet keyframed in a matter of a second or less.  Say someone has 12 frames for running animation, that's just 12 clicks in a row and they'd be done and have every frame from 0 to 11 keyframed at the time step of the animation.
For all the other properties it is trouble, and I reasonably sure this is why it was given the special + icon and its own type.
Without it, the same process starts by keyframing the first sprite frame, advance the timeline manually by one step, then go back to the inspector, bump the value up by one, keyframe again.  Repeat this several to a dozen times.
It can take much much longer, and it is easier to mess it up.

In the old GIF I had, you can at least see the effect of clicking the frame property to get a fast result, though the image shows it at the point where the frame number wasn't bumping up.

So four clicks and it should give 4 frames like 0 1 2 3 or if it was started at 5 it would go 5 6 7 8.

Makes sense, I'll look in to fixing this as soon as I've got time

Cool, thanks man.  I'll keep an eye out for it.


Update xcom.py

In the one-material case for the calculate_attenuation method, a check is made to see if the name being modified is the energies for which mass attenuation coefficients are tabulated. If so, these energies are not scaled by the cross-section scaling factors. This is the correct behavior and gives correct results.
However, this check isn't being done for the multiple mixture case. For example. xcom.calculate_attenuation(xcom.Mixture([92, 92], [0.5,0.5]), [1e6])['energy'] didn't return 1 000 000 - it returned something like 35 000 (don't have the logs on me right now).
Altering the code to check if the name being altered is "energy" fixes this problem.

Hi @ischreiber3,
Good catch, thanks for your fix. I'll look at the interpolator code as well.
I can see that the energy mixing is now fixed, but it may be that this is a symptom of improper mixing in the code in general (my intuition says that the data should be a weighted average, which, if implemented correctly, should not change the energy data at all).


inexplicable errors trying to bind FAST

I have a simple builder in the following project.
https://github.com/mattmacy/ruFAST
for starters I'm just generating wrappers for the following two headers:
#include <FAST/Importers/ImageFileImporter.hpp>
#include <FAST/Algorithms/ImageResampler/ImageResampler.hpp>
These include a tremendous amount of stuff including Eigen/Dense which seems to cause an awful lot of build errors.
See the following gist:
https://gist.github.com/mattmacy/07de40bb41b49672f442df3cfd3fcb7f
To reproduce just build / install the following and either libeigen3-dev or libeigen2-dev.
https://github.com/smistad/FAST

If I just include Eigen/Core (FAST includes Eigen/Dense which in turn include Eigen/Core) I get fewer errors:
http://pasted.co/286422b0
diff --git a/src/wrapper.hpp b/src/wrapper.hpp
index 2b037e7..5b538ba 100644
--- a/src/wrapper.hpp
+++ b/src/wrapper.hpp
@@ -1,2 +1,3 @@
-#include <FAST/Importers/ImageFileImporter.hpp>
-#include <FAST/Algorithms/ImageResampler/ImageResampler.hpp>
+#include <Eigen/Core>
+//#include <FAST/Importers/ImageFileImporter.hpp>
+//#include <FAST/Algorithms/ImageResampler/ImageResampler.hpp>

It doesn't look like bindgen properly mangles struct scoped typedefs.
The apt packages that llvm supposedly builds for Ubuntu / Debian don't actually so I used the pre-built binaries and put them in ~/.bin/llvm-3.9 char_type appears to be repeatedly redefined in different contexts and scoped to individual structs, e.g. include/c++/v1/string:504:
// char_traits
template
struct _LIBCPP_TYPE_VIS_ONLY char_traits
{
typedef _CharT    char_type;
627:
// char_traits
template <>
struct _LIBCPP_TYPE_VIS_ONLY char_traits
{
typedef char      char_type;
717:
#ifndef _LIBCPP_HAS_NO_UNICODE_CHARS
template <>
struct _LIBCPP_TYPE_VIS_ONLY char_traits<char16_t>
{
typedef char16_t       char_type;
etc. etc.
find ~/.bin/llvm-3.9 -type f | xargs grep "char_type;" | grep typedef
/home/mmacy/.bin/llvm-3.9/include/c++/v1/ios:    typedef charT char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/ios:    typedef _CharT char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/streambuf:    typedef charT char_type;
<...>
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef charT     char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef _CharT    char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef char      char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef wchar_t   char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef char16_t       char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef char32_t       char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/string:    typedef typename _Traits::char_type char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef _CharT char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef char char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef wchar_t char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef wchar_t char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef char char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef char char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef wchar_t char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef char char_type;
/home/mmacy/.bin/llvm-3.9/include/c++/v1/__locale:    typedef wchar_t char_type;

Well, I wouldn't call these "inexplicable". C++ is a complex language, and overall when complex templates come into place, bindgen can't understand absolutely everything.
The way to go when doing bindings to C++ is using the whitelisting APIs to generate what you need. If you need one of the things bindgen can't generate correct code for, the way to go is using the blacklisting APIs, and add custom replacements for those.

I missed the "have to" whitelist bit. I'd have to disable recursive white listing because it uses strings, so easier to just write a C wrapper lib for the bits I need and bind that. Thanks.


Is it okay to use OCTIS to evaluate topic models from other Python modules?

Let's say:
Z - the number of topics
W - the number of words (unique)
D - the number of documents
Given that OCTIS returns a dictionary containing a "topic-word-matrix" (a Z by W matrix), a list of "topics" (the top words for each topic), a "topic-document-matrix" (a Z by D matrix), and a "test-topic-document-matrix" (which can be initialized as a NumPy array containing an empty list), is it possible to convert the output of a topic model from another module into a similar format as the output of OCTIS in order to evaluate the topic model's performance using different metrics in OCTIS?
Thank you! :)

Hello :)
yes, you can evaluate the output of an external topic model using OCTIS metrics. You can refer to this issue for more details on how to do it: https://github.com/MIND-Lab/OCTIS/issues/61
Feel free to re-open the issue if you have further questions :)
Silvia


Save df feature

This PR adds the save dataframes feature.
Dataframes are saved to individual json files and all dataframes are reloaded on server restart.
Docs demonstrating how to use this feature are included in the docs directory.

This PR includes the save dataframe feature and session-based granular access-rule.
There are a few things that should be noted:

The quick-tour now uses the server in a python-wrapper pulled from pypi. So while the rdf.save() demonstration is present in the quick-tour it will not work in the quick-tour until the server is updated in pypi.
There is an issue deserializing the user id string from the policy. The quotes are removed from the user id causing the deserialization to string to fail. You can get around this for now by using single quotes wrapping around double quotes like so:
policy = Policy(safe_zone=UserId('"user-id"'), unsafe_handling=Log())

Fixed issue 2 mentioned above.


WIP: implement reddit proof operations

Not tested, just saving this work for now

The reddit-hosted proofs are now downloaded and validated & verified. The proof format changed slightly due the string properties in the JSON with \\" was causing JSON parsing errors on reddit.


Get blob count in container

Is it possible to get the number of blobs in a container? I haven't found it in the API reference but see it's possible to find from Storage Explorer so I imagine it must exist.

Hi @DVassilev, unfortunately there is no API to get number of blobs under a specific container. You can find all RESTful APIs provided by Azure Storage. SDK is a wrapper based on these RESTful APIs. https://docs.microsoft.com/en-us/rest/api/storageservices/blob-service-rest-api

@XiaoningLiu any plans to expose it as it seems to be available in Storage Explorer?

Storage Explorer is built based on storage JS SDK. Storage explorer calls list blobs to get blobs under specific level.

@DVassilev if SE has this functionality, it could implement more comprehensive logic in its own code instead of using sdk API directly. Given the facts that listing blobs can be unpredictable in terms of duration or resource consumption, we don't have plan to add this feature to storage js sdk yet. If you do believe it deserves a SDK feature, feel free to let us know.

This would seem to be a useful feature to expose in the SDKs -- not sure why the request was closed other than perhaps difficulty in implementing it?  It takes a long time to enumerate the blobs just to count them.  It would seem more efficient to examine the index structure to determine this.