Refining Zephyr's Device Driver Model - Take II

(This issue is a replacement of #6293 )
A deep revise and upgrade of the device driver model
Throughout its short existence, Zephyr has seen its kernel reworked, stabilized and made reliable with sound and concise APIs and objects. All still being designed within the scope of running on tiny targets, such as arduino_zero with 32k of RAM or bbc_microbit with its 16k of RAM for instance, but also providing enhanced features for fully fledged industrial boards with much more memory and CPU power.
Next to the kernel, the device driver ecosystem has experienced somewhat a different development.
The device driver APIs have been improved to cover most of identified generic use-cases, and are still being reworked, sometime deeply refined to adress new requirements. Surprisingly however, the core of this ecosystem: the device driver model, has gained little to no improvement at all. It does not make it void of issues, far from it actually. In fact, some of the issues, known from the beginning  sometime, have been a drawback for implementing advanced features. Worse, as time goes on with the device driver ecosystem growing everyday, these issues will tend to be more and more tedious to get fixed. It is not to say there are no attempts to fix some the known issues, there are. But I believe they are not generic nor concise enough, though some are definitely interesting test beds.
Hence a list of the known issues and a proposal to address these.
Identified issues

Power Management is broken:
The lack of dependency tree support among devices makes it unusable. The burden of managing client devices and their parents within the power management context is pushed to the user which has been proven to be tedious, unreliable and thus made the PM subsystem nearly - if not fully - unused at all. Due to this most device drivers do not implement the PM API.

No support for cancelling on-going device API call:
In PM context or else, it might be relevant to cancel an on-going call on a device. Stopping and/or re-initializing a user thread would require such feature for instance. A caller could also decide to cancel its own calls. See #24511

No support for a timeout on each and every device API call:
Being generic to all device driver API such feature is one of the important missing. It may happen, either because the system is overloaded or because the hw is not responding, that a call will never come to a closure. Thus locking up the device on the call as well as the caller waiting for something to happen. This prevents also the caller having the possibility to mitigate any error in case the call would be unsuccessful. See #24511

No error storage when device initialization fails or gets into hw fault:
In case of initialization failure, the device will just be inaccessible, and there would be no way to know what happened. In case of a run-time, non-blocking, hardware fault, only the user will get an error back. Localized logging cannot be sufficient in this case. See #23589

No possibility to recover a device in case of initialization failure or hw fault:
Such failure could be due to boot timing, temporary hw issue, cosmic rays, gremlins, etc... Currently, a device failing the initialization step will not be usable at all afterwards. One can decide to reboot, but if the boot sequence is the culprit, the device will never be recoverable. It should be possible to call init again. Either to fix such booting issue but also at run-time where recovering a device may require to reinitialize it (after a locking hw fault for instance). See #23589

Device instantiation:
A device is uniquely allocated in device driver code through DEVICE_DEFINE() or DEVICE_AND_API_INIT() or DEVICE_INIT(). It requires as many calls of one of these macros as there are devices then. The link with DTS is non-existent unless the developer makes it happen using DTS generated config options, which is the current process.

Each device is not constant (same for their config part):
It was meant to be constant, but due to a hack on device's API setting (in case of init failure it is set to NULL at runtime) it is never constant, thus ends into RAM instead of staying into the ROM. See #24873

The device name:
It is only used to get the device bindings at runtime and thus reduce boot performances and takes ROM/RAM for nothing.

Nameless device created by SYS_INIT():
It does not make any use of the name, API, PM API and thus use too much memory for nothing. See #23407

device_pm structure:
An obvious case of under optimized structure

Device's variable name:
Is not generated from the device name (you cannot un-stringify on per-processor level),
thus requiring a hard-coded unique and un-quoted name. That issue is due to the allocation macros (see issue 6).

Other know issues already recorded:

Device initialization order that respects device tree dependencies #22545

Adding support for multi-functional-devices #48934

Solutions
(Follow the same order as the issue listing)

PM dependency tree
(issue 6 needs to be fixed first)
DTS, as its name tells, knows every devices and their parent/child that will exist in the build for a particular board/SoC. Thus it makes fully sense to use this information to create the PM dependency tree. For instance, suspending SPI master device x will first suspend all its related SPI devices k, n and m before actually suspending x.
From a technical perspective, it's just an oriented graph. Thus all well understood algorithm managing it. From an implementation point of view however, it's very important to keep in mind such graph could be greedy in memory depending on how many devices are present, and more importantly, how many relationships exist among them obviously.
Hence, a proposal here that could help to keep a tiny memory footprint:
struct device_pm {
    ...
    const u16_t *childs;
};

Where such child array would be, for the SPI device x:
const u16_t device_x_childs[] = [ device_k, device_n, device_m, device_end ];

Note that device_<k/n/m/end> are not pointers, but the result of a simple operation:
device_<k/n/m> = dev_<k/n/m>_pointer - __device_init_start;

and device_end would be:
device_end = __device_init_end - __device_init_start;

That one would be used internally to know where the array stops.
All of it would be generated by DTS and the linker would do the rest. It takes twice less space compared to full pointers.
A completely separate tree could also be created, not in device_pm structure as seen above. It would result in more CPU usage in tree traversal to retrieve if a device being suspended or resumed is in there as a child or a parent. However, note that any accessed device will require anyway to retrieve its potential parent(s). So as a device tree is unlikely going to be thousands of nodes anyway, such traversal could be fast enough. It's worth studying what is the best of all solutions here.
Storing the actual DTS tree itself in the binary is not the right path: it would take much more memory and anyway would require as much CPU power than above, if not more due to comparisons being made on strings.
I believe the node id size, u16_t here, could be generated by DTS as well depending on the amount of devices, it could even go down to u8_t. But that would mean DTS knows about the boot services too, which are actually made of struct device and thus part of the same device array. It is not the case at the moment and impedes fixing issue 12 as well.
As noted in the introduction, some existing work could be reused to fix this issue. For instance, the on/off API is close to this PM requirements and thus its core could be partly back-ported in PM but improved for various state and not only on or off. Mostly the logic of waiting for all nodes to switch from on to off and conversely could be reused for PM state switch among all nodes.

Cancelling on-going device API call
Adding a generic device API function such as device_cancel_call(struct device *dev) could do the job. Would there be a necessity to check on caller's thread id, it would require to store such id on each call, perhaps. In any case, it would require device structure to hold a pointer on a device driver specific function to actually properly cancel a call and cleanup the hw (reinitialize it if needed etc...).

Adding a timeout on each and every device API call
Such timeout would be a generic attribute to all devices, so added into struct device. The non trivial part is how to populate the timeout and with what value. Such timeout value could be a fixed one, provided via Kconfig and/or DTS. But it could also be computed at run-time for the bus specific API for instance where it is possible to evaluate rather precisely how much time a transaction would take. Based on the frequency, word size, length of the whole transaction etc... For the API providing a timeout directly, the value would be then then one given via such API. Or more specifically, the default value would be superseded by such value.
Perhaps such feature could be made optional, via Kconfig, for tiny targets.

Error storage when device initialization fails or gets into hw fault
Such initialization failure needs to be stored, but also when a hw fault arises. These are separate errors and thus should have there own storage space. One bit for each would be sufficient, so a bit field would go. It might be worth to store the error as well (either limited to 8 or 16 bits?).
It could be worth studying if the PM busy bit could be stored there as well, unless we generalize a lock on each and every device, reducing many device driver's internal data storage as well as generalsing lock mechanism for concurrent access. The PM state could also be stored in the same bit-field to simplify things.
Usefulness of such error/state storage would be:

to re-initialize a device in case of boot failure and/or hw fault
in case of hw fault, any subsequent calls would not proceed and require to re-initialize properly the device. (avoiding cascading error calls)
a base for reporting such error to any type of use-case requiring fine grained device state reporting (for maintenance, etc...)

Again, such feature could be made optional, via Kconfig, for tiny targets.

Recovering a device in case of initialization failure or hw fault
As soon as issue 4 is fixed, it would be trivial to relevantly call device's init function based on the stored error/state.

Device instantiation
This is by far the biggest and tedious feature. As noticed earlier, this would pave the way to fix most of the other important issues and would finalize the connection between DTS and the code by letting DTS auto generating everything orbiting around the device concept. Also noticed earlier, prototypes have been undertaken already but were too complex from there usage point of view. However on PR #10885, one can see some examples, and it reaches a point where developer would have very few thing to do on device driver side.
But it could be made even simpler. Something like:
/**
 * @code{.codegen}
 *
 * device_declare(<yaml compatible name>, <init prio_flag>, <level>, <irq_func>, <init_func>,
 *                           <exposed api>, <internal data_struct>, <internal config_struct>)
 *
 * @endcode{.codegen}
 */

Note that  and  could be removed once issue 12 would be undertaken. DTS would know that information, and thus would not require to get it from such device_declare() pseudo-code.

struct device and config part made constant:
That is trivial once issue 4 is fixed as the api pointer would not be tempered with anymore. A coccinel script could help to check the whole code-base for compliance to this rule as well.

Getting rid of the device name:
That one is actually very easy, once issue 6 is fixed. Again, DTS could generate a header file such as generated_devices.h which would enumerate each and every device instance such as:
#include <device.>

extern const struct device *device_k;
extern const struct device *device_n;
extern const struct device *device_m;
...

And the (infamous) device_get_binding() would just be a macro, replacing the "call" to device_get_binding(DT_LABEL_DEVICE_K) into device_k. It's in fact very trivial. A previous q&d patch I did back in the days was able to show off this feature, however not based on DTS at that time (it got barely introduced then) but on Kconfig. And it worked very well, the gain of ROM/RAM was interesting and the boot time was better as well, since device_get_binding() was not anymore retrieving a device by its name.

Nameless device created by SYS_INIT():
A simple struct device, and its components, refactoring would be sufficient. Again, that was already prototyped back in the days for the issue 8.

Optimizing device_pm structure:

the dev attribute can be removed (CONTAINER_OF() would just work)
enable and fsm_state could be just in same bit field and generalized (instead of book keeping "internal power state")
the lock could be generalized in sturct device, and used also for all calls for concurrent access.
work, event and signal usage should be revised. See on/off API for instance

Device's variable name

Once issue 6 fixed, that would also directly fix this issue. See the PR #20253 attempting to generate such unique id "ZID", though the PR goal is wrong as there is no need for making device init and device_get DT aware per-se. Connecting strongly DTS to device (variable name, instances etc...) would anyway make the whole device driver model DT aware. (See issue 6)

Device initialization order that respects devicetree dependencies #22545

That one would require also first to expose the software services to DTS. That's trivial imo. Then indeed sorting out the priority and levels out of the device tree would require some work on DTS side.
Let's sort the details out directly in relevant issue.
Note that getting issue 6 fixed would greatly help that, in a sense no one would have to go all over the existing device drivers to fix the priority/labels there.
Final thoughts
I believe there is no proper way to fix most of these issues without deeply connecting DTS to the model. And as such, we should focus on fixing issue 6 (aka "instanciating device via DTS code generation")

CC @galak @pabigot @nordic-krch @erwango @MaureenHelm @nashif @anangl @henrikbrixandersen

One more known (but relatively minor) issue that affects kernel footprint:
The model of placing function pointers in an API struct defeats gc-sections, as the functions will always have at least a reference in that API struct even if not referenced elsewhere. So if a driver is built, all of its API members will be pulled into the binary even none of them, or only a subset of them, are invoked.
At the moment I have no proposals to remedy this, but thought it worth noting.

@tbursztyka: For Power Management you will need more complex dependency tracking, as you have several types of relation between devices. Examples:

Parent/Child: Which controller handles given device?
Device/GPIO: Which GPIO is used to select SPI Device? Which controller controls this GPIO?
Device/Clock: What provides clocks for the device?
Device/Power: What provides power for the device?

@tbursztyka thank you for taking that initiative. Few comments:
I would add following requirements/topics:

using devices with generic API's #22415
device uninit
One use case is bootloader which should provide clean state before jumping into application. Second use case is nordic specific: we have couple of peripherals which are sharing same hw and address space thus cannot be used at once (e.g. SPI0 and I2C0) and currently in zephyr there is no way to use both in same application. I guess there might be other cases where user may want to uninit driver not because of PM reason.
manual/deferred initialization
Currently, all devices are initialized before reaching application. However, there might be cases where startup time is vital and application may want to defer initialization of some devices (because they might not be needed). One of the examples might be wake up from brown out reset when we want to do some kind of maintenance (e.g. flush some retained data to flash) and we don't want to have full blown system started.

No support for a timeout on each and every device API call

I assume that this is applies only to synchronous calls.

@andrewboie Indeed, very good point. I wonder if an ld script could check if a device instance is being used, besides its presence in the device init section, and would give a warning about it. Though the variable name of the device pointer would probably be not really user friendly (it could be generated from the ZID, thus an indirect way to relate to DTS and then to the driver it belongs).
But that sounds convoluted, there is probably a better way.
@pizi-nordic Most of this has to be solved in DTS side. The goal is to embed as less information as possible. Note that a node child may have 1+ parents (spi master and gpio in case of a spi device using a gpio cs, for instance.). The hierarchy of nodes would have to be generated by DTS. On DTS side, a clock source would need to expose whether it can be stopped (or under-clocked etc...), if it's fixed: no need to make it as a parent. Dealing with clock gate, I'd prefer the driver to embed that info directly, though I did not think much of that issue. Could be made generic, let's see.
@nordic-krch I still have to take some time on your proposal 1. I am not yet convinced this require a generic point into device. It would need more use case I think. About point 2, yes that's a very good one. On DW IP blocks for instance it may share spi and i2s. It is indeed a common use case. However, we have to come up with a transparent solution, i.e. something that would not require the user to do anything. Partial solution is about the device lock mechanism, in case of 2+ dev sharing the same resource, such lock will have to be unique for these 2+ devs. But then indeed we need to know: "is dev_x initialized?" and "since I just got the lock from dev_2, how to de-init dev_1 and init dev_2?" and "if I just used dev_2 last time, and reuse it again... I don't need to re-initialize it then?" etc... Point 3 seems valid as well, and it is crossing point 2: the way to know if a device has been initialized or not, and thus reacting transparently based on that info.

No support for a timeout on each and every device API call

I assume that this is applies only to synchronous calls.

Can this be explained in more detail.?
The danger here is that you are pushing device driver specific knowledge up the stack and this becomes unmanageable very quickly. i.e. consider a driver API calls that polls on a HW state change. It could poll forever, but it's the responsibility of the driver (and not the core) to manage this timeout (and return -ETIMEOUT or whatever up the stack).

@lgirdwood There is nothing the core has to do in this case. The idea it to bring a common object into struct device so the drivers will be able to use afterwards in a normalized way, instead of letting each and every device driver reinventing the wheel on their own.

Adding a couple of ideas:

Expanding from the line of thought from @pizi-nordic, it'd be nice to have a concept of power domains in DTS. On TI SoCs and likely other ones out there, devices are grouped into power domains, and only when all devices in the domain are not needed then the entire domain can be shut off.

Another use for "device uninit" is to employ it as a way for the application to say it doesn't intend to use a device for a long time, so the device can be shut off. With several device drivers currently the driver can only assume a device is not needed whenever there is no on-going data transfer, in which case it'd just turn on and off the device around the "transfer" function for example. But if the application wants to do back-to-back transfers, this can result in an unnecessary large overhead. If there were a "device uninit" then the driver would have the option to turn on the device during init and shut it off when "uninit" is called.

@vanti the 1 is indeed a good point, however let's put it aside for the moment as it is DTS/PM only issue (there is a lot of issues with PM besides the dependency thing I mentioned. To put it mildly: it's a mess.). I think once we get the base fixed - issue 6 and 1 - we will be able to go further and fix PM completely. About 2, such use-case sounds just like suspend/resume to me. So I still don't see a proper use-case for "exposing" an uninit function. Note that "un-initializing" a device won't necessarily mean it will be shut down, from a power consumption perspective. And again, un-initiliazing a device which would be parent of other device... It's the issue 1.

@vanti the 1 is indeed a good point, however let's put it aside for the moment as it is DTS/PM only issue (there is a lot of issues with PM besides the dependency thing I mentioned. To put it mildly: it's a mess.). I think once we get the base fixed - issue 6 and 1 - we will be able to go further and fix PM completely. About 2, such use-case sounds just like suspend/resume to me. So I still don't see a proper use-case for "exposing" an uninit function. Note that "un-initializing" a device won't necessarily mean it will be shut down, from a power consumption perspective. And again, un-initiliazing a device which would be parent of other device... It's the issue 1.

@vanti the 1 is indeed a good point, however let's put it aside for the moment as it is DTS/PM only issue (there is a lot of issues with PM besides the dependency thing I mentioned. To put it mildly: it's a mess.). I think once we get the base fixed - issue 6 and 1 - we will be able to go further and fix PM completely. About 2, such use-case sounds just like suspend/resume to me. So I still don't see a proper use-case for "exposing" an uninit function. Note that "un-initializing" a device won't necessarily mean it will be shut down, from a power consumption perspective. And again, un-initiliazing a device which would be parent of other device... It's the issue 1.

@b0661 Sure, I am evaluating it along with other solutions.

deleted two duplicate comments, for the curious

So I get how iteratively enabling parents would be nice but iteratively disabling children seems sort of overkill. Wouldn't listing parents but only ref counting children be enough for pm?

Another point regarding deferred init etc:
Perhaps these shortcomings are not strictly a matter of the API lacking features. It could be argued that it's more a matter of what's considered idiomatic. If drivers were in general structured like this:
int foodev_init(struct device *dev)
{
        // init mutexes, reserve memory, other setup-type tasks

#ifndef CONFIG_DEVICE_PM
        // this is NOT done in init() if CONFIG_DEVICE_PM=y
        foodev_do_poweron(dev);
#endif /* CONFIG_DEVICE_PM */
}

int foodev_pm_control(struct device *dev, u32_t ctrl_command,
                      void *context, device_pm_cb cb, void *arg)
{
        // ...rather, it's done here:
        if (ctrl_command == DEVICE_PM_SET_POWER_STATE) {
                foodev_do_poweron(dev);
        }
}

then all "real" inits would be deferred until the user actually requested the device to be powered on. But NO (upstream) drivers are written like this to my knowledge.
Ofc, supporting this idiom would be a lot easier if the device could programmatically access its direct device dependencies...

Providing device dependencies is not difficult: we already have them, we just haven't emitted them yet, perhaps because we haven't identified the canonical representation of a device handle.  (The address of the struct device would work, but that's a lot of space when we could use a u8_t or u16_t handle value to identify dependent and depending nodes in any reasonable Zephyr application.)
While we can provide the dependency information for device tree nodes, that doesn't help with coordinating dependencies between devices and other initializers (#23407), whether or not those are also updated to be based on dependencies rather than hard-coded level plus configurable priority values (which I'm concerned can produce hard-to-identify failures if the priorities are mis-assigned).
I have some ideas about how to do this but it involves either grotesque linker script hackery; a special link that produces data that is processed to produce a dependency tree that gets embedded into the application; or both.  I don't think it's a viable path.
Aside: Maybe we should fork off a separate area to discuss specifically how to deal with initialization ordering, as there are probably other things related to this overview issue that will be obscured if we discuss too much here.

Each device is not constant (same for their config part):
It was meant to be constant, but due to a hack on device's API setting (in case of init failure it is set to NULL at runtime) it is never constant, thus ends into RAM instead of staying into the ROM. See #24873

Based on experience from #25208 I don't believe it will be possible to switch to using const struct device * everywhere: too many APIs pass or store device pointers in void *, which requires introducing casts that remove the const qualifier.  Comments to focus on:

MISRA violation in const removal
Dev-review discussion
Evidence it can be done if we decide it's important enough.  See the commits in the PR for examples of the massive changes required, some of which cannot be automated.

Providing device dependencies is not difficult: we already have them, we just haven't emitted them yet, perhaps because we haven't identified the canonical representation of a device handle. (The address of the struct device would work, but that's a lot of space when we could use a u8_t or u16_t handle value to identify dependent and depending nodes in any reasonable Zephyr application.)
While we can provide the dependency information for device tree nodes, that doesn't help with coordinating dependencies between devices and other initializers (#23407), whether or not those are also updated to be based on dependencies rather than hard-coded level plus configurable priority values (which I'm concerned can produce hard-to-identify failures if the priorities are mis-assigned).
I have some ideas about how to do this but it involves either grotesque linker script hackery; a special link that produces data that is processed to produce a dependency tree that gets embedded into the application; or both. I don't think it's a viable path.
Aside: Maybe we should fork off a separate area to discuss specifically how to deal with initialization ordering, as there are probably other things related to this overview issue that will be obscured if we discuss too much here.

@pabigot if the dependencies are only about:  1. get the last level's parent(s) of given struct device which will be used in device runtime pm where the number of reference children will be counted at runtime; 2. construct ordered list where parent will be at the front of children(devices will be suspended following this list and resumed in the converse order for the case of devices following system states), does that will simplify the implementation?

does that will simplify the implementation?

@wentongwu That's about what I'd assumed we'd do, though dependencies are static (I don't see why they would be dependent on power state).  The blockers are representation of device handles, and how to manage dependencies between devices and non-device functions.  The latter may need to be done manually in the driver source.

@pabigot Thanks, but what's the meaning of the representation of device handles? And I see your comments https://github.com/zephyrproject-rtos/zephyr/pull/24514#issuecomment-637208934, also new version pm subsystem is expected in 2.4 cycle, but the first we should give a solution for the device dependency. And above I just give the two possible use cases about the device dependencies from pm perspective to see if the only two use cases instead of wanting the whole dependency graph/tree can simplify the implementation

API meeting 16th June 2020
Two options proposed:

#25208 converts all struct device * parameters to const struct device *
#26127 moves all the constant data to a separate structure, and keeps struct device non-const

The issues with 1.:

All calls to device_get_binding() calls would now return a const pointer, requiring a change in the implementation of many applications
Device drivers that use struct device * to pass it as a context to threads or HAL functions would have to down-cast from const struct device * to void *
or store a pre-cast pointer to a non-const struct device *
or
have some sort of:

struct dev {
  struct device *d;
};

with an instance of that somewhere.
@tbursztyka suggests using const struct device *dev everywhere but storing a pointer to the struct device in the driver_data structure for drivers that need it.
For dynamic allocation, knowing if the instance is between the _start and _end of the driver linker section would be enough, in case the device driver actually needs to know whether it's in RAM and ROM.
Device drivers should not need to know whether the struct dev instance is in RAM or flash, ever.

https://github.com/zephyrproject-rtos/zephyr/issues/26072#issuecomment-645006182 has a summary of the impact of #25208 versus #26127 and a requested comparison (with limitations discussed there).

Some precision from my side:

The issues with 1.:

All calls to device_get_binding() calls would now return a const pointer, requiring a change in the implementation of many applications

I don't think we nacked all the huge API reworks (gpio, adc, spi, ... and on going) we have got so far, on the fact it would require changes in the implementations of many applications. So to me, this is a false argument. Moreover in this case, it's really a small change.

Device drivers that use struct device * to pass it as a context to threads or HAL functions

Again that's not a big change. Only a fractions of drivers would require that, not even mentioning threads. Same previous answer applies here as well.
About numbers given by @pabigot, the number of files being touched does not matter as soon as one solution is clearly better than the other one (in this case, const dev is really the one to pick). It would indeed matter if it was fully comparable.
The gain of RAM/ROM might not look tremendous, but that's already a relevant one. It certainly does not play any role in boards with 1Mb and more, but it does on all the ones that have below.
Last but no least, part of the gain made by such rework, will be useful to improve provided features to drivers (such as #24511 for instance, which is not going to eat up all that gain since many drivers implement such solution on their own currently, it's just a matter of normalizing the behaviors under a central API).

I've rebased #25208 on the same master commit as #26127 to improve comparability.  Because #25208 is closed I can't push an update, and	I don't want to submit another one, so if you want to reproduce the results you'll need to pull specific commits from my repository.  The links and specific commits used are documented in the results.
See https://gist.github.com/pabigot/d63ddfa24a30e7a95e902fe986cbbd89 for the script and latest results.
While I do not dispute that transition to const struct device* provides the maximum savings in RAM, my concern remains the impact of this change on existing in-tree and out-of-tree code.  This is not a small change, as you can see if you look at what had to change in the samples to eliminate compiler warnings.

Another potential resolution proposed in the 2020-05-14 dev-review is to put all the immutable data directly into struct device, but rely on the linker scripts to put the .device_PRIO section into non-volatile memory.
This would mean all existing API using struct device * would be unchanged, but we'd not use RAM to store the referenced objects.  Best of both worlds.
But it would also eliminate any chance of language-level detection when somebody writes through the pointer.
On many targets such a write would silently do nothing.  On some it might cause a bus fault.  On others where RODATA is stored in a memory technology that is not write-protected (e.g. FRAM) it could be catastrophic.
It's still an option.

rely on the linker scripts to put the .device_PRIO section into non-volatile memory.

That was always the plan so far, to force the devices instances to be in ROM (and not anymore in this RAMABLE_REGION, ROMABLE_REGION at it is right now).

But it would also eliminate any chance of language-level detection when somebody writes through the pointer.

That's a bad idea, you really want to know at compile time if you are using the APIs and the objects as they are meant to be used.

Dev Review 18th June:
Original reason for moving the immutable part of the device information to ROM:

Memory savings in RAM. This RAM is to be reused for other features like common thread safety and internal/external synchronization.

Reasons for passing around const struct device* instead of struct device *:

Statement of intentions: Device drivers and users of struct device * are not to modify the structure directly, Instead, a common device driver infrastructure with a defined API would allow device drivers to use the common mechanisms for all, without requiring drivers to provide their own.

Statement of intentions: Most device instances in Zephyr are defined at compile time and stored in ROM, so this is more truthful to the majority of cases

I've updated https://gist.github.com/pabigot/d63ddfa24a30e7a95e902fe986cbbd89 with new results comparing the alternatives.  I'd missed the commit that changed the linker scripts to place the device list in ROM instead of RAM.  This was obscured because size(1) does not accurately capture the true memory usage.  Instead I've switched to using the memory region summary produced by the linker and displayed when things are built.
The overall conclusions do not change, but the numbers are more justifiable.

As maybe related to #30105 if redoing the device model it would be a great addition to avoid the function pointer table altogether in many cases by perhaps using _Generic and driver specific types with a macro wrapper like i2c_transfer(somedevptr), which is about as good as we can get in C for static dispatch. It might  let a linker GC more function symbols and reduce the size of the elf along with other performance benefits.

One of the features sorely lacking from Zephyr is a controlled, reverse dependency order shutdown of the RTOS.  One use case for this is when shutting down a multi-threaded instance of MCUBoot and transitioning to another executable (which could even be different instance of MCUBoot running from RAM instead of Flash).  The hardware state during this handoff from one executable to another needs to be well controlled, and not necessarily inactive (e.g., some GPIO hardware or graphics display buffers may need to stay active, hardware watchdog may need to stay running).  For a scalable, composable solution, this will need to be registration-based, perhaps as an extension to SYS_INIT().

Adding reference to new discussion thread on metadata tracking - https://github.com/zephyrproject-rtos/zephyr/issues/49431

API meeting:

Requirement from @bjarki-trackunit:

To be able to call multiple API classes using the same struct device * (or equivalent) in each call

I have summarized the discussions and conclusions regarding the last months of discussion regarding MFDs and the device model. It is a 2-3 minute read approximately.


custom elements doesn't exist: purifier-card

[ ] I updated to the latest version available
[ ] I cleared the cache of my browser
After update i have this errro on lovelac card :
custom elements doesn't exist: purifier-card
I try reinstall in HACS , try older . Try add manual but not working, all time this error .

Have the sam problem. When I go back to 2.2.3 working good. After all of version have the same problem.

Have the sam problem. When I go back to 2.2.3 working good. After all of version have the same problem.

Thanks, 2.2.3 working for me !

The same problem as well, even v2.2.3 is not working.
But if I installe on the fresh instatce (where I didn't install purified-card before) - everiting is OK.
There are all required files in /config/www/community/purifier-card/:

Also there is the resourse sourse:

In the mean time, card is not eisitng in UI:

The same here.

Same here with latest version... it worked but stopped working after updating. Coming back to 2.2.3 does not work.

Same

I can confirm I have the vacuum-card installed. Thanks!

I just removed the vacuum card and it worked.

But, now this its the problem...


Data radio legality

In the manual, it lists amateur radio digital modes as a medium that reticulum can use. However, I'm fairly sure most countries (definitely the US and UK) ban the use of encryption on amateur bands. Is there some edge case in the law I'm not aware of? Did it mean to use amateur equipment in ISM bands (I don't know if that's legal either)? Is there something else I'm missing?

I am not a lawyer, however in the United States, encryption is only allowed for command and control of amateur radio satellites. Is there a use case for that using Reticulum? Sure. But as it sits now, traffic using Reticulum to send and receive terrestrial data over US amateur radio would be prohibited, at least with my understanding of the Rules. Without getting into the politics of it all, I can foresee a future time where the encryption ban in the US is lifted.
The wording in the manual still is applicable for other countries, though. For example in Poland, it is perfectly fine to encrypt communications over amateur radio. I would suggest that the line in the manual should be updated to include the words "where allowed" or "where encryption on amateur radio is legal" to prevent confusion.
As an aside, encryption is fine on public service and commercial frequencies in the US, assuming you hold the proper license.

Thanks for the reply, what do you mean by public service frequency?

Thanks for the reply, what do you mean by public service frequency?
Fire, police, ambulance, road works, town/city/state government, schools...

Things not public service: CB, GMRS, FRS...

What @kc1awv says here is completely spot on:

I believe the spirit of the manual is that it's up to the end user to be sure that what they are doing is legal where they live, and not rely on whether or not the manual of a program is giving them permission to do something that could be illegal.

A just marginally thorough coverage of what you can and cannot do when and where, when it comes to RF emissions would take up more pages than the manual itself, and varies wildly from area to area. Other countries that do not prohibit encryption on amateur radio spectrum include Germany and Denmark. Also, many commercial or personal spectrum license holders use amateur radio digital modes on commercially or personally licensed spectrum, since it is often the most efficient way to establish communication.
I am also not a lawyer, so take the following with a grain of salt, and as an interesting side-note. The following is my personal interpretation of the legal texts, and as such, just an opening for discussion on an interesting subject.
In general, all countries within the EU legislative framework and the United States follow the ITU Radio Regulations, which sets forth some guidelines for the actual legal implementation in each separate legislation. This is reflected for example in the United States by the Title 47 CFR FCC Part 97, which contains the actual rules governing the amateur radio service in the US. Specifically, Part 97.113 defines the "Prohibited Transmissions" for the amateur radio service. The exact section of concern reads as follows:

Music using a phone emission except as specifically provided elsewhere in this section; communications intended to facilitate a criminal act; messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.

Out of this section, it is obviously the "messages encoded for the purpose of obscuring their meaning" part that is relevant to this discussion. The point here is very clear. If you encode a message, in any way (encryption or not), for the purpose of obscuring its meaning, that will be a prohibited transmission. It is the purpose that is of importance here though. Encryption in and of itself is not illegal to use over amateur radio in the US, and in fact, Part 97 does not include the word "encryption" even once.
This means that there is plenty of situations where you can use systems that employ cryptography and encryption without breaking Part 97 rules.
Reticulum does not, per se, employ encryption to "obscure the meaning of messages". Reticulum fundamentally needs packets to be encrypted for the transport and routing layers to even work at all. If you could turn off the encryption and replace it with a dummy cipher, just inserting plaintexts, nothing would work. It would not be possible for the Transport layer to verify paths through the network, it would not be possible to sequence resource transfers, and it would not be possible to verify any sort of connectivity or data delivery to destinations.
As such, Reticulum first and foremost employs encryption because it is the most efficient way to make a decentralised routing and mesh protocol work at all, and frankly, it is the only way to do so. It is therefore solely the intention of the operator that bears relevance when using Reticulum over amateur radio spectrum, if you do not use Reticulum because you want to hide the content or meaning of messages, and nobody can legally prove otherwise, that part of the law cannot be used against you.
Even in the places where the above legal wording is implemented, there is plenty of situations where I would personally not have any qualms what so ever with using Reticulum, for example:

Using nomadnet to access pages on an amateur radio node that is publicly accessible (there can be no intention of obscuring meaning, since the content being sent is accessible to all licensed amateurs).
Using Reticulum to program a system for checking status of, and controlling a remote repeater site.
Creating a home automation system allowing you to control stuff (again the purpose here is not to obscure the meaning, but to make sure others can not remotely turn on your furnace or unlock your gate)
Sending messages to, and retrieving messages from a shared message board for amateurs.

I can also foresee a future where the legislation is changed, but it will not happen without it being challenged by users who want the change.
I take the stance that cryptography and encryption is already perfectly fine on amateur radio spectrum in many cases, but not all, and that we should work towards a situation where the prohibition of encryption is not just omitted, but the use of cryptography is actively protected and encouraged. This is my own stance, and it is definitely an unpopular one in many circles within the amateur radio community, mostly because of the lack of understanding of what cryptography actually is, and the value it provides.
I have yet to hear a good argument in favor of the prohibition of encryption within the amateur radio service.
Also, I will just move this to the discussion board.


WebVRManager > Fix for #336

Fixes the issues some people were experiencing with the headset not functioning.

webvr.js is looking for an object named WebVRCameraSet to pass the messages to, but since it gets renamed in the instance method it won’t be found. This only occurs if the Instance method gets called before Awake.
Also added a debug message if you rename the object with the WebVRManager on it.

@Banyango Ah! I didn't quite catch why that was happening. Thanks so much for the fix!


Enhancements: People & Group fields should have auto-complete feature & Bug field can be filled in the request form and Branch field should be auto-populated based on .reviewboardrc file

While posting review People & Group fields should have auto-complete feature so that we don't have to memorize any group name.
Bug Field should be available at Review Request form so user can define it there.
Branch Field should be auto-populated based on .reviewboardrc file if it exist.

this should really be three issues... I certainly just got caught on the third one


Update find.md

This is one of the commands with the most ...hmm not-totally-accurate documentation.
double quotes in the searched string are mandatory. I've added them in the syntax description as they are in the help message. Also added them in the examples.
Also I don't think examples with doc files are good idea as they are not text files.
it is not true that the command does not accept wildcards in file names so I removed the part with the FOR command.
I've added the exit codes - I think it is good idea to have them for all the commands (when possible - sometimes you can't give a good description for all of them)
the example with searching all the files in a drive will be too slow and I think it's better to use a directory instead.

@npocmaka : Thanks for your contribution! The author(s) have been notified to review your proposed change.

By the way - what files I need to change If want to add a documentation about a new commands?  A lot are missing but the most obvious are some internal CMD.exe commands.

Is there a policy that do NOT recommend external links to places like stackoverflow,ss64.com and so on?

Yes, the general rule is to only use microsoft.com links or relative links to neighboring pages. Theoretically, you could use links to verified Microsoft affiliates, but that is a marginal area and probably needs to be verified by the product group to be approved.

is there a way to put a link to a Microsoft's page?

Not quite sure what you mean, but you can usually add links to relevant microsoft.com pages, as long as the link is important for the topic in question.

@npocmaka : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@illfated: I'm sorry - only the author of this article, @JasonGerend, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Yes, I know. My sign-off comment is based on a previous agreement with the team. @khdownie : Would you happen to know if there are someone else available instead of @JasonGerend, since it seems like he is more than occupied with other work than these Pull Request?

@illfated I have a meeting with Jason on Monday morning and I will bring up the fact that we have a lot of these PRs that are being submitted through the public repo to correct issues, and then they just sit there. I know there are many others. I can't sign off on this as I'm not an author, but there has to be a way to get these (and other) corrections made.

Thank you very much. I am relieved to hear that you are aware of the situation and that you will discuss what can be done. Best of luck to you, take care and stay safe. 👍🏼

Looks good - sorry for the delay - thank you for your contributions!

Oh. I am just relieved to see you back. I was worried for a while. Thank you to all of you.


x/telemetry: 2024-1-18 An Internal Server Error is obtained

Go version
inapplicability
Output of go env in your module/workspace:
inapplicability

What did you do?
2024-1-19 access https://telemetry.go.dev/charts/2024-01-18
What did you see happen?
have Internal Server Error
What did you expect to see?
not have Internal Server Error

cc @pjweinb @hyangah @findleyr

Thanks for the report.
The report isn't available yet, so should return 404 instead.


[Feature Request] Allow adding a pre defined amount of time after completion of work and break sessions

It would be useful to have the ability to add a few minutes of time, even after work/break sessions are over. This would help in allowing us to complete a task that we had almost completed once the timer ticked to 0, while still tracking out time and sessions

That's nice to hear. Thanks!


3.8.0 Repairing armor does not grant skill points.

General information:
Project issue is for:
3.8.0 BE
Expected result:
Repairing armor should grant skill points
Actual result:
No skill level change
According to the latest Wiki. Repairing armor should give skill to the corisponding armor type. Every 10 points gives 0.4 skill point as an example for light armor. That used to work in the past but perhaps due to the new plate system we now repair the plates and not the armor, this could be just something that needs to be changed?
How to reproduce:

Get a damaged armor
Repair
Witness the skill not going up

Originally written by Stealthsuit

Just as an extra thing.
Yes I did use the armor repair kit.

Originally written by Stealthsuit

Fixed with: https://dev.sp-tarkov.com/SPT-AKI/Server/commit/28c9ddad9c03ce539f3f9ce6c447a98368382917

Originally written by chomp

Gained 0.1 light armour for repairing 38 total on integrated plates on a Module-3M.
Gained 0.1 heavy armour for repairing 21 total on integrated plates on TC-2002 helmet.
Gained 0.1 heavy armour for repairing 27 total on integrated plates for Tor-2 helmet.
Gained 0.2 heavy armour for repairing 48 points on standalone insert heavy plate (probably rounded to 0.2?)
Seems to be gaining around 0.1 for a repair job regardless the amount of durability repaired.
Even if (for a helmet for example) has 2 integrated plates, and each of them gained at least 10 durability you still get 0.1.
I'll have to check against the profile json to verify exact value as I'm not sure how rounding display works on the client for skills (probably rounds down?)

Originally written by acidphantasm

Hello, tested with the build from today (2/13/24), and i cant seem to get any skill points from repairing armor with or without a repair kit. tested Both light and heavy armor and with and without repair kit

Originally written by Dabi7582

Hello, tested with the build from today (2/13/24), and i cant seem to get any skill points from repairing armor with or without a repair kit. tested Both light and heavy armor and with and without repair kit

No skill increase at all when using a kit?
I was hoping to see increases to:

WEAPON_TREATMENT
HEAVY_VESTS/LIGHT_VESTS
INTELLECT

Originally written by chomp

No, tested multiple armors too, some from flea some from fence looking for low durabilities, and repaired to full, i stayed on the same amount of points for each of those skills that i had before i repaired

Originally written by Dabi7582

Attached are before and after screenshots of my profile skills when I repaired 2 different armours and a weapon from fence. They seem to be adding points.
Granted, the armour skill point gain is probably lower than it is supposed to be.

Attachments

beforeafterrepair.png (115 KiB)

Originally written by acidphantasm


Remember device with OneTouch login

Hi! Is there any reason to avoid remember device on OneTouch login flow? I noticed that remember_device helper is not used anywhere in OneTouch login process, and this could be a very useful usability improvement.
I could submit a PR if necessary, but I want to be sure this is not the intended behavior cause some security issue.
Thanks!

I don't believe there is a security reason to not include it. Though perhaps there is a UX question. That is, at which stage of the process do you include the check box to remember the device when you are authenticating via OneTouch?
I'm absolutely for including this, if we can find a good way to include it in the UI.
Thanks for bringing it up and let me know if you need any pointers around the repo.

Thanks for your answer @philnash, maybe we can use the same checkbox currently used in verify-token form. Just retrieving state on onetouch-status success trigger and sending the variable as a query string to the server could be enough (like onetouch_uuid). Then, in devise_authy_controller.rb we can replicate remember_device helper in 'approved' case for GET_authy_onetouch_status.

Sounds good! Give it a go and we will see how it comes together.

Hi @philnash, I already created a Pull Request with a possible solution for this Issue. Is there anything else I should do? Please if you can review my code would be awesome.
Thanks!

Thanks for the PR! I will take a look soon :)


too slow rendering since update After Effect to 24

Hello to all the community
We have a problem with too slow rendering since we update after effects from version 22 to 24 (on MACOS & ae_render_only_node without interface). Renderings can take up to 1500 seconds whereas before it took 30 seconds on version 22.
Then we noticed that the output module returned us an .mp4 file by default whereas before it was a .mov. Has anyone had the same problem as me and if so have you found a solution to revert to the QuickTime .mov format by default?
I saw in the documentation that you can modify output Module directly in the json (in template option) but I can't put it like in version 22 where my generation was still very fast..
Please help me..
Thanks !

I just discovered the reason for this slowdown. this came from a thickening of the "fontbold" font, once removed the generation becomes as fast as before.
That's it, if this helps anyone.
Bye!

That feels like the most AE thing that could've happened :)

Yes ;) and it took me a few weeks to find..:(

I can only say, I understand your pain! And I'm still amazed by the fact that you were able to even find this :)

Thank you very much, I hope I was able to help the community as much as they were able to help me !


Create dont-use-client-side

@AvigailHagay , I don't understand this pull request. The file is empty (besides, you should open a directory with the same name and send a README.md file with the solution in that directory, see my example)

I tried to upload a file from my computer, it won’t let me.
בתאריך יום ג׳, 4 באפר׳ 2023 ב-16:43 מאת Ben Hirschberg <
@.***>:

@AvigailHagay https://github.com/AvigailHagay , I don't understand this
pull request. The file is empty (besides, you should open a directory with
the same name and send a README.md file with the solution in that
directory, see my example)
—
Reply to this email directly, view it on GitHub
https://github.com/slashben/hadassah-picoctf-2023-writeups/pull/9#issuecomment-1496000195,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZJ5W5IJPFVSKBEXGQK24L3W7QQOXANCNFSM6AAAAAAWSVSQUU
.
You are receiving this because you were mentioned.Message ID:
@.***>


switch to Cursor class

This pull is opened in response to a review comment from @keilw about switching the Cursor interface to a class.  It needs to be agreed upon with @beikov whether to cancel this pull without changes because the interface is preferable or whether to merge the pull and switch to a class.
Signed-off-by: Nathan Rauh<EMAIL_ADDRESS>

I'll repost my questions for @keilw here

This Built-in implementation of Cursor seems a little odd. What is the purpose and is it intended to be overwritten by implementations?
If not, why is it an interface instead of just a class?
My intention is to allow jakarta-data implementers to provide their own Cursor implementations to e.g. provide extensions like exposing the order by item expression or simply provide a custom serialization implementation.
To me, having an interface here is the most flexible. Since users most probably won't create Cursor instances themselves, I also don't think that the interface here is a problem. Can you elaborate what you think is odd in particular?
Another possibility could be having a Cursor class only and making it extensible, but @beikov would need to agree to that.
We could surely do that, but then the object layout would be fixed i.e. every subtype has to use an Object[] as storage or ignore that. Can you explain what kind of problems you think the interface approach could lead to?

@beikov
Not sure, how using a class instead of an interface would change the way things are stored?
It would be Cursor, or can you explain here in concrete examples what difference the interface vs. class would make?
As this is defined in the public API of Jakarta Data, an interface makes it likely that implementors must also implement it and the TCK needs to take it into consideration.

Not sure, how using a class instead of an interface would change the way things are stored?
It would be Cursor, or can you explain here in concrete examples what difference the interface vs. class would make?

The point is that implementers are free to implement the Cursor interface however they like if they want.
If an implementation wants to provide a custom Cursor, it can do so by returning that from KeysetAwareSlice#getCursor() or implicitly through KeysetAwareSlice#nextPageable()/KeysetAwareSlice#previousPageable().
Reasons for Cursor subtypes could be:

Provider specific API e.g. provide access to the query expression for a cursor element
Custom serialization logic for cursor values
Custom storage layout (not Object[]) for the cursor

Not sure, if that "if they want" works for the spec, they may have to implement it anyway, that is the point I want to clarify with platform, Spec Committee or others.
There are "Optional Features" e.g. in Enterprise Beans but that's usually an entire spec that is no longer mandatory.
I think similar to Jakarta NoSQL we already have several possible areas of "optionality", remember using GraphQL or not, but currently KeysetPageable and its Cursor are baked into the abstract Pageable class, making them inseperable, so at the moment it is not possible to factor them out into a separate (optional) module, while e.g. Jakarta NoSQL has ben structured into modules already, see mapping.
It allows in theory (although for existing specs I am not aware that works, it's "all or nothing") to have a vendor like MongoDB only implement the mapping-document module but ignore column or key-value.
Even if we may not be forced to modularize it, there is not just a "if they want" because the TCK (via some kind of "profile") must cover all cases, especially the one where vendors implement their own Cursor.
That's why I'm raising this question, I am OK to merge the other PR but unless we change it to a class (in that case I guess we could call it an implementation detail) we will have to deal with it in the TCK.

I don't know what the TCK needs to deal with here exactly, but unless an implementer wants to provide extensions or customize things, it shouldn't be necessary for an implementer to provide a custom Cursor implementation. An implementer should be able to use the default implementation through the means of Pageable#afterKeyset/Pageable#beforeKeyset.
That being said, I want to clarify that the keyset aspect does not have anything to do with GraphQL and that this feature is not something that can IMO be separated out into a sub-module or anything like that. It is IMO important for usability to make this part of the core API.

No but the point is the aspect (challenge) of Optionality and Modularity (in the JCP only Java ME Embedded really accomplished that) whether it's different types of databases, GraphQL or anything else some vendors just don't want to care about.
In Jakarta Persistence there is no optionality either, which is why certain special features come with either Hibernate or EclipseLink. If they were in the spec both of them had to comply with it.
If Pageable/KeysetPageable are part of the API then the TCK must test for it and currently I'm not even sure, if a vendor has a choice, but if they do then they must run the TCK in a special profile or mode, e.g.  "default" vs. "customized" or similar.
With JSR 385 we were one of the only JSRs (beside the now unused ME Embedded) to offer a flexible set of 7 profiles in the TCK. Inspired by the CDI TCK but there only differences between e.g. the Web and Full Profile of Jakarta EE are taken into consideration.
Having a much smaller CDI is the challenge of "CDI Lite" and wherever there are possible customizations we may have to offer some kind of "profile" in the TCK as well.

@njr-11 do we need this PR?
If yes, can you rebase it, please?

@njr-11 do we need this PR? If yes, can you rebase it, please?

Good point.  We might need it depending on the outcome of a discussion that @keilw and @beikov were having, but don't know yet.
Looking over the discussion, one item that seems inaccurate is:

allowing "some vendors" to override means, all of them would have to

Let's consider another spec interface, jakarta.data.repository.CrudRepository.  There is a possibility a vendor could override it with their own, such as com.vendor.repository.VendorCrudRepository, maybe to add some vendor-specific built-in convenience methods or for whatever reason.  In no way does that imply that other vendors must do likewise, nor does it imply that a Jakarta Data TCK must test for the possibility of such a scenario.  Capabilities that vendors add outside of the specification remain outside of the specification.

IMO we don't need it, but it appears @keilw doesn't like the interface approach, though I don't fully understand why.

Yes, the Jakarta Data TCK must test for the possibility of such a scenario, and as soon as there is customization, it barely matters, if Cursor was an interface or (abstract) class.

I'll reiterate that it is out of scope for a TCK to cover vendor-specific extensions to the specification.  The only way I could see it being valid for TCK to require a vendor to supply their own Cursor would be if the specification had a method like the following on an interface (maybe Page) that the vendor must supply, <C extends Cursor> C getCursor(Class<C> vendorCursorExtension), in which case it would be correct for the TCK to test the method and its vendor extension Cursor result.  But since we don't do that and aren't going to do that, then the TCK must not test for Jakarta Data vendors providing extensions to Cursor.
It would be valid for the TCK to test application-provided extensions to Cursor, with the TCK application providing the extension and supplying it to pageable.beforeKeysetCursor and pageable.afterKeysetCursor methods, verifying that page contents are as expected when used with a database that is capable of keyset cursor pagination, and when used with a database that is incapable of keyset cursor pagination then the repository method raises UnsupportedOperationException or whatever exception we define to be the specification required behavior in that case.  I'll get a pull open to define the exception for the error condition because I don't think the spec has defined it yet.

Of course the TCK must test for implementations of the Pageable.Cursor interface, only any possible addition and new methods to a class that implements it would be out of scope for our TCK, but the behavior of the methods the API itself declares must be tested.

This pull is out of date and it is unclear that it is needed anymore, so I'm canceling it.


Error reporting when accessing non-grid services

When accessing non-service grid services in the sidecar proxy container of the apisix application, a 503 gateway is prompted, such as Baidu

kubectl exec -it ratings-v1-679fc7b4f-9zglr bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
Defaulting container name to ratings.
Use 'kubectl describe pod/ratings-v1-679fc7b4f-9zglr -n default' to see all of the containers in this pod.
node@ratings-v1-679fc7b4f-9zglr:/opt/microservices$
node@ratings-v1-679fc7b4f-9zglr:/opt/microservices$ curl www.baidu.com

502 Bad Gateway

502 Bad Gateway
openresty

node@ratings-v1-679fc7b4f-9zglr:/opt/microservices$ curl https://www.baidu.com
curl: (77) error setting certificate verify locations:
  CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs


Seed Connector and E2E Test Fails

Current Behavior

Seed Connector Job fails while deploying MXD.
E2E Test fails.

Expected Behavior

Both shouldn't fail.

Steps To Reproduce

Run terraform apply
Montior output and Seed Connector logs.

Reason
Create Policy Request fails with the below error:
[
  {
    "message": "Property '@type' was invalid: unknown. Error was: Invalid type https://w3id.org/edc/v0.0.1/ns/Policy for ODRL policy, should be one of [http://www.w3.org/ns/odrl/2/Set, http://www.w3.org/ns/odrl/2/Offer, http://www.w3.org/ns/odrl/2/Agreement]",
    "type": "InvalidRequest",
    "path": null,
    "invalidValue": null
  },
  {
    "message": "ARRAY must be org.eclipse.edc.policy.model.Policy but was: unknown",
    "type": "InvalidRequest",
    "path": null,
    "invalidValue": null
  }
]

Fix
Use  ~"@type": "policy"~  "@type": "odrl:Set" inside policy  object of the request body.

This issue will be fixed via #248 and #227.


Fixed typo

Initial pull request fixing a typo in the readme.md file

Hi Robert - there are many more typos in this document. Can you correct them and then resend the pull request?

Sorry I thought you were just looking for a simple pull request to make sure we were familiar with git. I will do the rest of the typos as well.


puzzled on color conversion

In some prototxt files, the layer "ColorConv" is used to deal with rgb->lab. But in other prototxt files, the python code "color.rgb2lab" take the place. why do not use the same way? In addition,  the layer ColorConv" can not be found in normal Caffe version. what the data type (0-1,or 0-255) should be used when adopting ColorConv?

Hi, I am having the same problem here. Could you please tell me how you solved it? Thanks~


wall breaker

Description
Added wall breaker game using HTML, CSS and JS
you can move the paddle to left and right using the key
destroying the wall's will earn you a point and it will increase the score
Fixes #(198)
Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@nikhv

@nikhv plss mention issue no only with #

and resolve conflict

issue #198


KeyVault Access Policy: "/subscriptions/b6b4b75f-/resourceGroups/simbachain-global-rg/providers/Microsoft.KeyVault/vaults/simbachain-global-vault/objectId/" didn't parse as either an Object ID ('{keyVaultId}/objectId/{objId}') or an Application ID ('{keyVaultId}/objectId/{objId}/applicationId/{appId}')

What happened?
Warning on KeyVault AccessPolicy resource "global key vault access policy for managed identity". I don't understand where that value is coming from.
Warning  CannotObserveExternalResource  2m56s (x116 over 118m)  managed/keyvault.azure.upbound.io/v1beta1, kind=accesspolicy  cannot run refresh: refresh failed: "/subscriptions/b6b4b75f-<REDACTED>/resourceGroups/simbachain-global-rg/providers/Microsoft.KeyVault/vaults/simbachain-global-vault/objectId/" didn't parse as either an Object ID ('{keyVaultId}/objectId/{objId}') or an Application ID ('{keyVaultId}/objectId/{objId}/applicationId/{appId}'):
➜ kubectl describe AccessPolicy.keyvault.azure.upbound.io policy-ezall-tst-opal-simbachain-global-vault-ap
Name:         policy-ezall-tst-opal-simbachain-global-vault-ap
Namespace:
Labels:       crossplane.io/claim-name=policy-ezall-tst-opal
              crossplane.io/claim-namespace=opal-policy-ezall-tst
              crossplane.io/composite=policy-ezall-tst-opal-m6rf8
Annotations:  crossplane.io/composition-resource-name: global key vault access policy for managed identity
API Version:  keyvault.azure.upbound.io/v1beta1
Kind:         AccessPolicy
Metadata:
  Creation Timestamp:  2023-11-14T14:04:07Z
  Generate Name:       policy-ezall-tst-opal-m6rf8-
  Generation:          2
  Owner References:
    API Version:           azure.simbachain.com/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  XOpal
    Name:                  policy-ezall-tst-opal-m6rf8
    UID:                   128e3edf-f<REDACTED>
  Resource Version:        34292681
  UID:                     c47a9893-<REDACTED>
Spec:
  Deletion Policy:  Orphan
  For Provider:
    Key Vault Id:  /subscriptions/b6b4b75f-<REDACTED>/resourceGroups/simbachain-global-rg/providers/Microsoft.KeyVault/vaults/simbachain-global-vault
    Object Id:     2900fbba-<REDACTED>
    Secret Permissions:
      Get
      List
    Tenant Id:  97fd3cb6-823b-<REDACTED>
  Init Provider:
    Object Id:
  Management Policies:
    *
  Provider Config Ref:
    Name:  provider-config-azure
Status:
  At Provider:
  Conditions:
    Last Transition Time:  2023-11-14T14:04:37Z
    Message:               observe failed: cannot run refresh: refresh failed: "/subscriptions/b6b4b75f-<REDACTED>/resourceGroups/simbachain-global-rg/providers/Microsoft.KeyVault/vaults/simbachain-global-vault/objectId/" didn't parse as either an Object ID ('{keyVaultId}/objectId/{objId}') or an Application ID ('{keyVaultId}/objectId/{objId}/applicationId/{appId}'):
    Reason:                ReconcileError
    Status:                False
    Type:                  Synced
Events:
  Type     Reason                         Age                     From                                                          Message
  ----     ------                         ----                    ----                                                          -------
  Warning  CannotObserveExternalResource  2m56s (x116 over 118m)  managed/keyvault.azure.upbound.io/v1beta1, kind=accesspolicy  cannot run refresh: refresh failed: "/subscriptions/b6b4b75f-<REDACTED>/resourceGroups/simbachain-global-rg/providers/Microsoft.KeyVault/vaults/simbachain-global-vault/objectId/" didn't parse as either an Object ID ('{keyVaultId}/objectId/{objId}') or an Application ID ('{keyVaultId}/objectId/{objId}/applicationId/{appId}')

Also note that this did not happen on "key vault access policy for managed identity" which has the same objectid mapping and is pretty similar.
➜ kubectl describe AccessPolicy.keyvault.azure.upbound.io policy-ezall-tst-opal-kv-mi-ap
Name:         policy-ezall-tst-opal-kv-mi-ap
Namespace:
Labels:       crossplane.io/claim-name=policy-ezall-tst-opal
              crossplane.io/claim-namespace=opal-policy-ezall-tst
              crossplane.io/composite=policy-ezall-tst-opal-m6rf8
Annotations:  crossplane.io/composition-resource-name: key vault access policy for managed identity
              crossplane.io/external-create-pending: 2023-11-14T14:07:39Z
              crossplane.io/external-create-succeeded: 2023-11-14T14:07:39Z
              crossplane.io/external-name: 2900fbba-f51c-43ac-a845-183813fc28d9
              upjet.crossplane.io/provider-meta:
                {"e2bfb730-<REDACTED>":{"create":1800000000000,"delete":1800000000000,"read":300000000000,"update":1800000000000}}
API Version:  keyvault.azure.upbound.io/v1beta1
Kind:         AccessPolicy
Metadata:
  Creation Timestamp:  2023-11-14T14:04:07Z
  Finalizers:
    finalizer.managedresource.crossplane.io
  Generate Name:  policy-ezall-tst-opal-m6rf8-
  Generation:     3
  Owner References:
    API Version:           azure.simbachain.com/v1beta1
    Block Owner Deletion:  true
    Controller:            true
    Kind:                  XOpal
    Name:                  policy-ezall-tst-opal-m6rf8
    UID:                   128e3edf-fa9f-<REDACTED>
  Resource Version:        34296443
  UID:                     82602968-bda1-<REDACTED>
Spec:
  Deletion Policy:  Orphan
  For Provider:
    Key Vault Id:  /subscriptions/b6b4b75f-<REDACTED>/resourceGroups/policy-ezall-tst-opal-rg/providers/Microsoft.KeyVault/vaults/policy-ezall-tst-opal-kv
    Key Vault Id Ref:
      Name:     policy-ezall-tst-opal-kv
    Object Id:  2900fbba-<REDACTED>
    Secret Permissions:
      Get
      List
      Set
    Tenant Id:  97fd3cb6-823b-<REDACTED>
  Init Provider:
    Object Id:
  Management Policies:
    *
  Provider Config Ref:
    Name:  provider-config-azure
Status:
  At Provider:
    Application Id:
    Id:              /subscriptions/b6b4b75f-<REDACTED>/resourceGroups/policy-ezall-tst-opal-rg/providers/Microsoft.KeyVault/vaults/policy-ezall-tst-opal-kv/objectId/2900fbba-<REDACTED>
    Key Vault Id:    /subscriptions/b6b4b75f-<REDACTED>/resourceGroups/policy-ezall-tst-opal-rg/providers/Microsoft.KeyVault/vaults/policy-ezall-tst-opal-kv
    Object Id:       2900fbba-<REDACTED>
    Secret Permissions:
      Get
      List
      Set
    Tenant Id:  97fd3cb6-823b-4578-ab45-226a5925ce05
  Conditions:
    Last Transition Time:  2023-11-14T14:07:39Z
    Reason:                ReconcileSuccess
    Status:                True
    Type:                  Synced
    Last Transition Time:  2023-11-14T14:08:42Z
    Reason:                Available
    Status:                True
    Type:                  Ready
    Last Transition Time:  2023-11-14T14:07:46Z
    Reason:                Success
    Status:                True
    Type:                  LastAsyncOperation
    Last Transition Time:  2023-11-14T14:07:46Z
    Reason:                Finished
    Status:                True
    Type:                  AsyncOperation
Events:                    <none>

How can we reproduce it?
apply the attached files
definition.txt
composition.txt
claim.txt
What environment did it happen in?

Crossplane Version: v1.12.2
Provider Version: provider-azure-keyvault:v0.38.2
Kubernetes Version: v1.26.6
Kubernetes Distribution: AKS

Workaround: delete the AccessPolicy. Upon recreation it was fine.

Thank you for raising this @emily-zall, is this issue still valid?

I'm closing this issue for now, if you still have the same or similar issue please feel free to reopen it with clear reproduction steps.

Hi @turkenf , I did run into this again today. My steps to reproduce are in the original description and my current versions are:
crossplane version v1.15.0
xpkg.upbound.io/upbound/provider-azure-keyvault:v0.38.2
Kubernetes distribution: AKS
Kubernetes version: 1.27.9


Flush buffer events when workflow close

Fail in flight decision & flush buffered events when workflow is timed out, terminated or retried (by continue as new)
Update mutable state AddTimeoutWorkflowEvent / AddWorkflowExecutionTerminatedEvent accordingly

Coverage increased (+0.3%) to 67.131% when pulling 126a972d3e8fe32ffa1aa64cd7f09bc5d5bef9b8 on flush-buffer-when-timeout-terminate into 5e00abe539c54be2617044ef16cd93f8c7610dbf on master.


Comand Line Category

Swiftline - Swiftline is a set of tools to help you create command line applications. :large_orange_diamond:

#570

Updated with Commander, created in issue #593

i'll close, ok?

@vsouza why did you close it?

I understood that was moved to another issue

sorry :cry:

@vsouza no problem! Now it's done. :smile:

heuehueheueh :+1:


Prebuilt binaries

Hi there!
Do you plan to create prebuilt (automated) binaries in the foreseeable future?
I'm running low on storage space on my computer, and it would be nice to be able to install RustPython easily without needing to build it ourselves. 😊
Thank you in advance.

This is a good suggestion. Could anyone please send a patch of github actions release?

@youknowone / @sn-o-w - saw this issue open and sent a PR: https://github.com/RustPython/RustPython/pull/5456
Could you folks take a look ? Cutting a new release on every merge to main for now - do we want to do something different ?

Ah, so at the moment release is only creating interpreter binaries without the full stdlib wired in.
You should be able to download the binary and run it as-is. But packaging in the stdlib needs more work atop this.


Client certificate mode

It would be great if etcdadm could allow nodes that are not going to be etcd members, but instead clients of etcd to be able to create their own certificates. I think it would add value so that one binary can handle all necessary etcd setup tasks.
I understand that distributing ca certs to non-etcd nodes is a "bad idea", but configuration management tools could benefit here.

I think being able to generate certs, similar to what kubeadm init phase certs does, is a good feature to have.
I also think the CA issue is orthogonal. If the CA is present, etcdadm should use it. But etcdadm should also be able to generate CSRs, and the user can get these signed by an external CA.


support build environment variable

This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.

Please fix CI issues.

Hi @snehapar9  @daniv-msft
Could you review and approve this PR?

Hi @zhoxing-ms, @yonzhan, could you pls help to review and merge the PR?

Hi @yanzhudd, could you pls help to review and merge the PR?

May I ask why to add java codes and SpringBoot to the tests?

May I ask why to add java codes and SpringBoot to the tests?
ACA cloud build service support build image from source code for java, so we add test case for java.


Attempting to scan NFC or barcode causes Android app to crash

Current Behaviour

React Capacitor app consistently crashes after attempting to scan NFC or barcodes using the examples provided. With NFC it just immediately crashes even if no tags are near and for barcode it crashes as soon as the camera detects a barcode.
Expected Behaviour

App should not crash and NFC tags/barcodes should be scanned.
Steps to Reproduce the Problem

Create project with boilerplate code for NFC and barcode
Build APK and install on Android device
Attempt to scan items

Context

Samsung S9, Android 10, Android Studio 2022.1.1 (Electric Eel), Gradle 7.4.1

Version: 0.5.0-beta.9
Platform: Android
Capacitor version: 4.6.3

Still having trouble with this. Not sure how relevant this is but if I run the code on browser, the functions return undefined. I assume that's just because there's no NFC hardware to access from the browser but I still felt it was worth pointing out in case it could help lead to the source of the issue.

I am using the most current release on Node, which is 0.5.0-beta.9. As for the required .aar files, they are actually in this repository under the android directory, although I plan on attempting to rebuild them and fix the error noted above.

I think I have experienced that before. If my memory serves me right, the cause of that error is using different .aar file. Are you using this files?

I'll be honest, I ended up just moving the project to React Native and using their NFC management plugin instead as it provides more features and stability out of the box. That being said, I still want to keep experimenting with this in my free time.

Hello @spencerAEE Thank you for creating this Ticket.
For NFC issue we have identified that it will crash automatically if NFC isn't turn on. We will fix this on the next release

@spencerAEE @nicholemnl this crash concerning NoSuchMethodError could mean that MLKit library is not present when you built the APK wtih the capacitor plugin.
This probably could be due to a number of things but from my experience I think it may be due to:

The MLKit library version built within the core-lib debug or release aars are not matching the MLKit library version added in https://github.com/newlogic/smartscanner-capacitor/blob/master/android/build.gradle#L99
The current built core-lib aars could be missing the MLKit libraries.

Hope this helps. 🙏🏻


Episode Idea: Cluster Autoscaler

i know this is a tool most of the ppl know and use but it could be still very interesting to get it explained again in detail and show its full potential:
https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

Great topic -- i'll be picking it up this week.
The process for producing an episode is here.  All the detail for the steps below is there.

[x] Pick a topic and create/use an issue in the repo
[x] If applicable coordinate with an upstream project if they're interested in attending the show
[x] Create the graphic
[ ] Schedule on Youtube
[ ] Add scheduled episode to TGIK playlist on YT
[ ] Create short link in rebrandly
[ ] Tweet about it from your personal account

[ ] Post tweets on internal #tgik slack channel and cc @castrojo and boschem
[ ] Get confirmation from boschem that she's seen the tweet and is scheduling it

Before episode:

[ ] Create HackMD page for live notes.  Start with README template in this repo
[ ] Paste HackMD URL on internal #tgik channel and cc @castrojo or other assistant

[ ] Assistant adds ~5-10 news items from around the web as possible "News of the Week"

[ ] Get everything tested well before episode so you can debug
[ ] Use internal slack channel to ensure that AV setup is good

After show (ideally right away but can wait until Monday):

Create/submit PR for this repo

[ ] Episode directory and README from hackmd
[ ] Any other files from the episode that might be useful
[ ] Update playlist.md with episode
Feel free to self merge

[ ] Edit YT description to point to episode directory here
[ ] OBS/OS Upgrade if applicable (Never on the day of a show)

nice. looking forward!

Closed with https://github.com/vmware-tanzu/tgik/pull/247/files
@jbeda / @mauilion : Can one of ya'll close this issue?


Problems while using mhchem

Hello Community,
I am using vue-cli as my develop tool. I was trying to use mhchem extension to enter the chemical formulas for my webapp, like the README said: "This extension isn't part of core KaTeX, so the script should be separately included.  Place it after the line that calls katex.js." I was trying to include it in index.html but failed ( I think the problem is because index.html is alive before the components in vue). I am willing to know how/where to include this extension in my webapp? Thanks for replying

Thanks for reaching out! I suspect that you're including the mchem extension from a CDN. This is likely the root cause of your issue. Instead of including the script through a CDN try importing the mchem extension where you installed vue-katex.
Try the following:
import Vue from "vue";
import VueKatex from "vue-katex";
import "katex/contrib/mhchem/mhchem";
import "katex/dist/katex.min.css";

Vue.use(VueKatex);

I hope this helps!
Cheers,
Jake


Overlays behave erratically when using Virtual Scrolling

What is the expected behavior?
Users should be able to utilize Virtual Scrolling with the Tree without worrying about other functionality breaking.
What is the current behavior?
When using Tooltips on Tree Nodes in combination with Virtual Scrolling, the Tooltips appear improperly without context.
What are the steps to reproduce?
Apply Virtual Scrolling to a Tree and then expose Tooltips on the Tree Node Definitions.
Demo - Mousing over any of the items in the Flat Tree should display a Tool Tip containing the Node's name, seemingly randomly it does accurately display the name in the proper place, most of the time you're left with a small gray box.
Edit: I have updated the demo to include a behavior where clicking on the text of a node will display a Snack Bar containing the node's name. This is also appearing as a gray bar at the top of the screen in many situations. This seems to be related to overlays as a whole in this context.

Hi @Daeluse ,
I've got exactly the same issue but I don't use Tree Nodes, I use angular-tree-component. Have you find any solution ?
Regards

Hi @Daeluse,
I think I have the same issue too but the stackblitz demo is no longer available to investigate more. Is it possible to restore it in any way?
T.i.a.

I'm having issue with change detection in material menu rendered inside of the tree with virtual scroll.
any ideas? @pfosser @Daeluse


Maybe unsound in as_bytes

https://github.com/CosmWasm/cosmwasm/blob/b5ee955e2f7b3f4ef4279151f4f3d23371f835b6/packages/std/src/memory.rs#L105
pub fn as_bytes(&self) -> &[u8] {
        unsafe { slice::from_raw_parts(self.offset as *const u8, self.length as usize) }
    }

I'm not sure if this code has an unsound problem, but it calls from_raw_parts without any checks. Although memory is a private mod, I decided to report the issue because I didn't see any //SAFETY to indicate this.

I'm pretty sure it's not unsound because the only way we create the Regions is from a Vec or from a slice which both should fulfill all the safety requirements.
But it's always a good idea to document this.


Update breadcrumbs.mdx

Fixing typo in breadcrumb documentation

Hey @saadriazkhan,
Thanks for contributing to material-tailwind, I'll publish this update on the upcoming update of the project.
Cheers,
Sajad

Merged to react/v2.0.0


Update managing-your-profile-readme.md and add beautify-github-profile

Why:
Hello
Hope you are great
I added beautify-github-profile  to this file so that others could have better GitHub profiles
Closes:

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@rzashakeri Hello! 👋 Thank you for taking the time to open this PR. I'll take this feedback to the team, but this seems to be something we would likely need to work on internally 💛
I'm going to go ahead and close this issue now. Thank you for your interest in improving the docs! ✨


Error when creating Cluster Role [Windows] [Kubernetes]

Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
Issue
What version of acs-engine?:
(Deployed using Azure Portal)

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes with windows worker nodes
kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.6", GitCommit:"7fa1c1756d8bc963f1a389f4a6937dc71f08ada2", GitTreeState:"clean", BuildDate:"2017-06-16T18:21:54Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}

What happened:
Error from server (Forbidden): error when creating "promethius-clusterrole.yaml": clusterroles.rbac.authorization.k8s.io "prometheus-operator" is forbidden: attempt to grant extra privileges: [{[*] [extensions] [thirdpartyresources] [] []} {[*] [apiextensions.k8s.io] [customresourcedefinitions] [] []} {[*] [monitoring.coreos.com] [alertmanagers] [] []} {[*] [monitoring.coreos.com] [prometheuses] [] []} {[*] [monitoring.coreos.com] [servicemonitors] [] []} {[*] [apps] [statefulsets] [] []} {[*] [] [configmaps] [] []} {[*] [] [secrets] [] []} {[list] [] [pods] [] []} {[delete] [] [pods] [] []} {[get] [] [services] [] []} {[create] [] [services] [] []} {[update] [] [services] [] []} {[get] [] [endpoints] [] []} {[create] [] [endpoints] [] []} {[update] [] [endpoints] [] []} {[list] [] [nodes] [] []} {[watch] [] [nodes] [] []} {[list] [] [namespaces] [] []}] user=&{kubeconfig  [system:authenticated] map[]} ownerrules=[] ruleResolutionErrors=[]
What you expected to happen:
It should create the clusterrole.
How to reproduce it (as minimally and precisely as possible):

Clone Prometheus-operator
Run "kubectl apply -f bundle.yaml"

Anything else we need to know:
I have tried binding cluster-admin role to kubernetes user but still the same issue.
Related Link: https://coreos.com/operators/prometheus/docs/latest/troubleshooting.html
Note:
I am using windows containers.
My main goal is to get Horizontal Pod Autoscaling working with windows containers.

This is ACS, not acs-engine. ACS does not currently support RBAC. It has made it into acs-engine recently, however.

@oivindoh Can you tell me when acs-engine new changes are pushed to ACS? And where I can find the list of supported kubernetes features in ACS and acs-engine?


Is key mapping to locate elements configurable

To locate an element using appium for mac, place the cursor and press fn key.
Is this key mapping configurable.
Running into issues while trying to locate elements on mac VM

Yes, this so much. I'm running into the same issue myself and its so frustrating because you cant send the function key thru VMWare.


Join with xlsx-renderer & xlsx-renderer-cli repositories

Monorepo
I've observe that I have difficulty maintaining several projects at once. It is that because of some purposes:

I have to have in mind where indeed issue is place,
I have to consider about where put new issues,
Both libraries has separated communities,
New repos for new packages included in spreadsheets topic will stay unpopular (with few stars amount) event if are awesome tool inside,
I really do not like having thousand of repos to maintain.

Because of that I decided to moving all my currents and further "spreadsheets" projects into monorepo. However on npm they still be published as separated packages.
Current

https://github.com/Siemienik/xlsx-import
https://github.com/Siemienik/xlsx-renderer
https://github.com/Siemienik/xlsx-renderer-cli
Further: https://github.com/Siemienik/xlsx-import-cli

After:
https://github.com/Siemienik/xtoolset
Paths:
.github/workflow/xlsx-import.yml
.github/workflow/xlsx-renderer.yml
.github/workflow/xlsx-renderer-cli.yml
.github/workflow/samples.yml
packages/xtoolset.   # hub with all packages in one (only reimport)
packages/xlsx-import
packages/xlsx-renderer
packages/xlsx-renderer-cli
samples/xlsx-import+nodejs
samples/[package]+[samplename]

I'm consider about using https://github.com/lerna/lerna

For some explanations I made two diagrams, one about how XToolsets may be used. Second, relationships and dependency flow:


Copy @interactors/html package from bigtest repository

Motivation
https://github.com/thefrontside/bigtest/issues/981
Approach
https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
I've used git-subtree for this type of chore before, but git-filter-repo is waaaaaaay faster to run.
All git history for packages/interactor in the bigtest repo should carry over here.
Next steps

Copy over the CI and tooling configs needed for this package from the bigtest repo root. I'm not planning to try and preserve git history for those, since their history will still be maintained in the other repo.
Turn on branch protections here.
Delete packages/interactor from the bigtest repo.

Is publishing set up to work on this repository?

Is publishing set up to work on this repository?

PR incoming.


Autocomplete is case sensitive

Commands like add_executable, etc, only autocomplete when you type in lowercase. As this is not a syntax requirement to use CMake, can autocomplete be case insensitive? I thought the extension was less than useful for a second because I would type 'ADD_EXECUTABLE' and it would never be found in the autocomplete list. Turns out my habit of writing CMake scripts in all caps isn't quite supported.

This is an issue for me as well. If someone wants to point me in the right direction I'd be happy to make the changes and submit at PR.

Hi,
This was by design because lower case is preferred in modern cmake guidelines.
If you want to change this behavior, look at cmXxxSuggestions calls in provideCompletionItems. It lookups the currentWord, if you lowercase currentWord, the promise will be resolved.
Then you should have to modify the result to uppercase the completion item.
I think it should do the job.


ci: fix dockerhub_sshnpd

- What I did
Same issue as #261
The dockerhub build for sshnpd was ignoring the working-directory and thus looking for the Dockerfile in the wrong place.
Removed the working-directory and added it directly to the context.
- How I did it
- How to verify it
- Description for the changelog
ci: fix dockerhub_sshnpd

Manually ran a docker build & push here to avoid having to draft a whole new release for v3.4.0.
https://github.com/atsign-foundation/sshnoports/tree/ci/manual-run-dockerhub-v3.4.0


Support Xcode 8

Update label tests to verify that LabelLayout produces the same results as UILabel. This is actually what we care about testing and makes the tests less fragile when a new version of iOS is released (they seem to tweak the sizes of emojis and font a lot).

Current coverage is 94.74% (diff: 96.55%)

Merging #37 into master will increase coverage by 0.18%

@@             master        #37   diff @@
==========================================
  Files            48         48
  Lines          2337       2341     +4
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2210       2218     +8
+ Misses          127        123     -4
  Partials          0          0

Powered by Codecov. Last update 7a1d226...fefa6b9

LGTM, but wonder if you want this in a different branch to master

This is compatible with Xcode 7. It ignores SWIFT_VERSION.


Added how-to-copy-a-list-of-my-lists-to-a-sharepoint-site

Category

[ ] Content fix
[x] New article

I wrote how to copy a list of My lists to a SharePoint site.

I noticed that another way to do this is to export a CSV with a schema and then create a list from that. I will draft this pull request once to add to that. Sorry😣

Sorry, I changed it to draft once by mistake😣


How to...

Hi there.
I have the below data.
I want to show the graph grouped on the date, with on that day there was high medium and low numbers.
Please can you advise how I can do this please?
Thanks in advance.
	, Count	 Date
 High	 16	 2016-10-03
 Medium	 14	 2016-10-03
 Low	 20	 2016-10-03
 High	 19	 2016-10-04
 Medium	 17	 2016-10-04
 Low	 12	 2016-10-04
 High	 22	 2016-10-05
 Medium	 15	 2016-10-05
 Low	 20	 2016-10-05
 High	 20	 2016-10-06
 Medium	 12	 2016-10-06
 Low	 14	 2016-10-06
 High	 9	 2016-10-07
 Medium	 16	 2016-10-07
 Low	 21	 2016-10-07
 High	 21	 2016-10-10
 Medium	 15	 2016-10-10
 Low	 25	 2016-10-10

This is more like a basic Highcharts-question, nevertheless I'd like to share my opinion with you. ;-)
This is how I would structure your data:
	high	medium	low
2016-10-03	16	14	20
2016-10-04	19	17	12
2016-10-05	22	15	20
2016-10-06	20	12	14
2016-10-07	9	16	21
2016-10-10	21	15	25

in customise tab:
chart settings > type > column
axes > x axis 1 > type > datetime
this results in a chart like: http://easychart.org/issues/58
interesting further reading material: http://www.highcharts.com/docs/chart-concepts/understanding-highcharts
Kind regards,
Thomas


Support for hasOwn

Hi Matt,
First, thanks for this great initiative. Keep rocking !
Small suggestion: what about adding support for Object.hasOwn ?
There's this thread for reference.

This is a great idea, but I'd prefer to rely on the TS team's decision instead of attempting to jump the gun.


[SPARK-21254] [WebUI] History UI performance fixes

What changes were proposed in this pull request?
As described in JIRA ticket, History page is taking ~1min to load for cases when amount of jobs is 10k+.
Most of the time is currently being spent on DOM manipulations and all additional costs implied by this (browser repaints and reflows).
PR's goal is not to change any behavior but to optimize time of History UI rendering:

The most costly operation is setting innerHTML for duration column within a loop, which is extremely unperformant. Refactoring  this helped to get page load time down to 10-15s

Second big gain bringing page load time down to 4s was was achieved by detaching table's DOM before parsing it with DataTables jQuery plugin.

Another chunk of improvements (1, 2, 3) was focused on removing unnecessary DOM manipulations that in  total contributed ~250ms to page load time.

How was this patch tested?
Tested by existing Selenium tests in org.apache.spark.deploy.history.HistoryServerSuite.
Changes were also tested on Criteo's spark-2.1 fork with 20k+ number of rows in the table, reducing load time to 4s.

Can one of the admins verify this patch?

Looks like you opened a duplicate of https://github.com/apache/spark/pull/18777

@srowen This one is for master branch, #18777 is for branch-2.1

It would have to go in master first so close the 2.1one

@srowen Done

Thank you @ajbozarth

It looks a lot simpler.

Could we try to run tests and build on Jenkins?

Jenkins test this please

Test build #80133 has started for PR 18783 at commit 4a61ac1.

Test build #80133 has finished for PR 18783 at commit 4a61ac1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80133/
Test PASSed.

Merged build finished. Test PASSed.

Thank you @srowen. Seems like jenkins is happy. Should we merge in this case?

Merged to master