validationFailMsg : Uncaught TypeError: this.title is not a function

There is no title function function in blocks.
  return i18n.t('errors:validation_fail', { type: this.title() });
}```

This should be just this.title instead :

```validationFailMsg: function() {
  return i18n.t('errors:validation_fail', { type: this.title });
}```

You'd probably be better doing this in a pull request. Makes it easier to check over and see where it is.

Thanks @mrdoinel — fixed now.


Enable spinal-level-based registration to the PAM50

In projects where spinal (not vertebral) levels are known (example here), it would be desirable to have the option to register these data to the PAM50, which already has a spinal level atlas.
A suggestion for implementation includes (based on @charleygros's ideas):

For each PAM50/spinal_levels/spinal_levels_*.nii.gz, compute the center of mass of the distribution.
Generate a single nifti file (could be called PAM50_spinal_levels.nii.gz) and create a voxel for each of the identified spinal level center of mass. The value of the level will be: 2 for spinal level 2, etc.
Update the PAM50 package to include this new file, upload to OSF+neuropoly website and update sct_download_data with the new URLs
Refactor sct_register_to_template to add a new flag -lspinal, which will point to the file PAM50_spinal_levels.nii.gz for doing a z-based non-linear registration of spinal levels between the source and the dest (PAM50) images (step=0 of the algo).

Fixed with #2513 .


Not supported URL scheme http+docker

Hello,
I am trying to install R2R locally on an Ubuntu 22.04 system and following are the steps I followed and then got the error:
conda create -n r2r python=3.11 -y && conda activate r2r
pip install r2r
r2r --config-name=local_ollama serve --docker
Error:
docker.errors.DockerException: Error while fetching server API version: Not supported URL scheme http+docker
My docker version:
(r2r) Ubuntu@0136-ict-prxmx50056:~$ docker --version
Docker version 27.0.3, build 7d4bcd8
Ollama is already running on default host and port. What I am missing here?

We have not seen this error before, and I am not immediately sure what the most likely source is. Here are some debugging tips from Claude 3.5, based on the information you have provided and our codebase:

Docker Configuration:
The error message suggests there's an issue with the Docker configuration. Specifically, it mentions "Not supported URL scheme http+docker". This could indicate that the Docker daemon is not properly configured or accessible.

Docker Socket:
The compose file includes a volume mount for the Docker socket (/var/run/docker.sock:/var/run/docker.sock:ro). Make sure this file exists and has the correct permissions.

Docker Network:
The compose files define a custom network (r2r-network). Ensure that this network is being created correctly and that all services can communicate over it.

Ollama Configuration:
The error mentions that Ollama is already running on the default host and port. This could potentially cause conflicts with the Ollama service defined in the Docker Compose file.

Environment Variables:
The R2R service in the compose file uses several environment variables. Make sure these are properly set, especially OLLAMA_API_BASE.

Given these potential issues, here are some steps to troubleshoot:

Check Docker Installation:
Ensure Docker is installed correctly and the Docker daemon is running.
sudo systemctl status docker

Check Docker Socket:
Verify the Docker socket file exists and has the correct permissions.
ls -l /var/run/docker.sock

Docker Network:
Try manually creating the Docker network before running the compose file:
docker network create r2r-network

Ollama Conflict:
If Ollama is already running on the host, stop it before running the Docker Compose setup:
sudo systemctl stop ollama

Environment Variables:
Double-check that all required environment variables are set correctly, especially OLLAMA_API_BASE. You might want to explicitly set this in your .env file or when running the command:
OLLAMA_API_BASE=http://ollama:11434 r2r --config-name=local_ollama serve --docker

Docker Compose Version:
Ensure you're using a recent version of Docker Compose that supports the condition: service_healthy syntax.

Run with Verbose Output:
Try running the command with verbose output to get more information:
r2r --config-name=local_ollama serve --docker --verbose

If none of these steps resolve the issue, it might be helpful to check the Docker logs for more detailed error messages:
docker-compose logs

This should provide more context about what's happening when the services try to start up.

I saw this issue earlier tonight and updating docker compose seems to have solved it


Consider removing the sequence length 4 bytes of padding for compact share

Related
See https://github.com/celestiaorg/celestia-app/issues/1092 for context
Problem
Since the sequence length varint in compact shares is padded to 4 bytes, they must be parsed slightly differently than sparse shares.
Proposal
Remove the 4 bytes of padding from the sequence length in compact shares. Note: this will introduce complexity in the logic for writing compact shares.

Obsolete after https://github.com/celestiaorg/celestia-app/issues/1121


unleashed.nfo

Remove unleashed.nfo from the list of banned files in banned_filelist.txt

Good catch,

and update it with tvmaze.nfo and imdb,nfo


setup: add missing dependent package dataclasses

Signed-off-by: Lu Ken<EMAIL_ADDRESS>

Can you explain why you need this ? dataclasses are included since Python 3.7 and we drop support for Python below 3.7.

Hello @kenplusplus Can you explain why you need it ?

We drop support for Python below 3.7.


Fix mimetype confusion during tests

It seems like it's easy for python to get confused when you name
a file the same as a dependent module.  This happened for mimetypes,
and seems to call the wrong mimetypes when trying to add_type the
second time.

Coverage remained the same at 70.571% when pulling e45e16bec8f14e83bf09985720ce76667c4e05d8 on cbanek:mimetype-fix into f8546761a08e128d9c973d3044cdc94c134f1d56 on pyvirtobs:master.

I think if you also take PR #112 we can get back to passing?

Merged this and the referenced one. Lets see if this unbreaks the tests.
Thank you!

Well looks like we're closer to unbreaking the tests.  The other PR will get the style ones.  I'm still vexed as to why this didn't fix that last failing test.  It didn't fail in PR #112 's travis branch run!

I think it is related to https://github.com/astropy/ccdproc/pull/650/files


feat: Support theming border width and button font weight.

This PR adds support for theming field components border width and button font weight.

You need to regenerate the design token and theming snapshots to make the tests pass, run the following:
npx jest -u -c jest.integ.config.js src/__integ__/themes.test.ts
npx jest -u -c jest.unit.config.js src/__tests__/design-tokens.test.ts


Map Point tool issues (ArcMap)

Tested build 17 Jan 2017 13:13.
The Map Point tools on the LLOS and RLOS can't be disabled.
Current Behavior:
The Observer and Target Map Point tool can't be disabled on the following tools: LLOS and RLOS. All these tools have the following behavior:

Click on Map Point tool to enable. Result: The tool is made active and provides coordinates from map as you move cursor over map. Cursor is crosshairs with center dot. There is not change to the look of the button to indicate that it's active...

Click on Map Point tool to disable. Result: The tool is not disabled (i.e. still provides coordinates from map as you move cursor over map).

Expected Behavior (at least what I would expect)

When tool tab is clicked, the Map Point tool should be disabled by default.
User clicks the tool to enable.  Result: the tool is enabled; the look of the button changes to indicate that's it's active; the cursor icon changes to the crosshairs with center dot. (other behavior is the same...i.e. interact with map, etc).
User clicks the tool to disable. Result: the tool is disabled; the look of the button changes to indicate that's it's active; the cursor icon changes back to whatever was the active cursor in ArcGIS Pro before the Map Point tool was made active.

@elinz @kgonzago if this is fixed in the component add-ins, will it be fixed here?

@nfeuerstein are you referring to the single add-in? Once it's fixed at a component level issue it will be reflected in the single add-in.

@elinz - this should be ready to verify from daily

fixed tool icon change on deactivate. pr: https://github.com/Esri/visibility-addin-dotnet/pull/178

this issue has been fixed, closing.


Add CI/CD to run tests

Definition in progress: Which CI tool we will use

[ ] GithubActions
[ ] Jenkins
[ ] CircleCI
ETC

This CI must run the tests and compile the contracts as a first iteration in each PR


Any thoughts on possibly moving to Dart lang instead of using TypeScript?

Seems like Dart is making good head way to building strong programming practices.

TypeScript suits our needs quite at the moment.  In particular it gives us a very high degree of control over the generated JavaScript, and makes it trivial to mix JavaScript and TypeScript.  It's difficult to imagine being able to justify the cost of switching our actual engine code.
However, I'm sure it would not be too difficult to create Dart declarations for the Turbulenz engine and develop your code against those.  Potentially these declarations could be automatically generated from our .d.ts files.
Again, I'm not familiar enough with Dart to know if this is really practical.  If you have any experience or insight into this kind of thing I'd be interested to hear.

I'm currently evaluating 2d physics engines for a Dart project. And I like the one that comes with this project, but since there's no Dart API ready I'll probably end up using either box2d or p2 Dart ports for now.
But it would be entirely possible to interoperate with the js files of turbulenz, by declaring the API in a Dart file. There's a full example with the chart.js lib, and info.

Thanks for the comments.  We don't currently have any plans to provide the Dart declarations.
Based on our experience with TypeScript, adding the declarations is easy enough that I'd suggest it's often worth doing it yourself so you can use the libraries you prefer.  I'm guessing it's similarly easy with Dart.
(It also appears that there is now at least one project to generate Dart declarations from .d.ts files.  I have no idea how stable it would be, but it could be interesting to try and may provide the bulk of what you need.)

Thanks @dtebbs, I didn't know about that project, I assume you're referring to this one. I'll give it a go.


Update wp hooks dependency renamed wp 6.0 and aliases

This also partially adds the dynamic hook checks requested in https://github.com/humanmade/psalm-plugin-wordpress/issues/12
It's possible to infer all dynamic hooks easily, but this requires a bit more changes I can only PR once my other PRs are merged to avoid having to rebase my PR and fixing tons of conflicts

Let's get #41 merged and then update this PR to merge

@kkmuffme what's the state of dynamic hooks? Either from WordPress core or from third-party plugins. Is there some way I can stub dynamic hooks?
In my psalm.xml, I have a block like this:
<plugins>
	<pluginClass class="PsalmWordPress\Plugin">
		<hooks>
			<directory name="stubs/hooks" recursive="true" />
		</hooks>
	</pluginClass>
</plugins>

And then I have stubs/hooks/actions.json and stubs/hooks/filters.json, which look like this:
{
	"$schema": "https://raw.githubusercontent.com/wp-hooks/generator/0.9.0/schema.json",
	"hooks": []
}

So I'm familiar with how to stub out individual hooks, but curious what is the recommended approach for dynamic hooks specifically. Or if that's not yet implemented, just looking for a status update.
Thanks!

Hi @kkmuffme, I've just tested #49 and created a small git repo.
https://github.com/paulshryock/test-psalm-wordpress-latest/blob/main/src/functions.php
I added several dynamic hooks:

WordPress core hooks
Third-party plugin hooks
First-party hooks

And none of these throw a Psalm error! ❤

But then I realized that it seems like dynamic hooks are not checked by Psalm at all, regardless of whether or not they are stubbed.
For example, this third-party hook did throw a Psalm error (HookNotFound) until I defined a stub for it (as expected 👍).
But this dynamic third-party hook which is not stubbed does not throw a Psalm error, and this dynamic first-party hook which is not stubbed does not throw a Psalm error.
Is this expected behavior?

composer upgrade humanmade/psalm-plugin-wordpress

composer.lock:
-                "reference": "faab6d5e5ae4b1d7ed374ea040524121ed62ab29"
+                "reference": "2d71d096ac6e47354e381b2d110d754a8c311c47"

🥳  Now I get those two failures I was expecting:
vendor/bin/psalm
Target PHP version: 8.1 (inferred from current PHP version).
Scanning files...
Analyzing files...

ERROR: HookNotFound - src/functions.php:52:1 - Hook "ep_delete_{$slug}" not found
/**
 * Dynamic third-party action with no stub defined.
 *
 * This should probably throw a Psalm error, but it does not.
 */
add_action(
  "ep_delete_{$slug}",
  function(int $object_id, string $slug): void {
    print json_encode(['object_id' => $object_id, 'slug' => $slug]);
  },
  10,
  2,
);

ERROR: HookNotFound - src/functions.php:69:1 - Hook "{$verb}_some_{$noun}" not found
/*
 * First-party dynamic hook with no stub defined.
 *
 * This should probably throw a Psalm error, but it does not.
 */
add_filter(
  "{$verb}_some_{$noun}",
  function(string $value): string {
    return "hello {$value}!";
  },
  10,
  1,
);

------------------------------
2 errors found
------------------------------

Checks took 0.02 seconds and used 1.949MB of memory
No files analyzed
Psalm was able to infer types for 100% of the codebase

This looks great! Thank you for the quick work on this; I feel this is an improved user experience.


[feat] Devtools can install other plugin such as Redux Devtools

Describe the problem
can install other plugin
Describe the solution you'd like
› Node.js: 16.15.1
› npm: 8.13.2
› pnpm: Not installed!
› yarn: 1.22.19
› rustup: 1.24.3
› rustc: 1.62.0
› cargo: 1.62.0
› Rust toolchain: stable-x86_64-pc-windows-msvc
Alternatives considered
No response
Additional context
No response

None of the webviews we use has support for extensions and probably will never do.

You need to use the standalone version of the devtool if it exists.


Add Refl1D migration between schemas

Adds a specific migration function to migrate models written before the restructure change to the new class layout.
Also adds the infrastructure to support further migrations.

In the future, if a breaking change is made which will affect the serialized output, the version number in refl1d.__schema_version__ can be incremented, and a new function added to the lookup table that will migrate the old JSON structure to one compatible with the new.

Note: won't actually do anything unless PR https://github.com/bumps/bumps/pull/204 is merged first.


Add NonGNU ELPA badge to README.org

This package has now been added to NonGNU ELPA!
This commit adds a NonGNU ELPA badge as it looks nice, and is occasionally useful.
Thanks!

Thank you!


SNAPSHOT repository?

I would like to run the 1.3.0-SNAPSHOT version of the plugin, do you have a repository for development builds?
I tried using jitpack for this, however this failed:
https://github.com/jitpack/jitpack.io/issues/590

@netbrain jitpack does not build SNAPSHOT it picks commits and also release tag builds
can you try the below for the latest on master

com.github.temyers
cucumber-jvm-parallel-plugin
f6d7c3029d

Thats what im already doing.
cucumber-jvm-parallel-plugin-f6d7c3029d.jar), Plugin's descriptor contains the wrong version: 1.3.0-SNAPSHOT -> [Help 1]

Would be good to have a snapshot repository somehow, either through jitpack (like a nightly build through travis.ci?) or through maven central? Anyhow, for now the workaround was to install the snapshot locally.

@netbrain i think we also need to add jitpack as part of cucumber-jvm-parallel plugin ..
but i would see adding it to maven snapshot repo is a good idea

SNAPSHOTS are published to Sonatype OSS Snapshot Repository:

cucumber-jvm-parallel-plugin is published to Maven Central at release time


Adding some new functions and tests to product module

Functions are to get all the products from the data base,and we have tested it using pytest with test called get_all_products#17

Functions are to get all the products from the data base,and we have tested it using pytest with test called get_all_products

Functions are to get all the products from the data base,and we have tested it using pytest with test called get_all_products

This should be the content of the first comment - where you currently have the link to the PR.
Your first comment should be the description of the issue.

Functions are to get all the products from the data base,and we have tested it using pytest with test called get_all_products

This should be the content of the first comment - where you currently have the link to the PR. Your first comment should be the description of the issue.

Understood


Add bun auto-update script

Issue description
Bun should have an auto-update field so that it can be automatically updated.
Steps to reproduce
N/A
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/add-auto-update-script-to-bun/21793/1


[MNT] Add pytest plugin to retry failed tests

Somewhat of a reoccurring issue with our test suite is instability. Some of these are legitimate failures with sporadically failing tests, but a majority are just nodes crashing and causing the whole set to fail.
This would make the runs a lot more stable, but the downside of the above is it would rerun some of the legitimate failures, and they may get lost instead of being noticed and fixed. It's a bit hacky.
The main cause of these crashes from what I have gathered is pytest-xdist which runs the tests in parallel, and removing it would make everything a lot slower. One of the chosen plugins features is to be able to recover from hard crashed when pytest-xdist is installed.
One potential mitigator would be to automatically parse the output logs and create issues for re-runs which aren't crashes, but that's just an idea, and I'm not sure how much effort this would take or if it is possible.

does it retry just once? Dont want it to keep rechecking when the fail is genuine

The time spent re-running legitimate failures would be relatively small IMO unless the test takes multiple minutes.
Thats not so relevant anymore though, I played around with this on tsml-eval and you can configure it to only work with specific failures. I have added an option to limit this to the xdist failures we usually see and verified it works in similar scenarios.

The plugin cant record the traceback/output for restarts currently, so this is the best option IMO.


Don't use string literals in SQLAlchemy execute() calls

Found Occurrences  (13 usages found)
Unclassified occurrence  (13 usages found)
forseti-security  (13 usages found)
google/cloud/forseti/common/gcp_api  (2 usages found)
_base_repository.py  (2 usages found)
459 return request.execute(http=self.http,
461 return request.execute(http=self.http,
google/cloud/forseti/enforcer  (1 usage found)
gce_firewall_enforcer.py  (1 usage found)
178 return request.execute(num_retries=4)
google/cloud/forseti/services  (8 usages found)
dao.py  (8 usages found)
504 session.execute(query)
507 session.execute(GroupInGroup.table.delete())
518 session.execute(qry)
551 rows_affected = bool(session.execute(qry).rowcount)
559 session.execute('UNLOCK TABLES')
1702 for parent, child in session.execute(qry):
2222 dbapi_connection.execute('pragma foreign_keys=ON')
2232 conn.execute('BEGIN')
google/cloud/forseti/services/model/importer  (2 usages found)
importer.py  (2 usages found)
298 self.session.execute(stmt)
303 self.session.execute(stmt)

Verified all the sqlalchemy execute() calls are safe from SQL Injection attack.


Update generate bundles script

Assisted-service-operator was converted from packagemanifest to bundle format so the automated scripting has to update. It will now look through all annotation metadata files to find the latest bundle on the desired channel.
Jira: ACM-6264

/lgtm


Enable to run optimize command by non-root user

Currently, optimize command requires root privilege. We should enable to run it by non-root user.
It is mainly because optimize command uses overlayfs to make rootfs environment for a container. fuse-overlayfs would be good alternative for overlayfs.

Ubuntu and Debian 10 support real overlayfs


beginDrawing does not record mouse position, so replaying or undoing strokes doesn't work.

https://github.com/jakubfiala/atrament.js/blob/59d3e6767b0b27e555c215e906993a616ea1d408/src/atrament.js#L151

Hi @coranos - thanks for submitting this and #46. I will make it so the start/end positions are recorded, and also provided to strokestart/strokeend events

cool. if you are interested, here is my demo for 'undo'
https://coranos.github.io/bananos/sketch/

Hey @coranos - this should now be fixed in v1.1.0. Feel free to reopen if you still encounter issues.
N.B. I decided to rename begin/endDrawing to begin/endStroke so the names are more descriptive of what the methods actually do.


Telegram instance loses token

Describe the bug
since ver.3.3.2 Telegram instance loses token
To Reproduce
Steps to reproduce the behavior:

Go to instance overview
See Instance "telegram" status
"telegram" status is every day/by restart warning
See log error "2024-06-24 05:59:59.024  - error: telegram.0 (2151) Token is not set!"

Expected behavior
Telegram instance token stays unchanged as set manually
Screenshots & Logfiles
log error "2024-06-24 05:59:59.024  - error: telegram.0 (2151) Token is not set!"
Versions:

Adapter version: 3.3.2
Plattform: docker (official image - v9.0.1)
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 1800 MHz
Modell: ARMv7 Processor rev 3 (v7l)
RAM: 3.7 GB
System-Betriebszeit: 91 T. 12:01:56
Node.js: v18.19.0
time:<PHONE_NUMBER>646
timeOffset: -120
NPM: 10.2.3
Adapter-Anzahl: 539
Datenträgergröße: 27.9 GB
Freier Festplattenspeicher: 3.1 GB
Aktive Instanzen: 20
Pfad: /opt/iobroker/
Betriebszeit: 24 T. 12:58:53
aktiv:

Additional context
Add any other context about the problem here.

Current telegram release is 3.6.0.
Please check whether this problem still exists with current version of adapter.
In addtion please add missing version information
adapter: 3.3.2 -> to be testets with 3.6.0
js-controller:
admin:
node: 18.19.0

Stable version of the telegram adapter in github is still 3.3.2. therefore i think it is the reason 3.6.0 is  not available in iobroker yet.
Make it pls. to stable first.
Your question "In addtion please add missing version Information", You mean version of what?

Sorry i see it now first:
js-controller: 5.0.19
admin: 6.13.16

3.6.0 is available at latest repository.
Please Test with this Version.

3.6.0 is not available in iobroker yet:

3.6.0 is available at LATEST repository.

Switch to latest / beta repository
press search for updates
update to current lates version (which is 3.6.0)
switch back to stable repository

3.6.0 is loses Token also, no changes

Please check the ioBroker log for any issues like DB not able to write files or such. because this should never happen and means that your configuration gets not stored.
Is this only happening when restarting adapter? Or is whole js.controller restarted?
Please enable expert mode in admin, then go Objects -> system.adapter.telegram.0 and use the pencil icon on right to see the instance config. When you see the error copy the json. check for "common.token".
Then enter the token in admin panel and save, adapter should restart.
check the json again- token now in?
restart telegram?  working? if not check object again
restart js-controller - check json again

Under system.adapter.telegram.0 is token available (encrypted), but not "commn.token"(?):
"native": {     "server": "false",     "port": "8443",.      ...     "answerTimeoutSec": 60,     "token": "$/aes-192-cbc:fe3f6ae85b46735e8c158e4a5a183580:1b9ee6dab9d4b6c5506a880462d10a6b11aa58071d0dbb2ea4cababbecfc06b39e4d079037dfdf5a0bad81d95b1eee10"   },
The token is in the instance settings on the morning after router-restart in the night empty again (iob will be not restartet).
Log:
2024-06-26 05:59:40.935  - info: host.iobroker instance system.adapter.telegram.0 started with pid 26444 2024-06-26 05:59:42.506  - info: hm-rpc.0 (26405) starting. Version 1.17.0 in /opt/iobroker/node_modules/iobroker.hm-rpc, node: v18.19.0, js-controller: 5.0.19 2024-06-26 05:59:43.050  - info: hm-rpc.0 (26405) xmlrpc server is trying to listen on <IP_ADDRESS>:2001 2024-06-26 05:59:43.056  - info: hm-rpc.0 (26405) xmlrpc client is trying to connect to <IP_ADDRESS>:2001/ with ["http://<IP_ADDRESS>:2001","iobroker:hm-rpc.0:f450d720733ca0e751df7aaee8207549"] 2024-06-26 05:59:43.186  - info: hm-rpc.0 (26405) xmlrpc <- system.listMethods ["iobroker:hm-rpc.0:f450d720733ca0e751df7aaee8207549"] 2024-06-26 05:59:43.204  - info: hm-rpc.0 (26405) xmlrpc <- listDevices ["iobroker:hm-rpc.0:f450d720733ca0e751df7aaee8207549"] 2024-06-26 05:59:43.327  - info: hm-rpc.0 (26405) xmlrpc -> 52 devices 2024-06-26 05:59:43.359  - info: hm-rpc.0 (26405) Connected 2024-06-26 05:59:47.245  - info: alexa2.0 (26429) starting. Version 3.26.5 in /opt/iobroker/node_modules/iobroker.alexa2, node: v18.19.0, js-controller: 5.0.19 2024-06-26 05:59:47.326  - info: alexa2.0 (26429) Starting Alexa2 adapter ... it can take several minutes to initialize all data. Please be patient! A done message is logged. 2024-06-26 05:59:48.398  - info: telegram.0 (26444) starting. Version 3.6.0 in /opt/iobroker/node_modules/iobroker.telegram, node: v18.19.0, js-controller: 5.0.19 2024-06-26 05:59:48.565  - error: telegram.0 (26444) Token is not set!
For me is not clear where I can see the error copy the json - in log is nothing about.
By the way: iobroker ist a docker container (see my first post above) - but other adapter keeps their settings.

Ok. instance parameters are store at local. So this is OK.
Does this entry exist when the problem occures too or is it removed / changed?
And if I read this correctly:

restarting the telegram instance works and there is no message about an unset token
the complete ioBroker instance is not restarted

So what restart do you refer to when you wite: '"telegram" status is every day/by restart warning' ?
Guess you refer to a restart of your router. Please confirm.
Is the token entry at the instance object empty or unchanged after the router restart?

I referred to a restart of my router. The token entry at the instance object empty at the morning after router and telegram restart.
I've checked without telegram restart in the night is everything ok - so was last night.
I'll check the logs of few next days and reopen the issue if wrong again.

@marian-t-web-de The token is a protected attribute.
Do you start/stop/restart the instance automatically by using setObject?

Yes, I've forgotten to replace it with extendObject() at one place.
This issue can therefore be closed, thanks for Your help.


About AppChannel

Hi all, our team and I have been playing with Dapr for a while and we have a question about the AppChannel.
For the http channel implementation, all requests go through the InvokeMethod API and that works fine. For the grpc implementation, only service method invokation is implemented base on AppChannel, all other rpc calls like ListTopicSubscriptions simply go through the raw grpc client.  This makes mocking certain app api unnecessarily complex since we need to mock GRPC app and http app separately.
Ideally, AppChannel should be the layer that abstract away all communications to the App Process and provide a set of APIs just like the grpc AppCallbackClient does (I mean same for http).
Based on this cleaner layered abstraction, we can start experimenting with some more interesting ideas, such as:

use different transport/protocol implementation. HTTP is too heavy.
local message passing.

Any thoughts on this?

@hongjic That's good suggestion. e.g. Having the abstraction layer, you would probably use light protocol, e.g. unix-socket, to communicate with your app.
As you see, AppChannel design is pretty generic, which we could extend to the other protocol relatively easy. But we are heading to 1.0 release now so that we do not have the time to consider design change.
BTW, can you elaborate more on your application scenario ?
cc/ @yaron2 @orizohar @msfussell @mchmarny


Fixes for mobile combobox focus and input reset behavior

Closes #1833
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

Will add tests when approach is approved

Behavior seems good to me!


Wrong include in PieElement.h

In PieElement.h you include Foundation.h while UIColor is used, which is part of UIKit.h . This can product problems when using MagicPie with Swift.
Can you replace
#import <Foundation/Foundation.h>
with
#import <UIKit/UIKit.h>
Thanks!

Hi.
Sorry for too late response, seams I missed this issue in notifications. I added #import <UIKit/UIKit.h> in last version.


Add serde support

This fixes #108, although there wasn't much to fix. serde just works out of the box with bitflags.
This pull request simply adds some tests to ensure support for serde will work in the future, and also acts as an example.

Thanks!


Added entries for prifddinas mining sites.

Closes issue #10987
Adds two entries to the MiningSiteLocation enumeration so that the proper labels appear on the "Prifddinas" map and are consistent with those shown on the "Runescape Surface" map.

Makes sense. New commit places them beside the surface map entries.


MAP-36: Look up non-asociations by offender no instead of booking ID

Previously, non-associations for cell moves were looked up via the current booking number for the offender, meaning that potentially relevant non-associations from previous bookings were not shown. It has been changed to look them up via the offender number, which should include non-associations from previous bookings too.
I have hidden this behind a feature flag, as we in the MAP team are new to the project and I don't want to block other teams from releasing to production while we test in dev.

tagging @ministryofjustice/hmpps-non-associations for their visibility


Long Running Jobs

Use Case
As a user running jobs on the network, I need to run jobs that take a long time to complete. For example, 2 days.
Tasks
TODO
Notes

The Example workload is running on a 16GB machine and takes two days.
There shouldn't be anything to prevent this from working now, but obviously infra changes or software updates would force recreation of the node or server that is running the job. So I guess we need some kind of drain and rolling update, to make sure we don't update whilst jobs are in flight.

@lukemarsden @binocarlos does the localdb help with this?

Once localdb supports sqlite it will, sorta, but we also need to switch our
deployment model to mutate VMs rather than swapping them out and support
resuming tracking jobs (long running containers) after a daemon restart.
On Wed, 3 Aug 2022, 17:57 David Aronchick, @.***> wrote:

@lukemarsden https://github.com/lukemarsden @binocarlos
https://github.com/binocarlos does the localdb help with this?
—
Reply to this email directly, view it on GitHub
https://github.com/filecoin-project/bacalhau/issues/427#issuecomment-1204228722,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACATUSI2QDS5HIPIPXPOV3VXKQGHANCNFSM55AZHFPA
.
You are receiving this because you were mentioned.Message ID:
@.***>

This is tricky and will depend on the framework running the job. If the job is just a pure python code running in a docker container for example, then we will lose progress whenever the compute node bounces. If on the other hand the job is a Spark or Flink application, then these frameworks support checkpointing and restoring from snapshots during deployments or failovers. We have discussed that Spark and Flink can be executor engines where the job is executed in a cluster owned by a single Compute Provider.
The other way would be to break the long running job into separate tasks in a DAG, and allow the DAG executor to resume from the last successful task during a failover


Strange PyPrep/Ransac outputs

Hi there,
I am building a large pipeline for EEG resting-state preprocessing. I am using Pyprep to detect bad channels on some clinical datasets (quite noisy to start with). When I run the function and check the outputs for :

noisy_channels_original
interpolated_channels
still_noisy_channels

I would expect here for 2 and 3 to be a subset of of 1. However, I sometimes find the interpolated list (2) to be longer than the original list of channels (1), and the final list (3) to be often empty. At other times, 3 doesn't contain the channels flagged in 1 that were not interpolated.
Have others encountered this issue?
Thanks for the feedback

Hi @golnousha, thanks for letting us know this is a point of confusion! Helps us know what we need to focus on in the documentation.
First of all, are your EEG recordings average-referenced prior to PyPREP? If it isn't, that likely explains the discrepancies you're seeing: noisy_channels_original is the initial detected noisy channels prior to PyPREP's internal average referencing. This is because PyPREP wants to make sure that any flat or NaN-containing channels are ignored when calculating the initial average reference. I've encountered this big-time with BioSemi recordings, where the initial CMS/DRL referencing masks most bad-by correlation and bad-by-RANSAC channels on its first pass.
Also, even if the original signals are average-referenced, (2) will still generally be longer than (1). This is because of PyPREP's iterative approach to finding a "clean" reference signal (copied here from the docs):

First, an initial pass of noisy channel detection is performed to identify channels bad by NaN values, flat signal, or low SNR: the data is then average-referenced excluding these channels. These channels are subsequently marked as “unusable” and are excluded from any future average referencing.
Noisy channel detection is performed on a copy of the re-referenced signal, and any newly detected bad channels are added to the full set of channels to be excluded from the reference signal.
After noisy channel detection, all bad channels detected so far are interpolated, and a new estimate of the robust average reference is calculated using the mean signal of all good channels and all interpolated bad channels (except those flagged as “unusable” during the first step).
A fresh copy of the re-referenced signal from Step 1 is re-referenced using the new reference signal calculated in Step 3.
Steps 2 through 4 are repeated until either two iterations have passed and no new noisy channels have been detected since the previous iteration, or the maximum number of reference iterations has been exceeded (default: 4).

In a nutshell, this means that PyPREP will usually end up with more detected bad channels after re-referencing then before, since removing the influence of some noisy channels on the average reference signal can reveal others that weren't detected earlier (hence the iterative approach).
Hope that helps! Also, please make sure you're using the latest GitHub version of PyPREP for any production work: we've recently fixed a lot of bugs that are still present in the current PyPI release.


10.x backport

@apoelstra. We had lots of CI fixes particularly for fuzz fixes, strict dead code errors. Is it possible to locally test the package and cut a release?

Yep, I will locally test things.

The MSRV on this old version is 1.41.1. Your use of the matches! macro breaks it. Can you change the unit test?

@apoelstra changed this. Can you try testing again

I think it's good now. The CI setup on this old version is pretty weird in a few ways (different MSRV for std vs nostd, unstable feature that requires nightly) so I am not 100% certain. But after reading the diff and doing some spot-checks and running my local CI on it and determining that failures are "expected", I think we're good to go. Will merge and release.

Tagged and published.