Various Changes

Updates the target to iOS 13.4 and corrects all of the associated warnings except those related to the rarely used bluetooth features. I will do these later. Updating the target will allow us to use newer APIs that will make the iCloud syncing more reliable and it will make the download size of the app smaller. Removing the code deprecated in iOS 11-13 while still supporting iOS 10 would be an alternative but would require more code
Fixes hundreds of dark mode related problems, mostly by changing text in various places from black to default, where the default color automatically switches between black and white
Fixed the missing Done buttons on the iPhone

Pull request rejected for the following reasons:

Too many changes in one request.
iOS 13.4 in beta - we should make update against released iOS version only.
The fix to the missing 'Done' button did not require iOS update.

Hi folks,
A few discussion points.
From my point of view, the most critical work to do on this app is to improve the reliability of the cloud syncing both to ensure that data is accessible from all devices for report generation and more importantly to ensure all data is backed up. Currently, there are several thousand lines of code devoted to doing this in CloudKit controller. Thousands of lines can be removed by using the new NSPersistentCloudKitContainer feature introduced in iOS 13. In addition, there is a huge amount of code dedicated to finding out when the network is reachable and scheduling transmissions. This also is no longer necessary. There is a lot of potential to increase reliability here. I am willing to attempt this now, but that may change in a few weeks if my colleagues come down with COVID and I have to take on additional medical work.
Second, the app is currently a disaster in dark mode as the text shows up black on black and cannot be read. All it will take to get the app rejected again is a reviewer switching to dark mode for 5 seconds. The way I've fixed dark mode here is by using the new UIColor.labelColor which automatically switches between black and white. If we are going to support older OSes this will not work. Other options are:

Include a flag in the app plist that disables dark mode
Include conditional code that checks which OS and makes the text either black or labelColor depending if we are on iOS 13 or older. Unfortunately, since the text color in many places is set from the Storyboard, this would involve writing a lot more code than we have now

As a nitpick, iOS 13.4 is not in beta. It is in Golden Master and is currently the OS that Apple's reviewers are testing on, so it is important that the app runs well on it. It will be released to the public at or before 1300 tomorrow Eastern time.
The changes I suggested, while they may seem extensive, are very basic and consist of only three things:

Changing the color of text to handle dark mode. This requires iOS 13.
Checking the traitCollection in viewWillAppear to deal with the done button issue. As an aside, while it is. This can be done in iOS 10, however we would need to test it against 10, 11, & 12 to ensure it doesn't introduce bugs. At the very least, it may result in the trait collection being checked twice on some of those systems
Changing the row actions to UIContextualActions to remove the use of deprecated APIs and API warnings. This requires iOS 11.

Anyway, enough from me. What do you suggest?

@kirvanp it might be easier for @huguesf to review the changes if you broke it down into a separate PR for each of those listed changes (assuming they don't interact with each other).
Let me know if you want any help with that

You could certainly break out the UIContextualAction changes (I believe there is 4) and the traitCollection fix (around 8). There's also a few changes specific to PDF generation, but it doesn't look like that code is in use now that we have the Excel.
That would leave the vast majority of the edits in the dark mode category. On the bright side, these are low risk edits- worst case scenario text isn't the right color.

Guys,
Thank you for your input.
Moving the discussion to #59 .
See you there!


The tool stops working with bigger datasets

For some reason osfm.py does not process the images and freezes on that step.

Closed in #9


How do I install this?

The current installation instructions don't work. Running python setup.py install produces a value error:
ValueError: bad marshal data (unknown type code)

@audun- We haven't released Python packages yet. However, if you're installing from source, you can execute pip install . on the repo's root.

I'm a little confused here.  Are the commands
pip install spyder-vim
and
conda install spyder-vim -c spyder-ide
as shown in README.md not supposed to work?
I understand that if it doesn't work there may be no resources to fix the problem, but it seems
that deleting those lines from the README wouldn't take long, and would prevent a lot of wasted time.

@VeloSteve Thanks for your recommendation, right now we're pending of doing the first release. There's already an open PR (#34) to solve this issue, feel free to add your contribution.

There seems to have been no movement on this for over two years and the pip and conda install procedures do not work.
I tried manually installing it in an Anaconda environment on Windows per PR #34 with the following:
git clone https://github.com/spyder-ide/spyder-vim
cd spyder-vim
python setup.py install .

However, it broke things so badly that neither uninstalling and reinstalling Spyder nor the entire Anaconda distribution fixed it.
Basically, the install (at least in my case on Windows) seems to be a complete disaster.

We'll create a proper release for this package once @bgallois let us know that he's happy with the current state of things.

@ccordoba12  @bgallois  Are ya'll still working on this? I'm on the newest version of spyder and getting the following on Windows.
!pip install spyder-vim
---RUNNING NEW PROGRAM---
C:\Users\Marc Ochsner\AppData\Local\Programs\Spyder\Python\python.exe
0.12.0
ERROR: Could not find a version that satisfies the requirement spyder-vim
ERROR: No matching distribution found for spyder-vim

I have the same question - was stoked to install this, then disappointed when I got the same error shown by mochsner...

I have the same problem too

Closing as duplicate of #21
To follow up the progress towards the initial release for this plugin/package you can check https://github.com/spyder-ide/spyder-vim/issues/78


[Python] [FlightRPC] Suspicious amounts of memory held on client after failed DoExchange

Describe the bug, including details regarding any error messages, version, and platform.
When a PyArrow FlightClient calls do_exchange and the call fails on server and the client holds onto the raised FlightError, then it seems that not all memory that was used during do_exchange processing is returned.
PyArrow: 12.0.1
Python: 3.11.4
Platform: Linux / 6.3.11-200.fc38.x86_64

Let me provide some more context to paint a better picture. In our system, we have a Flight RPC service that can generate data using Flight Descriptor containing a command. The command specifies a flight path of source data, flight path where to sink the data + some payload for the processing.
The command processing may take a while - it is a long running command and the service represents this internally as a task that it queues up. The clients 'submit' these tasks via GetFlightInfo and keep polling on the result.
When the task runs, it needs to do some expensive computation: this is what we have to offload to a worker process via DoExchange. The worker process has its own Flight RPC server (bound to unix socket).
The task will start DoExchange with the worker process, then open stream of the source data and shovel it to the worker. At this point, the worker does its work -> which may fail. On failure, the main process captures the error and makes it a result of the task - so that when client comes polling for the task result, they learn that it failed with that particular error.
What we found during load testing error scenarios is, that the RSS of the server (e.g. the main process) only ever goes up.
Note that there is no funny stuff on success. The worker produces data, the main process does DoPut for the sink flight path and streams the data where necessary. Memory usage in this case is as expected.

After a lot of head scratching I think I have finally pin-pointed this suspicious memory usage to the fact that the main process holds onto the exception that failed the DoExchange. If the code does not keep the exception, the memory usage is ok. As soon as it holds onto it, the memory accumulates. The rate of accumulation seems to correlate with the size of the source data.

Here is a gist with the reproducer that I cut to the bare-bones: https://gist.github.com/lupko/ce59226b99790af2474bfe459cb4e36d
The reproducer does malloc_trim to drop any unused memory that malloc has not returned to the system. You will be able to observe that the trim with accumulated errors does not impact process RSS at all. Only when the accumulated errors are dropped, the memory usage goes down (significantly).
Component(s)
FlightRPC, Python

Hmm, interesting, thanks for investigating. I wonder if we're accidentally capturing something in a closure or similar...

Oh, but it's the RSS of the server that goes up?

errors in to_reader() call are propagated as OSError (suspicious?)

This is tangential, but IMO this was a mistake of the original implementation of trying to reuse the Arrow errors instead of specifying a fully independent set of Flight-specific errors. So Arrow converts things like IOError (status code) to OSError (exception), and Flight reuses that (and additionally tries to map the gRPC status codes onto the Arrow status codes), which gets confusing fast.

hello @lidavidm, thank you for checking out the issue. to clarify:

the server - repro_server.py - the one that handles the DoExchange is fine.
it is the client - repro_client.py - the one that initiates the DoExchange - where the RSS keeps accumulating.

sorry if my description was a bit confusing... in our case the client who initiates the do_exchange is actually also a server :)
but, long story short, you can see the increased RSS in the process that runs the repro_client.py from the reproducer. the repro_server.py is fine (sans the usual malloc/malloc trim stuff).

Ok, thanks for clarifying!
I haven't gotten to investigate yet, sorry. I'll report back once I can.

i did some further digging and turns out this is related to Python exception handling. The stack frames included in exception's traceback keep reference to all local variables. And so naturally things do not get cleared up if code holds onto the exception.
There is even a function traceback.clear_frames(tb) to address this. Tested it with the reproducer and all is good.
So if anything, this could perhaps be a little doc update? A note into pyarrow.flight.FlightError perhaps? WDYT?
Otherwise I'm going to close this.

Ok, not surprising.
If possible I'd like to keep this open so we can figure out what is being held open, and if we can clear it explicitly instead of just documenting it.

of course, although I suspect there is very little that could be done on PyArrow side - it all looks like a Python thing to me:
For example if I fiddle-up the existing reproducer (repro_client.py) so that the _do_exchange method raises any error from Python-land and I hold onto that error, then I observe the same symptoms: because the exception references the traceback which references the stack frames and one of them references all local variables of _do_exchange - even those that are backed by instances of Arrow classes.
FYI here is some extra info about the exception funny stuff: https://cosmicpercolator.com/2016/01/13/exception-leaks-in-python-2-and-3/


I suggest adding the Ukrainian localization to the mod (I have already translated everything myself, you just need to add the file to the mod)

Localization file
uk_ua.json

Did you happen to miss a few entries? It's no problem, just checking

Thanks for your contribution, translation is added in 1.6.0


Govee H7143 Humidifier

It's not fair to call this an issue since I know this is designed for the Govee lights, but I thought I would ask in case this was in the works or possible in the near future.
I have said humidifier and MQTT is recognizing it as follows:
[2024-01-06T21:03:52 INFO  govee::commands::serve] Humidifier (Removed MAC) sku=H7143
[2024-01-06T21:03:52 INFO  govee::commands::serve]   Platform API: devices.types.humidifier. supports_rgb=true supports_brightness=true
[2024-01-06T21:03:52 INFO  govee::commands::serve]                 color_temp=None segment_rgb=None
[2024-01-06T21:03:52 INFO  govee::commands::serve]   Undoc: room=None supports_iot=true ble_only=false

While the Govee app doesn't allow me to enable local LAN, I did configure the add-on with my credentials and API key. I can turn the unit on/off, change it's color, as well as enable/disable the light and warm mist settings.
The settings I cannot change are:

Mode: Manual/Auto
-- Target % for Auto
-- Auto Stop disable
Mist Level: 40 - 80%
Display: Enable/Disable

Is there any way I could go about adding those options through the MQTT humidifier element or through this add-on? I'm in the beginning of my MQTT journey so I'm not sure what diagnostics to run to be of further help.
If there is any information I can provide that will be helpful please let me know.

I just picked up an H7160 today. The APIs won't let me control its lights (boo!) but I do see the mode stuff there.
I'll likely be working on enabling that here in govee2mqtt tomorrow.

Funny that we're reversed, that would be amazing! I was in the process of returning this in favor of a tuya compatible one - but that one doesn't have the lights, the warm mist or several other things.
Will stand by and if there is any information I can provide I'm happy to do so.

it's not really reversed: neither of us can control the modes, but only you can control the lights.
I do see the metadata for the mode control in the responses I'm getting from govee though, so it should be possible to make that work.
One thing that I am disappointed about is that the API doesn't return any of the useful sensor data for my device (https://developer.govee.com/discuss/6599ec2ebbfb7000701e87f8)

I've published an updated version that supports the H7160. It's possible that some or all functionality for your device may now be present.  I'd recommend deleting the humidifier device from under the MQTT integration section and then restarting the new version of the addon, and then please let me know how it shows up in home assistant and which functions work/don't work.

For context (or not lol)...
Everything looks good with my H7141 humidifier.
I am going to post similar in the smart fan ticket and could also help with the humidifier and purifier if you are willing to take a look.
I think the changes you made for the humidifier got all these other devices pretty close. I can see the different "parameter" options as entities for each device, so it may just be a matter of HA needing to understand these are the modes for the respective devices.

The manual option gives a slider from 1-8 which corresponds with the mist level of the device. Would be cool to incorporate this into the device screenshot I posted before, but not a huge deal either way.

The way the H7160 works is:

Auto Mode - you can set the target humidity percentage
Manual Mode - you can set the level of the mister
Custom - unknown/complex: combines scheduling with mister control

The way that HASS humidifier entity works is:

You can control/monitor the target humidity
You can optionally report the current humidity (my device doesn't support this, so there is no logic to report it)

So the Humidifier UI in HA can only realistically set the value for the Auto Mode.  The manual mister level has to be a separate entity because it just doesn't map to a humidity percentage.
I opted to hide both the additional number sliders for Auto and Custom for the H7160 because:

Auto - the slider range is an offset scale that can't easily be automatically mapped into the correct percentage range in the context of the standalone number slider. We don't really "know" what it is in that context and can't easily interpret it without leaving a nasty code smell in that part of the code.
Custom - I have no idea how to decode or extract those modes, but really, if you were doing something smart like that in HASS you would automate the Manual level directly in HASS and won't need control over the custom parameter.

If the H7143 works similarly to my H7160, then I can apply the same logic to how things get mapped into HASS.

I don't have a govee hygrometer paired to mine but looking at the options, auto mode seems to work the same way.
Definitely correct about manual mode and I understand your reasoning with the sliders. And completely agree custom mode seems far too complicated lol.
So I think the functionality between the two models is a match.
Regarding what you asked me to do for the fan, can I just enter that into the HA terminal? If so I'll play with it in a bit.

So I think the functionality between the two models is a match. Oh you put H7143 in your reply but mine is H7141. Just pointing it out in case.

OK, I'll make an update that treats those 3 devices similarly then.

Regarding what you asked me to do for the fan, can I just enter that into the HA terminal? If so I'll play with it in a bit.

I'm not sure; I don't run HAOS so I don't know what the access to docker is like in that environment.
Those http-control commands can be run from any device with docker, so if you have a separate box that can run docker, you can do so without fretting about the HASS system.

I'm a little limited on time this week but I removed the entity, updated and restarted. This is what it looks like in HASS:

The follow still/currently work:

Power On/Off
Warm Mist On/Off
Light On/Off
HASS Card shows current target humidity, power state, mode
HASS Card now accurately reflects the set color

Not working:

Setting mode manual/auto
Change the Target Humidity
Set color
Change Brightness

I don't see any errors in the logs - which I have set to verbose. Regarding the setting the color I wonder if it's related to the ability to set scenes as well as colors. This is listed with the command:
[2024-01-09T13:06:54 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("ptReal"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin: None,
sku: None, device: None }, op: Some(OpData { command: [SetHumidifierNightlight(HumidifierNightlightParams { on: false, r: 0,
g: 0, b: 0, brightness: 0 })] }) }

I see this warn - and am including the subsequent traces:
[2024-01-09T13:15:20 WARN  govee::hass_mqtt::enumerator] Do something about Mode nightlightScene for Humidifier
(MAC) DeviceCapability { kind: Mode, instance: "nightlightScene", parameters: Some(Enum { options:
[EnumOption { name: "Forest", value: Number(1), extras: {} }, EnumOption { name: "Ocean", value: Number(2), extras: {} },
EnumOption { name: "Wetland", value: Number(3), extras: {} }, EnumOption { name: "Leisurely", value: Number(4), extras: {} },
EnumOption { name: "ASleep", value: Number(5), extras: {} }] }), alarm_type: None, event_state: None }
[2024-01-09T13:15:20 TRACE govee::hass_mqtt::light] LightConfig::notify_state: state is DeviceState { on: true, online: None,
kelvin: 0, color: DeviceColor { r: 139, g: 0, b: 255 }, brightness: 13, scene: None, source: "AWS IoT API", updated: 2024-01-
09T21:15:19.112582452Z }
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/light/MAC/state -> {"brightness":13,"color":
{"b":255,"g":0,"r":139},"color_mode":"rgb","effect":null,"state":"ON"}
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/humidifier/MAC/state -> ON
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/humidifier/MAC/notify-target -> 72
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/humidifier/MAC/notify-mode -> Manual
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/switch/MAC/powerSwitch/state -> ON
[2024-01-09T13:15:20 TRACE govee::hass_mqtt::switch] CapabilitySwitch::notify_state: didn't find state for Humidifier (MAC) warmMistToggle
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/number/MAC/state/manual -> 0
[2024-01-09T13:15:20 TRACE govee::service::hass] gv2mqtt/number/MAC/state/auto -> 0
[2024-01-09T13:15:20 TRACE govee::hass_mqtt::switch] CapabilitySwitch::notify_state: didn't find state for Humidifier (MAC) nightlightToggle

MAC scrubbed from data out of habit

To flesh out the bits that aren't being controlled, I'd appreciate it you could capture the packets that are being sent via the IoT MQTT channel.
Set the debug level to govee::service::iot=debug,info so that you're not overwhelmed.
Then go into the Govee app and change a parameter and you should see some notifications show up in the log.
Please capture those together with what you set in the app, so that we have a mapping.
It can be helpful to vary the value in a mode (eg: change the target humidity or level to a couple of different values) so that it is easier to spot which parts of the packet are changing and how the value is mapped in.
Thanks!

I think this is the bulk of them:
Color Change
[2024-01-09T23:22:00 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin: None,
sku: None, device: None }, op: Some(OpData { command: [NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 100,
g: 0, b: 0, brightness: 1 }), NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 0, g: 0, b: 255, brightness: 13 })],
mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Brightness Change
[2024-01-09T23:23:12 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [NotifyHumidifierNightlight(HumidifierNightlightParams { on:
true, r: 39, g: 0, b: 0, brightness: 1 }), NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 139, g: 0, b: 255,
brightness: 13 })], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Scene Change
[2024-01-09T23:25:17 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [NotifyHumidifierNightlight(HumidifierNightlightParams { on:
true, r: 39, g: 0, b: 0, brightness: 1 }), NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 0, g: 1, b: 0, brightness:
19 })], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

[2024-01-09T23:25:17 WARN  govee::hass_mqtt::enumerator] Do something about Mode nightlightScene for Humidifier
(MAC) DeviceCapability { kind: Mode, instance: "nightlightScene", parameters: Some(Enum { options:
[EnumOption { name: "Forest", value: Number(1), extras: {} }, EnumOption { name: "Ocean", value: Number(2), extras: {} },
EnumOption { name: "Wetland", value: Number(3), extras: {} }, EnumOption { name: "Leisurely", value: Number(4), extras: {} },
EnumOption { name: "ASleep", value: Number(5), extras: {} }] }), alarm_type: None, event_state: None }

I'm not sure how practical the scene change will be, regardless of the scene I picked it seems as if the app has preset values for each scene and sends a standard rgb commands
Switch To Auto Mode
[2024-01-09T23:27:56 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("status"), msg: None, state: StateUpdate { on_off: Some(1), brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([AA, 12, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, B8]), NotifyHumidifierTimer { on: false }, NotifyHumidifierMode { mode: 3, param: 0 },
NotifyHumidifierManualMode { param: 9 }, Generic([AA, 05, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, AD]),
NotifyHumidifierAutoMode { param: TargetHumidity(200) }, Generic([AA, 16, 01, FF, FF, FF, FF, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, BD]), NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 39, g: 0, b: 0, brightness: 1 }),
NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 0, g: 1, b: 0, brightness: 19 }), Generic([AA, 08, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, A2]), Generic([AA, 10, 81, 03, 45, 3B, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 46]), Generic([AA, 1F, 00, 0D, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, B9]), Generic([AA, 1E, 01, 02, 01, 00, 74,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, C2]), Generic([AA, 1E, 01, 02, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
B5]), Generic([AA, 17, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, BD])], mode_value: [], sleep_value: [],
wakeup_value: [], timer_value: [] }) }

Change Target Humidity
[2024-01-09T23:31:52 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("status"), msg: None, state: StateUpdate { on_off: Some(1), brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([AA, 12, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, B8]), NotifyHumidifierTimer { on: false }, NotifyHumidifierMode { mode: 3, param: 0 },
NotifyHumidifierManualMode { param: 9 }, Generic([AA, 05, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, AD]),
NotifyHumidifierAutoMode { param: TargetHumidity(168) }, Generic([AA, 16, 01, FF, FF, FF, FF, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, BD]), NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 39, g: 0, b: 0, brightness: 1 }),
NotifyHumidifierNightlight(HumidifierNightlightParams { on: true, r: 0, g: 1, b: 0, brightness: 19 }), Generic([AA, 08, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, A2]), Generic([AA, 10, 81, 03, 46, 21, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 5F]), Generic([AA, 1F, 00, 0D, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, B9]), Generic([AA, 1E, 01, 02, 01, 00, 74,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, C2]), Generic([AA, 1E, 01, 02, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
B5]), Generic([AA, 17, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, BC])], mode_value: [], sleep_value: [],
wakeup_value: [], timer_value: [] }) }

On my device the range is 40 - 80%. I changed it to both max and min and it looks like it's range is 168 - 208 as an int
Switch to Manual Mode
[2024-01-09T23:38:06 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([3A, 05, 01, 09, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 37])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Min Mist Lvl
[2024-01-09T23:39:25 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([3A, 05, 01, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 3F])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Max Mist Lvl
[2024-01-09T23:40:02 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([3A, 05, 01, 09, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 37])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Mist level for me is 1 - 9
Disable Lock
[2024-01-09T23:41:42 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([AA, 1F, 00, 0D, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, B9])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Enable Lock
[2024-01-09T23:42:22 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([AA, 1F, 01, 0D, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, B8])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Disable Auto Stop
[2024-01-09T23:44:34 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([3A, 05, 03, 28, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 14])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Enable Auto Stop
[2024-01-09T23:43:22 DEBUG govee::service::iot] Packet { sku: Some("H7143"), device: Some("MAC"), cmd:
Some("multiSync"), msg: None, state: StateUpdate { on_off: None, brightness: None, color: None, color_temperature_kelvin:
None, sku: None, device: None }, op: Some(OpData { command: [Generic([3A, 05, 03, A8, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
00, 00, 00, 00, 94])], mode_value: [], sleep_value: [], wakeup_value: [], timer_value: [] }) }

Hope this helps!

For color and brightness, did the values in the logged packet match the color and brightness that you set?

I can test a few more to be sure but yes, just my simple blue, green and red tests all logged the appropriate 255 in their respective channels.

I made some changes in the latest version that will try to use the platform API for this device; it seemed like the same iot packets didn't help you in previous versions, so the current state is that it won't try to use iot at all for this device.
Since the metadata for your device doesn't provide a way to control the nightlight, that won't be controllable.
However, the work modes should hopefully work now.  Please let me know how you get on with this!

@davide169 if you're asking about a different product, please file a separate issue, thanks!


Question：How to generate table with SQLAlchemy?

I noticed the database object file in ‘/home/yileye/project/monitor/application/models‘
And after I run the command ’boost new model‘ ，I can see the new model file in this path
But how I use this file to generate the table in mysql?

Copy from README:
Create database with name your_project_name and encoding utf8.
Update SQLALCHEMY_DATABASE_URI in config/development.py as needed.
Then init tables:
python manage.py db upgrade

ok.thank you


compose: add ostree commit image types

These are a bit different than our other image types, but this is the
closest fit I could find without majorly reworking the API/UI.
The image types are not yet part of osbuild-composer, but I think we can
merge this eagerly as they will be ignored in case the backend doesn't
support them.
Two new image types are introduced "Fedora IoT" and "RHEL for Edge",
these are going to be very similar, but obviously available for
Fedora/RHEL respectively.
Signed-off-by: Tom Gundersen<EMAIL_ADDRESS>

@teg, I have an question about this change. The rhel one will be available only if it's on rhel, right? Otherwise that'll cause issue if user build rhel iot image on fedora.

@teg, I have an question about this change. The rhel one will be available only if it's on rhel, right?

Correct, osbuild-composer will only expose the Fedora variant on a Fedora machine and the RHEL variant on a RHEL machine. So as long as cockpit-composer only shows the image types osbuild-composer tells it about, we should all be good :)

@teg, make sense to me. Thanks!
I tried three times, the only failed case is due to image building timeout(30 minutes). I think most of time spend on package downloading. I'll retry the failed case tomorrow morning (my timezone), and all traffic in/out will become silence.

Thanks!


LINQ error occurs depending on calling order of Skip and Take

Describe the bug
LINQ Provider generates SQL that cannot be executed depending on calling order of Skip and Take.
To Reproduce
public class Entry
{
    public string Id { get; set; }
    public string Title { get; set; }
    public string Body { get; set; }
    public IList<string> Tags { get; set; }
    public DateTimeOffset CreatedAt { get; set; }
}

class Program
{
    static async Task Main(string[] args)
    {
        var connectionString = "";

        var cosmosClient = new CosmosClient(connectionString, new CosmosClientOptions
        {
            ConnectionMode = ConnectionMode.Direct,
            SerializerOptions = new CosmosSerializationOptions
            {
                PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase
            }
        });

        var container = cosmosClient.GetContainer("Blog", "Entry");

        var query = container.GetItemLinqQueryable<Entry>()
                             .Take(10)
                             .Skip(10)
                             .ToQueryDefinition();

        Console.WriteLine(query.QueryText);

        await container.GetItemQueryIterator<Entry>(query).ReadNextAsync();
    }
}

Expected behavior
SELECT VALUE root FROM root OFFSET 10 LIMIT 10

Actual behavior
SELECT VALUE r0 FROM (SELECT TOP 10 VALUE root FROM root ) AS r0 OFFSET 10 LIMIT<PHONE_NUMBER>

Environment summary
SDK Version: 3.3.1
OS Version: Windows
Additional context
Exception message
Microsoft.Azure.Cosmos.CosmosException: 'Response status code does not indicate success: 400 Substatus: 0 Reason: (Message: {"errors":[{"severity":"Error","location":{"start":29,"end":35},"code":"SC2203","message":"'TOP' is not supported in subqueries."}]}).'

Workaround - Swap the order of Take and Skip
        var query = container.GetItemLinqQueryable<Entry>()
                             .Skip(10)
                             .Take(10)
                             .ToQueryDefinition();

@khdang can you please take a look?

This is the right behavior. The order of Skip and Take matters.
The two statements are not equivalent.
The first one would take 10 items and then skip 10 items on the 10 items from the take clause, which would return an empty list. Whereas the second statement would skip 10 items and take the next 10 items.
 var query = container.GetItemLinqQueryable<Entry>()
                             .Take(10)
                             .Skip(10)
                             .ToQueryDefinition();

   var query = container.GetItemLinqQueryable<Entry>()
                             .Skip(10)
                             .Take(10)
                             .ToQueryDefinition();


Add sop frontend

There is a standard CLI interface: https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stateless-cli-08
Latest version of the draft is at https://dkg.gitlab.io/openpgp-stateless-cli/
Implementing it will allow to run OpenPGP interoperability test suite

Implementing the Rust SOP interface (https://docs.rs/sop) now gives you the CLI frontend for free.

@dkg yes, it is on my todo list, but unfortunately so are many other things 😭

i know the feeling, @dignifiedquire -- you have my sympathies.  Have things shifted around any that you might be able to take a crack at it?  #125 points to some stumbling blocks that @teythoon ran into when trying to write a sop-rs backend.  And even a partial implementation is a useful starting point.
Or, maybe some other rpgp dev might be interested in working on creating this mapping?  Maybe it'd be a job for someone coming up to speed on the project?

I've spent a bit of time with https://crates.io/crates/sop, and the "OpenPGP interoperability test suite", both of which are excellent!
The result of my hacking so far is the experimental and still somewhat incomplete https://crates.io/crates/rsop

No need to keep this issue open anymore, phew! thanks a lot @hko-s  @dignifiedquire and @link2xt for pushing through all the issues/PRs in the last weeks! :partying_face:
And to @teythoon for the base work and the integration into https://tests.sequoia-pgp.org/ :purple_heart:
and of course to @dkg for persevering and long-running background work!


Implementation of universe checking through the graph

In Universes.v, consistency, eq_universe and leq_universe are defined in terms of valuation.
This PR shows that those properties are decidable and implement the decision procedures by converting the set of constraints into a graph.

Ok, this should be ready!
There are still some admits but everything compiles (even the test-suite and translations) and computes (is_leq_universe, ...).

I take the responsibility for merging!


How should one try a nightly build?

steps
try using a nightly build
problem

Nightlies are published on bintray: https://dl.bintray.com/sbt/ivy-snapshots/org.scala-sbt/sbt/
Launcher isn't going to hit it by default.
There's no documentation instructing how to point at it.

expectation

Do we need to create proxy/forwarder for better URL like repo.scala-sbt.org/xxx?
Launcher should probably include that by default.
Document how to point at it.

For 1. https://dl.bintray.com/sbt/ivy-snapshots is addressable at https://repo.scala-sbt.org/scalasbt/ivy-snapshots
For 2. I've fixed this in sbt-extras: https://github.com/paulp/sbt-extras/pull/120
I don't understand 3.
Btw, there are gaps in the nightly builds.

https://www.scala-sbt.org/1.x/docs/Nightly-Builds.html


[5.2] Improved exception output for migrations and use DB Transactions

You would think migrations would always work, but sometimes developers do not use them properly. It becomes very difficult to track down where things went wrong when your migration folder is huge.
This PR does two things:

If a migration fails half way through, a DB transaction rolls it back
Shows a relevant error with a trace showing the migration that is messed up

It might be worth noting that not all databases support rolling back DDL statements and that the databases that do may only support rolling back some DDL statements. Of the databases Laravel supports MySQL is the only one (afaik) to not support it at all. The rest have fairly good support for transactional DDL.

@thecrypticace I haven't thought about that, good point. I'll look at some different databases tomorrow and get a better idea. We can probably ignore calls from begin, commit and rollback if the database isn't supported maybe. And now that I think about it, I should really utilize this code in the artisan migrate:rollback too.

Alright I think it's ready. On Illuminate\Database\Connection I implement a method to determine whether transactions are fully supported. That way in cases like MySQL it will not rollback only certain parts of the migration and confuse the developer. It defaults to false, but the child classes for postgres, sql server and sqlite override it and return true.

We can't use facades in the core like this. They are for userland only.


Chiral flag should be removed when all Up/Down stereobonds are removed

Steps to reproduce:

Launch Editor.
Create any chiral structure.
Change all Up/Down stereobonds with Simple bonds.

Expected result:
Chiral flag disappears when all Up/Down stereobonds are removed.
Actual result:
Chiral flag stays at the canvas when all Up/Down stereobonds are removed.
Epic link: #56

No change required, the issue was fixed as part of other tasks

There is a problem with stereoflags after performing undo action.

Create any chiral structure.
Change one Up/Down stereobond with Simple bond.
Click 'Undo' button.

Expected result: Chiral flag remains as it was in the original structure.
Actual result: Chiral flag is changed into 'Mixed'.

'Undo' (and 'Redo') option with deleted stereobond works in two steps. 1st click - Stereolabel is returned to the canvas. 2nd click - stereobond is returned to the canvas.
Steps to reproduce:

Add a structure on the canvas (e.g. one of α-D-Sugars from Custom templates).
Click on 'Calculate CIP' button.
Delete one of stereobonds.
Click 'Undo' button.

CIP Calculation works on demand: after structure changing user should click the 'Calculate CIP' button once again to re-calculate stereoconfiguration (see this issue https://github.com/epam/ketcher/issues/195)
Now Actual Result:
'Undo' (and 'Redo') option with deleted stereobond (see steps to reproduce in the comment above) works in one step.
Changing structure action is merged with cip marks clearing in the history stack.

The Chiral flag is removed after delete-undo actions.
Steps to reproduce:

Choose a structure with stereobonds from the Custom templates (e.g. a-D-Allopyranose).
Delete it with the 'Erase' tool or with the 'Delete' key.
Click the 'Undo' button.

Expected result: The structure with a chiral flag is present on the canvas.
Actual result: The structure without a chiral flag is present on the canvas.

Release/2.3 The issue is closed as partly fixed. A scenario with the non-disappearing stereocenters in the case of replacement of the stereobonds with the double cis/trans bonds or the dative bonds is described in #554 and will be fixed within this task.


Use u16string in C++ (to avoid wasting 32-bit while java doesn't support them

I tried this mostly for trying to avoid surrogate-pair problems. But it seems that it doesn't work either. So I'm giving up with this. Also C++11 std functions doesn't work with u16string either, so conversions are required which is problematic.


Consecutive files take long time to load

Hi,
I'm experiencing the following error:
Whenever I enable mod_h2 for a virtual host, the initial page load seems fine but the consecutive asset files take over one minute to load.

During loading the page stays completely blank. After one minute or so the page finally appears.
The issue doesn't appear when opening a blank html document.
The website is TLS encrypted

Please see the following screenshot for details:

(please note I disabled h2 on the domain visible in the screenshot temporarily)
Any ideas what might be the cause?
Thanks!

By the way, I'm using the default mpm_prefork, should I switch this to mpm_worker maybe?

By default, http/2 uses only a single worker in prefork. This is because prefork is intended for things that do not like multi-threading.
Please try, if worker/event mitigates this problem. If that is so, and your apps can live with it, I recommend sticking to it. You could give prefork more than one worker, but that sort of defeats the purpose of prefork.

Any results from trying my suggestions? Otherwise, I'd close this issue.

Yes, I switched to mpm_worker and to php-fpm.
Works like a charm now, thanks!

I suggest that this restriction, albeit sensible, be documented. I spent a day trying to work this out.
It seems that it was at one point, but that it was removed and did not make it to the official documentation.

Good point. I'll reopen and write something in the Apache mod_http2 documentation.

Documentation of this issue added in the official howto documenation for setting up HTTP/2 in Apache.


Custom URI validation

Hi, thanks for this great library since it helps us to validate our spec against our API!
We have an API that passes google cloud store links around as part of the request / responses.
In our (YAML, openapi) spec, we document those e.g. as
      documentUri:
        type: string
        format: uri
        description: remote reference to get the file
        example: 'gs://bucket/obj.pdf'

However, the built-in validation seems to rely on django's URL validators:
https://github.com/snok/drf-openapi-tester/blob/6ab4530347c652cae0e72371946138fb81ae453a/openapi_tester/validators.py#L67-L68
which in turn only support more commonly known URL schemes: https://docs.djangoproject.com/en/3.2/ref/validators/
I've also looked into adding a custom validator with the validators kwarg, but it looks like custom validators are run in addition to the base set of validators, not in place of.
What would be the best way to add such custom URI scheme? Would be happy to drop a PR once it's clear what to do.

Hmm. Its a use case we did not anticipate. If you have time to add a PR, I guess you could add a more sophisticated URL validator that wraps and extends the django buildin.
If not - you could locally subclass the validator and override the validation logic locally. Then use your version of the library.

I guess you could add a more sophisticated URL validator that wraps and extends the django buildin.

From what I read here https://github.com/snok/drf-openapi-tester/blob/6ab4530347c652cae0e72371946138fb81ae453a/openapi_tester/schema_tester.py#L236-L256
it seems like you can only add validators instead of overriding them.
I could indeed just change the validator definition
 "uri": create_validator(URLValidator(schemes=['http', 'https', 'ftp', 'ftps', 'gs'])),

but I'm not sure that's what you'd want.
Perhaps a simpler option would be:

define a custom gsuri format in our openapi spec
define a custom validator for that one?

that would work. An alternative within the scope of the library - modify the test_schema_section to call a function or use a @property called "get_validators" - which will return all the list of builtin validators. You can then override it externally.

Couldn't get it to work with a custom validator yet; looks like the validator is only run once.
Will probably check after the weekend.
Thx already for the quick reply! Worst-case, I'll just stick to a custom format in our openapi spec (without any validation)


to_bytes in stdlib

Related issue(s)
Resolves #482
Description
Still a draft due to needing an updated development flow with the aztec_backend. First pushing this as a draft so that I can have the relevant commit in the aztec_backend and vice versa.
This PR adds a to_bytes to the Noir std lib to enable easy transform of a Field into [u8]. Having to_bytes natively in the compiler also uses many less gates in comparison to transforming a bit array to a byte array directly in Noir.
Summary of changes
I added a ToBytes OPCODE as well as a new method split_bytes inside of acir_gen.rs. This acts in a very similar manner to the split method for bit decomposition except that we calculate the bytes values for decomposition through a nested for-loop where we split the bits by groups of 8, rather than one for loop where we calculate the bits like in split.
I also added a new Directive::SplitBytes for splitting bytes as the logic for filling in the witnesses differs from Directive::Split. I might change this to where I add another field to Directive::Split and based off this field determine whether to solve a bit or byte decomposition.
Dependency additions / changes
(If applicable.)
Test additions / changes
I added a to_bytes test that transforms a field into a byte array.
Checklist

[X] I have tested the changes locally.
[X] I have formatted the changes with Prettier and/or cargo fmt with default settings.
[X] I have linked this PR to the issue(s) that it resolves.
[X] I have reviewed the changes on GitHub, line by line.
[X] I have ensured all changes are covered in the description.

Additional context
(If applicable.)

Note: SplitBytes follows from Split, but its not very descriptive. In ACIR, we should have:
Split -> ToBits/BinaryDecomposition
SplitBytes -> ToBytes/ByteDecomposition
(The names on the right can be bikeshedded)

Note: SplitBytes follows from Split, but its not very descriptive. In ACIR, we should have:
Split -> ToBits/BinaryDecomposition SplitBytes -> ToBytes/ByteDecomposition
(The names on the right can be bikeshedded)
--
We can rename the SplitBytes in this PR or atleast not follow the naming convention of split

I went with Directive::ToBytes for now. If we wish to go with the longer name we can, but I felt ToBytes was clear. We can then change split in a separate PR.


Add CEE major

Add CEE major

Addresses #129

Addressed some of the format issues so that it can be viewed/used inside the app to more easily test it and check the content.
Still needs to be tested and reviewed for content/correctness as mentioned in https://github.com/TigerPathApp/tigerpath/pull/134#pullrequestreview-151609789


Update comments.php

Closes #
📑 Description

✅ Checks

[x] My pull request adheres to the code style of this project
[x] My code requires changes to the documentation
[x] I have updated the documentation as required
[x] All the tests have passed

☢ Does this introduce a breaking change?

[ ] Yes
[x] No

ℹ Additional Information

Summary by CodeRabbit

New Features

Improved formatting of help command output for better readability.

Bug Fixes

Enhanced consistency in error message handling for label creation and copying commands.

@gstraccini codacy reanalyze commit

@gstraccini codacy bypass


[bug fix] pushing comp-lzo setting to avoid error

I faced the following problem: client would connect but cannot receive any traffic from VPN server.
Logs from the docker container yielded the following line
IP packet with unknown IP version=15 seen

this is a well-known problem when comp-lzo is disabled on the server but enabled on the client.
Some clients, like my router, has some predefined parameters for OpenVPN configuration and enabled compression can easily be there like in my situation.
So I edited .conf file on the server to push comp-lzo no setting.
This PR contains ovpn_genconfig edit which adds this push to the configuration according to OVPN_COMP_LZO set in parameters.
I had no chances to test the result because on Mac OS X test/run.sh refused to run with the following log:
$ test/run.sh kylemanna/openvpn
readlink: illegal option -- f
usage: readlink [-n] [file ...]
test/run.sh: line 25: declare: -A: invalid option

so be sure to test this PR although it's pretty straightforward.
Thanks for the awesome project @kylemanna !

Can't connect using Tunnelblick with this line in config push "comp-lzo no".
I suppose something must be added to the client config (and ovpn_getclient script accordingly).


EC2 Cluster Defaults

Add sensible defaults to the EC2ClusterProvider.
@shapirov103 please update this issue with the defaults you want.
We will also need to add documentation for this.

Just FYI: current defaults are set in cdk.json as
    "instanceType": "t3.medium",
    "vpc": null,
    "minSize": 1,
    "maxSize": 2,

BTW, this is also a way to use existing VPC instead of creating a new one. There is also support for default VPC if VPC is set to default, however, it must have 3 private subnets.
I still think defaults should be provided in the code if customer does have context set in cdk.json.


Create Authentication pages for Tmplate.

Create the following pages.

[ ] Frontend

[ ] Registration Page
[ ] Login Page
[ ] Landing Page
[ ] Dashboard / Profile Page

[ ] Backend

[ ] Registration Page
[ ] Login Page
[ ] Landing Page
[ ] Dashboard / Profile Page

Registration and Login Pages are a priority, their frontend and backend. Landing page and dashboard could just be empty for now, but should work in accordance to the Authentication so write their backend logic.

@Dhruv-Kapoor-1202
How do i review?


is there any better detection algorithms?

I replace YoloV3 with EfficientDet(0-7) as detection part. But I found the results are worse than before?The error detection is more frequent with low fps(only 5 in D0). Have someone found some better detection algorithms, which has higher mAP and fps?
Also I tested it on MOT16, the metrics especiaclly MOTA are very bad, what's the reason? Can I compare it with the algorithms on Board directly? My application is for realtime, but they are not appliable.
Thank you very much. Look forward to your reply!

You can try Yolo v4

You can try Yolo v4

hello,could you tell me how to change yolov3 to yolov4?Simply changing  the cfg and the weight seems not work. Thanks!

@pauli-lab  Try this one
https://github.com/LeonLok/Deep-SORT-YOLOv4


Add optional author identifiers

Resource authors/contributors may have additional identifiers associated with them that improve their identifiability.  These include ORCID, ResearcherID, Google Scholar ID, Research Gate ID etc.  Functionality needs to be added to HydroShare to support these and support data citation where identification using these is encouraged (see e.g. http://www.copdess.org/copdess-suggested-author-instructions-and-best-practices-for-journals/)
The following is needed

[ ] Add to user profiles optional fields for "Identifier Name" and "Identifier Link" that may hold content such as ("ORCID", "http://orcid.org/0000-0002-1998-3479"), ("ResearcherID","http://www.researcherid.com/rid/G-8972-2011").  A user may have 0 to many of these.  Display these as links on the user's profile page.
[ ] Add to author/contributor entries in resources the ability to automatically include these fields when loading content from a HydroShare user, and to add these fields manually when adding an author or contributor who is not a HydroShare user.

This functionality is outlined in the science metadata design, but I do not think implemented anywhere yet https://docs.google.com/document/d/10xO-aIyaHC8y2baBupJukPhTjg-PJcrCmgT3gJ1qZ_s/edit

@mauriel133 I am assigning this to you for the front-end changes needed for this issue. I can do the back-end changes.

We are going to start with a small curated list and add an option to add Others.

ORCID, ResearchGate, Google Scholar, ResearchedID

@dtarb and @horsburgh I assume these additional identifiers need to be written to the xml metadata file.

I was only intending for them to be part of the user's profile in HydroShare. So, if someone went to my profile page they would see the links i have created to my other profiles and could click on them.
I don't think we should make them part of the metadata that gets added to resources a user creates.

@horsburgh The example science metadata xml document for HydroShare that you once provided to me includes these external identifiers.

@pkdash - thanks for being thorough. @dtarb - you posted this issue, which I think is adding new functionality that we have discussed in the past. You indicated above that you want people to be able to add these optional author identifiers to the metadata of a resource when they create authors and contributors on resources. This means that they would become part of a resource's metadata (they would actually get written to the resource's resourcemetadata.xml file). I told @pkdash (2 comments above) that they should only be part of a user's profile and not get copied to a new resource from the profile. @pkdash needs feedback so he can move forward on this.
I guess my latest thinking (obviously a little different than in the past) is that when creating authors and contributors for a resource we should copy enough information from their profile to identify and contact them (essentially what we have now), but not necessarily copy all of these links to other profiles into the metadata for a resource. Something similar to what a journal does. When a viewer of the resource wants to get more information about an Author or Contributor, they would click on the links that we provide to the HydroShare profile page for the Author/Contributor. These optional, external profile links would appear on a user's HydroShare profile page.
My justification is that we have no control over the links to these external systems or the content that is there. Our resources are archival - and, where possible, I think we should think carefully about copying content into them that may be ephemeral. This is less of an issue I think on a user's profile page.

I think that this identifier metadata should be copied into creator and contributor records that are part of resources.  ResearcherID and ORCID are not ephemeral.  They uniquely identify a specific researcher and are well established in the research citation world.  Journals often ask for them when publishing a paper.  The uniqueness they provide is not guaranteed by name and email (which is ephemeral).  I am not certain how stable ResearchGate and Google Scholar are, and I do not actually know what a Google Scholar ID is or how to find mine.  If there is concern over this, I would not object to scaling back and only doing ResearcherID and ORCID.
Another rationale for having the unique creator/contributor identifiers as part of the resourcemetadata.xml is that resource bags may persist outside HydroShare (e.g. if we do DataOne), and having identifiers not have to refer back to HydroShare makes them better.

@pkdash - looks like we are adding these to the resource metadata. This won't change the resource landing page display at all. This will only change what is included in the resourcemetadata.xml file.

@horsburgh Only if we decide not show the identifiers for creators and contributors on the landing page. But I imagine we also at some point want the user to be able to add identifiers as part of creating creator/contributor on the resource landing page. If we do that then we probably have to list the identifiers there.

I don't think we should do profile editing type things on the resource landing page. I think creation or editing of linked profiles should only be done via the user's profile page.

Correct, you do not edit a users profile from a resource landing page.  But you do edit author or contributor metadata.  That metadata may have been copied from the profile page.  If there is a place for these identifiers in the resource data model as part of author or contributor metadata, then we will need to have a place on the resource landing page to edit and add this when we are adding author or contributor that may not be a HydroShare user.  The behavior is the same as for other author or contributor metadata, such as organization.  It is copied at the time the resource is written, then only changed manually after that, no matter what a user does on their profile, e.g. change organization.

Perhaps the distinction is that profile information is not linked, it is copied into the resource data entries.

@dtarb - this is why I was suggesting to NOT add the optional identifiers to the metadata and ONLY make that information part of the profile in HydroShare. Now, we have to add complexity to the user interface by providing all of this new editing functionality on the resource landing page.
But - OK - have at it @pkdash. @dtarb is right - if we are going to allow the inclusion of this information as part of the resource's metadata then it needs to be editable. But, I think we should NOT have a 2-way linkage between the user's profile and the metadata editing on the resource landing page. In other words, when a user is added as an author/creator to a resource, their information gets automatically pulled from their profile (or typed in where the author/creator is not a HydroShare user). But, when a user adds an external identifier or modifies some other piece of their information on the resource landing page, that that change would NOT get copied back into their profile.
If they want to edit their profile, they should go edit their profile.

There has never been any linkage between hydroshare user object and creator/contributor and I am not proposing for creating any such linkage. The only thing that we do with user object as it relates creator/contributor is that we sometime create creator/contributor objects by copying data from the user object. The 2nd part of this github issue has the requirement that the user should be able to add/edit identifies for creators/contributors. Creators/contributors are currently editable only on the resource landing page.

Sounds good. Thanks @pkdash

@horsburgh and @Maurier while you are looking at this issue please also look at #1787 and #1774 that are related.

@Maurier @pkdash @horsburgh Based on being told that this was implemented in beta.hydroshare.org, my testing revealed the following problem
I tried

I got the message

I tried

I got the message

I tried with https

I got

Going around in circles

@dtarb I this can be closed.


PHP Fatal error:  Class 'Baum\Providers\BaumServiceProvider' not found

$ php artisan baum:install Uzytkownik
return output
PHP Fatal error:  Class 'Baum\Providers\BaumServiceProvider' not found in D:\Wor
k\system-ver.-0.1\vendor\laravel\framework\src\Illuminate\Foundation\ProviderRep
ository.php on line 157
{"error":{"type":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","me
ssage":"Class 'Baum\\Providers\\BaumServiceProvider' not found","file":"D:\\Work
\\system-ver.-0.1\\vendor\\laravel\\framework\\src\\Illuminate\\Foundation\\Prov
iderRepository.php","line":157}}

Anyone know how to fix this issues?

May be the installation didn't work. Try composer require baum/baum.
Than add Baum\Providers\BaumServiceProvider::class, to your providers config/app.php and run php artisan baum:install Uzytkownik again.


watcher.go: replaced the orig code time.Sleep(d)

watcher.go: replaced the orig code time.Sleep(d)to make w.close channel can recv
while in 'a very long Sleeping time' condition

oh man , two years ...


Document watching the file system in the user manual (first stab)

See #11854.

@lptr I merged the first version. Let's do improvements in a follow up PR.


Update grep target file for broader compatibility

By default all messages logged to /var/log/messages are also logged to /var/log/syslog. Recent versions of Ubuntu no longer log by default to /var/log/messages. By changing the target of the grep search to /var/log/syslog the instructions achieve broader compatibility, including vanilla installations of Ubuntu on Azure.

Hi @Kevin-M-Smith, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

Making this change will cause the command to fail on distributions other than Ubuntu (SLES, CentOS, Oracle, etc. do not have a "/var/log/syslog" file).  Perhaps instead we should add a caveat to step 2 to indicate that we should use "/var/log/syslog" on Debian/Ubuntu based systems?

Thanks for the heads up on that @szarkos. I've made changes to reflect your suggestion.

LGTM :)


Better discoverability of constituent repos

There are a lot of things someone might want to fork - johnny-five itself, the documentation, the website itself. We could enhance the various places where there are links to GitHub (the Fork banner, the footer) with some kinda popout menu that gives folks these different alternatives. Or some other non-popout menu solution!

Good idea


Bybit: Add StopOrder

Added multiple StopOrder endpoints (create/get/getAll/cancel/cancelAll) to Bybit API.
Additionally fixed some API models.
Don't wonder that size was changed from int to double. Even though the number of contracts should be an integer, Bybit still returns a number like 100.0, which fails on deserialization to int.

Unfortunately this PR hasn't been approved/merged for several months.


Remove deprecated methods

https://github.com/zeit/next.js/blob/2ba8ad9760ad705650919e179ede5893ec04146b/lib/app.js#L93-L125

Apparently we still use these in zeit.co


Update CRD with structural schema

Propose Change

Copy the CRD yaml manifest from longhorn-manager
Manually add the {{- include "longhorn.labels" . | nindent 4 }} after metadata.labels.

Issue
Longhorn 791

Test basic fresh install and upgrade cases. Both works.


WARNING submitblock returned inconclusive

Is there an existing issue for this?

[X] I have searched the existing issues

Current behaviour
Sometimes submitted blocks are not accepted by bitcoin core, logging "inconclusive". The header seems to be accepted by bitcoin but not connected as a block tip. This message is generated in src/bitcoin-chainstate.cpp and seems to indicate that block.GetHash() does not match the passed in parameter to submitblock_StateCatcher. This is very very odd because at the point it's called, it's called with just submitblock_StateCatcher(block.GetHash()) which is compared directly against block.GetHash().
I've seen this twice, and increased logging verbosity to try to find the error.
Restarting bitcoind caused it to connect this block as a block tip without resubmitting it.
Expected behaviour
.
Steps to reproduce
.
Relevant log output
contrib/cpunet/miner output:
2024-08-22 09:32:11 WARNING submitblock returned inconclusive for height 400 hash<PHONE_NUMBER>7214fdfb13ccd45f4e3170db7e441182efcaffc964e68aef70170c
2024-08-22 09:32:11 INFO Mined a block solution at height 400 with hash:<PHONE_NUMBER>7214fdfb13ccd45f4e3170db7e441182efcaffc964e68aef70170c
2024-08-22 09:32:11 INFO Mining Block: CBlock(nVersion=536870912                                  hashPrevBlock=000000002845d58dd229549bd64ac99e862e36052133de5da1f9e4afa0c0dcc6                    hashMerkleRoot=93979a6fe58fe2baed50f01e8faa8f3281a6d6072d456cfd9410297f80ea5678 nTime=Thu Aug 22  09:32:11 2024 nBits=1d00ffff nNonce=00000000 vtx=[CTransaction(version=2                          vin=[CTxIn(prevout=COutPoint(hash=0000000000000000000000000000000000000000000000000000000000000000 n=4294967295) scriptSig=029101 nSequence=4294967294)] vout=[CTxOut(nValue=50.00000000            scriptPubKey=0014314b346296a361d3e349edf0d0879be8095a68d5)] wit=CTxWitness() nLockTime=0)])

debug.log output:
2024-08-22T13:32:11Z Saw new header                                                               hash=00000000937214fdfb13ccd45f4e3170db7e441182efcaffc964e68aef70170c height=400

How did you obtain Bitcoin Core
Compiled from source
What version of Bitcoin Core are you using?
Bitcoin Core version v27.99.0-e8b157f687eb-dirty from cpunet branch
Operating system and version
Arch Linux 6.10.5-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC
Machine specifications
8 core AMD Ryzen

This "inconclusive" means it's an orphan. It looks like Bitcoin is not sending the UpdateTip ZMQ message. In the log below the miner starts mining at 9:40:05 local time and a new block comes in at 9:44:55 local time (13:44:55Z) and then the grind command finishes (successfully) at 9:45:34 local time. Since the miner script DOES process the ZMQ ConnectTip message, ("sequence C"), this indicates that bitcoind did not send us the ZMQ message, which, had we received it, the miner script would have stopped the existing mining process and started a new one with the new tip.
Bitcoin's log shows
2024-09-05T13:44:55Z Saw new header hash=0000000036968631c19291d914141e99d1cf0312481ee8394d8e65314
c268d51 height=984
2024-09-05T13:44:55Z UpdateTip: new best=0000000036968631c19291d914141e99d1cf0312481ee8394d8e65314
c268d51 height=984 version=0x20000000 log2_work=41.944002 tx=985 date='2024-09-05T13:40:05Z' progr
ess=1.000000 cache=0.3MiB(72txo)
2024-09-05T13:45:34Z Saw new header hash=00000000aa32745da6f8d44c7fccd597060ed51ac0d33c5caf7bcca06

while the miner log shows:
2024-09-05 09:40:05 DEBUG Calling grind command: 'src/bitcoin-util -cpunet -ntasks=8 grind 0000002
0fad74eae053b0eb367c270b6c1ff169b1451feeec3a501ed2129d096000000009405e820ed0e1cd37eff4427b17dc3347
60ebe13e180a0400ad53d68f69fd78bb5b4d966ffff001d00000000'
2024-09-05 09:45:34 DEBUG Calling bitcoin-cli: 'src/bitcoin-cli -cpunet -stdin submitblock'
2024-09-05 09:45:34 DEBUG     with input=b'00000020fad74eae053b0eb367c270b6c1ff169b1451feeec3a501e
d2129d096000000009405e820ed0e1cd37eff4427b17dc334760ebe13e180a0400ad53d68f69fd78bb5b4d966ffff001df
97c77db0102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0302d80
3feffffff0100f2052a0100000016001478749cbc210732b480fa9dfa981bc41c56d0422e00000000'
2024-09-05 09:45:34 DEBUG     result = b'inconclusive\n'

Running now with some more debug output on ZMQ messages to see if it was sent but we didn't decode it properly. Next step is to see if there's a race condition in bitcoind that might cause the UpdateTip ZMQ message to not be sent for some reason.

Saw another one. Bitcoin's log shows:
2024-09-06T15:51:35Z Saw new header hash=0000000003a0ad6b58bf45a5346aec558242c0b20577b5efdeaddd6a655a7026 height=1063
2024-09-06T15:51:35Z Saw new cmpctblock header hash=0000000003a0ad6b58bf45a5346aec558242c0b20577b5efdeaddd6a655a7026 peer=0
2024-09-06T15:51:35Z UpdateTip: new best=0000000003a0ad6b58bf45a5346aec558242c0b20577b5efdeaddd6a655a7026 height=1063 version=0x20000000 log2_work=42.055304 tx=1064 date='2024-09-06T15:48:12Z' progress=1.000000 cache=0.3MiB(25txo)
2024-09-06T15:54:31Z Saw new header hash=00000000c7d7e2c6d524d8b02472dc94144b3113f7ccf8b6d5baf405c47b1b2c height=1063

while miner.log shows:
2024-09-06 11:48:12 DEBUG Calling grind command: 'src/bitcoin-util -cpunet -ntasks=8 grind 0000002
007bf0812a1d78e8a34f03a50365aeeea71ba7f74ea6073a31fc0c9d00000000065e75ba787cde4720fe866b1708af8196
24ee53fba87e8c001704866bf5b8ef83c24db66ffff001d00000000'
2024-09-06 11:54:31 DEBUG Calling bitcoin-cli: 'src/bitcoin-cli -cpunet -stdin submitblock'
2024-09-06 11:54:31 DEBUG     with input=b'0000002007bf0812a1d78e8a34f03a50365aeeea71ba7f74ea6073a
31fc0c9d00000000065e75ba787cde4720fe866b1708af819624ee53fba87e8c001704866bf5b8ef83c24db66ffff001dd
d1aa4f80102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0302270
4feffffff0100f2052a010000001600146b885d00449707d1da384fba80745f3ef61335cf00000000'
2024-09-06 11:54:31 DEBUG     result = b'inconclusive\n'
2024-09-06 11:54:31 DEBUG     stdout = b'inconclusive\n'
2024-09-06 11:54:31 DEBUG     stderr = b''
2024-09-06 11:54:31 DEBUG Submitting block:<PHONE_NUMBER>bf0812a1d78e8a34f03a50365aeeea71ba7f74ea6073
a31fc0c9d00000000065e75ba787cde4720fe866b1708af819624ee53fba87e8c001704866bf5b8ef83c24db66ffff001d
dd1aa4f80102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff030227
04feffffff0100f2052a010000001600146b885d00449707d1da384fba80745f3ef61335cf00000000
2024-09-06 11:54:31 WARNING submitblock returned inconclusive for height 1063 hash 00000000c7d7e2c
6d524d8b02472dc94144b3113f7ccf8b6d5baf405c47b1b2c

I had subscribed to the hashblock and rawblock messages and added logging for them as well as for if an unexpected sequence message was received. It seems bitcoind emitted none of these at 11:51:35 local time when the new block was received from an external source. 3 minutes later at 11:54:31 local time the local miner generated a stale block. :-/
Not sure what is causing this. At this point it looks like a bug in bitcoind's ZMQ implementation...
I wonder if the ZMQ socket got closed? I'll investigate that next.

Seen again.
The ZMQ socket is not closed when the "inconclusive" message is received.

Well saw it again, reopening.
Bitcoin's log:
2024-09-10T13:09:32Z UpdateTip: new best=000000006a9759d25bf63fac080d56004e77ba872732da25a5985fca2
1a21acf height=1200 version=0x20000000 log2_work=42.230042 tx=1201 date='2024-09-10T11:48:15Z' pro
gress=1.000000 cache=0.3MiB(122txo)
2024-09-10T13:09:32Z New outbound-full-relay v2 peer connected: version: 70016, blocks=1200, peer=
37
2024-09-10T13:09:58Z Saw new header hash=00000000ce8f148b78bde71112a8795c01fce216a1ea58f862ef444e0
f34aae3 height=1200

Miner log:
2024-09-10 09:09:32 INFO Connected new block tip 000000006a9759d25bf63fac080d56004e77ba872732da25a
5985fca21a21acf
2024-09-10 09:09:32 DEBUG     result = b'{\n  "capabilities": [\n    "proposal"\n  ],\n  "version"
: 536870912,\n  "rules": [\n    "csv",\n    "!segwit",\n    "taproot"\n  ],\n  "vbavailable": {\n
 },\n  "vbrequired": 0,\n  "previousblockhash": "00000000f5b91658bab675da8d994065ac8f0ef17ba11251e
f2d474534e93de6",\n  "transactions": [\n  ],\n  "coinbaseaux": {\n  },\n  "coinbasevalue": 5000000
000,\n  "longpollid": "00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6128",\n  "t
arget": "00000000ffff0000000000000000000000000000000000000000000000000000",\n  "mintime": 17259185
11,\n  "mutable": [\n    "time",\n    "transactions",\n    "prevblock"\n  ],\n  "noncerange": "000
00000ffffffff",\n  "sigoplimit": 80000,\n  "sizelimit": 4000000,\n  "weightlimit": 4000000,\n  "cu
rtime":<PHONE_NUMBER>,\n  "bits": "1d00ffff",\n  "height": 1200,\n  "default_witness_commitment": "6a
24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9"\n}\n'
2024-09-10 09:09:32 DEBUG     stdout = b'{\n  "capabilities": [\n    "proposal"\n  ],\n  "version"
: 536870912,\n  "rules": [\n    "csv",\n    "!segwit",\n    "taproot"\n  ],\n  "vbavailable": {\n
 },\n  "vbrequired": 0,\n  "previousblockhash": "00000000f5b91658bab675da8d994065ac8f0ef17ba11251e
f2d474534e93de6",\n  "transactions": [\n  ],\n  "coinbaseaux": {\n  },\n  "coinbasevalue": 5000000
000,\n  "longpollid": "00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6128",\n  "target": "00000000ffff0000000000000000000000000000000000000000000000000000",\n  "mintime":<PHONE_NUMBER>,\n  "mutable": [\n    "time",\n    "transactions",\n    "prevblock"\n  ],\n  "noncerange": "00000000ffffffff",\n  "sigoplimit": 80000,\n  "sizelimit": 4000000,\n  "weightlimit": 4000000,\n  "curtime":<PHONE_NUMBER>,\n  "bits": "1d00ffff",\n  "height": 1200,\n  "default_witness_commitment": "6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9"\n}\n'
2024-09-10 09:09:32 DEBUG     stderr = b''
2024-09-10 09:09:32 DEBUG GBT template: {'capabilities': ['proposal'], 'version': 536870912, 'rules': ['csv', '!segwit', 'taproot'], 'vbavailable': {}, 'vbrequired': 0, 'previousblockhash': '00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6', 'transactions': [], 'coinbaseaux': {}, 'coinbasevalue':<PHONE_NUMBER>, 'longpollid': '00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6128', 'target': '00000000ffff0000000000000000000000000000000000000000000000000000', 'mintime':<PHONE_NUMBER>, 'mutable': ['time', 'transactions', 'prevblock'], 'noncerange': '00000000ffffffff', 'sigoplimit': 80000, 'sizelimit': 4000000, 'weightlimit': 4000000, 'curtime':<PHONE_NUMBER>, 'bits': '1d00ffff', 'height': 1200, 'default_witness_commitment': '6a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf9'}
2024-09-10 09:09:32 INFO Mining Block: CBlock(nVersion=536870912 hashPrevBlock=00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6 hashMerkleRoot=fa9bb457513b1bdb012d73f1f0112be95e0f624bd7e35a7a8b0ed09cedf2e161 nTime=Tue Sep 10 09:09:32 2024 nBits=1d00ffff nNonce=00000000 vtx=[CTransaction(version=2 vin=[CTxIn(prevout=COutPoint(hash=0000000000000000000000000000000000000000000000000000000000000000 n=4294967295) scriptSig=02b004 nSequence=4294967294)] vout=[CTxOut(nValue=50.00000000 scriptPubKey=0014545cb26ee5771cf33af26d18c84694b8e6c24b5c)] wit=CTxWitness() nLockTime=0)])
2024-09-10 09:09:32 DEBUG Calling grind command: 'src/bitcoin-util -cpunet -ntasks=8 grind 00000020e63de93445472def5112a17bf10e8fac6540998dda75b6ba5816b9f50000000061e1f2ed9cd00e8b7a5ae3d74b620f5ee92b11f0f1732d01db1b3b5157b49bfa0c45e066ffff001d00000000'
2024-09-10 09:09:58 DEBUG Calling bitcoin-cli: 'src/bitcoin-cli -cpunet -stdin submitblock'
2024-09-10 09:09:58 DEBUG     with input=b'00000020e63de93445472def5112a17bf10e8fac6540998dda75b6ba5816b9f50000000061e1f2ed9cd00e8b7a5ae3d74b620f5ee92b11f0f1732d01db1b3b5157b49bfa0c45e066ffff001d5140ca100102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0302b004feffffff0100f2052a01000000160014545cb26ee5771cf33af26d18c84694b8e6c24b5c00000000'
2024-09-10 09:09:58 DEBUG     result = b'inconclusive\n'
2024-09-10 09:09:58 DEBUG     stdout = b'inconclusive\n'
2024-09-10 09:09:58 DEBUG     stderr = b''
2024-09-10 09:09:58 DEBUG Submitting block: 00000020e63de93445472def5112a17bf10e8fac6540998dda75b6ba5816b9f50000000061e1f2ed9cd00e8b7a5ae3d74b620f5ee92b11f0f1732d01db1b3b5157b49bfa0c45e066ffff001d5140ca100102000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0302b004feffffff0100f2052a01000000160014545cb26ee5771cf33af26d18c84694b8e6c24b5c00000000
2024-09-10 09:09:58 WARNING submitblock returned inconclusive for height 1200 hash 00000000ce8f148b78bde71112a8795c01fce216a1ea58f862ef444e0f34aae3
2024-09-10 09:09:58 INFO Mined a block solution at height 1200 with hash: 00000000ce8f148b78bde71112a8795c01fce216a1ea58f862ef444e0f34aae3
2024-09-10 09:09:58 DEBUG Block hash 00000000ce8f148b78bde71112a8795c01fce216a1ea58f862ef444e0f34aae3 payout to tc1q23wtymh9wuw0xwhjd5vvs355hrnvyj6u8hs7ey
2024-09-10 09:09:58 DEBUG Solved block is CBlock(nVersion=536870912 hashPrevBlock=00000000f5b91658bab675da8d994065ac8f0ef17ba11251ef2d474534e93de6 hashMerkleRoot=fa9bb457513b1bdb012d73f1f0112be95e0f624bd7e35a7a8b0ed09cedf2e161 nTime=Tue Sep 10 09:09:32 2024 nBits=1d00ffff nNonce=10ca4051 vtx=[CTransaction(version=2 vin=[CTxIn(prevout=COutPoint(hash=0000000000000000000000000000000000000000000000000000000000000000 n=4294967295) scriptSig=02b004 nSequence=4294967294)] vout=[CTxOut(nValue=50.00000000 scriptPubKey=0014545cb26ee5771cf33af26d18c84694b8e6c24b5c)] wit=CTxWitness() nLockTime=0)])

At :32:09 we were notified over ZMQ of connection of a new block tip, and correctly restarted the mining process. We then immediately call getblocktemplate and we get a block with 00000000f5b91658bab675da8d994065ac8f0ef17ba11251e as the previous block hash, instead of the newly-seen (height 1200) block 000000006a9759d25bf63fac080d56004e77ba872732da25a.
Therefore this is a race condition in Bitcoin between the ZMQ notification and getblocktemplate returning a result with the updated information.

Why is there a new peer connection in the middle of that? The miner script does not make peer connections nor spin up/down bitcoind peer nodes.


Freeze header row

Hello @pjjonesnz!
This is an amazing library, but one feature I could not figure out how to implement are frozen header panes. This would typically be solved "manually" by writing the following:
customize: function( xlsx ) {
                var sheet = xlsx.xl.worksheets['sheet1.xml'];
                var f1 = `<sheetViews>
                        <sheetView tabSelected="1" workbookViewId="0">
                               <pane ySplit="1" topLeftCell="A2" activePane="bottomLeft" state="frozen" />
                        </sheetView>
                   </sheetViews>`;
                $('worksheet', sheet).prepend(f1);

Are there plans to add this or perhaps I might have overlooked something in the documentation? Thank you for your time.

Thanks so much for your comment.  You're correct that this isn't implemented, but I'll make a note of it for next time I make some changes.


WebApplicationFactory method(s) to create HttpClient instances should be virtual

I'm using WebApplicationFactory<T> for some tests where I need to configure HttpClient appropriately with some default headers in order for the application to accept requests as valid.
Because all the HttpClient Create*Client() methods are non-virtual, it's not possible for me to override any of the implementations to set the headers before returning the client, so I need to make my own method and get all my tests to call that instead (CreateValidClient()) rather than have the fixture handle it for the consumers of it transparently.
It would be much easier to use WebApplicationFactory<T> in these tests if some (if not all) of the methods for creating HttpClient instances were virtual.
This is similar to #7631 which also requests changes to make it easier to make derived classes from WebApplicationFactory<T>.

#7638

Hi @martincostello.
Can you please update the title to reflect what exactly the change is. The intent is more to have an ability to configure the created client, rather than return something else (this is inline with my review comments).
Something like "Provide an ability to configure the client created by WebApplicationFactory<T>".

@mkArtakMSFT Done 👍


docs: add installation options and the openupm badge

@3DI70R thanks for contributing to OpenUPM. Please consider to merge the documentation update.

Ok, i've updated it, but i did it manually instead of applying pull request, because your commit contained invalid package link (openupm add com.littlebigfun.addressable-importer)

@3DI70R Oh, my mistake. Thanks for the fix.


Provide link from comment #1 to current issue summary

When reviewing the issue queue, the Summary field links to the top of the issue page. If the issue has been updated then the "N new" in the Replies field links to the #new comment. It would be helpful (when viewing an issue that has not been viewed before) if the comment #1 gave easy access to the start of the issue summary. Perhaps the dreditor could provide a link from comment #1 to the "page-subtitle" h1 tag. This would avoid the need to unnecessarily scroll the browser to view the summary.

Hi @sja45uk, thanks for the suggestion! At this time we're generally not interested in adding these types of tweaks to Dreditor itself, it's much easier these days to get these types of changes into drupal.org directly where everyone can use them, regardless of whether they use Dreditor (or whether their browser/device even supports browser extensions).

Makes sense to put something into the base page, but I am not sure how easy that will be to achieve as it affects all visitors. Is it feasible for me to fork dreditor to introduce an experimental change to help me decide if an additional link from each comment would be useful.
Sent from my Windows Phone

From: Scott<EMAIL_ADDRESS>Sent: 19/10/2015 22:01
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS>Subject: Re: [dreditor] Provide link from comment #1 to current issue summary (#271)
Hi @sja45uk, thanks for the suggestion! At this time we're generally not interested in adding these types of tweaks to Dreditor itself, it's much easier these days to get these types of changes into drupal.org directly where everyone can use them, regardless of whether they use Dreditor (or whether their browser/device even supports browser extensions).

Reply to this email directly or view it on GitHub:
https://github.com/unicorn-fail/dreditor/issues/271#issuecomment-149346093

I'm a bit confused now I thought this was just for comment #1 based on your description. So is it more of a "back to top" link?
Yes, it's easy to fork this repository and there are instructions for building the code into extensions in CONTRIBUTING.md.

Scott - My original requirement was to go from the Comment #1 up to the issue summary. It became apparent to me from your reply that there were two options: change D.o issue display; or change dreditor. As I thought further about a fork to dreditor, I decided that a back to issue summary from every comment would probably better meet my needs. So the inevitable requirements drift has struck. Steve
From: Scott Reeves<EMAIL_ADDRESS>Sent: 20 October 2015 12:41
To: unicorn-fail/dreditor
Cc: Steve
Subject: Re: [dreditor] Provide link from comment #1 to current issue summary (#271)
I'm a bit confused now I thought this was just for comment #1 https://github.com/unicorn-fail/dreditor/issues/1  based on your description. So is it more of a "back to top" link?
Yes, it's easy to fork this repository and there are instructions for building the code into extensions in CONTRIBUTING.md.
—
Reply to this email directly or view it on GitHub https://github.com/unicorn-fail/dreditor/issues/271#issuecomment-149535375 .  https://github.com/notifications/beacon/AC2oPw6k1YCS_6hYHliV0fy88-x1w6WIks5o9h_fgaJpZM4GRM5z.gif

Gotcha. I know it's not quite the same but don't most browsers let you go to to the top of the page by pressing Home on the keyboard?

I guess I should try Home then PgDn to see if it satisfies the use case. Unfortunately the Issue Summary starts more than half way down the screen.
From: Scott Reeves<EMAIL_ADDRESS>Sent: 20 October 2015 18:01
To: unicorn-fail/dreditor
Cc: Steve
Subject: Re: [dreditor] Provide link from comment #1 to current issue summary (#271)
Gotcha. I know it's not quite the same but don't most browsers let you go to to the top of the page by pressing Home on the keyboard?
—
Reply to this email directly or view it on GitHub https://github.com/unicorn-fail/dreditor/issues/271#issuecomment-149633167 .  https://github.com/notifications/beacon/AC2oP4wUbcR90Fu5JI_BY2rPtGi9w-tYks5o9mrMgaJpZM4GRM5z.gif


Need to remove Copy, Like/Dislike buttons if there is error instead of valuable response

November 13, 2024. Agreed on daily to do the following:

If there is error only (or stage only + error) in the response Copy, Like an Dislike buttons should not be available
If there is some text in the response + error in the response Copy, Like and Dislike buttons should be available

Be sure to make equal behaviour for laptop, mobile, tablet

Verified on staging env successfully. Reported #2893, #2887, #2894, #1963


Add vue-termini

vue-termini is a simple & lightweight (css-only animation) animated terminal frame for vue projects.
It's super easy to setup and embed.
Repo: https://github.com/Mikepicker/vue-termini

Thank you!

@Mikepicker Please create a PR if this is still relevant


logout and delete account user flow

i
Task/Issue URL: https://app.asana.com/0/0/1203838033501358/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #2737

PR #2740

PR #2744

PR #2759

PR #2773   👈

This comment was auto-generated by Graphite.


Modifier keys get stuck when switching away from the Graphite browser window/tab

The Shift, Ctrl, and Alt (modifier) keys get stuck when you use those keys to switch away from the browser window or tab running Graphite (for example, Alt-Tabbing). Then when you try to, for example, draw with a shape tool, it will get stuck in proportional scaling (Shift) and/or centered scaling (Alt). This also messes with the viewport keyboard shortcut navigation behavior (from #229). I believe the solution is to check the state of modifier keys any time that any input is processed and reset them to their current state, because the browser should be reporting the correct (non-stuck) value but we are only listening for modifier key state when modifier keys, rather than all forms of input, are received.

I can work on this.


Error npm run build

Fails after installation in the build script, the log says:
./bin/build-code
"." it is not recognized as an internal or external command, program or batch file executable.

I'm with windows operating system.

It looks like this is a duplicate of https://github.com/CanopyTax/single-spa-examples/issues/40 I'll take a look at this right now.

There are some changes we'll need to make to the build scripts to get these to work on Windows, because most versions of windows don't support bash scripts.
Depending on which version of Windows you are using you can install the linux subsystem on windows https://docs.microsoft.com/en-us/windows/wsl/install-win10 and use bash on windows.

@peterlavey apologies for the slowness in fixing -- could you try it now? I just pushed up a commit that removed all the bash stuff and makes it cross platform.


Reset store to intial state

How would you go about resetting the store to the initial state (intial state declared in separate files and imported)... without manually resetting all the properties of the state?

Hi,
I had the same requirement.
I simply cloned the initial store and saved it in a variable.
Then I added a method on the store itself to "restore" the initial state based on the saved state.

That's what i ended up with as well.  Thanks for sharing.

ozeebee has the recommended solution! Thanks guys! glad you figured it out :)


🗣 Translate: Italian

I would like to translate docs in Italian

I would like to translate docs in Italian

assigned to you

Completed. Thanks for your contributions 🎉 ❤


correction for composer require command

there was a typo in the composer require command.
With this correction, the user is able to copy&paste the command from the readme :)

Cheers for the correction!


Loggly tag support and rspec testing

Resubmission of PR https://github.com/logstash-plugins/logstash-output-loggly/pull/3 with separated commit messages to statisfy the request made by @karmi

@suyograo is there any other steps needed for getting this PR merged in?

LGTM

@nywilken can you create a PR with a version bump and we can release a new gem

Please see my latest PR with the version bump. Thank you for merging my
changes.
On Tue, May 19, 2015, 4:51 AM Suyog Rao<EMAIL_ADDRESS>wrote:

@nywilken https://github.com/nywilken can you create a PR with a
version bump and we can release a new gem
—
Reply to this email directly or view it on GitHub
https://github.com/logstash-plugins/logstash-output-loggly/pull/5#issuecomment-103191036
.


Refactor/intake forms tech stack

Description
Change form functionality to restrict users to only select one "tech_stack".  Update "tech_stack" data type to be an array.
Video Link
https://www.loom.com/share/2db99d6072ab4125800c1a14e0f3beb9
Trello Link
https://trello.com/c/s7Ecg99q/393-refactor-mentee-intake-form
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have removed unnecessary comments/console logs from my code
[x] My changes generate no new warnings
[x] I have checked my code and corrected any misspellings
[x] No duplicate code left within changed files
[x] Size of pull request kept to a minimum
[x] Pull request description clearly describes changes made & motivations for said changes

good , I see the 6ab70fea8c1f6200549061db4af4a563f4c61b16 have chage Mentor.js but the c961125e5c269305d5ad2edec6c8813889ee1180 change back . I don't know why


Arpita demo

demo

looks fine to me all the changes you made and i'm pushing the changes to the main repository


Fix multiple issues in WorkerThreadPool

Fix project settings being ignored.
Made usages of native_thread_allocator thread-safe.
Remove redundant thread-safety from low_priority_threads_used, exit_threads.
Fix deadlock due to unintended extra lock of task_mutex.

NOTE: I have a concern that by cherry-picking this into 4.0 the users that tweaked threading/worker_pool/* settings will now get a behavior change. It's the correct thing to happen, but maybe too surprising for 4.0, or at least warrants a note in the release notes.
UPDATE: For the records, this may also fix some hard to reproduce crash related to a thread object in one of the projects used to test #74405, that worked fine otherwise.

NOTE: I have a concern that by cherry-picking this into 4.0 the users that tweaked threading/worker_pool/* settings will now get a behavior change. It's the correct thing to happen, but maybe too surprising for 4.0, or at least warrants a note in the release notes.

Doesn't seem too problematic. But yes, it will be mentioned in the changelog.

Sorry for the pushes, mark as draft, etc. I had just found an issue and thought it was a regression from this PR, but it isn't. I will just fix it in another PR, which may take more time.

Fantastic work!

This seems to be causing a deadlock when running unit tests godot --test, when compiling with scons tests=yes (or dev_mode=yes).
(gdb) bt
#0  0x00007f8821dfb736 in __futex_abstimed_wait_common () from /lib64/libc.so.6
#1  0x00007f8821dfdda8 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libc.so.6
#2  0x000000000a56c66c in Semaphore::wait (this=0xe8d16a8) at ./core/os/semaphore.h:56
#3  WorkerThreadPool::wait_for_task_completion (this=0xd6225c0, p_task_id=1) at core/object/worker_thread_pool.cpp:274
#4  0x0000000005987e62 in TestWorkerThreadPool::DOCTEST_ANON_FUNC_4977 () at ./tests/core/threads/test_worker_thread_pool.h:66
#5  0x00000000057b1b81 in doctest::Context::run (this=0x7ffd6311b9a0) at ./thirdparty/doctest/doctest.h:6930
#6  0x0000000005c2d145 in test_main (argc=2, argv=0x7ffd6311c018) at tests/test_main.cpp:186
#7  0x000000000576e168 in Main::test_entrypoint (argc=2, argv=0x7ffd6311c018, tests_need_run=@0x7ffd6311ba7f: true) at main/main.cpp:684
#8  0x00000000056f9e02 in main (argc=2, argv=0x7ffd6311c018) at platform/linuxbsd/godot_linuxbsd.cpp:55

Quoting myself from RC:

The problem is that, now the WorkerThreadPool is initialized once project settings are read, it's not initialized as part of the "very core" and, thus, it's not initialized for tests.
The simplest thing would be to add WorkerThreadPool::get_singleton()->init(); to test_main().
I'm not sure that is the right way to do it, though.
In any case, I'm doing that in the PR. Should be fine at least for now.

How late can WorkerThreadPool initialization be pushed to?
Specifically, if it can be initialized after ScriptServer (see below link), this can supersede #74501 and #76586 , which is currently blocking ThreadSanitizer in CI ( #73777 ) from being merged.
https://github.com/godotengine/godot/blob/fd4a06c51555904104b18494d0224f450d74fe2a/main/main.cpp#L2441

Alternatively, WorkerThreadPool::init() and WorkerThreadPool::finish() can be merged into a single WorkerThreadPool::resize() function, defaulting to 0 worker threads where tasks are run on the main thread.
This would make WorkerThreadPool available for use immediately in single-threaded mode, allowing it to be safely "initialized" into multithreaded mode much later than was possible before.
It would also make it possible to unit test different WorkerThreadPool sizes.

@myaaaaaaaaa, that can work. Could you please incorporate that change to your PR? Let's say that's a related but separate issue than the ones this PR aims to fix and it shouldn't take much longer to be merged. Aside, there should be a way to assert that the thread pool has been properly initialized with threads by some point. For instance, this PR was breaking tests by failing to initialize it because there would be zero threads to run the tasks, but at least we could realize. With the changes we are considering, the test cases would just happily run all the tasks on the main thread, which is not what they are meant to do.

Thanks!

@myaaaaaaaaa, that can work. Could you please incorporate that change to your PR? Let's say that's a related but separate issue than the ones this PR aims to fix and it shouldn't take much longer to be merged.

@RandomShaper  I would prefer to open a new PR for it after my outstanding threading PRs are merged/rejected first, to avoid headaches in development due to merge conflicts.
#73388
#72577
#72687
#72704
#72716
#72784


Runtime error in Homebridge 1.0.4

The plugin was running properly with homebridge 0.4.53. After the upgrade to 1.0.4 (all other plugins working properly or provide an update) I get:
 TypeError: Cannot read property 'length' of undefined
    at Accessory.configureCameraSource (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:541:40)
    at PlatformAccessory.configureCameraSource (/usr/local/lib/node_modules/homebridge/src/platformAccessory.ts:132:41)
    at CameraMotionPlatform.didFinishLaunching (/usr/local/lib/node_modules/homebridge-camera-motion/camera-motion.js:47:21)
    at HomebridgeAPI.emit (events.js:203:15)
    at HomebridgeAPI.signalFinished (/usr/local/lib/node_modules/homebridge/src/api.ts:231:10)
    at Server.start (/usr/local/lib/node_modules/homebridge/src/server.ts:159:14)
    at cli (/usr/local/lib/node_modules/homebridge/src/cli.ts:78:10)
    at Object.<anonymous> (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)

Same issue.

should this issue also be filled against the hap-node? didn't see anything about breaking changes around configureCameraSource?

Same issue here as well.

Same issue here as well.

Hello, sorry I am not using this anymore. If someone wants to get this project ou make some PR to fix the issue, he is welcome.

Hello, sorry I am not using this anymore. If someone wants to get this project ou make some PR to fix the issue, he is welcome.

Me too, did anyone find a workaround or anything?

Me too, did anyone find a workaround or anything?

Is anyone using this on an old version of Homebridge successfully? If so, which version are you using? thanks

Is anyone using this on an old version of Homebridge successfully? If so, which version are you using? thanks


Feat: Motivational quote extension

Is your extension request related to a problem? Please describe.
Sometime while working tirelessly and feel demotivated , so to motivate myself I have created this extension
By default, when you open a new tab in Chrome, you are presented with a blank page or a generic page displaying commonly visited websites or a search bar. This can be monotonous and may not provide any visual stimulation or motivation.
Describe the solution you'd like.
I want something which can motivate me instantly without ao much searching or surfing as in this high pace world it is very difficult to keep ourself motivated
Describe alternatives you've considered.
The extension solves the problem of a dull and uninspiring new tab page experience in the Chrome browser.
The extension addresses this problem by replacing the default new tab page with a visually engaging background image of nature and displaying motivational quotes. This helps to create a more pleasant and inspiring environment for users when they open a new tab.
Add any other context or screenshots about the extension here.
No response

I request you to please assign me this issue

I request the admin to please assign me this issue