Common Edit Command Library

Overview
The industry is full of timeline management software but nearly all of them include a fundamental set of tools for manipulation. The most well known being:

Overwrite
Trim
Cut
Slip
Slide
Ripple
Roll
Fill (3/4 Point Edit)

OpenTimelineIO, while not seeking to become a fully realized NLE, could benefit from having a simple toolkit to help automate building/modifying timelines based on time rather than index alone.
Proposal
For editing commands, we should strive to do all validation and assert that everything works before committing anything on the timeline. I'm proposing the EditEvent which might something like:
class EditEvent {
public:
    EditEventKind kind; // e.g. Insert, Append, Remove, Modify
    Retainer<Composition> parent;
    Retainer<Composable> composable;

    // ... Additional fields to execute the above as required

    bool run(ErrorStatus* error_status);
    bool revert();
};

An event is atomic in nature and does "one thing" to a Composable. Each edit maneuver (e.g. otio.edit.place(...)) would generate a vector of these events that can be played forward and, possibly, backward. The result of them collectively is the commands result.
for (EditEvent &event: events) {
    event.run(error_status);
    if (*error_status) {
        for (auto it = completed_events.rbegin(); /*...*/)
            (*it).revert();
        break;
    }
    completed_events.push_back(event);
}

Alternatively, we could build a more robust transaction system since all items can be cloned but there are memory considerations for that and beyond the scope of this initial proposal.
API
The API might look like:
otio.edit.place(item, into=track, at=rat_time, placement_kind=otio.edit.PlacementKind)
otio.edit.trim(item, edge=otio.edit.ItemEdge)
etc.

Additional commands can be added as the editing foundation is built.
Pros:

Atomic events make reuse simple and should scale well with the complexity of edit commands
Hooks up nicely to an undo/redo framework on third party software

Cons:

Additional code to handle event care

Questions/Considerations:

Could we handle preview flags for edit commands? This would let third party tools inspect the outcome of events before committing them.
Should EditEvent be a class system (e.g. InsertEvent, ModifyEvent) or something else entirely?

Thanks for the feedback! I agree that the transaction system is a whole extra dragon to slay. I'll try to proceed with the edit layer sans-transactions and keep lookout for a nice way to transition into a layer atop/aside it.
As for the initial edit commands, I've generated some images and assessed what their possible API call might look like. It's a rather long message so I've just linked the images. For documentation I would set them all together.
Overwrite

Image Reference
Anything overlapping is destroyed on contact. This may split an item.

API
otio.edit.place(
    composable: Composable,
    into: Composition,
    at: RationalTime,
    placement: otio.edit.PlacementKind = otio.edit.PlacementKind.Overwrite,
    fill_template: Composable = None, # Default to Gap
)

Insert

Image Reference
Items past the in point are shifted by the new items duration.
Item may be split if required.

API
otio.edit.place(
    ...,
    placement: otio.edit.PlacementKind = otio.edit.PlacementKind.Insert,
)

Trim

Image Reference
Adjust a single item's start time or duration.
Do not affect other clips.
Fill now-empty time with gap or template.
Clamps source_range to non-gap boundary (can only overwrite gaps)

API
otio.edit.trim(
    composable: Composable,
    adjust_in: RationalTime = None,  # Duration of change
    adjust_out: RationalTime = None  # -Duration of change
)

Slice

Image Reference
Slice an item, generating a clone of self and augment both item's source_range.

API
otio.edit.slice(
    composable: Composable,
    at: RationalTime,
)

Slip

Image Reference
Adjust the start_time of an item's source_range.
Do not affect surrounding items.
Clamp to available_range of media (if available)

API
otio.edit.slip(
    composable: Composable,
    delta: RationalTime, # Relative (e.g. RationalTime(-1, 24) sources one frame earlier)
)

Slide

Image Reference
Adjust start time of item and trim adjacent items to fill
Do not change main item's duration, only adjacent
Clamp to available range of adjacent items (if available)

API
otio.edit.slide(
    composable: Composable,
    delta: RationalTime, # Relative like slide
)

Ripple

Image Reference
Adjust a source_range without adjusting any other items
This effectively shifts all currently adjacent items to stay at the edges
(Impl detail for otio, this is the same as adjusting the source_range of the item)

API
otio.edit.ripple(
    composable: Composable,
    adjust_in: RationalTime = None,  # Duration of change
    adjust_out: RationalTime = None  # -Duration of change
)

Roll

Image Reference
Any trim-like action results in adjacent items source_range being adjusted to fit
No new items are ever created
Clamped to available media (if available)

API
otio.edit.roll(
    composable: Composable,
    adjust_in: RationalTime = None,  # Duration of change
    adjust_out: RationalTime = None  # -Duration of change
)

3/4 Point Edit

Image Reference
The most complex - this "fills" a gap based on a source in/out point or track in/out point
Often used to patch in items as edit is built
Note: This can be accomplished by a conjunction of commands above

API
otio.edit.fill(
    composable: Composable,
    into: Composition,
    replace: Composable,
    reference_point: otio.edit.ReferencePoint.SourceOut
)

One additional command might be a general swap. This can effectively be a "delete" and will replace an item with a gap or some fill template.

I think there is enough here, and assuming you're interested in doing the work, that a good way to go would be to put this into a .md file in the documentation folder and make a PR to start iterating on it.  It will be easier to make notes on the md using github's code review system, given how long this is.  We took a similar approach with the C++ core, first making a PR with documentation and design and then following up with implementation.
The images (which are great!) that you made can also be added inline in that case.
The document ^^ can also serve to seed the future document which is more user facing describing how to use these functions to execute common editing operations on OTIO files.
Some notes:

It seems like most of these arguments that you've marked as item: Item probably want to be compositions, right?  or example, does Slide make sense on a single free item? It seems like you want to give it a Composition (and maybe even more specifically a Track, and the implementation finds the item that you want to transform within the track.  Does that make sense?
For any parameter that is a time coordinate (for example, the at parameter, or the trim arguments), we're trying to get better at documenting the coordinate system that the argument is meant to be in.  For example, if you have trackA, and you are calling trim, I would expect the arguments to be in the track's output coordinate system (so after any kinds of effects or trimming has been done).
similar to how the place function has multiple uses, can slice, slip, and slide use the same underlying function with different replacement policies?  Similar question for ripple and roll.
After thinking about it, we have an algorithms module, which has things like flattening and filtering at the moment.  Would it make sense to have an edit_algo module under that?  Or are these distinct enough that users would expect to see them in an olio.edit namespace rather than olio.algorithms.splice for example?

This is fantastic, and fills a gap (pun intended) in OTIO that we have talked about for ages.
A couple of notes:

It might be easier to understand if place was separated into two overwrite and insert functions.
I can see clearly how most of these would work when modifying one or more clips in a track. However, if you use place to insert a clip into a stack, then it is less clear - does the clip only go into the top track of the stack? Does a new track get inserted? Similarly if I insert a stack into a stack, should it match up each track?
The additional swap function seems like a special case of fill - having a clear distinction between which one will trim/extend versus applying a speed up/down effect to stretch the clip to fit would be good. No one wants to accidentally apply a speed effect :)

When I was writing the flatten algorithm, I wished I had these. And in fact, there are some flaws in the flatten algorithm that could be addressed once we have these. That's more evidence that maybe flatten should be in the same module namespace as these.

Thanks again for the notes! I'm excited to take on the challenge. I'll work on a design doc in a PR next. The structure is definitely something I want to get right. The otio.algorithms module could be a great spot to expose the library, as long as we make it clear that it hosts the edit toolkit.
@ssteinbach

I see the need to specify the arguments more clearly for the various calls. We just have to decide if we're taking this api as either:

A. "do the edit to whatever item is at this time in a parent"
--- or ---
B. "apply the edit to the item I've got hold of"

All of these commands start with a single item and the edit algorithm decides what other elements need augmenting/removal. Because of that, the second way speaks to me more but I'm open to either path. I'll whip up some additional diagrams for this in the design doc to gain consensus.

For the time coordinates, I've had good luck with relative deltas wherever they fit. So for the command: "Trim this item's start point three frames in.", We only have to know the item we're adjusting, and it's left-sided neighbor, if any. So perhaps delta_start and delta_end would fit better? Another great topic for the design doc. The at parameter could use a name change (parent_time? - would the into argument be better as parent?)

@jminor

I think splitting the place command at the api level is a good idea. Under the hood they can still use nearly the same code path. That goes to @ssteinbach's point about the merging commands. The implementation will reuse a lot of the code, we just have to decide how explicit/general we want our end API to feel.

A few more notes on the notion of a transaction system, and a set of editing operations, and their relationships.
I would like to be able to use such a system of transacted edits as follows:

given a set of tracks and clips
propose an operation such as split
learn which things would be split (a list of elements to remove)
and learn which things would be created (a list of the things resulting from the split)
filter the proposed edit to create a new edit, or completely discard the proposed edit.
apply the edit according to the { removals, adds }

In order to filter the edit, the list of added objects would have to reference the parent objects. For example, if I propose a split, and wish to accept every split except those referencing audio media, I'd want to filter the audio related elements from the proposed deletes, and the corresponding new elements from the proposed adds.
I think these separable operations are implicit in the proposal, but I'd like to call them out explicitly, because another possibility for implementation is that an operation such as split occurs invisibly, so in order to learn what's changed, one would need to do some kind of memoization before and after and attempt a diff.

@meshula This is the kind of use case I hope to cover with the EditEvent system. Essentially this might boil down to two exposed "layers":

Common Edit Commands - Simple tasks with a clean OOP feel "e.g. Slice this item at time X in it's parent time coordinates" - the commands above represent this layer.
Raw Edit Commands - the underlying methods that do the work of the common commands. These allow the user to filter/modify the event list to their liking, or generate their own event list from scratch to make additional procedures.

* It's worth pointing out that all commands from both layers would return a vector of events. The CEC just returns them already processed, so they can be introspected afterwards. The REC would have the ability to generate event lists for later processing. Which may lead to otio.algorithms.process(events) or class AbstractEdit(...): of some sort.
I've got an initial sketch of the design doc here:
https://github.com/mccartnm/OpenTimelineIO/blob/openedit_design/docs/design/editorial_design.md
I'm just waiting on the CLA response to start the PR but in the mean time I'll add some additional details about this.

I recently came across this and noticed there hasn't been any activity for awhile? It looks really interesting so as an experiment I tried implementing a couple of the edit commands to get a feel for the work involved: https://github.com/AcademySoftwareFoundation/OpenTimelineIO/pull/1518
Great images BTW, they were very helpful for visualizing the operations. The code was fairly tricky to get working correctly so I wrote the tests first and then iterated until everything passed. I haven't added error handling and there are probably corner cases I missed.
One thing that occurred to me while working on this is that handling transitions or any future subclass of Composable that returns true for overlapping(), is going to make these much more complicated. Especially trying to satisfy the constraints mentioned in the documentation:
https://opentimelineio.readthedocs.io/en/latest/tutorials/otio-timeline-structure.html#transitions


stm32h747cm7 compatible with stm32h745i-DISCO?

Hi!
I am pretty new to embedded development but have been doing Rust for some time. A colleague borrowed me a STM32H745I-DISCO which has both a Cortex M4 and Cortex M7. Another colleague looked into getting started with me and suggested that I look for a HAL crate. The reference sheet (link currently dead for me) has the title "STM32H745/755 and STM32H747/757 advanced Arm ® -based
32-bit MCUs" so I would hope that the STM32H747 is compatible with the STM32H745. Both have the combination of M4+M7 and I am happy only using the M7.
However, when I try to run an example in the debugger, it always hangs on let pwrcfg = pwr.freeze();. I also tried pwr.ldo().freeze() and pwr.smps().freeze() (without knowing in detail what it is about, some power domains right?). Below is the blinky example adapted:
//! Blinky example adapted (no macro use, semihosting and PI13 as output)

#![deny(warnings)]
#![no_main]
#![no_std]

use cortex_m_rt::entry;
use cortex_m_semihosting::hprintln;
use panic_semihosting as _;
use stm32h7xx_hal::{pac, prelude::*};

#[entry]
fn main() -> ! {
    let cp = cortex_m::Peripherals::take().unwrap();
    let dp = pac::Peripherals::take().unwrap();

    // Constrain and Freeze power
    hprintln!("Setup PWR...                  ").unwrap();
    let pwr = dp.PWR.constrain();
    let pwrcfg = pwr.freeze();

    // Constrain and Freeze clock
    hprintln!("Setup RCC...                  ").unwrap();
    let rcc = dp.RCC.constrain();
    let ccdr = rcc.sys_ck(100.MHz()).freeze(pwrcfg, &dp.SYSCFG);

    hprintln!("").unwrap();
    hprintln!("stm32h7xx-hal example - Blinky").unwrap();
    hprintln!("").unwrap();

    let gpioi = dp.GPIOI.split(ccdr.peripheral.GPIOI);

    // Configure PE1 as output.
    let mut led = gpioi.pi13.into_push_pull_output();

    // Get the delay provider.
    let mut delay = cp.SYST.delay(ccdr.clocks);

    loop {
        loop {
            led.set_high();
            delay.delay_ms(500_u16);

            led.set_low();
            delay.delay_ms(500_u16);
        }
    }
}

[dependencies]
cortex-m = "0.6.0"
cortex-m-rt = "0.6.10"
cortex-m-semihosting = "0.3.3"
panic-halt = "0.2.0"
panic-semihosting = "0.6.0"
stm32h7xx-hal = { version = "0.14.0", features = ["stm32h747cm7", "rt"] }

# this lets you use `cargo fix`!
[[bin]]
name = "stm-hello-world"
test = false
bench = false

[profile.release]
codegen-units = 1 # better optimizations
debug = true      # symbols are nice and they don't increase the size on Flash
lto = true        # better optimizations

I am running the example like this:
cargo build && gdb-multiarch -x openocd.gdb target/thumbv7em-none-eabi/debug/stm-hello-world
# A second terminal runs `openocd` in version `0.12`.

Output of openocd:
Open On-Chip Debugger 0.12.0+dev-00150-g91bd43134 (2023-04-17-15:03)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Info : STLINK V3J3M2 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.300400
Info : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected
Info : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for stm32h7x.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x0800cd3c msp: 0x2407f890
Info : Device: STM32H74x/75x
Info : flash size probed value 2048k
Info : STM32H7 flash has dual banks
Info : Bank (0) size is 1024 kb, base address is 0x08000000
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000298 msp: 0x24080000, semihosting
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Unable to match requested speed 4000 kHz, using 3300 kHz
Info : Padding image section 0 at 0x080100d0 with 16 bytes (bank write end alignment)
[stm32h7x.cpu0] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000298 msp: 0x24080000, semihosting
Info : halted: PC: 0x0800029a
Info : halted: PC: 0x0800047e
Setup PWR...

Output of gdb:
Reading symbols from target/thumbv7em-none-eabi/debug/stm-hello-world...
core::ptr::read_volatile (src=0x7aa88221)
    at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ptr/mod.rs:1492
1492    /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/ptr/mod.rs: No such file or directory.
Breakpoint 1 at 0x800cd88: file src/lib.rs, line 570.
Breakpoint 2 at 0x800e600: file src/lib.rs, line 560.
Breakpoint 3 at 0x800c0b4: file src/lib.rs, line 71.
Breakpoint 4 at 0x8000478: file src/main.rs, line 12.
semihosting is enabled
Loading section .vector_table, size 0x298 lma 0x8000000
Loading section .text, size 0xe37c lma 0x8000298
Loading section .rodata, size 0x1abc lma 0x800e614
Start address 0x08000298, load size 65744
Transfer rate: 42 KB/sec, 10957 bytes/write.
Note: automatically using hardware breakpoints for read-only addresses.
halted: PC: 0x0800029a
0x0800029a in cortex_m_rt::Reset () at src/lib.rs:497
497     pub unsafe extern "C" fn Reset() -> ! {
(gdb) continue
Continuing.

Breakpoint 4, main () at src/main.rs:12
12      #[entry]
(gdb) continue
Continuing.
halted: PC: 0x0800047e

Almost every example needs a handle to pwrcfg, so I don't really get around it. Of course, maybe something else is completely messed up as I don't understand much about embedded programming ^^ However if I just put a log with a counter into the loop and remove all HAL-related stuff, I see the prints coming through semihosting, so I think the memory setup and flashing/booting in general works.
Thus I wonder: Do I just need to fiddle a little more with it, or does it just not work because the chip I have is not compatible with the one I use?
Any help would be greatly appreciated!

Hi! You can use the examples and instructions for the STM32H747 with a STM32H745 development board. However you need to configure the power supply correctly to use these examples. In the User Manual for your development board there is a section "SMPS/LDO power supply" and this will help you learn about SMPS and LDO modes.
I suspect you should try:

Set the power supply configuration to SMPS with pwr.smps().freeze()
Turn your board off and on again

Hey @richardeoin , thank you for pointing me to the power supply docs. I re-read them but the issue turned out to be something else: When I researched the board, I found the info somewhere that it did not have hard float support, so I used the target thumbv7em-none-eabi, but apparently the right target for the board is thumbv7em-none-eabihf (including FPUs).
# .cargo/config.toml
[build]
target = "thumbv7em-none-eabihf"

Now it works. Thanks for you swift reply! :slightly_smiling_face:


Revert "Misc quickstart fixes"

Reverts newrelic/newrelic-quickstarts#941
This should return the titles / names to their previous state.

The change we need for a quick fix to gigamon should be covered in https://github.com/newrelic/newrelic-quickstarts/pull/959  but we can leave this open in case need to do a full revert


[BEAM-12338] Adds missing BigQuery DisplayData for FnAPI path (#14815)

This cherry-picks https://github.com/apache/beam/pull/14815 to the 2.30.0 release branch.

Adds missing BigQuery DisplayData for FnAPI path

Addresses reviewer comments

Removes unnecessary check.

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @ihji

LGTM. Thanks!


Failed to start the released application

Hello,
I have made my first rebar3 project. I can compile my project, I also can make a release package, but unfortunately I cannot start my application once the release package was created.
I also tried start my app with console_clean, and there I can see that error_handler module cannot able to load:
{"init terminating in do_boot",{'cannot load',error_handler,get_files}}
I verified how the erlang_handler module can be loaded if I start a "stand-alone" Erlang VM, and yes, there is an error report when I try load it, and the error says "Can't load module that resides in sticky dir". Btw, the module is loaded in the VM.
I tried collect all information what may need to analyze this issue. Please let me know if I did something wrong.
Output of make release of my application
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$ DEBUG=1 rebar3 release -d false
===> Consult config file "rebar.config"
===> Consult config file "rebar.lock"
===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/apps/aws/rebar.config"
===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/apps/aws/rebar.lock"
===> Verifying dependencies...
===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/rebar.config"
===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/rebar.lock"
===> sh info:
cwd: "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws"
cmd: git rev-parse -q HEAD
	===> 	opts: [{cd,"/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale"}]

	===> Port Cmd: git rev-parse -q HEAD
	Port Opts: [{cd,"/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale"},
				exit_status,
				{line,16384},
				use_stdio,stderr_to_stdout,hide]

	===> Comparing git ref a40ce9c007251f858d56b8ea4c8d8bbb4d1a1003 with a40ce9c007251f858d56b8ea4c8d8bbb4d1a1003
	===> sh info:
		cwd: "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws"
		cmd: git config --get remote.origin.url

	===> 	opts: [{cd,"/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale"}]

	===> Port Cmd: git config --get remote.origin.url
	Port Opts: [{cd,"/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale"},
				exit_status,
				{line,16384},
				use_stdio,stderr_to_stdout,hide]

	===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/rebar.config"
	===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/rebar.lock"
	===> sh info:
		cwd: "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws"
		cmd: git --git-dir='/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/.git' rev-parse --verify HEAD

	===> 	opts: [{use_stdout,false},
						   {debug_abort_on_error,
							   [76,111,99,107,105,110,103,32,111,102,32,103,105,
								116,32,100,101,112,101,110,100,101,110,99,121,32,
								102,97,105,108,101,100,32,105,110,32,
								"/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale"]}]

	===> Port Cmd: git --git-dir='/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/erlang_ale/.git' rev-parse --verify HEAD
	Port Opts: [exit_status,{line,16384},use_stdio,stderr_to_stdout,hide]

	===> Compiling aws
	===> erl_opts [debug_info,debug_info]
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/spi_handler_sup.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/spi_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mnesia_transformer.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mcp7940n.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mcp23x17.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/i2c_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/gpio_test.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/gpio_int_test.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/commonDB.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/bit_operations.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_zone_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_water_source_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_sup.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_profile_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_mnesia.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_main.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_interrupt_handler.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_heartbeat.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_common_lib.erl: []
	===> Files dependent on /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_app.erl: []
	===> Files to compile first: []
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/spi_handler_sup.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl"]
	===>      Compiled spi_handler_sup.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/spi_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl"]
	===>      Compiled spi_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mnesia_transformer.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled mnesia_transformer.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mcp7940n.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp7940n.hrl"]
	===>      Compiled mcp7940n.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/mcp23x17.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl"]
	===>      Compiled mcp23x17.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/i2c_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl"]
	===>      Compiled i2c_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/gpio_test.erl: []
	===>      Compiled gpio_test.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/gpio_int_test.erl: []
	===>      Compiled gpio_int_test.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/commonDB.erl:
	["/home/ethrbh/tools/erlang_otp_17_4/lib/erlang/lib/stdlib-2.3/include/ms_transform.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl"]
	===>      Compiled commonDB.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/bit_operations.erl: []
	===>      Compiled bit_operations.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_zone_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_zone_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_water_source_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_water_source_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_sup.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_sup.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_profile_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_profile_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_mnesia.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_mnesia.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_main.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_main.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_interrupt_handler.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_interrupt_handler.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_heartbeat.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_heartbeat.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_common_lib.erl:
	["/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/spi_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/i2c_handler.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/mcp23x17.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/raspberry_pi_b_plus_gpio.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/commonDB.hrl",
	 "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/include/aws_main.hrl"]
	===>      Compiled aws_common_lib.erl
	===> Dependencies of /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib/aws/src/aws_app.erl: []
	===>      Compiled aws_app.erl
	===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/apps/aws/src/aws.app.src"
	===> No app_vars_file defined.
	===> Consult config file "/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/apps/aws/src/aws.app.src"
	===> Starting relx build process ...
	===> Resolving OTP Applications from directories:
			  /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/lib
			  /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/apps
			  /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/lib
			  /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel
	===> Missing beam file elf_format <<"/home/ethrbh/tools/erlang_otp_17_4/lib/erlang/lib/hipe-3.11.2/ebin/elf_format.beam">>
	===> Resolved aws-0.1.0
	===> release successfully created!

Try start my application
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$ _build/default/rel/aws/bin/aws console_clean
Exec: /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/erlexec -boot /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws/bin/start_clean -boot_var ERTS_LIB_DIR /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/../lib -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws/releases/0.1.0/lib -config /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws/releases/0.1.0/sys.config -args_file /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws/releases/0.1.0/vm.args -- console_clean
Root: /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws
/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws/_build/default/rel/aws
{"init terminating in do_boot",{'cannot load',error_handler,get_files}}
	Crash dump was written to: erl_crash.dump
	init terminating in do_boot ()
	ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$

My application app.src file
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$ cat apps/aws/src/aws.app.src
{application, aws,
[{description, "An OTP application"}
,{vsn, "0.1.0"}
,{registered, []}
,{mod, {'aws_app', []}}
,{applications,
[kernel,
stdlib,
mnesia,
observer,
runtime_tools
]}
,{env,[]}
,{modules, []}
]}.
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$
Start the Erlang VM and check how I can load error_handler module
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/aws$ erl
Erlang/OTP 17 [erts-6.3] [source] [smp:2:2] [async-threads:10] [kernel-poll:false]
	Eshell V6.3  (abort with ^G)
	1> l(error_handler).
	{error,sticky_directory}

	=ERROR REPORT==== 5-Apr-2015::00:03:27 ===
	Can't load module that resides in sticky dir
	2>
	2> error_handler:module_info().
	[{exports,[{undefined_function,3},
			   {undefined_lambda,3},
			   {breakpoint,3},
			   {raise_undef_exception,3},
			   {stub_function,3},
			   {module_info,0},
			   {module_info,1}]},
	 {imports,[]},
	 {attributes,[{vsn,[35820137150885589935290571101415965057]}]},
	 {compile,[{options,[{outdir,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/../ebin"},
						 {i,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/../include"},
						 warnings_as_errors,debug_info]},
			   {version,"5.0.2"},
			   {time,{2014,12,9,20,57,1}},
			   {source,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/error_handler.erl"}]}]
	3>

thanks for your help,
/Robi

Can you share your rebar.config?

This is the kind of error I'd expect from trying to reload a module already there as a system lib, which does sound weird. The error you see in the VM where you 'can' load the module shows that you in fact can't, but it was already loaded by the VM.
Try calling error_handler:module_info(). from a fresh VM where you haven't attempted to load the file and it should be there, I believe.

hello Tristan and Fred,
Here is the rebar.config
pi@raspberrypi ~/ethrbh/aws $ cat rebar.config
{erl_opts, [debug_info]}.
{deps, [
{erlang_ale, {git, "https://github.com/esl/erlang_ale.git", master}}
]}.
	{relx, [{release, {'aws', "0.1.0"},
			 [aws,
			  sasl]},

			{sys_config, "./config/sys.config"},
			{vm_args, "./config/vm.args"},

			{dev_mode, true},
			{include_erts, false},

			{extended_start_script, true},
					{overlay, [
							%% Create databse folder.
							{mkdir, "dbase/Mnesia"},

							%% Create dev_patches folder. The patch files can be pushed here.
							{mkdir, "dev_patches"}
							]}
					]
	}.

	{profiles, [{prod, [{relx, [{dev_mode, false},
								{include_erts, true}
								]}]
				}]
	}.

Here is how error_handler looks when I started the Erlang VM without trying to load the module.
pi@raspberrypi ~/ethrbh/aws $ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [kernel-poll:false]
	Eshell V5.9.1  (abort with ^G)
	1> error_handler:module_info().
	[{exports,[{undefined_function,3},
			   {undefined_lambda,3},
			   {breakpoint,3},
			   {stub_function,3},
			   {module_info,0},
			   {module_info,1}]},
	 {imports,[]},
	 {attributes,[{vsn,[245168539877787478960814359092548882371]}]},
	 {compile,[{options,[{outdir,"/build/erlang-GB7BnF/erlang-15.b.1-dfsg/lib/kernel/src/../ebin"},
						 {i,"/build/erlang-GB7BnF/erlang-15.b.1-dfsg/lib/kernel/src/../include"},
						 debug_info]},
			   {version,"4.8.1"},
			   {time,{2014,4,26,17,25,13}},
			   {source,"/build/erlang-GB7BnF/erlang-15.b.1-dfsg/lib/kernel/src/error_handler.erl"}]}]
	2>

thanks for your help,
/Robi

I hope it isn't the cause, but is there a reason you are using R15B1 instead of a more recent version?

hello,
I have tried start the released application on Ubuntu, where Erlang/OTP 17.4 is installed on. Unfortunately the same error has been occurred what I can see on the Raspberry Pi, where an older Erlang/OTP is installed currently. Btw, there is no any special reason to use this Erlang on the Pi, this is found in the "apt-get" database. But right now, I'm install the 17.4 on it, but I think this will not help.
I really suppressed that no one has seen it before. I do not know, maybe I did something wrong and not rebar.
This is the console printout on Ubuntu when try start the application
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ _build/default/rel/aws/bin/aws -help
Usage: aws {start|start_boot |foreground|stop|restart|reboot|pid|ping|console|console_clean|console_boot |attach|remote_console|upgrade|escript|rpc|rpcterms}
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ _build/default/rel/aws/bin/aws console_clean
Exec: /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/erlexec -boot /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/bin/start_clean -boot_var ERTS_LIB_DIR /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/../lib -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib -config /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/sys.config -args_file /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/vm.args -- console_clean
Root: /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws
/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws
{"init terminating in do_boot",{'cannot load',error_handler,get_files}}
	Crash dump was written to: erl_crash.dump
	init terminating in do_boot ()
	ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ which erl
	/home/ethrbh/tools/erlang_otp_17_4/bin/erl
	ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ erl
	Erlang/OTP 17 [erts-6.3] [source] [smp:2:2] [async-threads:10] [kernel-poll:false]

	Eshell V6.3  (abort with ^G)
	1> error_handler:module_info().
	[{exports,[{undefined_function,3},
			   {undefined_lambda,3},
			   {breakpoint,3},
			   {raise_undef_exception,3},
			   {stub_function,3},
			   {module_info,0},
			   {module_info,1}]},
	 {imports,[]},
	 {attributes,[{vsn,[35820137150885589935290571101415965057]}]},
	 {compile,[{options,[{outdir,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/../ebin"},
						 {i,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/../include"},
						 warnings_as_errors,debug_info]},
			   {version,"5.0.2"},
			   {time,{2014,12,9,20,57,1}},
			   {source,"/net/isildur/ldisk/daily_build/17_prebuild_opu_o.2014-12-09_21/otp_src_17/lib/kernel/src/error_handler.erl"}]}]
	2>

Here is the app.src file
{application, aws,
[{description, "An OTP application"}
,{vsn, "0.1.0"}
,{registered, []}
,{mod, {'aws_app', []}}
,{applications,
[kernel,
stdlib,
mnesia,
observer,
runtime_tools
]}
,{env,[]}
,{modules, []}
]}.
Here is the rebar.config file
{erl_opts, [debug_info]}.
{deps, [
{erlang_ale, {git, "https://github.com/ethrbh/erlang_ale.git", master}}
]}.
	{relx, [{release, {'aws', "0.1.0"},
			 [aws,
			  sasl]},

			{sys_config, "./config/sys.config"},
			{vm_args, "./config/vm.args"},

			{dev_mode, true},
			{include_erts, false},

			{extended_start_script, true},
			{overlay, [
						%% Create databse folder.
						{mkdir, "dbase/Mnesia"},

						%% Create dev_patches folder. The patch files can be pushed here.
						{mkdir, "dev_patches"},

						{mkdir, "deps/erlang_ale"},
						{copy, "_build/default/lib/erlang_ale/ebin", "deps/erlang_ale/"},
						{copy, "_build/default/lib/erlang_ale/priv", "deps/erlang_ale/"}
						]}
			]
	}.

	{profiles, [{prod, [{relx, [{dev_mode, false},
								{include_erts, true}
								]}]
				}]
	}.

thanks for your help,
/Robi

The error you see likely comes from one of two things:

The VM cannot find the error_handler module when booting from the release
The VM tries to load a copy of error_handler after it has done so already.

Can you run code:clash(). on your target system and see if it finds anything? do this while specifying -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib as your release does. This will tell you if there are duplicate files and paths to be found.
Can you otherwise use the same exec line you see and add the -init_debug argument? This one will dump every step the VM takes when it starts up and tell us where exactly it happens to go wrong.
Something like:
/home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/erlexec -boot /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/bin/start_clean -boot_var ERTS_LIB_DIR /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/../lib -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib -config /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar/aws/_build/default/rel/aws/releases/0.1.0/sys.config -init_debug -args_file /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/vm.args

Hello Fred,
First I tried to do the first what you have mentioned, I mean try do code:clash(). when specify the ERL_LIBS environment variable. The path you gave me maybe wrong because there is NO lib folder found in /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/. The following files can be seen here:
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ ls /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/
aws.boot  aws.rel  aws.script  sys.config  vm.args
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ ls /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib
ls: cannot access /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib: No such file or directory
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$
After that I tied to do the 2nd. Here I have to set the BINDIR env variable, because it was not set by default. Once I was ready to set this var, I started the Erlang VM with init_debug, but I do not see more info. Did I something wrong?
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/erlexec -boot /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/bin/start_clean -boot_var ERTS_LIB_DIR /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/../lib -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib -config /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar/aws/_build/default/rel/aws/releases/0.1.0/sys.config -init_debug -args_file /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/vm.args
Environment variable BINDIR is not set
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ export BINDIR=/home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$
ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$ /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/bin/erlexec -boot /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/bin/start_clean -boot_var ERTS_LIB_DIR /home/ethrbh/tools/erlang_otp_17_4/lib/erlang/erts-6.3/../lib -env ERL_LIBS /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/lib -config /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar/aws/_build/default/rel/aws/releases/0.1.0/sys.config -init_debug -args_file /mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws/_build/default/rel/aws/releases/0.1.0/vm.args
{progress,preloaded}
{"init terminating in do_boot",{'cannot load',error_handler,get_files}}
	Crash dump was written to: erl_crash.dump
	init terminating in do_boot ()
	ethrbh@ethrbh-VirtualBox:/mnt/ethrbh/private/microchip-pic/aws_on_raspberry/raspberry_master_rebar3/aws$

thanks fro your help,
/Robi

Well I don't really know what the paths should be, I just copied them from what you pasted here.

You rebuilt the code and release when you moved to Ubuntu and OTP 17, right?

hello,
Well by default I'm developing on Ubuntu where Erlang/OTP 17.4 was installed already. And as I have pushed the log yesterday the released application does not start with the same reason what I can see on the Raspberry Pi where an older version of Erlang/OTP was installed.
The interested is that if I try compile and make release with erlang.mk instead of rebar3 with the same settings, everything works. The released application can be started both on Ubuntu and on the Pi.
thanks for your help,
/Robi

Is the relx.config used by erlang.mk the same as the one in your rebar.config.

hello,
Well because the structure is a little bit different I would say that those files are not the same, but the contents are the similar. What exactly the same is the overlay section what describes what to do as "post" preparation.
I have two branches in local one for erlang.mk and one for rebar, and if you are interested I can send the configuration of both for you.
thanks for your help.
/Robi

@ethrbh the configuration for them would be great. Even better would be the full repo to clone :)

Hi, this issue has been inactive for two weeks without new input or feedback. If nothing new has come, we will assume things were fixed or that you found a workaround, and we'll close this issue. Please let us know if there is still a problem, thanks.


Blur amount is dependent on resolution at launch

I just tried making a Windows build of a game that uses this effect, and the blur worked, but was distinctly less blurred than it appeared in the editor:

This happens in Unity 2018.1.2f1 and in Unity 2018.2.0b9. I'm running Windows 10.

Could it be related to your Quality Settings ?

OK, I've just confirmed that it doesn't have to do with Quality Settings, but in the process I accidentally found what it DOES have to do with -- the amount of blur in the editor seems to be relative to whatever the resolution of the "game" pane was at the START of playback. When I was making my test case, I did "build and run", then went back to the editor, hit play, popped out the "game" tab, and THEN resized it to fit with the running game. At that point, if I turn play mode off and on again, THEN it matches.
Hopefully that's a good diagnostic as to how to fix this, because unfortunately it isn't much of a workaround for me, because where I'm actually using this is in VR... I'm pretty sure I'm rendering at the same VR resolution in the editor as in the build, but the blur is distinctly different regardless, which I guess means to work around this I'd have to resize my editor window to fit whatever buffers the standalone VR build is using, but I'm not sure what that would be?
Also, I just confirmed that the same amount of blur looks very different at different resolutions (even when working around the bug), here's the same scene but at half the size (then scaled up 2x for comparison)

OK so I just realised this has turned into a discussion of two different issues, but I have a workaround for one of them at least.
I can do a pull request to fix the fact that changing window size while it's running distorts the blur. I haven't yet figured out what to change to make the blur look similar at different resolutions. Should I do the PR for the first issue or wait until I've addressed both?

You're welcome to do one PR per issue :)

OK, the "it looks weird if you change the window size while it's running" bug is fixed here: https://github.com/andydbc/unity-frosted-glass/pull/5

OK, I think I've now got the original issue of the thread also fixed in https://github.com/andydbc/unity-frosted-glass/pull/6


TreeView accordion issue

Text is shifting during expand and collapse. This should not be ideal behaviour. Please fix this.
Codesandbox link: https://codesandbox.io/s/material-demo-forked-jo2rb?file=/demo.tsx
To reproduce the issue ->
https://user-images.githubusercontent.com/38126155/104282791-933dcc00-54d5-11eb-937d-46f8240575ec.mov

It's not a bug, because it adds scrollbar padding to the side, the same goes for any page content, browser shrinks your content.

It's not a bug, because it adds scrollbar padding to the side, the same goes for any page content, browser shrinks your content.

Vertical scrollbar is fine. But, here text is shifting horizontally.

Vertical scrollbar is fine. But, here text is shifting horizontally.

@povilass, if this is not a bug, then do you know how remove this effect which is by default in the component?

@povilass, if this is not a bug, then do you know how remove this effect which is by default in the component?

Because there is not enough space to display your text so vertical scroll pushes content and text horizontal recalculates width. You can not change it because of its browser functionality.

Because there is not enough space to display your text so vertical scroll pushes content and text horizontal recalculates width. You can not change it because of its browser functionality.

It's the same with the big text code if you have a scroll it pushes all content.

It's the same with the big text code if you have a scroll it pushes all content.

I'm not able to reproduce the issue for this text. PFA screen recording.
https://user-images.githubusercontent.com/38126155/104296116-46fb8780-54e7-11eb-9471-7f96f575ac9e.mov

I'm not able to reproduce the issue for this text. PFA screen recording.
https://user-images.githubusercontent.com/38126155/104296116-46fb8780-54e7-11eb-9471-7f96f575ac9e.mov

Because you need just enough space to display all content without scroll and resize the horizontal window border to display scroll again.

Because you need just enough space to display all content without scroll and resize the horizontal window border to display scroll again.

@povilass, you didn't understand the issue and just diverted the discussion.
You are changing browsers width to reproduce the issue while I asked you to expand and collapse the accordion.
Can you give me example of some other framework accordion? This issue is only with material ui.

@povilass, you didn't understand the issue and just diverted the discussion.
You are changing browsers width to reproduce the issue while I asked you to expand and collapse the accordion.
Can you give me example of some other framework accordion? This issue is only with material ui.

@ayupur It's the same problem when you expand the accordion scrollbar appears when you collapse scrollbar is gonna even your video shows that. What's the difference between resizing a window and expanding something result is the same you have a scroll because the content does not fit window height.

@ayupur It's the same problem when you expand the accordion scrollbar appears when you collapse scrollbar is gonna even your video shows that. What's the difference between resizing a window and expanding something result is the same you have a scroll because the content does not fit window height.

Are you able to reproduce the issue after changing windows height?
Accordion expansion and collapse changes windows height and not width.

Are you able to reproduce the issue after changing windows height?
Accordion expansion and collapse changes windows height and not width.

Ok not Material Ui framework but plain css, html and js https://www.w3schools.com/code/tryit.asp?filename=GML5H1I2YP7C

Ok not Material Ui framework but plain css, html and js https://www.w3schools.com/code/tryit.asp?filename=GML5H1I2YP7C

https://www.w3schools.com/code/tryit.asp?filename=GML5H1I2YP7C is working fine. PFA screen recording.
While in case of material ui, it is working differently. When expand the accordion, "for" is shifting from right:

to left:

Why is material ui working differently?
https://user-images.githubusercontent.com/38126155/104308185-49b1a900-54f6-11eb-9ba0-604539a6265f.mov

https://www.w3schools.com/code/tryit.asp?filename=GML5H1I2YP7C is working fine. PFA screen recording.
While in case of material ui, it is working differently. When expand the accordion, "for" is shifting from right:

to left:

Why is material ui working differently?
https://user-images.githubusercontent.com/38126155/104308185-49b1a900-54f6-11eb-9ba0-604539a6265f.mov

As I said you must start this example with no scroll and expand 1 item which adds scroll. What you showed after expand/collapse you still got scroll before and after because of screen resolution difference that's why I am added second example https://www.w3schools.com/code/tryit.asp?filename=GML5MUU7DU75

As I said you must start this example with no scroll and expand 1 item which adds scroll. What you showed after expand/collapse you still got scroll before and after because of screen resolution difference that's why I am added second example https://www.w3schools.com/code/tryit.asp?filename=GML5MUU7DU75

Got it. thanks

Got it. thanks


Move admin_url_namespace and base_url_path to base ViewSet class

Part of #10740.
I'm not sure whether we should allow passing model via the constructor. ModelViewSet never supported this. SnippetViewSet supported this when SnippetViewSetGroup was added in #10330, but I could've opted for a different approach where a SnippetViewSet subclass is dynamically created with the model attribute set.
The first commit moves admin_url_namespace and base_url_path to base ViewSet, and allowing ModelViewSet to accept model via the constructor in the process. The second commit reverts the changes to ModelViewSet so that model has to be specified on the class, and also removes this ability from SnippetViewSet to make it more consistent.
If we want to allow passing model via the constructor, then I can just revert the second commit.
Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[x] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?

Not sure if I should add tests, would be nice to have some or at least for the ModelViewSet, but we currently don't have any ModelViewSet in the test app right now. I'll definitely add it once we start adding more stuff as part of #10740, though. Edit: tests are in #10767.

It's a bit tricky to decide on an ideal way forward here, that balances the expectations of:

how an API for viewsets ought to work in a general Django setting that's not coupled to Wagtail or its hooks mechanism - it would be natural to be able to write something like path("foo/", include(foo_viewset.urls, namespace="foo")) in the project's urlconf, in which case the viewset doesn't get to specify its own URL prefix at all;
the Wagtail admin, where apps register themselves into the URL structure and so it makes sense for viewsets to specify their own prefixes;
the SnippetViewSet scenario, where most of the time you don't really care about URL prefixes or namespaces and want something to automate that decision for you.

1 and 2 can probably be reconciled by considering the viewset's own choice of URL prefix as a preferred / default choice, that the thing doing the final URL registration can decide to honour or not. I'm less sure about who should have control over the namespace - that subject takes you down the rabbit-hole of application namespaces versus instance namespaces... I'm pretty clear that the viewset needs to at least know its own application namespace, if not specify it itself, so that it can reverse its own URLs internally. Beyond that, the implications of setting an instance namespace that doesn't match the application namespace seem fairly esoteric, and I'm not sure if that's an argument in favour of "let people do those esoteric things when writing their own urlconfs" or "rigorously enforce matching namespaces so that developers don't screw up".
I'm also unsure whether being able to dynamically construct the prefix/namespace based on other attributes such as model (to accommodate number 3) is enough of a "core" feature to belong in the base ViewSet class, or whether it's more like an extra layer of sugar around it. I'm pretty sure this could be implemented where needed without any explicit support for it in the base ViewSet class - either with some metaclass logic ("does this new ModelViewSet subclass define an explicit url_prefix? If not, generate one from its model property") or carefully controlling the order things happen in __init__. Need to ponder this some more...
Just about the only thing I am sure of is that whatever methods/attributes we end up with here, they shouldn't contain the word "admin". I suspect this may be a carry-over from ModelAdmin ("the URL at which this model is administered") rather than referring to the Wagtail admin app, but whichever one it is, the base ViewSet class shouldn't be coupled to either of those concepts.

With apologies for the continued rubber-ducking, I think I'm arriving at a plan I'm happy with, and it's actually somewhat closer to your original approach...

All properties of a ViewSet can be set as class-level attributes, properties (including cached_property), or passed as kwargs to the constructor - in the latter case, we'll write them to self.__dict__ (inspired by how cached_property works) so that passing something like url_prefix as a kwarg still overrides the class-level default even if the class-level one is implemented as a property.
In the hypothetical future case that the viewset is being registered into the project's urlconf by a human editing urls.py, rather than through Wagtail's register_viewset mechanism, it's acceptable for them to ignore whatever the viewset thinks its URL prefix (and instance namespace) should be, and put whatever they like as the path. However, viewsets should always provide a url_prefix property as a suggested prefix (and Wagtail's register_viewset will respect it). They'll also provide a url_namespace property which is used internally as the application namespace (e.g. by get_url_name).
The base ViewSet will define both of these as a cached_property that returns self.name - as such, if a ViewSet subclass doesn't override these and fails to define a name at either the class or instance level, it'll blow up. However, the pattern of inferring a name from some other property (such as model) is one that's potentially useful beyond ModelViewSet, so we will no longer make name a required property of the base ViewSet. ViewSet subclasses that want to make use of this pattern can define their own name property with their own logic, or override url_prefix and url_namespace individually. Sub-sub-classes and instances of that viewset can in turn set an explicit url_prefix or url_namespace attribute to override that logic.
ModelViewSet will incorporate logic for constructing a name from the model name (as a default if the subclass / instance doesn't set one explicitly). I figure SnippetViewSet is probably somewhat tied to the names admin_url_namespace, base_url_path, get_admin_url_namespace and get_admin_base_path now for backwards compatibility - if so, it can define url_prefix and url_namespace properties appropriately to accommodate these.

Since these design decisions are rooted in a "big picture" future vision for viewsets that I haven't properly articulated yet (but really should do so sooner rather than later!), I propose that I make these changes and open a new PR that's a drop-in replacement for this one, for you to review - hopefully that doesn't end up too contentious, and your follow-up PRs can then be rebased on top of that without too much hassle.

Thanks @gasman, that all sounds good to me!
I'm very much in favour of the first point, would be nice if we eventually use that mechanism and drop all get_{foo}() methods that only take self as the parameter in SnippetViewSet in favour of encouraging users to just use properties if the value needs to be computed.
I was too focused on making SnippetViewSet as close to ModelAdmin as possible to make the conversion less of a hassle, hence those get_{foo} methods. I think that might've been a mistake, but oh well...

Closing in favour of #10782


Update it_IT.lang

Why are there + symbols in front of the 3 lines near
"nei.options.tools.dump.itempanel.mode.3"


Tag a release

:)

Fixed in https://github.com/silverstripe/silverstripe-routewhitelist/tree/v1.0.0

Whoop


Add support for a custom cache policy for ordered cache

what

To add support for a custom cache policy for ordered cache

/test all

This looks ready to go.


Error with expression of a curve variable.

A user reported a bug creating a simple expression with a curve variable. Here are the steps required to reproduce the error. The bug was reported by SelinaJane Spencer<EMAIL_ADDRESS>in an email to visitusers on 2/13/2019 at 2:08 AM. 1) Open multi_rect2d.silo2) Create a curve plot of wave3) Create an expression waveSquared that is wave*wave of type Curve4) Create a curve plot of waveSquared VisIt will give the following error: Curve: ()viewer: The 'waveSquared' expression failed because An internal error occurred when calculating an expression. Please contact a VisIt developer.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 3290
Status: Pending
Project: VisIt
Tracker: Bug
Priority: High
Subject: Error with expression of a curve variable.
Assigned to: Edward Rusu
Category: -
Target version: 3.0
Author: Eric Brugger
Start: 02/13/2019
Due date:
% Done: 0%
Estimated time:
Created: 02/13/2019 03:30 pm
Updated: 02/26/2019 12:19 pm
Likelihood: 3 - Occasional
Severity: 4 - Crash / Wrong Results
Found in version: 2.13.2
Impact:
Expected Use:
OS: All
Support Group: Any
Description:
A user reported a bug creating a simple expression with a curve variable. Here are the steps required to reproduce the error. The bug was reported by SelinaJane Spencer<EMAIL_ADDRESS>in an email to visitusers on 2/13/2019 at 2:08 AM. 1) Open multi_rect2d.silo2) Create a curve plot of wave3) Create an expression waveSquared that is wave*wave of type Curve4) Create a curve plot of waveSquared VisIt will give the following error: Curve: ()viewer: The 'waveSquared' expression failed because An internal error occurred when calculating an expression. Please contact a VisIt developer.
Comments:
I tried Eric's steps and added -dump to the command line.The input vtk file to avtBinaryMathExpression shows the SCALAR var name to be ./wave instead of just wave.I believe the culprit is the Silo reader. Breaks with any arithmetic. If I define waveSquared to be just wave, then it plots a flat line (all zeros). I think I may have tracked down the error. In avtSiloFileFormat, GetMeshHelper populates a string called directory_mesh. In this case, the value of that string is "./wave". This string is passed to GetCurve, which then looks for a curve called "./wave" instead of just "wave". Initial tests show that passing the variable name "wave" solves the user-specified issue. Will continue exploring and update early next week. Expanded the scope of this error to all instances of curve variables from all the _multi silo files in the silo_pdb dataset. Whenever you attempt to make an expression involving arithmetic with a curve variable, the same error occurs. Looks like either the expression handler or the arithmetic handler are failing to pick up on the fact that variables are named with "./" at the beginning.Interestingly, mesh variables do not have this problem. For example, from multi_rect2d, you can make an expression involving arithmetic with a mesh variable, and VisIt handles this just fine. Ok, so a) I confirm all the funky behavior you are seeing when dealing with curves from multi_xxx.silo files and b) I tried similar operations when dealing with curves from curve_test_data file and those curves work fine.Lets set up some pair programming time. In PR

Merged


Update simple add readme

Existing Sample Changes
Description
Updated to match the base vector add sample more closely. Added reference to base vector add sample. Added reference in base vector add readme to the simple add sample. Both of these are basic getting started samples.
Fixes Issue#
External Dependencies
N/A
Type of change
Please delete options that are not relevant. Add a 'X' to the one that is applicable.

[x] Implement fixes for ONSAM Jiras

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] VSCode

Adding @jimmytwei for notices.


Give SlotKind a property to indicate whether it is a presentation

SlotKinds represent types of things on a schedule, some of which have presentations attached as content, some of which do not. In the pinax-symposion-project the schedule grid only renders a presentation if the slot.kind.label is 'talk' or 'tutorial',  which leads to issues like https://github.com/pydata/conf_site/issues/68
Back when I was working on SciPy 2014, we forked symposion and changed SlotKind to add presentation = models.BooleanField(default=True, help_text="Whether or not this slot is a presentation")
so that we could change the template conditional to {% if slot.kind.presentation %}
from {% if slot.kind.label == "talk" or slot.kind.label == "tutorial" %} (see _grid.html L16)

:+1: lunch and coffee breaks are important schedule slot! It's modification should be merged.


Python 3.13 support

This PR adds support for Python 3.13 by updating dependencies where needed and appending it as a test target.

I thought we can skip the 13 version as fatal :)

Great! thanks


What is the real meaning of -service option?

As kitex -help shows, -service  specify the service name to generate server side codes. But after I followed the tutorial step by step, -service doesn't work. The generated service name is always the same as service name defined in thrift IDL file.
I debug kitex in local, the program arguments:

The cmd variable built in kitex main function:

It seems like -service option doesn't take effect.

what is 'generated service name' you mean?
the service name that -service provides is not equal to RPC service name, you can understand it as an Application name.
So -service has two effects:

Identify to generate code of server-side
Used in the shell scripts


ADC raw values calibration

Based on #550
Related issue #326
This PR implements ADC calibration based on ESP IDF. The following schemes supported:

Basic calibration which sets initial (zero) bias
Line fitting which corrects gain (also includes basic)
Curve fitting which corrects non-linearity (also inclues basic and line fitting)

First two schemes uses factory values stored in efuse fields when it available.
As a fallback a runtime calibration is made by connecting ADC input to ground or reference voltage internally.
Third scheme uses pre-defined polynomial coefficients derived from IDF.
Also applied useful optimizations for runtime calculations and to coefficients representation to reduce operations and avoid division.
NOTE: Currently calibration supported only for riscv chips because I haven't xtensa-based boards for testing, but it will be relatively easy add support for such chips later.
Must

[x] The code compiles without errors or warnings.
[x] All examples work.
[x] cargo fmt was run.
[x] Your changes were added to the CHANGELOG.md in the proper section.
[x] You updated existing examples or added examples (if applicable).
[ ] Added examples are checked in CI

Nice to have

[x] You add a description of your work to this PR.
[x] You added proper docs for your newly added features and code.

@katyo Thank you very much for working on this, is it something I can help you at this stage?

@JurajSadel,
Currently I search a way to avoid breaking changes for an API.
We need find a proper way to select calibration/fitting algorithm when enabling ADC pin.

I know my opinion here isn't very important, but I'm pretty happy with where this is heading. From a pure design standpoint, I would be happier if the algorithms weren't tied to the efuses, but having calibration coupled to the ADCs here isn't bad either.
I am slightly worried about the hardcoded constants in curve fitting - how confident can we be that a single set of constants work well across different production runs?

@bugadani
I share your concerns about hardcoded curve coefficients which derived from ESP IDF source. I'm far away from chip manufacturing but curve-based error correction gives me best precision at the moment particularly near to top edge of a range. Seems coefficients represents non-linearity of attenuator and convertor itself.

Now this PR uses efuse fields access from #567.

@JurajSadel Could you test it again?
I fixed calibration data version detection.
Also I added as a fallback the reference voltage calibration for linear scheme. But tha last one is not so good because actual reference voltage may varies in range 1.0..=1.2V. This value currently is not present in efuse.

I've confirmed that the examples build and run successfully on the C2, C3, and C6. The values for the C2 and C3 looked correct, however for me the C3 was reporting closer to 2.8V. Other than that seems good, though.

I just tried it and it works fine for me on C2 and C3. However C6 crashes in development mode with this
!! A panic occured in 'C:\projects\review\katyo\esp-hal\esp-hal-common\src\analog\adc\cal_line.rs', at line 73, column 15

PanicInfo {
    payload: Any { .. },
    message: Some(
        attempt to divide by zero,
    ),
    location: Location {
        file: "C:\\projects\\review\\katyo\\esp-hal\\esp-hal-common\\src\\analog\\adc\\cal_line.rs",
        line: 73,
        col: 15,
    },
    can_unwind: true,
}

And in release-mode it certainly shows weird values because of this

@bjoernQ Looks strange.
Seems code is zero here:
let gain = ((mv as u32 * GAIN_SCALE * 2 / code as u32 + 1) * 4096 / atten.ref_mv() as u32 + 1) / 2;

May be calibration data is missing (or version check failed)
or (a fallback way) runtime calibration failed.

Maybe adding some debug or trace logs might help identifying what is going on here. We already have the log dependency in esp-hal-common

I'm getting this panic from embassy when I've changed my patch in Cargo.toml to test this out.
The only change I did was changing from the latest commit of this PR (https://github.com/esp-rs/esp-hal/pull/550#issuecomment-1587102788)  to the latest commit in this branch
!! A panic occured in '/home/elpiel/.cargo/registry/src/github.com-1ecc6299db9ec823/embassy-executor-0.2.0/src/raw/mod.rs', at line 355, column 30

PanicInfo {
    payload: Any { .. },
    message: Some(
        unwrap of `driver::allocate_alarm()` failed: NoneError,
    ),
    location: Location {
        file: "/home/elpiel/.cargo/registry/src/github.com-1ecc6299db9ec823/embassy-executor-0.2.0/src/raw/mod.rs",
        line: 355,
        col: 30,
    },
    can_unwind: true,
}

@elpiel Could you try adc_cal example?

Example runs successfully for esp32-c3 adc_cal but I still get a panic in embassy.
As for the values, they still look unstable:
PIN3 ADC reading = 1102 (1050 mV)
PIN3 ADC reading = 260 (247 mV)
PIN3 ADC reading = 482 (459 mV)
PIN3 ADC reading = 374 (356 mV)
PIN3 ADC reading = 345 (328 mV)
PIN3 ADC reading = 472 (449 mV)
PIN3 ADC reading = 209 (199 mV)
PIN3 ADC reading = 567 (540 mV)
PIN3 ADC reading = 198 (188 mV)
PIN3 ADC reading = 585 (557 mV)
PIN3 ADC reading = 139 (132 mV)
PIN3 ADC reading = 644 (613 mV)
PIN3 ADC reading = 108 (102 mV)
PIN3 ADC reading = 635 (605 mV)
PIN3 ADC reading = 201 (191 mV)
PIN3 ADC reading = 555 (528 mV)
PIN3 ADC reading = 269 (256 mV)
PIN3 ADC reading = 485 (462 mV)
PIN3 ADC reading = 366 (348 mV)
PIN3 ADC reading = 342 (325 mV)
PIN3 ADC reading = 473 (450 mV)
PIN3 ADC reading = 212 (202 mV)
PIN3 ADC reading = 563 (536 mV)
PIN3 ADC reading = 211 (201 mV)
PIN3 ADC reading = 502 (478 mV)
PIN3 ADC reading = 173 (164 mV)
PIN3 ADC reading = 567 (540 mV)
PIN3 ADC reading = 101 (96 mV)
PIN3 ADC reading = 531 (505 mV)
PIN3 ADC reading = 201 (191 mV)

I'm measuring a value of a battery between 1.5 and 2.1V (with the voltage divider) and these values seem not accurate enough for Attenuation 11 db.

@elpiel Hmm, sounds strange.
Are you sure the configuration is correct? Is the correct GPIO is used? Have you try test with ESP IDF?
Looks like hardware issues.
I tested this PR with different esp32c3-based boards using different GPIOs, analog sources and attenuation configs. This works fine for me.

I've tested this adc_cal on 2 different board (Espressif Rust dev board & Olimex dev board) yesterday and I got the same results.
When connecting the pin to ground I do get a very low values between 4-6.
Most readings are below a 1000 on the pin.

Have you try test with ESP IDF?
No, I have not.

Which features you use embassy-time-systick or embassy-time-timg0?
My Cargo.toml has:

default = ["embassy-time-timg0"]

embassy-time-timg0 = [
    "hal/embassy-time-timg0",
    "embassy-time/tick-hz-1_000_000",
]

@elpiel Possibly calibration is not a root of problem in your case.
Could you test without calibration? (adc example or adc_cal with () for AdcCal to bypass calibration)

I see similarly unstable results on an ESP32-S3. ADC values are all over the place, averaging roughly about the correct value. I'm not sure if this is an issue with the 100kOhm+ source impedance combined with the undocumented input impedance of the ADC, or if it's noise coupled in from USB, a combination of the two or some third problem.

@elpiel The fact is that ADC input impedance on Espressif SoCs relatively low compared to many other MCUs (KOhms not MOhms).
I recommend you try use 10x-100x lower resistor values and add 10-100nF capacitor to input (after divider). You may need experimenting with it to get stable results.

Testing on the Olimex board with soldered jumpers for the battery meassurement on GPIO 3 indeed shows good results!
I need to double check the values with my multimeter and figure out a way to not charge the battery via USB when measuring it.
https://raw.githubusercontent.com/OLIMEX/ESP32-C3-DevKit-Lipo/main/HARDWARE/ESP32-C3-DevKit-Lipo_Rev_A/ESP32-C3-DevKit-Lipo_Rev_A.pdf
On the embassy project I still get a panic but I will check whether this is because of unhappy embassy crate versions

I just want to say that I'm writing on implementing this PR for the S3, just so others don't waste their time on that :) I'll post the results once this one gets merged.

After thinking some more, I don't think the consts are that big of a deal, we can always reference the ESP-IDF code to actually understand what's going on.

Honestly, I think the if major == 0 { 1 } pattern deserves some sort of explanation (be that a comment or a named constant) in the code as it looks like a mistake.

@jessebraham Because esp-idf still does not support calibration for H2 so I don't know how we can add support for it just now.
(see efuse/esp32h2/esp_efuse_rtc_calib.c#L13)


HHH-18172 Fix embeddable inheritance for types extending @MappedSuperclass

https://hibernate.atlassian.net/browse/HHH-18172

don't believe the JPA spec contemplates that an @Embeddable type might inherit a @MappedSuperclass

@gavinking Support for this predates the embeddable inheritance changes (we also had tests for it for a very long time) so I thought it would be nice if it kept working as expected.
@beikov I also applied the annotated class types validation as we discussed, this should be a clear error instead of the NPE that user reported.


Docs.MS Release Updates for azure_template

Update docs metadata and targeting for release of azure_template

Docs Build status updates of commit e0263a6:
:clock10: Full build: the average full build time is 167 min(s) 10 sec(s), this is based on the last 516 build(s) for this repository.

Docs Build status updates of commit e0263a6:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/template-readme-pre.md
:warning:Warning
View (azure-python) View (azure-python-preview)
Details

docs-ref-services/keyvault-administration-readme-pre.md
:warning:Warning
View (azure-python) View (azure-python-preview)
Details

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.continue_as_new.yml
:warning:Warning
View (azure-python-preview)
Details

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.call_http.yml
:warning:Warning
View (azure-python-preview)
Details

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.task_all.yml
:warning:Warning
View (azure-python-preview)
Details

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.new_uuid.yml
:warning:Warning
View (azure-python-preview)
Details

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.task_any.yml
:warning:Warning
View (azure-python-preview)
Details

ci-configs/packages-preview.json
:white_check_mark:Succeeded

docs-ref-services/template-readme-pre.md

Line 13: [Warning-h1-not-first] Markdown content is not allowed before {0}.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before {0}.
Line 25: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 25: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 29: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 29: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 33: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 33: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 37: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 37: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 41: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 41: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 45: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.
Line 45: [Warning-multiple-h1s] Multiple H1s({0}) are not allowed. You can only have one top-level heading.

docs-ref-services/keyvault-administration-readme-pre.md

Line 238: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/vs-azure-tools-storage-manage-with-storage-explorer?tabs=windows#generate-a-shared-access-signature-in-storage-explorer' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 238: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/vs-azure-tools-storage-manage-with-storage-explorer?tabs=windows#generate-a-shared-access-signature-in-storage-explorer' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 268: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/vs-azure-tools-storage-manage-with-storage-explorer?tabs=windows#generate-a-shared-access-signature-in-storage-explorer' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 268: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/vs-azure-tools-storage-manage-with-storage-explorer?tabs=windows#generate-a-shared-access-signature-in-storage-explorer' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.continue_as_new.yml

[Warning-DuplicateUids] Uid(azure.durable_functions.tasks.continue_as_new) has already been defined in preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.yml.

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.call_http.yml

[Warning-DuplicateUids] Uid(azure.durable_functions.tasks.call_http) has already been defined in preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.yml.

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.task_all.yml

[Warning-DuplicateUids] Uid(azure.durable_functions.tasks.task_all) has already been defined in preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.yml.

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.new_uuid.yml

[Warning-DuplicateUids] Uid(azure.durable_functions.tasks.new_uuid) has already been defined in preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.yml.

preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.task_any.yml

[Warning-DuplicateUids] Uid(azure.durable_functions.tasks.task_any) has already been defined in preview/docs-ref-autogen/azure-functions-durable/azure.durable_functions.tasks.yml.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel