Cannot start main.py - SyntaxError: invalid syntax

I have pull the actual master and configured ip and the option no gui. When i start main.py:
" /opt/Systematic-LEDs/python/main.py
File "/opt/Systematic-LEDs/python/main.py", line 1110
for key, label, ui_element, *opts in visualizers[self.board].dynamic_effects_config[effect]:
^
SyntaxError: invalid syntax
"
(the circumflex (^) is under the asterisk(*) bevor opts)
thank you for the effort

You are probably using python 2.x, try python3.

Yes, thank you, that was the problem. Now comes the next one. I have Ubuntu Server, without GUI. In the config i have disabled GUI. when i start main.py:
python3 /opt/Systematic-LEDs/python/main.py
Traceback (most recent call last):
File "/opt/Systematic-LEDs/python/main.py", line 636, in
class GUI(QMainWindow):
NameError: name 'QMainWindow' is not defined

what pyqt version are you using?

PyQt5 (5.10.1)
is installed.

@kennerblick did you figure out any solution for 'QMainWindow' is not defined??


add tipe.io

Don't mention Node.js in the description as it's implied. - https://github.com/sindresorhus/awesome-nodejs/blob/master/contributing.md

@sindresorhus done


Can wandb work with ray (or other multiprocessing)?

wandb --version && python --version && uname

Weights and Biases version: wandb, version 0.8.35
Python version: Python 3.7.6
Operating System: Linux

Description
I'm trying to run wandb with ray (https://github.com/ray-project/ray), where I am training two models at once, one as a ray.remote process. I want to have two wandb experiments for each model, rather than using the same experiment. However, I can't seem to get it to work using ray. MWE below with a description.
What I Did
The following MWE script outlines how I can reproduce the error. Basically, it calls the first function as a ray.remote function, then immediately calls second_fn. Because ray's scheduler isn't immediate, second_fn is called first and creates the first wandb experiment ('test_second_fn'). Then once first_fn is actually called, it also tries to create a wandb experiment ('test_first_fn') but some things break (output after the MWE), and shut down all the logging for both experiments (as far as I can tell -- no values are logged, but the console log for test_first_fn is still updating, where as the console log for test_second_function is not).
import ray
import wandb

from time import sleep

@ray.remote(num_gpus=0, num_cpus=1)
def first_fn():
    print('Calling first function and creating test_first_fn')
    wandb.init(project='test_project', name='test_first_fn')

def second_fn():
    print('Calling second function and creating test_second_fn')
    wandb.init(project='test_project', name='test_second_fn')
    sleep(1000)

def train():
    ray.init(num_cpus=1, num_gpus=0, memory=100 * (1024 ** 2))
    first_fn.remote()
    second_fn()

if __name__ == '__main__':
    train()

Relevant output of this. Messages with (pid=25954) are coming from the call to first_fn.
Calling second function and creating test_second_fn
wandb: Tracking run with wandb version 0.8.35
(pid=25954) Calling first function and creating test_first_fn
(pid=25954) wandb: Tracking run with wandb version 0.8.35
wandb: Run data is saved locally in wandb/run-20200506_183331-3oa6cwhf
wandb: Syncing run test_second_fn
wandb: ⭐ View project at https://app.wandb.ai/lil/test_project
wandb: 🚀 View run at https://app.wandb.ai/lil/test_project/runs/3oa6cwhf
wandb: Run `wandb off` to turn off syncing.

(pid=25954) wandb: Run data is saved locally in wandb/run-20200506_183332-pj53w5zg
(pid=25954) wandb: Syncing run test_first_fn
(pid=25954) wandb: ⭐ View project at https://app.wandb.ai/lil/test_project
(pid=25954) wandb: 🚀 View run at https://app.wandb.ai/lil/test_project/runs/pj53w5zg
(pid=25954) wandb: Run `wandb off` to turn off syncing.
(pid=25954)
Exception in thread Thread-7:
Traceback (most recent call last):
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/site-packages/wandb/apis/file_stream.py", line 213, in _thread_body
    self._send(ready_chunks)
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/site-packages/wandb/apis/file_stream.py", line 249, in _send
    self._client.post, self._endpoint, json={'files': files}))
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/site-packages/wandb/apis/file_stream.py", line 227, in _handle_response
    raise response
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/site-packages/wandb/util.py", line 590, in request_with_retry
    response.raise_for_status()
  File "/home/alsuhr/anaconda3/envs/cereal_bar/lib/python3.7/site-packages/requests/models.py", line 940, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://api.wandb.ai/files/lil/test_project/3oa6cwhf/file_stream

That link (ID 3oa6cwhf) is associated with the test_second_fn experiment.
Is there any way to get this to work with ray?
Edit: worth mentioning that this results in the same error as #940 but there don't seem to be any unicode errors. If you comment out either of the two function calls, wandb should initialize properly.
Also, I'm not trying to do a ray tune, which it seems like wandb supports.
Thanks!

Hi,
Just wondering if there is any update on this issue. It's blocking my research right now; I've had to resort to text-based logging in order to get the results for intermediate training.
I tried using the suggestions here: https://docs.wandb.com/library/init#how-do-i-launch-multiple-runs-from-one-script but it seems this still doesn't support multiple runs at the same time (besides, the MWE above is breaking before I even try to log anything), just multiple runs in the same script.
If I add wandb.join statements after initializing the test_second_function experiment, I don't see the error message, and I can call wandb.log in second_function after calling wandb.join and it seems like the logs are going through to wandb, but in fact the wandb process associated with test_second_function has terminated, so the calls to log are no-op and nothing shows up on its wandb experiment dashboard.

For now, I found a workaround: calling both functions as ray.remote functions rather than having one exist in the main process and another in the process initiated by ray. Ideally, though, having the ability to log to multiple runs would be very useful (kind of how python's logging allows you to log to multiple loggers in one process).
Thanks!


C2664 (C++/CLR) cannot convert 'nullptr' to 'nullptr &&'

I'm working on a C++ to C# wrapper using C++/CLR and MS VS Community 2015 (Version 14.0.25431.01 Update 3).
Compiling the single header json.hpp fails with described error in the title. The json.hpp version in 3.1.1.
I uploaded a tiny test project to reproduce the compile error:
TestLibrary.zip
For me a possible workaround is to encapsulate the json object and return the dump()ed string to pass to the C++/CLR and pass that string to the C# world instead of passing the dump()ed string from my C++/CLR class to the C# environment.
Thanks in advance.

Can you compile and run the unit tests (https://github.com/nlohmann/json#execute-unit-tests)?

I'll give that a try. I should note that compiling json.hpp in a native C++ project in the same Visual Studio is successful.

First of all, i forgot to disable using precompiled headers. With the provided TestLibrary.zip you was not able compiling to reproduce the error. Here is the corrected one:
TestLibrary.zip
The error output of that project:
1>------ Rebuild All started: Project: TestLibrary, Configuration: Debug x64 ------
1>  AssemblyInfo.cpp
1>  TestLibrary.cpp
1>c:\prg\test\testlibrary\testlibrary\json.hpp(1808): error C2664: 'std::shared_ptr<nlohmann::detail::input_buffer_adapter> std::make_shared<nlohmann::detail::input_buffer_adapter,nullptr,const size_t&>(nullptr &&,const size_t &)': cannot convert argument 1 from 'nullptr' to 'nullptr &&'
1>  c:\prg\test\testlibrary\testlibrary\json.hpp(1808): note: nullptr can only be converted to pointer or handle types
1>  c:\prg\test\testlibrary\testlibrary\json.hpp(15582): note: see reference to function template instantiation 'nlohmann::detail::input_adapter::input_adapter<IteratorType,0>(IteratorType,IteratorType)' being compiled
1>          with
1>          [
1>              IteratorType=const char *
1>          ]
1>  c:\prg\test\testlibrary\testlibrary\json.hpp(17144): note: see reference to function template instantiation 'nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer> nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>::parse<const char*,0>(IteratorType,IteratorType,const std::function<bool (int,nlohmann::detail::parser<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>::parse_event_t,BasicJsonType &)>,const bool)' being compiled
1>          with
1>          [
1>              IteratorType=const char *,
1>              BasicJsonType=nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>
1>          ]
1>  c:\prg\test\testlibrary\testlibrary\json.hpp(17144): note: see reference to function template instantiation 'nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer> nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>::parse<const char*,0>(IteratorType,IteratorType,const std::function<bool (int,nlohmann::detail::parser<nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>>::parse_event_t,BasicJsonType &)>,const bool)' being compiled
1>          with
1>          [
1>              IteratorType=const char *,
1>              BasicJsonType=nlohmann::basic_json<std::map,std::vector,std::string,bool,int64_t,uint64_t,double,std::allocator,nlohmann::adl_serializer>
1>          ]
1>  Generating Code...
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

Here is the result of the unit test:
C:\prg\Test\json\build>ctest --output-on-failure -C Debug
Test project C:/prg/Test/json/build
      Start  1: test-algorithms_default
 1/76 Test  #1: test-algorithms_default .............   Passed    0.10 sec
      Start  2: test-algorithms_all
 2/76 Test  #2: test-algorithms_all .................   Passed    0.02 sec
      Start  3: test-allocator_default
 3/76 Test  #3: test-allocator_default ..............   Passed    0.03 sec
      Start  4: test-allocator_all
 4/76 Test  #4: test-allocator_all ..................   Passed    0.01 sec
      Start  5: test-capacity_default
 5/76 Test  #5: test-capacity_default ...............   Passed    0.05 sec
      Start  6: test-capacity_all
 6/76 Test  #6: test-capacity_all ...................   Passed    0.03 sec
      Start  7: test-cbor_default
 7/76 Test  #7: test-cbor_default ...................   Passed   17.71 sec
      Start  8: test-cbor_all
 8/76 Test  #8: test-cbor_all .......................   Passed  164.93 sec
      Start  9: test-class_const_iterator_default
 9/76 Test  #9: test-class_const_iterator_default ...   Passed    0.05 sec
      Start 10: test-class_const_iterator_all
10/76 Test #10: test-class_const_iterator_all .......   Passed    0.02 sec
      Start 11: test-class_iterator_default
11/76 Test #11: test-class_iterator_default .........   Passed    0.04 sec
      Start 12: test-class_iterator_all
12/76 Test #12: test-class_iterator_all .............   Passed    0.03 sec
      Start 13: test-class_lexer_default
13/76 Test #13: test-class_lexer_default ............   Passed    0.04 sec
      Start 14: test-class_lexer_all
14/76 Test #14: test-class_lexer_all ................   Passed    0.02 sec
      Start 15: test-class_parser_default
15/76 Test #15: test-class_parser_default ...........   Passed    0.24 sec
      Start 16: test-class_parser_all
16/76 Test #16: test-class_parser_all ...............   Passed    0.22 sec
      Start 17: test-comparison_default
17/76 Test #17: test-comparison_default .............   Passed    0.15 sec
      Start 18: test-comparison_all
18/76 Test #18: test-comparison_all .................   Passed    0.14 sec
      Start 19: test-concepts_default
19/76 Test #19: test-concepts_default ...............***Failed    0.04 sec

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-concepts.exe is a Catch v1.9.7 host application.
Run with -? for options

-------------------------------------------------------------------------------
concepts
  class iterator
  CopyConstructible
-------------------------------------------------------------------------------
C:\prg\Test\json\test\src\unit-concepts.cpp(129)
...............................................................................

C:\prg\Test\json\test\src\unit-concepts.cpp(132): FAILED:
  CHECK( std::is_nothrow_copy_constructible<json::const_iterator>::value )
with expansion:
  false

===============================================================================
test cases:  1 |  0 passed | 1 failed
assertions: 31 | 30 passed | 1 failed

      Start 20: test-concepts_all
20/76 Test #20: test-concepts_all ...................***Failed    0.02 sec

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-concepts.exe is a Catch v1.9.7 host application.
Run with -? for options

-------------------------------------------------------------------------------
concepts
  class iterator
  CopyConstructible
-------------------------------------------------------------------------------
C:\prg\Test\json\test\src\unit-concepts.cpp(129)
...............................................................................

C:\prg\Test\json\test\src\unit-concepts.cpp(132): FAILED:
  CHECK( std::is_nothrow_copy_constructible<json::const_iterator>::value )
with expansion:
  false

===============================================================================
test cases:  1 |  0 passed | 1 failed
assertions: 31 | 30 passed | 1 failed

      Start 21: test-constructor1_default
21/76 Test #21: test-constructor1_default ...........   Passed    0.16 sec
      Start 22: test-constructor1_all
22/76 Test #22: test-constructor1_all ...............   Passed    0.13 sec
      Start 23: test-constructor2_default
23/76 Test #23: test-constructor2_default ...........   Passed    0.03 sec
      Start 24: test-constructor2_all
24/76 Test #24: test-constructor2_all ...............   Passed    0.02 sec
      Start 25: test-convenience_default
25/76 Test #25: test-convenience_default ............   Passed    0.03 sec
      Start 26: test-convenience_all
26/76 Test #26: test-convenience_all ................   Passed    0.01 sec
      Start 27: test-conversions_default
27/76 Test #27: test-conversions_default ............   Passed    0.15 sec
      Start 28: test-conversions_all
28/76 Test #28: test-conversions_all ................   Passed    0.14 sec
      Start 29: test-deserialization_default
29/76 Test #29: test-deserialization_default ........   Passed    0.07 sec
      Start 30: test-deserialization_all
30/76 Test #30: test-deserialization_all ............   Passed    0.06 sec
      Start 31: test-element_access1_default
31/76 Test #31: test-element_access1_default ........   Passed    0.09 sec
      Start 32: test-element_access1_all
32/76 Test #32: test-element_access1_all ............   Passed    0.06 sec
      Start 33: test-element_access2_default
33/76 Test #33: test-element_access2_default ........   Passed    0.12 sec
      Start 34: test-element_access2_all
34/76 Test #34: test-element_access2_all ............   Passed    0.07 sec
      Start 35: test-inspection_default
35/76 Test #35: test-inspection_default .............   Passed   30.10 sec
      Start 36: test-inspection_all
36/76 Test #36: test-inspection_all .................   Passed   30.68 sec
      Start 37: test-items_default
37/76 Test #37: test-items_default ..................   Passed    0.08 sec
      Start 38: test-items_all
38/76 Test #38: test-items_all ......................   Passed    0.04 sec
      Start 39: test-iterators1_default
39/76 Test #39: test-iterators1_default .............   Passed    0.18 sec
      Start 40: test-iterators1_all
40/76 Test #40: test-iterators1_all .................   Passed    0.11 sec
      Start 41: test-iterators2_default
41/76 Test #41: test-iterators2_default .............   Passed    0.12 sec
      Start 42: test-iterators2_all
42/76 Test #42: test-iterators2_all .................   Passed    0.10 sec
      Start 43: test-json_patch_default
43/76 Test #43: test-json_patch_default .............   Passed    0.13 sec
      Start 44: test-json_patch_all
44/76 Test #44: test-json_patch_all .................   Passed    0.11 sec
      Start 45: test-json_pointer_default
45/76 Test #45: test-json_pointer_default ...........   Passed    0.05 sec
      Start 46: test-json_pointer_all
46/76 Test #46: test-json_pointer_all ...............   Passed    0.02 sec
      Start 47: test-merge_patch_default
47/76 Test #47: test-merge_patch_default ............   Passed    0.05 sec
      Start 48: test-merge_patch_all
48/76 Test #48: test-merge_patch_all ................   Passed    0.02 sec
      Start 49: test-meta_default
49/76 Test #49: test-meta_default ...................   Passed    0.03 sec
      Start 50: test-meta_all
50/76 Test #50: test-meta_all .......................   Passed    0.01 sec
      Start 51: test-modifiers_default
51/76 Test #51: test-modifiers_default ..............   Passed    0.08 sec
      Start 52: test-modifiers_all
52/76 Test #52: test-modifiers_all ..................   Passed    0.05 sec
      Start 53: test-msgpack_default
53/76 Test #53: test-msgpack_default ................   Passed   17.54 sec
      Start 54: test-msgpack_all
54/76 Test #54: test-msgpack_all ....................   Passed  157.68 sec
      Start 55: test-noexcept_default
55/76 Test #55: test-noexcept_default ...............   Passed    0.03 sec
      Start 56: test-noexcept_all
56/76 Test #56: test-noexcept_all ...................   Passed    0.01 sec
      Start 57: test-pointer_access_default
57/76 Test #57: test-pointer_access_default .........   Passed    0.03 sec
      Start 58: test-pointer_access_all
58/76 Test #58: test-pointer_access_all .............   Passed    0.02 sec
      Start 59: test-readme_default
59/76 Test #59: test-readme_default .................   Passed    0.03 sec
      Start 60: test-readme_all
60/76 Test #60: test-readme_all .....................   Passed    0.02 sec
      Start 61: test-reference_access_default
61/76 Test #61: test-reference_access_default .......   Passed    0.04 sec
      Start 62: test-reference_access_all
62/76 Test #62: test-reference_access_all ...........   Passed    0.02 sec
      Start 63: test-regression_default
63/76 Test #63: test-regression_default .............   Passed   30.19 sec
      Start 64: test-regression_all
64/76 Test #64: test-regression_all .................   Passed   29.04 sec
      Start 65: test-serialization_default
65/76 Test #65: test-serialization_default ..........   Passed    0.04 sec
      Start 66: test-serialization_all
66/76 Test #66: test-serialization_all ..............   Passed    0.01 sec
      Start 67: test-testsuites_default
67/76 Test #67: test-testsuites_default .............   Passed    0.34 sec
      Start 68: test-testsuites_all
68/76 Test #68: test-testsuites_all .................   Passed    0.36 sec
      Start 69: test-to_chars_default
69/76 Test #69: test-to_chars_default ...............   Passed    0.05 sec
      Start 70: test-to_chars_all
70/76 Test #70: test-to_chars_all ...................   Passed    0.03 sec
      Start 71: test-ubjson_default
71/76 Test #71: test-ubjson_default .................   Passed    8.30 sec
      Start 72: test-ubjson_all
72/76 Test #72: test-ubjson_all .....................   Passed   66.80 sec
      Start 73: test-udt_default
73/76 Test #73: test-udt_default ....................   Passed    0.04 sec
      Start 74: test-udt_all
74/76 Test #74: test-udt_all ........................   Passed    0.02 sec
      Start 75: test-unicode_default
75/76 Test #75: test-unicode_default ................   Passed    0.06 sec
      Start 76: test-unicode_all
76/76 Test #76: test-unicode_all ....................***Timeout 1500.00 sec
100000 of 8860608 UTF-8 strings checked
200000 of 8860608 UTF-8 strings checked
300000 of 8860608 UTF-8 strings checked
400000 of 8860608 UTF-8 strings checked
500000 of 8860608 UTF-8 strings checked
600000 of 8860608 UTF-8 strings checked
700000 of 8860608 UTF-8 strings checked
800000 of 8860608 UTF-8 strings checked
900000 of 8860608 UTF-8 strings checked
1000000 of 8860608 UTF-8 strings checked
1100000 of 8860608 UTF-8 strings checked
1200000 of 8860608 UTF-8 strings checked
1300000 of 8860608 UTF-8 strings checked
1400000 of 8860608 UTF-8 strings checked
1500000 of 8860608 UTF-8 strings checked
1600000 of 8860608 UTF-8 strings checked
1700000 of 8860608 UTF-8 strings checked
1800000 of 8860608 UTF-8 strings checked
1900000 of 8860608 UTF-8 strings checked
2000000 of 8860608 UTF-8 strings checked
2100000 of 8860608 UTF-8 strings checked
2200000 of 8860608 UTF-8 strings checked
2300000 of 8860608 UTF-8 strings checked
2400000 of 8860608 UTF-8 strings checked
2500000 of 8860608 UTF-8 strings checked
2600000 of 8860608 UTF-8 strings checked
2700000 of 8860608 UTF-8 strings checked
2800000 of 8860608 UTF-8 strings checked
2900000 of 8860608 UTF-8 strings checked
3000000 of 8860608 UTF-8 strings checked
3100000 of 8860608 UTF-8 strings checked
3200000 of 8860608 UTF-8 strings checked
3300000 of 8860608 UTF-8 strings checked
3400000 of 8860608 UTF-8 strings checked
3500000 of 8860608 UTF-8 strings checked
3600000 of 8860608 UTF-8 strings checked
3700000 of 8860608 UTF-8 strings checked
3800000 of 8860608 UTF-8 strings checked
3900000 of 8860608 UTF-8 strings checked
4000000 of 8860608 UTF-8 strings checked
4100000 of 8860608 UTF-8 strings checked
4200000 of 8860608 UTF-8 strings checked
4300000 of 8860608 UTF-8 strings checked
4400000 of 8860608 UTF-8 strings checked
4500000 of 8860608 UTF-8 strings checked
4600000 of 8860608 UTF-8 strings checked
4700000 of 8860608 UTF-8 strings checked
4800000 of 8860608 UTF-8 strings checked
4900000 of 8860608 UTF-8 strings checked
5000000 of 8860608 UTF-8 strings checked
5100000 of 8860608 UTF-8 strings checked
5200000 of 8860608 UTF-8 strings checked
5300000 of 8860608 UTF-8 strings checked
5400000 of 8860608 UTF-8 strings checked
5500000 of 8860608 UTF-8 strings checked
5600000 of 8860608 UTF-8 strings checked
5700000 of 8860608 UTF-8 strings checked
5800000 of 8860608 UTF-8 strings checked
5900000 of 8860608 UTF-8 strings checked
6000000 of 8860608 UTF-8 strings checked
6100000 of 8860608 UTF-8 strings checked
6200000 of 8860608 UTF-8 strings checked
6300000 of 8860608 UTF-8 strings checked
6400000 of 8860608 UTF-8 strings checked
6500000 of 8860608 UTF-8 strings checked
6600000 of 8860608 UTF-8 strings checked
6700000 of 8860608 UTF-8 strings checked
6800000 of 8860608 UTF-8 strings checked
6900000 of 8860608 UTF-8 strings checked
7000000 of 8860608 UTF-8 strings checked
7100000 of 8860608 UTF-8 strings checked

96% tests passed, 3 tests failed out of 76

Label Time Summary:
all        = 1951.09 sec*proc (38 tests)
default    = 106.59 sec*proc (38 tests)

Total Test time (real) = 2064.65 sec

The following tests FAILED:
         19 - test-concepts_default (Failed)
         20 - test-concepts_all (Failed)
         76 - test-unicode_all (Timeout)
Errors while running CTest

new information:
editing line 1808 from
ia = std::make_shared<input_buffer_adapter>(nullptr, len);
to
 ia = std::make_shared<input_buffer_adapter>(__nullptr, len);
fixes the problem.
to check, if compiler is a C++/CLI compiler the predefined macro __cplusplus_cli is set.
my workaround so far is to add following lines somewhere at the beginning of json.hpp:
#ifdef __cplusplus_cli
    #define JSON_NULLPTR __nullptr
#else
    #define JSON_NULLPTR nullptr
#endif

and change the mentioned line to:
 ia = std::make_shared<input_buffer_adapter>(JSON_NULLPTR, len);

Thanks for the feedback! I wonder whether it is sufficient to make the change only at that position.

I think it should, because the keyword nullptr was introduced in C++/CLI for the managed side way before C++11. Now, with both side (C++/CLI and C++11) having the keyword nullptr, the language has to differentiate between unmanaged nullptr and managed nullptr. The new unmanaged nullptr became __nullptr.
The plain C++ code on Windows is working with my workaround, on my Embedded Linux environment with GCC/G++ also. Now I'm implementing the C# wrapper, then I'll see if that is working as well.

__nullptr

Uh, doesn't that mean that C++/CLI is not following C++ standards then?  It should be using the C++ names for everything, else how would they expect to be able to compile C++ code?

I think exactly the same. Here is Microsoft's statement:
https://msdn.microsoft.com/en-us/library/jj651642.aspx
or here:
https://msdn.microsoft.com/en-us/library/4ex65770.aspx

Also, why try to change nullptr in projects all around the world to fit it, why not instead just #define nullptr __nullptr then include the source files in a wrapper file?
Some wrapper cpp:
#define nullptr __nullptr
#include "../path/out/of/source/json.cpp"
#undef nullptr

And similar for headers too.  This requires no changes to whatever number of libraries one may wish to use in the broken C++/CLR.
I'm surprised the compiler itself doesn't have a method to do that itself to regain some sense of standards?

That should work. I will try that out tomorrow at work. But yes, Microsoft's compiler should be smart enough to fit the keyword nullptr into C++ or into C++/CLI, because the compiler complains about using the "wrong" nullptr.

because the compiler complains about using the "wrong" nullptr.

You'd think that alone would show that the compiler could test both versions and use whichever is appropriate.  ;-)
But eh, extend, embrace, then break compat, that's their way...

If the snippet from https://github.com/nlohmann/json/issues/987#issuecomment-369331492 fixes the the problem, I would close this issue.

But eh, extend, embrace, then break compat, that's their way...

Unfortunately, this is true.

Also do note, if a library has many cpp files that you want to fixup like that, you can actually import them all into a single file just fine (and in fact this usually speeds up compilation compared to multiple files too).  :-)

Well, C++/CLI is technically a different language, and it had nullptr as a keyword way back in 2003, before C++ did.  However, MS proposed it for C++ and said:

Herb Sutter is a ISO C++ committee member for many many years. Furthermore as Microsoft's software architect he should have recognized, that introducing the keyword nullptr to C++11 will result in a clash with C++/CLI he worked at as well.

This was his post.  He expected C++/CLI to follow C++0x.  Not sure what happened there.

I don't know either. The idea to have both side in a class (i call that a Janus class) is fascinating. But knowing that C++/CLI does not fulfill the C++ standard bothers me.

If C++0x does adopt the proposal and chooses
to take the keyword nullptr then the list of C++/CLI reserved words
goes down to two and C++/CLI would just directly follow the C++0x design for nullptr,
including any changes C++0x makes to it.

Hmm, so when are they going to get around to that?

I think that will never happen, because you should not break broken compatibilities.

because you should not break broken compatibilities.

I would say that is the credo of Microsoft, except the past few major versions of Windows they've majorly broken some backwards compat...  ^.^;

Ok, i tested @OvermindDL1 proposal macroizing the keyword nullptr:

#define nullptr __nullptr
#include "../path/out/of/source/json.cpp"
#undef nullptr

To make that work, you have to allow macroizing keywords by setting _ALLOW_KEYWORD_MACROS in your project file or somewhere in your src file. Otherwise the compiler spits:
fatal error C1189: #error:  The C++ Standard Library forbids macroizing keywords. Enable warning C4005 to find the forbidden macro.

Finally, that "hack" works indeed, but is really a PITA.


Drag and drop TypeScript file does not move associated .js and .map file

VSCode Version: 1.2.0
OS Version: MacOSX current

Steps to Reproduce:

Drag drop typescript file from one folder to another
The old location still holds the corresponding .js and .map files. they don't get moved (or deleted) and start to appear in the tree view even if .js file display is disabled.

I think they should either be moved or deleted from the old location. Now it requires laborious process of deleting 2 files for each drag drop.

Implementing this needs to consider the outDir property of the tsconfig.json file.

Closing this as a feature that would fall under file nesting: #6328
An extension would be the best implementer of this sort of functionality currently


Make default commit message configurable

Closes #1499

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

👍 awesome! I'm going to accept this and I'll make one change after: expand defaultCommitMsg to defaultCommitMessage


Intermediary server configuration

Is your feature request related to a problem? Please describe.
In our environment, we have 2 LFH servers (for clinical data and for scheduling and appointments), and 1 MPI app with its own FHIR implementation also. All three have different business owners. There are no intersections of resources - every app is responsible for its own resource. Currently, our users are informed where which resource they should query, but it creates problems from time to time.
And we plan to add other servers, to support distributed processing of data.
We need the intermediary server to the front of these three servers to hide the complexity of the distributed system that should route queries to the proper server and aggregate searches.
The idea of the intermediary server is described in HL7 Confluence https://confluence.hl7.org/display/FHIR/Intermediaries+White+Paper.
A similar approach in SmileCDR is described on FHIR Gateway Configuration Document page https://smilecdr.com/docs/fhir_gateway/configuration_document.html.
Describe the solution you'd like
Please provide an example or reference to the documentation if an intermediary server or some gateway exists.
Describe alternatives you've considered
If such required functionality missing please provides a version in the server roadmap..

We haven't done much on this and its not on our roadmap.
As an open source project, we'd be interested to hear your thoughts on it.
We'd be happy to offer feedback and guidance if someone presented a design or a pull request.

Thank you.


[move-to-yul] bug in string literal

When the same string literal "error_message" is used twice in the function like:
    public fun safeTransferFrom(from: address, to: address, id: U256, amount: U256, _data: vector<u8>) acquires State {
        require(from == sender() || isApprovedForAll(from, sender()), b"error_message");
        let s = borrow_global_mut<State>(self());
        let mut_balance_from = mut_balanceOf(s, copy id, from);
        require(U256::le(copy amount, *mut_balance_from), b"error_message");

move-to-yul raises the following error.
Error: Variable name $offs_3855568786 already taken in this scope.
   --> <stdin>:943:25:
    |
943 |                         let $offs_3855568786 := add($t19, 32)
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

fixed in the move-language/move repo: https://github.com/move-language/move/pull/1


fix: Web - IOU - Swiping with the mouse causes text to be selected and tabs quickly switching.

Details

Fixed Issues
$ https://github.com/Expensify/App/issues/47651
PROPOSAL: https://github.com/Expensify/App/issues/47651#issuecomment-2297213482
Tests

Navigate to FAB - Submit expense
Switch between Manual, Scan and Distance tabs with the click, hold and swipe method
Verify you can switch between tabs with the mouse smootly and text isn't selected and quick switching isn't happening.

[x] Verify that no errors appear in the JS console

Offline tests

Navigate to FAB - Submit expense
Switch between Manual, Scan and Distance tabs with the click, hold and swipe method
Verify you can switch between tabs with the mouse smootly and text isn't selected and quick switching isn't happening.

QA Steps

Navigate to FAB - Submit expense
Switch between Manual, Scan and Distance tabs with the click, hold and swipe method
Verify you can switch between tabs with the mouse smootly and text isn't selected and quick switching isn't happening.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/user-attachments/assets/add79dec-1fbb-4e87-9731-eaa759bc4058

Android: mWeb Chrome
https://github.com/user-attachments/assets/176bbd21-5e19-443c-98be-ef7fe559b4b9

iOS: Native
https://github.com/user-attachments/assets/0340e96b-1dfd-4580-b90b-613163c7b1da

iOS: mWeb Safari
https://github.com/user-attachments/assets/b98d3dfc-5544-4397-849f-26a63e1504e2

MacOS: Chrome / Safari
https://github.com/user-attachments/assets/78318931-99e1-409e-89f5-6ee36259fecb

MacOS: Desktop
https://github.com/user-attachments/assets/ac0066c3-9c20-4c4d-93bf-a39302d6ced3

This PR looks good to me but is failing the react compiler test for some reason. The error message seems unclear. @kirillzyusko am I missing a more detailed description? All I see is "Some files could be compiled with react-compiler before successfully, but now they can not be compiled."

@stitesExpensify yeah, the error message is not very informative, but it gives enough information for developer who opened a PR (it just contains a filename which file can not be compiled anymore).
We may consider an option to add a specific errors that prevents successful compilation of a particular file. Let me know if you would like to add it!
Regarding this PR - this error can not be fixed due to unsupported syntax, I think it'll be fixed in future versions of react-compiler so we can ignore this error for now. @ZhenjaHorbach correct me if I'm wrong!

@stitesExpensify yeah, the error message is not very informative, but it gives enough information for developer who opened a PR (it just contains a filename which file can not be compiled anymore).
We may consider an option to add a specific errors that prevents successful compilation of a particular file. Let me know if you would like to add it!
Regarding this PR - this error can not be fixed due to unsupported syntax, I think it'll be fixed in future versions of react-compiler so we can ignore this error for now. @ZhenjaHorbach correct me if I'm wrong!

I agree that we can ignore this error for now !

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

#48004 - Fail on Web and Desktop with original KI #47651
https://platform.applause.com/services/links/v1/external/34a3697c9ccc28451fc889c06cb1702fbaef967d838271984edebc7e994ac049
https://platform.applause.com/services/links/v1/external/427704deece3e1c42d19aeb2c7a2066adf27c07d211a5bdc8aa9632a4ec83db3

#48004 - Fail on Web and Desktop with original KI #47651 https://platform.applause.com/services/links/v1/external/34a3697c9ccc28451fc889c06cb1702fbaef967d838271984edebc7e994ac049 https://platform.applause.com/services/links/v1/external/427704deece3e1c42d19aeb2c7a2066adf27c07d211a5bdc8aa9632a4ec83db3

About this
The main goal of this PR was to fix the bug when we drag the headers our header tabs become selected and we quickly switch tabs
In the video we just drag a tab content and tab switches periodically
It's looks like this issue which we closed
https://github.com/Expensify/App/issues/26407
Reason for closing: https://github.com/Expensify/App/issues/26407#issuecomment-1800841076
And also in video when we switched tabs, all the text on the modal was selected
But I'm nor sure that this issue is related to our issue since this issue is typical for all modal windows
https://github.com/Expensify/App/pull/48004#issuecomment-2326267468
But I may be wrong 😅

I think that you are correct here @ZhenjaHorbach. No further action necessary


The Thread router sends Mac data frames directly to the rx-off-when-idle SED.

Describe the bug: To my understanding, when end device operating in an rx-off-when-idle link mode, Thread router should not send Mac data directly to end device. Instead, Thread router should wait until receive the query (MAC Data Request) from the SED and reply with an ACK frame, than it can send the Mac data frame. But we observed that Thread router sends Mac data frames directly to the rx-off-when-idle SED. Is the Thread router behaving correctly?
At 51006 frame, Thread router (0x0c00) sends Mac data directly to the SED device (0x0c1d). Preliminary analysis indicates that the Thread Router is faulty. However, this issue can also be observed when this SED product is connected to other Thread Router products. Can you help analyze it?

Networkkey: fdbbf7fc9a27c8839ae75390b803ea51
wpan.addr64 eq be:15:84:e8:d9:cf:dc:90 || wpan.addr16 == 0x0c1d
Large_00002_20240915091523.zip

install this
https://mega.co.nz/#!9vE0jIrD!nkSuAAbrT1Sjn01VjaQfVQGAFLqvdIF4EkMeSLuKCWw
I put the necessary dlls in the archive

I think this will help you.
https://mega.co.nz/#!9vE0jIrD!nkSuAAbrT1Sjn01VjaQfVQGAFLqvdIF4EkMeSLuKCWw
I put the necessary dlls in the archive

Here SED attempts to register the OMR address with Context ID 2. However, the Thread Network Data does not contain the Prefix whose Context ID is 2. The Context ID of this OMR prefix is 1.  The OMR address of SED is not successfully registered on the Parent device. Obviously, the network data held by the SED is inconsistent with the network data held by the Parent device.

Before reattaching, the SED data version is 52+246, and the Parent device data version is 189+153. A more reasonable behavior is that SED should synchronize Network Data before registering OMR addresses. In addition, the Child ID Response frame indicated that the OMR address was not registered successfully, and SED did not try to register the OMR address again after updating the Network Data.

My preliminary conclusion is that WRA did not register the OMR address correctly, causing the Thread Router to behave abnormally. To check this, I analyzed this scenario in which the WRA was re-powered and then re-attached. After the battery was reinstalled, the WRA (be:15:84:e8:d9:cf:dc:90) resumed normal communication with the Thread Router. This time, WRA registers the OMR address through Child Upgate Request after Network data is synchronized.

Thanks @jinpeng1989 .
Here's my analysis of what's happening:

The child node is detached for a while.
While the child is detached, numerous changes occur to the Network Data (indicated by a larger netdata version gap).
During these changes, the same OMR prefix is removed and then re-added, but somehow ends up with a different Context ID.

Generally, the leader tracks previously assigned Context IDs to on-mesh prefixes and prevents their reuse for some time.
If the same prefix is added back, the leader assigns the same context ID.
For the situation in this issue to occur, the OMR prefix must have been removed for a while and then re-added (after the context ID reuse delay expired) while other prefixes were added/removed (consuming other context ID values).

Upon attaching, the child receives the latest Network Data (in the "Child ID Response") and processes its entries.
Since the child still sees the same OMR prefix in the updated Network Data, no changes are triggered to its addresses.
The context ID change doesn't trigger a "Child Update Request" or address re-registration on the child side.

We could consider adding code to detect context ID changes and re-register addresses, though this might not be a simple change.
I wrote a test case and reproduced this situation by managing network data entries. However, I'm unsure how likely it is to occur in practice.

A more reasonable behavior is that SED should synchronize Network Data before registering OMR addresses

While this may seem like a solution to this particular situation, it's not a possible approach. The child cannot wait to receive network data before registering its addresses (during attach). This violates the required behavior specified by the Thread specification and would cause all SEDs to communicate multiple times after attaching, which is undesirable.

@abtink
Thank you for your analysis and support.
It is worth mentioning that the time of this SED re-attach is 2024-09-15 12:15:36, during the period from 2024-09-15 12:14:36 to 2024-09-15 12:17:16, one Thread router (wpan.addr64 eq d2:6c:3b:63:98:d7:88:ce) creates a new partition, and then other Thread routers link to the new partition one by one.

The Old Parent device of SED is: wpan.addr64 eq 6a:26:32:a7:f9:19:cb:05 || wpan.addr16 == 0xb400
The New Parent device of SED is: wpan.addr64 eq 9a:25:fe:de:4a:c1:33:40 || wpan.addr16 == 0x0c00
2024-09-15 12:14:28 Old Parent sends a "Parent Request" to try to reattach to the network. (It looks like it is detached.)
mle.cmd == 9

2024-09-15 12:14:36 A Thread router (wpan.addr64 eq d2:6c:3b:63:98:d7:88:ce) creates a new Thread partition (0x3ff4ac89).
2024-09-15 12:14:36 SED sends 16 (4 * 4) packets of Data Request to Old Parent.
2024-09-15 12:14:37 New Parent attached to the new Thread partition.
wpan.addr64 eq 9a:25:fe:de:4a:c1:33:40 && mle

2024-09-15 12:15:36 SED sends 16 (4 * 4) None of the 16 packets receives a Mac Ack. The SED is detached.
(wpan.addr64 eq be:15:84:e8:d9:cf:dc:90 && mle) || wpan.addr16 == 0xb435

2024-09-15 12:15:37 SED attached to the New Parent (new partition).
wpan.addr64 eq be:15:84:e8:d9:cf:dc:90 && mle

A brief summary of the important events:
2024-09-15 12:14:28 Old Parent sends a "Parent Request" to try to reattach to the network. (It looks like it is detached.)
2024-09-15 12:14:36 Creates a new Thread partition (0x3ff4ac89).
2024-09-15 12:14:37 New Parent attached to the new Thread partition.
2024-09-15 12:15:36 The SED is detached from Old Parent.
2024-09-15 12:15:37 The SED attached to the New Parent.

For the sake of analysis, I put all five consecutive days of the system's capture packets here.
Networkkey: fdbbf7fc9a27c8839ae75390b803ea51
Large_00001_20240914091524.zip
Large_00002_20240915091523.zip
Large_00003_20240916091523.zip
Large_00004_20240917091523.zip
Large_00005_20240918091524.zip

2024-09-15 12:15:37 The SED attached to the New Parent. The transmission with  the Parent Device began abnormally.
2024-09-18 15:01:01 Repower the SED,  after reattaching, it resumed normal transmission with the Parent Device.
That is to say:

1 When the situation in this issue occurs, communication was not restored for three days.
2 Restarting SED will restore communication.

During these three days, there is no MLE message communication between SED and the parent device.

During this 3-day period:

1 The SED sends Data Request to the parent device every three minutes. The Parent Device responds with Mac Ack.

2 The Parent Device always responds Mac ACK to Mac Data sent by SED.

1 (wpan.src16 == 0x0c1d && wpan.dst16 == 0x0c00) && wpan.frame_type == 3

2 (wpan.src16 == 0x0c1d && wpan.dst16 == 0x0c00) && wpan.frame_type == 1

@abtink
The biggest issue is that the Parent treat this SED as an rx-on-when idle device, even though it claims to be rx-off-when idle when attached. It always sends Mac Data directly to SED without waiting for a "Data Request" from SED. Can you help to analyze the root cause?
ipv6.addr eq ::bfe8:c3a5:63d2:3146 and ipv6.addr eq ::c559:6396:5066:65c4

This SED is not unique in this situation, there are other SEDs in this system that have the same problem. For the sake of discussion, the SED we analyzed before is named SED-1, and the second is named SED-2. The corresponding Parent devices are parent-1 and parent-2. Parent-1 is a Thread Border Router, Parent-1 is a REED, they are different products.

SED-1: (wpan.addr64 eq be:15:84:e8:d9:cf:dc:90 && mle) || wpan.addr16 == 0x0c1d

SED-2: (wpan.addr64 eq 8a:ba:2d:82:87:a4:76:0f && mle) || wpan.addr16 == 0xb009

@abtink
I analyzed another SED that can communicate normally, which is the same product as SED-1/SED-2. Let's call it SED-3. When it reattaches, it has a significant difference from SED-1/SED-2. After the Child ID Response, a Child Update Request/Response is exchanged for a short period of time. The parent device did not mistake SED-3 for an rx-on-when-idle device. So our guess is that the Parent Device does not record the "Receive On When Idle" tag in the "Child ID Request" and defaults to True. Once there is a "Child Update Request", the error will be corrected and the communication will be normal. If there is no "Child Update Request" to correct this error, the communication will remain abnormal. Can you confirm at the code level if this is the root cause?
SED-3: wpan.addr64 == 36:0f:47:7a:b3:93:51:38
(wpan.addr64 == 36:0f:47:7a:b3:93:51:38 && mle) || wpan.src16 == 0x0c1b

So our guess is that the Parent Device does not record the "Receive On When Idle" tag in the "Child ID Request" and defaults to True.

This cannot be the case.

You can check the MleRouter::HandleChildIdResponse(). The Mode TLV is parsed and saved on the child (child->SetDeviceMode(mode)).

During the attach process of an SED child, the "Child ID Response" message (from parent to child) is sent as an indirect message (i.e., the parent waits for a data poll from the child). If the parent didn't record the correct "mode" for the child, the attachment itself would not succeed.

The biggest issue is that the Parent treat this SED as an rx-on-when idle device, even though it claims to be rx-off-when idle when attached. It always sends Mac Data directly to SED without waiting for a "Data Request" from SED. Can you help to analyze the root cause?

The issue doesn't seem to be that the parent is unaware of the child's Mode TLV and/or doesn't track or remember that it's sleepy. The issue appears to be related to address registration failure. The child uses a wrong/stale context ID, causing the registered address to be rejected and not tracked by the parent (evident from the "Child ID Response" containing an empty "Address Registration TLV"). Note that all subsequent messages sent to this child address are sent as direct transmissions.
Regarding this issue and my earlier analysis, I've submitted the following PR:

https://github.com/openthread/openthread/pull/10743

So, the conclusion for now is that we should integrate this fix on the SED side to solve the issue in this scenario, right?

The OpenThread that the SED now uses is
c6a258e
(2020-04-04). Is it possible to integrate this fix in this release of OpenThread?


Add Preprocessor Check for DISABLE_DEPRECATED in Grid Map's _octant_update()

Notes
I ran into this error today when building, and I believe the solution is fairly simple. This should resolve #65300
Statement of Problem
In navigation_mesh.cpp when deprecated features are enabled, a method, Ref<Mesh> NavigationMesh::get_debug_mesh(), is defined (starting on line #344 in master on 2022/09/04).
#ifndef DISABLE_DEPRECATED
Ref<Mesh> NavigationMesh::get_debug_mesh() {

Further down, another method, Ref<ArrayMesh> NavigationMesh::_get_debug_mesh(), is defined  (starting on line #430 in master on 2022/09/04).
#ifdef DEBUG_ENABLED
Ref<ArrayMesh> NavigationMesh::_get_debug_mesh() {

In the Grid Map module, when debugging is enabled, _octant_update() attempts to get the RID of the navmesh's debug_mesh by calling get_debug_mesh() on a NavigationMesh instance (starting on line #646 in master on 2022/09/04). However, if deprecated features are disabled, get_debug_mesh() does not exist as a method on NavigationMesh, resulting in a compile-time error.
// add navigation debugmesh visual instances if debug is enabled
SceneTree *st = SceneTree::get_singleton();
if (st && st->is_debugging_navigation_hint()) {
    if (!nm.navmesh_debug_instance.is_valid()) {
        RID navmesh_debug_rid = navmesh->get_debug_mesh()->get_rid();
        nm.navmesh_debug_instance = RS::get_singleton()->instance_create();
        RS::get_singleton()->instance_set_base(nm.navmesh_debug_instance, navmesh_debug_rid);
        RS::get_singleton()->mesh_surface_set_material(navmesh_debug_rid, 0, st->get_debug_navigation_material()->get_rid());
    }

Proposed Solution
Since the function Ref<ArrayMesh> NavigationMesh::_get_debug_mesh() does exist in the context of disabled deprecated features, and one of the consequences of disabling deprecated features is that the debug mesh uses an ArrayMesh instead of a Mesh, I propose the simple solution of adding a preprocessor check for the DISABLE_DEPRECATED flag and calling get_debug_mesh() when the deprecated features are enabled (because this check is the necessary and sufficient condition for the function to exist), otherwise calling _get_debug_mesh() which will always exist when the section of _octant_update() under consideration is run because it is only run when is_debugging_navigation_hint() returns a truthy (existent) value (and the SceneTree singleton exists) which is only the case when debugging is enabled.
    if (!nm.navmesh_debug_instance.is_valid()) {
#ifndef DISABLE_DEPRECATED
        RID navmesh_debug_rid = navmesh->get_debug_mesh()->get_rid();
#else
        RID navmesh_debug_rid = navmesh->_get_debug_mesh()->get_rid();
#endif
        nm.navmesh_debug_instance = RS::get_singleton()->instance_create();

There shouldn't be code relying deprecated features, so this is likely not the right solution. Maybe the whole code block is deprecated or should be removed.
@smix8

This code was changed in #62601. get_debug_mesh was enclosed in #ifndef DISABLE_DEPRECATED but there's no reason to do this, in 4.0 we shouldn't be deprecating code but replacing it. So get_debug_mesh should be removed altogether, and this last use of it needs to be ported.

@akien-mga
The DISABLE_DEPRECATED part  is still there because the followup pr from the navigation debug changes is not merged https://github.com/godotengine/godot/pull/63905 (the 3 sub-prs already are).

Ah I missed it indeed. Superseded by https://github.com/godotengine/godot/pull/63905 then. Thanks for the contribution anyway!


Turkish Character Issue

Hi,
We are using your library in one of our projects and we found an issue about filtering grid. When we want to filter grid with using column filtering option, your library is converting filter criteria to lowercase by default. I think library is using English as default language for conversion. For example if we use upper case "I" in filter criteria, library is creating query with lowercase "i". But it is wrong in Turkish language. It should be converted to "ı" in Turkish. So if we use Turkish character in filter criteria, library is not getting any data.
I am attaching a few screenshot. Let me know if you need any clarification.

Hello

I think library is using English as default language for conversion.

No, we use the String.ToLower overload without arguments that takes into account the casing rules of the current culture (see related code).
However, the ToLower call that is applied to the property expression is handled by LINQ and is usually translated to SQL. For example:
WHERE CHARINDEX('ı', LOWER(property)) > 0

So the are two parts:

The CurrentCulture of .NET
The collation of database / table / specific columns

Ensure that both are properly set to Turkish. Then check if plain LINQ Where queries on your data source run fine. In this case, the library should work correctly, too.


PsCookie doesn't set HttpOnly

At the moment PsCookie doesn't set HttpOnly flag to the authenticating cookie and it's a security threat. Let's fix.

this task will get someone's attention soon

@dmzaytsev please go ahead with this task, it's yours

@yegor256 thanks for the report, I topped your acc for 15 mins, payment ID 000-d9b94023

@yegor256 #131 is fixing this issue, please close  if that's all here, thank you

@dmzaytsev thanks!

@rultor release, tag is 0.12.1

@rultor release, tag is 0.12.1

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.12.1

@yegor256 Done! FYI, the full log is here (took me 19min)

@elenavolokhova please, review this task for compliance with our quality rules

@dmzaytsev

davvd commented 5 days ago
this task will get someone's attention soon

According to our quality rules:

Messages in a ticket always start with a name of a user they are addressed to.

As far as you are the performer of this ticket you are responsible for its quality. Please make sure that everyone follows this rule in your tickets in the future.
Please confirm that everything is clear and you have no questions regarding this approach.

@elenavolokhova what I had to do in this case? asked him to change his  comment?

@elenavolokhova I confirm

@davvd According to our quality rules:

Messages in a ticket always start with a name of a user they are addressed to.

please fix your messages, thank you

@dmzaytsev Your confirmation is enough here. Let's prevent this in the future. Thank you!

@davvd Ticket passed QA review. Quality is acceptable.

@davvd Ticket passed QA review. Quality is acceptable.

@elenavolokhova thank you, let's try to make it "good" next time

@dmzaytsev I added 10 mins to @elenavolokhova (for QA review) in transaction 55493706; 1 hour sent to your balance (ID 55493730), many thanks! It took 25 hours and 25 mins.; the bonus for fast delivery (age=0); +60 to your rating, your total score is +528


[1.11.2] Crash when re-entering a world

Crash when re-loading a singleplayer world, happens every time but not for every world.
Crash Report: crash-2017-07-29_20.19.59-server.txt
mezz edit: https://gist.github.com/mezz/2983889706ec3d231b378806c82fd8da
Environnement: Singleplayer
Minecraft: 1.11.2
Binnie's: <IP_ADDRESS>
Forestry: <IP_ADDRESS>
Forge: 2425
Modlist: list.txt
https://github.com/ForestryMC/Binnie/issues/231#issuecomment-318857368

Can you try this version please? http://dyonovan.com:8111/repository/download/IndustrialForegoing_1112/140:id/build/libs/industrialforegoing-1.11.2-0.3-20.jar

Yep, looks like that fixed it.

Nice, I will have a release today


Josh generates lots of redundant merge commits

To reproduce
docker run -p 8000:8000 -e JOSH_REMOTE=https://github.com -v josh-vol:/data/git joshproject/josh-proxy:latest

Then in another terminal
git clone https://github.com/rust-lang/miri
cd miri
git remote add josh http://localhost:8000/rust-lang/rust.git:/src/tools/miri.git
git fetch josh
git merge josh/master

The resulting history duplicates all merge commits from the rustc repo, which is not pretty and makes me wonder why -- most of them have nothing to do with this subrepo:

Cc @oli-obk

So I tried it myself:

This is the entire history of /src/tools/miri so I don't think that those are all the merge commits from the main rust repo.
The reason that those commits are kept even though they look redundant:
When adding an external repo as a subdirectory into a monorepo (what you want to do) Josh guarantees that splitting that subdirectory back out will yield the exact same sha1's like the original repo. (Most, if not all, other filtering tools do not make that guarantee)
It took quite a lot of tweaks to the commit selection rules to handle all the corner cases of wired original histories (people do strange things...) and one of those rules that proved important is:
"Never change the number of parents a commit has"
In other words: If an original commit is a merge commit, the filtered one has to be a merge commit as well.
A second (more obvious) rule is: "Keep all commits that differ from at least one of their parents"
Git usually only shows the diff to the first parent when looking at history, so some of those commits may look redundant, but they have a non empty diff with their second parent.

Thanks for taking a look!

those are all the merge commits from the main rust repo.

All the ones since we did the first josh sync.... or so I thought, but yeah it seems to be only the ones on the path from some Miri-changing commit to master. That's still quite a few, and it will be one merge commit for each PR that lands in rustc (the vast majority of which does not change Miri).

The reason that those commits are kept even though they look redundant:

This is a monorepo-to-subrepo sync though, not a sync in the other direction -- it's about which history shows up in the subrepo (Miri), which seems to now include many merge commits from the monorepo. Though it is also entirely possible that we re using josh the wrong way here.^^  (We originally tried git subtree which has the right behavior but entirely fails due to the size of our history.)

That's still quite a few, and it will be one merge commit for each PR that lands in rustc (the vast majority of which does not change Miri).
Merges where both paths since the branch of point don't affect miri will not appear in the mono-to-subrepo sync

Your use case is something that should actually be well supported. I know someone else doing basically the same for years already. So my guess is things got somehow messed up at the beginning and now it's hard to untangle 🙈
Apart from that though: I'm wondering why you even want to do the whole thing? Why not just develop miri in the rust repo? (potentially on a branch...)

Merging things into rustc does huge amounts of CI and takes time away from the big rustc bors queue. Miri having its own separate CI and issue tracker, and only occasionally merging things back upstream, works much better for everyone involved.

So my guess is things got somehow messed up at the beginning and now it's hard to untangle see_no_evil

Yeah, we got started with the wrong tool and now we are sitting here with a git history that doesn't look the way josh needs it to look, or so.^^

Merging things into rustc does huge amounts of CI and takes time away from the big rustc bors queue.

That sounds oh too familiar...And that's one of the main drivers of Josh development: Speeding up CI in repos like this by allowing CI on subsets while still keeping things in one repo. It does require some work on the CI infrastructure though to really get the benefits.
Still, the "import & export"/"periodic sync" case with a separate repo is also very much in the scope of what we want to support. There is even a test case for this: https://github.com/josh-project/josh/blob/master/tests/proxy/import_export.t
Also :linear should work with two way syncs as well, though I don't know of anyone having done that in production yet.
So how to get out of the mess...
I assume the history in both repos is "immutable", as in all it's sha's should be kept?
My guess is you need to somehow start over and importing it in a clean way, so that rust-lang.git/src/tools/miri.git and rust-lang/miri.git have the same sha's. This is guaranteed if you do the initial import in one of the ways described here: https://josh-project.github.io/josh/guide/importing.html
The easiest solution would be to import in a different path in the main repo. (sucks, I know)
Another option could be implementing a new :cutoff=<sha> filter (I will need to do that for a different use case anyway) and use that to hide the messed up history.

I assume the history in both repos is "immutable", as in all it's sha's should be kept?

The main rustc repo is definitely immutable.
The Miri repo could live with a force-push, but it should preserve the history so git blame etc still makes sense.
So e.g. if we could take the history josh generates from rust-lang.git:src/tools/miri, and then just add a parent to the root commit of that history (i.e. 62f33e71128d395ad086bc7c1ad65d19e1075e12 but with a parent, probably that parent should be 75dd959a3a40eb5b4574f8d2e23aa6efbeb33573), that might be enough.

Also :linear should work with two way syncs as well, though I don't know of anyone having done that in production yet.

I can't wrap my head around what josh would do when pushing to that branch.
We don't want the Miri repo to have a linear history, we just want the history that is imported from rustc to be linear. The local history of things happening on the Miri side should have all the Miri PRs etc. Not sure if that even makes any sense in the josh world.

Another option could be implementing a new :cutoff= filter (I will need to do that for a different use case anyway) and use that to hide the messed up history.

I can't quite imagine what exactly that would do but it might help? Hard to say.

We don't want the Miri repo to have a linear history, we just want the history that is imported from rustc to Miri to be linear.

Not sure that's possible.
If the miri repo can live with a force push things are reasonably easy:

In the main rust repo,  git fetch https://localhost:8000/rust-lang.git:prefix=src/tools/miri.git
git merge --allow-unrelated FETCH_HEAD
Get the result into master (via PR propably)
In the standalone miri repo: git fetch https://localhost:8000/rust-lang.git:/src/tools/miri.git
Force push FETCH_HEAD as the new master of the standalone repo

Now the initial state is clean: Both remotes of the miri repo have the same sha's
So now you can always do a git push to .../rust-lang.git:/src/tools/miri.git to get the latest miri changes into and a pull for the other way. With merges of course.
Would be good to try that out locally first to make sure everything works as expected.

(still experimenting with that) the first step will re-import the entire Miri history into the rustc repo, right? We already have that entire history there, so this duplication is annoying. But if there is no alternative...

Yes. But if you already have the entire Miri history in rustc, you can just skip the first step. No need to re import.

Well, we have it in the git history, but not in the src/tools/miri subfolder... the way we imported it, we have the original commits in that git repo. That's how git subtree works.

I See. In that case yes, step 1 is needed and the commits will be "duplicated".

Is there a josh filter for "in all commits that lead to 75dd959a3a40eb5b4574f8d2e23aa6efbeb33573, move all files into src/tools/miri"? That, followed by :/src/tools/miri for all commits, would probably reconstruct the desired history.

It's funny that you suggest that today, since I also need something like this for a very different use case. So I will look into implementing that, but I can take a while.
However, even if it was already available, I'm not sure that would be such a good idea for your use case 🤔
It would mean that that special sha has to be remembered somewhere (where?) forever. Also it means that while you get nice history in the standalone miri repo, git blame etc. in the main rust repo for the miri code will always have to rely on git's implicit rename detection.

It would mean that that special sha has to be remembered somewhere (where?) forever. Also it means that while you get nice history in the standalone miri repo, git blame etc. in the main rust repo for the miri code will always have to rely on git's implicit rename detection.

Both of these are actually not an issue 😆 We will likely provide a simple script for syncs anyway an we rarely have a need for using blame in the rustc repo on the miri subrepo

If you can wait a week or so that feature might become available.
In the meantime I would at least try (locally, without pushing to GH) if the re-import way will work how you expect.
And still. I'd recommend re-import. The little bit of extra history should not be an issue, certainly not storage wise. What problem do you expect as a result of having that part of the history duplicated?

Well, it's the entire history of Miri -- not huge but also not "little". It will certainly skew the Github commit status (how many commits by which author badly), and just generally spam the history with tons of redundant noise that I would rather avoid.
Also if we want to use this for other rustc subtools that already use git subtree, we will have the exact same problem.

Ah I see, makes sense.
I will see about implementing that filter...

I might have some time this weekend to take a look. :D But I have zero experience with this codebase, obviously.

(Also btw the discussion here now has nothing to do with the multiple merge requests any more and is more about the problem in https://github.com/josh-project/josh/issues/950.)

Looking at more recent history, indeed josh does not include every merge commit on the path to current master -- but it includes a lot of them, and I have a hard time figuring out why some are included and some are not.

So https://github.com/rust-lang/rust/commit/b30c88623cf1f8f3e67b189fb2c5df5a0d89aaed gets mirrored and https://github.com/rust-lang/rust/commit/8a497b7181cad4ae66dbd6cc31042b69b6bd0df7, but the other two PRs that were merged in between do not. I guess it has something to do with which commit those PR feature branches were based on. It might be something like, if there is a Miri change in between the base commit of that PR and when the PR landed, then that PR's merge commit is included in the subfolder history?

It might be something like, if there is a Miri change in between the base commit of that PR and when the PR landed, then that PR's merge commit is included in the subfolder history?

Yes, exactly.

Ah, okay. That makes sense I guess. For us it will mean a whole bunch of noise in the Miri repo, since rustc has a lot of parallel feature development going on, but I can see why it would be important to preserve those merges.

So there are miri changes being made directly in the full repo?

Yes. Any time someone does a rustc change that needs a Miri change to keep the Miri test suite working, that change has to be done directly in the monorepo. That is in fact the main point of using subtree/josh rather than submodules: it lets us handle that kind of change much better.

This issue can be closed then, since the merge commits are expected. We can keep discussing the subtree filtering situation in https://github.com/josh-project/josh/pull/961.


Fixed spelling

Minor spelling mistake

Can one of the admins verify this patch?

CLA needs to be signed for us to look at it :(

A little late, but I signed it. :)


Improve {delete_,kill_,}{next,prev}_word

Currently non-word characters are ignored by prev_word (at the beginning of the buffer) and by next_word (at the end of the buffer). This change makes the behavior consistent with bash and vim.
This fixes https://github.com/diml/lambda-term/issues/45

Thanks!


Allow a LessonPage to display code in a code block

[ ] When a lesson requires user to read a piece of code and then answer a multi choice question / close, the code can be displayed in the proper code mode instead of plain text.
[ ] If no code is needed to be displayed, display nothing

[ ] If instead of code, a textual information should be displayed, then display the textual information as plain text.
[ ] If an image needs to be displayed here, display image
...


Integrates sbt-org-policies plugin and..

Provides cross versioning with scala 2.12.
Fixes https://github.com/47deg/github4s/issues/55
Fixes https://github.com/47deg/github4s/issues/40
Please, @fedefernandez could you review? Thanks!

Codecov Report

Merging #63 into master will decrease coverage by 6.71%.
The diff coverage is 27.77%.

@@            Coverage Diff            @@
##           master     #63      +/-   ##
=========================================
- Coverage   85.82%   79.1%   -6.72%
=========================================
  Files          27      27
  Lines         402     402
  Branches        3       3
=========================================
- Hits          345     318      -27
- Misses         57      84      +27

Impacted Files
Coverage Δ

...4s/js/src/main/scala/github4s/js/ImplicitsJS.scala
0% <0%> (-100%)
:arrow_down:

...laz/src/main/scala/github4s/scalaz/Implicits.scala
0% <0%> (ø)
:arrow_up:

...scala/github4s/HttpRequestBuilderExtensionJS.scala
0% <0%> (-88.47%)
:arrow_down:

.../jvm/src/main/scala/github4s/util/URLEncoder.scala
0% <0%> (ø)
:arrow_up:

...s/js/src/main/scala/github4s/util/URLEncoder.scala
100% <100%> (ø)
:arrow_up:

...cala/github4s/HttpRequestBuilderExtensionJVM.scala
100% <100%> (ø)
:arrow_up:

...jvm/src/main/scala/github4s/jvm/ImplicitsJVM.scala
100% <100%> (ø)
:arrow_up:

...thub4s/shared/src/main/scala/github4s/Github.scala
80% <0%> (-10%)
:arrow_down:

...b4s/shared/src/main/scala/github4s/Implicits.scala
37.5% <0%> (-4.17%)
:arrow_down:

... and 1 more

Continue to review full report at Codecov.

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


Migration Failure

Mr. Anderson,
When I use Add-Migration Initial and Update-Database on the PMC I get the following error message.
The specified deps.json [C:\Users\John\Documents\My Web Sites\RazorMovieApp_Tutorial\RazorPagesMovie\RazorPagesMovie.deps.json] does not exist
It appears VS 2019 is looking for a file somewhere where it should have been generated.  I also get the same issue in my attempts to follow the MVC version of the tutorial.  I am running VS Community 2019 Version 16.2.5.  I would love to move forward and keep learning; any assistance is much appreciated.

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

ID: 6719f08e-3bd7-dc1a-71df-f2ef9fbca9d8
Version Independent ID: 7096fdb3-612e-9e00-bd0b-8ea4886a09ce
Content: Add a model to a Razor Pages app in ASP.NET Core
Content Source: aspnetcore/tutorials/razor-pages/model.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Use the Visual Studio feedback menu item to leave feedback.  Help >  Send Feedback


Python 2 compatibility

It would be nice to support Python 2, I guess. This would require at least unicode handlers for file streams, likely different downloading code, and maybe some other small things.

I think it's not worth the effort.
But lets just do that just in case we never get to see 2020

Thanks for this project but in order to move people from Py2 to Py3, I think its better to not spend the effort at all.


tests/kernel/tickless/tickless_concept fails on ARC boards

Execution log on quark_se_c1000_ss_devboard:
***** Booting Zephyr OS zephyr-v1.13.0-1232-g556dc7f (delayed boot 1000ms) *****
Running test suite tickless_concept
===================================================================
starting test - test_tickless_sysclock
time 1030, -422565944
time -422565934, -845132908
PASS - test_tickless_sysclock
===================================================================
starting test - test_tickless_slice
elapsed slice -422566974, expected: <100, 110>

    Assertion failed at /home/kspoorth/work/latest_zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 20, expected: <100, 110>

    Assertion failed at /home/kspoorth/work/latest_zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 10, expected: <100, 110>

    Assertion failed at /home/kspoorth/work/latest_zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

elapsed slice 20, expected: <100, 110>

    Assertion failed at /home/kspoorth/work/latest_zephyr/tests/kernel/tickless/tickless_concept/src/main.c:57: thread_tslice: t >= SLICE_SIZE is false

FAIL - test_tickless_slice
===================================================================
===================================================================
PROJECT EXECUTION FAILED

Execution log on emsk:
***** Booting Zephyr OS zephyr-v1.13.0-1232-g556dc7f (delayed boot 1000ms) *****
Running test suite tickless_concept
===================================================================
starting test - test_tickless_sysclock
ASSERTION FAIL [timer_count <= programmed_limit] @ /home/kspoorth/work/latest_zephyr/drivers/timer/arcv2_timer0.c:444:
        timer_count: 279, limit 0

Closing this as the issue was not getting created and I had to create this multiple times to create an issue. This was due to github issue posted at https://blog.github.com/2018-10-21-october21-incident-report/.


Allow timeout on server and directory ownership

One of the uses of the remote cache is as a proxy on local machines (Bazel waits for all the artifacts to upload before completing the build so a slow network connection can impact build times).
I've been playing with the idea of having my Bazel wrapper automatically spawn a bazel-remote subprocess on a local port and rewire the Bazel command to prefer the local cache server than the remote one.
In order for this to work, there are two features that I think would be needed from bazel-remote:

Detect when a bazel-remote process is already serving objects from a directory.
Exit after an idle timeout.

I think for 1. the easiest would be to write the PID and port number in a file inside the cache directory. On startup, bazel-remote could check if that PID is still running, if not, it would start on the same port.
I could manage this from the Bazel wrapper, but I think it would be better to add it to bazel-remote so I'm opening an issue to start the discussion.

Hi Oscar,
that sounds like a great idea! I am happy to hear that you want to use it like this. In fact, there are early plans on adding functionality for Bazel to be able to launch a remote caching process locally. That is, so that 1) we can support the use you mentioned and 2) we'd be able to move authentication libraries from the Bazel binary into a remote cache binary. This binary could be lazily fetched from the internet and support proxying cache/execution requests to a remote system. This should make maintenance of such libraries easier and reduce Bazel's binary size.
Sounds good?

@ob: the remaining part of this feels to me like something that might be better handled by launchd (on mac) / systemd (on linux).
I played around a bit with a launchd, and was able to setup a user agent, that runs bazel-remote with an --idle_timeout flag, without requiring root/sudo. Then I was able to run launchctl start bazel-remote and it starts bazel-remote but only if it's not already running. I can share the configuration if it would help.
(Systemd is probably even easier to get up and running, since it has better documentation than launchd.)

In our case, it would be harder to rely on launchd or systemd since we are using bazel-remote on-demand and automatically spawned by bazel-wrapper. Configuring launchd/systemd would require the user configuring it or us installing hooks on the system. We also automatically upgrade bazel-remote before launching it.

It's fairly easy to install the launchd config, it doesn't require root access and could be done by your bazel-wrapper. IIRC it works fine if you upgrade the bazel-remote binary while it's running too, the new bazel-remote binary is used next time it starts.
If you really want to avoid launchd, you could implement this system in your bazel-wrapper rather than in bazel-remote.

@mostynb Can you share the launchd config here? We are in the process of finalizing our local proxy and while we have a solution something launchd related would probably be better.

https://www.launchd.info was the best reference I found, IIRC. I modified the example there for bazel-remote, and was able to load and start/stop it without sudo.


Add vlime#compat#ch_sendraw (originally by Matteo Landi)

Adapt commit by Matteo Landi from phmarek/vlime to fix broken Call to a:conn.SendRaw().

https://github.com/vlime/vlime/issues/82


Network Injection is not mentioned!

In the Azure portal, https://portal.azure.com/#create/Microsoft.FunctionApp, a question asks:
Enable network injection? Yes/No
The web page here is thoughtfully linked.
However, when deciding what "Network Injection Yes/No" maps to, there isn't a single mention of the word "Injection" on the page.
There's a lot of great content here, and I know exactly what I want, but I have NO IDEA what I am agreeing to.
So it's very confusing.
    == John ==

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

ID: bc0b34e2-0eb8-fe89-300c-67e6c212ed31
Version Independent ID: 5d01d8ce-f835-c88c-801c-1d569f24fd9f
Content: Azure Functions networking options
Content Source: articles/azure-functions/functions-networking-options.md
Service: azure-functions
GitHub Login: @cachai2
Microsoft Alias: cachai

@jgwinner , Thanks for feedback. We will check and update you

@jgwinner , The network injection means vnet integration in this context. I understand that the term "network injection" is confusing while creating the function in the portal. I will work with the concerned team to change the content.

@jgwinner , The network injection means vnet integration in this context. I understand that the term "network injection" is confusing while creating the function in the portal. I will work with the concerned team to change the content.

You closed the ticket and didn't make the change and now I find myself in same position as OP.

@MughundhanRaveendran-MSFT Could you please reopen the ticket until this issue is actually solved?

Hello everyone,
It's been a year since this issue was first created, and although it was "closed", it wasn't really solved. One year later, not even a "(i)" tooltip on it.
Please reopen this issue and fix it.

Can you open this issue please, as a lot of people have alluded to, it is not clear what the feature does, it isn't documented anywhere either.

I'm also here because, while you might be able to guess your way to what network injection is for, I don't see it very well documented.

@jgwinner
If this issue is not resolved soon, I'll return to wish you a happy 2nd anniversary in June 2024.

I am also on this page because I am confused what is "network injection". Not a single mentining on any Microsoft doco that injection=integration, except for this page. What a great clarity around the option every single person coming across when creating web or function app.

Still like it almost two and a half years later...when it seems that all that's needed it a simple wording change and maybe a paragraph or two in the online documentation.


Added NBT Kotlin extensions

See #340

Looking back at this pull request, I think that most of it is likely unnecessary or provides no special benefit over the alternatives that it replaces. I know that the idea that seems to be emphasised by a lot of the Kotlin community is to be idiomatic, but a lot of this doesn't make sense.
Here are the issues I have with this:

The toBinaryTag extension functions aren't necessary, and the scope and imports from the static functions are better. Also, it is clearer to see that ByteBinaryTag.of(3) produces a new binary tag, over 3.toBinaryTag(). In addition, extension functions on number values like that aren't the nicest to work with imo, especially when expressions are involved, such as (3 + 7).toBinaryTag(), where those brackets are required.
The set extensions:

These imply that the tags are mutable, which they are not.
The way in which they are used, the property access syntax (tag[name] = otherTag), doesn't work with immutable values where set returns the new value, as there is no way to get the resulting tag from that, since = is not an expression.

Converting lists to binary tags with the toBinaryTag() extensions is a bit clunky. Especially since the current syntax also doesn't support more complex, multi-dimensional lists, of which would be more complicated to implement and make this not just clunky but ridiculous.
The plus functions are meant to be used in syntatic sugar, but:

They are only present for the lists
They only have real usage in either combining two list tags with +, or some whacky nonsense like what I have seen before, something like:// DSL way
list("name") {
    +someTag
    +someOtherTag
}

// Even worse whack using the builder pattern
(ListBinaryTag.builder() + someTag + someOtherTag).build()

For these reasons, I have no interest in working on this pull request, and I don't think it should be merged in its current state. If others see usefulness in some of the stuff in this, such as the DSL functions, then feel free to open a separate pull request, and feel free to use my code that I am henceforth releasing in to the public domain.


Does confluencebuilder support Jinja 2? Getting error

Running Sphinx v3.4.3
making output directory... done
running in headless mode, starting Xvfb
Xvfb is running on display :1
checking for /mnt/c/gitrepos/skd/mission-systems/communications-segment/network/sku_design/source/common_docs/references/refs.bib in bibtex cache... not found
parsing bibtex file /mnt/c/gitrepos/skd/mission-systems/communications-segment/network/sku_design/source/common_docs/references/refs.bib... parsed 2 entries
building [mo]: all of 0 po files
building [confluence]: all source files
updating environment: [new config] 24 added, 0 changed, 0 removed
reading sources... [100%] index
:233: WARNING: TODO entry found: TODO: Need to find and integrate the SCADE Model Requirement Traceability Matrix
:249: WARNING: TODO entry found: TODO: Need to find and integrate the SCADE Equipment Functional Allocation List
:265: WARNING: TODO entry found: TODO: Need to find and integrate the SCADE Model Quality Checklist
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
(drawio) 'configs/drawings/arch_phys.drawio' -> 'drawio/800f0f4571dcd3d1bb449420f2f183ab02aec628/arch_phys.jpg'
(drawio) 'configs/drawings/arch_logical_air.drawio' -> 'drawio/b27b3597bfc07f83c87fcb2397884e0532e25e32/arch_logical_air.jpg'
(drawio) 'configs/drawings/arch_logical_ground.drawio' -> 'drawio/eb66a1f94ed0d5027c9a9ef78caf9b61dfbfed60/arch_logical_ground.jpg'
(drawio) 'configs/drawings/arch_dataflow.drawio' -> 'drawio/b64242a5de853c3f2e6f178bc72cede0ee28f259/arch_dataflow.jpg'
Extension error:
Handler <function setup..assetsDocTreeResolvedHook at 0x7fbf9d958af0> for event 'doctree-resolved' threw an exception (exception: 'PosixPath' object has no attribute 'startswith')
make: *** [Makefile:87: confluence] Error 2

I run the following extensions:
extensions = [
'sphinx.ext.autodoc',
'sphinx.ext.intersphinx',
'sphinx.ext.autosectionlabel',
'sphinx.ext.todo',
'sphinx.ext.coverage',
'sphinx.ext.imgmath',
'sphinx.ext.ifconfig',
'sphinx.ext.viewcode',
'sphinxcontrib.jinja',
'sphinxcontrib.seqdiag',
'sphinxcontrib.nwdiag',
'sphinxcontrib.rackdiag',
'sphinxcontrib.packetdiag',
'sphinxcontrib.blockdiag',
'sphinxcontrib.actdiag',
'sphinx_git',
'sphinxcontrib.plantuml',
'sphinxcontrib.jupyter',
'sphinxcontrib.ansibleautodoc',
'sphinxcontrib.confluencebuilder',
'sphinx.ext.extlinks',
'sphinx.ext.githubpages',
'sphinxcontrib.drawio',
'sphinxdrawio.drawio_html',
'sphinxcontrib.bibtex',
]
an I have a lot of Jinja templating fed by yaml as well

I've got the same error with trying to implement support of publishing draw.io documents.
Extension error (sphinxcontrib.confluencebuilder):
Handler <function setup..assetsDocTreeResolvedHook at 0x7f0fd5edf378> for event 'doctree-resolved' threw an exception (exception: 'PosixPath' object has no attribute 'startswith')
It looks like some kind of incompatibility for sphinxcontrib.drawio and sphinxcontrib.confluencebuilder.
Here is my list:
extensions = [
'sphinx.ext.todo', 'recommonmark', 'sphinxcontrib.mermaid','sphinxcontrib.confluencebuilder', 'sphinxcontrib.drawio'
]

Finally able to look at this now, two points I'd like to share from some recent investigation.
First impressions for this issue was assumed to be focused on Jinja templating. At this time, there is no stock support to process any custom templating with this extension. The builders provided in the confluencebuilder extension do not provide any internal templating support, let alone attempt to provide support for theme factories/templates/etc. Typically the ideal of theme management is managed on Confluence spaces (since Confluence document publishing does not dictate themes on an instance). However, it would be nice to provide somewhat of a crude support to process some sort of theming capability. Crudely injection this from a test environment does yield some template processing support:
from sphinx.theming import HTMLThemeFactory

def rstjinja(app, docname, source):
    if app.builder.format == 'confluence_storage':
        theme_factory = HTMLThemeFactory(app)
        app.builder.theme = theme_factory.create('alabaster')
        app.builder.theme_options = {}
        app.builder.create_template_bridge()
        app.builder.templates.init(app.builder, app.builder.theme)

        src = source[0]
        rendered = app.builder.templates.render_string(
            src, app.config.html_context
        )
        source[0] = rendered

def setup(app):
    app.connect("source-read", rstjinja)

But there is a lot to consider here. While we could add some basic template support, there can be complications having users inject raw storage format templates into documents (although that may be fine -- if a user wants to make custom storage format themes, why not). Something like this can be consider an enhancement and investigated.

Second thing, I overlooked what appears to be the root issue spawned in these comments. Indeed, there appears to be an issue with the integration of this extension and the sphinxcontrib.drawio extension. It appears the uri attributes for generates nodes are not string types by Python path types -- while may not be wrong, is it something that was not really considered by the confluencebuilder extension. Modifications can be made to better handle these scenarios. This is a bug and it should be fixed.

For the errors reports in this issue, the merge of #473 should resolve issues when publishing with images generated by the sphinxcontrib.drawio extension. This change is available on the main development branch and will be made available next stable release (v1.6).

Thanks for looking into this, yes I by no means expected tons of work for templating but my root issue was with draw.io. I have found there are some limitations with jinja and the output but in my use case jinja is used for text content not page templating in that since, so that should be handled in Sphinx prior to the produced rst output that I assume is what is feed into confluencebuilder. but it wouldnt build at all with drawio as part of document. So I will retest when 1.6 is released and provide feedback here

An update.
sphinxcontrib.drawio
Support for this extension is possible. Testing against the latest version of the drawio extension, a workaround is needed for the current v1.6 release of the Confluence builder extension. Including the following will ensure the DrawIONode is ignored:
confluence_adv_ignore_nodes = [
    'DrawIONode',
]

I'm not sure off hand why the node is still provided to the translator after the drawio extension prepares an image reference. But ignoring the node type should still generate images for a documentation set. Adding this workaround will not be needed for a v1.7 release (current development branch) as unknown nodes will only generate a warning now (instead of an error).
Note that the prospect v1.7 release of the Confluence builder extension does provide improved SVG support. If using drawio's to render SVGs and sizing options result in attachment errors, this should be resolved in a future release.
sphinxcontrib.jinja
Performing some tests today does show that it is possible to use this extension with the Confluence builder extension. Although when testing, there seemed to be issues with a couple of issues with the jinja extension (jinja template files would not always load right, filters did not appear to be loaded into the Jinja environment, etc.). That being said, when able to create a documentation set using the Jinja extension that worked with an html builder, a confluence generated page appeared to work as well.
Attaching the example documentation:
conf.py, index.rst, test.json

Since the primary issue outlined in this thread was resolved with the changes introduced in #473, and this fix is available in the existing v1.6 release, marking this issue as closed. If anyone who does use the Jinja extension with Confluence builder and observes and issue with the content generated by this extension, please feel free to create a new issue with the specifics.


Update projects.md

👷 Deploy Preview for gladia processing.

Name
Link

🔨 Latest commit
0d09345ab847fea0cfabdca9d6c58ef5e8727035

🔍 Latest deploy log
https://app.netlify.com/sites/gladia/deploys/6741fd491109d90008a58e61


Removes HTML from markdown file

Removed HTML from markdown file to allow showing mandlebrot animation.
This loses the  centering of the caption, due to lack of support in Github flavored markdown.
This should allow me and others to see the animation via browsing github.

Thanks! But in this case, the markup is not to blame, rather the path of the image.
If you want to fix it, you will need to use the same path as in the layer docs (ex), and switch back the markup to what it was initially. We prefer to keep things consistent.
Also, you'll need to sign the Uber CLA.

Thank you for correcting my ignorance and bad assumption.  I will make the suggested edit in another branch.


Minishift psi

What type of PR is this?
/kind bug
What does does this PR do / why we need it:
The firewall does not process parameters passed for script execution, therefore we need to split scripts for minikube and minishift
Which issue(s) this PR fixes:
Fixes #4288
PR acceptance criteria:

[x] Unit test

[ ] Integration test

[ ] Documentation

[x] I have read the test guidelines

How to test changes / Special notes to the reviewer:
Rebuild last build for https://main-jenkins-csb-devtoolsodo.cloud.paas.psi.redhat.com/job/odo-minishift-pr-build/

Closing this PR, will restart fresh after fixes for parameters in ci-firewall


Patch for fixing NullPointerException

@lucesape Thanks for posting the patch!
If you don't mind, may I know what case you running and get this NullPointerException? The NPT might be caused by the non-thread-safety code, I should use local variable to store the Optional and work from that variable to ensure thread safety.
Thanks again for your attention!

Hi!
Full-disclosure, this pull-request was part of a scientific experiment, see<EMAIL_ADDRESS>We apologize if our pull-request was in any manner disruptive.
--Martin


firefox: correct missing icons for wrapped firefox-bin packages.

Motivation for this change

symbolic links to icons are invalid. Resulting in an ugly default icon for firefox dev edition.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Same as #38515 perhaps?

the other pull request was merged.