Minor change of logging level

When connecting, it's quite common for the first join() attempt to fail and a message at the error level to be generated. The situation is non-fatal though, generating a spurious error in the logs.
Many deployments generate devops notifications on any error, thus reducing this to warning is prudent.

Thanks!


Fix image build

Our image builds are failing:
Step 11/14 : COPY --from=build /build/Public /run/Public
failed to export image: failed to create image: failed to get layer sha256:cfdb1e3e6d01d4fd1cc18081c3a68357b719d0232fd5d48dae62c09eb00f8b04: layer does not exist

There wasn't any code change around how we're building our images that could have triggered this. What I suspect is that the docker version on lb1 & lb2, which I updated a week ago or so, and which are building our images, caused this issue.


SSL

The website that I am using to connect to the socket server uses SSL. How can I do this?

Good question. It isn't a design feature right now. We use haproxy to
terminate SSL before the web-socket server. We are interested in playing
with the TLS work that @drawaes has done for "pipelines", but that would be
a radically different architecture, think "son of NetGain". So for now,
your best bet AFAIK is: terminate ahead of the server.
On Sat, 14 Apr 2018, 21:24 Terry Phillips<EMAIL_ADDRESS>wrote:

The website that I am using to connect to the socket server uses SSL. How
can I do this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/NetGain/issues/20, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsKJb9NJtkH8aqsMWn4CmQMpalgyZks5tolr9gaJpZM4TVNmc
.

Ah, ok. I am on windows server so that may be a bit hard. Thanks for the info though.

It would be great to understand how you did that! Btw, thanks for this library and so many others that you have open sourced. I am a huge user/proponent of dapper and stackexchtange.redis :)

Hey @mgravell I've sucessfully set up haproxy to terminate SSL before the websocket server, but I have this problem where now my websocket server logs the IP Address the proxy is binded to.
I've read that HAProxy can send a header to the websocket server containing the original, remote IP that made the request. But is there any way of reading the request headers with NetGain?
Do you log remote IP Addresses on your websocket servers? How do you do so.

@devMidgard Unfortunately we don’t have this case - the volume of websocket traffic in play is too large to log reasonably, so it’s just not a case we hit. In our case, sockets are also secondary and admittedly not as critical to page function as other places

Good question. It isn't a design feature right now. We use haproxy to terminate SSL before the web-socket server. We are interested in playing with the TLS work that @Drawaes has done for "pipelines", but that would be a radically different architecture, think "son of NetGain". So for now, your best bet AFAIK is: terminate ahead of the server.
…
On Sat, 14 Apr 2018, 21:24 Terry Phillips, @.***> wrote: The website that I am using to connect to the socket server uses SSL. How can I do this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20>, or mute the thread https://github.com/notifications/unsubscribe-auth/AABDsKJb9NJtkH8aqsMWn4CmQMpalgyZks5tolr9gaJpZM4TVNmc .

Do you have a working example of how i can use HAProxy to terminate SSL and then forward to netgains via websocket?

Good question. It isn't a design feature right now. We use haproxy to terminate SSL before the web-socket server. We are interested in playing with the TLS work that @Drawaes has done for "pipelines", but that would be a radically different architecture, think "son of NetGain". So for now, your best bet AFAIK is: terminate ahead of the server.
…
On Sat, 14 Apr 2018, 21:24 Terry Phillips, @.***> wrote: The website that I am using to connect to the socket server uses SSL. How can I do this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#20>, or mute the thread https://github.com/notifications/unsubscribe-auth/AABDsKJb9NJtkH8aqsMWn4CmQMpalgyZks5tolr9gaJpZM4TVNmc .

Do you have a working example of how i can use HAProxy to terminate SSL and then forward to netgains via websocket?

Here's the frontend/backend snippets for our HAProxy config to terminate SSL for our NetGain WSS connections. The backend port should match your NetGain WS port where as the frontend port can be anything you like (that's what the clients would connect to):
frontend websockets-ssl-in
	mode http
	log global
	bind *:{{ PORT}} ssl crt /etc/ssl/mycert.pem alpn h2,http/1.1 crt /etc/ssl/mycert.pem alpn h2,http/1.1

	default_backend websocket_backend

backend websocket_backend
	mode http

	# fetch websocket headers
	acl hdr_connection_upgrade hdr(Connection)                 -i upgrade
	acl hdr_upgrade_websocket  hdr(Upgrade)                    -i websocket
	acl hdr_websocket_key      hdr_cnt(Sec-WebSocket-Key)      eq 1
	acl hdr_websocket_version  hdr_cnt(Sec-WebSocket-Version)  eq 1

	# deny request for invalid websocket headers
	http-request deny if ! hdr_connection_upgrade ! hdr_upgrade_websocket ! hdr_websocket_key ! hdr_websocket_version

	server my_ws_server {{ IP }}:{{ PORT }} weight 1 maxconn 30000 check inter 30s # heath check every 30s


The package libgcc (GNU Compiler Collection, version 12.3.0) does not seem to be working as expected

I installed it by adding it to my configuration.nix file.
After rebuilding (sudo nixos-rebuild switch), cargo run (A rust command that needs this package did not work)
gcc --version and 'which gcc' returned no results.
I replaced libgcc in my configuration with the package libgccjit
This one works as intended.

This has nothing to do with nixos-search but you probably want gcc, not libgcc.


How did you manage to add tags/labels to your repository?

(Sorry, this is rather off-topic, I guess)
Even after googling and reading the GitHub documentation, I did not find out, how you managed to do this:

I.e. your repository seems to have some kind of "tags"/"labels" associated.
My question:
Could you please tell me how this is possible for my own GitHub repositories?

Just figured out:

Either this button is new or I never really saw it.
Sorry for polluting your Issues list.


PHPStan type improvements

A lot has changed in the PHP world when it comes to typing (for the better!)
Running PHP Stan level 6 is the default requirement for PHP.Gt repositories now, and this shows some glaring gaps in the static analysis when it comes to typing.
Fix fix fix!

This is now implemented.


parser: support partition in table hint

What problem does this PR solve?
parser part of https://github.com/pingcap/tidb/issues/17113
Check List
Tests

Unit test
Integration test

Code changes

Has exported function/method change
Has exported variable/fields change
Has interface methods change

Side effects

Possible performance regression
Increased code complexity

Related changes

Need to cherry-pick to the release branch

Unit test is failing.


[ARM/Thumb2] Multi-register struct returns use bitops to retrieve fields instead of retrieving the fields directly

Describe the bug
Multi-register struct returns do not use field names and instead use bitops to retrieve fields.
To Reproduce
Given this Thumb2 assembly:
        0801679e f7 f7 63 fe     bl         getslidedelta                                    vec2 getslidedelta(void)
        080167a2 28 77           strb       r0,[r5,#0x1c]
        080167a4 69 77           strb       r1,[r5,#0x1d]

where the function signature for getslidedelta is set to return a struct vec2 with fields x: uint32_t, y: uint32_t in registers r0, and r1, respectively, the decompiler provides this output:
    vec2 vVar2;
    // lines omitted
    vVar2 = getslidedelta();
    unaff_r5->slidex = (uint8_t)((ulonglong)vVar2 >> 0x20);
    unaff_r5->slidey = SUB81(vVar2,0);

Expected behavior
The decompiler gives the following output:
    vec2 vVar2;
    // lines omitted
    vVar2 = getslidedelta();
    unaff_r5->slidex = (uint8_t)vVar2.x;
    unaff_r5->slidey = (uint8_t)vVar2.y;

Environment (please complete the following information):

OS: macOS 12.2.1
Java Version: 17.0.1
Ghidra Version: 10.1
Ghidra Origin: official ghidra-sre.org distro

This is addressed by 31b30adf2dfdd2688cc0e4e7cd01d125fc27c45b


oss-directory: Automatic Contract validation

Describe the feature you'd like to request
When a contract is added to oss-directory we should validate the input.
Describe the solution you'd like
In the future, the majority of contracts will be added via add_deployer but there will still be cases of contracts that may be manually added. For instance, some contracts (like ethereum-attestation-service) are included in the GENESIS block. Others are deployed via a deterministic deployer contract.
When a new contract is added, we should:

validate that is not an EOA
validate that it does not have an EOA deployer that belongs to another project
lookup the contract name, if it has one

Describe alternatives you've considered
N/A

Decomposition of #1034

Closed with https://github.com/opensource-observer/oss-directory/pull/232


Godot 4.2 is unable to preload resources that DO exist.

Tested versions
This issue did not occur before i upgraded to 4.2.
System information
Linux Mint on GD 4.2 stable
Issue description
When attempting to instantiate a scene through code, you first have to preload it, but for some reason godot is saying that it does not exist:
extends Node2D

# Called when the node enters the scene tree for the first time.
func _ready():
	var roomnum = randi() % 3

	var rooms = [preload("res://scenes/rooms/emptyrooms/Empty1.tscn"), preload("res://scenes/rooms/emptyrooms/Empty1.tscn"), preload("res://scenes/rooms/emptyrooms/Empty3.tscn")]

	var dospawn = rooms[roomnum].instantiate()
	add_child(dospawn)
	print(roomnum)

Steps to reproduce
Download the project, open it, and debug run it.
Minimal reproduction project (MRP)
project.zip

The error message is really cryptic and unhelpful. It seems the issue is due to a loading cycle. On base.tscn you load the inst.gd script with loads that same scene:
extends Node2D

# Called when the node enters the scene tree for the first time.
func _ready():
	var baller = preload("res://base.tscn")
	add_child(baller)

If you comment/remove that _ready function, the scene loads normally again.

This issue did not occur before i upgraded to 4.2.

Did you upgrade from any 4.x version, or earlier from 3.x?

The error message is really cryptic and unhelpful. It seems the issue is due to a loading cycle. On base.tscn you load the inst.gd script with loads that same scene:

im sorry im not really sure what details i need to provide.

extends Node2D

# Called when the node enters the scene tree for the first time.
func _ready():
	var baller = preload("res://base.tscn")
	add_child(baller)

well im a dumbass, the code is incorrect.

If you comment/remove that _ready function, the scene loads normally again.
ill... try that...

im sorry im not really sure what details i need to provide.

I meant that the error Godot gives is not clear; it wasn't about your report :slightly_smiling_face:
I don't know if your scenario is supposed to work or not, but since you mentioned that it has happened since you ported this code to 4.2, this might be a regression. What was the previous Godot version you were using?

im sorry im not really sure what details i need to provide.

I meant that the error Godot gives is not clear; it wasn't about your report 🙂
I don't know if your scenario is supposed to work or not, but since you mentioned that it has happened since you ported this code to 4.2, this might be a regression. What was the previous Godot version you were using?

the project is only from 4.1, but i only got errors when i upgraded to 4.2, incidentally. sometimes godot will say the scenes are corrupted when i try to open them for some reason

Hi.
I've got the same issue on v4.2.stable.official [46dc27791]
With the "preload" line, an error raises when Godot starting. Line 140 of "bug.tscn" references the "bug.gd" script.

If I comment the line, error message disappear.

Changing preload for load works well. Seen in this other reported issue
https://github.com/godotengine/godot/issues/85081#issuecomment-1847899547

Using the MRP, I have found that you are preloading base.tscn inside base.tscn and adding it as a child without instantiating it.
from the variable name i think you just wants to add the other scene ball.tscn to the base.tscn as a child, so this code should work fine without raising any issues.
Update the inst.gd script and reload the project from Project menu.
func _ready():
	var baller = preload("res://ball.tscn").instantiate()
	add_child(baller)

If I'm wrong and you want to preload the same scene inside itself, then you can try other methods like self.duplicate() for example, since the packed scene is already loaded.


[Suggestion] New Flag

Please make a flag which disable falling blocks gravity example concrete powder

What would be your use care for this?


Symbols missing from shared object.

Hello.  Thanks for a fun project, well done!
I'm trying out the develop branch, after building successfully I check libsfizz.so and it does not contain any of the symbols found in libsfizz.a.
I'm not sure if C++ differs from C when it comes to linking, but I think the symbols of an archive (static library) are only included when linking if they are actually used by whatever you are linking. I'm not sure if this is the problem, but maybe.
I think you can use -Wl,--whole-archive static_libs.a -Wl,--no-whole-archive to include everything. There's also a cmake recipe for creating archives and shared objects from the same set of objects:
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) # Handy when building on windows

add_library(library_objects OBJECT ${source_files})
set_target_properties(library_objects PROPERTIES POSITION_INDEPENDENT_CODE 1) # Linux

add_library(library_static STATIC $<TARGET_OBJECTS:library_objects>)
target_link_libraries(library_static PUBLIC we_need_this_too.a)
if(BUILD_SHARED)
    add_library(library_shared SHARED  $<TARGET_OBJECTS:library_objects>)
    target_link_libraries(library_shared PUBLIC we_need_this_too.a)
endif()

Linking with the other static libraries (absl) should then work for the symbols used by any of the objects, but I'm not sure. May be totally wrong here.

No you are right apparently there are indeed no symbols in the shared libraries (and too many symbols in the LV2 plugin...). I will try to sort this out !


Regularizer on LSTM

Hi all,
I try to put l2 on LSTM, however, I got the error. " WeightRegularizer' object has no attribute 'p'"
    model = Sequential()
    model.add(Embedding(input_dim=n_symbols, output_dim=args.wvecDim,
        mask_zero=True, weights=[wordEmbeddings.T],input_length=maxlen))
    model.add(LSTM(output_dim=args.wvecDim, return_sequences=False,
        input_shape=(maxlen, args.wvecDim)))
    model.layers[-1].regularizers = [l2(1e-4)]

Traceback (most recent call last):
  File "main_keras.py", line 189, in <module>
    train_fn, val_fn, predict_proba= build_network(args, wordEmbeddings)
  File "main_keras.py", line 145, in build_network
    model.compile(loss='categorical_crossentropy', optimizer=optimizer)
  File "/Users/peng/Develops/keras/keras/models.py", line 390, in compile
    train_loss = r(train_loss)
  File "/Users/peng/Develops/keras/keras/regularizers.py", line 28, in __call__
    loss += T.sum(abs(self.p)) * self.l1
AttributeError: 'WeightRegularizer' object has no attribute 'p'

Is it cause by below line
model.layers[-1].regularizers = [l2(1e-4)]

I finally figured out I need to set params manually
model.layers[-1].regularizers[-1].set_param(l_lstm_1.layers[-1].get_params()[0][0])


Bug report (dev's ask me to do this tho)

Device information
Android version: 10 (SDK 29)
Android build ID: JEF-N29 <IP_ADDRESS>(C301E7R3P2)
Device brand: HUAWEI
Device manufacturer: HUAWEI
Device name: HWJEF
Device model: JEF-NX9

Neko version: <IP_ADDRESS> (standard, 3f51090, 132, 2021-11-28T19:29:48.420474)
Android phone & version: 10 (SDK 29)

Steps to reproduce
Refresh the manga list by hold and dragging down
Expected behavior
The manga is updating
Actual behavior
No load/update
Other details
neko_crash_logs.txt

Fixed in <IP_ADDRESS>


encoding/asn1: correctly parse GeneralizedTime

Fixes #28897
Implicitly tagged fields that have the struct field tag "generalized" should parse incoming data as a GeneralizedTime

CLA Signed.


change pinyin2 to pinyin

pinyin2 (https://github.com/princetoad/pinyin.js) is actually forked from pinyin (https://github.com/hotoo/pinyin).
If you check these 2 project, you can find pinyin is more activity and most recent change happens. So why not change to pinyin?

I can't remember the exact reason why the fork was originally selected. Perhaps it was better-maintained at the time of original implementation.
The original repo is definitely looking far healthier, thank you for this suggestion. I'm happy to accept a PR with the change if you're comfortable doing this. If so, feel free to add any test cases that would have failed with pinyin2 but that will work with pinyin.

Understand, I'm happy to do it. :)

Great.
https://github.com/lovell/limax/pull/6#issuecomment-121947350


Feature Request: Automatically download NWjs without CLI commands

Since this project is inspired by Electron-Prebuilt it'd be fantastic if I could just depend on this in my project and spawn NWjs directly in my app to start it without specifying anything else.
For instance, let's say my project depends on this: I run an npm install and npm start and my app spawns NWjs and my app starts up. Notice I did not have to specify any CLI commands to download a specific version of NWjs before I ran npm start and I didn't first install this into global.
This is the primary feature (I miss here) I use when I am using Electron-Prebuilt because it takes away any of the extra knowledge or user intervention to run your app in Electron. All dependencies are just ordinary npm modules and an npm install takes care of all the heavy lifting.

Yes, this is quit a neat feature of electron-prebuilt, intend to implement!

What about this? https://github.com/nwjs/npm-installer
"scripts": {
  "start": "nw app"
},
"devDependencies": {
  "nw": "=0.12.3"
}

Or maybe using nwjs?
"scripts": {
  "postinstall": "nw install 0.12.3 && nw use 0.12.3",
  "start": "nw app"
},
"devDependencies": {
  "nwjs": "*"
}

This looks good! Thanks.


make forge_socket error

when I make forge_socket module, errors pop up
[root@bigdata forge-socket]# make
cc -I../../lib/ -I/lib/modules/forge_socket -Wall -g -O2 -fstack-protector-all -                                            -param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -fPI                                            C  -lpcap -levent -levent_extra -lm -Wl,-Bsymbolic-functions -Wl,-z,relro,-z,now                                              forge-socket.c   -o forge-socket
/tmp/cckp267K.o: In function print_status': /home/zmap/examples/forge-socket/forge-socket.c:70: undefined reference to even                                            t_new'
/home/zmap/examples/forge-socket/forge-socket.c:74: undefined reference to log_                                            info' /tmp/cckp267K.o: In function main':
/home/zmap/examples/forge-socket/forge-socket.c:393: undefined reference to log                                            _init' /home/zmap/examples/forge-socket/forge-socket.c:406: undefined reference to buf                                            ferevent_socket_new'
/home/zmap/examples/forge-socket/forge-socket.c:411: undefined reference to eve                                            nt_new' /home/zmap/examples/forge-socket/forge-socket.c:484: undefined reference to log                                            _info'
/home/zmap/examples/forge-socket/forge-socket.c:442: undefined reference to log                                            _init' /home/zmap/examples/forge-socket/forge-socket.c:489: undefined reference to log                                            _info'
/home/zmap/examples/forge-socket/forge-socket.c:397: undefined reference to log                                            _fatal' /home/zmap/examples/forge-socket/forge-socket.c:460: undefined reference to log                                            _error'
/home/zmap/examples/forge-socket/forge-socket.c:473: undefined reference to log                                            _fatal' /home/zmap/examples/forge-socket/forge-socket.c:470: undefined reference to log                                            _fatal'
/home/zmap/examples/forge-socket/forge-socket.c:453: undefined reference to log                                            _fatal' /tmp/cckp267K.o: In function stdin_eventcb':
/home/zmap/examples/forge-socket/forge-socket.c:317: undefined reference to log                                            _debug' /home/zmap/examples/forge-socket/forge-socket.c:321: undefined reference to log                                            info'
/tmp/cckp267K.o: In function decrement_cur_running': /home/zmap/examples/forge-socket/forge-socket.c:85: undefined reference to log                                            debug'
/home/zmap/examples/forge-socket/forge-socket.c:87: undefined reference to buff                                            erevent_get_input' /home/zmap/examples/forge-socket/forge-socket.c:87: undefined reference to evbu                                            ffer_get_length'
/home/zmap/examples/forge-socket/forge-socket.c:94: undefined reference to log_                                            info' /tmp/cckp267K.o: In function grab_banner':
/home/zmap/examples/forge-socket/forge-socket.c:287: undefined reference to buf                                            ferevent_socket_new' /home/zmap/examples/forge-socket/forge-socket.c:289: undefined reference to buf                                            ferevent_set_timeouts'
/home/zmap/examples/forge-socket/forge-socket.c:297: undefined reference to buf                                            ferevent_get_output' /home/zmap/examples/forge-socket/forge-socket.c:303: undefined reference to log                                            _trace'
/home/zmap/examples/forge-socket/forge-socket.c:310: undefined reference to log                                            _trace' /home/zmap/examples/forge-socket/forge-socket.c:280: undefined reference to log                                            _error'
/home/zmap/examples/forge-socket/forge-socket.c:255: undefined reference to log                                            _fatal' /tmp/cckp267K.o: In function stdin_readcb':
/home/zmap/examples/forge-socket/forge-socket.c:330: undefined reference to buf                                            ferevent_get_input' /home/zmap/examples/forge-socket/forge-socket.c:333: undefined reference to log                                            _debug'
/home/zmap/examples/forge-socket/forge-socket.c:337: undefined reference to evb                                            uffer_get_length' /home/zmap/examples/forge-socket/forge-socket.c:339: undefined reference to evb                                            uffer_readln'
/home/zmap/examples/forge-socket/forge-socket.c:343: undefined reference to log                                            _debug' /home/zmap/examples/forge-socket/forge-socket.c:356: undefined reference to log                                            _trace'
/tmp/cckp267K.o: In function read_cb': /home/zmap/examples/forge-socket/forge-socket.c:134: undefined reference to buf                                            ferevent_get_input'
/home/zmap/examples/forge-socket/forge-socket.c:136: undefined reference to evb                                            uffer_get_length' /home/zmap/examples/forge-socket/forge-socket.c:140: undefined reference to log                                            _debug'
/home/zmap/examples/forge-socket/forge-socket.c:154: undefined reference to log                                            _fatal' /tmp/cckp267K.o: In function event_cb':
/home/zmap/examples/forge-socket/forge-socket.c:120: undefined reference to log                                            _debug' /home/zmap/examples/forge-socket/forge-socket.c:108: undefined reference to log                                            _error'
collect2: ld  return 1
make: *** [forge-socket]  error 1
what's wrong give me some suggest please. thanks

Forge socket needs to be linked against logger.o, this is fixed in the current master build.


fixed typo

Hoi, fixed a typo: anymore instead of anymode.

Thank you for your contribution! This was fixed by another PR.


possible filter and components query needlessly fires twice - and takes a very long time

@bprusinowski very similar results are fetched twice - most of which aren't even needed (non-key) - thanks for taking a look
Describe the bug
The rework of https://github.com/visualize-admin/visualization-tool/pull/1487 shows a tiny glitch endin up in a big difference on milk cubes.
To Reproduce Steps to reproduce the behavior:

Go to https://int.visualize.admin.ch/browse?dataset=https%3A%2F%2Fagriculture.ld.admin.ch%2Ffoag%2Fcube%2FMilkDairyProducts%2FConsumption_Price_Month&dataSource=Int-uncached
Enable Debug mode
Create visualization
See queryplan and GraphQL waterfall

Expected behavior

possible filters are fetched once
overall cubeComponents are fetched once using a speedy query

Actual behavior

possible filters are fetched twice
overall cubeComponents are fetched twice, the second query is very slow (and asks for information about every single non-keyDimension which becomes expensive and takes > 20s)
OTOH the chart already appears perfectly a few seconds from the start
so it's just the left panel (and not the filters) which fires that expensive re-query

Screenshots or video

Environment (please complete the following information):

Visualize environment and version: INT 4.7.2

Additional context
the query needlessly re-asking for information over all dimensions
get.components.expensive.txt
curl 'https://int.visualize.admin.ch/api/graphql' -X POST -H 'content-type: application/json' --data-raw '{"operationName":"DataCubeComponents","variables":{"locale":"de","sourceType":"sparql","sourceUrl":"https://lindas.admin.ch/query","cubeFilter":{"iri":"https://agriculture.ld.admin.ch/foag/cube/MilkDairyProducts/Consumption_Price_Month","filters":{"https://agriculture.ld.admin.ch/foag/dimension/product":{"type":"single","value":"https://agriculture.ld.admin.ch/foag/product/193"},"https://agriculture.ld.admin.ch/foag/dimension/value-chain-detail":{"type":"single","value":"https://agriculture.ld.admin.ch/foag/value-chain-detail/18"},"https://agriculture.ld.admin.ch/foag/dimension/key-indicator-type":{"type":"single","value":"https://agriculture.ld.admin.ch/foag/key-indicator-type/1"},"https://agriculture.ld.admin.ch/foag/dimension/production-system":{"type":"single","value":"https://agriculture.ld.admin.ch/foag/production-system/3"}},"loadValues":true}},"query":"query DataCubeComponents($sourceType: String!, $sourceUrl: String!, $locale: String!, $cubeFilter: DataCubeComponentFilter!) {\n  dataCubeComponents(\n    sourceType: $sourceType\n    sourceUrl: $sourceUrl\n    locale: $locale\n    cubeFilter: $cubeFilter\n  )\n}\n"}'

VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/cost-component> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/currency> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/data-method> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/data-source> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/date> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/foreign-trade> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/key-indicator-type> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/market> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/product> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/product-group> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/production-system> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/product-origin> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/product-properties> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/product-subgroup> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/sales-region> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/unit> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/usage> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/value-chain> }
VALUES ?dimensionIri { <https://agriculture.ld.admin.ch/foag/dimension/value-chain-detail> }

Hey @Rdataflow, thanks for identifying and reporting the issue. I am not 100% sure it's a regression from before the refactor of the query, as there are some specific reasons we need to have the flow mentioned as problematic above:

first query fetches all dimensions with values, including non-key dimensions,
we need this information to be able to create initial chart config and a list of possible chart types,
we need to access dimension values to derive the initial filters and check if we need to fire possibleFiltersQuery in case default filters result in no observations,
after the chart was initialized, we no longer need to send an unfiltered components query and send ones with filters, specifically for the left panel.

To sum up, it looks like it's the left panel that has some duplicated logic, but in fact first queries are set when initializing chart from cube and are not related to the queries we send from the left filter panel. I wouldn't treat this as a bug, as we introduced this behavior in order to make sure we show a "correct" chart as soon as it loads, and prevent showing no-data screen initially, followed by a reload of queries only afterwards.
I modified the logic a bit to re-use the preview query in https://github.com/visualize-admin/visualization-tool/pull/1697. As a con, it always fires possible filters query, contrary to conditional firing in the old logic. Let me know if that explains and improves situation :)

After discussing with @Rdataflow, we'll not merge #1697, but rather exclude non-key dimensions from the most expensive query fired when initializing a chart from cube. The problem with #1697 is that we can't easily determine "preferred dimension values", which means that e.g. when opening an NFI: Change cube, we do not select Schweiz anymore (as the top-root hierarchy value), but rather Fribourg.

@bprusinowski can this issue be closed (as the PR will not be merged), or should we keep it open?

got it! Thanks @bprusinowski


Put configuration options in user directory

Patch from Arch: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=superpaper

This is something that has been on my to-do list for a long time but it seems to me that if I move the configurations into the default config directory I will also need to solve how to handle the installation, which I haven't gotten around to figuring out.
Would you mind outlining for me what would be the expected installation procedure for a Python application like this? Should the installation process be setup together with the config dir change?
Secondly, if I throw the configs under XDG_CONFIG_HOME/superpaper, would it be an issue to put the temporary wallpaper images under there as well or should I start using a cache folder elsewhere?

I'm no code expert sorry so I can't give advice on that side but config and wallpapers should be separate. I would put the wallpapers in ~/.cache/superpaper/wallpapers

Thanks for your input. I'll probably solve this in two phases. First I'll start using the proper folders if Superpaper is run as a python script so git clones and maybe the AUR package will behave correctly and the portable release packages will stay as they are for the time being. Once I get installation flows setup the new installable releases will use the correct folders of each platform.

This was resolved with:  12aac36c65


No output when nothing is passed to command

Swiftly (swift-server/swiftly, this revision as of writing this issue) doesn't output anything when nothing is passed to it.
This seems very much like an issue of this package, not a fault of Swiftly.
Related to https://github.com/swift-server/swiftly/issues/38.
ArgumentParser version: 1.1.2 & the main branch
Swift version:
# swift --version
Swift version 5.8 (swift-5.8-RELEASE)
Target: aarch64-unknown-linux-gnu

Checklist

[x] If possible, I've reproduced the issue using the main branch of this package
[x] I've searched for existing GitHub issues

Steps to Reproduce

Clone Swiftly. this revision as of writing this issue.
Run swift run swiftly. There is no output. This is the issue.

# swift run swiftly
Building for debugging...
Build complete! (0.40s)

Run swift run swiftly xxx. Makes you sure the actual command is working:

# swift run swiftly xxx
Building for debugging...
Build complete! (0.44s)
Error: Unexpected argument 'xxx'
Usage: swiftly <subcommand>
  See 'swiftly --help' for more information.

Expected behavior
The output of swift run swiftly should be something like the output of swift run swiftly --help. It definitely should not be empty as that might make users think the command is not installed / not working.
Actual behavior
Running swift run swiftly results in no output.

ParsableCommand types provide this behavior (printing help by default) through the default implementation of the run() method. Since the swiftly command provides an empty implementation, that isn't done. You can either remove that implementation or print the result of Swiftly.helpMessage() from within that method.


Add GCP region/zone env var

The most recent nightly build failed to shut down the VM because the region was hardcoded in the API request that shuts down the VM at the end of the nightly builds. This PR passes the GCE_INSTANCE_ZONE env var to the container on the VM.
Is it possible to sneak this into main soon, so we don't waste VM $$$?
PR Checklist
Before requesting a review of your pull request, please make sure you've done the
following:

[ ] Merge the most recent version of dev (or the appropriate upstream branch) into
your branch and resolved any merge conflicts. You may need to do this several
times over the course of a PR as dev changes frequently.
[ ] Verify that all of the CI checks on your PR are passing. See
Running Tests with Tox
for details on how to run the full test suite locally if you need to debug a
particular failure.
[ ] Ensure that the docstrings for any new modules, classes, functions, or methods are
descriptive enough for developers and users to understand your code.
[ ] If you expanded data coverage or changed the outputs, ensure that the full
data validation tests
pass locally on a fresh DB.
[ ] If you've added new functions or classes, ensure that they have at least basic
unit tests.
[ ] If you've added new analyses, make sure they include defensive sanity checks that
will catch unexpected data issues.
[ ] Update the
release notes
to reflect your changes. Make sure to reference the PR and any related issues.
[ ] Do your own review of the PR. Add comments highlighting areas where you have
questions you'd like reviewers to answer, known issues, solutions you're
unsatisfied with, or other things that deserve special attention from the
reviewer.

If this needs to go into main then the PR should probably point there instead, since there have already been other commits to dev and we don't want to merge them up to main until after the release goes out (which will hopefully be tomorrow but... famous last words).

This was branched off of dev, so I created a new branch off main with these changes #2101.


Timeout request

Added a timeout option to ‘requests’ while getting speaker info.

Looks good! The comment describing the parameter should however describe how to disable the timeout. I assume passing None would work, but this should be stated explicitly.

You're right.
I used the timeout parameter of http://docs.python-requests.org/en/latest/api/#main-interface and it's optional so I think None should work.
Probably we can simply remove the default value and let you choose if you want to set a timeout

After quite a bit of searching through requests source code I was able to confirm that it does indeed default to None. @xxdede if you include this information in the docstring like @stefankoegl requested then we should be able to merge and get your change into the next release.

Added doc as suggested!
=)

One more thing: flake8 (which is part of the test suite) fails with the following error:
soco/core.py:1013:57: E231 missing whitespace after ','

When you add the space the build should succeed, and (from my point of view) your change should be ready to be merged.

Merged. Thank you @xxdede for your contribution.
Can you add a comment to the release notes issue #332 that describes your addition?


Open a session to yourself

Currently, an FSC node cannot open a session to itself because the underlying communication infrastructure (libp2p) does not allow it. Though, this sounds to be a useful feature in the FSC context when a single nodes is playing multiple roles that are supposed to interact at some point.
Therefore, this issue asks to introduce support for sessions to self.

let's reopen this when there will be a need.


⚠ Anthelion has degraded performance

In eb90f60, Anthelion ($ATH) experienced degraded performance:

HTTP code: 200
Response time: 2179 ms

Resolved: Anthelion performance has improved in a998953 after 411 days, 16 hours, 22 minutes.


Intake, catalogs, and datatree

Thanks @TomNicholas and sorry for creating issue noise. I guess I got a bit carried away with these comments in the readme:

Has functions for mapping user-supplied functions over every node in the tree,
Automatically dispatches some of xarray.Dataset's API over every node in the tree (such as .isel),

I was thinking that maybe the datatree abstraction could be a more formalised and ultimately 'xarray native' approach to the the problems that have been tackled by e.g. intake-esm and intake-thredds. Leaves in the tree could compositions over netcdf files, which may be aggregated JSON indexes. I guess I was thinking that some sort of formalism over a nested datastructure could help in dask computational graph composition. I have run into issues where the scheduler gets overloaded, or just takes forever to start for calculations across large datasets composed with i.e. mf_opendataset
I wonder if @andersy005, @mdurant or @rsignell have any experience or thoughts about if it makes any sense for interface between this library and intake?
Originally posted by @pbranson in https://github.com/xarray-contrib/datatree/issues/97#issuecomment-1200292141

@pbranson thanks for your ideas about integration of datatree with the intake ecosystem, this is definitely something I'm really interested in, and a potential use case I had in mind when originally creating this package.

I was thinking that maybe the datatree abstraction could be a more formalised and ultimately 'xarray native' approach to the the problems that have been tackled by e.g. intake-esm and intake-thredds.

I think this makes sense. Datatree is almost like an in-memory catalog of datasets.

Leaves in the tree could compositions over netcdf files, which may be aggregated JSON indexes.

Yep. There are probably lots of cool possibilities. My priority would be to build datatree in such a way that other packages can easily understand the model and experiment with interfacing in ways they think are sensible.

I have run into issues where the scheduler gets overloaded, or just takes forever to start for calculations across large datasets composed with i.e. mf_opendataset

I think this poor performance could be a bunch of different problems, and I'm not sure if datatree actually solves any of the dask-side issues. Datatree just makes it easier to express the complex operation which behaves poorly when run via dask.
cc @rabernat who has also pointed out the correspondence between datatree and intake catalogs to me before.

@TomNicholas Thanks for breaking this out of #97!
I should have guessed that this would have been part of your discussions! I just scanned back over the issues prompting the creation of datatree

I think this poor performance could be a bunch of different problems, and I'm not sure if datatree actually solves any of the dask-side issues.

The dask-side challenges could entirely be due to detail with my naïve usage! :-)

The ability to open a set of intake catalogs as a DataTree was actually added to intake-esm in https://github.com/intake/intake-esm/pull/512 by @mgrover!
Separately it's also been suggested that we might want to write a plugin for intake proper.

Closed and moved to https://github.com/pydata/xarray/issues/9438


Enriched the extension helpers on async result

Added a few extension methods for handling async result, such as SingleAsync, ForeachAsync.

@ali-ince I removed the extension method
Task ForEachAsync(..., Function<IRecord, Task>)
but instead added
List<T> ToListAsync<T>(..., Function<IRecord, T>)
The reason I changed is that I am not sure if we should make decisions for a user to await on their tasks. Instead I think it might be better to give ToListAsync method where a user could return his/her tasks into a list<Task> and then waitAll on them.
And in the future, when requested, we could add
Task ForEachAsync(..., Function<IRecord, Task>) and
Task ForEachAsync<T>(..., Function<IRecord, Task<T>>)


Rancher error sync rke2 etcd snapshot and showing 0 byte size

Rancher Cluster:
Rancher version: 2.6.9 (upgraded from 2.6.4)
Number of nodes: N/A
Node OS version: SLES15 SP3
Downstream Cluster:
Number of Downstream clusters: N/A
Node OS: SLES15 SP3
RKE/RKE2/K3S version: RKE2
Kubernetes version: 1.24.7
CNI: N/A
Longhorn:
No Longhorn
Issue description:
Customer facing an issue with RKE2 cluster snapshot.
The snapshot is taken and being shown on the list but with 0 byte size
ETCD throwing continuous errors trying to sync.
Business impact:
critical as the customer does not have a backup to rely on.
Troubleshooting steps:
edit yaml file to disable it and re-enable it again but no luck.
SSH into master node
The snapshot exists on the master nodes with the right time and size
Repro steps:
Create an RKE2 cluster
Take snapshot for that cluster
Check the list of snapshots
The snapshots appearing on the UI but with 0 byte size and wrong date (age of snapshot)
Workaround:
Is workararound available and implemented? NO
Actual behavior:
The snapshots of RKE2 should appears on the list with the right time and appropriate size
ETCD throwing errors not syncing with downstream cluster
Expected behavior:
The snapshots of RKE2 should appears on the list with the right time (age) and appropriate size.
Files, logs, traces:
[ERROR] error syncing 'kube-system/rke2-etcd-snapshots': handler snapshotbackpopulate: error while retrieving cluster local from cache via index: Index with name by-cluster does not exist, requeuing
[ERROR] error syncing 'kube-system/rke2-etcd-snapshots': handler snapshotbackpopulate: error while retrieving cluster c-m-frtz2drj from cache via index: Index with name by-cluster does not exist, requeuing
SURE-5650

Possible related bug: https://github.com/rancher/rancher/issues/39703
This needs to be reproduced in 2023-Q1-2.6x, 2023-Q1-2.6x, and if it cannot be reproduced in those, 2.6.9

@MKlimuszka I was not able to reproduce issue on either 2.7-head or 2.6-head. Worked with @ronhorton to recreate the same setup, except we used SLES15 SP4 instead of SLES15 SP3.

However, I was able to reproduce in Rancher v2.6.9 on an RKE2 cluster v1.24.9+rke2r2.

As shown above the snapshot does not have a status or size.

 When I clicked on the file it did have the correct timestamp.

When SSHing on to the node, the backup size seemed correct.

Reopening for potential additional investigations.

For SLES OS, if /usr/local is a mount point, it may cause the rke2 cli not to be placed in the expected directory.
This may be a clue https://github.com/rancher/rancher/issues/40624

After additional testing this issue does indeed seem to be only reproducible on cases where there are multiple Rancher replicas, so closing it.
Will reopen if it turns out to not be so.

@Martin-Weiss , nothing wrong with having multiple Rancher replicas (and in fact, the default is 3 for HA setups), but there is a bug in all currently released versions (more info in this PR: https://github.com/rancher/rancher/pull/39622) that has the fix tested for inclusion in 2.6.11/2.7.2.

@Martin-Weiss , nothing wrong with having multiple Rancher replicas (and in fact, the default is 3 for HA setups), but there is a bug in all currently released versions (more info in this PR: #39622) that has the fix tested for inclusion in 2.6.11/2.7.2.

Ok - cool - so the message is not “reduce to replica=1” ;-) - we “just” need to wait until next rancher release for the fix.. Thanks!!

I have the same situation on an rancher 2.8.2 managing 1.26 also after updating to 1.27.10+rke2r1

I'm also experiencing this problem. Tested in rancher 2.8.2 and 2.8.3 with kubernetes version  v1.27.10 +rke2r1 and  v1.27.12 +rke2r1 with 3 masters and 3 workers. The error persists no matter if s3 is turned on or off. And the files are saved successfully locally and on s3. Is there any work arround? Cloud upgrading kubernetes to version 1.28 solve this?

I've got this problem for Rancher v2.8.4 for 2 managed clusters. Obviously Rancher and the managed cluster disagree about the backups. Is there some way to resync without messing around with the numbers of backups, the backup schedule, manually removing files, etc., all indicating that the real problem is not understood yet?


get_scale.py in v2

In get_scale.py, the render_with_depth-function cannot be accessed. Cameras Views are successfully loaded and the config file could be found.
Traceback (most recent call last):
  File "get_scale.py", line 119, in <module>
    rendered_pkg = gaussian_renderer.render_with_depth(view, scene_gaussians, pipeline.extract(args), background)
AttributeError: module 'gaussian_renderer' has no attribute 'render_with_depth'

I carelessly removed the render_with_depth function, I will add it back later.


Fixed: operator when selecting proximity filter

Related Issues

When applying proximity filter the operator passed is equals but we don't need the distance calculation logic to check for exact distance.
Short Description and Why It's Useful

Changed the operator for proximity filter to less-equals as we need to check for all the facilities withing that specified distance.
Screenshots of Visual Changes before/after (If There Are Any)

Contribution and Currently Important Rules Acceptance

[x] I read and followed contribution rules

Verified and working fine in release v1.1.0.


Collect access advisor data

Have collect call the new APIs at https://aws.amazon.com/blogs/security/automate-analyzing-permissions-using-iam-access-advisor/

Collected in #254


Revisiting imputation outside data window

The package does some imputation for policy changes outside of the data window, motivated by the case of staggered adoption (example).
For each unit i, define F(i) as the first period in which we observe data for i, and L(i) as the last period in which we observe data for i.
I propose to refactor as follows:

default: no imputation. (I believe this is currently implemented as nostaggered)
no_unobserved_change: assumes that, for each unit i, the policy in periods t<F(i) is equal to z_{i,F(i)} and the policy in periods t>L(i) is equal to z_{i,L(i)}.
staggered

checks for consistency with staggered adoption, which means

z_{i,t} \in {0,1}
z_{i,t'}>=z_{i,t} whenever t'>=t

if consistency fails, throws warning and reverts to default
if consistency holds

if z_{i,F(i)}=0 and z_{i,L(i)}=1 for all i then applies no_unobserved_change
otherwise applies default

I can imagine other versions being appealing so feel free to weigh in @SimonFreyaldenhoven @chansen776 @jorpppp if you see something you prefer.

Thanks @jmshapir. This refactoring sounds good to me. I have a couple of comments.

For `staggered', I think we want to check that z_{i,t} is binary, not necessarily in {0,1}. In other words, we do not want to force the user to map their binary policy to {0,1}: instead we want the package to take the binary policy and produce properly-scaled estimates. I think _eventgenvars currently checks for a binary policy.
A more substantive point is whether xtevent' is currently deviating from the staggered' behavior. I believe Veli and Nate played around with this already. Would they agree that the current default behavior of `xtevent' is what you call staggered, or are there any differences we need to keep in mind?

Thanks @jorpppp!

For `staggered', I think we want to check that z_{i,t} is binary, not necessarily in {0,1}. In other words, we do not want to force the user to map their binary policy to {0,1}: instead we want the package to take the binary policy and produce properly-scaled estimates. I think _eventgenvars currently checks for a binary policy.

I'm definitely fine with allowing other binary forms, e.g. {1, 2} instead of {0, 1}.

A more substantive point is whether xtevent is currently deviating from the staggered' behavior. I believe Veli and Nate played around with this already. Would they agree that the current default behavior of xtevent` is what you call staggered, or are there any differences we need to keep in mind?

@veli-m-andirin @nateschor is your understanding that under staggered option, xtevent behaves as described under the staggered bullet in https://github.com/JMSLab/xtevent/issues/15#issue-1145180171?

Thanks @jmshapir @jorpppp!
@jmshapir, I have two questions about the proposal in https://github.com/JMSLab/xtevent/issues/15#issue-1145180171.
On the following statement:

checks for consistency with staggered adoption, which means
- z_{i,t} \in {0,1}
- z_{i,t'}>=z_{i,t} whenever t'>=t

For the second condition, how to deal with missing values, i.e. if there is a period t s.t. 1<=t<=T with a missing value, then are we going to ignore them or would this automatically translate as the failure of the second condition?
On this one:

if consistency holds
-  if z_{i,F(i)}=0 and z_{i,L(i)}=1 then applies no_unobseved_change
- otherwise applies default

Suppose that there are 40 units, for 39 of them we have z_{i,F(i)}=0 and z_{i,L(i)}=1, but for unit i' we have z_{i',t} = 0 for all t. Then should the package revert to default for all units?
Other than that, on the question in https://github.com/JMSLab/xtevent/issues/15#issuecomment-1049234033, I think that there are differences with the current behavior and what is suggested in in https://github.com/JMSLab/xtevent/issues/15#issue-1145180171.

The package currently seems to impute values that are "in the middle of the window", so it imputes more than missing end points.
If the policy variable in the first period equals 1, then the package seems to assume that the policy change took place in the first period.

@jorpppp these are based on https://github.com/JMSLab/eventstudyr/issues/2#issuecomment-1046275575. For those who can not access the repo, xtevent_staggered_test.txt contains a short "test" where these issues can be observed. Please let me know if I missed something.

Thanks @veli-m-andirin! On your questions:

When checking consistency my proposal is to reject only when the data are inconsistent, and therefore not to reject any conditions due to missing values.
I revised the proposal to make more explicit that we should apply the imputation to all units or none.

Thanks @jmshapir @jorpppp!
@jmshapir, I have two questions about the proposal in #15 (comment).
On the following statement:

checks for consistency with staggered adoption, which means

z_{i,t} \in {0,1}
z_{i,t'}>=z_{i,t} whenever t'>=t

For the second condition, how to deal with missing values, i.e. if there is a period t s.t. 1<=t<=T with a missing value, then are we going to ignore them or would this automatically translate as the failure of the second condition?
On this one:

if consistency holds

if z_{i,F(i)}=0 and z_{i,L(i)}=1 then applies no_unobseved_change
otherwise applies default

Suppose that there are 40 units, for 39 of them we have z_{i,F(i)}=0 and z_{i,L(i)}=1, but for unit i' we have z_{i',t} = 0 for all t. Then should the package revert to default for all units?
Other than that, on the question in #15 (comment), I think that there are differences with the current behavior and what is suggested in in #15 (comment).

The package currently seems to impute values that are "in the middle of the window", so it imputes more than missing end points.
If the policy variable in the first period equals 1, then the package seems to assume that the policy change took place in the first period.

@jorpppp these are based on JMSLab/eventstudyr#2 (comment). For those who can not access the repo, xtevent_staggered_test.txt contains a short "test" where these issues can be observed. Please let me know if I missed something.

Thank you @veli-m-andirin . @Constantino-Carreto-Romero will check these examples where -xtevent- may be imputing data in a different way from Jesse's proposal, and come up with possible solutions that we can discuss and eventually implement.

@Constantino-Carreto-Romero has been familiarizing himself with _eventgenvars and he now understands how it works. He also read Schmideiny's paper. He'll be working now on implementing @jmshapir 's suggestion https://github.com/JMSLab/xtevent/issues/15#issue-1145180171 and on checking the issues brought up by @veli-m-andirin https://github.com/JMSLab/xtevent/issues/15#issuecomment-1049936885.

Right now, I’m working on the code implementation of issue #15, about imputation outside of the observed data range for each unit. In the case of missing values in the policy variable z in the middle of the observed data range, these missing values will remain even after imputation under the staggered scenario. Ignoring these missing values would lead to a loss of observations.  When detecting these missing values, it might be helpful to launch a warning message such as “There are some missing values in policy z in the middle of the data range”.
While the user may impute these missing values manually, to make things easier for them, we were thinking of an option that lets the user impute values for policy z when these missing values follow a pattern:
In the staggered scenario, where the following conditions hold:
•	z_{i,t} \in {0,1}
•	z_{i,t'}>=z_{i,t} whenever t'>=t
and additionally, the following holds:
z_{i,F(i)}=0 and z_{i,L(i)}=1 for all i
where F(i) is the first period in which we observe data for i, and L(i) as the last period in which we observe data for i.
Suppose for a unit i’ and for some period of time [t’,t’’] within the observed data range, where t’<=t’’, we have missing values for the value of the policy z. If this missing value or group of contiguous missing values is neighbor of only 0’s or 1’s, i.e., z_{i’, t’-1}=0 and z_{i’, t’’+1}=0 or z_{i’, t’-1}=1 and z_{i’, t’’+1}=1, then impute the missing values with the corresponding value of the neighbors.
We also have a more general scenario that might be present in the data: suppose that for a unit i’ we have a data range [t’,t’’], where t’<t’’. Besides, there is at least a period t*, with t’<=t*<=t’’, where we do not observe the data for this unit. These observations will not be considered when estimating, as in the above scenario. In this case, it is not possible to propose a way to impute this missing data. In this scenario, it might be helpful to launch a warning message such as “there are some units with missing data for some periods”. This will make the user aware the estimations will be affected by these missing observations.

Right now, I’m working on the code implementation of issue #15, about imputation outside of the observed data range for each unit. In the case of missing values in the policy variable z in the middle of the observed data range, these missing values will remain even after imputation under the staggered scenario. Ignoring these missing values would lead to a loss of observations.  When detecting these missing values, it might be helpful to launch a warning message such as “There are some missing values in policy z in the middle of the data range”.
While the user may impute these missing values manually, to make things easier for them, we were thinking of an option that lets the user impute values for policy z when these missing values follow a pattern:
In the staggered scenario, where the following conditions hold:
•	z_{i,t} \in {0,1}
•	z_{i,t'}>=z_{i,t} whenever t'>=t
and additionally, the following holds:
z_{i,F(i)}=0 and z_{i,L(i)}=1 for all i
where F(i) is the first period in which we observe data for i, and L(i) as the last period in which we observe data for i.
Suppose for a unit i’ and for some period of time [t’,t’’] within the observed data range, where t’<=t’’, we have missing values for the value of the policy z. If this missing value or group of contiguous missing values is neighbor of only 0’s or 1’s, i.e., z_{i’, t’-1}=0 and z_{i’, t’’+1}=0 or z_{i’, t’-1}=1 and z_{i’, t’’+1}=1, then impute the missing values with the corresponding value of the neighbors.
We also have a more general scenario that might be present in the data: suppose that for a unit i’ we have a data range [t’,t’’], where t’<t’’. Besides, there is at least a period t*, with t’<=t*<=t’’, where we do not observe the data for this unit. These observations will not be considered when estimating, as in the above scenario. In this case, it is not possible to propose a way to impute this missing data. In this scenario, it might be helpful to launch a warning message such as “there are some units with missing data for some periods”. This will make the user aware the estimations will be affected by these missing observations.

Thanks @Constantino-Carreto-Romero @jorpppp!
Regarding issuing a warning when z is missing inside the date range covered in the data, I am totally fine with that.
Regarding imputing z inside the date range, I'm somewhat hesitant to do this for two main reasons:

In cases where it is clearly appropriate, I'd bet that users will already have done it. (e.g., if I know that a law change occurred on a certain date, I will be able to fill in the binary z for all dates before and since, and so won't need the package to implement this for me). Note that this is a bit different from imputing outside the date range covered in the data, which almost by definition the user has not done, and which is relevant for xtevent because of the use of leads and lags of Delta(z).
In cases where it isn't clearly appropriate, it could lead to some weird side effects.

That said, as long as it's not a default, and it's clearly documented, I don't strongly oppose.
@SimonFreyaldenhoven @chansen776 let us know if you have views, too.

@Constantino-Carreto-Romero some comments additional to the ones made on this commit: https://github.com/JMSLab/xtevent/commit/520a15e297d50a62d7638bf180be9b766fd2b189

Is the nodropoption undocumented? Where is it coming from?
We need to implement nounobservedchange as proposed by Jesse. Right now I think we only have default' and staggered'. We want to use those option names as well, instead of impute
Check the endpoint cases where there are missing value in z in the middle.

In this commit we have already implemented the imputation options that @jmshapir proposed in this post: default, no-unobserved-change, and staggered. We also added an extra option that builds upon the staggered option and additionally imputes missing values inside the observed data range of the policy variable only if the missing value(s) is (are) both preceded and followed by a state of unadopted policy (e.g., zero) or by a state of adopted policy (e.g., one) for that unit.
In what follows, we are going to work on:

Simplifying and clarifying the warning messages
Making some blocks of code more efficient
Grouping the imputation options into a single option with parenthesis, and inside the parenthesis, the users will specify which specific option they want
Modifying the helpfile

Right now, we are working on these improvements:

Adding some warning messages about binary cases.
Sharpening the code that checks the third condition of the staggered option
Making code of binary checking more efficient
Editing of helpfile

Some of the variables that are created in these imputation steps may be being stored as "double" when they could be stored as "int" to preserve space. We'll postpone checking that to issue #10 .

We are almost ready to wrap up this issue. We still need to check creation of the endpoint dummies when units are always-treated or never-treated, and we need to update the helpfile.
@jmshapir Once these two remaining tasks are done, @Constantino-Carreto-Romero  will start a PR here with me as a reviewer. I wanted to ask if @veli-m-andirin or @nateschor can pitch in as reviewers of this PR too. Since they've been working on these imputation issues their review may be useful here.

I wanted to ask if @veli-m-andirin or @nateschor can pitch in as reviewers of this PR too. Since they've been working on these imputation issues their review may be useful here.

@veli-m-andirin @nateschor what do you think?

I wanted to ask if @veli-m-andirin or @nateschor can pitch in as reviewers of this PR too. Since they've been working on these imputation issues their review may be useful here.

@veli-m-andirin @nateschor what do you think?

@jorpppp @Constantino-Carreto-Romero @jmshapir I'm happy to review!

@jorpppp @Constantino-Carreto-Romero @jmshapir I'm happy to review, too!

@Constantino-Carreto-Romero, thanks a lot for great effort here!
I wanted to raise a minor point: We typically close issues after a PR is opened for them. I can't close this one since I don't have write access to this repo. Could you take care of this?

I will take care of it.
Thank you @veli-m-andirin for the review.

@jmshapir @jorpppp @Constantino-Carreto-Romero @nateschor @rcalvo12,
Reviving this thread! I have two questions after running this code snippet:
use analysis/release/exampleplots/simulation_data_dynamic.dta
xtevent y_base x_r, pol(z) panel(id) timevar(t) pre(2) post(3) overidpre(4) overidpost(5) norm(-3) plot savek(a)

What is the current default for imputation? I assume it is "doing nothing" (i.e. not imputing unless that option is specified, is that correct), is that correct?

If so, why is the third lead of the first differenced policy variable here is zero in periods 38,39,40 instead of missing?

After running this code, @nateschor and I have been getting this plot. I wonder what does the reported mean on the left correspond to? If we follow the notation in the paper, I think it could be computed as:

by id: drop if a_eq_m3 == 0
collapse (mean) y_base

which gives -0.4274. (The mean of the outcome variable in units where there is a policy change three periods in the future.)  In fact, this is assuming that there are no policy changes outside the data window per the first bullet I outline. If we don't assume this, I think the corresponding calculation would be:
by id: gen firstdiff = z - z[_n -1]
by id: gen firstdiff_lead3 = firstdiff[_n + 3]
by id: drop if firstdiff_lead3 == 0
collapse (mean) y_base

which gives -0.276, which is also different from what is reported.
@jmshapir, I also wonder which computation you think would make more sense as the default for the mean we are reporting in the plots? I think the second one would make more sense if the default is not imputing anything, and maybe the first one would make more sense when impute option is specified.

@jmshapir, I also wonder which computation you think would make more sense as the default for the mean we are reporting in the plots? I think the second one would make more sense if the default is not imputing anything, and maybe the first one would make more sense when impute option is specified.

@veli-m-andirin thanks! I could see a case for a variety of defaults, but maybe the simplest is to treat observed and imputed values of $z_{i,t}$ symmetrically for the purpose of the calculation in (4)?

@veli-m-andirin  Thanks for noticing these issues.
Regarding:

What is the current default for imputation? I assume it is "doing nothing" (i.e. not imputing unless that option is specified, is that correct), is that correct?

That's correct. The default is to do nothing, it imputes only if the option impute is specified.

If so, why is the third lead of the first differenced policy variable here is zero in periods 38,39,40 instead of missing?

When running:
use analysis/release/exampleplots/simulation_data_dynamic.dta
xtevent y_base x_r, pol(z) panel(id) timevar(t) pre(2) post(3) overidpre(4) overidpost(5) norm(-3) plot savek(a)

The endpoints are being correctly not imputed but the other event-time dummies are being imputed when they shouldn't. Here  we should add a condition for imputing the other event-time dummies only if impute is specified. Should I open it as a new issue @jorpppp ?

After running this code, @nateschor and I have been getting this plot. I wonder what does the reported mean on the left correspond to? If we follow the notation in the paper, I think it could be computed as:

The reported mean is calculated following this code. What I notice here is that the mean is always being calculated using the original policy variable. It is also necessary to correct this, to use the imputed version of the policy variable when necessary.

Thanks @jmshapir @Constantino-Carreto-Romero!
@jmshapir, on https://github.com/JMSLab/xtevent/issues/15#issuecomment-1184969298: Can you please clarify treating observed and imputed values of  $z_{i,t}$ symmetrically, since I think in the default mode we are not imputing the policy variable?

@jmshapir, on #15 (comment): Can you please clarify treating observed and imputed values of zi,t symmetrically, since I think in the default mode we are not imputing the policy variable?

@veli-m-andirin under my proposal, in cases where we do not impute the policy variable, then we would use only observations ${i,t}$ with directly observed values of $z_{i,t}$ for the calculation in (4).

Thanks @jmshapir! Then, is it correct to say that for instance, in cases where we do not impute the policy variable, if we are normalizing the coefficient in front of the third lead of the first-differenced policy variable, then we should only use those observations where that lead is defined (and is non-zero)? (Note that in the example I posted in the first point here), $z_{i,t}$ is defined for $t\in{38,39,40}$ but $\Delta{z_{i,t+3}}$ should not be.)

Thanks @jmshapir! I think https://github.com/JMSLab/xtevent/issues/15#issuecomment-1185847554 clearly explains what I had in mind in https://github.com/JMSLab/xtevent/issues/15#issuecomment-1185603746, and for now I don't see cases where that proposal is ambiguous.


ROMFS: posix adjust standard vtol (1040) and tiltrotor (1042) gains

@dagar Have you seen https://github.com/PX4/sitl_gazebo/pull/632 ?

@dagar Have you seen PX4/sitl_gazebo#632 ?

Thanks, I'll leave the tiltrotor alone for now.

Something isn't working right in AutopilotTester::fly_forward_in_posctl(). This is supposed to be a climb for 10 seconds.


Application Command raised an exception: AttributeError: 'str' object has no attribute 'send'

Hi,
after the bot is online and trying to use command /search, from the terminal side there was an error happened:
root@78:/codingProject/EinsteinBot# python3 -u bot.py
Bot is online
Ignoring exception in on_interaction
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 126, in wrapped
ret = await coro(arg)
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 852, in _invoke
await self.callback(self.cog, ctx, **kwargs)
File "/codingProject/EinsteinBot/cogs/slashCommands.py", line 32, in search_slash
await callCommand(main.Commands.search, self, ctx, urlReal)
File "/codingProject/EinsteinBot/core/utils.py", line 45, in callCommand
await command(ctx, parameter)
File "/usr/local/lib/python3.8/dist-packages/discord/ext/commands/core.py", line 498, in call
return await self.callback(context, *args, **kwargs)  # type: ignore
File "/codingProject/EinsteinBot/cogs/main.py", line 109, in search
await sendDefer(ctx, argError, True)
File "/codingProject/EinsteinBot/core/utils.py", line 33, in sendDefer
await ctx.send(embed=message)
AttributeError: 'str' object has no attribute 'send'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.8/dist-packages/discord/client.py", line 382, in _run_event
await coro(*args, **kwargs)
File "/usr/local/lib/python3.8/dist-packages/discord/bot.py", line 1045, in on_interaction
await self.process_application_commands(interaction)
File "/usr/local/lib/python3.8/dist-packages/discord/bot.py", line 737, in process_application_commands
await self.invoke_application_command(ctx)
File "/usr/local/lib/python3.8/dist-packages/discord/bot.py", line 997, in invoke_application_command
await ctx.command.dispatch_error(ctx, exc)
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 385, in dispatch_error
await injected(cog, ctx, error)
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 106, in wrapped
ret = await coro(*args, **kwargs)
File "/codingProject/EinsteinBot/cogs/slashCommands.py", line 44, in search_slash_error
raise error
File "/usr/local/lib/python3.8/dist-packages/discord/bot.py", line 993, in invoke_application_command
await ctx.command.invoke(ctx)
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 357, in invoke
await injected(ctx)
File "/usr/local/lib/python3.8/dist-packages/discord/commands/core.py", line 134, in wrapped
raise ApplicationCommandInvokeError(exc) from exc
discord.errors.ApplicationCommandInvokeError: Application Command raised an exception: AttributeError: 'str' object has no attribute 'send'

@jckli

After changing
answerRaw = await cheinsteinpy.answer(url, self.cookie, self.userAgent)
as
answerRaw = cheinsteinpy.answer(url, self.cookie, self.userAgent)
in
main.py
The discord replied with Something went wrong or there was no solution.


Unit tests

Still a work in progress. Want to cover a few more functions. Branches off of the move to poetry branch so currently includes that PR as well.

Looks good, although you might want to rename test_reslover.py

Rebased and updated the misspelled file. Some formatting changes for the pyproject.toml file and added some testing libraries/configs.


[Bug] Material not showing after upgrade from Iron to Jazzy

Description
We currently try to upgrade our stack from iron to jazzy. We mostly use stl files in our model. With rviz in iron all meshes + materials are shown correctly. In jazzy all meshes based on a stl file are shown in the same light gray (see screenshot)

Additionally rviz produces (Only in case the model is loaded via the moveit planning scene) and endless stream of such errors:

[rviz2-17] [ERROR] [1719212675.170806883] [rviz2]: Can't assign material Shape86Material to the ManualObject MeshShape_ManualObject7 because this Material does not exist in group General. Have you forgotten to define it in a .material script?
[rviz2-17] [ERROR] [1719212675.171172805] [rviz2]: Can't assign material Shape88Material to the ManualObject MeshShape_ManualObject8 because this Material does not exist in group General. Have you forgotten to define it in a .material script?
[rviz2-17] [ERROR] [1719212675.171424283] [rviz2]: Can't assign material Shape90Material to the ManualObject MeshShape_ManualObject9 because this Material does not exist in group General. Have you forgotten to define it in a .material script?
[rviz2-17] [ERROR] [1719212675.171593158] [rviz2]: Can't assign material Shape92Material to the ManualObject MeshShape_ManualObject10 because this Material does not exist in group General. Have you forgotten to define it in a .material script?

It is actually this stream of endless errors that makes it unusable.
System

jazzy binary install
rviz version: 14.1.1

Additional information
For most of these meshes a material is set in the <visual> block such as <material name="steel_blue"/>
EDIT:
I just ran rviz with '-l'.
Ogre does complain about:

08:17:31: Warning: Material file:///file_path_to_stl_file.stlMaterial0 was requested with isManual=true, but this is not applicable for materials; the flag has been reset to false

I am getting the same error in my environment.
The material is applied to cylinders, etc., but not to stl.

As previously mentioned in the thread of issue #1236 I keep getting endless rviz2 logging errors even after the latest update to version 14.1.3 of rviz2 which included a fix for issue #1236, but not for me. In my case I the objects producing the continuous rviz2 log errors are collision objects that were added using moveit2's applyCollisionObject methods and they include .stl meshes (note: the objects are not defined in a URDF file).
The typical error message is the following, with the numbers between "Shape" and "Material" as well as after "Object" being kind of an computed counter increasing over time:
[rviz2-3] [ERROR] [1721749218.192680538] [rviz2]: Can't assign material Shape18906Material to the ManualObject MeshShape_ManualObject17738 because this Material does not exist in group General. Have you forgotten to define it in a .material script?
I am guessing here, but it seems that it kind of generates materials (like "Shape18906Material" from log output cited above) counting upwards the whole time and it looks for this material in some group "General" which I am not familiar with.
My current setup is

Ubuntu 24.04
ROS2 Jazzy Debian Packages installed via apt
Currently installed rviz2 version: ros-jazzy-rviz2/noble,now 14.1.3-1noble.20240719.202006 amd64 [installed,automatic]

Any ideas?

I also got the same errors with rviz2 installed from apt (14.1.5), and I subsequently tried building 14.0.0 and 14.2.0 from source (as an overlay, without uninstalling the apt package), and got the same errors.
I'm only using the MotionPlanning and Motion Planning Tasks plugins, so not sure if it's somehow related to those.

Same here! Ubuntu 24.04 with Jazzy from Debian packages and rviz2 14.1.5 from binaries

I had the same problem and found a solution by looking a bit around. And taking inspiration from this similar issue in Moveit here.
I fixed the error by adding one parameter to a function in as seen in this commit that i changed in my forked version :)
here

Nice catch! Could you make a pull request?

Sure I will try, I have never tried making a pull request before though XD


fix: accidental non-linted files in repo

Signed-off-by: kushthedude<EMAIL_ADDRESS>refer https://github.com/OpenRefine/OpenRefine/pull/3626#issuecomment-778817086

The issue was caused due to the pull_request_target as well as the branch which was being merged was not in sync with upstream/master

Thanks! Yes our pull_request_target workflow is a real problem. But I think what confused me more is that the build on master passes - because linting is only enforced in pull requests, not in master. Perhaps that's also something worth fixing?

Yes I will plug that additional step into snapshot_release workflow.


Data integration always fail for D365 Ops and Fin with newer platform update

It seems to us that for D365 Ops and Finance, if we have platform update:

version 15: users will always get either "Bad request error to D365" or "the data value violate integrity constraints"
version 20 or above: the integration projects (using template) will always complete, but no data will be delivered at all.

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

ID: 96ad26d7-2a8a-03a5-f742-740f941a5a5b
Version Independent ID: 0b9c2d3d-a699-71d5-5b03-000e27d0ae28
Content: Prospect to cash - Finance & Operations | Dynamics 365 | #MSDyn365FO
Content Source: articles/supply-chain/sales-marketing/prospect-to-cash.md
Service: dynamics-ax-applications
GitHub Login: @ChristianRytt
Microsoft Alias: crytt

Thanks for contacting us. Unfortunately, we're unable to handle Support requests for the product here. To contact Support, consider one of the options described here: Support contact options. In particular, you might want to go to the Dynamics 365 for Finance and Operations community page to get help with your questions from the Dynamics community.


auth: Adding unit tests

This covers tests for User and Role related operations. This tests brings code coverage in store.go from 40.2% to 72.3%.
/cc @mitake

Current coverage is 64.56% (diff: 100%)

No coverage report found for master at 6bef2bd.

Powered by Codecov. Last update 6bef2bd...2fe7945

Also we don't want to have separate merge commits in the PR. Could you also rebase your branch to current etcd master? Thanks.

Hoping to merge https://github.com/coreos/etcd/pull/7234 first. So I can use that branch to add new tests.

Updated PR with suggested changes by @mitake & @xiang90

@Rushit Thanks a lot for helping us improve the test coverage. This is super important for project health.
The test cases look good in general. I will let @mitake take the final look, and help you get it merged.

I have latest push with suggested changes. I am hoping to get bette with each PR.
No problem, Glad to contribute here 😄

@Rushit lgtm, thanks!


floats in version tags fail

one  problem I've realized: try tagging a version as '1.0' instead of '1.0.0'.
Pyyaml now parses 1.0 as a float, and you cannot access it with a typical notation we're using as a string, because of the distinction in python between string indices in a dict and float/int indices in a dict.
Originally posted by @nsheff in https://github.com/databio/refgenie/issues/90#issuecomment-522660888

This is fixed by the latest update to yacman (yacman 0.5.2)
so we need to require that version to solve this problem.


Hydration bug when using an  tag

Describe the bug
When adding an <html> tag in a view macro, the following warning appears in the browser's console:
component with id 0-0-0-1c not found, ignoring it for hydration
Leptos Dependencies
leptos = { version = "0.5", features = ["nightly"] }
leptos_axum = { version = "0.5", optional = true }
leptos_meta = { version = "0.5", features = ["nightly"] }
leptos_router = { version = "0.5", features = ["nightly"] }
axum = { version = "0.6.4", optional = true }

To Reproduce
Steps to reproduce the behavior:

Create a new project with cargo leptos new --git leptos-rs/start-axum
Add an <html> tag around the router:

#[component]
pub fn App() -> impl IntoView {
    // Provides context that manages stylesheets, titles, meta tags, etc.
    provide_meta_context();

    view! {
        <html class="dark"> // <== NEW
            // injects a stylesheet into the document <head>
            // id=leptos means cargo-leptos will hot-reload this stylesheet
            <Stylesheet id="leptos" href="/pkg/leptos-bug.css"/>

            // sets the document title
            <Title text="Welcome to Leptos"/>

            // content for this welcome page
            <Router fallback=|| {
                let mut outside_errors = Errors::default();
                outside_errors.insert_with_default_key(AppError::NotFound);
                view! {
                    <ErrorTemplate outside_errors/>
                }
                .into_view()
            }>
                <main>
                    <Routes>
                        <Route path="" view=HomePage/>
                    </Routes>
                </main>
            </Router>
        </html> // <== NEW
    }
}

cargo leptos serve
Go to localhost:3000
Open the console
Observe the message: component with id 0-0-0-1c not found, ignoring it for hydration

Expected behavior
There should be no warnings.

You can't use <html> (or <body>) like that in your components. If you look at the HTML you'll see there are now two, which is invalid HTML. Use an <Html/> or <Body/> component from leptos_meta instead.


Kanban: reject reason

PR includes

[x] Feature

Related issues

Resolve #925
QA Instructions, Screenshots, Recordings

Maybe it could be inside a popup


Add work item options

Hello there,
I was looking for some time for an extension to automatically update the status of an item. Thank you for making this module!
It would be interesting to add a possibility to filter the items impacted by the rules.
For example:
A Task with specific field (Tags: "xx", "activity" xx) would trigger the auto status and not all tasks.
Same for the target item, the use of a filter could help.
Like the clauses for queries.
could you look into this ?
Thank you

Hi!
I have actually gone a bit back and forth on this feature, but figured I might wait until someone asked for it. The way the rule check engine is built, it should not be too much work... I think.
I will take a look into this and see what is possible.

I've done some minor experiments, and it looks like this is possible to get up with a bit of work. I'm adding it to the backlog and working on it further :)

Hi again,
I am currently implementing this and wanted to check in to see that it is moving in the correct direction. Version 1 of this feature will allow you to dynamically select fields (both custom and pre defined) that is one of the types:

Boolean
Identity
Integer
PlainText
String

Based on the value type, you will be able to select one of the following compare operations:

= (Equals)
<> (Not Equals)
> (Greater Than)
< (Less Than)
>= (Greater Than Equals)
<= (Less Than Equals)

Some fields will give you custom controls to manage the compare value better (such as a tag picker and identity picker).
Is this like you were thinking?
Currently how the UI is:

It looks promising !
To select the field, will we have to use the "Reference name" or the "field name"? I m still novice on devops and dunno all the references names I will need yet.

It uses and stores the ReferenceName since this is a unique field. When you are creating/updating the filters, you will be presented with a dropdown over all the supported fields. This uses the field name to make it easier:

This feature suddenly became a bit bigger than expected, so it might take a bit longer. I am currently facing some issues in figuring out how the new filter functionality should integrate with the two options of Children lookup and Process parent.
Currently you are only allowed to create unique rules based on the selection of Work Item types (Child and parent) and the source/target state. This works fine with this issues when dynamically resolving the parent/child rules in the background, but when introducing filter I feel like we should have the option of being able to duplicate rules where only the filter is the difference.
This means that the background processing might receive two rules when resolving for child/parent, and it does not know which to pick for further processing.
Currently the filters you add does AND when comparing, but I might need to add "rule groups" to this. That means we avoid the issue of duplicate rules, and you can define sets of filters that belongs together.

Ok.
We dont currently use the feature Children lookup and Process parent. And we look forward to testing your work on automating status changes.

Hi!
I do not have a set EAT for the release yet as it is taking a bit longer to figure out the issues. With the current progress maybe this upcoming weekend or sometime next week.

I am going into a validation and testing step now. The main features should be done, but it might take some more time if issues are found during testing :smile:

Will aim for release next weekend, still need to do some tests, fix some minor issues and write the documentation for it.

Good to hear. I m looking forward to test it !

Good to hear. I m looking forward to test it !

This is now merged. I have a few smaller changes that is also included in the next release. Once all changes are implemented and nothing appears in a manual test this will be released.

This just released in v1.3.0. You can read some of the docs here, please let me know if you have any issues.

Thank you for your work, i m going to try it right now!

First of all, thank you for the update. It works pretty well.
Here a first feedback on setting the extension:
Menu

It would be interesting to be able to set a title for the rule
Then a possibility to sort the rules
Same state but different filters
I have a error message when i set same condition for same type of item (ex task) but with different filter (ex task "specification" and task "developpement") I want the same parent target state for both of these tasks, in this case "dev in progress" but a message "A rule already exists that matches the current configuration" (I could manage it if I create new states but could be more confusing)

here an example of our backlog for customdev (yellow arrow = in progress, green = done for task state)
Child look up
I ve tried to set this option. For example in my project we have different code part for a same developpment. I would like when all my tasks with the filter "dev" reach the state "done", the parent state change to "dev completed". May be i m mistaking in the setting
State update
The auto state works only when you change state from the item page, but not from the backlog page (using right clic, then edit) Is there any tech reason for that?

Hi!
Thank you for the feedback, I'll address some of it here.

The limitation that triggers the message  "A rule already exists that matches the current configuration" is a technical limitation due to Parent processing and Children lookup. If the only thing that is different between the two rules is the filters, then you can add another filter group. This is the reason filters are grouped this way. This is also described in the documentation here. A rule will be considered matched when Main option + at least one filter group matches.

Children lookup has some requirements:

The parent work item must have a rule for the same state. If the state is different between child/parent, this option will not match.
When checking children, a rule must be defined for each work item type and the state must match the one of the parent.

I am currently looking into improving this option, but it currently does not work very well if you have custom states that is different between the child and parent.
Take the following rule configuration:

This would close the User Story when the last Task below it is closed AND all the other tasks are closed. When it is checking children, it looks for any rules that targets the same state (Parent target state) and checks that all the work items are in this state.

The state update will only trigger from the work item form and the backlog view for a single work item. Not mass updates. This issue is the same as for: https://github.com/joachimdalen/azdevops-auto-state/issues/38#issuecomment-1049943447

When it comes to titles and sorting I am a bit more unsure. I am currently looking into if the rule editor should be redesigned (maybe a bit more like the default interface for Work item templates), but I'll keep those wishes in the back of my head when looking into that.

Hi there here a little more feedback:
I ve read that the change of state only works when changing state in the form of the item. i can confirm that. I ve tried mass edit, drag and drop and from the "panel form" in query result, the auto state doesnt work. We really have to enter in the form/page of the item.

Thank you for the additional feedback. :smile:
I am currently on holiday,  but have created a new issue from your feedback and will follow up when I am back.


1 integrate chip as a submodule

setup script and connectedhomeip submodule

If my changes look good feel free to merge

Thought we call our setup script with source so it wouldn't be necessary to source activate.sh ;)

Thought we call our setup script with source so it wouldn't be necessary to source activate.sh ;)

As far as I can tell we need to source all the way through. Otherwise the variables set by matter's activate.sh don't get set in my shell.

Feel free to merge this as you see fit.

Sounds legit


chore: Skip test that sporadically fails

This test works sometimes and not other times. I stopped skipping it a while back and it seemed to be fixed. I think what's really happening is that it's not fixed, rather the test scheduler is saving us sometimes by bailing out at a max time limit just before the call stack is exceeded... but that's a wild guess. Basically it's a bad test and we need to make a better test, then fix the issue seperately.

Created issue without looking this PR -  https://github.com/ReactiveX/rxjs/issues/6630


Block face position fix

Same fix I did for mineflayer's visible face math. (PR)
The math for getting the position relative to the center of the block was off by a bit.

LGTM


Implementing error handling

[x] Add AppException for developer defined business exceptions
[x] Add Errors collection to select from one of the defined errors
[x] Handle errors in middleware to make user-friendly responses to UI
[x] Handle error messages in UI
[x] Handle Identity Error Codes in AppException
[x] Generate TargetType.TargetMethod value to tag to log entries

Execption.TargetSite is reffering to the final method in stack trace where the exception has thrown. From this property we can generate a value like TargetType.TargetMethod and add it to the log entries.

Identity Error Codes are a nameof(ErrorMethod) in the IdentityErrorDescriber. As shown in the link below we have access to all error codes of identity:
https://github.com/aspnet/Identity/blob/85f8a49aef68bf9763cd9854ce1dd4a26a7c5d3c/src/Core/IdentityErrorDescriber.cs
As we are using exact Identity codes in out error codings, something like this will generate Users.PasswordMismatch. We can use these codes prefixed with Users area name in the json error dictionary.

close #120


Bazel-Like Rule Attribute Library

This project is great! I'm just in the beginning stages of using it for a custom configuration language.  Here is an example builtin callback:
# test.sky
local_workspace(
    name = "foo",
    root = ".",
    files = ["a.txt", "b.txt"],
)

func (i *Interpreter) handleLocalWorkspace(thread *skylark.Thread, _ *skylark.Builtin, args skylark.Tuple, kwargs []skylark.Tuple) (skylark.Value, error) {
	rule := &LocalWorkspaceRule{}
	files := skylark.NewList([]skylark.Value{})

	if err := skylark.UnpackArgs("local_workspace", args, kwargs,
		"name", &rule.Name,
		"root?", &rule.Root,
		"files?", &files,
	); err != nil {
		return nil, err
	}

	if rule.Name == "" {
		return nil, fmt.Errorf("local_workspace attribute 'name' is required")
	}

	iter := files.Iterate()
	defer iter.Done()
	var value skylark.Value
	for iter.Next(&value) {
		log.Printf("filename: %v\n", value)
		if value.Type() == "string" {
			rule.Files = append(rule.Files, value.String())
		} else {
			return nil, fmt.Errorf("`files` attribute element must be a string, not %s (%v)", value.Type(), value.String())
		}
	}

	i.LocalWorkspaceRule = append(i.LocalWorkspaceRule, rule)
	return skylark.None, nil
}

Here I've defined a "rule" called local_workspace.  This works!
However, I immediately find myself wondering if there is an existing library or plans to support bazel-like custom rule definitions, where I don't have to do all the validation myself.  Basically, I'd like to be able to build up custom rule definitions that have string_list attributes (in Go), and have the rule automap the args to some struct type or protobuf type.
This of course is not terribly hard to write, but it seems like something that may already be in the works so I thought I'd ask.

Based on lack of response for this issue, I'll assume there are not immediate plans to implement the above.

Sorry for not responding sooner, but you are right: there are no such plans.  The general criteria for adding stuff to this (or any) project should be (1) can we live without it? and (2) is there one clearly superior design that will serve many users well? In this case, (1) there's no good reason for this code to live in the Skylark interpreter as it's entirely client-specific behavior, furthermore specific to only one client, and (2) the thing you're asking for is rather ad hoc; one can imagine a dozen slightly different ways of doing it.
As you said, it's not terribly hard to write.

SGTM.  I'll repost-here a link here if I write one.


Fixed typo

...CLI includes a local browser-based installer...

LGTM, thanks!

The commit message also needs a DCO sign-off.

Superceded by https://github.com/flynn/flynn/pull/2206


Dashboard shows archived repositories

Is your support request related to a problem? Please describe.
As discussed in the office hours, following repositories have been archived but are still considered in the Dashboard:

https://github.com/eclipse-tractusx/puris-frontend
https://github.com/eclipse-tractusx/puris-backend

Describe the solution you'd like
Don't show the repositories. Either by evaluating github attributes or by adding a property to the .tractusx file (as discussed during the session).
Additional context
Sidenote: We merged them into a mono-repo

HI @tom-rm-meyer-ISST, thanks for opening the issue. I will take that on, as soon as the current quality gate phase is over. For the proposed solution:
I think we won't hide the archived repos, but show them in a separate list or so. As long as they are archived and not deleted, we need to at least think about them, since they are still part of the Tractus-X project.
Will keep you posted on this topic!

I will convert this ticket into a regular story for us to make planning easier.

Hi @tom-rm-meyer-ISST, added archived repos into separate section of the dashboard.


Fix Relay pagination example

I have two suggestions here:

Preserve __typename.
Only update the result set if there are new edges returned.

I'm not sure how significant the first issue is, but it throws a console warning.  The second is a significant issue.  Consider the scenario where loadMoreEntries is called and the server returns an empty dataset:
{
  comments: {
    edges: [],
    pageInfo: {
      endCursor: null,
      hasNextPage:false,
    }
  }
}

This stores endCursor as null on the client, and any subsequent calls to loadMoreEntries will end up returning additional results from the beginning of the dataset.

➤ meteor-bot commented:

Messages

:book:

Please add your name and email to the AUTHORS file (optional)

  Generated by :no_entry_sign: [dangerJS](http://github.com/danger/danger-js/)

➤ James Baxley commented:
Deploy preview ready!
Built with commit 94be97b34381e7937828b3a7661a09bb742776b5
https://deploy-preview-2538--apollo-client-docs.netlify.com

➤ codecov[bot] commented:
Codecov Report> Merging 2538(https://codecov.io/gh/apollographql/apollo-client/pull/2538?src=pr⪙=desc) into master will not change coverage.

The diff coverage is n/a.

@@           Coverage Diff           @@
1. master    #2538   +/-   ##

=======================================
Coverage   85.98%   85.98%
Files          39       39
Lines        2147     2147
Branches      500      500
Hits         1846     1846
Misses        292      292
Partials        9        9
Continue to review full report at Codecov.

Legend

Click here to learn more

Δ = absolute  (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 76ed60b...94be97b. Read the comment docs.


GzSpinBox causes the Qt Scene Graph to crash on macOS

Environment

OS Version: macOS, qt@5 5.15.8_3
Source or binary build? either

Description

Expected behavior: GUI plugins that use GzSpinBox should work correctly.
Actual behavior: The GUI application crashes. The error occurs on the Qt scene graph render thread.

Steps to reproduce

Update and upgrade brew. This will install qt@5 5.15.8_3.
Run gz sim -g shapes.sdf
Open the Component Inspector (if not already opened)

Output
See https://github.com/gazebosim/gz-sim/issues/1987.
The problem appears to be a conflict between QtQuickControls 1.4 and QtQuickControls 2.2. Both versions have a SpinBox but the behaviour is very different. The version in QtQuickControls 2.2 is for integer values only.
The QML documentation suggests an approach to use the controls for floats, but it is badly flawed and will not work for the use cases needed in gz-sim. A reimplementation of a spin box for doubles is needed. Docs and discussion:

https://doc.qt.io/qt-5/qml-qtquick-controls2-spinbox.html#validator-prop
https://stackoverflow.com/questions/43406830/how-to-use-float-in-a-qml-spinbox

This is a serious bug on macOS as it causes an application crash on start up for any of the default examples (because the default gui.config includes the component inspector which indirectly loads the spin box).
Possible approach
One of the answers in the SO article suggests a replacement SpinBox supporting doubles. This is almost a drop-in replacement for GzSpinBox. The branches below make the modifications to gz-gui7 and gz-sim7:

https://github.com/srmainwaring/gz-gui/tree/wips/7/wip-doublespinbox
https://github.com/srmainwaring/gz-sim/tree/wips/7/wip-doublespinbox

@srmainwaring I just tested this on an Intel macOS running Monterey, but I'm not getting a segfault at all. The spinbox doesn't seem to work properly (it's blank), but it doesn't crash. qt@5 has been upgraded to 5.15.10. Can you give it another try?

Can you give it another try?

@azeey - doing some book-keeping! Not seeing this at all in current Garden and Harmonic running Sonoma on M1 with latest brew - so suspect it was transient.


NWRFC "Observed" Precip

Sample File: ~https://www.nwrfc.noaa.gov/weather/netcdf/2022/20220810/QPE.2022081~

This share is a bit challenging to figure out.
As of 12/12/22, here is a sample QPE that works:
https://www.nwrfc.noaa.gov/weather/netcdf/2022/20221212/QPE.2022121212.nc.gz

@adamscarberry, this looks good. Just found this and will update the other NWRFC product issues also. Let's start by just getting the 12z file (-----12.nc.gz) - this may be the only file naming convention that is posted.

The QPE file contains 6hr grids (4 of them) - suspect this covers the past 24 hours of precipitation.

QPE is in inches, migration needs fixed by @adamscarberry

geoprocessor implemented, thanks @jeffsuperglide 👍🏻 Merged: https://github.com/USACE/cumulus-geoproc/pull/28.

Data acquisition and processing enabled in develop & stable; complete; closing issue