Moc files are not generated when build

sorry for disturbing you.
I encounter some issues when using premake-qt
there is my premake script:
require("cmake/cmake")
require("QTModules/qt")

local qt=premake.extensions.qt

qt.enable()

solution "testQtGenerate"
    configurations {"Debug","Release"}
    project "TestQt"
        language "C++"
        kind "ConsoleApp"
        cppdialect "c++17"
        files{"*.hpp","*.cpp"}
        location ("./testQt")
        symbols "ON"
        optimize "Off"
        architecture "x86_64"
        qt.enable()
        qtsuffix "d"
        qtmodules { "core", "gui", "widgets", "opengl" }
        qtprefix "Qt5"
        qtgenerateddir("QTMoc")
        optimize "Off"
        staticruntime "off"

and there is my c++ file which needs to generate a moc file:
#include <QtWidgets/qwidget.h>

class TestMoc:public QWidget{
    Q_OBJECT
public:
    TestMoc(QWidget* parent): QWidget(parent){
        this->setGeometry(0,0,200,200);
    }
    ~TestMoc(){};
};

I plan to use the CMake module of premake to generate CMakeLists.txt.
when I run "premake5 cmake" , it runs succeeded
but next, when I run cmake -B Build, the cmake report does not find QtMoc moc_XXXX.h error.
and I find the QtMoc folder does not have anything(or it means that the moc files are not generated)
I don't know whether I use premake-qt in the wrong way or should I change my premake script?

Hi,
This type of error usually happen if the generator doesn't support custom commands. I think that this is a problem coming from this cmake/cmake addon that you seem to be using.
Try to use a custom command in your project, and check if the generated CMake file contains that command. If it doesn't, I suggest to open an issue on the cmake addon page, because I can't do anything. And if it does contain the custom command, it might be some bug in my addon, in which case I will need the link to that cmake addon, in order to reproduce the issue.

Hi, thanks for the update, so it indeed was an issue with the cmake addon :)
I'm closing this issue then. For the problems with gmake2 action, there's the specific issue (still opened unfortunately, I wish I had more time T_T) and if you have any other issue with other actions, feel free to open issues for those.
Regards,
Damien.


ci: Add more Matrix tests shards

An experiment

this looks nice!

this looks nice!

👍🏻 I was going to test more matrix sizes but the results are so variable… the two runs at this size did all have shorter longest run times, so let’s just go ahead with it 😆


area-details-page

Create the area-specific page when clicking on an area in areas. Check figma and prototype for flow.
When doing the styling for this page, please make the CSS file a .module.css file extension rather than just .css. This will prevent your code from importing all CSS classes in the project repo. You can read more about this here
https://www.figma.com/file/O2igPzMS1fZPzjmOxlo6Mc/TLP-Wireframes?node-id=538%3A23322

closes #53

The routes on index.jsx have been changed (on dev) so can you merge dev into the branch and then update your rotes. Can you connect the "view site" button on area management to your area details page. Also, the designs have been changed slightly on figma, can you check in with Meredith about that (your current design is a little off, ex. the notes is an icon on figma).

Trailing changes to be wrapped up in another PR (see image):

Need to implement the search filters for sites
Need to connect site info to site view page when it's created
Need to fix the Table/TableRow components so that this btn-link bootstrap style is washed off + the randomly added pencil is gone


some $-patterns shift counter {} by one character in renamed filename

Microsoft PowerToys version
0.79.0
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
PowerRename
Steps to reproduce
search: .* + enable use regex
replace: <patterns as described below>
✔ Expected Behavior
All examples for file created March 10th 2024. File is first file in batch ({}->0)
replace:  <pattern> -> <result>
replace: $YY${}ABC -> 240ABC
replace: $YYYY${}ABC -> 20240ABC
replace: $MM${}ABC -> 030ABC
replace: $MMM${}ABC -> Mar0ABC
replace: $DD${}ABC -> 100ABC
replace: $DDD${}ABC -> Sun0ABC
replace: $DDDD${}ABC -> Sunday0ABC
replace: $YY$MM$DD${}ABC -> 2403100ABC
❌ Actual Behavior
for each of the named $ pattern the counter is shifted back by one character.
replace: $YY${}ABC -> 24A0BC
replace: $YYYY${}ABC -> 2024A0BC
replace: $MM${}ABC -> 03A0BC
replace: $MMM${}ABC -> MarA0BC
replace: $DD${}ABC -> 10A0BC
replace: $DDD${}ABC -> SunA0BC
replace: $DDDD${}ABC -> Sunda0yABC
replace: $YY$MM$DD${}ABC -> 240310ABC0
Other Software
No response

Hm, that's not good.  This might help understand the situation a bit better. (File names, settings, etc)

sure.

@yuyoyuppe you worked on the counter code, right? We've seen a couple of similar issues (so this might be a duplicate) and there is/are a significant problem when using both the $date and the $counter variables. This is important to pick up.

you're correct, thanks, I'll take a look!


DataTriggerBehavior fails to set a property

I'm submitting a...

Bug report

Current behavior
The following code does not work :

<Image Grid.Column="0" HorizontalAlignment="Center" VerticalAlignment="Center" Stretch="None">
	<i:Interaction.Behaviors>
		<ic:DataTriggerBehavior Binding="{Binding Discovered}" Value="false">
			<ic:ChangePropertyAction PropertyName="Source" Value="/Assets/Images/icon_mount.png"/>
		</ic:DataTriggerBehavior>
		<ic:DataTriggerBehavior Binding="{Binding Discovered}" Value="true">
			<ic:ChangePropertyAction PropertyName="Source" Value="/Assets/Images/icon_mount_available.png"/>
		</ic:DataTriggerBehavior>
	</i:Interaction.Behaviors>
</Image>

See the full repro: https://github.com/pdecostervgls/Uno-DataTriggerBehaviorImageSourceRepro
Environment

Nuget Package: 1.43.1
Package Version(s):

Affected platform(s):
- [ ] iOS
- [ ] Android
- [ ] WebAssembly
- [ ] Windows
- [ ] Build tasks

Visual Studio
- [ ] 2017 (version: )
- [ ] 2017 Preview (version: )
- [ ] for Mac (version: )

Relevant plugins
- [ ] Resharper (version: )

This is a limitation of the current Uno.Microsoft.Xaml.Behaviors.Uwp.Managed package, which will be updated soon to support this case properly. It was disabled at the time of the build because the XamlReader type was not supported by Uno.
As a workaround, instead of:
<ic:ChangePropertyAction PropertyName="Source" Value="/Assets/Images/icon_mount.png"/>

Use :
<ic:ChangePropertyAction PropertyName="Source"  TargetObject="{Binding ElementName=image}">
    <ic:ChangePropertyAction.Value>
        <BitmapImage UriSource="/Assets/checkbox_unchecked.png"/>
    </ic:ChangePropertyAction.Value>
</ic:ChangePropertyAction>

@jeromelaban Thanks for the workaround and fix.


Connect styles to index.html file

Attach the styles by adding the <link rel="stylesheet" href="styles.css"> line inside the  section.

In order for the styles to start displaying in the index.hnml file, they must be added to the <head></head> section

Thanks for the answer!


refactor(reactivity): flip unnecessary if-else

Thanks for the PR, however if/else is easier to comprehend compared to early return.


How to show custom splash screen?

Documentation says how to create custom splash screen, but not how to show it
https://flutter.dev/docs/development/add-to-app/android/add-splash-screen#creating-a-custom-splashscreen
What I need exactly - is to show splash screen, based on OS dark mode enabled or not
I just need to know, how to achieve the splash effect, like Instagram or Whatsapp, for example, have, where background has main system color

you need to do it native side you can achieve splash screen files under your projects android folder.

@Ejdersoy thanks, captain obvious

Hi @nt4f04uNd
@Ejdersoy is correct,
for now is necessary to complete the implementation
of the splash screen on the native side of the app.
Please see https://flutter.dev/community for resources for asking questions like this,
you may also get some help if you post it on Stack Overflow.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you


[Bug Report] There are gaps between checkbox buttons when using checkbox group

Element UI version
1.4.3
OS/Browsers version
WIN7 / All Browser
Vue version
2.4.2
Reproduction Link
https://jsfiddle.net/pj71jkyw/509/
Steps to reproduce

not use v-for to create checkbox button
gaps appear

What is Expected?
no gaps between buttons
What is actually happening?
gaps between buttons

For now you can add font-size: 0: https://jsfiddle.net/pj71jkyw/510/ . I'll add it to the CheckboxGroup style later.


Added parent CSS class to component to prevent CSS infection

This should at least alleviate #25, I'm not entirely sure if this fixes the whole issue but I'd be willing to adjust it or have changes made if there were suggestions. But as is, this css isn't scoped and as #25 mentions affects the entire site.
It seems to work when I serve it at least, and in our own site where we use this library, but if there's more stringent testing I can do feel free to let me know.

Nice. Thanks for adding.
I'd love to have automated tests on this project. But without it, I will run some manual regression on this, and then get it merged.


deps: Bump actions/checkout -> v3 (dependabot + fixes)

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Odd that the android_build and child jobs never started?

/retest

Actually it looks like there's a mistake in the yaml configs:

Invalid workflow file: .github/workflows/ios_build.yml#L21
The workflow is not valid. .github/workflows/ios_build.yml (Line: 21, Col: 7): Unexpected value 'fetch-depth' .github/workflows/ios_build.yml (Line: 47, Col: 7): Unexpected value 'fetch-depth'

could be me force pushing - i can look further if its blocking it somehow

Actually it looks like there's a mistake in the yaml configs:

ah that would explain it - let me update ...

hmm - wierd - im not seeing the error - its seems correct https://github.com/actions/checkout#usage and is working everywhere else

merged main altho dont see any reason it would merge badly - lets see

It seems to only be happening on macOS, the Linux jobs are running fine.

Invalid workflow file: .github/workflows/android_build.yml#L21
The workflow is not valid. .github/workflows/android_build.yml (Line: 21, Col: 7): Unexpected value 'fetch-depth' .github/workflows/android_build.yml (Line: 53, Col: 7): Unexpected value 'fetch-depth'

https://github.com/envoyproxy/envoy/actions/runs/4164747882

nm - i think it needs a with not sure why it does/not work - but ill update with correct syntax ...

I see this is now done automatically:

Adding repository directory to the temporary git global config as a safe directory
/usr/local/bin/git config --global --add safe.directory /Users/runner/work/envoy/envoy

So can we remove the explicit steps that do that in our workflow configs?

So can we remove the explicit steps that do that in our workflow configs?

yep - i was intending to follow up with that

@jpsim would you prefer if i just added that here ?

Yes can you please do that here? The time to cut that out should be offset by not having the overhead of creating/reviewing/waiting for CI on a new PR.

can we just revert this and land the action update ?

Yes of course.

argh - that still failed - reverted!


feat(deps): update template dependencies

BREAKING CHANGE:
loopback and sourceloop versions update
Description
Update template dependencies
Fixes #2045
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Intermediate change (work in progress)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] Performed a self-review of my own code
[x] npm test passes on your machine
[ ] New tests added or existing tests modified to cover all changes
[ ] Code conforms with the style guide
[ ] API Documentation in code was updated
[ ] Any dependent changes have been merged and published in downstream modules

@arpit1503khanna  please resolve the conflicts


Support metrics generation

We should add the ability for lading to produce metric style events to unblock additional soak test configurations. Depending on the metrics and "flavor" of metrics this may be a new generator or a new variant of existing generators.
We'll likely want to create separate tickets for the metric formats and flavors we want to include in lading

Seems straightforward to do as a payload, defined here. Then we'd just need to expand the payloads supported by whatever generator. Possibly relates to #55.


Set region to unknown on startup

This sets the current/default region  to a new “UNKNOWN” region to avoid invalid uplink packet reports, region parameters (and thus invalid downlinks) when the gateway can’t or has not received it’s asserted region from the config service yet.
It avoids sending packets with Unknown region information to the packet router since they can't really be responded to or handled.
A Maker can set the region to a known value at startup by using the GW_REGION environment variable. This may be useful for data only hotspots or to get faster initial uplinks at startup.
Fixes: #408

@ke6jjj only caveat to #408 is that the unknown region is printed as "UNKNOWN" instead of null. E.g.
{
  "region": "UNKNOWN"
}

That ok?

@ke6jjj only caveat to #408 is that the unknown region is printed as "UNKNOWN" instead of null. E.g.

Well, unfortunately no. The idea is to return a proper null for the API in question. For JSON that really would be null. We're looking for something consistent that Makers can program to.

@ke6jjj only caveat to #408 is that the unknown region is printed as "UNKNOWN" instead of null. E.g.

Well, unfortunately no. The idea is to return a proper null for the API in question. For JSON that really would be null. We're looking for something consistent that Makers can program to.

Fixed


Get-SqlInstance should be an array even if it returns only one element

I've add @ before all (Get-SqlInstance).ForEach
It resolves #340, #327

Darn, I was hoping to avoid having to do this on every test with this:
https://github.com/sqlcollaborative/dbachecks/blob/master/internal/functions/Get-SqlInstance.ps1#L11
Any idea why this didn't work? We can update the template and merge this PR as well, but was looking for a sleeker solution.

Could we specify the outputtype as an array? Would that do it?

ohhh! that sounds like a nice potential. will look into it

I am worried about leaving this open too long as the merge will become very conflicted.

It's been conflicted for a while, unfortunately. I would actually like to rewrite Get-Sqlinstance and Get-ComputerName real quick instead. Let's try that, brb

So sorry, @michalporeba - I was trying to figure this out w/o having to modify the easy-ish to read template. If #365 doesn't work, I'll update all of these myself. Thank you for your work!


TST: Test logbook

Not to be confused with Python logging
This does not actually use the olog, but it checks that a
correct message is passed to the handler that is normally
plugged into the olog.

@tacaswell ready to merge


Aug 18th 2020 - Currency Ref Data Meeting Minutes

Currency Reference Data Meeting
Date
Aug 18th 2020 - 10am EST / 3pm BST
Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Agenda

[ ] Convene & roll call (5mins)
[ ] Approve July 7th, July 21st and August 4th CurRef Meeting minutes
[ ] AOB, Q&A & Adjourn (5mins)

Decisions Made

[ ] Decision 1
[ ] Decision 2
[ ] ...

Action Items

[ ] Action 1
[ ] Action 2
[ ] ...

WebEx info

WebEx Meeting URL
Meeting Number:<PHONE_NUMBER>
Join by phone: +1.415.655.0003 USA Toll | +44-20319-88141 UK Toll | Access code:<PHONE_NUMBER>
Password: VXcd2eQgh82
Global call-in numbers

Hi!

Present

hi

hi

Here
On Tue, Aug 18, 2020 at 10:25 AM RichardWagener365<EMAIL_ADDRESS>wrote:

hi
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/finos/secref-data/issues/23#issuecomment-675510049,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI5OALWVIEZJ3O74JU3XRNTSBKFMBANCNFSM4PUXWGGQ
.

--
http://cruxinformatics.com/
Philip Brittan
CEO
+1.718.404.4614
cruxinformatics.com https://www.cruxinformatics.com/
--
The information contained in this communication is confidential and is
intended only for the use of the addressee. It is the property of Crux
Informatics, Inc., www.cruxinformatics.com
http://www.cruxinformatics.com/.  Unauthorized use, disclosure or copying
of this communication or any part thereof is strictly prohibited and may be
unlawful. If you have received this communication in error, please notify
us immediately by return email or by email to<EMAIL_ADDRESS><EMAIL_ADDRESS>and destroy this communication and
all copies thereof, including all attachments.  Thank you.


Add readme to cw-contract crate

Closes: #1218
Description

PR author checklist:

[ ] Added changelog entry, using unclog.
[ ] Added tests.
[ ] Linked to GitHub issue.
[ ] Updated code comments and documentation (e.g., docs/).
[ ] Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

I added a little more context and explanation to the README.


Add classification feature selection support

Description
Adds support for feature selection algorithms via a FeatureSelector interface, a SelectedFeatureSet class to represent the output of a FeatureSelector and a SelectedFeatureDataset which applies a feature set to another dataset. It also includes implementations of 4 information theoretic feature selection algorithms (MIM, CMIM, JMI, mRMR) for classification tasks. The FeatureSelector interface is sufficiently general that we can implement it for regression, anomaly detection etc, though it does not cover operating on sequence data except via the SequenceDataset.getFlatDataset hook which flattens the sequence data into a series of independent examples. In the future we'll look at adding feature selection algorithms for regression and other output types, and before the next release we'll add a tutorial on the feature selection algorithms added in this PR.
The information theoretic algorithms bin the feature values using equal width bins to convert the real valued features into categoricals. We could add extensions to use the categorical values if the feature map believes them to be categorical, or to add other binning systems. This also densifies the dataset while it transposes it into a columnar view from Tribuo's default row view. We could use a sparse implementation of the columnar view which treats all features as binary, this has worked well in the past but the code is rather complicated so this initial version doesn't contain it.
Currently the feature selection algorithms are lightly tested to compare the parallel versions against the serial version. I've tested them offline against the implementations from FEAST which is the reference implementation I developed in grad school. I'm considering adding a generated dataset with known outputs from FEAST to compare against in the unit tests.
Motivation
Feature selection algorithms are useful for reducing the complexity of downstream prediction tasks, and for analysing the relevant features in a dataset.
Paper reference
An overview of the feature selection techniques implemented here can be found in:
Brown G, Pocock A, Zhao M-J, Lujan M.
Conditional Likelihood Maximization: a Unifying Framework for Information Theoretic Feature Selection, JMLR 2012 - PDF

It would be awesome if you make a tutorial about that, and I am planning to
creat a wrapper model for feature selection using evolutionary algorithm.
If it's okay tell me please?
On Wed, Aug 3, 2022, 12:29 AM Adam Pocock @.***> wrote:

@.**** commented on this pull request.
In Core/src/main/java/org/tribuo/evaluation/EvaluationAggregator.java
https://github.com/oracle/tribuo/pull/254#discussion_r936042824:

@@ -174,6 +174,27 @@ public static <T extends Output, R extends Evaluation> Map<MetricID, De
return results;
}

/**

* Summarize all fields of a list of evaluations produced by<EMAIL_ADDRESS>CrossValidation}.

* @param evaluations The evaluations to summarize.

* @param <T> The output type.

* @param <R> The evaluation type.

* @return The descriptive statistics for each metric.

*/

public static <T extends Output, R extends Evaluation> Map<MetricID, DescriptiveStats> summarizeCrossValidation(List<Pair<R, Model>> evaluations) {

This change is separate from the rest of them but I added it to make it
easier to aggregate across cross validation folds which is currently a
little ugly to do and it didn't feel worth a full PR.
—
Reply to this email directly, view it on GitHub
https://github.com/oracle/tribuo/pull/254#pullrequestreview-1059450196,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWGLSQ3PKJ6OLAP7XRXONLDVXGHNDANCNFSM55MTS23Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

The summarizeCrossValidation method will convert a list of evaluations from the CrossValidation class into a Map<MetricID<T>, DescriptiveStats> which gives you the mean, min, max & std deviation of each metric across the folds. You could then use that to drive an evolutionary procedure if you wanted. Alternatively, if you're asking how to implement the FeatureSelector interface for an evolutionary algorithm, then you can see how to use it in the feature selection tutorial added in this PR, but we don't have detailed docs on implementing the interface. Probably best to look at the existing implementations and open an issue if you get stuck.

Sounds well.
Cross Validation is suitable for the evaluation function when working with wrapper FS, and implementing the FS interface is a very good idea, but how about using TRIBUO to read data, evaluate the generated subsets and using TABLESAW to drop the noisy columns based on the used evolutionary algorithm and group all of that in a new module in TRIBUO library where this module can contain multiple evolutionary algorithms like Crow search, Black Hole, ...etc. the implementation will be based on stream, parallel stream, Runnable, Callable, Executor Service.
and I am sorry to bother you, Adam.

The feature selection machinery will drop the unselected features for you, that's what SelectedFeatureDataset does. So you should only need to implement the evolutionary algorithms as FeatureSelector implementations which accept a Trainer and a number of folds (and any other parameters for the evolutionary part).

sounds very good, thank you


Allow using types to disambiguate overloaded calls

[x] Owner: @vgurevich
[ ] Supporters:
[x] Design document rationale: see below
[ ] P4 spec document written
[ ] P4C compiler implementation provided:
[ ] Discussed in P4 design meeting:
[ ] Approved by LDWG
[ ] Merged into spec
[ ] Merged into compiler

The current version of the spec states the following  in section <IP_ADDRESS> (Bold is mine):

Functions and methods are the only P4 constructs that support overloading: there can exist multiple methods with the same name in the same scope. When overloading is used, the compiler must be able to disambiguate at compile-time which method or function is being called, either by the number of arguments or by the names of the arguments, when calls are specifying argument names. Argument type information is not used in disambiguating calls.

I was wondering what is the rationale behind the last statement and whether it can be changed to allow the argument type(s) to be used for disambiguation, similar how it is done in at least some languages (e.g. C++).
Here are some basic use cases:
Advanced Hash
It is desirable to be able to define hash functions based on:

Predefined formulas (e.g. CRC-32, CRC-16, etc.)
CRC, based on an arbitrary polynomial, represented as CrcPolynomial() extern
Using a raw linear code generator matrix, represented as LcgMatrix() extern
Using a string with some formula, represented as a string
etc.

The obvious solution would be to overload the constructor, e.g.
enum HashAlgorithm_t {
    IDENTITY,
    RANDOM,
    CRC8,
    CRC16,
    CRC32,
    CRC64,
}

extern Hash<W> {
    Hash(HashAlgorithm_t algo);
    Hash(HashAlgorithm_t algo, CRCPolynomial<_> poly);
    Hash(HashAlgorith_t algo, LcgMatrix<_> matrix);
    Hash(HashAlgorith_t algo, string formula);

    W get<D>(in D data);
}

This does not work, however, because the compiler cannot disambiguate between these constructors and reports errors like this:
sample_arch.p4(497): [--Werror=duplicate] error: Ambiguous method Hash
extern Hash<W> {
       ^^^^
sample_arch.p4(505): [--Werror=duplicate] error: Candidate is Hash
    Hash(CRCPolynomial<_> poly);
    ^^^^
sample_arch.p4(506): [--Werror=duplicate] error: Candidate is Hash
    Hash( LCGMatrix<_> matrix);
    ^^^^
sample_prog.p4(115): [--Werror=type-error] error: hash: type Hash has no matching constructor
    Hash<bit<32>>(poly) hash;
                        ^^^^^

Note that the problems start during the architecture file processing, so even if the programmer later uses the argument names for disambiguation, things still look unpleasant.
For now there is a workaround that allows us to have two choices (predefined or custom CRC polynomial, but there is no good way to extend that:
enum HashAlgorithm_t {
    IDENTITY,
    RANDOM,
    CRC8,
    CRC16,
    CRC32,
    CRC64,
    CUSTOM_POLY,
    // CUSTOM_MATRIX, CUSTOM_FORMULA  -- of no use
}

extern Hash<W> {
    Hash(HashAlgorithm_t algo);    /* algo MUST be anything but CUSTOM_* */
    Hash(HashAlgorithm_t algo, CRCPolynomial<_> poly);  /* algo MUST be HashAlgorith_t.CUSTOM_POLY */

    /* But these still can't be added :( */
    // Hash(HashAlgorithm_t algo, LcgMatrix<_> matrix);    /* algo MUST be HashAlgorith_t.CUSTOM_MATRIX */
    // Hash(HashAlgorithm_t algo, string formula);         /* algo MUST be HashAlgorith_t.CUSTOM_FORMULA */

    W get<D>(in D data);
}

Advanced Meter Externs
There is a need to have Meter externs with some extra parameters that reflect architecture capabilities, e.g.
extern Meter<I> {
    Meter(bit<32> size, MeterType_t type);

    bit<8> execute(in I index, in MeterColor_t color, @optional in bit<32> adjust_byte_count);
    bit<8> execute(in I index, @optional in bit<32> adjust_byte_count);
}

Here the problem is that the compiler cannot figure out whether an execute() with two parameters represents the first or the second variant of the method, again, because the type is not used.
Proposal
The proposal is to allow argument type information to be used for disambiguation.

You are not showing the complete example that gave these errors.
The solution is have indeed constructor with different argument types, but also with different argument names, and to invoke the constructor explicitly indicating the argument name:
Hash(poly = blah) x;

@mbudiu-vmw -- I was quickly checking using the existing arch, but I can construct the minimal example.
As I pointed out, the problem is that the compiler does not like the arch itself.
Also, forcing the user to always use the argument name is not nice -- the computer is fully capable figuring this out and that's what people expect.

The architecture you submitted looks fine, the compiler should accept it. If it doesn't there's a bug.
Using types for disambiguation would not be a trivial change in the compiler.

The main question is how much type information we want to use.  I don't think we need anything as complex as C++ with its priority classes and whatnot.  Perhaps just say the types are used to eliminate methods that cannot match (no conversion is possible from the argument type to the parameter type), but if there is more than one that could match (with any possible implicit conversions -- we don't have too many) then the result is ambiguous.

@mbudiu-vmw -- as you can see in the original submission, error messages are displayed against the statements in the arch file first. Let me try to create a minimal example to aid the discussion.

@vgurevich : you are only showing the code for the workaround, but not the original code.
Supplying an argument name is not that onerous, but I agree types could be simpler.
The solution with argument names is less ambiguous in the presence of implicit casts.

@mbudiu-vmw -- attached is a basic example issue884.p4.txt that uses a fake architecture. Note, that even specifying the names of the arguments explicitly doesn't help.

The problem in this issue is not the overloading -- it's the missing W type parameter in the Hash constructor calls, which can't be inferred from the arguments.  If you add them, it also complains about the missing type params to LCGMatrix (which it should be able to infer), and that string literals are not compile time constants...

The problem in your example is not with the argument types, but with the type arguments of the generic. These cannot be inferred by the compiler. If you fill them in it compiles fine. (There still one extra problem with the strings, which the compiler does not recognize as compile-time constants, but that looks like a different bug.)

control Ingress(inout headers_t hdr, inout meta_t meta)
{
    Hash<bit<32>>(algo=HashAlgorithm_t.CRC32)       hash1;
    Hash<bit<32>>(poly=CRCPolynomial<bit<32>>(coeff=0x107))  hash2;
    LCGMatrix<bit<8>, bit<10>>(8w4, 10w7,
        "1000100
         0100011
         0010110
         0001001") hamming;
    Hash<bit<32>>(matrix=hamming) hash3;
    Hash<bit<32>>(formula="magic_formula()") hash4;

    apply {
    }
}

Note that the compiler should be able to infer the type parameters to LCGMatrix from the arguments -- not sure why that is failing.  Also maybe it should infer an int type parameter to CRCPolynomial as well.

I think that we lost this ability with a recent commit. Let me try to remember why.

No, it wasn't lost, the recent commit lost the ability to infer a value of "don't care" for a type parameter which is never used.
Indeed, I expect we would infer the values of these type parameters. Could it be that we do it for functions but not constructors?
I will file two issues with the compiler.

I think it's unwise to go down the path of allowing type information to be
used in overloading until we understand precisely what the P4_16 typesystem
is.
Currently neither a specification nor an algorithm for how type checking
and inference should work is written down anywhere except in the C++
implementation.
-N
On Thu, Jul 30, 2020 at 7:39 PM Mihai Budiu<EMAIL_ADDRESS>wrote:

No, it wasn't lost, the recent commit lost the ability to infer a value of
"don't care" for a type parameter which is never used.
Indeed, I expect we would infer the values of these type parameters. Could
it be that we do it for functions but not constructors?
I will file two issues with the compiler.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/p4lang/p4-spec/issues/884#issuecomment-666775602, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOCFUVWBA6SW4T5VNKWWRDR6IADLANCNFSM4PM55VTA
.

@mbudiu-vmw -- thanks for noticing the initial problem.
Attached is the simplified example issue884_1.p4.txt. If compiled "as-is" it produces the following error messages:
$ ~/trees/org/p4c/build/p4test issue884_1.p4
issue884_1.p4(14): [--Werror=duplicate] error: Ambiguous method Hash
extern Hash<W> {
       ^^^^
issue884_1.p4(15): [--Werror=duplicate] error: Candidate is Hash
    Hash(HashAlgorithm_t algo);
    ^^^^
issue884_1.p4(16): [--Werror=duplicate] error: Candidate is Hash
    Hash(CRCPolynomial<_> poly);
    ^^^^
issue884_1.p4(38): [--Werror=type-error] error: hash1: type Hash has no matching constructor
    Hash<bit<32>>(HashAlgorithm_t.CRC32) hash1;
                                         ^^^^^
issue884_1.p4(14)
extern Hash<W> {
       ^^^^
issue884_1.p4(39): [--Werror=type-error] error: hash2: type Hash has no matching constructor
    Hash<bit<8>>(my_crc) hash2;
                         ^^^^^
issue884_1.p4(14)
extern Hash<W> {
       ^^^^

If you compile it with argument names in the constructors (with -DUSE_ARG_NAMES), it compiles cleanly.
Why is this important?
Assume that initially the Hash() extern was defined with only one constructor. As a result, in 99.9% of code out there the instantiation is done without the argument name, e.g.
Hash<bit<32>>(HashLagorith_t.CRC32) hash;

Now you want to amend the architecture and add another constructor (with CRCPolynomial). If you do it with one argument, you are going to break that 99.9% of all existing programs. They will be broken because the sheer presence of an overloaded constructor in the arch file. This will be certainly wrong.
Now, imagine that you bit the bullet and decided to define the constructors like this:
enum HashAlgoritm_t {
   ...
   CUSTOM_POLY
}

Hash<T>(Hash_Algorithm_t algo);
Hash<T>(Hash_algorithm_t algo, CrcPolynomial<_> poly);

This would preserve the backwards compatibility for a while.
Now, you want to add the hash based on Linear Code Generator Matrix. You will be stuck, since the trick of adding another enum value will not work -- the compiler will not be able to distinguish between the constructor with the polynomial anbd the matrix.
If all the code would be typically written with argument names this would not be a problem, but usually it is not.
Precisely the same situation happens with overloaded methods -- it would be less of a problem if most of the code would be written from scratch, but once you have a body of code out there, adding a new argument seems to be much more difficult than one would expect.

@jnfoster  -- I agree that it is important to define these rules. I hope it would not be as difficult compared to C++ -- our type system is a lot simpler.
Assuming that we do that (and let's figure out what is required), would you agree that it would be a useful to use types for disambiguation  of overloaded constructors/methods/functions?

Overloading is always a controversial topic. I'm not opposed to it, but there is always a danger of making things more confusing... but your example involving hash constructors is pretty compelling...

We've just hit another case, where the current rule limits us in the ability to extend an existing architecture in a backwards-compatible way. If you look at the TNA, you will see the following definition for the extern, called ActionSelector:
extern ActionSelector {
    /// Construct a selection table for a given ActionProfile.
    ActionSelector(ActionProfile action_profile,
                   Hash<_> hash,
                   SelectorMode_t mode,
                   bit<32> max_group_size,
                   bit<32> num_groups);

    /// Stateful action selector.
    ActionSelector(ActionProfile action_profile,
                   Hash<_> hash,
                   SelectorMode_t mode,
                   Register<bit<1>, _> reg,
                   bit<32> max_group_size,
                   bit<32> num_groups);
. . .

As you can see, the first (simpler) constructor takes 5 parameters and the second, more complex one takes 6.
We need to add a new, @optionalbool new_flag  parameter to both constructors, but the current rules make it impossible, because once the compiler sees a constructor with 6 parameter, it cannot figure out, whether it is the first one with the optional parameter or the second one without an optional parameter.
Obviously, one can define a new (very similar) extern (e.g. ActionSelectorWithFlag, but that defeats the purpose and, in my opinion, is not a good solution.
I do propose to change the corresponding portion of the (section <IP_ADDRESS>)[https://p4.org/p4-spec/docs/P4-16-v1.2.1.html#sec_extern] (Bold is mine):

Functions and methods are the only P4 constructs that support overloading: there can exist multiple methods with the same name in the same scope. When overloading is used, the compiler must be able to disambiguate at compile-time which method or function is being called, either by the number of arguments and their types or by the names of the arguments and their types, when calls are specifying argument names. Remove the sentence about the type info not being used

Do you have a proposal for exactly how the compiler should use types in constructor calls to determine which of several methods might be meant, in the face of @optional constructor parameters?
e.g. should a parameter with type bit<8> be matched by a call where the parameter in the corresponding position uses a value with type enum bit<8> MyEnum_t ..., or not?  What if the argument in the call is the literal -5?  What if they are two differently named struct types, but they have the same corresponding field types and names?  What if one is one of the new generic structs that is either already added to the spec, or is proposed to be added to the spec (I have forgotten whether it is in the spec or not yet), and the other is a struct that "looks the same" if you instantiate the type parameter of the generic struct so that field names and types look the same?
Merely saying "and their types" doesn't answer these questions, and the p4c implementation and spec seems like they need answers to at least some of those questions, if not all of them.

The feature being in the spec is not enough for it to be in the implementation. And usually we don't put stuff in the spec until we have an implementation.
I have resisted so far using types because the phase ordering in the compiler requires the type checker to disambiguate calls in order to check them. Given the backlog of bugs, I am not sure when I would have time to modify the type checking algorithm to accommodate this feature. If there is a volunteer to tackle this feature I certainly won't object. But this is the kind of feature where I think an implementation should certainly exist before it is officially accepted.

@mbudiu-vmw -- that's precisely why I sent the "ping". I totally agree that in this case the implementation is going to drive the spec a lot more than in many other cases. I can write a detailed algorithm, but it is not going to be very useful until we make sure that it fits into the overall implementation of the type checker.
I will certainly discuss internally if this is something we can take an initiative on, but I want to make sure the issue is understood and we agree that it is important to resolve it, because it definitely holds us back.
Obviously, workaround suggestions are welcome as well.

@jafingerhut -- I agree.
Let's try, although this probably will not be a short proposal (as we can see in C++, which is one of the examples where types do play a significant role in the overloading resolution)
First, is the case without @optional parameters and without names being specified. If two or more functions/constructors have the same number of arguments, the compiler has to disambiguate, based on the types. One interesting quirk is that we have some implicit casting rules. I would think that if there are ambiguities, then the candidate with the fewer casts wins. In other words, if you have N constructors:
     c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m);
     c(t_2_1_t a2_1, ..., t_2_m_t a_2_m);

     c(t_N_1_t, a_N_1, ..., t_N_m_t a_N_m);

and a constructor call
    c(t_1_t a1, ..., t_m_t a_m);

compiler needs to select the constructor S with the types t_S_1_t, ..., t_S_m_t that require the fewer number of casts from t1_t, ..., t_m_t. If more than one constructor can be selected that way (i.e., there are several constructors. that require the same (minimal) number of casts), a compilation error occurs.
For example:
/* Example 1 */
extern e_1 {
    e_1(bit<32> a_1_1, bit<16> a_1_2); /* A */
    e_1(bit<32> a_2_1, bit<32> a_2_2); /* B */
}

e1(32w11, 16w12) --> e_1(a_1_1 = 32w11, a_1_2=16w12);  /* A-0, B- */
e1(21, 16w22) --> e_1(a_2_1 = 32w21, a_2_2=16w22);     /* A-1, B- */
e1(31, 32) --> error  /* A-2, B-2 */
e1(True, 42) --> error  /* A-, B- */

enum bit<16> { VAL_1 = 51, VAL2=52 } enum_1_t;
e1(51, enum_1_t.VAL2) -> e_1(a_1_1 = 32w51, a_1_2=16w52);  /* A-2, B- */

If we think about @optional parameters without names, then you simply have more cases to choose from. Assume, that they can follow the mandatory ones (although the algorithm will work the same way even if they are in the middle). In other words, a constructor with K optional parameters:
      c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m, @optional to_1_1_t oa_1_1, ..., @optional to_1_k_t oa_1_k);

is first expanded into the following K+1 constructors:
    c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m); /* No optional parameters */
    c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m, to_1_1_t oa_1_1); /* 1 optional parameter */
    c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m, to_1_1_t oa_1_1, to_1_2_t oa_1_2); /* 2 optional parameters */
    . . .
    c(t_1_1_t a_1_1, ..., t_1_m_t a_1_m, to_1_1_t oa_1_1, ..., to_1_k_t oa_1_k); /* K optional parameters */

After that, the previously described algorithm is applied.
For the calls with the mix of named and unnamed parameters, let's first establish some rules:

Unnamed parameters cannot follow named parameters.
All unnamed parameters in front are treated positionally
Named parameters cannot be used to specify anything that has already been specified positionally. For example, one cannot write c(1, 2, 3, a_1_2=5)

This basically reduces the problem of matching calls with the mix of parameters to the problems of matching parameters without names (already covered above) and matching parameters with names only (in other way, both halves of the call have to match the same variant of the constructor/function).
For the calls with the named parameters only, the names of the parameters in the call will be used to select the candidates and if there is more than one, then the type matching will be applied using the same rules as in the case of the calls with unnamed parameters. The only difference is that the compiler can "virtually" sort the parameters in the same order as their names.
What do you think?

Update: per my discussion with @jafingerhut , it might be better to have a stronger resolution rule: if there is more than one candidate that matches (regardless of the number of implicit casts) , then we'll declare an error. Given that these constructors are not arbitrary, but carefully developed by the people who define a specific architecture, this will work as well.

Notes from discussion of this issue in 2021-May-03 LDWG meeting:
Mihai: Error if the compiler cannot narrow the list of candidates down to one certainly sounds better than "fewest casts wins", even though multiple candidates remain.
Mihai: Implementation in p4c is not easy.  The p4c type checker is not a simple part of the implementation.
Chris: May require mixing type resolution and reference resolution logic.
Chris: Type variable parameters to constructors, two or more of which are the types of constructor parameters for more than one constructor call, seem like it might make source code example that could be constructed where it was impossible to narrow down a call down to one candidate constructor?  Even if it was possible, the p4c implementation might be tricky.
Mihai: While this does seem useful, currently other priorities of p4c developers may hinder quick proposed implementation.  If it leads to type resolution becoming much more complex in the spec, that would be a reason to push back even with a proposed implementation.

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.


process subtract is missing

I cannot find the process subtract on these two instances:
host = "https://openeo.eurac.edu/"
host = "https://<IP_ADDRESS>:8443"

Could you please add subtract @prateekbudhwar
Here the processes that are exposed:
names(list_processes())
 [1] "load_collection"        "save_result"            "run_udf"                "filter_bands"
 [5] "filter_bbox"            "filter_temporal"        "ndvi"                   "resample_cube_temporal"
 [9] "resample_cube_spatial"  "if"                     "mask"                   "merge_cubes"
[13] "reduce_dimension"       "absolute"               "and"                    "xor"
[17] "or"                     "not"                    "log"                    "ln"
[21] "sqrt"                   "power"                  "e"                      "gte"
[25] "gt"                     "eq"                     "lt"                     "lte"
[29] "neq"                    "sin"                    "cos"                    "tan"
[33] "sinh"                   "cosh"                   "tanh"                   "arcsin"
[37] "arccos"                 "arctan"                 "array_element"          "multiply"
[41] "sum"                    "divide"                 "mean"                   "max"
[45] "min"                    "apply"                  "linear_scale_range"     "normalized_difference"
[49] "resample_spatial"

Put the subtract process


Prevent forms from resubmission after refreshing the page

Summary:
On pages that are designed with use of form tags, user is promted to resubmit form content.
In some cases that may result with exception being thrown (ex. oscm-app/default.jsf).
It is advised to either redesign the forms to use JS onclick actions rather than submit buttons or introduce navigation rules that will redirect user to the same page.
Acceptance criteria:

[ ] when page with form (like controller's UIs) is refreshed after submitting the changes, message to confirm form resubmission does not appear

Details:

proposed solution is to add navigation rules to faces-config.xml. For example:

The described here is the currectly implemented solution for a list of JSF views in OSCM. However this is a bit brittle, since there is no suitable measure to ensure that this list is complete.
I am convinced we'll find a generic solution, that can be better applied to the UI as whole. For example, this might be to put some servlet filter in front which implements the post-redirect-get pattern.

.... of course a generic solution requires some attention on the system performance.

Not such resubmission releated issues have been reported in past time and this request is of low priority. Therefore we have dropped plans for launching the described implementation. Feel free to reopen if you experience any issues.


make tool to split arbitrary big cvs files into directories of arrow files

connected to #6
I would like to make a tool which takes a arbitrary large CSV file,
splits in in any number of partitions (using 1 to n columns as "groups")
and creates directory hierarchy accordingly and writes arrow files for each group
Having that and #6 implemented, we could work with very big CSV files.

I think this can be done "rather easy" in a few lines of R code.

step: Split large CSV file into lots of CSV files on disk

readr::read_csv_chunked  combined with
write_csv (append = true)
should allow to go over a CSV file chunk by chunk and write the pieces "line-by-line" to the target CSV files.
This should hardly use any memory (controlled by chunk size)

Step
Package arrow has a way to convert "hierarchies of CSV"  files to "hierarchy of arrow files",.
This should work, hopefully

Delete the temporary CSV files

The CSV parser of readr::read_csv_chunked is in my view, very, very good and fast.
So we can leave the CSV parsing to them.

t.m.d doesn't support writing arrow currently, so the idea with converter can be addressed to clojisr. I agree that your procedure can be easy.

Maybe we can close this for now.
I made a tool which can partition CSVs accordingly:
https://github.com/behrica/csvsplit
In the last weeks, geni and TMD got new features regarding big data formats (arrow, parquet)
I think we are "done", with this.
Clojure is ready for analysing  big data.
Geni - as large as you cluster can scale
TMD - big, as longs as it fits in RAM


Added PanelKit

Pull Request Description
PanelKit is a UI framework, written in Swift, that utilizes protocols (including extensions) in many ways.
Acceptance Criteria
To be accepted into the Swift source compatibility test suite, a project must:

[x] be an Xcode or swift package manager project
[x] support building on either Linux or macOS
[x] target Linux, macOS, or iOS/tvOS/watchOS device
[x] be contained in a publicly accessible git repository
[x] maintain a project branch that builds against Swift 3.0 compatibility mode
and passes any unit tests
[x] have maintainers who will commit to resolve issues in a timely manner
[x] be compatible with the latest GM/Beta versions of Xcode and swiftpm
[x] add value not already included in the suite
[x] be licensed with one of the following permissive licenses:

BSD
MIT
Apache License, version 2.0
Eclipse Public License
Mozilla Public License (MPL) 1.1
MPL 2.0
CDDL

[x] pass ./check script run

Btw, is every added project also supposed to be added to the readme?

Don't worry about adding projects to the README at this point. We're still working on the final form of the project list.

Looks good!


fix typo in values and virtues guide

There's a double "then"

Thanks for catching that @franziskuskiefer! I'll branch this and get it through our CI process.

@franziskuskiefer before we merge this, would you mind reading and accepting our Contributor License Agreements (CLA), and adding yourself to our Contributors list?
You can find the CLA here: https://www.ockam.io/learn/how-to-guides/contributing/cla/
After reading that, please open a PR to our contributors repo and add a row for yourself in this file: https://github.com/ockam-network/contributors/blob/main/CONTRIBUTORS.csv
Thanks again!

After we get the CLA sorted, there's just a few other things:

Could you please change the target of the PR to the develop branch?
Could you change the commit message to begin with 'docs: ' - we have a strict convention for tagging commits

Thanks!

I filed https://github.com/ockam-network/contributors/pull/6

Merged as https://github.com/ockam-network/website/pull/382. Thank you!


[DISCUSS] Cross platform API for RN<>WebView 2-way RPC/message passing

Referencing (my) prior discussions regarding this, for context and so we don't repeat here. In reverse chronological order:

https://github.com/alinz/react-native-webview-bridge/issues/109#issuecomment-425669058
https://github.com/react-native-community/discussions-and-proposals/pull/3#issuecomment-414858049
https://github.com/facebook/react-native/pull/9762#issuecomment-260583009

This consistent, robust, cross platform API is important for any app that blends native and webviews. I list mine as one. A requirement of this API is that an injected postMessage  for purpose of RN message passing, not be overridden by a website's JS in the WebView. Which is currently the case with RN core's WebView, and presumably this forked react-native-webview. It could be achieved (and have been attempted in prior discussions and in RN core's WebView) by loading RN's injected postMessage last, but that's unreliable should the website create after onLoad a function of the same name, alongside iframe issues. This is not hypothetical as it does get overridden for a fact, when loading google.com in WebView for example.
A simple function rename that doesn't use the web standard of postMessage would sidestep what is effectively a name collision issue. Call it rnPostMessage or anything else. Open to suggestions on a better alternative to renaming that actually has a guarantee for not being overridden by non-locally loaded JS within WebView.
This new API should consider/port code (if tested as reliable) from react-native-wkwebview, which is iOS only. And implement the same API for other platforms. There is also working RN<>WebView bridge API at react-native-webview-bridge that's well established (old but fully functional, with google.com loaded in webview, and for Android and iOS), but that's based on UIWebView and not WKWebView on the iOS side.

Thanks @fungilation !
One other interesting API I found when perusing Github was this one:
https://github.com/pinqy520/react-native-webview-invoke
It exposes an API where you can call an async function directly, as long as you control both the web and mobile side of the connection. Under the hood, it still uses postMessage, but I thought I'd bring this up in case it was interesting as a potential API.

Interesting. Although requiring below on the Web side is no good. New API should support any WebView src, not only local js:
import invoke from 'react-native-webview-invoke/browser'

@fungilation So I was using a fork of alinz/react-native-webview-bridge until I started using this package. I wrote a simple piece of code that allowed me to be 100% non breaking with what was there before. This does not mean it's safe regarding postMessage naming and such but I'll just post it here in case anyone needs it.
const injectedJavascript = `(function() {
  window.WebViewBridge = {
    onMessage: function() {
      return null;
    },
    send: function(data) {
      window.postMessage(data, '*');
    },
  };
  var event = new Event('WebViewBridge');
  window.dispatchEvent(event);
})()`;

const generateOnMessageFunction = data =>
  `(function() {
    window.WebViewBridge.onMessage(${JSON.stringify(data)});
  })()`;

sendMessageToWebView = (message) => {
    this.webView.current.injectJavaScript(generateOnMessageFunction(message));
  };

Then you just need to use onMessage prop to listen and sendMessageToWebView to send.
From the website the api is unchanged. You can use webviewBrigde send and onMessage as before :)

I totally agree this is a requirement for even considering React Native, with a WebView, as a suitable replacement for Cordova (without using the native components, rather than their web counterparts).
I created the following schematic and we will be investing some time in working up an example, any advice on improving this implementation strategy would be appreciated!
Also some idea of whether we would want to move this functionality into this package (I believe it should be included) or maintain it as a separate package would be nice.

Well that is what I'm doing already (excepted for the callback array, as I'm more in the just dispatching actions without waiting for answers mind)

@Titozz my end goal is to allow calling any react-native package directly from the WebView as if we didn't even have to cross the boundary between the two.
I have a simple (in a good way) working example of a Bridge which does the following; ReactNativeBridge.call('functionName', arg1, arg2, arg..., callback) where you can pass as many arguments as you want and callback is of the form (err, res). On the native side you define what functionName does (and whether it is sync/async), quite similar to the invoke package.
@fungilation I also forked this package and modified the Android implementation of postMessage (in the webview) to no longer overwrite the window.postMessage (this caused issues for our application).
I didn't implement this using injectedJavascript yet, as I actually don't mind importing a package on both sides (native & web), but will work on that soon.
Are there any other use cases I should take into account?
It is my intention to create a PR for this feature which could be enabled by passing bridge={true} to the Webview component and add documentation on how to use it in the WebView.
One limitation of my approach, which could be easily resolved, is that it currently only allows calling from WebView to Native, not the other way around.
Happy to hear your thoughts!

Okay I've updated all the repository issues regarding postMessage 😄 .
Let's keep the discussion focused in this thread only, or we will get lost! 😢
I think everyone agrees that using postMessage I not a good idea for several reasons!
Listing what we need:

[ ] More stability on setup
[ ] Stop using postMessage
[ ] 2 way communications

Nice to have ..?

[ ] Async / Callback return values
[ ] ?

@Titozzz for our use-case async/callback return values are a must-have.
The BridgedWebview repository (https://github.com/KoenLav/bridged-webview) I created already fulfills the first two checks on your list and covers async/callback returns values.
I'm not sure however how you interpret two-way communication? The approach I took is pretty much centered around the WebView having the 'lead' (dictating what is happening), but I can imagine use-cases where one would want the native side of things to have the lead, and dictate what happens in the WebView. What's your take on that?
I could quite easily extend the classes to also cover this use-case, but if we don't expect anyone to use it like that it could just make things confusing.

So I've read your code (super fast, sorry it's late here 😴). I'm however not sure that we want to implement something that is THAT specific. What I mean is that you defined a 'RFC' to communicate and do function calls and all that, but in the end what I think this repo should provid is a solid communication (eg: just posting JSON payload) both ways and then leave the implementation back to the users, as you did in your repository. I don't know if i'm clear. I'll try to explain better tomorrow !

I see (with regards to the use-case).
The reason I didn't invest any time into Native => WebView yet is also because it's pretty easy to solve once WebView => Native works. For example: injectJavascript(const result = doSomethingInWebview(); ReactNativeBridge.call('anyNativeFunction', result, someOtherVariables...);
=====
Given the use-case you are describing (just sending data from one side and having it picked up on the other side) I can imagine this might seem specific. What do you mean by solid communication? I think this repo already does that just fine (on Android, at least, not sure of the status of the WKWebView included at the moment). If there is still work to do in making sure that postMessage/injectJavascript work fine on all supported platforms then that definitely needs to happen first!
In our use-case we actually want to port a (Meteor) web-app from Cordova to React Native, but for some functionality we rely on native code (getting the unique device ID, communicating via TCP sockets, etc.). What I was going for is providing a way to do anything from the WebView about as easily as you could from the native side of things.
I don't think this is THAT specific; it can also be used to simply pass JSON from one side to the other, as it doesn't require setting a callback and the underlying postMessage function is still available as well, for users wanting more fine-grained control.
I simply defined a standardized way of instructing the native side how to handle specific messages, which I think is much easier to understand for a new user than what is currently out there (react-native-webview-bridge, react-native-webview-messaging, react-native-webview-invoke) AND supports all use-cases the packages I just mentioned support.
Looking through the code sample you posted earlier I did however notice that I didn't implement the onMessage function within the WebView yet, if I add that then the statement above (supporting all use-cases) is actually true, as far as I can tell.
Happy to hear your thoughts!

Meteor/Cordova! I tried and failed with my last mobile app project using it, good to see another migrant to RN.
I'm copying over my comment from the other issue as I think it's useful for discussion of what 2-way communication means to me, and what I think a good API looks like based on the tried and true in existing libraries:

I'm for a breaking change in API. Especially if that means sidestepping entirely security issues with origin. As a user, it doesn't matter as long as it's documented and works. I've  advocated for renaming so postMessage / onMessage equivalent APIs can work independent of what the WebView's original site javascript does. Sticking with web-centric APIs for RN<>webview communication has never been a wanted feature (for me).
For starter, instead of proposing completely new API, what about just borrow one from existing, working library? react-native-wkwebview's API looks comprehensive, but they are using the same window.postMessage and onMessage API. Do they guarantee against function overwriting from websites' javascript and security issues with origin?
react-native-webview-bridge I use actively with my own fork for my own app. It's not the best API but it works, and it works for both iOS and Android. We could start with that as far as API definition? With one exception, on calling from RN to WebView:
react-native-webview-bridge uses this to send string to WebView:
webviewbridge.sendToBridge("hello from react-native")

but react-native-wkwebview's way is better, since users can directly evaluate JS, and define separate functions for different purposes injected in webview. String sending in react-native-webview-bridge means a nest of conditionals to handle a list of strings sent from RN, and it gets messy.
this.webview.evaluateJavaScript('receivedMessageFromReactNative("Hello from the other side.")')

Is it just me, or is Github busted right now? Commenting keep coming back with error "You can't comment at this time."

WTH is with Github commenting. Database issue, keep saying I can't comment at this time so this is a mic test.

Meteor/Cordova! I tried and failed with my last mobile app project using it, good to see another migrant to RN.
I'm copying over my comment from the other issue as I think it's useful for discussion of what 2-way communication means to me, and what I think a good API looks like based on the tried and true in existing libraries:

I'm for a breaking change in API. Especially if that means sidestepping entirely security issues with origin. As a user, it doesn't matter as long as it's documented and works. I've  advocated for renaming so postMessage / onMessage equivalent APIs can work independent of what the WebView's original site javascript does. Sticking with web-centric APIs for RN<>webview communication has never been a wanted feature (for me).
For starter, instead of proposing completely new API, what about just borrow one from existing, working library? react-native-wkwebview's API looks comprehensive, but they are using the same window.postMessage and onMessage API. Do they guarantee against function overwriting from websites' javascript and security issues with origin?
react-native-webview-bridge I use actively with my own fork for my own app. It's not the best API but it works, and it works for both iOS and Android. We could start with that as far as API definition? With one exception, on calling from RN to WebView:
react-native-webview-bridge uses this to send string to WebView:
webviewbridge.sendToBridge("hello from react-native")

but react-native-wkwebview's way is better, since users can directly evaluate JS, and define separate functions for different purposes injected in webview. String sending in react-native-webview-bridge means a nest of conditionals to handle a list of strings sent from RN, and it gets messy.
this.webview.evaluateJavaScript('receivedMessageFromReactNative("Hello from the other side.")')

@fungilation I read your comments to most issues before I started working on this and I think the package linked in my latest PR, and the API it suggests, will suit your use case.
Any comments are much appreciated!

@Titozzz I looked into the implementation of react-native-webview-bridge and I don't think it is much/any safer than the currently implemented solution here.
Can you identify where their implementation is better and/or what is not 'strong' about the current implementation in this repository?

Sure I gave the example only because they are not using window.postMessage.
Issue with the current implem as stated in the docs:

Security Warning: Currently, onMessage and postMessage do not allow specifying an origin. This can lead to cross-site scripting attacks if an unexpected document is loaded within a WebView instance. Please refer to the MDN documentation for Window.postMessage() for more details on the security implications of this.

Plus when you instanciate the webview it messes with window.postMessage that was previously defined.
This is why we will probably define something else

@Titozzz my PR already resolves the second issue.
The cross site scripting one I think is a more difficult one, but I could also take a look at that.
Do you have any suggestions?

Yeah, we need to stop using postMessage behind the scenes !

I'm not sure I understand you correctly: in my opinion we need to stop using window.postMessage, but a .postMessage function would be fine, agreed?
The AnyGlobal.postMessage function is simply a function which is inserted into the window and enables us to send messages to the React Native side.
We could name the function anyhow we wanted as it simply makes use of a JavascriptInterface on Android:
https://github.com/react-native-community/react-native-webview/blob/master/android/src/main/java/com/reactnativecommunity/webview/RNCWebViewManager.java#L261
https://developer.android.com/reference/android/webkit/JavascriptInterface
Or a WKScriptMessageHandler on iOS WKWebView:
https://github.com/react-native-community/react-native-webview/blob/master/ios/RNCWKWebView.m#L146
https://spin.atomicobject.com/2016/09/01/sharing-web-data-wkwebview/
It does appear however, when reading the iOS example, that in iOS it is only possible to implement a variable in window.webkit.messageHandlers..postMessage.
So I guess, for consistency, we should do the same for Android (which lets us insert the bridge in any place).

yeah sure when I say stop using post message I'm talking about the one inside the window 😛 .

What do you think of my suggestion of implementing a switch called something like "overWriteWindowPostmessage" to re-enable the old behavior?

oh, I need to re-read that PR. Will do soon !

A requirement of this API is that an injected postMessage for purpose of RN message passing, not be overridden by a website's JS in the WebView. Which is currently the case with RN core's WebView, and presumably this forked react-native-webview. It could be achieved (and have been attempted in prior discussions and in RN core's WebView) by loading RN's injected postMessage

One thing I didn't understand is why is this necessary? You have control over the website's code, so why can't you prevent the JS in the website from overriding postMessage?

@satya164 I think the problem comes in when someone accidentally (or otherwise) navigates to an untrusted website, which can also use the window.postMessage protocol to send messages to native. By injecting the custom MyModule.postMessage, you control which web pages have a pathway to communicating back to React Native. Does that help?

@jamonholmgren so it's when you're injecting JS to a website you don't control?
I guess in that case, using __REACT_WEB_VIEW_BRIDGE.postMessage should work as expected. Though __REACT_WEB_VIEW_BRIDGE doesn't look like a public API, so probably the simplest change we have to make it rename __REACT_WEB_VIEW_BRIDGE to something like ReactNativeBridge or REACT_NATIVE_BRIDGE and document it. Then people can use ReactNativeBridge.postMessage when they can't control the website.

@satya164, Yes it's for injecting JS into ANY website, not just local JS. And backward compat with window.postMessage is not what any RN user should want. Let websites' JS not interfere with the RN<>WebView bridge or vice versa.
window.postMessage is for the Web and websites in the wild. Let's not touch it anymore.

@fungilation And backward compat with window.postMessage is not what any RN user should want

I'm not talking about compatibility with window.postMessage, I'm talking about backward compatibility with previous versions. Breaking existing code which relies on this API without any warning and deprecation cycle is very irresponsible, especially when a lot of people could be using this.

@KoenLav window.postMessage isn't polyfilled, it's simply replaced

Yeah, the current implementation isn't very nice. It should've been something like this to not break websites:
window.postMessage = function(data, origin) {
  window.originalPostMessage(data, origin);

  if (!origin) {
    __REACT_WEB_VIEW_BRIDGE.postMessage(String(data));
  }
}

However changing the behavior now would be a breaking change.
I saw your PR, I think the API is good. But it's a breaking change without a deprecation cycle. I think we should keep the code around for few versions, maybe with some kind of warning, and remove it later.

I thought the point of spinning WebView out of RN core into this repo, is so there can be clean improvements that break backward compat. I'm not sure you know how many times I've argued against using window.postMessage in RN core, at least renaming postMessage to something else. And I've repeatedly been ignored in the name of compatibility.
People who depends on old behavior can easily stick with RN core's WebView. Breaking changes in this repo at this stage can have warning of change, in console and in changelog, but require no deprecation cycle.
And I still fail to see the point of preserving window.postMessage for RN communication. If it's injected JS making such call, it can call whatever function the new API is to be named. Website JS wouldn't be RN-aware and would continue using window.postMessage, unchanged and undisturbed.

@fungilation totally agreed.
Adding a property which would reinstate the old, deprecated behavior (overwriting window.postMessage) would be nice though, I'll work on that tomorrow.
I think if/when we settle that issue we can start to think about what more the bridge should do; because IMO simply providing the developer with an API where strings can be passed from WebView to RN seems like doing half the work.

IMO simply providing the developer with an API where strings can be passed from WebView to RN seems like doing half the work.

this.webview.evaluateJavaScript() like I mentioned, borrowing from react-native-wkwebview?

@fungilation I'm talking about Web => RN, you're talking about RN => Web, I think?
For me injectJavascript does the job just fine there, why would you want to add evaluateJavascript and what would be the difference?

I'm always talking about both ways. "RN<>WebView 2-way RPC/message passing".
injectJavascript is only half of the story (a quarter?). Message passing from RN to WebView in order to get WebView to do something, or evaluateJavascript would be a direct RPC.

I understand, but as far as my requirements go I think everything is possible already, so I'm trying to find what you are missing.
If you want to call someFunction within the webview from RN simply injectJavascript("someFunction()").
If you want to call someNativeFunction from the webview you can use the API presented in the package I created (BridgedWebview), using ReactNativeBridge.call('someNativeFunction'), which I think should be merged into this repository.

Ok we are not talking about the same kind of injectJavascript. I'm referring to one that's a prop that takes a static string as JS to inject, once on WebView component init.

@satya164 This repository is using semver versioning, so would it be that bad to do breaking changes 🤔 ? To me as long as you do a major release and document how to upgrade it should be fine, right ?

If we want a smoother transition, we can add the new interface and let the old one for ~one month. However I don't like maintaining old code for too long as it hurts more than it helps most of the time. Same reason I'll probably get rid of the UIWebview soon-ish.

@Titozzz You're the maintainer, so it's up to you. I always add a deprecation warning first and remove it after few releases. Because even if you follow semver, not everyone understands it and many people update their deps blindly. When someone updates to a new version, you can suddenly break their code or provide a helpful warning to migrate to the new API. React and React Native do the same when deprecating things. I don't like keeping around old code, but ultimately it provides a better UX without any actual impact on maintenance since it's going to be removed anyway, there's no reason to touch it until it's removed.

This repo is a spinoff, experimental and brand new.

This repo is a spinoff, experimental and brand new.

Where does it say it's experimental? My coworkers are already using it in production. Why are you so against a deprecation warning anyway?

Why do I have to keep repeating myself as to why? Because you can go back to using RN core WebView in the meantime while it's bleeding edge, and the point of this repo is to implement the breaking changes that core wouldn't.
I'm done talking to you on this point since this is getting toxic.

@fungilation disagreements generally lead to new insights. Everyone here has the best intentions.
@satya164 while I understand your point I totally agree with @fungilation; there should be some breaking changes to fix the mistakes which were made before.
Providing a prop to restore the old behavior, in my opinion, is sufficient.
People should understand that this repository, at this point, isn't about stability but about moving things forward in a way which could not be achieved within core.
If this means that some of them, those who (1) already moved to this repository and (2) bump major versions without thinking twice, will break their application, so be it.
This is not our responsibility at this point.
Let's quit the endless discussion (we are not going to agree, apparently) and move things forward!

@fungilation @satya164 I think we covered the most significant points of view in this discussion.
Let's work towards implementing something?
Could you review my PR here and/or provide an alternative implementation?
https://github.com/react-native-community/react-native-webview/pull/104

I'm not sure I'm qualified to review this as my knowledge of native iOS/Android code is quite limited. In #104, @Titozzz last commented that it cannot be merged as is, so it's his call?
My 2c is if #104 only offers 1 way call from WebView to Native, without building a foundation for calling from the other way around as well, then it's not a good path forward.
Also, I'm not sure what you meant when you said "I didn't implement this using injectedJavascript yet" before? injectedJavascript or equivalent like eval is key in getting RN and WebView to talk to each other.

Please take a look at the code, you'll understand what's done from the diff :)
This PR does not (yet) offer a way to call functions from WebView to ReactNative. The package I am working on here does: https://github.com/KoenLav/bridged-webview
Titozzz mentioned he doesn't feel like this should be included in this repository (you and me disagree with him, and think it should), so I left it out of the PR for now.
This PR solely focuses on un-breaking things (window.postMessage) and making sure the behavior between iOS and Android is consistent, while maintaining backwards compatibility under a flag.
In a later PR I want to work on creating a property on the WebView (injectBridge={true}) which will make the following possible, from the WebView:
ReactNativeBridge.call('nativeFunctionName', arg1, arg2, function(err, res) { console.log(err, res) });
As you can see in the BridgedWebview repository.

Two questions:

Can the API be Promise based? I don't see a reason why using old node callback style for a React Native API
How does it handle event listener functions?

@KoenLav will review!
@iddan which API should be promise based?

ReactNativeBridge.call('nativeFunctionName', arg1, arg2, function(err, res) { console.log(err, res) });

Should actually be:
ReactNativeBridge.call('nativeFunctionName', [arg1, arg2]).then(console.log).catch(console.error);

Thank you @KoenLav , I still believe that this code does not really have to be here, but if everyone thinks it should be I will merge it in. Separating the the functionalities is a great way to get things moving, so good move.
As commented in the PR, I'll try to review tomorrow.
(+1 promises 👍 > callbacks )

@Titozzz I have been thinking about a more 'low-level' approach. While doing so it occurred to me that we can call any function inside the WebView from outside of it, but not the other way around. This is also what @fungilation is asking for, I believe.
The approach I took with the BridgedWebview allows specifying functions on the Native side which may then be called from the WebView, but it doesn't allow executing arbitrary code.
Hence a more low-level implementation of the same functionality I proposed in the BridgedWebview would be allowing the WebView to execute arbitrary code.
Something like ReactNativeBridge.execute(/ do something on the native side /). This doesn't require the whole callback structure, but does raise some security concerns (which would probably force us to implement the origin parameter and/or to validate the current origin of the WebView before executing arbitrary code.
These considerations have no impact on the existing PR, they are simply offering an alternative to the BridgedWebview I proposed.
Any thoughts on this?
ps I agree promises are preferred, however I just borrowed this implementation from Meteor's method calls. It should be easy enough to implement promises.

Once again, leaving the implementation as is (after merging that PR) allow you to build whatever code you want and if your desire is to call 'eval()' on what's sent to you through JSON, this is 100% fine. All the different use cases are the reason why I don't want to build a specific one inside the webview

Cannot migrate to this component from RN's WebView because onMessage not working here from out of the box

I realize I'm late to this conversation, but I recently wrote a library called yaob that can seamlessly bridge method calls over any JSON-style messaging layer. Our app has a lot of heavy client-side logic that we would like to run in a WebView for JIT purposes. I wrote the library to make this as seamless as possible, so I can just call methods, not deal with postMessage / onMessage.
Using
To start, you would define your API using some normal Javascript objects:
import { Bridgeable } from 'yaob'

// Make a normal class with async methods:
class ApiDemo extends Bridgeable {
  async doMath (a, b) {
    return a + b
  }
}

// Send that to the React Native side:
window.bridge.sendRoot(new ApiDemo());

On the React Native side, you just grab the object and call methods like normal:
const apiDemo = await this.bridge.getRoot()
const sum = await apiDemo.doMath(1, 2)

Every method call gets turned into a JSON message that passes over the bridge, so you never need to deal with the underlying messaging layer. You can also pass Bridgeable objects as parameters and return values, so the API isn't limited to a single object.
Setup
Setting up the window.bridge & this.bridge objects requires a bit of boilerplate. The yaob library provides a Bridge object, which needs to be wired into the WebView postMessage / onMessage mechanism. The ReactNative side looks like this:
export class Demo extends Component {
  constructor(props) {
    super(props);
    this.ref = React.createRef();

    this.bridge = new Bridge({
      sendMessage: message =>
        this.ref.current.injectJavaScript(
          `window.bridge.handleMessage(${JSON.stringify(message)})`
        )
    });
    this.bridge.getRoot().then(demoApi => {
      // Here we can call methods on the demoApi!
    });
  }

  render() {
    return (
      <WebView
        ref={this.ref}
        onMessage={event =>
          this.bridge.handleMessage(JSON.parse(event.nativeEvent.data))
        }
      />
    );
  }
}

The HTML side of the bridge (inside the WebView) looks something like this:
import { Bridge } from 'yaob'

window.bridge = new Bridge({
  sendMessage: message => window.postMessage(JSON.stringify(message))
});

Actually, the code above doesn't work reliably because of bugs like #5, where the HTML side needs to wait for the correct postMessage object to show up. Working around that would make this boilerplate much longer.
Things that would make this easier might include:

Make window.postMessage reliably available. This may involve picking another name like window.postReactNativeMessage so we don't have conflicts.
Add a WebView.postMessage / window.onMessage pair, so I can avoid the ugly injectJavaScript call.
Allow the message pipeline to handle Javascript objects using the structured clone algorithm, so I can avoid JSON.parse / JSON.stringify.

I would love to reduce the amount of code needed to set up the bridge. Anything the WebView can do to help here would be appreciated.
I agree that the WebView just needs to provide a simple / reliable way to send messages back and forth. Libraries like yaob can then provide method calls, events, subscriptions, and other cool features on top of this simple base.

Oh my god, this is exactly what I want and wish ❤ ❤ ❤

I think the beauty of a WebView custom implemented of RPC is it can share the same memory representation of objects in both the JS runtimes: RN and WebView as they use the same core. This will make performance much better than postMessage can offer at the moment.

Yes but primitives and base classes are shared

Cool

@KoenLav Awesome! I didn't realize these fixes were already in the works.
As for the structured clone algorithm, I don't have any particular ideas on the implementation. This was more of a pie-in-the-sky wishlist item for me. Using an NPM module like the one you pointed out might be a reasonable approach.

:tada: This issue has been resolved in version 4.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

Wow, thanks @Titozzz for making this happen! 🎉

:tada: This issue has been resolved in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

I have previously implemented an RPC bridge based on the postMessage api and the Comlink  library.
I'm using it in my own react-native project. You may check it out here:
rn-webview-rpc.

Sorry about replying to such an old thread, but it's still unclear to me which is the correct way to implement a synchronous two way communication between React Native and the WebView.
AFAIK the current implementation allows for non-blocking calls only, thus lacking the possibility to provide a return value from the native code to the webview in the same JS call.
For clarity, this is what I'm trying to achieve:
// WebView -> RN
await this.ReactNativeWebView.postMessage('message').then(response => response);

// RN -> WebView
if (message === 'message') {
  return await doStuff();
}

I've already read the thread and checked out the following repositories

https://github.com/KoenLav/bridged-webview
https://github.com/ronhe/rn-webview-rpc
https://github.com/pinqy520/react-native-webview-invoke
https://github.com/kirill578/react-native-webview-bridge-seamless
https://github.com/EdgeApp/yaob

And discussions: https://github.com/react-native-webview/react-native-webview/issues/467
But it didn't help identifying a correct approach to implement such a behavior.
This should be similar to what iOS does with the WKScriptMessageHandlerWithReply (see the userContentController section).


Remove K8S_HELM_VERSION_1_7 from Dockerfile

Helm 2.5.1 does not fully support k8s 1.7, and should be removed.
Helm release notes:
Helm v2.5.1 is tested on Kubernetes 1.5-1.7. However, the latest Kubernetes 1.7 features (e.g. custom type definitions) are not supported in this release. Full Kubernetes 1.7 support is coming in Helm 2.6

Blocked by https://github.com/samsung-cnct/k2/issues/513

PR: https://github.com/samsung-cnct/k2-tools/pull/102

LGTM


Test labeled with "passes 0% of the time" after 1 success + 1 failure.

Probably related to #211.
Observed behavior
A test that has been run 2 times with 1 failure is labeled with Passes 0.00% of time. Seems to be an issue with the metrics calculation.

Expected behavior
The test should be labeled with Passes 50.00% of the time.

The first run hasn't been sent to flaky.dev


Fix IRGen debug info for swift_task_alloc'ed variables.

The old code attempted to load the variable despite not knowing its size. Fixed by describing the variable's address on the task heap.

Matching LLDB test can be found in https://github.com/apple/llvm-project/pull/5768

Discovered via https://github.com/apple/swift/pull/62499

I wasn't sure but also didn't think so. Just trying to be thorough. I may know the words and grammar, but reading that code is like Darmok & Jalad at Tanagra.

Hmm, I'm still experiencing the symptom of the Xcode debugger not seeing some local variables that are clearly in scope and accessible, in this case running in a Task { } block (via function call) on macOS. Happy to provide this project.

Happy to provide this project.

That would be great. Either bugs.swift.org or feedback.apple.com work.

Set a breakpoint in DaemonCollector.swift:153 and run it. It should stop there almost immediately. Try to inspect the variables lower in the list in the Xcode variables pane (interestingly, it seems there's a line on the list above which variables are inspectable, below which they are not, and I feel like this has always been the case).
See the screenshot for examples (I context-clicked on label and executablePath and chose “Print description of”):

Exorcist.zip

Thanks! Here's an even shorter reproducer:


go to specific url

How can I go to a specific url after visit()?
For example, I'd like to:
$this->visit('/login')
<EMAIL_ADDRESS>'email')
->type('pword', 'password')
->click('submit')
and then:
->goto('arbitrary/url')
within the same web browser, so my user is still logged in and can to an arbitrary url.

got it:
protected function goToUrl($url)
{
    $url = $this->baseUrl() . $url;
    $this->currentPage = $url;
    $this->session->open($url);
    return $this;
}


raidboss: Initial A6S Triggers

These could always be improved upon; they were taken from a combination
of triggers from guides, a solo run of A6S that I couldn't complete
alone, existing triggers, and video footage.

Thanks! I feel like the alexander raids are probably the area that could use the most timeline and trigger attention at the moment, so this is much appreciated.


Fix worker grouping

Codecov Report

Merging #2622 into dev will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #2622      +/-   ##
============================================
- Coverage     36.48%   36.46%   -0.03%
+ Complexity     2491     2490       -1
============================================
  Files           431      431
  Lines         19878    19878
  Branches       2424     2424
============================================
- Hits           7252     7248       -4
- Misses        11972    11975       +3
- Partials        654      655       +1

Impacted Files
Coverage Δ
Complexity Δ

...he/dolphinscheduler/api/service/LoggerService.java
82.60% <0.00%> (-8.70%)
9.00% <0.00%> (-1.00%)

...he/dolphinscheduler/common/thread/ThreadUtils.java
74.60% <0.00%> (-3.18%)
14.00% <0.00%> (ø%)

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 6127f3a...933c5fe. Read the comment docs.


0.3.0 seems to hang loading of game for some

Multiple reports of people not being able to start the game when loading HookUI 0.3.0 via Thunderstore.

This been solved with release 0.3.1 (fingers crossed)


package is massive

1.92 MB

I know 🤦♂ This is because the library was originally intended to be used with React and then I just wrapped it around vanilla JS and had to add react-dom as dependency.
I think the quickest solution right now is to use Preact as dependency instead and in the future we can use Svelte to compile all to vanilla JS

Fixed on v1.0.0-beta.20

I know 🤦♂ This is because the library was originally intended to be used with React and then I just wrapped it around vanilla JS and had to add react-dom as dependency.
I think the quickest solution right now is to use Preact as dependency instead and in the future we can use Svelte to compile all to vanilla JS

Is there any plan to migrate to Svelte?


Laravel 5?

HI is this compatible with Laravel 5 ?
thanks

The PHAR can be used on any type of application (or as a global composer dependency) but Rocketeer cannot be required as a dependency of a L5 app no (because of Symfony components conflicts and stuff)

Is there any of full example how to configure Rocketeer with sample Laravel 5 application, with stages, shared .env files, npm, gulp etc.?

No, the documentation will be worked on a bit to include generic examples on how to run builds etc. but nothing that is completed yet. Rocketeer is a standalone package and isn't tied to Laravel anymore, as such there isn't any "special cases" for it in the code. PRs to rocketeers/docs are welcome if anybody wants to help a bit :d


HDFS documentation

Recently, #767 has been merged into main. Currently, this is feature not documented. We should add documentation for this feature to make it easier for developers and users to use DAPHNE with HDFS support. This includes how to run DAPHNE with HDFS support, examples, required setup, limitations / drawbacks (and more).

@corepointer likes labeling stuff :star_struck:
Sorry for the noise :speak_no_evil:

closed by 0091b98c4d31252d77cac8fdcb28de756ddce93f


failed to open driver: read /dev/ptmx: input/output error

Hi
I'm not sure if it's related to this: https://github.com/scrapli/scrapligo/pull/135
I wrote a small scrapligo application inside a vscode devcontainer mcr.microsoft.com/devcontainers/go:0-1.20-bullseye. It's running as it should.
But running it in an alpine, ubuntu or golang container doesn't work and ends up directly with this error message while opening the driver Driver.open():
read /dev/ptmx: input/output error

Maybe somebody has a hint for me?
Thanks!

Maybe as a workaround you can use standard transport which doesn't use pty?

Thanks for your fast response.
Where can I set/change the transport mode?
Currently I have something like that:
p, err := platform.NewPlatform(
	platformDefinitionPath,
	hostname,
	options.WithAuthNoStrictKey(),
	options.WithAuthUsername(username),
	options.WithAuthPassword(password),
	options.WithAuthSecondary(enablePassword),
)
if err != nil {
	return nil, fmt.Errorf("failed to create platform: %w", err)
}

d, err := p.GetNetworkDriver()
if err != nil {
	return nil, fmt.Errorf("failed to fetch generic driver from the platform: %w", err)
}

...

Nice 🚀 . Thanks for your help. It runs now also in an alpine image.


Release Telegraf v1.25.0 and v1.25.1

I have never done this, but these are the steps I took and I tried to do separate commits to make this easier to review:
cp -R content/telegraf/v1.24 content/telegraf/v1.25
git commit -am "copy v1.24 to v1.25"

cd content/telegraf/v1.25

# Update 1_24 to 1_25 in everything
find . -type f -exec sed -i 's/1_24/1_25/g' {} +
git commit -am "update 1_24 to 1_25"

# Update 1.24 to 1.25 in everything except the change log and plugins
find . -type f -not -path ./release-notes-changelog.md -not -path ./plugins.md -exec sed -i 's/1\.24/1\.25/g' {} +
git commit -am "update 1.24 to 1.25"

After that I did the following three commits:

Update plugins.md with aliases. It had twice as many 1.24 as it should, it was missing 1.23 and added 1.25
Updated change log with new entries, I used copy and paste from our change log as it seemed there was a mix of standards and ways to show changes.
Jump into data/telegraf_plugins.yml and added the 6 new input plugins

[x] Signed the InfluxData CLA
(if necessary)
[x] Rebased/mergeable

I should've told you that I'm in the middle of doing this right now

No worries, it is probably good to have more than just you working on it :)

I'm planning to work on is adding information about secret stores, but I haven't actually started that yet, so we're all good.

Yeah, I wasn't sure about the secret stores yet :) Let me know when you have a PR I'd like to see what you do! Happy to review.

Oh, actually, there is one other change that needs to be made:
In data/products.yml, update:

telegraf.versions with v1.25
telegraf/latest to  v1.25
telegraf.latest_patches:

add "1.25": 0
Update "1.24": 2 to "1.24": 4


[Bug] Mod is not working with a Gen6 save.

The set I tried:
Bronzor @ Berry Juice
Level: 50
Ability: Levitate
EVs: 60 HP / 4 Atk / 228 Def / 4 SpA / 148 SpD / 12 Spe
Careful Nature
- Stealth Rock
- Recycle
- Earthquake
- Psychic

The error I get:
https://gyazo.com/485b15b62b6a49433f98c76afba9a5cc
When I click on [Continue]
https://gyazo.com/1cb3d5c11ecf8245687f58deca2d90ad
I tried with many differents sets, I always got this error with a X save

Adding previous generation support as a feature request.


[PY test failure][llvm codegen] test_codegen_llvm.py

Hi, I got these errors when running test_codegen_llvm.py on the trunk hash a88b2842. I bisected the test functions and have these:
this one comes from test_llvm_intrin()
py3 test_codegen_llvm.py
Assertion failed: (Index < Length && "Invalid index!"), function operator[], file /Users/ywu/code/llvm-project/llvm/include/llvm/ADT/ArrayRef.h, line 240.
[1]    2692 abort      /Users/ywu/anaconda3/bin/python test_codegen_llvm.py

this one comes from test_llvm_lookup_intrin()
py3 test_codegen_llvm.py
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function init, file /Users/ywu/code/llvm-project/llvm/lib/IR/Instructions.cpp, line 405.
[1]    2828 abort      /Users/ywu/anaconda3/bin/python test_codegen_llvm.py

My clang version is 10.0 and I have set USE_LLVM in config.cmake. Could someone take a look? My llvm is built from src. this might caused the problem
btw, it would be great to have test icon on the github page :)

It would be great if you can dig deeper. Also please open a new thread on https://discuss.tvm.ai/ as we use the discuss forum for trouble shooting.
It could due to the fact that the intrinsic def changes. We do have a test ci which is currently green in the frontend readme