20240603.1.1 contains a buggy VS version

Description
windows-2022 image version 20240603.1.1 contains an update of Visual Studio Enterprise 2022 into version 17.10.34928.147. This version has a bug described and discussed here:
https://developercommunity.visualstudio.com/t/Cannot-build-any-project-after-update-to/10664111
Bug was fixed by the next VS service release 17.10.2 (17.10.35004.147).
Is it possible to expedite update of the pipeline to have a fixed VS version?
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[ ] Windows Server 2019
[X] Windows Server 2022

Image version and build link
There is no public example, this is internal MS team build.
Is it regression?
20240514.3.1
Expected behavior
Visual Studio Enterprise 2022 version 17.10.35004.147 (17.10.2) should be installed.
Actual behavior
Visual Studio Enterprise 2022 version 17.10.34928.147 is installed (17.10.0 or 17.10.1 - not sure).
Repro steps
Try to build a C# project which uses .net sdk version 7.0.404.
Build solution will crash crash with errors similar to the following:

Unhandled Exception: System.MissingMethodException: Method not found: ‘System.Collections.Generic.IEnumerator1<Microsoft.CodeAnalysis.NodeStateEntry1<System.ValueTuple2<System.__Canon,System.__Canon>>> Microsoft.CodeAnalysis.NodeStateTable1.GetEnumerator()’. axshare_mvc.Core, Axure.Atlassian.Connect, Axure.Cloud.Mailer.Templates, Axure.Mailer.Templates C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Roslyn\Microsoft.CSharp.Core.targets

Hi @alexander-vitchevsky , Visual Studio version is updated regularly to ensure the runners have the latest features, performance improvements, and security patches.Kindly wait for next vm roll out.Thanks

HI @alexander-vitchevsky  , the required Visual Studio version :17.10.35013.160 has been rolled out. Thanks.

@vidyasagarnimmagaddi , thank you!


Additions to your bandlist

Two bands that would fit perfectly on your Power Metal list:
Thunder And Lightning:
https://open.spotify.com/artist/4TN4Jka0OxorqP3t52O0WW?si=zOqKdbegTECyuTzbqInk6Q
Terra Atlantica:
https://open.spotify.com/artist/2jjCMNei7oJGKMal41tAZE?si=BXzw8zGvRfu4bDnNCLT91g

Hey @marcw1984
Thanks for you comment! Sorry, we just notice them now. Both Bands added!!
Stay heavy and let us know any other additions! :metal:


[HW] Hanniel Saldanha

Name: Hanniel Saldanha
Linkedin Profile: https://www.linkedin.com/in/hannielfls/
Attach the homework screenshots below:
Cassandra Data Modeling

Cassandra Query Language

Great job!

Thank you, I have a problem, in the other task of another workshop (https://github.com/datastaxdevs/workshop-sql-to-nosql-migration), which is giving this
error message "Operation LOAD_20210412-203125-575171 failed: DriverExecutionException (no message).
Caused by: File not found: /workspace/workshop-sql-to-nosql-migration/astra-creds.zip (No such file or directory). "
Do you have any idea, what could it be, because in theory, directory would be created with the commands "bash dsbulk.sh"

https://api.badgr.io/public/assertions/GlYYrZJmSjeOq6GkGboeBg?identity__url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fhannielfls%2F

@hannielfls Answering your question, could you please create an issue in the workshop repo? We can investigate it further then.


Add default_noreply to Client

Resolves #78
Have only added to the base Client at this time, will extend to other classes if accepted as a feature suggestion.

LGTM, thanks!

I have a few things to release to pypi, and will have that done by Wednesday evening. Sorry for the delay, just a busy week.

Cool - I'll add default_noreply to all the other Client classes in another PR coming soon.


Remove registeredDelivery parameter from SMPP connector docs

Description
registeredDelivery is not a parameter in [1], we need to remove that from the list in [2]
[1] https://github.com/wso2-extensions/esb-connector-smpp/blob/16adf353c05f7faa3167afce309e5fa7e248a81f/src/main/resources/operations/sendSMS.xml
[2] https://apim.docs.wso2.com/en/4.2.0/reference/connectors/smpp-connector/smpp-connector-config/#:~:text=Optional-,registeredDelivery,acknowledgment is required - Value other than 0 represents delivery report request.,-Optional
Steps to Reproduce
Mentioned under description
Version
4.2.0
Environment Details (with versions)
No response

PR: https://github.com/wso2/docs-mi/pull/1118
https://github.com/wso2/docs-mi/pull/1117


Integrate rapidcheck into pony code base test framework

Rapidcheck revision 5571b312a90efec90b3686f9faa8b6a2a21b63a9 was
placed into lib/rapidcheck.
Pony's Makefile was modified to compile rapidcheck code and link
tests against it. This includes ability to compile *.cpp files.
Sample test suite was created to demonstrate that wiring is in place.
File fun-rc.cc was created in test/libponyrt/ds to implement some
of the test cases found in fun.cc.
Thing to note:
Rapidcheck requires enabled rtti. To avoid recompiling things twice
three minor changes were introduced into rapidcheck code:
a) include/rapidcheck/detail/Any.hpp
virtual method typeInfo() which returns typeid(T) was commented
out,
b) include/rapidcheck/detail/ShowType.hpp
printing typeid(T).name() to the io stream was commented out,
I would like to ask for feedback on few items:

disabled rtti. I have commented few lines in rapidcheck to accomodate this but it is far from being a long term solution.
tests organisation, whether tests which utilize rapidcheck should exist in the same locations as the other ones (means all tests are linked against rapidcheck) or there should be a separate rapidcheck-dedicated target, the only one which is linked against the library.
possible tests naming convention to indicate those which utilize rapidcheck.

Thank you,
Wojciech

@WojciechMigda there appear to be some compilation errors.

What's RapidCheck's license?  Is there a LICENSE file that should be in this?

@WojciechMigda THANK YOU!

@WojciechMigda - Some feedback from today's sync call:
We're generally amenable to this, but more so for the runtime (libponyrt) than for the compiler (libponyc). That is, we'd like to see C++ property-based testing for things like the libponyrt hashmap implementation, but not so much for things like subtyping and ASTs. This is partly because we think that such tests will be more easily written in Pony, when we finally have some of the compiler stuff written in Pony. This is just something to keep in mind for the future when writing more property-based tests.
Responding to your specific 3 questions:

Let's turn on RTTI, but only for the rapidcheck-dedicated target (see point 2).
Let's use a rapidcheck-dedicated target.
If it's in a rapidcheck-dedicated target, we think a name convention probably isn't necessary.

Also, can you please address @killerswan's comment about the license?
Thanks!

Hi guys,
thank you for looking at this PR.
I was going to jump back in once I sort out the build errors but now I'll try to address your comments.

re: rtti. It can be enabled for the target which builds librapidcheck, but... there are many ways in which one can write testcases with rapidcheck. The most basic is when scenarios are written using rapidcheck api directly. Then there are provided wrappers for gtest, check, and boost.test. If one would like to use gtest wrapper (which would allow seamless integration with existing pony(rt) tests written with gtest) then the rtti thing be becomes an issue as rapidcheck expects that google test would be compiled with the same rtti setting. Hence, provided I am not missing something obvious, we would need libgtest being compiled twice - first for existing testcases which require rtti disabled, and then for rapidcheck which needs the opposite. I haven't checked the latter, though, so it might turn out that we would trip over ponyrt in turn not being compiled with rtti on.
One thing I can do to put this forward is to leave librapidcheck compiled with rtti, drop the sample scenarios in fun-rc.cc, and leave the decision about how rapidcheck testcases should be written (vanilla, gtest, ...) open. This should probably also help resolve compiler errors, although I am still baffled why they did not pop up at my setup.
License: my bad, I missed it. It is BSD-2 clause simplified (https://github.com/emil-e/rapidcheck/blob/master/LICENSE.md).

I'll try to do the following for now:

enable rtti for librapidcheck,
include rapidcheck license in the rapidcheck's subfolder,
remove fun-rc.cc and try to create a separate target wih plain vanillla example testcase.

@WojciechMigda if you create a rapidcheck-test Makefile rule, you should be able to enable rtti in general for the pony runtime and everything else.

remove fun-rc.cc and try to create a separate target wih plain vanillla example testcase.

why this step?

why this step?
@jemc Currently fun-rc.cc contains tests which make use of the gtest wrapper for rapidcheck. If I enable rtti for librapidcheck then without libgtest compiled with rtti too it won't link. With @SeanTAllen 's suggestion above, if I understand it correctly, we'll get it working, but with some stuff compiled twice, with and without rtti.

Got it. Thanks for the extra info.
For whatever it's worth, it would be okay to enable RTTI for the gtest targets - I think we just wanted to avoid compiling ponyc itself with RTTI if possible.

@WojciechMigda we are about to close a bug that could have been found via automated means if we had property based testing of the runtime. Looking forward to this making its way in.

@SeanTAllen I remember about this, I just need to find a slot to get back on the topic.

Appveyor build fails because seed value printed to stderr by rapidcheck testcases confuses waf(?). I would use some help on that, thanks.

I'll take a look in the next couple of days.

There can be problems using Python with PowerShell; try using cmd instead:
diff --git a/.appveyor.yml b/.appveyor.yml
index 5b494c1..9343732 100644
--- a/.appveyor.yml
+++ b/.appveyor.yml
@@ -84,6 +84,5 @@ build:
  none

test_script:
-  - ps: |
-      cd C:\projects\ponyc
-      python -x waf test --config $env:configuration --llvm $env:llvm
+  - cd C:\projects\ponyc
+  - python -x waf test --config $env:configuration --llvm $env:llvm

@kulibali thank you, it helped!

@WojciechMigda can you rebase this against master so we can get it moving towards being merged?

@SeanTAllen I am looking into this.

There was an issue submitted to rapidcheck (now closed) which reports this compilation error. From the quick glance it appears to be caused by a bug in gcc itself.
https://github.com/emil-e/rapidcheck/issues/148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933

@WojciechMigda - any update on this one?

Unfortunately, no. However, I looked into the latest build logs above and it is confusing why llvm compiles the offending file on alpine images, but fails on others. Are these official llvm releases being used?

Closing as stale.


Is there way to save the chosen file to a device path

Thanks for creating this nugget,
is there way to save the chosen file to a device path

what happens is that, I need to choose a .p12 file and save it in some path, so it is not only to see its content and copy it to another file to replace this, but to choose it and save that same one.

after many attempts this served me:
string objrute = Path.Combine(rute.path_cert, fileData.FileName);
File.WriteAllBytes(objruta, fileData.DataArray);

That's the way. You can also use result.GetStream() and use Stream.CopyTo(), if you want to go async.

Gracias, saludos.

You're welcome. By the way, it's actually Stream.CopyToAsync(), and there you can also specify a CancellationToken, e.g. for a progress dialog where the user can cancel the copying.


MyLife alerts

establish mechanic for Cosmos to host a set of potential alerts that would appear on site
Have it based on Q-session, and provide external way to reset this var, as alerts could happen any moment
input mechanic for azure could just be vs-code, not concerned about that at the moment

[ ] determine/define db/container/table [same/system/alerts
[ ] create datamanager system variant
[ ] pipeline
[ ] frontend

Absolutely, let's begin by creating a checklist for requirements gathering for Issue #132, "MyLife alerts." As you provide the details, I'll help structure them into a clear and actionable checklist. Here we go:

Define Alert Types:

[x] Identify different types of alerts needed (e.g., system messages, user notifications).

Determine Alert Triggers:

[x] Specify what events or conditions will trigger each type of alert.

Alert Content:

[ ] Decide on the content structure for each alert (title, message, action items).

User Interaction:

[ ] Define how users will interact with these alerts (dismiss, follow-up actions).

Display and Accessibility:

[ ] Establish how and where on the site these alerts will be displayed.
[ ] Consider accessibility and responsiveness in design.

Backend Integration:

[ ] Outline how alerts will be managed in the backend (creation, modification, deletion).

Data Storage and Management:

[ ] Determine the data storage needs (database design, data schema).

Performance and Scalability:

[ ] Assess the performance impact and scalability of the alert system.

Compliance and Security:

[ ] Ensure the alert system complies with relevant security and privacy standards.

Testing Criteria:

[ ] Define testing criteria for different alert scenarios.

Feel free to elaborate or add specific requirements for each of these points!

Great, you've provided some valuable insights for the "MyLife alerts" feature. Let's refine these ideas:

Session Start Trigger: Initiating the alert structure at the start of a session is a smart approach. It ensures that alerts are relevant and timely. Incorporating a push notification mechanism or an extensible hook for future enhancements sounds like a solid plan. This allows for scalability and adaptability as the system evolves.

System Error Triggers: Integrating alert triggers in every chat packet received is an innovative way to handle system errors. This method can efficiently notify users of any issues during their interaction with MyLife. It's a proactive approach to maintaining smooth user experiences.

Frequency and Volume Control: It's good to start with basic functionality and then expand. Providing hooks or placeholders for future frequency control features is a prudent way to plan for scalability without overcomplicating the current build.

User Customization: For now, skipping user customization simplifies development. Focusing on delivering a robust basic system before adding complexity is often a wise strategy.

Member-Generated Alerts: Planning for member-generated alerts in a future ticket is a great way to manage project scope. It keeps the current focus clear while laying the groundwork for future enhancements.

Fallback Mechanisms: While not immediately required, considering a simple fallback mechanism could be beneficial. For instance, a basic error message or notification alerting the user that the system is temporarily unavailable. This can be a simple function that gets activated when the primary alert system fails.

Historical Data: Writing hooks or empty functions for future implementation of historical data access is a forward-thinking approach. It leaves room for adding this functionality later without having to overhaul the system.

Your approach balances immediate needs with future scalability. It’s important to maintain this flexibility and foresight as the project progresses. If there are more aspects you'd like to discuss or refine, feel free to let me know! 🚀

Backend Coding Task List for Alert System
Initial Setup

[ ] Review Current Backend Architecture: Understand the existing backend structure to ensure smooth integration of the new alert system.

Database Integration

[ ] Setup Alert Table: Ensure the new alerts table in the database is properly configured and integrated.
[ ] Security Measures: Implement security protocols to restrict access to the system table, ensuring data integrity and privacy.

Server Configuration

[ ] Modify server.js:

[ ] Implement periodic searching for live alerts (e.g., every minute).
[ ] Configure session checking for already shown alerts.
[ ] Integrate appropriate middleware/routes for session start, login, and chat to trigger alert checks.

Data Management

[ ] Update mylife-datamanager.mjs:

[ ] Configure DataManager to retrieve and manage alerts based on specific criteria.

Session Management

[ ] Enhance session.mjs:

[ ] Implement pipeline for getAlerts() function.
[ ] Ensure all alerts are stored in the MyLife root session.
[ ] Manage user-shown alerts in session's alerts property.

Route and Function Updates

[ ] Adjust routes.mjs and functions.mjs:

[ ] Add and test getAlerts() function.
[ ] Ensure chat alerts are properly integrated and functional.

Testing and Validation

[ ] Test New Alert Creation: Verify the creation of new alerts and their proper functioning in the system.
[ ] Validate Alert Visibility: Check if alerts are visible to the user/member within the specified timerange.
[ ] Dismissal Functionality: Ensure that once dismissed, alerts do not show up again for the session.

Documentation

[ ] Update Backend Documentation: Document all changes, additions, and functionalities introduced in the backend for the alert system.


Make it easier to exit roc repl

Inspired by watching @kristoff-it's experience using Roc for the first time.
Theoretically there's a downside to special-casing exit here, but I predict in practice approximately zero people ever run into it. 😄

I like that idea! Want to add a new good first issue for it and share in Zulip? Could be a nice way into the codebase for someone! 😃


[Feature Request] SocialSply for msg/reply

To monitor for harassment, we need to make sure players aren't harassing other players via msg.
Can you add a single permission which allows viewing of people's private messages?

I think this as a permission as well as a command to enable/disable would be great, will work on it.

I've made a PR, thoughts on it? If it's fine just comment that it's fine and I'll merge it.


Create scripts for create environment on new system.

Create sub repository by git submodules for install scripts

Resolve by: 46ef311


Add license and vuejs badge

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (ad8c344) 100.00% compared to head (b90ead1) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##              master        #3   +/-   ##
===========================================
  Coverage     100.00%   100.00%
  Complexity       207       207
===========================================
  Files             45        45
  Lines            575       575
===========================================
  Hits             575       575

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add support for distro variants

The script now supports creating distro variants (e.g. "buster-next")
based on packages in the base build directory name (e.g. "buster").
This is done automatically, the command line only needs to specify the
destination name (e.g. "--distro=buster-next").
Signed-off-by: Cristian Prundeanu<EMAIL_ADDRESS>

I did this on purpose, to avoid the most common case of entering duplicate information (e.g. input buster, output buster). The case handling gets hairy since distro support is an array, we'd have to keep track of two arrays and match them correctly (i.e. what to do when the number of elements doesn't match - input buster, output buster and buster-next, etc).
The most obvious solution seemed to be to only specify the output, since the input can automatically be determined based on that, and the user really only cares about the output.

CI build failed on RHEL because the CI Redhat Enterprise account subscription is no longer active. Merging this as is.


Restored satrt as it was intended

Signed-off-by: nitinosiris<EMAIL_ADDRESS>Description
Restored "satrt" keyword as it was intended
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

🚀 Preview for commit 39cbe033fc74bb20486217f95fe8e55cd2b81c70 at: https://60f6cb8ebc3adfe802397b17--meshery-docs-preview.netlify.app


⚠ Avatar API Endpoint has degraded performance

In c274e34, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 1093 ms

Resolved: Avatar API Endpoint performance has improved in 9a0b082 after 5 minutes.


Remove Javascript 3rd-party dependencies from the Knetminer codebase

I've just copied my local clone of the Knetminer codebase and I realised there are directories with huge size, which seem to contain 3rd-party Javascript dependencies, eg, node_modules. This slows down operations like copies and Docker builds.
We should improve this and put those files out of our code base. One way to do it might be to see if there are already published Maven modules that could be linked from our POMs. Or, if no such thing exists, we could create separated Maven modules and link them.

for both Genomaps/ and KnetMaps/ in common/client-base/, fyi

After some investigation, this should be a reasonable plan.
Javascript refactoring
Work on the original Javascript repositories, KnetMaps and GenoMaps. For each of them:

Move everything about Bower into the NPM package list and build. This is hardly automatable, but there
is a guideline.
Upgrade Gulp and NPM versions.
Upgrade dependencies in Gulp and NPM. Use a similar approach of changing version one dependency at
a time and see if it works.
Ensure the Gulp/NPM files can build distribution files (in dist/) and add a build step to publish these files
into the NPM registry. If the latter is not viable, just publish back on the package github repository.
Once everything works, automate the build via GitHub Actions. Consider the approach we already have in
place for Java (here). This might be done after the KnetMiner refactorisation (see below)

KnetMiner refactorisation
Once the Js repo is re-arranged and can publish distro files, Go to KnetMiner and make client-base dependant on the distro only. At the moment this module has duplicates of both repositories and rebuilds everything (with bower, NPM, etc) during the Maven build. Clearly, this is redundant and needs to be factories. So,

we need to remove the Maven build steps that reproduce the Js process outlined in the previous section,
we need to remove non-distro files and
we need a different Maven build procedure that just downloads the distribution files into target/, thus preparing the .war building stage.

@manlikleo please close if completed.

This is practically completed, except for a few minor details:

On the respective Js repos, we need to update the documentation, including the demos
We also need to move these upgrades to the master branches
On knetmaps.js, we still have static files from dependencies, which we need to put back into the build cycle, see Rothamsted/knetmaps.js#36

@marco-brandizi @lawal-olaotan please close if done


How to add reusable modal(popup)

Double clicking is possible instead of editor.on('nodeselected')?
Need to dynamically add modal with different fields for each nodes.

View:

https://github.com/jerosoler/Drawflow/issues/566#issuecomment-1326065542

Is it possible to add double click without adding html on the node? Used addeventlistener(dblclick) it also not working. (angular project)

I can't help you in angular. But this would be the native javascript event with addEventListener.
    editor.container.addEventListener('dblclick', (e) => {
        if(e.target.closest(".drawflow_content_node")?.parentElement) {
            alert(e.target.closest(".drawflow_content_node").parentElement.id);
        }
    });


Shared Python lib

Summary
SUPSI, CSIC, Rovimatica, Ginkgo and Martel could all potentially benefit from a Python library for interacting with the Kitt4sme infra, especially Keycloak and Fiware. Developing a common code base and sharing it as a library is probably the way to go.
Intended outcome
Figure out if we should roll out our own thingie (e.g. FiPy) or rather entirely rely on existing libs like PyNGSI and PyNGSI-LD. We should come up w/ a solution that provides:

Type-annotated records to easily define NGSI v2 and LD entities
Built-in validation of NGSI entities
Orion and QuantumLeap clients
Transparent handling of Fiware headers---setting or propagation of tenant, service path and correlation ID.
Transparent handling of Keycloak security---JWT token acquisition, propagation and refresh.

How will it work?
Kitt4sme Python services would simply import the library and take advantage of all the built-in functionality. E.g. see how Roughnator uses FiPy.

PyNGSI
Reqs

[ ] Type-annotated records to easily define

[x] NGSI v2 entities
[ ] NGSI-LD entities

[ ] Built-in validation of NGSI entities
[ ] Clients

[x] Orion
[ ] QuantumLeap

[ ] Transparent handling of Fiware headers---setting or propagation of

[x] tenant,
[x] service path
[ ] correlation ID.

[ ] Transparent handling of Keycloak security---JWT token

[ ] acquisition
[ ] propagation
[ ] refresh.

Comments

Not maintained (last commit 1y ago)
Useful for developing "bridge" agents (converting "rows" from Sources to NGSI entities), with some ready-to-use implementations for MQTT, FTP, and generic HTTP server.
Tenant and auth configs managed via config file
Light entity validation (forbidden chars for id and other fields, reserved keywords)

python-ngsild-client
Reqs

[ ] Type-annotated records to easily define

[ ] NGSI v2 entities
[x] NGSI-LD entities

[ ] Built-in validation of NGSI entities
[ ] Clients

[x] Orion
[ ] QuantumLeap

[ ] Transparent handling of Fiware headers---setting or propagation of

[x] tenant,
[ ] service path
[ ] correlation ID.

[ ] Transparent handling of Keycloak security---JWT token

[ ] acquisition
[ ] propagation
[ ] refresh.

Comments

Under development (many contributions pushed in the last month)
Revolving around the concept of agents (converting "rows" from Sources to NGSI entities).
Light entity validation (fields presence - no actual type checking)

PyNGSI-LD
Reqs

[ ] Type-annotated records to easily define

[ ] NGSI v2 entities
[x] NGSI-LD entities

[ ] Built-in validation of NGSI entities
[ ] Clients

[x] Orion
[ ] QuantumLeap

[ ] Transparent handling of Fiware headers---setting or propagation of

[ ] tenant,
[ ] service path
[ ] correlation ID.

[ ] Transparent handling of Keycloak security---JWT token

[ ] acquisition
[ ] propagation
[ ] refresh.

Comments

Under development (project started in January 2022)
Revolving around the concept of agents (converting "rows" from Sources to NGSI entities).
Entity creation and validation delegated to python-ngsild-client

Given the above comments, my view is that rolling out FiPy is the best choice for us, because:

Security stuff is never managed in considered libs, while FiPy already supports some aspects
Other libs are mainly focused on mapping different sources (CSV, JSON, HTTP Server, MQTT messages, etc.), while we are also interested in managing different outputs (Orion and QuantumLeap), by also considering the security (mostly overlooked in the other libs, but crucial for KITT4SME, as well as for production envs)
Validation is never considered at the type checking level - FiPy models are validated with pydantic

Alternatively, we may consider extending a lib (pyngsild?) to meet our requirements, but:

NGSI v2 and LD versions are supported by different libs
Libs for NGSI-LD are quite new and not stable, thus we should deal with their current evolving status
Most of our requirements are already implemented in FiPy, thus we will end up migrating Fipy functions to an external lib

Instead, I would consider bringing some features (e.g., fields presence check, reserved keywords check, agents creation, sources implementation) from the considered libs to FiPy (considered libs are released under Apache2 license).

Wow! Excellent analysis, thanks a stack!! Let's make a decision about this in the next grooming session.


ENH: allow operator nodes to access full documents

If no input_info is given assume that we want the entire doc(s) as kwargs (useful for formatting where we have no idea what we want from the documents).

Note that this gets a bit tricky as we want to merge the events together if we have multiple documents come down. This means that we need to do a merge of two nested dictionaries. See here for a potential solution.

Closed by #60


WIP: Jenkins CI: clean repos before checkout

Hope this will fix some CI issues.

Coverage decreased (-0.01%) to 51.75% when pulling 680f7a6cf335e1ddfe475c8e78c7e75a7b722cee on qixcheng/jenkins/clean-repo-before-checkout into c5ce662a0221f968d30bd34785473f3f3f0b34be on master.

Coverage decreased (-0.01%) to 51.75% when pulling 680f7a6cf335e1ddfe475c8e78c7e75a7b722cee on qixcheng/jenkins/clean-repo-before-checkout into c5ce662a0221f968d30bd34785473f3f3f0b34be on master.

Coverage decreased (-0.01%) to 51.75% when pulling 680f7a6cf335e1ddfe475c8e78c7e75a7b722cee on qixcheng/jenkins/clean-repo-before-checkout into c5ce662a0221f968d30bd34785473f3f3f0b34be on master.


Improve unit tests

Need to make more tests, for example we can analytically calculate some results and verify that everything works as expected.
Should also refactor the current tests and conftest

superseeded by #60


Simpler package structure

Wanting to dynamically import only a single element not has to deep dive into the dist-src directory:
import('@aybolit/material/dist-src/components/abm-button').then()

I find this uncommon as well as providing a bundled js file as the default index.
Instead, I propose a simplified build where individual components are imported by default both statically and dynamically.
import '@aybolit/material/button'
// equal dynamic import
import('@aybolit/material/button')

If desired, the bundled build would stay but being the non-default alternative

Thanks for the issue. Actually, I was thinking about making each component a separate npm package (like most of people in Polymer community are used to). Would that solve the problem for you?

Sure, that would also be less surprising and indeed Polymer elements do come to mind as an example of established practices.
On the other hand some paper/iron packages actually come with multiple custom elements. Do you think it's worth separating each aybolit package into individual package per component? Sounds like a lot of packages :)

Hi,
I’ve been eying this repo since I’m working on an industrialized ui toolkit and we’re now defining our design system.
From our experience (we only use web components and, for now, Polymer) working with different repo’s per component turns into a mess pretty quickly. I much prefer the import '@aybolit/material/button' approach, which is the approach that libraries like reactstrap or web-components-material-web-components (whatever the name is...) use (in different eco systems, obviously).
I believe the Polymer team also came into that conclusion as that’s what the material team is now doing (and the paper-elements are dead, anyway).
Hope I was able to help 👍

@aveiga thanks for your opinion as well. I would prefer to collect the feedback before making any decisions, yet there is plenty of time until 1.0 release to revamp the structure.

working with different repo’s per component turns into a mess pretty quickly

That's not what I meant. There would be still 1 monorepo, but the structure could look similarly to what I've been experimenting in https://github.com/web-padawan/lit-components

@web-padawan 1mo later, what are your latest thoughts here?


mesh generation in rings example errors

Description
The file examples/rings/mesh/mesh.jl defines the function generate_ring_mesh. Among the keyword parameters there are rot_center, rot_axis and rot_\theta. However, the function body uses rc, ra and \theta instead. Therefore, calling the function errors out.
Even correcting the names, the gemerated mesh doesn't gemerate the same mesh as the one included in palace 0.13.0. In particular, differently from the distributed rings.msh file, the generated one does not include any physical group.
Environment
OS: NixOS 24.05
Palace: 0.13.0
Gmsh: 4.13.1
Julia: 1.11.1
Julia-Gmsh: 0.3.1

Hi @hughcars
Thanks for the explanation about the meshing algorithm. I'm new to Palace and Gmsh and the mesh generating scripts are very useful.


RFC: LushBuild (export lush anywhere, without lush)

Goals
The main goal of this is to allow theme developers to use Lush solely as a theme creation tool with it's live updates, extension system and DSL syntax, while not forcing end users to install Lush.  Part of this includes exporting your theme to VimL, but it also includes a Lua exporter with hooks to provide enduser configuration.
As a side effect, it also aims to let you export your Lush data easily to other formats.
WIP PR #77 (sort of misnamed compiler-plugins branch).
RFC:

UI issues? Particularly around configuring a lua theme as an end user.
Unclear documentation (this is probably a reasonable draft of what will ship in the vimdoc or separately)?
Additional features? (Can't promise but interested to know. I think the system is pretty extensible as is.)
Usefulness?

Preamble
The Lush build system is designed to take a lush spec (i.e. the color and group data from your theme) and apply any number of transforms to that data. These transforms can include conversion to a vim theme, terminal emulator theme, writing to different files, etc.
Some prerequisite knowledge
-- lush_build.lua
export zenbones,
  viml,
  {overwrite, "colors/zenbones.vim"}

The exporter simply pushes data through a function pipeline, these functions are termed "transforms".
There are two kinds of transforms: "head" and "tail".
Head transforms must accept a parsed lush spec (returned by require("theme")). It must return a table of any content. You will place a head transform at the start of your pipeline.
Tail transforms must accept a table and must return a table. The contents of these tables is not enforced, they could be strings (a table of lines), functions (such as closures around data), other tables, etc.
Transforms can take any additional number of arguments after the table.
Lush ships with some default transforms:

viml (head)
lua (head)
prepend (tail)
append (tail)
overwrite (tail)
patchwrite (tail)

These transforms are automatically injected into the build environment along with lush and export.
You can provide any of your own transforms just by writing a function, either in the build file or in another module.
We will discuss the simplest example, where you have a theme with no variations or configuration options and simply want to let non-lush users use your theme.
A basic theme, exported to VimL
To ship our theme as a viml file, we simply must load our theme, convert it to viml and save the output to a file.
We will use the viml and overwrite transforms.
Our build file would look something like this:
-- lush_build.lua

-- we start by calling export and giving it our theme as the first argument.
-- any other arguments form the pipeline.
local theme = require("my.lush.theme")
export(theme,
  -- now we will convert that theme to a list of viml highlight commands
  viml,
  -- the viml commands alone are generally not enough for a colorscheme, we
  -- will need to append a few housekeeping lines first.
  -- note how we are passing arguments to append by wrapping the transform
  -- in a table.
  -- {transform 1 2 3} will result in transform(last_pipe_value, 1, 2, 3)
  -- append accepts a table, so this call ends up being:
  -- append(last_pipe_value, {"set...",  "let..."})
  {append {"set background=dark", "let g:colors_name=\"my_theme\""}},
  -- now we are ready to write our colors file. note: there is no reason this has
  -- to be written to the relative "colors" dir, you could write the file to an
  -- entirely different vim plugin.
  {overwrite, "colors/my_theme.vim"})
-- and that is the whole build file

You can run :LushBuild <build_file> which will load and execute the given build file, or if no buildfile is specified, lush_build.lua is used. You probably want to do this from your lush themes root dir but you can run it anywhere.
Take Aways and Notes
It's important to remember:

The build file is "just lua", you can use any normal lua inside it, including loops, other modules, etc.
export() accepts a parsed lush spec, so you can use lush.extends to generate variations in or outside of the build file.
Transformers are "just functions", so it's very simple to write your own extensions to the provided transforms.

As a further example, we will write our own transform next.
Converting a Lush theme into an Alacritty theme
As an example, we will convert a theme into a (truncated) Alacritty theme.
To do this we will need to:

collect a subset of groups to export
convert #000000 hex values to 0x000000
generate a yaml file for use with Alacritty

-- As an example, we will imagine we are developing a lush transform
-- for release into the community.
--
-- We will say this transform expects to get a table shaped as:
--
-- {
--   primary = {
--     bg = color
--     fg = color
--   }
-- }
--
-- along with a name.

local function hash_to_0x(color)
  return string.gsub(color, "^#", "0x")
end

local function alacritty(colors, name)
  return {
    "# Colors: " .. name .. " theme",
    "colors:",
    "  primary:"
    "    background: " .. hash_to_0x(colors.primary.bg),
    "    foreground: " .. hash_to_0x(colors.primary.fg),
  }
end

return alacritty

-- lush_build.lua

local theme = require("my_theme")
local alacritty = require("lush_community.transform.alacritty")

export(theme,
  -- we must adjust our theme to conform to the alacritty transforms format.
  -- we can do this with an inline transform.
  function (groups)
    return {
      primary = {
        bg = groups.Normal.bg,
        fg = groups.Normal.fg
      }
    }
  end,
  -- now we can pass to alacritty, note that it needs a name
  {alacritty, "my_theme"},
  -- and now we can write, either to share or to our local config
  {overwrite, "~/.config/alacritty/theme.yaml"}
  -- note, as overwrite is a transform, it *must* return a table, and infact
  -- overwrite returns the same lines it was given. we can pass these lines
  -- another transform.
  {overwrite, "extra/terms/alacritty.yaml"})

Exporting as configurable lua
Nb: I specifically made my own lua theme, so some of the deployment of this may be wonky, the api code should be usable anywhere though.
The lua transform generates code you can call to load and apply a lush theme without lush. It will require you to provide a support context around it.
By using the patchwrite transform, we can instruct the lush build system to only update its own code, leaving our support code intact.

-- lush_build.lua

export(require("theme"),
  -- generate lua code
  lua,
  -- write the lua code into our destination.
  -- you must specify open and close markers yourself to account
  -- for differing comment styles, patchwrite isn't limited to lua files.
  {patchwrite "colors/theme.lua", "-- PATCH_OPEN", "-- PATCH_CLOSE"})

Before running this build file, we should prepare the destination for patchwrite.

-- colors/theme.lua

-- content here will not be touched

-- PATCH_OPEN

-- PATCH_CLOSE

-- content here will not be touched

After running :LushBuild, we will have a lush_apply function.
By default, lush_apply will convert your theme (now compiled as a table) into viml highlight commands and apply them, but you can provide optional function hooks to lush_apply to alter data along the way.
The following hooks are provided:

configure_group_fn = function(group) ... end

Accepts a group and may alter that group if needed, to turn italics on or off by user config for example.
Returns a group shaped table.

generate_group_fn = function(group) .. end

Accepts a group and generate something that apply will understand.
By default this is a highlight ... vim command but you could return other viml, raw lua, different tables, etc.
The results of this function is collected into a table of "rules", one per group.

before_apply_fn = function(rules) ... end

A final chance to alter any rules. This could include broad regex's or selective deletion, etc.

apply_fn = function(rules) ... end

Accepts a table of rules (or whatever was returned by generate_group -> before_apply) and should do something to apply these rules as highlights.
By default this passes the rules to vim.cmd but you could write your own handler to use nvim_set_hl, etc.

For complete details, see the documentation in the generated code (or lua/lush/transformer/lua.lua in the branch)
Now that our theme has been exported, we can adjust our theme.lua file to use the generated loader.

-- colors/theme.lua

-- PATCH_OPEN
-- Generated by lush builder on Mon Nov  1 22:20:06 2021
--
-- You can configure how this build function operates by passing in optional
-- function handlers via the options table.
--
-- See each default handler below for guidance on writing your own.
--
-- {
--   apply_fn = function(rules) ... end,
--   before_apply_fn = function(rules) ... end,
--   generate_group_fn = function(group) .. end,
--   configure_group_fn = function(group) ... end,
-- }
--
local lush_groups = { ... }
local lush_apply = function(opts)
...
end
-- PATCH_CLOSE

-- imagine we want to provide some optional adjustments to groups
local overrides = {
  Comment = {italic = false}
}

local setup = function(config)
  if config.italic_comments then
    overrides["Comment"]["italic"] = true
  end

  local my_configure_group = function(group)
    if overrides[group.name] then
      if overrides[group.name]["italic"] then
        -- apply configured override
        group.gui = "italic"
      end
    end

    -- return maybe adjusted group
    return group
  end

  -- run lush loader with our custom configure function to
  -- adjust the groups per user config.
  lush_apply(lush_groups, {
    configure_group_fn = my_configure_group
  })
end

return {
  setup = setup
}

Note, you don't have to run this exported lua directly, you could still have your "core theme file" that takes a config and requires which ever theme is appropriate.

return {
  setup = function(config)
    if config.light then
      require("theme.lush_export.light").apply()
    else
       -- ... etc etc
    end
  end
}

Other Transform Ideas or LushBuild concepts

Translate lush's guifg/bg to ctermfg/ctermbg.
Terminal themes from Lush themes.
Saving/Dumping theme as a "compiled lua" via string.dump().
Translating Lush themes into Textmate Emacs themes.
Imagine nvim_set_hl becomes stable with 10000x performance increase, you could easily swap viml for a set_hl transform and provide theme.lua and theme_nvim_5_1.vim.
"Your Lua exporter is bad" → don't have to wait for me to fix it, can build your own to fit your own needs (and share it!)
I like this theme but it doesn't support my terminal

You can install lush and write your own build file that just loads up the other theme and dumps to whatever you want.

Issues

Some murky-ness around how theme variants fit at the development stage

This has always been a weak point with lush since it's not something I do personally so the experience around it isn't really tested much.
This is especially an issue with the wide methods of configuring a theme, perhaps having a unified lush-lua export may help provide a "happy path" for at least those themes.

I'm really excited for this. I was in the middle of restructuring my build system but glad to see that lush is having something that is quite extensible and more powerful. I'll be moving to lush's build system when it's ready.
I'd like to share an idea about a vim compatible structure that doesn't need a separate colors file. Basically we don't need to have a separate colors/zenbones.vim and colors/zenbones_compat.vim. The structure of the colorscheme file would look like a simple branch:
...
let g:colors_name = 'zenbones'

if has('nvim')
    lua require("zenbones.util").apply_colorscheme() -- wrapper to just apply specs, term colors etc
else
    call {g:colors_name . '_' . &background}#load() -- use autoload files to store vim compat hl groups
endif

There will be two autoload files that will be generated by lush builder: autoload/zenbones_light.vim autoload/zenbones_dark.vim. Just each one containing light and dark hl groups respectively.
With this way, I can separate generated stuff from actual written code. I can even publish it in a separate repo as an optional dependency (mcchrish/zenbones_artifacts.vim) if one wants the compatible option.
This is at least what I plan to do.


Define conditions and messages as a JSON dictionary and Python functions

Here is the code:
https://github.com/NASA-IMPACT/github-projects-automation/tree/11-add-metrics-from-the-sde-board-on-the-sample-project-board


Enable tabular figures when using DirectWrite

This enables the tabular figures (numerals) OpenType feature when rendering text using DirectWrite.
This is useful in particular for most Segoe UI variants.

It's shocking what people will steal these days. 😬
https://github.com/jscript-panel/Core/blob/bd8bba57e1ad5c2323f18e510a421209707a97ef/Factory.cpp#L41-L42

Yes, that took a bit of digging to find out (literally nothing on Google for ‘DirectWrite tabular figures’) so I'll be writing a blog post on it soon 😄


Try putting honeycomb writes in a goroutine

Can we close this?  I think we only did this because I claimed that when enabling honeycomb on a localnet caused it to start up much slower.  This didn't end up making it any faster.

Honeycomb writes already happen in a goroutine, and are automatically batched.


Add docker support

To add docker files. First, we need a CI-CD action to deploy it to docker hub.
The first step to #97 and #99.
@lgvaz you need to set up secrets as username and password for docker hub in your GitHub secrets action.
As described here

Will this work without a Dockerfile?

Okay, I'm building locally. Once done will add PR for that too.

Just keep pushing to this PR =)

Added minimal docker file. It should hopefully.

Everything works locally now. @lgvaz setting up the Secrets with GitHub should and CI action should push this to docker hub as well.
As we update the master new container will be created and pushed again to docker container hub.

Yes, we can provide docker images with CUDA support as well as with No CUDA support (I guess this is useful for stuff like Raspberry Pi kinda devices). We need to tag them differently and need different Dockerfiles for both. Something which TensorFlow does like this. Currently, Dockerfile is built with torch GPU.

It is done as in here. The current image is built for GPU. As it uses PyTorch GPU. User needs to follow these instructions to run NVIDIA drivers within their container.

What best we can do is provide containers for both CPU and GPU separately. People need to setup their GPU using nvidia-docker and just run the container which will get created with this PR.

Alright then, let's merge this one and we keep adding more support as it needs


Redirect flow for FxA (fixes #984)

I just copy/pasted the tests from the other views and changed the 200s to 302s. There's probably a better way to test this...

The code looks good. Regarding the copy/pasted tests: I don't know, maybe this is something we need to discuss some more (maybe at Mozlando?).
I personally don't mind much about code duplication in tests. Simple tests are better than complex ones. It's easier to trust a simple test. However, code duplication means it's more difficult to refactor/modify in the future. But then again, it's tests.
In this specific case, if the only difference is the return code, then maybe you could rewrite the tests to use assert response.status_code == self.STATUS_CODE, and simply have a new class that inherits from the base one? You'd then still have simple tests, but no code duplication.
And you can still overload some tests if needed (if there's too many differences), or add new ones. It's however a bit more difficult to track down the test that fails, and realize that it's being run with another class (not sure that is very clear, I can elaborate more if needed).
Anyway, no clear answer here I'm sorry, but I'd be glad to discuss it!

I significantly refactored the tests to mock the common login_user and register_user functions and tested those separately.

Well, it looks much better like that, what do you think? Well done, awesome job!
r+wc (there's just two unused imports that make the build fail ;)


"Migrating To Phlex" for Rails docs glaring omission

Many Rails apps utilize the app/helpers feature for code reusability when rendering. I cannot figure out how to integrate the methods defined under app/helpers/ into Phlex's rendering pipeline, which seems very much like the kind of thing that would be pointed out under a Rails migration guide.
The docs make it clear how to create custom "helpers" for tags, which is nice but I absolutely need the logic in my helpers to become accessible inside Phlex classes/views. Also, the docs like to use the word "helpers" both for Rails built-in helpers and Plex's helpers, without a single mention of the existence of user-defined helpers under app/helpers, which is mildly confusing.

Thanks for opening this issue. I agree the docs need some major clarification here.

After working all week converting a bunch of views over to Phlex (love it btw!), I've found I was able to extract a decent amount of helpers into Phlex components. Compute-only helper methods used in multiple places can be placed in a file views/<controller_name>/helpers.rb under Helpers module. I then declare module-methods and call them where needed. Compute only methods used in one place can either be included in this module or a private method in the component that references it.
This or a similar suggestion about what to do with custom helper methods under app/helpers would at least get people headed in the right direction.

Found this thread when searching for advice for what to do with presenter logic - similar question, I guess. I'm psyched to start using Phlex but i'm unsure where to put presenter logic - i'm guessing similar to @tubsandcans included module above.
Background - I have an ImagePresenter that I call with an Image instance and args, that returns a Ruby object with formatted data for outputting the image as an HTML component potentially wrapped in a whole UI (image caption, lightbox markup, voting UI, info about image associations...) and I instantiate the presenter it in a few places in the code:

regular standalone images
carousel images
carousel thumbnails

Since these would be separate Phlex components, I obviously want to reuse the logic. Advice welcome, even a short word in this thread, but some documentation of this pattern would be great too.

@nimmolo depending on your requirements, either approach — having each component take a common presenter object, or having them share behaviour through inheritance from some common module or superclass — could make sense. You may also be able to have your carousel component just render the standalone image component for its own images and thumbnails.
The library doesn’t have any opinions on this.


Minor clean up for convolutions in C++

rename c64 to complex
make pi a constant instead of function
use int instead of ptrdiff_t
use for-loop instead of for_each

Hey, it looks like this PR is good to go, but it is blocked by @Gustorn. Should I just dismiss the review and merge?

I think size_t is preferred here, right?

size_t is the correct approach, I personally prefer it despite it requiring some verbose casting. antonte prefers the simplicity of int and I see his point. Merging now would finalize the use of int, we probably need somebody else to voice their thoughts on it before coming to a conclusion.

What about unsigned? int should never be used if it is physically incorrect for a variable to be negative, regardless of the size.

I'm closing this pull request since there is no convolutions chapter now.


zeebe-simple-monitor database structure

Dear,
I am writing to ask for the database structure of zeebe-simple-monitor. Could you please give me the sql commands of creating all the tables in the database? I am working on transfer them to MySQL database. Thanks a lot for helping!
Best wishes,
Ge Yang

The SQL commands are generated by Spring. There is no handwritten SQL. Everything is based on Spring Data.
Supporting MySQL database should be easy. Just look at the configuration here. There is already another issue #337 open for supporting MySQL similar to PostgreSQL.


[FEATURE] Allow "-PageSize"  in Get-PnPFileInFolder command

Get-PnPFileInFolder in a folder having more than 5000 files causes the error:
The attempted operation is prohibited because it exceeds the list view threshold.
You have a solution for Get-PnPListItem with -PageSize less than 5000.
If possible, would you please apply same option to commands that get files like Get-PnPFileInFolder
Thank you.

Closing this as duplicate of this feature request : https://github.com/pnp/powershell/issues/4141

@Ofer-Gal - this has been fixed in the latest nightly builds !

Thank you


I want GenPlugin to generate a tox.ini configuration for plugins

As a plugin developer, I want GenPlugin to generate a tox.ini configuration for plugins, so that my plugin testing configuration is already setup.
Related to #117.
Suggested tox.ini output:
[testenv]
commands = nose2 -c tox.ini {posargs}

[flake8]
extend-select = W504
ignore = E501, E402, D202, D401, W503, D212
exclude = .git,__pycache__,docs/source/conf.py,old,build,dist,venv,.env,.eggs,.tox
max-complexity = 10
# The GitHub editor is 127 chars wide
max-line-length = 127
statistics = True
show-source = True
docstring-convention = google
count = True
per-file-ignores =
    # Ignore docstring errors in tests
    *tests/*:D102,D100,D101,D200,ANN101,ANN201,W293,W291,ANN001,E731

[unittest]
start-dir = .
code-directories = {{plugin.name}}

[coverage]
coverage = src
always-on = True
coverage-config = tox.ini

[run]
omit =
  *.jinja2

[report]
fail_under = 60.01
precision = 2
show_missing = True
skip_empty = True
sort = cover

AC:

[ ] The Genplugin generates a tox.ini file at the top-level of plugin directory (same level as setup.py)
[ ]  The tox.ini file generated allows the plugin developer to successfully (assuming tests pass) test their plugin by running tox in the plugin's top-level directory

We should hold off on this until we update the GenPlugin to support 1st and 3rd party plugins since this is only helpful for 3rd party plugins.


Typo "Azure storage emulator"→"Azure Storage Emulator"

https://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-explorer

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

Misunderstanding.
Closed #62144.


Cannot Edit or Delete task when added

When you add a task, you should be able to click/swipe the arrow to either edit or delete task. For some reason that's not working.

Awesome first attempt!

Now I can fork this repo, make the changes, make a pull request and you can accept


provide total interaction count on campaign submit

added in latest commit https://github.com/WeiFund/WeiFund/commit/8ae03211b9ab4155662ac7bcc8be1c1a2d26421e


arch: xtensa: Remove unused field from _thread_arch

This PR removes the custom_data field from _thread_arch
for xtensa platform as it is currently unused.

Codecov Report

Merging #12009 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #12009   +/-   ##
=======================================
  Coverage   48.13%   48.13%
=======================================
  Files         281      281
  Lines       43425    43425
  Branches    10406    10406
=======================================
  Hits        20902    20902
  Misses      18368    18368
  Partials     4155     4155

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 e21d7cc...13b09c0. Read the comment docs.


Building upgrades not getting finished

I've noticed some of my building upgrades were not finished and are stuck on remaining = 0
Example grid IDs this has happend to
43669 - stuck at level 1 upgrade
54924 - stuck at level 8 upgrade
I cannot do anything with these, cannot demolish, cannot upgrade, they are just there, taking up space.

I was able to unstuck these by deleting the upgrade from browsers' console.
This is till an issue tho.

@edvordo thanks for the report, I will investigate this

Now it happened when training units.
Building/Grid IDs affected 113696, 113691, 113685 all on the same planet

A movement is stuck now as well at remaining = 0
Movement id: 13962

Well, just about any and all construction / training is now halted for me.
I've got several planets with stuck training / upgrades.
Even restarting them (making a request from console to delete upgrade / training) doesn't seem work anymore, they just get stuck again.
Only thing working for me at this point is just resource collecting.

Any updates on this? :)
I get that it's holidays season and I do not mean to rush anything, just asking.

Not sure what changed, but on new planets and new training/construction (on pre-owned planets) seem to be working alright now.
It's just those stuck upgrades / training I still have and can do almost nothing with (I can delete the training / cancel the upgrade and re-do it, but I'd prefer not to if it can be helped).

Also I think I found a new issue, some planets, even tho I have 7 Drone Bay buildings, I do not have the full capacity available to me.
For example, planet id 17505, I've got 7 Drone Bay buildings and hence should have 141k free unit supply storage (each building 20,000 unit supply giving 140k combined + 1000 unit supply from Command Center), but API responds with 133,400 available unit supply storage space.
This value seems to be stored in the database as a table column, so I guess some Upgrade(s) of one (or more) of the Drone Bays didn't update the planet record properly.

I'd welcome (say) a button to let us finish the upgrade / training manually. This could be a mechanic, that would use solarium in case the time remaining would be more than say a minute (scaled based on how many minutes are remaining possibly?), otherwise of course free.
I think even  the shortest upgrades / training are more than a minute. Also it would encourage players to harvest solarium more, since that could speed up unit production. IDK, just an idea.
But a button to manually finish an upgrade / unit training would be definitely helpful, if possible!
Also some kind of way to recalculate the (static values of a) planet would be nice, to solve the problem in my last comment. :)

A movement is stuck now as well at remaining = 0
Movement id: 13962

Is there a solution for this I have several such transporters in space?

Unfortuanatelly, I haven't found a way to make the transports finish. I think this has to be done on the server by @petaki


[FormBuilderTypeAhead]: Possibility of adding only select list values

Is there an existing issue for this?

[X] I have searched the existing issues

Package/Plugin version
10.0.0
What you'd like to happen
Add a possibility to decide if only values from the select list will be saved in the form field.

Alternatives you've considered
No response
Aditional information
No response

Hi - is this feature already implemented?
I copied the sample, but I'm only able to use values of the suggetions.


smooth edited result loose some frames

Base on my observation, the result from smooth edited video has a shorter length compare to input. Is there away to keep a fix duration for smooth editing?

Found out it was a result of fail on  computing landmark transformation.


Lazily evaluated fields for bulk operations

Thoughts
Sometimes database (or any) operations can be merged into one (or at least fewer) operations
Like, in queries, instead of getting a whole document (or row) just to return a few fields
or getting the same related document of multiple documents with multiple queries.
It all can be merged into one query.
Or, in mutations, instead of updating a document multiple times, it can be merged into a single operation.
Proposed Solution
Fields can return a lazily evaluated values that can be merged together after request execution.
Syntax
The library would expose an interface for lazily evaluated values.
interface LazyEvaluatedValue<T>

An adapter implements those interfaces
data class DatabaseGetOperation<T>(
    val collectionName: String,
    val filter: DatabaseFilter,  // made up class name
    val field: String
) :  LazyEvaluatedValue<T>

data class DatabaseSetOperation<T>(
   val collectionName: String,
   val filter: DatabaseFilter, // made up class name
   val field: String,
   val value: DatabaseValue // made up class name
) : LazyEvaluatedValue<T>

A graphql configuration variable can be set
graphql {
    engine {
        lazyValueEvaluator<DatabaseGetOperation> { values: List<DatabaseGetOperation> ->
              databaseClient.performOperations(values) // made up function name
        }
        lazyValueEvaluator<DatabaseSetOperation> { values: List<DatabaseSetOperation> ->
              databaseClient.performOperations(values) // made up function name
        }
    }
}

now the fields would look like:
field("getMyField") {
    //...

    getLazyEvaluatedValue {
        DatabaseGetOperation(
           collectionName ="myCollection",
           filter = DatabaseFilter("id=${instance.id}"),
           field = "myField"
        )
    }
}
field("setMyField") {
   val arg = argument { /*...*/ }

   getLazyEvaluatedValue {
        val argValue = arg()

      DatabaseSetOperation(
          collectionName = "myCollection",
           filter = DatabaseFilter("id=${instance.id}"),
           field = "myField",
           value = DatabaseValue(argValue)
      )
   }
}

Better Idea, why not achieve the same as Options API in monkt
The code would be like:
field("setMyField") {
    val arg = argument { /*...*/ }

   get {
       val argValue = arg()
       val insertionResult by enqueue {
               DatabaseSetOperation(
                    collectionName = "myCollection",
                    filter = DatabaseFilter("id=${instance.id}"),
                    field = "myField",
                    value = DatabaseValue(argValue)
               )
       }

       wait()

       val insertionResult2 by enqueue {
               DatabaseSetOperation(
                    collectionName = "myCollection",
                    filter = DatabaseFilter("id=${instance.id}"),
                    field = "myField",
                    value = insertionResult.value
               )
       }

       return@get insertionResult.value
   }
}

This way, multiple sequentials evalutions can be acheived

Here is some technical thoughts to implement an API similar to the Options API in monkt:
core module

No modification of existing APIs is necessary.
The enqueue function can be in the GetterScope

graphql module

Update the FieldResolver mapping to make it wrap the to-be-evaluated values
Update the GraphQLResponse to collect the to-be-evaluated values and keep executing
them until all executed and then replace them in the response with the final execution results

Finally, this feature is not very important to me (personally) right now so I might do it later this year


Include devtools in wrangler monorepo

Previously, wrangler relied on @threepointone's built-devtools. Now, these devtools are included in the wrangler repository.
This PR is marked as a draft until https://github.com/cloudflare/wrangler2/issues/960 is resolved, at which point I'll add a CI step to automatically deploy builds.
Closes #881

This continues to not work because --assets isn't happy about the size of some of the files.

It's probably easier to review by checking it out on your machine -- the package.json is still there 👍🏻

Can't stamp this on my phone, but let me merge it in anyway


add message monitoring for events and event evaluation

loklak can evaluate events (aggregation of users, mentions, hashtags, hosts of tweetet links) and prepare statistics about this. The idea for this feature request is, that:

it should be possible to start the monitoring of events, where one event may be a single talk
view statistics about an ongoing or past event. The statistics should include:
a histogram showing the number of tweets per time (minimum resolution: one minute)
top-x tables for most tweeted hashtags, most active users and most mentioned users
starting of a monitoring of an event may be connected to an in-app payment option
The information for these items are all provided by loklak, what is needed is only an interface in the app.

for a documentation of the event evaluation, see http://loklak.org/api.html#search under subsection "Search Result Aggregations"
Here is an example of an aggregation:
http://loklak.org/api/search.json?q=fossasia since:2015-03-01 until:2015-03-27&source=cache&count=0&fields=created_at,screen_name,mentions,hashtags&limit=10
{
"search_metadata" : {
"startIndex" : "0",
"itemsPerPage" : "0",
"count" : "0",
"query" : "fossasia since:2015-03-01 until:2015-03-27"
},
"statuses" : [ ],
"aggregations" : {
"created_at" : {
"2015-03-02 00:00" : 4,
"2015-03-03 00:00" : 0,
"2015-03-04 00:00" : 6,
"2015-03-05 00:00" : 4,
"2015-03-06 00:00" : 10,
"2015-03-07 00:00" : 6,
"2015-03-08 00:00" : 4,
"2015-03-09 00:00" : 24,
"2015-03-10 00:00" : 19,
"2015-03-11 00:00" : 47,
"2015-03-12 00:00" : 44,
"2015-03-13 00:00" : 628,
"2015-03-14 00:00" : 364,
"2015-03-15 00:00" : 440,
"2015-03-16 00:00" : 51,
"2015-03-17 00:00" : 41,
"2015-03-18 00:00" : 36,
"2015-03-19 00:00" : 27,
"2015-03-20 00:00" : 24,
"2015-03-21 00:00" : 12,
"2015-03-22 00:00" : 11,
"2015-03-23 00:00" : 5,
"2015-03-24 00:00" : 15,
"2015-03-25 00:00" : 21,
"2015-03-26 00:00" : 17,
"2015-03-27 00:00" : 5
},
"hashtags" : {
"fossasia" : 820,
"FOSSASIA" : 552,
"mozasia" : 106,
"MozAsia" : 76,
"Singapore" : 42,
"DevOps" : 30,
"FOSSAsia" : 29,
"opensource" : 26,
"Fossasia" : 23,
"FirefoxOS" : 19
},
"screen_name" : {
"rara79" : 71,
"engineersftw" : 51,
"dukeleto" : 50,
"downey" : 46,
"nikunjness" : 36,
"kushaldas" : 32,
"nhie22" : 32,
"repeatedly" : 30,
"fossasia" : 29,
"danishkanavin" : 26
},
"mentions" : {
"fossasia" : 328,
"VivianBala" : 37,
"mozilla" : 37,
"mariobehling" : 33,
"hpdang" : 29,
" " : 22,
"bunniestudios" : 22,
"janjongboom" : 21,
"harishpillay" : 20,
"gen" : 19
}
}
}


Service type creation fix, changed to use correct type and port

Signed-off-by: Marco Yeung<EMAIL_ADDRESS>

Showing you personal email address : Marco Yeung<EMAIL_ADDRESS>

Can just push -f, don't need to close


Get icon bug

不能获取某些图标，并且也不会生成字母图标，而是返回 Failed to fetch the icon，这种情况应该返回字母图标才对？
例如：https://favicon.153224.xyz/favicon/hot.amjun.com.png

The path here has obvious errors, I'm not sure if it's related

不能获取某些图标，并且也不会生成字母图标，而是返回 Failed to fetch the icon，这种情况应该返回字母图标才对？
例如：https://favicon.153224.xyz/favicon/hot.amjun.com.png

relative path issues:
<link rel="icon" href="ico/favicon.png" />

https://f7adc314.favicon-3j1.pages.dev/favicon/hot.amjun.com

The path here has obvious errors, I'm not sure if it's related

Img src is OK, use the new version

The path here has obvious errors, I'm not sure if it's related

Regular Packaging and Deployment
https://github.com/seadfeng/favicon-downloader/actions/runs/10716944191

Okay, thank you. I just realized that I forgot to translate it. Sorry


Bump allocator version of expression evaluation

The expression evaluation is pretty heavy on the garbage collection so I am exploring Bumper.jl. Initial tests show that you do get a massive (50% or higher) speedup from this, even for simpler equations.
It is possible for us to figure out total number of allocations in advance, so I wonder how much we can gain from using a fixed-size buffer here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.7%) to 91.558%

Totals

Change from base Build<PHONE_NUMBER>:
-2.7%

Covered Lines:
1475

Relevant Lines:
1611

💛  - Coveralls


Enhancement to top menu

The top pour over and espresso menu is kind of ugly. It should be redesigned.
Also hide it if someone disables espresso or pour over views

This will be in the next build


Dselans/node selection

WIP

Turns out it wasn't very easy.
I would really love to see the performCheckDistribution method be refactored at some point in the future.. As of right now, it would probably be quite difficult to test that thing.
Nevertheless, the functionality is there; docs updated, etc.


Fix #6158

Terminal escape sequences are only set if standard output (file descriptor 1) and standard error (file descriptor 2) are both associated with a terminal.

Can one of the admins verify this patch? (see README)

Awesome, that was quick!

Thanks


CNV-40099: Force stop terminating

📝 Description
Replacing stop with force stop when stuck on terminating status of VM
🎥 Demo

Please add a video or an image of the behavior/changes

/retest

/retest

/retest


building on #7 from the solid work by @scheibling

In this update, there is an added feature that works as follows:
When an array of values is provided for a particular field, an $in search is constructed for Mongo:
?filter[fn]=1,2,3,4
{
  "fn": {
    "$in": [1, 2, 3 ,4]
  }
}

When expressions / operators are provided on a list of values, an $and search is created instead:
?filter[fn]=>=1,<5,!=3
{
  "$and": [
    {
      "fn": {
        "$gte": 1
      }
    },
    {
      "fn": {
        "$lt": 5
      }
    },
    {
      "fn": {
        "$ne": 3
      }
    },
  ]
}

One open element to consider here... if a mixed array is provided (i.e. ?filter[fn]=>=1,<5,3,4) the values with no expressions are simply ignored:
{
  "$and": [
    {
      "fn": {
        "$gte": 1
      }
    },
    {
      "fn": {
        "$lt": 5
      }
    }
  ]
}

Question: is this desirable behavior? Should the additional values interpreted and applied to an additional $in within the outer $and clause?

That looks a bit more sanely implemented than my solution indeed, great job!
I did come up with one more alternative path over the last few days, and it's relating to the case of wanting to chain conditions for multiple different fields. One solution would be to slightly modify this solution and use the following for "and"-clauses (but leave the "or"-clauses with the existing syntax):
?filter=[price]>=100,[price]<=1000,[category]=!lamps
The above would likely need some changes to the underlying parser as well though, and optics-wise I'm not entirely happy with that syntax...
Another would be to leave this PR as-is, and introduce a "join"-option (which is likely a slightly smaller change comparatively, as we'd just need to surround all the existing clauess with a $and: { })  when all the other parts are parsed and added to the query.

Doing some more cross application testing at the moment and will verify all things work as expected before merge and preparation for release!


Should we prevent Ionide to load files under .fable folder

I am opening this here because I don't think there is a benefit to parsing/loading these projects in Ionide/FSAC but I can be wrong.
cc @alfonsogarciacaro
If we add this feature, I propose to make it configurable via a setting.
IMO it's like for projects under paket-files, packages I don't think there is a benefit to loading them but I can be wrong of course :)

What’s .fable folder? And aren’t most people using sln files anyway? In such case Ionide loads the projects only from sln file.

I personally don't use sln I hate this file format. :)
What's the benefit of using sln ?

Help people who used VS to open our project ?
Useful if you have several fsproj but what if you have only one ?

What is .fable folder ?

Quoting @alfonsogarciacaro from another issue:

Fable 2 is copying files from nuget packages in a local .fable folder to avoid the problem we had before that some dependencies couldn't be resolved unless users were very careful in their webpack configuration

I think it's good to use the solution file as Ionided does now, but it'd be also good too to keep in mind repos that don't have one. Paket added the .fable folder as an exception (together with node_modules, etc) but it may be a good idea to just ignore all folders starting with . as that's the standard way to hide a directory in unix.

Or maybe use the .gitignore rules (not sure how difficult this is). The .fable folder includes a .gitignore file by default.

We have FSharp.excludeProjectDirectories which does exactly what you want, all we need is to add .fable to default values. PRs welcomed ;-)

Thanks!

We added ".fable" to excludeProjectDirectories #916 but I still get fail messages from projects in the .fable folder, any idea?

I can't reproduce that one...

I doesn't happen all the time, it seems to be related to using Fable development version in another directory (e.g. running dotnet run -p ../Fable/src/dotnet/Fable.Compiler) as if that somehow widened but I don't understand why the processes should be related. I just mentioned in case it ringed a bell. Let's see if I can find the conditions to reproduce and report again.


⚠ API (search) has degraded performance

In 78e61c9, API (search) (https://api.dev.package-search.services.jetbrains.com/search-packages) experienced degraded performance:

HTTP code: 200
Response time: 7787 ms

Resolved: API (search) performance has improved in fd93d63 after 15 minutes.


Adding tests

Merging. This looks good and puts the number of tests up to 148. Cool! My test run time went from 1.8s to 15.s, but still fast.


add client and client_url to pagerduty incidents

These values are used in the PagerDuty API and are currently null for events triggered via the Sentry integration. Sends client as sentry and client_url as the sentry url for the triggering issue.

Should client_url actually be the event's URL or just a reference to e.g. the sentry install?

The PagerDuty API doesn't currently expose the full set of custom details that are sent by the triggering integration, so it would be really helpful to have a link to the sentry issue in the PagerDuty webhook. The PD documentation describes the client_url as "The URL of the monitoring client that is triggering this event", so I think the issue url is a valid choice.

Seems reasonable, especially if there's not a more appropriate workaround. Thanks!


Update fr.json

Please send your pull requests the develop branch.
Don't forget to add the change to CHANGELOG.md.

Note: Sometimes the development moves very fast. It is highly
recommended that you update your branch of develop before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.
Thanks!

Does the pull request solve a related issue?
If so, can you reference the issue?
What does the pull request accomplish? Use a list if needed.
If it includes major visual changes please add screenshots.

Hi, I've updated the french translation file :) Cheers
Sorry i'm total github noob, so not sure the process is fine ...

Sorry, new to this. Kind of still trying to figure everything out. What do
you mean? Can you be a little more specific?
On Apr 16, 2017 06:26, "FlaFla15"<EMAIL_ADDRESS>wrote:

Please send your pull requests the develop branch.
Don't forget to add the change to CHANGELOG.md.
Note: Sometimes the development moves very fast. It is highly
recommended that you update your branch of develop before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.
Thanks!

Does the pull request solve a related issue?
If so, can you reference the issue?
What does the pull request accomplish? Use a list if needed.
If it includes major visual changes please add screenshots.

You can view, comment on, or merge this pull request online at:
https://github.com/MichMich/MagicMirror/pull/855
Commit Summary

Update fr.json

File Changes

M translations/fr.json
https://github.com/MichMich/MagicMirror/pull/855/files#diff-0 (7)

Patch Links:

https://github.com/MichMich/MagicMirror/pull/855.patch
https://github.com/MichMich/MagicMirror/pull/855.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MichMich/MagicMirror/pull/855, or mute the thread
https://github.com/notifications/unsubscribe-auth/AaT_6TJ7Wa2y181kOy0VHOrCv4dOz3K_ks5rwfrLgaJpZM4M-mpZ
.

hi  @justjim1220 justjim1220
it's an automated message =)
i was trying to update french translation.


Definition for rule 'react/jsx-no-duplicate-props' was not found

Bump semistandard version to 7.0.5, which contains fix for this issue

Why was the version locked down in https://github.com/ricardofbarros/linter-js-standard/commit/762992e62f21e66e2be3478b814cbd03494ac90d? Would have fixed itself by trusting SEMVER.

Hey @oaleynik , thanks to @devTristan PR contribution, this issue is fixed in a proper way instead of a simple dependency update. From now this package will try to use the local standard (project's node_modules/) instead of the bin inside it.

One way or other - thanks for finally fixing it!


26 implement simple star columns masking

changed the admin.rego and mask.rego files
added column star masking, as well as string hash masking

You need to address in your code like you are comunicate with the abac_am for getting the attributes


Feature/slim 3083 response retrieval

Smart metering will first make a call to get the response and afterwards a second call to delete the response data.
For this call we added a seperate wsdl SmartMeteringCommon.wsdl with the deleteResponseData method

https://ci.opensmartgridplatform.org/view/Nightly/job/OSGP_open-smart-grid-platform_nightly/

https://ci.opensmartgridplatform.org/view/Nightly/job/OSGP_open-smart-grid-platform_nightly/1297/

https://ci.opensmartgridplatform.org/view/Nightly/job/OSGP_open-smart-grid-platform_nightly/1298/

I made a new PR to support the DCO requirement, for signed commits:
https://github.com/OSGP/open-smart-grid-platform/pull/690


add Internal Changes section to CHANGELOG

Currently we have changed, added, removed and fixed sections in the changelog. These sections written for the perspective of users/devs to show them latest changes on core. Such these updates result some changes on core's behavior.
To document some internal changes that doesn't directly interest users but might interest contributors and doesn't change program's behavior, we can add an internal changes section and put them all there.
Example lines for internal changes:

(#x) pubsub.Unsubscribe() added (this feature added to make a fix possible)
(#y) refactor on container package, Container type introduced (internal improvements)
(#y) integration tests has their own build tags, run them with  go test -tag=integration (internal improvements)

if this proposal survives add logs about https://github.com/mesg-foundation/core/pull/340 to internal changes section


A little improvement / bug fixing for "Module pattern"

@okadurin  can you actually edit it in https://raw.githubusercontent.com/Kottans/js-slides/gh-pages/modules/index.md & run cleaver ?


Plugin not working with last version

Hi, I installed the new version and the plugin did not work, could you check it?
Thank's and congrats for the plugin I could not live without it
Eduard

It's works for me. Change version to 5.3.0 in package.json and run npm install

Hi
We did as you mention and did not work. Kibana crash!!! No data
Any idea why?
Thanks
Eduard

El 6 abr 2017, a las 15:04, Tony Koval<EMAIL_ADDRESS>escribió:
It's works for me. Change version to 5.3.0 in package.json and run npm install
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Can you share log from Kibana?

Hi Tony,
Se below the log, but seams nothing is wrong. But when we install the
plugin kibana did not show nothing, you have to uninstall the plugin to see
the data again.
I really love your plugin and I want to have up again, let's see if we
found the mistake.
Thank's and congratulations
Eduard
elastic@speakingsensors:/usr/share/kibana$ sudo bin/kibana
log   [19:46:03.948] [info][optimize] Optimizing and caching bundles for
graph, monitoring, kibana, timelion, login, logout and status_page. This
may take a few minutes
log   [19:47:22.317] [info][optimize] Optimization of bundles for graph,
monitoring, kibana, timelion, login, logout and status_page complete in
78.36 seconds
log   [19:47:22.354]<EMAIL_ADDRESS>Status changed
from uninitialized to green - Ready
log   [19:47:22.400]<EMAIL_ADDRESS>Status
changed from uninitialized to yellow - Waiting for Elasticsearch
log   [19:47:22.414]<EMAIL_ADDRESS>Status
changed from uninitialized to yellow - Waiting for Elasticsearch
log   [19:47:22.434]<EMAIL_ADDRESS>Status changed
from uninitialized to yellow - Waiting for Elasticsearch
log   [19:47:22.446]<EMAIL_ADDRESS>Status
changed from uninitialized to green - Ready
log   [19:47:22.448] [warning][reporting] Generating a random key for
xpack.reporting.encryptionKey. To prevent pending reports from failing on
restart, please set xpack.reporting.encryptionKey in kibana.yml
log   [19:47:22.450]<EMAIL_ADDRESS>Status
changed from uninitialized to yellow - Waiting for Elasticsearch
log   [19:47:22.470]<EMAIL_ADDRESS>Status
changed from yellow to green - Kibana index ready
log   [19:47:22.474]<EMAIL_ADDRESS>Status changed
from uninitialized to yellow - Waiting for Elasticsearch
log   [19:47:22.475] [warning][security] Generating a random key for
xpack.security.encryptionKey. To prevent sessions from being invalidated on
restart, please set xpack.security.encryptionKey in kibana.yml
log   [19:47:22.477] [warning][security] Session cookies will be
transmitted over insecure connections. This is not recommended.
log   [19:47:22.522] [info][license][xpack] Imported license information
from Elasticsearch: mode: trial | status: active | expiry date:
2017-05-01T13:38:04+02:00
log   [19:47:22.531]<EMAIL_ADDRESS>Status
changed from green to yellow - Waiting for Monitoring Health Check
log   [19:47:22.532]<EMAIL_ADDRESS>Status
changed from yellow to green - Ready
log   [19:47:22.532]<EMAIL_ADDRESS>Status changed
from yellow to green - Ready
log   [19:47:22.533]<EMAIL_ADDRESS>Status
changed from yellow to green - Ready
log   [19:47:22.534]<EMAIL_ADDRESS>Status changed
from yellow to green - Ready
log   [19:47:22.537]<EMAIL_ADDRESS>Status
changed from uninitialized to green - Ready
log   [19:47:22.548]<EMAIL_ADDRESS>Status changed
from uninitialized to green - Ready
log   [19:47:22.561]<EMAIL_ADDRESS>Status
changed from yellow to green - Ready
log   [19:47:22.624]<EMAIL_ADDRESS>Status changed
from uninitialized to green - Ready
log   [19:47:22.743]<EMAIL_ADDRESS>Status changed
from uninitialized to green - Ready
log   [19:47:22.746] [info][listening] Server running at
http://<IP_ADDRESS>:5601
log   [19:47:22.747] [info][status][ui settings] Status changed from
uninitialized to green - Ready
2017-04-11 13:06 GMT+02:00 Tony Koval<EMAIL_ADDRESS>
Can you share log from Kibana?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mstoyano/kbn_c3js_vis/issues/16#issuecomment-293224518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALhduNcOgU-7S6QKvQKd7hnZhjqaxRlPks5ru17HgaJpZM4M0h5y
.

I dont see the problem in logs. How do you install plugin? Try this steps:
$ stop kibana
$ cd KIBANA_HOME/plugins
$ git clone https://github.com/mstoyano/kbn_c3js_vis.git c3_charts
$ cd c3_charts
$ vim package.json (change version to 5.3.0)
$ npm install
$ run kibana

Hi Tony,
Yes we did the same steps to install the plug in
any idea?
thank's for your help
2017-04-12 9:40 GMT+02:00 Tony Koval<EMAIL_ADDRESS>
I dont see the problem in logs. How do you install plugin? Try this steps:
$ stop kibana
$ cd KIBANA_HOME/plugins
$ git clone https://github.com/mstoyano/kbn_c3js_vis.git c3_charts
$ cd c3_charts
$ vim package.json (change version to 5.3.0)
$ npm install
$ run kibana
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mstoyano/kbn_c3js_vis/issues/16#issuecomment-293499192,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALhduMmIES7e6B_l9U8NV6A3zczQEO8Wks5rvIAHgaJpZM4M0h5y
.

Try unpack this to plugins. This version works for Kibana 5.3.0
kbn_c3js_vis.zip

Hi Tony,
Unpacking directly works perfect! by the way,  is it possible to do a 2
axes graph?
Thank you and congrats for your excellent work
Eduard
2017-04-12 10:15 GMT+02:00 Tony Koval<EMAIL_ADDRESS>
Try unpack this to plugins. This version works for Kibana 5.3.0
kbn_c3js_vis.zip
https://github.com/mstoyano/kbn_c3js_vis/files/915844/kbn_c3js_vis.zip
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mstoyano/kbn_c3js_vis/issues/16#issuecomment-293506372,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALhduN5Ccf_XgvHkSNmgv4fZutySgzgsks5rvIgNgaJpZM4M0h5y
.

Hi
I am trying to install this plugin on Kibana 5.4.0 Ubuntu , the plugin is getting installed but i am not seeing it .
Could you please let me know the steps , i already tried the above mentioned steps
Thanks


Renamed VerifyFileTest class  to exclude it from TestSuite run as it depends on deleted resource

Renamed TestFile VerifyFileTest to VerifyFileTestDisabled to exclude it from TestSuite run as it is dependent on resource foo.jks deleted during Apache Code Donation . We can't comment out only the failing test methods as test class should have at least one test method and in this case all test methods have issues.

Makes sense and am merging this.


python link

onwards and upwards for this / terminals need more pictures.

Hey! Thanks for the PR.
This project is completely unaffliated with the imgcat pypi package. In fact, it seems to be a completely different Python implementation, with its own CLI. As such, I will not be adding the link to this README.
That means there are at least THREE different, unaffiliated projects, all called imgcat:

iTerm2's imgcat script
python-imgcat
this project

“The secret of freedom lies in educating people, whereas the secret of tyranny is in keeping them ignorant.”


Adds validating permissions in entra app permission remove. Closes #6109

Adds validating permissions in entra app permission remove. Closes #6109

Merged manually


Typings

Added typescript typings.

Is it necessary for TypeScript development?

It is possible to use a module without typings in Typescript when --allowJs compiler option is present, but ts compiler is unable to infer types from js and exported values will have an any type in this case. So typings is not something 100% necessary but very nice to have feature.


Count Complete Tree Nodes in JAVA

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
Count Complete Tree Nodes in JAVA
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
#7494

@ankitaggarwal23 Sir, plz review my PR and let me know if any changes are required.


Update USPS Informed Delivery email address

Breaking change

Proposed change

Simple update to fix informed delivery email address.  This likely is a universal change, but I'll tweak this to allow both addresses for now in case i'm wrong.
Type of change

[ ] Dependency upgrade
[X] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #244
This PR is related to issue:

Oops, must have missed something else in the code as two addresses causes the component not to load.  Single address works fine and loads the images.

Done.