Case studies demos don't work on iOS 13.2

Describe the bug
The case studies demos don't work on iOS 13.2. This issue is similar, if not identical, to #238.
This is the case in both the latest release (0.9.0) and the main branch as of today (at commit c1f88bd8608e8a26fd61ab46c9f11a63b0f4023d)
To Reproduce

Clone the repository.
Open ComposableArchitecture.xcworkspace
Select the "Case Studies (SwiftUI)" scheme
Select a simulator running 13.2 (I specifically tested this on the "iPhone 11 (13.2.2)" simulator)
Build & Run
In the application tap the "Basics" row
Tap the "+" button on the counter
Note the number doesn't change from zero

Expected behavior
The counter number should increase to 1
Environment

Xcode Version 12.3 (12C33)
Swift 5.3
OS (if applicable): iOS 13.2, 13.1, and 13.0

iOS 13 itself has many bugs with SwiftUI and Combine until version 13.4

Sure, but if you look at the other issues this was fixed and regressed. This is also not related to SwiftUI at all, it reproduces in the UIKit case studies as well. It's likely a combine issue, since it was fixed before, I'm wondering if there's some #if available trickery that would make it work across all iOS 13 versions. Otherwise I'm probably going to have to drop using TCA and I really don't want to, I'm loving working with it.

I have a suspicion that this issue might be related to this: https://forums.swift.org/t/question-about-valid-uses-of-observableobject-s-synthesized-objectwillchange/31141/2
In the ReactiveSwift fork of TCA, I added the following property in ViewStore to ensure that this wasn't a problem:
https://github.com/trading-point/reactiveswift-composable-architecture/blob/master/Sources/ComposableArchitecture/ViewStore.swift#L104
public lazy var objectWillChange = ObservableObjectPublisher()

In theory, just by conforming to ObservableObject (like ViewStore does), you get an objectWillChange property synthesised for you (some magic happening here to allow a protocol to have stored properties 🧙♂), but if you don't have @Published property you get a new instance every time, which will cause the bug you are seeing. Note that ViewStore no longer uses @Published - also worth reading the comments on that PR btw.
It seems that in iOS 13.3 and above this issue was fixed in Combine.
So, I think this would be fixed it this property were added to ViewStore:
public lazy var objectWillChange = ObservableObjectPublisher()

It doesn't need @available checking as there's no harm in it being there even with the fixed versions of Combine.
@nsillik would you be able to test if the change above fixes this issue?

I have a suspicion that this issue might be related to this: https://forums.swift.org/t/question-about-valid-uses-of-observableobject-s-synthesized-objectwillchange/31141/2
In the ReactiveSwift fork of TCA, I added the following property in ViewStore to ensure that this wasn't a problem:
https://github.com/trading-point/reactiveswift-composable-architecture/blob/master/Sources/ComposableArchitecture/ViewStore.swift#L104
public lazy var objectWillChange = ObservableObjectPublisher()

In theory, just by conforming to ObservableObject (like ViewStore does), you get an objectWillChange property synthesised for you (some magic happening here to allow a protocol to have stored properties 🧙♂), but if you don't have @Published property you get a new instance every time, which will cause the bug you are seeing. Note that ViewStore no longer uses @Published - also worth reading the comments on that PR btw.
It seems that in iOS 13.3 and above this issue was fixed in Combine.
So, I think this would be fixed it this property were added to ViewStore:
public lazy var objectWillChange = ObservableObjectPublisher()

It doesn't need @available checking as there's no harm in it being there even with the fixed versions of Combine.
@nsillik would you be able to test if the change above fixes this issue?

@mluisbrown that's an awesome find! I'm in meetings all day today and tomorrow, but I'll check this and if it works submit a PR.

@mluisbrown that's an awesome find! I'm in meetings all day today and tomorrow, but I'll check this and if it works submit a PR.

@mluisbrown very nice. Seems to work! Thank you.

@mluisbrown very nice. Seems to work! Thank you.

@nsillik Do you still plan on PRing a fix for this? Would love to have this working for folks 😄 If you don't have time we can look into it soon.

@nsillik Do you still plan on PRing a fix for this? Would love to have this working for folks 😄 If you don't have time we can look into it soon.

Was just about to do this. Should have it done by the end of the day.

Was just about to do this. Should have it done by the end of the day.

@stephencelis  #353

@stephencelis  #353

I guess this issue can be closed now that #353 was merged?

I guess this issue can be closed now that #353 was merged?


ResourceAdapter: support containers (WildFly/JBoss) that do not start a transaction (use the XAResource interface)

Problem:
in seems that on JBoss 5 the messages are not acknowledged while running inside a Message Driven Bean.
The user reported that he has to manually call Message.acknowledge() to see the message acknowledged.
This is not good because when the Session is "transacted" the acknowledgement is automatic and it must happen on Session.commit(),
Here we are in the ResourceAdapter and we are in the PulsarMessageEndpoint
https://github.com/datastax/pulsar-jms/blob/c3a0073232d4498dde1a407d1807f8925430a838/resource-adapter/src/main/java/com/datastax/oss/pulsar/jms/rar/PulsarMessageEndpoint.java#L177
the message is acknowledged() on "commit()", so if we have to manually call acknowledge() then it means that the Container is not calling "commit()" on the XAResource.
Modifications:

PulsarMessageEndpoint: ack/nack the message if the MessageEndpoint did not call "start" on the TransactionControlHandle
add tests about Transactions and MessageListener (not related to the ResourceAdapter, but this about MessageListeners and transactions)

@akhil1000 This is the fix for the weird behaviour you observed on JBoss and @MessageDriven beans

@akhil1000 patch merged.
It will be released on the next release train
thanks for your feedback

Thank you, Enrico


Make click_rich extra dependency; Migrate tox to nox

click_rich introduce a lot of extra dependencies that are not required to run robotidy and bloats install for users who only want to use robotidy API.
This change move click_rich dependency to rich profile. Install robotidy with rich profile to get it:
pip install robotframework-tidy[rich]

Migrated tox to nox. It's easier to create dev scripts with Python itself and it also allows to easily install the package for testing in a way it's done by user. Reduced the amount of placed with defined requirements list.
There was also typo extras_requires -> extras_require (easy one to make - install_requires have s and setup.py doesn't complain about it). Our extras profiles didn't work since the beginning!
Closes #303

Codecov Report

Merging #304 (f09efff) into main (ca622f9) will decrease coverage by 1.67%.
The diff coverage is 34.78%.

@@            Coverage Diff             @@
##             main     #304      +/-   ##
==========================================
- Coverage   97.61%   95.94%   -1.68%
==========================================
  Files          37       37
  Lines        2561     2616      +55
==========================================
+ Hits         2500     2510      +10
- Misses         61      106      +45

Impacted Files
Coverage Δ

robotidy/rich_console.py
17.07% <17.07%> (ø)

robotidy/app.py
93.39% <50.00%> (-1.75%)
:arrow_down:

robotidy/decorators.py
70.83% <50.00%> (-5.36%)
:arrow_down:

robotidy/files.py
92.63% <50.00%> (-1.94%)
:arrow_down:

robotidy/transformers/__init__.py
98.01% <50.00%> (-1.99%)
:arrow_down:

robotidy/cli.py
96.20% <75.00%> (-1.85%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ca622f9...f09efff. Read the comment docs.


Repository pattern should not be used by default

I've noticed here and elsewhere you preach using the repository pattern IRepository on top of IDbSet which is already the repository pattern. Sometimes it is necessary to put abstractions on top of abstractions but those decisions shouldn't be taken lightly.

I recommend practices that result in clean, loosely coupled code. One such practice is depending on interfaces that you control, rather than third party vendors, for your domain model. It takes virtually no effort to create a small interface with 1-5 methods to abstract access to data, and uses only POCOs (so no dependency on a particular data access technology). If instead you rely on IFoo from vendor Bar, which exposes types also owned by vendor Bar, it's generally much more difficult to change later, and frequently to unit test as well.

Also: if you wait till you need it, which is in general a good philosophy, it can be difficult to factor in later. Especially when architecture starts settling around the vendor pattern.
I use repositories for 1) EF data access, 2) large-scale bulk insert, 3) caching, and 4) in-memory testing.
The general idea is that domain logic depends on repositories, not vendor-specific data access. That way domain logic doesn't need to know where entities come from. It doesn't know or care if I'm backing it with a database, whether I'm batching or caching or testing.

Also good points. I forgot to mention that using your own interfaces enables caching patterns like this one: http://ardalis.com/building-a-cachedrepository-via-strategy-pattern
And suppose in this example I decided EF wasn't the best option and I wanted to just use a micro-ORM like Dapper (https://github.com/StackExchange/dapper-dot-net). Doing so with my dependency only on my own type is trivial compared to ripping out vendor-specific interfaces littered throughout my program's layers.

@ardalis
Seconded... personally I tend to create a repository, then swap between say InMemory implementation for Tests,  MongoDB for local development, then DocumentDB for production.
Just because EF has a pattern that could be construed as a Repository, it doesn't mean that a Repository is redundant.

@ardalis
Seconded... personally I tend to create a repository, then swap between say InMemory implementation for Tests,  MongoDB for local development, then DocumentDB for production.
Just because EF has a pattern that could be construed as a Repository, it doesn't mean that a Repository is redundant.

The general idea is that domain logic depends on repositories, not situation-specific data access.
The domain logic should never depend on infrastructure. If it does, your direction of dependencies will break-down. IQueryable is all your domain needs to know about.

In my experience, 90% of the time, IRepository is YAGNI.

domain logic depends on repositories, not situation-specific data access

The domain logic should never depend on infrastructure.

These two statements are saying the same thing. In the first one, perhaps it's not clear that he means abstractions/interfaces, defined in the Core of the application, not specific repository implementations. But that's what's meant.
IQueryable shouldn't be exposed outside of your data access code if possible, especially if you're using Entity Framework, because it is a very leaky abstraction. It enables complex querying behavior, including business logic, to be embedded into UI layer code, and can result in code that will compile and work perfectly well with on backing store (say, an in-memory collection) but will fail at runtime when used with EF (because EF can't translate something into SQL). It's another example of how EF can embed itself into your application, escaping from the data access layer where you'd want to keep it if you're following separation of concerns.

IQueryable is all your domain needs to know about.

The problem with IQueryable is that it ends up coupling you to vendor-specific infrastructure quirks. I know in theory it sounds perfect, but in practice, IQueryable forces you either to:

Make your domain model also double as your persistence model

You are forced to lose richness in the domain model in order to make your persistence infrastructure happy
The queries you write are very query provider sensitive with special treatment around eager loading, navigation properties, etc. Queries will act differently and even fail between query providers, including the default LINQ to objects provider.

Write code around translating the IQueryable back and forth between models.

This is a lot harder than using an IRepository to translate because the possible compositions off IQueryable are endless.  (If you use AutoMapper, you have another set of infrastructure quirks to worry about. AutoMapper was not designed for this, according to its author.)

IRepository solves this by presenting a more limited surface area than IQueryable. If you depend on a well-designed IRepository, you're depending on less than if you depend on IQueryable.
As far as getting information, IRepository as an interface is thus not infrastructure but it is a simpler IQueryable. Of course, it might be implemented by infrastructure classes but the domain model will never know that.
As far as saving changed aggregates or adding newly created aggregates, IQueryable doesn't help you unless yet again you use vendor-specific infrastructure-specific extension methods.
In onion architecture as I understand it, the application layer is responsible for injecting the proper infrastructure into the domain. That's the application layer's buffer between infrastructure and domain. The domain doesn’t know what infrastructure it's using, it only knows how to call it via a common non-infrastructure-specific interface (IRepository).

@jarrettv Here's something to consider to back up the idea that IRepository is a domain interface, not an infrastructure interface. In good SOLID architecture, interfaces are owned not by the implementers but by the clients of the interface. The client programs to the interface whose sole purpose is to fit the client's needs. IRepository was created out of the responsibilities of the domain services, not out of the needs of the infrastructure services.

If I had seen @ardalis's post I wouldn't have gone into so much depth- good summary.
@jarrettv Here's something to consider to back up the idea that IRepository is a domain interface, not an infrastructure interface. In good SOLID architecture, interfaces are owned not by the implementers but by the clients of the interface. The client programs to the interface, whose sole purpose is to fit the client's needs. IRepository was created out of the responsibilities of the domain services, not out of the needs of the infrastructure services.

Wow great conversation here. I would be fun to have a friendly YouTube debate on the topic.
There is a buffet of patterns in DDD and when you are loading your plate up to solve a problem, there is no rule saying you must take this (IRepository) and that (IDomainEvent).
You offer good arguments on why IRepository is useful, but none of these reasons were driven by a business need.
When organizing your solution, there will always be compromises such as:

Make your domain model also double as your persistence model

My argument is evaluate the business problem you are trying to solve and then decide what patterns are necessary. This was my beef with the Dependency Injection page on docs.asp.net. (It looks like someone cleaned it up)
For low to medium business complexity, I find IDomainEvent and IQueryable good enough to isolate my domain from the infrastructure.

IQueryable shouldn't be exposed outside of your data access code ... because it is a very leaky abstraction

IQueryable is a useful compromise for dealing with large aggregate roots. The alternative is more code and more complexity. If you can't tell by now, I lean towards less code is better. 💪

IRepository is a domain interface, not an infrastructure interface

Persistence is infrastructure. Business doesn't and shouldn't care about CRUD or SaveChanges. Let that infrastructure stuff stay in your controller/handler.

the application layer is responsible for injecting the proper infrastructure into the domain

IMHO, there shouldn't be any infrastructure in the domain. Furthermore, I rarely see the need for domain services -- especially as we strive for bounded contexts thru micro-services.

In any substantial codebase, I doubt based on my experience that your approach would, in fact, yield less code overall.  If you ever need to query a set of entities twice in similar ways, you'll end up with that duplication in multiple controller action methods or UI event handlers. If you were using an interface to abstract that need, you would likely identify it as a common requirement and push the common querying logic into the interface (perhaps as a new method on a repository interface). This is far less likely if you just say the UI layer is the wild west and infrastructure concerns are fair game there alongside UI and domain objects.
You can write applications this way, and they'll work, but they're likely to be more expensive to maintain in the long run. The UI layer is also likely to violate SRP, OCP, DRY, etc. and if you're not bothering to abstract out data access you may just opt not to use abstractions (i.e. interfaces) at all, in which case you could argue you're violating ISP (though it's a stretch if you're not actually using any interfaces). I have clients who pay me to fix this kind of code. They're generally happy with the results once I show them the benefits of applying these principles and the ease with which the resulting codebase can be maintained and modified.
By all means, start out without IRepository. But follow Separation of Concerns. Follow DRY. Follow SRP and ISP and DIP. And see if there is a better way to keep data access from polluting other, unrelated aspects of the application. I've not found one, which is why for non-throwaway applications I stick with abstracting it away.  If you think your application is going to live longer than that and might need to use a new data access stack, it's really not that hard to code to an abstraction rather than hard-coding dependencies on implementation details everywhere.

Would it be more accurate to mark ApplicationDbContext and EfRepository internal and program only against IRepository<T>? Then I just wonder what would be the correct way to map abstractions to implementations in Startup class when registering services if context implementation and EF repository would be located in different assembly. Play with InternalsVisibleTo?

More accurate? I'm not sure what you mean by that.
If you do have dependencies in other projects/assemblies that need wired up at startup, you can use capabilities of third party containers to achieve this. For instance with StructureMap you can have a Registry class in the separate project (and thus with access to internal types there), and then configure the container to use this registry at application startup. Does that help?

In my domain model assembly I'll have the domain's client interface definition, IRepository, but no reference to my persistence assembly.
In my persistence assembly, I'll have a reference to the domain model assembly.
My client assembly (the one with Program.Main and application logic) has references to both assemblies. I have my composition root here (I use Castle.Windsor) which registers concrete public repository classes from the persistence assembly for the IRepository interface. If you aren't using an IoC container, you would create instances of the concrete repository classes in the application assembly and pass them to the domain services that only know about the IRepository interface.
InternalsVisibleTo is not a good design here in my opinion.

So if I'm using pure DI, then composition root (located in client's assembly) would need to have access to precise type of repository class from the persistence assembly anyway (e.g. EfRepository<T>). Either I would need to open it up for "public" access or use internals visible to.
Of course IoC containers would come and help me to discover registry in persistence assembly and map repositories to interfaces.
Just thinking in more theoretical level - for instance in ports & adapters architecture cases. When repository implementation is physically "outside" from domain assembly. Does it really matter to protect repository implementation then?! Then assemblies really become only as packaging mechanism and not used for encapsulation.
What are your thoughts and experience?

It's convenient if the composition root/client assembly has access to implementation types in the infrastructure project(s). But it's not required. I blogged about a simple way to use the types without such references here: http://blog.falafel.com/use-types-from-project-without-referencing/. If that's important to you, and/or if your team lacks the discipline to not use types from Infrastructure in the client project, it can be a good approach to maintain the encapsulation you're looking for, IME.

Think you are right regarding defensive approach - it's more question about team self-disciple to use types from assemblies "allowed" not from assemblies "available".
Thanks all!

If you do keep the references, you could also use a tool like NDepend to detect usage of Infrastructure types from the UI/client project.

@ardalis It looks like I have something to learn. I wasn't aware that there was a great benefit to preventing the UI client from using infrastructure classes; in fact I thought it was its responsibility.
For example, caching is applied some places but not others, and batching is used some places and not others. I'm accomplishing this by having the application logic use new CachingRepository or new BulkMergeRepository instead of the default repository.
Is that type of access harmful for the application logic? How else does the application logic get to decide, or what is responsible to decide if not the application logic?

@jnm2 I do think it's best if the front end/UI only works with abstractions, not implementations, and thus doesn't directly use types in Infrastructure. To answer your specific question, that's simply a matter of choosing which collaborators your system will use at runtime. Usually this is the responsibility of the IOC container. Have a look at my articles on the CachedRepository pattern to see how you would do this.
http://ardalis.com/introducing-the-cachedrepository-pattern
http://ardalis.com/building-a-cachedrepository-via-strategy-pattern
After reading those, please reply back here with what you think.

Regarding the caching - I still think that it's mostly pure infrastructure cross-cutting concern and composition root might decide where to put caching or not. Original repository should not be aware of caching as such. And also - I would look for using decorator api - this way you can simply write:
For<IRepository<Ninja>>().DecorateAllWith<RepositoryWithCache<Ninja>>();

But I guess it's just a matter of taste - idea does not change.

Hmm. So the decision whether to cache or batch is made in the wiring of the composition root, if you have one.

How would this work if in one application service or view model I wanted caching and in another I did not, for the same entity?
What about a client that doesn't currently use an IoC container?
In my scenario, batching is more specialized. Nothing happens when entities are saved. A BulkMergeRepository-specific method is called to flush. What abstraction should be used here? IDisposable isn't quite right. I don't see value in abstracting this anyway because using a normal write-through repository performs terribly. Is this a poor design?

You can always specify in your IOC what types a particular type wants to use. I rarely do this, but it's supported. So if you have one service that wants a cached repo and another that doesn't, you can specify that. If you wanted to specify it elsewhere, like in the service itself, one option would be to use marker interfaces. ICachedFooRepository could inherit from IFooRepository but not change its signature at all. Services could request ICachedFooRepository as a way of specifying they want cached behavior.

Clients that don't use IOC that need to work with services that expect DI must simply instantiate the dependencies manually.

This sounds like a UnitOfWork pattern. Are you familiar with it? Batching and Committing are UoW concerns and could be modeled that way.

I would be afraid that would introduce behavioral coupling between the wiring code and each particular type, because each type knows whether it wants caching. Marker interfaces are a good solution; in fact IBulkMergeRepository is also a good solution. I'm happy with this.

I probably don't have a practical enough understanding of UnitOfWork yet. The DDD ideology  as I understand it states that transactional boundaries should be on single aggregate roots, so IRepository.Save() already implements the only transaction I should be allowed to use.
Except for this bulk merge case. In this case the atomicity is not the aim, the aim is only the practical difference in speed between SqlBulkInsert and Entity Framework.

From my experience - it was OK enough to introduce this ""behavioral de/coupling". Made services/view models dumb enough to not to care about caching - but instead moved that responsibility to the composition root (DI registries in my case). What I personally liked about this approach - is flexibility you get. When you decide and are forced to implemented caching in the service or view model, the only place you need to change this behavior - is composition root. Reset of the services are not affected.
Will that make code more readable and understandable - if reading service source code you might be wondering - is this guy using cache or not? I guess Mark has already answered that.

This was a great discussion but I'm closing the issue now.


Think about to fix the issues found by adapter checker

I am an automatic service that looks for possible errors in ioBroker and creates an issue for it. The link below leads directly to the test:
https://adapter-check.iobroker.in/?q=https://raw.githubusercontent.com/iobroker-community-adapters/ioBroker.discovergy

[ ] [E115] No license found in io-package.json
[ ] [E201] Bluefox was not found in the collaborators on NPM!. Please execute in adapter directory: "npm owner add bluefox iobroker.discovergy"

ERR:["E115","E201"]:ERR
Thanks,
your automatic adapter checker.

fixed :
https://github.com/iobroker-community-adapters/ioBroker.discovergy/commit/e86e0ac1b175c01949221a005c8d9f17649ac4bf


support  the env variables  in requirements.txt

info from slack

why raised issue in here? it's irrelevent


Add .nvmrc and match accepted nodejs engine version

Angular2 has added a .nvmrc (https://github.com/angular/angular/blob/master/.nvmrc). I believe angular-cli should integrate this as well to give developers an easier time switching to the project's recommended nodejs version.

fixed in #65


New SPPublishServiceApplication Resource

This Pull Request includes a new DSC Resource SPPublishServiceApplication that publish a Service Application.

[x] Change details added to Unreleased section of changelog.md?
[x] Added/updated documentation and descriptions in .schema.mof files where appropriate?
[x] Examples updated for both the single server and small farm templates in the examples folder?
[x] New/changed code adheres to [Style Guidelines]?(https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md)?
[x] Unit and Integration tests created/updated where possible?

This change is

Sorry I merged non-desired commit, I'll come back with the good commit.
Thanks


bug: "reveal" type menu on iOS causes menu hamburger button not to work

Bug Report
On iOS app when triggering navigation using Back button from a "child" page quickly clicking menu's hamburger button (while back animation is still in progress) causes that button to stop working until swipe gesture is used to re-open the menu.
Ionic version:
[x] 4.11.2
Current behavior:
The menu's hamburger button becomes unusable (can't open menu) until menu is re-opened with a swipe gesture.
Expected behavior:
Menu hamburger button should open the menu.
Steps to reproduce:

In Ionic native app on iOS (that has menu with "reveal" type) navigate forward to a child page so that Back button is displayed.

Try clicking on the menu button to open the side menu once both animations finish.

Other information:
The button / menu works fine in iOS native app when menu's type is "overlay".
Ionic info:

Ionic:

   Ionic CLI                     : 5.4.4 (/Users/[username]/.nvm/versions/node/v10.15.3/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.11.2
   @angular-devkit/build-angular : 0.803.15
   @angular-devkit/schematics    : 8.3.15
   @angular/cli                  : 8.3.15
   @ionic/angular-toolkit        : 2.1.1

Cordova:

   Cordova CLI       : 9.0.0<EMAIL_ADDRESS>   Cordova Platforms : ios 5.0.1
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 2.5.3, (and 12 other plugins)

Utility:

   cordova-res : 0.8.0 (update available: 0.8.1)
   native-run  : 0.2.9

Thanks for the issue. Can you provide a repo with the code required to reproduce this issue? I am unable to reproduce this on the Ionic sidemenu starter (with type="overlay" changed to type="reveal")

Hi @liamdebeasi , are you using native iOS app? Web works fine. I'll try to provide a repo once I get a chance. Thank you.

Ah sorry I missed that part - let me give that shot real quick.

Same result when running as a standalone app. We typically disable pointer events during the transition and then re-enable it after the transition. A repo when you get a chance would be great. Thanks!

@liamdebeasi Hi, I did a few tests and I think I discovered what caused issues with Back button / hamburger button display in our app. We have a custom component to render the contents of a header. Of course, when it was rendered extra node was inserted into the DOM between ion-header and ion-toolbar components. Apparently, this causes some delay before the Back button is hidden during which I was able to click on the menu hamburger button. Once I updated our custom header component not to insert its node into the DOM (ion-toolbar goes right after ion-header) the Back button started to disappear once animation started (i.e without delay). And I think now things work fine when menu type is "reveal". Thank you for looking into the issue.

Also, in our case on most pages menu's hamburger button and the Back button are displayed together, which you don't have in the Ionic Conference app.


feat: persist dropdown selection

PR FOR ISSUE #35
I added the feature to persist drop down selections made by the user even if user switches or refreshes the page.
With the help of <href="http://paulrose.com/bootstrap-select-sass/">Bootstrap select sass, I added this feature using the val() and selectpicker() functions. Using sessionStorage in javascript, I added selected items to the storage every time a user selects an option from the drop down list.
And once the <selec> and <options> are rendered I call the setChecked() method to initiate checking of previously selected values and used val() to set the options to checked.

Hey @darensin01 @Jwright707,
Kindly review this PR for issue #35. Thanks!


Fix typo

Github -> GitHub

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

Merging typo fix


How to use offline mode

How do you use offline mode? It just keeps trying to connect to a certain ip but will never load.

just download 1.16.5 paper mc (https://papermc.io/api/v2/projects/paper/versions/1.16.5/builds/790/downloads/paper-1.16.5-790.jar)
easiest way to connect is just tunnel your local server with some tunnelling software like ngrok
and replace server param in minecraft.js.org url

to enable offline mode just configure online-mode=false in server.properties

Where is server.properties?


Add support for DisableCommenting in ListInstance

New property "DisableCommenting" should be introduced to ListInstance object.

Please add label status:next-version-ideas


Redux Example

Hi there,
It would be great to have an example of Reactabular used with Redux. I'm struggling to understand how props and state are supposed to interact and the breadcrumb // this could go through flux etc. in the CRUD example docs isn't enought to get me going.
In particular I'm thinking that props should be driving the rows data and that the this.state should be reserved to the component's sorting and filtering state (for instance).
Hope this might be useful to others!
Jun

Good point. In part it depends on what you want to maintain at Redux. It would be possible to push entire table state there. But, yeah, example would clear this up.


fix(types): Generate nuxt types automatically at install

This removes the need for /* @ts-expect-error */ and generally improves the DX.
I'm not sure if this is generally the recommended way to do this for modules, but it seems to work.

Typescript seems to be picking up the playground components declared in .nuxt/components.d.ts and trying to typecheck them. Oh well.

Typescript seems to be picking up the playground components declared in .nuxt/components.d.ts and trying to typecheck them. Oh well.

yea, I worked with the same problem in nuxt.com when fixing the bugs for our docs. but maybe @nuxt/types in types is the solution

@killjoy1221  did you resolves this one already?

this might be lint configuration problem only

Thanks @killjoy1221 , this is all working now 🚀

yea thanks @killjoy1221 💯


New release

When will be there a new release?
There's some features in version 0.9.3 that currently don't work but are perfectly fine in the repo.

@HalbardHobby 0.9.4 has been just released! (see #315)


iox-#1612 Move std::string conversion methods to iceoryx_dust

Signed-off-by: Simon Hoinkis<EMAIL_ADDRESS>Pre-Review Checklist for the PR Author

[x] Code follows the coding style of CONTRIBUTING.md
[x] Tests follow the best practice for testing
[x] Changelog updated in the unreleased section including API breaking changes
[x] Branch follows the naming format (iox-123-this-is-a-branch)
[x] Commits messages are according to this guideline

[x] Commit messages have the issue ID (iox-#123 commit text)
[x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[x] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[x] Relevant issues are linked
[x] Add sensible notes for the reviewer
[ ] All checks have passed (except task-list-completed)
[x] All touched (C/C++) source code files from iceoryx_hoofs are added to ./clang-tidy-diff-scans.txt
[x] Assign PR to reviewer

Notes for Reviewer

Move std::string conversion methods to iceoryx_dust

Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] Unit tests have been written for new behavior
[ ] Public API changes are documented via doxygen
[ ] Copyright owner are updated in the changed files
[ ] All touched (C/C++) source code files from iceoryx_hoofs have been added to ./clang-tidy-diff-scans.txt
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Closes #1612

@elfenpiff

Why not pursue the from and into approach? We already have it implemented for several types.
When we split this up we should it do cleanly right from the beginning in my opinion.

Yeah, that's a good idea. I used the declaration in helplets.hpp and slightly adapted it as free functions do not support partially specialized templates.


Added maxInstances & minInstances to cloudfunction config

Closes issue #55

Why would the min have a default of 1 yet the max have a default of 0?

Oops! I misread the line "enter a number greater than or equal to 1" on the documentation. Using 0 will clear and set to default, so you are correct.
Updated PR.


Bump up to v0.10.12-SNAPSHOT

Planning to release v0.10.11 with #1277, #1285, #1286, and #1287.
I already have #1289 and #1290 in the queue, but they can be impactful changes. So, I'm going to cut the version before them.

Thanks!


Blocking file IO in installation co-routine

The download co-routine has a blocking file operation. It may be best to run that operation in a process pool executed via an asyncio executor.

Thanks for the suggestion! I am uncertain that executing the write in a process pool would actually improve performance though, since the entire contents of the file would have to be pickled and copied to the new process. Is there a reason to prefer this to using a thread pool?

That's a good point. A thread pool may be the better choice

I've whipped up a couple of benchmarks and I'm unable to find any case in which the write has any appreciable impact on performance--even completely removing it I was not able to get a reliable performance improvement, with a 0.7% average speedup. It seems like downloading is always the bottleneck.
Do you have an explicit example you expect to suffer from blocking writes?


VPC endpoints are being replaced sporadically due to service_name being unknown at plan time

Description
vpc endpoints flapping sporadically due to https://github.com/hashicorp/terraform-provider-aws/issues/25568.
Commented on problem here:
https://github.com/hashicorp/terraform-provider-aws/issues/25568#issuecomment-1998004128

This is happening for us sporadically. It doesn't happen all the time. Sometimes we apply and suddenly all of our VPC endpoints need to be replaced. We aren't changing anything going into the VPC module or relating to the endpoints. Sidenote - we are deploying in govcloud.
We're using this module:
https://github.com/defenseunicorns/terraform-aws-vpc/blob/main/main.tf#L130-L256 which feeds into this ->
https://github.com/terraform-aws-modules/terraform-aws-vpc/blob/master/modules/vpc-endpoints/main.tf#L11-L21
truncated output, but it does this for all of our endpoints that get fed from that aws_vpc_endpoint_service data that feed into the aws_vpc_endpoint resource
         ~ requester_managed     = false -> (known after apply)
           ~ route_table_ids       = [] -> (known after apply)
           ~ service_name          = "com.amazonaws.us-gov-west-1.ssm" # forces replacement -> (known after apply) # forces replacement
           ~ state                 = "available" -> (known after apply)

[x] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]:
v5.5.3

Terraform version:
Terraform v1.5.7
on darwin_arm64

Provider version(s):
aws 2.4.1

Reproduction Code [Required]
<EMAIL_ADDRESS>which feeds into this ->
<EMAIL_ADDRESS>Steps to reproduce the behavior:

Deploy vpc + endpoints using https://github.com/defenseunicorns/terraform-aws-vpc which uses this module
Deploy again some time later. TF will detect that the service names are unknown and replace them for no reason.

Expected behavior
They should not be replaced if nothing is changing.
Actual behavior
The VPC endpoints are forced to be replace due to the use of the aws_vpc_endpoint_service data source, sometimes. This is due to them being known after apply.
Terminal Output Screenshot(s)
basically this, for all VPC endpoints, sometimes.

Additional context
possible solution
Ideally this module should allow the use of feeding in a service_name and doing a lookup() on that so that we can build it outside when passing in the map of endpoints, but defaulting to data.aws_vpc_endpoint_service.this[each.key].service_name if none provided.

@zack-is-cool your issue is most likely related to this https://github.com/defenseunicorns/terraform-aws-vpc/blob/f21519a579225c4f7a6e0efc05cf2cf96f0a8b89/main.tf#L255
@jordanboston do you have an explicit depends_on your module definition as well? If so, remove it

@zack-is-cool your issue is most likely related to this<EMAIL_ADDRESS>
It's odd that it's not replacing them each time the TF is applied though? This code is being deployed to long lived environments and just seems to randomly decide it doesn't know the vpc endpoints - this is without messing with the aws_ec2_subnet_cidr_reservation.this object or locals that it uses in the referenced code. I've experienced that depends_on is sometimes finicky in general.
Assuming I can't get rid of this depends_on, do you see any issue with the proposed workaround in the OP^? Or is there another way I should be handling this?

possible solution
Ideally this module should allow the use of feeding in a service_name and doing a lookup() on that so that we can build it outside when passing in the map of endpoints, but defaulting to data.aws_vpc_endpoint_service.this[each.key].service_name if none provided.

This issue has been resolved in version 5.7.0 :tada:


let gRPC client pass more parameters to services

e.g. the RunStep, RunJob, RunWorkflow endpoints should accept
verbose  bool // whether or not to log debug stuff
github   stuff // current context from git repository
// probably much more

the latter is a pretty major bug atm as the server looks in its own path to find the git repo which won't work if we are on a remote machine

started in https://github.com/frantjc/sequence/pull/41

update: server now accepts a
repository string

which it uses to get GitHub context from and lookup config with. Eventually the former will need to be offloaded onto the client
...unless the repository string is a URL, in which case the server can potentially get the GitHub context remotely. Not sure about this, though, as, off the top of my head, the server wouldn't have access to what branch the client is on


Add create-tina-app package and CLI capabilities

Users should be able to initialize a next app with a single npm init or yarn create command and specify one of our starters
Ideally this is just a package from within our monorepo but not sure
Add a vanilla starter site

Site should just have pages/index.js, pages/[something-dynamic] - which just use getStaticProps/getStaticPaths and dump the values as JSON onto the page
When admin is ready, adds /pages/admin
.tina/ folder with minimal schema

PR here: https://github.com/tinacms/tinacms/pull/2251


Missing implicit for org.joda.time.DateTime

For example:
case class Task(
  _id: Option[BSONObjectID] = None,
  title: String,
  updated: Option[DateTime] = None,
)

object Task extends Enumeration with MongoDao[Task] {
  import play.api.libs.concurrent.Execution.Implicits._
  implicit val ec = defaultContext

  private def db = ReactiveMongoPlugin.db
  def collection = db[BSONCollection]("tasks")
  implicit val handler = Macros.handler[Task]
}

will not compile as
Error:(28, 40) Play 2 Compiler:
 /Users/lorekhov/workspace/taskshot/app/models/Task.scala:28: Implicit org.joda.time.DateTime for 'value updated' not found
   implicit val handler = Macros.handler[Task]

Seems like it is a good idea - to add DateTime implicit in library :)

It doesn't seem like a good idea to me. It implies that joda time is the way to do time. While I admit that that library is good, it isn't the only way to do it. Adding support for this in ReactiveMongo (RM) would require RM to depend on joda time and I'd rather have RM without such dependencies (despite that fact that I use joda time in my projects!). At most, RM ought to provide an implict for java.util.Date or other things that are part of the Java SDK, but not third party libraries.

I agree with @reid-spencer . The support for Joda could be in a separate module, but having it in RM code would add a dependency to Joda for all projects using RM without Joda.

Sorry, I just forgot to close an issue. (As I'm agree with @reid-spencer as well.)

There is already an handler for joda DateTime in ReactiveMongo-Extensions: https://github.com/ReactiveMongo/ReactiveMongo-Extensions/blob/0.10.x/core%2Fsrc%2Fmain%2Fscala%2Fdao%2FHandlers.scala#L24


CLI10: got a few compiler crashes today with "JavaScript heap out of memory"

🐞 Bug report
Command (mark with an x)

[ ] new
[ ] build
[x] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] xi18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Is this a regression?

Yes, the previous version in which this bug was not present was Angular 9 with CLI 9.
Description

Small project freshly migrated from ng9 to 10, I sometimes get a compiler crash with "JavaScript heap out of memory" during ng serve.
It never happened to me before ng 10.
Project is available here:
https://github.com/ldex/Angular-Academy-202
🔥 Exception or Error

<--- Last few GCs --->

[1308:00000253CB798AB0] 11379648 ms: Scavenge 2033.1 (2051.3) -> 2032.1 (2051.3) MB, 5.4 / 0.0 ms  (average mu = 0.125, current mu = 0.067) allocation failure
[1308:00000253CB798AB0] 11379665 ms: Scavenge 2033.1 (2051.3) -> 2032.2 (2051.3) MB, 8.2 / 0.1 ms  (average mu = 0.125, current mu = 0.067) allocation failure
[1308:00000253CB798AB0] 11379824 ms: Scavenge 2033.5 (2051.6) -> 2032.6 (2051.6) MB, 5.4 / 0.0 ms  (average mu = 0.125, current mu = 0.067) allocation failure

<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 00007FF6513377DD]
    1: StubFrame [pc: 00007FF6513388D3]
Security context: 0x00c2be6408d1
    2: formatLocation(aka formatLocation) [00000377970C75D1] [C:\Users\beep\Desktop\DemoApp\node_modules\webpack\lib\formatLocation.js:~41] [pc=000001471AADB4D8](this=0x012e6a0404b1 ,0x002fb6ac6cd1
SourceLocation map = 00    3: /* anonymous */(aka /* anonymous */) [000003C749112FE1] [C

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF65072470F napi_wrap+113583
 2: 00007FF6506CF7D6 v8::base::CPU::has_sse+66646
 3: 00007FF6506D05D6 v8::base::CPU::has_sse+70230
 4: 00007FF650EE42EE v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF650ECC3C1 v8::SharedArrayBuffer::Externalize+833
 6: 00007FF650D9890C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436 7: 00007FF650DA3B40 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
 8: 00007FF650DA0664 v8::internal::Heap::PageFlagsAreConsistent+3204
 9: 00007FF650D95E63 v8::internal::Heap::CollectGarbage+1283
10: 00007FF650D944D4 v8::internal::Heap::AddRetainedMap+2452
11: 00007FF650DB56DD v8::internal::Factory::NewFillerObject+61
12: 00007FF650B1BF61 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1665
13: 00007FF6513377DD v8::internal::SetupIsolateDelegate::SetupHeap+546637
14: 00007FF6513388D3 v8::internal::SetupIsolateDelegate::SetupHeap+550979
15: 000001471AADB4D8

🌍 Your Environment

Angular CLI: 10.0.0
Node: 12.18.0
OS: win32 x64

Angular: 10.0.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.1000.0
@angular-devkit/build-angular     0.1000.0
@angular-devkit/build-optimizer   0.1000.0
@angular-devkit/build-webpack     0.1000.0
@angular-devkit/core              10.0.0
@angular-devkit/schematics        10.0.0
@ngtools/webpack                  10.0.0
@schematics/angular               10.0.0
@schematics/update                0.1000.0
rxjs                              6.5.5
typescript                        3.9.5
webpack                           4.43.0

Anything else relevant?

Same situation on my personal project which has been created in v10 (not upgrade from v9).

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/

Angular CLI: 10.0.0
Node: 12.14.1
OS: darwin x64

Angular: 10.0.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.1000.0
@angular-devkit/build-angular     0.1000.0
@angular-devkit/build-optimizer   0.1000.0
@angular-devkit/build-webpack     0.1000.0
@angular-devkit/core              10.0.0
@angular-devkit/schematics        10.0.0
@ngtools/webpack                  10.0.0
@schematics/angular               10.0.0
@schematics/update                0.1000.0
rxjs                              6.5.5
typescript                        3.9.5
webpack                           4.43.0

I can confirm that node.exe for @ngtools/webpack/src/type_checker_worker.js is growing roughly by 300MB on every single file save/recompile cycle. It went OOM for me after updating to Angular 10 within an hour or so... Its pretty annoying that ng serve crashes due to this every hour. I always wonder why my page still runs an old state until I notice that ng serve went away and the recompile/refresh never happened...

Most likely this is related to a regression in the compiler which was fixed via https://github.com/angular/angular/pull/37641 and will be available in 10.1.
JFYI @alxhub

WA- https://dev.to/koscheyscrag/fix-of-angular-cli-javascript-heap-out-of-memory-error-while-running-ng-serve--1jjh

I was able to fix this by downgrading the @angular-devkit package(s) to version 0.803.26
"devDependencies": {
    "@angular-devkit/build-angular": "0.803.26",
    ...
}

then updating packages using npm install.
Any version above 0.803.26 keeps giving me the "JavaScript heap out of memory" error (on serve or build).

It's still happening after upgrading to v10.0.1 but Its frequency is a little down on my environment. We still need more effective fixes.
cc/ @alan-agius4

The fix is to come out in 10.1.x. So lets wait for it or use workarounds as pointed out by me or @AXeL-dev

@PPInfy, the fix is was referring too, is included in 10.0.1.
@lacolaco, we’ll still continue looking at other possible issues and resolutions.
Nb: using an older version of build-angular might cause undefined behaviour. Angular and Angular CLI version 10 needs @angular-devkit/build-angular version 0.1000.0 or later, using incompatible version is consider unsupported.

@alan-agius4 I thought since the issue is open and based on your comment this will come in release 10.1.0 to be precise.

@PPInfy, sorry I missed a 0 in my above comment. (Which I edited)

I'm getting this same error but after running "ng update @angular/core @angular/cli" on a very complex ng9 project. I am using @angular/compiler 10.0.1.

try running node --max_old_space_size=2048 ./node_modules/@angular/cli/bin/ng serve
or
node --max_old_space_size=2048 ./node_modules/@angular/cli/bin/ng build

@PPInfy - If that comment was directed at me, I updated my comment for clarify.  I'm getting the error when running the update command, not 'after' on build like I originally said.

Try "node --max_old_space_size=2048 ./node_modules/@angular/cli/bin/ng update @angular/core @angular/cli"

Repro from https://github.com/angular/angular-cli/issues/18070
https://github.com/genielabs/HomeGenie/tree/master/src/homegenie-ui-app
//cc @genemars

@PPInfy - When I try that I get the following output:

Using package manager: 'npm'
Collecting installed dependencies...
Found 48 dependencies.
Package '-e' is not a dependency.

Quick update: We've identified the memory leak in Ivy compiler, and we're currently working on a fix. It'll be out in v10.0.2.

v10.0.2 is out! I'll close this issue for now. Please open a new issue if you run into other memory issues.

@kyliau - I am still getting the out of memory error but it is on the 'update' command instead of on build.  Do you want me to create a new issue?

@AlphaCreative-Mike yes please create a new issue. It'll help us triage and prioritize the issue if you open a new one. Thank you!

Still getting the exact same issue using 10.0.2:
$ ./node_modules/.bin/ng --version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/

Angular CLI: 10.0.0
Node: 14.4.0
OS: linux x64

Angular: 10.0.2
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1000.0
@angular-devkit/build-angular      0.1000.0
@angular-devkit/build-ng-packagr   0.1000.0
@angular-devkit/build-optimizer    0.1000.0
@angular-devkit/build-webpack      0.1000.0
@angular-devkit/core               10.0.0
@angular-devkit/schematics         10.0.0
@angular/cdk                       10.0.1
@angular/cli                       10.0.0
@ngtools/webpack                   10.0.0
@schematics/angular                10.0.0
@schematics/update                 0.1000.0
ng-packagr                         10.0.0
rxjs                               6.5.5
typescript                         3.9.5
webpack                            4.43.0

Using serve, after a couple of recompiles:
<--- Last few GCs --->

[18915:0x5936310]  3270672 ms: Scavenge 2014.4 (2060.9) -> 2002.6 (2060.9) MB, 4.4 / 0.0 ms  (average mu = 0.373, current mu = 0.366) allocation failure
[18915:0x5936310]  3270717 ms: Scavenge 2017.0 (2060.9) -> 2005.3 (2062.1) MB, 4.7 / 0.0 ms  (average mu = 0.373, current mu = 0.366) allocation failure
[18915:0x5936310]  3271845 ms: Scavenge 2019.7 (2062.6) -> 2007.9 (2037.6) MB, 36.6 / 0.0 ms  (average mu = 0.373, current mu = 0.366) allocation failure

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xa2b020 node::Abort() [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 2: 0x97a467 node::FatalError(char const*, char const*) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 3: 0xb9e0ee v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 4: 0xb9e467 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 5: 0xd3e875  [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 6: 0xd3f21b v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 7: 0xd4d012 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 8: 0xd4de65 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
 9: 0xd4f37f v8::internal::Heap::HandleGCRequest() [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
10: 0xcfa457 v8::internal::StackGuard::HandleInterrupts() [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
11: 0x104fe4a v8::internal::Runtime_StackGuardWithGap(int, unsigned long*, v8::internal::Isolate*) [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]
12: 0x13a9ed9  [/home/jakob/.nvm/versions/node/v14.4.0/bin/node]

Same issue for me as well.
[972:000001705E494E80]   167385 ms: Scavenge 1330.4 (1424.2) -> 1329.6 (1424.7) MB, 6.3 / 0.0 ms  (average mu = 0.149, current mu = 0.074) allocation failure
[972:000001705E494E80]   167396 ms: Scavenge 1330.6 (1424.7) -> 1329.9 (1425.2) MB, 5.3 / 0.0 ms  (average mu = 0.149, current mu = 0.074) allocation failure
[972:000001705E494E80]   167407 ms: Scavenge 1330.9 (1425.2) -> 1330.2 (1425.7) MB, 4.6 / 0.0 ms  (average mu = 0.149, current mu = 0.074) allocation failure
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 000001746E35C5C1]

Security context: 0x013eeb49e6e9
1: getArg [0000029075F0BD01] [D:\Project\Releases\Spike\Workspace\frontend\node_modules\webpack-sources\node_modules\source-map\lib\util.js:~18] [pc=000001746F512690](this=0x029075f04061 ,aArgs=0x02d6f0d1b031 ,aName=0x013eeb4c9f11 <String[8]: original>,aDefaultValue=0x00bbd42822b1 )
...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF70F89DD8A v8::internal::GCIdleTimeHandler::GCIdleTimeHandler+4506
2: 00007FF70F878886 node::MakeCallback+4534
3: 00007FF70F879200 node_module_register+2032
4: 00007FF70FB930DE v8::internal::FatalProcessOutOfMemory+846
5: 00007FF70FB9300F v8::internal::FatalProcessOutOfMemory+639
6: 00007FF70FD79804 v8::internal::Heap::MaxHeapGrowingFactor+9620
7: 00007FF70FD707E6 v8::internal::ScavengeJob::operator=+24550
8: 00007FF70FD6EE3C v8::internal::ScavengeJob::operator=+17980
9: 00007FF70FD77B87 v8::internal::Heap::MaxHeapGrowingFactor+2327
10: 00007FF70FD77C06 v8::internal::Heap::MaxHeapGrowingFactor+2454
11: 00007FF70FEA1EA7 v8::internal::Factory::NewFillerObject+55
12: 00007FF70FF1F096 v8::internal::operator<<+73494
13: 000001746E35C5C1

For me the issue got solved by changing "target": "es6" from "target": "es5" in tsconfig.json. However I do have a question. Will this change work in IE11?

For anyone still seeing issues, it's probably caused by the same issue as reported in #18087. This is being addressed in #18089 that's expected to be in the next release, which should be released over the course of today.
For people using Yarn, you can add a "resolutions" block to force copy-webpack-plugin to 6.0.3 however this must then be removed when upgrading to the next release, as it could introduce compatibility issues in the future.

does it change with target as es6? Because I tried many times switching between target es5 and es6 and everytime there is no build/server issue with target as es6 (tsconfig.json -> compilerOptions--> target).

Anyone else's team dead in the water until this releases?

Update worked fine for me, after the update the leak seems gone, processes are growing and shrinking again in a "normal" way I guess :) Only thing observed, incremental build times are way slower now - like 5 seconds instead of 1 second before...

@mduft are you using tsconfig.json -> compilerOptions--> target as ES6 ?

@PPInfy we have "target": "es2015", currently...

@mduft that is nothing but es6. with target es6/es2015 this is working touchwood. So again this seems like a compiler issuer rather than packager issue. Can someone here confirm this?

@alan-agius4 - Please test the fixes with target as es5. I think the root cause might be related to that.

Update worked fine for me, after the update the leak seems gone, processes are growing and shrinking again in a "normal" way I guess :) Only thing observed, incremental build times are way slower now - like 5 seconds instead of 1 second before...

@mduft After which update did you see to start the incremental rebuild time regression? I am trying to figure out if it's due to a change in Angular framework or the CLI. Investigating this without a reproduction is practically impossible I'm afraid, so is it possible to share a reproduction?

Angular CLI: 10.0.1
Node: 10.16.3
OS: win32 x64
Angular: 10.0.2
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace:
Package                            Version
@angular-devkit/architect          0.1000.1
@angular-devkit/build-angular      0.1000.1
@angular-devkit/build-ng-packagr   0.1000.1
@angular-devkit/build-optimizer    0.1000.1
@angular-devkit/build-webpack      0.1000.1
@angular-devkit/core               10.0.1
@angular-devkit/schematics         10.0.1
@angular/cdk                       10.0.1
@angular/cli                       10.0.1
@angular/flex-layout               10.0.0-beta.32
@angular/material                  10.0.1
@ngtools/webpack                   10.0.1
@schematics/angular                10.0.1
@schematics/update                 0.1000.1
ng-packagr                         10.0.0
rxjs                               6.6.0
typescript                         3.9.5
webpack                            4.43.0
With this also same situation - OOM.

Again with Target ES6 it is working absolutely fine.

I thought it was easy to repro using this project - the latest commit has the update to 10.0.2 - however switching back to the commit before, it now also takes longer than usual :|


Paperless-ng

Added "paperless-ng" under "Document Management".
Pretty nice and easy to use document management system, use it on my own and it's easy to setup in a docker environment.

thanks. good pickup


rename index.ftl to index.ftlh when upgrading spring boot to 2.2+

Spring Boot recently yet again introduced a breaking change, which leads to the infamous whitelabel error page. They changed the default suffix from .ftl to .ftlh.
https://github.com/spring-projects/spring-boot/issues/15131
So for Spring Boot 2.2.x applications, these extensions have to be updated.

yes.. what the hell.. how do they break the user experience like that.. let me upgrade that now

@grmkris by the way.. did you upgrade the spring boot version.. that's why it failed right?

Yes if I remember correctly

@grmkris ok... if you want to send a PR for that .. I will really appreciate it..

Okay... will do. Just can't promise it will be this week :( Busy life
On Thu, 30 Jul 2020 at 13:01, salaboy<EMAIL_ADDRESS>wrote:

@grmkris https://github.com/grmkris ok... if you want to send a PR for
that .. I will really appreciate it..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/learnk8s/knote-java/issues/3#issuecomment-666298646,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADWTG22YSNM6QAOUO4T4WT3R6FHHXANCNFSM4O4Z2VEA
.

@grmkris thanks a lot.. same here.. I am doing a webinar today if you want to join :) https://www.linode.com/blog/kubernetes/learnk8s-lab-series/

I will try to send PR about this Freemarker issue ya.
Please check


Support configuration discovery for stylish-haskell

Description
The Haskell beautifier used internally (stylish-haskell) supports its own configuration file either via command line parameter -c or implicitly by finding a file called .stylish-haskell.yaml in the directory, or an ancestor of the directory, where stylish-haskell is being run from.
Currently when I run Beautify Editor the configuration file which I placed in my project root folder is not being used.
This could be due to the tool being run from a different directory or in some sandbox like manner where it does not gain access to the configuration.
It would be nice if stylish-haskell ran from at least my project root to use the project wide settings for beautification.
Proposed change
Invoke stylish-haskell from project root or from the directory containing the file in question, this should in theory traverse ancestors until it finds the .stylish-haskell.yaml in the project root.

Issue still relevant: using atom-beautify, we can only set a global .stylish-haskell.yaml settings file, as it will not detect files in the project root.
This change would be nice for two reasons:

Avoid implicit settings
Ideally, I'd have settings files on a per-project basis, so that is obvious where the behavior is coming from. If not, I will forget either the location or even the existence of the configuration, leading to issues.
Advanced settings
Stylish Haskell allows for some extensive configuration, settings that go well beyond overall style preference (which arguably shouldn't change much project to project) requiring per-project settings.


Vickel: Watch poojadesigners.in

Vickel requests the watch of the watch_keyword poojadesigners\.in. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

poojadesigners\.in has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by double-beep in Charcoal HQ


Support create comment on pull_request_target event

The pull_request_target event is similar to pull_request but allows specific activity types. In my case, I want to limit the trigger to [opened, synchronize].

I just created https://github.com/zgosalvez/github-actions-report-lcov/pull/25 . See my reasonings in the PR. Will the changes in this PR work the same way as mine? Because the event is always non-null (non-empty) when the work flow is triggered? So we might as well drop the check on the event name itself?

@jhen0409  By the way, you have not uploaded the generated files under dist folder. My understanding is that that we need those files to for the github actions to work. My PRs all contain those files. May be I have misunderstood something?

@jhen0409 By the way, you have not uploaded the generated files under dist folder. My understanding is that that we need those files to for the github actions to work. My PRs all contain those files. May be I have misunderstood something?

I hope the the PR can be reduced the review noises, so I expected it can be build when release new version.

I just created #25 . See my reasonings in the PR. Will the changes in this PR work the same way as mine? Because the event is always non-null (non-empty) when the work flow is triggered? So we might as well drop the check on the event name itself?

I saw #25 I think it will broke the workflow on another trigger types, because it not always have pr number on every trigger type.

I hope the PR can be reduced the review noises, so I expected it can be build when release new version.

Ah got it.

I saw https://github.com/zgosalvez/github-actions-report-lcov/pull/25 I think it will broke the workflow on another trigger types, because it not always have pr number on every trigger types.

I dont think I understand the comment. But I think you prefer to get the PR number for ever comment. Is that correct?

I dont think I understand the comment. But I think you prefer to get the PR number for ever comment. Is that correct?

I mean github.context.payload.pull_request, it doesn't exist on trigger types like push. In case if I just want to update artifact without create comment, I will use the trigger type like that.

Hello everyone. I just want to make sure I'm processing the right PR. So in lieu of this PR, #25 can be merged and this can be closed?

Hello everyone. I just want to make sure I'm processing the right PR. So in lieu of this PR, #25 can be merged and this can be closed?

It might depend on the use case like I saw in https://github.com/zgosalvez/github-actions-report-lcov/pull/22#issuecomment-1160115960.
However, these more trigger types may includes the payload. The best way probably is skip create comment when the payload is empty.

From my side, I dont mind creation of multiple comments. Creation of a comment is a minor action and it does not take long. And I can also manually delete comments that are not needed. But this is just my use case.
The primary goal of https://github.com/zgosalvez/github-actions-report-lcov/pull/25 is that if I update my PR with more unit tests and the coverage improves, I want it to show up as a comment. If that is achieved in a better way, I will be happy to accept the solution.

Note the PR https://github.com/zgosalvez/github-actions-report-lcov/pull/28 . This allows us to skip creating multiple comments. :-)

Thank you for your patience and contribution. I'm kind of lost in the conversation but I've decided to merge this relatively straightforward PR. Thank you again!


broken code generation

pggen release: 2021-04-18
Code generation failed for following example configuration:
 pggen gen go \
	 --schema-glob '${schema_path}/*.up.sql' \
	 --query-glob '${query_path}/A/query.sql' \
	 --query-glob '${query_path}/B/query.sql' \
	 --query-glob '${query_path}/C/query.sql' \
	 --query-glob '${query_path}/D/query.sql' \
	 --query-glob '${query_path}/E/query.sql' \
	 --query-glob '${query_path}/F/query.sql' \
	 --go-type 'int8=int8' \
	 --go-type 'int=int' \
	 --go-type 'varchar=string' \
	 --postgres-connection '${db_url}' \
	 --output-dir 'db'

result : generated 6 query files
Although pggen is generating Codes for only F query directory and entire DBQuerier and Querier interface is missing from the output directory. I am using golang migrate for maintaining database migrations so my db schema are in A.up.sql format in schema directory
update: renaming query.sql files  generates all codes. it seems pggen is overwriting generated codes because of same file name

Yep, definitely a bug. It sounds like pggen is trying to reuse the query.sql.go name for each directory A, B, ..., F. The F directory wins since it's last.
I think I'll use the following name algorithm:

If output dir is not set, just use the base name since they file names can't collide, i.e. query.sql to query.sql.go.
If output dir is set, make the generated names unique by:

using the parent directory as a prefix, e.g. A/query.sql to db/A_query.sql.go
If there's still a collision (if grandparent directory is different), append a digit starting from 1, e.g.

dir1/A/query.sql to A_query_1.sql.go
dir2/A/query.sql to A_query_2.sql.go

Is it possible to generate the query.sql.go from the first folder than traverse other folders and append generated code to the existing query.sql.go file?

I prefer the conceptual simplicity of 1 query file producing 1 go file. Though, it wouldn't be too hard to do it after the fact with a sed script.


make route name matcher have better description

Expected: '/second'
Actual: ToStringOverrider<String?>:<route "/second">
Which: not an <Instance of 'String'>

another approach


Add translations as extra ingest output

Feature request from @chaoran-chen which would save covSpectrum a lot of money by not having to run nextclade for open data anymore.
Translations will be uploaded to same bucket as "aligned.fasta.zst"
but with "aligned" replaced by "translation_N" (etc. for other genes, E, S)
Cache is used like for aligned sequences
Only producing zst compressed output as we're moving there in the future
and xz/gz is only for backwards compatibility of existing scripts
Resolves https://github.com/nextstrain/ncov-ingest/issues/394
Testing

I tested locally with the debug config file
I will run a genbank trial ingest to see, if that works should be good to merge, if there's a bug we can always revert: nextstrain build --aws-batch --attach ce172ab3-0ece-48df-83e8-0fbea3ba02f5 /home/runner/work/ncov-ingest/ncov-ingest: previous run had an error, trying again :(

It works! Check through e.g.
aws s3 cp s3://nextstrain-staging/files/ncov/open/branch/publish-translations/translation_E.fasta.zst .

Would be good to double check translations occasionally after reruns. @chaoran-chen, it would be super useful if you could do sanity checks on occasion and report back, as you'll be the main user of this file at least for now (I can't think of anyone else using these, we likely won't have a use at this point).

Fantastic, thank you very much, Cornelius! Yes, we will put it into use very soon and then keep you updated if anything works!

I've pushed a commit to address the use of params and touch files instead of outputs, as well as two smaller separate commits. These are only tested in dry run mode, so may need minor adjustment. Please feel free to rework them as needed.

@corneliusroemer Not sure what I pushed is correct as-is, but it's something to chew on at least if you want. Please feel free to adjust as you see fit. Perhaps I should have pushed to another branch, but I thought it'd be easiest to discuss here in context.

Doing a test run after I implemented the suggestions from review from @tsibley and @joverlee521
nextstrain build --aws-batch --attach --no-download .

Translations should be available via:
aws s3 cp s3://nextstrain-staging/files/ncov/open/branch/publish-translations/translation_E.fasta.zst .

in around 12 hours.

Test runs worked out well. I'll merge this in 24hr unless there are objections @joverlee521 @tsibley

@chaoran-chen I'm sorry, I forgot to trigger a full rerun on Nextclade, so the translations are not complete yet. They should be in ~24hr though. Let me know if the aren't. Sorry for the oversight!

Translations should be there now and complete!
❯ aws s3 cp s3://nextstrain-data/files/ncov/open/translation_E.fasta.zst .
download: s3://nextstrain-data/files/ncov/open/translation_E.fasta.zst to ./translation_E.fasta.zst

~/Downloads/tmp via 🐍 v3.11.4 via 🅒 py11 took 16s
❯ seqkit seq -n translation_E.fasta.zst| wc -l
 8114018


Consistency

pid and syscall_number should at all times be a long (can use either pid_t or int I guess.)
Functions which take a constant string as parameter should have const char * as type, rather than char *.

I'm going to close this - mostly because I don't believe const to be particularly useful. (Somewhat related: The plan9 compiler also completely ignores const, afaics)
I'll have a look at some types a bit later.


Change from blackbox to whitebox annotation.

Yosys's treatment of blackbox attributes's now includes stripping all contents
within the blackbox.  The whitebox attribute is what should be used to
explicitly define contents of a blackbox.
This PR also updates Yosys (as of 4 days ago at b6345b1).

Superceeded by #730


Feature Request - Power down everything possible (external bay, fans...) after waiting time has been exceeded

i have gotten word from divimath, this is not possible by software. the fans etc. can only be killed via the switch.


Add py39 support and drop py35 support

Description
Out with the old, in with the new. 😄
Motivation and Context
Python 3.9 was released on 2020-10-05 and Python 3.5 reached its end of life
This PR will conflict with #57 , due to changes in tox.ini

FYI this has been released (finally) in 1.3.2 🎉


Fleet

Show error if creating with YAML and no namespace on namespaced type
More fleet

https://github.com/rancher/dashboard/issues/1458


WIP - Fix crossdock by waiting for Cassandra when needed

Signed-off-by: Isaac Hier<EMAIL_ADDRESS>
Which problem is this PR solving?

Hopefully fixes #1191.

Short description of the changes

Increase timeout to 3 minutes.
Test port with netcat instead of using cqlsh immediately.

I tagged this as WIP and am going to stop reviewing. There are many different changes going on here, fine if you want to experiment, but for official PRs let's agree what you're trying to achieve (the whole thing started with "increase timeout"), whether we want such changes (e.g. making the schema image actually start Cassandra - 👎 ), and then do them separately.

Waiting for https://github.com/jaegertracing/jaeger-client-go/pull/349 then can submit latest changes and see if combination of newest client with these fixes resolves the issue.

I think there are agent failures due to gRPC. See this crossdock log:
{"level":"error","ts":1543327192.891047,"caller":"grpc/reporter.go:70","msg":"Could not send spans over gRPC","error":"rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:14250: connect: connection refused\"","stacktrace":"github.com/jaegertracing/jaeger/cmd/agent/app/reporter/grpc.(*Reporter).send\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/cmd/agent/app/reporter/grpc/reporter.go:70\ngithub.com/jaegertracing/jaeger/cmd/agent/app/reporter/grpc.(*Reporter).EmitBatch\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/cmd/agent/app/reporter/grpc/reporter.go:50\ngithub.com/jaegertracing/jaeger/cmd/agent/app/reporter.(*MetricsReporter).EmitBatch\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/cmd/agent/app/reporter/metrics.go:77\ngithub.com/jaegertracing/jaeger/thrift-gen/agent.(*agentProcessorEmitBatch).Process\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/thrift-gen/agent/agent.go:197\ngithub.com/jaegertracing/jaeger/thrift-gen/agent.(*AgentProcessor).Process\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/thrift-gen/agent/agent.go:152\ngithub.com/jaegertracing/jaeger/cmd/agent/app/processors.(*ThriftProcessor).processBuffer\n\t/home/ihier/proj/go/src/github.com/jaegertracing/jaeger/cmd/agent/app/processors/thrift_processor.go:115"}

@pavolloffay any ideas?

That was my suspicion when I opened the ticket, since this started happening after grpc endpoint got merged, but the crossdock logs we're not showing.
Do we need to declare the new port somewhere?

Well this should solve crossdock flakiness overall. Probably need another fix for the gRPC stuff. I'm not 100% sure what the issue is. connection refused could be that the collector is not up yet. But exposing the port is a good idea.

connection refused could be that the collector is not up yet.

the compose file says to restart on failures, so that should only be a transient issue. But if collector is down because the storage is not ready, then 😢

It seems to be primarily to be a race condition between starting the server and when it is ready for connections. I've had this issue with gRPC in the past. Essentially, the setup looks like this:
server := ...
go func() {
    server.serve()
}
// supposedly serving requests at this point

The problem is that even a wait group does not help if the serve function blocks indefinitely.

var wg sync.WaitGroup
server := ...
wg.Add(1)
go func() {
wg.Done()  // Cannot wait after serve call or will end up blocking forever.
server.serve()
}
wg.Wait()
// supposedly serving requests at this point

That doesn't provide a much better guarantee IMO.

I am not sure why that would be a problem - eventually it should still start, and the agent should keep restarting until it is able to connect.
Does grpc server object provide a status method? if so, we could integrate it with the health checker in main.

You are correct about retrying. The problem is the agent only succeeds after attempting to write a trace to the collector, and subsequently drops the trace. The issue relates to the TRANSIENT_FAILURE status in gRPC request. We should potentially check for that status and retry the request instead of dropping it. I'm doing more research and will keep you posted.

Got it! Now the only question is if I add this to every gRPC call.

For the record, I consistently see this in crossdock too: WARN  18:39:19 Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being swapped out, especially with mmapped I/O enabled. Increase RLIMIT_MEMLOCK or run Cassandra as root.

Closing in favor of a solution to #1221.


add promxial policy optimization template to pl_examples

What does this PR do?
Adds implementation of proximal policy optimization in PyTorch Lightning

Fixes # (issue) <- this links related issue to this PR
Before submitting

[ ] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[ ] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified
[ ] Check that target branch and milestone match!

Did you have fun?
Make sure you had fun coding 🙃

Hello @sid-sundrani! Thanks for opening this PR.

In the file pl_examples/domain_templates/reinforce_learn_ppo.py:

Line 462:121: E501 line too long (128 > 120 characters)

Do see the Hitchhiker's guide to code style

Hello @sid-sundrani! Thanks for opening this PR.

In the file pl_examples/domain_templates/reinforce_learn_ppo.py:

Line 462:121: E501 line too long (128 > 120 characters)

Do see the Hitchhiker's guide to code style

I added my code to the wrong branch (master) and I'm merging with dev.. Not sure what to do, there seem to be 448 commits now in this PR.. Should I close this PR and add my code to PyTorchLightning:release/1.0.x and create a PR again?

I added my code to the wrong branch (master) and I'm merging with dev.. Not sure what to do, there seem to be 448 commits now in this PR.. Should I close this PR and add my code to PyTorchLightning:release/1.0.x and create a PR again?

@sid-sundrani well in fact the correct for you is release/1.2-dev I have fixed it for you 🐰

@sid-sundrani well in fact the correct for you is release/1.2-dev I have fixed it for you 🐰


oclif readme for single command CLIs produces wrong output

Follows-up #426
Like this:
bindl .
Downloads and extracts binaries from compressed packages using a config file
USAGE
  $ bindl . [--version] [--help] [-c <value>]
FLAGS
  -c, --config=<value>  Path to the config file
  --help                Show CLI help.
  --version             Show CLI version.
DESCRIPTION
  Downloads and extracts binaries from compressed packages using a config file
  The config will be read from any valid config file in the current directory. The configuration file can be defined
  using all the extensions and names accepted by cosmiconfig, such as bindl.config.js

See code: src/index.ts

bindl .: there is no such command . in my CLI.

Got'cha. Do you have a link to your CLI's repo so we can use it for testing?


[ODS-4610] Web Api Appsettings.json is missing default configurations

@raghuramakrishna Have you pushed up all your changes?  You've marked my comments as resolved or mentioned that you fixed the issue, but I'm not seeing the expected changes.

Sorry I have pushed the change. You can review now.

@blmeyers Strange I did resolved it before, I have updated it again. Please review


16sRNA studies

This is not an issue. I really like the idea and will definitely looking forward using the package; however, I am curious was the package is not covering 16s studies ?

We do not at this time have a pipeline set up for 16s processing, we would need additional funding to do that on a large scale! However we are working on an equivalent package for 16s data from the HMP: https://github.com/waldronlab/HMP16SData

If only we had the $$$, I would happily write a package!

I am sure you there are undergrad students looking for fame and full of ambition that money is not the first on their priority list. Thanks anyway for your work and your comments :-)

Interesting idea, will keep it in mind for the future. Going to close this issue now and glad you like the package 👍

And if you know a student who would up to the task, let us know, but it's not easy work!


not working

it says 2985 successfully loaded proxy
Server started
Client successfully connected
Client successfully connected but doesnt work in game.
I want to fix this but in mope.io I can't open dev tool,

it says 2985 successfully loaded proxy
Server started
Client successfully connected
Client successfully connected but doesnt work in game.
I want to fix this but in mope.io I can't open dev tool,

can you dm me at discord: ProB1#0001


Release v1.3.6

doc(CONTRIBUTORS): added
add CONTRIBUTORS to [files] in package.json

fixes #63

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 60.756%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
519

Relevant Lines:
861

💛  - Coveralls


fix: RealmUnsupportedSetError on List of RealmType

What happened?
When using a List of a RealmModel inside another, it doesn't generate a setter for the property.
Repro steps
@RealmModel()
class $Routine {
  @PrimaryKey()
  late String id;

  late List<$Product> products = [];
}

@RealmModel()
class $Product {
  @PrimaryKey()
  late String id;
}

Generates:
  @override
  set products(covariant RealmList<Product> value) =>
      throw RealmUnsupportedSetError();

Version
Flutter 3.19.1
What Atlas Services are you using?
Local Database only
What type of application is this?
Flutter Application
Client OS and version
Android 14
Code snippets
No response
Stacktrace of the exception/crash you're getting
No response
Relevant log output
No response

@nirinchev Thanks for the quick response. Could you provide an example snippet?

final r = Rutine('sleep');
r.products..clear()..addAll(['pillow', 'bed'])

But be aware that how you manipulate the list has an effect on what notifications you get, and what get synced to Atlas (if you are using that).
In general, if possible, instead of blanket updating realm collections, try to do the minimal changes needed.

final routine = Routine('r123', products: [Product('p123')]);
realm.write(() {
  realm.add(routine);
});

final newList = [Product('p456'), Product('p789')];

// instead of routine.products = newList do this:
realm.write(() {
  routine.products.clear();
  for (final product in newList) {
    routine.products.add(product);
  }
});


Passing arch to the nix install script and adjusting brew libs + use macos-14 to build if needed

The commit descriptions provide more info.

@jmarrec, why the change from always using universal2 installers on arm64 ?

I cannot properly link a c++ executable to it if using the universal installer.
Libpython.dylib reports mach-o x64

that seems like a different issue. universal2 installer provides dual arch (x86_64 & arm64). Do you have a repro for this ?

Not that simple to provide a MCVE, but I've experienced it in a (large) project that uses CMake and CPack for packaging, and which redistributes the python dylib.
Linking is ok, the issue is when executing it. It refuses to launch it due to code signature I think.
codesign --verify --deep --verbose Python
Python: invalid Info.plist (plist or signature have been modified)
In architecture: arm64

@mayeut here is a MCVE repro: https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106
It's not impossible that this could be the issue: https://stackoverflow.com/questions/58997650/trying-to-codesign-a-mac-osx-app-but-when-i-check-it-i-get-pharo-app-invalid
The SO post mentions that codesign behaves differently when you have a library/exe that starts with an uppercase, and the resolved python library is Python in this case. And I think that lib is codesigned to begin with, while when you force build it isn't.
Anyways, the program links, but can't be executed.
https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106#step:7:15
And the relevant build warning at https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017246804#step:6:2196

And here is a run with my fork for setup-python, which uses my fork of python-versions where I force build the python package on mac
https://github.com/jmarrec/test-Github-Actions/actions/runs/9446912815


feat: Add Remove-AzApiManagementUser script

Added script to remove a user to an Azure API Management service.
Closes https://github.com/arcus-azure/arcus.scripting/issues/320
Note: cannot add integration tests as we don't have an Azure API Management service available in our resource group due to costs.

The name of the new script is Remove-AzApiManagementUser, as this follows our earlier scripts like Create-AzApiManagementUser for the user part and Remove-AzApiManagementDefaults for the remove part.
However this is also the name of the script in the Az.ApiManagement module, see https://docs.microsoft.com/en-us/powershell/module/az.apimanagement/remove-azapimanagementuser?view=azps-8.2.0.
This caused some issues during unit testing, so some commands have the module specified, such as:
https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-e1b36c2bbfb0483eb2ed4e8fd8e53e5497845e4459253c4cc182c14361734f11R1389
https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-e1b36c2bbfb0483eb2ed4e8fd8e53e5497845e4459253c4cc182c14361734f11R1406
https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-59aa3eb8ad259606b36e109cb8c6a4f4b532a886be3bff485dcbd01806da1739R31
During all my testing this wasn't an issue, but interested in if you think we should rename or not @stijnmoreels

The name of the new script is Remove-AzApiManagementUser, as this follows our earlier scripts like Create-AzApiManagementUser for the user part and Remove-AzApiManagementDefaults for the remove part.
However this is also the name of the script in the Az.ApiManagement module, see https://docs.microsoft.com/en-us/powershell/module/az.apimanagement/remove-azapimanagementuser?view=azps-8.2.0.
This caused some issues during unit testing, so some commands have the module specified, such as: https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-e1b36c2bbfb0483eb2ed4e8fd8e53e5497845e4459253c4cc182c14361734f11R1389 https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-e1b36c2bbfb0483eb2ed4e8fd8e53e5497845e4459253c4cc182c14361734f11R1406 https://github.com/arcus-azure/arcus.scripting/pull/321/files#diff-59aa3eb8ad259606b36e109cb8c6a4f4b532a886be3bff485dcbd01806da1739R31
During all my testing this wasn't an issue, but interested in if you think we should rename or not @stijnmoreels

Yeah, I think that we should rename this instead then. PowerShell let's you use it together with -AlloClobber but don't think this is a good approach, and I imagine many 'strange' behaviors if the users use the Azure variant.
Maybe we can add ...Account to it? Like Create-AzApiManagementUserAccount and Remove-AzApiManagementUserAccount? It's find if the first one (create) is done in another PR to keep this one clean.

The name of the new script is Remove-AzApiManagementUser, as this follows our earlier scripts like Create-AzApiManagementUser for the user part and Remove-AzApiManagementDefaults for the remove part.
However this is also the name of the script in the Az.ApiManagement module, see docs.microsoft.com/en-us/powershell/module/az.apimanagement/remove-azapimanagementuser?view=azps-8.2.0.
This caused some issues during unit testing, so some commands have the module specified, such as: #321 (files) #321 (files) #321 (files)
During all my testing this wasn't an issue, but interested in if you think we should rename or not @stijnmoreels

Yeah, I think that we should rename this instead then. PowerShell let's you use it together with -AlloClobber but don't think this is a good approach, and I imagine many 'strange' behaviors if the users use the Azure variant. We also used Create-AzTableStorageAccountTable to avoid calling it New-AzStorageTable in the Table Storage module.
Maybe we can add ...Account to it? Like Create-AzApiManagementUserAccount and Remove-AzApiManagementUserAccount? (it's maybe even more clear then) It's fine if the first one (create) is done in another PR to keep this one clean.

Renamed the scripts to Create-AzApiManagementUserAccount and Remove-AzApiManagementUserAccount 👍🏻  Included the renaming of the create script in this PR as well, as I feel this is related to this PR (renaming only came up during development of the remove script). Thanks for your feedback!


Add Redux To React Components

In this milestone of my Bookstore React Project, I implemented the following changes:

Made sure that I kept the state immutable in reducers.
Changed the default state in the books reducer from an empty array to an array with a few books.
Connected the app to the Redux store.
Made sure that list of books displays books from the Redux store.
Added functionality for the "Add new" button click in the React component responsible for adding new books.
Added functionality for the "Remove" button click in the React component responsible for removing books.
Added functionality for the "Check status" button click In the React component responsible for categories.
Made sure there are no linter errors.
Used correct flow Gitflow.
Documented my work in a professional way.

Hello @tresorsawasawa 👋🏼 ,
Thank you for taking out time to swiftly review and approve this PR. You are amazing.


Unable to find data to plot

Q:Which city in Beijing, Shanghai, Guangzhou, and Shenzhen is more active in terms of "virtual transaction quantity" and "virtual transaction unit price"?
Provided required fields for analysis and drawing failed, unable to find data

Reason for Closure: [Data field value is Chinese]
Solution Implemented: [Correct after modifying comment]

If you have any further questions or concerns, please feel free to reopen the issue or open a new one. Your feedback is valuable to us, and we encourage continued collaboration.
Thank you,
[leonliuzx]
[DeepBI]


Running oneview-ansible with Python2?

Hello,
The readme file lists python 3.4.2 or higher as a requirement to run oneview-ansible.
Is this is a hard requirement?
My customer would prefer to run it with Python2. What would be the limitations?
Which Python2 version would you recommend (if any)?
Thanks for your help

Since we are migrating from ansible to ansible-collections, we recommend to use python 3.4.2 version because python 2 gets deprecated. But most of our ansible libraries works with python 2.7.9 as well. So you can use python >= 2.7.9

Since we are migrating from ansible to ansible-collections, we recommend to use python 3.4.2 version because python 2 gets deprecated. But most of our ansible libraries works with python 2.7.9 as well. So you can use python >= 2.7.9

@vinicole  Please close this issue if your question was answered.

Ok, sorry for the delay. Thanks for your answer.


Release 1.4.0

[x] Create a branch for the release.
[ ] Update the dependencies. The dependabot PR backlog is not comprehensive and doesn't include transitive dependencies, and merging them one at a time tends to break things, so the best way to do this is manually with npm.
[ ] Do a test build of the NPM package on your local machine so you know if something is going off the rails before the automated build action on GitHub.
[ ] Bump the "version" number in package.json and reinstall the dependencies so the correct version number is in package-lock.json.
[ ] Open a PR that merges the release branch into main.
[ ] Merge the release PR after it passes testing and review.
[ ] Tag a corresponding release on GitHub. This will trigger an automated NPM package build on GitHub. If the package build succeeds it will be automatically published to NPM.

@alancleary can you verify if this is expected or I am doing something wrong?
npm test

><EMAIL_ADDRESS>test
> npm run test:dev && npm run test:prod

><EMAIL_ADDRESS>test:dev
> wtr

Error: Could not find any test files with pattern(s): ./test/**/*_test.js

This is prior to doing any dependency updating, so either I've done something dumb in my setup or this testing stuff is still aspirational...

@adf-ncgr The testing scripts in package.json were brought over from the starter repo we used to bootstrap this repo. No tests have actually been implemented. Hopefully this will be changing in the nearish future.

OK, so I will read that as "aspirational"; serves me right for reading (and believing) the README. Thanks!

The README was also brought over from the starter repo :sweat_smile:

@alancleary, more surrogate release management help needed. Since one of the dependencies to be bumped is lit-analyzer, I thought I should try npm run lint:lit-analyzer but this resulted in ✖ 25 problems in 10 files (13 errors, 12 warnings). The same result is given on a fresh clone of the repo (ie with the current set of dependency versions), so not sure if it is actually something that needs fixing? Please advise when you get a chance (but beware that the errors seem unlikely to be things that I'll be competent to fix)

Yet another carryover from the starter repo. We stopped using it around the time we introduced es-lint and prettier with the plan to get it working again at some point. Perhaps @ctcncgr remembers why we did this. Regardless, don't worry about it. Thanks for checking!

final box checked. release v1.4.0 is live