Binding DateTimePicker DisplayDateEnd and DisplayDateStart

What steps will reproduce this issue?
<controls:DateTimePicker DisplayDateEnd="{Binding BoundryEndDate}" DisplayDateStart="{Binding BoundryStartDate}" />

ViewModel binding:
public DateTime? BoundryStartDate { get; set; }
public DateTime? BoundryEndDate { get; set; }

Whenever I update one of these bindable properties, the DateTimePicker will not update the DisplayDateEnd and DisplayDateStart.
Note that it will work if it is done at initializing of the ViewModel (and thus the DateTimePicker?):
public DateTime? BoundryStartDate { get; set; } = DateTime.Now;
Expected outcome
To update both the DisplayDateEnd and DisplayDateStart properties accordingly.

Environment

MahApps.Metro v1.4.0
Windows 10 x64
Visual Studio 2017 Professional 4.6
.NET Framework 4.6

@Nkmol Do you implement the INotifyPropertyChanged interface for your ViewModel? It doesn't seems so.

@punker76 Thanks for your reaction!
I am using MVVM Light and my ViewModel uses the ViewModelBase which uses the INotifyPropertyChanged interface: public class InspectionViewModel : ViewModelBase, ICreateUpdatePopup.
Other bindings, for example with a TextBox.Content, works fine.
With kind regards,
Nkmol

Are sure the INotifyPropertyChanged.PropertyChanged event is raised? If not, use a backing field for the property and change your properties like this:
private public DateTime? _boundryStartDate;

public DateTime? BoundryStartDate {
    get { return _boundryStartDate; }
    set {
        if (_boundryStartDate != value) {
            _boundryStartDate = value;
            RaisePropertyChanged(() => BoundryStartDate);
        }
    }
}

If there is not some compiletime magick implemented like fody, then those properties wont notify the UI about changes. Throwing the mvvm light viewmodelbase doesnt change that. you have to actually invoke the event for updates to show. @thoemmi approach is a good start, even though i dont recommend using expressions for triggering INPC, but either CallerMembername or the use of nameof().

@Insire  :+1: for nameof(), but I never liked CallerMembername because you don't see it on the caller side.

 Time for "Back to basic" 😄
Thanks!


Number of unread messages on the bottom icon is wrong

Total number of unread chats must be shown in the bottom icon (as WhatsApp does) and not the total unread messages.

@pulkonet That totally depends on the what zulip is targeted to show, Though I agree that this must be the total number of unread chats

In all the other community chat apps also it is done the same way. They show the number of unread chats. Also, this might seem to be trivial at this point but with communities, with a large number of direct messages, this may get to be a big number which would be unreasonable to show.

@timabbott what do you think this number should show? Do you agree?
@pulkonet to make your case stronger, give examples of how it works in Slack, FB Messenger, WhatsApp.

Here's from WhatsApp. The number shown beside chats is not the total number of unread messages
I don't have screenshot from slack at this point and messenger has no such unread chats thing in app. Though on FB web app they show the number of unread chats only.

I'm not sure.  That widget feels like a notification area, where it might be most appropriate to show the total number of conversations with unread messages.
That said, I'd prefer work on the PM threads part of the app go into showing PM threads at the top of in the main "Unreads" view, since I think that will be a better way to consume the information, and we might end up removing the unread counts from that element altogether after doing that.

@timabbott I don't quite get your point. could you please elaborate?

Also, should I work on this or leave it as it is?

@pulkonet what @timabbott is talking about is actually being polished and going in master today.
Don't do anything for now, but it will be more clear what we want to do later this week :)
Sometimes discussing features is important, and also is important to not act immediately but let the thought sit for a while in people's heads ;)
But that was a great point you made and will likely lead to some changes/improvements. Keep comparing the app's behavior to Slack, FB Messenger, WhatsApp (and others, but in this order of importance). If you find differences, we will very likely want to make the app more similar to what other apps do.


Use task dependencies in build type tasks.

Context
This PR uses task dependencies to replace old "rewrite behavior" in BuildTypesPlugin.
For every build type, a task with same name will be created in each subproject, and build type tasks are configured to depend on it.
For example,
    create("quickTest") {
        tasks("test", "integTest", "crossVersionTest")
    }

There will be core:quickTest/baseServices:quickTest tasks, etc.

@bot-gradle test RFM

@bot-gradle test RFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test RFR

OK, I've already triggered ReadyForRelease build for you.

@jjohannes I marked this as draft because I haven't finished BuildTypesPluginTest, but the change itself is ready for review.

@bot-gradle test CA

OK, I've already triggered CompileAll build for you.

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test RFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle help

Currently I support the following commands:

@bot-gradle test {BuildStage} to trigger a build

e.g. @bot-gradle test SanityCheck plz
SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/ReadyForMerge/ReadyForNightly/ReadyForRelease are supported
test this means test ReadyForMerge
SanityCheck can be abbreviated as SC, ReadyForMerge as RFM, etc.

@bot-gradle help to display this message

@bot-gradle test RFM

OK, I've already triggered ReadyForMerge build for you.

@blindpirate after some back and forth I think we now have a good solution for the time being. I now put all the "lifecycle tasks" (aka built types) that we need for the CI pipeline into the "LifecyclePlugin" (which was the BuildTypesPlugin). That plugin is much simpler now.
The project properties are also set in the plugin but in the very beginning. Now if we apply that plugin first in the build, we make sure that they are set early. Then the remaining configuration is no longer order dependent. This allows for a much cleaner root build script, where all plugins are now applied in the plugins block.
Can you please have a look?
Once we are happy with this, we should run it through Ready for Release and do one nightly from branch publishing to make sure everything still works as expected.

@bot-gradle test RFM

OK, I've already triggered ReadyForMerge build for you.

@blindpirate is anything stopping us from merging this now it has been reviewed?

Nothing. Once it passes all CI steps, it can be merged. I'll take care of it today.

I checked everything works. Thanks @jjohannes !


Added CSV widgets so they can be used in a widget group

Coverage increased (+0.01%) to 95.074% when pulling c3d06d79889dd1dcf5ccb678559867ce8c513f5e on mikeengland:add-csv-widgets-to-widgetgroup into 740c96112baf900fccbd1ad54316fe4fc930afcb on kayak:master.

Coverage increased (+0.01%) to 95.074% when pulling 52dccc905d8fbfbbae9f3a7d901fc0330d46c614 on mikeengland:add-csv-widgets-to-widgetgroup into 740c96112baf900fccbd1ad54316fe4fc930afcb on kayak:master.


Improve Performance

We recently switch our bfio utility from OmeXml.py to ome-types. We spent a significant amount of time optimizing our OME Tiff reader/writer and OME Zarr reader/writers. However, one thing we have noticed is that our readers have slowed down by more than an order of magnitude after switching to ome-types.
I did some profiling, and for a 2048x2048 16-bit image, our read time from initial loading to data in memory went from 90ms to >3s. It looks like further analysis reveals that >95% of the time is being spent in ome_types.schema.to_dict. Specifically with how the schema is being parsed by xmlschema. I'll dump the profile in a separate comment so I don't take up too much space here.
This is a deal breaker for us with this kind of performance, but at the same time ome_types is clearly the best option in terms of properly processing OME XML. We can process terrabytes of data a day, so a 30x or more slowdown creates a significant problem, and maybe being a little more sloppy with metadata is okay as long as we can still parse it out properly.
I'm not willing to give up on ome-types though, so if you're open to a discussion about optimization, I am happy to contribute (either discussion or code).
The first sets of questions I have are:

How tightly integrated is xmlschema with the repository? Would it be easy or difficult to switch to something else?
Is it possible we could create a lighter weight xml parser or figure out a way to do lazy parsing? Maybe we could use some alternative to xmlschema when we are reasonably certain that the metadata will pass schema checks.

Based on what I've seen so far, it looks like all XML data is parsed to a dictionary and then passed to other things. So it at least seems possible to change over to something else as long as the input is xml and the output is dictionary that uses the parsing definitions found in schema.OMEConverter.

I suspect that this is mostly due to 1) validation (in addition to parsing) and performance of xmlschema itself.

for validation, see #108, where I think everyone agrees it would be nice to have a parser that pretty much doesn't validate at all... and just lets ignores stuff or lets errors happen elsewhere
for parsing... xmlschema isn't super tightly integrated... and I'd love to move to lxml which would significantly speed things up.  See https://github.com/tlambert03/ome-types/pull/103 for an example of stuff that I was doing to remove dependence on xmlschema in prep for lxml

mostly, I focused at first on correctness and API, but more than happy to dig (or have someone dig) into performance issues now.  It just hasn't really come up yet, so I suspect there's a lot of low hanging fruit

Here is the profile I got from to_dict. I used an OME Tiff file that was converted from a czi file, and Zeiss likes to go crazy with the metadata.
Things to note:

Total script execution time was 25.2s
Units under Time are in microseconds
In the script, I load the same image twice. This means that the second call to get_schema should be cached since it's using lru_cache.

Timer unit: 1e-06 s

Total time: 25.2 s
Function: to_dict at line 225

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
   225                                           @profile
   226                                           def to_dict(  # type: ignore
   227                                               xml: str,
   228                                               schema: Optional[xmlschema.XMLSchema] = None,
   229                                               converter: XMLSchemaConverter = OMEConverter,
   230                                               **kwargs,
   231                                           ) -> Dict[str, Any]:
   232         4    6583856.0 1645964.0     26.1      schema = schema or get_schema(xml)
   233         4   14872838.0 3718209.5     59.0      result = schema.to_dict(xml, converter=converter, **kwargs)
   234                                               # xmlschema doesn't provide usable access to mixed XML content, so we'll
   235                                               # fill the XMLAnnotation value attributes ourselves by re-parsing the XML
   236                                               # with ElementTree and using the Element objects as the values.
   237         2         10.0      5.0      0.0      tree = None
   238      4002       2405.0      0.6      0.0      for annotation in result.get("structured_annotations", []):
   239      4000       3331.0      0.8      0.0          if annotation["_type"] == "xml_annotation":
   240      4000       2182.0      0.5      0.0              if tree is None:
   241         2         38.0     19.0      0.0                  from io import StringIO
   242
   243                                                           # determine if we're dealing with a raw XML string or a filepath
   244                                                           # very long XML strings will raise ValueError on Windows.
   245         2          2.0      1.0      0.0                  try:
   246         2       5104.0   2552.0      0.0                      _xml = xml if os.path.exists(xml) else StringIO(xml)
   247                                                           except ValueError:
   248                                                               _xml = StringIO(xml)
   249
   250         2      16327.0   8163.5      0.1                  tree = ElementTree.parse(_xml)  # type: ignore
   251      4000       2198.0      0.5      0.0              aid = annotation["id"]
   252      4000    3705077.0    926.3     14.7              elt = tree.find(f".//{NS_OME}XMLAnnotation[@ID='{aid}']/{NS_OME}Value")
   253      4000       6648.0      1.7      0.0              annotation["value"] = elt
   254         2          1.0      0.5      0.0      return result```

I did do even more digging than this, including doing some initial parsing using lxml, but even xmlschema.to_dict took up a considerable amount of the time.
Once you use to_dict, isn't it a dictionary? And do other parts of the code use xmlschema or is it only used in schema.py?

Your point about Pydantic makes sense. I think I read that you're generating the pydantic classes based off the xml schema. So most validation checks are effectively carried out a second time by Pydantic, even if things like element ordering are not validated by Pydantic.
If you're open to this I think I'm going to work on this a bit. It seems like the key thing to make this work with the rest of the code is to make sure the output format is dict, mainly because that makes instantiating pydantic classes easier. So, I think rather than replacing the current version maybe a parallel lightweight version of to_dict that just parses the element tree into a dictionary makes sense?

correct, xmlschema is mostly used as a buildtime dependency to autogenerate the python code from the OME XML schema. at runtime, however, it is only used in schema.py and then only in (as mentioned above) a real excess of caution to first validate that the user's XML string conforms to the OME XML schema before converting it to a dict.  But then note that after that occurs, the python model itself will also perform some validation.
Long story short, we can use lxml  instead of xmlschema when parsing the input XML and converting it to a dict... and I would expect that to be much faster.  Both due to the lack of xml validation, and due to the fact that lxml is just plain faster at parsing XML in the first place.

If you're open to this I think I'm going to work on this a bit.

I would looove that :)  I have long wanted this to be faster, just haven't had time or an immediate need.  I would encourage you to check out this branch.  If I recall, it was reasonably close to working with lxml.  See the new from_xml function, which had a new validate=False param, and fell back to lxml2dict, which was defined here.
I suspect a little bit more tweaking will be needed to make the dict pass as input to the pydantic model.  And I'd point you here for where those little hacks currently happen with the xmlschema importer.
This would be amazing to get across the finish line, so let me know if I can help

This is how I get involved in too many things haha. I'll use that branch as a starting point. I'll also try to create a unit test to test...something. Either make sure the dictionaries we get from each method are equivalent or maybe just comparing OME.to_json or OME.to_dict, which should be a little more consistently structured.

This is how I get involved in too many things haha.

you and me both :joy:
Sounds like a great place to start.  Don't drive yourself nuts though.  If it's enjoyable and you keep feeling like you see the path forward, it would be great.  But if you start getting annoyed, lemme know.  I also do want this to work so could pick it up from there

Too late. I'm already going nuts. I'll figure it out.

I have it working on 50% of the test files, so still a few things to work out. However, now that I've dug around the code a bit, I think discussing what a final solution might look like is appropriate.
First, I noticed that there was a difference between the lxml result and the xmlschema result. It looks like there are additional flavor attributes that are added to the dictionary for the xmlschema result that are not present in the lxml result. These missing attributes do not appear to cause a problem with Pydantic classes. They are things like units for microscope bulbs and things like that.
Related to this, one of the things I played around with before opening the issue was validating with lxml. I think I'm going to add in lxml validation which will parse out the XML using schema. I suspect this will give a result closer to what xmlschema gives. It's only a couple more lines of code and the schema parsing doesn't seem to add much overhead (surprisingly).
Finally, the implementation. I think I see three types of parsing related to validation, so maybe we could have the from_xml have a validation keyword that takes three values:
strict - current xmlschema approach. Even if lxml can provide similar chema validation, I think it's good to keep this for a few releases in case there are bug reports for lxml.
light - use this to use lxml schema validation. This may be a misnomer since it might perform as strictly as xmlschema.
off - only parse with lxml without schema parsing, hope pydantic doesn't have problems.
Most of my work on this has been figuring out how it works. Finishing this off should go quickly now, assuming there are no surprises.

Sounds great!  i wonder if rather than having on validation param with strict/light/off, we might have two params: converter - a function that converts xml to dict (could be either xmlschema or lxml, or anything in the future) and validate, a boolean that determines whether the xml should be validated or not (still up to the converter to perform though).  Might be a bit more future proof if we come up with something even better than lxml?  Default would be converter=lxml2dict, validate=False.

I guess thats true. Even with xmlschema, I don't think it's necessary to validate.
I think this is a good solution. Once I finish fixing some of these trailing issues I'll work on implementing these options. Right now I'm getting roughly a 6x performance boost using lxml versus xmlschema. That seems a bit slow to me, but I'm not going to optimize just yet. I think I see a number of areas that could be bogging this down outside of lxml, but I'll leave that for a subsequent PR.

I have a "rough draft" of it ready.
It currently passes all unit tests for parsing the xml to a dictionary then passing to Pydantic. I added a new parameter to test_from_xml to test parsing with and without validation.
It currently defaults to validate=True. When I default to validate=False, it doesn't pass the roundtrip tests (yet).
I need to add in the lxml schema validation and the converter arg.
I don't think it will be ready for a PR until I add the validate parameter to all unit tests that use from_xml and they all pass. However, I thought I would share the code if you wanted to take a look. It is a little hacky, but not too bad. It needs some cleaning yet, but if you look at the logic and something doesn't make sense, I can try to change it or add in some comments.
https://github.com/Nicholas-Schaub/ome-types/blob/lxml/src/ome_types/util.py

I've been able to parameterize all of the tests that use from_xml to use validation. There are now 240 tests, and all but 5 pass. I suspect the last 5 to fix might have to do with some of the exceptions you catch when encoding.
I couldn't help myself but do a little optimization. As I suspected, the biggest drain was regular expressions. I was able to compile and rewrite them a bit, and now we are getting a 12x speedup compared to the 6x speedup we had before. One thing i thought of that would likely improve performance globally (for both xmlschema and lxml) is to use attribute aliasing on Pydantic classes. Right now, a lot of time is spent converting camel case to snake case when parsing. What we could do instead is create attribute aliases so that when you initialize a pydantic class with PlateRef=value it would end up setting plate_ref=value. You could also access the attribute using either object.PlateRef or object.plate_ref. I don't know if that would break your system, but using aliasing would probably reduce the total amount of code you would have in the repo and improve performance. You would take an initial hit when loading the library, but you would reduce the time spent parsing.
Obviously not something to do for this PR, but possibly something to consider if it's feasible for performance. I use this kind of aliasing when creating Typescript-Python interfaces so that we can keep snake case in Python and camel case in Typescript.

Also, the nice thing about aliasing is that you don't need to custom code the names. You can just create a generator.
https://pydantic-docs.helpmanual.io/usage/model_config/#alias-generator

I was able to compile and rewrite them a bit, and now we are getting a 12x speedup compared to the 6x speedup we had before

my hero 🤩

use attribute aliasing on Pydantic classes.

That sounds like a great idea!

We handle such a large number of files from such a diversity of sources I just assume that if it fails your tests, then we are going to have a problem. I'm assuming that we might still have issues even with all your extensive testing. I know we have run into quite a few special cases in the past, but I really like how extensive your tests are.
I am resolving the final two and then I'll open a PR. I haven't gotten to profiling to_xml for our image writer, but I might want to take a look at the performance of that as well.
I'll open a separate issue for the Pydantic aliasing.
Another question I thought of: Both our library and AICImageIO have special catches for fixing common problems in metadata written by OmeXml.py. Are you interested or considered migrating their work into this repo so that if validation fails ome-types could make an attempt to fix it? I can point you to some code if you want to take a look. Basically, we have a boolean value you can set to try and fix errors, and if it's unset then it will throw the standard validation errors.

I did some digging on those last two errors and I'm throwing in the towel because I don't think they are significant. Basically, when you parse data using schema validation it adds in default values for units, and possibly some additional xml flavoring that I don't believe contribute to any meaningful differences. What I did for now is create a special test exception case.
I also ran benchmarks using pytest, and I think there might be some overhead associated with the tests that don't give you a real feel for how big of a difference there is between the two. So, what I did was just profile from_xml over ten runs. I switched the ordering of which gets called first in case there was some lazy loading startup times, and there really wasn't a meaningful difference. You can see below that lxml for the indicated test file runs in 0.256 ms where xmlschema.to_dict runs in 645ms.
I have to add in the different parsers and cleanup code then it should be good to go.
Timer unit: 1e-06 s

Total time: 6.47677 s
File: /home/schaubnj/anaconda3/envs/py39/lib/python3.9/site-packages/ome_types/_convenience.py
Function: from_xml at line 8

Line #      Hits         Time  Per Hit   % Time  Line Contents
==============================================================
     8                                           @profile
     9                                           def from_xml(xml: Union[Path, str, bytes], validate=True) -> OME:  # type: ignore
    10                                               """Generate OME metadata object from XML string or path.
    11
    12                                               Parameters
    13                                               ----------
    14                                               xml : Union[Path, str]
    15                                                   Path to an XML file, or literal XML string.
    16
    17                                               Returns
    18                                               -------
    19                                               ome: ome_types.model.ome.OME
    20                                                   ome_types.OME metadata object
    21                                               """
    22        20         21.0      1.1      0.0      if validate:
    23        10         55.0      5.5      0.0          from .schema import to_dict
    24
    25        10         41.0      4.1      0.0          xml = os.fspath(xml)
    26        10          6.0      0.6      0.0          if isinstance(xml, bytes):
    27                                                       xml = xml.decode("utf-8")
    28        10    6453479.0 645347.9     99.6          d = to_dict(xml)
    29        50         52.0      1.0      0.0          for key in list(d.keys()):
    30        40         29.0      0.7      0.0              if key.startswith(("xml", "xsi")):
    31        30         23.0      0.8      0.0                  d.pop(key)
    32                                               else:
    33        10         86.0      8.6      0.0          from .util import lxml2dict
    34
    35        10       2561.0    256.1      0.0          d = lxml2dict(xml)
    36        20      20422.0   1021.1      0.3      return OME(**d)  # type: ignore


Github action for terraform

This action validates, formats and plans every pull request and also commits to master branch

Use az ad sp create-for-rbac --name "sp-hello-azure-tf" --role Contributor --scopes /subscriptions/<subscription-id> --sdk-auth To get client_id, client_secret and tenant_id for your subscription

For basic planning and checking it works.
Refer to https://github.com/hashicorp/setup-terraform/blob/master/README.md for more configuration options

This should merged after #26 and codebase has been unified with #27

With disabling continue-on-error on format and plan, every commit and PR needs to run terraform fmt to ensure all checks complete.


DOC Add file status icons to change log

Issue https://github.com/silverstripe/silverstripe-asset-admin/issues/1066

If we can add screenshots (which I think we can) I think that would be a helpful addition!

@brynwhyman have added an image, it won't show in the markdown file until it is merged
For now, you can see this file at
https://raw.githubusercontent.com/creative-commoners/silverstripe-framework/pulls/4/file-manager-icons/docs/en/04_Changelogs/_images/file-status-icons.png


Extensions like junit rules

See https://reddit.com/r/Kotlin/comments/4qmawt/spek_vs_kotlintest/

I like the idea and thought of it myself. However the JUnit 4 extension model is somewhat strange. JUnit 5 extensions model is much better, although they couldn't resist to use reflection magic. Essentially there are a few extension points:

BeforeAllCallback
BeforeEachCallback
BeforeTestExecutionCallback
AfterTestExecutionCallback
AfterEachCallback
AfterAllCallback

It would be easy to provide similar interfaces and extension points. More interesting would be the question how these callbacks should be registered with a test class. In principle the callbacks are just functions of type () -> Unit, so there is no need to have special interfaces.
The actual question how extensions should be combined. It could be the case that one or more provided extensions (from frameworks) should be combined with custom beforeEach behavior. This is a syntactical question and question of the correct (or expected) order.

Maybe we should collect some use cases to have a good guidance while designing this API. Use cases would have helped us with tagging, too ...
If we implement something like the JUnit model, I'd vote for a single extension interface. We could provide default implementations for all methods of the interface, so that an implementer is  not forced to implement all methods if just one is needed.
A Spec class could have a property to provide extensions:
class MySpec : StringSpec() {
  override val extensions = listOf(SpringExentsion, DatabaseExtension)
  ...
}

This approach would be the same as for defaultConfig. But it could be handy to call a method, so that subclass could add more extensions:
class MySpec : StringSpec() {
  init {
    addExtensions(SpringExentsion, DatabaseExtension)
    ...
  }
}

However, I prefer the approach with an overridden property for some reason.

Since the extensions have plug-in characteristic, it would be handy to have a single interface that could be implemented for certain use cases / frameworks.
interface Extenstion {
  fun beforeAll(context: Context) {}
  fun beforeEach(context: Context) {}
  fun afterEach(context: Context) {}
  fun afterAll(context: Context) {}
}

A concrete implementation would only override the required methods.
An extension could be registered like this:
registerExtension(exA, exB)

I suggest that the extensions are executed before (beforeAll, beforeEach) and after (afterEach, afterAll) according methods of the test class. If there is more than one extension per test class, the order of registration should take effect (from left to right).
I've left out BeforeTestExecutionCallback and AfterTestExecutionCallback, because I see no point in having them.
What do you think?

I think it sounds good. There's the possibility of wanting to know "which" test is executed, and that could only work if we introduce some TestName class or similar.

The context seems to be pretty important here. What should go into the context class?
The JUnit TestExtensionContext offers the following:

TestException
TestInstance
DisplayName
Element
Parent
Store
Tags
TestClass
TestMethod
UniqueId

TestNG offers much more via the listener API.
Since the approach is similar to AOP, AspectJ could be a source of inspiration, too.
That is pretty much information and without more concrete use cases it is hard to decide what would be actually useful. I suggest that we design a minimalistic context, since it is easier to add something than to remove something.

My idea for the extension mechanism looks like this at the moment:
interface Extension {
  fun beforeAll(context: TestCaseExcutionContext) {}
  fun beforeEach(context: TestCaseExcutionContext) {}
  fun afterEach(context: TestCaseExcutionContext) {}
  fun afterAll(context: TestCaseExcutionContext) {}
}

data class TestCaseExcutionContext(
    val failure: Throwable?,
    val specInstance: TestBase,
    val testCase: TestCase)

However, this would be limited to extending a single test classes. It would not be possible to extend the whole set of test classes and their tests directly. What would be the name for this set of all test classes (specs) and their tests? I'm used to the word "suite" for this, but we're already using a suite per spec.
My vague idea for these "global" extensions is a base class, that a singleton objects implements. The base class would place global settings in a singleton. But this feels somewhat strange and could lead to errors if multiple objects are derived from that base class. Better ideas?
I think of the following example usages:

start an external application like a database before the first test is run, shut it down after the last test
use a dependency injection framework and @Inject on fields in test classes
execute certain tests within a transaction
filter out certain tests

Further examples?

Some good thoughts.
First off the global extensions. What about using reflection magic to look for a class that derives Extensions, or something. If that class (or more) is found, then the extensions in them are registered. It's a common approach. Bit like Spring finding its classes. Camel finding its routes.
Something like
class MyExtensions : GlobalExtensions {
  addExtension(extension1, extension2)
}

I've done this kind of thing before, so I know its not that hard to do. There's a Java library that will find you all the classes of a certain interface / superclass.
Second point, if we have a global extension it needs to be a different interface, one that also supports before/after tests, but also before/after the entire test "suite" is created/destroyed. So it could be subinterface of Extension.
interface GlobalExtension : Extenion {
  fun setup(context: MaybeSomeGlobalContext)
  fun destroy(context: MaybeSomeGlobalContext)
}

I think for the contents of TextCaseContext (no need to call it TestCaseExcutionContext seems a bit of a mouthful imo), we should add everything we possibly can get a handle on easily - name, class, etc.
Finally, the name for "all the tests". I think suite is more commonly used for a "tests in a file". So we do need another name, and I can't think of anything good at the moment.

After thinking for a while, I consider your suggestion to use reflection for finding the global config the best option. I think GlobalConfig is the right name for the according abstract class, since the implementing object would be the right place for adding other kinds of global configuration, too.
abstract class GlobalConfig {
  val extensions: List<GlobalExtension> = listOf()
}

The GlobalConfig could be handy to add a usual Extension to all specs, but then we would need to wrap an Extension in a GlobalExtension or we'd need another property for global Extensions. Or we could have just one interface for all extensions, but this could be confusing. What do you think?
Everything I can think of ("name, class, etc.") should be available via the TestCaseContext:
data class TestCaseContext(
    val failure: Throwable?,
    val specInstance: TestBase,
    val testCase: TestCase)

The interface for GlobalExtension would look like this:
interface GlobalExtension : Extension {
  fun beforeVeryFirst() {}
  fun afterVeryLast() {}
}

What do you think of the method names?
I've no idea for a a kind of context for the beforeVeryFirst and afterVeryLast methods. But maybe no context is needed here.
It would still be helpful to have a clear naming (glossary) to have sharp definitions of things like "suites", "specs" etc.

Sounds good, GlobalConfig is fine. I don't like the names beforeVeryFirst though. What about just "setup" and "teardown" or start and stop, init or shutdown?
I like the idea of a glossary. Could add a section to the readme.
test = A single test function
spec = A set of tests in a single class file
suite = All the tests in a given source folder (src/test/kotlin)
What do you think? Should suite be a spec, and something else a suite ?

With beforeVeryFirst I wanted to make clear that this is not a setup per spec, but a method that is called before the very first test is executed. Maybe there is no good name to distinguish these cases. However, I'm thinking about reducing the GlobalExtension interface to just two methods, one before and one after running all tests. And then the naming could be just beforeAll and afterAll like in a per spec extension. The difference would be context then.
interface GlobalExtension {
  fun beforeAll() {}
  fun afterAll() {}
}

Or would you still prefer setup/tearDown?
If we want to allow setting per spec extensions globally for convenience, we could add another property for it.
Another change ini my design is the type of context for beforeAll and afterAll, since there is no test result and no test instance.
interface Extension {
  fun beforeAll(context: TestBase) {}
  fun beforeEach(context: TestCaseContext) {}
  fun afterEach(context: TestCaseContext) {}
  fun afterAll(context: TestBase) {}
}

What do you think so far?
Let's move the glossary discussion to the forum.

What do you think of "ProjectConfig" and "ProjectExtension" instead of "GlobalConfig" and "GlobalExtension"? Maybe "project" is the word we were looking for (more than a suite/spec).

While implementing this feature I discovered two problematic use cases:

handling excpetions (for example catching and rethrowing another type)
measuring execution time of a test, since some sort of state must be kept between before and after processing

Therefore I'm thinking about replacing before and after by something like an AspectJ "around advice". However this would not be aligned with the usual before and after methods of spec classes. These could be replaced by around advices, too, but this wouldn't be as intuitive.
Any ideas/opinions?

I was never a fan on around advice. Why can't you just assign state in before, and read it again in after?

State would solve the problem with my timer example, but it wouldn't solve the exception handling problem. The code for exception handling looks like this at the moment:
        val callable = Callable {
          performBeforeEach(spec, testCase)
          try {
            try {
              testCase.test()
              performAfterEach(spec, testCase, null)
            } catch (exception: Throwable) {
              performAfterEach(spec, testCase, exception)
              // afterEach would need to rethrow the exception, to gain a failure
              // alternative: throw exception
            }
          } catch (e: Throwable) {
            Failure(testCase.description, e)
          }
        }

As you can see, we can decide whether the exception should be swallowed by the afterEach handler or rethrown in any case.
Both cases could be handled easily and without threading issues with something like around advices.

Can you show me how the around advice version would look.
On 25 September 2016 at 19:26, Christian Helmbold<EMAIL_ADDRESS>wrote:

State would solve the problem with my timer example, but it wouldn't solve
the exception handling problem. The code for exception handling looks like
this at the moment:
    val callable = Callable {
      performBeforeEach(spec, testCase)
      try {
        try {
          testCase.test()
          performAfterEach(spec, testCase, null)
        } catch (exception: Throwable) {
          performAfterEach(spec, testCase, exception)
          // afterEach would need to rethrow the exception, to gain a failure
          // alternative: throw exception
        }
      } catch (e: Throwable) {
        Failure(testCase.description, e)
      }
    }

As you can see, we can decide whether the exception should be swallowed by
the afterEach handler or rethrown in any case.
Both cases could be handled easily and without threading issues with
something like around advices.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kotlintest/kotlintest/issues/77#issuecomment-249437386,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtZGgv4MBH9iTq-tdYA8nYCAp_tc0Pzks5qtry5gaJpZM4JN_gt
.

With an around advice it would look like this:
val callable = Callable {
    performBeforeEach(spec, testCase)
    try {
        performAroundEach(spec, testCase)
    } catch (e: Throwable) {
        Failure(testCase.description, e)
    }
}

performAroundEach in the same class ( TestBase) would look like this:
  private fun performAroundEach(spec: TestBase, testCase: TestCase): Unit {
    spec.extensions.forEach { extension ->
      val context = TestCaseContext(spec = this, testCase = testCase)
      extension.aroundEach(context)
    }
  }

The interface for extensions:
interface SpecExtension {
  fun aroundEach(context: TestCaseContext) {
    context.proceed()
  }
  // ...
}

An implementation would look like this:
object Timer : SpecExtention {
    override fun aroundEach(context: TestCaseContext) {
        val startTime = System.currentTimeMillis()

        context.proceed()

        val endTime = System.currentTimeMillis()
        val duration = endTime - startTime
        println(duration)
    }
}

For my eyes it is simple an beautiful. The only thing you have to remember is to call proceed. But that is the same with AspectJ advices and Servlet filters ...

Ok exactly like servlet filters, filter.doChain() or whatever it is.
Yes lets do this then.
On 25 September 2016 at 19:46, Christian Helmbold<EMAIL_ADDRESS>wrote:

With an around advice it would look like this:
val callable = Callable {
performBeforeEach(spec, testCase)
try {
performAroundEach(spec, testCase)
} catch (e: Throwable) {
Failure(testCase.description, e)
}
}
performAroundEach in the same class ( TestBase) would look like this:
private fun performAroundEach(spec: TestBase, testCase: TestCase): Unit {
spec.extensions.forEach { extension ->
val context = TestCaseContext(spec = this, testCase = testCase)
extension.aroundEach(context)
}
}
The interface for extensions:
interface SpecExtension {
fun aroundEach(context: TestCaseContext) {
context.proceed()
}
// ...
}
An implementation would look like this:
object Timer : SpecExtention {
override fun aroundEach(context: TestCaseContext) {
val startTime = System.currentTimeMillis()
    context.proceed()

    val endTime = System.currentTimeMillis()
    val duration = endTime - startTime
    println(duration)
}

}
For my eyes it is simple an beautiful. The only thing you have to remember
is to call proceed. But that is the same with AspectJ advices and Servlet
filters ...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kotlintest/kotlintest/issues/77#issuecomment-249438807,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtZGuVbN9cwTZz9T2EbYG1wfmAQ_volks5qtsGbgaJpZM4JN_gt
.

Ok, fine. Would you go as far as unifying the whole interception/extension model? The Extension interface would look like this:
interface SpecExtension {

  fun aroundEach(context: TestCaseContext, invocation: () -> Unit) {
    invocation()
  }

  fun aroundAll(context: TestBase, invocation: () -> Unit) {
    invocation()
  }
}

The beforeAll, beforeEach, afterEach, and afterAll methods in the specs (actually TestBase) could be replaced by the same two methods. We would avoid two overlapping approaches with then. And we would have to explain only one consistent approach in the documentation. But it would be different than what users are knowing from JUnit or TestNG.
I see these options:

only around advices for extensions and spec methods
around advices for extensions, but the usual before/after methods in the spec. This would lead to the same limitations for before/after (keeping state, handling exceptions) ad mentioned previously.
around advices for extensions, around advices and before/after in specs
offering both, around advices and before/after methods in extensions AND specs. This would lead to redundancy, more concepts to explain and probably somewhat ugly code. But JUnit/TestNG would be familiar with it.

I prefer the first option, but I consider myself somewhat radical sometimes ;-)
What shall we do?

I think it makes sense to unify it all, keep it the same. Maybe a better word than "invocation" although, perhaps "test" and "suite".
You get into an interesting situation where you might be able to change the receiver for the invocation, allowing people to pass connections, etc, into the test itself.
A typical use case for before and after is to create a db connection and then close it down.
class MyTest : WordSpec() {
  var connection : Connection = _
  override fun aroundAll(context: TestBase, suite: () -> Unit) {
    connection = create()
    invocation()
    connection.close()
  }
}

It's ok except I don't like having to use var fields.
The other option is aroundAll could return an object, an instance of AroundAll which has multiple methods, including one for handling errors. Ie a bit more like the observer interface in RXJava.

My interceptor implementation (currently on its own branch) works so far. An interceptor looks like this at the moment:
interface TestCaseInterceptor {
  operator fun invoke(context: TestCaseContext, callable: () -> Unit) {
    callable()
  }
}

I'll try to reduce it to a simple function (what it is already effectively). As you can see, I've splitted the interface for TestCase and SpecInterceptors, because chaining a combined interceptor and applying the chain to either a testCase or a spec, wouldn't make much sense.
And I want to add interceptors to the config, so that it is possible to add interceptors only to certain testcases. But then it could make sense to move the TestCaseInterceptors to the Spec config object as well, to keep it consistent. However, per spec interceptors would remain in the class as a property. Does this make sense to you?
My plan is to introduce a ProjectInterceptor that runs before the very first and after the very last test. But there is no such thing as "project" in terms of JUnit. JUnit just picks some Spec first and executes it. There is nothing that could actually be wrapped, but maybe I can find a workaround that make it look like a usual interceptor.

Do you have an idea how an ProjectInterceptor could be implemented? I have currently no idea, since JUnit looks up tests by reflection an just starts with an arbitrary test.

What's the method signature for project interceptor at the moment ?

Since there is no context, it is only:
  fun interceptProject(project: () -> Unit) {
    project()
  }

This could be reduced to a pure function type (() -> Unit).

Ok, so what is it you're asking. How to find instances of it?

Yes, the question is how to find a "project instance". As far as I know there is no such thing in JUnit. Getting a test case instance is simple, getting a spec instance is simple ... but how to get a project instance?

Ah ok. Well you need to use this library.
https://github.com/ronmamo/reflections
Which allows you find instances. So we'll tell people to do this:
object MyProjectConfig extends AbstractProjectConfig {
 fun ...
}

And then using that library we find them on the classpath. It's a technique I've used before.

I'm already using this library to find the project config, but what I need is the "project" to be executed. If it were a hierarchical data structure it would look like this:

project

spec 1

test case A
test case B

spec 2

test case A
test case B
test case C

The I could wrap the whole callable project in an interceptor like I do with test cases and specs. But there is no such instance (as far as I know) that is a container around all specs.

Right I see. The KTestJUnitRunner is invoked for each file I think. So we might be scuppered.
One possibility, is that you have a singleton object. The first time KTestJUnitRunner is created, in the constructor, invoke ProjectConfig there if you haven't invoked it already.
Not sure how you'd go about knowing when it's finished though. And without that you can't really do your around advice.
We might just have to drop the idea of project interceptors.

I'm still looking for a project interceptor solution, but if I find no way, I'll stick with the before/after approach in this case.
While developing the tests for the interceptors, I discovered the need for adding certain config properties instead of overriding them. Lets say we had a spec with a default config:
class MySpec : StringSpec {

  override val defaultTestCaseConfig = config(tag = TagA, interceptors = listOf(interceptorA))

  "should do something" {
    ...
  }.config(tag = TagB, interceptors = listOf(interceptorB) // would override tags and interceptors from above
}

So, I had the idea to introduce "additional" parameters, which would add the arguments to the exsisting arguments instead over overriding them.
  "should do something" {
    ...
  }.config(additionalTag = TagB, additionalInterceptors = listOf(interceptorB))

In this example the test case would effectively have the tags TagA and TagB and the interceptors interceptorA and interceptorB. This is pretty much the same behavior as in annotation driven frameworks like JUnit, where (some) annotations at class level are inherited by each test case and where each test case can have additional annotations.
What do you think @sksamuel ?

Which version of JUnit do you use ?
I don't see anything in build.gradle but kotlintest/src/main/kotlin/io/kotlintest/KTestJUnitRunner.kt depends on it somehow.
IMO it would be better to use JUnit 5.x alphas and use the new extensions mechanism.

The new JUnit extension model doesn't fit well with our programming model and is needlessly complicated (e. g. Store). Maybe we could introduce an adapter later, to be able to reuse existing extensions for frameworks like Spring.

@sksamuel What do you think about the additional* config params? If I would introduce it, I would remove the tag (singular) parameter to avoid confusion and too many parameters (otherwise I would have to introduce additionalTag to be consistent).
Btw: I see no solution for project interceptors with JUnit. We could do it with TestNG, I think, but that would be a major change now. However, I still have problems to run KotlinTest tests in IntelliJ, so if we should change the underlying test runner we could take the opportunity to introduce project interceptors.

Not sure if additional is really that important. Tags are not used that much, just the odd "integration" or "mongo" type tag. So people can easily repeat them?
As for interceptors - what about Junit 5. That has them?

I agree, that we don't necessarily need the "additional*" parameters. If someone misses them, we could introduce them later. However, I tend to remove the tag (singular) parameter, since it is a bit inconsistent. It is not clear, whether it overrides the other tags (what would be consistent) or not (what actually happens).
JUnit 5 dosen't have interceptors.

I consider the extensions/interceptors complete now. The only remaining thought is to split the interface ProjectExtension.
interface ProjectExtension {
  fun beforeAll() {}
  fun afterAll() {}
}

Interceptors and extensions in a list are executed from left to right. But if you think of the before/after methods as pairs, the afterAll methods must be executed in reversed order, what is a bit counter intuitive. Any thoughts @sksamuel ?
Please have a look at the code and documentation so far (branch: feature/#77_extensions). Do you find the documentation clear?

Overall very nice. A couple of thoughts thought.

Do we need to have the ProjectConfig object. Why not just find all ProjectExtensions on the class path?

Would it be nice if in a test spec interceptor, you could decide which tests should run or not? You'd need to pass in a collection of "tests" which the user could filter and then pass to an "executor".

I prefer an explicit ProjectConfig, because:

it is more obvious what  the actual config is
the order of extensions might be important (and can not be controlled with a reflection scanning approach)
there could be unwanted extensions on a class path (from libs/frameworks)

Good idea,  I'll try to implement it like that.

Do you see any drawbacks in splitting the ProjectExtension interface?

I created a separate ticket #106 for passing the list of test cases to the spec interceptor.

Done and merged to 2.0 branch. https://github.com/kotlintest/kotlintest/pull/107

@helmbold I'm just doing some work on tickets #111 #112 and I notice that no tests complete in intellij now. By complete I mean the status in intellij doesn't change, it either says ignored, or stays with the yellow in progress circle. I think maybe something in the interceptor work broke it? Can you confirm you see the same thing ?

@sksamuel Same here. I've never associated that with interceptors until now.

Shall I leave it to you to see what broke it or do you want me to have a go ?

I'll have a look.

I've created a separate issue: #114


Update dependency es6-promise to version 4.x

This Pull Request updates dependency es6-promise from version ^3.0.2 to 4.0.5
Changelog
4.0.5 / 2016-10-03
==================

release v4.0.5
Merge pull request #243 from wKovacs64/fix-auto-again
Fix auto.js for Node < 4 compatibility
Fix auto.js for Node < 4 compatibility

4.0.4 / 2016-10-02
==================

release v4.0.4
Merge pull request #241 from ThomasConner/master
Only use vertxNext() when it is not undefined
Update the dist files
Only use vertxNext() when it is not undefined

4.0.3 / 2016-09-27
==================

release v4.0.3
Fix download links in README
Merge pull request #240 from stefanpenner/greenkeeper-mocha-3.1.0
Update mocha to version 3.1.0 🚀
chore(package): update mocha to version 3.1.0
https://greenkeeper.io/

4.0.2 / 2016-09-26
==================

release v4.0.2

4.0.1 / 2016-09-26
==================

release v4.0.1

4.0.0 / 2016-09-26
==================

Merge pull request #230 from stefanpenner/4.x
Provide separate auto-polyfill version of this module
release v4.0.0
update README: re auto polyfil
build output
Provide separate auto-polyfill version of this module
This commit provides a mechanism for users to load a version of this
module which automatically installs the polyfill, separately from the
default non-automatic version, as outlined in
https://github.com/jakearchibald/es6-promise/pull/126#issuecomment-120542090
It uses require('es6-promise/auto') instead of
require('es6-promise/polyfil') so that it does not directly conflict
with the es-shim-api API Contract[1], in case support is later added.
In addition to the Node/Browserify file, a UMD file which triggers
automatic polyfill installation is also provided.
Fixes: #140
Alternative-to: #126

https://github.com/es-shims/es-shim-api#api-contract
Signed-off-by: Kevin Locke<EMAIL_ADDRESS>

v3.3.1 dist

Coverage remained the same at 99.27% when pulling ceabd57df7e8109ce806b8dd97569ec4e3d9a993 on renovate/es6-promise-4.x into 04e6333857faec23fd84042491f547a534ea13f0 on master.

Coverage remained the same at 99.27% when pulling ceabd57df7e8109ce806b8dd97569ec4e3d9a993 on renovate/es6-promise-4.x into 04e6333857faec23fd84042491f547a534ea13f0 on master.


Replace deprecated ReportUnit

https://github.com/reportunit/reportunit
This has been replaced by:
https://github.com/extent-framework/extentreports-dotnet-cli

In order for this to be done, a new Addin would need to be created.  Not sure if this is something that will be undertaken in the timeframe of 2.0.0.

@gep13 if the arguments are the same, we could just use Context.Tools.Resolve and set it as the tool to use (perhaps).

Ooo, haven't looked at that, perhaps...

Had a quick look, and it seems the new tool, unfortunately, do not have the same arguments.

Opened a request for an addin for the tool: https://github.com/cake-contrib/addin-requests/issues/14


Fix restore state with PostgreSQL

Description:
Trying to fix restore state does not work with PostgreSQL. Found root cause of this

different DB engines handles differently sort of Null values
restore_state helper checks for recorder runs via last_recorder_run function
for SQLite, correct row is returned and date range then handled
for PostgreSQL, row with Null value in end column is returned and then state restore is aborted (it is incorrectly row of active recorder run, and not last, as expected)

Fixed by adding query option to filter out null value column from SQL result. Should not break anything - last_recorder_run function is not used elsewhere
Related issue (if applicable): fixes #8974
Checklist:
If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass

Thanks for contribute


ALS-1884 App should work without any data inside the custom.properties file and prompt the user which fields are missing

Issue #, if available:
Description of changes:
fix: The app should work without any data inside the custom.properties file and prompt the user which fields are missing
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Should this one be closed in favor of https://github.com/aws-geospatial/amazon-location-features-demo-android/pull/96 ?


@paljs/nexus : NEXUS__UNKNOWN__TYPE was already defined when updating to prisma 4.0.0

I'm using nexus plugin for input types in a nexus Graphql server.
but when updating to Prisma 4 I got this error  NEXUS__UNKNOWN__TYPE   was already defined when .
when rolling back to Prisma 3.5 it works fine.

I am working on that now to update prisma version to prisma 4 and fix all breaking changes

Is there any progress update on this?

need to use the last prisma 3.15
because the one used by paljs 3.16 for node 14 seems buggy

I was able to fix this issue by manually generating DMMF when the app starts
import { getDMMF, getSchema } from '@prisma/internals';
const dmmf = await getDMMF({ datamodel: await getSchema() })
And providing the DMMF to the paljs plugin when calling makeSchema
  plugins: [paljs({ dmmf: [dmmf] })]

This issue request is in #284


[WIP] Nodejs Bot Guide

Following pr should add a detailed guide create/migrating your discord bot.
• Getting Started
> Initial Setup
> Installation, Create Application
• Design
• Actual Guide
> Managers, Structures, Plugins/Modules...
• Misc
> Create Embeds, Components
> Create Collectors
> Checking Pernissions
• Scaling
> Clustering
> Cross Communication
> Global Cache, redis?
> Standalone managers...

The guide now offers a rough overview of how to use the library and how to design your bot.
As soon as the npm for the plugins is out, more pages will be added.
Also, the guide will be more detailed and will have a custom migration page once I rewrote my bot

• Sidebar position is broken bc of the wrong position numbers in the folders
• Will takeover the changes Skill4zkillz suggested
@itohatweb how do I add the deno mft thingy?

just run the deno fmt command in your console.

Will install deno today 👀

Fixed the denom fmt thing


https://nest.jakl.one/

uncompressed size is 23.1KB

Thanks for this submission. I'm a big fan of ActivityPub and the ideas behind it as well, so I'm looking forward to look through your posts!

Thanks for adding me! In fact, it's more an Indieweb site which I've set up to just repost some of the things to Mastodon too.


merge package from arlac77/npm-package-template

package.json

chore(devDependencies): update nyc:^11.7.2 from template
chore(devDependencies): add rollup-plugin-babel:^3.0.4 from template
chore(devDependencies): add babel-preset-env:^1.6.1 from template

:tada: This PR is included in version 6.0.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Describe how to update tfstate file after migration to the registry

Include instructions from this comment: https://github.com/terraform-aws-modules/terraform-aws-vpc/issues/4#issuecomment-332380572

I've just run into this (switching to use the new module with live resources that will be destroyed if I run apply).
I found I had to do the following (I'm using terragrunt, but exactly the same commands will work with terraform too):
terragrunt state mv module.vpc.aws_internet_gateway.mod module.vpc.aws_internet_gateway.this

terragrunt state mv module.vpc.aws_eip.nateip[0] module.vpc.aws_eip.nat[0]
terragrunt state mv module.vpc.aws_eip.nateip[1] module.vpc.aws_eip.nat[1]
terragrunt state mv module.vpc.aws_eip.nateip[2] module.vpc.aws_eip.nat[2]

terragrunt state mv module.vpc.aws_nat_gateway.natgw[0] module.vpc.aws_nat_gateway.this[0]
terragrunt state mv module.vpc.aws_nat_gateway.natgw[1] module.vpc.aws_nat_gateway.this[1]
terragrunt state mv module.vpc.aws_nat_gateway.natgw[2] module.vpc.aws_nat_gateway.this[2]

terragrunt state mv module.vpc.aws_vpc.mod module.vpc.aws_vpc.this

I was then left with the following resources that were destroyed and re-created (which didn't cause me a problem because I am not using them):
module.vpc.aws_db_subnet_group.database
module.vpc.aws_elasticache_subnet_group.elasticache

The remaining changes were non-destructive (changes to tags.Name only).

I'm using flat terraform v.0.10.7, you don't have to provision resource indexes:
terraform state mv module.vpc.aws_vpc.mod module.vpc.aws_vpc.this
terraform state mv module.vpc.aws_nat_gateway.natgw module.vpc.aws_nat_gateway.this
terraform state mv module.vpc.aws_internet_gateway.mod module.vpc.aws_internet_gateway.this
terraform state mv module.vpc.aws_eip.nateip module.vpc.aws_eip.nat

Can you guys submit a PR to describe this process in more details for people who are facing the same problems?

Ah, I see - you can move all the indexed resources in one command, eg. in my case:
terragrunt state mv module.vpc.aws_internet_gateway.mod module.vpc.aws_internet_gateway.this
terragrunt state mv module.vpc.aws_eip.nateip module.vpc.aws_eip.nat
terragrunt state mv module.vpc.aws_nat_gateway.natgw module.vpc.aws_nat_gateway.this
terragrunt state mv module.vpc.aws_vpc.mod module.vpc.aws_vpc.this

Closing this (as its a pretty old issue), if anyone is still having an issue with this please open a new issues.


Update event 36

I have updated the event including the date but I'm not sure that it is pulling through correctly. will confirm once published.
I'm getting issues when trying to run the docker container, it's pointing to errors in another event, but I don't want to have to fix the YAML on other people's events to get the tests to pass.

Picked up a few additional changes to be made,
I also got the build working by commenting out the extension to event 30


Comparison of hidden states to LAI

At our last meeting (2/15) we discussed comparing hidden state 3 to the LAI of the different sites.

Here, four focal sites for which LAI was available, we observed that H3 was similar for the first three, but quite different for the coastal plain site 01466500 (lower right)
The LAI for these four sites does not explain this difference.

The coastal plain site (upper left in this figure) does have the highest summer LAI of the four, but it is highly seasonal, not explaining the constant H3 state above

This is an interesting paper that is under review at HESS: Hydrological concept formation inside long short-term memory (LSTM) networks.
Motivating question: Is the model learning hydrologic processes that are not explicitly included in the training dataset?

The authors train a single LSTM on 669 catchments to predict streamflow from meteorological variables and watershed attributes
They then extract the cell states from each timestep
Then run a linear regression on cell state time series and independent hydrologic observational time series of soil moisture, and snow depth, they call this linear regression a "probe"

Basically, how well can a linear combination of cell states recreate an independent time series of a hydrologically relevant process

The key findings are:

they can represent basin specific soil moisture reasonably well, but shallow much better than deeper
in catchments with snow they can represent snow depth, but they had to first identify which catchments these were
the findings were robust to model initialization with different random seeds, and different "probe" architecture

A couple of nuggets that I thought were interesting:

By using a linear probe to relate cell states to the predicted variable (soil moisture or snow depth) they can interpret the weights of the linear probe to see which cell states are most important
Nice discussion of cell states: "There is no reason why the LSTM should store that information in a single cell, rather than distribute information across multiple cells. In fact, the LSTM could also model a process as the difference of two (or more cells) or any other combination of multiple different cells. Indeed it is likely that information is distributed due to the process of dropout. Using dropout randomly sets certain weights to zero during training in order to prevent the neural network overfitting, preventing the co-adaptation of weights such that one weight “corrects” the influence (Srivastava et al., 2014). However, this also means that the network can potentially learn the same process in two different places in the network, since the network must be robust to those weights being “switched off” when dropped out"
They raise the question of using the probe approach in ungauged basins, if an LSTM can generalize to an unseen basin, maybe the probe weights could as well

This is getting long so I'll end there, but I thought this might have some relevance to how we are thinking about cell states

Any objections to converting this issue to a Discussion (i.e. how can we interpret model hidden states?)?

no objections here.


Mobile Layout Support for Dashboards

Proposal:
Dashboards should layout in a useable way on mobile and desktop. I understand some users might just make separate desktop and mobile dashboards, but it would be nice to have an option for better layouts on quick and simple dashboards. I would propose something simple, like giving the user an option to change the fixed gird size on mobile. If seems like the current grid is 12 cells, it would be nice to maybe have mobile wrap cells down, for a fixed size of 3 or 4.
Alternatively, giving users the option to enable horizontal scrolling might also be nice. So users can still see the same fixed-width view as the desktop, without the graphs being squished to nothingness.
Current behavior:
If you make a dense dashboard on desktop, with cells in the 2-3 width range, on mobile the cells are so squished in the width you can't see the information in them.
Desired behavior:
I had a few ideas described in the proposal.
Alternatives considered:
Use case:
Making dashboards and being able to check-in quickly on mobile.

Actually for me both Chrome and Firefox on Android show an empty dashboard (which feels like a bug). When I toggle on "Desktop site", I see what was described here: very narrow cells that are close to useless.
Is better mobile support planned?


How to migrate settings to new machine?

I have a fresh sketch install on a new computer and transferred all of my plugins, but HandyMenu (amazing by the way) is blank. Very time consuming to set up again, is there a plist file where the shortcut settings are stored?

Hey @mikecm1. The plugin keeps all setting in the Sketch's User Defaults. Unfortunately, there is no way to transfer shortcuts at the moment. Give me a day and I will make option to export/import settings :)
Thanks for feedback!

Wow, how’s that for support! Thanks!

@mikecm1 Just released 5.2 with import/export: Menu -> Plugins -> HandyMenu -> .... Have a nice migration 🙃


fix: use only non empty collections for completions

Pull Request Checklist

[x] Target branch: Pull request targets the dev branch
[x] Description: Filter out empty collections from completions to improve response quality
[x] Changelog: Added below
[x] Documentation: No documentation updates needed
[x] Dependencies: No new dependencies
[x] Testing: Code changes have been tested
[x] Code review: Self-review completed
[x] Prefix: Using fix: prefix as this addresses a bug/improvement

Changelog Entry
Description
This PR filters out empty collections from the completions to ensure only meaningful collections are included in the chat responses. This fixes the error for hybrid search.
Changed

Updated collection filtering logic in Chat.svelte to exclude empty collections

Fixed

Fixed issue where empty collections were being included in completions, causing error in hybrid search

The error handling should be done from the backend, feel free to reopen!


Fix array brackets

Fixes #39145

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

The string that you are trying to change is in interval notation. This means that your proposed change would change the meaning of the expression. #please-close


Unusual line delimiter dialog doesn't tell me which file

Version: 1.58.0-insider
Commit: 3e0c442a8ee9fdc037d627d70fe291f72af04cfd
Date: 2021-06-16T05:18:57.982Z
Electron: 12.0.11
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.11.0-18-generic
After starting up VS Code I got a modal dialog telling me about an unusual line delimiter.
It didn't tell me about the file this is about.

After accepting to fix, I saw where the problem was

I find the dialog too heavy, especially on startup.
I would need to see the code to find out what's the issue here. E.g. in our case, this is in a test, so might be intended
Maybe have a warning triage next to 'LF' in the status bar?
When I click ignore for this file, how can I unignore the file?

@aeschli I agree this is pretty weird. The Detected unusual line terminators prompt comes from a code editor contribution which executes only when a code editor widget is instantiated and shows the problematic file. I think that this normally works fine, but in this case I believe the problematic file was opened, the dialog was shown, and then the "Release Notes" editor opened under the prompt and changed the active editor from under the prompt.
@bpasero I agree with the feedback here, but I'm not sure what to do. Maybe we could make the "Release Notes" editor wait until all confirm dialogs have been closed before showing itself or that the workbench starts directly with that editor after a release?
Regarding converting this to a passive indicator in the status bar: I don't think that would be wise. Having this unusual line terminator will lead to semantic tokens, jump to definition and all kind of language features to become off. Here is the background: https://github.com/microsoft/vscode/issues/96142

Maybe instead of a modal dialog this could be shown somewhere in the editor area?
Almost like the trust banner but instead of showing to the top of the window, showing right above the editor but still inside the editor?

As for release notes, I think we are investigating to move away from using an editor and using something else but I cannot find the issue now.
Arguably this can happen in other cases too I guess, e.g. when I open a file which loads slow and I manage to open another editor over it?

Well, easiest fix is to add the file name into the dialog, I would argue then it doesn't really matter which editor is active.

PR is up to change the dialog just a bit (https://github.com/microsoft/vscode/pull/126650):


Feature - Keycloak Integration

Please check if the PR fulfills these requirements

[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature

What is the current behavior? (You can also link to an open issue here)
No integration with Keycloak to authentication and authorization

What is the new behavior (if this is a feature change)?
Now it is integrated

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No

Is there any issue related to this PR in other repository? (such as dojot/dojot)
dojot/dojot#2490

Closing this in favor of https://github.com/dojot/gui-v2/pull/180

All new features will be developed with the MFE architecture


Must be 'Menu' class?

I have a set of activerecord models that I would like to categorize (only 2 levels deep but possibly more in the future) and thinking of using this nested sets lib ... (to assign my models a category somehow, still need to figure out how, probably a single model->hasOne(category) relationship will do)
I noticed in the Readme it says to create "new Menu([options])" - can this class be called something else (like "Category") whereby I mean can I call the class whatever I like?
Thanks help appreciated,
g

Yes, you can name the model in any way you desire. The point of this behavior is that you can attach it to any model and it makes the model work with nested sets.
I use it as product categories, website menus, a restaurant menu (first level are the times of day, the second the categories, the 3rd level the meals), etc. None of my models are actually called "Menu".

Awesome thanks @Mihai-P this what I was hoping for ...
If you don't mind can I ask how you link your products to product categories?  I have a model called BlogSite (resembles a blog/website) which I want to categorize and have it listed under a directory with something like /directory/{cat_level_1}  and /directory{cat_level_1}/{cat_level_2} which lists the appropriate blogSites.

I have not done that, but you could try using the sluggable behavior http://www.yiiframework.com/doc-2.0/yii-behaviors-sluggablebehavior.html .

Cool thanks will check it out.
How if I may ask do you link your products to categories?
On 3 Oct 2017 10:27 pm, "Mihai-P"<EMAIL_ADDRESS>wrote:

I have not done that, but you could try using the sluggable behavior
http://www.yiiframework.com/doc-2.0/yii-behaviors-sluggablebehavior.html .
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/creocoder/yii2-nested-sets/issues/113#issuecomment-333967948,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH_CtnSoYXnRzOjNrLO01dKIZe9sSvh4ks5sopitgaJpZM4Pqvjg
.

Depends on the requirements, sometimes the products table have a category_id field (when products belong to 1 category only) or with a category_product relationship table when a product can belong to multiple categories.

OK thanks much thought that might be case just wanted to confirm :D


Misc doc changes

Besides other changes, this commit ensures the generated HTML doc for
HexDocs.pm will become the main doc source for this Elixir library.
List of changes:

Set readme as main html doc
Fix markdowns
Fix typos
Update gitignore
Update formatter config
Use common source url
Fix spdx license id
Update license section
Badges and more badges!

Screenshot:

Docs for 0.4.3 have been published!


Add network isolation test example.

What would be the use case for this? Is this purely for documentation/demo or can people inherit this config downstream?

What would be the use case for this? Is this purely for documentation/demo or can people inherit this config downstream?
EDIT: Ah I see the title -- seems like this is to provide an example/demo then.

I set out to write a unit test which couldn't access the network. I wasn't sure if I'd need to write a library based on SecurityManager, a test annotation, or what. It turns out that SecurityManager is deprecated and scheduled for removal, with no great replacement. The only promising way I found was this approach, from StackOverflow: https://stackoverflow.com/a/67550942


[ photoprism ] Upload cron job not working since updating to 220517-jammy

Which addon?

Addon name : PhotoPrism
Addon version : 220517-jammy

Describe the bug
New photos uploaded and imported do not show in search when ordered by show most recently added.
It worked in 220302-impish .

To Reproduce

upload new photos
import new photos
look in search and order by recently added and see your new photos are not there.

Full addon log
Starting...
/etc/cont-init.d/00-banner.sh: executing
-----------------------------------------------------------
 Add-on: Photoprism
 A server-based application for browsing, organizing and sharing your personal photo collection
-----------------------------------------------------------
 Add-on version: 220517-2
 You are running the latest version of this add-on.
 System: Debian GNU/Linux 11 (bullseye)  (amd64 / qemux86-64)
 Home Assistant Core: 2022.5.5
 Home Assistant Supervisor: 2022.05.2
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums
 https://github.com/alexbelgium/hassio-addons
-----------------------------------------------------------
/etc/cont-init.d/32-nginx_ssl.sh: executing
/etc/cont-init.d/90-config_yaml.sh: executing
Using config file found in /config/addons_config/photoprism/config.yaml
Config file is a valid yaml
[08:27:08] INFO: Starting the app with the variables in in /config/addons_config/photoprism/config.yaml
PHOTOPRISM_SITE_URL=https://photos.blah/
/etc/cont-init.d/92-local_mounts.sh: executing
/etc/cont-init.d/92-smb_mounts.sh: executing
Mounting smb share(s)...
[08:27:09] FATAL: The structure of your "networkdisks" option : "//server/share" doesn't seem correct, please use a structure like //<IP_ADDRESS>/sharedfolder,//<IP_ADDRESS>/sharedfolder2. If you don't use it, you can simply remove the text, this will avoid this error message in the future.
/etc/cont-init.d/99-run.sh: executing
[08:27:09] INFO: Defining database
[08:27:09] INFO: Using MariaDB addon. Requirements : running MariaDB addon. Discovering values...
PHOTOPRISM_DATABASE_DRIVER=mysql
PHOTOPRISM_DATABASE_SERVER=core-mariadb:3306
PHOTOPRISM_DATABASE_NAME=photoprism
PHOTOPRISM_DATABASE_USER=service
PHOTOPRISM_DATABASE_PASSWORD=
[08:27:14] WARNING: Webtrees is using the Maria DB addon
[08:27:14] WARNING: Please ensure this is included in your backups
[08:27:14] WARNING: Uninstalling the MariaDB addon will remove any data
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'CHARACTER SET = utf8mb4' at line 1
[08:27:15] INFO: Please wait 1 or 2 minutes to allow the server to load
[08:27:15] INFO: Default username : admin, default password: "please_change_password"
[08:27:15] INFO: App launched...
started 220517-bookworm as root (amd64-prod)
Problems? Our Troubleshooting Checklists help you quickly diagnose and solve them:
https://docs.photoprism.app/getting-started/troubleshooting/
file umask....: "0002" (u=rwx,g=rwx,o=rx)
home directory: /photoprism
assets path...: /opt/photoprism/assets
storage path..: /share/photoprism/storage
config path...: default
cache path....: default
backup path...: /share/photoprism/backup
import path...: /share/photoprism/import
originals path: /share/photoprism/originals
running as uid 0
photoprism start
time="2022-05-23T08:27:24+01:00" level=info msg="PhotoPrism® needs your support!"
time="2022-05-23T08:27:24+01:00" level=info msg="Visit https://docs.photoprism.app/funding/ to learn more."
time="2022-05-23T08:27:26+01:00" level=info msg="webdav: /originals/ enabled, waiting for requests"
time="2022-05-23T08:27:26+01:00" level=info msg="webdav: /import/ enabled, waiting for requests"
time="2022-05-23T08:27:26+01:00" level=info msg="http: starting web server at <IP_ADDRESS>:2341"

PS. I have changed my password, so this line isn't true:
Default username : admin, default password: "please_change_password"

Full addon config

BACKUP_PATH: /share/photoprism/backup
CONFIG_LOCATION: /config/addons_config/photoprism/config.yaml
DB_TYPE: mariadb_addon
IMPORT_PATH: /share/photoprism/import
ORIGINALS_PATH: /share/photoprism/originals
STORAGE_PATH: /share/photoprism/storage
UPLOAD_NSFW: true
certfile: fullchain.pem
cifspassword: password
cifsusername: username
keyfile: privkey.pem
networkdisks: //server/share
ssl: false
System

Supervisor version: Home Assistant Supervisor 2022.05.2
Host system version: Home Assistant Core 2022.5.5

Hi, thanks. To be clear, they only don't appear in this view or they aren't uploaded at all ?
I'll have to look if this is an issue with the addon, or the underlying app

Hi, I can't replicate. I've installed the latest version and have the exact same log as you (mentioning the default username / password is still correct as it says it is the default and not current). I've uploaded a picture, approved it in the "review" tab, then it appeared on my recent files... Are you sure your files are not stuck in review?

I use the Photosync app to upload into the import folder, and then I run the following on a cron using docker exec:
photoprism mv /share/photoprism/import

Hmmm, I've never had to use the review tab before... is that enforced now?
I've got 6K of photos in there, is there any way to approve them all?

Hi, do you need the cron? According to documentation, auto import is a built in function : https://docs.photoprism.app/user-guide/library/import/

Hi, so if I understand correctly your issue, it is that your cron command stopped working ?
Several options :

with webdav - If you go in the webui, in library, import, you can set the move function and upload all files at once if needed. All files added in the future in the upload folders should be automatically uploaded baesd on photoprism documentation. This only works with webdav https://github.com/photoprism/photoprism/issues/1288
with cron : you could use another command sur as this one docker exec -it photoprism photoprism import https://github.com/photoprism/photoprism/issues/281#issuecomment-1067956594
For info, cron job request ongoing : https://github.com/truecharts/apps/issues/2467

Edit : I've put files in the import folder and have tested both the import from UI option, and the command photoprism import successfully. I've therefore removed the "bug" tag as everything seems to work as intended

I have no idea what the cause of the issue was now, but it's gone after a restart of Home Assistant.

Ah ah, well in the end what is important is that it works ;-)


Problem upgrading to v22.09

Describe the Bug
When upgrading to v22.09 from 22.07.3, I received this error:
From https://github.com/BookStackApp/BookStack
 * branch              release    -> FETCH_HEAD
Updating 1fdf854e..2ac9efae
error: Your local changes to the following files would be overwritten by merge:
        app/Config/app.php
Please commit your changes or stash them before you merge.
Aborting

I assume this was because my app.php file was different to the one it was being updated with (my app.php has a custom entry for file upload size)?
I renamed the app.php file and re-ran
git pull origin release
composer install --no-dev
php artisan migrate

and all seems to have updated correctly - I reverted app.php to my original version after doing this. Adding these comments in case anyone else has a similar problem.
Steps to Reproduce
Upgrade using the command above
Expected Behaviour
The upgrade process to complete without an error
Screenshots or Additional Context
No response
Browser Details
Firefox 104.0.2 64 bit on Ubuntu 22.04 LTS
Exact BookStack Version
v22.0.7
PHP Version
8.0.22
Hosting Environment
Ubuntu 22.04 LTS on HP server

Hi @techauthoruk,
This would be expected behaviour in that scenario.
Editing of the app/ files is not supported and will cause upgrade conflicts.
I believe there's a warning at the top of the edit file to advise against editing.
If you let me know exactly what line you've altered, I should be able to provide the officially support way of performing the config change made here.

Hi @ssddanbrown
I use a bash script file to backup all my BookStack files and databases and then perform the upgrade to the latest version, which may well be the reason I didn't see any warnings or other prompts...maybe I should look at updating my script to give some sort of prompt!
The line changed in my app.php file was:
    // The limit for all uploaded files, including images and attachments in MB.
    'upload_limit' => env('FILE_UPLOAD_SIZE_LIMIT', 2048),

I think the original entry here for file upload size was 50, but I had to change this as even though my Apache and php upload limits were set at 2048 in their respective .ini files (and having code suggested in your support notes in the custom head section within BookStack), I couldn't upload large files until I changed this value. The error may be mine in that I missed some other changes I should have made, but all works fine with this entry in app.php. I'm no expert in this!

Hi @techauthoruk,
The proper way to change that option would be by adding:
FILE_UPLOAD_SIZE_LIMIT=2048

to your .env file, found in the root folder of your BookStack install.
This is documented in our docs here: https://www.bookstackapp.com/docs/admin/upload-config/#bookstack

and having code suggested in your support notes in the custom head section within BookStack

That was an old mechanism that was replaced with the above.
This change can be found in our update notes here: https://www.bookstackapp.com/docs/admin/updates/#updating-to-v2111-or-higher  ("Updating to v21.11 or higher" section)

Ah @ssddanbrown
Fair comment, although as a non-technical user, it's a bit of a stretch to expect me to check all the revision/update notes to see what the changes have been :D - remember, many of us are user-admins with a limited degree of technical prowess!
I will remove the code in the custom head section & revert the app.php file to the default 50Mb setting to avoid future issues (I assume that this is the correct action to take?). I will test for uploadfs and then see what happens on the next app update

mmm...doing this has (seemingly) removed all my shelf/book custom images! Not what I was expecting and I don't have time to investigate this further today.

Wow!!!!!!
Making these (seemingly small) changes have resulted in not only losing all my custom book images, but also when I try to log in producing an error message that says "The image '...\image filename hidden.png' cannot be displayed because it contains errors"
Why? What has happened to cause this? What have I done to do this and does it mean I need to upload ALL my custom images and reassign them?

it's a bit of a stretch to expect me to check all the revision/update notes to see what the changes have been :D

Always worth checking the official updates page before updates though, I ensure any potentially breaking changes or security notices are listed there for each version change.

I will remove the code in the custom head section & revert the app.php file to the default 50Mb setting to avoid future issues (I assume that this is the correct action to take?).

Yes, The latest release version of the file can be found here.

Why? What has happened to cause this?

I don't know, Changing the mentioned files alone (.env, app.php) should not cause this unless there are maybe formatting issues.

Can you confirm the output of running git status in your BookStack install directory?
Can you confirm the exact change made to the .env file.
Can you confirm if you have a STORAGE_TYPE option set in your .env fille.
Can you confirm what the current error message looks like? Does the error show with BookStack branding?

No, changing config options alone should not delete/break existing images unless something else has been ran in an attempt to fix things. I'd expect them to re-show once configuration issues have been resolved.

@ssddanbrown
Dan
Don't know what happened, but reverting the configs made no difference. I ended up restoring my install from a backup in its entirety, and all is now working as it should. Something obviously got corrupted, but thank you daily backups!
I have made the changes to the .env file and /Config/app.php is now in line with the structure you suggested.
Mark

Good to hear things are back working. Will therefore close this off.


Deployment

#Deployment
##User Story
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information
##Acceptance Criteria
GIVEN a Prework Study Guide website,
WHEN I visit the website using the URL,
THEN I can access my website form any browser

This is complete


Progress Bar Not Hiding After Download Completion

The progress bar on the download page is not hiding after the download is completed. Once the download is finished, the progress bar remains visible, which can be confusing for users and may cause them to think that the download is still in progress. This issue is particularly problematic for users who download large files, as the progress bar may stay visible for a long time after the download is finished. The progress bar should disappear automatically once the download is complete to provide a clear indication that the process is finished.

Hey!
Which file contains the progress bar?

@SahilDave04 setup.py, but I decided to fix it 😅, you can try to depopulate the infobox  widget 5 seconds after completing the download, so ill keep this is issue for now.


Release it to Nuget

It's a great lib. If we can get it easily in Visual Studio, it'd be better. Nuget is a platform(tool) for this.

Thanks for the proposal, but it looks like too much work...