Hello, can you support humidifier

The following information is obtained from IOT Tuya and rospogrigio / localtuya:
DPS                                 Function description     Code                   Type              Value range
"2 (value: middle)",           Humidifier Intensity    mode	                Enum	      {"range":["small","middle","large"]}
"3 (value: cancel)",            Timer(Hours)
"4 (value: 0)",                    Timer(Minutes)
"9 (value: 0)",                    Low Water Level
"10 (value: True)",             Master switch             switch	                Boolean	      {true,false}
"12 (value: humidity)",      Work Mode	            spray_mode	        Enum	      {"range":["sleep","humidity","work"]}
"15 (value: 65)",                Set Humidity             humidity_set	        Integer	      {"unit":"%","min":40,"max":90,"scale":0,"step":1}
"16 (value: 65)",                Current  Humidity
"22 (value: True)"              UV Lamp                   sterilization          Boolean	      {true,false}
dp's 3 and 4 – it is timer setting. 3 – in hours, 4 – in minutes. When timer is no set, then dp_3 have value 'cancel'.
Can you add support?  Thank you !

Do you have any identifying name for this device?

Do you have any identifying name for this device?

It's QT-JS2014
details:
https://www.alibaba.com/product-detail/2021-Newest-White-Led-Display-Constant_1600227334261.html?spm=a2700.galleryofferlist.normal_offer.d_title.3ef86ed93Reg5Q
iot.tuya.com debug info
{
"result": {
"category": "jsq",
"functions": [
{
"code": "spray_mode",
"type": "Enum",
"values": "{"range":["sleep","humidity","work"]}"
},
{
"code": "switch",
"type": "Boolean",
"values": "{}"
},
{
"code": "mode",
"type": "Enum",
"values": "{"range":["small","middle","large"]}"
},
{
"code": "sterilization",
"type": "Boolean",
"values": "{}"
},
{
"code": "humidity_set",
"type": "Integer",
"values": "{"unit":"%","min":40,"max":90,"scale":0,"step":1}"
}
],
"status": [
{
"code": "spray_mode",
"type": "Enum",
"values": "{"range":["sleep","humidity","work"]}"
},
{
"code": "switch",
"type": "Boolean",
"values": "{}"
},
{
"code": "mode",
"type": "Enum",
"values": "{"range":["small","middle","large"]}"
},
{
"code": "sterilization",
"type": "Boolean",
"values": "{}"
},
{
"code": "humidity_current",
"type": "Integer",
"values": "{"unit":"%","min":0,"max":100,"scale":0,"step":1}"
},
{
"code": "humidity_set",
"type": "Integer",
"values": "{"unit":"%","min":40,"max":90,"scale":0,"step":1}"
}
]
},
"success": true,
"t":<PHONE_NUMBER>360
}

Thanks.  About the only one that isn't described by the schema above is the "9": (value 0) Low water level.
I suspect this is a bad translation, and is actually a tank full indicator, similar to the Goldair dehumidifier.  In the Goldair case, it seems to be an error code bitfield (and I think I saw the schema in the past, where it was documented as "Error"), with the only observed values being 0 (no error) and 8 (tank full or removed).
Can you confirm this by 1) removing the tank and polling the dps values. 2) filling up the tank and polling the dps values.
The tank full status is useful to have for notifications, so if you can confirm it the integration will be more useful.

I just realised, this is a humidifier rather than a dehumidifier, so the "low water level" will be correct.  I just need the value for it then.

I've released 0.5.3 just now, with support for this device as a climate device.
I will replace this sometime in the future with a proper humidifier device implementation, but currently it is not a supported device type so this was quicker.
A climate device also gives access to the fan mode ("mode" above), which would become read-only for a humidifier device, but it seems the presets ("spray_mode" above) may already cover this with Sleep corresponding to Small, and Work corresponding to Large.  Possibly, like the Goldair dehumidifier, these presets force the fan mode to a specific value, and only the middle preset lets you control the fan separately, making the two controls a bit redundant.

Thank your job
I have tested the state of water shortage, "9 (value: 0)" becomes 1, it should be a binary sensor, and "15 (value: 65)" becomes unavailable at the same time

I test released 0.5.3, "Set Humidity" Cannot be set, "Timer" and "UV Lamp Switch" have no control buttons are displayed on the climate panel interface
log in HA:
2021-06-01 21:43:34 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Pureenjoy Humidifier for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 269, in async_setup
result = await component.async_setup_entry(hass, self) # type: ignore
File "/usr/src/homeassistant/homeassistant/components/climate/init.py", line 162, in async_setup_entry
return await hass.data[DOMAIN].async_setup_entry(entry)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 164, in async_setup_entry
raise ValueError("Config entry has already been setup!")
ValueError: Config entry has already been setup!
2021-06-01 21:50:01 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [547991721248] async_set_humidity() got an unexpected keyword argument 'humidity'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 167, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1481, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1516, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 658, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 689, in _handle_entity_call
result = hass.async_run_job(partial(getattr(entity, func), **data)) # type: ignore
File "/usr/src/homeassistant/homeassistant/core.py", line 443, in async_run_job
return self.async_run_hass_job(HassJob(target), *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 427, in async_run_hass_job
return self.async_add_hass_job(hassjob, *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 361, in async_add_hass_job
task = self.loop.create_task(hassjob.target(*args))
TypeError: async_set_humidity() got an unexpected keyword argument 'humidity'

It seems you have some config duplication, perhaps from an earlier attempt to get the humidifier working.
Please delete everything referring to the device from your configuration.yaml, restart HA, and check for any entities realted to it in the Configuration UI, and delete them before trying to add it again.
The other error is coming from the front end, I just tried Call Service from the Developer UI to set the humidity on my dehumidifier here, and it does not give that error, so it may be related to the earlier failure to properly initialise the device.

I've fixed the UV Switch, I had typed the wrong dps in for that field. Also added a descriptive field for the Water Low state.
I also went ahead and implemented the humidifier entity type. I've added it into the config keeping the climate entity there - they control the same DPS values, so there may be some conflict if you leave both configured, especially if you have automations.
Advantage of the humidifier type is that the default lovelace card can control the humidity.
The disadvantage is that it is lacking fan support, and also support for reporting current temperature and humidity, though I have added those as attributes, so they are available to automations and to some card types.  I guess next I'll have to implement sensor entities so I can export these properly, and also the Tank as a binary sensor as you requested.

I have deleted the localtuya components and tested 0.6.0. The humidity setting is still unavailable. The UV lamp has no switch. The humidifier card looks like the following:

debug log:
2021-06-02 21:11:18 DEBUG (MainThread) [custom_components.tuya_local] Setting up entry for device:<PHONE_NUMBER>3fda90b427
2021-06-02 21:11:18 INFO (MainThread) [custom_components.tuya_local.device] Creating device:<PHONE_NUMBER>3fda90b427
2021-06-02 21:11:18 INFO (MainThread) [custom_components.tuya_local.device] Setting protocol version for Pureenjoy Humidifier to 3.3.
2021-06-02 21:11:22 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Loaded device config andersson_gsh_heater.yaml
2021-06-02 21:11:22 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Loaded device config eanons_humidifier.yaml
2021-06-02 21:11:22 DEBUG (MainThread) [custom_components.tuya_local.humidifier] Adding humidifier device for eanons_humidifier
2021-06-02 21:12:27 DEBUG (SyncWorker_13) [custom_components.tuya_local.device] Refreshing device state for Pureenjoy Humidifier.
2021-06-02 21:12:27 DEBUG (SyncWorker_13) [custom_components.tuya_local.device] Pureenjoy Humidifier refreshed device state: {"devId": "03800086483fda90b427", "dps": {"2": "middle", "3": "cancel", "4": 0, "9": 0, "10": false, "12": "work", "15": 40, "16": 66, "22": false, "updated_at":<PHONE_NUMBER>.2252648}}
2021-06-02 21:12:27 DEBUG (SyncWorker_13) [custom_components.tuya_local.device] new cache state (including pending properties): {"2": "middle", "3": "cancel", "4": 0, "9": 0, "10": false, "12": "work", "15": 40, "16": 66, "22": false, "updated_at":<PHONE_NUMBER>.2252648}
2021-06-02 21:12:28 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 12 value from work to boost
2021-06-02 21:12:28 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 2 value from middle to medium
2021-06-02 21:12:28 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 9 value from 0 to OK
2021-06-02 21:13:25 DEBUG (SyncWorker_7) [custom_components.tuya_local.device] Refreshing device state for Pureenjoy Humidifier.
2021-06-02 21:13:25 DEBUG (SyncWorker_7) [custom_components.tuya_local.device] Pureenjoy Humidifier refreshed device state: {"devId": "03800086483fda90b427", "dps": {"2": "middle", "3": "cancel", "4": 0, "9": 0, "10": false, "12": "work", "15": 40, "16": 66, "22": false, "updated_at":<PHONE_NUMBER>.7587986}}
2021-06-02 21:14:49 DEBUG (SyncWorker_10) [custom_components.tuya_local.device] new cache state (including pending properties): {"2": "middle", "3": "cancel", "4": 0, "9": 0, "10": false, "12": "work", "15": 40, "16": 66, "22": false, "updated_at":<PHONE_NUMBER>.9826572}
2021-06-02 21:14:49 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 12 value from work to boost
2021-06-02 21:14:49 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 2 value from middle to medium
2021-06-02 21:14:49 DEBUG (MainThread) [custom_components.tuya_local.helpers.device_config] Eanons/pureenjoy Humidifier: Mapped dps 9 value from 0 to OK
2021-06-02 21:15:27 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [548009184176] async_set_humidity() got an unexpected keyword argument 'humidity'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 167, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1481, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1516, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 658, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 689, in _handle_entity_call
result = hass.async_run_job(partial(getattr(entity, func), **data)) # type: ignore
File "/usr/src/homeassistant/homeassistant/core.py", line 443, in async_run_job
return self.async_run_hass_job(HassJob(target), *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 427, in async_run_hass_job
return self.async_add_hass_job(hassjob, *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 361, in async_add_hass_job
task = self.loop.create_task(hassjob.target(*args))
TypeError: async_set_humidity() got an unexpected keyword argument 'humidity'

Thank you again for your job
Explain "humility" mode in spray_ mode("12 (value: humidity)") it is not normal mode, it should be constant humidity mode, which means to keep running at the set humidity,"work" mode is the working mode, which means to stop running at the set humidity, not the boost mode
btw:
mode("2 (value: middle)") ,It's the amount of mist from the humidifier,and it can also be understood as fan speed

OK, I've reproduced the humidity setting problem, it seems the frontend is using keyword args for this, so the parameter name needs to match exactly.  I will modify and make a new release today.  For the UV light, you need to enable the switch entity on the device (in Configuration/Integrations, select the device in Tuya Local box, and choose Options to change which entites are enabled).  Maybe it can be modelled as a light, I did not think of that, but the functionality is the same since it only has on/off capabiities, and you probably don't want it included in automations for "turn on all lights".
I mapped humidifier intensity mode to fan_mode because the climate entity in HA supports adjusting fan, swing and preset, and I thought fan was closest match.  But for humidifier entity, there is no fan support, so it is better to change it to "intensity_mode" I guess. Maybe you need to include both the climate and humidifier entities for now to be able to adjust this.
For the presets (spray_mode), do all modes allow setting intensity, or only the "work" mode?  My guess is that Sleep mode forces "small" intensity to stay quiet, and Humidify mode automatically adjusts intensity to keep constant humidity, would that be correct?
If it is correct, then in my future plan I plan to support pairing of DPS so that the Home Assistant mode could control spray mode and intensity mode together like:
Sleep: spray_mode="sleep"
Auto: spray_mode="humidify"
Eco: spray_mode="work", intensity_mode="small"
Normal: spray_mode="work", intensity_mode="middle"
Boost: spray_mode="work", intensity_mode="large"
I tried to use standard mode names from https://github.com/home-assistant/core/blob/dev/homeassistant/components/humidifier/const.py:

MODE_NORMAL = "normal"
MODE_ECO = "eco"
MODE_AWAY = "away"
MODE_BOOST = "boost"
MODE_COMFORT = "comfort"
MODE_HOME = "home"
MODE_SLEEP = "sleep"
MODE_AUTO = "auto"
MODE_BABY = "baby"

Different mode names is technically possible, but there will be no translations in the UI if they are not part of the base Home Assistant mode set.

Thank you. setting the target humidity can be controlled. I have selected the switch and humidifier options at the same time. The switch entity cannot be used. The UV lamp is not mapped to the switch entity

I'm not sure why the second switch is showing up as disabled.  I double checked, the switch is set to dps 22, and that matches your original request and the logs you've posted since.  The unit tests are passing, so the config seems correct for a switch.
The only think I can think of is that the only switches I have for testing here are with power monitoring, and maybe the generic switch containing a function for power that returns None in your case is causing a problem in Home Assistant. If you have anything in the logs it would help confirm if that is the problem.

Your guess is correct, the switch can not be used because there is no power attribute
2021-06-04 20:15:41 ERROR (MainThread) [homeassistant.components.switch] Error adding entities for domain switch with platform tuya_local
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 558, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 581, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 334, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 370, in _async_write_ha_state
attr.update(self.state_attributes or {})
File "/usr/src/homeassistant/homeassistant/components/switch/init.py", line 107, in state_attributes
value = getattr(self, prop)
File "/config/custom_components/tuya_local/generic/switch.py", line 87, in current_power_w
if self._power_dps is None:
AttributeError: 'TuyaLocalSwitch' object has no attribute '_power_dps'
2021-06-04 20:15:41 ERROR (MainThread) [homeassistant.components.switch] Error while setting up tuya_local platform for switch
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 239, in _async_setup_platform
await asyncio.gather(*pending)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 364, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 558, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 581, in add_to_platform_finish
self.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 334, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 370, in _async_write_ha_state
attr.update(self.state_attributes or {})
File "/usr/src/homeassistant/homeassistant/components/switch/init.py", line 107, in state_attributes
value = getattr(self, prop)
File "/config/custom_components/tuya_local/generic/switch.py", line 87, in current_power_w
if self._power_dps is None:
AttributeError: 'TuyaLocalSwitch' object has no attribute '_power_dps'

Oh, its a bug, The power dps should be None when it doesn't exist in the config, but it is not even initialised.

I hope this issue is fixed in 0.6.2.
I will add a proper fan entity in soon, so you can control the intensity as a "fan" without needing to configure a climate entity.  And also move some of the more important attributes out to their own sensors (current humidity mainly), as after reading the discussions about why the humidifier entity is lacking in features compared with the climate entity, it seems the modern way is to implement everything in separate smaller entities tied together by being attached to the same device.

Thanks, UV lamp is ready to use in 0.6.2


Update use-statsig-for-analytics-only.mdx

🚀 Deployed on https://6463ed95177a4d1a619961fa--cozy-fox-0defec.netlify.app


MeasureExpression is not working

Somehow this measure expression is always not working.
<MeasureGroups>
        <MeasureGroup name='度量' table='t_olap_person'>
	        <Measures>
		       <Measure name="测试" aggregator="sum" formatString='#,###'>
			         <MeasureExpression>
				        <SQL dialect="mysql"> (case when `t_olap_person`.`f_birth_year`=1991 then 1 else 0 end) </SQL>
				 </MeasureExpression>
			</Measure>
		</Measures>
		<DimensionLinks>
			<FactLink dimension='维度'/>
		</DimensionLinks>
        </MeasureGroup>
</MeasureGroups>

I get the error like
mondrian.olap.MondrianException: Mondrian Error:Cube '...': Measure '测试' must contain either a source column or a source expression, but not both

One for the Mondrian or  Saiku mailing lists I'm afraid.


Animations (Marquee, Flash) in Badge Preview of the App

Description
The Badge should react according to the selected animation. Currently it only displays the Text onto the preview.
GIF of How it should work

Would you like to work on the issue?
YES

@adityastic that is not the marquee effect as shown by the device.

@yashk2000  is the left marquee different in the actual device?


Support extra_deps arg for rosidl both cc and py

This stems from a problem I ran into yesterday, where python_rules numpy wasn't providing the cpp headers and I would end up in a following scenario -
ali@bdai_docker:/workspaces/bdai/projects/dexterity$ bazel build //...
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=103
INFO: Reading rc options for 'build' from /workspaces/bdai/projects/dexterity/.bazelrc:
  'build' options: --announce_rc --cxxopt=-std=c++20 --cxxopt=-Werror --cxxopt=-Wall --cxxopt=-Wextra --cxxopt=-Wdouble-promotion --cxxopt=-Wformat --cxxopt=-Wunused --cxxopt=-Wfloat-equal --cxxopt=-Wshadow --cxxopt=-Wconversion --cxxopt=-Winline --cxxopt=-Wno-variadic-macros --cxxopt=-Wnon-virtual-dtor --cxxopt=-Wpedantic --incompatible_strict_action_env --@aspect_rules_py//py:interpreter_version=3.10.12
INFO: Analyzed 59 targets (5 packages loaded, 10431 targets configured).
INFO: Found 59 targets...
ERROR: /workspaces/bdai/projects/dexterity/ws/src/mocap_print/BUILD:5:24: Compiling ws/src/mocap_print/mocap_generated_interfaces/py/mocap_generated_interfaces/msg/_marker_s.c failed: (Exit 1): gcc failed: error executing command (from target //ws/src/mocap_print:_mocap_generated_interfaces_py_c) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -MD -MF ... (remaining 110 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
bazel-out/k8-fastbuild/bin/ws/src/mocap_print/mocap_generated_interfaces/py/mocap_generated_interfaces/msg/_marker_s.c:11:10: fatal error: numpy/ndarrayobject.h: No such file or directory
   11 | #include "numpy/ndarrayobject.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~

And unsurprisingly -
ali@bdai_docker:/workspaces/bdai/projects/dexterity$ bazelisk query "@pypi_numpy//:*" | grep ndarrayobject
Loading: 0 packages loaded
@pypi_numpy//:site-packages/numpy/core/include/numpy/ndarrayobject.h
Loading: 0 packages loaded

Via this patch users would be able to provide the cc dependency as an extra. I don't think it's a perfect solution, but it is a solution that doesn't involve touching python_rules themselves. An example to use this would be -
rosidl_interfaces_group(
    name = "mocap_generated_interfaces",
    interfaces = [
        "msg/RigidBody.msg",
        "msg/Marker.msg",
        "msg/RigidBodies.msg",
    ],
    visibility = ["//:__pkg__"],
    deps = [
        "@ros2//:builtin_interfaces",
        "@ros2//:geometry_msgs",
    ],
    extra_deps = [
        "@numpy_repo//:numpy_cc",
    ],
)

cc: thanks @dta-bdai for this patch :)

This change is

#include "numpy/ndarrayobject.h"

Hm... I'm a bit suspicious that either
(a) we have a bug in drake-ros that we're not able to observe (i.e., we have system-installed numpy, and you do not), or
(b) there is something misconfigured on your side that requires numpy when really it shouldn't be required.
Do you know if you have system-wide installed numpy, or is it purely local to Bazel?

Also, can you reproduce this error in drake-ros itself, perhaps by adjusting the installed dependencies and running within a container?

#include "numpy/ndarrayobject.h"

Hm... I'm a bit suspicious that either (a) we have a bug in drake-ros that we're not able to observe (i.e., we have system-installed numpy, and you do not), or (b) there is something misconfigured on your side that requires numpy when really it shouldn't be required.
Do you know if you have system-wide installed numpy, or is it purely local to Bazel?

We do have a broken version of systemwide numpy but we're going for a more aggressive hermetic environment where we don't depend on system deps where we don't absolutely have to. This seemed to have solved the problem in the docker container we're running into. On our end, it's much better to modify our bazel approach than to change dockerfiles as of now.

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @ali-bdai)

a discussion (no related file): nit The usage of extra_deps may be ambiguous w.r.t. what language this is intended for; you may get mixed providers (e.g. cc going where py should be or vice-versa).
If this approach is indeed needed, then the language type should be qualified.

Absolutely, that's why we wanted to push stuff upstream as well. Currently this works for us "as it is" as a temporary solution.

If this approach is indeed needed, ..

As primary the maintainer of TRI's starlark rule set, I'll advocate that drake-ros should accept & merge something like this, even if it's not "needed" for numpy.  Macros that wrap things like creating a library should always do their best to pass through options from higher layer callers above then down into the lower layer primitives like cc_library and py_library.  It's not really feasible to argue that pass-throughs are never necessary, because we can't foresee every circumstance.
Certainly root causing and fixing the numpy thing the "right" way is ideal, but having an escape hatch is important for improving iteration speed and allowing for hotfixes during emergencies.

... the language type should be qualified.

I agree with this part.  It should be named cc_extra_deps and py_extra_deps.


Many of our NixOS services run as root and shouldn't

Ideally, they'd also be AppArmor'd and so on, but at the least they should get their own users, ideally in a way that we don't have to go manually add users for each individual service.
Anyone have a list of those modules handy so we can make this issue into a checklist? If not, I'll try to compile one later.

Our X server version in particular is supposedly capable to run root-less with systemd.

Related to #14645

Has the X server issue in particular been fixed?

Many services need to bind to a port < 1024 and require either running as root (and maybe dropping the privileges), some iptables forwarding trick or a capabilities setting. This restriction was considered a security feature but actually makes things worse and it's still here basically for no other reason than the historical one. It can be disable in the kernel with
#define PROT_SOCK 0

What do you think about it?

For services that support it, using systemd socket activation is a really nice way to let a process use a port < 1024 (systemd will bind the port and spawn children on each connection).
I don't see why this restriction "makes things worse", so I would not want to disable it. E.g., I wouldn't want a rogue process to be able to bind on port 22!

What's wrong with net_bind capability for services that don't support socket activation?

For services that don't support socket activation, I prefer iptables/nftables based forwarding. net_bind allows the service to bind to any privileged port, while with iptables/nftables it can only receive traffic from the pre-specified ports.

I don't see why this restriction "makes things worse"

In my opinion It makes things more complicated by requiring another step before running the program with really no benefit.

I wouldn't want a rogue process to be able to bind on port 22!

If sshd or some other server it's running already it won't be able to bind, and if there's none what's the problem with that? You shouldn't rely on the port number for security. You have to verify the fingerprint (for ssh) or a certificate (for a webserver).

@spacekitteh with gnome 3.22 we can run x without root privileges (see #19081)

systemd version 232 will support dynamically created users for the lifespan of services:

Support for dynamically creating users for the lifetime of a service
has been added. If DynamicUser=yes is specified, user and group IDs
will be allocated from the range 61184..65519 for the lifetime of the
service. They can be resolved using the new nss-systemd.so NSS
module. The module must be enabled in /etc/nsswitch.conf. Services
started in this way have PrivateTmp= and RemoveIPC= enabled, so that
any resources allocated by the service will be cleaned up when the
service exits. They also have ProtectHome=read-only and
ProtectSystem=strict enabled, so they are not able to make any
permanent modifications to the system.

This sounds to me like it would solve this problem very elegantly.

bump

Regarding services binding to ports lower than 1024, there's also CAP_NET_BIND_SERVICE as described here. The command itself needs to be run as root but once done any user can launch the binary and have it bind lower ports.
It's also non-permanent so if the binary is replaced the permission is lost.

@Unode, we do not need to fiddle with setcap. systemd will handle that: https://www.freedesktop.org/software/systemd/man/systemd.exec.html

Are there any updates to this issue, please?

It's now possible to run X rootless with #47773, though using a display manager still requires root.
Does anyone know if it's possible at all? The display manager needs root in order to login but it seems to me that the permission could be dropped once logged in.

If anyone's interested I found out about net.ipv4.ip_unprivileged_port_start sysctl option that can be set to 0 to remove the privileged port restriction.
I'll try to explain it again: the "security" mechanism is the following: "I'm talking to  on :<privileged_port>, it must have root premissions, therefore it's secure". This only made sense 30-40 years ago: a hacker couldn't simply set up is own mainframe, become root and mitm your connection but in 2019 we have unix running on watches, being root is meaningless. The correct way to authenticate is to use public key cryptography.
Protecting these ports is only useful if, for example, you have a socket activate sshd and don't want untrusted local users to bind to port 22, basically jamming the connection. I don't know how common this is. Meanwhile if I want to fire up a one-time webserver I have to fiddle with, setcap (doesn't work for a script or any binary in the /nix/store because it's read only), or setup port forwarding with iptables. If I'm in a hurry I'll end up running it as root, and that's not good.

@rnhmjoj for the one-time www server case, have you tested whether something like
nix run nixpkgs.busybox -c systemd-run --uid=nobody \
   --property=AmbientCapabilities=CAP_NET_BIND_SERVICE -r httpd -p 80 -f

works?

@joachifm I didn't know about that, thank you. Interestingly, someone just told me Apple removed the privileged ports in macOS 10.14: https://news.ycombinator.com/item?id=18302380.

Is this being worked on? It would be nice to get an option to setcap binaries in general

In general this issue remains a goal of NixOS . How often, and by whom, the issue is worked on varies. I'll be writing a PR to run our phpfpm service entirely without root once 21.05 is out, for example.
It might be a good idea to compile a list of services that run as the root user and then classify which ones don't need to, giving this issue a concrete task list.
I'm not sure if anyone is interested in compiling that list, though.

Note that DynamicUser=true requires nss-systemd.

Here is a very complex GitHub search that appears to match services that run as root (excluding ones that explicitly specify User = "root":
https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+path%3Anixos+(AND+lang%3Anix+AND+(systemd+AND+%2Fservices+%3D+{%2F+AND+%2F[a-z\-]*+%3D%2F)+OR+(%2Fsystemd.services.[a-z\-]*+%3D%2F))+AND++(NOT+%2FDynamicUser+%3D+true%3B%24%2F+NOT+%2FUser+%3D+"root"%3B%24%2F+NOT+"boot.initrd.systemd.services")&type=code


Mockups for alternative relabelings

Relabelings for lemma wâpamêw with emojis

https://user-images.githubusercontent.com/15003407/150276848-d302d716-4cdc-4afa-909c-d9428b762e83.mov

Relabelings for wordform niwâpamâw with emojis

https://user-images.githubusercontent.com/15003407/150277363-7695cfa3-4a63-406a-8a2d-566262b15928.mov

Relabelings for lemma wâpamêw without emojis

https://user-images.githubusercontent.com/15003407/150277392-3bef564d-9ffc-4f04-8c95-0824a7268550.mov

Relabelings for wordform nimaskomak with emojis

https://user-images.githubusercontent.com/15003407/150297251-458d5acb-6c6f-46cf-80c9-fc0bc252fb5c.mov

Relabelings for wordform nīnágūts'īdìtɫīīzh with emojis

https://user-images.githubusercontent.com/15003407/150297984-e936e352-a2e8-495a-8e7a-783c7e9a1e7d.mov

@nienna73 Here are now elaborated mockups for relabing, with the three primary alternatives. The emoji for lexeme-specific info (here an open book) and the overall positioning of the information can well be discussed.

This refactor is well underway. There's now one option that changes the relabelling globally. This can be done through the settings page or the options at the bottom of the page. Do we still want this one accessible to users?

@nienna73 Yes, I can confirm we can still leave the selection of the relabeling scheme in conjunction with the paradigms, so it is explicitly visible there. Though we might decide later on to simplify things. What we probably would no longer need are the Community vs. Linguist Mode toggles at the bottom of the page (in part because they are sometimes difficult to reach), in part because we ought to add nêhiyawêwin mode there as well, for the sake completeness and consistency.


vscode extension develop webview Abnormal interface display

vscode version 1.81.1
my html create a input

The datalist option is not directly below the input

in browser is normal

Duplicate of #129999


Deleting user from VM, unsupported

[Enter feedback here]

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

ID: 0474c5a5-4231-0e39-f63f-f7bc05cb7797
Version Independent ID: 22ea94c8-cc6f-97aa-77b1-4ffca845807e
Content: az vm user
Content Source: latest/docs-ref-autogen/vm/user.yml
Service: virtual-machines
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

Attempting to delete a user from a VM, returns "Deleting a user is not supported on Windows VM"!

@zhoxing-ms for awareness

@garrygbain Could you please send the debug log (add --debug parameter) to me by email? My email address is<EMAIL_ADDRESS>

This problem was by designed. We need the Compute team to confirm whether the current Windows VM supports deleting the user

@garrygbain Thanks for reaching out to us and reporting this issue. Could you please elaborate on your ask ? What is your use case and what are you trying to achieve ? Awaiting your reply.

@garrygbain Adding on to the above comment, please let me know if you are using a Windows VM or Linux VM. Awaiting your reply.

Hi @navba-MSFT  We have 10 Windows VMs; These are used to access environments and we often setup user accounts on each VM. I have scripted adding the accounts but unable to delete the accounts by script, so this is being completed manually.

@garrygbain You can try the below workaround and check if that helps:
Create a file by name script.ps1 with below content:

Remove-LocalUser -Name 'testUser'

Then you can run the below command remotely:

Invoke-AzVMRunCommand -ResourceGroupName $resourceGroup -Name $vmName -CommandId 'RunPowerShellScript' -ScriptPath .\script.ps1

Hope this helps.

@garrygbain Thanks for getting back. Could you please run the below command to set the subscription context first and then run the above invoke command ?

Set-AzContext -Subscription $subscriptionId
Select-AzSubscription -SubscriptionId 'XXXX-XXXX-XXXX-XXXX'
az account set --subscription "XXXX-XXXXX-XXXXX-XXXX"

@garrygbain Thanks for getting back. We will now proceed with closure of this GitHub issue. If you need any further assistance on this issue in future, please feel free to reopen this thread. We would be happy to help.

HI, what about if i want to delete the user across multiple  VMs in different subscriptions, the az cli, 'az vm user delete' allows you to provide ids for all the VMs irrespective of subscription. Also the workaround doesnt address the issue which is why the cmd isnt working. ANy ideas on how to resolve? Thanks

@garrygbain Thanks for getting back. We will now proceed with closure of this GitHub issue. If you need any further assistance on this issue in future, please feel free to reopen this thread. We would be happy to help.

not working for domain user

@navba-MSFT i raised a similar issue and it got closed, without a response. Your solution doesn't cover the use-case where i am trying to delete a user across multiple vms in didfferent subscriptions. can you kindly recommend a way forward, why does the az vm user --ids state that it can do that when the error states otherwise. Also @zhoxing-ms and @yonzhan where should this issue be addressed, seeing as my issue was closed before a solution was given? Thank you.

@JereO-Nc see my reply in your github issue https://github.com/Azure/azure-cli/issues/23595


change module name from 'client'

Hi
I'm working on adding SCRAM support to https://github.com/pgjdbc/pgadba and that is a library that uses the module system.
The default module that this library gets published under is named 'client' and that is extremely generic.
It also gives me this warning when compiled with maven:
[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *
Would you consider adding a module-info.java file?

I ran into this issue today, actually the module is named client because the JAR is lacking module metadata (no module-info and no Automatic-Module-Name entry in the MANIFEST.MF) hence the module name is whatever the name of the archive (i.e. if it is named client.jar then the module name is client) which is clearly not ideal and explains the warning.
This can be easily fixed by adding Automatic-Module-Name in the MANIFEST.MF of each modules (client, common...), Maven can do that automatically:
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifestEntries>
              <Automatic-Module-Name>${project.groupId}.${project.artifactId}</Automatic-Module-Name>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>

Then the best would be to actually modularized the library by defining proper module-info.java descriptor.
I have a way to bypass this issue within my project so it's not that urgent for me but not providing such metadata generally makes it difficult to integrate scram to a Java modular application.
Regards

Hi, this is on the roadmap, but there's no ETA yet.


running ci

run ci
Microsoft Reviewers: Open in CodeFlow

We could force this PR in and fix the test failures with another PR btw.

Btw, the CI failures is likely not because of the changes in this PR.

Do you think we merge this into Bicep-params-file?
Also I found this sample test input from (prototype syntax) I did while ago in the logs

I'll force merge this


Added prefetch to MADV_WILLNEED in madvise

MADV_WILLNEED did not even prefetch memory so prefetch added to MADV_WILLNEED in madvise.

I checked all the changes, and the changes work correctly.


Add tests for codegen of (tagged) template literals

I've started adding codegen tests within the crochet_codegen crate.  In a future PR, I'll migrate all codegen tests out of the crochet crate into crochet_codegen.

Codecov Report

Merging #185 (55de5bd) into main (8e4049a) will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #185      +/-   ##
==========================================
+ Coverage   94.53%   94.58%   +0.04%
==========================================
  Files          30       30
  Lines        3205     3197       -8
==========================================
- Hits         3030     3024       -6
+ Misses        175      173       -2

Impacted Files
Coverage Δ

crates/crochet_codegen/src/js.rs
90.61% <100.00%> (+0.32%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us.


[BUG]Chatbot input design distorted

Describe the bug
When i  paste text in input more than three lines  chatbot input design are distorted

@HenryHengZJ i want to work on this issue.

@HenryHengZJ is this still an issue?
@vkrm-segta have you been able to fix this issue?

oh sorry forgot to close the issue. It has been fixed and merged - https://github.com/FlowiseAI/Flowise/pull/333


When BlazeFace (full-range) could be released?

Description of issue (what needs changing)
No response
Clear description
BlazeFace (short-range) works really great but I wonder when the BlazeFace (full-range) model for face detection could be released?
Correct links
No response
Parameters defined
No response
Returns defined
No response
Raises listed and defined
No response
Usage example
https://developers.google.com/mediapipe/solutions/vision/face_detector/index#models
Request visuals, if applicable
No response
Submit a pull request?
No response

Hi @StevenSK-king,
At present, we lack information regarding the availability timeline. It could be in the development phase and will be accessible upon completion. Unfortunately, we cannot provide a specific timeline at this moment. Rest assured, we will keep you informed through the same thread once it becomes officially available.
Thank you

bump on this as well, really enjoying using blazeface short range but a lot of my subjects are in the 8-15 foot range. any timeline/update would be greatly appreciated.

looking forward for that too

Anyone at Google have an update on this? Been sitting indefinitely for months

Hi, are there any updated about this? Thanks in advance for replying.

You can find the download link for the full-range models of the previous Mediapipe here.

Hey, thanks for the reply. I tried using the old model and as far as I can remember, there was an issue when trying to load it as explained in the docs. Do you have different experiences with this? Thanks in advance!

I am also waiting for the long-range model. Meanwhile, since my application is not required to be superfast. I ran the person detection model first to get person crops and then ran the short-range face detection model on all the people crops and then derived the face crops in the original picture from this information. Works really well for me.
PS. I had to run NMS to remove duplicate face boxes.

Does anyone know if there's currently a model which works at ~5 metres / 10 ft in any version which has the face landmarks? It seems to work well for me until the gaze with the camera is lost, and then it fails to detect at 5-10 feet. Maintaining the gaze up to 10 feet works fine though, so it seems to be very close.
Sadly no update on the "Coming soon" on the landing page for a long time now.


🍱 Composable TTY components

The TTY interactive mode is not composable at all. We should provide functions so that an implementer can easily make one if they want to. The current interactive mode is more for show and should be removed.

The interactive mode was removed!

This will be too difficult without Notty.


Trouble compiling R/Rcpp library with all debug info

I have the following snippet for reproducing a crash in the reticulate R library, which you can run directly with nix-shell:
let pkgs = import <nixpkgs> {}; in
with { inherit (pkgs) mkShell enableDebugging rstudioWrapper rWrapper rPackages python3 gdb callPackage lib stdenv writeShellScriptBin; };

let
  keepDebugInfo' = stdenv: stdenv //
    { mkDerivation = args: stdenv.mkDerivation (args // {
        dontStrip = true;
        hardeningDisable = [ "all" ];
        preConfigure = ''
          export NIX_DEBUG=1
          export NIX_CFLAGS_COMPILE="$NIX_CFLAGS_COMPILE -gdwarf -Og -O0 -g3 -g"
          '';
      });
    };
  stdenv = keepDebugInfo' pkgs.stdenv;
  my_rPackages = callPackage (pkgs.path + "/pkgs/development/r-modules") {
    overrides = {};
    pkgs = pkgs // { callPackage = lib.callPackageWith ( pkgs // { inherit stdenv; }); };
    };

  myR = selector: rWrapper.override { packages = selector my_rPackages; };
  rStuff = myR (p: with p; [ reticulate ]); #keras tensorflow ]);
  pyStuff = python.withPackages (p: with p; [ Keras tensorflow ]);

  debugsh = writeShellScriptBin "debug.sh" ''
    #! /usr/bin/env bash
    exec gdb -quiet\
        -ex "set auto-load safe-path /"\
        -ex "set confirm off"\
        -ex "run"\
        -ex "break py_run_string_impl"\
        -ex "run"\
        -ex "info shared"\
        -ex "info locals"\
        -ex "quit" \
        -ex "set confirm on" "$@"
    '';
in
  mkShell {
    name = "woo-science";
    buildInputs = [
      rStuff
      pyStuff
      gdb
      ];
    shellHook = ''
      exec R --slave --no-restore --vanilla --file=test.r -d ${debugsh}/bin/debug.sh'';
    }

The info locals gdb command always complains about no symbol table information, even though everything I looked at suggest that the .so file does have debug symbols in it, I tried to add all debug flags, ...
Does anyone know how to get this to work?

https://github.com/rstudio/reticulate/issues/487


Completed assignment 2

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
Complete assignment #2
What did you learn from the changes you have made?
Linear regression with sklearn
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
No
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
No
How were these changes tested?
Checked against raw data
A reference to a related issue in your repository (if applicable)
Not applicable
Checklist

[x] I can confirm that my changes are working as intended

A2: Complete
Good work.
Note that for Q2 part (ii) More specifically, what concept in linear regression does the plotted line represent? " Line of best fit" in which it minimizes the squared distance between the fitted line and the observations


minimal version

I am not really a developer and thought about adding your library somewhere. But all these files for simple qr code generation and auth seems a bit over done.
As you write on your readme it does not really make much sense to remote generate your qr codes. So why even offer this? When I was browsing your files I see also things like time.google.com. Anyone with a bit of security has blocked the major clouds.

does your library even work in a air-gapped environment?
is there some minimal download, that just does basic things off line?

If you don't like it you don't have to use it. I don't mind criticism or constructive feedback but your approach isn't very pleasant to put it mildly. And that's coming from a Dutch guy which are known for being blunt.

Hello,
Version 3.x (currently the master branch) adresses these issues you mention. In v3, one needs to explicitely define a QRCodeProvider.
You can use Endroid or Bacon, or anything else, as long as the interface works (I'm using Mpdf QR code generator in my project). These work perfectly in air-gapped systems.
We're in the process of releasing v3.

But all these files for simple qr code generation and auth seems a bit over done.

A lot of my recent contributions removed some code, and streamlined the library. For instance, this PR https://github.com/RobThree/TwoFactorAuth/pull/122.
As a final note, please realize that your message is quite negative and out of place. This library is provided to you free of charge, and while we welcome constructive criticism, your message is too blunt. Look at how you could have expressed the same thing but with respect: https://github.com/RobThree/TwoFactorAuth/issues/104.


[Usage] A path to the LoRA adapters isn't being handled properly

Describe the issue
Following the docs on LoRA models (https://github.com/haotian-liu/LLaVA/blob/main/docs/LoRA.md) we've run the following command:
python -m llava.serve.model_worker --host <IP_ADDRESS> --controller http://localhost:10000 --port 40000 --worker http://localhost:40000 --model-path /root/raw_data_for_llava/raw_data_for_llava/LLaVAR/further_finetuning/lora --model-base meta-llama/Llama-2-7b-hf

and ran into the following error:
2023-11-10 13:00:47 | ERROR | stderr |
2023-11-10 13:00:47 | INFO | stdout | Loading LoRA weights from /root/raw_data_for_llava/raw_data_for_llava/LLaVAR/further_finetuning/lora
2023-11-10 13:00:47 | ERROR | stderr | Traceback (most recent call last):
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/site-packages/peft/utils/config.py", line 177, in _get_peft_type
2023-11-10 13:00:47 | ERROR | stderr |     config_file = hf_hub_download(
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/site-packages/huggingface_hub-0.19.0-py3.8.egg/huggingface_hub/utils/_validators.py", line 110, in _inner_fn
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/site-packages/huggingface_hub-0.19.0-py3.8.egg/huggingface_hub/utils/_validators.py", line 158, in validate_repo_id
2023-11-10 13:00:47 | ERROR | stderr | huggingface_hub.utils._validators.HFValidationError: Repo id must be in the form 'repo_name' or 'namespace/repo_name': '/root/raw_data_for_llava/raw_data_for_llava/LLaVAR/further_finetuning/lora'. Use `repo_type` argument if needed.
2023-11-10 13:00:47 | ERROR | stderr |
2023-11-10 13:00:47 | ERROR | stderr | During handling of the above exception, another exception occurred:
2023-11-10 13:00:47 | ERROR | stderr |
2023-11-10 13:00:47 | ERROR | stderr | Traceback (most recent call last):
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/runpy.py", line 196, in _run_module_as_main
2023-11-10 13:00:47 | ERROR | stderr |     return _run_code(code, main_globals, None,
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/runpy.py", line 86, in _run_code
2023-11-10 13:00:47 | ERROR | stderr |     exec(code, run_globals)
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/raw_data_for_llava/raw_data_for_llava/LLaVAR/LLaVA/llava/serve/model_worker.py", line 275, in <module>
2023-11-10 13:00:47 | ERROR | stderr |     worker = ModelWorker(args.controller_address,
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/raw_data_for_llava/raw_data_for_llava/LLaVAR/LLaVA/llava/serve/model_worker.py", line 65, in __init__
2023-11-10 13:00:47 | ERROR | stderr |     self.tokenizer, self.model, self.image_processor, self.context_len = load_pretrained_model(
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/raw_data_for_llava/raw_data_for_llava/LLaVAR/LLaVA/llava/model/builder.py", line 115, in load_pretrained_model
2023-11-10 13:00:47 | ERROR | stderr |     model = PeftModel.from_pretrained(model, model_path)
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/site-packages/peft/peft_model.py", line 244, in from_pretrained
2023-11-10 13:00:47 | ERROR | stderr |     PeftConfig._get_peft_type(
2023-11-10 13:00:47 | ERROR | stderr |   File "/home/developer/anaconda3/envs/llava/lib/python3.10/site-packages/peft/utils/config.py", line 183, in _get_peft_type
2023-11-10 13:00:47 | ERROR | stderr |     raise ValueError(f"Can't find '{CONFIG_NAME}' at '{model_id}'")
2023-11-10 13:00:47 | ERROR | stderr | ValueError: Can't find 'adapter_config.json' at '/root/raw_data_for_llava/raw_data_for_llava/LLaVAR/further_finetuning/lora'

So apparently something is going wrong with parsing the path to the adapter; after reviewing https://github.com/huggingface/huggingface_hub/blob/18d0ae2ebfcfc696c50a67e7dad8fa63f5f23068/src/huggingface_hub/utils/_validators.py#L123 and further
my guess is we're interpreting a repo_type as a repo_id or something similar.
Why might that be?

did you solve the problem?


Broken box when using a certain combination of size and padding

Describe the problem
There seems to be a problem with a certain combinations of width, content length and padding.
Steps to reproduce the problem
Using the very first code from the README, only with padding: 1 instead of 3:
require 'tty-box'

box = TTY::Box.frame(
  width: 30,
  height: 10,
  align: :center,
  padding: 1
) do
  "Drawing a box in terminal emulator"
end

puts box

Actual behavior
The script produces this output:
$ ruby test.rb
┌────────────────────────────┐
│                            │
│ Drawing a box in terminal  │
│ emulator │
│          emulator          │
│                            │
│                            │
│                            │
│                            │
└────────────────────────────┘

Provided also as a screenshot:

Describe your environment

OS version: Ubuntu 16
Ruby version:  2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
TTY::Box version: 0.2.0

Thank you for reporting this! Do you have some time to investigate the cause?

Released v0.2.1 with your fix! Thanks again! ❤

With pleasure.


Abstract schema and form/schema in order to manually specify rules

We are generating validation rules by converting our in-house schema to the dry-validation rule AST and then compile it into a an array of rules. Basically we want to have our rules in a Dry::Validation::Schema[::Form] object so we can reuse the validation process and error compilation that dry-validation provides.
Currently there is no way to do it properly, our options is to duplicate whatever Dry::Validation::Schema does or resort to monkey patching.

I'm gonna tweak the schema so that it can accept rules from the outside and it will append them to the built-in ones. If the built-in ones are not present then only the injected ones will be used, which I believe is what you need.

Yeah, sounds like exactly what I want.
Basically I followed the wiki page https://github.com/dryrb/dry-validation/wiki/Rule-AST and you end up with an array of rules, but then you are on your own when trying to use them for anything useful =P

Just wondering if this would help with a use-case we're interested in. We've always had to write custom validation objects for a survey service that we use. Basically, a person can configure their own survey with some questions requiring a response (not all).
In order to properly validate a survey submission, we need both the originating survey AND the submission itself. @solnic are you suggesting that "accept rules from the outside" might fit this particular use-case where the presence validation of a key on a form submission is dependent on something external?

@bradrobertson sounds like it, yes. You basically want to dynamically generate rules based on information from some external source.


removing FIPS from the download page

per https://github.com/tetrateio/protocol/issues/227 removing FIPS links from the download page.

@PetrMc I checked the download page. FIPS-related data is removed. You can push live.

thanks @psbrar99 and @MB-Designs


Possibility of using logos' core

Hi! First of all, thanks for writing this super cool crate and making Rust's ecosystem more robust.
I'm the original developer of pest and was wondering what would be the best way to take advantage of some of the technology use in logos. It seems like a lot of the simpler production rules could take advantage of a similar tree approach. I'm also working on a higher level framework to improve pest's grammar compilation, but I have yet to decide on an intermediate representation that would deliver the best results.
This is why I'm curious whether you would be interested perhaps separating the derive into a more generic core crate that would be reusable in other projects. The goal here is to offer a good experience for people new to parsing and to bring as much of the technology we write here in the Rust community reusable and well-integrated, so any other ideas or feedback would be most appreciated.

Hey! Thanks a lot, when I first saw Pest I was really blown away by how easy it is to use. I got to talk to a couple people using it, some of whom are beginning Rustaceans, and their experience is great. Pest is definitely one of those crates that helps driving Rust adoption!
As for extracting the pattern-tree-resolution engine into a core crate - absolutely! I'd be happy to collaborate and see what the requirements of Pest are. I reckon there might be some friction because I'm using Regex syntax as input, but then the tree actually doesn't look anything like Regex, so it should be possible to make it general enough not to have to change the syntax of .pest files.

The are just a few difference between PEG (which pest uses) and a Regex engine:

everything matches eagerly; parse trees produced are always deterministic
lookaheads
named production rules

Maybe there is a simple enough way to make the parsing strategy generic, so as to be able to use eager matching. Adding lookaheads should be straight-forward. As for the tagged rules, that can be left for pest to handle; everything below it can highly-optimized eager Regex.

Actually, lookaheads will be probably the only tricky part.
Everything matching eagerly is how Logos works atm (.*? will fail to compile), so that's fine. Named production should be very easy to do by just swapping my Token markers with a generic.
I'll give extracting the tree resolution stuff into a crate a go this week, then we can try to square the circle of it into pest and see what changes are needed. I should also do some reading of the pest source code to get a better understanding of what it's doing (I have some assumptions, but assumptions tend to suck).

pest's backend is not very stable right now. I'm planning to write an RFC in pest detailing how the next version (3.0) will use intermediate representation in order to do high-level optimizations, then have this IR generate Rust code that does the parsing. Once this IR is defined, it will be very easy to know exactly is needed.

After a bit more research, I think the best approach is to have pest deal with lookaheads itself, maybe optimize them statically if it can. Thus, the kind of IR Logos could help it would be:

UTF-8 strings
case-insensitive UTF-8 strings
UTF-8 character ranges
sequences like ab
ordered choices a|b, where b is matched only if a fails
eager bounded repetitions a{0,n}
eager unbounded repetitions a*

pest 3.0 should be able to statically optimize most expressions and inline most rules such that the work that Logos will do will be clear and precise. It should be able to start parsing from a specific index in a string and return an Option<usize> with the match position.

Hello @dragostis, I am trying to make this project live-on, and wanted to check if this issue / feature request was this requested?
Thanks :-)

At this point, I'm out of the loop and have no time to invest in this, so I'm closing this issue.


[pulsar-admin]make skip all messages async

Motivation
Make skip all messages async
Verifying this change
Using exist unit tests
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation

Does this pull request introduce a new feature? (no)

retest this please

run cpp tests
run integration tests

run integration tests

run integration tests


[marker flicker]  Fix flicker of map pins on state change

Fixes https://github.com/airbnb/react-native-maps/issues/683 caused by https://github.com/airbnb/react-native-maps/pull/548.
In #548, MapMarker.js was changed from
const AIRMapMarker = requireNativeComponent('AIRMapMarker', MapMarker); to
const AIRMapMarker = this.getAirComponent();.
AirMapMarker is what is returned in the render method.
The bug was that this.getAirComponent() was returning a new native component each time causing a re-render.  This only happened for the default component, not the other ones since they were cached.  The fix is to cache the default component.
Note: this seems to affect map markers with arbitrary views inside them the most.
Before:

After:

@spikebrehm @lelandrichardson @gilbox

@gilbox

domo arigatou!

When do you plan to release this?

@gilbox How I can help you with release?

Looks like does not happen in recent versions (0.19.0) Let us know if still persists.

Still having this flickering bug.

still bug exist in version 0.27.1


api/social-image is over the 1Mb limit in free version of Vercel

Description
I merged the latest changes and fixes from the main branch today and hit following issue:
Error: The Edge Function "api/social-image" size is 1.11 MB and your plan size limit is 1 MB. Learn More: https://vercel.link/edge-function-size

I can disable them from my site but I thought that you would want to know.
Notion Test Page ID
7875426197cf461698809def95960ebf

This seems to be happening because of bundling both interSemiBoldFont and interRegularFont fonts into the edge function.
I removed interRegularFont from my api/social-image.ts and it started to work again.
Maybe we could be able to live with just a bold font in the social images?

Yeah, I think that's a good call to make sure it works for all users.

I removed the regular font for now: https://github.com/transitive-bullshit/nextjs-notion-starter-kit/commit/172bd84f835fe6144ee9ecee5927ee820a24003a

Thanks, I'll close the issue too 👍


NChain ports??

2021-12-04T08:02:10.266 full_node chia.server.upnp        : INFO     UPnP failed. This is not required to run chia, it allows incoming connections from other peers.
2021-12-04T08:02:10.267 full_node chia.server.upnp        : INFO     Success
2021-12-04T08:02:14.909 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604987640> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:24.078 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604987440> [Connect call failed ('<IP_ADDRESS>', 38445)]
your wikki says 1 port 1 one page then another port in another. you even mention 6888 which is used by flax ???
so basically
documentation bad.
What config shal i have nchain has 0 connections
Autoscroll
2021-12-04T07:22:40.477 daemon chia.daemon.server         : INFO     sending term signal to chia_wallet
2021-12-04T07:22:40.478 daemon chia.daemon.server         : INFO     sending term signal to chia_full_node
2021-12-04T07:22:40.478 wallet wallet                     : INFO     got signal 15
2021-12-04T07:22:40.478 daemon chia.daemon.server         : INFO     sending term signal to chia_harvester
2021-12-04T07:22:40.479 wallet wallet                     : INFO     Cancelling reconnect task
2021-12-04T07:22:40.478 full_node full_node               : INFO     got signal 15
2021-12-04T07:22:40.479 daemon chia.daemon.server         : INFO     sending term signal to chia_farmer
2021-12-04T07:22:40.479 wallet wallet                     : INFO     Closing connections
2021-12-04T07:22:40.479 harvester harvester               : INFO     got signal 15
2021-12-04T07:22:40.479 full_node full_node               : INFO     Cancelling reconnect task
2021-12-04T07:22:40.479 farmer farmer                     : INFO     got signal 15
2021-12-04T07:22:40.480 wallet chia.wallet.wallet_node    : INFO     self._close
2021-12-04T07:22:40.480 harvester harvester               : INFO     Cancelling reconnect task
2021-12-04T07:22:40.480 full_node full_node               : INFO     Closing connections
2021-12-04T07:22:40.480 farmer farmer                     : INFO     Cancelling reconnect task
2021-12-04T07:22:40.480 wallet wallet                     : INFO     Calling service stop callback
2021-12-04T07:22:40.480 harvester harvester               : INFO     Closing connections
2021-12-04T07:22:40.480 farmer farmer                     : INFO     Closing connections
2021-12-04T07:22:40.481 wallet wallet                     : INFO     Closing RPC server
2021-12-04T07:22:40.481 full_node full_node               : INFO     Calling service stop callback
2021-12-04T07:22:40.481 farmer farmer                     : INFO     Calling service stop callback
2021-12-04T07:22:40.481 full_node full_node               : INFO     Closing RPC server
2021-12-04T07:22:40.481 farmer farmer                     : INFO     Closing RPC server
2021-12-04T07:22:41.009 farmer farmer                     : INFO     Waiting for socket to be closed (if opened)
2021-12-04T07:22:41.010 farmer farmer                     : INFO     Waiting for ChiaServer to be closed
2021-12-04T07:22:41.011 full_node full_node               : INFO     Waiting for socket to be closed (if opened)
2021-12-04T07:22:41.011 full_node full_node               : INFO     Waiting for ChiaServer to be closed
2021-12-04T07:22:41.014 full_node full_node_server        : INFO     Connection closed: <IP_ADDRESS>, node id: a7f673a4bc23a92e2a5d26f86a7844113f95e217eaa1ba878df1e5e1ba71e17d
2021-12-04T07:22:41.014 full_node chia.full_node.full_node: INFO     peer disconnected {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:22:41.014 farmer farmer_server              : INFO     Connection closed: <IP_ADDRESS>, node id: 871aa6cce293cbc85586ca20978d0c3b7484194fce5e0939ee813a98174fae6b
2021-12-04T07:22:41.015 farmer chia.farmer.farmer         : INFO     peer disconnected {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:22:41.015 full_node full_node_server        : INFO     Connection closed: <IP_ADDRESS>, node id: 7b8f15bf215d00aec0d99117c7c422341117e47b3b9e9cecd82f3eb2cddfaa62
2021-12-04T07:22:41.015 wallet wallet                     : INFO     Waiting for socket to be closed (if opened)
2021-12-04T07:22:41.015 wallet wallet                     : INFO     Waiting for ChiaServer to be closed
2021-12-04T07:22:41.015 farmer farmer_server              : INFO     Connection closed: <IP_ADDRESS>, node id: 6d6ca7774d236425d9a092adb9d1c73fc195775adffdb8c97a4398e5c2e0b4e3
2021-12-04T07:22:41.015 full_node chia.full_node.full_node: INFO     peer disconnected {'host': '<IP_ADDRESS>', 'port': 38449}
2021-12-04T07:22:41.016 farmer chia.farmer.farmer         : INFO     peer disconnected {'host': '<IP_ADDRESS>', 'port': 38448}
2021-12-04T07:22:41.016 wallet wallet_server              : INFO     Connection closed: <IP_ADDRESS>, node id: 871aa6cce293cbc85586ca20978d0c3b7484194fce5e0939ee813a98174fae6b
2021-12-04T07:22:41.016 wallet wallet                     : INFO     Waiting for RPC server
2021-12-04T07:22:41.016 farmer farmer                     : INFO     Waiting for RPC server
2021-12-04T07:22:41.016 full_node full_node               : INFO     Waiting for RPC server
2021-12-04T07:22:41.391 harvester harvester               : INFO     Calling service stop callback
2021-12-04T07:22:41.392 harvester harvester               : INFO     Closing RPC server
2021-12-04T07:22:41.392 harvester harvester               : INFO     Waiting for socket to be closed (if opened)
2021-12-04T07:22:41.392 harvester harvester               : INFO     Waiting for ChiaServer to be closed
2021-12-04T07:22:41.394 harvester harvester_server        : INFO     Connection closed: <IP_ADDRESS>, node id: 625bf164638a756c37e5001f33261e8491039ac8763433c35f3e663c4ff0fdf4
2021-12-04T07:22:41.394 harvester chia.harvester.harvester: INFO     peer disconnected {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:22:41.395 harvester harvester               : INFO     Waiting for RPC server
2021-12-04T07:22:43.013 farmer farmer                     : INFO     Closed RPC server
2021-12-04T07:22:43.013 farmer farmer                     : INFO     Waiting for service _await_closed callback
2021-12-04T07:22:43.013 farmer farmer                     : INFO     Service farmer at port 38447 fully closed
2021-12-04T07:22:43.017 full_node full_node               : INFO     Closed RPC server
2021-12-04T07:22:43.017 full_node full_node               : INFO     Waiting for service _await_closed callback
2021-12-04T07:22:43.018 full_node chia.server.upnp        : INFO     UPnP, shutting down thread
2021-12-04T07:22:43.018 full_node full_node               : INFO     Service full_node at port 58445 fully closed
2021-12-04T07:22:43.019 wallet wallet                     : INFO     Closed RPC server
2021-12-04T07:22:43.019 wallet wallet                     : INFO     Waiting for service _await_closed callback
2021-12-04T07:22:43.019 wallet chia.wallet.wallet_node    : INFO     self._await_closed
2021-12-04T07:22:43.169 wallet wallet                     : INFO     Service wallet at port 38449 fully closed
2021-12-04T07:22:43.396 harvester harvester               : INFO     Closed RPC server
2021-12-04T07:22:43.397 harvester harvester               : INFO     Waiting for service _await_closed callback
2021-12-04T07:22:43.397 harvester harvester               : INFO     Service harvester at port 38448 fully closed
2021-12-04T07:22:43.483 daemon chia.daemon.server         : INFO     process chia_full_node returned 0
2021-12-04T07:22:43.484 daemon chia.daemon.server         : INFO     process chia_harvester returned 0
2021-12-04T07:22:56.161 daemon chia.daemon.server         : INFO     Starting Daemon Server
2021-12-04T07:22:56.162 daemon chia.daemon.server         : INFO     Waiting Daemon WebSocketServer closure
2021-12-04T07:22:58.912 harvester harvester               : INFO     Started harvester service on network_id: ext9
2021-12-04T07:22:58.913 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:22:58.917 harvester harvester_server        : INFO     Cannot connect to host <IP_ADDRESS>:38447 ssl:<ssl.SSLContext object at 0x7f5e7382fa40> [Connect call failed ('<IP_ADDRESS>', 38447)]
2021-12-04T07:22:58.925 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_harvester'}
2021-12-04T07:22:58.926 daemon chia.daemon.server         : INFO     registered for service chia_harvester
2021-12-04T07:22:58.926 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:22:59.235 full_node chia.full_node.full_node: INFO     Initializing blockchain from disk
2021-12-04T07:22:59.274 full_node chia.consensus.blockchain: INFO     Started 4 processes for block validation
2021-12-04T07:22:59.276 full_node chia.full_node.full_node: INFO     Initialized with empty blockchain time taken: 0s
2021-12-04T07:22:59.280 full_node full_node_server        : INFO     Started listening on port: 58445
2021-12-04T07:22:59.280 full_node full_node               : INFO     Started full_node service on network_id: ext9
2021-12-04T07:22:59.289 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_full_node'}
2021-12-04T07:22:59.290 daemon chia.daemon.server         : INFO     registered for service chia_full_node
2021-12-04T07:22:59.290 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:23:00.289 farmer farmer_server              : INFO     Started listening on port: 38447
2021-12-04T07:23:00.290 farmer farmer                     : INFO     Started farmer service on network_id: ext9
2021-12-04T07:23:00.290 farmer farmer                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:23:00.302 farmer farmer_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:23:00.603 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_farmer'}
2021-12-04T07:23:00.604 daemon chia.daemon.server         : INFO     registered for service chia_farmer
2021-12-04T07:23:00.604 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:23:00.638 wallet chia.wallet.wallet_blockchain: INFO     Started 26 processes for block validation
2021-12-04T07:23:00.640 wallet wallet                     : INFO     Started wallet service on network_id: ext9
2021-12-04T07:23:00.641 wallet chia.wallet.wallet_node    : INFO     Loop start in sync job
2021-12-04T07:23:00.641 wallet wallet                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:23:00.655 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_wallet'}
2021-12-04T07:23:00.655 daemon chia.daemon.server         : INFO     registered for service chia_wallet
2021-12-04T07:23:00.655 wallet wallet_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:23:00.655 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:23:00.707 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbd27440> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:23:01.921 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:23:01.931 harvester harvester_server        : INFO     Connected with farmer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:23:01.989 harvester chia.harvester.harvester: INFO     refresh_batch: event started, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:23:01.989 harvester chia.harvester.harvester: INFO     refresh_batch: event batch_processed, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:23:01.989 harvester chia.harvester.harvester: INFO     refresh_batch: event done, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:23:03.281 full_node chia.server.upnp        : INFO     UPnP failed. This is not required to run chia, it allows incoming connections from other peers.
2021-12-04T07:23:03.281 full_node chia.server.upnp        : INFO     Success
2021-12-04T07:23:07.854 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd4540> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:23:17.013 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd4640> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:23:30.170 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd46c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:23:51.343 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd4a40> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:24:00.643 wallet chia.wallet.wallet_node    : INFO     Will not attempt to connect to other nodes, already connected to {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:24:28.520 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd46c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:25:37.662 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd4640> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:27:50.816 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fd0bbcd4540> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:30:24.221 daemon chia.daemon.server         : INFO     Starting Daemon Server
2021-12-04T07:30:24.221 daemon chia.daemon.server         : INFO     Waiting Daemon WebSocketServer closure
2021-12-04T07:30:26.986 harvester harvester               : INFO     Started harvester service on network_id: ext9
2021-12-04T07:30:26.986 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:30:26.989 harvester harvester_server        : INFO     Cannot connect to host <IP_ADDRESS>:38447 ssl:<ssl.SSLContext object at 0x7f2418465a40> [Connect call failed ('<IP_ADDRESS>', 38447)]
2021-12-04T07:30:26.996 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_harvester'}
2021-12-04T07:30:26.997 daemon chia.daemon.server         : INFO     registered for service chia_harvester
2021-12-04T07:30:26.997 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:30:27.185 full_node chia.full_node.full_node: INFO     Initializing blockchain from disk
2021-12-04T07:30:27.211 full_node chia.consensus.blockchain: INFO     Started 4 processes for block validation
2021-12-04T07:30:27.213 full_node chia.full_node.full_node: INFO     Initialized with empty blockchain time taken: 0s
2021-12-04T07:30:27.216 full_node full_node_server        : INFO     Started listening on port: 6888
2021-12-04T07:30:27.216 full_node full_node               : INFO     Started full_node service on network_id: ext9
2021-12-04T07:30:27.229 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_full_node'}
2021-12-04T07:30:27.229 daemon chia.daemon.server         : INFO     registered for service chia_full_node
2021-12-04T07:30:27.229 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:30:28.253 farmer farmer_server              : INFO     Started listening on port: 38447
2021-12-04T07:30:28.254 farmer farmer                     : INFO     Started farmer service on network_id: ext9
2021-12-04T07:30:28.254 farmer farmer                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 6888}
2021-12-04T07:30:28.267 farmer farmer_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 6888}
2021-12-04T07:30:28.450 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_farmer'}
2021-12-04T07:30:28.451 daemon chia.daemon.server         : INFO     registered for service chia_farmer
2021-12-04T07:30:28.451 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:30:28.480 wallet chia.wallet.wallet_blockchain: INFO     Started 26 processes for block validation
2021-12-04T07:30:28.482 wallet wallet                     : INFO     Started wallet service on network_id: ext9
2021-12-04T07:30:28.483 wallet chia.wallet.wallet_node    : INFO     Loop start in sync job
2021-12-04T07:30:28.483 wallet wallet                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 6888}
2021-12-04T07:30:28.501 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_wallet'}
2021-12-04T07:30:28.501 wallet wallet_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 6888}
2021-12-04T07:30:28.501 daemon chia.daemon.server         : INFO     registered for service chia_wallet
2021-12-04T07:30:28.502 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:30:28.675 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b340> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:30:29.993 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:30:30.003 harvester harvester_server        : INFO     Connected with farmer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:30:30.058 harvester chia.harvester.harvester: INFO     refresh_batch: event started, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:30:30.059 harvester chia.harvester.harvester: INFO     refresh_batch: event batch_processed, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:30:30.059 harvester chia.harvester.harvester: INFO     refresh_batch: event done, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:30:31.217 full_node chia.server.upnp        : INFO     UPnP failed. This is not required to run chia, it allows incoming connections from other peers.
2021-12-04T07:30:31.218 full_node chia.server.upnp        : INFO     Success
2021-12-04T07:30:35.842 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b2c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:30:44.994 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b7c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:30:58.146 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b740> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:31:19.309 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b5c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:31:28.485 wallet chia.wallet.wallet_node    : INFO     Will not attempt to connect to other nodes, already connected to {'host': '<IP_ADDRESS>', 'port': 6888}
2021-12-04T07:31:56.480 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b940> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:33:05.648 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b740> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:35:18.812 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f87a6b8b7c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:39:31.133 daemon chia.daemon.server         : INFO     Starting Daemon Server
2021-12-04T07:39:31.133 daemon chia.daemon.server         : INFO     Waiting Daemon WebSocketServer closure
2021-12-04T07:39:33.949 harvester harvester               : INFO     Started harvester service on network_id: ext9
2021-12-04T07:39:33.950 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:39:33.954 harvester harvester_server        : INFO     Cannot connect to host <IP_ADDRESS>:38447 ssl:<ssl.SSLContext object at 0x7fbf89605a40> [Connect call failed ('<IP_ADDRESS>', 38447)]
2021-12-04T07:39:33.962 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_harvester'}
2021-12-04T07:39:33.962 daemon chia.daemon.server         : INFO     registered for service chia_harvester
2021-12-04T07:39:33.962 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:39:34.074 full_node chia.full_node.full_node: INFO     Initializing blockchain from disk
2021-12-04T07:39:34.102 full_node chia.consensus.blockchain: INFO     Started 4 processes for block validation
2021-12-04T07:39:34.104 full_node chia.full_node.full_node: INFO     Initialized with empty blockchain time taken: 0s
2021-12-04T07:39:34.108 full_node full_node_server        : INFO     Started listening on port: 58445
2021-12-04T07:39:34.108 full_node full_node               : INFO     Started full_node service on network_id: ext9
2021-12-04T07:39:34.121 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_full_node'}
2021-12-04T07:39:34.121 daemon chia.daemon.server         : INFO     registered for service chia_full_node
2021-12-04T07:39:34.121 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:39:35.165 farmer farmer_server              : INFO     Started listening on port: 38447
2021-12-04T07:39:35.166 farmer farmer                     : INFO     Started farmer service on network_id: ext9
2021-12-04T07:39:35.166 farmer farmer                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:39:35.179 farmer farmer_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:39:35.410 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_farmer'}
2021-12-04T07:39:35.410 daemon chia.daemon.server         : INFO     registered for service chia_farmer
2021-12-04T07:39:35.411 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:39:35.432 wallet chia.wallet.wallet_blockchain: INFO     Started 26 processes for block validation
2021-12-04T07:39:35.434 wallet wallet                     : INFO     Started wallet service on network_id: ext9
2021-12-04T07:39:35.434 wallet chia.wallet.wallet_node    : INFO     Loop start in sync job
2021-12-04T07:39:35.434 wallet wallet                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:39:35.447 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_wallet'}
2021-12-04T07:39:35.447 daemon chia.daemon.server         : INFO     registered for service chia_wallet
2021-12-04T07:39:35.447 wallet wallet_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:39:35.447 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T07:39:35.531 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb384c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:39:36.957 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:39:36.969 harvester harvester_server        : INFO     Connected with farmer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T07:39:37.028 harvester chia.harvester.harvester: INFO     refresh_batch: event started, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:39:37.028 harvester chia.harvester.harvester: INFO     refresh_batch: event batch_processed, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:39:37.028 harvester chia.harvester.harvester: INFO     refresh_batch: event done, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T07:39:38.109 full_node chia.server.upnp        : INFO     UPnP failed. This is not required to run chia, it allows incoming connections from other peers.
2021-12-04T07:39:38.110 full_node chia.server.upnp        : INFO     Success
2021-12-04T07:39:42.674 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb388c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:39:51.830 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb380c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:40:04.988 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb38940> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:40:26.156 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb07840> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:40:35.437 wallet chia.wallet.wallet_node    : INFO     Will not attempt to connect to other nodes, already connected to {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T07:41:03.331 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb382c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:42:12.499 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb38840> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T07:44:25.663 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7fcc6bb388c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:03.266 daemon chia.daemon.server         : INFO     Starting Daemon Server
2021-12-04T08:02:03.266 daemon chia.daemon.server         : INFO     Waiting Daemon WebSocketServer closure
2021-12-04T08:02:06.182 harvester harvester               : INFO     Started harvester service on network_id: ext9
2021-12-04T08:02:06.183 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T08:02:06.186 harvester harvester_server        : INFO     Cannot connect to host <IP_ADDRESS>:38447 ssl:<ssl.SSLContext object at 0x7f0ac94e9a40> [Connect call failed ('<IP_ADDRESS>', 38447)]
2021-12-04T08:02:06.192 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_harvester'}
2021-12-04T08:02:06.192 daemon chia.daemon.server         : INFO     registered for service chia_harvester
2021-12-04T08:02:06.192 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T08:02:06.230 full_node chia.full_node.full_node: INFO     Initializing blockchain from disk
2021-12-04T08:02:06.256 full_node chia.consensus.blockchain: INFO     Started 4 processes for block validation
2021-12-04T08:02:06.257 full_node chia.full_node.full_node: INFO     Initialized with empty blockchain time taken: 0s
2021-12-04T08:02:06.261 full_node full_node_server        : INFO     Started listening on port: 58445
2021-12-04T08:02:06.261 full_node full_node               : INFO     Started full_node service on network_id: ext9
2021-12-04T08:02:06.272 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_full_node'}
2021-12-04T08:02:06.273 daemon chia.daemon.server         : INFO     registered for service chia_full_node
2021-12-04T08:02:06.273 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T08:02:07.363 farmer farmer_server              : INFO     Started listening on port: 38447
2021-12-04T08:02:07.363 farmer farmer                     : INFO     Started farmer service on network_id: ext9
2021-12-04T08:02:07.364 farmer farmer                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T08:02:07.381 farmer farmer_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T08:02:07.654 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_farmer'}
2021-12-04T08:02:07.654 daemon chia.daemon.server         : INFO     registered for service chia_farmer
2021-12-04T08:02:07.654 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T08:02:07.766 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f46049574c0> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:07.805 wallet chia.wallet.wallet_blockchain: INFO     Started 26 processes for block validation
2021-12-04T08:02:07.814 wallet wallet                     : INFO     Started wallet service on network_id: ext9
2021-12-04T08:02:07.818 wallet chia.wallet.wallet_node    : INFO     Loop start in sync job
2021-12-04T08:02:07.818 wallet wallet                     : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T08:02:07.835 wallet wallet_server              : INFO     Connected with full_node {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T08:02:07.837 daemon chia.daemon.server         : INFO     Register service {'service': 'chia_wallet'}
2021-12-04T08:02:07.837 daemon chia.daemon.server         : INFO     registered for service chia_wallet
2021-12-04T08:02:07.837 daemon chia.daemon.server         : INFO     {'success': True}
2021-12-04T08:02:09.190 harvester harvester               : INFO     Reconnecting to peer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T08:02:09.203 harvester harvester_server        : INFO     Connected with farmer {'host': '<IP_ADDRESS>', 'port': 38447}
2021-12-04T08:02:09.280 harvester chia.harvester.harvester: INFO     refresh_batch: event started, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T08:02:09.280 harvester chia.harvester.harvester: INFO     refresh_batch: event batch_processed, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T08:02:09.280 harvester chia.harvester.harvester: INFO     refresh_batch: event done, loaded 0, removed 0, processed 0, remaining 0, duration: 0.00 seconds
2021-12-04T08:02:10.266 full_node chia.server.upnp        : INFO     UPnP failed. This is not required to run chia, it allows incoming connections from other peers.
2021-12-04T08:02:10.267 full_node chia.server.upnp        : INFO     Success
2021-12-04T08:02:14.909 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604987640> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:24.078 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604987440> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:37.251 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604931040> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:02:58.418 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f4604957740> [Connect call failed ('<IP_ADDRESS>', 38445)]
2021-12-04T08:03:07.819 wallet chia.wallet.wallet_node    : INFO     Will not attempt to connect to other nodes, already connected to {'host': '<IP_ADDRESS>', 'port': 58445}
2021-12-04T08:03:35.590 full_node full_node_server        : INFO     Cannot connect to host introducer.ext9.org:38445 ssl:<ssl.SSLContext object at 0x7f46049577c0> [Connect call failed ('<IP_ADDRESS>', 38445)]

Thanks for the detailed log dump.  Reading between the lines, you are experiencing N-Chain connection issues.

Connections page: Add some node connections -> use nodes from https://xchforks.com/n-chain/ or other.
Connections page: Check port forwarding.

Happy to help you with your connection issues.


Paramedic Autoinjector + Medical QOL

About the PR
gives the paramedics a cartridge autoinjector round start, three extra cartridges and a tourniquet.
puts tourniquets in the medical vendors and allows them to be placed in medical belts.
adds medical cartridge autoinjector to the medfab.
slightly decreases cartridge autoinjector recharge time to a round number for my own sanity.
Why / Balance
https://discord.com/channels/1202734573247795300/1313408235478323230
also its a cool idea.
Changelog
:cl:

add: Added a medical cartridge autoinjector.
tweak: Cartridge autoinjectors now have a 30 second cooldown.
tweak: EMT belts now contain a tourniquet and medical cartridge autoinjector.
tweak: Medical vendors now contain six tourniquets and two medical cartridge autoinjectors.
fix: Tourniquets can now go inside medical belts.

Minor spelling mistake in the CL
You typed not instead of now

Can you also add ephedrine and ichor cartridges to emagged medfab, there is no reason for them not to be there.

Can you also add ephedrine and ichor cartridges to emagged medfab, there is no reason for them not to be there.

tried but it gave me a yaml fail so i didnt bother.

realised that ichor is a bit goated, its been replaced by puncturase :trollface:

okay this is epic


ipv6 ends with network interface

[x] I am running the latest app version
[x] I checked to make sure that issue has not already been filled

Describe the bug
The value of the ipv6 ended with an additional %wlan0 after the ipv6. I expect that wlan0 is the name of the network interface that is used.
To Reproduce
Steps to reproduce the behavior:

Open app
Read ipv6

Expected behavior
The ipv6 should only be the ipv6.
Smartphone:

Device: Shift5me
OS: Android 8.1.0

This issue has already been fixed in the upcoming update, it's gonna be out soon

Thank you for reporting


Cancel all orders button

The API provides a mechansim to cancel all orders in one transaction. You just submit orderCancellation without a marketId or orderID: https://docs.fairground.vega.xyz/docs/api-howtos/cancel-order/
So, we should add a 'Cancel all' button to the bottom of the orders list:

@mattrussell36 to refine


Full width Select

Thank you for your plugin!
Is there an option to have it 100% wide by default or we need to play around in the CSS?

+1 have same question here
thx for your plugin!

Good suggestion -- I'll add a width option as well since the height option is getting lonely ;).

For those wondering here's the basic CSS override for it to be 100% wide:
`.prettydropdown {
display: block;
width: 100%!important;

ul {
width: 100%!important;

li {
  width: 100%!important;
}

}
}`

@amichel86 great, thanks. I currently don't have the bandwidth to add a width option that takes both px and % units, so maybe someone can tackle this and submit a PR. In the meantime, the quickest solution is to override the CSS as shown above.

Note that there is now a width option beginning with v4.13.0.


Add dropdown on users/roles page.

I changed the users and roles page to be the same as every other page (files/digital downloads etc). This is my first pull request so please tell me if something is wrong.

Thanks!  This looks good.


core: increase Xmx in order to build "smoothly" with several gradle daemons

What this PR changes/adds
Increase -Xmx in gradle daemons
Why it does that
Users may have OOM while building.

never run into this issue, feels like it's something that needs to be configured on the local gradle configuration, more than checked into the repository (the same, in my opinion, would be for the other org.gradle settings about parallelism into the gradle.properties file)

@jbonofre try to comment out the other org.gradle settings about parallelism and see if you still get that issue. I disabled parallelism locally because it slowed my machine, probably it can cause also OOM on yours.

Good point. I remember I did it for Apache Beam as well. Let me try. Thanks !

+1 for not including the org.gradle.workers settings as part of the checked in gradle properties.

@jbonofre this problem probably has been resolved in #961, if so, can you close this? thanks

@ndr-brt agree, it looks good to me. Thanks !