[BUG] long fh does not work for specific forecasting pipeline

posted by @anthonygiorgio97 in #2452
(added some missing imports)
Another strange behaviour is that if fh=[1,2] the code below works, but if fh=[1,2,3] or [1,2,3,4],... or longer, I have error:
from sktime.forecasting.compose import make_reduction, ForecastingPipeline, TransformedTargetForecaster
from sktime.forecasting.model_selection import ExpandingWindowSplitter, temporal_train_test_split, ForecastingGridSearchCV
from sktime.forecasting.fbprophet import Prophet
from sktime.transformations.series.adapt import TabularToSeriesAdaptor
from sktime.transformations.series.boxcox import LogTransformer
from sktime.transformations.series.compose import OptionalPassthrough
from sktime.transformations.series.difference import Differencer

from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVR
from sktime.datasets import load_longley

y, X = load_longley()

#split train/test both y and X
fh = [1,2,3]
train_model, test_model = temporal_train_test_split(y, fh = fh)
X_train = X[X.index.isin(train_model.index)]
X_test = X[X.index.isin(test_model.index)]

#pipeline
pipe = TransformedTargetForecaster(steps = [
            ("log", OptionalPassthrough(LogTransformer())),
            ("differencer", Differencer(drop_na = True)),
            ("scaler", TabularToSeriesAdaptor(StandardScaler())),
            ("myforecasterpipe", ForecastingPipeline(steps = [
                ("logX", OptionalPassthrough(LogTransformer())),
                ("differencerX", Differencer(drop_na = True)),
                ("scalerX", TabularToSeriesAdaptor(StandardScaler())),
                ("myforecaster", make_reduction(SVR()))
        ]))
])

#cv setup
N_cv_fold = 1
step_cv = 1
cv = ExpandingWindowSplitter(initial_window = len(train_model) - (N_cv_fold - 1) * step_cv - len(fh),
                            start_with_window = True,
                            step_length = step_cv,
                            fh = fh)

param_grid = [{"log__passthrough": [False],
               "myforecasterpipe__logX__passthrough": [False],
               "myforecasterpipe__myforecaster__window_length": [2,3],
               "myforecasterpipe__myforecaster__estimator__C": [10,100]
              },
              {"log__passthrough": [True],
               "myforecasterpipe__logX__passthrough": [True],
               "myforecasterpipe__myforecaster__window_length": [2,3],
               "myforecasterpipe__myforecaster__estimator__C": [10,100]
              }
             ]

#grid search
gscv = ForecastingGridSearchCV(
            forecaster = pipe,
            cv=cv,
            param_grid=param_grid,
            verbose = 1
        )

#fit
gscv.fit(train_model, X = X_train)

Error:
ValueError: could not broadcast input array from shape (5,2) into shape (1,5,3)
I think the problem regards the inverse_transform of Differencer on exogenous variable used for validation, when we have to do prediction in validation set. But I don't understand why for forecasting horizon [1,2] it works.
Originally posted by @anthonygiorgio97 in https://github.com/alan-turing-institute/sktime/issues/2452#issuecomment-1100855032

I can confirm that the bug still exists with 0.12.0

FYI @anthonygiorgio97, moved one of the unresolved bugs to a new issue.

I will take a look at this bug!

Ah, interesting!
The original thread produced a similar bug:
https://github.com/alan-turing-institute/sktime/issues/2452
https://github.com/alan-turing-institute/sktime/pull/2487
In 0.13.0, the default of the na_handling param will change to fill_zero.

That would help ensure that X ends up being the correct length at the end of the pipeline for the final prediction.

I think the differencer is already doing that, the problem occurs in cases where there is no earlier time stamps to widen to. If you do backfilling, the result would be the same as fill_zero.
Having read the above, I'm not sure what the best action is. fill_zero default prevents the condition from materializing, but if the user chooses to shorten the X, the error message is not informative.
Questions one might ask:

is an action necessary at all? E.g., should a user know that the Differencer shortens series?
The Differencer docstring could be improved with a warning that certain parameter settings shorten the series, others create NA (and pipelining with an Imputer may be advised)
if a generic error message about index incompatibility should be raised, where should it be raised? Could be a warning along the lines of "transformer A does not guarantee same indices as output, but forecaster B requires same index set as input"?

I think the differencer is already doing that, the problem occurs in cases where there is no earlier time stamps to widen to. If you do backfilling, the result would be the same as fill_zero.

I guess it might be worth verifying that this works properly in the context of a pipeline or something as well?  For example - if Differencer is the third step in a transformer pipeline then we would want to grab the extra points for backfilling before the first step so they get properly transformed.

if a generic error message about index incompatibility should be raised, where should it be raised? Could be a warning along the lines of "transformer A does not guarantee same indices as output, but forecaster B requires same index set as input"?

Actually broader question related to this - is there a reason sktime doesn't make broader use of the logger class? This seems like it could be an appropriate time to log a warning, and then if there is some sort of error, I think the relevant warning (and tips) would print out with the error trace?

For example - if Differencer is the third step in a transformer pipeline then we would want to grab the extra points for backfilling before the first step so they get properly transformed.

Good point. Though, I can't see a way for this without "contextual awareness" of estimator, i.e., the Differencer being aware that it's being called within a pipeline and what the other steps are. Contextual awareness of estimators is imo one of many pathways to hell, can you think of a way that would not require it?

Actually broader question related to this - is there a reason sktime doesn't make broader use of the logging class?

I think it's a combination of laziness and lack of developer familiarity (e.g., I would think I have only beginner familiarity with logging).
With the "plumbing" layer in place, we could localize logging concerns there? Any good ideas, e.g., how a design might look like, and how it would materialize in this specific example?
Re this very bug: do you think it's solved by the changes to Differencer parameters, or is more action needed?

Good point. Though, I can't see a way for this without "contextual awareness" of estimator, i.e., the Differencer being aware that it's being called within a pipeline and what the other steps are. Contextual awareness of estimators is imo one of many pathways to hell, can you think of a way that would not require it?

I totally agree! I think my plan was not to make Differencer contextually away but pipelines!  ie - pipelines are aware of all the steps and in theory should be able to count the number of lost columns and adjust the input accordingly.  To me this seems like it could be an appropriate place to do so, then we could encourage anyone chaining together transformers/forecasters to use the pipelining features.  Or we go the pywatts route which is closer to everything is a pipeline? (even if just one step?)

Re this very bug: do you think it's solved by the changes to Differencer parameters, or is more action needed?

I think it is "solved" by no longer raising errors, but I suspect statistically it might not be doing what the original author intended... (due to the issues above) so I would potentially be hesitant to mark it as fully solved.  I have a potential workaround in mind that might not require changing the code base (but is in-elegant) by just splitting the pipeline into 2 parts - a transformer-style pipeline that reduces the dimension by 1 (ie starts out with fh one larger) and then feeding the output of that pipeline into a TransformedTargetForecaster which has the remainder of the original steps. Would need to check that it actually works before posting it as a solution.
As to logging, I think Lukasz has an example of what that might look like in sktime in his PR #2744. For this example I was thinking about logging a warning when the user uses the drop_na option that it might raise issues.  The idea would be to create a more informative error trace if there are issues down the road from making that choice

pipelines are aware of all the steps and in theory should be able to count the number of lost columns and adjust the input accordingly.

If that's the plan, then the components need to be able to tell the pipeline what the expected output size is, not just the format. E.g., "which columns will you lose"?
I was already thinking about giving transformers a method such as get_expected_cols(X) or similar, and one could have get_expected_rows, although I wonder whether it really adds sth above simply passing X to transform and looking at what comes out.

I have a potential workaround in mind that might not require changing the code base (but is in-elegant) by just splitting the pipeline into 2 parts - a transformer-style pipeline that reduces the dimension by 1 (ie starts out with fh one larger) and then feeding the output of that pipeline into a TransformedTargetForecaster which has the remainder of the original steps. Would need to check that it actually works before posting it as a solution.

I don't understand the proposed solution here. You would have some transformers separate? Based on what would we split the transformer chain? Can you explain? Perhaps also in one of the meetings, since it seems involved.

As to logging, I think Lukasz has an example of what that might look like in sktime in his PR https://github.com/alan-turing-institute/sktime/pull/2744. For this example I was thinking about logging a warning when the user uses the drop_na option that it might raise issues. The idea would be to create a more informative error trace if there are issues down the road from making that choice

Maybe it's also worth looking at the mock estimator(s) of @ltsaprounis which already log method calls?

So, I wanted to follow up on this issue, both to propose a solution to this specific problem, and to move the design questions which have come up as a result of this issue to a new more design-focused issue (#2880).
First, here is a proposed solution which works with our current code base.  Essentially one can pre-transform the data for all the steps up to and including the one which changes size.  Then you can continue with the rest of the pipeline as before.  One disadvantage of this solution is that it makes it harder to automate either including or not including the Log-Transformer with OptionalPassthrough  In the meantime I suggest the original user who raised this issue compare the best solutions available both with and without that transformer manually.  (and hopefully we will arrive at a cleaner solution soon)
from sktime.forecasting.compose import make_reduction, ForecastingPipeline, TransformedTargetForecaster
from sktime.forecasting.model_selection import ExpandingWindowSplitter, temporal_train_test_split, ForecastingGridSearchCV
from sktime.forecasting.fbprophet import Prophet
from sktime.transformations.series.adapt import TabularToSeriesAdaptor
from sktime.transformations.series.boxcox import LogTransformer
from sktime.transformations.series.compose import OptionalPassthrough
from sktime.transformations.series.difference import Differencer
from sktime.transformations.compose import TransformerPipeline
from sklearn import clone

from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVR
from sktime.datasets import load_longley

y, X = load_longley()

#split train/test both y and X
fh = [1,2,3,4]
train_model, test_model = temporal_train_test_split(y, fh = fh)
X_train = X[X.index.isin(train_model.index)]
X_test = X[X.index.isin(test_model.index)]

#preprocess the steps
pre_process_steps = [
    LogTransformer(),
    Differencer(),
]

y_transformed = train_model
X_transformed = X_train
for transformer in pre_process_steps:
    y_transformed = clone(transformer).fit_transform(X=y_transformed)
    X_transformed = clone(transformer).fit_transform(X=X_transformed)

#pipeline
pipe = TransformedTargetForecaster(steps = [
            ("scaler", TabularToSeriesAdaptor(StandardScaler())),
            ("myforecasterpipe", ForecastingPipeline(steps = [
                ("scalerX", TabularToSeriesAdaptor(StandardScaler())),
                ("myforecaster", make_reduction(SVR()))
        ]))
])

#cv setup
N_cv_fold = 1
step_cv = 1
cv = ExpandingWindowSplitter(initial_window = len(y_transformed) - (N_cv_fold - 1) * step_cv - len(fh),
                            start_with_window = True,
                            step_length = step_cv,
                            fh = fh)

param_grid = [{"myforecasterpipe__myforecaster__window_length": [2,3],
               "myforecasterpipe__myforecaster__estimator__C": [10,100]
              },
              {"myforecasterpipe__myforecaster__window_length": [2,3],
               "myforecasterpipe__myforecaster__estimator__C": [10,100]
              }
             ]

#grid search
gscv = ForecastingGridSearchCV(
            forecaster = pipe,
            cv=cv,
            param_grid=param_grid,
            verbose = 1
        )

#fit
gscv.fit(y_transformed, X = X_transformed)

As to more design minded questions - we are moving that discussion to a new issue (#2880), however in the meantime I suspect one reasonable solution may be that even though we are using these pipelines as forecasters, we might not actually need to trim X for the actual forecasting step until the final step which actually performs the forecasting?

@fkiraly, if you agree that the above solution is reasonable, maybe we can close this issue?

we might not actually need to trim X for the actual forecasting step until the final step which actually performs the forecasting?

Hm, not sure - I thought the issue is not so much with X being trimmed but being transformed into sth with a different index set. Where there is not a clear "not trimmed" option, since the result is not simply X at some sub-set of columns.

Yes!  Sorry, I think my initial message was unclear!
I wanted to just loop in the original poster of this bug @anthonygiorgio97 and bring you up to speed!
First off, wanted to thank you for bringing up this bug!  It has brought up some interesting design questions (as you can see).  We are having on ongoing design discussion as to how to address this problem in a more permanent way (#2880 if you would be interested in joining in!) but in the meantime have found a temporary workaround solution that might work for you! (it is located in the comment 3 above this one!).  Main takeaways and things to be aware of:

This work around doesn't allow you to do full tuning of any transformers not in TransformedTargetForecaster.  In order to try out both including and not including LogTransformer like you were originally trying to do I would recommend comparing the performance of the best tuned models while either applying that transformer (as in the text above) or commenting it out.
A better solution is in the works - though it might be a while before it gets fully resolved.  We intend to update this issue when the matter gets fully resolved.

Please let us know if you have any further questions, ideas or complaints about this issue in the meantime though! :)


Workflow search queries APIs

Describe the solution you'd like

I would like to use the Java SDK to query [elasticsearch] for open workflow executions like in Go: https://pkg.go.dev/go.temporal.io/sdk/client#Client.ListOpenWorkflow.
I'm sure that other workflow search queries would be useful here too.

Describe alternatives you've considered

query elasticsearch directly

Additional context
Add any other context or screenshots about the feature request here.

Edit: Apologies, found updates right after posting: https://github.com/temporalio/samples-java/blob/16982c43266d4ae3abfa7009fb3a188d1fa11c1a/src/test/java/io/temporal/samples/listworkflows/ListWorkflowsTest.java

Closing as duplicate https://github.com/temporalio/sdk-java/issues/1552


JAX Tracer error when trying to plot_response_curves()

Hi,
Everything seems to be running smoothly - getting good results and am able to run plot_media_channel_posteriors(), plot_model_fit(), plot_out_of_sample_model_fit(), plot_media_baseline_contribution_area_plot() and plot_bars_media_metrics().
However, when I try to chart the plot_response_cruves:
plot.plot_response_curves(media_mix_model=mmm, media_scaler=media_scaler, target_scaler=target_scaler)
I'm hit with the following exception:
---------------------------------------------------------------------------
UnfilteredStackTrace                      Traceback (most recent call last)
[<ipython-input-50-456180661661>](https://localhost:8080/#) in <module>
----> 1 plot.plot_response_curves(media_mix_model=mmm, media_scaler=media_scaler, target_scaler=target_scaler)

45 frames
UnfilteredStackTrace: jax._src.errors.TracerIntegerConversionError: The __index__() method was called on the JAX Tracer object Traced<ShapedArray(int32[], weak_type=True)>with<DynamicJaxprTrace(level=3/0)>
See https://jax.readthedocs.io/en/latest/errors.html#jax.errors.TracerIntegerConversionError

The stack trace below excludes JAX-internal frames.
The preceding is the original exception that occurred, unmodified.

--------------------

The above exception was the direct cause of the following exception:

TracerIntegerConversionError              Traceback (most recent call last)
[/usr/local/lib/python3.9/dist-packages/jax/_src/numpy/lax_numpy.py](https://localhost:8080/#) in _chunk_iter(x, size)
   5219
   5220   This object references a source array and a specific indexer into that array.
-> 5221   Methods on this object return copies of the source array that have been
   5222   modified at the positions specified by the indexer.
   5223   """

TracerIntegerConversionError: The __index__() method was called on the JAX Tracer object Traced<ShapedArray(int32[], weak_type=True)>with<DynamicJaxprTrace(level=3/0)>
See https://jax.readthedocs.io/en/latest/errors.html#jax.errors.TracerIntegerConversionError

I tried downgrading both the matplotlib version as well as the jax/jaxlib as per another issue posted a month ago, but nothing seems to be working.
Any ideas?

I've tried it, but didn't think of restarting the environment again - seems to be working now!
However, I'm getting barely usable plots:


Use ${project.groupId} instead of deprecated ${groupId}

${groupId} and ${artifactId} are deprecated and cause the following warning during the build:
[WARNING] The expression ${groupId} is deprecated. Please use ${project.groupId} instead.
[WARNING] The expression ${artifactId} is deprecated. Please use ${project.artifactId} instead.

Codecov Report

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

@@            Coverage Diff            @@
##             master     #975   +/-   ##
=========================================
  Coverage     94.71%   94.71%
  Complexity      414      414
=========================================
  Files             2        2
  Lines          6093     6093
  Branches       1613     1613
=========================================
  Hits           5771     5771
  Misses           90       90
  Partials        232      232

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 cf888c5...ea3b0bf. Read the comment docs.

Your changes are now live.
Thank you for the contribution!

Wonderful, thank you!


Consider supporting parsing Date from seconds to epoch value

So we can parse<PHONE_NUMBER> to Thursday, Aug 16, 2018 12:39:58AM GMT.

Isn't this already provided by JSON.Decoder.DateDecodingStrategy.secondsSince1970 and JSON.Encoder.DateEncodingStrategy.secondsSince1970?

I wasn’t aware of strategies. How do I use them? Or I’ll look at doc later today.

Exactly the same way it works with the standard library's JSONDecoder and JSONEncoder; namely, the decoder and encoder have properties you can assign to such as JSONDecoder.dateDecodingStrategy to control the strategy for that particular decoder/encoder instances (they have properties for date, data, and the key decoding strategy).

I ended up using PMKUtilities.JSONDecodable protocol extension and added a convenience method (getDateSecondsSince1970(_:)) for taking care of this.
I tried to use the decoder, but it wasn't what I needed. I just wanted a simple call json.getDate(...). Using this strategy meant creating decoder, get the JSON value, unwrap it, call this method for just one value when all other values I could deserialize with a simple call like above.

Oh I see what you were asking for now.
I'm going to go ahead and close out this ticket. The core JSON behaviors are all about manipulating JSON data, and you're supposed to wrap them if you want to convert non-JSON types (such as Date) to/from JSON. JSON.Decoder and JSON.Encoder are the built-in mechanisms for converting non-JSON types to/from JSON, and those mechanisms already support what you're asking for with Dates. So if you want to have a convenient way to convert a Date to/from JSON, and you're not using JSON.Decoder or JSON.Encoder, then you should just extend JSON yourself to handle this.


Ace code editor

This PR add a panel of type code editor
It's based on this library https://github.com/ajaxorg/ace/
I have activated the language and theme selection
basic autocompletion with ctrl+space
and possibility to add anotations

@xavArtley I'd be happy to merge this once there is a reference gallery entry. At some point we will have to have a discussion which components make sense in panel itself and which could be added somewhere else.

Indeed I think this model should be external to panel more in some custom extensions

We'll need to work out a plan for managing external components like this.

I'm actually happy to merge this now and move it later if we decide on a repo to extend panel. Does that sound okay @xavArtley ?

Ok for me


Support custom Cypress tests in CI/CD

What are you trying to accomplish? Please describe.
We'd like to be able to add our own Cypress tests to our FastStore projects. There's no barrier to us doing that, but the tests do not get pulled into the CI/CD test run.
What have you tried so far?
Based on some local testing, a change to the faststore Cypress config file (see line 9 below) pulls in our custom tests along with the existing FastStore tests when running the tests from the .faststore directory. My assumption is that this small change might mean the tests would also get automatically pulled into the CI/CD test run?
There might be a better way to do this, and the interface in the Cypress app becomes admittedly a little clunky with all those nested folders.
Would you consider this change, or do you already have plans to support including customer Cypress tests in CI/CD?
Additional question
Also wondering if you have plans to upgrade to the latest Cypress version (v12)?

Adding a follow-up question to ask about the overall plan for E2E testing in FastStore — the existing Cypress tests in FastStore are currently broken in our demo repo (ex: Some analytics tests assert a certain number of products are visible, but our catalog setup means that assertion is false). This approach where tests are dependent on catalog setup, and where the customer can supposedly completely customize their storefront without the ability to change the tests, doesn't seem ideal.
Should we expect changes to the E2E testing approach in FastStore?
We'd also like to get the issue with the breaking tests resolved in the meantime so we can get back to a passing build state in our FastStore demo instance, and to make sure our QA instance doesn't end up with the same problem.

Regarding the update of Cypress, it has not yet been prioritized by our team but we've taken note 📓.

@gvc Thanks for the new enableCypressExtension flag! I have been testing it out and it does seem to give us a path forward for including our own custom tests, but I wanted to share a little initial feedback on a few issues I've encountered:

The new docs suggest test files should be located in cypress, but to run those tests locally, I need to add "integrationFolder": "cypress" to the Cypress config file since the cypress open command looks for tests in cypress/integration by default. If locating tests in just cypress will remain the convention, I think that workaround should be documented as any user will want to run tests locally first.
In our custom test files, I haven't found a way to import from the Faststore config file (to use the page URLs stored there) that works both locally and in CI. We can work around this by storing URLs locally in the file, but a user who looks at the OOTB tests for examples may see your pattern of importing from the config file and run into the same problem.

Since the existing issue where the OOTB Faststore Cypress tests are currently failing for us due to catalog differences, we now have to add empty/dummy test files to overwrite the OOTB tests and get to a passing test run, which doesn't seem like a very clean pattern. Have you considered a fix where we can turn off all of the OOTB tests with another flag or config change instead?

Thank you so much for leaving this initial thoughts about this experimental feature 🤩

I think we should keep the default cypress/integration. We'll change it.
🤔 We'll take a look into this issue
The inclusion of a disabled configuration is currently not in our plans. We'll prioritize improving our OOTB tests, refining and making the tests more versatile to avoid this problem.

Please don't hesitate to share additional feedback as you explore this feature. It will help us to improve it. 🚀 🚀 🚀

Hey @erinmorrissey-hearst 👋🏼
First of all, thank you for the feedback, it was very important for us think and discuss deeply about these Cypress-related improvements.
Regarding your points, we improved our documentation in #2080 to inform the correct location where custom tests should be, the cypress/integration folder. We also have the #2092 with more documentation improvement being reviewed and merged soon to give you a way to exclusive execution of your custom tests (ignoring the OOTB tests), but you will only be able to do this with Cypress 12.
FastStore already has the feature flag to enable Cypress 12, you can enable this in your faststore.config file inside the experimental section by adding the cypressVersion: 12. After that, you can follow the official Cypress guide to replace your cypress.json with the new cypress.config.ts file. We did the same for our Starter store here.
Then, just rename the folder where all of your custom tests are from cypress/integration to cypress/e2e, the Integration tests check will run only for your custom tests.
If you have any other questions, don't hesitate to answer here, we will wait for your feedback 😉

Thanks @lucasfp13! We did upgrade to Cypress v12 a few weeks back and just pushed some changes to successfully bypass the OOTB Faststore integration tests using the folder rename approach.


Invert usage of @UseJdbc

Apply to superclass SQLTransportIntegrationTest of integration tests
and override where necessary.

Codecov Report

Merging #6280 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #6280      +/-   ##
============================================
+ Coverage     83.17%   83.23%   +0.05%
+ Complexity    12825    12819       -6
============================================
  Files          1479     1479
  Lines         48506    48506
  Branches       5924     5924
============================================
+ Hits          40344    40373      +29
+ Misses         5399     5364      -35
- Partials       2763     2769       +6

Impacted Files
Coverage Δ
Complexity Δ

...n/java/io/crate/exceptions/JobKilledException.java
0% <0%> (-66.67%)
0% <0%> (-1%)

...in/java/io/crate/lucene/match/CrateRegexQuery.java
43.47% <0%> (-30.44%)
4% <0%> (-4%)

.../java/io/crate/exceptions/ValidationException.java
57.14% <0%> (-14.29%)
2% <0%> (-1%)

...n/java/io/crate/planner/projection/Projection.java
90% <0%> (-10%)
6% <0%> (-1%)

...crate/planner/projection/MergeCountProjection.java
63.63% <0%> (-9.1%)
5% <0%> (-1%)

...main/java/io/crate/blob/v2/BlobIndicesService.java
68.05% <0%> (-5.56%)
20% <0%> (-2%)

...xecutor/transport/TransportSchemaUpdateAction.java
83.87% <0%> (-4.84%)
13% <0%> (-2%)

.../projectors/BatchIteratorBackpressureExecutor.java
92.53% <0%> (-4.48%)
17% <0%> (-1%)

...otocols/postgres/RetryOnFailureResultReceiver.java
88.46% <0%> (-3.85%)
10% <0%> (-1%)

.../operation/udf/DropUserDefinedFunctionRequest.java
91.42% <0%> (-2.86%)
10% <0%> (-1%)

... and 24 more

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 6289817...a40a001. Read the comment docs.


A more constrained link definition in message objects

per discussion on irc,
The rel attribute on links seems burdensome when we can just put links in sub-objects and infer the rel-type from the attribute name. I believe @dominictarr feels the same.
We discussed -and I now propose -we restrict links from appearing in the top object, and remove the rel attribute instead. A sub-object will then be determined to be a link by looking for feed, msg, and ext, which may be used in any combination on the sub-object. The relation type will be the key of the sub-object in its immediate parent.
For example, this message --
  "content": {
    "type": "post",
    "text": "hello @dominic",
    "repliesTo": {
      "msg": "xhoAEBPnmEN2+kfTYrUrb6G0Q/Nc7x9lc0WB9UskoGk=.blake2s",
      "rel": "replies-to"
    },
    "mentions": [
      {
        "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s",
        "rel": "mentions",
        "name": "dominic"
      }
    ]
  }

changes to--
  "content": {
    "type": "post",
    "text": "hello @dominic",
    "repliesTo": {
      "msg": "xhoAEBPnmEN2+kfTYrUrb6G0Q/Nc7x9lc0WB9UskoGk=.blake2s"
    },
    "mentions": [
      {
        "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s",
        "name": "dominic"
      }
    ]
  }

In this case, it is structurally similar -- it's only dropped the rel. Other messages will have to change structure. For instance:
"content": {
  "type": "follow",
  "rel": "follows",
  "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s"
}

Will become
"content": {
  "type": "follow",
  "follows": {
    "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s"
  }
}

--
As an aside, I'm also considering a semantic refactor for the message types, in which case follow may become something more like:
"content": {
  "type": "follow",
  "newFriend": {
    "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s"
  }
}
// and for unfollow:
"content": {
  "type": "unfollow",
  "oldFriend": {
    "feed": "wuDDnMxVtk8U9hrueDj/T0itgp5HJZ4ZDEJodTyoMdg=.blake2s"
  }
}

But that's not related to this topic (unless we want it to be)

+1 on posts and mentions.
Should we make the relations more generic? like, post could use append.msg = <post_id> or updates.msg = <post>
that could be then used in any object type which works by appending?
For other data structures, I'm thinking about this:
var task = { //first task
  type: 'task'
  ...
}

{
  type: 'taskmod',
  object: hash(task),
  updates: hash(task)
}

A thread could be considered an aggregation of messages, like any other datastructure...
using generic properties to represent this simplifies scemantics, and indexes.
So we could use object and updates on posts... the only thing about posts/threads being that they are updated by appending, instead of merging...
Likewise, a follows message is really about creating or deleting a link between you and another feed.
In this way, it's simpler to have just one message type (follows) which can be either positive or negative - we can retrive it with one query, and just aggregate the messages (unfollows just looks like type: 'follows', follows: {feed: <id>, retracted: true})
It reads less like english, but it means there will be less code...

I like the idea of using more generic relations, but I think we need to be careful.
I wouldn't want to use updates for a reply because it's not inconceivable that we add message edits (even if we don't plan to now) in which case updates would be my natural choice.
I'm ok with using only one type -- I think we can keep it readable with the rels.
For instance, what about...
{ type: 'follow', followed: { feed: ... } }
{ type: 'follow', unfollowed: { feed: ... } }
{ type: 'trust', trusted: { feed: ... } }
{ type: 'trust', untrusted: { feed: ... } }
{ type: 'trust', flagged: { feed: ... } }
{ type: 'trust', unflagged: { feed: ... } }
{ type: 'name', name: 'bob', assignee: { feed: ... } }
{
  type: 'post',
  text: 'this is a reply',
  root: { msg: ... }, // top of thread
  parent: { msg: ... }, // immediate parent
  mentioned: [{ feed: ... }],
  attachment: [{ ext: ... }]
}

if there are two rels that is a more complicated index, or two queries merged.
{ type: 'trust', trust: { feed: Y } }
{ type: 'trust', trust: { feed: Y , revoke: true } }

then we can just query all feed relations from X to Y, via an index on trust.feed, or even check whether X trusts Y with just a single query.
@pfraze hmm, when I said updates i was thinking about something that was part of the "object" but joined the object after the message it updated. maybe it would be better to call that appends?
It's more about representing the causal order, so that we can detect consistency.
The more important thing is actually the object link, because that is about retriving all the messages that mutate that object (the thread, in the case of posts). Then we need the causal ordering link, by the time we are making a distinction between adding a comment, and updating a comment, that it certainly an application level concern.

then we can just query all feed relations from X to Y, via an index on trust.feed, or even check whether X trusts Y with just a single query.

Ok, that's sound

It's more about representing the causal order, so that we can detect consistency.

That's inherent in links, the relation semantics are orthogonal.

The more important thing is actually the object link, because that is about retriving all the messages that mutate that object (the thread, in the case of posts).

I agree, but I prefer root to object and parent to updates or appends because they represent the tree structure more specifically while remaining generic.

by the time we are making a distinction between adding a comment, and updating a comment, that it certainly an application level concern.

Yes but relation semantics are application semantics. It's not a huge issue (on par with "what to name this api function") but I think root and parent are more clear.

@pfraze okay I'm on board with root and parent.

@pfraze on second thoughts, root and parent mixes vocabulary, root from trees, and parent from lineage.
should be: root branch leaf or ancestor parent child. I'm in favor of root/branch/leaves

I do appreciate the consistency. My argument for root and parent is that's the same semantics used in the unix file-system to indicate ancestor directories.

right. I needed to extend the metaphore, and talk about the dangling ends of the tree. git calls these "heads".
what has a Root, Parents, and Heads???
Root, Branches, and Leaves is way more sensible

:deciduous_tree: :+1:

Ok, let's get started on this monster! I think I can do this without breaking backwards compatibility, but that would mean our standard is a blend of the two approaches: basically, that rel is optional, and (let's say) takes priority over the keyname. Does that sound ok, or would we rather break backwards compat?
As for the updates, I'm going to hit https://github.com/ssbc/ssb-msgs to support this new scheme. I'll update https://github.com/ssbc/secure-scuttlebutt as needed after. Then, I'll update https://github.com/ssbc/ssb-msg-schemas, and then phoenix and my personal apps. Did I miss anything?

@pfraze I think we can skip full backwards compat, and maybe limit it to backwards compat with what phoenix actually does, but not what the code does? so it's compatible with how the code was used, but not everything that it could do. This works because we happened to use <rel>: {msg, rel: <rel>}* anyway
*excusing camel casing.

@dominictarr almost -- some messages do, but we've got a lot of messages shaped like this:
{ type: 'follow', rel: 'follows', feed: $hash }

oh. if we make it back compat we  will have to carry that code around forever, and we have only just start, and there are only like 20 people who have installed this? we can just refollow them.

Ok. So everybody understands, this change will cause you to lose the following data:

Follows
Trusts
Flags
Names given to other users

@dominictarr shall we do a deep search for links, or must links be subobjects of the top object?
I propose the latter, such that links are either in the form:
{ type: 'type', myLink: { feed/msg/ext: ... } }

or:
{ type: 'type', myLink: [{ feed/msg/ext: ... }] }

I also propose that the link type is case-insensitive, and that all handling code lowercases the rel before processing it.

+1 for proposed form, that's JSON-LD. :octopus:
i think we shouldn't worry about back compat, but this does bring up the delightful question of ssb data migrations, which would allow us to change the structure of our data without losing data and without having to worry about back compat.

@ahdinosaur in this case, we'd need an active migration, where clients must republish old content in the new form. We can't do it in general because we can't recreate someone elses signature.

@dominictarr ah true, hmm.

@ahdinosaur dominic's correct, but we can still write a migration tool, which I plan to do https://github.com/ssbc/phoenix/issues/341

@dominictarr this has been fully implemented, close issue?


Add count up from specified date and time option

See also Add an infinite count-up timer option #124.

So this enhancement would behave more like a live uptime status by feeding it an accepted standard datetime formatted string or a fuzzy datetime string we can understand. From there Hourglass, could just perform a difference from the local time (unless there's a fancy option to diff on time zones later) and display time remaining.

A simple way would be a "now" option which would start it from the moment you hit "now" and punch in the current datetime
A datetime in the past would display time elapsed since that date in years, days, hours, minutes, seconds.
A datetime in the future could display a countdown until that datetime is reached, and once elapsed could continue running a "since…" in years, days, hours, minutes, seconds.


Reducing Gold requests on post-submit Cirrus shards

Description
This PR adds another condition for the FlutterSkippingGoldenFileComparator.
Prior to https://github.com/flutter/flutter/pull/43371 landing, the FlutterSkippingGoldenFileComparator was a catch-all for tests that did not meet the conditions of post-submit testing. Now that Gold is supported locally, the FlutterLocalFileComparator is the catch-all, and is running unnecessarily on some Cirrus shards in post-submit.
Tests
FlutterSkippingGoldenFileComparator determines the correct testing environment.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I signed the CLA.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] All existing and new tests are passing.
[ ] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[ ] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] No, this is not a breaking change.

FYI @kjlubick 🙂

Skipping the tests is scary... I worry that someone is going to switch us to LUCI or some other environment and not know that they should be enabling these tests. (I did something similar in skipping the CI tests on LUCI.) We're basically saying that the tests on LUCI aren't really running.
cc @godofredoc @dnfield
Anyway, LGTM.

I've been told we are waiting on more mac capacity to be able to support LUCI, but once we have it, I can enable them.  I've also been advised the same for mac pre-submit checks that are currently not running at all and therefore are also skipped. :(
For reference: Comments on cirrus.yml during and early version: https://github.com/flutter/flutter/pull/40710/files/6945396148e0c3a706f0db440183f32fc99a4f79
This pilot run with Gold is further limited by api performance right now, so I have tried to keep it as lean as possible, preferring more platforms over multiple runs on a single platform which is what we had before.

Thank you for the feedback! I am going to merge this with https://github.com/flutter/flutter/pull/43748, which is also looking to land a gold adjustment based on feedback and has some overlap with this change.
It will also prevent a delay in landing this performance boost due to a self-inflicted merge conflict later. 😝


A new branch has created

Create a new branch for this commit and start a pull request

merge commits: branch closed.

add comment. merge and close

merge and close


using the disable or enable method with select2 doesn't change the disabled property of the element that it's replicating

if I have select2 on an input hidden, and then use the select2 method to disable, the input hidden still remains enabled.
my thinking says that if your disabling / enabling select2, then whatever element it's attach to should also be disabled / enabled.
this came up when I was running a check to determine if the element itself was disabled. If there's a different way to check if select2 is either enabled or disabled for a particular element, I could use that as well.

Blowing the dust of this topic, It's still happening for me, anyone else experiencing issue's?

@notflip, As of Select2 4.1, they've removed support for .enable
$("select").prop("disabled", true); // instead of $("select").enable(false);

Hello
I found this way.
$('#descJugador').select2('val', this.id);
$('#descJugador').select2('data').disabled = false;
$('#descJugador').select2('data', null);
If you do that, the select2 refresh the value dynamically


Add new models

Hi! I'm so glad that I can contribute to the awesome package.
I've added the following new models introduced on June 13, 2023.

gpt-3.5-turbo-0613
gpt-3.5-turbo-16k
gpt-3.5-turbo-16k-0613
gpt-4-0613
gpt-4-32k-0613

You'll want to update the wasm bindings as well to make this work.
See https://github.com/zerfl/tiktoken/commit/7ed984eed3ec2b7d15b35a2eeb09278cfd16af03#diff-3920f5b0c1e7a80683f05ae43cb02274ad7d418643021a88b4cf765008c79779

Looks fine to me! Thanks @rodumani @zerfl!

The new models are missing from typescript definition. See
export type TiktokenModel =

in wasm/src/lib.rs


Questions after testing marswm briefly (i saw a snazzy post on r/unixporn).

In marsbar --help:

marsbar 0.4.1
jzbor
Task bar for marswm (and other EWMH-compliant window managers)

USAGE:
    marsbar [OPTIONS]

OPTIONS:
    -c, --config <CONFIG>         Print current config and exit <-- is this wrong?
    -h, --help                    Print help information
        --print-config            Print current config and exit
        --print-default-config    Print default config and exit
    -V, --version                 Print version information

why is the internal workspace number not the same as the number displayed on marsbar?

e.g. workspace 0, default keybinding Mod4+1, displayed on marsbar as 1

what about the workspace handling of marsbar is "like i3"?

i3 has dynamic workspaces, there are practically infinite and arbitrary in number (signed 32bit integer)
marswm has predefined workspaces for screens, always visible on marsbar

Also for anyone on NixOS, you can use this derivation for installing:
{
  lib,
  fetchFromGitHub,
  rustPlatform,
  libX11,
  libXft,
  libXinerama,
  libXrandr,
  pkg-config,
  xorgserver,
  ...
}:
rustPlatform.buildRustPackage rec {
  pname = "marswm";
  version = "0.4.1";
  src = fetchFromGitHub {
    owner = "jzbor";
    repo = pname;
    rev = version;
    hash = "sha256-IQtojvheZEmuQZNycCN01PPAdGdt/BT6h7mr7ZpwXbo=";
  };
  cargoHash = "sha256-CLoBzwx9r+Yy4tfBjPKxsjuTagHyZywepAUlJh2hXvo=";
  buildInputs = [
    libX11
    libXft
    libXinerama
    libXrandr
    pkg-config
    xorgserver
  ];
}

I might add marswm to nixpkgs, once the simple-package-paths rfc gets merged.

* why is the internal workspace number not the same as the number displayed on marsbar?

Hm I understand why this might be irritating, but I think it is quite normal to expose collections as one-indexed to users while handling it as zero-indexed internally and in APIs.

* what about the workspace handling of marsbar is "like i3"?

  * i3 has dynamic workspaces, there are practically infinite and arbitrary in number (signed 32bit integer)
  * marswm has predefined workspaces for screens, always visible on marsbar

This refers to marswm using workspaces rather than tags like dwm does. I figured not everybody might get the different, so I added i3 as an example that also uses workspaces. You are right unlike i3 marswm does not dynamically allocate or deallocate workspaces. Although it would probably not be to difficult to change I would much rather change the bar to only display occupied workspaces. One other thing marswm does similar to i3 is allocating dedicated workspaces for each monitor, although again unlike i3 those workspaces have "special" names.

Also for anyone on NixOS, you can use this derivation for installing:
[...]

Thanks for sharing. You can also find a nix overlay in my personal overlay flake. It will not always be the released version, but rather the version I personally find most useful at the time, so not exactly stable.

I might add marswm to nixpkgs, once the simple-package-paths rfc gets merged.

I also already thought about this, although until now I did not really see the significance. Does nixpkgs require a maintainer to approve/register for the package? Anyway feel free to ping me if you plan to create a pull request.
I hope this answers some of your questions :)

I understand why this might be irritating, but I think it is quite normal to expose collections as one-indexed to users while handling it as zero-indexed internally and in APIs.

I've never used dwm but, this wasn't strange to me in anyway. I've used frankenwm for a long time and it handles workspaces in the same way. Originally, it supports 10 workspaces, which makes it even more confusing, since workspace 10 is bound to Mod4 + 0 but, workspace 1, which is actually 0 + 1 is bound to Mod4+1 😀
@Quantenzitrone Glad you liked my "pink" Rice 😉

wouldn't it be better then to compare the workspace handling to a different wm?
i don't know much about a lot of window managers, but i think most wms do it like marswm
e.g. bspwm awesomewm hyprland


belindas_closet_android_3_209_fix_all_product_nav_on_admin_page

resolves #209
Now after you log in and are taken to the Admin Page, clicking the "all products" button routes to the page with product categories

Not sure why this keeps happening and we'll definitely look into it but so far using the following git commands are working for people:
git commit --amend --no-edit
git push --force-with-lease

This is a way to push an empty commit to trigger a re-build and hopefully the check won't hang up.


Example: Running previous test runnable and not needing to return
the cursor to the function position.

Would love feedback on this feature. Things like where should it be, how things are named, configuration options, and any other feedback. I put it into the hover menu because that's what I started to use, but there's also runnables.lua where this may work better or in addition to hover_actions.lua.
Thank you!

Thanks for the PR, looks mostly good to me, but:

I think we should always cache (not super expensive)
And add a command to run the last runnable

Also, would it be possible to rework this to merge this into the modularize_and_inlay_rewrite branch as I'm planning to merge that into main very soon

Ok, can do those.
I have been using this branch for a while, and it's mostly good, but it also catches undesired effects and causes them sometimes to fire off unexpectably.
For example,

tests runnables work great
go to definition seems to be a runnable that is captured
but debug doesn't seem to run again (I have something else that correctly debugs the last one though)

So in the short term it might be good to not make it a general "last_runnable" but limit it to test runnables, specifically the ones for the test functions. My question is, should we expand the API to have specific types of runnables, and commands for those,
:RustLastTest
:RustLastDebug
:RustLastRunnable

or filter RustLastRunnable to not include go to definition type things and make debugger work with :RustLastRunnable.
:RustLastRunnable

Mostly want to pin down the API before a release that is consistent. Thank you, I will post a pull request to that branch.


Issue/5211 optional embedded

Description

Short description here *

closes #5211
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Code is clear and sufficiently documented
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

Processing this pull request


Add event API to allow low-level events (e.g. input)

As per our discussion on Slack I'd like to propose that Ebiten exposes the low level events it receives from the underlying platform (key presses, joystick, etc) in a separate package "event".
Arguments in favor:

It's more efficient than converting the state based API.
It's easier to use for certain applications, such as GUI's.
In some cases it's more correct.

The API could be something like it is in Allegro, https://liballeg.org/a5docs/trunk/events.html,  but without the C-ism like unions and an event queue, which could be replaced simply with a Go channel.

Thanks! I agree to introduce a new package for lower level input. The existing input APIs would rely on the new 'event' package.
Note that gomobile has an event system by channels: https://godoc.org/golang.org/x/mobile/app
I'll reply more details about your idea later.

My assumption is that all event, not only inputs but also e.g., updating frames, should be in the same event loop, so the event package would treat all such events. (and the existing APIs would be the wrapper).  Do you think it'd make sense?

Yes, that makes sense. All events should be handled in the same loop. In Allegro we also have things like timer events, or events when the screen becomes not drawable, etc. The existing APi is the wrapper, and if you like, you can also request that the events are not sent only to the wrapper but also directly to your own channel.
Yes, the design of the event system could probably look like it is in x/mobile/app , although the events would be a bit more high level (wrapping the platform specific events).  In that library there are events for lifecycle, mouse, paint, size, touch. We will also need events for joystick, keyboard, window. Perhaps timers are not needed as Go already provides these.

Thanks. We're now on the same page :) Then, what we should do will be:

Rewrite driver.UI, driver.UIContext, driver.Input, (e.g., https://github.com/hajimehoshi/ebiten/blob/master/internal/driver/ui.go) event-based
Rewite all the driver implementation
Create the new package github.com/hajimehoshi/ebiten/event to use the new driver API
Rewrite the existing package github.com/hajimehoshi/ebiten to use the event package

Could you write a doc about your suggestion of the new API in 'event' package?

It's easier for me to write some code than a design document, so I wrote this documented code in the hope it will be clear enough to show what I mean.  Feel free to make suggestions, the file is here:
https://github.com/beoran/ebiten/blob/beoran-event/event/event.go

Hi, thank you for your suggestion! I looked through and would like to point out:

Is there a reference you used to define event types?

Web API might be the most portable.

Let's add game-updating event (KindGameUpdate) that calls the registered function to update the game state

DisplayPaint is similar but Ebiten can call the function multiple times for one display update.

Let's use a standard time.Time instead of Timestamp
Rename Code -> KeyCode, Modifier -> KeyModifier, and so on
Rename Joystcick -> Gamepad
Rename Axis -> GamepadAxis, Button -> GamepadButton, and so on
Display events will be necessary but sound hard to define so far. Could we skip defining them for now and consider them later?

I prefer the word 'View' to 'Display', but this is controversial. 'Display' might be confusing with physical monitors.
Ebiten doesn't have 'orientation' change events.
It is now chaos how Ebiten apps treat screen-size changes.

Apps on desktops and browsers assume that the screen size never changes unless SetScreenSize is called.
Apps on mobiles assume the same thing, and if the outer view (a GL surface)'s size is changed, the scale is adjusted automatically (when ebitenmobile command is used).

Application lifetime is not determined.Could we skip defining application events for now and consider them later?

Mobiles and browsers don't have 'destroy'.

I don't think we have to define a type for a channel.

Let's add game-updating event (KindGameUpdate) that calls the registered function to update the game state

DisplayPaint is similar but Ebiten can call the function multiple times for one display update.

On second thought, as event should be the lower-level layer, DisplayUpdate (or other names like FrameUpdate) sounds better and the user of event package should calculate how many times the update function is called 🤔

I have updated the file based on your suggestions:
https://github.com/beoran/ebiten/blob/beoran-event/event/event.go
To answer your questions:

I used Allegro as the reference since it has all useful events I can think of.
I made an event type KindViewUpdate, that could be used as you suggest.
I used time.Time everywhere.
I added prefixes for the struct member types everywhere, for Key, Mouse, Touch, Gamepad.
I used Gamepad everywhere.
Did that too as you suggested.
I renamed Display to View, and removed the KindViewOrientation event, but kept the KindViewResize event since you will need that to adjust the scale automatically on a higher level.  We can define other View events as the need arises.
I dropped all Application events, we can define them later if needed.
I removed the channel type
I added a TouchID, and renamed Which to GamepadID as well, for consistency.

Hope you will like my changes and answers. :)

Thank you!

I renamed Display to View, and removed the KindViewOrientation event, but kept the KindViewResize event since you will need that to adjust the scale automatically on a higher level. We can define other View events as the need arises.

OK I agreed.

Can we have Basic struct without Any struct?

Thank you!

I renamed Display to View, and removed the KindViewOrientation event, but kept the KindViewResize event since you will need that to adjust the scale automatically on a higher level. We can define other View events as the need arises.

OK I agreed.

What is the Source object? What kind of object is there?
Do we really need Time attribute at Basic? Wouldn't the time when receiving enough?
Do we really need Event interface? I think we can eliminate Any struct from Basic struct. Any doesn't sound idiomatic in Go, but perhaps I might not know the idiomatic.
We don't use Z/W positions of mice.
When do we use NewChannel? I thought the loop would be like:

for := range  {

}

Thank you!

I renamed Display to View, and removed the KindViewOrientation event, but kept the KindViewResize event since you will need that to adjust the scale automatically on a higher level. We can define other View events as the need arises.

OK I agreed.

What is the Source object? What kind of object is there?
Do we really need Time attribute at Basic? Wouldn't the time when receiving enough?
Do we really need Event interface? I think we can eliminate Any struct from Basic struct. Any doesn't sound idiomatic in Go, but perhaps I might not know the idiomatic.
We don't use Z/W positions of mice.
When do we use NewChannel? I thought the loop would be like:

app.Main(func(eventCh chan Event) {
for e := range eventCh {
  if e.Kind() == KindMouseEnter {
    // ...
  }
}

I updated the file again.
To answer your questions:

Source is for the event's low level source, i. e. the driver. I included it because my experience from Allegro shows that it can be useful to have a reference to that.
Time is the time when the event was /emitted/. It's possible that some events are too slow in and will need to be discarded. I copied this from Allegro.
Event needs to be an interface for type safety and to allow users to reuse the interface to send their own events. This is very useful for GUI systems. But it's true we don't need the Any sub struct so I solved this in a different way.
I dropped Z and W, although maybe mouse wheel would be useful later.
You are right, we will probably not need this function, so I dropped it.

Thank you!

Source is for the event's low level source, i. e. the driver. I included it because my experience from Allegro shows that it can be useful to have a reference to that.

I understood you referred Allegro, but let's remove this until we find an actual use case. I don't want to expose a driver things of Ebiten.

Time is the time when the event was /emitted/. It's possible that some events are too slow in and will need to be discarded. I copied this from Allegro.

Ditto.

Event needs to be an interface for type safety and to allow users to reuse the interface to send their own events. This is very useful for GUI systems. But it's true we don't need the Any sub struct so I solved this in a different way.

Let's revisit after we solve the above items.

OK, I updated the file again. I left out Source and Time, and renamed the method Kind in the event interface to EventKind, so Basic can simply have a Kind member.  I also added a TouchPressure member to the Touch event, and removed DZ and DW.
I am still convinced that Event needs to be an interface as there are no C-like unions in Go. The best way in Go to simulate unions is to use an interface.

Thank you for fixing the proposal again and again!

We no longer need Source interface.
Do we need Z/W position for mouse?

I am still convinced that Event needs to be an interface as there are no C-like unions in Go. The best way in Go to simulate unions is to use an interface.

I think there is still room for discussion. As the interface now has only 'EventKind', if we had another way to determine the kind of an event, we would no longer need the interface.
Could we determine the event type by type assertion instead of a kind value? If you need a custom event, you would need a new kind value that is never duplicated with existing value. Even if you could create a new kind value that is not duplicated with other existing events, other people might add a new kind that can duplicate with yours... On the other hand, type assertion way can avoid this problem completely.
What do you think?

I made another more "radical" change this time, so type switches or type assertions wi work. I still kept the Event interface with a marker method IsEvent, because I dislike the empty interface. With the Event interface it is hard to accidentally pass the wrong object, and easy to add new members later if needed.
I also simplified even more by dropping most integer types, that didn't do much. I renamed all D methods to Delta, that is clearer.
I did add a Wheel and DeltaWheel for the mouse, because they are useful for scrolling.
Hopefully I am getting closer to to make this idea to your liking.

Thanks! I think you agreed that type-assertion way is better :-)

I was wondering why we need a marker method. As far as I know, there is only-one use case of a maker method: https://golang.org/pkg/runtime/#Error , but this is used to distinguish from regular errors. When sending a custom event, would we really make a mistake as you said? Or, even if we send an arbitrary object to the event emitter, what would be the problem?
What about ending with Event if a struct is an emitted event struct? There are structs that are not emitted there.
What about integrating touch-related events to TouchEvent and use an enum value (e.g., TouchType)?

Hopefully I am getting closer to to make this idea to your liking.

Yeah, I think we are getting closer to the agreement :-)

Another update!

Well the main problem would be forward compatibility in case we decide we need some top-level methods on all events after all. But yes, the marker method is not strictly needed, so I'll make type Event interface {}. this still makes type checking possible. I also dropped the Basic struct.

That would create too much of a stutter, since other packages will use the events as event.KeyUp, event.KeyDown, etc. It would be a hassle to have to type event.KeyUpEvent or worse, event.EventKeyUp. However it's true that some structs are just auxilliary. So I made them private and added constructors, which seems to give a better user experience as well.

What you suggest is actually contrary to what we are trying to do in eliminating the EvenrKind. Now, with every event it's own struct, we can handle all events with a single type switch ot a series of types assertions. If TouchKind becomes separated out then that will needs a separate second select statement to handle touch events only. Also it would be confusing between the different events. We shoud either have an Eventkind or not, but not a mix of both.

I added a small try out program as well, here:
https://github.com/beoran/ebiten/blob/beoran-event/event/tryevent/tryevent.go

It would be a hassle to have to type event.KeyUpEvent or worse

I tend to agree, but, New* functions sound verbose and I'd prefer plain structs for events... What about 'E' (e.g., event.KeyDownE)?

What you suggest is actually contrary to what we are trying to do in eliminating the EvenrKind.
...
If TouchKind becomes separated out then that will needs a separate second select statement to handle touch events only. Also it would be confusing between the different events. We shoud either have an Eventkind or not, but not a mix of both.

I meant to eliminate entire EventKind, but I'm fine having enums to distinguish details for one group of events (key up or key down or key press...). It's because my motivation to eliminate kind was to make it easy to add a custom event, and adding auxiliary enums should not prevent it.
However, your idea makes sense. Mixing might be confusing. I'd like to see plain-structs way as I suggested anyway.

https://github.com/beoran/ebiten/blob/beoran-event/event/tryevent/tryevent.go

Nice! That sounds pretty good!

OK, I think I understand, you really like to keep things /simple/. :-)
So, I dropped the New functions, and removed all sub structs. Now, It's very easy to make an event using, for example,  event.KeyUp{64, 0}. A E suffix is even less readable than an Event suffix, but since all structs are now flat and there are no structs that are not events anymore, I think we don't need any suffix anymore. Look at the tryevent.go to see how nicely it looks now.
Mixing events and kinds for sub events is not only somewhat confusing, also less efficient, because you need two checks in stead of one. In the I have a handler for all possible events, 19 in total, and I think it looks fine. Normally we will branch out to different handler functions in a GUI anyway.
Thanks for your appreciation.

I'm almost satisfied with your suggestion https://github.com/beoran/ebiten/blob/beoran-event/event/event.go. Thank you! That is very beautiful and, yes, very simple :-). I still have small requests, but l'll leave them until an actual PR comes.
So, next, let's tackle actual action items as I mentioned at https://github.com/hajimehoshi/ebiten/issues/926#issuecomment-523803963 . 3 can be implemented as a mock without 1. and 2., but what we could do would be limited. @beoran , do you have a preference what you want to do? If not, could you make a PR for 3.?

I made #930 with a PR, for only 3. I tried to follow the guide lines but I ill need your guidance.
Once this is OK, we can work on action points 1., 2. and 4. in that order, I guess.

Action items I come up with:

Add event.Key definition and make ebiten.Key an alias to event.Key (@hajimehoshi will do)
Add event.ModifierKey (or Modifier?)
Add a new function to driver.UI to return a channel that emits events.
Implement the function on GLFW.
Make an example that uses event directly.
Implement the function on JS.
Implement the function on mobiles.
Reimplmement ebiten package to use event package.

Now I'm doing 1. Stay tuned!

Yes, that seems like a good plan. Although, maybe 10. needs to be done between 4. and 5. If you feel you need help with any of those, please ask and I'll do what I can.

Yes. Especially gamepad part is relatively independent thing, so I'm interested in your plan about gamepads. I think you will refer Allegro?

Yes: https://gitlab.com/beoran/galago/tree/master.
I want to make a low lever replacement for GLFW, but I will make it completely modular, so you can ue only what you need, and I will start with the game pad part, as I wrote the gamepad/joystick and haptic drivers for Allegro5.

Finished 1. and 2. at https://github.com/hajimehoshi/ebiten/issues/926#issuecomment-526936431

There are three packages that we consider the relationships

event
internal/driver
driver implementations like internal/uidriver/glfw

internal/uidriver/glfw depends on internal/driver for key definitions or other interface definitions. The question is whether event should depend on internal/driver or vice versa.
My current plan is to make event depend on internal/driver.
package event

func Loop() chan interface{} { // Event interface should be used?
  return getAppropriateDriver().Loop()
}

package driver

type UI interface {
   Loop() chan interface{}
}

The problem is that the internal/driver package cannot know event structs like KeyboardKeyDown. The driver side would need to implement counterparts of event structs, and event package converts this appropriately.
If internal/driver depends on event, as driver implementations depend on internal/driver, I'm not sure how event determines actual drivers.
@beoran Any thoughts?

Hmm, the dependency is a bit of a problem, yes. I think we should probably
split the event package into a internal/event package with the types and
constants, and an event package, with functions and aliases. Then the
dependency graph becomes internal/event -> internal/driver -> event and
also internal/event-> event.
Does that sound like a good idea?
Op di 3 sep. 2019 16:35 schreef Hajime Hoshi<EMAIL_ADDRESS>
There are three packages that we consider the relationships

event
internal/driver
driver implementations like internal/uidriver/glfw

internal/uidriver/glfw depends on internal/driver for key definitions or
other interface definitions. The question is whether event should depend
on internal/driver or vice versa.
My current plan is to make event depend on internal/driver.
package event
func Loop() chan interface{} { // Event interface should be used?
return getAppropriateDriver().Loop()
}
package driver
type UI interface {
Loop() chan interface{}
}
The problem is that the internal/driver package cannot know event structs
like KeyboardKeyDown. The driver side would need to implement
counterparts of event structs, and event package converts this
appropriately.
If internal/driver depends on event, as driver implementations depend on
internal/driver, I'm not sure how event determines actual drivers.
@beoran https://github.com/beoran Any thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/926?email_source=notifications&email_token=AAARM6PR2FLBIMO5MMOWLHDQHZY3LA5CNFSM4IORRFUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5YM67I#issuecomment-527486845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARM6JFYCPYWZG47JAKJ6LQHZY3LANCNFSM4IORRFUA
.

So where would the event struct definition be? At least event should have them for the users, right?

Hmm, we could use aliases, but that would not be so readable. So no, my
first idea isn't that good.
When I think more, the problem is not the structs, but the constants such
as the key codes. We would like to map these to the key constants of the
glfw driver, but at the same time we want to use the events in the driver,
which would create a cyclical dependency, because the events use said key
constants.
To break this cycle, perhaps it's easier to duplicate the key constants.
Because you are generating them automatically anyway?
Op di 3 sep. 2019 19:02 schreef Hajime Hoshi<EMAIL_ADDRESS>
So where would the event struct definition be? At least event should have
them for the users, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/926?email_source=notifications&email_token=AAARM6LJWWS5THF5E6WCZULQH2KA7A5CNFSM4IORRFUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y37WA#issuecomment-527548376,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARM6I4KG7XR5D4EKN4GM3QH2KA7ANCNFSM4IORRFUA
.

Key constants are already shared between internal/driver and event. They are generated automatically.
I think aliases sound the way to go. The original definition will be in internal/driver and event define them for their aliases. The problem is that godoc.org would not show the original definitions and this would make the users confused. 🤔

If we are going to use aliases, them we probably have to take the output of
go doc internal/event, and then paste that above the aliases as a comment
in event. The file event/event.go with aliases and comments could then be
generated, perhaps?
Op di 3 sep. 2019 19:38 schreef Hajime Hoshi<EMAIL_ADDRESS>
Key constants are already shared between internal/driver and event. They
are generated automatically.
I think aliases sound the way to go. The original definition will be in
internal/driver and event define them for their aliases. The problem is
that godoc.org would not show the original definitions and this would
make the users confused. 🤔
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/926?email_source=notifications&email_token=AAARM6OL4ZDL3JZNBG5I3SLQH2OJ7A5CNFSM4IORRFUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Y7NPA#issuecomment-527562428,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAARM6MDGAJ7JNGEMHB4NXLQH2OJ7ANCNFSM4IORRFUA
.

Generating sounds good. My current idea is generate struct definitions that are duplicated, and convert it like event.Key and driver.Key. It is easy to convert a struct to another struct as long as they have exported same members (https://play.golang.org/p/Mizflu9T3qc). Duplication might not be beautiful, but this should work.

Yes, I guess some duplication might be unavoidable if only for documentation or dependency reasons.

Now I'm making an auto generator for events. Stay tuned...

Good, I am still working slowly on a Linux input/joystick/Gamepad driver.

The approach of using a separate Go joystick driver for Linux may work, but perhaps it's easier and quicker for Ebiten if GLFW supported a callback function when the joystick changes. I read in their issue tracker something like this is desired but no one has done the effort to implement it. I guess that I could do this in stead.

As I finished works for 1.10, I'll restart this work.

Add event.Key definition and make ebiten.Key an alias to event.Key (@hajimehoshi will do)
Add event.ModifierKey (or Modifier?)
Add a new function to driver.UI to return a channel that emits events.
Implement the function on GLFW.
Make an example that uses event directly.
Implement the function on JS.
Implement the function on mobiles.
Reimplmement ebiten package to use event package.
Remove unnecessary functions from driver.UI and Input interface.
Improve GLFW driver to use an event-driven style

My first plan was to make ebiten package depend on event package. In this plan, theoretically users can develop apps only with event package without ebiten package. I thought this would be clean but the change would be huge. In the first place, what we needed was fined grained input detection, then creating a package only for events sounds overkill.
Instead, my suggestion is to create Events function that returns a channel in ebiten package, and event packages will include only event definitions.
The new action items are:

[x] 1. Add event.Key definition and make ebiten.Key an alias to event.Key (@hajimehoshi will do)
[x] 2. Add event.ModifierKey (or Modifier?)
[ ] 3. Add a new function to driver.UI to return a channel that emits events.
[ ] 4. Implement the function on GLFW.
[ ] 5. (Updated!) Add Events function to ebiten package and create an example.
[ ] 6. Implement the function on JS.
[ ] 7. Implement the function on mobiles.
[ ] 8. (Updated!) Reimplmement ebiten package to use Events function. (This is still unclear. Would it be possible to keep both the current input API implemented with Events and exposing the API Events?)
[ ] 9. Remove unnecessary functions from driver.UI and Input interface.
[ ] 10. Improve GLFW driver to use an event-driven style

@beoran What do you think?

Thanks for getting back top this! This plan looks fine, we can still move gradually to use events more in Ebiten later on.
The issue for the event callback for joysticks for GLFW is here:
https://github.com/glfw/glfw/issues/601
I am having some problems with this GLFW issue, though, since joysticks and game pads in GLFW are actively polled when you read them. There are functions to poll the event state and call the callback functions but these also have to be changed quite thoroughly to also support joystick events.

I made some progress on GLFW joystick events, they work on Linux with my PR. As you know, I can only test on Linux, perhaps, if you could spare the effort, you could test my PR on other platforms as well?

EDIT: one important thing to note is that Ebiten will have to call
glfwPollEvents() regularly (perhaps once every frame) to receive the events through the callbacks.

Ah good point. Thanks!

I made some progress on GLFW joystick events, they work on Linux with my PR. As you know, I can only test on Linux, perhaps, if you could spare the effort, you could test my PR on other platforms as well?

Are you talking about https://github.com/glfw/glfw/pull/1590 ? Now Ebiten uses GLFW 3.2, and I am waiting for GLFW 3.3 binding for Go. Then before testing your PR, I need to move on GLFW 3.3...

If you need bindings, I'll contribute those too, I have made bindings for Allegro 5 to Go as well. But I'd prefer my PR for GLFW to be accepted first, so I don't have to do double work.

There is a PR for GLFW 3.3 https://github.com/go-gl/glfw/pull/256.
Even after this PR is landed, we need to wait for 3.4 including your PR, right?

Yes, likely so. Hmmm, updating GLFW might not be the fatstest way to get events for joystick input after all, who knows when they will make 3.4? At this rate, maybe in 2022? Hopefully not, but if they are slow in taking in my PR, I'll probably have to go back to my previous idea of programming a low level game library in Go myself to replace GLFW.

I recently discovered Fyne (https://github.com/fyne-io/fyne). This is a Go langage GUI library that also uses GLFW 3.2 and is fully event based. It seems they set up callbacks for mouse and keyboard events. https://github.com/fyne-io/fyne/blob/78cdfc5936493bfcc77a99e0a6e26dcf8ea42ad7/internal/driver/gl/window.go
The only thing missing really are joystick events. However, on Linux, there's no need to use GLFW for joysticks, you could just use my library in stead. On other platforms, I don't know... :p

OK, I'll take a look. What is the URL of your library? Is this in pure Go?

It's the same as above, look here for how to use it:
https://gitlab.com/beoran/galago/blob/master/os/linux/input/input_linux_test.go
Admittedly, I have to clean it up more, so your suggestions are welcome.
This is pure Go, as I interact with the Linux kernel directly. That's the great thing of the  Linux kernel, it has a stable ABI, so, you can directly do system calls to it, without having to use any C at all.

Hmm, this works only on Linux, right?

Yes, right, I am focusing on Linux right now, other platforms are harder to
support for me right now.
Op di 3 dec. 2019 14:07 schreef Hajime Hoshi<EMAIL_ADDRESS>
Hmm, this works only on Linux, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hajimehoshi/ebiten/issues/926?email_source=notifications&email_token=AAARM6OAWRLUOAEUQO5SEHLQWZK23A5CNFSM4IORRFUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFZJWRY#issuecomment-561158983,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAARM6NUJGQJZGZQW353S7LQWZK23ANCNFSM4IORRFUA
.

Sorry but let me remove the milestone from this issue. This issue seems a very long-term work.

Yes, that's right. Only now someone on GLFW tried out my branch on Windows. My own messing around doesn't make much progress for now too. We'll have to wait for the situation of either GLFW or of myself to get better. :)

Merged into #1704


Consistent localized formatting

Just realized Lingui offers convenience methods for language-aware number and date-time formatting via i18n.number() and i18n.date() respectively.
This pull request switches most of our formatting to use that, except for the ago function, I'll touch on that in a separate pull request (haven't figured out how to make unit formatting for months and minutes to not be the same m suffix, I think we might need a separate logic for English, unfortunately)
This seems like the better approach because currently we're very inconsistent as to how we're dealing with localized formatting. Here's how we've been doing it so far:

pass undefined as the locale
pass locale retrieved from expo-localization
pass locale from our content language settings
enforce en-US locale

I've removed the formatCountShortOnly function as it's only used in the drawer, I'm not sure why it should be using a different formatting than the one in <Metrics> component, but we can add that back if necessary.

I've just noticed that some locales doesn't seem to have any compact notation formatting whatsoever, like German and Italian, I'm not sure what to do in this case, should we do a fallback to English in those scenarios? or should we just not?

In Japanese, i18n.number() defines an compact notation for numbers in tens of thousands, but does not seem to define  for numbers in thousands. I think it's fine to leave it as it is, without falling back to English.


Fix first_unused_segment

Hi, I found it strange that the const version of first_unused_segment is different from the non-const version and this, indeed, seems to be wrong. The tests then failed with the canonical (non-const) version due to an implementation difference of how next is used depending on the constructor, as far as I could tell. I tried my best to make it uniform. It still passes all tests now.

Great thanks, I seem to have missed the other segment() tests in the separate file. Also, my fix for the constructor was not entirely correct, it turns out. It failed when constructing from a completely filled source (leading to next = 2capacity), which was detected by span_iterator_suite.
Everything should be fine now. At least the tests are happy :)


tests, sriov: Place a delay between tests

What this PR does / why we need it:
Place a delay between tests to assure resources (VF/s) are fully released before reused again on a new VMI.
(results show that waiting for VMI/s to disappear is not enough) Ref: https://github.com/k8snetworkplumbingwg/sriov-cni/issues/219
This workaround should be temporary until the fix [1] can be consumed. [1] https://github.com/k8snetworkplumbingwg/sriov-cni/pull/220
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:
NONE

/test pull-kubevirt-e2e-kind-1.22-sriov

/cc @ormergi

@EdDev please note that in general, given a pod with attached VF, when the pod is deleted the VF might get reseted after the pod was deleted and not longer exist in the cluster.
I would wait for the VMIs to dispose explicitly and then add a wait for 10 seconds, to make sure we wait 10 seconds after the pod is disposed.
Hopefully it will be enough.

We should try a few more times.
/test pull-kubevirt-e2e-kind-1.22-sriov

2/2 success.. lets try again:
/test pull-kubevirt-e2e-kind-1.22-sriov

/test pull-kubevirt-e2e-kind-1.22-sriov

This is exactly what I expect the change to do.

Just to understand, is it guaranteed that DeferCleanup() will be called before AfterEach() this PR adds?

Just to understand, is it guaranteed that DeferCleanup() will be called before AfterEach() this PR adds?

It is suppose to be called in the reverse order it is registered, like a stack behavior.
Inner after* are called on teardown before outer after*.

3/3 success
/test pull-kubevirt-e2e-kind-1.22-sriov

@EdDev please test pull-kubevirt-e2e-kind-1.23-sriov lane from now on, its the default SR-IOV lane following kubevirt/project-infra#2477

4/4 success
Adding 1.23 lane.
/test pull-kubevirt-e2e-kind-1.22-sriov
/test pull-kubevirt-e2e-kind-1.23-sriov

Failure with the same issue detected on the 5th attempt:
kern  :info  : [Tue Nov 22 16:00:44 2022] i40e 0000:af:00.0: Setting MAC 02:00:00:fa:40:c9 on VF 4
kern  :info  : [Tue Nov 22 16:00:44 2022] i40e 0000:af:00.0: Bring down and up the VF interface to make this change effective.
kern  :info  : [Tue Nov 22 16:00:44 2022] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
kern  :info  : [Tue Nov 22 16:00:44 2022] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
kern  :info  : [Tue Nov 22 16:00:44 2022] i40e 0000:af:00.0: Setting MAC 02:00:00:44:11:2c on VF 5
kern  :info  : [Tue Nov 22 16:00:44 2022] i40e 0000:af:00.0: Bring down and up the VF interface to make this change effective.
kern  :err   : [Tue Nov 22 16:00:44 2022] IPVS: rr: TCP <IP_ADDRESS>:30443 - no destination available
kern  :err   : [Tue Nov 22 16:00:45 2022] IPVS: rr: TCP <IP_ADDRESS>:30080 - no destination available
kern  :err   : [Tue Nov 22 16:00:45 2022] IPVS: rr: TCP <IP_ADDRESS>:30080 - no destination available
kern  :err   : [Tue Nov 22 16:00:45 2022] IPVS: rr: TCP <IP_ADDRESS>:30443 - no destination available
kern  :err   : [Tue Nov 22 16:00:49 2022] IPVS: rr: TCP <IP_ADDRESS>:30443 - no destination available
kern  :err   : [Tue Nov 22 16:00:50 2022] IPVS: rr: TCP <IP_ADDRESS>:30080 - no destination available
kern  :info  : [Tue Nov 22 16:00:50 2022] i40e 0000:af:00.0: Setting MAC 32:40:7b:a6:4d:9a on VF 4

There is a 6sec period between the two mac settings.

By waiting between the tests, we are suppose to assure there is enough time for the race not to occur.
But it seems it does occur. So it is either that something else is happening, or we do not understand the reap problem.

The new SR-IOV CNI fix has been tagged, so the focus goes there, to see if it solves it.
No need to get back to this one (to debug) if the solution indeed works.


ToCode Solution: תרגול מבני נתונים

01 and 02 are ok, but in 03 there is something strange.
This loop looks unnecessary and calling split 3 times on the same line looks also unnecessary.
Can you reduce it to one split and no loop?
            for part in line.split('='):
                dic[line.split('=')[0]] = line.split('=')[1].strip('\n')

04:  r'.\words' is very Windows-like. and the relative path-name is unnecessary you could write 'words' and that would be enough.
There is also something incorrect as it prints 'help' as well which has no anagram.
(We don't have automated tests for this exercise)

done

03: There is not need for that for-loop on after_split like this:
for line in host:
        if len(line) > 2:
             k, v = line.split('=')`
             dic[k] = v.strip('\n')


version 0.0.2 [sd-boost]

Fixes # .
Changes proposed in this pull request:

Update about the calculation for the sum of the total user adjusted balance of staked sdToken
Replaced by 'workingSupply' of the gauge
New and clearer names

Hi @clement-ux There is a open proposal on your space, https://snapshot.org/#/stakedao.eth/proposal/0x78684cea3da915b50e75e0538e2abe40f4b4bdf3caf043f6ac8f136295bc22b7
And these changes can affect the proposal voting power calculation, It is better to wait until the proposal is closed or create a sd-boost-v2 strategy

Hi @ChaituVR
Snapshot strategy "sd-boost" was used on doyousync.eth space (test space) and not on stakeDAO.eth space. We have delete all the test proposal on the test space doyousync.eth.
The actual proposal that you ping me don't use sd-boost at all, so there will be no problem if we do it now :)


Fixing spelling mistake: implimentation

Hi @JonJam, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

@JonJam Thanks!


hCaptcha disappears when browser window is too small

The hCaptcha disappears when browser window is too small. This means people using my website on a mobile device will have problems.

I failed to reproduce this issue. Can you please provide example code?

I noticed this problem with Google's reCAPTCHA as well.

This is my function in my views.py file.
def sidebar_directory_page(request, template='sidebarlandingpage/sidebar_directory_page.html'):
    if request.method == 'POST':
        form = HcaptchaForm(request.POST)

        if form.is_valid():
            return SidebarDirectoryPage.objects.first().serve(request)
        else:
            return render(request, 'sidebarlandingpage/captcha_page.html', {'captcha_form': form})

    else:
        form = HcaptchaForm(request.POST)
        return render(request, 'sidebarlandingpage/captcha_page.html', {'captcha_form': form})

And this is my template file captcha_page.html:
{% extends "base.html" %}
{% load static wagtailcore_tags wagtailimages_tags wagtailembeds_tags %}

{% block main %}

    {% image page.get_parent.specific.hero_image fill-900x400 as img %}

If the CAPTCHA does not appear, make your browser window wider. If you are on a mobile device,
                try rotating your screen.

{{ captcha_response }}

            <form action="" method="POST">
                {% csrf_token %}
                {{ captcha_form }}
                <input class="btn btn-primary" type="submit" value="Click here after completing the CAPTCHA">
            </form>

{% endblock main %}

And my form in forms.py as well:
from django.forms import forms
from hcaptcha.fields import hCaptchaField

class HcaptchaForm(forms.Form):
    hcapthca = hCaptchaField(required=True)


Delete phantomjsdriver.log

Guessing this shouldn't be in repo?

Current coverage is 100% (diff: 100%)

Merging #3429 into next will not change coverage

@@           next   #3429   diff @@
===================================
  Files        71      71
  Lines      2855    2855
  Methods       0       0
  Messages      0       0
  Branches      0       0
===================================
  Hits       2855    2855
  Misses        0       0
  Partials      0       0

Powered by Codecov. Last update ea77ac2...6bc90ec

oops, just saw this, deleted already. Thanks.


[image-mirror] Check repo existence on PR

Currently the CI for image mirror doesn't do much on checkout, we should check if the repo exists in our dockerhub org, as if it doesn't the merge will fail.

Dupe: https://github.com/rancher/tasks/issues/189


Adding Grammar AutoCorrrector NLP model

I want to add a Grammar AutoCorrrector NLP model. which understands user's texts , identifies grammatical errors and corrects it.
The model can be trained using datasets
@Niketkumardheeryan  Kindly assign me the issue

@Niketkumardheeryan Kindly assign me the issue


Error with recents versions.

Hello!
Recently, I compiled Wired to upgrade the old version I had installed in my PC. Wired compiled fine, but when I tried to run it the only message that I got in terminal is:
"thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/cli.rs:50:47
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace"
An then, Wired crashes.
Edit: Using sudo, Wired works. The problem only appear when I run Wired as a normal user.
Sincerely,
Andrés.

Hmm.  It looks like it's having trouble removing the old socket, maybe it's owned by a different user or something?  Can you try manually remove /tmp/wired.sock?  (or reboot, which should do the same thing).


Warn users if fees is weirdly high.

(to be discussed, as some hardware signers also perform the check directly)
This could be a setting, with a default value and that can be changed by editing the conf for those who need.
The warning could be:
"the transaction fee is unusually high. Are you sure to proceed?" (probably displaying the reason for trigger too).
Triggers:

fee > x percent of value
fee > x0 000 sats

(Maybe 10 percent and 100k sats as defaults)

Mistakes happen, setting the fee yourself might actually increase the risk
On Thu, Jan 11, 2024, 08:37 Antoine Poinsot @.***>
wrote:

Well the fee is set by the user at the moment. This would make sense
once we have fee estimation yes.
—
Reply to this email directly, view it on GitHub
https://github.com/wizardsardine/liana/issues/910#issuecomment-1886721631,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADWNZE553OWQM7QKELVQXA3YN6XGFAVCNFSM6AAAAABBVI2VECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBWG4ZDCNRTGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

It seems to me that we currently ERROR when fee rate is >1000 sats/vbyte, including CPFP adjustment.
This makes this issue more relevant since we have CPFP, as users might end up even more confused.
So this issue is to WARN users instead of ERROR, making it possible to bypass.
From the current 1ksats/vbyte limit, I would add a % and an absolute fee condition, if any is reach, warn the user.
I guess the absolute fee is the most controversial one, but at the end of the day, it's what the user actually pays so it is relevant.

FYI i think coldcard warn user at 3% fee