Fixed issue with embedded changeset errors

When a polymorphic_embed has its own nested embed the changeset for the nested embed doesn't contain the errors for the nested embed.
I reviewed the code to see how the embed_errors were being set and I made a modification to add the nested embed errors to the errors keyword list.

When you say nested embed, do you mean a nested polymorphic embed, a nested embeds_one, or nested embeds_many?

In my case I have a polymorphic embed called survey, and some of the embedded schemas for survey have an embeds one called address. This PR fixes the issue I'm running into where when I pass address to inputs_for

I'm actually surprised :D it will take some time before I get back into the code. Providing a test will accelerate the process though. In the meanwhile I guess you depend on your fork.

Sounds good, I will work on a test and try to get it to you next week. I'm just curious, what part are you surprised about?

That the nested errors don't work, and the change in the pattern matching ( {_, errors}). Dunno I'm confused. If you get that test out I'll work on it next week.

The way the current embed_errors code works it seems to assume that the Changeset errors field would contain the errors from nested changesets, which when I was debugging the issue and inspecting the various changesets doesn't seem to be the case. Each Changeset errors field only contains the errors for the current changeset.
My modification to do_get_errors excursively adds the nested errors to the Changeset errors field.
I'm not sure that the embed_errors logic ever worked since since as far as I know the Changeset errors field never contained nested errors. I changed the pattern match to match the format I was using to recursively append the nested errors.

There are a few separate issues I'm working through. I'm going to close this PR for now and open separate PRs once I have tests.

Do you have some failing tests to share?
I'd like to work on this but I gotta understand and see the problem first :D

I've been working on this intermittently over the last few months but I'm having a hard time recreating it. I will spend some more time today and see if I can create a test that recreates this issue.

I spent several hours on this today but I still cannot figure out what is going on or why my patch fixes it.
All I know is that I have a form (1) which has an embedded polymorphic form (2) which has an embedded form (3).
The original form (1) has all the correct errors in the source, the polymorphic_form (2) is missing the errors in the source but still has the errors in data, the embedded form (3) is missing errors in both source and data.
Form (3)

%Phoenix.HTML.Form{
  action: nil,
  data: %FC.CheckIns.Surveys.ReplaceCard{
    address1: "a",
    address2: nil,
    city: "a",
    id: nil,
    new_card_number: nil,
    replace_card: nil,
    state: nil,
    zip: "a"
  },
  errors: [],
  hidden: [],
  id: "check-in-form_survey_replace_card_survey",
  impl: Phoenix.HTML.FormData.Ecto.Changeset,
  index: nil,
  name: "check_in[survey][replace_card_survey]",
  options: [],
  params: %{
    "address1" => "a",
    "address2" => "",
    "city" => "a",
    "new_card_number" => "",
    "state" => "",
    "zip" => "a"
  },
  source: #Ecto.Changeset<action: :validate, changes: %{}, errors: [],
   data: #FC.CheckIns.Surveys.ReplaceCard<>, valid?: true>
}

Form (2)
%Phoenix.HTML.Form{
  action: nil,
  data: #Ecto.Changeset<
    action: :insert,
    changes: %{
      received_card: false,
      replace_card_survey: #Ecto.Changeset<
        action: :insert,
        changes: %{address1: "a", city: "a", zip: "a"},
        errors: [
          state: {"can't be blank", [validation: :required]},
          replace_card: {"can't be blank", [validation: :required]}
        ],
        data: #FC.CheckIns.Surveys.ReplaceCard<>,
        valid?: false
      >
    },
    errors: [
      communication_preference: {"can't be blank", [validation: :required]},
      consent_to_sms: {"can't be blank", [validation: :required]}
    ],
    data: #FC.CheckIns.Surveys.Welcome<>,
    valid?: false
  >,
  errors: [
    communication_preference: {"can't be blank", [validation: :required]},
    consent_to_sms: {"can't be blank", [validation: :required]}
  ],
  hidden: [__type__: "welcome"],
  id: "check-in-form_survey",
  impl: Phoenix.HTML.FormData.Ecto.Changeset,
  index: nil,
  name: "check_in[survey]",
  options: [],
  params: %{
    "__type__" => "welcome",
    "received_card" => "false",
    "replace_card_survey" => %{
      "address1" => "a",
      "address2" => "",
      "city" => "a",
      "new_card_number" => "",
      "state" => "",
      "zip" => "a"
    }
  },
  source: #Ecto.Changeset<
    action: :validate,
    changes: %{
      received_card: false,
      replace_card_survey: #Ecto.Changeset<action: :validate, changes: %{},
       errors: [], data: #FC.CheckIns.Surveys.ReplaceCard<>,
       valid?: true>
    },
    errors: [
      communication_preference: {"can't be blank", [validation: :required]},
      consent_to_sms: {"can't be blank", [validation: :required]}
    ],
    data: #FC.CheckIns.Surveys.Welcome<>,
    valid?: false
  >
}

Form (1)
%Phoenix.HTML.Form{
  action: "#",
  data: %FC.CheckIns.CheckIn{
    __meta__: #Ecto.Schema.Metadata<:loaded, "check_ins">,
    completed_at: nil,
    date: ~D[2020-01-01],
    deleted_at: nil,
    direction: nil,
    follow_up: false,
    follow_up_date: nil,
    follow_up_type: nil,
    id: "c2cc719e-6b16-4ab3-b7ae-4b4a15812d9c",
    inserted_at: ~N[2021-04-29 18:14:08],
    mode: nil,
    notes: "Test",
    outcome: nil,
    previous_check_in: #Ecto.Association.NotLoaded<association :previous_check_in is not loaded>,
    previous_check_in_id: "8ac10260-da80-4c9f-b8ed-2e3d9118ed61",
    rescheduled_at: nil,
    rescheduled_date: nil,
    shopper: %FC.Shoppers.Shopper{},
    shopper_id: "3c5f26db-cb37-4a52-a8c7-b181c28dafea",
    sub_type: nil,
    survey: nil,
    type: :welcome,
    updated_at: ~N[2021-05-18 18:48:23],
    user: #Ecto.Association.NotLoaded<association :user is not loaded>,
    user_id: "ac272b98-c1f4-4421-8ee0-ec641a18f00c"
  },
  errors: [],
  hidden: [id: "c2cc719e-6b16-4ab3-b7ae-4b4a15812d9c"],
  id: "check-in-form",
  impl: Phoenix.HTML.FormData.Ecto.Changeset,
  index: nil,
  name: "check_in",
  options: [
    method: "put",
    id: "check-in-form",
    phx_target: %Phoenix.LiveComponent.CID{cid: 3},
    phx_change: "validate",
    phx_submit: "save"
  ],
  params: %{
    "direction" => "outgoing",
    "follow_up_date" => "2021-05-20",
    "follow_up_type" => "none",
    "mode" => "call",
    "notes" => "Test",
    "outcome" => "made_contact",
    "rescheduled_date" => "",
    "survey" => %{
      "__type__" => "welcome",
      "received_card" => "false",
      "replace_card_survey" => %{
        "address1" => "a",
        "address2" => "",
        "city" => "a",
        "new_card_number" => "",
        "state" => "",
        "zip" => "a"
      }
    },
    "type" => "welcome"
  },
  source: #Ecto.Changeset<
    action: :validate,
    changes: %{
      direction: :outgoing,
      follow_up_date: ~D[2021-05-20],
      follow_up_type: :none,
      mode: :call,
      outcome: :made_contact,
      survey: #Ecto.Changeset<
        action: :insert,
        changes: %{
          received_card: false,
          replace_card_survey: #Ecto.Changeset<
            action: :insert,
            changes: %{address1: "a", city: "a", zip: "a"},
            errors: [
              state: {"can't be blank", [validation: :required]},
              replace_card: {"can't be blank", [validation: :required]}
            ],
            data: #FC.CheckIns.Surveys.ReplaceCard<>,
            valid?: false
          >
        },
        errors: [
          communication_preference: {"can't be blank", [validation: :required]},
          consent_to_sms: {"can't be blank", [validation: :required]}
        ],
        data: #FC.CheckIns.Surveys.Welcome<>,
        valid?: false
      >
    },
    errors: [],
    data: #FC.CheckIns.CheckIn<>,
    valid?: false
  >
}

And how did you notice that the errors weren't shown? More specifically, what is the code that shows the errors? Do you use your application's error_tag/2 function in the form or are you trying to use traverse_errors/2?

I'm am using the following error_tag function
  def error_tag(form, field, opts \\ []) do
    errors = Keyword.get_values(form.errors, field)

    if length(errors) > 0 do
      content_tag(:span,
        Enum.map(errors, fn error -> translate_error(error) end) |> Enum.join(", "),
        opts
      )
    end
  end

The association I'm working with is an embeds_one, so I don't need to preload. Everything is working for me except the errors are lost on form (3) without my patch that recursively adds the nested changeset errors to the parent changeset.
Without my patch, the parent changeset is correct and has all the appropriate errors nested under changes.
It seems like something in PolymorphicEmbed.HTML.Form.to_form is losing the error information for the polymorphic changeset in some edge case I'm hitting but am unable to reproduce.

I've added a test and pushed an update.
Could you test and see if it works for you? That would be really appreciated 🙏

Unfortunately v1.6.0 is a regression for my project (all my tests related to polymorphic embeds are failing). v1.5.1 works but still has the issue with missing errors.
It looks like in v1.6.0 polymorphic_embed_inputs_for is no longer rendering a form when the PolymorphicEmbed field is nil. Previously it would render a form that would create a new record for my PolymorphicEmbed field.

Can you test 1.6.1 🙏🙏🙏 ?

1.6.1 fixed the regression, but doesn't fix my issue with embedded errors.
On Thu, May 20, 2021, 1:00 PM Mathieu Decaffmeyer @.***>
wrote:

Can you test 1.6.1 🙏🙏🙏 ?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mathieuprog/polymorphic_embed/pull/35#issuecomment-845345216,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADPF5USWTYB2R6B7GZRIFTTOVE5XANCNFSM4XFRVWOA
.

Ok now I'm surprised. I have a test that creates a changeset with an embeds_one inside a polymorphic_embed with an error:
https://github.com/mathieuprog/polymorphic_embed/blob/master/test/polymorphic_embed_test.exs#L1199
Check the sms_reminder_attrs:
:result is an embeds_one inside polymorphic embed :channel.
channel: %{
  my_type_field: "sms",
  result: %{
    success: ""
  }
},

Same for :country inside the polymorphic embeds :contexts.
There is definitely an error that has been tested here:
assert f.errors == [success: {"can't be blank", [validation: :required]}]

and here:
assert f.errors == [name: {"can't be blank", [validation: :required]}]

As the errors are shown in the tests, can you then check your client code again?
You have an inputs_for for your embeds_one right?

Even though the tests are working, found out add_changes_for_nested_embeds/3 is not tested or doesn't work as expected.
I'm working on it.

So I removed like 60 lines of code 😅 wasn't tested, worked poorly, seemingly unnecessary, and error-prone.
Can you test with version 1.6.2 🙏🙏🙏 ?

v1.6.2 does fix the issue I was having with the errors being lost!
It introduces one new regression. Now instead of the embeds_one inside the PolymorphicEmbed losing the errors, it is losing the changes.
So if set the attrs like so:
channel: %{
  my_type_field: "sms",
  result: %{
    success: true
  }
},

success will be nil.
I may have some time today to write a test for this. Seems like we are pretty close though.

Well that's bad :D because that seem to be the purpose of add_changes_for_nested_embeds/3 of 60 lines that I removed.
But anyway this was bugged as we could see.

I added a test right here:
https://github.com/mathieuprog/polymorphic_embed/blob/master/test/polymorphic_embed_test.exs#L1323
You can see that the :result which is an embeds_one keeps its value of true on error.
Can you help me make it fail?
About the tests, you can find some particularities:

for polymorphic? <- [false, true] do: run the tests for regular embeds and polymorphic embeds to make sure that the polymorphic behaves the same way (I can explain further if needed).
"from safe_inputs_for #{polymorphic?}": sometimes you can see that string being returned in safe_inputs_for, it's just to make sure that we actually went inside the safe_inputs_for block.

After attempting to debug the new regression, I think it may be caused by my implementation rather than this library.
I think v1.6.2 will work with my application after I do a bit of refactoring.
I ran out of time to debug this today but I will look more into it next week.

Ok, that's interesting. Somehow you lose the params of the changeset. In any case let me know! Hope we can sort this out 🤞

Any news? 🧐

My issue with the errors has been solved. I will need to refactor a few parts of my implementation to be able to switch off of my branch, but I should be able to get to that in a few weeks. I'm going to close this pull request since this issue is resolved.

Thanks! Curious to hear what went wrong, if you'd have the time in the future when you debug it.
Good luck:)


logout returns M_UNKNOWN_TOKEN instead of M_MISSING_TOKEN

Using /_matrix/client/r0/logout without an access token returns the error
M_UNKNOWN_TOKEN Access Token unknown or expired
while every other unauthorized request, including /_matrix/client/r0/logout/all returns
M_MISSING_TOKEN Missing access token.

This is a synapse bug - I'll move this there.


fix: back and next buttons for purpose/targets pages

As noted in #2267, the back button is broken on the "Applications" aka Purpose page.  This PR removes the button and adds the missing back button to the Targets page.

cc @eharris128

Tested locally. LGTM.
Cleaner implementation as well :)


Setting SO_NOSIGPIPE on Socket for BSD derivatives

Under macOS, for example, If the socket for whatever reason is closed, you end up in the SIGPIPE handler.
Setting the SO_NOSIGPIPE option will instruct the OS to not generate SIGPIPE, but instead return EPIPE, which can be handled gracefully along with other IO errors.

I'll look into allowing this as an option.


84-Plot different graphs where we can check the training of the model

Monitoring various runs using MLflow, adjusting parameters, and seeking the optimal combination to maximize the Mean Reciprocal Rank (MRR) metric.


Some type improvements

Some type improvements, reducing the number of warnings at compile time.
The handling of the OGRFieldSubType enum isn't quite right but doesn't cause any errors.

I've had a go at resolving #551. You can now force Fiona to build entirely in C++ by passing --cython-language c++ as an argument to setup.py.

@snorfalorpagus you're awesome! What would you think about basing this on the new maint-1.8 branch?

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Coverage remained the same at 83.133% when pulling 7620ce8c91f097ccbd8029d8025734612a89eb90 on snorfalorpagus:types into 74e2c90769e45c50f958a1b92cef6cf42b498a90 on Toblerity:master.

Thanks @sgillies. I've rebased against maint-1.8.


nixosTests.rabbitmq: remove stdenv.shell in su

Motivation for this change
https://github.com/NixOS/nixpkgs/pull/74123#discussion_r350203294
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg test rabbitmq


core.tests to directory

File https://github.com/Lrcezimbra/django-template/blob/master/project_name/core/tests.py to directory

Closed by 741e3468e9de1c081bffd3d6f8350b45e4641559


"Request a demo" just spins on Mac/Safari

Calendar displays fine with Mac/Chrome

Just tried it out with Mac/Safari. Works fine for me.


New package: TimeArrays v1.0.0

Registering package: TimeArrays
Repository: https://github.com/bhftbootcamp/TimeArrays.jl
Created by: @gryumov
Version: v1.0.0
Commit: d8284164db4b6cfb19eb3d6edec1619b342c0fdf
Reviewed by: @gryumov
Reference: https://github.com/bhftbootcamp/TimeArrays.jl/commit/d8284164db4b6cfb19eb3d6edec1619b342c0fdf#commitcomment-142779020
Description: TimeArrays simplifies working with time series data. It offers features like basic math operations, sliding window techniques, data resampling, and handling of missing values
Release notes:

Release TimeArrays v1.0.0

Looks good in principle, but the (widely used?) TimeSeries.jl already provides TimeArray, which has at least the potential for conflicts.
Maybe check in with @iblislin on whether this is a problem. You'd definitely want to discuss the relation to TimeSeries in the documentation.

TimeSeries.jl is an excellent package, but it heavily relies on DataFrame-like structures. We decided to take a different approach. Our method allows using time series as a simple list of "time-value" pairs, where the value can be anything, such as a number or a custom data type. This is convenient if you need to add your own data processing functions.
We understand that our choice of the name TimeArray might be confusing since TimeSeries.jl already exists. But if we change the name to TimeSeries, it would only create more confusion. Therefore, we decided to keep the name TimeArray.

[noblock] Yeah, I'm pretty sympathetic. And unless someone shows up to explain that this is a serious problem and has a good proposal on how to fix that problem, I'll just let this merge.
I've actively tried to reach out to anyone who might have a stake in this, so I'll just unblock now and we'll see what happens during the rest of the waiting period. BTW, https://github.com/JuliaRegistries/General/pull/108334#issuecomment-2151799084 will need a [noblock] as well.


Don't ship the tests with iris

Lift and shift the iris.tests out and up to the root directory (same level as setup.py) to avoid installing the tests with iris.
Also collapse the lib directory, it's not necessary.

Removing the tests will mean it is not possible to run the tests on an installed version. That may or may not be OK, I'm not sure. It is worth considering this use case at least.

Hey @ajdawson! Great to hear from you :smile:
I definitely think it's worthwhile considering. Just though I'd have the debate here...
My line of thought was that if iris has been installed as a package then it's most likely a pucker packaged release, and it should just work. In that sense, I really wouldn't expect someone to run all the tests, as they'd also need to set-up the test data etc. I'm more inclined to think that a developer would run the tests, and they wouldn't do that from an installation, rather they'd pip install -e . (or similar) a development (or master) branch into an installation that they own i.e., miniconda - in which case they'd have access to the tests.
Hmmm I dunno...
What I do know is that currently there is ~9.5MB of code sitting under iris.tests :worried:

My line of thought was that if iris has been installed as a package then it's most likely a pucker packaged release, and it should just work.

I can buy that line of thought. I guess packaging the tests used to make a lot of sense before conda and wheels were prevalent and we used to have to install from source ourselves. I will not object to proceeding with this work.

I'm :+1: on this in principle, but we should take the opportunity improve the "how to" descriptions for new developers :  At present the "Developer's Guide" assumes a distressing level of proficiency, E.G. it lays out how to write tests + where to put them without ever explaining "how to run the tests".
Possibly, "setup.py tests" still works, or not, but that was never well signposted, or even clearly documented in the setup.py command-line help.

Possibly, "setup.py tests" still works

It ran last time I tried, though I had failures in places I hadn't touched.  I also got failures because iris.standard_names.py didn't get regenerated.  It hadn't so far occurred to me to try other ways of running the tests.  So, as well as new developers, I'd benefit from an update to these docs.

@SciTools/peloton are all in favour of this 👍
We acknowledge that for certain cases it makes it more difficult to test that Iris is working in an environment into which it is installed, but for those cases it's still possible to run the tests in ANY environment - PROVIDING THE tests DIRECTORY IS NOT IN THE lib DIRECTORY (this is also a big argument for keeping the lib directory).

I very regularly run the tests in freshly created environments to ensure that iris is functional. Notably, not all the tests pass (!) but this is usually due to image comparison failures or slightly different string formatting or something else caused by different versions of dependencies in my installed environment. Nonetheless it is helpful to get that assurance that the environment works as expected, after reviewing any test failures.
Everytime I run the tests in a conda environment, I think of this issue and how much of a pain it would be if the tests weren't there in the install. I could go searching the repo for the tests when I want to run them in my environment but this would be a bit cumbersome.
So unless the tests get much bigger such that the install of iris is unreasonably large, I would prefer we kept them

Cool, let's maintain packaging the tests within iris, as there is genuine benefit in doing so.
Thanks everyone for chipping in, much appreciated :smile:

After a git clean
$ du -sch lib/iris/tests/* | sort -h
4.0K	lib/iris/tests/idiff.py
<snip>
2.0M	lib/iris/tests/unit
17M	lib/iris/tests/stock_arrays.npz
37M	lib/iris/tests/results
57M	total

So the bulk of the "tests" are the results directory and the stock arrays file.  Those could potentially be moved into the test data repo if we wanted to trim some weight?


Add ability to dismiss attachment modal via swipe

@marcaaron will you please review this?
Details
This PR adds the ability to swipe down and right to dismiss an attachment on mobile.
Fixed Issues
Fixes https://github.com/Expensify/Expensify/issues/154788
Tests

Sign into an account and send an image attachment
After the attachment uploads, tap on it, confirm an attachment modal shows
Double tap on the image, confirm it zooms
Double-tap again, confirm it zooms out
Use two fingers to zoom in, confirm the image zooms in
While zoomed in, swipe down and right and confirm the modal doesn't close, and that the viewport pans around the zoomed image
Double-tap again then swipe down or right, confirm the modal dismisses
Confirm that there are no regressions on web

Confirm attachments still show up on web
Confirm the modal attachment closes normally on web

QA Steps
Same as above
Tested On

[x] Web
[x] Mobile Web
[ ] Desktop
[x] iOS
[x] Android

🚀 [Deployed](https://github.com/Expensify/Expensify.cash
/actions/runs/765130740) 🚀 to
staging on Mon Apr 19 2021 at 22:41:56 GMT+0000 (Coordinated Universal Time)

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Android/iOS - Chat - Image does not zoom in when two fingers are used
Expected Result
Confirm the image zooms in
Actual Result
Image does not zoom in
Action Performed

Launch the app and login
Send an image attachment
After the attachment uploads, tap on it, confirm an attachment modal shows
Use two fingers to zoom in

Platform
iOS ✔
Android ✔
Notes/Images/Videos
Issue is reproducible in production but it's failing step 5 of the PR. Let me know if I should raise this as a separate issue.
https://user-images.githubusercontent.com/44479856/115468224-c4c6e180-a200-11eb-8a4e-9e751b56a07f.mp4

@isagoico if this is happening on production then let's create a new issue for it, feel free to tag me in it and I'll have a look


Simplify CSV unmarshalling using gocsv

Removes the mappers module (which constructed structs by hand from CSV
rows, using column indices), use gocsv to automatically construct the
structures using annotations on the objects (similar to how the JSON is
emitted).
This reduces the effort required to add new fields or endpoints, and
mapping by name rather than column index is less error-prone. The
reported deaths mapper was in fact using the wrong column indices e.g.
leading to gender and age being swapped.
The one downside is that the code is now dependent on the column headers
used. Some of them need cleanup (e.g. some have leading spaces) and this
will now require code changes to match.

@Vutlhari please review.

Nicely done :)

Thanks, glad I could help.


Server render error fix

Tried to use this module with nuxt and ssr, encountered some problems.

Thanks!


Question regarding compatibility warning to semantic ui react 0.83.0

Hi there,
you explicitly warn that there are compatibility issues with semantic 0.83 - could you please state the nature of the compatibility emergency? ;) Can I help?
Regards
Frank

Hi! There is only one issue relating to 0.83.0 but it is huge. Take a look at these threads #43 #46. And it seems like there is a PR already made in semantic-ui-react but it is not released yet.

Ok - any idea which PR it is so it can be referenced here?

semantic-ui-react v0.84.0 is released.


Can't run npm run dev from basic Netlify template

What version of Remix are you using?
^1.3.4
Steps to Reproduce
After choosing netlify as the deploy target, I get an error running npm run dev.
Is this because a netlify CLI needs to be globally installed? I wasn't expecting the build target to affect dev mode, but if that's the case, perhaps it could be made clearer during npx create-remix or the error message could be clearer?
npm --version
8.1.2
node --version
v16.13.2

npx create-remix
Need to install the following packages:
  create-remix
Ok to proceed? (y)
npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.
? Where would you like to create your app? test-remix-2
? What type of app do you want to create? Just the basics
? Where do you want to deploy? Choose Remix if you're unsure, it's easy to change deployment targets. Netlify
? TypeScript or JavaScript? TypeScript
? Do you want me to run `npm install`? Yes
npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.

> postinstall
> remix setup node

Successfully setup Remix for node.

added 784 packages, and audited 785 packages in 55s

195 packages are looking for funding
  run `npm fund` for details

4 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.
💿 That's it! `cd` into "test-remix-2" and check the README for development and deploy instructions!
➜  cd test-remix-2
➜  npm run dev

> dev
> cross-env NODE_ENV=development netlify dev

node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: spawn netlify ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn netlify',
  path: 'netlify',
  spawnargs: [ 'dev' ]
}

Expected Behavior
After running npx create-remix with a Netlify build target, I should be able to run npm run dev and it should either work or show an error message to help me recover.
Actual Behavior
After running npx create-remix with a Netlify build target, running npm run dev shows an error message with no recommended steps to recover.

 ENOENT usually means something is trying to read / require a file that does not yet exist on disk.
If the above works, then we should update the template to first do a build before starting the netlify server.

No that doesn't help:
➜  test-remix-3 npm run build

> build
> remix build

Building Remix app in production mode...
Built in 351ms
➜  test-remix-3 npm run dev

> dev
> cross-env NODE_ENV=development netlify dev

node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: spawn netlify ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
    at Process.ChildProcess._handle.onexit (node:internal/child_process:288:12)
    at onErrorNT (node:internal/child_process:477:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn netlify',
  path: 'netlify',
  spawnargs: [ 'dev' ]
}

@penx netlify needs indeed to be installed globally, this is mentioned in the Netlify template's README but not really obvious when configuring a new project.
@jacob-ebey could some additional output be logged depending on the chosen template in create-remix?

Maybe I’m missing something, but if netlify is a deploy target, why is the cli needed during development?

@penx netlify needs indeed to be installed globally, this is mentioned in the Netlify template's README but not really obvious when configuring a new project.
@jacob-ebey could some additional output be logged depending on the chosen template in create-remix?

I second that. I think it will be really helpful if the README clearly states that netlify-cli needs to be installed globally along with the reason why. The Netlify Setup instructions as it reads now makes it seem as if the cli tool is optional.

Why not include netlify-cli as a local dev dependency by default in the template?

The CLI did have the following message though
💿 That's it! `cd` into "test-remix-2" and check the README for development and deploy instructions!

So we're already saying to people that they need to read the README.
The first step of the README literally says, that you need to install the Netlify CLI
## Netlify Setup

1. Install the [Netlify CLI](https://www.netlify.com/products/dev/):

```sh
npm i -g netlify-cli
```

I don't think we can do anything about people not reading the instructions provided tbh 🤔

could some additional output be logged depending on the chosen template in create-remix?

@machour That's something that should be done in the remix.init script from the template then, which is another thing people seem to not run for some reason 😅🙈

The CLI did have the following message though
💿 That's it! `cd` into "test-remix-2" and check the README for development and deploy instructions!

So we're already saying to people that they need to read the README.
The first step of the README literally says, that you need to install the Netlify CLI (globally)

Closing this issue as README mentions that 🙏🏼


Cannot see caret in editor

From<EMAIL_ADDRESS>on 2013-05-22T14:20:52Z
Spyder Version:  2.1.11
Python Version:  2.7.3
Qt Version:      4.8.3, PyQt4 (API v2) 4.9.5 on Windows
What steps will reproduce the problem?

Type anything in editor 2. 3. What is the expected output? What do you see instead? Cannot see caret in editor

Please provide any additional information below
.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1403

From ccordoba12 on 2013-06-28T22:09:15Z
It's there, try to change your color scheme one of our dark ones to see it more clearly.
Status: Invalid


More refined transition configuration

Hi!
Thank you for this good lib that can replace the good old Barba.js!
I'm seeing a use case that Highway cannot cover:
Let's assume you have this website architecture:
[home]--[about]--[contact]
--> It might be interesting to have the ability to have a different 'in' transition of the about page depending on where you are coming from.
For example, here is a 'cheap' but simple use case (like a slider):

If you come from 'home',  you want that the 'about' page slides in from the right.
If you come from 'contact', you want that the  'about' page slides in from the left.

Here is a suggestion about the config:
new Highway.Core({
  renderers,
  transitions: {
    default: Fade,
    home: Home,
    contact: Contact,
    about: {
      home: aboutHome,
      contact: aboutContact,
    },
  }
});

Or simpler:
You just provide additional params in in and out methods of a class Transition. For example, an object as follow:
{
  from: 'home',
  to: 'about',
};

PS: The prefetch option was interesting on Barba.js. Are you planing to implement it? :)

Hi @Michkkael,
Thanks for the suggestion!
You're right it might be interesting to extend the transition feature and cover even more use cases. We'll think about it for the v2.0.0 that's in beta for now and keep you in touch.
About the prefetching, it's really the worst way of doing it in Barba.js. It doesn't make sense to prefetch a page when a user hovers un link since users might hover link either by mistake or without clicking them. This means you're doing HTTP requests without being sure the user will do anything.
Another more efficient way to do it would be to use a library like Premonish to try to predict if the user intent to click an element or not based on the intention score.
The problem is that it would add an extra layer of weight and complexity to our library that we want to keep simple to use. So we are not closing the door this the prefetch feature but it needs time to be done intelligently and efficiently. We will think about it for a later major release maybe.
Best regards,
Anthodpnt

We took a look for a solution to improve the way transitions are working but we couldn't find the cleanest and most effective one for now. One lead would be to send in the transitions the name of the view we come from or we go to in order to use this information and create some conditional statements inside the transition itself, but it's not possible for now.
Right now the out method of the transition is called in parallel of the fetching of the view we are going to so we don't know the name given to this one until the fetch is resolved and we get the DOM. This means we cannot send this information in the out transition for example.
We keep this request pending for now and we are closing the issue since no right solution seems to be available for now...

@mikehwagz BTW, thanks a lot for this reducer. I used it for a project, it works like a charm!
You're right it's not ideal because of what you are pointing. But I don't see other good solutions.
An other solution would be to have an idea of the name of the view we're going to load. For instance:
Projects
But it's not convenient at all. :/

@Michkkael of course! glad that helped you out.
Yea, the solution you've proposed would definitely work in certain cases, but not in all cases (for example a link created within a WordPress WYSIWYG field).


Reworks timeout logic. Fixes windows tests. Supports Copter 3.3 release in tests.

Motivated by the Windows tests often failing, I figured out what was breaking them (finally!) This patch does a few things:

Switches our tests to dronekit-stil 3
Switches tests to Copter-3.3 (not RC)
Stops issuing as many 5s warnings
Adds a heartbeat_timeout property to connect(), by default set to 30s (this is different from the 5s warning, in that it actually closes the connection)

This branch supercedes #406, since Linux was actually failing (somewhat consistently) on one of the old builds.

Is this timeout just for connecting? If so, can user  set 0 to disable the timeout altogether (should they so wish)?
If it is a general timeout, would we ever want to change this timeout after connecting?

@hamishwillee It can now be set to 0 (or None) to not trigger.
We will probably want the ability to change this timeout after connecting, but I want to expose that in another PR (or issue).

Looking forward to testing - do I just update Dronekit via pip to get the latest?
Also, how do I access the documentation as listed in the top of lib/init.py?  There's a lot of good info that doesn't seem to show up anywhere?
"Connect"description / doco in lib/init.py doesn't include timeout (line 46)
It seems that if the connection times out, this happens:
raise APIException('Timeout in initializing connection.')
The timeout.py sample doesn't use this, it seems to just end when / if it times out, which at least is better than hanging.  Is the intent that you use the raised exception to identify that the connect has failed and handle it that way, or is there a parameter within "Vehicle" that indicates it's not connected?

@mikerob It is unlikely that a new release has appeared for this on pip yet. YOu can however build dronekit from github source using the instructions here (on windows). You may have to uninstall dronekit first (pip uninstall dronekit).
The documentation hasn't been rebuilt yet (@tcr3dr - worth doing another docs build soon!). It has much improved, but does not yet include the timeout docs (this only went in 3 hours ago!). If you want to build and test the docs locally yourself it is quite easy - see these instructions.

Hamish, have installed - thanks.  I'm running on a RasPi so it makes life easier than windows.
Hit something odd, not sure if it's a PEBKAC or a code issue:
from dronekit import connect
from dronekit.lib import APIException
try:
vehicle=connect('/dev/ttyAMA0', heartbeat_timeout=10)
except APIException as ai:
print "APIException fail - Something bad happened"
print type(ai)
print ai.args
print ai.msg
except Exception as ai:
print "Something we didn't expect"
print type(ai)
print ai.args
print ai
else:
print "It worked"
If I set timeout to 10 or more, it works fine.  If less than that, it throws the following:
pi@MavStation ~/pigs $ python to_exc.py

Link timeout, no heartbeat in last 5 seconds
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/local/lib/python2.7/dist-packages/dronekit-2.0.0rc7-py2.7.egg/drone
kit/init.py", line 77, in mavlink_thread
fn(self)
File "/usr/local/lib/python2.7/dist-packages/dronekit-2.0.0rc7-py2.7.egg/drone
kit/lib/init.py", line 855, in listener
raise Exception('>>> No heartbeat in %s seconds, aborting.' % self._heartbea
t_error)
Exception: >>> No heartbeat in 9 seconds, aborting.

APIException fail - Something bad happened
<class 'dronekit.lib.APIException'>
()
Timeout in initializing connection.
It looks like setting timeout too low interferes with or gets inside some other exception handling loop.

Hi @mikerob, the default heartbeat_timeout is 10 seconds. You should be able to set it to 0 to indicate you want no timeout. Otherwise it's possible it will throw early on in the connection process if it doesn't receive a heartbeat in time.
The timeout configuration is very new, so possibly buggy! If you have an issue, please file it as a separate issue and we can address it there.


Move update log to the bottom of the homepage, above the footer.

I like the updates, but they won't be relevant enough to justify being at the top of the homepage, IMO.  Happy to do something else if we want.

Mostly addresses #630

no worries at all.  Thanks!


Is there any way to listen modal open or close?

Great library! It makes building cmd tools super easy!
I recently got a situation when I use ninja-keys to work with my react project. I use global storage to store the state of ninja-keys, but I don't know when should I set the state to false and I couldn't find any eventListener to check modal is open ore close.
If there is any way to listen modal state will be great!

You can create a interval of, like 5 milliseconds and check for the ninja.__visible variable

In case someone needs a way to detect a ninja visible modal:
ninjaModal = document.querySelector('ninja-keys')
if (ninjaModal) {
    const el = ninjaModal.shadowRoot.querySelector('div')
    if (el && el.classList.contains('visible')) {
      return
    }
}


Fix - Cache relayer healthcheck

Description
This PR adds a caching utility that wraps a function call and caches results for a defined period.
This is useful for caching the results of healthCheck. When the relayer loses connection with a broker, the broker will check if the relayer is available by calling healthCheck for every single active order. This needlessly spams the relayer with requests.
Related PRs
List related PRs if applicable
Todos

[x] Tests
[x] Documentation
[x] Link to Trello

 Relayer gets spammed with healthchecks on a connection break


bug when  date rolling

use mariadb, mysqlclient
when I change system date
django apscheduler fails to the db connection
and never recovers.
other django and db connection
to the maria db never  fails except django apscheduler
MySQL server has gone away
tested on win10
by changing system calendar panel

See #107. Changing system date / time while APScheduler is running will affect job scheduling and execution, and is probably not a good idea.


Add suggestion fix for the rule no-inline-styles

One of the things I notice myself doing a lot during development is moving inline styles out after I finalize them. I thought it could increase my and hopefully others' productivity if we could automize that job with help of your plugin.
Therefore I prepared a basic PR that would add the suggestion for the no-inline-styles rule. would like to get the maintainers' idea for it and hopefully make it acceptable to merge.
the idea
there are two different ways that the suggestion would act.

if there are no StyleSheet.create nodes are defined in the document creates one and puts the styles in.
from
<View style={{flex:1}} />

to
<View style={styles.viewStyle} />

const styles = Stylesheet.create({ viewStyle: { flex: 1 } });

if there is already a StyleSheet node defined:
from
<View style={{flex:1}} />
const styles = Stylesheet.create({ container: { flex: 1 } });

to
<View style={styles.viewStyle} />

const styles = Stylesheet.create({container: { flex: 1 },  viewStyle: { flex: 1 } });

Sorry for late reply, but it looks like an interesting idea. How should it work if you have multiple views?
<View style={{flex:1}} />
<View style={{margin:10}} />

Ultimately I think the style should be renamed by the programmer as normally it is named after the purpose of the component like container, button, etc. however, for the purpose of this suggestion, we could add a suffix to the second style like viewStyle_2, viewStyle_3, ....


refactor(iroh): move code from builder to node and make things nicer

Description
This is a cleanup of the node and builder code.

Move run and gc_loop from builder.rs to node.rs - it is not about building but about running.
Improve the code flow and naming all around the builder, spawn and run functions
Make sure we shutdown the node correctly while spawning

Breaking Changes

Removed Node::controller. Use Node::client instead. The former was mostly unusable anyway because we made the RPC structs private.

Notes & open questions

Change checklist

[x] Self-review.
[x] Documentation updates if relevant.
[ ] Tests if relevant.
[x] All breaking changes documented.

Very much in favour of moving core node logic into node. It always felt weird to have half the logic in the builder!


How can I open the git history preview window like example picture?

I use the default config and use :VGit buffer_history command but does not meet my expectations. It's performance like this:

So How can I open the git history preview window like example picture? I like this plugin and thank you very much for your work.

Hey @ChiTungFok, I believe the window layout is set to be horizontal by default. However, to get the view you see in the README.md you need to set that to vertical, you can change this by doing the following when instantiating the plugin:
require('vgit').setup({
    diff_preference = 'vertical',
})

You can also change it on the fly using the following command:
:VGit set_diff_preference vertical

Glad to hear you are enjoying the plugin! Hopefully this solves your issue! Let me know if you encounter any further issues, thanks.


Search within Settings does not properly update results

Issue Type: Bug

Click the Manage gear and select Settings.
Under the "Search settings" text input box are three categories:
[User Settings]  [Workspace Settings]  [Folder Settings]
Search for a phrase, such as 'replace'
Results under the [User Settings] category for me show:
Window (1) -> New Window (1)
Features (1) -> Search (1)
Extensions (1) -> Git (1)
Click on the [Workspace Settings] category
Results under the [Workspace Settings] category for me show nothing
6a. Searching for 'replace' while this category is already selected shows:
Features (1) -> Search (1)
Extensions (1) -> Git (1)
Switch back to the [User Settings] category
Results under the [User Settings] category for me show:
Window (1)

The "Window (1)" is not expandable like it was previously.
8a. Searching for 'replace' while [User Settings] is still selected shows the results from #4 as expected.
Essentially, switching between categories, the search results are not updating properly. the results are correct if the category is already selected before searching for the keyword.
 Could you add a few screenshots so to be sure I understand what you are seeing? Can you also open the developer tools (Help > Toggle developer tools) and check for errors?


feat: add tests for @typescript-eslint/parser

What is the purpose of this pull request?

Other: added tests for @typescript-eslint/parser in the no-native rule

What changes did you make? (Give an overview)

Installed @typescript-eslint/parser as a dev dependency.
Removed the istanbul ignore next directive in the no-native source file.
Configured a second rule tester with @typescript-eslint/parser in the no-native test file.
Ran both the original rule tester and the TypeScript rule tester in the test file.
Bumped the version number from 6.0.0 to 6.0.1 in package.json and package-lock.json.

The tests seem to be failing. Converting the PR to a draft in order to fix the tests.

The tests are passing now. 😁


Support autorest --az --help to show all arguments

Want somewhere to see all arguments --az supports

move to backlog since need autorest core support


Happy New Year

Hello Timothée
Just to wish you a Happy New Year and to thank you for all you do for us free of charge and without anything in return.
Regards
Dave Neve

Thanks, I always appreciate your feedback. I'm not really doing this free of charge, though, the work has mostly been funded by grants from Svenska kulturfonden (as part of the Fiskmö project) and the European Union (as part of the European Language Grid project).


Add support for Cilium Service Mesh

Signed-off-by: Suryashankar Das<EMAIL_ADDRESS>Description
This PR fixes #294
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

@mganguli @sunkuranganath we're ready for a new release of SMP.


HystrixObservableCommand.Setter missing setter method for threadPoolKey?

At first glance it appears HystrixObservableCommand.Setter is missing setter method for protected class variable HystrixThreadPoolKey threadPoolKey? Note: HystrixCommand.Setter does have one "andThreadPoolKey".
If true, is the work around to create a HystrixCommand with a ThreadPoolKey and convert it to its Observable version?

Using thread-isolation for HystrixObservableCommand is not the right thing to do.  It will be deprecated and eventually removed (see #1200 / #1264 / #1228 for previous discussions)


Re-organize react-snippets keys to be alphabetical

Is your feature request related to a problem? Please describe.
Currently the code snippets in react-snippets aren't sorted alphabetically by key.
Describe the solution you'd like
Re-organize the keys so that they are alphabetical based on https://eslint.org/docs/rules/sort-keys. Then the test that accounts for this sorting can be re-incorporated.
Describe alternatives you've considered

Additional context

Related PR: https://github.com/intuit/accessibility-snippets/pull/44

I would Like to work on this issue!


Platform views on iOS can be synchronized starting iOS 8.0

CAEAGLLayer only supports synchronizing the GL contents with CA contents starting iOS 9.0.
With metal this is supported starting iOS 8.0.
Once we migrate to Metal we should synchronize starting iOS 8.0.

Is this still a valid issue? I'm to sure how to check if this still valid today.

@chinmaygarde @zanderso any idea if this is still outstanding?

Skia only supports the Metal backend on iOS 11.0 and later: https://github.com/flutter/flutter/issues/18208, but as for whether this is done where we use Metal, @cyanglaz might be the best person to answer.

Metal is supported on iOS 10.0 and above. I don't think addressing this issue is going to be a priority given the discussions around raising the minimum supported iOS version.

The current minimum support of the iOS version is 11. I'm closing this issue as it is obsolete.


Cannot really extend CommentModel

Because in Comment widget class you're using directly cyneek\comments\models\CommentModel:
$query = CommentModel::find()
            ->where(['entity' => $this->entity, 'entityId' => $this->entityId]);

instead of the one defined in config:
// ...
    'modules' => [
        // ...
        'comment' => [
           'class' => 'cyneek\comments\Module',
            'modelMap' => [
                'Comment' => '@app\comments\CommentModel'
            ]
        ]
    ],
    // ...

You are totally right; I'll check it out!

All right, version 1.0.3 done, try if it works ok for you and let me know, please.

Yes, thanks.


Suggested changes to be made in development

[ ] Onboarding Screen 1

Let's analyze the provided comparison of the design and the actual app screens for the "Onboarding" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:36) is different, although this is minor and can be ignored.
Skip Button: The "Skip" button text appears consistent but check the alignment and spacing.
Main Content:
Title Text: The title "Comprehensive security for your bitcoin" appears consistent in both but verify the exact font size and weight.
Image: The central graphic (illustration of keys and connections) seems consistent but ensure the exact size and positioning.
Subtitle Text: The subtitle text below the image ("Create single or multi-key wallets...") appears smaller in the app. Verify the font size and weight.
Button Styles:
Button Text: The text "See FAQs" should match in size, weight, and color.
Button Size and Padding: The size and padding of the button differ slightly between the design and the app.
Pagination Dots:
Dot Size and Spacing: The size and spacing of the pagination dots at the bottom appear consistent but verify the exact match.
Spacing:
Spacing between Elements: The spacing between the title, image, subtitle, button, and pagination dots should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
Skip Button: Ensure the "Skip" button is aligned correctly and matches the design's spacing.
Main Content:
Title Text: Verify the font size and weight of "Comprehensive security for your bitcoin" to ensure it matches the design.
Image: Ensure the size and positioning of the central graphic match the design specifications.
Subtitle Text: Increase the font size and adjust the weight of the subtitle text to match the design.
Button Styles:
Button Text: Ensure the text "See FAQs" matches the design in terms of size, weight, and color.
Button Size and Padding: Adjust the button size and padding to match the design specifications.
Pagination Dots:
Dot Size and Spacing: Verify the size and spacing of the pagination dots to ensure they match the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, image, subtitle, button, and pagination dots to match the design.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Onboarding" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Onboarding Screen 2

Let's analyze the provided comparison of the design and the actual app screens for the "Onboarding - 3" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:36) is different, although this is minor and can be ignored.
Skip Button: The "Skip" button text appears consistent, but the alignment and spacing should be verified.
Main Content:
Title Text: The title "Security should not come at the cost of privacy" appears consistent in both but verify the exact font size and weight.
Image: The central graphic (illustration of keys and connections) seems consistent, but ensure the exact size and positioning.
Subtitle Text: The subtitle text below the image ("No account creation is needed...") appears smaller in the app. Verify the font size and weight.
Button Styles:
Button Text: The text "See FAQs" should match in size, weight, and color.
Button Size and Padding: The size and padding of the button differ slightly between the design and the app.
Pagination Dots:
Dot Size and Spacing: The size and spacing of the pagination dots at the bottom appear consistent, but verify the exact match.
Spacing:
Spacing between Elements: The spacing between the title, image, subtitle, button, and pagination dots should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
Skip Button: Ensure the "Skip" button is aligned correctly and matches the design's spacing.
Main Content:
Title Text: Verify the font size and weight of "Security should not come at the cost of privacy" to ensure it matches the design.
Image: Ensure the size and positioning of the central graphic match the design specifications.
Subtitle Text: Increase the font size and adjust the weight of the subtitle text to match the design.
Button Styles:
Button Text: Ensure the text "See FAQs" matches the design in terms of size, weight, and color.
Button Size and Padding: Adjust the button size and padding to match the design specifications.
Pagination Dots:
Dot Size and Spacing: Verify the size and spacing of the pagination dots to ensure they match the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, image, subtitle, button, and pagination dots to match the design.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Onboarding - 3" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Onboarding screen 3

Let's analyze the provided comparison of the design and the actual app screens for the "Onboarding - 2" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:37) is different, although this is minor and can be ignored.
Skip Button: The "Skip" button text appears consistent, but the alignment and spacing should be verified.
Main Content:
Title Text: The title "Upgrade to Diamond Hands for generational holding" appears consistent in both but verify the exact font size and weight.
Image: The central graphic (illustration of keys and connections) seems consistent but ensure the exact size and positioning.
Subtitle Text: The subtitle text below the image ("Plan your inheritance...") appears smaller in the app. Verify the font size and weight.
Button Styles:
Button Text: The text "See FAQs" and "Start App" should match in size, weight, and color.
Button Size and Padding: The size and padding of the buttons differ slightly between the design and the app.
Pagination Dots:
Dot Size and Spacing: The size and spacing of the pagination dots at the bottom appear consistent but verify the exact match.
Spacing:
Spacing between Elements: The spacing between the title, image, subtitle, button, and pagination dots should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
Skip Button: Ensure the "Skip" button is aligned correctly and matches the design's spacing.
Main Content:
Title Text: Verify the font size and weight of "Upgrade to Diamond Hands for generational holding" to ensure it matches the design.
Image: Ensure the size and positioning of the central graphic match the design specifications.
Subtitle Text: Increase the font size and adjust the weight of the subtitle text to match the design.
Button Styles:
Button Text: Ensure the text "See FAQs" and "Start App" match the design in terms of size, weight, and color.
Button Size and Padding: Adjust the button size and padding to match the design specifications.
Pagination Dots:
Dot Size and Spacing: Verify the size and spacing of the pagination dots to ensure they match the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, image, subtitle, button, and pagination dots to match the design.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Onboarding - 2" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Welcome screen

Let's analyze the provided comparison of the design and the actual app screens for the "Welcome Start" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:37) is different, although this is minor and can be ignored.
"Need Help?" Button: The "Need Help?" button in the design is labeled "Learn More" in the app. Verify the size, padding, and color.
Main Content:
Title Text: The title "Welcome" appears consistent in both but verify the exact font size and weight.
Subtitle Text: The subtitle text ("Create a fresh app or recover an existing one") appears slightly different in size and weight. Verify consistency.
Cards Section:
The text and icons within the cards ("Start now" and "Recover an existing app") should be consistent in size and alignment.
Ensure the padding and border-radius of the cards match the design.
Footer Text: The footer text ("Note: By proceeding you agree to our Terms of Service and our Privacy Policy") appears smaller in the app. Verify the font size and weight.
Spacing:
Spacing between Elements: The spacing between the title, subtitle, cards section, and footer text should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
"Need Help?" Button: Ensure the text, size, padding, and color of the button match the design. If the button text needs to be "Learn More," ensure it matches the design specifications.
Main Content:
Title Text: Verify the font size and weight of "Welcome" to ensure it matches the design.
Subtitle Text: Adjust the font size and weight of the subtitle text to match the design.
Cards Section:
Ensure the icons and text within the cards are consistent in size and alignment with the design.
Adjust the padding and border-radius of the cards to match the design.
Footer Text: Increase the font size and adjust the weight of the footer text to match the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, subtitle, cards section, and footer text to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Welcome Start" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Home page

Let's analyze the provided comparison of the design and the actual app screens for the "Home – Start – 1" screen.
Differences Identified
Header Section:
Logo and Text: The text "Pleb" and "PLEB" seem consistent, but verify the exact font size and weight.
Gear Icon: The gear icon appears consistent, but ensure the exact size and positioning match the design.
Notification Banner:
Text Content: The text content in the notification banner differs between the design and the app.
Buttons: The "SKIP" and "ACTION" buttons in the design are different from the "SKIP" and "BACKUP" buttons in the app. Verify the size, padding, and color of the buttons.
Main Content:
Cards Section:
The icons and text within the cards (Manage Keys, Inheritance Planning, Keeper Concierge) should be consistent in size and alignment.
Ensure the padding and border-radius of the cards match the design.
Wallet Section:
The text "01 Wallets" and "1 Wallet" should be verified for font size and weight consistency.
The wallet details, including the icon and text, should match the design specifications.
Button Styles:
Add Wallet Button: The "Add Wallet" button should be consistent in size, padding, and border-radius with the design.
Button Text: Ensure the text inside the buttons is consistent in size, weight, and color.
Spacing:
Spacing between Elements: The spacing between the notification banner, cards section, wallet section, and buttons should be consistent with the design.
Bottom Margin: The bottom margin in the app appears slightly different from the design.
Instructions for Developers
Header Section:
Logo and Text: Ensure the font size and weight for "Pleb" and "PLEB" match the design.
Gear Icon: Adjust the size and positioning of the gear icon to match the design.
Notification Banner:
Text Content: Ensure the text content in the notification banner matches the design.
Buttons: Adjust the size, padding, and color of the "SKIP" and "ACTION" buttons to match the design specifications.
Main Content:
Cards Section:
Ensure the icons and text within the cards are consistent in size and alignment with the design.
Adjust the padding and border-radius of the cards to match the design.
Wallet Section:
Verify and adjust the font size and weight for the text "01 Wallets" and "1 Wallet."
Ensure the wallet details, including the icon and text, match the design specifications.
Button Styles:
Add Wallet Button: Adjust the size, padding, and border-radius of the "Add Wallet" button to match the design.
Button Text: Ensure the text inside the buttons is consistent in size, weight, and color with the design.
Spacing:
Spacing between Elements: Adjust the spacing between the notification banner, cards section, wallet section, and buttons to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Home – Start – 1" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Setting up app modals

Let's analyze the provided comparison of the design and the actual app screens for the "Setting up App" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:37) is different, although this is minor and can be ignored.
Background Blur: The background blur in the app screen is less prominent compared to the design.
Main Content:
Title Text: The title "Setting up your app" appears consistent in both but verify the exact font size and weight.
Subtitle Text: The subtitle text below the title ("Keeper lets you create...") appears slightly smaller in the app. Verify the font size and weight.
Graphic: The central graphic (illustration of gears and connections) seems consistent, but ensure the exact size and positioning.
Footer Text: The footer text ("This step will take a few seconds...") appears smaller in the app. Verify the font size and weight.
Pagination Dots:
Dot Size and Spacing: The size and spacing of the pagination dots at the bottom appear consistent but verify the exact match.
Spacing:
Spacing between Elements: The spacing between the title, subtitle, graphic, footer text, and pagination dots should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
Background Blur: Increase the background blur to match the design specifications.
Main Content:
Title Text: Verify the font size and weight of "Setting up your app" to ensure it matches the design.
Subtitle Text: Increase the font size and adjust the weight of the subtitle text to match the design.
Graphic: Ensure the size and positioning of the central graphic match the design specifications.
Footer Text: Increase the font size and adjust the weight of the footer text to match the design.
Pagination Dots:
Dot Size and Spacing: Verify the size and spacing of the pagination dots to ensure they match the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, subtitle, graphic, footer text, and pagination dots to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Setting up App" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Keeper settings

Differences Identified
Header Section:
Font Size and Weight: The font size of "Keeper Settings" appears slightly different.
Icons: The gear icon and Bitcoin icon have different placements and sizes.
Alignment: The alignment of the text "Customize your app" differs between the design and the app.
Cards Section:
Icon Sizes: The icons within the cards (Recovery Key, Manage Wallets, Personal Cloud Backup) differ in size.
Padding: The padding inside the cards appears inconsistent.
Card Shadows: The shadows on the cards seem less pronounced in the app than in the design.
Settings List:
Font Size: The text for the settings items (Dark Mode, App Access, etc.) is smaller in the app.
Switch Style: The Dark Mode toggle switch is different in design and the app in terms of color and size.
Spacing: The spacing between each settings item is less in the app compared to the design.
Footer Section:
Button Styles: The "Keeper Telegram" and "Keeper Twitter" buttons differ in padding and font size.
Text Alignment: The "Terms of Service" and "Privacy Policy" links are not aligned the same way in the app.
Instructions for Developers
Header Section:
Font Size and Weight: Ensure the font size and weight for "Keeper Settings" matches the design.
Icons: Adjust the size and placement of the gear icon and Bitcoin icon to match the design.
Alignment: Align the text "Customize your app" correctly under "Keeper Settings."
Cards Section:
Icon Sizes: Ensure the icons within the cards are the same size as in the design.
Padding: Adjust the padding inside the cards to match the design specifications.
Card Shadows: Add more pronounced shadows to the cards to match the design.
Settings List:
Font Size: Increase the font size of the settings items to match the design.
Switch Style: Update the Dark Mode toggle switch to match the design in terms of color and size.
Spacing: Increase the spacing between each settings item to match the design.
Footer Section:
Button Styles: Adjust the padding and font size of the "Keeper Telegram" and "Keeper Twitter" buttons to match the design.
Text Alignment: Ensure the "Terms of Service" and "Privacy Policy" links are aligned as per the design.
By addressing these discrepancies, the app will better align with the design specifications, ensuring a more consistent user experience.

[ ] Backup recovery key modals

Differences Identified
Header Section:
Font Size and Weight: The font size of "Backup Recovery Key" appears consistent, but ensure the weight matches the design.
Text Alignment: The alignment of the text "Carefully write down the 12-word Recovery Key..." differs between the design and the app.
Button Styles:
Button Text: The text "View Recovery Key" and "Backup Now" should match in size, weight, and color.
Button Size and Padding: The size and padding of the buttons differ between the design and the app.
Icon Size:
Icon within the Card: The icon size within the card appears larger in the app than in the design.
Spacing:
Spacing between Elements: The spacing between the text, icon, and button should be consistent with the design.
Instructions for Developers
Header Section:
Font Size and Weight: Ensure the font size and weight for "Backup Recovery Key" matches the design.
Text Alignment: Align the text "Carefully write down the 12-word Recovery Key..." correctly under the header.
Button Styles:
Button Text: Ensure the text "View Recovery Key" and "Backup Now" matches the design in terms of size, weight, and color.
Button Size and Padding: Adjust the button size and padding to match the design specifications.
Icon Size:
Icon within the Card: Reduce the icon size within the card to match the design.
Spacing:
Spacing between Elements: Increase the spacing between the text, icon, and button to match the design specifications.
By addressing these discrepancies, the "Backup Phrase (Seed)" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Recovery key

Let's analyze the provided comparison of the design and the actual app screens for the "Recovery Key" screen.
Differences Identified
Header Section:
Font Size and Weight: The font size of "Recovery Key" appears slightly different.
Text Alignment: The alignment of the text "Make sure you keep this safe" differs between the design and the app.
Input Fields:
Field Size: The size of the input fields for the recovery key is slightly different.
Font Size: The font size within the input fields appears smaller in the app.
Field Border: The borders of the input fields are lighter in the app.
Button Styles:
Button Text: The text "Next" should match in size, weight, and color.
Button Size and Padding: The size and padding of the button differ between the design and the app.
Spacing:
Spacing between Elements: The spacing between the input fields and other elements should be consistent with the design.
Note Section: The spacing around the note section at the bottom appears different.
Miscellaneous:
"Learn More" Button: The "Learn More" button in the design is not present in the app.
Bottom Navigation: The bottom navigation indicator (line) is missing in the app.
Instructions for Developers
Header Section:
Font Size and Weight: Ensure the font size and weight for "Recovery Key" matches the design.
Text Alignment: Align the text "Make sure you keep this safe" correctly under the header.
Input Fields:
Field Size: Adjust the size of the input fields to match the design specifications.
Font Size: Increase the font size within the input fields to match the design.
Field Border: Darken the borders of the input fields to match the design.
Button Styles:
Button Text: Ensure the text "Next" matches the design in terms of size, weight, and color.
Button Size and Padding: Adjust the button size and padding to match the design specifications.
Spacing:
Spacing between Elements: Increase the spacing between the input fields and other elements to match the design.
Note Section: Adjust the spacing around the note section at the bottom to match the design.
Miscellaneous:
"Learn More" Button: Add the "Learn More" button as present in the design.
Bottom Navigation: Add the bottom navigation indicator (line) as shown in the design.
By addressing these discrepancies, the "Mobile Key" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Add  Wallet Vault

Let's analyze the provided comparison of the design and the actual app screens for the "Add a Wallet" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:49) is different, although this is minor and can be ignored.
"Need Help?" Button: The "Need Help?" button in the design is labeled "Learn More" in the app. Verify the size, padding, and color.
Main Content:
Title Text: The title "Add a Wallet" appears consistent in both but verify the exact font size and weight.
Subtitle Text: The subtitle text ("Choose from a template") appears slightly different in size and weight. Verify consistency.
Cards Section:
The text and icons within the cards ("Create New," "Import," "Advanced") should be consistent in size and alignment.
Ensure the padding and border-radius of the cards match the design.
Wallet Options:
The text and icons for wallet options (Hot Wallet, 2-of-3 Vault, 3-of-5 Vault, Collaborative) should be consistent in size and alignment.
Ensure the padding and spacing are consistent with the design.
Upgrade Section:
The "Upgrade" button and the text "Available to Diamond Hands users" should be consistent in size and style. Verify padding and alignment.
Spacing:
Spacing between Elements: The spacing between the title, subtitle, cards section, wallet options, and upgrade section should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
"Need Help?" Button: Ensure the text, size, padding, and color of the button match the design. If the button text needs to be "Learn More," ensure it matches the design specifications.
Main Content:
Title Text: Verify the font size and weight of "Add a Wallet" to ensure it matches the design.
Subtitle Text: Adjust the font size and weight of the subtitle text to match the design.
Cards Section:
Ensure the icons and text within the cards ("Create New," "Import," "Advanced") are consistent in size and alignment with the design.
Adjust the padding and border-radius of the cards to match the design.
Wallet Options:
Ensure the text and icons for wallet options (Hot Wallet, 2-of-3 Vault, 3-of-5 Vault, Collaborative) are consistent in size and alignment with the design.
Adjust the padding and spacing to match the design specifications.
Upgrade Section:
Ensure the "Upgrade" button and the text "Available to Diamond Hands users" are consistent in size and style with the design. Adjust the padding and alignment as needed.
Spacing:
Spacing between Elements: Adjust the spacing between the title, subtitle, cards section, wallet options, and upgrade section to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Add a Wallet" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Create a hot Wallet

Let's analyze the provided comparison of the design and the actual app screens for the "Add a Wallet – Hot Wallet" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) is consistent in both screens.
"Need Help?" Button: The "Need Help?" button is labeled consistently, but verify the size, padding, and color.
Main Content:
Title Text: The title "Create a Hot Wallet" appears consistent in both, but verify the exact font size and weight.
Subtitle Text: The subtitle text ("With Mobile key (Single-key)") appears slightly different in size and weight. Verify consistency.
Input Fields:
The text and placeholder within the input fields ("Name your vault," "Add a description (Optional)," "$") should be consistent in size and alignment.
Ensure the padding and border-radius of the input fields match the design.
Text Below Input: The instructional text below the input fields ("When the wallet balance crosses...") appears slightly smaller in the app. Verify the font size and weight.
Button Styles:
The "Proceed" button should be consistent in size, padding, and border-radius.
Ensure the text inside the button is consistent in size, weight, and color.
Spacing:
Spacing between Elements: The spacing between the title, subtitle, input fields, instructional text, and buttons should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
"Need Help?" Button: Ensure the text, size, padding, and color of the button match the design.
Main Content:
Title Text: Verify the font size and weight of "Create a Hot Wallet" to ensure it matches the design.
Subtitle Text: Adjust the font size and weight of the subtitle text to match the design.
Input Fields:
Ensure the text and placeholder within the input fields ("Name your vault," "Add a description (Optional)," "$") are consistent in size and alignment with the design.
Adjust the padding and border-radius of the input fields to match the design.
Text Below Input: Increase the font size and adjust the weight of the instructional text below the input fields to match the design.
Button Styles:
Adjust the size, padding, and border-radius of the "Proceed" button to match the design.
Ensure the text inside the button is consistent in size, weight, and color with the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, subtitle, input fields, instructional text, and buttons to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Add a Wallet – Hot Wallet" screen will better align with the design specifications, ensuring a more consistent user experience.

[ ] Setup a Vault

Let's analyze the provided comparison of the design and the actual app screens for the "Add a Vault" screen.
Differences Identified
Header Section:
Time Display: The time on the design (9:41) and the app (11:49) is different, although this is minor and can be ignored.
"Need Help?" Button: The "Need Help?" button is labeled consistently, but verify the size, padding, and color.
Main Content:
Title Text: The title "Setup a Vault" appears consistent in both, but verify the exact font size and weight.
Subtitle Text: The subtitle text ("Create an m-of-n vault") appears slightly different in size and weight. Verify consistency.
Input Fields:
The text and placeholder within the input fields ("Name your vault," "Add a description (Optional)") should be consistent in size and alignment.
Ensure the padding and border-radius of the input fields match the design.
Configuration Section:
The text and buttons for "Total keys for vault configuration" and "Required Keys" should be consistent in size and alignment.
Ensure the padding, border-radius, and spacing of the buttons match the design.
Button Styles:
The "Proceed" button should be consistent in size, padding, and border-radius.
Ensure the text inside the button is consistent in size, weight, and color.
Spacing:
Spacing between Elements: The spacing between the title, subtitle, input fields, configuration section, and buttons should be consistent with the design.
Bottom Margin: The bottom margin in the app appears larger than in the design.
Instructions for Developers
Header Section:
"Need Help?" Button: Ensure the text, size, padding, and color of the button match the design.
Main Content:
Title Text: Verify the font size and weight of "Setup a Vault" to ensure it matches the design.
Subtitle Text: Adjust the font size and weight of the subtitle text to match the design.
Input Fields:
Ensure the text and placeholder within the input fields ("Name your vault," "Add a description (Optional)") are consistent in size and alignment with the design.
Adjust the padding and border-radius of the input fields to match the design.
Configuration Section:
Ensure the text and buttons for "Total keys for vault configuration" and "Required Keys" are consistent in size and alignment with the design.
Adjust the padding, border-radius, and spacing of the buttons to match the design.
Button Styles:
Adjust the size, padding, and border-radius of the "Proceed" button to match the design.
Ensure the text inside the button is consistent in size, weight, and color with the design.
Spacing:
Spacing between Elements: Adjust the spacing between the title, subtitle, input fields, configuration section, and buttons to match the design specifications.
Bottom Margin: Reduce the bottom margin to match the design specifications.
By addressing these discrepancies, the "Add a Vault" screen will better align with the design specifications, ensuring a more consistent user experience.

Not relevant I think


feat resource parsing by type

This is more for letting you guys know the type of changes I am doing to avoid touching on some of this files.
I have introduced a resource type which matches the LBA extensions: http://lbafileinfo.kazekr.net/index.php?title=File_formats_by_extension
The idea is for each type we have a parsing function that will allow us to parse and create our own formats.
Only few of the things have changed and so far seems to be working fine. Had some weird issues with some scenes failing on getFloorHeight for some unknown reasons but that seems to be fine now.
The PR will also help us test a bit more this changes since there are a lot of times that have been changed.
Preview here: https://pr-384.lba2remake.net

@agrande @slwilliams please have a look at the resource management changes to facilitate the LBA1 support.
Not fully finished, but to ensure we do not diverge from master too much, so it's better to merge it.


Needs to be updated to rust-alpha

src/lib.rs:1:12: 1:28 warning: feature has been added to Rust, directive not necessary
src/lib.rs:1 #![feature(associated_types, globs, unboxed_closures)]
                        ^~~~~~~~~~~~~~~~
src/lib.rs:1:30: 1:35 warning: feature has been added to Rust, directive not necessary
src/lib.rs:1 #![feature(associated_types, globs, unboxed_closures)]
                                          ^~~~~
src/lib.rs:1:12: 1:28 warning: feature has been added to Rust, directive not necessary
src/lib.rs:1 #![feature(associated_types, globs, unboxed_closures)]
                        ^~~~~~~~~~~~~~~~
src/lib.rs:1:30: 1:35 warning: feature has been added to Rust, directive not necessary
src/lib.rs:1 #![feature(associated_types, globs, unboxed_closures)]
                                          ^~~~~
src/lib.rs:12:5: 12:23 error: unresolved import `std::c_str::ToCStr`. Could not find `c_str` in `std`
src/lib.rs:12 use std::c_str::ToCStr;

@tomassedovic I don't know how you'd feel about this, but is there any chance that you could add me to the managers of the tcod crate on crates.io? That way I can publish new versions of the crate when updating for new versions of Rust.

@jgilchrist would love to! Do you happen know how to do that? Quick glance at the UI didn't help. I'll try to find out.

ah, here we go: http://doc.crates.io/crates-io.html#cargo-owner
@jgilchrist thanks for all your help in the last few days. You an owner of tcod and tcod-sys crates now :-)

Brilliant, just to check I know what's going on I'll bump the version and try and release a new version to crates.io which will run on the latest rust. No worries, and thanks!

It worked, brilliant! 0.3.2 is out.

Sweet!


First cut making Dijkstra.AST.* independent of other namespaces

An initial attempt to make Dijkstra.AST.* independent of other namespaces, particularly Haskell.*.  Everything under Dijkstra.AST compiles, but LibraBFT.Impl.Consensus.BlockStorage.BlockTree does not.  We have some challenges where we want to mix Haskell and AST that I have not ironed out yet.  In some cases I have duplicated definitions in Dijkstra.AST.Prelude and friends, but this has led to some difficulties around things like where Monad instances come from, and having the right syntax definitions in the right context.  Need to step back and think more about this, but sharing what I have for now.
Signed-off-by: Mark Moir<EMAIL_ADDRESS>

I am creating a new version of this PR, with the issues outlined above addressed, so closing this one.


Create error-returning variants of all calls

I understand the convenience of just turning errors into panics, it allows easier method chaining and can make the code look much cleaner.
But when integrating into existing codebases, the code is no longer idiomatic and it becomes a bit messy to handle errors without taking down a large system. Of course, it could be handled by wrapping all calls in recover, but that just makes the code very confusing and harder to maintain.
It would be nice if errors handling was a little easier.

One solution would be to just have an extra copy of methods that can return errors. Like LoadModelE, model.ExecE, etc.
For method chaining the error could be kept in the returned struct and checked using a .Check call.
This will conflict with the current use of panics, so it should either be a new set of chainable methods or put in a new major version

E.g.
  m := tg.LoadModelP(....)  // panic on error
  m, err := tg.LoadModelE(....) // return error
  m := tg.LoadModel(...) // does not panic, but saves the error
  err := m.Check() // return above error

It's definitely not perfect, and the idea of having an error hanging around in the model struct isn't the most elegant solution

Hm... I find the proposed solution of doubling the API a bit ugly but I totally understand your point.
Perhaps it would be better to look at the tfgo codebase and see where there are panics that can be turned into errors - for sure not in the method changing (hence every operation on the tensors should panic, and I guess this is correct because it means we are building a static graph in a wrong way and it's just impossible to fix this at runtime).
But from a very quick look, I see that, for example, model.Exec panics, and this is something that instead can return an error (the model can return an error when bad input is passed or other similar I/O problems).
Even the LoadModel/ImportModel can both return an error instead of panicking (e.g. when the model location is changed at runtime, it's easy to recover from this situation instead of going in panic).
If you're willing to follow this path (searching for panic in the codebase, check if they are "too much" and replace with the error return, but not in the method changing graph definition ), I'd be happy to review a merge request :smile:


With the release of Docker 19.03, usage of nvidia-docker2 packages are deprecated since NVIDIA GPUs are now natively supported as devices in the Docker runtime.

Is there any influences on PAI? If I need to upgrade the version of docker (I'm using 18.x right now), or to upgrade the nvidia-docker2?

We have not tested the latest release of Docker and nvidia-docker2.

Is there any influences on PAI? If I need to upgrade the version of docker (I'm using 18.x right now), or to upgrade the nvidia-docker2?

@Chenyangzh thanks for supporting OpenPAI, which OpenPAI version are you using?

Hi @Chenyangzh,
In short, no.
For k8s version, PAI only uses nvidia-container-runtime instead of deprecated nvidia-docker. You can upgrade docker-ce to 19.03 and it won't break anything.

PAI runs GPU containers in k8s using nvidia runtime as default runtime and set GPUs through NVIDIA_VISIBLE_DEVICES, which works for both docker-ce version 18 and 19.
Starting from 19.03, docker supports --gpus option to run GPU containers directly in runc runtime, it also leverages nvidia-container-runtime.

So if you installed nvidia-container-runtime package (NOT nvidia-container-toolkit) correctly, and set nvidia as default runtime, there's no change after upgrading docker-ce to latest version.


ipython v5 breaks beaker

on the JS console:
Using ipython compatibility mode: 5
namespace.js:10 accessing `utils` is deprecated. Use `require("base/js/utils")`
beakerApp.js:18756 note: probing until backend is ready, an error here is normal
8http://<IP_ADDRESS>:8801/0aad728/ipython.679656566778/login Failed to load resource: the server responded with a status of 502 (Bad Gateway)
namespace.js:10 accessing `utils` is deprecated. Use `require("base/js/utils")`
namespace.js:21 accessing `Kernel` is deprecated. Use `require("services/kernels/kernel").Kernel`
kernel.js:458 Starting WebSockets: ws://<IP_ADDRESS>:8801/0aad728/ipython.679656566778/api/kernels/c3ce846b-eef6-4279-bde7-2c2e0366773e
beakerVendor.js:63042 TypeError: Cannot read property 'readyState' of undefined
    at waitForKernel (ipython.js:609)
    at setShellIdCB (ipython.js:617)
    at spin (ipython.js:153)
    at beakerVendor.js:68649
    at completeOutstandingRequest (beakerVendor.js:55361)
    at beakerVendor.js:55637

i think unfortunately we should revert https://github.com/twosigma/beaker-notebook/commit/b4e41296e2a72b2fc49edd6b66187e8bf3cdebbe
and then support each version explicitly like we used to.

i think unfortunately we should revert b4e4129


feat: use streaming in playground requests

Fixes #23
What does this PR do?
Use streaming when sending requests to the playground
Screenshot / video of UI

What issues does this PR fix or reference?
#23

How to test this PR?
Just play with the playground

When testing on Linux, the following error is raised when calling const client = new OpenAI({ baseURL: http://localhost:${state.container.port}/v1 });:
Error: The OPENAI_API_KEY environment variable is missing or empty; either provide it, or instantiate the OpenAI client with an apiKey option, like new OpenAI({ apiKey: 'My API Key' }).

I am having the same issue

When testing on Linux, the following error is raised when calling const client = new OpenAI({ baseURL: http://localhost:${state.container.port}/v1 });:
Error: The OPENAI_API_KEY environment variable is missing or empty; either provide it, or instantiate the OpenAI client with an apiKey option, like new OpenAI({ apiKey: 'My API Key' }).

Should be fixed now

When testing on Linux, the following error is raised when calling const client = new OpenAI({ baseURL: http://localhost:${state.container.port}/v1 });:
Error: The OPENAI_API_KEY environment variable is missing or empty; either provide it, or instantiate the OpenAI client with an apiKey option, like new OpenAI({ apiKey: 'My API Key' }).

I am having the same issue

Should be fixed now


Clean up sidebar nav

Move FAA and Wordle examples so they only take a single entry in the Table of Contents on the side

CLA-bot triggered due to invalid .gitconfig associated with some of the commits. Fixed the issue and re-pushed the branch.


Hotfix lp unregister

Hotfix for issue 36
Temporarily freeze unregister lp logic when a user remove all liquidity from a pool.

This hotfix has been discard.


fix misspell "environment" in helpers.go

This change is

@fate-grand-order Thanks for the fix!
/lgtm
/approve


Enforce type header validation not working

Describe the issue:
Hi Team,
[apim.token.validation]
enforce_type_header_validation = true

But it didn't work because WSO2 IS (as key-manager) still produced access tokens without "typ" header however this type header is available in the token which was generated in IS 6.1.0 and the above param and fix is working for IS KM 6.1.0
How to reproduce:

Setting up the APIM 4.1.0 and IS 5.11 as KM.
Enable the below property in the APIM to enforce type header for token validation.

[apim.token.validation]
enforce_type_header_validation = true

Expected behavior:

Environment information

Product Version: IS 5.11.0

The same concern is faced in a setup with APIM 3.2.0 and ISKM 5.10.0. This is because the JWT tokens generated by ISKM 5.10.0 does not have the typ header in the access token


Doctor Visits adjusted signal AUC does not match the raw signal

Actual Behavior:
When looking at the data from the Doctor Visits signal, the day-adjusted signal does not seem to match the area under the curve of the raw signal.

Expected behavior
@RoniRos and I were looking through this yesterday and it was our intuition that the AUC should match between these two signals.
Context
Here's some code to replicate the plot above
import wget

docvisit = wget.download("https://api.covidcast.cmu.edu/epidata/covidcast/csv?signal=doctor-visits:smoothed_cli&start_day=2024-05-29&end_day=2024-08-29&geo_type=nation")
docvisitadj = wget.download("https://api.covidcast.cmu.edu/epidata/covidcast/csv?signal=doctor-visits:smoothed_adj_cli&start_day=2024-05-29&end_day=2024-08-29&geo_type=nation")

df = pd.read_csv("covidcast-doctor-visits-smoothed_cli-2024-05-29-to-2024-08-29.csv")
dfadj = pd.read_csv("covidcast-doctor-visits-smoothed_adj_cli-2024-05-29-to-2024-08-29.csv")

df.time_value = pd.to_datetime(df.time_value, utc=True)
dfadj.time_value = pd.to_datetime(dfadj.time_value, utc=True)
dfadj = dfadj[['time_value', 'value']].rename(columns={'time_value':'time_value', 'value':'valueadj'})

foo = df[['time_value', 'value']].merge(dfadj, on='time_value', how='left')
foo.plot(x='time_value', y=['value', 'valueadj'])

I believe this was part of @rumackaaron 's work. Are we correct in assuming that these should match?

Interesting find! Mathematically, they don't have to match and I think that's the expected behavior in this case. When creating the design matrix in weekday.py, the constraint is that $\sum_{wd=0}^6 \alpha_{wd} = 1$. After fitting the day-of-week parameters $\alpha$, we take the original signal $y_t$ and multiply it by $\exp(\alpha_{wd})$ to get the weekday-adjusted signal $y'_t$ (where $wd$ is the day-of-week of $t$).
For simplicity, say that there are only two days in the week. Let $\alpha_0 = -1$ and $\alpha_1 = 1$, and $y_0 = 5$ and $y_1$ = 1. The sum of the raw values $y$ is 6, and the sum of the weekday-adjusted values is $5\exp(-1) + \exp(1) = 4.55$. We see something similar here, where the sum of the adjusted signal is lower than the sum of the raw signal.
It may be possible to create a different constraint to ensure that (at least on the training data), the sum of the original signal is the same as that of the adjusted signal. I don't think it's possible to ensure that constraint holds over an arbitrary time interval while using multiplicative day-of-week effects.
P.S. I find it concerning that the "sawtooth" pattern is still present in the adjusted signal. I don't know what the training period is for fitting the day-of-week effects, but it may be worth experimenting to find an appropriate period that consistently removes the "sawtooth" pattern.

I don't think it's possible to ensure that constraint holds over an arbitrary time interval while using multiplicative day-of-week effects.

Indeed.  In fact, it's not possible to ensure that with any modification (think of the special case of an interval of one day).
Even if we relax the requirement to all intervals of some fixed length (e.g. 7 days), I think that the only solution is a moving average.  But a moving average isn't sufficiently sensitive to the most recent developments.
This suggests an asymmetric kernel, e.g. a triangle or half-Gaussian.  I think all kernels satisfy some form of long-term AUC equivalence.   But this doesn't address the day-of-week effects.
We need to send this problem for some research TLC.


encoding/xml: copyValue uses int16 causing error on strconv.ParseInt

What version of Go are you using (go version)?

> go version
go version go1.12.5 windows/amd64

What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Michael\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\Michael\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Michael\AppData\Local\Temp\go-build556838694=/tmp/go-build -gno-record-gcc-switches

What did you do?
Unmarshalled an XML node containing the int value 258387
What did you expect to see?
The string "258387" parsed correctly to it's integer value.
What did you see instead?
When parsing an XML attribute, the xml.Unmarshal method uses a signed 16b int for the destination of ParseInt.
When the parsed integer is > MAX_16 an (expected for the size of dst) error is thrown.
Not sure if this is reproducible every time an int is parsed > MAX_16, rather in my large (40MB) XML file, this is a consistent occurrence with every int.
in xml/read.go:

		itmp, err := strconv.ParseInt(strings.TrimSpace(string(src)), 10, dst.Type().Bits())
		if err != nil {
			return err
		}

the value presented by the debugger during runtime:

dst0.Type():
...
size = 2
align = 2
... trimmed
fieldAlign = 2
...

call stack:

encoding/xml.copyValue at read.go:618
encoding/xml.(*Decoder).unmarshal at read.go:574
encoding/xml.(*Decoder).unmarshalPath at read.go:685
encoding/xml.(*Decoder).unmarshal at read.go:519
encoding/xml.(*Decoder).unmarshalPath at read.go:685
encoding/xml.(*Decoder).unmarshal at read.go:519
encoding/xml.(*Decoder).unmarshalPath at read.go:685
encoding/xml.(*Decoder).unmarshal at read.go:519
encoding/xml.(*Decoder).DecodeElement at read.go:146
encoding/xml.(*Decoder).Decode at read.go:134
encoding/xml.Unmarshal at read.go:128
... call back to main, trimmed for brevity

I should add, for dst0 and dst:

// line 602-603
func copyValue(dst reflect.Value, src []byte) (err error) {
	dst0 := dst

both dst0 and dst are equal

@alfarom256 can you provide an example input that causes an error, ideally in a play.golang.org snippet?

Please excuse my report, there was a type assigned in a buried struct.
I changed it to int32 and the error was fixed.
User error strikes again!


Document setup using stackblitz

Stack blits can be used to develop cv-frontend without having to setup everything locally.
https://stackblitz.com/~/github.com/CircuitVerse/cv-frontend-vue

That's good idea @tachyons shall i take this up

seems like the preview is failing for this link

Very true its on both firefox and chrome.

https://cvfrontendvue-3bdo--4000--22b9f6d5.local-corp.webcontainer.io/simulatorvue/   Try to use this on the then its working fine.