Will core 0 fence and then core 1 do fence.i make instruction fetch get the same instruction memory in a multicore system

Hello @aswaterman ,
I have a question in understanding these lines of the zfencei spec
https://github.com/riscv/riscv-isa-manual/blob/3c1d60298f16523aba30d45ba4d7c9381a4e2d4c/src/zifencei.adoc?plain=1#L69-L79
As spec described below,
To make a store to instruction memory visible to all RISC-V harts, the writing hart also
has to execute a data FENCE before requesting that all remote RISC-V
harts execute a FENCE.I.

below updated

If in multicore system eg. 4 core, core 0 load instruction from external memory and write data into its data-cache, and then do a FENCE in just core 0, will other cores such as core 1-3 (after they do a FENCE.i) see the same instruction in the same memory address as core 0 see?  or in other word, will core 1-3 instruction fetch be able to see the data in core0's data-cache?
There is a dissussion in linux implemention about this, see

<EMAIL_ADDRESS>https://github.com/torvalds/linux/commit/01261e24cfab69c65043e1e61168348ae23a64c2

Here is a updated version:
If in multicore system eg. 4 core, core 0 load instruction from external memory and write data into its data-cache, and then do a FENCE in just core 0, will other cores such as core 1-3 (after they do a FENCE.i) see the same instruction in the same memory address as core 0 see?  or in other word, will core 1-3 instruction fetch be able to see the data in core0's data-cache?
Actually, per our understanding to ISA-SPEC, we feel the answer is NO, i.e., the core 1-3 instruction fetch cannot see the data in core0's data-cache. The right sequence should be :

1, core 0 load instruction from external SD card memory and write data into its DCache

2, core 0 then do a FENCE.i to make sure its own ICache is synced with its DCache, and the core0's DCache will be flushed into main memory

3, core 0 then do a FENCE as barrier to make sure the preceding operation is visible to memory

4, core0 then ask for other core1-3 to do FENCE.i

5, and then core1-3 (after do FENCE.i) re-fetch the instruction from the main memory to get the latest instructions

Can you help to confirm that our understanding is correct?
Many Thanks

On Wed, Jul 17, 2024 at 8:30 PM Huaqi Fang @.***> wrote:

Here is a updated version:
If in multicore system eg. 4 core, core 0 load instruction from external
memory and write data into its data-cache, and then do a FENCE in just core
0, will other cores such as core 1-3 (after they do a FENCE.i) see the same
instruction in the same memory address as core 0 see? or in other word,
will core 1-3 instruction fetch be able to see the data in core0's
data-cache?

The missing piece in the preceding (which corresponds to "the writing hart
also has to execute a data FENCE before requesting that all remote RISC-V
harts execute a FENCE.I") is to perform the memory access(es) after the
FENCE that cause a request to be sent to all the remote harts.
All this of course presumes data cache coherency and hence no need for
CBO's to explicitly push the written instruction out of core 0's data cache.

Actually, per our understanding to ISA-SPEC, we feel the answer is NO,
i.e., the core 1-3 instruction fetch cannot see the data in core0's
data-cache. The right sequence should be :

1, core 0 load instruction from external SD card memory and write data
into its DCache
2, core 0 then do a FENCE.i to make sure its own ICache is synced with
its DCache, and the core0's DCache will be flushed into main memory
The FENCE.I doesn't cause core 0's DCache to be flushed.  It just causes
its ICache and instruction fetch/etc. to become synchronized or consistent
with the instruction written into its DCache.

3, core 0 then do a FENCE as barrier to make sure the preceding
operation is visible to memory

As noted above the FENCE is to order the write of the instruction into
core 0's DCache with the sending of a request (e.g. an IPI) to all remote
harts.  That ensures that the write is globally visible before any of the
remote harts receive the request to do a FENCE.I (assuming all DCaches are
coherent with each other as noted above).

4, core0 then ask for other core1-3 to do FENCE.i

5, and then core1-3 (after do FENCE.i) re-fetch the instruction from
the main memory to get the latest instructions
Yes.  The FENCE.I in a typical implementation flushes the fetch/decode
pipeline of the core and, if the ICache is not coherent with all
the DCaches in the system, also flushes the ICache.  (Details will vary
depending on the details of an implementation.)

Greg

Can you help to confirm that our understanding is correct?
Many Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/1544#issuecomment-2235244072,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALLX6GS56UNY7AHMFT6NJMDZM4ZGZAVCNFSM6AAAAABLBZBEP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZVGI2DIMBXGI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi @gfavor , thanks for your reply.
As the email list<EMAIL_ADDRESS>described below, I just copied a piece of latest discussion quoted

Finally,
Riscv spec describe the fence.i instruction as following:

The FENCE.I instruction is used to synchronize the instruction and
data streams.
RISC-V does not guarantee that stores to instruction memory will be
made visible to instruction fetches on a RISC-V hart until that hart
executes a FENCE.I instruction. A FENCE.I instruction ensures that a
subsequent instruction fetch on a RISC-V hart will see any previous
data stores already visible to the same RISC-V hart. FENCE.I does not
ensure that other RISC-V harts' instruction fetches will observe the
local hart’s stores in a multiprocessor system.

From this description, fence.i instruction only applies to local
core,making instruction fetch can see any previous data stores on the
same core.

Not on the same core, it is said: "A FENCE.I instruction ensures that
a subsequent instruction fetch on a RISC-V hart will see any previous
data stores already visible to the same RISC-V hart".
In other words, any store that is in the dcache of core0 should be
seen by the instruction fetcher of any other core right? Since any
core should be able to see what is in the other core's dcache right
(ie the dcaches are coherent)? If your instruction fetcher on the
other cores does not see the data, a simple memory barrier on core0
should make it visible, no need to flush the core0 dcache.

The commit[1] author(Alexandre Ghiti) thought If your instruction fetcher on the other cores does not see the data, a simple memory barrier on core0 should make it visible, no need to flush the core0 dcache., but we thought we need to do a fence.i to flush the core0 dcache not just a simple memory barrier, and then the other cores instruction fetcher then can see the data, could you help us to confirm which one is a correct understanding.
cc @palmer-dabbelt the commit co-author
[1] https://github.com/torvalds/linux/commit/01261e24cfab69c65043e1e61168348ae23a64c2
Thanks
Huaqi

The commit[1] author(Alexandre Ghiti) thought If your instruction fetcher
on the other cores does not see the data, a simple memory barrier on core0
should make it visible, no need to flush the core0 dcache.

A memory barrier (aka FENCE) does not make specified prior memory accesses
globally visible.  It only ensures an order in which preceding and
following memory accesses eventually become globally visible.  And FENCE
instructions do not cause flushing actions on caches.
but we thought we need to do a fence.i to flush the core0 dcache not just a

simple memory barrier,

FENCE.I does not cause flushing actions on DCaches.  It only establishes
consistency between the I side of a core and its DCache.
Greg

Message ID: @.***>

Hi Greg, thanks for your reply, we will continue to discuss with the patch author.


Installation problem

So, maybe i'm to dull for this...
Instructions say: "Add this repository to HACS, install it, then go to Configuration > Integrations > Add Integration > Choose "MyJDownloader" and enter your email address and password. Your currently available JDownloaders should appear as devices."
I do: Add this repository to HACS, install it, restart (even full reboot) then go to Configuration > Integrations > Add Integration > Choose "MyJDownloader" and no such Integration there. And no way to enter the configuration manually as the 'old' sensor login information does'n counts.
What am i doing wrong?

First, thanks for trying it out. I'm not sure why it did not show up actually. If you can wait for a few more days, you should be able to install it from the original repo at https://github.com/doudz/homeassistant-myjdownloader as I will make a pr soon to replace the previous version of the integration with this rewritten one.
You can follow the progress on that here: https://github.com/doudz/homeassistant-myjdownloader/issues/12

@RobindotK v2.0.0 just got released, You can install it again from the original repo.

I have same issue as above


Button Enhancement all over the project

Use the same kind of drop shadow all over the project
Have round rectangular corners
radius: 6-8
x:0
y:3
b:6
Before giving a pr just send the image here

Use the same kind of drop shadow all over the project
Have round rectangular corners
radius: 6-8
x:0
y:3
b:6
Before giving a pr just send the image here

Can I?

@anushbhatia @smaranjitghose  Can I work on this ?

@anushbhatia -  radius 10px
box-shadow -0 3 6

Is this fine?


Add the possibility to write values using IDM modbus

Hi,
before all, thanks for this integration.
I performed different tests and this integration (at least with my setup) represents the only way to correctly setup the
modbus communication with the IDM heatpump.
Here I suggest what I think is a useful integration
Is your feature request related to a problem? Please describe.
IDM heat pump offers the possibility to also write values using modbus. I found two sensors to be particularly interesting.

sensor.idm_warmepumpe_aktueller_pv_produktion
sensor.idm_warmepumpe_aktueller_pv_uberschuss

Setting this two values, you can inform the heat pump about how much energy you have from a photovoltaic system and how much of that energy is available as it does exceed your current consumption. As far as I understood, this way the heat pump can prepare hot water taking advantage of the energy that otherwise will be unused. Saving energy later as the water will be already hot.
Describe the solution you'd like
The perfect solution will be to select another sensor as input, and one of the two variables as output, repeating the process for both variables.

sensor.my_inverter_pv_produktion ->  sensor.idm_warmepumpe_aktueller_pv_produktion
sensor.my_inverter_aktueller_pv_uberschuss -> sensor.idm_warmepumpe_aktueller_pv_uberschuss

Two considerations:

aktueller_pv_uberschuss can be te result of an arithmetical operation, current production - current energy usage, which can be obtained using aliases if I correctly understood.
Some inverters automatically shout down at night, that should be took into consideration when reading input from the sensor, thus performing something like sensor.my_inverter_pv_produktion or 0.0

Describe alternatives you've considered
I tried to setup everything manually following the really precious instructions on this repo Homeassistant-IDM-Integration, however I encounter some problems with the home assistant modbus implementation as every few reads it encounters an error, setting the values to unavailable until the next read.
I have investigated a little bit in the code as home assistant core uses the same pymodbus 3.1.3, but I did non find the cause of the problem.
I never tested write operations as I do not feel confident of the solution until I can get rid of the problem during reading.
Error:
[homeassistant.components.modbus.modbus] Pymodbus: idm_wp: Modbus Error: [Connection] ModbusTcpClient(<IP_ADDRESS>:502): Connection unexpectedly closed 0.0067907405853271484 seconds into read of 8 bytes without response from unit before it closed connection

First of all thanks for the interest in the integration.
I know of the writable registers the IDM heat pumps provide. However, I have not implemented them, because the heat pump I used to develop this integration is connected to a Fronius Solar Inverter, which uses a proprietary protocol through which the heat pump can access even more information than otherwise. Therefore, I sadly have no way of testing the modbus way of setting solar energy values. Without a way to test things, I'm not comfortable to write the necessary code.
If you feel comfortable writing the necessary code yourself, I am open to pull requests. I can also point you in the right direction (which code probably needs changes), but you'd have to do most of the work.
Otherwise, I can only suggest you look into connecting the heat pump to your solar inverter through some other means. The IDM multiple different inputs for this, IDM support may be able to help you with that and you can also find some info via Google.

every few reads it encounters an error, setting the values to unavailable until the next read.

Yes, that in fact is part of the reason why I developed this integration. It seems the IDM heat pump doesn't like to keep TCP sockets open and refuses to respond after a while. The integration solves that by trying to reconnect when a read fails. Only if the reconnect also fails is the value set to unavailable.

Yes I am considering a pull request but I still trying to understand the code. You did a really great job and looking into your code I am learning a lot of things. Last time I tested I was looking into the docker setup you made with visual studio code. I will try to implement something as soon as I understand the code better.
For the moment since you know a lot of the problem on the TCP socket, what do you think opening an issue on homeassistant/core repo to explain the problem? and suggesting them the same fix? Probably it can solve the situation also for others.
The strange thing is that this problem seems to not occur in every installation. I asked to the developer who wrote the repo I linked and he seems to have zero problems. While another person told me that after every correct read the next will be a  bad one. In my case instead it seems more a random pattern, and my main hypothesis is that this was caused by the fact that I was using different scan intervals.

The VS Code / devcontainer setup is based on https://github.com/ludeeus/integration_blueprint, which has a bit more documentation on it.

what do you think opening an issue on homeassistant/core repo to explain the problem? and suggesting them the same fix? Probably it can solve the situation also for others.

There is already a recent issue https://github.com/home-assistant/core/issues/87265 for similar problem with different device. The developers of Homeassistant decided that the "Connection unexpectedly closed" problem is not an error in the modbus integration and therefore they cannot do anything.
It seems the config in https://github.com/home-assistant/core/issues/87265#issuecomment-1434364862 (somewhat) helped the person with the original issue. Maybe it works for you too.
Otherwise, I would suggest you open a new issue yourself. You can tag me, or link to this issue and I'll gladly explain to the homeassistant devs what I did in this integration. But I don't think it would be much help, if I opened the issue myself. I don't have any logs with the error right now. I also can't test any fixes without reconfiguring my (working) homeassistant setup, which I'd like to avoid.

The strange thing is that this problem seems to not occur in every installation.

If the IDM heat pump does use a timeout for idle connections, the read intervals configured in homeassistant would definitely have an effect on the issue. If you read very often, you may not see the error at all. It could also be that different IDM models act differently or that it depends on your local LAN setup, especially WiFi might cause unstable connections.

Thank you very much I found the documentation and I started following it yesterday. Let's see if I can come up with something useful.
I have read the issue you linked multiple times, but at the end the owner found out the problem which was a NodeRed instance. After reading the issue I tested different setups hoping that also in my case was something network related. I disconnected everything and to be sure there was nothing even on my pc (which I use to monitor) I changed all the ips, but nothing.
Then I found out other IDM and homeassitant owners have the same problem and thanks to this I found your repo.
From your response I am finally convinced that it is something related to timeout of the TCP socket. I wrote a simple python script to test reads and only after I read your answer I realized it was working because I was opening and closing a new connection every time, now I will try to keep it open to test if there is a timeout. I have several different ideas to test.
I found also an issue home-assistant/core#87265 which is more related to RTU but that suggest in June there will be an update of pymodbus.

@Colleoni  If you have progress on the writing data to the heatpump and you need testers... I'd be in... would be nice to control heating temperature in winter via home assistant!
Also THANKS a lot for the integration so far. I used to read the values manually using node-red and their modbus integration. But this is just so much easier and gives me so much more sensor data! Love it! Thanks a lot!!!

Hi all, closing connection and sockets may be related to limited resources and is a way to keep the system running endless. Therefore this behavior may be partly intended by IDM and I can understand why they did so. @kodebach: Your code fixes that issue and I think this is the prefered way anyway. You never can expect sockets are endless connected and need always be prepared for a error handling and reconnect code. Well done, just keep it that way, even modbus implementation changes later. That is good practise anyway.
For the writing of the two PV values, I am interested as well and can test.
@Collenoi: Your initial considerations about calculation of these values, this is your job in the automation of your Setup. This will never be part of this integration, because this integration can't take care of your solar setup. I like it a lot more to have this separated.

closing connection and sockets may be related to limited resources and is a way to keep the system running endless

Yeah that all makes sense. However, the way it is implemented is still very strange. The heat pump doesn't actually terminate the TCP socket AFAICT, it just stops responding and/or sends empty responses.

@georgbachmann @AndyNew2, unfortunately I did not have time to look any further into the setup. So still at the starting point and currently using a manual schedule which I setup to what I expect to be sunny hours during the day. Simply by manually looking into PV production stats (sure it does not consider the possibility of cloudy days, so not a real solution)
For the initial considerations, sure it depends on personal setup I do not expect to find them integrated (or at least not strictly required), I just thought they could be useful to explain the issue and the possibilities.
In any case, I think you can create your own aliases and operations in homeassitant.

@Colleoni - @SimowN implemented the writing of the PV values already. See https://github.com/simowNgithub

@KV62: I struggle to understand the work from SimowN: Does this mean the provided script directly writes the values via modbus to the iDM Heatpump. Because the provided github link is no home assistant integration. It is just little elements. The description is poor. So nothing to install, just copy and past the script and adapt to my needs? For example I do not need this calculation and currently just want to copy the values from Solarmodul to iDM.

closing connection and sockets may be related to limited resources and is a way to keep the system running endless

Yeah that all makes sense. However, the way it is implemented is still very strange. The heat pump doesn't actually terminate the TCP socket AFAICT, it just stops responding and/or sends empty responses.

@kodebach should we check it together to get it work? at the moment i tuned my script for restarting the HA modbus service after every write register to the IDM. Because after updating the modbus libs with HA 2023.09.* the old script was broken.

Does this mean the provided script directly writes the values via modbus to the iDM Heatpump. Because the provided github link is no home assistant integration. It is just little elements.

AFAICT the repo at https://github.com/simowNgithub/Homeassistant-IDM-Integration contains example configuration files that use the existing modbus integration for Home Assistant to communicate with the heat pump. I had problems with frequent disconnections and "unavailable" values with that approach, which is why I wrote this custom integration. I believe the modbus integration has since been improved and now also handles automatic reconnects.

should we check it together to get it work? at the moment i tuned my script for restarting the HA modbus service after every write register to the IDM. Because after updating the modbus libs with HA 2023.09.* the old script was broken.

The integration already has code to automatically restart it's internal modbus client, if a read fails, so there shouldn't be any issues in this integration. I believe the improvement to the underlying pymodbus library that would help here is the retry_on_empty option. I didn't test this, because I solved it differently in my integration. But in the standard modbus integration this option was exposed as retry_on_empty in 2023.9.x, but has been deprecated in 2023.10.x. Now it is automatically enabled, so maybe with 2023.10.x your scripts work better again.
In #40 I added some basic logic for writing values via a service exposed by the integration. It is almost entirely untested, but should in theory allow write the values requested here. Feel free to test and provide feedback in #40.

Yes that is a lot better understandable. When I read the description from simowNgithub, I expected to see something similar you did, but this is not the case. The the sentense "Use my script for getting the available power for the heatpump and sync the values to the heatpump" means actually a little bit rework and not just using the script but mainly the configuration file holding the code and needs adaptation. Nothing described, but the integration in iDM which is described in the iDM paper anyway is very detailed. That is confusing, since you expect the same detail level on the HA integration as well. I am quite busy in the moment but at a certain point will try #40

Thanks to @kodebach for the improved integration. So far I have used @simowNgithub 's script/config and adapted this for my situation (surplus solar power provided from a P1-connector to my smart meter + calculated solar production from my clamps used by my Myenergi-car charger(some problems with the latter)). I get values to the heat pump and can see that it reacts based on this.
I am now considering to use @kodebach 's integration as the basis. To make this work for my situation, I wanted to ask whether it is correct that I can do the following:

Create a config file to define + do the required calculations for surplus solar & calculated solar production (assume that all other variables required are defined in the @kodebach integration)
Use @simowNgithub 's script & automation to write these values to the heat pump

Appreciate if you could confirm that in principle this would work + I assume that the @kodebach integration will be extended with the write option later on, so that only 1. will be required.

In theory your idea should work. I think you can just remove the sensors part of the modbus config for the heat pump (you need the rest for writing). In the scripts and automations you still use modbus.write_register to write to the heat pump, but you swap the IDs from the removed modbus: sensors config with the corresponding IDs from this integration.

Anybody tried yet this beta? It is a little bit hassle to install that version.
@kodebach: Would you mind to create a standard beta release? I will still try but need to find more time...

Hi All,
I was using the IDM HACS in combination with the modbus write_register scripts for several months. But from time to time it happens that the value at the IDM site doesn't get updated anymore. Therefore I am also very interested into getting this done all in one stable integration.
I am about to test the write feature. I was able to successfully implement the write-values branch into HA. But I struggle with the adaption of the scripts.yaml.

In theory your idea should work. I think you can just remove the sensors part of the modbus config for the heat pump (you need the rest for writing). In the scripts and automations you still use modbus.write_register to write to the heat pump, but you swap the IDs from the removed modbus: sensors config with the corresponding IDs from this integration.

I am not sure with what I have to replace the data (hub, unit, address) part with?
idm_update_pv_values:
  alias: Update Photovoltaik values to IDM Headpump
  sequence:
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 74
    data_template:
      value: >
        [ {{ unpack(pack(states("sensor.wp_aktueller_pv_uberschuss")|float, ">f"), ">H", offset=2) }},
          {{ unpack(pack(states("sensor.wp_aktueller_pv_uberschuss")|float, ">f"), ">H") }} ]
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 78
    data_template:
      value: >
        [ {{ unpack(pack(states("sensor.pv_aktuelle_produktion")|float, ">f"), ">H", offset=2) }},
          {{ unpack(pack(states("sensor.pv_aktuelle_produktion")|float, ">f"), ">H") }} ]
  mode: single

My sensor names from the integration are default:

sensor.idm_warmepumpe_aktueller_pv_produktion
sensor.idm_warmepumpe_aktueller_pv_uberschuss

Could someone please give me an example what exactly this has to look like?
Thanks.

Hi All, I was using the IDM HACS in combination with the modbus write_register scripts for several months. But from time to time it happens that the value at the IDM site doesn't get updated anymore. Therefore I am also very interested into getting this done all in one stable integration.
I am about to test the write feature. I was able to successfully implement the write-values branch into HA. But I struggle with the adaption of the scripts.yaml.

In theory your idea should work. I think you can just remove the sensors part of the modbus config for the heat pump (you need the rest for writing). In the scripts and automations you still use modbus.write_register to write to the heat pump, but you swap the IDs from the removed modbus: sensors config with the corresponding IDs from this integration.

I am not sure with what I have to replace the data (hub, unit, address) part with?
idm_update_pv_values:
  alias: Update Photovoltaik values to IDM Headpump
  sequence:
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 74
    data_template:
      value: >
        [ {{ unpack(pack(states("sensor.wp_aktueller_pv_uberschuss")|float, ">f"), ">H", offset=2) }},
          {{ unpack(pack(states("sensor.wp_aktueller_pv_uberschuss")|float, ">f"), ">H") }} ]
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 78
    data_template:
      value: >
        [ {{ unpack(pack(states("sensor.pv_aktuelle_produktion")|float, ">f"), ">H", offset=2) }},
          {{ unpack(pack(states("sensor.pv_aktuelle_produktion")|float, ">f"), ">H") }} ]
  mode: single

My sensor names from the integration are default:

sensor.idm_warmepumpe_aktueller_pv_produktion
sensor.idm_warmepumpe_aktueller_pv_uberschuss

Could someone please give me an example what exactly this has to look like? Thanks.

Hi, i had this issues with the new HA releases. At the moment I always restart the modbus HA component before the write register…

idm_update_pv_values:
  alias: Update Photovoltaik values to IDM Headpump
  sequence:
  - service: modbus.restart
    data:
      hub: idm_heatpump
    enabled: true
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 74
    data_template:
      value: "[ {{ unpack(pack(states(\"sensor.wp_aktueller_pv_uberschuss\")|float,
        \">f\"), \">H\", offset=2) }}, \n  {{ unpack(pack(states(\"sensor.wp_aktueller_pv_uberschuss\")|float,
        \">f\"), \">H\") }} ]\n"
  - service: modbus.write_register
    data:
      hub: idm_heatpump
      unit: 1
      address: 78
    data_template:
      value: "[ {{ unpack(pack(states(\"sensor.pv_aktuelle_produktion\")|float, \">f\"),
        \">H\", offset=2) }}, \n  {{ unpack(pack(states(\"sensor.pv_aktuelle_produktion\")|float,
        \">f\"), \">H\") }} ]\n"
  mode: single

I am not sure with what I have to replace the data (hub, unit, address) part with?

See https://github.com/kodebach/hacs-idm-heatpump/pull/40#issuecomment-1782490699

When the heatpump starts, does the heatpump expect this value is reduced by the own consumption? So when the heatpump starts and needs 1kW the value should go down by 1kW?

That seems to be the case. At least from what I can tell with my setup, where the heat pump is communicating directly with the Fronius solar inverter. I can still read the "PV Übschuss" value from the heat pump and as soon as the heat pump switches on this value drops.
I assume the the idea behind the two value is that you have two power meters. One that measure the power from the solar array and another that measures the power leaving your house towards the grid (sometimes you can use the smart meter provided by the power company for that). The heat pump then wants the raw value from the first power meter as well as the difference between the two meters.
The Modbus documentation from IDM also says that you can use the "Aktuelle Leistungsaufnahme Wärmepumpe" value if necessary and that the heat pump will start as soon as "PV Überschuss" > "Aktuelle Leistungsaufnahme Wärmepumpe" and will then follow the settings in the PV menu. I assume there is also some hysteresis involved and that the heat pump compares against an expected power value, if it is not currently running.

Is it expected to be negative in case the pv production is too less and external energy is consumed. This is used for iDM statisticts, correct?

Not sure. The integration would currently show negative values as "unavailable". But you can just look at the debug logs, when your PV is running and producing power, but there is no surplus. If the raw value for power_solar_surplus is negative, I should probably change the integration to allow that.
But the difference between 0 and negative is probably just what shows up in the IDM UI.

I am not sure with what I have to replace the data (hub, unit, address) part with?

See #40 (comment)

Thanks for the explanation. In the developer section it is working fine and looks for example like this:
service: idm_heatpump.set_power
data:
  target: sensor.idm_warmepumpe_aktueller_pv_produktion
  value: 0.123

But I am was not able to successfully add my sensor data to the value. Maybe it is a problem with the format of my data preparation?
I have a GoodWe GW10K-ET, using the GoodWe Inverter Integration to receive the data.
In the configuration.yaml I use an adapted version of this config: https://github.com/simowNgithub/Homeassistant-IDM-Integration/blob/main/configuration.yaml
template:
  - sensor:
      - name: "PV aktuelle Produktion"
        unique_id: "idm_aktuelle_pv_produktion"
        unit_of_measurement: "kW"
        state: >
          {% if states('sensor.pv_power') == 'unavailable' %}
            0.0
          {% else %}
            {{ '%.2f'%(states('sensor.pv_power')|float / 1000|float| float) }}
          {% endif %}
        state_class: measurement
        device_class: power
        icon: mdi:solar-power
      - name: "WP aktueller PV Überschuss"
        unique_id: "idm_aktueller_pv_ueberschuss"
        unit_of_measurement: "kW"
        state: >
          {% if states('sensor.pv_power')|float == 0|float %}
            0.0
          {% elif states('sensor.meter_active_power_total') == 'unavailable' %}
            0.0
          {% elif states('sensor.meter_active_power_total')|float < 0|float %}
            0.0
          {% else %}
            {{ '%.2f'%(states('sensor.meter_active_power_total')|float / 1000|float| float) }}
          {% endif %}
        state_class: measurement
        device_class: power
        icon: mdi:solar-power

The two values are prepared as float and rounded to two decimal places. It is working fine with the "modbus.write_register" script, but somehow I cannot use it in the "idm_heatpump.setpower" service.
service: idm_heatpump.set_power
data:
  target: sensor.idm_warmepumpe_aktueller_pv_produktion
  value: {{ states('sensor.pv_aktuelle_produktion') }}

Fehler beim Aufrufen des Diensts idm_heatpump.set_power. Unknown error
Does someone have an idea what I am doing wrong?

2. a) When the heatpump starts, does the heatpump expect this value is reduced by the own consumption? So when the heatpump starts and needs 1kW the value should go down by 1kW? This is usually automatically the case, but not for me. I need to substract in that case the estimated own consumption.

As the uberschuss it the actual value fed into the grid measured by the smart meter, it will be for sure getting lower if the power is consumed by the heat pump. I think the IDM is regulating the actual usage by using both values (produktion and uberschuss), but not sure how exactly it works. I assume that it regulates the power usage of the IDM always close to a uberschuss of almost 0.

2. b) Is it expected to be negative in case the pv production is too less and external energy is consumed. This is used for iDM statisticts, correct?

These values are above prepared in a way, that it will never be below 0.

Actually for trying the branch I am a little bit behind the topic. Do I need to have git installed to do so? I have no idea how to get the clone done. I guess it is too error prone to do it file by file and transfer this to the HA installation?

I simply downloaded the branch (ZIP) and copy pasted (replaced) the files of the idm integration: \config\custom_components\idm_heatpump

In the IDM GUI in settings - Photovoltaik - PV Leistung
you see three values Überschuss - PV Leistung - Hausverbrauch
So how are you writing "Hausverbrauch"? Either a negativ Überschuss ;-) or is there a hidding register to write to?

So how are you writing "Hausverbrauch"? Either a negativ Überschuss ;-) or is there a hidding register to write to?

I assume "Hausverbrauch" is calculated by the heat pump as Hausverbauch = PV-Leistung - Überschuss. Possibly it also subtracts it's own usage.

but somehow I cannot use it in the "idm_heatpump.setpower" service.

@geryyyyyy can we please continue this discussion in #40. Otherwise it gets complicated with so many people discussing different things in one thread. See https://github.com/kodebach/hacs-idm-heatpump/pull/40#issuecomment-1783891380

I have temporary the script from simon running. I see value for PV Generation and PV Überschuss, but Hausverbrauch is always 0.
I don't see any further statistics either. Seems this is a functionality they dedicate to known Solar Generation Systems they support natively...

The new release v0.5.0-beta01 now supports writing the PV values. Anyone using #40, please switch back to installing via HACS so you'll get future updates. Everyone else, please update and report any issues.
It would also be helpful, if you could post a list of other sensors which you'd like to set from Home Assistant. Some would be pretty easy to add. Others come with caveats in the Modbus docs from IDM, where I'd like to come up with some kind of safety mechanism first to avoid users (unknowingly) damaging their heat pump by using this integration.


Navigation simply doesn't work

Version
Tell us which versions you are using:

react-native-router-flux v4.0.0-beta.28 (v3 is not supported)
react-native v0.52.0

I am testing this on an Android phone.
Expected behaviour
A simple navigation from one scene to another. I've looked at the example app and I've followed tutorials similar to this one: https://www.tutorialspoint.com/react_native/react_native_router.htm.
Actual behaviour

Steps to reproduce
Here's my code in App.js:
import React from 'react';
import { Dimensions } from 'react-native';
import { Router, Scene } from 'react-native-router-flux';

import Example1 from './components/Example1';
import Example2 from './components/Example2';

const App = () => (
  <Router>
    <Scene key="root">
      <Scene key="example1" component={Example1}/>
      <Scene key="example2" component={Example2}/>
    </Scene>
  </Router>
);

export default App;

Here's my code in Example1.js:
import React from 'react';
import {
  StyleSheet,
  Text,
  View,
  TouchableOpacity,
  StatusBar
} from 'react-native';

import { Actions } from 'react-native-router-flux'

export default class Example1 extends React.Component {
  render() {
    return(
      <View style={styles.container}>
        <StatusBar hidden={true}/>
        <Text>Example 1!</Text>
        <TouchableOpacity onPress={() => Actions.example2()} color="blue">
          Go to example 2
        </TouchableOpacity>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

Here's my code in Example2.js (Only difference is going to the other example):
import React from 'react';
import {
  StyleSheet,
  Text,
  View,
  TouchableOpacity,
  StatusBar
} from 'react-native';

import { Actions } from 'react-native-router-flux'

export default class Example1 extends React.Component {
  render() {
    return(
      <View style={styles.container}>
        <StatusBar hidden={true}/>
        <Text>Example 2!</Text>
        <TouchableOpacity onPress={() => Actions.example1()} color="blue">
          Go to example 1
        </TouchableOpacity>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center',
  },
});

###Other notes
I've tried several iterations of using the Actions keyword. I've done Actions.example1 as per the RNRF Example App, and Actions["example1"].call() as per the API documentation. If anyone could guide me as to what I'm doing wrong, that would be appreciated 😄

Have you tried putting ‘initial’ to any of the example scenes props? Might be irrelevant but worth a try.
Such as:

It mainly tells the router which screen to render first.

Unfortunately, I still have the same error. My App function now looks like this:
const App = () => (
  <Router>
    <Scene key="root">
      <Scene key="example1" component={Example1} initial/>
      <Scene key="example2" component={Example2}/>
    </Scene>
  </Router>
);

I even tried explicitly typing 'initial={true}`, but that doesn't work either.

This is an android-specific issue and there is usually something wrong with your syntax. This is because Android's Yoga is much more strict than IOS when it comes to formatting/syntax - sometimes you will get this error just for having extra whitespace and it can be horrendous to track down.
In the original code you pasted above @syntaxiom , you may have to wrap the text inside your TouchableOpacity in  because Yoga gets very upset about raw text inside a render. Also stray commas, comments inside render, etc all can piss it off as well.
Thats the only thing I can spot that should offer up a yoga node error.

Just want to share what I have come across.
I got exactly the same error and it only happens right after upgrading Gradle to version 3+. Because my app uses react-native-maps and it breaks on android build only. At first the problem was my gradle config was still version 2 (react-native default), so I did as they recommended and this happened.


chore(client): prune backup scripts

ecosystem tests running at https://github.com/prisma/ecosystem-tests/actions/runs/2240280453

Internal Slack thread

so that was needed to publish correctly, as Prisma generate overwrites the index.d.ts and we want the “raw” index.d.ts to be published and make sure that local testing doesn't mess it that up

So very old legacy from publishing the lib locally, and probably not relevant when publishing from CI in our case

From this integration run https://unpkg.com/browse/<EMAIL_ADDRESS>

All good here!


Synch repo cluster-api-provider-ibmcloud with machine-api-provider-ibmcloud

Following actions has been performed
Fork the repo https://github.com/openshift/machine-api-provider-ibmcloud
Clone the forked repo locally
git remote add old https://github.com/openshift/cluster-api-provider-ibmcloud.git
git fetch old
git checkout -b mergebranch
git merge --allow-unrelated-histories old/main
Push the changes

thanks @Karthik-K-N , this looks good for the initial code drop. we've got a bunch of cleanup to do, eg removing the old repo location/name. i think we will need a staff engineer to manually merge this, or i think Joel can next week when he is back.

thanks @Karthik-K-N , this looks good for the initial code drop. we've got a bunch of cleanup to do, eg removing the old repo location/name. i think we will need a staff engineer to manually merge this, or i think Joel can next week when he is back.

ok sure, I have already changed occurence of cluster-api-provider-ibmcloud with machine-api-provider-ibmcloud wherever i have seen.

that's awesome @Karthik-K-N , i'll spend some time reviewing and find out who can merge this for us.


[Themes] Theme Console - ensureReplEnv 1/2 - Storefront Password Prompting

WHY are these changes introduced?

Part of https://github.com/Shopify/develop-advanced-edits/issues/257

WHAT is this pull request doing?
graph LR
    A[Start] --> B{Is the storefront password protected?}
    B -- No --> I[End]
    B -- Yes --> D{Is the --store-password flag provided?}
    D -- No --> E[Prompt the user for a password]
    D -- Yes --> F[Validate the provided --store-password flag]
    E --> G[Validate the prompted password]
    F --> H{Is the password valid?}
    G --> H{Is the password valid?}
    H -- Yes --> I[End]
    H -- No --> E[Prompt the user for a password]

How to test your changes?

Ensure your storefront is password protected via the admin
pnpm shopify theme console --dev-preview
You should see a password prompt
a. Enter a couple of incorrect passwords, then the correct one
pnpm shopify theme console --dev-preview --store-password=<PASSWORD>
a. Try with some valid and invalid passwords.

https://github.com/user-attachments/assets/7473062a-8f3b-4b89-8306-14f86e8f9f1f

Measuring impact
How do we know this change was effective? Please choose one:

[ ] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[x] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x] I've considered possible documentation changes

🎩 and works as expected

WHY are these changes introduced?

Part of https://github.com/Shopify/develop-advanced-edits/issues/257

WHAT is this pull request doing?
graph LR
    A[Start] --> B{Is the storefront password protected?}
    B -- No --> I[End]
    B -- Yes --> D{Is the --store-password flag provided?}
    D -- No --> E[Prompt the user for a password]
    D -- Yes --> F[Validate the provided --store-password flag]
    E --> G[Validate the prompted password]
    F --> H{Is the password valid?}
    G --> H{Is the password valid?}
    H -- Yes --> I[End]
    H -- No --> E[Prompt the user for a password]

How to test your changes?

Ensure your storefront is password protected via the admin
pnpm shopify theme console --dev-preview
You should see a password prompt
a. Enter a couple of incorrect passwords, then the correct one
pnpm shopify theme console --dev-preview --store-password=<PASSWORD>
a. Try with some valid and invalid passwords.

<EMAIL_ADDRESS>
Measuring impact
How do we know this change was effective? Please choose one:

[ ]  n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[x]  Existing analytics will cater for this addition
[ ]  PR includes analytics changes to measure impact

Checklist

[x]  I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x]  I've considered possible documentation changes

Hello sir pls help.. mine keeps saying incorrect password even after I used the right one


Feature request: Allow gotz to remain opened and update continuously

I'd like to keep gotz opened and glance at it without running the command. Ideally this is a flag or configuration value with maybe a sane update interval that can also be configured. I don't need 60 FPS for this, for example, or even every second. Minutes?

On Linux I would simply use watch gotz, but that probably does not work across platforms. This looks interesting and may support it. Will look at it a bit more and see whether it can somewhat easily be done. :relaxed:

Implemented by #2
(enable via --live true)


write timeouts may be handled poorly

And don't seem to be configurable

Added configurable timeouts, the behavior is a bit confusing (presumably due to urllib3).
When uploading a large file to azure with a bad wifi connection, the first error happens after READ_TIMEOUT seconds, all subsequent errors take CONNECT_TIMEOUT seconds.
It seems like each chunk of azure_write_chunk_size has to be uploaded within the timeout period, or else the request will die.
The behavior I observed on windows is that sock.sendall() returns immediately, so it's possible that we could hit the read timeout as a result, since we will be waiting in read for the request to finish, which it will not do in time since we are uploading until we hit the timeout.
Users can at least set the timeouts to be higher to work around this, but maybe it would be better if we increased the timeout on slow connections.


Add missing new line characters

Presently the output is incomplete:
$ ./ety
No input files given, aborting. Use -h to print help.$

Thanks!


Standardize API Responses

Context

Consistency is key for API usage -- if users get a certain result out of one endpoint, they'll likely expect similar results from other endpoints. We should enforce standardization early in our design to improve the user experience.
Additionally, we should design our responses to be potentially extensible -- we may want to add additional components to our responses in the future (for example, deprecation_warning), and we don't want to completely distort the response result if that occurs. It's easier if additional components consist of additional key-value pairs.

Requirements

For 200: OK responses for GET methods returning multiple results, the result should contain three key-value pairs: a message pair describing the response, a count value, describing how many values are returned, and a data value, containing a list of all results. For example:

{
  "message": "Data successfully returned"
  "count": 3
  "data": [{CONTENT_HERE}, {CONTENT_HERE}, {CONTENT_HERE}]
}

For 200: OK responses for GET methods returning single results, the result should contain two key-value pairs: a message pair describing the response, and a data pair containing a dictionary of the result, for example:

{
   "message": "Data successfully returned"
   "data": {CONTENT_HERE}
}

For 200: OK responses for PUT, and DELETE methods, a status message should be contained within a JSON response labeled message, for example:

{
   "message": "Entry successfully updated"
}

For 200: OK responses for POST methods, a the result should contain at least two key-value pairs, a message pair describing the response, and an id pair providing the id of the value added. For example:

{
   "message": "Data request created"
   "id": 513
}

Tests

Existing tests will need updated to check the results are in the provided formats.
To make this easier, create standardized functions for checking that the result is as expected. Alternatively, look into using something like marshmallow to automatically standardize results.

Docs

Swagger documentation will need updated.

Open questions

NOTE: These changes may break some existing logic utilizing endpoint requests.

nice, this is a good idea! especially like anything that makes it show up in PR checks.


Enum value prefixes stripped as PascalCase but should be SCREAMING_SNAKE_CASE

I believe the wrong prefixes are stripped.
The code strips UpperCamelCase...
https://github.com/influxdata/pbjson/blob/bc86f947b462d91f3d4d09252f6190ac79c64beb/pbjson-build/src/resolver.rs#L90-L115
... but protobuf recommendes SCREAMING_SNAKE_CASE

https://protobuf.dev/programming-guides/style/#enums

This should probably be adjusted?

Never mind, did not properly understand the code.
My issue is that enum variants are not changed when serialized... need to look further.


Add building a package with mb2

Please do not hard-wrap the text, otherwise it will be tough to re-wrap it every time it's modified and to read its diff too:)

Please do not hard-wrap the text, otherwise it will be tough to re-wrap it every time it's modified and to read its diff too:)

Really? M-x fill-paragraph is hard?

Please do not hard-wrap the text, otherwise it will be tough to re-wrap it every time it's modified and to read its diff too:)

Did as you wish, even though I think editing and reading the source files is easier when they are wrapped. And the rendered result is the same.


Improve readme

Fixes #109

Added a contributing section
Expanded documentation section
Added table of contents
Improved initial connection class documentation

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Button

Grid system

[ ] text button
[ ] colour variants
[ ] size variants
[ ] disabled
[ ] link (with notice for use case)
[ ] icon


Restart Docker only if restart file exists

High-level description
Only restart Docker if a restart file exists. This allows bootstrap to determine when a restart is necessary while keeping the certificate name the same.
To get this to build, also had to resolve a problem with Calico's build container due to the current image being deprecated (D2IQ-72821).
Corresponding DC/OS tickets (required)

D2IQ-72846 upgrade from 2.1.{0,1} to 2.2.0 stops workloads

Related tickets (optional)

D2IQ-ID JIRA title / short description.

@mesosphere-mergebot test all


Bump libc and openssl-sys crates

libc-0.2.48 is has no support for FreeBSD on archs like powerpc64,
arm64, etc.
openssl-sys-0.9.46 is too old to support LibreSSL 3.x.

Coverage increased (+0.4%) to 40.496% when pulling d9f143bf5d4cf87effae2532b9f2ef0c2be0139d on t6:patch-bump-libc into a563545e4e323da8aa1f3cad50973d4cac131c6a on newsboat:master.

Thank you, @t6!


apiVersion mismatch between last-applied-configuration and manifest causes silent import failure

If you have a resource that appears to be apps/v1 but was last applied with extensions/v1beta1, terraform import fails silently
This came up for me today with a (very old) Deployment but will likely come up again for Ingress
This would be fine if it failed with an error message but it says it imported successfully but terraform state list doesn't have it there.
I suspect that erroring if the lac has a differnt api version to the response resource in https://github.com/kbst/terraform-provider-kustomization/blob/master/kustomize/resource_kustomization.go#L484-L491 might be enough for this edge case

I agree it shouldn't fail silently. I'm not sure about the cause. A diff between the apiVersion in the ID given to the import command and what's in the lastAppliedConfig annotation seems most likely to cause this.
Relying on the annotation is generally a problem with the provider. Linking this here to connect the dots to consider for a future refactor. https://github.com/kbst/terraform-provider-kustomization/pull/89

This issue hasn't had any activity in a long time and the code has since been refactored. I'm closing this issue. Should the issue show up again, we can create a new issue.


[joy-ui][Chip] The default dark mode design seems incorrect

Related page
https://mui.com/joy-ui/react-chip/
Kind of issue
Broken demo
Issue description
Looking at basic demo:

I don't see any background color or border or anything to indicate that this is a chip, this looks like a regular text.
Context
n/a
Search keywords: chip joy text broken

In light mode, it's ok:

Heya @MonstraG, thanks for opening the issue! The here is actually not with the Joy UI Chip component but rather with the docs demo container being a bit too light in dark mode (and the color used is very similar to the Joy UI gray palette); thus the Chip seemingly looks without a background. If you check the very first demo on the Chip page (Introduction demo), you'll see how you can see the Chip's background better as the container background color there is darker.
In any case, I opened the above-linked PR to tone down that container's dark mode color a bit more. :)


Thread safety and segfaults

Go hashmaps are sadly not thread safe, so when you have things like
line 142
		history[pid] = *stat

it is not safe. My app has different monitors running in different threads, I use this pacakge for cpu and memory monitors, and sometimes they collide and I get

Error:

fatal error: concurrent map writes

goroutine 22 [running]: runtime.throw(0x29c1b6, 0x15)

   /usr/lib/go-1.7/src/runtime/panic.go:566 +0x78 fp=0x10632c58 sp=0x10632c4c

runtime.mapassign1(0x268668, 0x10668880, 0x10632cf8, 0x10632d4c)

   /usr/lib/go-1.7/src/runtime/hashmap.go:458 +0x94 fp=0x10632cd8 sp=0x10632c58

github.com/struCoder/pidusage.stat(0x6c30, 0x298086, 0x4, 0x4, 0x0, 0x0)

   go/src/github.com/struCoder/pidusage/pidusage.go:142 +0xc64 fp=0x10632ebc sp=0x10632cd8

github.com/struCoder/pidusage.wrapper.func1(0x6c30, 0x106688a0, 0x0, 0x0)

   go/src/github.com/struCoder/pidusage/pidusage.go:40 +0x4c fp=0x10632ee0 sp=0x10632ebc

github.com/struCoder/pidusage.GetStat(0x6c30, 0x10632f10, 0x0, 0x0)

   go/src/github.com/struCoder/pidusage/pidusage.go:152 +0x6c fp=0x10632ef8 sp=0x10632ee0

cwtch.im/cwtch/server/metrics.(*Monitors).Start.func3(0x1069ebb8, 0x1066a380)

   go/src/cwtch.im/cwtch/server/metrics/monitors.go:37 +0x28 fp=0x10632f0c sp=0x10632ef8

cwtch.im/cwtch/server/metrics.(*monitorHistory).monitorThread(0x1069e800)

   go/src/cwtch.im/cwtch/server/metrics/metrics.go:218 +0xfc fp=0x10632fcc sp=0x10632f0c

runtime.goexit()

This could pretty easily be fixed if you add a global write lock
	writeLock         sync.Mutex
....
writeLock.Lock()
history[pid] = *stat
writeLock.Unlock()

Should fix this issue

added a PR #9 to fix this :)

@dballard
Thanks 👍


replace (run.cancel, run.later) with run.debounce

I wonder if this could also be applied here

🎉 awesome!

The debounce is leaking after the session object has been destroyed. So when you destroy and recreate the container (via an app reset for example) the destroyed session store will keep syncing data and there's no way to break the loop. It will also throw errors if it detects changes because it will attempt to set the content property on a destroyed object (the destroyed internal session).  This bug actually existed before this PR but the PR made it impossible to break the loop in a subclass as the debounced tasks are no longer tracked.
As a result, I believe we need to keep track of these timers (as we were before this PR) and Ember.run.cancel them in a willDestroy hook. However, it seems it's currently not possible to cancel a debounce created by another debounce so going back to run.later and calling run.cancel when destroying may be the most straightforward approach. Thoughts?

Ouch, you're right @teddyzeenny - this should be fixed. Can you create an issue so we can track the problem there and move the discussion there? If there's no way to cancel the debounces now anymore I think you're right and we need to go back to later/cancel.

Sorry for the bad idea😓
Le 2 janv. 2017 12:50, "Marco Otte-Witte"<EMAIL_ADDRESS>a
écrit :
Ouch, you're right @teddyzeenny https://github.com/teddyzeenny - this
should be fixed. Can you create an issue so we can track the problem there
and move the discussion there? If there's no way to cancel the debounces
now anymore I think you're right and we need to go back to later/cancel.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/simplabs/ember-simple-auth/pull/1131#issuecomment-269962750,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABvfZekFUcNl0nJRuungIATPq0ztf66uks5rOORsgaJpZM4LLxk7
.

@sly7-7: no, thanks for your contribution! We'll get it figured out!

@sly7-7 not a bad idea at all. Your PR merely uncovered an already existing issue.


 This should be working fine now.

Awesome work on sentinel tests - they are much more readable now. Merging.

Thanks, continued to improve tests further in the cluster branch by using bundled redis server:

https://github.com/go-redis/redis/blob/c228cc3/Makefile#L8
https://github.com/go-redis/redis/blob/c228cc3/redis_test.go#L169


Retrieve mention scores

How to retrieve mention scores ? Running doc._.coref_scores gives error (Can't retrieve unregistered extension attribute 'coref_scores').

We now also annotate the score in the new release (4.0). See the README for details.


Readme

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@d2424a0). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff            @@
##             main        #3   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?         4
  Lines           ?       398
  Branches        ?         0
========================================
  Hits            ?       398
  Misses          ?         0
  Partials        ?         0

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


existential pattern match

The accepted CIP is the relevant baseline for this PR. WHERE <pattern> we should not have in scenarios. EXISTS( <pattern> ) (not mentioned in the CIP) is probably still best tested in expressions/pattern/Pattern1. The "simple subquery exists" and "subquery exists" functionality described in the CIP should probably go as two features in a new separate category, such as expressions/existentialSubquery/existentialSubquery1 (and .../existentialSubquery2).

Hi Dvir, for further work on this PR, I like to draw your attention to PR #493, which has update to the CIP cited above and should form the basis for this feature here. The CIP update is obviously not merged, yet. Nevertheless, I am relatively confident that it illustrates the main direction of things. It also something you may want to make your colleagues aware of. Comment welcome, of course.

The CIP has been merged.
Further, I think we should rename Pattern1 - Existential Pattern Match into Pattern1 - Pattern predicate to cover what the CIP refers to as <RelationshipsPattern> (that is the name of the corresponding non-terminal in the oC grammar).

Please add at least one scenarios to test the  is allowed in all sizes listed in the CIP.
Please add scenarios "Fail on using pattern in right-hand side of SET", e.g. SET n.prop = (a)-[:REL]->()

this query
MATCH (n) SET n.prop =  head(nodes(head((n)-[:REL]->()))).x
don't fail in neo4j

this query
MATCH (n) SET n.prop = head(nodes(head((n)-[:REL]->()))).x
don't fail in neo4j

That is right and expected. It is a legacy functionality that evaluates a naked pattern to a list. This will be removed in due course of the usual deprecation cycles.

@AviAvni the PR has merge conflicts now. Please locally rebase the underlying branch onto a current master to draw out and fix the conflicts. Thanks.

@hvub done


0.11.0: Documentation release

This issue is collecting everything that's needed to document the 0.11.0 release accordingly. Issues will be split into different issues.
Updates on conduit-site (we could have a feature branch here so we can ship at once)

[x] Update all references of 0.10.0 to 0.11.0 @raulb  🔍 commit
[x] Add more details on persistence definition so includes support to different drivers (see this). @hariso Link to PR

Database implementation for SQLite3 by lyuboxa · Pull Request #1682 · ConduitIO/conduit. Related https://github.com/ConduitIO/conduit/pull/1703

[x] Update Conduit Architecture page to include the Schema service running on a side. @hariso  @raulb

[x] Update architecture diagram. My suggestion is to included below the dotted line
[x] Include definition under Persistence to indicate this separate service.

[x] Add a new page under /docs/features named Schema Registry so it’s listed as a new feature.  @raulb

New page named schema-registry.mdx needs to contain sidebar_position: 6
Stream Inspector needs to be updated to sidebar_position: 7
Needs to mention that it’s possible to persist the schema either in memory or using a different driver.
Mention “Conduit Schema Registry is a service that stores and manages schemas. It is used internally in Conduit to store the schemas of records that are produced and consumed by connectors.”  The schema registry can either be embedded in a Go application or run as a standalone service exposing a REST API that’s compatible with Confluent’s Schema registry https://docs.confluent.io/current/schema-registry/develop/api.html.
schema subject and version are attached to the record metadata so it preserves all types when it comes to structured records.
This builtin schema registry comes out of the box and could be configured to use Confluent’s schema registry: https://github.com/ConduitIO/conduit/pull/1694/files#diff-72a95f6cd4fd2517b43176996ef522e7b86cf4421c352f67e7661881b5db5846R98-R99
Mention default schema type is currently avro [Schemas] Connector SDK: Create and get a schema from Conduit by lovromazgon · Pull Request #1694 · ConduitIO/conduit

[x] Add new metadata fields to Conduit (https://github.com/ConduitIO/conduit-commons/blob/main/opencdc/metadata.go#L47-L59) @raulb  🔍 commit

opencdc.key.schema.subject
opencdc.key.schema.version
opencdc.payload.schema.subject
opencdc.payload.schema.version

[x] Document on https://conduit.io/docs/connectors/building-connectors/developing-source-connectors#source-connector-lifecycle-functions, how to configure the middleware, also indicating how to disable the recently added for schema registry. Here's an example https://github.com/ConduitIO/conduit-connector-s3/pull/525/files#diff-c2c587e9de1acc152a646c08609ac201aa8f5b78494e4ec069d340ad89b2ceb2 @raulb 🔎 commit

Updates on conduit GitHub repository

[x] Update mention to what other persistence options are available when Configuring Conduit (see available drivers) @hariso Link to PR

This shipped yesterday.


Generated documentation is broken

Closure Library website (i.e. https://developers.google.com/closure/library/) points to http://google.github.io/closure-library/api/, which is empty

Looks live to me.
On Jun 4, 2015 3:34 AM, "Dmytrii Shchadei"<EMAIL_ADDRESS>wrote:

Closure Library website (i.e.
https://developers.google.com/closure/library/) points to
http://google.github.io/closure-library/api/, which is empty
—
Reply to this email directly or view it on GitHub
https://github.com/google/closure-library/issues/478.

For me the page is empty :

Do you see any errors in the dev console?  What browser are you using?  It
looks fine in Chrome for me.
On Sat, Jun 6, 2015 at 4:01 AM, Dmytrii Shchadei<EMAIL_ADDRESS>wrote:

For me the page is empty :
[image: screen shot 2015-06-06 at 1 02 28 pm]
https://cloud.githubusercontent.com/assets/946519/8019393/1438d8dc-0c4c-11e5-8edc-9e44ac59c868.png
—
Reply to this email directly or view it on GitHub
https://github.com/google/closure-library/issues/478#issuecomment-109564798
.

Click on the arrow to the right of "types" for some reason it is starting
collapsed for you.
On Mon, Jun 8, 2015 at 5:07 PM, John Lenz<EMAIL_ADDRESS>wrote:

Do you see any errors in the dev console?  What browser are you using?  It
looks fine in Chrome for me.
On Sat, Jun 6, 2015 at 4:01 AM, Dmytrii Shchadei<EMAIL_ADDRESS>
wrote:

For me the page is empty :
[image: screen shot 2015-06-06 at 1 02 28 pm]
https://cloud.githubusercontent.com/assets/946519/8019393/1438d8dc-0c4c-11e5-8edc-9e44ac59c868.png
—
Reply to this email directly or view it on GitHub
https://github.com/google/closure-library/issues/478#issuecomment-109564798
.

@concavelenz It's empty even when uncollapsed and there is a console error

Damn :) That's one of my extensions, which breaks it. In a private mode everything works fine.

Thanks for tracking it down.  Extensions injecting corrupting code is a
continous source of problems for sites that don't have CSP that protect
against it.
On Tue, Jun 9, 2015 at 3:50 AM, Dmytrii Shchadei<EMAIL_ADDRESS>wrote:

Damn :) That's one of my extensions, which breaks it. In a private mode
everything works fine.
—
Reply to this email directly or view it on GitHub
https://github.com/google/closure-library/issues/478#issuecomment-110317063
.

Surprisingly, the reason was http://benvanik.github.io/WebGL-Inspector/


[FEATURE] Add copy text button for both text area

Describe the solution you'd like
Add a copy text button (in the red box given in the image below) so the users can easily copy plain/cipher text.

You can take reference from this StackOverflow question: https://stackoverflow.com/questions/39501289/in-reactjs-how-to-copy-text-to-clipboard

Can I work on this?


Add missing changelog entries for policies included

@davidor could you reference the JIRA issue(s) in the commit msg?


mm_x and mm_y not adjusted when resampling image

Issue summary
tileIterator's dictionary contains mm_x and mm_y which is defined to be "mm_x, mm_y: size of the current tile pixel in millimeters." in base.py. When a different-than-maximum magnification is requested, the mm_x and mm_y do not change accordingly, and it thus denotes the "size of pixel in millimeters for maximum magnification" instead of that of "the current tile"
Current output
When creating a tileIterator for a whole-slide image with 0.2505 microns per pixel (through openslide: slide.properties[openslide.PROPERTY_NAME_MPP_X])
slide = openslide.OpenSlide("path/to/WSI")
print(slide.properties[openslide.PROPERTY_NAME_MPP_X])  # 0.2505

li_slide = large_image.getTileSource("path/to/WSI")
tile_iterator = li_slide.tileIterator(tile_size=dict(width=225, height=225),
                                                  scale=dict(mm_x=0.5e-3, mm_y=0.5e-3),
                                                  region=dict(left=0, top=0, right=region_width, bottom=region_height),
                                                  tile_overlap=dict(x=0, y=0),
                                                  format=large_image.tilesource.TILE_FORMAT_NUMPY,
                                                  resample=PIL.Image.BICUBIC)

we get tiles with a dictionary like:
{
        "x": 11674.0,
        "y": 898.0,
        "width": 224,
        "height": 224,
        "level": 9,
        "level_x": 26,
        "level_y": 2,
        "magnification": 20.040242969658358,
        "mm_x": 0.0002505,
        "mm_y": 0.0002505,
        "tile_position": {
            "level_x": 26,
            "level_y": 2,
            "region_x": 26,
            "region_y": 2,
            "position": 420
        },
        "iterator_range": {
            "level_x_min": 0,
            "level_y_min": 0,
            "level_x_max": 197,
            "level_y_max": 64,
            "region_x_max": 197,
            "region_y_max": 64,
            "position": 12608
        },
        "tile_overlap": {
            "left": 0,
            "top": 0,
            "right": 0,
            "bottom": 0
        },
        "format": "numpy",
        "gx": 11674.0,
        "gy": 898.0,
        "gwidth": 449.0,
        "gheight": 449.0,
        "scaled": 0.5010060742414589,
        "tile_x": 11674,
        "tile_y": 898,
        "tile_width": 449,
        "tile_height": 449,
        "tile_magnification": 40.0
    }

where the important entries to note are:
        "width": 224,
        "height": 224,
        "magnification": 20.040242969658358,
        "mm_x": 0.0002505,
        "mm_y": 0.0002505,
        "tile_width": 449,
        "tile_height": 449,
        "scaled": 0.5010060742414589,
        "tile_magnification": 40.0

Meaning the tile is correctly sampled and is downscaled from magnification 40 (with mm_x=0.2505)  to 20.04 (mm_x=0.0002505/0.50100..=0.0005), yet this is not clearly shown in the dictionary. (Which took me 6+ hours of sanity checks to ensure it was going correctly)
Expected result:
Similarly to magnification, width, height, x, and y, I would expect two entries: one from before and after resampling, e.g. (taking only the small 'important' json from above):
        "width": 224,
        "height": 224,
        "magnification": 20.040242969658358,
        "mm_x": 0.0005,
        "mm_y": 0.0005,
        "tile_width": 449,
        "tile_height": 449,
        "tile_mm_x": 0.0002505,
        "tile_mm_y": 0.0002505,
        "scaled": 0.5010060742414589,
        "tile_magnification": 40.0

Thanks for submitting this.  I'll try to get a PR this week.

One additional note:

It does not only display maximum resolution, it does display the mm_x and mm_y for an exact magnification level correctly
However, when resampled, this is not adjusted

See PR #441.  You'll notice inexact values, so when you ask for 0.0006 mm you'll get results that are slightly different, e.g., 0.00059987.   This should be addressed when #440 is resolved.

Slight variations are acceptable I'd say as indeed we are working with integer tile sizes, so an exact match might not be possible. Thanks for the fix, and the addition of the test in your PR looks nice.


Hard-coded timezone offset used in DWRF readers and writers for Timestamp

Bug description
Today, when writing a Timestamp to file, DWRF TimestampColumnWriter writes two integers: (1) the offset in seconds from the Timestamp to epoch and (2) the nanoseconds of the Timestamp. Before written to file, the seconds offset is subtracted by a hard-coded offset 8 * SECONDS_PER_HOUR (i.e.,  offset for UTC-8).
We observed one problem related to this hard-coded offset when we run aggregation and window fuzzer that verify the result with Presto. As brief context, to get Presto’s result for fuzzer, we start the Presto server via HiveQueryRunner first. The fuzzers then send the query in SQL to Presto and write input vectors to a table file (via TimestampColumnWriter) to be read by Presto directly. However, when there are Timestamp-typed input columns, we see the results from Presto are always 2 hours behind the result from Velox.
I looked into the execution of one iteration in window fuzzer. I found that when a Timestamp is written to file by Velox, its seconds offset was subtracted by 8 * SECONDS_PER_HOUR. On the other hand, Presto server uses a different timezone America/Bahia_Banderas (UTC-6). As a result, the Timestamp received by Presto was adjusted at some moment, and when received by the Presto's window operator, the Timestamp is already 2 hours behind the original Timestamps generated by Velox fuzzer. Finally, Presto sends the query result back to Velox through the REST API directly with no file writing/reading, so the result Timestamp remains 2 hours behind.
In an internal discussion, @zzhao0 pointed out that DWRF doesn't keep any timezone information in file, so it hard-codes a well-known offset (i.e., UTC-8) that all engines reading or writing files of DWRF format must follow. Currently, we know there is a mismatch between Velox and Presto regarding the writing/reading of Timestamp values, but it's unclear whether Velox or Presto, or which part of them, is wrong. A look into Presto's reader behavior would likely be helpful.
System information
N/A
Relevant logs
No response

cc @mbasmanova @Yuhta

CC: @aditi-pandit @majetideepak

Presto seems having the assumption that in memory format is UTC and in DWRF file is local time, which is insane given that files can be copied across time zone but live processes not likely.  But in Velox reader/writer we probably can provide generic mechanism to allow passing in an inlined functor to adjust the timestamp values being read.  Engines can create whatever functors they need from the time zone information.

Likely the Velox implementation of DWRF TIMESTAMP type reading is incorrect. DWRF reader must be offsetting the session (local) timezone and not hard-code UTC-8.
Presto's TIMESTAMP semantics matches TIMESTAMP WITH SESSION TIMEZONE (adjusted to UTC) type.
Velox as a general library must define the semantics of Timestamp type. Is it Timestamp Without Timezone or Timestamp With Session Timezone (adjusted to UTC)? I think it is the later and we might need a new logical type for the former.
I found this blog post helpful about the various TIMESTAMP semantics https://www.databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html

Velox like Arrow will also need a TimestampTz type since Velox vectors can move across timezones.
https://github.com/apache/arrow/blob/main/cpp/src/arrow/type.h#L1664

@majetideepak We do have timestamp with time zone (https://github.com/facebookincubator/velox/blob/main/velox/functions/prestosql/types/TimestampWithTimeZoneType.h) and I think it's better than encoding the timezone in type (Arrow has the tendency to overuse type and result in some serious problems, e.g. encoding & timezone).

I think at type level we are good, it's just in reader we need a customizable converter.  How to interpret the timestamps should be UDF specific, to both keep compatible with Presto, and not to push the insane Presto interpretation to other engines.

CC: @duanmeng


More in-depth camera effects/realism[REQUEST]

Describe the feature you would like to see implemented
When using infinigen, the camera is playing a big role in the generation of the environments. The movement, angle of light caught by the camera/user, etc plays a role in the feel of the environment that has been created. I was wondering if possible, a way to add post processing and realistic camera effects into the generator. Ex, aperture modes, lens fogging/effects, lens stabilization (or lack thereof), color profiles, and general bokeh. This may just be a post processing addition, but for example, in infinigen now, the camera is stable across an arid environment versus a snowy environment. Possibly adding ways to allow the camera to interact with the environment could bolster the variation and 'feel' of generated landscapes.
Thanks!

Thank you for the clarification, must've missed this! For the current tech, and type of code, an 'autofocus' feature wouldn't make the most sense, as this is an artistic tool/rendering bot. I appreciate it!
Great idea with the parent glass pane, this could also be a node that interacts with light, possibly solving the light tracing with the droplets/dust/fog, and possibly even adding more lens effects. Will look into this with Blender,  but also possibly looking into a multi-layer parent node affect, creating an 'artificial' lens in front of the user camera.
Will look through Blender and create a corresponding thread and fork to implement at some point.


localize devops.md

localize devops.md

For anyone's information: The PR #703 supercedes this PR. 😊


Multi consumers, FIFO is absolute for each consumer.

Exception only setBufferStrategy = BufferStrategy.OVERRIDE, override means data can be discarded, no need for FIFO

Close


#83 - Automatically restart the bot

Add bash file for automatically restarting the bot. This is already running every few days via cron. This allows changes to go in, get approved, and merged into main and then picked up automatically without me having to log in to the server to apply them.

NOT letting builds finish - it's just a bash script and doesn't affect running of bot.


Accessory vs Platform API

I want to use a different filename, based on the device unique ID (ZigBee mac address) instead of on the (user changeable!) accessory name.  I managed this by setting the accessory.displayName, but now it also shows the history service (007) under the ID.  I figured I could create the 007 service myself, and fakegato-history would pick it up:
https://github.com/simont77/fakegato-history/blob/8e88a4a24c79b484b1a4acf3a2e7af77256c04ec/fakegato-history.js#L440-L448
However, my platform plugin is recognised as accessory plugin.  Shouldn't line 440 check for getServices() instead of getService()?
https://github.com/nfarina/homebridge/blob/b670ec1036135b0df06094f1738d7c93499c3a39/lib/server.js#L388

@ebaauw When I write that, I was looking at this to determine if the passed object was an Accessory ( Platform V2 API ) or a Service ( Accessory API).  I realize it could be a little more elegant, but for my plugins it seems to work.
https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/Accessory.js#L237

Ok, this would be a differece between platforms with dynamic accessories vs static accessories.  Could we check for either?

Sorry, I cannot help on that, I have only static plugins

Are they recognised as platform or as accessory?  For static plugins you would have getServices() as you don’t have accees to the hap.Accessory object.

They all have getServices()

Ok, so the platform part is meant only for dynamic platforms.


Angular: local files not added / updated

- Do you want to request a feature or report a bug?

Not sure

- What is the current behavior?
I have added Netlify index.html and config.yml to assets folder. The admin/ route works as expected. I am able to post blog article upload images. Images are synced with Github repo but local files are not modified to include the new post or image.
- Please mention your versions where applicable.
Netlify CMS version: 1.9.4
Browser version:

Node.JS version: 8+
Operating System: Windows 10
- Please link or paste your config.yml below if applicable.
backend:
  name: github
  repo: ....some repo link

publish_mode: editorial_workflow

media_folder: "assets/images/uploads"
public_folder: "assets/images/uploads"

collections:
  - name: "blog" # Used in routes, e.g., /admin/collections/blog
    label: "Blog" # Used in the UI
    folder: "assets/posts/blog" # The path to the folder where the documents are stored
    create: true # Allow users to create new documents in this collection
    slug: "{{year}}-{{month}}-{{day}}-{{slug}}" # Filename template, e.g., YYYY-MM-DD-title.md
    fields: # The fields for each document, usually in front matter
      - {label: "Layout", name: "layout", widget: "hidden", default: "blog"}
      - {label: "Title", name: "title", widget: "string"}
      - {label: "Publish Date", name: "date", widget: "datetime"}
      - {label: "Featured Image", name: "thumbnail", widget: "image"}
      - {label: "Rating (scale of 1-5)", name: "rating", widget: "number"}
      - {label: "Body", name: "body", widget: "markdown"}

Closing as stale


[Multi-stage] Allow filter for lookup JOIN

Customize the following 2 rules to not push down filters/transforms for lookup JOIN:

CoreRules.FILTER_INTO_JOIN and CoreRules.JOIN_CONDITION_PUSH: Do not push down filter to right table, but allow pushing down to left table
CoreRules.PROJECT_JOIN_TRANSPOSE: Disable the rule for lookup JOIN

TODO: Allow transpose to left table in CoreRules.PROJECT_JOIN_TRANSPOSE

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

Project coverage is 0.00%. Comparing base (59551e4) to head (4652829).
Report is 1385 commits behind head on master.

:exclamation:  There is a different number of reports uploaded between BASE (59551e4) and HEAD (4652829). Click for more details.
HEAD has 53 uploads less than BASE

Flag
BASE (59551e4)
HEAD (4652829)

integration
7
1

integration2
3
1

temurin
12
1

java-21
7
1

skip-bytebuffers-true
3
0

skip-bytebuffers-false
7
1

unittests
5
0

unittests1
2
0

java-11
5
0

unittests2
3
0

integration1
2
0

custom-integration1
2
0

Additional details and impacted files
@@              Coverage Diff              @@
##             master   #14523       +/-   ##
=============================================
- Coverage     61.75%    0.00%   -61.76%
=============================================
  Files          2436        3     -2433
  Lines        133233        6   -133227
  Branches      20636        0    -20636
=============================================
- Hits          82274        0    -82274
+ Misses        44911        6    -44905
+ Partials       6048        0     -6048

Flag
Coverage Δ

custom-integration1
?

integration
0.00% <ø> (-0.01%)
:arrow_down:

integration1
?

integration2
0.00% <ø> (ø)

java-11
?

java-21
0.00% <ø> (-61.63%)
:arrow_down:

skip-bytebuffers-false
0.00% <ø> (-61.75%)
:arrow_down:

skip-bytebuffers-true
?

temurin
0.00% <ø> (-61.76%)
:arrow_down:

unittests
?

unittests1
?

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests
JS Bundle Analysis - Avoid shipping oversized bundles


several improvements for providers

Fix Scaleway and Metaldata always printing to stdout
Capitalize provider names and add missing vmware
Introduce timeout function for Packet

Signed-off-by: Itxaka<EMAIL_ADDRESS>

cc @davidcassany :)


Add a helper extensions for setting up authentication with Azure AD

We should provide some extensions that simplify setting up authentication with Azure AD for both web apps and web APIs. Here is what the templates current do:
https://github.com/dotnet/templating/tree/rel/vs2017/3-Preview2/template_feed/Microsoft.DotNet.Web.ProjectTemplates.2.0/content/StarterWeb-CSharp/Extensions/AzureAd
https://github.com/dotnet/templating/tree/rel/vs2017/3-Preview2/template_feed/Microsoft.DotNet.Web.ProjectTemplates.2.0/content/WebApi-CSharp/Extensions/AzureAd
See also #1213 and #1212

@vibronet

Pretty much what I suggested in November when the AzureAD-specific/non-standard telemetry stuff was added directly in IdentityModel:
https://github.com/aspnet/Security/issues/1035#issuecomment-260133984
https://github.com/aspnet/Security/issues/1035#issuecomment-261291374

@danroth27 AzureAdOpenIdConnectOptionsSetup has code that looks intended to be customized.

Well customers can just tweak the resulting options with a normal services.Configure<OpenIdConnectOptions> instead of editing the setup class too

Right, all the places where we want to point customers to customize the code we would recreate in the template using a call to services.Configure<OpenIdConnectOptions>

@ajcvickers @Eilon @muratg
@HaoK I believe this should be assigned to you, correct? Are you going to be able to get to this by EOW?

@danroth27 now that Azure AD is going to have its own OIDC extension/wrapper, is moving the non-standard/implementation-specific "telemetry" stuff from IdentityModel to this new helper something you could consider?

@vibronet @Tratcher @brentschmaltz
@PinpointTownes I'm not familiar with the "telemetry" stuff you're referring to. Adding some folks who probably have more context.

@danroth27 here's the feature in question: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/pull/529/files
It was discussed here: https://github.com/aspnet/Security/issues/1035.

@danroth27 now that we are down to 2-3 files, are we ok with this living in the template for preview 2?  The AzureAd/B2C Options concept is just a template concern, and the OptionsInitialize (which we'll need to rename to PostConfigure once the Options PR is in), is pretty simple (sets authority using the Azure options).  And you wanted the other events code in the template anyways


Mock run of new (proposed) SOP noctua-model replacement and updates

This is to be a standing ticket to support and discuss mock runs of current and proposed SOPs for https://github.com/orgs/geneontology/projects/87 . The reason to consolidate is to 1) make it look more like how it will be run in the future and 2) prevent the proliferation of expensive branches of noctua-models. Currently, we'll be testing:

replaced_by ontology updates
relations updates (i.e. https://github.com/geneontology/minerva/pull/478
in-place sparql updates (most recently, to change purls back to CURIEs)

Replaces #479 and #476 .

@vanaukenk It would be good to decide on a standard commit message for relation updates.

@balhoff In your example given at https://github.com/geneontology/minerva/pull/478/files#diff-aefb43779e951b6f961416f1195b5d9b753eca8a12a29f64a7a2cd8fb432e63dR226, you have a file class-replacements.tsv. where/what is this file? Is this for future use?

@kltm I'm thinking that it might be useful to have a generic commit message for any changes that are not made using a 'replaced by' tag in an ontology.
How about:  "Automated change YYYY-MM-DD: CURIE:xxxxxxx updated to CURIE:yyyyyyy" ?

@vanaukenk We can't really have variables in a git commit message in this case as it is for the entire code tree at that moment in time, rather than individual files, so individual CURIEs would not make much sense.

@kltm - I thought you were referring to the actual comment in the models (where I'm still wondering if we should use 'replaced by' for these relations updates since that has a specific meaning in ontologies.. @balhoff - any thoughts?)
For a git commit message, then, how about:
'Updating RO relations as specified in noctua-models/migration/replace_relations.tsv'
I am open to suggestions here, if there's something you and @balhoff think would be more informative or appropriate.

@vanaukenk Sounds good to me. I think my only comment would be something a step outward: https://github.com/geneontology/noctua-models/pull/233#issuecomment-1125431640

Thank you for the clarification @balhoff ; I've updated the SOP.
The changes connected with just a relations change are available here: https://github.com/geneontology/noctua-models/commits/issue-minerva-483-test-updates

@vanaukenk A replaced_by changes set is available here: https://github.com/geneontology/noctua-models/commits/issue-minerva-483-test-updates
(I'm mostly sure I did this right, but there was some fiddliness.)


fix: ensure peggo version cmd works correctly

closes: #207

Do not merge until changelog is updated on main

Do not merge until changelog is updated on main

Whoops! Sorry, I thought you meant to update it after this PR gets merged


Updates to name-load dialog

Update name load instructions to explain how to work with multiple classes

Yeah, I'll put them here since they're all related


input text wont appear on Windows phone

Hi i m using Windows phone 8.1 with Internet Explorer. When using mini.css the user input wont appear even if it is here.
Please could you tell me if there is a fix for this ?
This bug also exists when using the login template on http://minicss.org using Windows Phone 8.1

IE is not officially supported for any of the distributed flavors. There could be a fix or some workaround, which will not be patched into the source code, but that you could apply manually. For a fix, however, I would need more information, such as the browser version and a screenshot of the problem.
I would strongly advice you to not use mini.css with legacy browsers such as IE, as it will most definitely cause some issues and you will have to identify, understand and patch them mostly on your own. Develop on and for supported browsers only.

Hi Angelos Chalaris and thank you for your prompt answer :D !
I temporary solved this issue by commenting the lines 734-735 of the file mini-dark.css
line 734 /*-webkit-flex-basis: 0px;
line 735   flex-basis: 0px; */
At that time i also commented the lines 767 and 768 of mini-dark.css
Thank you for your work.

That sounds like a decent enough fix, good job! Bear in mind that this is a problem with Flexbox, upon which mini.css heavily relies. You might find more bugs like this, especially in the card and grid modules.
I will be closing this issue, based on the fact that your problem is resolved. Have a nice day!


add proper read support for time field options

The runtime requires that in all points, the field time must either be a valid JuttleMoment or not present.
To support various back end adapters in handling time fields, the parseTime utility function should be extended to support the following options and semantics.

timeField - Name of the field in the original data that, if present, is expected to contain a valid time. The default is time.
timeRenameField - If the original data contains a field named time, this specifies the name of the field in the resulting juttle point that should contain a copy of the time field.

For any point in which the resulting 'time' field cannot be converted into a valid Juttle time, the runtime must log a warning and not process the data point.
When the timeField is not time, the original field should be removed from the point before emitting it to juttle.
For example, given the following data point:
{time: "2015-01-01T00:00:00.000Z", other: "2015-02-01T00:00:00.000Z", value: 10}

Then read with no options should produce:
{time: "2015-01-01T00:00:00.000Z", other: "2015-02-01T00:00:00.000Z", value: 10}

read -timeField 'other' should produce:
{time: "2015-02-01T00:00:00.000Z", value: 10}

read -timeField 'other' -timeRenameField 'origTime' should produce:
{time: "2015-02-01T00:00:00.000Z", origTime: "2015-01-01T00:00:00.000Z", value: 10}

Given a data point of:
{time: "invalid", other: "2015-02-01T00:00:00.000Z", value: "abc"}

Then read with no options should produce:
Warning: the time field must contain a number or a string representing time.

Then read -timeField "value" with no options should produce:
Warning: the time field must contain a number or a string representing time.

read -timeField 'other' should produce:
{time: "2015-02-01T00:00:00.000Z", value: "abc"}

read -timeRenameField 'badtime' should produce:
{badTime: "invalid", other: "2015-02-01T00:00:00.000Z", value: "abc"}

read -timeField "other" -timeRenameField 'badtime' should produce:
{badTime: "invalid", time: "2015-02-01T00:00:00.000Z", value: "abc"}

Warning: the time field must contain a number or a string representing time.

or Date?

:+1:
Is there a similar issue in the works for -timeField behavior in write?

or Date?
Good point

Is there a similar issue in the works for -timeField behavior in write?

No but there should be.

For example, given the following data point:
{time: "2015-01-01T00:00:00.000Z", other: "2015-02-01T00:00:00.000Z", value: 10}
read -timeField 'other' should produce:
{time: "2015-02-01T00:00:00.000Z", value: 10}

Should this case also produce a warning if there is a value for pt.time? Maybe "Warning: overwriting value of time field with {{info.field}} field"

Yeah -- that makes sense. Though how would the user suppress that warning?
On Fri, Feb 5, 2016 at 2:15 PM, Vlad Vega<EMAIL_ADDRESS>wrote:

For example, given the following data point:
{time: "2015-01-01T00:00:00.000Z", other: "2015-02-01T00:00:00.000Z",
value: 10}
read -timeField 'other' should produce:
{time: "2015-02-01T00:00:00.000Z", value: 10}
Should this case also produce a warning if there is a value for pt.time?
Maybe "Warning: overwriting value of time field with {{info.field}} field"
—
Reply to this email directly or view it on GitHub
https://github.com/juttle/juttle/issues/339#issuecomment-180593868.

--
Michael Demmer
Jut - CTO / VP Engineering
<EMAIL_ADDRESS>

What is the status of this now that #315 is merged?

Closing this now that #315 is merged. If a need for timeRenameField comes up we can always revisit the issue.


[WEB] Splashscreen is moving to left right before showing the first app view

Hi !
I have a strange behavior that I can't fix with my web splashscreen. Right before showing the first app view, it moves to left.
https://user-images.githubusercontent.com/44947503/212347844-d197e2f0-b26e-4eca-a77e-1672e0709648.mov
Steps to Reproduce
Create a new project, add an image in web/images folder, add a splashscreen in index.html using the image, in

Run the app
My flutter doctor :
[✓] Flutter (Channel stable, 3.3.10, on macOS 12.5.1 21G83 darwin-arm, locale fr-FR)
    • Flutter version 3.3.10 on channel stable at /Users/appspanel/Documents/development/utils/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 135454af32 (4 weeks ago), 2022-12-15 07:36:55 -0800
    • Engine revision 3316dd8728
    • Dart version 2.18.6
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at /Users/appspanel/Library/Android/sdk
    • Platform android-33, build-tools 32.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A400
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] Connected device (4 available)
    • Android SDK built for arm64 (mobile) • emulator-5554                        • android-arm64  • Android 10 (API 29)
      (emulator)
    • iPhone 14 (mobile)                   • A826E6DA-84BD-47E4-9486-67D7197A11FE • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-16-0 (simulator)
    • macOS (desktop)                      • macos                                • darwin-arm64   • macOS 12.5.1 21G83
      darwin-arm
    • Chrome (web)                         • chrome                               • web-javascript • Google Chrome 109.0.5414.87

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Thanks for your help

@Velliane thanks for your report. Can you try checking Example: Display a progress indicator  or Gallery app index.html if it can help?

Thanks a lot @huycozy ! it actually helped  👍

@Velliane Glad it can help you.
Given your last message, I feel safe to close this issue, if you disagree please write in the comments and I will reopen it. Thank you!


sr-only content should not be selectable

:wave: I think this is a bug, but willing to admit that I'm by no-means an accessibility expert.
When adding screen-reader content with sr-only, if I select over the content it ends up on my clipboard.
You can see an example from the TailwindUI Stats section:

  <svg class="self-center flex-shrink-0 h-5 w-5 text-green-500" fill="currentColor" viewBox="0 0 20 20">
    <path fill-rule="evenodd" d="M5.293 9.707a1 1 0 010-1.414l4-4a1 1 0 011.414 0l4 4a1 1 0 01-1.414 1.414L11 7.414V15a1 1 0 11-2 0V7.414L6.707 9.707a1 1 0 01-1.414 0z" clip-rule="evenodd"/>
  </svg>

    Increased by

  5.4%

If you select the percentage, sometimes you'll end up with "Increased by5.4%" in your clipboard depending on how much you drag. There is no visual indicator that you have extra text when dragging.
I can work around this by adding select-none but should sr-only be forcing that style? It was unexpected behavior to me.

I don't think this should be the default.
In many cases sr-only text should be selectable as that's what the SR reads out. I would argue even the given example should be selectable.
It might be a bit inconvenient for other users, but otherwise would hinder accessibility for the visually impaired.

I don't think this should be the default.
In many cases sr-only text should be selectable as that's what the SR reads out. I would argue even the given example should be selectable.
It might be a bit inconvenient for other users, but otherwise would hinder accessibility for the visually impaired.

Thanks -- I was not sure what the expectation for a SR would be, so appreciate the input.

It could also be prevented by adding proper ARIA labels to the SVG:
<svg role="img" aria-label="Increased by" class="..."

With this approach you don't need the extra span with sr-only, your icon is correctly announced and you don't have extra content to focus/select.


Support for Literate CoffeeScript (.litcoffee)

Reference:

http://coffeescript.org/#literate
http://news.ycombinator.com/item?id=5277916

+1 on litcoffee support -- I'll be trying to use @sjorek's fork. Is there some reason it hasn't been included?

dang, it's been years!  still no progress on this?  is this project dead?  should I taker over?

README says it is dead and if you want to take over to shoot the author an e-mail.


Try Coral Stick accelerator or similar

Saturnino told me that he has some Coral stick TPU accelerator and that we should try it out. Let's set this to lowest priority because I don't fully see the use case and I think we would be very limited in terms of code, I think they only accept tflite models.

@adriangarciia could you check if it works?

Yes, I have integrated the coral into Friagte and it does work, the inference speed dropped significantly by at least 90%

Can you upload it to the repo?