Base class inheritance

This is an example implementation for base class inheritance.
It is related to https://github.com/FAIRmat-NFDI/nexus_definitions/pull/66
What we need to do:

[ ] Add support for inheritance in nyaml2nxdl
[ ] Support for resolving inherited base class, i.e., construct the full field list from a bc and its parents
[ ] The conversion understands that a sub-class inherits from its parent and such can be replaced, e.g., that a NXbeam group can be filled with, e.g., the path /ENTRY[entry]/BEAM_OPTICAL[beam].

[ ]  Support using base classes in the path, e.g., we want to be able to write /ENTRY[entry]/NXBEAM_OPTICAL[beam] if we want to use an NXbeam_optical if an NXbeam is demanded, but the converter should check all the fields of NXbeam_optical

The converter already picks up on this. It's just that it will nexus.get_node_at_nxdl_path with the following NXDL path:
/ENTRY/BEAM_OPTICAL.
We need to make sure nexus.py understands that NXbeam_optical inherits from NXbeam and such can be replaced.
But is this what we want? Do we want to allow specialized beams be used in AppDefs that list the parent beam? Also, then do we allow using a different specialized beam or just the parent?

We need to make sure nexus.py understands that NXbeam_optical inherits from NXbeam and such can be replaced.

Yes, I think this is the better formulation of this point. I will update it.

But is this what we want? Do we want to allow specialized beams be used in AppDefs that list the parent beam? Also, then do we allow using a different specialized beam or just the parent?

I would say yes. It should be possible to use any sub-class for a parent class (e.g., for NXbeam any of NXbeam_optical, NXbeam_electron, NXbeam_neutron, ...). IMO this inheritance should also always be compatible, e.g. NXbeam_optical has all the same fields required and recommended as NXbeam but just adds some more. If we demand a specalized class only this specialized class should be allowed (e.g., NXbeam_optical).

IMO this inheritance should also always be compatible, e.g. NXbeam_optical has all the same fields required and recommended as NXbeam but just adds some more.

We will then need scripts to make sure we set up such compatibilty at all times. This can be hectic especially if I want to have a more specialized NXbeam_optical that switches around a bunch of stuff. The framework then should be able to either reject such changes and explain why or provide it as an incompatible to an NXbeam entry during writing.
I also want to bring another point which always puzzles me with NeXus: Why don't we tell what base class/type we exactly used in the data instance aka the h5 file. Currently, we only provide an AppDef and the framework has to resolve the rest of the dataset types using the AppDef as a source of truth. This means whenever I would like to add another group that is used in another technique or so, I have to go and make a new AppDef. This seems to have been designed for applications to know exactly what to expect. But my argument for that is that we can easily write an application that looks through the h5 file with its pointers to what type/concept every dataset is. And then act upon it if it knows how to deal with this concept. If it doesn't, it just ignores it for specialized functionality but still provides access to the user if they know what to do with it. The entanglement of data instance/storage structure dictating what concept we are dealing with is quite a hassle.
With the above strategy, one can easily use NXbeam_optical or whatever they like. If the app understands it aka finds compatible fields in this group, it works with it. But if it doesn't, then it ignores it.

IMO this inheritance should also always be compatible, e.g. NXbeam_optical has all the same fields required and recommended as NXbeam but just adds some more.

We will then need scripts to make sure we set up such compatibilty at all times. This can be hectic especially if I want to have a more specialized NXbeam_optical that switches around a bunch of stuff. The framework then should be able to either reject such changes and explain why or provide it as an incompatible to an NXbeam entry during writing.

That's why I would mainly use inheritance for adding additional fields to the parent class and not renaming or moving anything (because this changes our notion of the information contained in this class). The question is when we write it as NXbeam_optical and it does not conform to it, do we allow to set it to NXbeam (if allowed by the appdef) if this is fulfilled and show a warning or do we rather abort the whole process?

I also want to bring another point which always puzzles me with NeXus: Why don't we tell what base class/type we exactly used in the data instance aka the h5 file.

This information is written, no? There is the NX_class attribute which collects which class we write. Consuming applications could use this field to understand which class it is dealing with.

Currently, we only provide an AppDef and the framework has to resolve the rest of the dataset types using the AppDef as a source of truth. This means whenever I would like to add another group that is used in another technique or so, I have to go and make a new AppDef.

This is one of my main reasons to have base class inheritance. With this appdefs can be as easy as just stating which combination of classes I expect. We even could go towards a generic experiment which we manually compose. However, we just offload the specifics into the base classes then (i.e., we would still want to require certain fields for an, e.g., mpes experiment with a collection of fields we don't want to (re-)use in any other experiment). I would also argue that our current process is removing the differences between appdefs and base classes, except that we still name them such.

This seems to have been designed for applications to know exactly what to expect. But my argument for that is that we can easily write an application that looks through the h5 file with its pointers to what type/concept every dataset is. And then act upon it if it knows how to deal with this concept. If it doesn't, it just ignores it for specialized functionality but still provides access to the user if they know what to do with it. The entanglement of data instance/storage structure dictating what concept we are dealing with is quite a hassle.

We really can push towards trying also having a generic representation without relying on an appdef (or only a generic appdef, or not using the terms of appdefs and base classes anymore and just consider them using the same modeling principles). And I tend to like this idea as it gets closer to what is done in owl, that is, only relating some properties to an experiment. But again, I think we just offload the variability into the base class taxonomy.

With the above strategy, one can easily use NXbeam_optical or whatever they like. If the app understands it aka finds compatible fields in this group, it works with it. But if it doesn't, then it ignores it.

I think these are all good points. I think we should just discuss/test some of them and see which one works best for us. I'm currently reading also a bit in owl/ontologies modelling so maybe I can draw some inspiration from this as well.

That's why I would mainly use inheritance for adding additional fields to the parent class and not renaming or moving anything (because this changes our notion of the information contained in this class). The question is when we write it as NXbeam_optical and it does not conform to it, do we allow to set it to NXbeam (if allowed by the appdef) if this is fulfilled and show a warning or do we rather abort the whole process?

So you mean that an AppDef asks for an NXbeam_optical but a user provides an NXbeam in the data? I think we should discuss this over a meeting when we have a consensus on the examples you've setup on the definitions repo. I would say if NXbeam_optical is incompatible with NXbeam then we cannot just accept an NXbeam as the data. But I'm not too confident with this. I need more clarification.

This information is written, no? There is the NX_class attribute which collects which class we write. Consuming applications could use this field to understand which class it is dealing with.

The resolution depends on how we modify that NX_class in our AppDef. If we change the doc string etc or we add fields to it this becomes a separate entity in the AppDef than what it is in the base class. I think with this base_class inheritance this will become simpler as we can take the specialized base class and list it in the AppDef rather than modifying it there. The only limitation would be that some fields could be named the same in different groups. Their meaning comes from their hierarchy. That is much easier to handle if we have direct pointers for every single field. So I could mix match my data and still point to the right concept.

This is one of my main reasons to have base class inheritance. With this appdefs can be as easy as just stating which combination of classes I expect. We even could go towards a generic experiment which we manually compose. However, we just offload the specifics into the base classes then (i.e., we would still want to require certain fields for an, e.g., mpes experiment with a collection of fields we don't want to (re-)use in any other experiment). I would also argue that our current process is removing the differences between appdefs and base classes, except that we still name them such.

I agree with you. The current AppDefs seem to be an unnecessary limitation. If we have good base classes, any combination of them can be read correctly and understood. AppDefs would just be our h5 files using these base classes.

We really can push towards trying also having a generic representation without relying on an appdef (or only a generic appdef, or not using the terms of appdefs and base classes anymore and just consider them using the same modeling principles). And I tend to like this idea as it gets closer to what is done in owl, that is, only relating some properties to an experiment. But again, I think we just offload the variability into the base class taxonomy.

With the above strategy, one can easily use NXbeam_optical or whatever they like. If the app understands it aka finds compatible fields in this group, it works with it. But if it doesn't, then it ignores it.

I think these are all good points. I think we should just discuss/test some of them and see which one works best for us. I'm currently reading also a bit in owl/ontologies modelling so maybe I can draw some inspiration from this as well.

It will be nice to experiment with this. Please share some resources if you find something interesting. Thanks!

That's why I would mainly use inheritance for adding additional fields to the parent class and not renaming or moving anything (because this changes our notion of the information contained in this class). The question is when we write it as NXbeam_optical and it does not conform to it, do we allow to set it to NXbeam (if allowed by the appdef) if this is fulfilled and show a warning or do we rather abort the whole process?

So you mean that an AppDef asks for an NXbeam_optical but a user provides an NXbeam in the data? I think we should discuss this over a meeting when we have a consensus on the examples you've setup on the definitions repo. I would say if NXbeam_optical is incompatible with NXbeam then we cannot just accept an NXbeam as the data. But I'm not too confident with this. I need more clarification.

No. My thought was, that the appdef requires an NXbeam and we might enter some data as /ENTRY[entry]/BEAM_OPTICAL[beam] to denote, that we want to enter the more specific form of NXbeam_optical into an NXbeam group. What happens now if the /entry/beam group does not contain all the fields required by NXbeam_optical, but all fields required by NXbeam. Do we downgrade to NXbeam and warn the user about the process or do we abort the conversion process?
IMO an NXbeam should never be allowed to replace NXbeam_optical if it is required in the appdef. Except for when NXbeam_optical is empty and thus equivalent to NXbeam. But we might want to carry some information from using an empty subclass (e.g., like the empty NXbeam_electron in this PR). In the ontology world this would make sense, but I don't know if we want such thing in nexus.

This information is written, no? There is the NX_class attribute which collects which class we write. Consuming applications could use this field to understand which class it is dealing with.

The resolution depends on how we modify that NX_class in our AppDef. If we change the doc string etc or we add fields to it this becomes a separate entity in the AppDef than what it is in the base class. I think with this base_class inheritance this will become simpler as we can take the specialized base class and list it in the AppDef rather than modifying it there. The only limitation would be that some fields could be named the same in different groups. Their meaning comes from their hierarchy. That is much easier to handle if we have direct pointers for every single field. So I could mix match my data and still point to the right concept.

The easiest would be to tell the writer which classname to write to NX_class, like in the example above.
It's another benefit of having base class taxonomies. We can just simply build a general concept and reuse it without recreating some anonymous classes (as I would call what is happening rn when we extend the base classes in appdefs).

This is one of my main reasons to have base class inheritance. With this appdefs can be as easy as just stating which combination of classes I expect. We even could go towards a generic experiment which we manually compose. However, we just offload the specifics into the base classes then (i.e., we would still want to require certain fields for an, e.g., mpes experiment with a collection of fields we don't want to (re-)use in any other experiment). I would also argue that our current process is removing the differences between appdefs and base classes, except that we still name them such.

I agree with you. The current AppDefs seem to be an unnecessary limitation. If we have good base classes, any combination of them can be read correctly and understood. AppDefs would just be our h5 files using these base classes.

Yes, we still might want to have some notion of an experiment, i.e., as a collection of N scan-axis with M sensors at each scan point + sample + operator + instrument. But we could combine it as we like with what we scan and what instrument we use.

We really can push towards trying also having a generic representation without relying on an appdef (or only a generic appdef, or not using the terms of appdefs and base classes anymore and just consider them using the same modeling principles). And I tend to like this idea as it gets closer to what is done in owl, that is, only relating some properties to an experiment. But again, I think we just offload the variability into the base class taxonomy.

With the above strategy, one can easily use NXbeam_optical or whatever they like. If the app understands it aka finds compatible fields in this group, it works with it. But if it doesn't, then it ignores it.

I think these are all good points. I think we should just discuss/test some of them and see which one works best for us. I'm currently reading also a bit in owl/ontologies modelling so maybe I can draw some inspiration from this as well.

It will be nice to experiment with this. Please share some resources if you find something interesting. Thanks!

I think the W3C primers on rdf, rdfs and owl are very extensive. Currently I'm reading this book which is very nice to get an overview.

I did not follow all the discussions so far, but I somehow have the feeling that we should separate two things in the discussion:

the base class inheritance (which I support very much)
the introduction of required fields into base classes (which I am not so sure we should do)
The reason for doing the second is not so eminentily clear to me, as indeed it somewhat mixes the purpose of application definition and base classes, and I think there are very good reasons so have the two. We should think very carefully about why we want to introduce requirements in the first place, because any requirement very severely limits the usability of everything we crease, as we have seen in the discussion at the mpes-workshop.

I did not follow all the discussions so far, but I somehow have the feeling that we should separate two things in the discussion:

the base class inheritance (which I support very much)
the introduction of required fields into base classes (which I am not so sure we should do)

My feeling is that having a base class inheritance without having required fields does not solve too much. Essentially, we simply add some additional vocabulary in an additional file. While I see that this can declutter our glossary a little it does not give us the notion of something representing an entity (e.g., a detector). We could very well use a class and its subclass interchangeably and just requiring the same fields in an appdef. For me it feels just adding some more files and complicating where a person has to look for glossary terms when writing or reading an appdef without adding any logical abstraction.

The reason for doing the second is not so eminentily clear to me, as indeed it somewhat mixes the purpose of application definition and base classes, and I think there are very good reasons so have the two. We should think very carefully about why we want to introduce requirements in the first place, because any requirement very severely limits the usability of everything we crease, as we have seen in the discussion at the mpes-workshop.

I agree that it is good to have a glossary of terms as we currently have it in the base classes. And I'm not fully arguing that we should get rid of the base classes entirely (even though we can discuss whether we can collect glossary terms also in a hierarchical way). Besides this fact, it is not so evident to me that its good to have the distinction of base classes and appdefs. We had several occurrences in the past where we had problems due to their nature, here are some of the problems we already had (which is not a complete list):

Reusing something from an appdef, that is, reusing something which requires some fields to be present, is not really possible. We typically have to copy everything by hand, which is error-prone, slow and hard to maintain.
We cannot give the notion of something as a part of, e.g., an instrument, as we cannot really build an NXdetector without an application definition (I know we can do it when we collect the specific "anonymous" group from the appdef - but how would we write this in a file?). However, I think we need such a feature to be able to properly write parts of an instrument, e.g., an instrument just collecting an NXdetector part.
For people new to nexus the different required/optional defaults are often confusing.
We cannot really interchange something more general with something more specific if we have additional information at runtime. Like inserting a more specific NXccd for an NXdetector.

I think the last point is a crucial one for the requirements you mention. I think we agree that we have to require some fields, but not too much to not be too restrictive. With a taxonomy we can build a very general top-level class where we don't require much and then add more and more specifics into the sub-classes. This is the point where a general glossary might be useful, because we might want to add only one specific field to the parent class, but we don't have everything available for a specific sub-class. We still want to write this field properly defined and show that its part of this taxonomy.
We could also keep the current base classes entirely but simply add this taxonomy features we are currently thinking about as an additional layer in between appdefs and base classes. In this case the base classes would give us the vocabulary for a taxonomy and an appdef would basically just be a specific class in the taxonomy which we attach the notion of being a standardised data collection. This would also allow to be compatible with the current way things are in nexus and we could seamlessly add taxonomies where we need it.

Reusing something from an appdef, that is, reusing something which requires some fields to be present, is not really possible. We typically have to copy everything by hand, which is error-prone, slow and hard to maintain.

It is possible by appdef inheritance, but I agree it's probably not elegant, if it only applies to a small part of the tree

We cannot give the notion of something as a part of, e.g., an instrument, as we cannot really build an NXdetector without an application definition (I know we can do it when we collect the specific "anonymous" group from the appdef - but how would we write this in a file?). However, I think we need such a feature to be able to properly write parts of an instrument, e.g., an instrument just collecting an NXdetector part.

Well, I think we do that e.g. with NXelectronanalyzer, which has NXdetectioncolumn, NXenergydispersion, etc. as parts, no? That's all defined in the base classes, it would be sufficient to even only cite NXintrument.

For people new to nexus the different required/optional defaults are often confusing.

One could just write optionality everywhere explicitly, that can easily be done with the yaml2nxdl

We cannot really interchange something more general with something more specific if we have additional information at runtime. Like inserting a more specific NXccd for an NXdetector.

Okay, I think I understand your point now. You want to cite NXbeam, and have every subclass require a few fields to specify as e.g. NXbeam_poalized, and only if these fields are present, you are allowed to replace NXbeam by NXbeam_polarized, right? In principle, that is not a bad idea, as it would allow to build very generic applications, that could work based on the existence of these specialized versions of the generic base classes. Still, we need to make sure to not restrict the file format too much, and not require unnecessary fields in the "base" version of our taxonomy.

Reusing something from an appdef, that is, reusing something which requires some fields to be present, is not really possible. We typically have to copy everything by hand, which is error-prone, slow and hard to maintain.

It is possible by appdef inheritance, but I agree it's probably not elegant, if it only applies to a small part of the tree

It's also relevant between different methods, i.e., most experiments have some form of detector or sensor without having an inheritance between themselves (even though we have to ask whether different detectors in different fields have some commonality or should remain in their specific domain - but there are other examples, e.g., NXsample).

We cannot give the notion of something as a part of, e.g., an instrument, as we cannot really build an NXdetector without an application definition (I know we can do it when we collect the specific "anonymous" group from the appdef - but how would we write this in a file?). However, I think we need such a feature to be able to properly write parts of an instrument, e.g., an instrument just collecting an NXdetector part.

Well, I think we do that e.g. with NXelectronanalyzer, which has NXdetectioncolumn, NXenergydispersion, etc. as parts, no? That's all defined in the base classes, it would be sufficient to even only cite NXintrument.

I mean it slightly different here. We have this different classes, yes. However, one could not just build an NXenergydispersion without getting the requirements from the appdef. With what I have in mind we would have a base class which automatically requires the fields to be a proper NXenergydispersion and we would just have to state in the appdef that we want one of such NXenergydispersions. The benefit is that an application could just write an NXenergydispersion which is in compliance with NXmpes without ever needing to know about NXmpes (I know we could just require additional fields in the base class. This is admittedly still a problem here, because we always need to build the union between a class or one of it's possible subclasses and the required fields in the appdef). Currently, we can only do it by using the NXmpes/NXinstrument/NXenergydispersion class somewhere.

For people new to nexus the different required/optional defaults are often confusing.

One could just write optionality everywhere explicitly, that can easily be done with the yaml2nxdl

That's true. I also have to admit that part of the confusion is also about how the web view of our definitions is structured and that everything is nested and one has to know that there is relevant information somewhere else. So this might rather be a point of documentation.

We cannot really interchange something more general with something more specific if we have additional information at runtime. Like inserting a more specific NXccd for an NXdetector.

Okay, I think I understand your point now. You want to cite NXbeam, and have every subclass require a few fields to specify as e.g. NXbeam_poalized, and only if these fields are present, you are allowed to replace NXbeam by NXbeam_polarized, right? In principle, that is not a bad idea, as it would allow to build very generic applications, that could work based on the existence of these specialized versions of the generic base classes. Still, we need to make sure to not restrict the file format too much, and not require unnecessary fields in the "base" version of our taxonomy.

Exactly. Yes, we have to be careful to not require to much if we are far up in the tree. But I think when we carefully design this, it can be extremely helpful. I also would like this glossary+taxonomy approach as this would allow us to test and change stuff without breaking any of our current definitions. Because I think we need to do a few iterations to get a good solution which balances requiredness and optionality.

The benefit is that an application could just write an NXenergydispersion which is in compliance with NXmpes without ever needing to know about NXmpes

I very much want this. It will also help us with comparing/searching across data. We know that no matter where we find this entity, it's supposed to be read and written in the same way.


post reports and junit client implementation in bash

should support post tg gz for junit and storage html
should only use bash
only needs to handle single stage / report dir / junit initially (can add shell scripts for other stages later)

done


[Function Views] Add function views to the project

Description
Implement base URL paths for the project:

/                     : task list view
/create/              : task create view
/<int:pk>/            : task detail view
/<int:pk>/complete/   : task complete view
/<int:pk>/update/     : task update view
/<int:pk>/delete/     : task delete view
/profile/             : user profile view
/sign-up/             : sign up view
/sign-in/             : sign in view
/logout/              : logout view

DoD
URL are available and serve incoming request properly.

task complete view should implement swap status behavior. This will be implemented via REST API in the future via #2.


UTF-16 encoded .txt files aren't parsed

This is not quite a bug... but it did bug me. 😉
After a few hours looking into an issue where PlaceholderAPI refused to parse some .txt files in the shortcuts folder, I found that these files had in common that I had written them in UTF-16 encoding. Switching to UTF-8 instead resolved my issue.
I figured I might as well mention this here, hoping it helps someone else.
Thank you for maintaining shortcut! It's been a game changer for placeholders.

Yeah. Not really something I could probably fix here... And also no real reason to have this issue opened to begin with.


include: kernel: Add macro to avoid stack overhead

When CONFIG_USER_SPACE is enabled threads end up allocating space for a privileged stack.
When a thread will run in kernel mode, this extra space is not needed.
k_thread_create() allows to make this distinction passing an object defined using K_KERNEL_STACK_DEFINE macro.
https://docs.zephyrproject.org/3.1.0/kernel/services/threads/index.html#kernel-only-stacks
K_THREAD_DEFINE macro does not allow to make the same distinction.
Need an additional macro to be able to define threads intended to run always in kernel mode.

So, first, new public APIs need docs so readers understand what the purpose of an API is. Which brings me to...
I don't quite understand the purpose of this API. A thread with a priviledged stack is a user mode thread, one without is a kernel thread. It seems like you're just creating a new kind of kernel thread and naming it "supervisory thread"?
Are you just trying to have a THREAD_DEFINE() macro for static kernel threads? If so, why not name it K_KERNEL_THREAD_DEFINE(), and adjust the scheme in the headers such that it shares the same implementation with a non-userspace K_THREAD_DEFINE()?

I think the problem trying to be addressed here is that we always end up allocating space for a privileged stack in all threads when userspace is enabled. If you know that a thread will always run in kernel mode this extra space is not needed. Sounds reasonable to me this, but there are things missing, we need to put this info into the thread so if one tries to move it to usermode it properly fails. Right now you are just avoiding the additional "privileged stack" memory allocation but what happens if we try to make it an usermode thread ?
The names are really confusing, regarding sharing code it will need to change those macros if I remember correctly.

So, first, new public APIs need docs so readers understand what the purpose of an API is. Which brings me to...
I don't quite understand the purpose of this API. A thread with a priviledged stack is a user mode thread, one without is a kernel thread. It seems like you're just creating a new kind of kernel thread and naming it "supervisory thread"?
Are you just trying to have a THREAD_DEFINE() macro for static kernel threads? If so, why not name it K_KERNEL_THREAD_DEFINE(), and adjust the scheme in the headers such that it shares the same implementation with a non-userspace K_THREAD_DEFINE()?

Updated the PR comment with a clearer intention (i hope), added documentation to use KERNEL_THREAD to keep it inline with stack naming convention in https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/kernel.h#L285
K_THREAD_STACK_DEFINE() - For stacks that may support either user or

supervisor threads.

K_KERNEL_STACK_DEFINE() - For stacks that may support supervisor

threads only. These stacks use less memory if CONFIG_USERSPACE is
enabled.

So, first, new public APIs need docs so readers understand what the purpose of an API is. Which brings me to...
I don't quite understand the purpose of this API. A thread with a priviledged stack is a user mode thread, one without is a kernel thread. It seems like you're just creating a new kind of kernel thread and naming it "supervisory thread"?
Are you just trying to have a THREAD_DEFINE() macro for static kernel threads? If so, why not name it K_KERNEL_THREAD_DEFINE(), and adjust the scheme in the headers such that it shares the same implementation with a non-userspace K_THREAD_DEFINE()?

I think the problem trying to be addressed here is that we always end up allocating space for a privileged stack in all threads when userspace is enabled. If you know that a thread will always run in kernel mode this extra space is not needed. Sounds reasonable to me this, but there are things missing, we need to put this info into the thread so if one tries to move it to usermode it properly fails.

@ceolin  Isn't passing a kernel-only stack enough to guarantee that?  https://docs.zephyrproject.org/3.1.0/kernel/services/threads/index.html#kernel-only-stacks

Right now you are just avoiding the additional "privileged stack" memory allocation but what happens if we try to make it an usermode thread ?
The names are really confusing, regarding sharing code it will need to change those macros if I remember correctly.

@ceolin could you elaborate about the kind of conditions to check. I'm not familiar with this Zephyr mechanism, can threads defined this way be updated dynamically to use a different stack or do you mean compilation time?

You will need some mechanisms to prevent such a thread from entering user mode via k_thread_user_mode_enter().

You will need some mechanisms to prevent such a thread from entering user mode via k_thread_user_mode_enter().

Actually I think that's OK?  I mean, it won't work and will surely panic the system, but it's a call that only works from kernel mode anyway.   It's no different than a thread created without the USER flag via k_thread_create().

Actually I think that's OK? I mean, it won't work and will surely panic the system, but it's a call that only works from kernel mode anyway. It's no different than a thread created without the USER flag via k_thread_create().

k_thread_user_mode_enter() adds K_USER to the thread option and will make the current running kernel thread into a user thread. For example, z_main_stack is "user capable" so you can make the main thread (with K_USER) into a user thread without any issue. The z_stack_is_user_capable() is going to return true because the stack object appears in the kobject list (even for stacks used for kernel threads). So without all the extra space needed for user thread stacks, it is possible different threads under a domain can corrupt each others' stacks. I think it is better to have some extra checks to deny user mode entry if it is a strict kernel-only thread.

I think the original idea is that you can have a kernel thread running all the necessary code to grant access to various kernel objects, and then turns itself into user thread. So there is no need to have separate threads granting access, and thus no need to manually serialize execution. Hence the "backend" does not really distinguish between kernel and user threads. This will need some time to unravel.


feat: Add strings as option for list following meta

I was reading through some of the GNU Assembler docs for another project and realized I should have included strings as an option for the sequences supported in my last PR. This simply adds a sequence of strings as an option in addition to ints and floats.
Not related to this PR, but I was looking into writing some basic tree-sitter tests for some of the existing features of the grammar. Would this be helpful?

Thanks!

Not related to this PR, but I was looking into writing some basic tree-sitter tests for some of the existing features of the grammar. Would this be helpful?

Yes, that would be awesome.


Encryption page for ADLS Gen 2 is missing

There doesn't appear to be an equivalent page for talking about the details for encryption for ADLS Gen2 as Gen 1
https://docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-encryption
Can we assume the same information applies for ADLS Gen 2?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 41611e5e-da21-39f8-19ca-e5b53752e8d7
Version Independent ID: 4fa3f560-5d8f-6a91-27ae-add26ea87ff4
Content: Encryption in Azure Data Lake Storage Gen1
Content Source: articles/data-lake-store/data-lake-store-encryption.md
Service: data-lake-store
GitHub Login: @esung22
Microsoft Alias: yagupta

Including some folks on the ADLS Gen2 team.
From: JosephCason<EMAIL_ADDRESS>Sent: Thursday, August 1, 2019 8:22 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Ellick Sung<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: [MicrosoftDocs/azure-docs] Encryption page for ADLS Gen 2 is missing (#36328)
There doesn't appear to be an equivalent page for talking about the details for encryption for ADLS Gen2 as Gen 1
https://docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-encryptionhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fdata-lake-store%2Fdata-lake-store-encryption&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164929725&sdata=oBN83KG1AP6GSQa1OCW0s1dyGf5Fzvp3cytKGu17LLY%3D&reserved=0
Can we assume the same information applies for ADLS Gen 2?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 41611e5e-da21-39f8-19ca-e5b53752e8d7
Version Independent ID: 4fa3f560-5d8f-6a91-27ae-add26ea87ff4
Content: Encryption in Azure Data Lake Storage Gen1https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fdata-lake-store%2Fdata-lake-store-encryption%23feedback&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164939726&sdata=k2U%2B%2FWp3gYmSeTqaTDMYGsOKSgas%2F4CPZukCLlldKEo%3D&reserved=0
Content Source: articles/data-lake-store/data-lake-store-encryption.mdhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fazure-docs%2Fblob%2Fmaster%2Farticles%2Fdata-lake-store%2Fdata-lake-store-encryption.md&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164939726&sdata=WJvGjjhqwaWtYbbAvBpjaXmeTjlL2C0lrAy6HnMgeTc%3D&reserved=0
Service: data-lake-store
GitHub Login: @esung22https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fesung22&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164949717&sdata=DKH3pNg4NVUZhWgbSxXZVxtzDHQW5fTgc1C4MLpk7F0%3D&reserved=0
Microsoft Alias: yagupta

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36328%3Femail_source%3Dnotifications%26email_token%3DADR7YJM766K3DRS2VJ7KOCTQCL5RHA5CNFSM4IIRZWCKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HC3JIGA&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164949717&sdata=WaTxVWDlEvO69vozJYnnh%2FoonnWiViVNNqaM%2FCpZDPM%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADR7YJISZTRBXQNGAJ5GRELQCL5RHANCNFSM4IIRZWCA&data=02|01|elsung%40microsoft.com|44533228189542691bdf08d71693fcbd|72f988bf86f141af91ab2d7cd011db47|1|0|637002697164959717&sdata=bfS4kG%2FfhFgM3HzNSo3qVdW9WHuKeHyJPZ%2B8l6%2BvIt8%3D&reserved=0.

Here is the ADLS Gen2 security documenthttps://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json which includes encryption.  Thanks!
Stephen
From: Ellick Sung<EMAIL_ADDRESS>Sent: Thursday, August 1, 2019 8:33 AM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Sachin Sheth<EMAIL_ADDRESS>Stephen Wu<EMAIL_ADDRESS>James Baker (XSTORE<EMAIL_ADDRESS>Cc: Mention<EMAIL_ADDRESS>Subject: RE: [MicrosoftDocs/azure-docs] Encryption page for ADLS Gen 2 is missing (#36328)
Including some folks on the ADLS Gen2 team.
From: JosephCason <notifications<EMAIL_ADDRESS>Sent: Thursday, August 1, 2019 8:22 AM
To: MicrosoftDocs/azure-docs <azure-docs<EMAIL_ADDRESS>Cc: Ellick Sung <elsung<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Subject: [MicrosoftDocs/azure-docs] Encryption page for ADLS Gen 2 is missing (#36328)
There doesn't appear to be an equivalent page for talking about the details for encryption for ADLS Gen2 as Gen 1
https://docs.microsoft.com/en-us/azure/data-lake-store/data-lake-store-encryptionhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fdata-lake-store%2Fdata-lake-store-encryption&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676504372&sdata=53O5o82i7ZLQ7L7H4ZtDAAYFmcqS3PyYQiYpIxStTkE%3D&reserved=0
Can we assume the same information applies for ADLS Gen 2?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 41611e5e-da21-39f8-19ca-e5b53752e8d7
Version Independent ID: 4fa3f560-5d8f-6a91-27ae-add26ea87ff4
Content: Encryption in Azure Data Lake Storage Gen1https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fdata-lake-store%2Fdata-lake-store-encryption%23feedback&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676504372&sdata=vpOeO6N8JNrb0xfASKOrYWaiYpONEtFEWYORKg0rooU%3D&reserved=0
Content Source: articles/data-lake-store/data-lake-store-encryption.mdhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fazure-docs%2Fblob%2Fmaster%2Farticles%2Fdata-lake-store%2Fdata-lake-store-encryption.md&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676514366&sdata=Gd%2B93CmA9P5XbKOOgP%2F7UJg7xoE7PM%2F2WUo2UkqirQE%3D&reserved=0
Service: data-lake-store
GitHub Login: @esung22https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fesung22&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676514366&sdata=Fzf76SodGvZma7Njyx75%2BVgC4CTU8TlSYlj8aNnSjBU%3D&reserved=0
Microsoft Alias: yagupta

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36328%3Femail_source%3Dnotifications%26email_token%3DADR7YJM766K3DRS2VJ7KOCTQCL5RHA5CNFSM4IIRZWCKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HC3JIGA&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676524361&sdata=5usRVtfxeK%2B7kaqwZijt4mvGpDdR84W6NR6YEAPTrWU%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADR7YJISZTRBXQNGAJ5GRELQCL5RHANCNFSM4IIRZWCA&data=02|01|stewu%40microsoft.com|630db8893abd4c7219b908d716957e89|72f988bf86f141af91ab2d7cd011db47|1|0|637002703676524361&sdata=hF10tOObzWm5HICMaK%2FzTky9YSkn5W6yp8goaZcGORU%3D&reserved=0.

@JosephCason Please refer to the doc shared by @esung22 and do let us know if you have any further query.
https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json

Can you please remove my alias from this document, I am not on the ADLS team anymore.
Stephen Wu provided the document, including him.
From: KranthiPakala-MSFT<EMAIL_ADDRESS>Sent: Thursday, August 1, 2019 12:31 PM
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Ellick Sung<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Encryption page for ADLS Gen 2 is missing (#36328)
@JosephCasonhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJosephCason&data=02|01|elsung%40microsoft.com|fa1c68e392b6402613ca08d716b6c255|72f988bf86f141af91ab2d7cd011db47|1|0|637002846512581672&sdata=Ftfn4uGqwchlOEmCj8SkSLdu2iRfVjti4xVyC%2BQVXS0%3D&reserved=0 Please refer to the doc shared by @esung22https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fesung22&data=02|01|elsung%40microsoft.com|fa1c68e392b6402613ca08d716b6c255|72f988bf86f141af91ab2d7cd011db47|1|0|637002846512581672&sdata=JkaP9HO93JRFOk3PbMj5AC%2BkGVh%2F5ixPEUnTLGk9AK8%3D&reserved=0 and do let us know if you have any further query.
https://docs.microsoft.com/en-us/azure/storage/common/storage-security-guide?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.jsonhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fstorage%2Fcommon%2Fstorage-security-guide%3Ftoc%3D%252fazure%252fstorage%252fblobs%252ftoc.json&data=02|01|elsung%40microsoft.com|fa1c68e392b6402613ca08d716b6c255|72f988bf86f141af91ab2d7cd011db47|1|0|637002846512591671&sdata=iDrmcmQ6bxiSCIALOudfZpE2r3Xoj%2BVUOjSnlS7MWD8%3D&reserved=0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36328%3Femail_source%3Dnotifications%26email_token%3DADR7YJMGFIQCEWCPRVU6ASDQCM2WTA5CNFSM4IIRZWCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LUU7Y%23issuecomment-517425791&data=02|01|elsung%40microsoft.com|fa1c68e392b6402613ca08d716b6c255|72f988bf86f141af91ab2d7cd011db47|1|0|637002846512591671&sdata=%2BhdLS7%2BGmlY8q1jjimRSZrDC4SiS%2BRN2a3Rvl682uaA%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADR7YJN3467SDB37V7SMTE3QCM2WTANCNFSM4IIRZWCA&data=02|01|elsung%40microsoft.com|fa1c68e392b6402613ca08d716b6c255|72f988bf86f141af91ab2d7cd011db47|1|0|637002846512601663&sdata=U8Q%2FioHZddRnrJXso3wgAdVGBW3pHNFszl6rxxw7j5s%3D&reserved=0.

@JosephCason We will now proceed to close this thread as we have not heard back from you. If there are further questions regarding this matter, please tag me in your reply and reopen the issue. We will gladly continue the discussion.
Thank you.


If loop in macro creating "mapping values are not allowed error"

OpenTest version number:1.1.4
Issue:
I'm writing an If loop in Macro, where if the scenario is 'notLoyalty', it should click the Button.
I checked if I missed space anywhere, or if indentation is wrong, but still keeps giving me this error.
Macro file:
-  description: Verify Loyalty and perform action
    script: |
    if (text: $macroArgs.checkLoyalty= 'notLoyalty') {
        $runAction("org.getopentest.selenium.Click", {
           locator: { xpath: "//div[contains(@class,'loyalty-signup-option-
                       group')]//label[@class='custom-checkbox fa']" }
         });
      }

My test file is as below:
- description: Create Account with Loyalty
   macro: Create_Account_with_Loyalty
   args:
           checkLoyalty: Loyalty

The log keeps stating that mapping values are not allowed in line 44 which is as below:
locator: { xpath: "//div[contains(@class,'loyalty-signup-option-
group')]//label[@class='custom-checkbox fa']" }
Log details:
ERROR: java.lang.Exception: Failed executing test web/Customer_with_loyalty_shipping, segment 1
at org.getopentest.base.TestActor.executeTestSegment(TestActor.java:2118)
at org.getopentest.base.TestActor.runOneSession(TestActor.java:2839)
at org.getopentest.base.TestActor.runOneSession(TestActor.java:2875)
at org.getopentest.Main.main(Main.java:20)
Caused by: java.lang.RuntimeException: There was an error while executing action no. 4 (Create_Account_with_Loyalty) in segment 1 of test web/Customer_with_loyalty_shipping.
The action definition was:
{
"action": "org.getopentest.base.MacroAction",
"args": {
"newCustomerFirstName": "Test",
"newCustomerLastName": "Automation",
"newCustomerEmailAddress"<EMAIL_ADDRESS>"newCustomerPassword": "auto@1234",
"newCustomerPasswordConfirm": "auto@1234",
"checkLoyalty": "Loyalty"
},
"description": "Create Account with Loyalty",
"macro": "Create_Account_with_Loyalty"
}
at org.getopentest.base.TestActor.executeTestSegment(TestActor.java:2076)
... 3 more
Caused by: java.lang.RuntimeException: Failed executing action org.getopentest.base.MacroAction with arguments {"newCustomerEmailAddress":"test.automation.z@carters.com","newCustomerPassword":"auto@1234","checkLoyalty":"Loyalty","newCustomerLastName":"Automation","newCustomerFirstName":"Test","newCustomerPasswordConfirm":"auto@1234"}
at org.getopentest.base.TestActor.executeActionByDef(TestActor.java:1773)
at org.getopentest.base.TestActor.executeTestSegment(TestActor.java:2026)
... 3 more
Caused by: java.lang.Exception: There was an error executing macro action Create_Account_with_Loyalty with arguments {"newCustomerEmailAddress":"test.automation.z@carters.com","newCustomerPassword":"auto@1234","checkLoyalty":"Loyalty","newCustomerLastName":"Automation","newCustomerFirstName":"Test","newCustomerPasswordConfirm":"auto@1234"}
at org.getopentest.base.TestActor.executeMacroActionByName(TestActor.java:1922)
at org.getopentest.base.TestActor.executeActionByDef(TestActor.java:1653)
... 4 more
Caused by: mapping values are not allowed here
in 'reader', line 44, column 24:
locator: { xpath: "//div[contains(@clas ...
^

This looks like an error in the indentation on your YAML file. Please check the indentation to ensure your test and macro are valid YAML files.


Create external hyperlink with PSEXCEL ?

Hi,
Do you have a solution to create an external hyperlink with PSEXCEL ?
I tested :
$Worksheet.SetValue(1,1,'=LIEN_HYPERTEXTE("X:\XXX\XXX.docx";"TEXT")') --> OK, the expression writes the text but the hyperlink is not created.
$Worksheet.Hyperlinks.Add($Worksheet.Cells.Item(1,1),'"X:\XXX\XXX.docx","","","TEXT"') --> Nok
Have you got an idea ?
Thanks !

Hi!
Not currently, but, it looks like EPPlus (the library we use) does support setting a hyperlink
Only problem is, I don't know if a regex can truly capture whether we should hyperlink a cell.  If we find a link in the text? What if there's more than one?  Is there really a regex that can capture any format of link, without false positives? etc.
Could potentially be added to Format-Cell, but you would need to have code that says "I want this cell to have this hyperlink," or something along those lines (you could likely come up with a regex that fits your needs specifically)
Timing wise, this might take a while - Have a conference talk coming up, holidays, decompress, etc, and PSExcel is already on the back burner (trying to encourage folks to use ImportExcel) - Ping me in February if you don't hear back - if you want to try tackling it yourself for a pull request, this might get you started
Sorry to be a pain!
Cheers!

Hi RamblingCookieMonster !
I am sorry not to have been able to get back to you sooner.
Ok, no problem !
Thank you very much for the splendid job done with PSEXCEL !


Update to 1.21.1 please?

I want to use this in a pack, but a lot of the mods have mysteriously skipped over 1.21.0, so could you please update this one?

I’ve just learned that 1.21.1 is mostly compatible with 1.21 mods, so I’m changing my request to “Please update the Modrinth page so that the mod is marked as compatible,” which I’ll assume it is until I can test it.


[Relay] Add ClipAndConsecutiveCast and CastClip to SimplifyExpr

This commit adds SimplifyClipAndConsecutiveCast and SimplifyCastClip to SimplifyExpr Relay pass. These simplify sequence clip->cast->cast and cast->clip based on Clip min/max attributes and Cast target data type.

SimplifyClipAndConsecutiveCast example:
%0 == [type=int32]
%1 = clip(%0, a_min=0f, a_max=255f) [type=int32]
%2 = cast(%1, dtype="uint8") [type=uint8]
%3 = cast(%2, dtype="int32") [type=int32]
--> Here Clip dtype == Cast2 dtype and max_value("uint8") == 255
min_value("uint8") == 0
Optimized sequence (both casts can be removed):
%1 = clip(%0, a_min=0f, a_max=255f) [type=int32]

SimplifyCastClip example:
%1 = cast(%0, dtype="uint8") [type=uint8]
%2 = clip(%1, a_min=0f, a_max=255f) [type=int8]
Optimized sequence (remove Clip):
%1 = cast(%0, dtype="uint8") [type=uint8]

@tvm-bot rerun

@tvm-bot run


WHERE statement returning [] or nothing

const checkvalid = function(username, password, pin){
    const prep = db.prepare(`SELECT * FROM users WHERE username = ? AND password = ? AND pin = ?`)
    console.log(prep.get(username, password, pin))
}

https://uploadi.ng/QNCjWZFu
The columns are correct, although whenever i do run, get or all it does not return anything, except for doing run which returns
{ changes: 0, lastInsertRowid: 0 }
I have no idea why this is happening.
When i call the function i do it as follows,
const valid = helpers.checkvalid(req.params.username, sha512(req.params.password), req.params.pin)
// this is where my auth is meant to go...

Questions like this belong to StackOverflow, this doesn't appear to be an issue with better-sqlite3. With this little information it's impossible to help you. You need to provide a self contained minimal reproducible example.
Also
https://security.stackexchange.com/questions/52041/is-using-sha-512-for-storing-passwords-tolerable
https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512

it does not return anything

checkvalid does not have a return

Duplicate of https://github.com/JoshuaWise/better-sqlite3/issues/125


Cherry-picks from master to 3.2.x

Coverage remained the same at 88.635% when pulling 13f7caf43945e94e34e8393fcb988f6a24e68055 on mprimi:3.2.x into 9bf8edc06a97436954e6638f8eb676a29b1dd9e1 on Netflix:3.2.x.

Coverage increased (+0.2%) to 88.829% when pulling 13f7caf43945e94e34e8393fcb988f6a24e68055 on mprimi:3.2.x into 9bf8edc06a97436954e6638f8eb676a29b1dd9e1 on Netflix:3.2.x.


✅ Add dockerized release pipeline for frontend

[x] Add Dockerfile
[x] Handle runtime env vars in container
[x] Add Github action to build Docker image

Closed in 80dd85d523be1564457d465ae2b8d2e06421ab5f


File

i don't understand, i try download file, but Promise dont contain filePath varible.
I use
bot.on('photo', function(msg) {

	var path = bot.downloadFile(msg.photo[msg.photo.length-1].file_id, "./public/img").filePath;
	console.log(path);
});

but, i got
{ _bitField: 0,
_fulfillmentHandler0: undefined,
_rejectionHandler0: undefined,
_progressHandler0: undefined,
_promise0: undefined,
_receiver0: undefined,
_settledValue: undefined }
where i lose?

What downloadFile returns is a Promise created by Bluebird.
A Promise is an object with a then method which parameter is the callback of the asynchronous action once is resolved.
What I mean is, you have to call then with your callback.
Eg:
// I haven't tested this code, its based on what you write.
bot.on('photo', function(msg) {
  var photoId = msg.photo[msg.photo.length-1].file_id;
  var path = bot.downloadFile(photoId, "./public/img").then(function (path) {
    console.log(path);
  });
});

oh, it`s works! I am noob in NodeJS, Thanks!

On NodeJS the I/O operations are asynchronous (like HTTP petitions or writing on a file), this is the best part of NodeJS without doubt. To execute a function after a an asynchronous action, a callback is provided. One way is passing the callback on the function parameters, but it turns out into a callback hell.
On node-telegram-bot-api Bluebird Promises are provided to simplify the development.


Update imgui.cpp to prevent Remix Menu nullptr crash

Removed a nullptr reference that triggered a crash when opening the Remix menu if no current window was set. Current cause for the nullptr is unknown.  Adding this check was enough to make Sword and Fairy 4 load into gameplay without crashing, and made the Remix menu available for use.  However the reason for the error occurring to begin with is unknown and this commit probably needs more work.
Logger is commented out as this script is imgui related (not DXVK related) and doesn't appear to have Logger references, ideally this should be revised so that the reason behind the nullptr value can be tracked down.

This wouldn't really be a good fix for the issue in question I think. We still have yet to debug the linked issue but the ImGui Window should never be null in this case so it should not need to be checked (so it likely is a problem on the Remix side of things). We also try to avoid modifying ImGui directly (as issues in it should be reported to ImGui and fixed upstream ideally if it is truly an issue in ImGui rather than on our side).
That being said if you can find why this is happening on the Remix side and update this PR to fix it that way instead that'd be fine (as you mention in your description), that or we'll just close this if we get around to finding what is causing this issue and fixing it.

That sounds good.  I'll close this PR as I agree that it's not really a valid solution to the problem.  As of late I've been having difficulty actually reproducing this bug and it makes me think its cause may actually have been resolved incidentally.


Fix anchor link

Fixes #31723

@Potapy4 : Thanks for your contribution! The author, @vladvino, has been notified to review your proposed change.

Verified the updates; the link works when tested in GitHub preview.
@Potapy4 Thanks!


Disable unreliable test

This test is failing at a rate which is blocking other check ins, disabling until we can put eyes on it.

I've opened issue #1815 to track

/azp run


Implement export

I'll add decent tests in the later PRs.

@satoru-takeuchi Thank you for your review. I squashed my commits.


Getting empty S3 bucket after running the solution

There appears to be some 'bug' recently introduced where currently, the right sizing solution runs 'fine' but creates empty s3 bucket (with no recommendation csv file). Raised a support case with aws and they said they were able to repro but can't help as it's not 'officially supported'.
Are more people running into this and/or can some one help fix this?
FYI - I was able to run it successfully last on March 26th.

Sorry for the inconvenience. The published solution should be fixed now, and updated GitHub files have been updated too.


Upgrade sarama to support Kafka 2.3.0

Upgrade Sarama library to support Kafka version 2.3.0.

Thanks.
Unrelated to this PR, I think it might be time to move from Godep to Go Modules. 🤔

Coverage remained the same at 74.702% when pulling 25e9ff2c3315437e5c4a54fba76ae883b0d420f1 on khorshuheng:upgrade-sarama into 02f109d976fe7cc21d4c944493ce4664b8b95bf8 on linkedin:master.

Thanks.
Unrelated to this PR, I think it might be time to move from Godep to Go Modules. 🤔

I will try to submit another PR after this is merged, as i would much prefer to use go.mod. WiIl need some time to test and modify the docker compose set up though.


Inject core-js import when member access with variable

Describe the feature
Currently swc only inject core-js import when
'a'.at(1)

but not
const b = 'at'
'a'[b](1)

Babel plugin or link to the feature description
https://babeljs.io/repl#?browsers=chrome 55&build=&builtIns=usage&corejs=3.21&spec=false&loose=false&code_lz=MYewdgzgLgBARjAvDA5AQyigUF0lbBLw4BEAjCQNrAC6AFGQJRA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env&prettier=true&targets=&version=7.17.9&externalPlugins=&assumptions={}
Additional context
This would, once again, require implementing a certain degree of evalute, although I don't whether or not it's worth to it implement it in compat, or to implement this feature at all...

clone - minify - analyze may work

That's the first step -- however babel also supports this

Oh... It makes me think applying minifier is better.
We can inline aggressively, ignoring output becoming larger


GH-37923: [R] Move macOS build system to nixlibs.R

This PR modifies the build system of the R package to no longer rely on auto/homebrew. Instead this PR adds the infrastructure and code paths to use the same type of  pre-compiled libarrow binaries as we use for Linux. The main difference is the use of the binaries even on CRAN (as we previously also used binaries in form of brew bottles).
The addition of the new artifacts to tasks.yml should ensure that they get uploaded to the nightly repo as well as to the artifactory during the release (@kou please confirm).
A summary of the changes in this PR:

update r/configure and r/tools/nixlibs.R to enable the source build on macOS and usage of precompiled binaries using the existing mechanism to test compile a program to detect the exisitng openssl version
added tests for the changes in nixlibs.R
update the binary allow-list
Add the build jobs for libarrow binaries for arm64 and x86_64 macos with openssl 1.1 and 3.0 to the r-binary-packages job
Use the binaries to build the nightly packages
bump snappy version to 1.1.10 (and patch it on 10.13) due to build issues with the current version. This also touches on a number of issues in regards to a sanitizer issue we have had for a long time: #32562 #31766
Disable the centos binary test step: #37922

Follow up issues:

#37921

Closes: #37923

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

#37716 and #37717 will be helpful for this.

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages
First try with completly converted workflow :crossed_fingers:

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages
This should be it... test program compilation correctly detects openssl and chooses the right binary... :crossed_fingers:

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

@github-actions crossbow submit r-binary-packages

This is now review ready imo. The build is still failing on the package build for m1 due to a missing openssl symbol. I am a bit puzzled as all flags are set correctly afaik: https://github.com/ursacomputing/crossbow/actions/runs/6334017427/job/17203457256#step:16:109
Any local tests with the binary on an M1 to repro would be helpful as I don't have an apple silicone machine here.

@github-actions crossbow submit r-binary-packages

add a checksum check

Agreed: https://github.com/apache/arrow/issues/37941

@github-actions crossbow submit r-binary-packages

I think this initial version should be ready to merge for further testing.

Thanks for the through review @kou I will add the other changes tomorrow :)

@github-actions crossbow submit r-binary-packages

As all checks pass now it seems that it was a flakey test

@github-actions crossbow submit r-binary-packages


Get embeded object by filter email

How I can get embeded object user from userRegistration by filter email?
How I can update field email in userRegistration struct?
type user struct {
	name  string
	email string
}

type userRegistration struct {
	user     user
	password string
	listoffavorites []favorites

}

With Best Regards

Hi, In answer to your questions:

To get the fields in a struct you should ensure that the fields are exported, if they are not exported when inserting your record the document will be empty. For example you should change your type definitions to:

type user struct {
    Name  string
    Email string
}

type userRegistration struct {
    User     user
    Password string
    ListOfFavorites []favorites
}

Then when you fetch the results from the database you simply scan the result into userRegistration and access the User field.

To update a single field in a document I recommend simply using a map. For example:

r.Table("userRegistration").Update(map[string]interface{}{
    "User": map[string]interface{}{
        "email"<EMAIL_ADDRESS>    },
})

Hope that helps, if you have any other questions I try to be active in https://gitter.im/dancannon/gorethink

@dancannon How i can Filter objects by email with structure  userRegistration in db?

Maybe something like this...?
r.Table("userRegistration").Filter(r.Row.Field("User").Field("Email").Eq("??"))

As mentioned above struct fields need to be exported to work in queries. See https://golang.org/ref/spec#Exported_identifiers

@dancannon Thanks, now It's clear

@dancannon Thanks, now it's clear for me


Fluid events

Hey,
So ive been working on a plugin and have noticed that fluids being placed(using buckets etc etc) dont seem to be recorded i was hoping for a FuildBlockChange event or something intergrated into the ChangeBlockEvent
Thanks
Johnfg10

I believe this was fixed in https://github.com/SpongePowered/SpongeCommon/commit/e4438fd5ebc340a371c8b00f6c6a516584dcda38
Give it another go

If its still an issue then reopen the issue in spongecommon, otherwise 👍


Add JUnit XML uploading for smart flank

After each test run, the JUnit XML file is uploaded to Google storage
To Do

[x] Upload JUnit XML
[ ] Shard tests based on JUnit XML timing

Codecov Report

Merging #385 into master will decrease coverage by 0.73%.
The diff coverage is 47.82%.

@@             Coverage Diff              @@
##             master     #385      +/-   ##
============================================
- Coverage     79.88%   79.15%   -0.74%
- Complexity      476      484       +8
============================================
  Files            66       66
  Lines          1546     1578      +32
  Branches        234      238       +4
============================================
+ Hits           1235     1249      +14
- Misses          173      188      +15
- Partials        138      141       +3


Added AMGC logo

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
Added AMGC Logo
Contract Address: 0x41385664aad657990000004d3906d1572a6bb4c6
Token Name: Amigo Coin
Token Symbol: AMGC

[x] Filename in the lowercase format
[x] Image format: png
[x] Image size: 256 by 256 px

Also, you can use these graphics to say that your ERC20 token fully compatible with Trust Wallet (https://trustwallet.com/logo-assets). Tokens will show up automatically once the user receives them.
Feel free to share this on social media and tag Trust Wallet:

Twitter: @trustwalletapp

Facebook: @trustwalletapp


Equihash Masternode Support

Note
Please use the following format to file an issue. Issues that fail to comply will delay our responses.
Please remove this section when you submit the issue. Thank you for your cooperation.
Description
When adding an Equihash coin with Masternodes MiningCore cannot accept blocks. While investigating there is no support for Equihash Coins with Masternodes. Can I take the Masternode.cs and Payee.cs file from /miningcore/src/MiningCore/Blockchain/Bitcoin and place it under /miningcore/src/Miningcore/Blockchain/Equihash and would that then enable MiningCore to successfully handle blocks with masternode payments?
Steps to Reproduce

Add coin with Masternode, for example ZelCash
Mine enough to hit a block and find that it crashes MiningCore

Expected behavior
To be able to mine a block successfully.
Actual behavior
MiningCore crashes on block.
Reproduces how often
100%
Version
If you are using released version, please state your version.
If you are using clone from dev branch, please state commit hash of your copy.
Also, please include the OS name and version you're currently running.
Additional Information
Any additional information, log, configuration or data that might be necessary to reproduce the issue.

You can try
https://github.com/coinfoundry/miningcore/blob/master/src/Miningcore/Blockchain/Bitcoin/BitcoinJob.cs#L114

@eketubol Which coin are we talking about?

Hi @oliverw there are two coins which I am interested in, ZelCash which is a very promising coin and has recently released masternodes and Vidulum which is a lesser known coin. ZelCash is Equihash 144 and Vidulum is Equihash 192.

I believe at minimum you will need the equihash block template to support the masternode payee (look at getblocktemplate for those two coins and see how the masternode payment is being reported. Some report as payee, some as other things). I haven’t looked so equihash in miningcore May already have some of the MN stuff in it, or it may not.

@eketubol @calebcall Masternodes and Payee are currently not implemented for the Equihash Coin Family. It shouldn't be too hard to port it over from the Bitcoin Family code. I haven't done it myself yet because I didn't see the need and also because this Blockheader and Coinbase assembly is a sensitive area where its quite easy to break things.

I will be committing an update to zero (zer) soon you may copy it.

@equ1miner Care to elaborate?

https://github.com/zerocurrencycoin/Zero-MiningCore/commit/f35ee9f5f79c031f496763c634f5862713348ea4

Hi, so @equ1miner have you solved the problem with masternode payments? I'm using zero fork, hash and shares are ok and when I mine vdl getting  bad-cb-payee rejects and when I mine 144 algo I'm getting tx-overwinter-active rejects. Is there any possibilities to fix these problems? Thanks.

Hi @oliverw, any fix for zhash masternode payments and tx-overwinter-active rejects? Thanks.

Anyone to help with this issue, don't have much experience but I can try. It would be nice that miningcore can support most algos out of box. Thanks.

Well, miningcore does support equihash, just not masternodes on equihash.  Supporting most algos isn't really reasonable without having community contributions.  Oliver is only one person and runs his own pool so as he has a need, things get added (which is totally fair).  If the community has a need, they should be working on and contributing those back to the project.

Hi @calebcall, thanks for quick reply. Yeah I meant for masternodes payments on equihash. I understand your point. Maybe someone can jump in a near future and make that possible. Thanks again.

Hi, so @equ1miner have you solved the problem with masternode payments? I'm using zero fork, hash and shares are ok and when I mine vdl getting bad-cb-payee rejects and when I mine 144 algo I'm getting tx-overwinter-active rejects. Is there any possibilities to fix these problems? Thanks.

The active version has been released and both online and live on main for some time and it is on the zero github.
You may have have to modify based on VDL's daemon's response to "getblocktemplate" or other customization of VDL
VDL is not ZERO but maybe you can more easily isolate the changes given a working example that you can test on zero.
Good luck!

Thanks


"Check your inbox" heading out of alignment after signing up for an account [DESKTOP]

Environment: https://staging.fightpandemics.work/
Steps to reproduce:

Go to https://staging.fightpandemics.work/
Click "Join Now" and enter info in email, password, and confirm password fields. Click "Join Now".
User will be redirected with a "Check your inbox message".

Actual results:
The "Check your inbox" heading is aligned above the message towards the right.
Expected result:
The "Check your inbox" heading should be centered above the message.

Hi @jessica-lau  - I am unable to reproduce the issue. Can I ask what browser or environment are you using?

Hi @omarzoghayyer I was using the staging environment on Chrome v83.0 on Windows10. However, I just rechecked this issue by doing another sign up process and everything seems to be looking good now.

This issue can be closed.


Remove cipher tool exec

This PR removes ciphertool.sh execution from WSO2 base puppet module

What is the reason to remove the execution as there is a  flag to disable the secure vault?

@pubudu538 CipherTool execution after Puppet template application makes it impossible to enable scheduled Puppet agent runs without restarting the server everytime. This is basically a side effect that alters the templated files that Puppet would later identify as artifacts that need to update and then restart the server.


Update documentation example

The example that comes on this site: https://smallrye.io/smallrye-mutiny/ is not working as expected, because the method
fail(Throwable failure) was replaced by failWith(Throwable failure). Also .subscribe().with doesn't return a Uni.
If you think that the proposed changes are too "verbose" could be summarized into
Uni<String> request = (...)

request.ifNoItem().after(ofMillis(100)).failWith(new Exception("💥"))
                .onFailure().recoverWithItem(fail -> "📦")
                .subscribe()
                .with(item -> log("👍 " + item));

But I try to keep the same amount of lines as the current implementation.

Good points, but it's running too wide:

Ok, let see If now fits, or I have to continue making it more narrow.

Still off the bounds 😆

Ok, here we go!. Also, I decided to go for the less verbose example!. as we had in the original example.

Blank space is important, so I pushed a reformat commit:

Looks balanced!

Thanks @pjgg !


Swift 3.0 support

Is this project still being developed? In its current state it is not compatible for use in a Swift 3 project, and most of the issues raised here have been unanswered. Any indication if work has already begun to review and accept the many pending PRs will be nice. and if yes, a possible timeline too
Thanks

Oh Snap. My bad, just found the swift3 branch.


enhancement: data clone api

model should be the builder tables [Routes,Pages,FormSchemas, BE, TS]
process
name: Custom + existing name + timestamp
entityRef: existing + timestamp
_status: DRAFT
---create data in the model

closing as done


353 upgrade python modules

Numpy had to be updated due to a security warning (from >=1.21 to >=1.22).
The new numpy version does not support Python 3.7 and this is updated to 3.8.
Pandas Version 1.4 had a view errors and warnings.
Merge Request - GuideLine Checklist
Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.
Checks by code author:

[x] There is at least one issue associated with the pull request.
[x] The branch follows the naming conventions as defined in the git workflow.
[x] New code adheres with the coding guidelines
[ ] Tests for new functionality has been added
[x] A local test was succesful
[x] There is appropriate documentation of your work. (use doxygen style comments)
[ ] If new third party software is used, did you pay attention to its license? Please remember to add it to the wiki after successful merging.
[ ] If new mathematical methods or epidemiological terms are used, has the glossary been updated ? Did you provide further documentation ?
is present or referenced. Please provide your references.
[ ] The following questions are addressed in the documentation*:  Developers (what did you do?, how can it be maintained?), For users (how to use your work?), For admins (how to install and configure your work?)
For documentation: Please write or update the Readme in the current working directory!

Checks by code reviewer(s):

[x] Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
[x] The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
[x] There are appropriate unit tests and they pass.
[x] The git history is clean and linearized for the merge request.
[x] Coverage report for new code is acceptable.

Closes #353 and #229.

Sorry I couldn't do a review! I saw that python was updated to 3.8. one comment: as I was looking up the actual release of python the current development of python 3.11 is promising a lot of improvements performance wise, see [https://docs.python.org/3/whatsnew/3.11.html](python 3.11 doc).
Maybe we could see if we can upgrade to this version. :-)

@xsaschako We also support multiple versions of python, see https://github.com/DLR-SC/memilio/blob/main/.github/actions/build-py/action.yml#L22-L23. Now the minimal version changed but we could do a test for python 3.11 in the future. Maybe make it an issue?

@xsaschako We also support multiple versions of python, see https://github.com/DLR-SC/memilio/blob/main/.github/actions/build-py/action.yml#L22-L23. Now the minimal version changed but we could do a test for python 3.11 in the future. Maybe make it an issue?

Ah, yes! I have a vague memory of some python versions not working. I'll investigate it after Stuttgart or when I'm free. Also, I'll open an issue.


Noclip Accuracy

It would be awesome if you could add a noclip accuracy where it doesn't have a limit but it shows your percentage and your deaths on the top left, like megahack.

Much love <3

Just add a noclip accuracy label


Issue with Admob bindings

Hello,
I was trying to implement Admob bindings by following the sample but I was having an issue that was causing my screen not to respond to any touch inputs. I narrowed down the issue to this line:
window.makeKeyAndVisible();
I was able to work around this issue by calling this method in my interstitial's didReceiveAd delegate method and then calling window.setHidden(true); in my interstitial's didDismissScreen method.
I looked at the issues listed here and did not see anything like it. Am I doing something wrong? I did a little research about these methods in the iOS world but I don't understand enough about what is happening to figure it out. Should the Admob sample be changed or did I do something wrong on my end?

AdMob is now officially supported as a RoboPod: https://github.com/robovm/robovm-robopods
Just add the following to your Gradle:
dependencies {
   ... other dependencies ...
   compile "org.robovm:robopods-google-mobile-ads-ios:1.5.0"
}

or maven files:
<dependency>
   <groupId>org.robovm</groupId>
   <artifactId>robopods-google-mobile-ads-ios</artifactId>
   <version>1.5.0</version>
</dependency>

Please use the RoboPod from now and post any issues you encounter on their issues list. Thanks!


add P202 aliases

Closes #920
Gives a dual alias "focal point" to our "generic point", as well as using "specialized" to reflect "generic" in an alias.
Since "focal point" is not super common in general topology, I think keeping the current main name is appropriate.

I am ok with this.  Leaving it to someone else to formally review, so you get a second opinion.

Do you want to assign someone to review?  Or should I just approve?

Just saw this. Looks good!


Fix TypeScript dependencies

Closes https://github.com/mlcommons/mobile_app_open/issues/279

Let's merge and see if it resolves all the warnings


add Layer functions

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
9 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 99.393%

Files with Coverage Reduction
New Missed Lines
%

godal.go
9
99.57%

Totals

Change from base Build<PHONE_NUMBER>:
-0.3%

Covered Lines:
2785

Relevant Lines:
2802

💛  - Coveralls

This PR modifies the exposed API and cannot be accepted. Although the Bounds struct is in essence a good idea, please continue using [4]float64 as previously


Time Block (past, present, future)

WHEN I view the time blocks for that day
THEN each time block is color-coded to indicate whether it is in the past, present, or future

Add time blocks for past, present, and future using for loop along with Dayjs


Typo Fix in flutterfire_ui README.md

Fixed a typo under ### Migrating to firebase_ui_database. Under 'Run in your terminal', the command was flutter pub add firebase_ui_firestore instead of flutter pub add firebase_ui_database
Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR. Note that you'll have to prefix the issue numbers with flutter/flutter#.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[ ] All existing and new tests are passing.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] The analyzer (melos run analyze) does not report any problems on my PR.
[ ] I read and followed the Flutter Style Guide.
[ ] I signed the CLA.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change.
[ ] No, this is not a breaking change.

@reticent-roklimber could you please sign the CLA here https://cla.developers.google.com/?


ERR! code ELIFECYCLE on npm start

node v5.11.1
npm ERR! npm  v3.8.6
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node server/index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node server/index.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the redux-universal-example package,
npm ERR! not with npm itself.
I run into these errors whenever I try starting an example such as todos

Hi! Have you ran npm install in that folder?

Also can you generally run node in command line? There might be something wrong with your node installation if not.

ohh i ran npm install on the root folder and not in all specific examples. yes todos works thank you. I am new in node.

No problem!


Pre assigned urls support

At this time there`s no support for pre assigned urls? right?
like this http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html
[]`s

Worked fine, was my fault. Thanks


Encoder

Yups! I have used and old branch for creating this one. The new commits start on f648211 : "add encode_integer"


Products not seen as purchased in TestFlight builds

I'm seeing the following behavior only in TestFlight builds. This is with configuration .default.

Purchase a product
Force quit the app and restart

In the didChangeStatesFor: callback, the product purchased in step 1 doesn't seem to come back as .purchased. Note that it does get returned when calling restorePurchases().
What's strange is that in dev builds, the product comes back as .purchased. Is this expected behavior because of the difference between sandbox and production iTunes accounts?

Yes, I'm calling fetchDataIfNecessary() on the product interface controller when the app is launched and then checking didChangeStatesFor callback.

You won't get the didChangeStates callback every time. If the app was purchased previously, it will already be purchased when you next launch and you won't get a callback because nothing has changed.

After calling setup() in your AppDelegate, you should check the current state of a product if you aren't storing it somewhere already and use that. Then, be ready to respond in the didChangeStates delegate if the state of any product changes after the app is launched.

Ah, gotcha, so I should manually check if a product is purchased by calling merchant.product(withIdentifier: "iap.productidentifier"). Thanks!

Glad I could help.
One pattern that might be useful is to declare the Product objects as globals or namespaced globals like let product = Product(identifier: "iap.productidentifier", kind: .nonConsumable) or whatever. Then, you can pass that instance around into the register(...) method, into Merchant.state(for: product) etcetera etcetera.
As a general rule, the ProductInterfaceController object should only be used when tied to the storefront/purchase interface. Outside of those contexts, use the Merchant directly.


Update the examples in the readme after testing before rolling out the release

Add working examples with the capabilities of the module:

Setting up a new storage instance
Secrets of reading/writing

duplicate https://github.com/obervinov/vault-package/issues/18


small fixes and improvements

A few minor fixes/improvements, one per commit

Well while we're at small fixes, damp,m allocate wrong size memory in test_adjoint, let me llok into it

On the allocation
I can't reproduce it on my machine, looks like TRAVIS is allocating m.damp two times but can't figure out why. This doesn't impact this fixes so can be ignored for now.

Well while we're at small fixes, damp,m allocate wrong size memory in test_adjoint, let me llok into it

Sorry, where? what example?

Sorry, where? what example?

All test_adjointA in TRAVIS
tests/test_adjointA.py::test_acoustic[True-dimensions0-2-4] Allocating memory for m ((70, 70, 70))
Allocating memory for damp ((70, 70, 70))
Allocating memory for src_coords ((1, 3))
Allocating memory for src ((220, 1))
Allocating memory for rec_coords ((50, 3))
Allocating memory for m ((84, 94))
Allocating memory for damp ((84, 94))
Allocating memory for src_coords ((1, 2))
Allocating memory for src ((199, 1))
Allocating memory for rec_coords ((60, 2))
Allocating memory for srca_coords ((1, 2))
Allocating memory for rec_coords ((60, 2))

Yes, the allocation has nothing to do with this PR, so still good to go once green.
@mloubout The bug you're reporting is indeed in master and arises due to an accidental naming clash with py.test. Effectively pytest always calls setup() before any test invocation, which we accidentally overwrite with from examples.seismic.acoustic.acoustic_example import setup. Renaming our function to something like ac_setup fixes this and avoids double allocation of m and damp. That being said, I'm not a big fan of these setup methods throughout the test base, since they completely obfuscate our tests to non-devs.

@mlange thanks for finding that out
As of the setup function, it wasn't there originally but I was asked to do it to remove duplicate code in the tests/examples. I don't mind at all removing it.

Yeah, I guess we need to trim the setup code (source, receiver and model initialisation) a bit before we can reasonably pull that out. With the right wrappers that should be no more than like 5-10 lines roughly, at which point the overhead is mall enough to not have to hide things.

Rebased. Travis was already green. I'll merge this as soon as Travis is green again

Merged.