Missing dependencies when using tutorials after Debian-based install

Using a fresh installation of Ubuntu 20.04 and following the latest instructions for a Debian-based install of ROS 2 (https://docs.ros.org/en/rolling/Installation/Ubuntu-Install-Debians.html), it is not currently possible to run through all of the tutorials in sequence, as one might expect. There are missing dependencies: colcon, colcon_cd, rosdep, etc. Perhaps there should be a section in "Configuring your ROS 2 environment" that adds any dependencies required to successfully run through the tutorials.

I believe that this was solved when we added in the ros-dev tools, so I'm going to close this one out.


Fix repository missing exception while running IndicesRequestIT with remote store settings

Description
[Describe what this change achieves]
Related Issues
Resolves https://github.com/opensearch-project/OpenSearch/issues/9158
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The PR has been stalled for quite a while. Please reopen if you are still working on it.


Updated triangle example for Vulkano 0.24.0

Greetings!
The file "https://github.com/vulkano-rs/vulkano-examples/blob/master/src/bin/triangle.rs" (The "triangle example" linked to on the main page of vulkano.rs) didn't compile on the latest version of Vulkano.
Cargo.toml
[dependencies]
vulkano = "0.24.0"
vulkano-win = "0.24.0"
vulkano-shaders = "0.24.0"
winit = "0.25.0"

After a bit of fiddling around, I got this to compile and run:
// Copyright (c) 2016 The vulkano developers
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or
// https://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or https://opensource.org/licenses/MIT>,
// at your option. All files in the project carrying such
// notice may not be copied, modified, or distributed except
// according to those terms.

// Welcome to the triangle example!
//
// This is the only example that is entirely detailed. All the other examples avoid code
// duplication by using helper functions.
//
// This example assumes that you are already more or less familiar with graphics programming
// and that you want to learn Vulkan. This means that for example it won't go into details about
// what a vertex or a shader is.

use vulkano::buffer::{BufferUsage, CpuAccessibleBuffer};
use vulkano::command_buffer::{AutoCommandBufferBuilder, DynamicState, SubpassContents};
use vulkano::device::{Device, DeviceExtensions};
use vulkano::image::{ImageUsage, SwapchainImage};
use vulkano::instance::{Instance, PhysicalDevice};
use vulkano::pipeline::viewport::Viewport;
use vulkano::pipeline::GraphicsPipeline;
use vulkano::{swapchain, Version};
use vulkano::swapchain::{
    AcquireError, ColorSpace, FullscreenExclusive, PresentMode, SurfaceTransform, Swapchain,
    SwapchainCreationError,
};
use vulkano::sync;
use vulkano::sync::{FlushError, GpuFuture};

use vulkano_win::VkSurfaceBuild;
use winit::event::{Event, WindowEvent};
use winit::event_loop::{ControlFlow, EventLoop};
use winit::window::{Window, WindowBuilder};

use vulkano::render_pass::{Subpass, FramebufferAbstract, RenderPass, Framebuffer};

// Because IntelliJ-Rust seems to have trouble with types from Prelude unless imported explicitly.
// Seems like a regression of https://github.com/intellij-rust/intellij-rust/issues/2877
use std::prelude::v1::*;
use std::sync::Arc;
use vulkano::command_buffer::CommandBufferUsage::OneTimeSubmit;
use vulkano::image::view::ImageView;

fn main() {
    // The first step of any Vulkan program is to create an instance.
    //
    // When we create an instance, we have to pass a list of extensions that we want to enable.
    //
    // All the window-drawing functionalities are part of non-core extensions that we need
    // to enable manually. To do so, we ask the `vulkano_win` crate for the list of extensions
    // required to draw to a window.
    let required_extensions = vulkano_win::required_extensions();

    // Now creating the instance.
    let instance = Instance::new(None, Version::V1_2, &required_extensions, None).unwrap();

    // We then choose which physical device to use.
    //
    // In a real application, there are three things to take into consideration:
    //
    // - Some devices may not support some of the optional features that may be required by your
    //   application. You should filter out the devices that don't support your app.
    //
    // - Not all devices can draw to a certain surface. Once you create your window, you have to
    //   choose a device that is capable of drawing to it.
    //
    // - You probably want to leave the choice between the remaining devices to the user.
    //
    // For the sake of the example we are just going to use the first device, which should work
    // most of the time.
    let physical = PhysicalDevice::enumerate(&instance).next().unwrap();

    // Some little debug infos.
    println!(
        "Using device: {} (type: {:?})",
        physical.properties().device_name.as_ref().expect("Device name not known."),
        physical.properties().device_type.as_ref().expect("Device type not available.")
    );

    // The objective of this example is to draw a triangle on a window. To do so, we first need to
    // create the window.
    //
    // This is done by creating a `WindowBuilder` from the `winit` crate, then calling the
    // `build_vk_surface` method provided by the `VkSurfaceBuild` trait from `vulkano_win`. If you
    // ever get an error about `build_vk_surface` being undefined in one of your projects, this
    // probably means that you forgot to import this trait.
    //
    // This returns a `vulkano::swapchain::Surface` object that contains both a cross-platform winit
    // window and a cross-platform Vulkan surface that represents the surface of the window.
    let event_loop = EventLoop::new();
    let surface = WindowBuilder::new()
        .build_vk_surface(&event_loop, instance.clone())
        .unwrap();

    // The next step is to choose which GPU queue will execute our draw commands.
    //
    // Devices can provide multiple queues to run commands in parallel (for example a draw queue
    // and a compute queue), similar to CPU threads. This is something you have to have to manage
    // manually in Vulkan.
    //
    // In a real-life application, we would probably use at least a graphics queue and a transfers
    // queue to handle data transfers in parallel. In this example we only use one queue.
    //
    // We have to choose which queues to use early on, because we will need this info very soon.
    let queue_family = physical
        .queue_families()
        .find(|&q| {
            // We take the first queue that supports drawing to our window.
            q.supports_graphics() && surface.is_supported(q).unwrap_or(false)
        })
        .unwrap();

    // Now initializing the device. This is probably the most important object of Vulkan.
    //
    // We have to pass five parameters when creating a device:
    //
    // - Which physical device to connect to.
    //
    // - A list of optional features and extensions that our program needs to work correctly.
    //   Some parts of the Vulkan specs are optional and must be enabled manually at device
    //   creation. In this example the only thing we are going to need is the `khr_swapchain`
    //   extension that allows us to draw to a window.
    //
    // - A list of layers to enable. This is very niche, and you will usually pass `None`.
    //
    // - The list of queues that we are going to use. The exact parameter is an iterator whose
    //   items are `(Queue, f32)` where the floating-point represents the priority of the queue
    //   between 0.0 and 1.0. The priority of the queue is a hint to the implementation about how
    //   much it should prioritize queues between one another.
    //
    // The list of created queues is returned by the function alongside with the device.
    let device_ext = DeviceExtensions {
        khr_swapchain: true,
        ..DeviceExtensions::none()
    };
    let (device, mut queues) = Device::new(
        physical,
        physical.supported_features(),
        &device_ext,
        [(queue_family, 0.5)].iter().cloned(),
    )
        .unwrap();

    // Since we can request multiple queues, the `queues` variable is in fact an iterator. In this
    // example we use only one queue, so we just retrieve the first and only element of the
    // iterator and throw it away.
    let queue = queues.next().unwrap();

    // Before we can draw on the surface, we have to create what is called a swapchain. Creating
    // a swapchain allocates the color buffers that will contain the image that will ultimately
    // be visible on the screen. These images are returned alongside with the swapchain.
    let (mut swapchain, images) = {
        // Querying the capabilities of the surface. When we create the swapchain we can only
        // pass values that are allowed by the capabilities.
        let caps = surface.capabilities(physical).unwrap();

        // The alpha mode indicates how the alpha value of the final image will behave. For example
        // you can choose whether the window will be opaque or transparent.
        let alpha = caps.supported_composite_alpha.iter().next().unwrap();

        // Choosing the internal format that the images will have.
        let format = caps.supported_formats[0].0;

        // The dimensions of the window, only used to initially setup the swapchain.
        // NOTE:
        // On some drivers the swapchain dimensions are specified by `caps.current_extent` and the
        // swapchain size must use these dimensions.
        // These dimensions are always the same as the window dimensions
        //
        // However other drivers dont specify a value i.e. `caps.current_extent` is `None`
        // These drivers will allow anything but the only sensible value is the window dimensions.
        //
        // Because for both of these cases, the swapchain needs to be the window dimensions, we just use that.
        let dimensions: [u32; 2] = surface.window().inner_size().into();

        // Please take a look at the docs for the meaning of the parameters we didn't mention.
        Swapchain::start( device.clone(), surface.clone())
            .num_images(caps.min_image_count)
            .format(format)
            .dimensions(dimensions)
            .layers(1)
            .usage(ImageUsage::color_attachment())
            .sharing_mode(&queue)
            .transform(SurfaceTransform::Identity)
            .composite_alpha(alpha)
            .present_mode(PresentMode::Fifo)
            .fullscreen_exclusive(FullscreenExclusive::Default)
            .clipped(true)
            .color_space(ColorSpace::SrgbNonLinear)
            .build().unwrap()
    };

    // We now create a buffer that will store the shape of our triangle.
    let vertex_buffer = {
        #[derive(Default, Debug, Clone)]
        struct Vertex {
            position: [f32; 2],
        }
        vulkano::impl_vertex!(Vertex, position);

        CpuAccessibleBuffer::from_iter(
            device.clone(),
            BufferUsage::all(),
            false,
            [
                Vertex {
                    position: [-0.5, -0.25],
                },
                Vertex {
                    position: [0.0, 0.5],
                },
                Vertex {
                    position: [0.25, -0.1],
                },
            ]
                .iter()
                .cloned(),
        )
            .unwrap()
    };

    // The next step is to create the shaders.
    //
    // The raw shader creation API provided by the vulkano library is unsafe, for various reasons.
    //
    // An overview of what the `vulkano_shaders::shader!` macro generates can be found in the
    // `vulkano-shaders` crate docs. You can view them at https://docs.rs/vulkano-shaders/
    //
    // TODO: explain this in details
    mod vs {
        vulkano_shaders::shader! {
            ty: "vertex",
            src: "
				#version 450

				layout(location = 0) in vec2 position;

				void main() {
					gl_Position = vec4(position, 0.0, 1.0);
				}
			"
        }
    }

    mod fs {
        vulkano_shaders::shader! {
            ty: "fragment",
            src: "
				#version 450

				layout(location = 0) out vec4 f_color;

				void main() {
					f_color = vec4(1.0, 0.0, 0.0, 1.0);
				}
			"
        }
    }

    let vs = vs::Shader::load(device.clone()).unwrap();
    let fs = fs::Shader::load(device.clone()).unwrap();

    // At this point, OpenGL initialization would be finished. However in Vulkan it is not. OpenGL
    // implicitly does a lot of computation whenever you draw. In Vulkan, you have to do all this
    // manually.

    // The next step is to create a *render pass*, which is an object that describes where the
    // output of the graphics pipeline will go. It describes the layout of the images
    // where the colors, depth and/or stencil information will be written.
    let render_pass = Arc::new(
        vulkano::single_pass_renderpass!(
            device.clone(),
            attachments: {
                // `color` is a custom name we give to the first and only attachment.
                color: {
                    // `load: Clear` means that we ask the GPU to clear the content of this
                    // attachment at the start of the drawing.
                    load: Clear,
                    // `store: Store` means that we ask the GPU to store the output of the draw
                    // in the actual image. We could also ask it to discard the result.
                    store: Store,
                    // `format: <ty>` indicates the type of the format of the image. This has to
                    // be one of the types of the `vulkano::format` module (or alternatively one
                    // of your structs that implements the `FormatDesc` trait). Here we use the
                    // same format as the swapchain.
                    format: swapchain.format(),
                    // TODO:
                    samples: 1,
                }
            },
            pass: {
                // We use the attachment named `color` as the one and only color attachment.
                color: [color],
                // No depth-stencil attachment is indicated with empty brackets.
                depth_stencil: {}
            }
        )
            .unwrap(),
    );

    // Before we draw we have to create what is called a pipeline. This is similar to an OpenGL
    // program, but much more specific.
    let pipeline = Arc::new(
        GraphicsPipeline::start()
            // We need to indicate the layout of the vertices.
            // The type `SingleBufferDefinition` actually contains a template parameter corresponding
            // to the type of each vertex. But in this code it is automatically inferred.
            .vertex_input_single_buffer()
            // A Vulkan shader can in theory contain multiple entry points, so we have to specify
            // which one. The `main` word of `main_entry_point` actually corresponds to the name of
            // the entry point.
            .vertex_shader(vs.main_entry_point(), ())
            // The content of the vertex buffer describes a list of triangles.
            .triangle_list()
            // Use a resizable viewport set to draw over the entire window
            .viewports_dynamic_scissors_irrelevant(1)
            // See `vertex_shader`.
            .fragment_shader(fs.main_entry_point(), ())
            // We have to indicate which subpass of which render pass this pipeline is going to be used
            // in. The pipeline will only be usable from this particular subpass.
            .render_pass(Subpass::from(render_pass.clone(), 0).unwrap())
            // Now that our builder is filled, we call `build()` to obtain an actual pipeline.
            .build(device.clone())
            .unwrap(),
    );

    // Dynamic viewports allow us to recreate just the viewport when the window is resized
    // Otherwise we would have to recreate the whole pipeline.
    let mut dynamic_state = DynamicState {
        line_width: None,
        viewports: None,
        scissors: None,
        compare_mask: None,
        write_mask: None,
        reference: None,
    };

    // The render pass we created above only describes the layout of our framebuffers. Before we
    // can draw we also need to create the actual framebuffers.
    //
    // Since we need to draw to multiple images, we are going to create a different framebuffer for
    // each image.
    let mut framebuffers =
        window_size_dependent_setup(&images, render_pass.clone(), &mut dynamic_state);

    // Initialization is finally finished!

    // In some situations, the swapchain will become invalid by itself. This includes for example
    // when the window is resized (as the images of the swapchain will no longer match the
    // window's) or, on Android, when the application went to the background and goes back to the
    // foreground.
    //
    // In this situation, acquiring a swapchain image or presenting it will return an error.
    // Rendering to an image of that swapchain will not produce any error, but may or may not work.
    // To continue rendering, we need to recreate the swapchain by creating a new swapchain.
    // Here, we remember that we need to do this for the next loop iteration.
    let mut recreate_swapchain = false;

    // In the loop below we are going to submit commands to the GPU. Submitting a command produces
    // an object that implements the `GpuFuture` trait, which holds the resources for as long as
    // they are in use by the GPU.
    //
    // Destroying the `GpuFuture` blocks until the GPU is finished executing it. In order to avoid
    // that, we store the submission of the previous frame here.
    let mut previous_frame_end = Some(sync::now(device.clone()).boxed());

    event_loop.run(move |event, _, control_flow| {
        match event {
            Event::WindowEvent {
                event: WindowEvent::CloseRequested,
                ..
            } => {
                *control_flow = ControlFlow::Exit;
            }
            Event::WindowEvent {
                event: WindowEvent::Resized(_),
                ..
            } => {
                recreate_swapchain = true;
            }
            Event::RedrawEventsCleared => {
                // It is important to call this function from time to time, otherwise resources will keep
                // accumulating and you will eventually reach an out of memory error.
                // Calling this function polls various fences in order to determine what the GPU has
                // already processed, and frees the resources that are no longer needed.
                previous_frame_end.as_mut().unwrap().cleanup_finished();

                // Whenever the window resizes we need to recreate everything dependent on the window size.
                // In this example that includes the swapchain, the framebuffers and the dynamic state viewport.
                if recreate_swapchain {
                    // Get the new dimensions of the window.
                    let dimensions: [u32; 2] = surface.window().inner_size().into();
                    let (new_swapchain, new_images) =
                        match swapchain.recreate().dimensions(dimensions).build() {
                            Ok(r) => r,
                            // This error tends to happen when the user is manually resizing the window.
                            // Simply restarting the loop is the easiest way to fix this issue.
                            Err(SwapchainCreationError::UnsupportedDimensions) => return,
                            Err(e) => panic!("Failed to recreate swapchain: {:?}", e),
                        };

                    swapchain = new_swapchain;
                    // Because framebuffers contains an Arc on the old swapchain, we need to
                    // recreate framebuffers as well.
                    framebuffers = window_size_dependent_setup(
                        &new_images,
                        render_pass.clone(),
                        &mut dynamic_state,
                    );
                    recreate_swapchain = false;
                }

                // Before we can draw on the output, we have to *acquire* an image from the swapchain. If
                // no image is available (which happens if you submit draw commands too quickly), then the
                // function will block.
                // This operation returns the index of the image that we are allowed to draw upon.
                //
                // This function can block if no image is available. The parameter is an optional timeout
                // after which the function call will return an error.
                let (image_num, suboptimal, acquire_future) =
                    match swapchain::acquire_next_image(swapchain.clone(), None) {
                        Ok(r) => r,
                        Err(AcquireError::OutOfDate) => {
                            recreate_swapchain = true;
                            return;
                        }
                        Err(e) => panic!("Failed to acquire next image: {:?}", e),
                    };

                // acquire_next_image can be successful, but suboptimal. This means that the swapchain image
                // will still work, but it may not display correctly. With some drivers this can be when
                // the window resizes, but it may not cause the swapchain to become out of date.
                if suboptimal {
                    recreate_swapchain = true;
                }

                // Specify the color to clear the framebuffer with i.e. blue
                let clear_values = vec![[0.0, 0.0, 1.0, 1.0].into()];

                // In order to draw, we have to build a *command buffer*. The command buffer object holds
                // the list of commands that are going to be executed.

                //
                // Note that we have to pass a queue family when we create the command buffer. The command
                // buffer will only be executable on that given queue family.
                let mut builder = AutoCommandBufferBuilder::primary(
                    device.clone(),
                    queue.family(),
                    OneTimeSubmit
                )
                    .unwrap();

                builder
                    // Before we can draw, we have to *enter a render pass*. There are two methods to do
                    // this: `draw_inline` and `draw_secondary`. The latter is a bit more advanced and is
                    // not covered here.
                    //
                    // The third parameter builds the list of values to clear the attachments with. The API
                    // is similar to the list of attachments when building the framebuffers, except that
                    // only the attachments that use `load: Clear` appear in the list.
                    .begin_render_pass(
                        framebuffers[image_num].clone(),
                        SubpassContents::Inline,
                        clear_values,
                    )
                    .unwrap()
                    // We are now inside the first subpass of the render pass. We add a draw command.
                    //
                    // The last two parameters contain the list of resources to pass to the shaders.
                    // Since we used an `EmptyPipeline` object, the objects have to be `()`.
                    .draw(
                        pipeline.clone(),
                        &dynamic_state,
                        vertex_buffer.clone(),
                        (),
                        (),
                        vec![]
                    )
                    .unwrap()
                    // We leave the render pass by calling `draw_end`. Note that if we had multiple
                    // subpasses we could have called `next_inline` (or `next_secondary`) to jump to the
                    // next subpass.
                    .end_render_pass()
                    .unwrap();

                // Finish building the command buffer by calling `build`.
                let command_buffer = builder.build().unwrap();

                let future = previous_frame_end
                    .take()
                    .unwrap()
                    .join(acquire_future)
                    .then_execute(queue.clone(), command_buffer)
                    .unwrap()
                    // The color output is now expected to contain our triangle. But in order to show it on
                    // the screen, we have to *present* the image by calling `present`.
                    //
                    // This function does not actually present the image immediately. Instead it submits a
                    // present command at the end of the queue. This means that it will only be presented once
                    // the GPU has finished executing the command buffer that draws the triangle.
                    .then_swapchain_present(queue.clone(), swapchain.clone(), image_num)
                    .then_signal_fence_and_flush();

                match future {
                    Ok(future) => {
                        previous_frame_end = Some(future.boxed());
                    }
                    Err(FlushError::OutOfDate) => {
                        recreate_swapchain = true;
                        previous_frame_end = Some(sync::now(device.clone()).boxed());
                    }
                    Err(e) => {
                        println!("Failed to flush future: {:?}", e);
                        previous_frame_end = Some(sync::now(device.clone()).boxed());
                    }
                }
            }
            _ => (),
        }
    });
}

/// This method is called once during initialization, then again whenever the window is resized
fn window_size_dependent_setup(
    images: &[Arc<SwapchainImage<Window>>],
    render_pass: Arc<RenderPass>,
    dynamic_state: &mut DynamicState,
) -> Vec<Arc<dyn FramebufferAbstract + Send + Sync>> {
    let dimensions = images[0].dimensions();

    let viewport = Viewport {
        origin: [0.0, 0.0],
        dimensions: [dimensions[0] as f32, dimensions[1] as f32],
        depth_range: 0.0..1.0,
    };
    dynamic_state.viewports = Some(vec![viewport]);

    images
        .iter()
        .map(|image| {
            Arc::new(
                Framebuffer::start(render_pass.clone())
                    .add(ImageView::new(image.clone()).unwrap())
                    .unwrap()
                    .build()
                    .unwrap(),
            ) as Arc<dyn FramebufferAbstract + Send + Sync>
        })
        .collect::<Vec<_>>()
}

I didn't open a pull request, since it would cause a mismatch between the different examples, but perhaps you could review the code above update the example with it at some point?

I think you need to submit this to the vulkano-examples repository, not here.

As per that repo: "Issues are disabled for this repo, please file issues on the main vulkano repo mentioning that you ran the examples from this repo."

@werner291 We don't practically maintain vulkano-examples repository since the copies of examples reside in the main repo and we keep them consistent with the API. Honestly speaking I'm not quite understand the purpose of that repository, in my opinion it only confuses the users. But if you want to help with maintenance, please open a Pull Request to vulkano-examples with all examples update, and I will review it. Also, please mention the Pull Request in this thread. Thank you for raising the issue.

Oh, there's examples in the main repo? That are practically a more up-to-date copy? Yes, that's indeed very confusing; I certainly lost a bit of time on it.
Also, note that vulkano.rs refers to the triangle example in vulkano-examples, that's how I got to there in the first place.
Perhaps you could consider deprecating the vulkano-examples repo, with a link to the examples directory in the main repo? That way you don't keep ferrying updates back and forth between the two.

Speaking of pull requests, I did open one recently to update the code on the vulkano-www repo, though I'm not exactly sure how active that repo is. (https://github.com/vulkano-rs/vulkano-www/pull/94)


iOS Angular binding

Hello,
I've tried using this plugin on iOS and did not have success with the two-way binding using ngModel.
Example:
<android>
        <TextInputLayout hint="Login" hintAnimationEnabled="true">
            <TextField [isEnabled]="!loggingIn" [(ngModel)]="user.login" keyboardType="number" returnKeyType="next" maxLength="11"></TextField>
        </TextInputLayout>
        <TextInputLayout hint="Password" hintAnimationEnabled="true">
            <TextField [isEnabled]="!loggingIn" [(ngModel)]="user.password" returnKeyType="next" (returnPress)="submit()" secure="true"></TextField>
        </TextInputLayout>
    </android>
    <ios>
        <TextInputLayout hint="Login" hintAnimationEnabled="true" [isEnabled]="!loggingIn" [(ngModel)]="user.login" keyboardType="number"
            returnKeyType="next" maxLength="11" ngDefaultControl></TextInputLayout>
        <TextInputLayout hint="Password" hintAnimationEnabled="true" [isEnabled]="!loggingIn" [(ngModel)]="user.password" returnKeyType="next"
            (returnPress)="submit()" secure="true" ngDefaultControl></TextInputLayout>
    </ios>

Although the input works fine, the iOS version does not update the user.login and user.password values. Is there any way to make the angular binding work on the iOS version?

I don't use angular w/ NativeScript, so not sure. PRs welcome.

As a workaround, I was able to get this working on iOS in angular using a combination of [text] and (textChange):
<ios>
    <TextInputLayout hint="Login" [text]="user.login" (textChange)="updateModelValue($event)"/>
</ios>

updateModelValue(args) {
    this.user.login = args.object.text;
}

Not as nice as using [(ngModel)], but it at least works for me for the time being.

the same problem here ! any PRs?

@alqabali - just use [text] and (textChange) bindings as @ExaltedJim pointed out. There is a PR, however I'm still not sure I want to put angular-specific stuff in this repo - the purpose of this repo is bindings between {N} and the android/iOS components used vs {N}-Angular and the android/iOS components used.


Ruby example is wrong or outdated

Is a need for volunteers on this project?  I think it's something I would use, maybe someone can throw out some ideas for what else is needed in terms of updating docs or other things that a new contributor could helpfully tackle.
Was the API apiVersion: k8s.io/v1 intentional?  I don't know if kubeless is intended to be upstreamed into k8s.io but function does not seem to be in my k8s.io/v1 as of the latest minikube.
(Also, thanks for the mostly working example!)
Issue Ref: None
Description:
I had to make a couple of changes to this example to get it to work, but this version worked.
Submitted for your consideration
TODOs:

[ ] Ready to review
[ ] Automated Tests
[ ] Docs

You are correct, this is an omission from when we switch the function signature.
And correct as well the api group is kubeless.io/v1beta1
thanks for finding this and submitting a fix
/lgtm


Expose wrapper promise as a prop so it can be chained on (fixes #79)

Description
This exposes a new promise prop, which is the internal wrapper Promise created when starting the promiseFn. This wrapper promise fulfills and rejects along with the underlying promise, so it behaves as one would expect, contrary to the promise returned by run, which always fulfilled. Because the promise returned by run is an oddball and not frequently used (it was even untested), it was changed to just return undefined.
This fixes #79
Breaking changes
The return type for run was changed from Promise to undefined. You should now use the promise prop instead. This change cannot be automated, so you should upgrade manually.
Checklist
Make sure you check all the boxes. You can omit items that are not applicable.

[x] Implementation for both <Async> and useAsync()
[x] Added / updated the unit tests
[x] Added / updated the documentation
[x] Updated the PropTypes
[x] Updated the TypeScript type definitions

Released in v8.0.0

Thanks, I answered your question on SO. Basically this is a bug which will be fixed soon. See also https://github.com/ghengeveld/react-async/issues/92#issuecomment-525709738


Added new attribute to support hiding line view when text entered

Add new attribute to attrs.xml
Add new field mHideLineWhenFilled to class PinView
Add PinView with new attribute to MainActivity for visual example

Thank you for your contribution.


Docker-Compose command not running

After attaching tmux session and cd simple-taiko-node.
sudo docker-compose up -d giving error
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.l2_execution_engine: 'pull_policy'
Unsupported config option for services.taiko_client_driver: 'pull_policy'
Unsupported config option for services.taiko_client_proposer: 'pull_policy'
Unsupported config option for services.taiko_client_prover_relayer: 'pull_policy'
Unsupported config option for services.zkevm_chain_prover_rpcd: 'pull_policy'

Ensure, that you have Docker Compose version 1.27.0 or later installed. You can check your version with docker-compose --version If you have an older version, update it. You can do it with your package manager.
Check docker-compose.yml there are no indentations or other syntactical errors.


Suggestion: option to remove social media links post-save

Hi there,
At present, iD shows me links to social media sites such as Facebook after I save, but I really abhor social media because of all the ongoing problems (fake news and poor community atmosphere).
I wonder if someone could add the option to hide social media links post-save, aka “Do not show this again”?

@mini-ika These links are provided from the OSM-Community (local to global), see
https://github.com/osmlab/osm-community-index to allow mappers to get into contact with others. Isn‘t that a good idea?

I understand that such links are useful for new mappers, and I never implied that it should not appear by default.
However, I made a suggestion for serial iD mappers who may get bored of seeing such links, particularly when they have no faith in using social media.
I hope I am not putting too much pressure on you.

I have over 10,000 edits and I didnt even notice they were there until I saw this issue. So Im not sure its such a problem for "serial" mappers. As its easy to ignore.

To me it is an annoyance, but your mileage may vary.
 OpenStreetMap (no social media links)
openstreetmap.org##div.save-communityLinks

Thanks @mini-ika - We also have #5225 to track splitting up the index better.  I might add something to hide links.


Set up correct .lounge_home at install time

Thanks to https://github.com/thelounge/lounge/pull/1416, lounge add <user> and others can now work correctly without using LOUNGE_HOME or (deprecated) --home, by setting the correct path in .lounge_home.
This will be valid as of v2.5.0.

by setting the correct path in .lounge_home

If installed via $ npm install -g thelounge, would you have to change /usr/local/lib/node_modules/thelounge/.lounge_config?

Sounds like that, yes. Perhaps for consistency you should use --prefix in install to control where lounge gets installed.
https://github.com/thelounge/deb-lounge/blob/17fb69791afaf9773b62121e7dc1b2efb1d68552/build-package#L14

The container currently sets LOUNGE_HOME, that's not deprecated is it?

It's not, however using .lounge_home should be the most consistent way.

Currently, do people need to set LOUNGE_HOME when using lounge add <user>? If so, then .lounge_home will indeed make this more convenient.

Currently, do people need to set LOUNGE_HOME when using lounge add  with Docker?

Nope. It's set "globally" in the container environment.

I'm closing as the containers already have LOUNGE_HOME set.


Fix group authentication check

Previously still allowed access to routes with authentication. This
adds a test copied from the user controller test and returns a 401.

Exactly what I need :) Thanks @lumenlunae  !!
Why is this not getting merged?

Their version is a few versions up now. I should update my own branch here to match master, and hopefully will have time in the next day or two too.

On Nov 18, 2015, at 11:02 AM, Robert Strobl<EMAIL_ADDRESS>wrote:
Exactly what I need :) Thanks @lumenlunae !!
Why is this not getting merged?
—
Reply to this email directly or view it on GitHub.

closed via #446


Add Django 2.0 / 2.1 - django CMS 3.6

Is there a special reason why this PR is not merged?

No good reason except lack of time
I am testing this on an internal project, but my goal is to merge it and release an update this week


Don't publish overall coverage flag

Also simplifies to just publish after the normal tests instead of running tests twice which can make CI output on github a bit confusing.
I have noticed codecov output looking wrong sometimes. Also for example the flags view doesn't render.
When looking at flags and codecov docs, I noticed that flags and reports are one to one. I think our current overall flag breaks this expectation https://docs.codecov.com/docs/flags#one-to-one-relationship-of-flags-to-uploads
Not sure if this will improve anything but want to try it out, an "overall view" is just the default view anyways I think.

Codecov Report
Base: 72.60% // Head: 72.60% // No change to project coverage :thumbsup:

Coverage data is based on head (83b8a37) compared to base (d451181).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           v3/dev     #491   +/-   ##
=======================================
  Coverage   72.60%   72.60%
=======================================
  Files         146      146
  Lines        6851     6851
=======================================
  Hits         4974     4974
  Misses       1608     1608
  Partials      269      269

Flag
Coverage Δ

default
72.52% <ø> (?)

no-tinygo
?

overall
?

tinygo
71.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


Auto dependencies upgrade by bot.

Auto dependencies upgrade by bot. This is automatically generated by bot.
The bot tries to fetch all possible updates and modify the project files automatically.
This pull request may break or change the behavior of this application. Review with cautious!

Hi @Anduin2017
This will blow up because it's a .NET 6 project

Emmmmm.. Edi's pipeline is blown up.

It doen't matter. It's a curry configuration that PR build won't be deploy to prod, so it is considered as failed, but actually success.


New release?

Thank you for a neat and helpful action :)  Any plans to release a new version with the commit updating @actions/core? The action is producing a lot of warnings atm.

Would be very nice to get a new version avoiding the github deprecated features.
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I'm working on that

Fixed in 1.15


FR: Carthage support

Now that the Firebase SDKs are open source, can we then have Carthage support? 😍
*** Cloning firebase-ios-sdk
*** Checking out firebase-ios-sdk at "4.0.0"
*** Skipped building firebase-ios-sdk due to the error:
Dependency "firebase-ios-sdk" has no shared framework schemes

We can't add Carthage support via a shared framework scheme for the time being since all the Firebase libraries have a common dependency in Analytics, which is still closed source and vended as a static library. If we were to try to distribute the other Firebase libs as dynamic frameworks, they would all have link time dependencies on Analytics and would end up duplicating the Analytics classes in the runtime, bloating app size and causing undefined behavior in some instances.
Carthage does support vending binaries, so we could still distribute these as static binaries with static dependencies on Analytics. Others wouldn't be able to easily build and redistribute libraries wrapping Firebase, but otherwise we'd retain many of the benefits of using Carthage. But before this can happen Analytics also needs to be distributed through Carthage, since mixing dependency managers is not something we should encourage developers to do.
The most straightforward solution would be to distribute Analytics as a dynamic framework through Carthage and then build the open source Firebase frameworks on top of that via a shared framework scheme. This is unlikely to happen in the very short term. In the longer term, we'd need to weigh the drawback of causing longer app launch times for dylib users versus the benefit of allowing users to install Firebase through Carthage and easily build frameworks wrapping Firebase. If you have either of these concerns (app launch times/want to build on top of Firebase), please share your thoughts!

Ok, fingers crossed for support in the future 🤞  and thanks for the clarification.

For time being I already created a carthage compatible for firebase. https://github.com/soheilbm/firebase

@morganchen12 I'm very much interested in building frameworks on top of Firebase, and I think the more Firebase continues to grow as a defacto database and auth/etc. solution, the more people/companies are going to be wrapping it, at least for internal use (but probably convenience frameworks at some point).
At the moment though I'm most interested in this Analytics topic. From what I can tell at first pass of the source (at least of FirebaseCore), Analytics being present is desired but not required. Is this actually/will this continue to be the case?

Hi @mhuusko5. Google Analytics for Firebase is what enables us to offer an integrated experience across the various other Firebase services we offer. As such we try to make Firebase Analytics included in the default experience since this is will maximize the value to our users. A great example of this is the AdMob integration with Firebase. When used together, we are able to combine metrics from both AdMob and Analytics to answer more sophisticated questions like "On which screens are users being exposed to advertising the most or the least?" However, we know that some advanced users may explicitly only want AdMob SDK which is why we avoid having hard dependencies. So yes, since this is by design, and so you can expect that we will continue to only be using weak dependencies for the majority of our inter-product integrations. There are other weak dependencies in the codebase as well, such as between Database and Auth, such that Database works without it, but when Auth is included in an app its functionality is enhanced. Hope that clarifies this.

@salqadri fantastic, thanks for the breakdown, and I love the design strategy. 👍

@mhuusko5 for the time being you can create frameworks wrapping Firebase for your own personal use by just embedding them in a CocoaPods target without any issues. Life becomes much harder once you try to distribute the framework afterwards.

Distributing Analytics through Carthage shouldn't be that hard. For an example, this is what mapbox does: https://www.mapbox.com/ios-sdk/
Relevant line in a consumer's cartfile would be binary "https://www.mapbox.com/ios-sdk/Mapbox-iOS-SDK.json" ~> 3.5, which just points to a JSON file (https://www.mapbox.com/ios-sdk/Mapbox-iOS-SDK.json ) with version numbers and a URL from where to download the .framework

@AndrewSB for reference the issue here isn't Carthage, it's that we currently don't ship Analytics as a dynamic framework, which we must before distributing it through Carthage.

Ahh, I see. Still a static framework, I take back what I said then. So I guess we're waiting on that dynamic framework then

Carthage has recently added some info to its README about integrating static frameworks that could be helpful - https://github.com/Carthage/Carthage#build-static-frameworks-to-speed-up-your-apps-launch-times

I create some dynamic frameworks compatible with carthage for my own projects with dependencies. It's not really complex. And if you want to create a cross-platform framework compatible with carthage you can take a look to articles like this one:
Creating Cross-Platform Swift Frameworks for iOS, watchOS, and tvOS via Carthage and CocoaPods 👍

If it's can help I create this tutorial: Swift Cross Platform Framework

+1

+1

+1

+1

+1

Is there any progress?

This PR will be updated when there is progress.
Please don't add additional comments unless you are interested in contributing to the implementation.
Use :+1: to indicate interest.

👍🏻

How is this still an open issue? Is somebody actively working on it?
Carthage 0.28 supports static binaries: https://github.com/Carthage/Carthage/releases/tag/0.28.0

+1

@AndrewSB Thanks for digging in and glad to hear you're making progress, but I'm not sure it's currently possible with Carthage to support Firebase as the mix of source static frameworks currently required to work with the Analytics and InstanceID binary static framework dependencies.
I'm currently working on making a pure binary Firebase Carthage distribution derived from the Firebase zip distribution and planning to make it publicly available in the near future.

@paulb777 thats great to hear, that does seem like the complete solution. Keep us updated on how that's going. Like I mentioned last year, it should be as simple as creating a JSON file like https://www.mapbox.com/ios-sdk/Mapbox-iOS-SDK.json once the releases are uploaded in a standard way

Thanks @paulb777 !
For the time being this is my solution:
https://github.com/MonsantoCo/FirebaseFramework

An experimental binary Carthage Firebase distribution is now available including all of Firebase except Firestore and Invites. Details at https://github.com/firebase/firebase-ios-sdk/blob/master/Carthage.md.
I've also created a new github Carthage label for any specific issues or feedback.

I think this is just fine but can we expect Firestore support in near future?

@olejnjak Firestore has a dependency on gRPC which has resources and I couldn't figure out how to get the Carthage installer to install resources.  Any ideas?

@paulb777 are you talking about https://github.com/grpc/grpc? Can you be more specific with the resources that are required? Also, the folks over at Carthage are usually pretty helpful. If you aren't sure how to do this, creating an Issue there will probably get you an answer

@AndrewSB Specifically gRPC/etc/roots.pem from https://github.com/grpc/grpc.
I couldn't find a place to put it in the zip without being ignored by the Carthage installer.
The next time I have bandwidth for Carthage, I'll take another stab at it and make an issue. In the meantime, suggestions and contributions are welcome.

I updated the Carthage distribution with Firebase 4.11.0.
It now includes Functions, Firestore, and Invites.
Instructions for adding the Resources in Firestore and Invites are now available.

Thanks to @blender for help with Carthage binary resource installation.

Having the same problem @rerelease, having the import Firebase statement produces this warning.
Replacing with any other library works import FirebaseCore for example or import FirebaseAnalytics.

How to add this repository to Carthage? Only need paste that lines "binary ..." to the Cartfile?

How to add this repository to Carthage? Only need paste that lines "binary ..." to the Cartfile?

README : https://github.com/firebase/firebase-ios-sdk/blob/master/Carthage.md#carthage-usage

@prsolucoes Does #1061 answer your question?

Yes. In my opinion, i think that something more clear as "paste de following lines into your Cartfile" will be easier to carthage newbies like me auhahuahuahuahua. But i understand that is paste lines and im testing now.

Hi,
After include this reps:
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"

And carthage build, i have include the frameworks, but got error:
Invalid architecture: Could not read architectures from /Users/paulo/Developer/workspaces/xcode/ubook-reader-ios/Carthage/Build/iOS/FirebaseCoreDiagnostics.framework
Command /bin/sh failed with exit code 1

I've just deleted that framework, and all works well

I can ignore it? Remove it from my build and copy-framework?

Today im using all of this:

To use Analytics and Messaging parts.

@kasyanov-ms @prsolucoes I deployed Firebase 4.12.0 to Carthage and fixed the FirebaseCoreDiagnostics error in the process.
I'm not able to reproduce the "This app could not be installed at this time." issue. If that's still occurring for you, please create another issue with details on how to reproduce.

Hi @paulb777, Thanks for the update. But FirebaseCoreDiagnostics is needly or not?

Now with the new version everything is working and compiling, but when i run i get the error:

@prsolucoes i think that this might be some problem with your project configuration...

@olejnjak @paulb777  No guys, dont be a problem here. I create an empty and simple new project, add carthage file, download the frameworks, link into the project and the same problem happen. If i remove all from firebase, the project back to work:
The repository that i create only to test firebase and carthage:
https://github.com/prsolucoes/firebase

@olejnjak @paulb777 Hi. I made more command line tool in my sample project (https://github.com/prsolucoes/firebase). After run on simulator (make run-simulator) i got error:
ios-sim launch ./build/Build/Products/Debug-iphonesimulator/FirebaseTest.app --devicetypeid=iPhone-7
An error was encountered processing the command (domain=IXUserPresentableErrorDomain, code=1):
This app could not be installed at this time.
Underlying error (domain=MIInstallerErrorDomain, code=57):
	Found bundle at /Users/paulo/Library/Developer/CoreSimulator/Devices/CE49D8E9-CC06-4398-9ED1-D11DB21B64C9/data/Library/Caches/com.apple.mobile.installd.staging/temp.NvZWu9/extracted/FirebaseTest.app/Frameworks/FirebaseCore.framework with the same identifier (com.firebase.Firebase) as bundle at /Users/paulo/Library/Developer/CoreSimulator/Devices/CE49D8E9-CC06-4398-9ED1-D11DB21B64C9/data/Library/Caches/com.apple.mobile.installd.staging/temp.NvZWu9/extracted/FirebaseTest.app/Frameworks/Protobuf.framework

I think that it can be a clue.
Can you check?

Hi @olejnjak and @paulb777,
I solved it changing manually all info.plist as i sad and it is working now:
./Carthage/Build/iOS/Protobuf.framework/Info.plist:	<string>com.firebase.Firebase.Protobuf</string>
./Carthage/Build/iOS/Firebase.framework/Info.plist:	<string>com.firebase.Firebase</string>
./Carthage/Build/iOS/FirebaseCore.framework/Info.plist:	<string>com.firebase.Firebase.Core</string>
./Carthage/Build/iOS/FirebaseAnalytics.framework/Info.plist:	<string>com.firebase.Firebase.Analytics</string>
./Carthage/Build/iOS/FirebaseMessaging.framework/Info.plist:	<string>com.firebase.Firebase.Messaging</string>
./Carthage/Build/iOS/GoogleToolboxForMac.framework/Info.plist:	<string>com.firebase.Firebase.GTFM</string>
./Carthage/Build/iOS/nanopb.framework/Info.plist:	<string>com.firebase.Firebase.nanopb</string>
./Carthage/Build/iOS/FirebaseNanoPB.framework/Info.plist:	<string>com.firebase.FirebaseNanoPB</string>
./Carthage/Build/iOS/FirebaseInstanceID.framework/Info.plist:	<string>com.firebase.Firebase.InstanceID</string>
./Carthage/Build/iOS/FirebaseCoreDiagnostics.framework/Info.plist:	<string>com.firebase.Firebase.CoreDiagnostics</string>

Now you only need correct all the frameworks to have individual bundle-id. What i do is change to "com.firebase.Firebase + . + [Framework Name]"

@prsolucoes these are static frameworks, you are not supposed to add them to the copy-frameworks script

Hi,
So, i dont need add anyone too copy-framework?

Thanks.

Right - the Firebase frameworks are all static and linked at build time and don't need to be copied for runtime linking.

Hi,
I have updated everything and all is working.
I change all the project and make a sample that receive a message from Firebase console and show a push message. It is nice. With carthage support and makefile to help users.
Thanks for all support guys. Here is the repository:
https://github.com/prsolucoes/firebase

Hi there,
I have a question about the Carthage support help page.
Under Static Frameworks it is stated that:
"Note that the Firebase frameworks in the distribution include static libraries. While it is fine to link these into apps, it will generally not work to depend on them from wrapper dynamic frameworks."
Could this comment be elaborated?
Is it a generic logical issue with static libs inside dynamic frameworks?
Is it an issue with how Carthage does this?
Or is it an issue with the libraries themselves?
We are already manually building a dynamic wrapper framework using CocoaPods - and use this dynamic framework in our own Carthage setup.
Initial tests show that using this Carthage repo instead (still linking into a dynamic framework that contains all of our networking/sync logic) appears to work just fine, so it would be great to know what the issue might be.
Carthage support is a great update, thanks! Looking forward to the tvOS and macOS builds to become available through this channel as well. ;-)

@mortenbekditlevsen  Thanks for the feedback!
Yes - it's a general issue about how static and dynamic linking works.  Static linking happens at build time. Dynamic linking happens at run time. if a dynamic library depends upon a static library, that static library will be loaded at runtime, which it isn't necessarily built to do.  When a second dynamic library is linked that depends on the same static library, two copies of the static library will get linked into the app.
While app's like this may pass simple tests, they will have subtle failures based on indeterministic behavior of data inside the static library - like values of static/global variables or calls to isKindOfClass:.
Xcode will log in the console One of the two will be used. Which one is undefined.
While it may be possible to make workarounds viable for particular use cases, none of Xcode, CocoaPods, or Carthage have a general purpose solution for depending on static libraries from dynamic frameworks.

Thanks, @paulb777 ,
So am I correct in assuming, that if only one dynamic library has the static libraries linked, then you will only ever have one copy of the static libraries loaded, and you will get no inderterminism in that regard?

@mortenbekditlevsen that's correct.

I was also wondering, since Crashlytics are now part of Firebase and are the default crash reporting tool, can we expect official Carthage support? I mean different than "some guys" repo (https://github.com/Carthage/Carthage/issues/2036)?

+1 for Fabric/Crashlytics inclusion. I am waiting for this inclusion before I switch from my current Firebase solution.

Todd from Crashlytics here. Right now we don't have plans for official Carthage support, but all previous workarounds should continue to work in the new system. Thanks! 👍

I was told to investigate using Firebase for one an upcoming app.
This thread has been enlightening in helping me make a decision.
It seems Carthage support is officially out of the question - i.e., I'll look for another solution.
Unfortunately, I'm one of those developers not comfortable using a package manager that alters my project files / settings.

Hello,
This PR which just landed in Carthage/master makes it possible to use the archive at https://kit-downloads.fabric.io/cocoapods/fabric/1.7.6/fabric.zip with Carthage.
What is left to do, is for Google/Crashlytics to host the binary dependency file somewhere. This is a simple JSON, see https://github.com/Carthage/Carthage/blob/master/Documentation/Artifacts.md#binary-project-specification
@TKBurner Do you think this is something that Fabic users can expect? It would definitely be better for developers to get Fabric from the original source rather than so far benevolent third parties.

+1

@TKBurner Does you mean that we can't expect Crashlytics.framework and Fabric.framework to support Carthage, but FirebaseXXXX.framework and all Firebase originals will have Carthage support?

Hi everyone!
I've being trying to make FirebaseDatabase work with no success... I followed the installation guide throughfully, adding ObjC to other linker flags, removing the Firebase.framework from the linked frameworks, including GoogleService-Info.plist in my build target and my subset for the Cartfile is as follows:
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseDatabaseBinary.json"

I'm receiving a lot of Apple Mach-O Linker errors... 😕 This is a new project using Xcode 9.3, iOS 11 support, Swift 4.1 any clues? Thanks in advance!

@miguelrc86 Occasionally, Xcode's automatic linking fails to pull in all of the necessary libraries. You can find the missing libraries by internet searching the missing symbol errors or systematically adding in all of the libraries that show up in Carthage/Build/iOS/*/Modules/module.modulemap.
In this case, the c++ and sqlite libraries need to be added to the Link Binary With Libraries Build Phase:

Oh! Thank you so much @paulb777 for your ultra quick and clear response, will do that! 🙂

This also helped me - I was missing libicucore.tbd and libc++.tbd.

Thanks @paulb777 @pisarm added those libraries, also had to include StoreKit and voila! Firebase is up and running now 👊🏻

You are all in great hands with @paulb777, we had a chance to meet and are trying to see what we can as far as Crashlytics.

I've got Carthage working and running—however, I'm seeing the same linker warning as @rerelease and @Drusy:
ld: warning: Auto-Linking framework linker option at /Users/jacob/workspace/fundu-ios/Carthage/Build/iOS/Firebase.framework/Firebase is not a dylib and not an archive

There was a mention of removing any import Firebase statements; however, that seems to contradict the required step of configuring a FirebaseApp shared instance (e.g. FirebaseApp.configure() in application:didFinishLaunchingWithOptions:).
Has anyone managed to get rid of this warning?

@jemartti I resolved this by using import FirebaseCore instead if I remember well, so yeap, you need to follow the instructions by removing the Firebase framework and its related imports, hope it helps.

I often get an error when runninc carthage update with the framework protobuf. No idea where it comes from. Happens on different machines. Any ideas? thanks:)
carthage update --platform iOS
*** Downloading binary-only framework FirebaseDynamicLinksBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseDynamicLinksBinary.json"
*** Downloading binary-only framework FirebasePerformanceBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json"
*** Downloading binary-only framework FirebaseABTestingBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json"
*** Downloading binary-only framework FirebaseFunctionsBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFunctionsBinary.json"
*** Downloading binary-only framework Fabric at "https://raw.githubusercontent.com/Building42/Specs/master/Carthage/Fabric.json"
*** Downloading binary-only framework FirebaseDatabaseBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseDatabaseBinary.json"
*** Downloading binary-only framework FirebaseMessagingBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"
*** Downloading binary-only framework FirebaseAnalyticsBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
*** Fetching Localize-Swift
*** Downloading binary-only framework FirebaseFirestoreBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json"
*** Downloading binary-only framework FirebaseAdMobBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAdMobBinary.json"
*** Downloading binary-only framework FirebaseAuthBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json"
*** Downloading binary-only framework Crashlytics at "https://raw.githubusercontent.com/Building42/Specs/master/Carthage/Crashlytics.json"
*** Downloading binary-only framework FirebaseRemoteConfigBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json"
*** Downloading binary-only framework FirebaseStorageBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseStorageBinary.json"
*** Downloading binary-only framework FirebaseInvitesBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseInvitesBinary.json"
*** Checking out Localize-Swift at "2.0.0"
*** Downloading binary-only framework Crashlytics at "https://raw.githubusercontent.com/Building42/Specs/master/Carthage/Crashlytics.json"
*** Downloading binary-only framework Fabric at "https://raw.githubusercontent.com/Building42/Specs/master/Carthage/Fabric.json"
*** xcodebuild output can be found in /var/folders/xw/40bn71nx71591_rwtsp05k780000gn/T/carthage-xcodebuild.3BRGy2.log
*** Downloading binary-only framework FirebaseABTestingBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json"
*** Downloading binary-only framework FirebaseAdMobBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAdMobBinary.json"
*** Downloading binary-only framework FirebaseAnalyticsBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
*** Downloading binary-only framework FirebaseAuthBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json"
*** Downloading binary-only framework FirebaseDatabaseBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseDatabaseBinary.json"
*** Downloading binary-only framework FirebaseDynamicLinksBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseDynamicLinksBinary.json"
*** Downloading binary-only framework FirebaseFirestoreBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json"
*** Downloading binary-only framework FirebaseFunctionsBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFunctionsBinary.json"
*** Downloading binary-only framework FirebaseInvitesBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseInvitesBinary.json"
*** Downloading binary-only framework FirebaseMessagingBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"
*** Downloading binary-only framework FirebasePerformanceBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json"
*** Downloading binary-only framework FirebaseRemoteConfigBinary at "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json"
A shell task (/usr/bin/xcrun dwarfdump --uuid /Users/<...>/Carthage/Build/iOS/Protobuf.framework/Protobuf) failed with exit code 1:
error: unable to open '/Users/<...>/Carthage/Build/iOS/Protobuf.framework/Protobuf': No such file or directory

@nidegen I've seen this a few times, but not able to reproduce reliably. I suspect a Carthage race condition since Protobuf.framework is a dependency of multiple components.
Rerunning the carthage update command is a workaround.

@paulb777 yes I have also just reupdated carthage a couple of times, but it is really a pain for our CI pipelines😬😬
are the binaries not just download only? how comes carthage has to check out dependencies there?

@nidegen Since Carthage doesn't do dependencies for binaries, the multiple Firebase components that depend on Protobuf.framework need to include it.

Some frameworks are fetching version 5.0.1 and some version 5.1.0.
Example:
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json" is only pulling down 5.0.1
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json" == 5.0.0 produces
No available version for binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json" satisfies the requirement: == 5.1.0
The JSON file contains 5.1.0 but it seems Carthage but perhaps it does not like that is out of order.
Anyone else seeing this issue?

@paulb777 i dont get it. if binaries have no dependencies (I already understood it that way) why is there an issue with a dependency (protobuf). To me it seems that carthage does check for dependencies after all, or performs some kind of processing of the binaries. i dont see why it should / a binary package is performing anything

@nidegen The Carthage zip files for multiple Firebase components include the Protobuf.framework. If you're using two or more of those components, Carthage will attempt to do multiple copies to ./Carthage/Build/iOS/Protobuf.framework.
@schlingding Does clearing the Carthage cache make a difference - rm -rf ~/Library/Caches/org.carthage.CarthageKit

@paulb777 I have tried clearing the cache and removing the Carthage folder as well. Same results. I’m on the latest version of Carthage.

@paulb777 Ran Carthage today and now it's pulling all 5.1.0 versions. Leaving the previous comment intact in case someone else runs into the issue.

Seeing this on "5.2.0"
Failed to write to /.../Carthage/Build/iOS/Protobuf.framework: Error Domain=NSCocoaErrorDomain Code=513 "“Protobuf.framework” couldn’t be removed because you don’t have permission to access it." UserInfo={NSFilePath=/.../Carthage/Build/iOS/Protobuf.framework, NSUserStringVariant=(
    Remove
), NSUnderlyingError=0x7faa64d60730 {Error Domain=NSPOSIXErrorDomain Code=66 "Directory not empty"}}

Only way to resolve is
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json" == 5.1.0

@paulb777 For the protobuf checkout bug, deleting cache with rm -rf ~/Library/Caches/org.carthage.CarthageKit actually fixes my issue, probably also yours @walsht
I run it before each carthage update

Hey guys! Can you add macOS support? The binary binary ".../firebase/ios/carthage/FirebaseAnalyticsBinary.json" is working perfectly for iOS, but it would even greater to have a binary link for macOS as well.

Anyone had troubles updating from 5.4 to 5.6? Missing FirebaseNanoPB and GoogleToolboxForMac, and I'm unable to build the project without those.

Firebase is releasing weeks faster than the updates to the binary files for carthage.
At the time of this post, I'm seeing the latest carthage binary references at 5.8.0 where 5.8.1, 5.9.0, and 5.10.0 have since been released.
Can updating these binary references be part of the Firebase iOS release process or are there further issues?
Please update soon so the community can take advantage of the bug fixes and enhancements.
Thank you!

@schlingding 5.10.0 is now available via Carthage.
See #1862 to follow the status of official Carthage support

Those of you interested in Firebase via Carthage may want to check out Firebase via Rome. Rome provides many of the Carthage features as well as a few additional advantages. Check out the details at https://github.com/firebase/firebase-ios-sdk/blob/master/Rome.md.
We'd love to hear any feedback in another issue.

thanks, @paulb777 clearing carthage cache solved my issue


Could not find class 'android.widget.NumberPicker'

From<EMAIL_ADDRESS>on October 15, 2012 05:59:24
There is problem with the newest robotium - could not find NumberPicker class.
Problem exists for devices with api <= 2.1
NumberPicker class exists from api 2.2
Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.
10-15 13:12:12.518 E/dalvikvm(  972): Could not find class 'android.widget.NumberPicker', referenced from method com.jayway.android.robotium.solo.Solo.getCurrentNumberPickers
10-15 13:12:12.518 W/dalvikvm(  972): VFY: unable to resolve const-class 70 (Landroid/widget/NumberPicker;) in Lcom/jayway/android/robotium/solo/Solo;
10-15 13:12:12.538 E/dalvikvm(  972): Could not find class 'android.widget.NumberPicker', referenced from method com.jayway.android.robotium.solo.Solo.setNumberPicker
10-15 13:12:12.538 W/dalvikvm(  972): VFY: unable to resolve const-class 70 (Landroid/widget/NumberPicker;) in Lcom/jayway/android/robotium/solo/Solo;
10-15 13:12:12.538 W/dalvikvm(  972): VFY: unable to find class referenced in signature (Landroid/widget/NumberPicker;)
10-15 13:12:12.538 W/dalvikvm(  972): VFY: Ljava/lang/Object; is not instance of Landroid/view/View;
10-15 13:12:12.538 W/dalvikvm(  972): VFY: bad arg 1 (into Landroid/view/View;)
10-15 13:12:12.538 W/dalvikvm(  972): VFY:  rejecting call to Lcom/jayway/android/robotium/solo/Waiter;.waitForView (Landroid/view/View;I)Z
10-15 13:12:12.538 W/dalvikvm(  972): VFY:  rejecting opcode 0x6e at 0x0004
10-15 13:12:12.538 W/dalvikvm(  972): VFY:  rejected Lcom/jayway/android/robotium/solo/Solo;.setNumberPicker (Landroid/widget/NumberPicker;I)V
Original issue: http://code.google.com/p/robotium/issues/detail?id=339

From<EMAIL_ADDRESS>on October 15, 2012 06:33:38
I will have to remove the new NumberPicker methods. Will make a new release today (3.5.1).
Status: Accepted
Owner<EMAIL_ADDRESS>

From<EMAIL_ADDRESS>on October 15, 2012 07:09:01
3.5.1 has been released now. You will find it at: https://code.google.com/p/robotium/downloads/list
Status: Verified

From<EMAIL_ADDRESS>on September 26, 2013 05:49:15
What is the proper way to manipulate a numberpicker-widget with robotium after the methods have been removed?


reCAPTCHA v1 is shut down

See https://developers.google.com/recaptcha/docs/faq

Is this why I cannot post a comment to a snippet?  The captcha field just screams red saying the field is required but there is nothing I can see that I can type in.

Yup, that would be why!


[core] enable bf16 training

Currently on the main branch of trl training in bfloat16 & logging with wandb fails. Users will encounter an error that are hard to interpret.
The fixes are the following:

remove wandb.watch(model) as it takes care of logging gradients that are in bf16, otherwise users will get an error that is similar to https://github.com/wandb/wandb/issues/3332 | I propose to remove this is not a core feature and is a main blocking point
upcast the tensors in fp32 before logging them
force-upcast the lm_logits in fp32

cc @lvwerra

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

What's the issue with lm_logits being in fp32?

So that we can compute the loss in fp32 and I found that this was more stable + sometimes we log a list of tensors, and directly casting the loss in fp32 avoids the issue with numpy & bf16

@younesbelkada @lvwerra I'm running into a problem where this forced upcast causes a massive spike in memory for models with large vocabularies (e.g., Gemma 2 by Google). This then either throws an OOM error or forces me to cut the minibatch size in half, which doubles the runtime
https://github.com/huggingface/trl/issues/1980
Could you please provide more information or evidence about the stability argument?


[CBR-446] Evaluate acid-state fix

Description
There was a space leak in acid-state. This PR incorporates that fix and removes the checkpointing code that was a temporary in-repo fix.
Linked issue

Type of change

[x] 🐞 Bug fix (non-breaking change which fixes an issue)
[~] 🛠 New feature (non-breaking change which adds functionality)
[~] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[~] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[~] 🔨 New or improved tests for existing code
[~] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[x] I have read the style guide document, and my code follows the code style of this project.
[x] If my code deals with exceptions, it follows the guidelines.
[x] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
[ ] CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

[~] I have added tests to cover my changes.
[x] All new and existing tests passed.

QA Steps

Screenshots (if available)

Looks great, thanks @parsonsmatt !

I'll rebase this and fix stack2nix while Matt is asleep :)

Integration tests still failing, fix coming as part of #3684, likely not related to this.


[Suggestion] Refresh Machine Recipe Configs In-Game

Suggestion: Refresh Machine Recipe Configs In-Game.
I'm suggesting this as an idea since it's a real pain having to close and reopen Minecraft in order for the changes done to the machine configs to take place. It would also save modpack developers time when making a pack. It could be done by a simple command like; '/enderio_configs' or something along those lines.

Thank you for your suggestion. It has been added to our list or possible enhancement.
This ticket will be closed because we want the list of open tickets to reflect known issues.


joplin-desktop: 2.13.15 -> 2.14.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/joplin/versions.
meta.description for joplin-desktop is: An open source note taking and to-do application with synchronisation capabilities
meta.homepage for joplin-desktop is: https://joplinapp.org
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.14.11 with grep in /nix/store/kz4dyxgy232sw0qycgjd4jl95k7ljs83-joplin-desktop-2.14.11
found 2.14.11 in filename of file in /nix/store/kz4dyxgy232sw0qycgjd4jl95k7ljs83-joplin-desktop-2.14.11

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
joplin-desktop

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/kz4dyxgy232sw0qycgjd4jl95k7ljs83-joplin-desktop-2.14.11 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A joplin-desktop https://github.com/r-ryantm/nixpkgs/archive/62952599a8625c4b00e040169cd8b006539b06d0.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/62952599a8625c4b00e040169cd8b006539b06d0#joplin-desktop

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/kz4dyxgy232sw0qycgjd4jl95k7ljs83-joplin-desktop-2.14.11
ls -la /nix/store/kz4dyxgy232sw0qycgjd4jl95k7ljs83-joplin-desktop-2.14.11/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

joplin-desktop

Maintainer pings
cc @HugoReeves @qjoly for testing.

This is a pre-release version of Joplin

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/joplin/versions.
meta.description for joplin-desktop is: An open source note taking and to-do application with synchronisation capabilities
meta.homepage for joplin-desktop is: https://joplinapp.org
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.14.17 with grep in /nix/store/krw0vc3ij7lww128vgplvc6bwz8hmz45-joplin-desktop-2.14.17
found 2.14.17 in filename of file in /nix/store/krw0vc3ij7lww128vgplvc6bwz8hmz45-joplin-desktop-2.14.17

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
joplin-desktop

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/krw0vc3ij7lww128vgplvc6bwz8hmz45-joplin-desktop-2.14.17 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A joplin-desktop https://github.com/r-ryantm/nixpkgs/archive/a356c6e4335cbdd8b04de522eed995d8b2c86d12.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/a356c6e4335cbdd8b04de522eed995d8b2c86d12#joplin-desktop

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/krw0vc3ij7lww128vgplvc6bwz8hmz45-joplin-desktop-2.14.17
ls -la /nix/store/krw0vc3ij7lww128vgplvc6bwz8hmz45-joplin-desktop-2.14.17/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

joplin-desktop

Maintainer pings
cc @HugoReeves @qjoly for testing.

This is a pre-release version of Joplin

now 2.14.17 is an actual release


CockroachDB ON UPDATE clauses are ignored

I assume this is because they aren't supported in postgres, it is a cockroachdb extension because they don't support triggers yet. I defined them in my schema.sql, they seem to be silently dropped when atlas tries to actually apply the schema.
ON UPDATE is documented here https://www.cockroachlabs.com/docs/stable/create-table.html#on-update-expressions

On update support would be very nice, but more critically we need a way to know if something isn't supported without it just silently disappearing


Add LocalAddr to Config struct and honor in broker.Open().

We have hosts that are multi-homed and being able to pick a source address is important to contend with things like network ACLs.

Nice, thanks!


CDN for beta.0 not working

CDN for beta.0, as per readme, doesn't seem to work:
https://npmcdn.com/<EMAIL_ADDRESS>Is this the new one? I poked around for a bit and it seems to be match
https://npmcdn.com/<EMAIL_ADDRESS>

Think you just hit cases before this PR (https://github.com/ReactiveX/RxJS/pull/1070) lands in, points latter as you tried :)

I just checked in changes and believe issue's now resolved, closing it. Please feel free to reopen if it's required.

Can confirm, CDN gets me the right file. Cheers!


running ALEFix on save

Hello! I am a new user of ale, I noticed the work done on #571, and have started trying to use it. I'm running into issues when trying to run it on save (which is being tackled by #570), but figured I might as well ask in case it is due to user error.
Here are my configs:
let g:ale_fixers = {}
let g:ale_fixers.javascript = [
\ 'prettier',
\ 'eslint',
\]
let g:ale_javascript_prettier_options = ' --stdin\ --parser\ flow\ --single-quote\ --trailing-comma\ all\ --no-bracket-spacing'

autocmd BufWrite *.js ALEFix

I'm noticing a few things:

I'm trying to set up a autocommand to run ALEFix on save, but for some reason when I save, the file will write, the checker will run, and then the buffer will update with the changes. As a result:
a. vim complains that the buffer has not yet been saved when trying to quit
b. if i very quickly quit before the buffer updates with the change, the fix won't actually occur (e.g, via :wq.

Is this due to some async feature of ale? I previously used neoformat to do something similar, for which this doesn't occur.

when specifying ale_fixers for javascript, if I change the order of eslint and prettier so that eslint comes before prettier, the javascript_prettier_options don't get applied.

If I don't specify ale_javascript_prettier_options, ALEFix runs into an error

Error detected while processing function ale#fix#Fix[21]..<SNR>213_RunFixer[6]..ale#handlers#prettier#Fix[1]..ale#Var:
line    3:
E716: Key not present in Dictionary: ale_javascript_prettier_options
E116: Invalid arguments for function getbufvar(str2nr(a:buffer), l:full_name, g:[l:full_name])
E15: Invalid expression: getbufvar(str2nr(a:buffer), l:full_name, g:[l:full_name])

Thank you for doing such amazing work!

You can't accomplish this with a simple autocmd on BufWrite. I will add support for this eventually.
The jobs for fixing files run asynchronously, so eslint and prettier will stop executing after the file has already been closed. I need to change the code so it can be used for writing changes back to the file on disk, even if the buffer is no longer open.

I'll have to make a note to change ale#Var so it can look up buffer variables from a Dictionary which is saved for fixing files if the buffer is closed before fixing is completed.

This is supported with an option now. See :help g:ale_fix_on_save.

wow, thank you for the incredibly quick turnaround!

Not sure if this can be fixed but when I do a :wq in NeoVim I get these errors:
Error detected while processing function <SNR>99_NeoVimCallback[29]..<SNR>106_HandleExit:
line   13:
E484: Can't open file /var/folders/nc/1y1czqf96736xppxnnkmgkrc0000gn/T/nvimrSHvON/6/keyword_args.rb

Please open a new issue with steps for repeating the bug.


Bluetooth: Host: Support concurrent initiating and scanning

The HCI command LE Read Supported States command returns if the controller supports running the scanner and initiator roles in parallel.
This commit utilizes this information in the host:

It does not prevent initiating a connection when the scanner is running
It does not prevent the host from restarting the background scanner when there the host wants to auto-initiate a connection.
It does not stop the scanner when the host wants to auto-initiate a connection.

To support this feature, the scanner and initiator always have to use the same address. This because the HCI command LE Set Random Address cannot be issued after the initiator or scanner has started.

When privacy is disabled, the scanner has to use its identity
address to ensure it uses the same address as the initiator.
Only one identity is supported.

To simplify the implementation, it is a requirement to use
extended advertising commands to avoid interfering with
the random address used by the advertiser(s).
The changes in this commit will be tested out of tree as the Zephyr Bluetooth Controller does not support this functionality.

For those that stumble upon this PR, this PR does not yet contain changes needed in host/id.c.
Assumptions:

The controller will not support concurrent scanning and initiating with two different identities (public + random).
This feature will only be used when the controller supports extended advertising and scanning commands. Otherwise the advertiser must also be taken into account when starting or stopping the scanner/initiator.

Implementation requirement:

When starting the initiator after the scanner, the controller random address is not updated. The spec does not allow changing the random address when one of those two roles are running.

Changes needed:
The functions bt_id_set_scan_own_addr() and bt_id_set_create_conn_own_addr() are by default now not setting the same address. This requires changes in order to meet requirement (1).
a) bt_id_set_create_conn_own_addr(). If privacy is enabled, a new (host generated) RPA is set. Otherwise, the default ID is used.
b) bt_id_set_scan_own_addr(). A new (host generated) RPA is set unless CONFIG_BT_SCAN_WITH_IDENTITY is enabled.
This may require the following:

When CONFIG_BT_PRIVACY is enabled:

These two functions need to take into account if the scanner or initiator is running. If "the other role" is running, we need to reuse the previously generated address.

When CONFIG_BT_PRIVACY is disabled:

The scanner needs to use its identity address with scanning. That is, CONFIG_BT_SCAN_WITH_IDENTITY is required.

le_update_private_addr() called upon le_force_rpa_timeout() may require additional changes to restart the initiator-

Do we really want to extend the support for stack-initiated scanning? It was under my impression that we would remove that feature in the near future, similar to the auto-adv resume feature

Do we really want to extend the support for stack-initiated scanning? It was under my impression that we would remove that feature in the near future, similar to the auto-adv resume feature

I would say that most of the complexity in this PR is to allow this functionality to work nicely with the existing stack-initiated scanning. The auto-connect and fallback to host privacy are things that make it hard. If we would to remove that later, it would make the  implementation simpler. Until that is done we need to ensure existing functionality is not broken.

Pushed to retrigger CI testing.

Do we really want to extend the support for stack-initiated scanning? It was under my impression that we would remove that feature in the near future, similar to the auto-adv resume feature

I would say that most of the complexity in this PR is to allow this functionality to work nicely with the existing stack-initiated scanning. The auto-connect and fallback to host privacy are things that make it hard. If we would to remove that later, it would make the implementation simpler. Until that is done we need to ensure existing functionality is not broken.

I may have misunderstood something then - Isn't this PR adding a new feature, rather than fixing an existing feature?
My point was that if we were to remove the feature complete in the coming months, then I'd rather not add a new Kconfig (CONFIG_BT_SCAN_AND_INITIATE_IN_PARALLEL) that has to be deprecated as well.
Others may disagree with me, so let's hear what they say :)

Do we really want to extend the support for stack-initiated scanning? It was under my impression that we would remove that feature in the near future, similar to the auto-adv resume feature

I would say that most of the complexity in this PR is to allow this functionality to work nicely with the existing stack-initiated scanning. The auto-connect and fallback to host privacy are things that make it hard. If we would to remove that later, it would make the implementation simpler. Until that is done we need to ensure existing functionality is not broken.

I may have misunderstood something then - Isn't this PR adding a new feature, rather than fixing an existing feature?
My point was that if we were to remove the feature complete in the coming months, then I'd rather not add a new Kconfig (CONFIG_BT_SCAN_AND_INITIATE_IN_PARALLEL) that has to be deprecated as well.
Others may disagree with me, so let's hear what they say :)

I understand why you would like to avoid adding another Kconfig entry. As I see it, we need to start using controller-based privacy to get rid of the listed limitations. That is not straight-forward. Here is a more detailed view of the added limitations:

The use of extended advertising commands. This limitation was added because we use host-based privacy. With legacy commands we would have to stop the initiator when the advertiser RPA refreshes. This adds additional complexity. Getting rid of this limitation is not straight forward. Tracked in https://github.com/zephyrproject-rtos/zephyr/issues/71751.
Scanning with identity address when !BT_PRIVACY. Without this, the scanner would use a NRPA and the initiator would use an identity address. This is not possible as the controller cannot use two different random addresses at the same time. It is likely that this limitation can be resolved by using controller-based privacy.
Supporting one identity only: This limitation may be unnecessary to keep. Added it to simplify testing efforts. The number of use cases where both these features are needed is likely limited.
Scanning without timeout only: Relates to the use of host privacy. Can also be fixed by implementing the timeout in the host. See also https://github.com/zephyrproject-rtos/zephyr/issues/73634


[charm_tracing] Add juju_charm to topology attributes

Enhancement Proposal
In charm_tracing, we create resource attributes for the root span:
        resource = Resource.create(
            attributes={
(...)
                # juju topology
                "juju_unit": unit_name,
                "juju_application": self.app.name,
                "juju_model": self.model.name,
                "juju_model_uuid": self.model.uuid,
            }
        )

They don't contain the charm name itself. Should it be added?

I can't recall why I didn't add it. I think it didn't sound especially useful given we already have charm type and unit.
We could do that though.


Absolute import path generates if long subfolder hierarchy

Steps to Reproduce

Create a new project.
Create 'widgets' folder and any subfolder like 'auth'.
Create a dart file inside this folder with some classes.
Mention these classes in another dart file and press 'Enter'. It should auto-generate an 'import' line.

Expected results:
Project relative path generated:
import 'package:chatapp/widgets/auth/auth_form.dart';
Actual results:
Absolute disk path generated:
import 'file:///D:/Flutter/chat_app/lib/widgets/auth/auth_form.dart';
Obviously if you move your project to the other folder this path would be wrong. Thus it's not a appropriate behaviour.

Which IDE are you using?
This seems like a bug in an IDE plugin, or perhaps a bug in the analysis server.

/cc @dantup @jacob314

I use Android Studio


Check box (the toggleone) and dropdown problem

$('.test.checkbox').checkbox({
	onChecked:function(){
		$('#studyField').addClass('animated fadeOutLeft').one(animEnd,
			function(){
				$(this).removeClass('animated fadeOutLeft');
				$(this).addClass('closed');
				$('#eventField').removeClass('closed');
				$('#eventField').addClass('animated fadeInLeft').one(animEnd,
					function(){
						$(this).removeClass('animated fadeInLeft');
					});

			});

	},
	onChange:function(){

		$('#eventField').addClass('animated fadeOutLeft').one(animEnd,
			function(){
				$(this).removeClass('animated fadeOutLeft');
				$(this).addClass('closed');
				$('#studyField').removeClass('closed');
				$('#studyField').addClass('animated fadeInLeft').one(animEnd,
					function(){
						$(this).removeClass('animated fadeInLeft');

					});

			});

	}
});
$('.ui.dropdown').dropdown();

here is my code inside my javascript file.
everything is working fine. the link src are properly arranged and the animations work.
what my code does is hide/show a div containing a field where there is a dropdown input and div containing a field with out a dropdown input.
THE PROBLEM:
the first time I encounter the page I can properly use the dropdown input.
but when I toggle the checkbox (http://semantic-ui.com/modules/checkbox.html#toggle)
which hides the div with a dropdown and shows the div without dropdown.
the drop down input malfunctions
why?
when i toggle again the checkbox
which hides the div without dropdown and show the div with a dropdown, everytime I click the dropdown it AUTOMATICALLY toggles the switchbox which is very weird.
I hope you could help me out. answers are much appreciated

it works well on firefox idk with chrome

Have something weird happening with both checkbox toggle and checkbox slider.
This checkbox is controlling another bunch of hidden fields on my page. And sometimes when I click on a toggle, the whole screen goes blank on mobile safari. I debugged it with developer tools, and the only thing that fixed blank screen is to toggle off/on z-index: -1 on the checkbox input element. And that is really weird because this z-index css attribute is only set on .ui.checkbox input.hidden


Make the _DatePickerDialog easier to driver with Flutter driver

The Material date picker dialog is pretty hard, verging on impossible (to selected dates from previous/future years) to control via the Flutter Driver due to the lack of keys on some elements.
It would be great to have keys on the main elements so that they can be tapped by the driver.  The useful elements to have well known keys on are highlighted below:

Having well known keys on these elements would make it easier to figure out the currently selected date and subsequently what driver actions to take to pick another date before or after the current date.
I'm happy to do a PR for this so let me know any thoughts or if I have missed something simple with driving this element with the driver.
As an example to selected a date around the current date I currently have to do this, which is pretty horrid and would be made a lot easier if I was able to use a key to get the currently selected date and year.  Then I would also be able to driver the widget to select a date far in the past or future by being able to tap the year button, select a year then month and day etc.
    final monthYearText = DateFormat.yMMMM(locale).format(dateToSelect);

      await runZoned(
        () async {
          await world.driver.scrollUntilVisible(
            find.byType('PageView'),
            find.text(monthYearText),
            dxScroll: 200,
            timeout: const Duration(seconds: 10),
          );
        },
        onError: (dynamic error, dynamic stack) async {
          await world.driver.scrollUntilVisible(
            find.byType('PageView'),
            find.text(monthYearText),
            dxScroll: -500,
            timeout: const Duration(seconds: 20),
          );
        },
      );

      await world.driver.tap(
        find.text(day.toString()),
        timeout: const Duration(seconds: 2),
      );

      await world.driver.tap(
        find.text('OK'),
        timeout: const Duration(seconds: 2),
      );

At the moment the above code just relies on blind luck to select a date (which has to be fairly close to the current date) which leads to unstable tests.
Note: running tests on the current stable branch.
Jon

Any updates with this?

I also need this feature,
Can't select previous year's :(


ref #23 - Upgrade django-chartjs to python35 and Django 1.8+

Upgrade support to python 2.7 + 3.4 + 3.5, on Django 1.8 + 1.9 and 1.10
ref #23

[x] change tox.ini
[x] change .travis.yml
[x] update demoproject and settings in order to unit tests to pass
[ ] need to do a new release or release on PyPi for python3 ?

Should we release a new version or same version under universal wheel for py2 and py3?

A new version :)

PR ready for review

Yes I guess it is good if people can run the same things as travis does locally using tox

Updated to have the matrice in tox :)


Add tool for auditing blockchain event order

This is an alternative to #998, written in Go rather than bash.
Not sure where we should put scripts if we keep adding them... do we just keep adding root level folders like this?

I really like the go version. I'm not sure the best way to organize all of the scripts,