text:
relative path to flutter_rust_bridge.yaml / rust_root is not working

Describe the bug
Using a relative path, as in
› flutter_rust_bridge_codegen generate --config-file ../flutter_rust_bridge.yaml

fails with
Error: When compute_mod_from_rust_path(code_path="../app_core/src/application/bridge/frb_generated/mod.rs", base_dir="/Users/patmuk/code/own/sherry/system/sherry/app_core/src")

Caused by:
    prefix not found

This happens as well with other means of specifying a relative path, e.g. as rust_root in the flutter_rust_bridge.yaml or within an build.rs file.
Steps to reproduce
› flutter_rust_bridge_codegen generate --config-file ../flutter_rust_bridge.yaml
Logs
Error: When compute_mod_from_rust_path(code_path="../app_core/src/application/bridge/frb_generated/mod.rs", base_dir="/Users/patmuk/code/own/sherry/system/sherry/app_core/src")

Caused by:
    prefix not found

### Expected behavior

The base dir can be matched even if the path is relative.

### Generated binding code

_No response_

### OS

Sonoma 14.3.1.

### Version of `flutter_rust_bridge_codegen`

2.0.0.

### Flutter info

```shell
› flutter doctor -v
[✓] Flutter (Channel stable, 3.22.2, on macOS 14.3.1 23D60 darwin-arm64, locale en-US)
    • Flutter version 3.22.2 on channel stable at /Users/patmuk/code/own/sherry/system/sherry/.toolchain/flutter-local/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 761747bfc5 (3 weeks ago), 2024-06-05 22:15:13 +0200
    • Engine revision edd8546116
    • Dart version 3.4.3
    • DevTools version 2.34.3

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /nix/store/4yaia9206kv08wp96zz51nf3fy4cnkrz-android-sdk-env/share/android-sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /nix/store/4yaia9206kv08wp96zz51nf3fy4cnkrz-android-sdk-env/share/android-sdk
    • ANDROID_SDK_ROOT = /nix/store/4yaia9206kv08wp96zz51nf3fy4cnkrz-android-sdk-env/share/android-sdk
    • Java binary at: /nix/store/89mg4clgnz0hxakm1jn0qz7gzhbfva0v-zulu-ca-jdk-17.0.10/bin/java
    • Java version OpenJDK Runtime Environment Zulu17.48+15-CA (build 17.0.10+7-LTS)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
    • Xcode at /Applications/Xcode-15.3.0.app/Contents/Developer
    • Build 15E204a
    • CocoaPods version 1.15.2

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

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).

[✓] VS Code (version 1.79.2)
    • VS Code at /Users/patmuk/Library/Mobile Documents/com~apple~CloudDocs/Desktop/Visual Studio Code.app/Contents
    • Flutter extension can be installed from:
      🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[✓] Connected device (4 available)
    • iPhone 15 (mobile)              • D8014A3D-781A-4EC7-9113-3B50DF17BCAB • ios            • com.apple.CoreSimulator.SimRuntime.iOS-17-4 (simulator)
    • macOS (desktop)                 • macos                                • darwin-arm64   • macOS 14.3.1 23D60 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad                • darwin         • macOS 14.3.1 23D60 darwin-arm64
    • Chrome (web)                    • chrome                               • web-javascript • Google Chrome 125.0.6422.142

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Version of clang++
No response
Additional context
In my setup the rust folder is outside of the flutter folder, as in
/users/patmuk/code/myProject/rust
/users/patmuk/code/myProject/flutter

As a workaround I moved flutter_rust_bridge.yaml to /users/patmuk/code/myProject/ (was in the flutter folder), and hid build.rs.
I assume that this can be fixed quite easily - but at the moment my time does not allow me to do so myself :(

I assume that this can be fixed quite easily

I think so, possibly just add one line to resolve the relative path into an absolute path and done.

but at the moment my time does not allow me to do so myself :(

No worries! Do you have interest in PR later (since this is a good-first-issue)? Alternatively, I will work on it later in the next batch (not super high priority since this has workaround)
Workaround:
flutter_rust_bridge_codegen generate --config-file $(pwd)/../flutter_rust_bridge.yaml

No worries, take your time!

Issue still exist, keeping the ticket alive

@fzyzcjy is this solved in the latest master? I just looked into the code for fixing this issue but the frb_examples are working ...

No I did not touch it (or at least do not explicitly do so). But if it is fixed then looks good!

Btw does 2.4 work for you?

No - I guess I executed the frb_examples wrongly, I am now using frb_internal :)
I am still getting
--- stderr
  Error: When compute_mod_from_rust_path(code_path="../app_core/src/application/bridge/frb_generated/mod.rs", base_dir="/Users/patmuk/code/own/sherry/examples/flutter-rust-bridge_crux_style/app_core/src")

  Caused by:
      prefix not found

when referring to ../flutter_rust_bridge.yaml.

Ok, then feel free to PR, or I will do it later (but again not of high priority since this is easily workaround-able)

authors: fzyzcjy patmuk


text:
How to change time from 24hr to AM/PM

Right now data picker is showing 24hr timing but I would like to make it AM/PM time, couldn't find a way to do that.

http://momentjs.com/docs/#/i18n/changing-locale/
moment.locale('tr', {
longDateFormat : {
LT : "HH:mm",
LTS : "HH:mm:ss",
L : "DD/MM/YYYY",
LL : "D MMMM YYYY",
LLL : "D MMMM YYYY LT",
LLLL : "dddd D MMMM YYYY LT"
}
}

source: gharchive/issue

license: mit

license_type: permissive

license_source: bigquery


text:
Fix various bugs on develop

fix logging
create .klio folder in home directory when it does not exist
fix logic when klio.yaml is not found in project directory

Coverage report
github.com/g2a-com/klio/internal/dependency/manager/error.go:9:		Error				100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:45:	NewManager			0.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:57:	GetUpdateFor			100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:93:	InstallDependency		72.5%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:196:	GetInstalledCommands		100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:221:	downloadFile			68.8%
github.com/g2a-com/klio/internal/dependency/registry/common.go:35:	findHighestMatching		100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:53:	isCompatible			100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:57:	isMoreSpecific			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:20:	NewLocal			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:29:	Update				92.9%
github.com/g2a-com/klio/internal/dependency/registry/local.go:53:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:57:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:61:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:22:	NewRemote			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:31:	Update				90.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:67:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:71:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:75:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:11:	Match				100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:17:	GreaterThan			100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:23:	getExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:31:	getMinorAndPatchConstraints	100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:39:	getMajorConstraints		100.0%
github.com/g2a-com/klio/internal/project/schema.go:19:			NewDefaultConfig		100.0%
github.com/g2a-com/klio/internal/project/schema.go:27:			MarshalYAML			60.0%
github.com/g2a-com/klio/internal/project/schema.go:86:			minimalConfig			100.0%
github.com/g2a-com/klio/internal/project/schema.go:104:			UnmarshalYAML			54.5%
github.com/g2a-com/klio/internal/project/util.go:11:			LoadProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:20:			SaveProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:25:			CreateDefaultProjectConfig	83.3%
total:									(statements)			74.4%

Coverage report
github.com/g2a-com/klio/internal/dependency/manager/error.go:9:		Error				100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:45:	NewManager			0.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:57:	GetUpdateFor			100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:93:	InstallDependency		72.5%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:196:	GetInstalledCommands		100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:221:	downloadFile			68.8%
github.com/g2a-com/klio/internal/dependency/registry/common.go:35:	findHighestMatching		100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:53:	isCompatible			100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:57:	isMoreSpecific			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:20:	NewLocal			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:29:	Update				92.9%
github.com/g2a-com/klio/internal/dependency/registry/local.go:53:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:57:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:61:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:22:	NewRemote			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:31:	Update				90.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:67:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:71:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:75:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:11:	Match				100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:17:	GreaterThan			100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:23:	getExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:31:	getMinorAndPatchConstraints	100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:39:	getMajorConstraints		100.0%
github.com/g2a-com/klio/internal/project/schema.go:19:			NewDefaultConfig		100.0%
github.com/g2a-com/klio/internal/project/schema.go:27:			MarshalYAML			60.0%
github.com/g2a-com/klio/internal/project/schema.go:86:			minimalConfig			100.0%
github.com/g2a-com/klio/internal/project/schema.go:104:			UnmarshalYAML			54.5%
github.com/g2a-com/klio/internal/project/util.go:11:			LoadProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:20:			SaveProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:25:			CreateDefaultProjectConfig	83.3%
total:									(statements)			74.4%

Coverage report
github.com/g2a-com/klio/internal/dependency/manager/error.go:9:		Error				100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:45:	NewManager			0.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:57:	GetUpdateFor			100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:93:	InstallDependency		72.5%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:196:	GetInstalledCommands		100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:221:	downloadFile			68.8%
github.com/g2a-com/klio/internal/dependency/registry/common.go:35:	findHighestMatching		100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:53:	isCompatible			100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:57:	isMoreSpecific			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:20:	NewLocal			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:29:	Update				92.9%
github.com/g2a-com/klio/internal/dependency/registry/local.go:53:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:57:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:61:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:22:	NewRemote			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:31:	Update				90.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:67:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:71:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:75:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:11:	Match				100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:17:	GreaterThan			100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:23:	getExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:31:	getMinorAndPatchConstraints	100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:39:	getMajorConstraints		100.0%
github.com/g2a-com/klio/internal/project/schema.go:19:			NewDefaultConfig		100.0%
github.com/g2a-com/klio/internal/project/schema.go:27:			MarshalYAML			60.0%
github.com/g2a-com/klio/internal/project/schema.go:86:			minimalConfig			100.0%
github.com/g2a-com/klio/internal/project/schema.go:104:			UnmarshalYAML			54.5%
github.com/g2a-com/klio/internal/project/util.go:11:			LoadProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:20:			SaveProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:25:			CreateDefaultProjectConfig	83.3%
total:									(statements)			74.4%

Coverage report
github.com/g2a-com/klio/internal/dependency/manager/error.go:9:		Error				100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:45:	NewManager			0.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:57:	GetUpdateFor			100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:93:	InstallDependency		72.5%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:196:	GetInstalledCommands		100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:221:	downloadFile			68.8%
github.com/g2a-com/klio/internal/dependency/registry/common.go:35:	findHighestMatching		100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:53:	isCompatible			100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:57:	isMoreSpecific			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:20:	NewLocal			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:29:	Update				92.9%
github.com/g2a-com/klio/internal/dependency/registry/local.go:53:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:57:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:61:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:22:	NewRemote			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:31:	Update				90.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:67:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:71:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:75:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:11:	Match				100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:17:	GreaterThan			100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:23:	getExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:31:	getMinorAndPatchConstraints	100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:39:	getMajorConstraints		100.0%
github.com/g2a-com/klio/internal/project/schema.go:19:			NewDefaultConfig		100.0%
github.com/g2a-com/klio/internal/project/schema.go:27:			MarshalYAML			60.0%
github.com/g2a-com/klio/internal/project/schema.go:86:			minimalConfig			100.0%
github.com/g2a-com/klio/internal/project/schema.go:104:			UnmarshalYAML			54.5%
github.com/g2a-com/klio/internal/project/util.go:11:			LoadProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:20:			SaveProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:25:			CreateDefaultProjectConfig	83.3%
total:									(statements)			74.4%

Coverage report
github.com/g2a-com/klio/internal/dependency/manager/error.go:9:		Error				100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:45:	NewManager			0.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:57:	GetUpdateFor			100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:93:	InstallDependency		72.5%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:196:	GetInstalledCommands		100.0%
github.com/g2a-com/klio/internal/dependency/manager/manager.go:221:	downloadFile			68.8%
github.com/g2a-com/klio/internal/dependency/registry/common.go:35:	findHighestMatching		100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:53:	isCompatible			100.0%
github.com/g2a-com/klio/internal/dependency/registry/common.go:57:	isMoreSpecific			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:20:	NewLocal			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:29:	Update				92.9%
github.com/g2a-com/klio/internal/dependency/registry/local.go:53:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:57:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/local.go:61:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:22:	NewRemote			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:31:	Update				90.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:67:	GetExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:71:	GetHighestBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/remote.go:75:	GetHighestNonBreaking		100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:11:	Match				100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:17:	GreaterThan			100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:23:	getExactMatch			0.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:31:	getMinorAndPatchConstraints	100.0%
github.com/g2a-com/klio/internal/dependency/registry/version.go:39:	getMajorConstraints		100.0%
github.com/g2a-com/klio/internal/project/schema.go:19:			NewDefaultConfig		100.0%
github.com/g2a-com/klio/internal/project/schema.go:27:			MarshalYAML			60.0%
github.com/g2a-com/klio/internal/project/schema.go:86:			minimalConfig			100.0%
github.com/g2a-com/klio/internal/project/schema.go:104:			UnmarshalYAML			54.5%
github.com/g2a-com/klio/internal/project/util.go:11:			LoadProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:20:			SaveProjectConfig		0.0%
github.com/g2a-com/klio/internal/project/util.go:25:			CreateDefaultProjectConfig	83.3%
total:									(statements)			74.4%

source: gharchive/pull-request

license: MIT

license_source: github-api


text:
Rich type representation in Attributes

In the DWG call today the question came up about how to perform message typing in a more dynamic manner. You can see one way of performing this task here by using the protobuf oneof field and reflection.  This PR attempts to close #607 by adding richer type representation, and also close #445 by adding integers as one of the available types. Big thanks to @calbach and @diekhans for providing the basis for this in Sequence Annotations, this PR extends that work to the rest of the data model.
The info field is used on many GA4GH messages and acts as a way to "tag" a message with data that are have not been represented by the named fields. The field items are lists of internal protobuf types, and their type information is retained with the message itself. This allows code to inspect the info field and perform tasks depending on the type.
With Sequence Annotations we saw the addition of a similar spirited effort that uses GA4GH types in a protobuf oneof field to allow typed information to be stored in a Feature message. This improves data interchange by allowing ExternalIdentifier or OntologyTerm messages to be used as values in the attributes map.
This PR attempts to unify the approach by including the strengths of the ListValue method used by the info field with the extensibility of the Attributes approach from the Features protocol.
To carry this out, the Attributes message is moved to metadata.proto so that it can be used amongst the other protocols. The info field was replaced for messages that had it with the field attributes. I've renamed the vals field to attr, since I found the repetition of vals...values confusing in code.
I've also expanded the available types in an attribute value message (int32, int64, bool, double, null). This list can be extended with other GA4GH messages as needed.
Added attributes to the Variant Annotation Set message and RNA expression messages.
Please view the iPython notebook example that shows how to work with the attributes field. More information on the oneoffield can be viewed here.
I've included an example below of how JSON serialization of the attributes field as it appears for the variant in json_intro.rst. I hope this addresses any concerns that fidelity of the data is lost when using JSON serialization:
      "attributes": {
          "attr": {
              "numberOfPapers": {
                  "values": [
                      {"int32Value": 11}
                  ]
              },
              "variantFacts": {
                  "values": [
                      {"stringValue": "is_long"},
                      {"stringValue": "is_interesting"}
                  ]
              }
          }
      }

+1 I really like this idea.
First, since one of the languages of the genetics community (python) is untyped anything that brings some degree of type integrity is welcome.
Second, standardizing this method of creating space for secondary (and unforeseen) attributes that people need to store is a big plus as well.
One shortcoming that was discussed was the storage of arbitrary object types, but this isn't supported any better in the current implementation. In either case, users would need to serialize their object to text and deserialize it later to work on it. I think this is not a primary use case for the info and the vast majority of time users will be storing primitive types.

Thanks @andrewjesaitis, that's right, you'll still be able to store arbitrary JSON strings in string_value messages as is done now.

On the MTT side, we have almost exactly the same structure:
// characteristics object uses lists of BioCharacteristic objects to describe
// diseases and phenotypes associated with this Individual.
Characteristics characteristics = 5;
// BioCharacteristic is a prototype wrapper object for single instances
// of phenotypes, diseases ... which may be described through one or several
// ontology terms
message BioCharacteristic {
string description = 1;
repeated OntologyTerm ontologyTerms = 2;
}
// Characteristics
message Characteristics {
repeated BioCharacteristic diseases = 1;
repeated BioCharacteristic phenotypes = 2;
}
We're happy updating the names of the attributes if this is helpful.
@mbaudis created a new branch, see https://github.com/ga4gh/schemas/blob/metadata-bio-characteristics/src/main/proto/ga4gh/bio_metadata.proto. It would be good to coordinate, use it across and merge the branch.

To clarify, we propose to add an object of type biocharacteristic to the values allowed for attributes.

How often are typed values needed? Is this overkill?

My question gets at documenting the motivation for this change. The discussion is scattered in several PRs and issues. I will try to summarize: The motivation is to be able to precisely represent the data and to be able to recreate the original state of the data (roundtrip), e.g. if passing variants from a vcf file, then be able to recreate the vcf  file from the data in the message. Therefore, there is a need to have lists of typed values that can be scalar or array values. Also, the data can be hierarchical.
The drawback of this approach is that it is complicated and will require more complex processing just to get a simple value. Will this impede acceptance of GA4GH by consumers of the data? Is the goal of roundtrip even attainable? The formats are not even precisely defined (see #505).
My impression of the info field was that it is for metadata, most often a string value. What if we keep info as well as adding attributes where it is necessary?

Thanks @ejacox, great questions! The basic problem is that folks want to be able to tag with Ontology Terms, when they're available, in an open ended kind of way. The other messages are aspirational and don't interfere with the normal use cases.
The attributes message as it as used in sequence annotations provides the highest fidelity of interchange, and this PR brings that feature to the rest of the API. It answers the question, "what do I do with my JSON" in as final of a manner as we can do at this time.
In terms of keeping the info field, the attributes message is the same for the use case of the info field. I chose to rename it because I believe it's semantically more clear. The differences from the current info field are being able to nest keys and use some GA4GH messages as tags. https://github.com/ga4gh/schemas/pull/700/commits/a4a8bcc8c69a18efb8f5624129a0e281a0a512d0#diff-4fd17066615aa04304c49ac00877970bR104
dataset.info['version'].values.add().string_value = "version"
###
dataset.attributes.attr['version'].values.add().string_value = "version"
dataset.attributes.attr['species'].values.add().ontology_term.MergeFrom(myOntologyTerm)

You can compare the proto that backs the info field with the contents of this PR (https://github.com/google/protobuf/blob/master/src/google/protobuf/struct.proto#L93). Hopefully this will be largely code neutral and adds features that are needed to properly model loosely structured metadata. It also provides a path to better define the types represented in the metadata, but like the info field, will likely be used for string: [string] mappings much of the time.
The feature that results in the reference server is being able to provide an interface for interchanging JSON metadata, or any other hierarchically structured message of a mixture of GA4GH and internal protobuf types. Inspirations for nesting keys was developed to interchange structured tags in tagstorm format http://hgwdev.cse.ucsc.edu/~kent/tagStorm/testTagStorm.html .
A common use case request has been modeling loosely structured data, especially metadata, for example when interchanging phenotype data. I hope others will offer their perspective.
At first I found these data structures (info field) extremely overwrought for interchanging simplistic data. I have experience working with tag-bags that map strings to strings, and not being able to do this in just a few characters of code was frustrating and added a steep learning curve. I was able to finally convince myself when working with variant set metadata in the variant annotations API. Often, analyses provide annotations in an unstructured manner, and these annotations were often nested arrays that needed to be split. It was my hope that no one would ever have to guess about whether a field is comma separated, contains booleans or strings, ontology terms or external identifiers, when using this API.
Hopefully, clients will obscure the type reflection that one would like when working with these attributes. Thanks for your considerations @ejacox. @bwalsh had stated something similar about the info field in the past, which I understand. However, I believe that type security, hierarchy, and using our own type system will enable a lot of common interchange use cases.

Following discussion with @ejacox, we will be modifying this PR to allow other metadata entries to be gathered together. https://github.com/ga4gh/schemas/pull/690#issuecomment-240509046
The new signature will be variant.metadata.attributes, which will allow us to store all shared metadata elements on a single message in the proto.

Hmmm. Don't think I really understand the purpose of this and think it may obscure the original intention of the info field.
If I remember correctly, the purpose of the info field was to store data defined in source that didn't explicitly have a place in the schema. Moving it to be under a per record metadata field seems to change or at least obscure this purpose, since it suggests that this is data about the record rather than data "of" the record but that didn't have an explicit field for it.
As an example, I don't really view the data in a VCF's INFO field as metadata, it is data about a variant. I wouldn't expect Sift or Polyphen scores to be metadata, but under this change it is where they would be stored.

We proposing to keep the timestamp info explicit (not in attributes/info). Rather, any info (metadata) that applies to data in general will be put into a metadata message. Explicit fields will still be explicit.
Our motivation is to gather all purpose fields in one place. With timestamps, we were beginning to put them all over the place. When we wanted to change them, we needed to touch many messages. This way, any future changes (type change, description change, etc.) to timestamps will occur in one place.
Does that address your concerns and still align with original intent @andrewjesaitis ?

An alternative would be to add the metadata message that has named metadata fields like created and updated and then maintain the attributes at the level they are.
Given the Variant Set Metadata message uses the word "metadata", I can't mount much of an argument against the suggestion to use it as an accessor for the attributes.
Ideally only developers have to see this part of the model, and if you look at how applications have to reconcile the meaning of tags in the Variant protocol, it might make more sense to call it metadata as opposed to info, I believe. It would be great to provide a similar self-description protocol in other parts of the API. We need to try to be VCF compliant, but not rely on it.
I would identify one problem as mixing the term "metadata" here, because the variant set metadata serves a number of purposes. It has ID resolution, descriptions, and type definitions (to some extent). So a variant set provides metadata about a variant's attributes, and a server provides metadata about a variant's record.
As pointed out by @ejacox, we need to better specify the use cases around the timestamp. It's not clear if it is meant to be provided by the file. If it is left up to interpretation, it is a server specific message about a record, and maybe should go in a different named field: record_metadata.

@ejacox I do not get this. Obviously, in GA4GH we use "metadata" roughly as "everything but the sequence", not just as describing housekeeping data associated with a message.
And this is a view shared broadly outside GA4GH, when talking about data sharing concepts etc.
So, please, try not to mix this into "named attributes and then accompanying metadata" or such.
For time stamps and ids, I personally prefer the use of "housekeeping" attributes. The current info field just is for unassigned data.
So general agreement with @david4096, though IMO created/updated (please read up all the scattered discussions & history, including previous better naming record_created ...) are part of the record (and technically different from server time stamps; e.g you may send a record to another host without changing the values).

I think I'm in agreement with @david4096 suggestion of keeping attributes as a typed key-value store to hold data that doesn't explicitly have a field in the model. So I think this PR currently satisfies that.
If we want to move timestamps to a separate metadata message that should be a separate PR. I'll throw my timestamp thoughts on the other issue to keep this PR focused.

authors: andrewjesaitis david4096 ejacox mbaudis mcourtot


text:
Mapping for Mad Catz Fightpad SFxT

As said in the title, here is the mapping I have for my Mad Catz Fightpad "Street Fighter x Tekken". I thought I had already reported it but I don't see it in the list.
03000000ad1b00002ef0000090040000,Mad Catz Fightpad SFxT,platform:Linux,a:b0,b:b1,y:b3,x:b2,start:b7,guide:b8,back:b6,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpleft:h0.8,dpdown:h0.4,dpright:h0.2,lefttrigger:a2,righttrigger:a5
I assume it should be the same for all Mad Catz Fightpads and not the "Street Fighter x Tekken" editions specifically but just in case...

Merged, thanks!

authors: gabomdq terzag

license: Zlib


text:
Don't zoom when the image is wrapped in an  tag.

Hello,
I'm currently having this really annoying "bug", when if you click on an image that is inside an  tag it won't let you click the image, and will just zoom into it. Is there a way I can make the plugin ignore images wrapped inside an  tag?

I was having the same issue and realized that, yes, you can do this using the selector to enable zoom only for img tags that are not children of an a tag:
      zoom: {
        selector: '.markdown :not(a) > img',
        background: {
          light: 'rgb(255, 255, 255)',
          dark: 'rgb(50, 50, 50)'
        },
      }

authors: scottamain walkxcode


text:
Stupid tuple question.

Thanks so much for writing this! I'm trying to hack w Python ctypes which might be a good expectation test, and baseline benchmark. Lol. What is the tuple syntax?
from python import Python

def main():
    let ctypesu = Python.import_module("ctypes.util")
    let ctypes = Python.import_module("ctypes")
    let libc = ctypes.CDLL(ctypesu.find_library("c"))
    let getopt = libc.getopt
    let getopt.argtypes = (ctypes.c_int, ctypes.POINTER(ctypes.c_char_p), ctypes.c_char_p)

Sure, you can find an example here: https://github.com/gabrieldemarmiesse/mojo-stdlib-extensions/blob/master/stdlib_extensions/datetime/init.mojo#L116

Sorry watching p99conf talks. Will try!
This has been useful in spying on mojo compiler for OSX.
 sudo dtruss mojo build hello.🔥 2>&1 1>/dev/null | grep

thanks! I'll close this issue then!

authors: chadbrewbaker gabrieldemarmiesse


text:
Typescript Refactored Version.

Why?  Why not!??

https://www.youtube.com/watch?v=xDJWuuLCHIo

Whoa, I watched your video, and this seems great! A huge improvement in code quality all around, and you probably fixed countless unknown bugs. I'd appreciate all those identically-described commits being squashed into one, but apart from that I'd love to merge this.
I'm going to wait and see what the other maintainers (cc @gabrielecirulli, @sigod) think of this before merging it.

Interesting work, I'll have a look later this week. Just to set
expectations right: I can't promise that we merge this, as it is still a
radical change. I will give it proper consideration though.
On Wed, 16 Nov 2016 at 11:30 PM, Anna Harren notifications@github.com
wrote:

Whoa, I watched your video, and this seems great! A huge improvement in
code quality all around, and you probably fixed countless unknown bugs. I'd
appreciate all those identically-described commits being squashed into one,
but apart from that I'd love to merge this.
I'm going to wait and see what the other maintainers (cc @gabrielecirulli
https://github.com/gabrielecirulli, @sigod https://github.com/sigod)
think of this before merging it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gabrielecirulli/2048/pull/425#issuecomment-261093542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA2E-y3UZTNHjfwuuOXT711DrrdSNJAsks5q-4PxgaJpZM4K0Nsc
.

@gabrielecirulli I totally understand if this goes too far LOL.|
But I think where it really gets interesting is class inheritance.  By using Point2D as a base class for example.
You'll also find as any 'game' or app like this gains complexity, you can really benefit from the reuse.
Someone should pull and test this branch to make sure I'm not crazy. :P

You should .gitignore any compiled file / source map. Would make this pr much smaller and cleaner.

@Andrew1431, I could, but then it wouldn't work straight out of the box.
Currently, this version doesn't change where the JS files lived.  So I'm more inclined to keep the built files.  That way if someone doesn't have TS, they can still download and run/test it.

##Heq

var a = 10;
a ++;

aaaaaaa
vvvvvvvv

_job_offer_袠薪褋邪泄褌褍 袗谢械泻褋邪薪写褉�.pdf

authors: Andrew1431 Insayt electricessence gabrielecirulli iirelu


text:
Chessboard example has problems in Safari

I can't reproduce this. Can you post your exact Safari version, OS X version, screen resolution, and whether your screen is Retina? Thanks!

My system should be up-to-date (on May 19th 2015):
Safari 8.0.6
OS X 10.10.3
Screen Resolution 1440 x 900 on a Retina display

Anything unusual in your configuration? Like an external monitor.
I'm updating Safari from 8.0.5 but I doubt that's the issue..
Any problems in other browsers?

Not having this problem on 8.0.6 either. What's your hardware?

Hm… I tested it now on my external display too, which is the current Thunderbolt Display from Apple. It doesn't work either, whether I’m using both displays or just one of them.
Chrome and Firefox work fine.

On 19 May 2015, at 14:36, Dan Abramov notifications@github.com wrote:
Not having this problem on 8.0.6 either. What's your hardware?
—
Reply to this email directly or view it on GitHub https://github.com/gaearon/react-dnd/issues/155#issuecomment-103470548.

Ok, found the problem: https://chrismatic.io/ublock/ https://chrismatic.io/ublock/ This is my current adblocker and disabling it fixes the problems. However I’m using it in Chrome as well, which is working fine.

On 19 May 2015, at 14:36, Dan Abramov notifications@github.com wrote:
Not having this problem on 8.0.6 either. What's your hardware?
—
Reply to this email directly or view it on GitHub https://github.com/gaearon/react-dnd/issues/155#issuecomment-103470548.

Thanks. Indeed, ublock was overriding the Image constructor so the instanceof check failed. I replaced it with some duck typing, and it should be more correct now. This will get into the next minor release.

This should be fixed in 1.1.
Please verify.

Will look into it when I'm back home. :)

Is the new version already used for the Chessboard example?
I'm now getting following errors - with disabled extensions!

I'm getting the same error.

Custom image is not shown while dragging.
When I drop to an invalid location, it still stays in 'dragging' state.
If I drop to a valid location, it works fine.

Safari Version 8.0.2 (10600.2.5) - no extensions.

Just checked the other examples in safari, invalid drops cause it to stuck in dragging state.
And starting dragging always produces the same error, on the same line HTML5.js:157
[Error] TypeError: null is not an object (evaluating 'Array.prototype.slice.call(n.types)')
	slice (main-e36e66a10c13c4e9d8ac.js, line 1)
	l (main-e36e66a10c13c4e9d8ac.js, line 1)
	handleTopDragStart (main-e36e66a10c13c4e9d8ac.js, line 1)
	(anonymous function) ([native code], line 0)`

Thanks! Should be fixed now. Browsers :scream:. I'm starting to think HTML5 backend should be moved to a separate repo so I can bump its versions without bumping React DnD.

authors: gaearon haihappen hakanderyal

repo: gaearon/react-dnd


text:
dev tools getting an error...Lazy require of extension.binding did not set the binding field

dev tools getting an error...Lazy require of extension.binding did not set the binding field
(CONTENT_SCRIPT context for lmhkpmbekcpmknklioeibfkpmmfibljd) Lazy require of extension.binding did not set the binding field
(CONTENT_SCRIPT context for lmhkpmbekcpmknklioeibfkpmmfibljd) extensions::lastError:82: Uncaught TypeError: Cannot convert undefined or null to object{TypeError: Cannot convert undefined or null to object
    at Object.clear (extensions::lastError:82:23)
    at handleResponse (extensions::sendRequest:84:15)
    at chrome-extension://lmhkpmbekcpmknklioeibfkpmmfibljd/js/pagewrap.bundle.js:1:1}
(CONTENT_SCRIPT context for lmhkpmbekcpmknklioeibfkpmmfibljd) extensions::messaging:9: Uncaught Natives disabled{<stack trace unavailable>}
Uncaught
  (anonymous function)

repo:  https://github.com/born2net/studioweb
Angular 2 Kitchen sink: http://ng2.javascriptninja.io
and source@ https://github.com/born2net/Angular-kitchen-sink
Regards,
Sean

Online demo would save me some time to debug, but http://ng2.javascriptninja.io redirects to http://secure.digitalsignage.com/boiler/

yes sorry my signature is confusing.
here is link to repo demo online: https://secure.digitalsignage.com/studioweb/
and source:   https://github.com/born2net/studioweb
but it seems to do it only when I debug in WebStorm :/
see image

if I disable the chrome ext dev-tools, no error

Well, I don't see much information here. Could you provide some steps to reproduce? Also you can run the extension in dev mode to get more details. Note that you should clone [the extension's repo(https://github.com/zalmoxisus/redux-devtools-extension), not redux-devtools, which are completely different.

ok will be back later this afternoon and will do

I tried running your repo and don't get any problems (though I see you're not using the extension after logging in). Could be a problem with interfering with Webpack's extension. If you'll provide exact steps on how to debug it with Webpack so the exception occurs, I'd look into it.

if i was a betting man I would bet it is an issue with latest ng-cli (thus Webpack) as I am working closely with the ng-cli team and they are making major changes right now pushing towards last release.
so I believe you are right most likely related to webpack / ng-cli (I am using ng-cli .30 beta)
Here is the new repo (moved) of cli:
https://www.npmjs.com/package/@angular/cli
regards
Sean

I tried to compile the dev extension but no luck.
I am still seeing  the issue.
Any chance someone can check with my repo:
https://github.com/born2net/studioweb
Also, I was mistaken and this is not related to ng4, same issue with ng2.
and it makes working with dev-tools really hard because my console is clobbered with error all the time.
see attached image:

TX
Sean

Hey Sean,
Once again, please provide detailed steps on what should be done in Webpack to reproduce that.

Hi,
So I am using angular-cli .30 which is also part of my project when you fork it, just run:
npm run dev
and that's it
If you wish I can make a video
TX
Sean

Sorry, I meant WebStorm not webpack. Written steps of what should be done in WebStorm would be great.
What was the issue with compiling the extension? It's just npm i && npm run buld:extension.

again I do apologize, my bad, it's not related to WebStorm at all.
It's an issue with redux dev-tool, thus I included a new snapshot showing console error in Chrome dev tools.
sorry for misleading.
reproducing should be real easy, standing by to assist.

Well, I tried the repo before and didn't get any exceptions. I synced your last  changes and still don't replicate the issue:

so odd :(
please see this:
https://dl.dropboxusercontent.com/u/93017334/ErrDevTools.mp4
any ideas? something I can check?

:( very odd, can you please check this video:
https://dl.dropboxusercontent.com/u/93017334/ReduxErr.mp4
TX
Sean

As I see in the video, it's still inspected by Webstorm extension. Could you try it without WebStorm?
I didn't use Websorm IDE debugging, if you can provide some steps, I'll check that.

you are absolutely right, I disabled the WebStorm debug extension and now, no more errors.
so WebStorm and Devtools are not liking each other.
What can I provide to help resolve the issue?
TX
Sean

WebStorm is trying to inspect the Redux Extension's script, which it shouldn't do. As told, I'm not an expert in WebStorm. If you provide some steps on how to run debugging in the IDE as you do, I'd check it. Or maybe pushing the .idea folder to github could be enough to replicate your config environment?

sure thing, the config is super vanilla.
see below:

be happy to provide .idea if needed but its all very simple.

I installed WebStorm's Chrome extension.
Added the settings like in your screenshot.
Clicked "debug" icon (as you can see in the video)
And still no exceptions.

Unless I didn't miss anything, the resolution for you I guess is to build our extension in dev mode and debug it.

first tx for the effort and GIFs.
no idea, I am using WebStorm 2017.1 EA
https://blog.jetbrains.com/webstorm/2016/12/webstorm-2017-1-early-access-preview/
not sure if related :/

I'm redirected to UserLogin page not to AutoLogin in your video. Also I had to remove this line because you don't have this file and it fails to build.  Maybe the source is different.
I'm using WebStorm 2016.2.4, but I doubt it makes any difference because the issue is related to its browser extension which is the same.

tx will be fixing "./libs/bootstrap-timepicker/js/bootstrap-timepicker.min.js", on next submit
and if you click the [x] remember me, it should auto login you on the next reload

OK, did it, but still no exceptions :)
I suggest to close this issue since it's not related to this repo in any way, and when you have some more details, please open a new issue on https://github.com/zalmoxisus/redux-devtools-extension. Some repo watchers may be annoyed with lots of notifications, while they are not using the extension (this repo is intended to use devtools without browser extension).
I added the info in the README to avoid the confusions in future.
Thanks you for the report anyway! And feel free to submit issues there.

thank you, I will continue this with WebStorm devs and see if I can resolve with them, tx again!

I suddenly got a similar thing running an Ionic3 project. (uses Angular 4 under covers too). Using Visual Studio Code - so not specific to an IDE.

Got the same errors. My theory is that this is caused by breakpoints/syntax issues that happen before the  tag is loaded.

authors: born2net jgfet konijn zalmoxisus

repo: gaearon/redux-devtools


text:
The tests aren't cleaning up after themselves

When I run go test a bunch of things are left under pipeline that pollute the work tree.
~/golang/src/github.com/gaia-pipeline/gaia makefile_refactor* 10s
❯ git status
On branch makefile_refactor
Your branch is up-to-date with 'skarlso/makefile_refactor'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	pipeline/.circleci/
	pipeline/.gitignore
	pipeline/.goreleaser.yml
	pipeline/Gopkg.lock
	pipeline/Gopkg.toml
	pipeline/LICENSE
	pipeline/Makefile
	pipeline/README.rst
	pipeline/cmd/
	pipeline/docker/
	pipeline/frontend/
	pipeline/gaia.go
	pipeline/handlers/
	pipeline/pipeline/
	pipeline/plugin/
	pipeline/scheduler/
	pipeline/store/
	pipeline/vendor/

I'm actually a bit ashamed of the tests. 😣
They are really messed up and most times they are not working.

Don't worry about it. :) I'll clean them up as I go through them. ;)

Fixed by #12

authors: Skarlso michelvocks

repo: gaia-pipeline/gaia


text:
Feat: Multiple texture support

Support multiple texture
Fix hack texture problem that fragment sub mesh not share one default material.

Duplicated #85

repo: galacean/engine-spine


text:
virtual appliance: the TS password combination is invalid

You can login with login planemo@test.comand password planemo.

Nope... Does anybody know what is the new password here?

the user does not exist at all since I can manually create it

xref: https://github.com/galaxyproject/ansible-galaxy-toolshed/pull/2

should be fixed by the above

repo: galaxyproject/planemo-machine


text:
Add a new topic: translatomics

Hello, everyone!
My partner and I created a new topic called translatomics and wrote some tutorial about it. Besides, workflows can be tested on our Galaxy-based translatome workbench (https://db.cngb.org/galaxy/). We listen carefully to your suggestions.
Best wishes,
Ludong Yang

Hi @ldyang14, thanks for your contribution, you obviously put a lot of effort into this! and apologies for the lack of feedback.
Some general points:

There are a lot of very short tutorials in here, do you think you could merge some of them to make a longer "end-to-end" tutorial?
The "Inferring ribosome stalling or pausing" tutorial contains no hands-on steps. You could make a slide deck out of this if you just want to provide some scientific background, or add it to the intro slides you already made, or make it part of a longer more comprehensive tutorial as suggested in previous point.
Please put any input data on Zenodo
Please add workflow files for any tutorials

Let me know what you think

repo: galaxyproject/training-material


text:
Tutorial Monocle3 R notebook - WIP

NEW TUTORIAL
Next one in the single-cell series and a follow up to the existing tutorial on trajectory analysis using monocle3, but now more advanced and with a notebook in R!

On this!

OK I tried to resolve conflicts, but just in case I have a hard copy of your tutorial & images in case this went wrong

authors: nomadscientist wee-snufkin


text:
Update iuc,devteam,bgruening,galaxyp tools

TODO: Please replace this header with a description of your pull request.
Installation sequence for tool-installers

[ ] Test using @galaxybot test this
[ ] Inspect CI output for expected changes
[ ] Deploy using @galaxybot deploy this if test install was successful
[ ] Merge this PR

@galaxybot deploy this

repo: galaxyproject/usegalaxy-tools


text:
adding segalign tool

TODO: Please replace this header with a description of your pull request.
Installation sequence for tool-installers

[ ] Test using @galaxybot test this
[ ] Inspect CI output for expected changes
[ ] Deploy using @galaxybot deploy this if test install was successful
[ ] Merge this PR

@galaxybot test this

@galaxybot deploy this

authors: natefoo richard-burhans


text:
Page is not resolvable

maybe we need to use a different gateway or our IPNS configuration needs to be modified-

Update: The page became resolvable at bio.openlinks.io/115696026228202431964 after approximately 2 minutes. This appears to be a propagation delay rather than a complete resolution failure.

Possible Solution: Cache the site on CF until its resolvable through the Gateway

repo: galaxyxone/openlinks


text:
packaging with opam

I'd like to use this project in an opam-based setup. I was hoping, it could also be included in the opam-coq-archive.
What do you think about that?
I'm currently using my fork, see https://github.com/gallais/parseque/pull/6
relevant for https://github.com/WasmCert/WasmCert-Coq/issues/9

I am happy for it to be shipped, I just do not have time to maintain & deal with distribution.
Would you be happy to do it if I gave you full access to the repo?

thanks for the reply!
I'm happy to do the packaging (I'll probably have time for that in the summer.)

I'd be happy to push an initial release to opam-coq-archive. All that's needed from the repo maintainer is a GitHub release (which will provide a version number and tarball). The rest is a pretty simple PR on the opam-coq-archive repo.

I'd be happy to push an initial release to opam-coq-archive. All that's needed from the repo maintainer is a GitHub release (which will provide a version number and tarball). The rest is a pretty simple PR on the opam-coq-archive repo.

just created a release. That would be much appreciated!

I'd be happy to push an initial release to opam-coq-archive. All that's needed from the repo maintainer is a GitHub release (which will provide a version number and tarball). The rest is a pretty simple PR on the opam-coq-archive repo.

just created a release. That would be much appreciated!

PR at https://github.com/coq/opam-coq-archive/pull/2621

btw assuming you came here looking for an opam-based version of Wasmcert-Coq, my fork is almost there, may be useful until it is available through opam

Indeed I was! Thanks for the pointer.

release 0.1.0 is out:
zsh-5.8$ opam install coq-parseque
The following actions will be performed:
  ∗ install coq-parseque 0.1.0

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><>  🐫
[coq-parseque.0.1.0] downloaded from https://github.com/gallais/parseque/archive/refs/tags/v0.1.0.tar.gz

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><>  🐫
∗ installed coq-parseque.0.1.0
Done.

thanks!

authors: gallais jeromesimeon womeier

repo: gallais/parseque


text:
How to include RobotS in my Cargo.toml dependency

I have tried with:
robots = "0.3.0"
and
robots = { git = "https://github.com/gamazeps/RobotS.git" }
but I get: no matching package named robots

@TLmaK0 because the package is named RobotS, not robots:
RobotS = { git = "https://github.com/gamazeps/RobotS.git" }

OMG!! I thought I had tried it. Thanks!!

repo: gamazeps/RobotS


text:
Shoot cluster is hibernated even the hibernation is configured to false

How to categorize this issue?

/area shoot cluster
/area hibernation
/area usability
/kind bug
What happened: When you want to deploy shoot cluster without hibernation  and you specify hibernation part in shoot cluster definition yaml with shceduling.
hibernation:
    enabled: false
    schedules:
    - location: Europe/Bratislava
      start: 00 17 * * 1,2,3,4,5

hibernation is disabled only if this part is deleted from yaml or if schedules part is removed.
hibernation:
    enabled: false

On that case hibernation enabled value is ignored and shoot cluster will be hibernated anyway.
What you expected to happen:
When I specify hibernation  to enabled: false it should not check schedules and should disable hibernation.
How to reproduce it (as minimally and precisely as possible):
create yaml manifest for shoot cluster where you specify hibernation part following:
hibernation:
    enabled: false
    schedules:
    - location: Europe/Bratislava
      start: 00 17 * * 1,2,3,4,5

Anything else we need to know?:
Environment:

Gardener version: 1.43
Kubernetes version (use kubectl version): 1.21.X
Cloud provider or hardware configuration: Openstack

@jan-kuky , there is a mismatch between your expectation and the actual behaviour.
.spec.hibernation.enable denotes the desired state of the Shoot cluster (whether the desired state is to have the cluster hibernated or awake).
.spec.hibernation.schedules denotes schedules to hibernate/wake up the cluster automatically. The Shoot hibernation controller of gardener-controller-manager reads this schedule and updates the .spec.hibernation.enabled field accordingly (depending on whether Shoot was to hibernate or wake up according to the schedule).
If you want a schedule to be not respected, then you have to remove the corresponding schedule.
PS. I can kind of agree that we miss a proper documentation for this.
/remove kind/bug
/area documentation
/kind enhancement

authors: ialidzhikov jan-kuky

repo: gardener/gardener


text:
Nit: Update to golang@1.14.5

How to categorize this PR?

/kind task
/priority normal
What this PR does / why we need it:
@ThormaehlenFred recently asked to update to golang@1.14.5.
Ref https://groups.google.com/d/msg/golang-announce/f2c5bqrGH_g/GnH6k56AAAAJ
Release note:

NONE

/lgtm


text:
Do not reconcile shoots multiple times during their maintenance time windows

How to categorize this PR?

/area scalability
/kind enhancement
/priority critical
What this PR does / why we need it:
Today, the shoot controller has various problems that lead to scalability issues in very large landscapes:

It is reconciling shoots multiple times during their maintenance time windows (if the gardenlet's component config sets "reconcile in maintenance only" to true) based on the sync period. This also happens even if the reconciliation has already happened before for the current time window.
When the gardenlet restarts then all shoots whose maintenance time window is met will be enqueued and reconciled immediately. If many shoots have the same maintenance time window then this will produce a lot of load.

This PR adapts the behaviour in the following ways:

When the gardenlet has already reconciled a shoot in its maintenance time window then it doesn't do it again. Instead, it computes a random duration for the next time window and requeues the shoot. Already reconciled shoots are those whose last reconciliation was less then 24h ago.
When the gardenlet is (re)started then it does no longer reconcile all shoots whose maintenance time windows are met immediately. Instead, it computes a random time for the current time window and requeues the shoot ("jittering"). This will have the effect that not all shoots are getting reconciled at the same time right after startup.

Both changes will lead to a lot of less load on the seeds, the garden cluster (apiservers), and to less network I/O.
/cc @vpnachev
Special notes for your reviewer:
The implementation introduces a so called "reconciliationDueTracker" in the shoot controller. Its purpose is to distinguish the two cases:

gardenlet starts and checks if shoot whose maintenance time window is met must be reconciled
gardenlet runs and checks if a shoot whose maintenance time window is met must be reconciled but was already delayed/jittered before

A better implementation is probably to handle this situation in the shootAdd() function, i.e., right in the event handler for CREATE SHOOT events. However, this would require some duplication of the logic that is already part of reconcileShoot(), and it even might have other side effects. The logic is quite complex at the moment, so I was reluctant do follow this approach (and risking to break something). I guess the reconciliationDueTracker approach is easier to understand/review for now, it's more lightweight and has less duplication/complexity. Nevertheless, we should clean up this shoot control logic when possible so that the whole flow/logic and different cases become better understandable and readable.
Release note:

The shoot controller inside the gardenlet has been adapted to cater with large Gardener landscapes:
1. When the gardenlet has already reconciled a shoot cluster during its maintenance time window then it doesn't reconcile it again. Instead, it computes a random duration for the next time window and requeues the shoot. Already reconciled shoots are those whose last reconciliation was less then `24h` ago.
1. When the gardenlet is (re)started then it does no longer reconcile all shoots immediately whose maintenance time windows are met. Instead, it computes a random time for the current time window and requeues the shoot ("jittering", i.e., spreading the load). This will have the effect that not all shoots are getting reconciled at the same time right after startup.

/assign

Out of scope of this PR, I was thinking about to set the next reconciliation time in the shoot status after each successful reconciliation. Then the controller can use this as reference when it has to reconcile again. If it was down during this time, it should schedule new reconciliation during the maintenance time window, which can be the current or the next window depending what is the current time.

Yes, good idea. Let's discuss those options when we tackle #3160

I've pushed a small improvement based on a suggestion from @timuthy - thanks again for this nice catch. PTAL.

authors: rfranzke timuthy


text:
[ci:component:github.com/gardener/autoscaler:v1.22.1->v1.22.2]

How to categorize this PR?

/area TODO
/kind TODO
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

/close
in favour of https://github.com/gardener/gardener/pull/6295


text:
docker images specs fails with update_docker_image.sh

Hi,
your update_docker_image.sh uses the json .Config.Image item to proof if a image is pulled out correctly. This Config.Image is only written if you are using the docker import mechanism. I try to build docker images from a dockerfile and then the image name ends up in .ContainerConfig.Image.
May there be a switch to resolve this issue?
Regards,
Rudi G.

I had a different issue around the same code and the script now uses Id https://github.com/garethr/garethr-docker/commit/914f3319ae13a6fd7ba642cb7d500a80540b0691. I think that should resolve your problem too but if not please reopen this issue.

authors: garethr rudgab

repo: garethr/garethr-docker


text:
Install Adobe Acrobat Reader

winget install -e --id Adobe.Acrobat.Reader.64-bit

Is it paid or free?

Fixed

authors: Dabgotra garretpatten

repo: garretpatten/windows-setup-scripts


text:
Feature request

It would be fine to work also with 3rd-party dhcp servers.
i. e. http://www.n3k.de/produkte/ip-management/runip/runip-managed-dns-dhcp-appliance/

Thanks for your interest in the project @ThiloL
This library is primarily a .NET wrapper around the native Win32 API's exposed by Microsoft's DHCP Server. The structure of the libraries public surface area (its classes, properties, methods, etc) is heavily influenced by the architecture of these Win32 APIs.
Personally, I have no desire to expand the library to support other DHCP Server implementations. It seems to me that such an endeavour would most likely be done in a separate project. However I'm not against the idea in principle.
If you would like to build the abstraction layer and implement a third-party API I encourage you to submit a pull-request. If you intend to do so I encourage you to further outline your plans in this thread first to avoid any issues later on. You might want to consider (among other things):

efforts to maintain compatibility for existing users
an abstraction which would allow any server to be implemented
how to deal with dependencies (ie. a rest-api might require a HTTP client library and json support; but these dependencies would be prohibitive for a user just wanting Microsoft DHCP Server support)

I look forward to hearing your thoughts on this.

authors: ThiloL garysharp

repo: garysharp/DhcpServerApi


text:
Core: Session.getDouble throws NumberFormatException on real double value

I try to get double value from feeder provided value for some calculations and got this issue.
Example:
var myScenario = scenario("Scenario-1")
    .feed(myFeeder)
    .exec(
        session -> {
            var prd = session.getDouble("PRD");
            return session.set("NEW_PRD", prd * 5.0);
        }
    )

Result:
00:36:48.178 [ERROR] i.g.c.a.b.SessionHookBuilder$$anon$1 - 'hook-9' failed to execute: j.l.NumberFormatException: For input string: "34.20"
However method getDoubleWrapper works well.

Thanks for reporting!

authors: slandelle svyaz

repo: gatling/gatling


text:
feat: rename to a better param

fixes #87

Looks good! 👍🏼

Note that if it is a breaking change and we merge it, we are tied to not release more versions until v0.3.0, so we couldn't release patches meanwhile. I would convert it to a draft until v0.3.0 is prepared.

Looks good 👍🏼 But this would be a breaking change, right?

Yes it is breaking, we can punt till v.0.3.0. Note, we should finalize with major breaking changes afterwards, not to upset our authors :)

authors: friendlymatthew mondeja

repo: gaucho-labs/leptos-hotkeys


text:
Add Enumeration to legacy apis

This doesn't ban all uses of Enumeration though. It only catches code like
class TpEnumeration implements Enumeration<Object> {

Any ideas?

Thank you for your contribution @delanym!

authors: delanym gaul

repo: gaul/modernizer-maven-plugin


text:
refactor: Improve FiveShorts activity with better coroutine managemen…

…t and code organization

Encapsulated query generation logic into a generateQuery method.
Refactored fetchResponse method to handle coroutine launching and network calls more cleanly.
Converted getShortsFromDatabase to a suspend function for proper coroutine usage.
Introduced showLoading method to manage loading state and improve code readability.
Enhanced error handling and logging for network and JSON parsing operations.
Improved database operations by ensuring they run in a background thread.


text:
local stoarege added

🚀 Pull Request
Description
I added Local storage to Dark / Light mode then browser can keep remember which mode user likes and continue that mode when they visited back or refresh the page

Related Issue
#603

Type of Change
What kind of change does this pull request introduce?

[ ] 🐛 Bug fix
[X] 🚀 New feature
[ ] 📄 Documentation update
[ ] 🛠 Code improvement/refactor
[X] 🖼 UI/UX update
[ ] Other (please specify)

Screenshots (if applicable)
https://github.com/user-attachments/assets/3fa2f120-f40f-4a48-b17e-3f6e700305b2

Checklist
Please ensure the following tasks are complete before submitting the pull request:

[X] I have tested my changes and ensured they work as expected.
[X] I have added any necessary documentation or comments.
[X] I have checked the existing issues and pull requests to avoid duplicates.
[X] I have starred this repository.
[X] I have reviewed my code for best practices and readability.
[X] I have included any relevant tests (if applicable).

Additional Context
Add any other relevant information or context about the pull request here.

the text (Login and register) is Turing into white because of they have same CSS as other body and my issue don't cover that that's reason I didn't solve that issue

@PriyaGhosal please review the PR

Will this PR be counted in gssoc


text:
TRAJ_STOP doesn't appear to work as expected

Two reasons:

"JointTrajectoryStreamer does not send TRAJ_STOP if in IDLE state" (ros-industrial/industrial_core#175)

there is no support in the current industrial_robot_client for a server to signal a client to send the next traj point. The client will always send a next point upon receiving an ACK to the previously sent point. This leads to the situation where ROS_TRAJ -- with a full point buffer -- will not send out ACKs, which makes industrial_robot_client hang in sendAndRecieve(..). Any pending TRAJ_STOP JOINT_TRAJ_PTs will be blocked at this point.
For sparse trajectories with long (joint space) distances between subsequent traj pts this will lead to the driver first having to 'finish' a (potentially long) segment until it can ACK again, and only then the TRAJ_STOP will be received.

To address 2, the fanuc_driver nodes could adopt the approach the motoman_driver is using, with explicit BUSY responses to incoming JOINT_TRAJ_PTs if the buffer is full, and the client node retrying every so often.
That would allow TRAJ_STOP msgs to be multiplexed into the message stream.

https://github.com/ros-industrial/industrial_core/pull/199 should address https://github.com/ros-industrial/industrial_core/issues/175.

The PR partially helped indeed, but when robot is close to get to the given goal, stop() function does not take effect, on the teach pendant I see the trajectory points are already been pushed while robot is still on the move, is there any suggestion to address this ?

on the teach pendant I see the trajectory points are already been pushed while robot is still on the move

I don't really understand what you mean by this.
Network handling and motion are decoupled in this driver. The ROS side could push 100 pts, with the robot still not moving, depending on what buffer length is configured.

is there any suggestion to address this ?

Without checking this myself it's hard to provide you with any advice.
There is no way to really CANCEL a motion right now with the way the driver is implemented. The problem is essentially similar to https://github.com/ros-industrial/fanuc/issues/93.
You could add a SKIP condition to the J statement and trigger that somehow, or perhaps implement a general ABORT upon receiving a stop.
Another alternative: create something that drops HOLD and then reset ROS_TRAJ.

I don't really understand what you mean by this.

I meant, once the controller received all the trajectory points that are going to be executed, the TRAJ_STOP doesn't stop robot anymore, and all point received points are executed, after that TRAJ_STOP is being executed.

stop() function
yes I was referring to move_group->stop()

unfortunately I could not understand the alternatives you listed above as I have no experience in KAREL programming

so after some head scratching and getting lost in fanuc's not so clever documentations,  I found a temporary solution using your fanuc_ros_cgio. But as you described in the project, the timing is not that desirable. I still hope to get some more reliable solution for this.
in https://github.com/ros-industrial/fanuc/issues/93 you said;

This will not be addressed any more in fanuc_driver - other developments will take priority.

But this issue is still open here, is there any willingness to go on this issue in future ?

I found a temporary solution using your fanuc_ros_cgio. But as you described in the project, the timing is not that desirable. I still hope to get some more reliable solution for this.

Switching to an actual fieldbus would immediately reduce latency and increase determinism.

in ros-industrial/fanuc#93 you said;

This will not be addressed any more in fanuc_driver - other developments will take priority.

But this issue is still open here, is there any willingness to go on this issue in future ?

I would be OK with PRs being submitted to address this issue, but I don't have time in the foreseeable future to work on it myself.
The easiest way to integrate this would probably be something I described in my previous comment:

add a SKIP condition to the motion instruction in ROS_TRAJ
make that condition evaluate to true based on an IO signal that is triggered using a fieldbus (or similar) or by sending a message to ROS_TRAJ

Unfortunately using ROS_TRAJ and industrial_robot_client will run into bullet nr 2 in the OP of this thread.

https://github.com/ros-industrial/industrial_core/issues/175 was fixed. I expect this to work now here in fanuc_driver_exp as well.
Closing.

authors: gavanderhoorn jediofgever


text:
Implement InList and NotInList methods

Some matcher structs (Number, DateTime) have InRange method that checks that the value belongs to given range [min; max].
Another convenient thing would be InList method, that checks that the value equals to one of the given values a, b, c, ....
For example:
array.Element(1).String().InList("green", "red")

We need to add InList and counterpart NotInList methods to the following structs:

Value
Object
Array
String
Number
Boolean (just for completeness)
Duration
DateTime

The new methods can use assertions of type AssertBelongs and AssertNotBelongs. Please place these methods after InRange, or after Equal* if there is no InRange for this struct.
Each method should have documentation comment with code example and be covered by a unit test. It would be also nice to demonstrate usage of InRange and InList in _examples/fruits_test.go.

Hi @gavv, I have created PR for this issue: https://github.com/gavv/httpexpect/pull/256
Could you check it? and let me know how it goes
PS.

Since AssertionList rejects a single slice as a param, single array param in InList will behave like IsEqual and NotInList will behave like NotEqual. Added in https://github.com/gavv/httpexpect/commit/649ee8caf0e8c918aa9a2de8a8d6f6c5c3ec1cf7
https://github.com/gavv/httpexpect/blob/86f366a2d10b8a8ddd3cb1a9b2a5c00f37a1df68/assertion_validation.go#L186-L190

I'll update _examples/fruits_test.go if this PR is merged. Or do you have an alternative without modifying go.mod under _examples?

Thanks for pr! Will take a look shortly.
Re: PS

Let's just remove this check from assertion validation. It was useful euristics to catch bugs, but it's not working well with InList.

Yes, let's update examples separately, thanks.

Addressed in https://github.com/gavv/httpexpect/pull/256/commits/40c6e50cc826924a245632406c46278e2c0f9a98.
Sure, thanks for your awesome repo as well :100:

Reopening after auto-close because we also need to update example.

Created follow-up issue: https://github.com/gavv/httpexpect/issues/261

I've tagged v2.11.0, which includes InList.

@gavv, thanks for reviewing the PR.
I'll add an example along with this issue https://github.com/gavv/httpexpect/issues/251 if that's okay for you.

Great, thanks!! Please leave a comment there so that I can assign it to you.

authors: fahimbagar gavv

repo: gavv/httpexpect


text:
Gazebo Fortress - Loading Models Problem with Ogre2.2

Hi there,
I’m currently using Gazebo Fortress with the SubT Simulator on Ubuntu 18.04, and the models in the world are taking up to 10 minutes to load with a medium complexity map. I have the models saved locally in the standard cache location (.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models) and the cache files are accessed only after Ogre 2.2 times out when attempting to load texture & deletes the buffer memory.
This issue doesn’t occur with Ignition Dome, and the map loads normally with Ignition Dome.
This is likely a physics engine related problem, as Ignition Dome doesn’t use Ogre2. The log from Ogre2 when the map is being loaded says the following:
“17:33:42: Can’t assign material scene::Material(55155) because this Material does not exist. Have you forgotten to define it in a .material script?
17:33:42: Can’t assign material scene::Material(55154) because this Material does not exist. Have you forgotten to define it in a .material script?
17:33:42: WARNING: Deleting mapped buffer without having it unmapped. This is often sign of a resource leak or a bad pattern. Umapping the buffer for you…”
Once the buffer is unmapped, the scene loads.
Possible Causes:

Ogre2 has an issue loading textures
There is an issue with namespace changes from ignition::gazebo to gz::sim
There is a problem with the setup of the Ignition Fortress & Ignition Fuel

Related errors occur:

EGL related
" 17:28:41: Trying to init device: EGL_EXT_device_drm /dev/dri/card0…
17:28:41: Created GL 4.5 context for device EGL_EXT_device_drm /dev/dri/card0
17:28:41: Destroying device: EGL_EXT_device_drm /dev/dri/card0…
17:28:41: EGL Device: EGL_EXT_device_drm /dev/dri/card1
17:28:41: Trying to init device: EGL_EXT_device_drm /dev/dri/card1…
17:28:41: OGRE EXCEPTION(3:RenderingAPIException): eglInitialize failed for device EGL_EXT_device_drm [ /dev/dri/card1 in EGLSupport::getGLDisplay at /var/lib/jenkins/workspace/ogre-2.2-debbuilder/repo/RenderSystems/GL3Plus/src/windowing/EGL/PBuffer/OgreEglPBufferSupport.cpp (line 322)
17:28:41: OGRE EXCEPTION(3:RenderingAPIException): eglInitialize failed for device EGL_EXT_device_drm /dev/dri/card1 in EGLSupport::getGLDisplay at /var/lib/jenkins/workspace/ogre-2.2-debbuilder/repo/RenderSystems/GL3Plus/src/windowing/EGL/PBuffer/OgreEglPBufferSupport.cpp (line 322)
17:28:41: Destroying device: EGL_EXT_device_drm /dev/dri/card1…
17:28:41: EGL Device: EGL_MESA_device_software
17:28:41: Trying to init device: EGL_MESA_device_software…
17:28:41: Created GL 3.3 context for device EGL_MESA_device_software [
17:28:41: Destroying device: EGL_MESA_device_software…
17:28:41: EGL Device: EGL_MESA_device_software
17:28:41: Trying to init device: EGL_MESA_device_software…
17:28:41: Created GL 3.3 context for device EGL_MESA_device_software
17:28:41: Destroying device: EGL_MESA_device_software …"

Could be caused by a graphics card issue, or this may be a red herring.

Level manager error:
[Err] [LevelManager.cc:218] Could not find a plugin tag with name gz::sim. Levels and distributed simulation will not work.
Found that it’s likely benign and can be ignored - Launch ignition through network issue · Issue #1350 · gazebosim/gz-sim · GitHub

Things I have tried:
Saved cache files in different likely locations, and edited multiple environment variables of gazebo to point towards the files
Set the uri of all the models that are being pointed towards, to be towards the local versions using model:// syntax
Compiled Ignition Fuel from source with debug mode on and debugged it using GDB. Tried multiple versions, and the code is pretty box standard from what I can tell.
Installing different versions of Ignition Gazebo
Using Ogre1. Ogre1 did the same thing without the material error in the log, but the same time hanging whilst the models are being loaded into the world.
Any suggestions on where to go from here? I’ve tried everything I can think of and it’s really slowing my development time down! Thank you in advance for your help.

Are there are errors printed in the console?
Dome -> Fortress: we upgraded ogre from 2.1 to 2.2 but not sure if that's the reason or not.
17:33:42: Can’t assign material scene::Material(55154) because this Material does not exist. Have you forgotten to define it in a .material script?
17:33:42: WARNING: Deleting mapped buffer without having it unmapped. This is often sign of a resource leak or a bad pattern. Umapping the buffer for you…”

These warnings should be ok to ignore. They still happen in newer version of gazebo.
17:28:41: OGRE EXCEPTION(3:RenderingAPIException): eglInitialize failed for device EGL_EXT_device_drm [ /dev/dri/card1 in EGLSupport::getGLDisplay at /var/lib/jenkins/workspace/ogre-2.2-debbuilder/repo/RenderSystems/GL3Plus/src/windowing/EGL/PBuffer/OgreEglPBufferSupport.cpp (line 322)

Related issue: https://github.com/gazebosim/gz-rendering/issues/587 - Logged when OGRE tries to query EGL devices - the OGRE 2 dev says it should be harmless.

Using Ogre1. Ogre1 did the same thing without the material error in the log, but the same time hanging whilst the models are being loaded into the world.

Maybe it's a Fuel server issue (https://app.gazebosim.org/). Some older models on Fuel points to ignitionrobotics.org instead of gazebosim.org and may no longer work. Launching gz sim should show errors in console mentioning that it timed out downloading these models.

An alternative reason: Ignition Fuel is trying to load models that are no longer accessible. Is there a way to setup Ignition Fortress to use local files by default prior to attempting to download?

Gazebo looks at the local cache first before downloading them from fuel. So if the models are available in ~/.gz/fuel/.. it should just load those.

From what you've said it sounds like the error is most likely an issue created by Ogre2.2. Is there a way to implement the memory buffer deletion sooner with Ogre2.2?

I'm not sure if that's the reason for slow down. You mentioned that it's also hanging with Ogre1 so that makes me thing it's caused by something else.
One thing I would try first is to comment out some models in the world and see if it's because certain models are taking too long to load.

Thanks for the suggestion @iche033! I have been using the simple_tunnel_02 map and have commented out different model files. I removed all of the model files except the robot one by one until all model files were removed, and tried different robots (it is very funny to watch a single robot falling through a non existent floor!). All/any of the model files cause this error to crop up in the Ogre2 rendering log:
"Can't assign material scene::Material(65447) because this Material does not exist. Have you forgotten to define it in a .material script?"
It is only after the memory is cleared that the GUI loads with the robot:
WARNING: Deleting mapped buffer without having it unmapped. This is often sign of a resource leak or a bad pattern. Umapping the buffer for you... `
After digging into it further and trying different approaches, I have reached the following conclusion which likely explains the situation:
There is a porting problem with Ogre2.2 and Ogre2.1 when the updates were rolled out to gz-rendering6. The reason the error still happens with Ogre1, is the version of gz-rendering6 remains the same, so the code still hangs when launched with the earlier Ogre1 engine instead.
I have identified the particular push when related areas were discussed in gz-rendering6: [(https://github.com/gazebosim/gz-rendering/issues/223)]
Tagging the relevant contributors from that push - @mjcarroll @ahcorde @chapulina @darksylinc
This also is in line with what I am experiencing with EGL support with Ignition Fortress -  the headless version is actually far slower than the normal GUI version, which it shouldn't be. This means that the port from Ogre2.1 to Ogre2.2 has a fundamental bug of some kind in gz-rendering6 and the EGL rendering is not happening as it should. It could be that there are inefficiencies in Ogre2.2's way of rendering but these bugs I'm experiencing are leading me to think it's a bug based in gz-rendering6, rather than Ogre2.2 based. I think this may solve related bugs which cropped up with Ignition Fortress (e.g. [https://github.com/gazebosim/gz-sim/issues/1116] and [https://github.com/gazebosim/gz-sim/issues/1370]), so I think it's worth other people taking a look at. It's a bit beyond my skill level to solve myself unfortunately.
I believe there also may be a different in how the two different .materials files are structured in the fuel models vs what comes loaded in Ogre2.2 and works already. I have attached the two corresponding files which highlight that difference, although it may not be a contributing factor.
skybox.material (ogre2.2).txt
tunnel_tile.material (fuel model material).txt

I'm now running a very similar installation and I don't observe this delay. I run it on a NUC with Intel GPU, though. And also with ctu_cras_norlab_absolem_sensor_config_1 .

How long is the delay you observe? Mine is about 1 minute from ign-rendering-ogre2 loading start (with a single robot model).

I've found this very dependent on the map in question and possibly the specs of the PC. It can range from 1 minute to 10-15 minutes with a map like tunnel_circuit_01. Should I open up a separate issue regarding EGL processing headless being slower than the normal run through with fortress?

I've found this very dependent on the map in question and possibly the specs of the PC. It can range from 1 minute to 10-15 minutes with a map like tunnel_circuit_01. Should I open up a separate issue regarding EGL processing headless being slower than the normal run through with fortress?

Is that on Linux or on Windows (or Windows via WSL)?
When you mentioned headless, I remembered that if no monitors are plugged to Windows, the OS will disable the GPUs and tons of problems appear. You could be running on full SW emulation.

I've found this very dependent on the map in question and possibly the specs of the PC. It can range from 1 minute to 10-15 minutes with a map like tunnel_circuit_01. Should I open up a separate issue regarding EGL processing headless being slower than the normal run through with fortress?

Is that on Linux or on Windows (or Windows via WSL)?
When you mentioned headless, I remembered that if no monitors are plugged to Windows, the OS will disable the GPUs and tons of problems appear. You could be running on full SW emulation.

Thanks so much for the feedback, this is a bit of a headscratcher! It is on native Linux 20.04 with ROS Noetic and Ignition Fortress and a monitor plugged in. I am running headless via the following launch script using the "headless:=true" option: https://github.com/osrf/subt/blob/26fd5da5cc0d7dbbcd269b30752ca305d2bba3d5/subt_ign/launch/competition.ign#L387C13-L387C14
I've tested the headless on different run throughs using 1, 3 and 5 robots for 1 hour worth of elapsed time (real time, rather than sim time) and the RTF for the headless run throughs are slower than the normal run with the GUI in every case. I believe it indicates 1 of 3 things:

The port of gzrendering6 from Ogre2.1 and Ogre2.2 was implemented with a bug which makes headless slower
The setup using that particular launch file and the SubT simulator is configured wrong
Ogre2.2 renders things less effectively in headless mode

I believe it is likely the first result given the replicated error we are encountering with loading materials in the gazeborendering log. Any help would be much appreciated as solving this bug around headless being slower is really important to moving forward with my PhD work.

AFAIK the "headless:=true" option through ROS launch script just disables GUI window but does not actually enable EGL (a little confusing because both are sometimes referred to as headless).

the RTF for the headless run throughs are slower than the normal run with the GUI in every case

This is really weird. I haven't seen this issue before.
Are you able to share your ogre2.log?

The simplest way to address this is to debug it yourself:

Build gazebo from sources in Debug mode. To do so run colcon build --cmake-args -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Debug --merge-install when running the colcon step (I disabled tests to speed up compilation since they shouldn't be needed).
Install QtCreator
Start a terminal.
Just like in the documentation, run the command (with the period at the beginning) . ~/workspace/install/setup.bash so that environment variables are set.
Launch QtCreator FROM WITHIN THIS TERMINAL (so that QtCreator inherits the environment variables from the previous step).
Go to Debug -> Start and Debug external application.
Enter gazebo's executable and parameters as in this picture:

Launch it

Once it launched, start doing what triggers this bug (assuming it requires further interaction).
When it starts taking too long (i.e. the bug finally manifests), hit "Pause":

Once paused it may look like this:

What's relevant is the call stack and the threads enumeration.
This is the callstack, please Right Click -> "Copy contents to Clipboard" and paste it here:

The other thing is the Threads button:

In this example we have very few threads, but Gazebo has A LOT of threads. Go one by one (you can use the mouse wheel to scroll through the Threads very quickly) and see if there is something suspicious that looks stuck. Each time you change threads, the call stack changes. Anything that looks like relevant or "stuck" to you, please paste it here.
Then you can click on the Pause button again to unpause it; and repeat this step to see if it's stuck in the same place or somewhere else. It is relevant to know if the app is stuck in the same place or keeps jumping between different locations.

repo: gazebosim/gz-sim


text:
Multiple  NodeShared per process

🎉 New feature
Closes #531
Summary

Currently the transport architecture restricts a single NodeShared object per process. This is achieved by mapping process id to an instance of NodeShared class. However, recently, I had some use cases where I need to isolate several nodes, each with their own DISCOVERY variables, such as GZ_DISCOVERY_MSG_PORT,GZ_DISCOVERY_SRV_PORT, GZ_DISCOVERY_MULTICAST_IP,GZ_PARTITION, in a single process. Due to the limitation mentioned above, this is not possible because
DISCOVERY is tied to a process, and when instantiating multiple Nodes per process, all of them obtain the same NodeShared object and hence the same DISCOVERY variables.
To overcome this, one approach is to also use a thread_id to create a unique identifier that maps to a NodeShared object. This pins down the uniqueness of NodeShared object to each thread, not the process. The proposed modification performs this by the following logic:
// Map for obtaining shared node
static std::unordered_map<std::string, NodeShared*> nodeSharedMap;

 auto pid = getProcessId();
  // Get current thread ID, so we can create multiple NodeShared per Process, per thread
  auto tid = std::this_thread::get_id();
  // Create a unique id using both pid and tid
  std::stringstream ss;
  ss << tid;
  std::stringstream unique_ss;
  unique_ss << std::hex << pid << "-" << ss.str();
  auto uid = unique_ss.str();

 // create or access the shared node
 nodeSharedMap.find(uid) ; //access
// OR
 nodeSharedMap.insert(uid, new NodeShared) ; //create

This allows specification of DISCOVERY variables per thread.
Test it

For testing the proposed improvement, I added two test files nodeDiscoveryPubs_TEST.py and nodeDiscoverySubs_TEST.py under python/test directory. Each one shall be run in a separate terminal before and after modifications to see the results. Before modification, it is not possible to receive the messages by the subscribers due to the issue I mentioned. However, after my modification, the subscribers are able to receive their messages.
Finally, the proposed modification can also be verified from CLI. When the publisher TEST is run, it prints the command that can be run in a shell to set the DISCOVERY vars to listen to their publications.
NOTE: The following tests failed:
NodeTest.ScopeProcess  and  NodeTest.ScopeProcessRemap, because the test runs by creating publisher and subscriber in different threads. Due to the proposed modification, these 2 tests will fail.
Checklist

[X] Signed all commits for DCO
[X] Added tests
[ ] Added example and/or tutorial
[X] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[X] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸

Hi Azeey,
I found that there is an alternate approach to my use case. I feel like implementing my solution requires a lot of modifications, and after testing it, even though it works, it feels like I modified some fundamental architecture. Firstly, I do not know why the architecture was used in the first place, so modifying it may come with consequences.
So I decided to settle with an IPC solution to my problem (even though its much slower).

repo: gazebosim/gz-transport


text:
fix(Theme): Remove css variable --color-nums-shadow

Closes #1334
Описание изменений
Удалили переменную --color-nums-shadow .
В местах её использования - использовали подходящие по цвету переменные.
Чек-лист

[ ] PR: направлен в правильную ветку
[ ] PR: назначен исполнитель PR и указаны нужные лейблы
[ ] PR: проверен diff, ничего лишнего в PR не попало
[ ] PR: прилинкованы затронутые issue и связанные PR
[ ] PR: есть описание изменений
[ ] JS: нет варнингов и ошибок в консоли браузера
[ ] Тесты: новый функционал и исправленные баги покрыты тестами
[ ] Документация: отражены все изменения в API компонентов и описаны важные особенности реализации или использования
[ ] Сторибук: для компонентов написаны или обновлены stories
[ ] Верстка: используются переменные
[ ] Верстка: проверена с разным количеством контента

Опционально

[ ] Доработки: заведены задачи для дальнейшей работы, если что-то решено не править в текущем пулл-реквесте
[ ] Коммиты: проименованы в соответствии с правилами

в src/hooks/useThemeVars/helpers.ts остался '--color-nums-shadow' удали его и там

не все комментарии учтены

repo: gazprom-neft/consta-uikit


text:
Doesn't work on Android 6

Is this tested on Android 6 ?
Currently this works as expected on Android 5.x but not on 6.

@vukasin0 - thanks for opening the issue.  Currently we are migrating to Apache Cordova JIRA so I migrated your issue to CB-11363


text:
Auto-publishing time UTC vs local

For one of our resources we have an auto-publication set to Wednesday at 12:00:

According to the log file, the resource gets published at 10:00, but I don't know if that is UTC or local time:
10:00:03 Archive generation started for version #1.119
10:00:03 Start writing data file for Darwin Core Occurrence

As a user I expect the resource to be published at 12:00 local time, but I have the impression the 12:00 UTC +2 is converted to 10:00 UTC and the resource gets published at 10:00 local time.
@mike-podolskiy90

Can you investigate if the resource is indeed auto-published at the defined local time?
Could you align how times are shown in the log file with how they are shown in the auto-publishing? I think it's fine everything is UTC, but then it would be good to indicate that and maybe show UTC in addition to the local time in the auto-publishing settings.

I appreciate @peterdesmet for posting this. Over the years, I also have noted the discrepancy between when I set (and expect) publication to occur in my local time zone and the timestamp that is indicated by GBIF when publication actually occurs. The indication is that publication actually occurs in the time zone of the server and not my local time. It was never important enough for me to report, but I am reminded of it every time I set a publication date and time or need to confirm that a resources was published on schedule.
Also, now that the VN IPT is hosted by GBIF, if publication time is intended to be local time, it might be necessary to add an option to select a time zone or UTM. As I think about now, I'm guessing the cloud IPTs all publish on CEST times.

Just for info, the GBIF servers are all set to UTC.

Would it be useful to have a time zone selector too? So users decide what time zone to use.
@peterdesmet @dbloom

authors: MattBlissett dbloom mike-podolskiy90 peterdesmet

repo: gbif/ipt


text:
SSL Error

Hi,
Love the idea behind this mod, sadly i can't make it work.
I got this issue when trying to import this URL : https://www.grabcraft.com/minecraft/tauren-totem/towers#general

Any idéa ?

This is a problem with old java versions (like the one that comes with Minecraft) not understanding the security certificate that's used by GrabCraft. Please try version 0.3 of the mod; it says it's for 1.16.4 but should work from 1.16.2 on.

ok will do, thx

authors: gbl psentenac

repo: gbl/GrabcraftLitematic


text:
NetworkX backend is slow

Hi, first of all, osmnx is simply incredible! Very easy to use Swiss army knife for OSM data network analysis!
I see one big problem though - the network analysis using the NetworkX is painfully slow.
I have tried calculating node closeness centrality for a rather large graph (90k nodes, 200k edges) and it took about 14 hours. I then exported the graph and recalculated the same measure - closeness centrality in R using igraph and it only took 10 minutes on the same hardware.
I am not very fluent with Python, so I an only hypothesising here. I guess igraph for Python is as fast as igraph for R, and is therefore faster than NetworkX, because it is written in C. I can see that osmnx code relies heavily on NetworkX - you are not only using it for ad hoc calculations of centrality measures in your examples, but NetworkX dependancies are all over the codebase of osmnx.
Do you think this could be affecting the performance of osmnx functions and do you consider moving to igraph or even graph-tool (which seems to even faster than igraph https://graph-tool.skewed.de/performance )?

OSMnx downloads OpenStreetMap (OSM) data and converts it to a NetworkX (nx) multidigraph object. If some tests would be more efficiently run in memory on igraph objects, I'm open to reviewing a PR. If you're interested, performing a quick benchmarking test between networkx and the python implementation of igraph would be a useful first step.

Similarly, you can use graph-tool, which has been demonstrated to have better performance than igraph: https://graph-tool.skewed.de/
Here's a Gist on how to export from NetworkX into graph-tool.
Both of these tools require a bit more set up than NetworkX, though. So be prepared to roll up your sleeves and do a bit of work.

@e-kotov apologies, it has been updated (the post)

Closing for lack of activity. Can re-open at later date.

For folks looking for faster graph analysis, I'd recommend the following workflow as demonstrated in this OSMnx + igraph example:

Download and construct a NetworkX graph using OSMnx
Export NetworkX -> igraph
Conduct fast centrality analysis etc in igraph

This can be done easily by adapting the code in the linked example notebook. The new OSMnx docker image also contains igraph, to make this even more painless (especially for windows users).
Finally, I've never been able to get OSMnx and graph-tool working together in the same python environment due to clashing C dependencies. If someone else has, a PR would be welcome to update the Dockerfile to include graph-tool.

After using the i-graph and observing some inconsistent results, I just discovered that i-graph's centrality definition for disconnected graphs is not very optimal. As per i-graph:
If the graph is not connected, and there is no path between two vertices, the number of vertices is used instead of the length of the geodesic. This is always longer than the longest possible geodesic.
This could be one of the reasons why the closeness centrality in the i-graph is significantly faster than Networkx (which calculates centrality for the individual component), as I guess the weights are not used. For a centrality based on a weighted graph, complexity will be higher O(N^2) and thus longer time.
An ideal would be to use harmonic definition, please see here, here and here, which is a work in progress.
Please correct me if I have understood something incorrectly. :)

authors: e-kotov gboeing kuanb vishalmhjn

repo: gboeing/osmnx


text:
Polish: add refinement overloads to filter / partition (Filterable ty…

…pe class)
This change makes obsolete to define specific overloads of filter / partition in order to handle refinements (e.g. in the Array module) by adding overloads to the Filterable type class.
This change is also beneficial to the data types which don't admit a unconstrained Filterable instance (e.g. Either)
import * as E from 'fp-ts/lib/Either'
import { monoidAll } from 'fp-ts/lib/Monoid'

declare function isString(x: unknown): x is string

const filterableEither = E.getFilterable(monoidAll)

filterableEither.filter(E.right<boolean, string | number>(1), isString)
// before: E.Either<boolean, string | number>
// after: E.Either<boolean, string>

filterableEither.partition(E.right<boolean, string | number>(1), isString)
// before: Separated<Either<boolean, string | number>, Either<boolean, string | number>>
// after: Separated<Either<boolean, string | number>, Either<boolean, string>>

/cc @giogonzo

@gcanti should we also @deprecated the instance methods in Option etc.?

@giogonzo no, I'd wait a final decision on v2 for that.
However we can deprecate:

Array.filter
Array.partition

authors: gcanti giogonzo

repo: gcanti/fp-ts