text:
Added Support for Extenstion-less Assets

Objective

Addresses Support processing and loading files without extensions from #9714
Addresses More runtime loading configuration from #9714
Fixes #367

Solution
AssetServer::load::<A> and AssetServer::load_with_settings::<A> can now use the Asset type parameter A to select a registered AssetLoader without inspecting the provided AssetPath. This change cascades onto LoadContext::load and LoadContext::load_with_settings. This allows the loading of assets which have incorrect or ambiguous file extensions.
// Allow the type to be inferred by context
let handle = asset_server.load("data/asset_no_extension");

// Hint the type through the handle
let handle: Handle<CustomAsset> = asset_server.load("data/asset_no_extension");

// Explicit through turbofish
let handle = asset_server.load::<CustomAsset>("data/asset_no_extension");

Since a single AssetPath no longer maps 1:1 with an Asset, I've also modified how assets are loaded to permit multiple asset types to be loaded from a single path. This allows for two different AssetLoaders (which return different types of assets) to both load a single path (if requested).
// Uses GltfLoader
let model = asset_server.load::<Gltf>("cube.gltf");

// Hypothetical Blob loader for data transmission (for example)
let blob = asset_server.load::<Blob>("cube.gltf");

As these changes are reflected in the LoadContext as well as the AssetServer, custom AssetLoaders can also take advantage of this behaviour to create more complex assets. For example, magic bytes at the beginning of a binary file:
// Inside AssetLoader::load
let path = load_context.path();

// First byte encodes asset type in my custom format
let mut magic = [0];

if reader.read_exact(&mut magic).await? != 1 {
    panic!("Couldn't read magic byte!")
}

let handle = match magic[0] {
    0 => load_context.load::<SettingsAsset>(path).into(),
    1 => load_context.load::<KeyBindsAsset>(path).into(),
    2 => load_context.load::<AudioOptionsAsset>(path).into(),
    v => panic!("Unsupported magic byte value {v}")
};

Ok(CustomAsset { handle })

Change Log

Updated custom_asset example to demonstrate extension-less assets.
AssetServer::get_handle_untyped now returns all UntypedHandles for a path, rather than an Option<UntypedHandle>.
Added AssetServer::get_asset_type_id_asset_loader, which returns the ErasedAssetLoader for the Asset type specified by TypeId.

Notes
I chose to refactor AssetLoaders into its own module because I was having trouble adding support for Asset TypeId information to it due to how tightly coupled it was to AssetServer. This wasn't strictly required, but I believe this is a better state for these types to be in, and should make it easier to update in the future.
As a part of that refactor, I chose to store AssetLoaders (within AssetLoaders) using a HashMap<TypeId, ...> instead of a Vec<...>. My reasoning for this was I needed to add a relationship between Asset TypeIds and the AssetLoader, so instead of having a Vec and a HashMap, I combined the two, removing the usize index from the adjacent maps.

I chose to refactor AssetLoaders into its own module because I was having trouble adding support for Asset TypeId information to it due to how tightly coupled it was to AssetServer. This wasn't strictly required, but I believe this is a better state for these types to be in, and should make it easier to update in the future.

I like this refactor! Decoupling that is a good step, and it's small enough that I don't feel terrible doing it in the same PR.

Because I believe type information is of a higher priority than file extension, I have chosen to ignore the extension unless required (loading without supplying a TypeId). This allows for loading different types of assets from files with the same extension:

Oh this is extremely useful: I've run into this before and had to do bizarre .foo.json naming schemes. In the future, would we be able to get hints from metadata in the file itself? Definitely agree that type info > file extension though.

As a part of that refactor, I chose to store AssetLoaders (within AssetLoaders) using a HashMap<TypeId, ...> instead of a Vec<...>. My reasoning for this was I needed to add a relationship between Asset TypeIds and the AssetLoader, so instead of having a Vec and a HashMap, I combined the two, removing the usize index from the adjacent maps.

Thanks for calling this out: it's a solid choice.

The "disambiguate between assets of the same file extension via type annotations" bit of this PR is wildly useful: can you add / extend an example for it?

I've updated the custom_asset example to demonstrate the creation of a Blob asset loader, which just simply reads the bytes of a file and stores them in a Vec<u8>:
#[derive(Asset, TypePath, Debug)]
pub struct Blob {
    pub bytes: Vec<u8>,
}

This allows loading the same path multiple times, provided they are for distinct asset types:
#[derive(Resource, Default)]
struct State {
    handle: Handle<CustomAsset>,
    other_handle: Handle<CustomAsset>,
    blob: Handle<Blob>,
    printed: bool,
}

fn setup(mut state: ResMut<State>, asset_server: Res<AssetServer>) {
    // Recommended way to load an asset
    state.handle = asset_server.load("data/asset.custom");

    // File extensions are optional, but are recommended
    state.other_handle = asset_server.load("data/asset_no_extension");

    // Will use BlobAssetLoader instead of CustomAssetLoader thanks to type inference
    state.blob = asset_server.load("data/asset.custom");
}

In the example, I also show that you can create a loader with no defined extensions:
impl AssetLoader for BlobAssetLoader {
    type Asset = Blob;
    type Settings = ();
    type Error = BlobAssetLoaderError;

    fn load<'a>(/* snip */) -> BoxedFuture<'a, Result<Self::Asset, Self::Error>> {
        /* snip */
    }

    fn extensions(&self) -> &[&str] {
        // This loader won't be used for any files by default
        &[]
    }
}

This blob loader I think is a good example of where you might want that behaviour; you have an asset which you want to load, but it's not the default way you would interact with that particular file. It would be possible to now provide a default implementation for AssetLoader::extensions, defaulting to this behaviour. However, I haven't done that, as I believe for most users most of the time, they do want to declare a file type (and extension) for their asset.

@alice-i-cecile bump for review.

So @bushrat011899, extending on my proposed use case a bit.

I have multiple types which should be stored as a .json file.
I want to parse the json file to determine what Rust type to load this in as, and then add it to a central collection.

Is that feasible with this PR?
That said, this example seems great to me, and I'm happy to approve this PR as is.

So @bushrat011899, extending on my proposed use case a bit.
1. I have multiple types which should be stored as a .json file.

2. I want to parse the json file to determine what Rust type to load this in as, and then add it to a central collection.

Is that feasible with this PR?

@alice-i-cecile Yes that should be entirely possible:

First you'd create a plain JSON AssetLoader to give you the parsed contents to inspect.

// Handle<JsonAsset> implied by .json file extension if
// `JsonAssetLoader` is configured to be default handler of .json
let my_data_json_handle = asset_server.load("data/my_data.json");

Once loaded, you can then inspect the JSON data for whatever information you'd need to determine the type it should be:

let my_data_json = json_assets.get(&my_data_json_handle)?;

let serde_json::Value::String(magic_token) = my_data_json.get("magic_token")? else {
    return None;
};

// Can re-use the path value for DRY reasons
let path = my_data_json_handle.path().unwrap();

// All match arms need to have the same return type, using UntypedHandle to avoid an enum
let my_data_handle = match magic_token {
    "key_bindings" => asset_server.load::<KeyBindingsAsset>(&path).untyped(),
    "settings" => asset_server.load::<SettingsAsset>(&path).untyped(),
    "scoreboard" => asset_server.load::<ScoreboardAsset>(&path).untyped(),
    _ => my_data_json_handle.untyped(),
};

Some(my_data_handle)

I imagine you'd want an enum for the central collection, and that would probably be the type of my_data_handle in the above match statement instead of using UntypedHandle's. Additionally, this behaviour is extended to the LoadContext::load method, so you could put all of this functionality into a custom AssetLoader. With #10565 and the load_with_reader method @nicopap suggested (would need another PR to add), you could even potentially reuse the Reader, reducing the number of IO operations. But that's all performance optimisation that is entirely optional.

Awesome, I'll spin out a follow-up issue for that.

@torsteingrindvik can I get your review here?

@torsteingrindvik can I get your review here?

Yes- I have a use case for this so I'll try to test it before the week ends then I'll report back.

Just noting this early in my testing:
I switched to this branch in my codebase and now I see
2023-11-18T14:22:55.705371Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705375Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705393Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705956Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705968Z  WARN bevy_asset::server: Could not load asset via type_id

will investigate where these stem from, but noting that more informative logs would be good e.g. which type id is problematic, where did it try to load it from.

2023-11-18T16:41:36.048351Z ERROR bevy_asset::server: Requested handle of type TypeId { t: 299388583603764235311690958868876481710 } for asset 'foo.ron' does not match actual asset type 'path::to::MyBarAsset', which used loader 'path::to::MyBarAssetLoader'

I tried this scenario:

Init an asset loader MyBarAssetLoader which loads MyBarAsset from ron files
Forget on purpose to init asset loader MyFooAssetLoader which loads MyFooAsset from ron files
Try to load a ron file which turns into Handle<MyFooAsset> from a ron file
Get the above error

Two things:

If possible it would be great to map the verbose TypeId in the err msg into a human readable name of the type we're trying to load
Since this PR brings better asset type inference UX, it would be nice if the error message was more along the lines:

2023-11-18T16:41:36.048351Z ERROR bevy_asset::server:
Requested handle of asset type `MyFooAsset` for asset path 'foo.ron' does not have an asset loader.
Other asset loaders registered for this extension are: [
 'path::to::MyBarAssetLoader' for asset type 'path::to::MyBarAsset'
]

Happy with testing now, I can confirm the things I was hoping for is made possible by this PR.
This PR unlocks doing stuff like
app
  .init_asset_loader::<RonAssetLoader<Foo>>()
  .init_asset_loader::<RonAssetLoader<Bar>>()
  .init_asset_loader::<RonAssetLoader<Qux>>()

where RonAssetLoader has a blanket impl of AssetLoader if the generic is an asset.
Super ergonomic, thanks for this PR.

Would this not also make it possible to load assets without a path at all?
For PR #10565 a new method was added to LoadContext::load_direct_with_reader to load an asset from a reader directly instead of from a file. Since the path parameter in that method was primairly used to indentify the correct loader, it would be nice if that can be eliminated.
However, there are some connections between an asset path and asset dependencies that i dont quiet understand yet.

Would this not also make it possible to load assets without a path at all?

Yes absolutely! I'll see how easy it would be to blend those changes into this PR for some even better ergonomics. If I can't get anything clean too quickly I'll palm it off for a future PR. But yes, definitely possible.

Just noting this early in my testing:
2023-11-18T14:22:55.705371Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705375Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705393Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705956Z  WARN bevy_asset::server: Could not load asset via type_id
2023-11-18T14:22:55.705968Z  WARN bevy_asset::server: Could not load asset via type_id

EDIT: After changing the log message, they are all on the form
WARN bevy_asset::server: Could not load asset via type_id from <my asset folder absolute path>/models/Wall/scene.gltf.meta

likely since I don't use meta files for my gltf models. I haven't fully understood the processed/unprocessed workflow yet so not entirely sure if it's a problem on my end or not.

This is actually a really interesting error that I hadn't picked up on. The cause isn't because you're not using meta, it's because GltfLoader (which handles .glb. and .gltf files) can load Scene's, but its Asset type is Gltf. The same behaviour can be seen when running the Alien Cake Addict example. For now, I've updated the TypeId resolution to just give up if there's a label provided with an AssetPath, since it could point to anything. In the future (Asset V2 maybe?) I hope that a better system could be used for contained/labelled assets which could register and expose this behaviour.

Would this not also make it possible to load assets without a path at all? For PR #10565 a new method was added to LoadContext::load_direct_with_reader to load an asset from a reader directly instead of from a file. Since the path parameter in that method was primairly used to indentify the correct loader, it would be nice if that can be eliminated.

I've updated this PR to provide/update 3 methods for working with Reader's on the LoadContext:
load_direct_with_reader_and_path (previously load_direct_with_reader)
Load an ErasedLoadedAsset using the provided Reader, claiming it was from a provided Path. This uses the extension within the provided path to determine what loader to use, and what underlying asset type is loaded. This would be most useful for Zip style loaders which might store a file path internally, and not know what type is actually stored internally.
for (path, reader) in parsed_zip_file.entries {
    let entry = load_context.load_direct_with_reader_and_path(&mut reader, path).await?;
    entries.push(entry);
}

load_direct_with_reader_and_type_id
Load an ErasedLoadedAsset using the provided Reader, claiming it of a type matching the provided TypeId. This uses the TypeId provided to determine what loader to use, and what underlying asset type is loaded. This could be useful for runtime type checking, but I'm not certain how frequently it could be used.
load_direct_with_reader
Load an Asset of type A using the provided Reader. This uses the type parameter A to determine what loader to use, and what underlying asset type is loaded. This is likely to be the preferred option for most users when the asset type can be known at compile time. This would be most useful for containers of known data types (e.g., the GltfLoader could use this to load Scene's, etc.)
for (header, reader) in container.entries {
    match header.data_type {
        ContainedType::Scene => {
            let scene = load_context.load_direct_with_reader(&mut reader).await?;
            result.scenes.push(scene);
        }
        ContainedType::Mesh => {
            let mesh = load_context.load_direct_with_reader(&mut reader).await?;
            result.meshes.push(mesh);
        }
        // ...
    }
}

hmm, What about an additional field: HashMap<AssetPath, Vec<TypeId>> or path_to_id: HashMap<AssetPath, Vec<UntypedAssetId>>. After all UntypedAssetId already stores the TypeId.

Sorry about the radio silence everyone, I had an unusually lovely holiday break over the new year, but I'm back now and wanting to sort out some of these outstanding PRs from last year.
I doubt this will be approved before the 0.13 merge window closes, but I've upstreamed this branch to the latest version of main and resolved all the merge conflicts that produced (of which there were enough that this was basically a full re-write! You guys were busy!)
I've also narrowed the scope of this PR to try and help spur its adoption:

There are no breaking changes in this PR now. All existing public APIs are unchanged in both signature and behaviour.
More specialised functions I added (like load_direct_from_reader_with_type_id) have been removed. I do think they are useful, but they aren't required to deliver on the key features of this PR.
I've removed the refactor I did (loaders.rs), since it nearly doubled the size of this PR on its own, and probably didn't help with the review process.

To focus on the core functionality of this PR:

Assets can now be loaded even if their path is missing an extension using type inference at the call site.
The same path can now be loaded as different asset types, again, via type inference at the loading call site.
AssetLoader's no longer need to define extensions if they are not to be used as a default loader. Instead, they can omit the extensions method in the trait definition entirely.

Thanks again to everyone who reviewed this PR over the last couple months while I was away! ❤

Not sure if okay as-is or not, worth mentioning:
I tried having a CustomAsset and a CustomAssetLoader like your example, which works nicely.
However, if I try loading a CustomAsset from a file named e.g. foo.ron, I get an error that no .ron loader is added.
Loading it from foo (no extension) works.
So I suppose the question is why require listing the supported extension(s) in the loader trait impl at all, when type inference can help out?

I made an example which breaks and I think it shouldn't:

Example
// my-asset
RonAsset (
    name: "Cube 1",
    translation: (0.1, 0.9, 2.4)
)

// my-asset-2
RonAsset2 (
    name: "Cube 2",
    translation: (0.8, 0.3, 0.9)
)

use bevy::{
  asset::{io::Reader, ron, AssetLoader, AsyncReadExt, LoadContext},
  prelude::*,
  reflect::TypePath,
  utils::{thiserror, thiserror::Error, BoxedFuture},
};
use serde::Deserialize;

#[derive(Asset, TypePath, Debug, Deserialize, Component)]
pub struct RonAsset {
  pub name: String,
  pub translation: Vec3,
}

#[derive(Asset, TypePath, Debug, Deserialize, Component)]
pub struct RonAsset2 {
  pub name: String,
  pub translation: Vec3,
}

#[derive(Default)]
pub struct RonLoader;

#[derive(Default)]
pub struct RonLoader2;

#[non_exhaustive]
#[derive(Debug, Error)]
pub enum RonLoaderError {
  /// An [IO](std::io) Error
  #[error("Could not load asset: {0}")]
  Io(#[from] std::io::Error),
  /// A [RON](ron) Error
  #[error("Could not parse RON: {0}")]
  RonSpannedError(#[from] ron::error::SpannedError),
}

impl AssetLoader for RonLoader {
  type Asset = RonAsset;
  type Settings = ();
  type Error = RonLoaderError;
  fn load<'a>(
      &'a self,
      reader: &'a mut Reader,
      _settings: &'a (),
      _load_context: &'a mut LoadContext,
  ) -> BoxedFuture<'a, Result<Self::Asset, Self::Error>> {
      Box::pin(async move {
          let mut bytes = Vec::new();
          reader.read_to_end(&mut bytes).await?;
          let custom_asset = ron::de::from_bytes::<RonAsset>(&bytes)?;
          Ok(custom_asset)
      })
  }
}

impl AssetLoader for RonLoader2 {
  type Asset = RonAsset2;
  type Settings = ();
  type Error = RonLoaderError;
  fn load<'a>(
      &'a self,
      reader: &'a mut Reader,
      _settings: &'a (),
      _load_context: &'a mut LoadContext,
  ) -> BoxedFuture<'a, Result<Self::Asset, Self::Error>> {
      Box::pin(async move {
          let mut bytes = Vec::new();
          reader.read_to_end(&mut bytes).await?;
          let custom_asset = ron::de::from_bytes::<RonAsset2>(&bytes)?;
          Ok(custom_asset)
      })
  }
}

fn main() {
  App::new()
      .add_plugins(DefaultPlugins)
      .init_asset::<RonAsset>()
      .init_asset_loader::<RonLoader>()
      .init_asset::<RonAsset2>()
      .init_asset_loader::<RonLoader2>()
      .add_systems(Startup, setup)
      .add_systems(Update, (set_cube_translation, set_cube_translation2))
      .run();
}

#[derive(Debug, Component)]
struct Cube;

fn setup(
  mut commands: Commands,
  mut meshes: ResMut<Assets<Mesh>>,
  mut materials: ResMut<Assets<StandardMaterial>>,
  asset_server: Res<AssetServer>,
) {
  // circular base
  commands.spawn(PbrBundle {
      mesh: meshes.add(shape::Circle::new(4.0)),
      material: materials.add(Color::WHITE),
      transform: Transform::from_rotation(Quat::from_rotation_x(-std::f32::consts::FRAC_PI_2)),
      ..default()
  });

  // cube 1
  commands.spawn((
      PbrBundle {
          mesh: meshes.add(shape::Cube { size: 1.0 }),
          material: materials.add(Color::rgb_u8(124, 144, 255)),
          ..default()
      },
      asset_server.load::<RonAsset>("data/my-asset"),
  ));

  // cube 2
  commands.spawn((
      PbrBundle {
          mesh: meshes.add(shape::Cube { size: 1.0 }),
          material: materials.add(Color::rgb_u8(124, 244, 255)),
          ..default()
      },
      asset_server.load::<RonAsset2>("data/my-asset-2"),
  ));

  // light
  commands.spawn(PointLightBundle {
      point_light: PointLight {
          intensity: 250_000.0,
          shadows_enabled: true,
          ..default()
      },
      transform: Transform::from_xyz(4.0, 8.0, 4.0),
      ..default()
  });
  // camera
  commands.spawn(Camera3dBundle {
      transform: Transform::from_xyz(-2.5, 4.5, 9.0).looking_at(Vec3::ZERO, Vec3::Y),
      ..default()
  });
}

fn set_cube_translation(
  mut transform_via_asset: Query<(&mut Transform, &Handle<RonAsset>)>,
  ron_assets: Res<Assets<RonAsset>>,
) {
  for (mut transform, asset_handle) in &mut transform_via_asset {
      let Some(asset) = ron_assets.get(asset_handle) else {
          continue;
      };
      if transform.translation != asset.translation {
          info!("Updating {}", asset.name);
          transform.translation = asset.translation;
      }
  }
}

fn set_cube_translation2(
  mut transform_via_asset: Query<(&mut Transform, &Handle<RonAsset2>)>,
  ron_assets: Res<Assets<RonAsset2>>,
) {
  for (mut transform, asset_handle) in &mut transform_via_asset {
      let Some(asset) = ron_assets.get(asset_handle) else {
          continue;
      };
      if transform.translation != asset.translation {
          info!("Updating {}", asset.name);
          transform.translation = asset.translation;
      }
  }
}

Run via cargo run --example hot_asset_reloading --features="file_watcher" (I modified the hot_asset_reloading.rs file).
Initially all seems ok:
2024-01-31T09:39:49.332644Z  INFO hot_asset_reloading: Updating Cube 1
2024-01-31T09:39:49.332663Z  INFO hot_asset_reloading: Updating Cube 2

Updating one of the files via hot-reloading gives an error:
2024-01-31T09:40:19.259971Z  INFO bevy_asset::server: Reloading data/my-asset because it has changed
2024-01-31T09:40:19.260257Z ERROR bevy_asset::server: no `AssetLoader` found for file with no extension

Updating the other file does not give an error, but the system updating the translation doesn't run like it should either
2024-01-31T09:40:29.994741Z  INFO bevy_asset::server: Reloading data/my-asset-2.ron because it has changed

I made an example which breaks and I think it shouldn't:
Example
Run via cargo run --example hot_asset_reloading --features="file_watcher" (I modified the hot_asset_reloading.rs file).

Ah that's why I'm having trouble replicating this issue myself, I wasn't testing with the file_watcher feature. Thank you for posting this! I'll look at this and see if I can get this PR compatible with that feature as well.

Ok @torsteingrindvik this should be resolved now. Again, thanks for testing this, I had completely forgotten to test against the file_watcher feature. As an aside, the fix involves now passing the original input_handle into the load_internal method called by reload, which should skip a fistful of redundant operations involved in getting/recreating the handle. Probably no performance impact in the real world, but still nice.
Running your example now works as expected, where editing the extensionless assets is immediately reflected in the running application with no runtime errors.

Ok @torsteingrindvik this should be resolved now. Again, thanks for testing this, I had completely forgotten to test against the file_watcher feature. As an aside, the fix involves now passing the original input_handle into the load_internal method called by reload, which should skip a fistful of redundant operations involved in getting/recreating the handle. Probably no performance impact in the real world, but still nice.
Running your example now works as expected, where editing the extensionless assets is immediately reflected in the running application with no runtime errors.

Great! Approved. Thanks yourself for the nice PR.

authors: LennysLounge alice-i-cecile bushrat011899 nicopap torsteingrindvik


text:
update Window's width & height methods to return f32

This allows for better precision of the width and height when the scaling factor and physical resolution come together to produce a logical resolution that is not an integer. Admittedly, this will have little effect on most usages. An issue would occur if things were being laid out relative to the right or bottom edge. In this case it would be common to subtract some offset from the width or height.
It was requested to provide a demonstration of the ill effects this PR would resolve. Producing an example in engine is difficult (for me at least) and unreliable due to having no control over the scaling factor. Instead I created the following illustration of a scenario where trouble could occur.
In the example below imagine a line is being placed along the right most edge by subtracting 0.4 logical pixels (0.5 physical pixels) from the width to get the line to fall in the middle of the last pixel. Because the width is not precise enough the bounds of the line do align with the pixel grid. This causes the line to bleed into the neighboring pixels and not achieve the target color.

Is there an Operating System that creates non-integer sized windows?

When running in high DPI monitors the logical resolution is scaled down from the physical resolution (physical pixels). On my current workstation, I run a 125% scaling factor so each physical pixel is 0.8 logical pixels, then depending on what size my window is, the resulting logical width may not be integral.

Cool cool having looked into the details of winit a bit (and considering the example above), this looks like its the right call.

I think we need to align WindowDescriptor::width/height and set_resolution. They are the "same" property in my mind (they are both logical resolutions). We should either allow people to specify fractional sizes  (which I expect to behave counterintuitively for computers with a scale factor of 1) or we shouldn't.
They also currently behave differently right now. If i set my os scale factor to 2.0, then create a window that is initially 1280u32 x 720u32, I get a window that is 2560u32 x 1387u32 physical units. (note that my display has a physical height of 1440). I'm assuming this gets "clamped" to a slightly smaller max height to account for window decorations (and maybe desktop shell menus).
Calling  set_resolution(1280., 720.0) causes wgpu to fail to create window textures (and the app fails to render):
wgpu_core::device: Requested size 2560x1440 is outside of the supported range: Extent2D { width: 2560, height: 1387 }..=Extent2D { width: 2560, height: 1387 }

Changing set_resolution back to u32, removing the manual scaling for "up" to a physical scale, then in the winit backend using LogicalScale instead of PhysicalScale when responding to SetResolution commands resolves the bug (and make the behavior consistent).

After Looking into this a little bit, its a catch 22. We can't know what the quantization of the logical size will be until we know the scale factor, but we can't know the scale factor until we have created the window on a particular monitor. Specifying the size in logical values will always be a guess, and we will find out the truth once the system has created or resized the window.
This creates a some challenges. For one, prior to creation we currently have no way to store the guess for the size to use during the create. It also raises some questions about the behavior of the width and height properties with respect to their values once we learn the scale factor.
From where we are now, it seems to me that the solution is to store the "requested" logical size and an optional physical size that is updated when we learn the truth about it. The width and height functions would return the requested size always, and the logical_width and logical_height methods would come back to life to report the true value if we know them. This would require that logical_width, logical_height, physical_width, physical_height all return Optionals, since until the window is created we don't know what they will turn out to be.
In the scenario @cart highlights where the OS clamps one of the dimensions, the width or height could diverge from the truth significantly which seems counter-intuitive.
In my mind the difference between f32 and u32 is fairly minor (sans potential layout alignment issues). The real issue is that what is passed via the window descriptor or the set_resolution call is only a request, and what you actually get could be quite different dependent on you environment.
I have begun implementing what I described above, but I fear that this effort has opened a small can of worms that should have saved for later.

Maybe we can sort of "punt" this problem:

WindowDescriptor doesn't need to care about physical size. Its just a request for a new window
We can rename set_resolution to something like queue_resize(logical_width, logical_height). This wouldn't update the fields until the "real" values are known
Users that care about reacting to the actual new size can listen for resized events.

This way, both apis can be consistent, and both apis can just be "requests".

I have update this PR based on comments from @cart. It seems like a little much for something so minor, but I think something like this is necessary to cover to properly handle high DPI.
While playing with this I started to notice an issue with the UI layout. In the squash crate, all coordinates are rounded to the nearest whole number, and we pass logical coordinates. On a high DPI monitor this prevents that final placements from aligning to the physical pixel grid which produces artifacts.
I have a commit based on this PR that converts everything to physical coordinates before passing to squash, then converts back to logical coordinates once squash produces a layout. This aligns everything to the pixel grid which cleans up the issues. It still needs a little work though before it is ready for review.

My changes to flex are ready for review. I was going to wait until this PR is resolved before submitting them as a separate PR since the issue it addresses is related but independent of what this PR addresses. I could add it to this PR though, if that is preferred.

Awesome! Looking now. Lets do the stretch changes in a separate PR.

Turns out we can remove the "option" returns and simplify the code by making winit/bevy window creation "atomic". Theres no need to "wait".
Everything works as expected for me in all permutations of 1x + 2x scale factors / windowed / fullscreen

I tested it on some non-integral scaling factors, and it looks good in my setup. The window creation change really did the trick!

Awesome. Thanks for adding the WASM fix :)

source: gharchive/pull-request

authors: blunted2night cart smokku

repo: bevyengine/bevy

license_type: permissive

license_source: github-api


text:
Add optional shared bind group to custom materials

Objective
Add the possibility for all instances of a custom material to have a shared data set (Uniforms, Textures, Samplers, etc.) or multiple custom materials to share a common data set.
This can be used for things like:

Global general data like Time can be uploaded only once per frame and then used by multiple materials. (Semi-alternative to: #5409
Material instance common data. textures, world information, etc. (e.g. Environment global wind direction can be used in multiple instances of a custom shader)

In my project the need arose when trying to visualize my world grid in multiple shaders.
Solution

Add an associated type named SharedGroup to the Material trait that specify a resource that can be turned into a bind group (must impl AsBindGroup). This resource can either use the derive(AsBindGroup) to specify shared static data (e.g. shared textures, samplers) or manually implemented for user managed buffers etc. (The animated shader example have be updated to use this pattern)
Update MaterialPlugin to bind the SharedGroup bind group to slot 3 if present. (If no shared group is specified the code path should be identical to pre- this patch)
Add a convenience plugin that will fetch a resource that impl AsBindGroup and prepares it for use as a shared bind group in the material plugin.

Alternate Solution:

Instead of an associate type on the material trait, the material and its shared group could be more "loosely" bound via one extra generic parameter on the MaterialPlugin. I.e. MaterialPlugin<M: Material, G: AsBindGroup = ()>. Pros: It could then default to () without any changes needed to existing custom materials. Cons: I have not tested this fully, and are not really sure  how it would affect speciallization etc. But it should be doable.

Changelog

Changed Material trait to include a SharedGroup associated type
Changed MaterialPlugin to support an optional user-specified shared bind group
Added SharedBindGroupPlugin to help prepare shared bind groups

Migration Guide

Add type SharedGroup = (); to all custom materials (impl Material for X)

Hi, First time pull-request here :). Hope the description makes sense. Happy for any feedback.

I clicked the wrong button, I didn't mean to approve 🤦♂
I don't know how to reset approval though.

Fully agree with you on basically all accounts.

I'm not a fan of using an associated type for that. It adds complexity to all uses of Material even if most Material don't need shared data.

Me neither, it is unfortunate that it forces boilerplate on all implementations. I will try an implementation of the alternate (in the description) and see how that goes.

I also don't like the need for a new branch everywhere you want to add a draw command that could potentially make use of the shared data.

Are you referring to the two sets of draw commands (DrawWithoutSharedGroup and DrawWithSharedGroup)? Honestly I thought these where only meant for internal use within the MaterialPlugin, but maybe I have missunderstood their full purpose.

I don't think this should be an alternative to adding a time/globals bind group. This is something that is useful in enough situations to justify a permanent bind group and most other engines also offer similar features. Especially if people want to have more things other than time, it would be annoying that they would now need to merge them somehow.

Agreed, personally I would like both a standard set of often used globals (time, etc.) and the option to add your own. In my case some map data for my grid.

Are you referring to the two sets of draw commands (DrawWithoutSharedGroup and DrawWithSharedGroup)? Honestly I thought these where only meant for internal use within the MaterialPlugin, but maybe I have missunderstood their full purpose.

Yes, but reading the code again, it's not as bad as I thought. It's still a bit unfortunate that it needs to separate sets of draw commands.

Changed the implementation to use a optional (defaulted to ()) generic parameter to the MaterialPlugin instead of the associated type on the Material trait. This changes the feature to be purely additive rather than requiring changes in existing code. No more added boilerplate when not using a shared bind group.

I definitely appreciate the need that you put forth in the description and you clarify your approach well.
A couple of things come to mind:

When bind groups are bound, all bind groups with higher indices also have to be rebound. Binding has a cost so this performs less well if the bind rate is not from least (e.g. view or global bindings in group 0) to most (e.g. per-draw mesh bindings in group 2, currently.)
The approach I have been thinking about is to make it possible to configure the different bind groups. The bind group layouts can be modified through pipeline specialisation but there is no easy way to create the bind groups. AsBindGroup only supports a type including an entire binding, and that doesn’t help with, say, if you want to add some global or low-bind-rate data to bind group 0. So I’m trying to think about a flexible and efficient way of supporting composable bind group layouts and perhaps an easier and more flexible way to create bind groups. AsBindGroup also creates a separate buffer for each instance of that type. That maybe works fine for one material in our current one Mesh means one draw setup, but we want to move toward batching draw calls and ultimately bindless textures which then means trying to move toward having all instance data in an array in one buffer, storing indices in appropriate ways to look up that data.

So, I want to peel back AsBindGroup a bit to ideally have methods that return bind group layout entries and bind group entries or something like that such that one can say ‘I want the view uniform binding in bind group 0 binding 0, and this noise texture and sampler in bind group 0 bindings 1 and 2’ etc. I don’t know what @cart thinks about this exactly. I think they’ll be on board with the flexibility as long as the ergonomics and performance are there. :) And if we take a plain data only material asset (ie no textures/samplers) as an example, I want those to be written into arrays in single buffers and the array index to be stored in a component on the render world entity, kind of like the mesh uniform dynamic offset stuff, but array indices instead of buffer offsets.
I started work on all this but unfortunately I don’t currently have the time to continue.

Alright, this is very interesting.

When bind groups are bound, all bind groups with higher indices also have to be rebound. Binding has a cost so this performs less well if the bind rate is not from least (e.g. view or global bindings in group 0) to most (e.g. per-draw mesh bindings in group 2, currently.)

Ah, that makes some things a lot clearer. I knew that the best/common practice was to group the shader resources by frequency to minimize binds/rebinds, but not that the actual index mattered. That., of course, makes my proposed implementation less than ideal to say the least.

So, I want to peel back AsBindGroup a bit to ideally have methods that return bind group layout entries and bind group entries or something like that such ...

Yes, I was thinking the same thing while diggin' through the code for this implementation. For me it was simply the fact that after the .bind_group_layout(...) method is called there is no way for the caller to know what is actually in the layout. For instance in this feature, being able to know if the layout is empty would be valuable to opt for a code path with no binding at all.

The approach I have been thinking about is to make it possible to configure the different bind groups. ...

This would be fantastic. While working on this I was thinking of something similar where the material system have couple of named contexts or "buckets" for shader resources defined. E.g. GLOBAL, SHADER, MATERIAL, MESH. Where each correspond to a update frequency or basically nesting depth in the render loop.
Then the AsBindGroup becomes something akin to a AsResourceSet instead that only return a collection of resource descriptors that are named and assigned to contexts. The material system would then be in charge of creating the actual layouts and groups enabling some optimizations like removing empty groups, sampler deduplication etc.
On the shader side some preprocessor magic creates a set of constants that enable the shader to access resources via name and not needing to know the actual group and binding id that have been assigned.

authors: IceSentry marlyx superdump


text:
Fix wavy text

Addresses #283
Quick fix for wavy text.
You can see the difference in the "ing" in "Nothing".
Before

After

Here is what it looks like in Word for reference:

Commit history is polluted.


text:
Remove Children component when calling despawn_descendants

Objective
Fix #8474

Should this get a regression test?

I would like to see a regression test, yeah :)

authors: B-Reif alice-i-cecile devil-ira


text:
Websocket is not running, could not able to debug

Hi everyone,
I've implemented websockets with pusher replacement successfully on my system. However sometimes when I am installing it on dev servers it seems, websocket is not starting. Its only showing plain message as 'Starting the WebSocket server on port 6001..." .
I am not able to understand the reasons & don't know how to debug as no error messages are being shown from this package. Can anybody advice?
For your information,
my dev server IP is local network ie. 192.168.X.X  & pusher port 6001.
No SSL etc. Its plain.
SITE_URL/laravel-websockets also not able to connect. So my understanding is websocket is not correctly starting.
Any clue would be great help to me.
Thanks

Already abandoned

Hi Parallels999,
I didn't catch you. Could you please help me understanding.

Hello @skodilkar, are you using a Docker container to run your application? If so, make sure you forward your ports in your docker-compose
 ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'
            - '6001:6001'
            ```

source: gharchive/issue

authors: Arr-n-D parallels999 skodilkar

repo: beyondcode/laravel-websockets

license: MIT


text:
feat: Implement CreateLink and setup linker test in go-service-oss

feat: Implement CreateLink and setup linker test in go-service-oss

Do we need to check whether the object is symlink in List? Or add the check later?

Do we need to check whether the object is symlink in List? Or add the check later?

I think both are fine. If we need to check if the objects in the list are symlink, then we need to add ListMode support for symlink to go-storage first.

If we need to check if the objects in the list are symlink, then we need to add ListMode support for symlink to go-storage first.

I think there's no need to add ListMode for symlink.
We can get the object type form the response of ListObjects. We just need to set the object mode to ModeLink  if the type is Symlink.

authors: JinnyYi abyss-w

repo: beyondstorage/go-service-oss


text:
grafana_dashboard can't use it

Hi,
I did the simplest init.pp to test grafana_dashboard. I also exported a test dashboard I created in grafana as test.json and put it in grafana/templates. But when I test my module I gete this error:
Error: /Stage[main]/Grafana/Grafana_dashboard[testboard]: Could not evaluate: can't convert Hash into String
I just can't figure out why it's happening, is there a problem with my json file since I exported it directly from grafana I assumed it was ok. If not how should it looks.
Thx!
class grafana {
grafana_dashboard { 'testboard':
grafana_url       => 'http://localhost:3000',
grafana_user      => 'admin',
grafana_password  => 'admin',
content           => template('grafana/test.json'),
}
}

I had the same error on CentOS 6.8. Created #115 with a fix which worked for my case.

repo: bfraser/puppet-grafana

license_source: bigquery


text:
Performance improvement

This is an issue tracking efforts on improving the parsing performance to reach the level of other C implementation.

[x] benchmark comparison
[ ] async crate

Will use #12 to better keep track of performance before we attempt to improve it.

repo: bgpkit/bgpkit-parser


text:
Positioning bug fix

There is a great possibility to pose dropdown colorpicker about button using margins on .sp-container in CSS, but .offset method calculates such top and left that dissolve margins and colorpicker stands on it's place. If .css method is used margins work.

It's posed incorrectly if appended not to body. So request is closed.

repo: bgrins/spectrum

license: mit


text:
allow cargo vet to be used as a library

This has been requested. Totally in favor of supporting this, though we may want to wait until there's a specific consumer to kick the tires.

I think we'd be interested in using cargo-vet as a library in cargo-deny as it fits in with the general ethos of that tool, which is automatically verifying dependencies meet a project's basic requirements on various axes.

Do you have any idea what you'd want the API surface-area to look like?

We've been slowly reworking the code in the general direction of this. There is still only a main.rs, but most "applicationy" things are now isolated to it. We expect to split part of main.rs into a new lib.rs. What would remain in main.rs is:

fn main
fn real_main
fn cmd_*
the ci module that has all the clap stuff
some odds and ends related to terminal UI

Things like miette::Report and Console would be banished to main.rs, and I've already narrowed their scope a lot to reflect this. Library things are now largely all using type errors, which still uses miette to add extra hierarchy (list of errors nested under high-level errors) but they're normal Errors you can Display if you want, no need to pull in miette "pretty".
Things like minimize_unaudited would be moved to lib.rs as core operations.
The biggest TODO for this split is to cleanup Config which currently contains a copy of the CI flags, which presumably library users don't want to have to fill in/use.
The other big question is "what do library users want from this"?
The current design is that you run cargo-metadata to get the lockfile state and Store::acquire to load+parse the contents of supply-chain. Then you can do whatever analysis/adjustments you want on the parsed structures, and then do store.commit() to write back the results. All cmd_* functions just do this.
The heart of the analysis is resolver::resolve which takes the store and metadata and does vet check, producing either some happy stats or a list of problems. Either way you will get a ton of datastructures describing exactly how you passed/failed. You can then compute_suggest to get the suggest output. This involves a bunch of extra network/disk traffic as we do a bajillion async diffs and Cache those results for subsequent runs.
Commands like certify literally just push a value into the Store before committing. Commands like inspect tell the Network/Cache to ensure we have access to the source of some packages and does some operation on the returned paths.

I can try to block out some time later this month (most everyone is going on vacation here) to try integrating the vet functionality into cargo-deny as a concrete test case to find pain points or issues.

It's worth calling out that the most loosely-coupled approach for embedding cargo-vet would be to just parse the JSON output (like a CI use-case would). The tool is pretty fast to run even with hundreds of dependencies, and so it's worth at least considering the simple approach.

authors: Gankra Jake-Shadle bholley

repo: bholley/cargo-vet


text:
How to select all residues within radius of mouse click?

Hi, thanks for the great viewer!
I would like to create a new view containing only residues that fall within some distance X from my mouse pointer. I would like this selection to be highlighted and move around as I move my mouse around. Is this possible?

Sounds like it would be very possible, it should be fast enough.
You would need to create a selection based on the mousemove event, such as
var rect = pv_viewer.boundingClientRect();
var picked = pv_viewer.pick({ x : event.clientX - rect.left,  y : event.clientY - rect.top });
And then selectWithin a PV structure (eg protein = pv_viewer.get('model01').structure() )
protein.selectWithin( picked.target(),
{
radius: 4,
matchResidues:true
});
matchResidues extends the atoms found in the radius to be a complete residue.

Also when I am not hovering directly over an atom, I get this error.
Uncaught TypeError: Cannot read properties of null (reading 'target')
    at HTMLDivElement.<anonymous> (index.html:58:24)
(anonymous) @ index.html:58

I want to pick up atoms within a given radius of my mouse even if my mouse if not on top of an atom. Is this possible?

I see the selectWithin only works on residues, not atoms. So Some minor changes -

That worked quite nicely. Thanks! :)

repo: biasmv/pv


text:
EEG/iEEG suffixes are not listed in the Entities appendix

https://github.com/bids-standard/bids-specification/blob/master/src/99-appendices/04-entity-table.md

the entity entries (REQUIRED vs OPTIONAL) should be the same as they are for MEG, so we could expand the MEG columns to say something like

[meg, eeg, ieeg]
(channels)
and [meg, eeg, ieeg]
(photo coordsystem headshape)

potentially differing entities such as the space (discussed here) are not yet listed in this appendix.
for eeg and ieeg alone we would then need to add only a column for electrodes files:

[eeg, ieeg]
(electrodes)

Am I missing something? cc @robertoostenveld @choldgraf

+1 from me

I am not sure whether the two columns work: I think that the table should only contain data (i.e. channel-time-series data) and tsv files, and no json files.
coordsystem is a json (sidecar file), not a data file. It would not have key-value pairs in the file name that the corresponding data (electrodes.tsv, or MEG sensor information stored in the MEG data itself) would not have.
photo contains data, and headshape also contains data (i.e. both are experimentally measured/determined). The same goes for electrodes. But photo and electrodes do not have the same key-value pairs in their file names. E.g. photo is not (cannot be) expressed in different coordinate systems, so the space-xxx pair would not apply, whereas it could apply for headshape and electrodes.

Although I don't know the solution at this moment, I propose to make a table (e.g. google sheet) with initially all types of files in separate columns, and the same rows as here, then start adding the REQUIRED/OPTIONAL, and then check which columns end up the same and then possibly collapse them again. Or even keep them separate: this will make the table wide, but ensures that each file type can be found.
Let me just make a quick start: see the table here.

Thanks for getting started on the table @robertoostenveld, this is much cleaner compared to what I proposed. I made a few comments and will add some work later.
As an additional enhancement it might be good if we turn each row of the first column into links, so that people can directly jump to the description of e.g., proc or ce

... it might be good if we turn each row of the first column into links, so that people can directly jump to the description of e.g., proc or ce

That would indeed be nice. I find myself spending a lot of time searching for these details.  It would require an (invisible) anchor to be added to the text sections. At the end of this page there are some suggestions for anchors in text (as opposed to headings, where they are automatically made)

I was actually only thinking about linking to the nearest heading, but the anchor idea is much better. Let's implement that once we update the entity table with our draft from your google doc

authors: choldgraf chrisfilo robertoostenveld sappelhoff

repo: bids-standard/bids-specification


text:
FIX: Do not require notch frequencies to be parsed as numbers, accommodating triplets

While schematizing, the notch column was defined as a number. In the case of iEEG at least, the BEP leads had submitted examples where notch took the form [low, center, high]. This PR recognizes this as existing practice and recommends that curators and tools adopt [low, center, high] for interoperability, but does not require it.
cc @bids-standard/raw-electrophys for comment.
Closes https://github.com/bids-standard/bids-examples/issues/395.

@adam2392 Are you comfortable with the current wording leaving open the possibility of a more structured recommendation/requirement in the future?

Thank you for the clarification. Is the current wording better?

Yes, thank you! Just a minor suggestion is to say: "If notch filters are applied at multiple frequencies, these frequencies MAY ..."

@Andesha is this something you'd feel comfortable taking a moment to review?

authors: christinerogers dorahermes effigies


text:
Update Input Datatype Details and Fix Sorting Features on BIDS-Apps Page

First of all, we’d like to thank you for the effort you’ve put into the new website; it looks fantastic.
Our teams, Hippunfold and Micapipe, noticed that the “Status of the Latest Docker Image” table on the BIDS-Apps page currently lacks input datatype details for both tools, and “uses raw” is marked as “no.” We were wondering if this information is automatically pulled from the Docker hub or the GitHub repository and if there’s a way we could update it ourselves to correct the information.
The intended entries should be as follows:

App
Input Datatype
Uses Raw
Use Derivatives

hippunfold
anat
YES
NO

micapipe
anat, dwi, func
YES
YES (could use FreeSurfer/FastSurfer derivatives)

Additionally, we observed that the sorting features for “Number of Docker Pulls” and “Image Size” don’t appear to be working as expected. One last issue is that the table width does not fit the screen, and one column is missing even when adjusting the zoom or switching browsers.
Could you also clarify what “status unstable” means on the table "Status of the default branch on the source repository"?
Thanks again!

thanks for getting in touch and for the feedback

if there’s a way we could update it ourselves to correct the information.

most of the metadata for the bids apps is stored in this file: https://github.com/bids-standard/bids-website/blob/main/data/tools/apps.yml
can I let you update the info with a pull request? it'd be MUCH appreciated.

the sorting features for “Number of Docker Pulls” and “Image Size” don’t appear to be working as expected.

yup that's a bug I have noticed but forgot to open an issue for
I suspect that the sorting is done based on the name of the svg image represented in the 'badge' rather than by the actual number (or something like this)
Not had the time properly investigate or fix.

Could you also clarify what “status unstable” means on the table "Status of the default branch on the source repository"?

ah yeah that's underexplained at the moment: we should add some info
so the status of the latest image should mean: if I pull the latest 'stable' version from dockerhub and run the test contained in the repo: do they pass?
the unstable table is meant to represent the status of the bids-app on the default branch of the repo. with every commit or pull request merge we run the following tests:

try to build the docker image
try to use that image to run the bids app on some lightweight bids dataset
if that passes we push that image to dockerhub with an 'unstable' tag (can be useful if users want to check the bleeding edge version of an app that has not yet been released)
if any of those fail then this table should let us know about it

as you can see this is still work in progress

Could you also clarify what “status unstable” means on the table "Status of the default branch on the source repository"?

So I quickly looked.
It seems that micapipe has no test set up to run in continuous integration in the repo, so we should probably have some "not available" for this case.
For hippunfold I guess the workflow that could be used for 'unstable' would be this one: https://github.com/khanlab/hippunfold/actions/workflows/python-testing.yml

Thank you for your quick reply, good luck fixing the bugs of the website.
We updated the apps info in the  apps.yml see the  PR 568 .
We'll work on a CI for micapipe. we've tried before but github actions crashed because the container was quite big. so we need to use a different strategy. Do you have any suggestion?
We'll follow up the hippunfold ci @jordandekraker

github actions crashed because the container was quite big. so we need to use a different strategy. Do you have any suggestion?

a lot of bids apps use circle-CI to run their CI: not sure how big your image is but this could maybe work.
worth checking how much circle-CI allows you

authors: Remi-Gau rcruces

repo: bids-standard/bids-website


text:
Digital Ocean => DigitalOcean

I've been lurking on BBS for a bit and I know this is super nitpicky, but this corrects "Digital Ocean" as "DigitalOcean". One of my... enterprising... colleagues even made our internal SlackBot fix this internally!

The community is cool so far, looking forward to making some actual posts soon!

oops thanks!

authors: davidcelis ednapiranha

repo: bigboringsystem/bigboringsystem


text:
Add semi RPC commands to the API

I've been hard at work building stuff based on BigchainDB and since I'm not working in Python, I've come across some difficulties in getting a stable system going. (especially together with docker)
I want to be able to perform all actions the python client can perform (e.g. follow the documentation example) but not in Python, but from my NodeJS code. While there is some REST api calls, there is too much missing to make it usable at the moment. (I understand the difficulty in building and maintaining this REST api)
I started out with an extra Flask api between my code and the bigchaindb node, but that becomes a mess quickly because you need to sync keys, but not hostnames, and an extra http component is not very beneficial for performance.
I took a page from bitcoin and multichain, and by pure googling and stack overflowing I fabricated this addition to the API. It allows any function call or variable call through the api. With no maintenance at all if the client should change.
warning: I have no idea about the security repercussions of what I did here, please use it as input, not a finished product*
It supports all methods of the bigchaindb client, all variables in the client, and all variables and calls on the crypto component.
Examples:
POST http://bigchain.docker:59984/rpc/bigchaindb

{
  "method": "me"
}

{
  "result": "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse"
}

POST http://bigchain.docker:59984/rpc/bigchaindb

{
  "method": "create_transaction",
  "params": {
    "owner_before": "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse",
    "owner_after": "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse",
    "tx_input": "None",
    "operation": "CREATE",
    "payload": {
      "naam": "test"
    }
  }
}

{
  "result": {
    "id": "659171e4921d64cfe7bddbfb3cb00744e6951b0403e52dca4e91c1dc4600e65d",
    "transaction": {
      "conditions": [
        {
          "cid": 0,
          "condition": {
            "details": {
              "bitmask": 32,
              "public_key": "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse",
              "signature": null,
              "type": "fulfillment",
              "type_id": 4
            },
            "uri": "cc:4:20:rOxXPC6VwwilYi1O51Dkv43dFr645s6j2v10o0tm6y0:96"
          },
          "owners_after": [
            "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse"
          ]
        }
      ],
      "data": {
        "payload": {
          "naam": "test"
        },
        "uuid": "525b73f4-ff93-476f-8871-82eef9f0dc31"
      },
      "fulfillments": [
        {
          "fid": 0,
          "fulfillment": null,
          "input": "None",
          "owners_before": [
            "Ce29QivVvJuNgTGbrPBuWEaRwrG2Nhqa8kR55V3QpLse"
          ]
        }
      ],
      "operation": "CREATE",
      "timestamp": "1474880951",
      "version": 1
    }
  }
}

POST http://bigchain.docker:59984/rpc/crypto

{
  "method": "generate_key_pair"
}

{
  "result": [
    "4MspmDAsnBGRPVQVDGmGtDhb51zBnbvWe85hy79V6FHD",
    "Fs7omc6FDbTQqdH14ovK6dWjWLXoEBFW1VmF3cHzsz3q"
  ]
}

I believe something like this would make it a lot easier for developers in other languages to get started.
Thoughts?

Current coverage is 93.61% (diff: 23.07%)

Merging #639 into master will decrease coverage by 2.10%

@@             master       #639   diff @@
==========================================
  Files            23         24     +1
  Lines          1308       1347    +39
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1252       1261     +9
- Misses           56         86    +30
  Partials          0          0

Powered by Codecov. Last update 6c43bc3...80aecc7

Thanks for this proposal.
We understand the pain right now in using bigchaindb with other languages other then python.
We have discussed internally whether to use REST or rpc calls.
I personally don't feel comfortable opening the nodes so much to rpc calls.
With bitcoin its a bit different, you can just install the bitcoin daemon download a copy of the blockchain and do whatever you want locally with little to no impact with the rest of the network.
With bigchaindb is a bit different assuming that you are a client you will always have to communicate with a remote bigchaindb federation node which needs to have a tight control over its resources.
We are currently working hard in separating the bigchaindb server and client code and at the same time improving the api to bring it into a more useful state.
Another idea that as been floating around would was, the python client driver could not only be a client to the bigchaindb REST API but it could also provide a command line interface similar to bitcoin-cli to perform several operations. The reason for this is that a client needs to not only be able to perform REST calls but it also needs to implement all the crypto code to be have to generate and fulfill cryptoconditions, basically the client also needs to implement the cryptoconditions spec.
So I like the idea of possibly doing something like this but in the python client driver .
@diminator thoughts?

I'm not following a 100%. Yes, RPC will result in a bit more 'calls' since it's not possible to create methods like in the examples made by @diminator or in the client.py that combine a few bigchaindb python calls. But load wise, these calls do still happen internally and add only some network traffic overhead. At the same time access to these calls can be limited by the IP address of the flask server, and via traditional firewall rules.
The python client driver is essentially the code that I wrote in NodeJS, but I need a way to get the different commands to bigchaindb, via an API (be it REST or RPC, I couldn't care less 😄 ). A cli component that my code needs to call is not a very clean solution. While I use b.me and b.me_private over the API, an approach like the python client is possible however.
Calls that are needed for sure are:

crypto.generate_key_pair (I can do this implementation in node as well, but this is duplicating logic)
create or

create_transaction
sign_transaction
validate_transaction
write_transaction

transfer or

create_transaction
sign_transaction
validate_transaction
write_transaction

get_owned_ids
everything related to fulfilment and crypto conditions (have not implemented them yet, don't know the full list)

@roderik First of all: Thanks so much for committing time to this project :tada:!
To give you context:
We're currently in the process of separating client and server logic. Logic that can be used on both server and client can all be found here: https://github.com/bigchaindb/bigchaindb-common
Some methods seem to be quite interesting for you:

Generate a CREATE transaction: https://github.com/bigchaindb/bigchaindb-common/blob/master/bigchaindb_common/transaction.py#L308
Generate a TRANSFER transaction: https://github.com/bigchaindb/bigchaindb-common/blob/master/bigchaindb_common/transaction.py#L360
Sign any transaction: https://github.com/bigchaindb/bigchaindb-common/blob/master/bigchaindb_common/transaction.py#L435
Serialize a transaction to a dict (and then json): https://github.com/bigchaindb/bigchaindb-common/blob/master/bigchaindb_common/transaction.py#L555

My idea (and this we do not even have on the roadmap yet) was that we could potentially have a binary (executable on maybe on various Unix systems) that uses these function's parameter signature, but on the command line. Each of those commands would take JSON as an input and would yield JSON as an output.
This way, it would be very easy for other developers to write language-specific bindings for this unix-binary.
I kinda stole this idea from https://github.com/bitpay/bitcoind-rpc/blob/master/lib/index.js
Not sure how much that helps you at this very point, at least it gives you a direction on where we might be going.

Thanks @roderik, your effort seems in-line with some of our internal efforts on creating a suitable (python) driver and exposing the API endpoints. Very interesting approach, but as you and @r-marques mentioned, might expose the nodes a bit too much from a security point of view. RPC methods would open up the internals of BDB more, but could likely be restricted to what a standard JSON API would offer.
Most of the API discussion is grouped in #601 (and PR's like #554, #555, #624 spin out of that)
We'd want to have support for at least a JSON driver, hence I would like to categorize some of the endpoints you proposed and see what's the shortest path to a JS driver.
This that make sense to serve through a/the JSON API are:

write_transaction ie POST /transactions
get_transaction ie GET /transactions/{tx_id}
get_owned_ids ie GET /transactions/unspents/{owner_id} see #624

Could be part of either JSON API and/or JS/Python driver:

validate_transaction ie POST /transactions/validate (not implemented yet, but makes sense). When validation in the client would only the crypto would be validated, not the federation rules (doublespends, ...)
generate_key_pair ie POST /accounts (not implemented yet, but could be part of a KPI infrastructure), should be an easy starting point for KPI infrastructure

Probably part of only the (JS/Python) driver:

create_transaction: return a template of a transaction with some prefilled fields. Probably the main driver routine to be foreseen in a JS environment
sign_transaction and everything related to crypto-conditions. This should be relatively easy using the JS version of crypto-conditions.

I'm going to have to move forward using my method in a forked docker image, my PoC needs to progress fast 😄 I'll refactor later.
But on the longer term, what can I do to help in this regard. So much is in flux in different PR's that it's hard to get a grasp on the next steps.

@roderik: The development here might be of interest to you.
@r-marques @diminator: How to proceed with this PR?

I feel that between the api and the cli everything in here will be covered.
The http api itself should take care of most of https://github.com/bigchaindb/bigchaindb/pull/639#issuecomment-249819462
Except for signing and manipulation of conditions and fulfillments that need to be handle client side and which the cli should provide

authors: TimDaub codecov-io diminator r-marques roderik

repo: bigchaindb/bigchaindb


text:
Silverstripe 5 support

Checked against an Auth0 installation and it seems to work OK.  The league/oauth-client is still on major ^2 upstream, so the dependency doesn't need to be changed.

Thanks @elliot-sawyer

authors: elliot-sawyer kinglozzer

repo: bigfork/silverstripe-oauth


text:
Add dictionaryOf method

Overview
This pull request adds a dictionaryOf(_:type:) function that is analogous to the existing arrayOf(_:type:) function.
Example
This pull request makes the following example possible:
let residentJSON = JSON.Dictionary([
    "residentsByName": [
        "Matt": ["name": "Matt", "age": 33, "hasPet": false, "rent": .Null],
        "Drew": ["name": "Drew", "hasPet": true, "rent": 1234.5],
        "Pat": ["name": "Pat", "age": 28, "hasPet": .Null]
    ]
])

do {
    let residents = try residentJSON.dictionaryOf("residentsByName", type: Resident.self)
    if let matt = residents["Matt"] {
        print("Matt is \(matt.age) years old.")
    }
} catch {
    // handle error
}

Justification
I admit that it's rare to run into JSON that would make use of the dictionaryOf(_:type:) function. However, I needed something similar to decode this parameter in the IBM Watson Developer Cloud iOS SDK.
The IBM Watson Speech to Text documentation provides an example JSON payload for which the dictionaryOf(_:type:) function would be very helpful:
{
  "keywords_result": {
     "tornadoes": [
        {
           "normalized_text": "tornadoes",
           "start_time": 1.52,
           "confidence": 1.0,
           "end_time": 2.15
        }
     ],
     "colorado": [
        {
           "normalized_text": "Colorado",
           "start_time": 4.94,
           "confidence": 0.925,
           "end_time": 5.62
        }
     ]
  }
}

In particular, I believe the following should be able to decode the JSON payload:
public struct TranscriptionResult: JSONDecodable {

    public let keywordResults: [String: [KeywordResult]]

    public init(json: JSON) throws {
        keywordResults = try json.dictionaryOf("keywords_result")
    }
}

Implementation Notes
I tried to follow the example of the arrayOf(_:type:) function. I used it (and its documentation) as the starting point for dictionaryOf(_:type:). Hopefully, these changes are consistent with your style as a result.
I also searched for all occurrences of arrayOf so I could add an analogous use of dictionaryOf.

I'm a big 👍 on this, and will merge tomorrow save for that one comment. We appreciate the excellent tests!

Nice work!  Thanks also for exposing some documentation problems.  : |

Thanks, @mdmathias!
I committed an update to reflect the changes from your comments. Thanks for the thorough review! :)

Okay, I added those fixes to the documentation for getArrayOf and arrayOf. I think this is ready to be merged after the Travis build completes.

authors: glennrfisher mdmathias zwaldowski

repo: bignerdranch/Freddy


text:
Prelolipop Raise Animator

This pull request is to add the selector animation for prelolipop devices

IIUC, you are trying to imitate the elevation change animation. I'm not sure that I understand the UX benefit of the animation it it doesn't also show the drop shadow. Either way I think it definitely needs to animate in reverse when de-selected. Let me know if you're still working on this. I know it's been a while since anybody addressed this PR. If not, I'm going to close this PR.

repo: bignerdranch/recyclerview-multiselect


text:
table ElementInputData will no longer be used to storing the user input data

table ElementInputData in .data.xml file will no longer be used to storing the user input data. We will use runtimedataholder distributed in page object to storing data.
for data sharing, for example login user name and password, we can implement it by reusable page objects, user name and password will be stored in the login form page objects which are independence page object could be included in other pages.

code related to this table needs to be removed from ATE,
example scripts need to be updated as well.

This table is useful in the repeatStep implementation for storing the use input data in a loop, DON'T delete this table, we will revise it and use it in repeatStep design

this is coded to be used for repeateStep

repo: bigtester/automation-test-engine


text:
🛑 Barrs Barking Salon is down

In 3e66c01, Barrs Barking Salon (https://barrsbarkingsalon.co.uk) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Barrs Barking Salon is back up in 1685bbe.

repo: bigupjeff/my-site-uptime-monitor


text:
Create my-slide2

Add bigwuz's file

Add bigwuz's file

gailemingzi

repo: bigwuz/github-slideshow


text:
AMF parse issue

[AMF] > Unsupported AMF value type 5
[AMF] > IllegalStateException: Data not enough when parse Value
This happens with live FLV playback. Metadata exists with RTMP playback. Any idea?

相同的问题，我是用nginx-http-flv直播的，会报错。但是接着能正常播放

@xqq i have the same question  'Unsupported AMF value type 5' ,and can't get the keyframes info .
here is my onMetaData  export from wireshark
onmetedata.zip

有报错但是不影响播放不知道是为什么

authors: andade1996 invalidtask mengshixing wony-zheng


text:
Make Bin great (again)

Right now, there are some architectural integrity flaws in the system that I want to fix to make the Bin subsystem more centralized:

[ ] A PackageRegistry instance needs to be fed into a runner if the runner intends to use it (this is simply incorrect). Most runners will need to know information about files, which includes file locations.
[ ] Graph objects are constructed manually, outside the scripting environment
[ ] The idea of 'modules' hasn't been fleshed out. One of the next steps is to be able to add modules, which include their own scripting environment. However, it'd be even better if they were sandboxed to their own global tables, and then parent (outer?) modules that included those sub-modules could access that child module's global table as a simple returned table. That'd be amazing. EDIT this is entirely possible.
[ ] Environment is a misnomer; ideally, configuration files should be their own modules and all modules should belong to a single environment; currently, Environment is a single scripting instance.
[ ] There is no coupling between Graph::addInput()/Graph::addOutput() and the PackageRegistry object. This is a problem.
[ ] There are no checks for file existence upon adding them as source inputs
[ ] There are no checks to see if the intended outputs were generated
[ ] The Git subsystem that will ultimately enable fetching plugins has not even been looked at
[ ] Runners require that they are casted to Runner* in order to have the full interface. Super annoying; is that helper method even necessary?..
[ ] Tasks are simply strings. They have no inclination as to where they came from nor do they support any meta-data.

Some things that are intended (at least for now):

There is a PackageRegistry for every Environment (see above for the note about the name Environment) - realistically, a PackageRegistry for each Module. This is intended because all modules register their packages relative to their module root, and thus need to have a clean registry that can be tacked on to the parent registry via PackageRegistry::addPackage(..., ..., PackageRegistry).

I'm sure I'll be adding more to this, but these didn't warrant their own issues as these are the things I envisioned for Bin from the start and hence intend for them to be completely functional in v1.

re coupling registry with graph and making modules:
Going to make a super-interface Registry that the existing PackageRegistry will implement. Then, there will be a subclass of Registry called NestedRegistry that is a proxy wrapper around another Registry that tacks on a base package string.
Then, Graph will be modified to use a Registry object that checks to see if a package has been registered upon a label being added to either inputs/outputs.
Further, this will help with sub-module architecture; a nested module is run with its own script state and its own package Registry (which is really a NestedRegistry). When it adds packages, those will be forwarded up the chain to ultimately be adding the fully qualified packages.

re Environment misnomer:
Changing it to ScriptGlobals will help.

Closing in lieu of breaking these out into their own tickets.

repo: bin-build/bin


text:
Enhancement | Add steps and example code when creating new Roles in the Ref-Arch

When a new Role is created in the ref-arch to access AWS accounts, for example, a Developer role, the commands given in this document do not generate the records for that profile/role in the ~/.aws/[PROJECT]/config file.
While mitigating this issue, as a workaround it would be useful to add in the reference documentation how to manually edit the ~/.aws/[PROJECT]/config file.
[profile PROJECT-shared-developers]
output = json
region = us-east-2
role_arn = arn:aws:iam::ACCOUNT_ID:role/Developers
source_profile = PROJECT-security
mfa_serial = arn:aws:iam::ACCOUNT_ID:mfa/[YOUR_USERNAME]
[profile PROJECT-apps-devstg-developers]
output = json
region = us-east-2
role_arn = arn:aws:iam::ACCOUNT_ID:role/Developers
source_profile = PROJECT-security
mfa_serial = arn:aws:iam::ACCOUNT_ID:mfa/[YOUR_USERNAME]
[profile PROJECT-apps-prd-developers]
output = json
region = us-east-2
role_arn = arn:aws:iam::ACCOUNT_ID:role/Developers
source_profile = PROJECT-security
mfa_serial = arn:aws:iam::ACCOUNT_ID:mfa/[YOUR_USERNAME]
...

Below is an example block used for one of the configurations already running:
Also, if possible, it would be very useful to add the steps to create a new role (with code examples) and to add a user to an IAM group.

We will favor the SSO flow and thus will not tackle this issue soon (probably even discard it later on).

This feature will be supported in our next stable release => https://github.com/binbashar/leverage/pull/232

repo: binbashar/le-ref-architecture-doc


text:
Cannot yapf format file

90f8cf
java.lang.Throwable
	at com.intellij.openapi.diagnostic.Logger.error(Logger.java:132)
	at com.intellij.openapi.diagnostic.Logger.error(Logger.java:135)
	at com.intellij.idea.IdeaLogger.error(IdeaLogger.java:105)
	at ReformatCode.reformatFile(ReformatCode.java:50)
	at ReformatCode.actionPerformed(ReformatCode.java:93)
	at com.intellij.openapi.actionSystem.ex.ActionUtil$1.run(ActionUtil.java:216)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.performActionDumbAware(ActionUtil.java:233)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem$ActionTransmitter.a(ActionMenuItem.java:310)
	at com.intellij.openapi.wm.impl.FocusManagerImpl.runOnOwnContext(FocusManagerImpl.java:911)
	at com.intellij.openapi.wm.impl.IdeFocusManagerImpl.runOnOwnContext(IdeFocusManagerImpl.java:136)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem$ActionTransmitter.actionPerformed(ActionMenuItem.java:300)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem.a(ActionMenuItem.java:117)
	at com.intellij.openapi.application.TransactionGuardImpl.a(TransactionGuardImpl.java:86)
	at com.intellij.openapi.application.TransactionGuardImpl.a(TransactionGuardImpl.java:109)
	at com.intellij.openapi.application.TransactionGuardImpl.submitTransaction(TransactionGuardImpl.java:118)
	at com.intellij.openapi.application.TransactionGuard.submitTransaction(TransactionGuard.java:122)
	at com.intellij.openapi.actionSystem.impl.ActionMenuItem.fireActionPerformed(ActionMenuItem.java:117)
	at com.intellij.ui.plaf.beg.BegMenuItemUI.a(BegMenuItemUI.java:513)
	at com.intellij.ui.plaf.beg.BegMenuItemUI.access$300(BegMenuItemUI.java:45)
	at com.intellij.ui.plaf.beg.BegMenuItemUI$MyMouseInputHandler.mouseReleased(BegMenuItemUI.java:533)
	at java.awt.Component.processMouseEvent(Component.java:6541)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
	at java.awt.Component.processEvent(Component.java:6306)
	at java.awt.Container.processEvent(Container.java:2237)
	at java.awt.Component.dispatchEventImpl(Component.java:4897)
	at java.awt.Container.dispatchEventImpl(Container.java:2295)
	at java.awt.Component.dispatchEvent(Component.java:4719)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4889)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4526)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4467)
	at java.awt.Container.dispatchEventImpl(Container.java:2281)
	at java.awt.Window.dispatchEventImpl(Window.java:2746)
	at java.awt.Component.dispatchEvent(Component.java:4719)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764)
	at java.awt.EventQueue.access$500(EventQueue.java:98)
	at java.awt.EventQueue$3.run(EventQueue.java:715)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90)
	at java.awt.EventQueue$4.run(EventQueue.java:737)
	at java.awt.EventQueue$4.run(EventQueue.java:735)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:734)
	at com.intellij.ide.IdeEventQueue.b(IdeEventQueue.java:821)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:645)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:365)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

It's my first attempt at formatting any file, and this big exception pops up

Hi,
This exception happens because of error when invoking the YAPF command.
You have to make sure that this command: /usr/local/bin/yapf <file path> succeeds without any error.

You could try invoking yapf as python -m yapf ..., and use whatever python is setup as the project interpreter. That way people who use conda or virtualenv could use this plugin.

authors: binh-vu jesterhazy nmiculinic

repo: binh-vu/yapf-pycharm


text:
chore: promote unocoins to version 0.0.22

chore: promote unocoins to version 0.0.22
this commit will trigger a pipeline to generate the actual kubernetes resources to perform the promotion which will create a second commit on this Pull Request before it can merge

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign dnmahendra
You can assign the PR to them by writing /assign @dnmahendra in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

repo: binomy/jx-pluto-gke-gsm


text:
Implement a function that resolves the class of xargs at runtime.

There is a (non-blocking) issue with xargs, that requires specific treatment. I am not sure if we need to figure this out and mention this in the OSDI paper or if we should deal with this later. The problem can be seen in shortest_scripts (https://github.com/andromeda/dish/blob/master/evaluation/microbenchmarks/shortest_scripts.sh).
More precisely, the command xargs -L 1 wc -l returns 0 if the input is empty, and otherwise it returns line_number script_path for each line of the input script_path. This means that if we parallelize and some of the chunks end up being empty (because of the previous grep), the output will contain lines with 0.
There are two observations to be made from the above:

Stateless commands need to return empty output when they receive empty input. I will add this in the paper assumptions. This is actually covered in our linearity assumption.
xargs -L 1 is not always stateless. In general our treatment of xargs is kinda hacky, so we should discuss how exactly we address its issues in the paper. @nvasilakis @abenetopoulos Maybe we can say that xargs due to its dynamicity needs a specific treatment and a developer must annotate each xargs in their code with whether it can be parallelized or not.

BTW for the OSDI evaluation I have dealt with the issue by adding a grep that filters 0 lines (which makes sense in general as with empty input this pipeline should return empty output.

@festutz this might be relevant for the annotations, but not for PaSh itself, so I am closing

repo: binpash/pash


text:
Fixed Errors and Failures in Travis Build for Python 3+

The travis build is still failing with FAILED (skipped=32, unexpected successes=40) but at least the errors and failures have been ironed out.
In order to do this I've had to do a number of things:

Setting requirements.txt package versions
upgrading packages where necessary and make the relevant changes
Making some changes to .travis.yml

I'm not familiar with Travis but should the build not pass if no errors or failures have been encountered?

See pull request: #925

repo: binux/pyspider


text:
Prettify non-standard JSON in android app

Certain apps eg: Uptime Kuma POST a lot of information as JSON. Would be nice if the android app displayed these as somewhat human readable format eg: as a table

Can you give a concrete example? Is this the same as #104 again, or is this about the presentation of the data?
ntfy should not be changing your message at all; that seems wildly out of scope. ntfy should also not know what you are sending, so if it's JSON from Uptime Kuma or a random other message doesn't matter to ntfy.
It may be useful to have Markdown support for basic formatting, but typically I want to avoid that, because the overall app appearance suffers from it.

A bit different from #104. Mine was purely about cosmetics. Instead of displaying the json as a text blob (unformatted), it could prettify it. Currently, Kuma notifications are displayed like this in the app:

The app when it detects JSON, could for example, add some colors and format it in a human readable form

While I understand your rationale behind this, I think this is very much outside the scope of what ntfy should do. If you want your message to look different, you should send another message. What you're describing sounds like an email program modifying emails at will, which is unexpected and would feel intrusive.
Plus, messages are by default broadcast as Android intent, meaning that other apps can read and process them. I shouldn't modify the payload at all for that reason too.
.o hope that makes sense.

Good point. Maybe the notification and/or intent can still stay original but the json can be parsed and displayed inside the app in a prettified way, like in a code editor for example, like this:

The data itself doesn't change at all. It's all just aesthetics. There could be a small button to view the raw message. Or the raw message could be the default and the small button is to prettify json

I really don't think that ntfy should do this. If it was easy I'd maybe do it, but it's a ton of work and probably some libraries for what seems to be a pretty odd edge case.
I'm taking the liberty of rejecting this proposal. Please do not take this personally, and do not be discouraged to submit more ideas. I love seeing how people are using ntfy and it makes me happy that you guys wanna add features. But please do understand that I can't implement every idea.
Thank you.

authors: binwiederhier kzshantonu

repo: binwiederhier/ntfy


text:
Deprecate nondegenerate_chars in favor of a better name.

Using nondegenerate was probably a mistake. It is hard to talk about (I know I have mixed myself up a couple of times) and it almost implies the inverse of degenerate which isn't really the intention. Fortunately, it shouldn't be too painful to deprecate and gives us a chance to exercise that process.
standard might be a better description. So to kick off the conversation, I propose we deprecate the following:
nondegenerate_chars -> standard_chars
has_nondegenerates() -> has_standards()
nondegenerates() -> standards()
The only thing I'm not too jazzed about is how awkward standard is when plural. has_standards() is a particularly amusing demonstration of this.
Does anyone have a better name to describe the "normal" bases of a sequence?

For context, @jairideout and I were discussing this offline last Friday.

How about describing the nondegenerate characters as "regular"? "standard" implies the standard IUPAC characters, while this API may apply to an entirely different alphabet in the future.
So the API would become:

nondegenerate_chars -> regular_chars
has_nondegenerates() -> has_regulars()
nondegenerates() -> regulars()

:+1:

This came up in discussion today and we think the terms we should use are definite and degenerate, with definite replacing nondegenerate.
We landed on definite based on the definition: clearly stated or decided; not vague or doubtful. While indefinite is probably a more relevant term than degenerate, we're not going to replace degenerate with indefinite, since degenerate is widely understood in this context. We will however document degenerate characters as being indefinite.

@anderspitman are you interested in working on this? It'd be a good next step now that we have GrammaredSequence.

@jairideout since we're going to be using our deprecation process for this, do I need to start by making a PR that marks all the nondegenerate stuff as deprecated as of our next release? I could also change the names of things but keep the old names as aliases that simply call the new names and mark the aliases as deprecated.

That sounds good, you can do this all in a single PR

OK. Also, for the tests, should I change all of them to use definite? This would introduce a small amount of surface area for bugs, but I don't think the risk is very high. The safest solution would be to duplicate at the tests for nondegenerate and definite then remove the old tests when we completely get rid of nondegenerate in 2 releases.

for safety I'd duplicate the tests and then remove them when the deprecated names are removed

:+1:

authors: anderspitman ebolyen gregcaporaso jairideout

repo: biocore/scikit-bio


text:
Website colors

@bkmgit see this link, 27. Gorgeous contrast. I think those colors work.

@karegapauline There are a lot of choices. Assuming only the colors need to be changed please indicate the color changes that should be made to the dark and light themes. Ideally take a screen shot and put a label on each color that should be changed, or have a list in this thread. It may be helpful to also check

https://www.toptal.com/designers/colorfilter
http://a11yrocks.com/colorPalette/
https://palette.rocks/
http://colorsafe.co/

This is a helpful site. http://a11yrocks.com/colorPalette/
#AAC789 option is my suggestion.

Please be specific. There are at least 5 colors for each skin.

Dark

Green BOSSCon logo
Site background color
Light text
Dark pink menu highlight
Light pink menu highlight
Dark footer

Light
Green BOSSCon logo
Site background color
Dark text
Dark pink menu highlight
Light pink menu highlight
Dark footer

The contrast in #AAC789, with the dark and light green. exactly as it is is I was suggesting, with a small change at the footer. I don't know if this breakdown helps.
Dark
Green BOSSCon logo
Site background-color
Light text
Dark green menu highlight (#AAC789)
Light green menu highlight
Grey (#808080) footer
Light
Green BOSSCon logo
Site background-color
Dark text
Dark green menu highlight
Light green menu highlight
Grey footer

@karegapauline Thanks. HTML color code for light green? Currently the logo BOSSCon 22 uses #55ba3f - it probably it should use #AAC789 or whatever color code is used for light green.

Maybe #437356 works for light green, or can continue with pink for the menu highlight, for example #F34A53

#437356 this works, I was thinking it can replace the pink menu highlight.

Sample screen shots from https://github.com/bioinformatics-hub-ke/BOSS22/pull/48

Footer

Please merge if ok. The template has a formula to calculate the lighter menu highlight color, at present this is unchanged.

It gives a light green color.

https://github.com/bioinformatics-hub-ke/BOSS22/pull/48

authors: bkmgit karegapauline


text:
💅 useSingleCaseStatement shouldn't report break statements

Environment information
CLI:
  Version:                      1.7.2
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           linux

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v21.7.3"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/10.5.0"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Linter:
  Recommended:                  false
  All:                          true
  Rules:                        performance/noDelete = "off"
                                style/noDefaultExport = "off"
                                style/noNamespaceImport = "off"
                                style/useNamingConvention = "off"

Workspace:
  Open Documents:               0

Rule name
lint/style/useSingleCaseStatement
Playground link
https://biomejs.dev/playground/?lintRules=all&code=YwBvAG4AcwB0ACAAZgBvAG8AIAA9ACAAJwBiAGEAcgAnADsACgBzAHcAaQB0AGMAaAAgACgAZgBvAG8AKQAgAHsACgAgACAAYwBhAHMAZQAgACcAYgBhAHoAJwA6AAoAIAAgAGMAYQBzAGUAIAAnAGIAYQByACcAOgAKACAAIAAgACAAYwBvAG4AcwBvAGwAZQAuAGwAbwBnACgAMQApADsACgAgACAAIAAgAGIAcgBlAGEAawA7AAoAIAAgAGQAZQBmAGEAdQBsAHQAOgAKACAAIAAgACAAYwBvAG4AcwBvAGwAZQAuAGwAbwBnACgAMgApADsACgB9AA%3D%3D
Expected result
The rule should not be triggered when a switch case only contains a single statement and a break;, since that is how you generally use switch statements and wrapping every single statement in {} is inconvenient.
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

I'd like to pick this up.

repo: biomejs/biome


text:
BUG: RaggedArray init may need to be stricter?

npstructures 0.2.16  on Python 3.12 x86_64 Linux
The second print below fails. I'm not sure what the intended behavior is, but I suspect I shouldn't even be able to get as far as that print, and instead get a failure on initialization?
from npstructures import RaggedArray

# this works
x = RaggedArray([[0, 1, 2, 3], [4, 5, 6]])
print(x)

# this fails
x = RaggedArray([0, 1, 2, 3], [4, 5, 6])
print(x)

Error:
[0 1 2 3]
[4 5 6]
Traceback (most recent call last):
  File "/home/treddy/rough_work/test.py", line 9, in <module>
    print(x)
  File "/home/treddy/python_venvs/py_312_bionumpy_review/lib/python3.12/site-packages/npstructures/raggedarray/__init__.py", line 162, in __str__
    return "\n".join(str(row) for row in self[:20])
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/treddy/python_venvs/py_312_bionumpy_review/lib/python3.12/site-packages/npstructures/raggedarray/__init__.py", line 141, in __iter__
    flat = self.ravel()
           ^^^^^^^^^^^^
  File "/home/treddy/python_venvs/py_312_bionumpy_review/lib/python3.12/site-packages/npstructures/raggedarray/base.py", line 78, in ravel
    self._flatten_myself()
  File "/home/treddy/python_venvs/py_312_bionumpy_review/lib/python3.12/site-packages/npstructures/raggedarray/base.py", line 62, in _flatten_myself
    self.__data = self.__data[idx]
                  ~~~~~~~~~~~^^^^^
IndexError: index 4 is out of bounds for axis 0 with size 4

Thanks, the init of RaggedArray is overloaded in a bit unfortunate way, where two arguments are interpreted as (continous_array, shape) where continous_array is a 1d array and shape specifies the row_lenghts. Added a check now that asserts that the provided shape matches up with the given data to avoid confusion

authors: knutdrand tylerjereddy

repo: bionumpy/npstructures


text:
🛑 Biosimulations API is down

In 7b42453, Biosimulations API (https://api.biosimulations.org/health/status) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Biosimulations API is back up in 9bc9f61.

repo: biosimulations/status


text:
hera segfault

Heya-- the recent fixes fixed the GRCh38 index issue, but hera-quant segfaults:
 hera quant -i hera_index -o SRR1548811 fastq/SRR1548811_1.fastq fastq/SRR1548811_2.fastq

hera_index is the GRCh38 index.
ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR154/001/SRR1548811/SRR1548811_1.fastq.gz
ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR154/001/SRR1548811/SRR1548811_2.fastq.gz
are the two FASTQ files. Thanks!

hi roryk ,
Please try again with '/' after -o SRR1548811 (-o SRR1548811/) and tell us if it can work. This error should be fixed in this version as we expected, but it seem to be not.
Thank you for informing us.

Hi Ginny! Thanks so much for the quick reply. That totally fixed it.

authors: GinnyAquarius roryk

repo: bioturing/hera


text:
Cant run evillimiter

Whenever i try and run it using sudo evillimiter it throws me an error of KeyError: 'mpl_toolkits.legacy_colorbar'
Help?
im on kali virtualbox btw

Set the 'mpl_toolkits.legacy_colorbar' rcParam to False to use Matplotlib's default colorbar implementation and try again.

repo: bitbrute/evillimiter


text:
File Push does not work on Linux Mint 20.3

Problem:
I can not push any js file into the game. No js file is shown in the game terminal with the command ls. The push of file does not work with the context menu nor the command pallet in vs code.
What I did:
I included the auth token from the game into the property "bitburner.authToken"  under the file "setttings.json" under the folder ".vscode"

Fix: I had to enable the API-Server in the game to make this work

repo: bitburner-official/bitburner-vscode


text:
Ellipsify the version number on the about screen

Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo

[X] I still think this issue should be opened here

Report
The version number overlaps with the label. On tablet, the row item expands beyond its container boundaries on the right. See screenshots.

We could ellipse this number. If it is important to show the whole thing, maybe consider using a vertical layout (value text below the label text).
Since this links to a website, the icon should also be the link icon used for the website and source code links further up on the screen.
I am also curious as to what version this refers to. Aren't version usually just regular numbers, like Bitcoin Core 26?

@GBKS is this still an issue? (on mobile/ tablet)
I see it correctly in the desktop version at the moment:

Is it resolved by just having shorter strings or by automatically eliding ("...") text (which is the more robust solution)? Seems like QML supports this.

repo: bitcoin-core/gui-qml