[Core] Changes to support 0.2.0 flashinfer

Dataype and wrapper changes for 0.2.0 flashinfer
Related: #11194

I found flashinfer 0.2.0 uses more memory on rank 0 when tp>1. I built it from source with AOT mode. Is that normal?

@JaheimLee Seems like we have a fix, we'll update to Flashinfer 0.2.0.post1. Thanks

@JaheimLee Seems like we have a fix, we'll update to Flashinfer 0.2.0.post1. Thanks

Still have this problem. And I got another error
INFO 12-25 22:54:21 config.py:478] This model supports multiple tasks: {'generate', 'score', 'classify', 'reward', 'embed'}. Defaulting to 'generate'.
INFO 12-25 22:54:22 awq_marlin.py:109] The model is convertible to awq_marlin during runtime. Using awq_marlin kernel.
INFO 12-25 22:54:22 config.py:925] Using fp8 data type to store kv cache. It reduces the GPU memory footprint and boosts the performance. Meanwhile, it may cause accuracy drop without a proper scaling factor
INFO 12-25 22:54:22 config.py:1216] Defaulting to use mp for distributed inference
WARNING 12-25 22:54:22 cuda.py:98] To see benefits of async output processing, enable CUDA graph. Since, enforce-eager is enabled, async output processor cannot be used
WARNING 12-25 22:54:22 config.py:604] Async output processing is not supported on the current platform type cuda.
INFO 12-25 22:54:22 llm_engine.py:249] Initializing an LLM engine (v0.6.5) with config: model='/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ', speculative_config=None, tokenizer='/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.float16, max_seq_len=32768, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=2, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=awq_marlin, enforce_eager=True, kv_cache_dtype=fp8, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='xgrammar'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ, num_scheduler_steps=8, multi_step_stream_outputs=True, enable_prefix_caching=True, chunked_prefill_enabled=False, use_async_output_proc=False, mm_cache_preprocessor=False, mm_processor_kwargs=None, pooler_config=None, compilation_config={"splitting_ops":["vllm.unified_attention","vllm.unified_attention_with_output"],"candidate_compile_sizes":[],"compile_sizes":[],"capture_sizes":[],"max_capture_size":0}, use_cached_outputs=False,
WARNING 12-25 22:54:22 multiproc_worker_utils.py:280] CUDA was previously initialized. We must use the `spawn` multiprocessing start method. Setting VLLM_WORKER_MULTIPROC_METHOD to 'spawn'. See https://docs.vllm.ai/en/latest/getting_started/debugging.html#python-multiprocessing for more information.
WARNING 12-25 22:54:22 multiproc_worker_utils.py:312] Reducing Torch parallelism from 28 threads to 1 to avoid unnecessary CPU contention. Set OMP_NUM_THREADS in the external environment to tune this value as needed.
INFO 12-25 22:54:22 custom_cache_manager.py:17] Setting Triton cache manager to: vllm.triton_utils.custom_cache_manager:CustomCacheManager
INFO 12-25 22:54:22 selector.py:155] Using Flashinfer backend.
WARNING 12-25 22:54:22 registry.py:262] `mm_limits` has already been set for model=/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ, and will be overwritten by the new values.
INFO 12-25 22:54:37 config.py:478] This model supports multiple tasks: {'generate', 'classify', 'score', 'reward', 'embed'}. Defaulting to 'generate'.
INFO 12-25 22:54:38 awq_marlin.py:109] The model is convertible to awq_marlin during runtime. Using awq_marlin kernel.
INFO 12-25 22:54:38 config.py:925] Using fp8 data type to store kv cache. It reduces the GPU memory footprint and boosts the performance. Meanwhile, it may cause accuracy drop without a proper scaling factor
INFO 12-25 22:54:38 config.py:1216] Defaulting to use mp for distributed inference
WARNING 12-25 22:54:38 cuda.py:98] To see benefits of async output processing, enable CUDA graph. Since, enforce-eager is enabled, async output processor cannot be used
WARNING 12-25 22:54:38 config.py:604] Async output processing is not supported on the current platform type cuda.
INFO 12-25 22:54:38 llm_engine.py:249] Initializing an LLM engine (v0.6.5) with config: model='/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ', speculative_config=None, tokenizer='/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.float16, max_seq_len=32768, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=2, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=awq_marlin, enforce_eager=True, kv_cache_dtype=fp8, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='xgrammar'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=/data/pretrained_models/Qwen2.5-72B-Instruct-AWQ, num_scheduler_steps=8, multi_step_stream_outputs=True, enable_prefix_caching=True, chunked_prefill_enabled=False, use_async_output_proc=False, mm_cache_preprocessor=False, mm_processor_kwargs=None, pooler_config=None, compilation_config={"splitting_ops":["vllm.unified_attention","vllm.unified_attention_with_output"],"candidate_compile_sizes":[],"compile_sizes":[],"capture_sizes":[],"max_capture_size":0}, use_cached_outputs=False,
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 122, in spawn_main
    exitcode = _main(fd, parent_sentinel)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 131, in _main
    prepare(preparation_data)
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 246, in prepare
    _fixup_main_from_path(data['init_main_from_path'])
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
    main_content = runpy.run_path(main_path,
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen runpy>", line 287, in run_path
  File "<frozen runpy>", line 98, in _run_module_code
  File "<frozen runpy>", line 88, in _run_code
  File "/data/lijinghui/uv_projects/LLM/test.py", line 19, in <module>
    llm = LLM(
          ^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/utils.py", line 990, in inner
    return fn(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/entrypoints/llm.py", line 230, in __init__
    self.llm_engine = self.engine_class.from_engine_args(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/engine/llm_engine.py", line 532, in from_engine_args
    engine = cls(
             ^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/engine/llm_engine.py", line 288, in __init__
    self.model_executor = executor_class(vllm_config=vllm_config, )
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/executor/distributed_gpu_executor.py", line 26, in __init__
    super().__init__(*args, **kwargs)
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/executor/executor_base.py", line 36, in __init__
    self._init_executor()
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/executor/multiproc_gpu_executor.py", line 58, in _init_executor
    worker = ProcessWorkerWrapper(
             ^^^^^^^^^^^^^^^^^^^^^
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/executor/multiproc_worker_utils.py", line 167, in __init__
    self.process.start()
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ^^^^^^^^^^^^^^^^^
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/context.py", line 289, in _Popen
    return Popen(process_obj)
           ^^^^^^^^^^^^^^^^^^
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/popen_spawn_posix.py", line 42, in _launch
    prep_data = spawn.get_preparation_data(process_obj._name)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 164, in get_preparation_data
    _check_not_importing_main()
  File "/home/mosh/.local/share/uv/python/cpython-3.12.7-linux-x86_64-gnu/lib/python3.12/multiprocessing/spawn.py", line 140, in _check_not_importing_main
    raise RuntimeError('''
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
        in the main module:

            if __name__ == '__main__':
                freeze_support()
                ...

        The "freeze_support()" line can be omitted if the program
        is not going to be frozen to produce an executable.

        To fix this issue, refer to the "Safe importing of main module"
        section in https://docs.python.org/3/library/multiprocessing.html

Exception ignored in: <function LLM.__del__ at 0x7f1a6c5fc180>
Traceback (most recent call last):
  File "/data/lijinghui/uv_projects/.venv/lib/python3.12/site-packages/vllm/entrypoints/llm.py", line 236, in __del__
    if self.llm_engine and hasattr(self.llm_engine, "shutdown"):
       ^^^^^^^^^^^^^^^
AttributeError: 'LLM' object has no attribute 'llm_engine'
ERROR 12-25 22:54:39 multiproc_worker_utils.py:123] Worker VllmWorkerProcess pid 2759640 died, exit code: 1
INFO 12-25 22:54:39 multiproc_worker_utils.py:127] Killing local vLLM worker processes

Here is my code
import os
os.environ["CUDA_VISIBLE_DEVICES"] = "0,1"
os.environ["VLLM_ATTENTION_BACKEND"] = "FLASHINFER"
os.environ["VLLM_USE_FLASHINFER_SAMPLER"] = "1"
from transformers import AutoTokenizer
from vllm import LLM, SamplingParams

model_name = "Qwen2.5-72B-Instruct-AWQ"
model_path = os.path.join("/data/pretrained_models", model_name)
# Initialize the tokenizer
tokenizer = AutoTokenizer.from_pretrained(model_path)

# Pass the default decoding hyperparameters of Qwen2.5-7B-Instruct
# max_tokens is for the maximum length for generation.
sampling_params = SamplingParams(temperature=0.7, top_p=0.8, repetition_penalty=1.05, max_tokens=512)

# Input the model name or path. Can be GPTQ or AWQ models.
llm = LLM(
    model=model_path,
    gpu_memory_utilization=0.97,
    tensor_parallel_size=2,
    kv_cache_dtype="fp8",
    enforce_eager=True,
    enable_prefix_caching=True,
    num_scheduler_steps=8,
)

# Prepare your prompts
prompt = "Tell me something about large language models."
messages = [
    {"role": "system", "content": "You are Qwen, created by Alibaba Cloud. You are a helpful assistant."},
    {"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True
)

# generate outputs
outputs = llm.generate([text], sampling_params)

# Print the outputs.
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")


As a manager, I want a way to update the status of or send communications to batches of submissions at a time

This is planned to be covered in the work we are doing in the Winter 2019 Sprints. Adding to project board.
Note, we were not planning to cover communications as batch actions. @danblah what is the use case for this?


chore: use Apache 2.0 license

See discussions in #35
cc @lalicw

@tbouffard @tbouffard  This is a good step forwards, but note there were some examples which were under the new license that will need to be reverted to the revision before the change away from the Apache license.
I think it'd be a good idea to change the notices in each source file to say something like "Converted to TypeScript and maintained by the maxGraph project. See also CONTRIBUTORS.md for more info". I originally put some notices saying I made modifications to be in line with the 4b section of the Apache license ("You must cause any modified files to carry prominent notices stating that You changed the files;") but I think it could be remove these and put who has made which changes in a different file.
(Sorry for not being active lately btw - haven't been working on any projects in last month or two. Started working to convert the styles to objects a few times but didn't follow throug. @junsikshim I think your changes are pretty similar to what I had in mind and are likely some of the last major things needed before a release. I'd like to do some documentation-related things explaining what maxGraph does on the front page if I have time - some people I referred this project to didn't immediately understand possible use cases for this library before I explained to them from the current README.md, and think it could be good to put a description of the project at the top of this page possibly together with a hosted storybook instance to show its capabilities.)

Putting back to Draft until we consider the updates proposed by https://github.com/maxGraph/maxGraph/pull/85#issuecomment-1120377371

Closed because a much larger plan is decided. See #89


App can't be resized to 1/3 screen width

Summary
On macOS, the Mattermost desktop application won't allow itself to be resized to 1/3 of the screen width; this breaks "thirds" tiling in e.g. Rectangle.
Steps to reproduce

Install Mattermost 5.3.1 on macOS 13.4.
Open Mattermost and log in.
Set screen resolution either to 1800x1169, or the default of 1512x982.
Drag the edge of the Mattermost window and attempt to resize to 1/3 of the screen width.

Expected behavior
I expect the window to resize as directed.
Observed behavior (that appears unintentional)
The window refuses to resize below a certain point; the resize pointer remains, but the window just stops resizing.

@duncan-bayne I've transferred this issue over to the Desktop App repo since we're making changes here.
We did a quick UX review and were able to drop the minimum width down to 600px. This is the lowest we can currently go while still maintaining a good UX in the Desktop App, so I hope that helps a bit. We might be able to drop it down further in the future but this is what we can do for now.


Will inline properties conflict with props?

Clear and concise description of the problem
Maybe the props required by the component like left will be compiled into class by unocss

Foo
defineProps({left:0})

It may also generate the left:0 class on the foo container.
Suggested solution
There is a filter that can only enable the detection and conversion of attributes in class or className for the page, not for all attr.
{
  onlyClassDetection: {
    include: [],
    exclude: []
  }
}

Alternative
No response
Additional context
No response
Validations

[X] Read the Contributing Guidelines.
[X] Read the README.md of using the package.
[X] Already used the Interactive Docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

It sounds like you can use blocklist.

It sounds like you can use blocklist.

This should cause the global class to become unusable. I might just want it to be specific to individual pages, and I just want it to not take effect as an attribute, but I still need to keep it working within the class.

You don't need to disable globally: https://github.com/unocss/unocss/blob/f9a4e81dc20cea2f880b21aae99f0ac97fcbeb26/packages/preset-attributify/src/types.ts#L35-L39

You don't need to disable globally:
https://github.com/unocss/unocss/blob/f9a4e81dc20cea2f880b21aae99f0ac97fcbeb26/packages/preset-attributify/src/types.ts#L35-L39

This attribute is really helpful. This means that if I use ignoreAttributes:['left', 'top'], all left="" & top="" in the page will be invalid for unocss. It would be nice to have a more accurate one. Controls, for example, only for individual pages, their components may have props and unocss attribute conflicts. You need to enable this ignoreAttributes, otherwise, other pages that need to use the left or top as an attribute will lose this style.


Thanks！

I am looking forward to your work. It's so cool.If possible, could you please send the ultra-high precision model to<EMAIL_ADDRESS>Thank you！

Have you recieved the models?


Feature/sign up ui tweaks

Description
Fixes validation issues, along with UI tweaks.
https://trello.com/c/jw49RpdO/64-sign-up-sign-in
Type of change

[x] New feature (non-breaking change which adds functionality)

Change Status

[x] Complete, tested, ready to review and merge

How Has This Been Tested?

[x] Manual testing

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] There are no merge conflicts

 Sign Up/Sign In

 Sign Up/Sign In


Update the README to reflect both usage in the context of a Flogo app & the API

Current behavior (how does the issue manifest):
The current README only reflects getting started and usage via the API.
Expected behavior:
The README should capture all variants of usage, such as, within the context of a Flogo application leveraging the JSON DSL. We should also capture the usage around leveraging the streaming action along side the rules action in a single application.

PR #41


Do not use systemctl for checks inside chroot

All the systemctl commands used for that rollback
check are not valid inside a chroot. So just avoid
them and return false, to prevent unwanted rollbacks.

@yrobla this repository is being obsoleted.  If you still believe this PR should be included, please re-submit into https://github.com/openshift/cluster-node-tuning-operator/ .


Remove color argument to calls to Draw and asset methods

They cause unnecessary table allocations, and you can just use Draw.set_color() instead for slight performance gains from not having to set the color between multiple assets each time. It would be better if we used Draw.set_color() as the blessed way of setting colors. Also we should remove the option of passing a table argument to Draw.set_color() as well.
This really needs to be done before the API gets too popular.

Actually I think being able to pass a table to Draw.set_color() is very useful when used with the theme table returned by UiTheme.load(), so you could just do Draw.set_color(self.t.base.text_color). The real issue is with code that will allocate a table every frame because a table color constant was not bound to an upvalue outside :draw().


Replace node kind checks by InstanceOf checks

This allows better code analysis as every tool/IDE knows what object type goes into a condition branch

The switch (true) truly reads weird.
On a related note: shouldn't all those switch statements have a "default: throw…" case? I noticed some have, some don't (I know, existing code).

Yup, it is indeed but PHP has no better way yet (though I believe it might be changed in the future).
I suppose I could add a default throw, that would make sense as all logical branches would be covered then 👍

Seems like default: throw... statemens are not there for a reason (eg. they're handled later).

Ops 🤷♀ Who would knew…

One reason why instanceof checks were not used there in the first place was performance. I was 100% sure that strict equality checks were faster than instanceof.
So changes like this do require some benchmarking (and we don't have a good enough benchmark for such things in our phpbench yet). I think we need some bench for a query with ~2000 field calls (and ideally make sure all changed paths are affected).
Those micro-optimizations seem minor, but when we sum them up and then multiply x 1000 (or more) - it becomes noticeable.

Started with a micro benchmark
<?php

class A
{
    public $kind = 'A';
}

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $a = new A();

    if ($a instanceof A) {
    }
}
var_dump(microtime(true) - $s);

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $a = new A();

    if ($a->kind === 'A') {
    }
}
var_dump(microtime(true) - $s);

On PHP 7.2
double(7.4557127952576)

double(7.6205501556396)

wow, why do our numbers differ so much?
php -v
PHP 7.2.10-0ubuntu<IP_ADDRESS> (cli) (built: Sep 13 2018 13:45:02) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
$ php bench.php
float(0.53607106208801)
float(0.6186990737915)
$ php bench.php
float(0.49281096458435)
float(0.59114003181458)
$ php bench.php
float(0.4991409778595)
float(0.6029200553894)

But yeah, instanceof seems to be fater.
Did you maybe forget a 0? In that case I get:
$ php bench.php
float(5.1001918315887)
float(6.1185019016266)

Left xdebug enabled ;) With php -n having similar numbers

@vladar just checked HugeSchemaBench and it seems that it does query operations on huge schema 🤔

Those benches just test instanceof hits, not misses. There are actually several use cases we need to bench: hits, misses, hits and misses on the parent type (like a extends b, $a instanceof b). I think the latest one is the one we actually use the most.

What about this
<?php

class A
{
    public $kind = 'A';
}

class B extends A
{
}

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $b = new B();

    if ($b instanceof A) {
    }
}
var_dump(microtime(true) - $s);

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $b = new B();

    if ($b->kind === 'A') {
    }
}
var_dump(microtime(true) - $s);

float(0.54834389686584)
float(0.62606191635132)

<?php

class A
{
    public $kind = 'A';
}

class B extends A
{
}

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $b = new B();

    if (!$b instanceof A) {
    }
}
var_dump(microtime(true) - $s);

$s = microtime(true);
for ($i = 0; $i < 10000000; $i++) {
    $b = new B();

    if ($b->kind !== 'A') {
    }
}
var_dump(microtime(true) - $s);

float(0.62735915184021)
float(0.65307688713074)

I am on christmas/ny vacation at the moment, will get back to it later.


Get listed as Heco wallet

Get us listed under "Partner" at https://www.hecochain.com/en-us/ and https://www.hecochain.com/en-us/wallet

Application sent


add links to NR I/O quickstart page from the NR doc

Hi Cloudflare team, I noticed most of the links and web search traffic for NR/Cloudflare logpush integration leads to this page. This gives great info on setting up the logpush, but doesn't mention the next step of actually installing the quickstart and seeing the visualizations. I added an extra section here based on the analytics integrations page I found, and linked to the quickstart in NR. Let me know if this is reasonable or needs any changes, thanks!

Hi @jcountsNR Thank you so much for your feedback. Actually the analytics integrations live on another section: https://developers.cloudflare.com/fundamentals/data-products/analytics-integrations/new-relic/

@angelampcosta thanks! I noticed this when I forked the Repo, but I had not seen it prior. Is it possible that this page does not get as much traffic as the logpush page? Maybe instead of duplicating it we could just add a link to this page for the next steps.

@jcountsNR The logpush page does get a bit more page views, but overall they're relatively comparable. Thank you for your suggestion, I think it makes sense to add a link to the integration page. I'll follow up on that on a ticket.

@angelampcosta , sure, thanks!


Please update npm

in the npm repository the floating-vue package is  "^2.0.0-beta.20" but on GitHub it is listed version 2.1.3. Could the npm package be updated?
I moved from vue-tippy to have a more up to date and live package.
Thanks!
mario

It's the old v-tooltip package


Move TxIn and TxOut to primitives

Turn the crank; move TxIn and TxOut to primitives.
The change in patch 1 is the only surprising thing. The rest is trivial (if 900 lines of diff can be trivial).

944 green lines of trivial ;)

Done reviewing 7ce4c99dc8bc33ddfb73e4f49660ddf4fbe97054

The whole primitives crate is basically useless without alloc feature. You are correct though, this does make it slightly worse. I thought it better not to put feature guards on what will be almost everything in the transaction module just so that OutPoint is available. I almost think we should just put "alloc" requirement on the whole crate really.

Had to rebase I'm afraid because of merge conflicts.

Hey @apoelstra, just this one then we can move Transaction - I think we are actually getting close.

CI fail is unrelated, its the -j1 thing. https://github.com/rust-bitcoin/rust-bitcoin-maintainer-tools/pull/18


Handle correcly state with pegtl grammar

I'm very new to peg and pegtl, so probably I'm missing something. I have a grammar very similar to the following one:
using namespace tao::pegtl;

struct A : one<'A'> { };
struct B : one<'B'> { };

struct comp : seq<plus<sor<seq<A, B>, A>>,eof> { };

template< typename Rule >
struct test_action : nothing< Rule > {};

template<>
struct test_action<A>
{
    template< typename Input >
    static void apply(const Input& in)
    {
        std::cout << "A";
    }
};

template<>
struct test_action<B>
{
    template< typename Input >
    static void apply(const Input& in)
    {
        std::cout << "B";
    }
};

void test()
{
    parse< comp, test_action >(memory_input("AAB", ""));
}

he parse works great, but there is too many activation of test_action::apply. The program outputs "AAAB", because, if I understand well, the parse tries the first alternative (AB) for the first character and fails, then proceeds with the other (A). But even if it "rewinds", it always call test_action::apply. What is the correct way to handle this situation? My intent is to output "AAB", possibly without complicate the grammar.

Any parser that "rewinds", like those generated by PEGTL, will have to 'undo' any state modifications it made on the failed branch. The way PEGTL allows you to do this is with the "control class", which gives you callback when a parse rule starts to match and when it matches either successfully or not, but it's up to you as the programmer to put a solution together.
Imho, for complex grammars where backtracking is likely and easy to miss, the best thing to do is make your parser construct a parse tree, which is easy to fix when it backtracks using simple push and pop operations  (e.g. resulting in removing the first 'A' node), and then pass that tree to the rest of your program. Constructing a parse tree inside a backtracking PEGTL is a simple and generic algorithm that works for any grammar.


Redis SVC Question

Hello,
Can you please explain how should application connect to the redis?
There is no service for connecting to port 6379 on the redis nodes?
Can you please explain?
Thanks so much,
Meir

@meirhazonAnyVision Did you figure this one out ?
@brendandburns

If you use https://github.com/kubernetes/examples/tree/master/staging/storage/redis you have to connect the redis-sentinel:
https://github.com/kubernetes/examples/blob/master/staging/storage/redis/redis-sentinel-service.yaml


cant download "New cloud YOU NEED THAT.rar"

cant download "New cloud YOU NEED THAT.rar".
the download link is leading to a "HTTP Error 403 Forbidden" message

its available in the wabbajack discord support channel pins


Unable to build on Android

By upgrading Pactus to Go 1.23.x, we are no longer able to build Pactus for Android. The error we encounter is:
undefined: anet.Interfaces

After searching the internet, I found this issue mentioned here: https://github.com/wlynxg/anet/blob/main/README.md#how-to-build-with-go-1230-or-later. Unfortunately, this solution didn’t work, and I still received the same error.
To build Pactus for Android, you can run this command:
CGO_ENABLED=0 GOOS=android GOARCH=arm64 go build -ldflags "-s -w" -trimpath -o ./build/android/pactus-daemon ./cmd/daemon

Currently anet package fixed issue on v0.0.5: https://github.com/wlynxg/anet/issues/7

Parent package upgraded it to latest version: https://github.com/pion/transport/blob/master/go.mod

Issue is tracking for fix in: https://github.com/libp2p/go-libp2p/issues/2997

@FishDontExist Libp2p fixed it v0.37.0 please update dependencies:
https://github.com/libp2p/go-libp2p/releases/tag/v0.37.0
Please follow https://github.com/pactus-project/pactus/blob/main/docs/update-dependensies.md for update deps.


release plotly v2.2.0

This should work as we haven't released that yet

The release was created but the issue was not automatically closed


Problem with multi format datetime

I've used this method for my program
moment.utc(value, [pattern1, pattern2, moment.ISO_8601], true)
but after I've imported moment-jalaali it doesn't work at all and return undefined.
I can't understand how it related to moment-jalaali, is there any conflict with the original moment?

I believe, when I use "moment-jalaali" the moment.utc function corrupted. How can I deal with this problem?

Moment Jalaali overrides utc function. It might have an issue there. You can help by finding the problem and improving the code.


[keyvault] keyvault-keys: bump minimum version of core-rest-pipeline

Packages impacted by this PR

@azure/keyvault-keys

Issues associated with this PR

#26001

Describe the problem that is addressed by this PR
Bump version of core-rest-pipeline dependency to include isRestError type guard which is used as part of fix in #26001.

API change check
API changes are not detected in this pull request.


Support extension UriHandlers

In a vscode extension you can register a URI handler:
https://code.visualstudio.com/api/references/vscode-api#UriHandler
This UriHandler will get invoked when an external webpage redirects into VS Code with the extension identifier specified.
This works in vscode.dev (thanks to @joaomoreno) where the server sets up a well-known route (vscode.dev/callback) that handles requests that will turn around and invoke registered UriHandlers. Note, this works in tandem with vscode.env.openExternal which will give you the exact Uri to redirect into.
vscode-test-web should have a similar capability and I feel like a lot of the logic can be shared.
Additionally, the Microsoft and GitHub auth extensions use UriHandler for logging in so this means that extensions that use our in-box auth extensions can not be tested in vscode-test-web either.
Workaround
Sideloading the extension on vscode.dev works around this and still allows the author to test their extension on web.

@TylerLeonhardt I'm new to the callback. I adopted what @bpasero did in microsoft/vscode#140329. Can you give it a try?
It's just in source, not yet published -> use yarn link.
Ideally this all goes to callback.html so no server code is needed.

There is still a little server dependency to serve callback.html, replace some variables and set the proper content security policy. But it is true that the change I pushed for callbacks makes the flow state less, where before the server had to keep callbacks in memory (now they are in local storage of the client).

In the meantime we've adopted the new fully serverless callback.html.
@TylerLeonhardt Is the more needed to get the auth flow running in vscode-test-web as well?
Currently, when I try the github authentication flow, I end up with the Enter Github Auth Token quick input.

@aeschli GitHub auth doesn't work with localhost. You will have to try either Microsoft auth or I made a test extension for UriHandlers:
https://github.com/TylerLeonhardt/open-external
once you have it running locally, run the command: Open an external Uri and choose Trigger uri handler...


How can I check to apply parent and child.plist

I used electron-osx-sign plugin to sign for my app.
However, App submission is rejected.
App reviewers, they executed my app and try to log in using accounts and password provided by our development team. But reviewers said that my app cannot fetch next content and there is just loading panel in login view. I think that this loading panel is shown during asynchronous request using axios to get authentication.
I checked Electron guide in more detail.
https://electronjs.org/docs/tutorial/mac-app-store-submission-guide
I noticed that I did not create .plist files(parent.plist, child.plist) and also didn't add some below keys into parent.plist.
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.network.server</key>
<true/>

So, I create two plist files and add above keys into parent.plist.
and then, I use below commend when I signed with electron-osx-sign plugin.
electron-osx-sign MyApp.app --entitlements="parent.plist" --entitlements-inherit="child.plist"

So, I got question,
Do these above keys make the server request(or get response) possible?
(My app also has websocket functionality).
If so, How can I know that these changes are well reflected?
I opened contents in my app(open package), I can still see that there was only info.plist file.
Thanks.

Great question! I think the parent.plist should look like the following. I think even only having the network client entitlement key should work with web socket.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.network.server</key>
    <true/>
  </dict>
</plist>

And you won't need to manually provide the child entitlements file as the default one would work fine 😸 The entitlement entries will be recorded in the executable program and won't be available as plain text like Info.plist.
If you run export DEBUG=electron-osx-sign* before running electron-osx-sign, you can find the actual signed entitlements at the end of the log. Alternatively you may run codesign -d --entitlements :- path/to/my.app to display all entitlements on the app bundle.

Thanks for your replay.
'And you won't need to manually provide the child entitlements file as the default one would work fine'
You mean that I do not need to create 'child.plist' file.
That means, it does not matter that I add child.plist file manually right?.
because I already submit my app to App store with signing by below comment in my release date.
Is not there any problem?
electron-osx-sign MyApp.app --entitlements="parent.plist" --entitlements-inherit="child.plist"

My app's directory structure like below.
electron-mat
   ㄴMyApp-mas-x64
      ㄴ MyApp.app
      ㄴ parent.plist
      ㄴ child.plist
      ㄴ LICENSE
      ㄴ LICENSES.chromium.html
      ㄴ version

parent.plist file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>OUR_TEAM_ID.MY_APP_BUNDLE_ID</string>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.network.server</key>
    <true/>
  </dict>
</plist>

child.plist file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

Thanks again for your awesome plugin.

Yep! electron-osx-sign will automatically use the template https://github.com/electron-userland/electron-osx-sign/blob/master/default.entitlements.mas.inherit.plist when signing a MAS build of Electron.
Let us know if your submission was successful 😺

Thanks!

Lol, makes sense. Defaults to app-sandbox=true.


sslmode = require issue

hello - I need to set sslmode = require  in my LibPQ.Connection  to connect to a cloud postgresdb.  I cant connect because it seems this option is not available on the connection parameters that can be set?

"sslmode=require" should work in the DSN.

the connection itself works ( with sslmode - require ) , but it crashes when I try to do a simple excute statement to pull data  result = execute(conn, "SELECT * FROM mytable limit 10").
I had the same problem when using mysql.jl and it turned out it was an issue with how the sslmode was set in the package. it has been fixed now. I am seeing the same issue here.  I am able to connect to the postgres db with a regular db desktop client using the same credentials.  But i get the error message below when i try to run the excute statement above. I got in touch with timescale ( my cloud provider for the postgres db ) and they say its not a license issue ( since I am able to connect ok normally).  Not sure how to proceed.
InternalError: ERROR:  invalid value for timescaledb.license_key 'Exxx='
Stacktrace:
 [1] error(::Memento.Logger, ::LibPQ.Errors.PQResultError{LibPQ.Errors.CXX,LibPQ.Errors.EXX000}) at C:\Users\vacqu\.juliapro\JuliaPro_v1.4.0-1\packages\Memento\kUo0a\src\loggers.jl:454
 [2] handle_result(::LibPQ.Result; throw_error::Bool) at C:\Users\vacqu\.juliapro\JuliaPro_v1.4.0-1\packages\LibPQ\QljsB\src\results.jl:228
 [3] execute(::LibPQ.Connection, ::String; throw_error::Bool, kwargs::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at C:\Users\vacqu\.juliapro\JuliaPro_v1.4.0-1\packages\LibPQ\QljsB\src\results.jl:280
 [4] execute(::LibPQ.Connection, ::String) at C:\Users\vacqu\.juliapro\JuliaPro_v1.4.0-1\packages\LibPQ\QljsB\src\results.jl:276
 [5] top-level scope at In[20]:9

Can you give me your full DSN (with any important details anonymized)?

you mean this ?
conn = LibPQ.Connection(" host = myhost
                     user = xx
                     port = 12345
                     sslmode = require
                     dbname = defaultdb
                     password = xxxx ")

without the execute statement, I get this:
PostgreSQL connection (CONNECTION_OK) with parameters:
  user = xx
  password = ********************
  dbname = defaultdb
  host = xxxxx
  port = 12345
  client_encoding = UTF8
  options = -c DateStyle=ISO,YMD -c IntervalStyle=iso_8601 -c TimeZone=UTC
  application_name = LibPQ.jl
  sslmode = require
  sslcompression = 0
  gssencmode = disable
  krbsrvname = postgres
  target_session_attrs = any

Yes thanks. I'll look to see if there are any important compatibility issues around PostgreSQL in the timescaledb docs.

much appreciated. thank you. I can also connect you with the timescale devs


Debug specific test filter not applied on Windows

Describe the bug
When trying to debug a specific test block, the debug process just runs all tests in the file on Windows with Yarn.
To Reproduce
Steps to reproduce the behavior on the example project:

yarn install
Add a second test block

import { describe, it, expect} from 'vitest';

describe('add', () => {
  it ('1 + 1', () => {
    expect(1 + 1).toBe(2);
  })

  it ('2 + 2', () => {
    expect(2 + 2).toBe(4);
  })
})

Add a breakpoint on line 5, inside the "1 + 1" test
Open the Vitest sidebar and select "Debug test" on "2 + 2"
The breakpoint is hit, indicating "1 + 1" is being run

Expected behavior
When debugging a specific test, I expect to only run that test
Screenshots
If applicable, add screenshots to help explain your problem.

Shown above: "2 + 2" is being debugged, but the debugger has broken inside "1 + 1"
The full output for the debug test run:
"C:\Program Files\nodejs\node.exe" .\node_modules\vitest\vitest.mjs test D:/vitest-ext-basic-example/add.test.ts -t ""add 2 + 2"" --api 52918
 DEV  v0.12.10 d:/vitest-ext-basic-example
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
      API started at http://localhost:52918
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
Could not read source map for file:///d:/vitest-ext-basic-example/@vite/env: ENOENT: no such file or directory, open<EMAIL_ADDRESS>
Environment
(Paste info.txt content generated by the example project)

OS: [e.g. macOS] Windows 11
VSCode version: 1.69.2
Vitest version: 0.12.10
Vitest plugin version: v0.2.23 (prerelease)

(filled manually, the setup script does not work on Windows either)
Vitest settings updated
'C:\Users\a-typ\AppData\Local\Programs\Microsoft' is not recognized as an internal or external command,
operable program or batch file.
node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "undefined".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

This is probably related to the quoting of the test name pattern on windows devices: It is quoted and then later passed to the debug config, which quotes the argument againt, thus, on windows, the comandline looks like:  ... tests/add.test.ts -t ""multi word named task"". What windows effectively sees is  ... tests/add.test.ts -t multi word named task, so the pattern is multi, and "word", "named" and "task" is passed to the filter arguments.
For what I tested, the bug can simply be fixed by removing the following:
https://github.com/vitest-dev/vscode/blob/dd70a041b8d955ed821b53684104a1f630044ea0/src/pure/runner.ts#L82-L84

@a-type does it work now on pre-release version?

Tests no longer run at all with any run mode with the latest version:
Test result not found.
Are there tests with the same name?
Can you run vitest successfully on this file? Does it need custom option to run?

Vitest output:
'.' is not recognized as an internal or external command,
operable program or batch file.

Debug run now states No test files found, exiting with code 1.  Full output:
"C:\Program Files\nodejs\node.exe" .\node_modules\vitest\vitest.mjs D:/vitest-ext-basic-example/add.test.ts -t "add 2 + 2" --api 60210
 DEV  v0.12.10 d:/vitest-ext-basic-example
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
      API started at http://localhost:60210
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
filter:  D:/vitest-ext-basic-example/add.test.ts
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10365
include: **/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10367
ignore:  /\/node_modules\//, /\/dist\//
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10369

No test files found, exiting with code 1
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10483
Process exited with code 1

Perhaps because of the forward slashes in the test file path? It's unclear, considering I can run node .\node_modules\vitest\vitest.mjs D:/vitest-ext-basic-example/add.test.ts -t "add 2 + 2" --api 60210 in PowerShell and it works fine.

It might actually be the + symbol in the filter. Running -t "add 2" correctly filters to 2 + 2, but -t add 2 + 2 skips everything.

@a-type thank you for your info. It's weird we need to escape +. Can you run tests correctly on this version?

My reproduction case still does not work. Attempting to debug an individual test in the example repro does not run anything.
This does not appear to be related to + after all (even though that does seem to be a problem). Apologies for the distraction. For example:
import { describe, it, expect} from 'vitest';

describe('add', () => {
  it ('1 + 1', () => {
    expect(1 + 1).toBe(2);
  })

  it ('2 + 2', () => {
    expect(2 + 2).toBe(4);
  })

  it('foo', () => {
    expect('foo').toBe('foo');
  })
})

Running just add foo:

Outputs:

"C:\Program Files\nodejs\node.exe" .\node_modules\vitest\vitest.mjs D:/vitest-ext-basic-example/add.test.ts -t "add foo" --api 50098
 DEV  v0.12.10 d:/vitest-ext-basic-example
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
      API started at http://localhost:50098
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10480
filter:  D:/vitest-ext-basic-example/add.test.ts
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10365
include: **/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10367
ignore:  /\/node_modules\//, /\/dist\//
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10369

No test files found, exiting with code 1
node_modules/vitest/dist/chunk-vite-node-externalize.464ab3dd.js:10483
Process exited with code 1

Would this issue related to this issue #65 ?
The drive name is a capital case, e.g. C:/ or D:/

That could be it, yeah.

FYI, the commit made to address this issue (https://github.com/vitest-dev/vscode/commit/a6019a45d45abb0411f3e6a67eaf5c5f00dead2e) caused quotes to be set properly when debugging (which uses a VS Code API) but turned off quotes when running (which uses spawn), effectively undoing part of #24.
Run commandline:
"C:\Program Files\nodejs\node.exe" .\node_modules\vitest\vitest.mjs /xyz/test/unit/vue-component/vueComponent.spec.ts -t "Vue Component init" --api.port 63875 --api.host <IP_ADDRESS>
Debug commandline:
c:/xyz/node_modules/.bin/vitest.cmd /xyz/test/unit/vue-component/vueComponent.spec.ts -t Vue Component init

I've found a more targeted fix that I'll be PR'ing shortly. As for the issue reported here, I believe it was fully fixed by #94 and think this could be closed now.


Query service: /api/config returning index.html

Description
The query-service is returning the body of index.html when the UI requests /api/config.
This is causing errors in the browser, but fortunately they are not interrupting the UI experience.
The ideal scenario is the config is dumped into the body of index.html when it is served. This will allow us to remove the HTTP call to /api/config entirely.
Per a previous discussion, the index.html can contain the following, which I believe can be replaced with a JSON serialization of the config:
JAEGER_CONFIG = DEFAULT_CONFIG;

Where DEFAULT_CONFIG is replaced with the UI config contents.
The UI config contents are {} by default, and can be overridden via a envar or cmd line parameter (maybe query.ui-config?) that conveys a filepath with a YAML or JSON file.
Steps to reproduce the issue:

Follow the steps here
Create a trace via the HotROD app
View a trace

Describe the results you received:
/api/config returns the index.html content.
Describe the results you expected:
Either /api/config returns the index.html content or we switch to dumping the config into the body of the HTML.

Let's make a change in the UI project first that ensures that the generated index.html contains
DEFAULT_CONFIG = {};
JAEGER_CONFIG = DEFAULT_CONFIG;

Then we can add code to the query service to assign a different value to JAEGER_CONFIG when serving index.html

Sounds good, will post back when it's merged.

UI change: https://github.com/jaegertracing/jaeger-ui/pull/107

All done & tested, keeping this open until we add docs on how to use it.

https://github.com/jaegertracing/jaeger-ui could list all configurable options.

@pavolloffay elaborate? Like a help page?

or you mean the README?  +1 then

just the readme for now

I think we have one outstanding issue (https://github.com/jaegertracing/jaeger-ui/issues/123) before we can document (although the current solution already works, so we could just document it as is - https://github.com/jaegertracing/jaeger-ui/issues/124).
Since there are tickets in the UI repo now, I am going to close this one.


DS-2504: Method getLink() returns incorrect context path

This is only quick fix. The solution will be improved in a few days.
https://jira.duraspace.org/browse/DS-2504

There is no rule that the rest api should be served at the URI "/rest". I would recommend using the servlet context, or externalizing a baseURL.

Yes, we are planning to do so. Maybe tomorrow;-)

I added static method to class Resource. I dont like that dependency between DSpaceObject and Resource, but i think there is no option. (i do not see any other options).

The , which knows its context path, could supply that path as a constructor argument to its , or DSpaceObject could provide a setter to be used by an .
Ideally DSpaceObject would just supply the part of the path it knows, and  would concatenate that with the part it knows, but I don't know how to do that with all the JAX-RS magic going on.

Good ideas, but if it will be setting by constructor or setter, then many code must be changed. I think this is only way how to do it. Because DSpace Object cannot know context path, because it is not Resource. So, it must get it from Resource.

+1 I think this looks clean, and gets the job done.

Does anyone object to merging this as-is?


Feature to include watermark as image on osd viewer at particular location such as bottom right..

Hi ,
how to add watermark as image on osdviewer at particular location?

The easiest way to do this would be to just make a regular <div> on the page and use CSS to position it over the viewer in the bottom right.
A more involved way would be to paint it on to viewer.drawer.canvas every frame.


Save file for a cosmosDB document seems pointless

If a user wants to save to local disk, there is Ctrl+Shift+S (save in another file).
Approaches:

Open the doc at a file not in their workspace, but in the extension folder?
Open doc in the temp folder

Closing as dup of https://github.com/Microsoft/vscode-cosmosdb/issues/109


clientconfig refactor

This commit is a large refactor of the clientconfig package.
It attempts to become a single point of entry for all OpenStack
authentication, supporting authentication from clouds.yaml,
explicit authentication parameters, and environment variables.
Supersedes #26
Requires https://github.com/gophercloud/gophercloud/pull/896
For https://github.com/gophercloud/gophercloud/issues/252

@jrperritt ping for review at your convenience

@jrperritt Thank you for the review. Comments addressed and ready for another round.

Looks good. Good job on this


Re-brand for REX-Ray and EMC {code} in Cloud-Native Storage

First off @dankohn, thanks for putting this together.
Our team has gone through some rebranding efforts and just wanted to make sure this makes its way into 1.0
EMC {code} is now {code} by Dell EMC. Our new logo .png logo can be vertical or horizontal. Horizontal is preferred.
In addition, REX-Ray has been upgraded to a new color logo.

Hi @kacole2, love the new REX-Ray look, and we'll get both updated in our upcoming release.

REX-Ray logo is probably my favorite of all ~500.

@shawnpreissner @dankohn oddly enough, we're going through another logo change. Once I have the new files I'll update this issue. Thanks for understanding.

😢
--
Dan Kohn<EMAIL_ADDRESS>Executive Director, Cloud Native Computing Foundation https://cncf.io/
tel:+1-415-233-1000
On Tue, Aug 1, 2017 at 6:41 PM, Kendrick Coleman<EMAIL_ADDRESS>wrote:

@shawnpreissner https://github.com/shawnpreissner @dankohn
https://github.com/dankohn oddly enough, we're going through another
logo change. Once I have the new files I'll update this issue. Thanks for
understanding.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cncf/landscape/issues/90#issuecomment-319517519, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC8MBtoaXdavPGg0rGwWLYkA9fj46gC3ks5sT6mqgaJpZM4MZqdJ
.

say it ain't so, @kacole2

@shawnpreissner @dankohn not to REX. he's good. :) We're dropping the "by Dell EMC" and will be "Dell Technologies" or "Dell Tech".

Ok @kacole2, hopefully the timing works out as we're going to be releasing a new version in the coming weeks. Please keep us posted.

@kacole2 do you have a new logo? Please reply with today if at all possible.

@shawnpreissner it's on my hit list today.

@kacole2 We are planning to include REX-Ray and libstorage in the next version of the landscape, but not Code by Dell EMC, since the latter is not a specific project. We will also be including https://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/Dell_EMC_logo.svg/1024px-Dell_EMC_logo.svg.png as a non-open-source storage offering.

@dankohn @shawnpreissner sorry for not getting back at you earlier. Graphics, ya know. :) At least these suggestions don't make me feel as bad not having a graphic yet.
That's fine to remove the {code} by Dell EMC since it's not project specific. Please keep REX-Ray and libStorage in there. And yes, please include the Dell EMC logo as a non-open-source storage offering.

Thanks, @kacole2 stay tuned for a release soon!

Thanks @kacole2, closing as these updates were included in the most recent version https://github.com/cncf/landscape#current-version


bug: Fix, update & improve models in Jan Hub

Problem
I have encountered many issues with the wrong model default settings (incorrect prompt template, the stop words missing, etc.).
e.g., comments in Jan 0.5.7 Release Sign Off janhq/jan#3818

Model Testing Results
I have tested 45 models from Jan Hub, here are the results.
Next step

[ ] Update correct default settings for failed models
[ ] Better description for all models
[ ] Consider removing legacy models
[ ] Update Hub with new trending models?

cc @hahuyhoang411

No.
Model Name
Issue Identified
Status

1
Llama 3.2 1B Instruct Q8

2
Llama 3.2 3B Instruct Q8

3
Qwen2.5 7B Instruct Q4

4
Qwen2.5 Coder 7B Instruct Q4

5
Llama 3.1 8B Instruct Q4

6
Qwen2.5 14B Instruct Q4

7
Codestral 22B Q4
Error in response format, wrong prompt template?

8
TinyLlama Chat 1.1B Q4
Garbled response, error in response format

9
LlamaCorn 1.1B Q8

10
Deepseek Coder 1.3B Instruct Q8

11
Gemma 1.1 2B Q4
Error in response format, wrong prompt template?

12
Gemma 2 2B Q4

13
Phi-3 Mini Instruct Q4

14
Stable Zephyr 3B Q8

15
Llama 2 Chat 7B Q4
Error in response format, wrong stop word insertion?

16
CodeNinja 7B Q4
Error in response format, wrong prompt template?

17
LaVa 7B
Garbled response, sometimes cannot run

18
Mistral 7B Instruct Q4
Error in response format, wrong stop word insertion?

19
Noromaid 7B Q4

20
Openchat-3.5 7B Q4

21
Stealth 7B Q4

22
Trinity-v1.2 7B Q4

23
Vistral 7B Q4
Error in response format, wrong stop word insertion?

24
Qwen 2 7B Instruct Q4
Error in response format, wrong prompt template?

25
Qwen Chat 7B Q4

26
Llama 3 8B Instruct Q4

27
Hermes Pro Llama 3 8B Q4

28
Aya 23 8B Q4

29
Gemma 1.1 7B Q4
Error in response format, wrong stop word insertion?

30
BakLlava 1
Garbled response, sometimes cannot run, wrong stop word insertion?

31
Gemma 2 9B Q4

32
LaVa 13B Q4
Garbled response; prompt template issue?

33
Wizard Coder Python 13B Q4
Garbled response; prompt template issue?

34
Phi-3 Medium Instruct Q4

35
Gemma 2 27B Q4

36
Qwen2.5 32B Instruct Q4

37
Deepseek Coder 35B Instruct Q4

38
Phind 34B Q4
Error in response format, wrong stop word insertion?

39
Yi 34B Q4

40
Command-R v01 34B Q4
Garbled response; prompt template issue?

41
Aya 23 35B Q4

42
Mixtral 8x7B Instruct Q4
Error in response format, wrong stop word insertion?

43
Llama 3.1 70B Instruct Q4

44
Llama 2 Chat 70B Q4
Error in response format, wrong stop word insertion?

45
Qwen2.5 72B Instruct Q4

On one note
We will need to develop model.yaml to easily define model capabilities (e.g. function calling, vision, etc). Users are facing an issue with imported LlaVa: https://github.com/janhq/jan/issues/3855

model.yaml should have some sort of capabilities field, e.g. tools: true
Jan allows users to "edit" Models, e.g. view a model's functionalities + edit it
Cortex: users will just edit model.yaml directly

Related

[ ] https://github.com/janhq/jan/issues/3953

I edited the list based on current trends. cc @imtuyethan


[ADDITION] Add FiloSottile/age under File Encryption

Category
File Encryption
Software to be added
age is a simple, modern and secure file encryption tool, format, and Go library. It features small explicit keys, no config options, and UNIX-style composability.
age is multi-platform with releases available on Darwin, BSD, Linux, and Windows as pre-compiled Go binaries.
age is also very easy to use from the command line, with encryption being done using passwords, passphrases, SSH keys, keyfiles, and even GitHub user account metadata.
Supporting Material
GitHub Repo: https://github.com/FiloSottile/age
Format Spec: https://github.com/C2SP/C2SP/blob/main/age.md
Manpage: https://github.com/FiloSottile/age/blob/main/doc/age.1.html
Authors: Filippo Valsorda and Ben Cox
Association Disclosure
No response
Would you like to submit a PR?
Maybe?
Please tick the boxes

[X] You have filled out this form accurately, and to the best of your knowledge
[X] You have indicated weather or not you are associated with the suggested addition
[X] A similar submission has not already been opened for this software/ service
[X] You agree to the code of conduct

age is awesome, thank you for suggesting it.
I'll add it now...


[Feature] enable CodeQL static code analysis

enable CodeQL static code analysis
What problem does this PR solve?
Issue Number: close #1555
Problem Summary:
What is changed and how it works?
Proposal: xxx
Feel free to ping committers for the review!
Contribution Checklist

Make sure that the pull request corresponds to a GITHUB issue.

Name the pull request in the form "[Feature] [component] Title of the pull request", where Feature can be replaced by Hotfix, Bug, etc.

Minor fixes should be named following this pattern: [hotfix] [docs] Fix typo in README.md doc.

Purpose of this pull request

@tisonkun PTAL, You can pass it first, next, I will fixed issue found by CodeQL.


Add elimu.ai to the OSS Directory

https://github.com/opensource-observer/oss-directory?tab=readme-ov-file#how-to-contribute

Looks like someone added elimu.ai already (two weeks ago). And I opened a PR for including our blockchain addresses: https://github.com/opensource-observer/oss-directory/pull/397


Function DisableTailoredExperiences defined twice

Script version: 5.0.1.
While looking through the preset file I noticed that there is a line DisableTailoredExperiences and instead of having
# EnableTailoredExperiences after it, there is # DisableTailoredExpereriences. Then I looked into the Sophia.psm1 file and lo and behold there are two function definitions for DisableTailoredExperiences. I don't have time at the moment but I can add a pull request later to fix this issue.

LOL. Yes, my mistake. The file are getting bigger day by day. Thanks. I'll release a new version in some days with all small fixes.

Also, DisableSuggestedContent is defined twice... I suggest naming the second one DisableSuggestedSetup. Same for EnableSuggestedContent.


Create a log group for AWS Batch jobs

Overview
Before this change the log output for all batch jobs across all environments was being written to an AWS-created generic batch log group. Using a dedicated group will simplify searching and allow us to set separate retention for these logs. We want to keep these log records forever.
Connects #1998
Demo
Abbreviated plan output
  # aws_batch_job_definition.default must be replaced
-/+ resource "aws_batch_job_definition" "default" {
      ~ arn                   = "arn:aws:batch:eu-west-1:249322298638:job-definition/jobOpenSupplyHubStagingDefault:65" -> (known after apply)
      ~ container_properties  = jsonencode(
          ~ {
              ~ environment          = [
        ...snip...
                ]
              ~ image                = "249322298638.dkr.ecr.eu-west-1.amazonaws.com/opensupplyhub-batch:e5a42e3" -> "249322298638.dkr.ecr.eu-west-1.amazonaws.com/opensupplyhub-batch:e5a42e"
              + logConfiguration     = {
                  + logDriver = "awslogs"
                  + options   = {
                      + awslogs-group         = "logOpenSupplyHubStagingBatch"
                      + awslogs-region        = "eu-west-1"
                      + awslogs-stream-prefix = "default"
                    }
                }
              - mountPoints          = [] -> null
              - resourceRequirements = [] -> null
              - secrets              = [] -> null
              - ulimits              = [] -> null
              - volumes              = [] -> null
                # (3 unchanged elements hidden)
            } # forces replacement
        )
      ~ id                    = "arn:aws:batch:eu-west-1:249322298638:job-definition/jobOpenSupplyHubStagingDefault:65" -> (known after apply)
        name                  = "jobOpenSupplyHubStagingDefault"
      - parameters            = {} -> null
      - platform_capabilities = [] -> null
      ~ revision              = 65 -> (known after apply)
      - tags                  = {} -> null
      ~ tags_all              = {} -> (known after apply)
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # aws_batch_job_definition.notifications must be replaced
-/+ resource "aws_batch_job_definition" "notifications" {
      ~ arn                   = "arn:aws:batch:eu-west-1:249322298638:job-definition/jobOpenSupplyHubStagingNotifications:12" -> (known after apply)
      ~ container_properties  = jsonencode(
          ~ {
              ~ environment          = [
                ...snip...
                ]
              ~ image                = "249322298638.dkr.ecr.eu-west-1.amazonaws.com/opensupplyhub-batch:e5a42e3" -> "249322298638.dkr.ecr.eu-west-1.amazonaws.com/opensupplyhub-batch:e5a42e"
              + logConfiguration     = {
                  + logDriver = "awslogs"
                  + options   = {
                      + awslogs-group         = "logOpenSupplyHubStagingBatch"
                      + awslogs-region        = "eu-west-1"
                      + awslogs-stream-prefix = "notifications"
                    }
                }
              - mountPoints          = [] -> null
              - resourceRequirements = [] -> null
              - secrets              = [] -> null
              - ulimits              = [] -> null
              - volumes              = [] -> null
                # (3 unchanged elements hidden)
            } # forces replacement
        )
      ~ id                    = "arn:aws:batch:eu-west-1:249322298638:job-definition/jobOpenSupplyHubStagingNotifications:12" -> (known after apply)
        name                  = "jobOpenSupplyHubStagingNotifications"
      - parameters            = {} -> null
      - platform_capabilities = [] -> null
      ~ revision              = 12 -> (known after apply)
      - tags                  = {} -> null
      ~ tags_all              = {} -> (known after apply)
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # aws_cloudwatch_log_group.batch will be created
  + resource "aws_cloudwatch_log_group" "batch" {
      + arn               = (known after apply)
      + id                = (known after apply)
      + name              = "logOpenSupplyHubStagingBatch"
      + retention_in_days = 0
      + tags_all          = (known after apply)
    }

Notes
Optional. Ancillary topics, caveats, alternative strategies that didn't work out, anything else.
Testing Instructions
Verify that the plan output looks correct
$ docker-compose -f docker-compose.ci.yml run --rm terraform
bash-5.1# export GIT_COMMIT=e5a42e (or whatever the head of `ogr/develop` is)
bash-5.1# ./scripts/infra plan

Checklist

[ ] fixup! commits have been squashed
[ ] CI passes after rebase
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[ ] This PR is targeted at the correct branch (develop vs. ogr/develop)
[ ] If this PR applies to both OAR and OGR a companion PR has been created

Thanks for the review.


added most "normal" types

In ngraph we cannot use boolean types for any non-logical operation, which I guess makes sense and we should do the same

i'll merge this now, but i'll look into having something in shogun-core similar to what's in arrow that i've mentioned as we keep having these enums and stuff for primitive types all around shogun and would be great to have it unified - and use a more c++ like approach instead of ansi c, see enum


upated test for Data change

Data from backend changed hence updated the test
Test coverage results :test_tube:
:white_circle: Total coverage has not changed
No changes to code coverage between the base branch and the head branch

I've marked this PR as draft so that it doesn't get merged by mistake as it'll cause test failures to happen on our main branches.

@NandanAnantharamu Closing this PR as it's not the right solve for the problem. Instead of asserting a hard-coded response, we should assert the API response directly.


Split modules react and react/addons; exporting Component<P, S, C> class

So... this PR splits react-0.13.0.d.ts and react-addons-0.13.0.d.ts, with no shared code or interfaces. That feels bad, but there's a good reason why:
The Problem
React.Exports.Component doesn't have type parameters (it has the type interface React.ComponentClass<any, any, any>, which is not extendable by a class). The reason this seems to work right now is because React.Component references the class in the global React module, and not in "react" or "react/addons". So if you import react, react.Component is not a class.
The Solution
Export class Component<P, S, C> directly from module "react" as well as from module "react/addons". This has some unfortunate side effects:
Top Level Exports
Previously we managed sharing between "react" and "react/addons" by extending React.AddonsExports from React.Exports. Now that we need to export a class, we can't use export assignment:
var exports: React.Exports;
export = exports;

So every Top Level API method must be exported individually.
export function createClass<P, S, C>(...)
export function createElement<P>(...)
export class Component<P, S, C> { ... }

No Shared Interfaces
We got away with packing all React-related interfaces into the global React module because neither "react" nor "react/addons" exported any individual elements. Now that they do, If you use
import React = require("react");

it clobbers the React module definition and its interfaces are no longer accessible. This means that we need to either (a) define global interfaces (ReactElement, ReactComponent, etc.), which is against DT best practices, or (b) declare interfaces in both "react" and "react/addons" modules.
Attempted Workarounds
module merging:
declare module "react/addons" {
    import React = require("react");
    module React { // <---- (*)
        var addons: { ... };
    }
    export = React;
}

Doesn't work. The module to be merged (*) is ignored completely.
So...
This is the conclusion that I came to. We should split up "react" and "react/addons", making sure that changes stay in sync between the two files.
Bonus features:

fixes static properties on modern components (needs type annotations)
write better tests for Top-Level API, making sure that they preserve type information (eg. ClassicComponentClass -> ClassicFactory -> ReactClassicElement -> ClassicComponent)

cc @pspeter3, @jbrantly

It seems that this doesn't allow use with internal modules (since declare module React is replaced with declare module "react". In fact, I don't think the old definitions supported internal modules either. I think we should have support for internal modules.
I put together a quick idea that I think works. I put it up at https://gist.github.com/jbrantly/a9db05bad85d131c4a7f
The basic idea is that all of the functionality is available through a global module React (including the exported Component class and top level APIs like createClass). This is a change from the old definitions in that you should now be able to do something like React.createClass() in an internal module. The named module "react" is also declared for external modules which exactly equals the global module. No addon functionality is defined in this file.
A second file is created for the addons. The second file extends the global React module to add the "addons" interface and variable, and "react/addons" is declared. In this way you can either use react.d.ts for both internal and external modules without addons, and if you need addons you instead can use react-addons.d.ts which simply extends react.d.ts. No duplicated code.

We've tried that before. Some of the problems are that the React module and the imports can collide and secondly that if you have both definitions in your project, require("react"); automatically gives you addons because of module merging. Maybe we can have a global module for react interfaces (ReactApi?) and then have the modules export their own individual things. I honestly wish that react/addons was it's own node module so we could just have a separate typings and they did not have an overlapping set of exports.

the React module and the imports can collide

I'm not sure I entirely understand the problem with this. Are there any negative side-effects? AFAIK in my example if you did import React = require('react') and then used React it's true there is potentially some ambiguity between what React refers to (the imported module or the global module) but in practice it doesn't really matter because they both mean the same thing. If anything I think it would be more confusing if they didn't collide because you could do import react = require('react') and usage of both react and React will compile but only react will actually work. But this is just a side-effect of  the recommended approach to supporting both internal and external modules with the same declaration file[1].
Also, to be clear, I don't think this point is relevant to the normal/addons separation but more to the internal/external modules separation. I apologize for muddying the waters a bit in this regard. However, I do think we need to keep internal/external module separation in mind.

if you have both definitions in your project, require("react"); automatically gives you addons because of module merging

That's true and unfortunate. IMO it seems like a worthwhile tradeoff to keep from having repeated declarations, but I could certainly understand if others disagreed. It would be nice if we didn't have to make the tradeoff at all somehow but I don't see another alternative.
Another thing to keep in mind is that it's possible this doesn't actually break anything at run time. Assuming you're using both, as you said, it looks like addons gets appended to the react export so require('react') would actually have the addons assuming require('react/addons') had also been called. But that isn't guaranteed. Just food for thought. See https://github.com/facebook/react/blob/master/src/browser/ReactWithAddons.js

Maybe we can have a global module for react interfaces (ReactApi?) and then have the modules export their own individual things

I think this could work but might be a little unwieldy. I assume you mean something like:
import react = require('react');

var elm: ReactApi.ReactElement<any> = react.createElement(...)

Not entirely sure how I feel about that. I think it might lead to more confusion than is necessary.

What I really don't want to see is the definitions being repeated into a bunch of files. I could foresee repeating in 3 files: one for external modules, one for external modules with addons, and one for internal modules. While that may model everything really well it seems like overkill to me. I think we need to make some concessions. TypeScript Handbook [1] recommends putting both internal and external module definitions in a single file. This has the concession that if you're using external modules, the internal module definitions are still available but the user just has to be aware not to use them. I think we can apply a similar concession to the normal/addons separation. If you're not using addons, fine, don't include that definition file and you don't get it. If you are, then include the right definition file and you get addons everywhere.
[1] "Global / External-agnostic Libraries" http://www.typescriptlang.org/Handbook#writing-dts-files-examples

In the interest of moving forward (I definitely agree that the current state of the definitions is broken), I think it boils down to this:

How are we going to handle internal modules?
We don't. External only.
We do. We need to have a global React module somewhere.
1. We have a global React module and the external module just exports it (ala my example)
2. We put the global React module in a completely separate file and duplicate code. (so you need to choose which declaration file to use depending on whether or not you plan on exposing React as a global)
3. We defer for another PR.
How are we going to handle addons?
We duplicate interfaces. This allows fine-grained control (require('react') will never have the addons property).
We use module merging to not duplicate code (ala my example). In this case if you reference the addons declaration file anywhere in your project then require('react') will include the addons property.

Please note that the original issue (React.Component not being a class) is actually solved more by the internal/external module solution than it is by the addons solution. The addons solution (I believe) only effects whether or not require('react') has the addons property. This PR inadvertently fixes the issue by going external only.
So I think if we each just voted and see where we wind up that mind lead to more fruitful discussion and progress than me making walls of text.
I personally vote for 1.ii.a and 2.ii for the reasons previously outlined.

Honestly the entire ecosystem around react targets external modules there is no use to have a definition based on a global React module, as for addons separation I think there is a better solution : just don't provide any declarations for addons, in future react release this will anyway be pulled out of master in separate repo, and for myself I already request thoses addons this way:
var cx = require('react/lib/cx');

@jbrantly your solution about using a different name for react require like lowercase react is really problematic if you want to use jsx-trypescript, because like the officila jsx compiler it converts tags to 'React.createClass'.
In general the definition of React is really wrong in a lots of way, for example: https://github.com/borisyankov/DefinitelyTyped/blob/master/react/react.d.ts#L244-L288 is entirely wrong the events handler should only be on HTML Element, adding a third generic types on component for context have practically no value but is quite bother some, the overload of createElement should not use union type etc etc.
I personally use https://github.com/fdecampredon/jsx-typescript/blob/jsx/typings/react.d.ts and even if it's not as complete it allows me to get a far better type inference.
Finally on the topic of external vs internal module I think the problem is deep, I can't personally use any of the DefinitelyTyped definition files as is, I don't want my global scope to be polluted by anything when I work with external modules, and I hate the fact that some of those file use ///<reference /> when I strictly forbid them from my own project.
This is a build problem I think there would be a way to create a definition for internal module and find something that automatically transform it in a external module def. but that's another topic.

@fdecampredon thanks for weighing in! I appreciate it.

Honestly the entire ecosystem around react targets external modules there is no use to have a definition based on a global React module

I disagree. React exposes a global object for people to use, I think we should allow for that in the definitions. The React tutorial uses it. The two most popular (I think) 3rd party React components expose globals: react-router and react-bootstrap. While most people may use external modules and for good reason I don't think we should exclude those that don't.

just don't provide any declarations for addons, in future react release this will anyway be pulled out of master in separate repo

That's good news! That is exactly what @pspeter3 was hoping for. I think the issue is that the officially documented way of using addons is react/addons and the addons property, so for now I'm guessing that's what we should (unfortunately) model.

your solution about using a different name for react require like lowercase react is really problematic if you want to use jsx-trypescript, because like the officila jsx compiler it converts tags to 'React.createClass'.

I actually like to use uppercase React for just that purpose, it's the Asana guys that want to use lowercase react. But there's really no reason that they shouldn't be able to do that if they want.

I don't want my global scope to be polluted by anything when I work with external modules

So it sounds like you would be a proponent of putting any internal module definitions (assuming we had them in the first place) in a separate, duplicated file.

@jbrantly are you now advocating 1.ii.b and 2.i? I generally agree with @fdecampredon that I don't want my global scope touched when I'm using external modules though don't feel strongly about the /// <reference syntax.
Global vs CommonJs
I agree with @fdecampredon. I don't understand where you are getting this exposed React global unless you are directly linking to the script tag. I feel like most people use the npm module for rendering on the server and then use browserify or webpack.
React Addons
Having declarations for the test utilities has been awesome. One solution I had was to define them all as external modules so you just require the exact ones you want. In the long run, a separate module will achieve the same result. I think removing the addons type definitions entirely though would be a shame.
react vs React
We've been using react instead of React purely because IntelliJ becomes confused when you have a local variable React and a global module React. It shouldn't matter at the end of the day but we would prefer to use React.
Event Attributes
The event handlers are only for HTML and SVG elements. I believe SVG elements can also have event handlers.
Context
Adding a third generic is actually fairly helpful for our case. We use context as a means for dependency injection and have a way to ensure that components have sufficient context to create all of their children.

So it sounds like you would be a proponent of putting any internal module definitions (assuming we had them in the first place) in a separate, duplicated file.

Not really I think it would be easy to provide a way to automatically build the definitions in the 2 modes for example pretty easily we could wrap a definition written in internal module :
/// internal module def
declare module MyModule {
  export init(): void;
}

would be transformed into :
/// external module def
declare module 'my-module' {
  module MyModule {
    export init(): void
  }
  export = MyModule
}

Alternatively we could have a 'template file' for definition file that can generate both mode:
/// template def
declare module <% module.name %> {
   export function init(): void;
}

That would be transformed into :
/// internal module def
declare module MyModule {
  export init(): void;
}

and
/// external module def
declare module 'my-module' {
  export init(): void
}

But this second solutions could cause problem with export = .
The typescript team pretty much have done something similar since now we have 2 declarations files for typescript one for external module, the other for internal module.

Event Attributes
The event handlers are only for HTML and SVG elements. I believe SVG elements can also have event handlers.

Yup but for user defined component we don't want those handlers.

Context
Adding a third generic is actually fairly helpful for our case. We use context as a means for dependency injection and have a way to ensure that components have sufficient context to create all of their children.

I can understand but honestly what's the difference between :
class MyClass extends React.Component<{},{},{ myContextVar: string}> {
}

and
class MyClass extends React.Component<{},{}> {
  context: { myContextVar: string}
}

I doubt that you access to context outside of the component or that you can enforce type-checking on children based on the parent context or getChildContextMethod.
Anyway this is honestly a case that very very few people uses, and I feel that it gets in the way of comprehension and simplicity for people who don't use it.

The typescript team pretty much have done something similar since now we have 2 declarations files for typescript one for external module, the other for internal module.

Do you have a link for that?

Do you have a link for that?

https://github.com/Microsoft/TypeScript/blob/release-1.4/bin/typescript.d.ts
https://github.com/Microsoft/TypeScript/blob/release-1.4/bin/typescriptServices.d.ts
And the corresponding jake task https://github.com/Microsoft/TypeScript/blob/release-1.4/Jakefile#L330-L367

@fdecampredon Thanks! Wow. I totally missed that those had the same contents when I looked at them when making ts-loader. I just assumed typescriptServices was for the language services instead of the compiler. That is really interesting.

are you now advocating 1.ii.b and 2.i?

I'm not advocating it but I'm willing to concede on the point since everybody else doesn't want to pollute the global namespace when using external modules (which I totally understand). Pollution is the way that TypeScript currently recommends in the Handbook and the way pretty much every other definition file out there does it, and it sucks that we'll have duplicate definitions and need to keep multiple copies in sync, but I understand the end-goal. Apparently the TypeScript team does as well according to the links  @fdecampredon provided. It's certainly not the hill I'll die on, but I wanted to make sure we had some discussion around it before giving my +1 since there are definitely tradeoffs involved.
I did open an issue in TypeScript for this: Microsoft/TypeScript#2018

I don't understand where you are getting this exposed React global unless you are directly linking to the script tag. I feel like most people use the npm module for rendering on the server and then use browserify or webpack.

That's totally where I'm getting it. Well, not me personally, but where some people can get it. I'm not saying it's a best-practice or even commonly used thing, but it is part of the publicly documented React API and for the x% of people that do use it, however small x is, I think we should support it. Exactly for the same reasons that the two of the most popular 3rd party React components support it.

React Addons

I also opened a ticket regarding this item: Microsoft/TypeScript#2019

Not really I think it would be easy to provide a way to automatically build the definitions in the 2 modes for example pretty easily we could wrap a definition written in internal module.

I think that would be great. I have no idea how we would go about doing that in the context of DefinitelyTyped. I don't know if there's precedent for it here. Perhaps we could ask the DT people?

Event attributes, context, etc

I wonder if those items should be fixed/discussed in a separate PR and keep this one just related to the normal/addons issue and possibly the internal/external issue.

To sum up, I'm willing to give this PR a +1 as-is and essentially choose 1.ii.c where we create another PR to add internal module support that looks like 1.ii.b unless @vsiao wants to update this PR to also include it.

I agree with this plan. I think we should iterate to add 1.ii.b and at least fix the EventAttributes since @fdecampredon correctly pointed out this is a bug. Thoughts @vsiao?
As for context, @fdecampredon, I've created #3641

Hey there, sorry for going MIA—been busy past couple of days.
@jbrantly Good point on external modules; we should definitely support them somewhere. But are we heading towards 4x code duplication? From what I'm reading, 1.ii.b sounds like it requires react.d.ts, react-addons.d.ts, react-global.d.ts, and react-addons-global.d.ts :( To that end, @pspeter3 and I would like to explore writing a script to generate those files so we don't have to do the code copying every time we make a change.
@fdecampredon I disagree that ReactAttributes is 'entirely' wrong—it is meant only as a base to HTMLAttributes and SVGAttributes; composite component props should not extend from ReactAttributes. We could perhaps take key, ref, and children out as BaseProps as you have, but the problem with having P extends BaseProps everywhere is that key, ref, and children are explicitly removed from the props property of ReactElement. I do however agree with you on contexts; they aren't a core feature so perhaps we can think of a way to support it without over-complexifying the types for simple use-cases.

But are we heading towards 4x code duplication?

If you look at the issue I opened on TypeScript they are saying that you can merge external modules. So it might actually only be 2x code duplication (one for external modules and one for internal). I haven't gotten it to actually work yet though.
Regarding internal modules, there is really no reason to duplicate code in react-global.d.ts and react-addons-global.d.ts. As soon as react-addons-global.d.ts is referenced anywhere in the project the addons property will be available everywhere. So I think the final version will have either 2x duplication (if we can get that external module merging issue resolved) or 3x.

@jbrantly—I added the global defs and a README.md to explain the duplication and discussion process. So I think that puts this PR squarely in 1.ii.b. lmk if you have any questions or concerns, and cc a collaborator if you think this is merge-ready. Thanks!

@vsiao Sorry for the delay, I was on vacation. This looks really good! Thanks a ton for all the work you put into this.
@johnnyreilly @vvakame +1 from me

Thanks!

It looks like we'll be able to take the 3 duplications down to 2 in TS 1.5: Microsoft/TypeScript#2019

Awesome!

:+1: :+1: :+1: thanks for following up, @jbrantly

@vsiao, I have been able to merge them with the ES6 exports in TypeScript 1.5.  See merge request #5660 and comment there.


setClearButtonCaption() to allow localisation

Hi again,
Could be great also to be able to localize or customize buttons captions.
Some setClearButtonCaption(String caption) could be a nice add :-)
Regards

The contents of the clear button can be customized by css.
Here's an example:
.signaturefield .signaturefield-clearbutton {
    border-radius: 5px;
    padding: 2px;
}
.signaturefield .signaturefield-clearbutton:before {
    content: "Hasta la vista, baby";
    width: auto;
}

Great, thanks. I will do it this way.
Regards.


Misaligned new page

The new page button position appears to be misaligned.

Setting the position to relative in my custom.css seems to resolve the issue.
.left-sidebar-inner .new-page {
  position: relative;
  bottom: 0;
}
nav.px-2 {
  padding-bottom: .5rem;
}

What is your logseq version?
获取 Outlook for iOShttps://aka.ms/o0ukef

发件人: Isaac Dadzie @.>
发送时间: Wednesday, January 12, 2022 4:55:52 PM
收件人: pengx17/logseq-dev-theme @.>
抄送: Subscribed @.***>
主题: [pengx17/logseq-dev-theme] Misaligned new page (Issue #32)
The new page button position appears to be misaligned.
[2022-01-12_08-05]https://user-images.githubusercontent.com/4581114/149094678-9da00655-3895-456c-a24e-64dbef2d58bb.png
Setting the position to relative in my custom.css seems to resolve the issue.
.left-sidebar-inner .new-page {
position: relative;
bottom: 0;
}
nav.px-2 {
padding-bottom: .5rem;
}
[2022-01-12_08-54]https://user-images.githubusercontent.com/4581114/149095353-b251e0bf-1e28-4da9-9852-99d4bb648b4b.png
―
Reply to this email directly, view it on GitHubhttps://github.com/pengx17/logseq-dev-theme/issues/32, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAEOVOVXHWWINWB2EAVRQYTUVU6ZPANCNFSM5LYMRSTQ.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

Logseq version 0.5.6
Dev theme version 1.23.11


Partially revert 21f043d

This patch crashes The Witcher 3 due to the chain of wnd_proc being
broken, so messages don't arrive to the parent window.
I'd say to properly ignore incoming messages would be to override the wnd_proc of the game itself, and peek the message.

This would also revert and reopen #12. I'm not married to the solution that's being reverted in this PR but we do need to find a way to have the same functionality.
Could you try whether changing the LRESULT(1) return with a call to DefWindowProcW works? I think this could sidestep inputs that are directed to the game while preserving the overall windowing functionality. Unfortunately I don't have a means to test this. It would be nice to have a directory of clients of hudhook so changes could be tested over as many games as possible.
Pinging @OneXDeveloper in case they have other ideas that could work here.

I haven’t had a chance to test out this original change yet. But I wonder if the trait approach would work? That would allow us to selectively enable this based off of the IO or other logic of our tools.

Here:
https://github.com/FransBouma/InjectableGenericCameraSystem/blob/90d7e39b2e9ff7736951a9ff47ac889707dc1072/Cameras/DMC5/InjectableGenericCameraSystem/InputHooker.cpp#L152-L164
You can see he hooked into GetMessage and then depending on the variables, he sets the message to NULL to avoid being processed by the windows procedure.
If I understand correctly, that would be the equivalent of hooking into the original windows procedure (the one it's called at the end of the injected one) and then in there decide to ignore the messages, or hook into the windows functions like GetMessage/PeekMessage and decide it there.
Cutting the chain right away means messages won't be handled to the parent procedure.

Here:
https://github.com/FransBouma/InjectableGenericCameraSystem/blob/90d7e39b2e9ff7736951a9ff47ac889707dc1072/Cameras/DMC5/InjectableGenericCameraSystem/InputHooker.cpp#L152-L164
You can see he hooked into GetMessage and then depending on the variables, he sets the message to NULL to avoid being processed by the windows procedure.
If I understand correctly, that would be the equivalent of hooking into the original windows procedure (the one it's called at the end of the injected one) and then in there decide to ignore the messages, or hook into the windows functions like GetMessage/PeekMessage and decide it there.

Oh, I see. Detouring those functions as well seems a bit much, I'd rather keep the profile as light as possible on that front and only detour what we absolutely need to.

Cutting the chain right away means messages won't be handled to the parent procedure.
Also, the Trait method could work too since it would be set by the user rather than the library itself, which can be avoided for programs with UB. Since we're adding a trait for commonalities between DX11 and DX12 in #13, we could do it in there, but I'm not totally convinced that's the way to go yet.

If we could defer control of this to the user, with sensible defaults, I think that would be the best way to go. We could merge #13 once it's ready and then figure out a good solution starting from there.

Superseeded by https://github.com/veeenu/hudhook/pull/13


feat(keycloak): proof of concept using @s3pweb/keycloak-admin-client-cjs

This PR is a PoC to see if exporting Keycloak Admin Client as CommonJS can help us upgrade keycloak
Fixes: https://issues.redhat.com/browse/RHIDP-3181
CI is failing because the wrapper doesn't export Users and Groups

no longer needed


Typo "Teams Room device"→"Teams Rooms device"

https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/blob/live/Teams/rooms/rooms-release-note.md
#PingMSFTDocs

Learn Build status updates of commit fcd34b4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Teams/rooms/rooms-release-note.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@dstrome PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Build Token Stream

I had no idea what this means....
I think i'm referring to performing lexical analysis on the template to generate a collection, or stream, of tokens.


AUR Package

Hello, could you please update the AUR package to the latest release?

Done! Enjoy.

Thanks a lot!


Port forwarding log has formatting issues

Testing #191540 on Linux
There are ANSI escape sequences as well as empty lines:
2023-08-30 11:12:19.936 [info] [forwarding] starting CLI
2023-08-30 11:12:19.997 [info] [forwarding] [2023-08-30 11:12:19] debug No code server tunnel found, creating new one

2023-08-30 11:12:19.997 [info] [forwarding] [2023-08-30 11:12:19] trace Found token in keyring

2023-08-30 11:12:23.233 [info] [forwarding] [2023-08-30 11:12:23] info Creating tunnel with the name: ubuntu-linux-22-04-desktop

2023-08-30 11:12:23.233 [info] [forwarding] [2023-08-30 11:12:23] trace Found token in keyring

2023-08-30 11:12:26.235 [info] [forwarding] [2023-08-30 11:12:26] trace Found token in keyring

2023-08-30 11:12:27.197 [info] [forwarding] [2023-08-30 11:12:27] debug Starting tunnel to server...

2023-08-30 11:12:27.199 [info] [forwarding] [2023-08-30 11:12:27] trace Found token in keyring

2023-08-30 11:12:28.872 [info] [forwarding] [2023-08-30 11:12:28] debug Connected to tunnel endpoint: TunnelRelayTunnelEndpoint { base: TunnelEndpoint { connection_mode: TunnelRelay, host_id: "ad01adb3-1b36-4c76-803c-eb1b09e822ff", host_public_keys: [], port_uri_format: Some("https://01bkhf70-{port}.eun1.devtunnels.ms/"), tunnel_uri: Some("https://01bkhf70.eun1.devtunnels.ms/"), port_ssh_command_format: Some("ssh 01bkhf70-{port}@ssh.eun1.devtunnels.ms"), tunnel_ssh_command: Some("ssh 01bkhf70@ssh.eun1.devtunnels.ms"), ssh_gateway_public_key: None }, host_relay_uri: Some("wss://eun1-data.rel.tunnels.api.visualstudio.com/api/v1/Host/Connect/01bkhf70"), client_relay_uri: Some("wss://eun1-data.rel.tunnels.api.visualstudio.com/api/v1/Client/Connect/01bkhf70") }

2023-08-30 11:12:28.872 [info] [forwarding] [2023-08-30 11:12:28] trace Found token in keyring

2023-08-30 11:12:28.873 [error] [forwarding]

2023-08-30 11:12:29.498 [info] [forwarding] [2023-08-30 11:12:29] info forwarding port 8000 at Private

2023-08-30 11:12:46.702 [error] [forwarding]

2023-08-30 11:12:46.702 [info] [forwarding] [2023-08-30 11:12:46] trace Found token in keyring

2023-08-30 11:12:47.371 [info] [forwarding] [2023-08-30 11:12:47] info forwarding port 3000 at Private

2023-08-30 11:14:40.594 [error] [forwarding]

I still see the ESC[2m[ parts being rendered on 1.82.0-insder commit e7756c on Linux.


Kleeja 3.1.6 show error after restore in the local server

Good Day support,
kindly note that i have restore Kleeja 3.1.6 in the local server with detalis ( XAMPP 8.1.12 PHP 8.1.12 ) but it show the below error, it's working fine after restore if the version is ( XAMPP 7.4.33  PHP 7.4.33 ) and less

thank you

any update please

Good Day support,
kindly note that i have restore Kleeja 3.1.6 in the local server with detalis ( XAMPP 8.1.12 PHP 8.1.12 ) but it show the below error, it's working fine after restore if the version is ( XAMPP 7.4.33 PHP 7.4.33 ) and less

thank you

We are aware of the compatibility problem with PHP 8. Our team is currently working on a new version, 3.1.7, which will include support for PHP 8. In the meantime, you may continue using PHP 7, as it works without issues.
We appreciate your patience and understanding. Stay tuned for updates regarding the release of version 3.1.7.


[Feedback] Wrist overlay counting yourself as a friend may lead to unnecessary confusion

Basically what the title says . I feel having the wrist counter add a tick for you to the friend counter may be unnecessary especially if you're trying to get a quick count of how many of your friends are in the instance and (now with this recent update) making sure to always count one down to not include yourself in the count.

Hmmm the only reason I did this change was to make the number consistent with the instance counter on the user/world dialog.

Hmmm the only reason I did this change was to make the number consistent with the instance counter on the user/world dialog.

I'm noticing that now actually. Is it necessary to even include yourself as a friend in the user/world dialog counter as well though or is that just an API thing? The reason I bring this up is I just feel it's kind of unnecessary bloat to the in-instance friend counter.

Yup that was the reason I chose to add yourself to wrist overlay instead of removing from dialog instance counter because it will require a lot more code to do, I might do it though if it's better to not include yourself it will just be a pain.

Yup that was the reason I chose to add yourself to wrist overlay instead of removing from dialog instance counter because it will require a lot more code to do, I might do it though if it's better to not include yourself it will just be a pain.

I figured that would've been the case. If you decide to do it though, your efforts definitely won't go unappreciated. ^^

https://github.com/Natsumi-sama/VRCX/commit/3b07a54bc67684c9030fe5569df1c010a7bd3613 yup that was annoying to do, and may give broken friend count when using an alt account depending if they are friends with main account or not but eh good enough.