best guess is that release mode optimizations collapsed these two
functions into one, because in release mode the assertion that would
fail was:
assert!(listeners.add(other_dummy_listener));
which would mean that `listeners.add()` thought it was trying to add
a duplicate listener function.
adding dummy println's is a simple way to ensure that the compiler
won't try to collapse these thinking that they are the same function.
ultimately, cargo workspaces are kind of weird. you can do things like
`cargo run` from the top-level cargo.toml file and run an individual
sub-module via `--bin`, or you can go to that sub-module's directory
where it's own cargo.toml is, and `cargo run` directly from there.
the current working directory will be different in each case, and this
difference can be very annoying when you want to do seemingly-logical
things like organize sub-module "asset" files (e.g. images, and other
types of data files that aren't code) within that sub-module's
directory. in this case, how do you write code in that sub-module that
can load those asset files in a way that will work in BOTH of the
aforementioned scenarios for `cargo run`?
you can't really! some people use the `CARGO_MANIFEST_DIR` environment
variable that cargo sets when running any given cargo module, but this
is only a valid method for obtaining the module's root directory when
running from a cargo command ... which you won't be doing when running
within a debugger! likely you or your IDE invoked the debugger process
against the already built executable directly, so `CARGO_MANIFEST_DIR`
will not be set and you're back to square one!
super annoying!
as such, i am now giving up and am just doing what it seems like most
other cargo projects that utilize workspaces do ... place all the
assets for all sub-modules together in the same directory, relative
to the workspace root.
why go with this approach?
because it works under the most common scenarios (but NOT all!):
- running via `cargo run --bin` from the workspace root
- debugging via gdb/lldb etc using the workspace root as the cwd
these seem to be the most common ways to do each type of task from
any rust-equipped editor/IDE that i've seen so far.
previously, there were a ton of places that were allocating new Path
instances via `Path::new` for the purpose of creating a path to be
passed into a function as a Path argument
this has now been simplified everywhere by updating all functions
and methods that previously took Path arguments to instead take
AsRef<Path> arguments, allowing much more flexibility in the types
of path arguments passed in
dev/test builds that heavily use deflate (e.g. anything with png files)
perform *incredibly* slow with 1.0.28. also tried switching the backend
to zlib which didn't really speed things up too much.
i hate updating dependencies. *sigh*
i suppose there is not much benefit to using this versus equivalent
functionality on SystemResources (for example). however the dimensions
returned by these new methods do respect whatever display scaling is
being used by ImGui. and these are technically more convenient to use
in whatever place you're building up a UI in. meh.
as well as support for directly instantiating a BitmapAtlas from
such a descriptor.
saving a BitmapAtlas to a descriptor file directly is not added (yet?)
as my gut feeling is that these files would probably be hand-written?
saving from a BitmapAtlas directly would (in a simple/naive impl)
always result in a long-ish list of "tiles" anyway, since grids are
turned into tiles. this further reinforces me feeling that you'd either
write these files by hand, or at the very least, just construct a
descriptor instance in code somehow and save that
plus these are easier to type.
i do not anticipate needing structured color types for any other
type of components (e.g. i don't see a need for an ARGBu16x4, etc).
so i am fine with just having `ARGB` being associated with four u8's
with no real indication of this in the type name itself.
our target is IndexedBitmap's will use PixelType=u8 and
RgbaBitmap's will use PixelType=ARGBu8x4
thus, restricting the Pixel trait to primitive unsigned numerics won't
work anymore, but we do still need to support basic stuff like
equality testing and copy/clone support for our generic bitmap
operations
Gered