Dual Transformer for long term and short term seq[QST]

❓ Questions & Help
Details
Im working on a project that requires me to produce a stable long-term user and item representation and also use short-term user behavior for next action prediction. Is it possible to create a custom architecture to train two transformer towers together with different inputs and then have concat at later point. What is the recommended architecture for problems like this.

I am doing the same. Any leads will be appreciated

@vivpra89 is there a specific reason you don't want to use a single transformer architecture with single sequence? is the reason accuracy?  by using a single sequence the position embeddings would help the network to learn about what the most recent interactions are, or you might use time elapsed as side information. You can calculate the time elapsed between each interaction or since last user interaction.
If you really want to have to sequences, yes you can have two transformer block and concat them without applying masking, which means the target (the last item in the user interaction sequence) should be in a different column and not in the input-sequence.

@rnyak In two sequences approach, we create two separate sequences: one for long-term behavior and another for short-term behavior. The long-term sequence captures the historical preferences and patterns of the user, while the short-term sequence represents recent interactions or activities. Each sequence is trained individually using a transformer architecture, which allows the model to capture complex dependencies and patterns within the data.
Once both models are trained, we can combine them using a fusion method.This approach can be effective as it considers both long-term and short-term preferences.
What is your opinion on this architecture?

Hi @NamartaVij and @vivpra89 . Transformers4Rec provides some masking options for training sequential models: Causal Language Modeling and Masked Language Modeling, that you set in TabularSequenceFeatures like here. Those masking approaches extract the labels from the sequence.
For that reason, in Transformers4Rec you can only have one TabularSequenceFeatures block with masking set. For example, you could have two TabularSequenceFeatures (one for each sequence), and set masking only for the short sequence TabularSequenceFeatures (from which the targets would be extracted), and then concatenate it with the long sequence TabularSequenceFeatures, from which the model would have access to all long-sequence positions.
@NamartaVij You proposed training two models separately and that definitely is possible. Maybe you train one of those models first and share the embedding weights with the second model, using the TensorInitializer. If you use weight tying (NextItemPredictionTask(weight_tying=True)), then the output of the model will be in the same vector space as the item embeddings. So you could maybe use that property to combine the session embedding output from both short and long term models to look for similar items. Does that make sense?
What do you mean by "using a fusion method"?

@gabrielspmoreira If we assume Long Term sequences are purchases and short term are ATCs, do you think this works with causal masking for both transformers?
Create a schema or read one from disk: tr.Schema().from_json(SCHEMA_PATH).
schema: tr.Schema = tr.data.tabular_sequence_testing_data.schema
max_sequence_length, d_model = 20, 64
Define the input module to process the tabular input features.
input_module_lt = tr.TabularSequenceFeatures.from_schema(
schema,
max_sequence_length=max_sequence_length,
continuous_projection=d_model,
aggregation="concat",
masking="causal",
d_output=200,
)
input_module_st = tr.TabularSequenceFeatures.from_schema(
schema,
max_sequence_length=max_sequence_length,
continuous_projection=d_model,
aggregation="concat",
masking="causal",
d_output=200,
)
Define a transformer-config like the XLNet architecture.
transformer_config_lt = tr.XLNetConfig.build(
d_model=d_model, n_head=4, n_layer=2, total_seq_length=max_sequence_length
)
transformer_config_st= tr.XLNetConfig.build(
d_model=d_model, n_head=4, n_layer=2, total_seq_length=max_sequence_length
)
Define the model block including: inputs, masking, projection and transformer block.
lt_body = tr.SequentialBlock(
input_module_lt,
tr.MLPBlock([d_model]),
tr.TransformerBlock(transformer_config, masking=input_module.masking)
)
st_body = tr.SequentialBlock(
input_module_st,
tr.MLPBlock([d_model]),
tr.TransformerBlock(transformer_config, masking=input_module.masking)
)
Define the evaluation top-N metrics and the cut-offs
metrics = [NDCGAt(top_ks=[20, 40], labels_onehot=True),
RecallAt(top_ks=[20, 40], labels_onehot=True)]
body_concats = mm.ParallelBlock(
{'lt_body': lt_body,
'st_body': st_body},
aggregation='concat'
)
Define a head with NextItemPredictionTask.
head = tr.Head(
body_concats,
tr.NextItemPredictionTask(weight_tying=True, metrics=metrics),
inputs=input_module,
)
Get the end-to-end Model class.
model = tr.Model(head)

@vivpra89 if I want to create two sequences. May I know how to create into two sequences before creating schema.

Hi @NamartaVij and @vivpra89 . Transformers4Rec provides some masking options for training sequential models: Causal Language Modeling and Masked Language Modeling, that you set in TabularSequenceFeatures like here. Those masking approaches extract the labels from the sequence. For that reason, in Transformers4Rec you can only have one TabularSequenceFeatures block with masking set. For example, you could have two TabularSequenceFeatures (one for each sequence), and set masking only for the short sequence TabularSequenceFeatures (from which the targets would be extracted), and then concatenate it with the long sequence TabularSequenceFeatures, from which the model would have access to all long-sequence positions.
@NamartaVij You proposed training two models separately and that definitely is possible. Maybe you train one of those models first and share the embedding weights with the second model, using the TensorInitializer. If you use weight tying (NextItemPredictionTask(weight_tying=True)), then the output of the model will be in the same vector space as the item embeddings. So you could maybe use that property to combine the session embedding output from both short and long term models to look for similar items. Does that make sense? What do you mean by "using a fusion method"?
)
@gabrielspmoreira , Thankyou for your response. I got it about TabularSequenceFeature for one sequence.
However, Could you please explain the second approach which you suggested regarding sharing the embedding weights with the second model.

Hi @NamartaVij and @vivpra89 . Transformers4Rec provides some masking options for training sequential models: Causal Language Modeling and Masked Language Modeling, that you set in TabularSequenceFeatures like here. Those masking approaches extract the labels from the sequence. For that reason, in Transformers4Rec you can only have one TabularSequenceFeatures block with masking set. For example, you could have two TabularSequenceFeatures (one for each sequence), and set masking only for the short sequence TabularSequenceFeatures (from which the targets would be extracted), and then concatenate it with the long sequence TabularSequenceFeatures, from which the model would have access to all long-sequence positions.
@NamartaVij You proposed training two models separately and that definitely is possible. Maybe you train one of those models first and share the embedding weights with the second model, using the TensorInitializer. If you use weight tying (NextItemPredictionTask(weight_tying=True)), then the output of the model will be in the same vector space as the item embeddings. So you could maybe use that property to combine the session embedding output from both short and long term models to look for similar items. Does that make sense? What do you mean by "using a fusion method"?

@gabrielspmoreira  Can you please help me with a snipped on how to concat TabularSequenceFeatures, or use TensorInitializer to share embedding weights, couldnt find them in examples.

@gabrielspmoreira
`# Define input block
sequence_length, d_model = 20, 64
pre-trained embedding
pretrained_dim = 256
np_emb_item_id = np.random.rand(27929, pretrained_dim)
embeddings_op = EmbeddingOperator(
np_emb_item_id, lookup_key="item-list", embedding_name="pretrained_item_embeddings"
)
set dataloader with pre-trained embeddings
data_loader = MerlinDataLoader.from_schema(
schema,
train,
batch_size=256,
max_sequence_length=sequence_length,
transforms=[embeddings_op],
shuffle=False,
)
set the model schema from data-loader
model_schema = data_loader.output_schema
Define input module to process tabular input-features and to prepare masked inputs
inputs= tr.TabularSequenceFeatures.from_schema(
model_schema,
max_sequence_length=sequence_length,
continuous_projection=64,
aggregation="concat",
d_output=d_model,
masking="mlm",
)
Define XLNetConfig class and set default parameters for HF XLNet config
transformer_config = tr.XLNetConfig.build(
d_model=d_model, n_head=8, n_layer=2, total_seq_length=sequence_length
)
Define the model block including: inputs, masking, projection and transformer block.
body = tr.SequentialBlock(
inputs, tr.MLPBlock([256]), tr.TransformerBlock(transformer_config, masking=inputs.masking)
)
prediction_task = tr.NextItemPredictionTask(weight_tying=True,
metrics=[NDCGAt(top_ks=[2, 5, 10], labels_onehot=True),
RecallAt(top_ks=[2, 5, 10], labels_onehot=True)])
Define the head related to next item prediction task
head = tr.Head(
body,prediction_task
)
Get the end-to-end Model class
model_si = tr.Model(head)
#Set arguments for training
training_args = T4RecTrainingArguments(
output_dir="./tmp",
max_sequence_length=10,
data_loader_engine='merlin',
num_train_epochs=10,
dataloader_drop_last=False,
per_device_train_batch_size = 64,
per_device_eval_batch_size = 32,
gradient_accumulation_steps = 1,
learning_rate=0.000666,
report_to = [],
logging_steps=200,
)
Instantiate the T4Rec Trainer, which manages training and evaluation
trainer = Trainer(
model=model_si,
args=training_args,
schema=schema,
compute_metrics=True,
)
OUTPUT_DIR = os.environ.get("OUTPUT_DIR", "./data/sessions_by_day_si/")
from transformers4rec.torch.utils.examples_utils import fit_and_evaluate
OT_results = fit_and_evaluate(trainer, start_time_index=1, end_time_index=2, input_dir=OUTPUT_DIR)
`
above code fails with a RuntimeError: mat1 and mat2 shapes cannot be multiplied (640x704 and 960x64)
am I missing something here

@gabrielspmoreira @rnyak how to concatenate in the end both outputs to get the final prediction?


fix(validation): wrong condition for required field

Description
The condition to check if a field is required returns an object, which is always truthy. I fixed the issue by reading the value property of said object, which returns whether the field is required or not.
How Has This Been Tested?
tested with unit tests and use of the pre-release in our internal repo
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (740e3b1) 74.48% compared to head (de7182b) 74.68%.
Report is 4 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #99      +/-   ##
==========================================
+ Coverage   74.48%   74.68%   +0.19%
==========================================
  Files          28       28
  Lines         388      391       +3
  Branches      123      125       +2
==========================================
+ Hits          289      292       +3
  Misses         64       64
  Partials       35       35

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Intermittent errors when doing meltano config airflow

Can't seem to consistently reproduce this.
❯ meltano config airflow set webserver web_server_port 8081
2022-06-09T02:07:03.866027Z [info     ] Environment 'dev' is active
[Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'

but if I run meltano invoke airflow:ui and then kill the process once it's trying to connect I can successfully run
❯ meltano config airflow set webserver web_server_port 8081
2022-06-09T02:09:10.771279Z [info     ] Environment 'dev' is active
Orchestrator 'airflow' setting 'webserver.web_server_port' was set in the active environment in `meltano.yml`: 8081

so clearly something about the airflow.cfg being present or not.
I would expect to be able to set the config in my meltano.yml even if the airflow.cfg is not present.
It seems like it's something with invoke because this is what happens if I try to change the port to 8082, then do an invoke, and then reset the port again
❯ meltano config airflow set webserver web_server_port 8082
2022-06-09T02:10:32.255003Z [info     ] Environment 'dev' is active
Orchestrator 'airflow' setting 'webserver.web_server_port' was set in the active environment in `meltano.yml`: 8082
❯ meltano invoke airflow version
2022-06-09T02:10:47.148948Z [info     ] Environment 'dev' is active
2.1.2
❯ meltano config airflow set webserver web_server_port 8082
2022-06-09T02:11:00.416107Z [info     ] Environment 'dev' is active
[Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'

@tayloramurphy Can you run again with --log-level=debug and share the full stacktrace? I'm not sure why meltano config meltano set would use the actual Airflow config file (.meltano/run/airflow/airflow.cfg), that should only be relevant on invoke.

@DouweM
2022-06-09T02:17:07.680278Z [debug    ] Generated default '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'
2022-06-09T02:17:07.683015Z [debug    ] [Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'
Traceback (most recent call last):
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/cli/__init__.py", line 51, in main
    cli(obj={"project": None})
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 1256, in invoke
    Command.invoke(self, ctx)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/cli/params.py", line 23, in decorate
    return func(*args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/cli/params.py", line 56, in decorate
    func(project, *args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/cli/config.py", line 81, in config
    run_async(invoker.prepare(session))
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/utils/__init__.py", line 52, in run_async
    loop.run_until_complete(future)
  File "/Users/taylormurphy/.pyenv/versions/3.9.7/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/plugin_invoker.py", line 223, in prepare
    async with self.plugin.trigger_hooks("configure", self, session):
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/async_generator/_util.py", line 34, in __aenter__
    return await self._agen.asend(None)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/behavior/hookable.py", line 87, in trigger_hooks
    await self.__class__.trigger(self, f"before_{hook_name}", *args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/behavior/hookable.py", line 115, in trigger
    raise err
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/behavior/hookable.py", line 107, in trigger
    await hook_func(target, *args, **kwargs)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/plugin/airflow.py", line 126, in before_configure
    self.update_config_file(invoker)
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/core/plugin/airflow.py", line 77, in update_config_file
    with airflow_cfg_path.open() as airflow_cfg_file_to_read:
  File "/Users/taylormurphy/.pyenv/versions/3.9.7/lib/python3.9/pathlib.py", line 1252, in open
    return io.open(self, mode, buffering, encoding, errors, newline,
  File "/Users/taylormurphy/.pyenv/versions/3.9.7/lib/python3.9/pathlib.py", line 1120, in _opener
    return self._accessor.open(self, flags, mode)
FileNotFoundError: [Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/taylormurphy/.local/pipx/venvs/meltano/lib/python3.9/site-packages/meltano/cli/__init__.py", line 59, in main
    raise CliError(str(err)) from err
meltano.cli.utils.CliError: [Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'
[Errno 2] No such file or directory: '/Users/taylormurphy/Documents/Projects/dev/demoday/prepped/.meltano/run/airflow/airflow.cfg'

@tayloramurphy OK, so the offending line is https://github.com/meltano/meltano/blob/main/src/meltano/cli/config.py#L81. Let me try to find out why that would be needed...

@pandemicsyn Do you remember why that was added there, and not just in the meltano config <plugin> test entrypoint? PluginInvoker.prepare is a pretty expensive method that triggers configuration hooks: https://github.com/meltano/meltano/blob/main/src/meltano/core/plugin_invoker.py#L223, which in the case of Airflow go as far as invoking the plugin and building its database, which shouldn't be necessary if we're just updating Meltano's conception of its config.

@tayloramurphy I'm trying to figure out why Airflow.before_configure would be failing when it's called through meltano config...
Do you ever see meltano invoke airflow version fail with the same error? Or only ever meltano config?
When you saw meltano config fail, were you running meltano invoke airflow ... in another terminal session?

@DouweM haven't seen meltano invoke airflow version fail. Only config.
That commit rings a bell about some work @edgarrmondragon did around meltano test and some bugs we had with Airflow I think. @edgarrmondragon do you recall?

@tayloramurphy I recall that, though it was specific to meltano test and its eagerness to "prepare" an invoke context for all plugins: https://gitlab.com/meltano/meltano/-/issues/3233#note_851804821, which as @DouweM mentioned is an operation with lots of side effects.
So this seems to have a similar cause, but in a different place in the code.

@pandemicsyn Do you remember why that was added there, and not just in the meltano config  test entrypoint? PluginInvoker.prepare is a pretty expensive method that triggers configuration hooks: https://github.com/meltano/meltano/blob/main/src/meltano/core/plugin_invoker.py#L223, which in the case of Airflow go as far as invoking the plugin and building its database, which shouldn't be necessary if we're just updating Meltano's conception of its config. Even with test, I'm not sure we need that extra call as it already uses PluginInvoker.prepared which does that prepare call as well: https://github.com/meltano/meltano/blob/main/src/meltano/cli/config.py#L286.

 I probably didn't know any better.

errr  https://gitlab.com/meltano/meltano/-/merge_requests/2326/diffs isn't actually where that came from,  neither is https://gitlab.com/meltano/meltano/-/merge_requests/2179 which are the two MR's linked in the issue for the changelog entry in  https://github.com/meltano/meltano/commit/ef0151da69228c282b0785b2073e14e4da6c802a

@pandemicsyn OK, I think we can at least fix the meltano config issue then by losing that superfluous invoke call. If it's never happened on meltano invoke we don't really need to dive deeper into that part of it.
I'll put this in the project/board, you can figure out with AJ if it makes sense for you to pick it up or someone else should!

@pandemicsyn - do you think you have a path forward here on a fix, either that you could implement or that you could guide another engineer thought?
If so, I'm in favor of picking this up in next iteration.

@aaronsteers I think the trick might be trying to figure out why it was included in the first place, some what worried that theres a non obvious reason why it was included when we added meltano test.  Its totally possible I didn't know any better at the time and was just trying to make the async refactor play nice with the conflicting meltano test MR.
Happy to pick this up, but i might need you to clarify my priority/order - with the other currently assigned issues I doubt I can deliver all three.

So, yea, this might actually be a really quick fix. I was worried I had added this intentionally for a reason I can't recall, but I think this just got introduced accidentally when we picked up the community contrib:
https://gitlab.com/meltano/meltano/-/merge_requests/2179/diffs?commit_id=7bad854e3d7ee4c4b2a0ebede24e1ee41797d3b1#bd50d05c414b847ffb1be734807753e08662c778_52_58
And then I missed the implications of that addition being in that top-level click group, and just blindly made it async aware to resolve the merge conflict from having just landed that large async refactor:
https://gitlab.com/meltano/meltano/-/merge_requests/2179/diffs?commit_id=a029c46acb157b10870e62ff2d5bb3ea2822b34e
So as @DouweM alluded, I think the fix is just dropping that run_async(invoker.prepare(session)) statement, and double-checking that meltano test which actually relies on that invoker still works as expected.

This one was bugging me after dinner - so had to send a fix along: https://github.com/meltano/meltano/pull/6227

@pandemicsyn - Really appreciate the extra effort here. Thanks very much!


AttributeError: 'MetaLoader' object has no attribute 'dataset'

When I try to resume a checkpoint from last training, it raises an error:
[rank12]: Traceback (most recent call last):
[rank12]:   File "/cpfs/29f69eb5e2e60f26/user/GPT/pretrain/mm_intern/duyifan/ST-LLM-temp/stllm/train/train_hf.py", line 278, in <module>
[rank12]:     train()
[rank12]:   File "/cpfs/29f69eb5e2e60f26/user/GPT/pretrain/mm_intern/duyifan/ST-LLM-temp/stllm/train/train_hf.py", line 267, in train
[rank12]:     trainer.train(resume_from_checkpoint=True)
[rank12]:   File "/cpfs/29f69eb5e2e60f26/user/GPT/pretrain/mm_intern/duyifan/miniconda3/envs/stllm/lib/python3.10/site-packages/transformers/trainer.py", line 1662, in train
[rank12]:     return inner_training_loop(
[rank12]:   File "/cpfs/29f69eb5e2e60f26/user/GPT/pretrain/mm_intern/duyifan/miniconda3/envs/stllm/lib/python3.10/site-packages/transformers/trainer.py", line 1893, in _inner_training_loop
[rank12]:     epoch_iterator = skip_first_batches(epoch_iterator, steps_trained_in_current_epoch)
[rank12]:   File "/cpfs/29f69eb5e2e60f26/user/GPT/pretrain/mm_intern/duyifan/miniconda3/envs/stllm/lib/python3.10/site-packages/accelerate/data_loader.py", line 1086, in skip_first_batches
[rank12]:     dataset = dataloader.dataset
[rank12]: AttributeError: 'MetaLoader' object has no attribute 'dataset'

Sorry, our code currently only supports resume from epoch, not resume from step. Resuming from step cannot retrieve the historical order of the dataset.


Getting Operational error  no such table: core_document

Hi, I tried doing a clone and running this program, I get an error saying this:

Request Method:
GET

http://<IP_ADDRESS>:8000/

1.11.3

OperationalError

no such table: core_document

/home/musigma/virtualenvpycharm35/lib/python3.5/site-packages/django/db/backends/sqlite3/base.py in execute, line 328

/home/musigma/virtualenvpycharm35/bin/python

3.5.0

['/home/musigma/django_project/FileUploadPOC/simple-file-upload',  '/usr/local/lib/python35.zip',  '/usr/local/lib/python3.5',  '/usr/local/lib/python3.5/plat-linux',  '/usr/local/lib/python3.5/lib-dynload',  '/home/musigma/virtualenvpycharm35/lib/python3.5/site-packages',  '/home/musigma/virtualenvpycharm35/lib/python3.5/site-packages/setuptools-28.8.0-py3.5.egg',  '/home/musigma/virtualenvpycharm35/lib/python3.5/site-packages/pip-9.0.1-py3.5.egg']

Fri, 11 Aug 2017 18:24:56 +0000

There is a lot more to this page, please let me know if you can help me or if you need more clarifications to do so. Thank you.

Hi @sohamghoshmusigma
Before running make sure you run the project's migrations:
python manage.py migrate

Then try to run it again. This way, Django will create the core_document table in your database.
I will add further description in the repository, as already mentioned by the issue #1
I hope it helps!

Hi @vitorfs
It worked like a charm. thank you for explaining why the solution works also. I'm new to django, so that definitely helped.


bpf documentation updates, part 1

Related: #713

test-me-please

test-me-please

test-me-please

test-me-please


lodash: added _.toPlainObject() method

https://lodash.com/docs#toPlainObject

@chrootsu thanks mate!


Fix more clippy warnings.

Fix remaining clippy warnings.
I've now added cargo clippy to my pre-commit hook and I suggest that others do the same.
I didn't agree with one of the clippy checks and put an #[allow()] block in.

I thought that I should include you in the conversation as you have been working hard.


[BUG] On React without concurrent rendering, render prop produces ResizeObserver errors on Firefox

Bug description
When using React <18, or on React 18 and not using concurrent rendering (using ReactDOM.render() instead of createRoot().render(), use of the render prop produces errors on Firefox. This error is easily and consistently reproduced by rendering a list of elements which all use the same data-tooltip-id and data-tooltip-content. The error produced is:
ResizeObserver loop completed with undelivered notifications.

without a stack trace, which is caught by window.onerror handlers (and thus ends up in Sentry and other monitoring platforms).
Firefox also issues the following warning in the console:
Layout was forced before the page was fully loaded. If stylesheets are not yet loaded this may cause a flash of unstyled content.

The app doesn't crash, but the error happens on almost every tooltip hover change (move cursor from element A to element B quickly), and thus produces thousands of errors per session per user on a tooltip-heavy site.
The error can of course be ignored with a regex as it does not crash the app or the tooltips, but clearly there is something wrong.
Version of Package
I have tested the following versions:

v5.25.0 - Reproduces
v5.24.0 - Reproduces
v5.19.0 - Reproduces
v5.15.0 - Reproduces
v5.12.0 - Reproduces
v5.10.1 - Cannot reproduce, or library is just so slow to change tooltips that it doesn't happen

To Reproduce

Run the example

I have created a reproduction here: https://github.com/johannkor/react-tooltip-bug-repro
You can clone it and use the latest Firefox version (120.0.1). Here is the gist of the repo:

import React from "react";
import ReactDOM from "react-dom";
import { Tooltip } from "react-tooltip";
// using `disableStyleInjection="core"` to ensure it's not related to the recent
// style injection features
import "react-tooltip/dist/react-tooltip.css";

const TOOLTIP_ID = "tooltip";

function App() {
  return (

      <Tooltip
        disableStyleInjection="core"
        id={TOOLTIP_ID}
        render={({ content }) => {content}}
      />

        {Array(50)
          .fill(0)
          .map((_, i) => (

              row {i}

          ))}

  );
}

ReactDOM.render(<App />, document.getElementById("root"));

When the app is running, quickly swipe your cursor up and down the middle of the page

Swipe so that the cursor is over the tooltips, and swipe quickly enough that the tooltips don't have enough time to fully appear
Swipe from the top of the page to the bottom of the page quickly for maximum effectiveness

Notice the error in the webpack dev server's error overlay which pops up

This bug also appears with normal usage (non-furious mouse swiping), but I found this to be the most effective way to reproduce it.
Expected behavior
I prefer this error not to occur, as it forces us to ignore the ResizeObserver error which hides other, unrelated ResizeObserver errors from us.
Desktop (please complete the following information if possible or delete this section):

OS: macOS
Browser: Firefox
Version: 102.0.1
Frameworks: React 16, React 17, React 18 (when not using concurrent mode)

Additional context
I have managed to reproduce this with Chrome in a larger application, but I have not been able to reproduce the error in the MVP above with Chrome.

After some looking around, I found this comment suggesting using setTimeout() on the observer callback, which seems to have fixed it. See #1137 and<EMAIL_ADDRESS>I don't think we should merge this just yet, in case this introduces some other issues. We'll do some testing later on.
The beta version should be fine to use though.

I genuinely appreciate your effort in figuring this out, but I'm 95% sure this isn't a real cause for concern. I have some tests in mind to demonstrate that, but I'll only be able to get to my computer later on today. In summary, if you have problematic code causing an issue with ResizeObserver, you will get the error thrown, but having the error thrown doesn't mean you have problematic code.

I'm also slightly concerned about these 10ms setTimeouts in the codebase

If I recall correctly, this has been tested and there were no issues with it as far as we could tell. I'll try to demonstrate later as well.

Again, I really appreciate your effort on this, and I welcome you to keep making suggestions on things we could improve. So thanks!

First regarding your concern about the 10ms timeout. Since that's the only place the open state gets changed (at least when it's being fully handled internally), all open/close actions are queued on the event loop due to using setTimeout(), so there's no worry about them getting "desynced".
Here's what happens if we change that 10ms to a full second.
https://github.com/ReactTooltip/react-tooltip/assets/21102974/15c43740-dc10-474e-bed9-e7f5289466af

Now about the ResizeObserver loop issue, unfortunately I was unable to quickly create an example that "proves" the tooltip is not doing anything too crazy on the callback, so I'll just defer to the ResizeObserver documentation.
Relevant sections (emphasis mine):

Resize events that don't meet that condition are deferred to the next paint, and an error event is fired on the Window object [...].

As long as the error event does not fire indefinitely, resize observer will settle and produce a stable, likely correct, layout. However, visitors may see a flash of broken layout, as a sequence of changes expected to happen in a single frame is instead happening over multiple frames.

According to its own specs, the observer pushes any further changes to the next render cycle, which I'd argue is similar to what we're doing by wrapping the callback with a setTimeout(). Since, at least as far as I can tell, the layout is not getting broken, and there are no other visible issues with the tooltip because of this, I'd call it a non-issue.
Feel free to object to any of these conclusions, since I haven't demonstrated they're actually true, just that it's most likely the case.
Though unless there's any actual impact to the performance or usability of the tooltip, I'd just leave this as-is if I were you. Even if this is "fixable", it seems like way more trouble than what it's worth.
Again, thanks for the effort.


Do not reconfigure vswitch connectivity if it is persisted

Coverage increased (+0.08%) to 75.29% when pulling 10a43300a59ef0cb27b83bfb33209fc69c929ee6 on lukasmacko:master into 8ba9bbfba874605a66f7459a0ec71fa18d8c3e7c on contiv:master.


[Update] Enhance billing alerts based on account plan and usage limits

#4259  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jnsdls and the rest of your teammates on  Graphite


[OPENJDK-776] WIP: UBI9 images

This is a work-in-progress but raising the PR now since time is ticking
so SME review can begin if possible.
The starting point is to copy the UBI8 images exactly.
The next step is to slim the UBI9 ones down module by module.
The general approach is to: identify each module to slim; make a copy
with a higher version number (generally 9.0); adjust the older images
so they pull in the lower version number; hack away at the newer
version.
The rationale behind modifying the older image descriptors rather than
the new ones, despite that meaning some source-level changes to the
older images, is to ensure that the default happy path is the newer
modules, and the legacy/deprecated ones are treated as exceptional.
Doing it this way does result in the precise module order for older
images changing. I have tried to do a binary image comparison after
each such change to ensure that there are no significant differences.
Insignificant differences include things like RPM package DB and logs
not being identical due to a different RPM install order (etc)
https://issues.redhat.com/browse/OPENJDK-776

I'm open to other approaches to managing the source than the approach I've used here. In particular I wonder now whether to keep different RHEL major versions in distinct git branches. There are pros and cons to each approach. Considering that and any switch should probably be done at a different time.

GitHub CI is not going to be able to build or test RHEL9 images prior to GA. I can build and run test suites and circulate results internally.

Thank you very much for all your review so far!

Closing in favour of #296 (although Im keeping an eye on the unresolved conversations in this one so I can be sure they are resolved there)


Typo in Readme

What kind of change does this PR introduce?
Readme update
What is the current behavior?
Documentation refers to Firebase.

My bad ! I had misread the phrase...


add zheight option to widgets

closes #297
Adds the ability to change the order widgets are rendered. Large numbers will be rendered above small numbers (zheight = 1 will be rendered above zheight = 0). All widgets default to 0, except for background which defaults to -1.

updated, i originally called it zheight because hyprland uses that term for floating windows.


Fix the copyryright IBM issue in the headers

This is one example:
https://github.com/apache/incubator-openwhisk-apigateway/blob/master/conf.d/managed_endpoints.conf#L2,
https://github.com/apache/incubator-openwhisk-apigateway/blob/master/conf.d/management_apis.conf#L2
Still keep an eye on other files to see if there is still the same copyright left.

@daisy-ycguo Could you take care of this issue?

I think the license header is not Apache 2. Should we change it to Apache 2 ?

Yes

If we decide to donate everything, we can only keep the apache license without IBM copyright.

What do you mean by that, is there code in Apache repositories that you think has not been donated to the ASF?

All source code currently in all the ASF repos that came from IBM is donated to ASF.

This issue has been closed, since all the headers have been changed to the Apache header.


WIP: Add named classes for final blocks

Instead of defining blocks in category_factory.gd, define blocks ahead of time, each in their own GDScript file. Although it is not a concept in GDScript itself, we can consider block classes such as EntryBlock to be abstract block types.
By doing this, we are able to reduce duplication in the block script resource associated with each BlockCode node. In particular, the serialized data can simply refer to "PrintBlock", and all of the EntryBlock properties expected for the print block are implied.
This commit only adds ReadyBlock and PrintBlock as an example, and likely breaks everything else.

At a high level I think this is the right direction: ignoring the Godot type system and scene/script split for a moment, I think conceptually it makes more sense for “Print block” to be a type, which gets instantiated; and the only data that should need persisting is where it is in the program, its type, and the user-supplied parameter.
The current setup where the prototype print block in the sidebar is actually an instance of the statement block type, with its label in the block editor and the template for the generated GDScript, doesn't quite feel right, particularly because those properties get persisted into the user's game once per instance of the block despite being shared between all print blocks (and so you can't adjust the generated code without recreating every print statement or manually editing the scene files).
The big block of boilerplate in _init seems a bit sad and although I suggested a code generator on Slack I think that would still make the cure worse than the disease. I think what you are trying to avoid is having to create print_block.tcsn which extends entry_block.tcsn; and you want to ensure that any properties that were set on EntryBlock are propagated onto this subclass; before then overriding the important ones.
Having experimented a little, and with the hint about abstract types in your commit message, I think we could do this a bit differently with less boilerplate. In statement_block.gd, replace the @export var block_format etc. instance variables with:
static func get_block_format() -> String:
    return ""

Then define print_block.gd as follows:
class_name PrintBlock
extends StatementBlock

static func get_block_format() -> String
    return "Print {text: STRING}"

...

(I did a quick experiment and calling get_block_format() from the superclass does call the overridden implementation from the subclass.)
Then to instantiate the print block we have 3 options:

Define a scene for it – this is the simplest option, though it's a few extra clicks to define one and involves committing a lot of boilerplate to the repo that we're never going to edit. I can see why you wanted to avoid that.
Override _init as you have done – now that I understand it, it's a clever trick! Once all the property-copying and -setting logic is gone I think it would boil down to:

func _init():
	var _block = load(StatementBlock.get_scene_path()).instantiate() as Node
	_block.replace_by(self, true)
	_block.queue_free()

and (apart from infinite recursion issues) I think you could actually move this to the superclass (!).

In the category factory, instantiate the parent scene but replace its script:

	b = BLOCKS["statement_block"].instantiate()
        b.set_script(load("res://.../print_block.gd"))

I do not know how to persist that to disk, but if you .duplicate() an instanced scene that has had its script replaced in this way, the substitute script comes along with the duplicate as you would hope.


Support  multiple constraints pypi dependencies

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
# pyproject.toml
[project]
authors = [{ name = "ZhengYu, Xu", email =<EMAIL_ADDRESS>}]
description = "Add a short description here"
name = "playground"
requires-python = ">=3.7,<3.12"
version = "0.1.0"
dependencies = [
    'pyarrow >=11.0.0; python_version >= "3.7" and python_version < "3.8"',
    'pyarrow ==16.1.0; python_version >= "3.8" and python_version < "3.12"',
]

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["osx-64"]

[tool.pixi.feature.py311.dependencies]
python = "3.11.*"

[tool.pixi.feature.py37.dependencies]
python = "3.7.*"

[tool.pixi.tasks]

[tool.pixi.environments]
default = { features = ["py311"], solve-group = "py311" }
py311 = { features = ["py311"], solve-group = "py311" }
py37 = { features = ["py37"], solve-group = "py37" }

Issue description
I am installing different versions of pyarrow by restricting the python_version, but it seems that pixi fail to resolve it.

Expected behavior
Correctly resolve the dependencies.

https://github.com/prefix-dev/pixi/blob/b117b6ac0368603d91b238afa9e3507525e7795a/crates/pixi_manifest/src/pyproject.rs#L268-L273
https://github.com/prefix-dev/pixi/blob/b117b6ac0368603d91b238afa9e3507525e7795a/crates/pixi_manifest/src/target.rs#L219-L237
It seems that pixi ignores pyproject dependency markers

I think Pixi should support constraint dependencies like Poetry does

Indeed, we have to add env marker support.

Possibly related: https://github.com/prefix-dev/pixi/issues/1956

Indeed, we have to add env marker support.

We also need to do changes to this to rattler, or its likely we need to, because the pep508-rs version is now totally different from the uv implemantation :).


Add quality factor to octet-stream mediatype

Depending on the IMS implementation, they may return octet-stream when image/jpeg is available because octet-stream appears higher on the list of acceptable media types. This PR adds q=0.9 to the field value.
Fixes #80

I've tested this with Slim for a month or so using patch-package for local and remote IMS instances (dcm4chee, google, and GE) and it has been working well FWIW


[AMORO-2565] Optimization task loss leads to the optimization process remaining in a running state indefinitely

Why are the changes needed?

Close #2565.
Brief change log

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before making a pull request

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not documented)

Can add some test cases?

Can add some test cases?

This change is relatively simple, but I don't know how to write concurrent tests. This scenario only occurs when polling task from multiple tables in the same OptimizingQueue simultaneously.

Can add some test cases?

This change is relatively simple, but I don't know how to write concurrent tests. This scenario only occurs when polling task from multiple tables in the same OptimizingQueue simultaneously.

I couldn't reproduce this bug  locally. The main reason is that after this modification, If the clearProcess method is not called, it seems that we cannot make the tasks of other tables enter the optmizer.

Can add some test cases?

This change is relatively simple, but I don't know how to write concurrent tests. This scenario only occurs when polling task from multiple tables in the same OptimizingQueue simultaneously.

I couldn't reproduce this bug locally. The main reason is that after this modification, If the clearProcess method is not called, it seems that we cannot make the tasks of other tables enter the optmizer.

You are right, my modification is wrong.


SyntaxError: invalid syntax

Hi Austin,
I'd really like to use your script and I have almost no clue what I'm doing, but I've installed everything as per your instructions and now get an error when executing the file as follows:
File "discord_xbl_status.py", line 40
def init(self, config: XblPresenceMonitorConfig, event_loop=None):
^
SyntaxError: invalid syntax
Did I do something wrong and if so, how can it be fixed?

did you edit any of the text in that file at all?

No, only the text in the config file.

Hm. What version of python are you on? I just got this running a few minutes ago and it worked fine. Though I did have to modify that file a bit to remove a deprecated method further down. Check out my fork

Python v3.4
Downloaded your fork. Now I get this:
File "discord_xbl_status.py", line 7

^
SyntaxError: invalid syntax

What version of python?

I'm confused. Package manager says: Python v3.4
But when I run python it says: 2.7.6

Check your PATH variable. Make sure it's pointing to the newer python version

Would running "python3 discord_xbl_status.py" also work? Checking the PATH variable now.

It could, not terribly sure on that one.

Strange. No matter if I use your old or your new file, the error message is now a different one (< !DOCTYPE html>)

Man, I give up. Thanks for your help. I get the same error in Windows (Python 3.6) and Ubuntu (Python 3.4) now.
I desperately wanted this work, since its the only script of this kind I could find anywhere. So sad it's all so complicated :(

Sorry I couldn't help more. I'm not quite sure what the issue is.

Is the script working for you in both Windows and Linux (what distro do you use)?

I'm on Windows 10. I just ran it through the command line.


Lambda permission for API GW not properly set

See details in #6

I think the is closed given #6 is closed. Please reopen if it's not.


navigator.init() crashes

Hi,
I have bluerobotics-navigator 0.0.2 installed on the following Rpi

Linux rpi 5.10.33-v8+ #1415 SMP PREEMPT Fri Apr 30 15:53:26 BST 2021 aarch64 GNU/Linux

but run into this error when running bluerobotics_navigator.init()
~ $ python
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bluerobotics_navigator as navigator
>>> navigator.init()
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/navigator-rs-0.3.0/src/lib.rs:278:45
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
pyo3_runtime.PanicException: called `Result::unwrap()` on an `Err` value: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

any ideas what we can do to make it work?
The navigator board works and the navigator library work fine in the webapp terminal of BlueOS 1.1.1 ...
cheers,
dom

Hi @DRL,
I've updated the README with the instructions provided by email to set up the overlays.
Can we confirm that the scripts fixed those issues?
We are working to deploy the newer version with PWM relay mode and a leak sensor.

Hi @RaulTrombin,
yes, I can confirm that these instructions solve the issue.
Thank you,
dom


Add linkifyjs ES6 module build

This allows consumers to use ES6 imports in the browser.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 92.974%

Totals

Change from base Build<PHONE_NUMBER>:
-0.08%

Covered Lines:
846

Relevant Lines:
879

💛  - Coveralls


Convert TinyPerson annotation to YoloV8 format

Hello!
May i know how to understand the annotation format of the tinyPersons dataset ?
I want to convert to YoloV8, however, seem to have some problems. I found some links online such this https://universe.roboflow.com/chris-d-dbyby/tinyperson/dataset/5 on Roboflow, but it does not seem to be correct.
May i understand what is the annotation format for TinyPersons?
Thanks you!

Hello!
May i know how to understand the annotation format of the tinyPersons dataset ?
I want to convert to YoloV8, however, seem to have some problems. I found some links online such this https://universe.roboflow.com/chris-d-dbyby/tinyperson/dataset/5 on Roboflow, but it does not seem to be correct.
May i understand what is the annotation format for TinyPersons? Thanks you!

hello, have you solved this problem？i want to convert yolo format too

@Stray111 no I haven't solved it yet. I still can't decipher what do the annotations mean


Gemini pro 1.5 support?

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
A clear and concise description of what you want to happen.
Since gemini 1.5 (vertex ai) now has access to function calling, i was wondering if it was possible for it to be implemented on this system.
Additional context
Gemini 1.5 has access to OpenAPI Spec function calling like OpenAI, and gemini only requires 1 model for vision and language, rather than openai needing two. You can have a far bigger chat history with context, upload files like pdfs and have access to a better system prompt.
https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/function-calling
https://cloud.google.com/vertex-ai/generative-ai/docs/model-reference/function-calling
https://cloud.google.com/python/docs/reference/aiplatform/latest/vertexai
to use this you need the gemini-1.5-pro-preview-0409.
if it is not possible using the 1.5 model, you can use the gemini-1.0-pro-001 or gemini-1.0-pro-002 models respectively.
if needing help with this, e.g: accessing the api, i'd be more than willing to help.
@small-cactus

From the documentation you provided, the API schema and overall how it
works compared to the OpenAI API is very different. One example is that the
vertex api wants you to list the tool list json inside the function itself,
id have to rewrite the tool logic to implement Gemini support.
If you could prove me wrong and show a more compatible method or a way to
bridge both apis into one easily, that would be great.
On Mon, Apr 15, 2024 at 6:10 AM Josh @.***> wrote:

By the way, function calling supports both prompt turn and chat turn
models.
—
Reply to this email directly, view it on GitHub
https://github.com/small-cactus/M.I.L.E.S/issues/10#issuecomment-2056453241,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A57SAQN5I75COBVO2JLMQKLY5ORQ5AVCNFSM6AAAAABGHAMSWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWGQ2TGMRUGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Adding that support would be out of the scope of my skills, I've played around with gemini as a voice assistant and it's not viable, so I don't see value in adding it, there are many reasons, here are some I can name off the top of my head:
All gemini models tend to over explain and don't know when to "shut up". Eg they over explain everything and add extra sentences when not necessary. It'll give you the answer in the first sentence, and then keep talking and talking and talking for like 4 more paragraphs.
Gemini models do not follow instructions very well, they act non deterministic.
Gemini models are trained on VASTLY different training data sets from ChatGPT models, so my entire system prompt would be useless for ideal performance.
Response times are very slow, sometimes it can be fast, but again, they over explain and run time up, a 1 second delay is the difference between a slow reply and thinking that it stopped working.
Believe it or not, OpenAI models are trained to be spoken to, the response format fits perfectly with spoken language, Gemini models are fine in this regard, but it's really not the best. They also don't pay attention to the system instructions enough to understand that I put "You are talking to the user in a voice conversation" into the prompt.
But you are extremely welcome to fork and try to add gemini support, any details you need, I can help with and I will provide them. Here's some stuff to get you started, all tools are located in tools.json, the actual functions to correspond to these arrays are located in main.py randomly within the code (bad I know). The only part you should have to modify is the change AI model function, and "maybe" the change personality function, because it changes the system prompt and I don't know if the format is the same.
Other than that, all openai code (besides webcam recognition) is within the ask function. Let me know if you need anything else!

I think im gonna use groq's API as they have native function calling support using OpenAI's schema for other models


[help wanted] any way to update learning rate and momentum

Hi, I am reading a tutorial with nolearn/lasagne, where the author point out it is possible to update learning rate and momentum over time.
Is it possible to do it in keras? The coverage speed is low, so I am wondering whether it's possible to use the technique to improve the speed.

Look at the decay parameter in SGD to get a decreasing learning rate over time.
Otherwise, you can manually set sgd.momentum, sgd.lr and sgd.decay (where sgd is an instance of SGD). Note that sgd.lr is the base learning rate, not the actual learning rate, ie. it is the learning rate before decay is applied.

How is the decay applied to the learning rate?  Is it multiplied by the decay factor after each epoch?  Is the decay subtracted from it?  Is it exponential?


Question: Is there a way to validate lwm2m object definition in json format?

I am looking for a json schema that is similar to http://openmobilealliance.org/tech/profiles/LWM2M.xsd but used for json instead of xml object definitions.
But I can't seem to find it. It would be used to validate that something like below is well formed
{
    "name": "Test Meter",
    "id": 666,
    "instancetype": "mulitple",
    "mandatory": false,
    "description": "",
    "resourcedefs": [
      {
        "id": 0,
        "name": "Pressure",
        "operations": "RW",
        "instancetype": "single",
        "mandatory": true,
        "type": "float",
        "range": "",
        "units": "",
        "description": ""
      }
    ]
  };

For your information, I would use the jsonschema file to prevalidate any object models before it is imported to the server. (Via a node.js script)

Reference:

Object model in java is located in leshan-core/src/main/java/org/eclipse/leshan/core/model/ObjectModel.java

Object Definition in XML format is parsed in leshan-core/src/main/java/org/eclipse/leshan/core/model/DDFFileParser.java

Models are loaded via leshan-core/src/main/java/org/eclipse/leshan/core/model/ObjectLoader.java

There is no json schema :/
The json format was introduce at the beginning because of legal issue about xml object definitions format from OMA.
Now xml files can be reused without constraints, json format is deprecated. I mean there is no needs to support another format than the one supported by OMA.

I see. Then is there a way to migrate existing json models to XML instead?

I feel we can close this issue.


Do not playback videos after finishing

I have another issue for which I have simply removed the last lines of the code.
The problem: I use auto-editor mainly for creating screencasts. I record 2 to 5 minutes of screen activity (explaining something) in which I pause often to think what to say next. All the pauses are then removed by auto-editor. Which is great. When I am finished with a clip I immediately start the next recording, while auto-editor is working on the current one. I created a script for that in which each recording is put into a queue directory and processed. Since I have 16 cores I can sometimes process 5 videos at once.
That said, it is very irritating when a video just starts because it is finished rendering. I think this should not be the default behavior or it should at least be configurable.

I added the --no_open option that stops the program from starting videos.
Thanks for the suggestion :)


Mobile local dev: Adding mobile connection workers

Contributions: We are not currently taking public contributions - see our contributions policy. However, we are accepting issues and we do want your feedback.

Description
This PR adds MobileWorkerConnector to be used as a base for mobile Connectors. It also integrates it into Playground along with necessary logic
Tests
Tested along with other PRs in mobile_merge on iOS and Android devices and simulators
Documentation
Primary reviewers
cc @DanailPenev

This PR is now updated with all the feedback received. We now have 2 separate worker types for Android and iOS. The weird class tree was simplified by having the same code in the AndroidClientWorkerConnector and the iOSClientWorkerConnector. Exceptions were updated to be more accurate. Finally, the splash screen logic was moved into a separate prefab that spawns the relevant worker type and disposes of it if it fails.


feat(bump): update upjet, and deps

Description of your changes
implement latest changes from upjet
add management policies (https://github.com/upbound/upjet/pull/248)

Fixes #
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

i use the following WorkspaceStore config:
		WorkspaceStore: terraform.NewWorkspaceStore(log, terraform.WithFeatures(featureFlags)),

and the e2e uptests green:
--- PASS: kuttl (37.35s)
    --- PASS: kuttl/harness (0.00s)
        --- PASS: kuttl/harness/case (36.42s)
PASS
20:05:14 [ OK ] running automated tests

if i use the following WorkspaceStore config:
		WorkspaceStore: terraform.NewWorkspaceStore(log, terraform.WithDisableInit(len(*nativeProviderPath) != 0), terraform.WithProcessReportInterval(*pollInterval), terraform.WithFeatures(featureFlags)),

i get the follwoing error in managedResource:
apiVersion: v1
items:
- apiVersion: null.template.upbound.io/v1alpha1
  kind: Resource
  metadata:
    annotations:
      upjet.upbound.io/test: "true"
    creationTimestamp: "2023-08-03T17:58:02Z"
    generation: 1
    name: example
    resourceVersion: "801"
    uid: 041f86b8-c9eb-4b2f-a4b5-b486828a7784
  spec:
    deletionPolicy: Delete
    forProvider:
      triggers:
        example-trigger: example-value
    managementPolicies:
    - '*'
    providerConfigRef:
      name: default
  status:
    atProvider: {}
    conditions:
    - lastTransitionTime: "2023-08-03T17:58:03Z"
      message: |-
        observe failed: cannot run refresh: refresh failed: Inconsistent dependency lock file: The following dependency selections recorded in the lock file are inconsistent with the current configuration:
          - provider registry.terraform.io/hashicorp/null: required by this configuration but no version is selected

        To make the initial dependency selections that will initialize the dependency lock file, run:
          terraform init
      reason: ReconcileError
      status: "False"
      type: Synced
kind: List
metadata:
  resourceVersion: ""

Seems somehow connected with adding the terraform.WithDisableInit(len(*nativeProviderPath) != 0) but I am not that familiar with that feature. Maybe @ulucinar can shead some light on it?

Hi folks,
The template provider does not use the shared gRPC server and instead, relies on the Terraform CLI to manage the lifecycle of the native provider process. Thus, we cannot use terraform.WithDisableInit(true) with the template provider. This option causes the provider to skip running a terraform init during the workspace initialization, and hence the error observed by @haarchri. We can skip running a terraform init only with the shared gRPC implementation.

so then everything is fine with this PR - can i get a review @ulucinar  ;)


feat: add option and interface for @ionic/vue global config

Close #37

Thank you so much for your great work on this ❤


How to do localization

For the build tasks, I have found from the tasks repo that the task.json must have a task.loc.json with id like ms-resource:loc. instead of the resources, and a bunch of localized .resjson files in the folder Strings/resources.resjson/.
But I have found nothing for UI like the ones in this repository.
Is there any documentation or process to localize these parts?

I will continue to pay attention to this matter


Some Stuff in Taskbar wont maximize

Hi there! I am running the latest version of cairo, and some software cant be maximized again after minimizing to the taskbar.
For this software I need to use Alt + Tab for changing the current window.
Software I noticed it:

Ryzen Master (in very few cases it worked maximizing, mostly not)
some Games (Assasins Creed Origins)
Latency Mon

If I can help in someway just tell me what I have to do to provide more information. (logs, etc)

This generally happens when the program is running with elevated privileges. Are these applications being run as administrator by chance?


GEP: Conditions and Status update

We currently have a lot of outstanding issues related to status, mostly around Conditions, whether it be issues with specific Conditions being hard to understand, or general issues around Conditions. It's just because a lot of the status and Conditions design has grown very organically, what we effectively need is a design pass to make sure everything is consistent. There have been a few looks at this previously, but nothing coordinated across the whole API.
This issue covers a review of all the outstanding status issues, figuring out which ones relate, generating a TODO list, and then writing a GEP to cover all the changes.
Based on my initial quick pass, I think it's likely that this will include changes that will break conformance, but I think the longer we leave this, the worse the changes will be.
I propose making this a blocker for v0.6.0 release, so that we can get the pain out of the way now, and move forward with a consistent view of how our status flows work.
Here's my initial notes from doing a quick issue roundup.
Rough initial notes to link in relevant issues
In general, we need to make sure we're reusing the same Condition types across different resources, and that they have the same or similar definitions across resources as well.
The biggest review to date was #1111, and there are still some outstanding items from that.
GatewayClass has Accepted. This seems well-defined.
Gateway has Ready, which has significant issues, see #1156. This probably needs a follow-up to describe the change.
I think we definitely need to have a better description of what Ready means, and ensure that the definitions are consistent. @evankanderson has raised that it would be really useful for knative's use case for Ready to mean "Ready to pass traffic as soon as it's set", but I don't know the extent to which we can mandate that. We may be stuck with setting a "Ready means will be ready in <5sec" or something, but that will require implementation feedback.
We need to move the Listener condition to Attached instead of Detached, as described in #1110. Having a small set of standard positive-polarity (that is, they are status: true if everything is good) Conditions is useful, and similar things should have similar names.
#1112 also needs to be updated post the closing of #1211.
We also need to note if conditions should be added if they are in a happy state. The latest comments on #1315 is talking about this.
Personally, I prefer that conditions are always added, even if they are Unknown, but this one needs discussion.
#1362 should probably also be done as part of this.

I was initially going to create a new issue for this, but will start here for now since I know this is meant to be a bit of an umbrella issue.
Closely related to your comments about a "Ready" condition on HTTPRoute, I think we really need something to fill the gap in our current conformance tests here. Currently we're limited to an "Accepted" condition with a rather vague definition:
https://github.com/kubernetes-sigs/gateway-api/blob/eba0e7ebb266c351ba11d5c0c8302ac0313c817e/apis/v1beta1/shared_types.go#L190-L191
Unfortunately we're using that condition as a signal that HTTPRoutes are ready for conformance tests:
https://github.com/kubernetes-sigs/gateway-api/blob/eba0e7ebb266c351ba11d5c0c8302ac0313c817e/conformance/utils/kubernetes/helpers.go#L167-L169
That usually starts the 30 second timer for MakeRequestAndExpectEventuallyConsistentResponse. Unfortunately some implementations are going to have a longer gap than that between when they've "Accepted" a Route and when they've "Reconciled" it, unless we should be interpreting "Accepted" to also mean "Reconciled".  It seems like we need to:

More clearly define what "Accepted" means for Routes
Add a new Route condition (Reconciled, Ready, or similar) that conformance tests wait for before making HTTP requests

I'm glad you brought that one up Rob, as that's been one on my mind as well.
Right now I would personally characterize Accepted as also meaning Reconciled, at least colloquially. Defining it as anything else seems difficult because all implementations universally have a sense of "the dataplane has been configured" but everything in between that, and even some of the stuff after that seems more dubious as far as universality.
Do you think it's on the table to increase the timeout to something that supports all known implementations, and simply defining it as "configured in dataplane"?

Do you think it's on the table to increase the timeout to something that supports all known implementations, and simply defining it as "configured in dataplane"?

I think we probably need some change like this for conformance. The amount of time it takes for these changes to propagate is wildly dependent on what's being configure. For example, if we're rolling out changes globally, it may take longer for them to reach certain regions. We already allow these timeout to be configurable, maybe we just need to remove or increase the max value that we consider conformant here:
https://github.com/kubernetes-sigs/gateway-api/blob/eba0e7ebb266c351ba11d5c0c8302ac0313c817e/conformance/utils/config/timeout.go#L59

I have a somewhat-related concern, based on past history with different envoy-based implementations.
In some implementations, adding a new percentage rule with a new backend pool to an existing HTTPRoute can cause traffic to be dropped with 500s (no healthy upstream). The root cause is that the new route definitions arrive at some envoy pods before the cluster definitions do, and when traffic arrives at that route, there's no corresponding backend programmed.
It would be nice to have a set of rules as to when / how to avoid this scenario (dropping traffic on an already-programmed route when making changes). Per-implementation workarounds are going to be less fun in a Gateway world where e.g. Knative wants to be aware of a single abstraction, rather than inventorying all known implementations.
I mention this in the context of conditions as it seems like the might be Conditions involved in the solution to "don't drop traffic when adding backends under load".

Do you think it's on the table to increase the timeout to something that supports all known implementations, and simply defining it as "configured in dataplane"?

I think we probably need some change like this for conformance. The amount of time it takes for these changes to propagate is wildly dependent on what's being configured. For example, if we're rolling out changes globally, it may take longer for them to reach certain regions. We already allow these timeout to be configurable, maybe we just need to remove or increase the max value that we consider conformant here:
https://github.com/kubernetes-sigs/gateway-api/blob/eba0e7ebb266c351ba11d5c0c8302ac0313c817e/conformance/utils/config/timeout.go#L59

Would a Ready congestion separate from Accepted/Reconciled allow implementations to choose that 30s value for themselves? (Yes)
I think the question is whether implementations would know that timing duration themselves (i.e. it might differ depending on the number and location of nodes).

Okay, I've spent a whole lot of time reading through issues, code, and docs, and here are my current suggestions. I've bucketed them into more general things and specific things.
General things
We should make sure that, as far as possible, Conditions should have similar names and flow for each resource.
We should mandate the use of observedGeneration for Conditions, and check that it's set correctly in conformance. This gives the conditions a built-in staleness check with respect to spec, but is less helpful when other changes may trigger Condition changes (think here of Ready flapping if the dataplane breaks).
We should cover at least two states with positive-polarity, "check" conditions:

Accepted or Reconciled, or Attached, which mean that the resource has been seen by the controller and fits into a set of related Gateway API resources that are syntactically and semantically valid.
Ready, Programmed, or simlar, which mean that the resources have been scheduled, programmed, or otherwise provisioned onto underlying infrastructure and are either ready now or will be soon (where "soon" is currently TBD, but will be clearly defined and included in conformance). Note that this particular Condition may change state if the state of underlying infrastructure changes, so observedGeneration is le

Other Conditions can be used, but must be negative-polarity, "error" conditions that describe specific error states that are not recoverable without human intervention. In general, these should add more information to the boolean "something is broken" information you will get from the positive-polarity summary Conditions. Existing examples here are ResolvedRefs or Conflicted.
Specific things
Gateway
Addresses field in GatewaySpec needs an update to be explicit about Conditions.
Hostname field in the Listener struct needs an update to specify the Conditions in the hostname match failed case.
AllowedRoutes in Listener should also be updated to have details about what happens in the cases of various number of routes being included and invalid:

No valid routes attached.
All routes attached are valid.
At least one valid route is attached, and 1 or more invalid routes are attached.
Is a Route with 0 valid rules valid? I'm incined to say yes.
(This should address #1112 )

Route
The RouteParentStatus Conditions field has a bunch of details about how to handle Conditions - these should be moved to the ParentRefs field of CommonRouteSpec.
HTTPRoute
HTTPRouteRule Rules stanza should have documentation about how to handle:

0 valid Rules
all valid rules
some valid rules, and some invalid.

(This should address #1112)
We should ensure that the existing backendRefs docs document this in a similar format.
backendRefs should also update with info about what Conditions to set in each case.
The same should be done for the rules that are still in v1alpha2.
ReferenceGrant
ReferenceGrant should have a status subresource added with a Condition that indicates if the resource is syntactically valid (probably Accepted). This needs an issue and agreement, and should probably block v0.6.0.

In some implementations, adding a new percentage rule with a new backend pool to an existing HTTPRoute can cause traffic to be dropped with 500s (no healthy upstream). The root cause is that the new route definitions arrive at some envoy pods before the cluster definitions do, and when traffic arrives at that route, there's no corresponding backend programmed.
It would be nice to have a set of rules as to when / how to avoid this scenario (dropping traffic on an already-programmed route when making changes). Per-implementation workarounds are going to be less fun in a Gateway world where e.g. Knative wants to be aware of a single abstraction, rather than inventorying all known implementations.

I agree that this is a problem, but I would like to sort out the basic flow first -  it's a little orthogonal to the main thrust of this issue (which is that what we have at the moment is very inconsistent across resources).
However, for Envoy-based implementations, this is all about ordering the cache updates or implementing ADS (which enforces ordering as well).

This is just an example, but the more we can use the same language to describe operations, the less conceptual overhead there is for using this API.

Big +1 to this ^

Accepted or Reconciled, or Attached, which mean that the resource has been seen by the controller and fits into a set of related Gateway API resources that are syntactically and semantically valid.

In #1111 I had initially considered whether Accepted and Attached would mean the same thing (and thus want to remove one of them), but I think the discussion in https://github.com/kubernetes-sigs/gateway-api/pull/1085#discussion_r931212794 proposes a clear distinction between the two and a use case where they may be set to different values. Agreed about language referring to route/policy "attachment" makes this all a bit unclear though.

This condition [Attached] indicates that, even though the listener is syntactically and semantically valid, the controller is not able to configure it on the underlying Gateway infrastructure.

https://github.com/kubernetes-sigs/gateway-api/issues/1031 is likely relevant here too for where this behavior should be documented.

With respect to observedGeneration, both Accepted and Ready might flip from True to Unknown or False without a spec change as other parts of a configuration tree change. (Deletion of a ReferenceGrant, for example.)

Other Conditions can be used, but must be negative-polarity, "error" conditions that describe specific error states that are not recoverable without human intervention. In general, these should add more information to the boolean "something is broken" information you will get from the positive-polarity summary Conditions. Existing examples here are ResolvedRefs or Conflicted.

Two notes here:

ResolvedRefs is positive, while Conflicted is negative. That's probably the high order bit to sort out.
If you mix positive and negative polarities. (Accepted and Ready are positive, others are negative), every UI which wants to display the status of Gateway resources as dots/check marks/etc will need to bake in that rule. "UI" here includes both web UIs as well as CLI tools.

Policy resources and ReferenceGrant resources may also be able to use Attached to describe the resources they attach to as metadata resources.

I think that you don't want Conditions on Policy resources. In particular, it's possible (and reasonable/handy) to have a ReferenceGrant which grants two different Gateway objects with different controllers access to all Services in a namespace.

One additional state that might or might not be Condition-worthy: when there is at least one resource which is blocked from attachment due to Policy (in comparison with "resource does not exist" reasons).
My rationale here is that debugging this kind of failure is likely to be common, and so a little guidance / hand-holding for new users / users in a rush might be helpful.
Maybe this is part of Accepted, but we should consider whether "Gateway references a non-existent Secret in a different namespace" is the same Condition / error message as "Gateway references a Secret in a namespace which it is not allowed to use".
Among other things, I'm guessing that the conformance spec might have different things to say about how the Gateway tree of configuration as a whole works in those error conditions.

One last thought:
Given the ability to delegate the configuration tree to different namespaces, you may want to provide different Condition views of the overall configuration tree on the HTTPRoute objects then on the Gateway object, for three reasons:

limit status updates on state change
avoid confusing/unable to assist failure reports when resources in a different namespace are broken
avoid leaking resource information between namespaces for users limited to a single namespace

I think any conditions we put on ReferenceGrant will need to be namespaced by controllerName, just like most of the other status.

Good thoughts as always, @evankanderson, much appreciated.

With respect to observedGeneration, both Accepted and Ready might flip from True to Unknown or False without a spec change as other parts of a configuration tree change. (Deletion of a ReferenceGrant, for example.)

I think we should work to try and make deletion of a ReferenceGrant not induce things to flip their Attached state - we've been moving in that direction a bit, but I think it's worth checking the rules for this specific case. If we can keep it that only Ready flips without a spec change, I think we're in a better place.
About Condition polarity:

Two notes here:

ResolvedRefs is positive, while Conflicted is negative. That's probably the high order bit to sort out.

Agreed.

If you mix positive and negative polarities. (Accepted and Ready are positive, others are negative), every UI which wants to display the status of Gateway resources as dots/check marks/etc will need to bake in that rule. "UI" here includes both web UIs as well as CLI tools.

In the absence of some way to tell which polarity Conditions are (if only someone had suggested doing that 😛 ), our options are either:

Mandate all positive Conditions
Allow mixed ones, and keep the number of positive ones low, and have common Types, so that UIs can special-case-handle them easily

I don't include "make them all negative" because that sounds even worse than what we have now.
The second option has definitely been my plan, on the assumption that we'll try and keep the number of condition Types relatively low as well, but particularly the positive polarity ones.
Thanks for the last thought about having HTTPRoute have a different view - I agree that the critical thing is that the HTTPRoute Conditions have the information that the HTTPRoute owner needs, and no more. HTTPRoute owners shouldn't be able to use the status to learn about things in another namespace they haven't asked to use.

Okay, I think the outstanding item here is for me to write a GEP that details the changes to be made. I'll skip the preliminary "what and why", "merge a preliminary GEP that doesn't discuss the how" stage, since I think we've hashed that out in this issue, and write a full GEP on this one, with as many changes as I can find all in one spot.

Okay, I've marked this issue as a GEP now, so I'll prepare a PR for GEP-1364 - Status and Conditions Update.

Should this be closed now that https://github.com/kubernetes-sigs/gateway-api/pull/1383 has merged, or should it stay open until implementation is complete?

Should this be closed now that https://github.com/kubernetes-sigs/gateway-api/pull/1383 has merged, or should it stay open until implementation is complete?

I'm not really sure what we should do. Generally we've been leaving these open until they're implemented and documented, but not until they reach beta/GA. In upstream (k/enhancements), tracking issues are left open for all KEPs until they are either removed or graduate to GA. We may want to move to that approach. I've got a related PR that tries to more clearly document our approach here: https://github.com/kubernetes-sigs/gateway-api/pull/1440.

If the dilemma is whether to keep it open until it releases, I say close it. It's tracked against v0.6.0 milestone that should be sufficient to indicate in what release it's done.

@shaneutt At a minimum, I want to leave a GEP tracking bug open until it's met the criteria to be released. If we close out without actually implementing or documenting it, we may accidentally release a feature that's only half of the way there.

relevant to this GEP/Issue: https://github.com/kubernetes-sigs/gateway-api/issues/1521

When #1540 merges, this is done enough that we can consider it implemented.


Move gravity api to kat5

[x] Provision
[x] Setup raidz
[x] Move gravity
[x] Change monitoring
[x] Redirect API

All activities completed.


Wip/cardiology intervals

I read through several instruction manuals / websites for at-home blood pressure measurements. All of them recommend taking your blood pressure twice a day so I targeted the multi-timer genie templates at 'twice a day' timers.
I then sent a survey to several groups of friends asking for natural language examples for taking a pill twice a day. I extended my templates to capture all the different variations they used in their phrasing.

Thanks for the feedback! I changed the second-person references to first-person references. I'm working on refactoring the rules to use nonterminals so as to utilize recursive expansion rather than sampling. As per your recommendation, I also plan on introducing a couple more relative times for a couple of the rules (such as "night" / "afternoon" / "school [start/end]" / "work [start/end]").
Combined with these relative times, if we limit ourselves to capturing only time phrases (such as "before work" / "before school") which are relatively universal and frequently used in communication, rather than attempting to consider all time phrases personal to a user (such as "before soccer practice" / "before dance"), then I think the set of time phrases we need to capture will be bounded (and not that big) and doable to cover. In my survey I sent out, only a select few time phrases were used (such as "before meals" / "when you brush your teeth" / "before work"), making them good candidates to cover in our timer syntax.

It would be interesting, as a future project, to also capture personal time phrases for the user. A virtual assistant should ideally include at least the core functions of a human assistant, such as keeping a calendar. We could allow the user to record calendar events on their virtual assistant and support commands referencing these events (e.g. If the user records an event of "Soccer practice on Mondays at 3 PM" then the virtual assistant will understand timer phrases such as "Before soccer practice"). After more thought, would be further interesting to integrate this, location data, and traffic data into a reminder system on Almond that sends event reminders to users at an early enough time that they arrive at their event on time, accounting for traffic between that event and their current location. Lots of cool things we could do with an integrated calendar system.

I merged this because today's feature freeze release day but more work will be needed before we'll enable this feature in the default model. Luckily, soon you will be able to experiment with this in production by uploading custom Genie template packs.


min max metric

Before submitting

[ ] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?

What does this PR do?
Fixes #49
PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

@SkafteNicki seems to be a duplicate to #506

@janhenriklambrechts how is it going here, ready for review?

@Borda not yet finished, but will work on it this afternoon -- so expect a clean PR by tomorrow :)

@SkafteNicki mind have look ^^ :rabbit:


[Bug?] Say to latest release is not up to date

https://imgur.com/a/LRqm03e

Literally missed this, is the bug still an issue?

Are you using that in pterodactyl? If not it looks like you just need to install jq


Diagnostic logs in Virtual Machine Scale Sets should be enabled

Hello,
I found one problem with the warning "Diagnostic logs in Virtual Machine Scale Sets should be enabled". It can't be fixed for VMSS with 0 instances.

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

ID: b9d7741b-cd5a-29b0-c360-e054f7686c87
Version Independent ID: f03434f5-504a-d87f-b9ce-3ed695db9227
Content: Secure score in Azure Security Center
Content Source: articles/security-center/secure-score-security-controls.md
Service: security-center
GitHub Login: @memildin
Microsoft Alias: memildin

@MasterKolka
Thanks for your feedback! We will investigate and update as appropriate.

Thanks! I made a pull request to update this. @memildin please confirm
https://github.com/MicrosoftDocs/azure-docs-pr/pull/163651


Sy preview : Loading animation not shown

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to version 1.7.0.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

Tachiyomi version
R399
Android version
Android 10
Device
Aosp rom
Steps to reproduce
Open one chapter in any manga
Expected behavior
There's should appear loading animation
Actual behavior
Loading animation not shown
Crash logs
No response
Other details
https://user-images.githubusercontent.com/81817527/126860788-93122ae3-b2a0-41f1-90df-87480dfd7cab.mp4

Main tachi is doing weird stuff with the loading animations


Misc enhancements

Use python-requests instead of firing up curl and wget
Removed the attachment contents download logic from bzxmltophill by making downloadbzbugs ensure they are available as files
Work around the Bugzilla limit of 10000 result rows when retrieving the list of bugs
Split bugs retrieval in batches to handle big projects
Resumable downloads
Misc fixes

Thanks a lot for that!
I would rather use phabricator to manage that project -- could you please provide the patches there with git phab?
Thanks! :)

Sure! Submitted as T3520.


Frontend container returns 404 for routes

Problem
If a user navigates to a url (that is not the index) then the frontend container returns 404.
Solution
Return the index for all routes.

@jrw972
I'm running docker run -p 80:80 libre311-frontend-image
I go to localhost:80 but I see a blank white screen and in the console see this
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.

Thanks for testing this.  I think I know the problem.

@JackDiSalvatore Can you review this again?


Different binding for "," — comma key.

In case of english keyboard, all working, as expected.
But for users with different languages there is a problem, that on place of comma can be another letter.
Example: russian "б"
Maybe it should bind not keyCodes, but exactly symbols?
Btw, many thanks for this directive!

same issue! , is not binding in russian keyboard

👍 I'lve got this issue tooo

same issue.
now i find a temporary solution: add-on-comma="false".
russian "б" is worked, but entering "," not add entered text as new tag...

I fixed the stuff manually within the code.

Unfortunately, the previous fix doesn't work for me, so I have made another change here.