docs(dependency-injection): revised Dart and TS code and prose

Contributes to #1508 and #1522.

The main change on the TS side is to present best practices first, rather than presenting sample code and then saying "don't do that".
The "Optional dependencies" section has been moved towards the end of the provider variants section and its sample code has been simplified.
Reworked *_1.{ts,dart} sources so that main_1.{ts,dart} can actually be run, which helped find some bugs in those sources.
Despite https://github.com/angular/angular/issues/8928, the Dart and TS OpaqueToken sections have been left in the prose. They can be revisited later.

Enhancements to the Dart code include:

Added TestComponent.
Added a provider sample that makes use of an app config Map (to match TS); also added the more Dart-like use of a custom app configuration class, whose instance is initialized via the cascade operator.
Fixed Engine class hierarchy so that a single field named cylinders is defined (rather than two fields: one in the Engine supertype and one in the subclass), because having two fields is a bad design smell.
Similarly, fixed Logger hierarchy so that a single field named logs is defined. Also made logs a read-only field.
Reintroduced the SilentLogger().

@Foxandxss @wardbell @thso @kwalrath : this is ready for review. As usual, it is less painful to view the diff while ignoring changes in whitespace (such as indentation).

I have nothing to add, @kwalrath is doing an awesome job on the review. Sounds fine for me.

Looks great! The only real problem I saw was the "key benefits of defining a configuration object class" paragraph, which needs to be clarified and probably broken up.

@Foxandxss & @wardbell: I don't know the TS side, so you still might want to take a look to make sure the new text is OK by you...

Will look

Updates done.

Looks great! The only real problem I saw was the "key benefits..." paragraph

That paragraph has been reworked.

I had a couple more quibbles about the cascade wording, but otherwise LGTM.

Updates done.

LGTM. I'll merge this unless someone screams NO...


No up-to-date data retrieved

I use the API to retrieve status of my climate system
Every 5 mins I request zone info from the AirzoneCloud and store information in my influx / grafana setup.
It seems requested data is not up-to-date. However after accessing the AirzoneCloud with the app and do a request again via the python script the data is up-to-date.
What can cause this issue ?

I am using several refresh options and also the ask_airzone_update
Is there an example available of how this should work (to fetch up-to-date temperature and humidity data)

Hello,
I just released a new version using the official Airzone API : https://developers.airzonecloud.com/docs/web-api/
That should fix this issue so I close it.
Max


Add feature: Plugins update

Hi guys,
I'm thrilled to suggest a new feature for Insomnia! This feature will make updating installed plugins easier and more intuitive for all users. Previously, the update process required a bit of maneuvering, as users had to reinstall their plugins. I've essentially added a touch of UI enhancement to streamline this process. I'm eager to hear everyone's feedback on this!

I think this is a great feature, thank you so much for your work on this! However, Check Updates implies that it will only Check whether there are updates or not and present that information to me. I would actually prefer that approach as well. I don't want all my plugins to be updated without me being able to first review. Ideally, I would be able to click Check Updates, see what plugins have updates available, and then be able to individually pick and choose which plugins will get updated.

As no one from Insomnia team reacted so far, I'm closing my PR


Add a module pulsar-ai-functions to have a distinct NAR for AI ops

The name of the built-in function will be ai-functions ai-tools

It would be great to not bundle the OpenAI (and eventually the HuggingFace) jars into the standard transform function

done


creating Mars Mission images search form

As a user,
I would like to enter a date and camera
so that I can view the images taken by the rover on that day and camera
Acceptance Criteria:

the user is presented with the following fields: date and camera
the form must have error messages on invalid input
the user can proceed with mars rover images search only after all fields are populated correctly.

done


Authorized Views Bug When Using Schema Property on Relationship

Describe the bug
BigQuery Authorized views cannot be dynamically granted.
Steps To Reproduce
This config should grant access to the underlying tables:
{{ config(
  grant_access_to=[
    {'project': ref('pharmacy_claims_recon_yearmonth').database , 'dataset': ref('pharmacy_claims_recon_yearmonth').schema}
  ]
  )
}}

select *
from {{ ref('pharmacy_claims_recon_yearmonth') }}

The access grant successfully works with ref('pharmacy_claims_recon_yearmonth').database.
The access grant DOES NOT successfully work with ref('pharmacy_claims_recon_yearmonth').schema.  Dataset will work with a variable declared with the {% set variable='value' %} command, but no variation on the schema property appears to work, including explicitly casting it to a string like ref('pharmacy_claims_recon_yearmonth').schema|string.
Expected behavior
Access grant works correctly off of the schema value of a relationship.
Screenshots and log output
If applicable, add screenshots or log output to help explain your problem.
2021-12-10T23:49:04.768410Z: Began running node model.vida.v_pharmacy_claims_recon_yearmonth
2021-12-10T23:49:04.768702Z: 23:49:04 | 1 of 1 START view model dbt_bliyanage_clinops.v_pharmacy_claims_recon_yearmonth [RUN]
2021-12-10T23:49:04.768933Z: Acquiring new bigquery connection "model.vida.v_pharmacy_claims_recon_yearmonth".
2021-12-10T23:49:04.769013Z: Compiling model.vida.v_pharmacy_claims_recon_yearmonth
2021-12-10T23:49:04.775412Z: Writing injected SQL for node "model.vida.v_pharmacy_claims_recon_yearmonth"
2021-12-10T23:49:04.790750Z: finished collecting timing info
2021-12-10T23:49:04.813317Z: Writing runtime SQL for node "model.vida.v_pharmacy_claims_recon_yearmonth"
2021-12-10T23:49:04.826940Z: Opening a new connection, currently in state closed
2021-12-10T23:49:04.827102Z: On model.vida.v_pharmacy_claims_recon_yearmonth: /* {"app": "dbt", "dbt_version": "0.20.2", "profile_name": "user", "target_name": "default", "node_id": "model.vida.v_pharmacy_claims_recon_yearmonth"} */

  create or replace view `test-dbt-vida`.`dbt_bliyanage_clinops`.`v_pharmacy_claims_recon_yearmonth`
  OPTIONS()
  as

select *
from `test-dbt-vida`.`dbt_bliyanage_claims`.`pharmacy_claims_recon_yearmonth`;

2021-12-10T23:49:05.944456Z: Access entry <AccessEntry: role=None, view={'projectId': 'test-dbt-vida', 'datasetId': 'dbt_bliyanage_clinops', 'tableId': 'v_pharmacy_claims_recon_yearmonth'}> already exists in dataset
2021-12-10T23:49:05.944813Z: finished collecting timing info
2021-12-10T23:49:05.945195Z: Sending event: {'category': 'dbt', 'action': 'run_model', 'label': '27b7581e-1241-47f3-ad36-bfb5e7099b84', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x7fc1c9436e80>]}
2021-12-10T23:49:05.945507Z: 23:49:05 | 1 of 1 OK created view model dbt_bliyanage_clinops.v_pharmacy_claims_recon_yearmonth [OK in 1.18s]
2021-12-10T23:49:05.945589Z: Finished running node model.vida.v_pharmacy_claims_recon_yearmonth

System information
The output of dbt --version:

In build configs we use: 0.20.2
Additional context
Here are a couple other observations from troubleshooting this:

When this fails to authorize a view (for example, because of a bad value) the error is eaten and never raised, with either a log or error message.  This makes it very hard to troubleshoot when this is working.
It would be nice if there was a log message confirming the authorization grant when it was successful as well.
It appears when there is an error, the logs report Access entry <AccessEntry: role=None, view={'projectId': 'test-dbt-vida', 'datasetId': 'dbt_bliyanage_clinops', 'tableId': 'v_pharmacy_claims_recon_yearmonth'}> already exists in dataset, even if there is no authorization.

In an ideal world, we would just be able to specify grant_access, and dbt would be able to resolve all ref's in a particular query, and grant access to the appropriate underlying datasets without them having to be explicitly named by a person.

@BenLiyanage Thanks for the detailed write-up, and sorry for the delay getting back to you!
Explanation
You're doing everything right here. The problem has to do with how dbt resolves and stores configuration values. This happens at parse time, and aren't recalculated at execution time, with the exception of pre/post hooks wrapped in extra curly braces.
At parse time, dbt hasn't yet resolved the configs of the other model (ref('pharmacy_claims_recon_yearmonth')), so it just uses some placeholder values instead—specifically, it uses the default database + schema of the current model. Those placeholder values are saved in the grant_access_to config, so they're what's used when it comes time later on to actually grant access.
This is quite confusing behavior that trips up lots of folks in dbt (https://github.com/dbt-labs/dbt-core/issues/2921, https://github.com/dbt-labs/dbt-core/issues/2793). The ultimate resolution might look like:

Supporting "nested curlies" for more configs, telling dbt to re-render them at execution time
Re-rendering all configs at execution time, at the risk of the config: selection method yielding inconsistent results

Workaround
In the meantime, in order to keep the table location and the authorized view's access grant in sync, your best bet is to use a var() (defined in dbt_project.yml) or env_var() for both:

Configuring the database + schema for pharmacy_claims_recon_yearmonth
Configuring grant_access_to for the authorized view

The var / env var is fully resolved and available at parse time, so dbt will calculate and store the correct value in both places.

Okay, what would it look like to actually solve this problem? I think your suggestions are spot on.
More visibility

It would be nice if there was a log message confirming the authorization grant when it was successful as well.

Agreed — let's add some more logging to the grant_access_to method, so that it logs before every grant attempt, and after successful grants. It may add a bit of noise to the debug-level logs, but I think it's worth it for functionality this subtle:
        logger.debug(f"On {entity}: Attempting to grant {access_entry}")

        if access_entry in access_entries:
            logger.debug(f"Access entry {access_entry} "
                         f"already exists in dataset")
            return

        access_entries.append(AccessEntry(role, entity_type, entity))
        dataset.access_entries = access_entries
        client.update_dataset(dataset, ['access_entries'])
        logger.debug(f"On {entity}: Succeeding in granting {access_entry}")

Better overall approach

In an ideal world, we would just be able to specify grant_access, and dbt would be able to resolve all ref's in a particular query, and grant access to the appropriate underlying datasets without them having to be explicitly named by a person.

You're really onto something! This feels quite ergonomic, and it honestly wouldn't be so far-fetched to implement.
Let's say you were able to define a config like:
{{ config(authorized_view: true) }}

Then, we could add logic to the view materialization:
    {% if config.get('authorized_view') %}
      {# Create a list of all ref/source relations this model depends on #}
      {% set source_array = [] %}
      {% for ref_table in model.refs %}
        {{ source_array.append(ref(*ref_table)) }}
      {% endfor %}
      {% for src_table in model.sources %}
        {{ source_array.append(source(*src_table)) }}
      {% endfor %}

      {# For each ref/source, grant access to its dataset. This could be cleverer to avoid duplicative grants #}
      {% for src_tbl in source_array %}
        {% set grant_target_dict = {'project': src_tbl.project, 'dataset': src_tbl.dataset} %}
        {% do log(grant_target_dict, info = true) %}
        {% do adapter.grant_access_to(this, 'view', None, grant_target_dict) %}
      {% endfor %}
    {% endif %}

With that logic in place, I manage just run the view, and it grants access to every project.dataset pair I need!
In that world, users probably  wouldn't need to pass the grant_access_to config explicitly—but you could always go to "full-control" mode if need be.
While this is a tricky feature, the code is nicely self-contained, so I'm going to mark this a good first issue. Is this something you'd have any interest working on / contributing to? :)

Hey @jtcohen6 --can you provide an example of the project version of this setup?
Re: a better implementation -- We are an enterprise customer.  Ideally this is put onto a backlog since we are paying a hefty sum for this product.  We pay for this so we don't have to build our own internal version, and can focus on building our own product differentiator.  Let me know if there are any dots that need to be connected around that.  I believe @matt-winkler was one of our onboarding reps.

Another callout around authorized views: in our home grown system we also did what you guys are doing--authorizing views individually via an append strategy.  This is incredibly slow compared to updating a datasets list once at the end with the exhaustive list of views to authorize.

Another callout--I was really hoping to make a macro that just authorizes a bunch of refs.  If we have to hard code the locations of all the refs that seems like it would make it hard to do, or atleast require a lot of variables.

@BenLiyanage Appreciate the callouts. My goal here is to balance between a general implementation that makes sense (I think you suggested a good one), and giving you the information and tools to unlock the behavior you're after, given your specific needs.
If you're willing to include a custom macro in your project for this, there are folks on the dbt Labs team who can certainly help with the solution-ing work to make it happen. I believe it would be totally doable, by combining a few ingredients:

the grant_access_to macro / context method, which is available for custom use, above and beyond the current implementation in the BigQuery view materialization. Given your comment, it sounds like a concrete improvement would be allowing grant_access_to to accept multiple entities (= authorized views), and grant access on a common dataset to all of them at once
the Results object, available in the on-run-end hook (i.e. run once at the end of dbt run), which has access to full configuration and information about the models that just ran — including which ones are configured to be authorized views, and their direct upstream dependencies

This is decidedly spaghetti code, but hopefully it's a demonstration of what's possible when writing custom macros that tap into existing functionality in the dbt-bigquery plugin. I see two clear avenues for improvement:

More user-friendly default behavior, which grants access to one auth view's upstream dependencies (as described above)
Exposing the capability, in the grant_access_to adapter method, to grant access to multiple auth views at once, for users who want to batch grants for speedier results at scale

{% macro grant_access_to(entities, entity_type, role, grant_target_dict) -%}
  {# This macro takes a list of "entities" (authorized views) and grants them access to a dataset (specified by grant_target_dict) #}
  {# Currently, the dbt-biquery (Python) method `grant_access_to` appends entities one-by-one #}
  {# It sounds like we could speed this up by making it possible to append many entities at once #}

  {% for entity in entities %}
    {% set entity_name = entity.database + "." + entity.schema + "." + entity.alias %}
    {% do log("... to " + entity_name, info = true) %}
    {% do adapter.grant_access_to(entity, entity_type, role, grant_target_dict) %}
  {% endfor %}

{% endmacro %}

{% macro parse_auth_view_upstream_datasets_from_results(results) %}
  {# This macro takes the `Results` object, available in the `on-run-end` context, identifies models #}
  {# configured with `authorized_view: true`, and parses the database location of their upstream model dependencies #}
  {# via the `graph.nodes` context variable #}
  {# It returns a dictionary containing one entry per dataset to grant access on, and each of those entries #}
  {# contains a list of authorized views that need access to it #}

  {% if execute %}

  {% set datasets_to_grant_access_on = {} %}

  {% for result in results %}

    {% set node = result.node %}

    {% if node.config.get('authorized_view') %}

      {% for upstream_id in node.depends_on.nodes %}
        {% for upstream_node in graph.nodes.values() %}
          {% if upstream_node['unique_id'] == upstream_id %}
            {% set dataset_fqn = upstream_node.database + '.' + upstream_node.schema %}
            {% if dataset_fqn in datasets_to_grant_access_on.keys() %}
              {% do datasets_to_grant_access_on[dataset_fqn]['needs_access'].append(node) %}
            {% else %}
              {% do datasets_to_grant_access_on.update({dataset_fqn: {
                'project': upstream_node.database,
                'dataset': upstream_node.schema,
                'needs_access': [node]
              }}) %}
            {% endif %}
          {% endif %}
        {% endfor %}
      {% endfor %}

    {% endif %}

  {% endfor %}

  {{ return(datasets_to_grant_access_on) }}

  {% endif %}

{% endmacro %}

{% macro grant_access_for_all_authorized_views(results) %}
  {# This macro is the entrypoint to the operation. It receives results, #}
  {# parses them via the macro defined above, and finally loops over each dataset entry #}
  {# to grant access #}

  {% set datasets_to_grant_access_on = parse_auth_view_upstream_datasets_from_results(results) %}

  {% for dataset_grant in datasets_to_grant_access_on %}

    {% set grant_target_dict = {
      'project': datasets_to_grant_access_on[dataset_grant]['project'],
      'dataset': datasets_to_grant_access_on[dataset_grant]['dataset']
    } %}

    {% do log("Granting access on dataset " + dataset_grant, info = true) %}

    {% do grant_access_to(
      entities = datasets_to_grant_access_on[dataset_grant]['needs_access'],
      entity_type = 'view',
      role = None,
      grant_target_dict = grant_target_dict
    ) %}

  {% endfor %}

{% endmacro %}

$ dbt run
20:49:41  Running with dbt=1.0.0
20:49:41  Found 4 models, 0 tests, 0 snapshots, 0 analyses, 191 macros, 1 operation, 0 seed files, 0 sources, 0 exposures, 0 metrics
20:49:41
20:49:45  Concurrency: 5 threads (target='dev')
20:49:45
20:49:45  1 of 4 START table model dbt_jcohen_another_schema.my_other_table............... [RUN]
20:49:45  2 of 4 START view model dbt_jcohen.my_table..................................... [RUN]
20:49:47  2 of 4 OK created view model dbt_jcohen.my_table................................ [OK in 2.54s]
20:49:47  3 of 4 START view model dbt_jcohen.my_other_auth_view........................... [RUN]
20:49:48  1 of 4 OK created table model dbt_jcohen_another_schema.my_other_table.......... [CREATE TABLE (1.0 rows, 0 processed) in 3.71s]
20:49:48  4 of 4 START view model dbt_jcohen.my_authorized_view........................... [RUN]
20:49:48  3 of 4 OK created view model dbt_jcohen.my_other_auth_view...................... [OK in 1.18s]
20:49:50  4 of 4 OK created view model dbt_jcohen.my_authorized_view...................... [OK in 1.55s]
20:49:50
20:49:50  Running 1 on-run-end hook
20:49:50  Granting access on dataset dbt-dev-168022.dbt_jcohen
20:49:50  ... to dbt-dev-168022.dbt_jcohen.my_other_auth_view
20:49:51  ... to dbt-dev-168022.dbt_jcohen.my_authorized_view
20:49:51  Granting access on dataset dbt-dev-168022.dbt_jcohen_another_schema
20:49:51  ... to dbt-dev-168022.dbt_jcohen.my_authorized_view
20:49:52  1 of 1 START hook: testy.on-run-end.0........................................... [RUN]
20:49:52  1 of 1 OK hook: testy.on-run-end.0.............................................. [OK in 0.00s]
20:49:52
20:49:52
20:49:52  Finished running 3 view models, 1 table model, 1 hook in 10.10s.
20:49:52
20:49:52  Completed successfully
20:49:52
20:49:52  Done. PASS=4 WARN=0 ERROR=0 SKIP=0 TOTAL=4

I'd still like to figure out a better path forward for this, since it is awkward in dbt today. I sense there's a pretty clear trade-off between:

performance hit while dbt is running, to authorize each view immediately after creation
latency between view creation + authorization, if the update_dataset calls are batched into an end-of-run hook

This is decidedly spaghetti code, but hopefully it's a useful demonstration of what's possible when writing custom macros that tap into existing functionality in the dbt-bigquery plugin. I see two clear avenues for improvement:

More user-friendly default behavior, which grants access to one auth view's upstream dependencies (as described above)
Exposing the capability, in the grant_access_to adapter method, to grant access to multiple auth views at once, for users who want to batch grants for speedier results at scale

-- macros/grant_operation.sql

{% macro grant_access_to(entities, entity_type, role, grant_target_dict) -%}
  {# This macro takes a list of "entities" (authorized views) and grants them access to a dataset (specified by grant_target_dict) #}
  {# Currently, the dbt-biquery (Python) method `grant_access_to` appends entities one-by-one #}
  {# It sounds like we could speed this up by making it possible to append many entities at once #}

  {% for entity in entities %}
    {% set entity_name = entity.database + "." + entity.schema + "." + entity.alias %}
    {% do log("... to " + entity_name, info = true) %}
    {% do adapter.grant_access_to(entity, entity_type, role, grant_target_dict) %}
  {% endfor %}

{% endmacro %}

{% macro parse_auth_view_upstream_datasets_from_results(results) %}
  {# This macro takes the `Results` object, available in the `on-run-end` context, identifies models #}
  {# configured with `authorized_view: true`, and parses the database location of their upstream model dependencies #}
  {# via the `graph.nodes` context variable #}
  {# It returns a dictionary containing one entry per dataset to grant access on, and each of those entries #}
  {# contains a list of authorized views that need access to it #}

  {% if execute %}

  {% set datasets_to_grant_access_on = {} %}

  {% for result in results %}

    {% set node = result.node %}

    {% if node.config.get('authorized_view') %}

      {% for upstream_id in node.depends_on.nodes %}
        {% for upstream_node in graph.nodes.values() %}
          {% if upstream_node['unique_id'] == upstream_id %}
            {% set dataset_fqn = upstream_node.database + '.' + upstream_node.schema %}
            {% if dataset_fqn in datasets_to_grant_access_on.keys() %}
              {% do datasets_to_grant_access_on[dataset_fqn]['needs_access'].append(node) %}
            {% else %}
              {% do datasets_to_grant_access_on.update({dataset_fqn: {
                'project': upstream_node.database,
                'dataset': upstream_node.schema,
                'needs_access': [node]
              }}) %}
            {% endif %}
          {% endif %}
        {% endfor %}
      {% endfor %}

    {% endif %}

  {% endfor %}

  {{ return(datasets_to_grant_access_on) }}

  {% endif %}

{% endmacro %}

{% macro grant_access_for_all_authorized_views(results) %}
  {# This macro is the entrypoint to the operation. It receives results, #}
  {# parses them via the macro defined above, and finally loops over each dataset entry #}
  {# to grant access #}

  {% set datasets_to_grant_access_on = parse_auth_view_upstream_datasets_from_results(results) %}

  {% for dataset_grant in datasets_to_grant_access_on %}

    {% set grant_target_dict = {
      'project': datasets_to_grant_access_on[dataset_grant]['project'],
      'dataset': datasets_to_grant_access_on[dataset_grant]['dataset']
    } %}

    {% do log("Granting access on dataset " + dataset_grant, info = true) %}

    {% do grant_access_to(
      entities = datasets_to_grant_access_on[dataset_grant]['needs_access'],
      entity_type = 'view',
      role = None,
      grant_target_dict = grant_target_dict
    ) %}

  {% endfor %}

{% endmacro %}

As an example, I define two table models in different schemas:
-- models/my_table.sql
{{ config(materialized = 'table', schema = 'other_schema') }}
select 1 as id

-- models/my_other_table.sql
{{ config(materialized = 'table', schema = 'other_other_schema') }}
select 1 as id

I define two authorized views in my main schema (note that authorized_view is a config I've made up, not defined in dbt-core or dbt-bigquery — it's just a sentinel for my result-parsing macro):
{{ config(materialized = 'view', authorized_view = true) }}
select * from {{ ref('my_table') }}
union all
select * from {{ ref('my_other_table') }}

{{ config(materialized = 'view', authorized_view = true) }}
select * from {{ ref('my_table') }}

Finally, I add the entry-point macro as a project on-run-end hook:
# dbt_project.yml
on-run-end:
  - "{{ grant_access_for_all_authorized_views(results) }}"

And:
$ dbt run
20:56:25  Running with dbt=1.0.0
20:56:25  Found 4 models, 0 tests, 0 snapshots, 0 analyses, 191 macros, 1 operation, 0 seed files, 0 sources, 0 exposures, 0 metrics
20:56:25
20:56:28  Concurrency: 5 threads (target='dev')
20:56:28
20:56:28  1 of 4 START table model dbt_jcohen_other_other_schema.my_other_table........... [RUN]
20:56:28  2 of 4 START table model dbt_jcohen_other_schema.my_table....................... [RUN]
20:56:31  2 of 4 OK created table model dbt_jcohen_other_schema.my_table.................. [CREATE TABLE (1.0 rows, 0 processed) in 2.77s]
20:56:31  1 of 4 OK created table model dbt_jcohen_other_other_schema.my_other_table...... [CREATE TABLE (1.0 rows, 0 processed) in 2.78s]
20:56:31  3 of 4 START view model dbt_jcohen.my_other_auth_view........................... [RUN]
20:56:31  4 of 4 START view model dbt_jcohen.my_authorized_view........................... [RUN]
20:56:32  4 of 4 OK created view model dbt_jcohen.my_authorized_view...................... [OK in 0.99s]
20:56:32  3 of 4 OK created view model dbt_jcohen.my_other_auth_view...................... [OK in 1.06s]
20:56:32
20:56:32  Running 1 on-run-end hook
20:56:32  Granting access on dataset dbt-dev-168022.dbt_jcohen_other_schema
20:56:32  ... to dbt-dev-168022.dbt_jcohen.my_authorized_view
20:56:33  ... to dbt-dev-168022.dbt_jcohen.my_other_auth_view
20:56:34  Granting access on dataset dbt-dev-168022.dbt_jcohen_other_other_schema
20:56:34  ... to dbt-dev-168022.dbt_jcohen.my_authorized_view
20:56:35  1 of 1 START hook: testy.on-run-end.0........................................... [RUN]
20:56:35  1 of 1 OK hook: testy.on-run-end.0.............................................. [OK in 0.00s]
20:56:35
20:56:35
20:56:35  Finished running 2 table models, 2 view models, 1 hook in 9.77s.
20:56:35
20:56:35  Completed successfully
20:56:35
20:56:35  Done. PASS=4 WARN=0 ERROR=0 SKIP=0 TOTAL=4

Hello @jtcohen6 and @BenLiyanage ,
Thank you for the above illustration.
I'm new to DBT and trying to implement authorised views in Bigquery and its
I tried to implement the same example which showed this PR but i'm getting the error while running it. Could you please check and advise me.
Can you please share the configuration to run authorised permissions at every model level instead of on-run-end?
step-1 : Created a macro - grant_operation.sql
{% macro grant_access_to(entities, entity_type, role, grant_target_dict) -%}   {# This macro takes a list of "entities" (authorized views) and grants them access to a dataset (specified by grant_target_dict) #}   {# Currently, the dbt-biquery (Python) method grant_access_to` appends entities one-by-one #}
{# It sounds like we could speed this up by making it possible to append many entities at once #}
{% for entity in entities %}
{% set entity_name = entity.database + "." + entity.schema + "." + entity.alias %}
{% do log("... to " + entity_name, info = true) %}
{% do adapter.grant_access_to(entity, entity_type, role, grant_target_dict) %}
{% endfor %}
{% endmacro %}
{% macro parse_auth_view_upstream_datasets_from_results(results) %}
{# This macro takes the Results object, available in the on-run-end context, identifies models #}
{# configured with authorized_view: true, and parses the database location of their upstream model dependencies #}
{# via the graph.nodes context variable #}
{# It returns a dictionary containing one entry per dataset to grant access on, and each of those entries #}
{# contains a list of authorized views that need access to it #}
{% if execute %}
{% set datasets_to_grant_access_on = {} %}
{% for result in results %}
{% set node = result.node %}

{% if node.config.get('authorized_view') %}

  {% for upstream_id in node.depends_on.nodes %}
    {% for upstream_node in graph.nodes.values() %}
      {% if upstream_node['unique_id'] == upstream_id %}
        {% set dataset_fqn = upstream_node.database + '.' + upstream_node.schema %}
        {% if dataset_fqn in datasets_to_grant_access_on.keys() %}
          {% do datasets_to_grant_access_on[dataset_fqn]['needs_access'].append(node) %}
        {% else %}
          {% do datasets_to_grant_access_on.update({dataset_fqn: {
            'project': upstream_node.database,
            'dataset': upstream_node.schema,
            'needs_access': [node]
          }}) %}
        {% endif %}
      {% endif %}
    {% endfor %}
  {% endfor %}

{% endif %}

{% endfor %}
{{ return(datasets_to_grant_access_on) }}
{% endif %}
{% endmacro %}
{% macro grant_access_for_all_authorized_views(results) %}
{# This macro is the entrypoint to the operation. It receives results, #}
{# parses them via the macro defined above, and finally loops over each dataset entry #}
{# to grant access #}
{% set datasets_to_grant_access_on = parse_auth_view_upstream_datasets_from_results(results) %}
{% for dataset_grant in datasets_to_grant_access_on %}
{% set grant_target_dict = {
  'project': datasets_to_grant_access_on[dataset_grant]['project'],
  'dataset': datasets_to_grant_access_on[dataset_grant]['dataset']
} %}

{% do log("Granting access on dataset " + dataset_grant, info = true) %}

{% do grant_access_to(
  entities = datasets_to_grant_access_on[dataset_grant]['needs_access'],
  entity_type = 'view',
  role = None,
  grant_target_dict = grant_target_dict
) %}

{% endfor %}
{% endmacro %}`
step-2 : Created a model with table config- my_table.sql
{{ config(     materialized = 'table',      schema = 'junifer_real_time',     tags=['auth_view_test'],     )  }} select 1 as id
step-3 : Created a model with authorised view config -
{{ config(     materialized = 'view',      authorized_view = true,     tags=['auth_view_test']     )  }} select * from {{ ref('my_table') }}
step-4 : Added the on run end  config to dbt_project.yml file
`on-run-end:

"{{ grant_access_for_all_authorized_views(results) }}"`

Error is
`(base) ➜  dbt git:(dataplat-509-dbt-dw) ✗ bulb_data_tools dbt run --models tag:auth_view_test
master: Pulling from bulb-data/data-warehouse-dbt
Digest: sha256:9b190293478842e2bc6b54fa7dc4ca2e6136557180c1e3484ae071e5722b102c
Status: Image is up to date for eu.gcr.io/bulb-data/data-warehouse-dbt:master
08:32:01  Running with dbt=1.0.3
08:32:35  Encountered an error:
Compilation Error in operation data_warehouse-on-run-end-0 (./dbt_project.yml)
'str object' has no attribute '\n'

in macro grant_access_for_all_authorized_views (macros/grant_operation.sql)
called by operation data_warehouse-on-run-end-0 (./dbt_project.yml)
Traceback (most recent call last):
File "/Users/vijaytumati/opt/miniconda3/bin/bulb_data_tools", line 33, in
sys.exit(load_entry_point('bulb-data-tools', 'console_scripts', 'bulb_data_tools')())
File "/Users/vijaytumati/bulb-data-tools/bulb_data_tools/cli/cli.py", line 296, in _main
fire.Fire(cli)
File "/Users/vijaytumati/opt/miniconda3/lib/python3.9/site-packages/fire/core.py", line 141, in Fire
component_trace = _Fire(component, args, parsed_flag_args, context, name)
File "/Users/vijaytumati/opt/miniconda3/lib/python3.9/site-packages/fire/core.py", line 466, in _Fire
component, remaining_args = _CallAndUpdateTrace(
File "/Users/vijaytumati/opt/miniconda3/lib/python3.9/site-packages/fire/core.py", line 681, in _CallAndUpdateTrace
component = fn(*varargs, **kwargs)
File "/Users/vijaytumati/bulb-data-tools/bulb_data_tools/cli/dbt/dbt.py", line 160, in run
_run_docker_command(_generate_docker_command("run", command))
File "/Users/vijaytumati/bulb-data-tools/bulb_data_tools/cli/dbt/dbt.py", line 56, in _run_docker_command
subprocess.run(terminal_command, shell=True, check=True)
File "/Users/vijaytumati/opt/miniconda3/lib/python3.9/subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command 'docker run --rm -it --pull 'always' -v $(PWD)/dev_config:/root/.dbt/ -v ${HOME}/.config/gcloud:/root/.config/gcloud -v $(PWD)/data_warehouse/:/opt/data_warehouse_dbt/ eu.gcr.io/bulb-data/data-warehouse-dbt:master run --models 'tag:auth_view_test'' returned non-zero exit status 2.`

I opened a new issue proposing a way we could proceed here: https://github.com/dbt-labs/dbt-bigquery/issues/87
Going to close this issue in favor of centralizing the conversation over there.

@jtcohen6 thanks for suggesting the macro approach, it's working for us with slight changes to the script. We ran into errors if parse_auth_view_upstream_datasets_from_results macro returns nothing/undefined.
We've had success with moving {% set datasets_to_grant_access_on = {} %}, and the associated return out of the if block (so it always at least returns an empty dictionary).


Expo not deploying to iOS simulator

Hi,
Yesterday I got an update from expo to version 2.20.1 (2.20.1) and idk why but it broke the deployment to iOS simulator (haven't test it on Android emulator yet), devices still work though both Android and iOS.
The React Native Packager console shows two errors, one after scanning folders:
Error starting tunnel: Error: Starting tunnels timed out

And the other one when doing the deploy to iOS simulator:
Error installing or running app. Error: Couldn't connect to the server, check your internet connection.

Any help?

Hi there! As per the issue template, please post issues to https://github.com/expo/expo/issues


add lodestar

Do not merge until @dapplion has reviewed the lodestar DNP and it's published.

duplicate with #10, shall I close mine?

duplicate with #10, shall I close mine?

Not yet. I'll probably close this one. Yours is complete marking it as duplicate now.


Unique identifiers for posts and pages

See issue #409 for more details.
The unique identifier is permanently attached to the post or page and doesn't change during its lifetime. It can be used for many purposes that require identification, such as Disqus comment threads (to avoid thread duplication), redirection of old URLs, etc.
This avoids thread splitting, duplication, and other problems in Disqus, as discussed at:
https://help.disqus.com/customer/en/portal/articles/2158629
PS: If you're not upgrading Bludit, you will need to open /admin/dashboard?update to force adding identifiers to existing posts and pages.
Also:

Fix a mistake in dashboard.php ($post instead of $page).
Reverse the defaults in Disqus plugin settings: Pages and posts to have commments by default, while home page to not.

Hi, I like the idea of having a uniqueID for each post/page. This is will be generated when the post/page is created and then you don't need to send again when the post/page is edited.
If you need for Disqus you need to use the key of the post/page not the uniqueID because the post/page can change the key and has a different URL assigned.

I needed to send the uniqueID again because it generated a new ID when I edited the post. That's why in commit f298113 I added the current ID as a hidden field to send back when editing.
For Disqus, actually it's the uniqueID that should be used because the key will change as you just said when you edit the title, and you end up with a different URL assigned, but the Disqus comment thread would be the same because of the same uniqueID. That's the purpose of using uniqueID here.
Otherwise Disqus would start a new comment thread and all the old comments will not be shown anymore when the post key changed and URL changed.

Thanks for liking this. I know this is a lot of change in the core. It's okay if you want to take some time to study it before merging. Please do let me know if any code could be written better, or there's anything you don't understand.

Sorry I don't follow you about to send the ID when you edit a post.
New post

Generate uniqueID
Generate a KEY based on title

Edit post

Generate a KEY based on title

So if you change edit the title of the post, the UID doesn't change, and Disqus keep the comments for this UID.
I going to take part of your code and make the uniqueID, and if you don't mind I will change the name for UUID (https://en.wikipedia.org/wiki/Universally_unique_identifier)

Sorry I don't follow you about to send the ID when you edit a post.

Please refer commit f298113. What I meant is that when you edit a post or page, the existing uniqueID needs to be put in a hidden field in the form (just like how you're already putting the key in a hidden field). This is so that when the user submits the edits, the same ID is sent back. Because in the back-end, if the submission doesn't have a ID already, a new one is generated. That's what I meant.

New post
Generate uniqueID
Generate a KEY based on title
Edit post
Generate a KEY based on title
So if you change the title of the post, the UID doesn't change, and Disqus keep the comments for this UID.

This is absolutely correct, and it is exactly what my PR is doing.

Hi, I close this PR for the conflic, and is implemented with you solution. thanks


Added basic prompt generation for RAG.

Pull Request Checklist
Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.
Before submitting, make sure you've checked the following:

[x] Target branch: Please verify that the pull request targets the dev branch.
[x] Description: Provide a concise description of the changes made in this pull request.
[x] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
[x] Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?
[x] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation?
[x] Testing: Have you written and run sufficient tests for validating the changes?
[x] Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
[x] Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:

feat: Introduces a new feature or enhancement to the codebase

Changelog Entry
Description

Adding a feature: option to generate more actual RAG query by llm, then process RAG search.

Added

'Enable RAG Prompt Generation' option, disabled by default.
'RAG Prompt Generation Template' option with default template.

Changed

RAG documents search is now using prompt before search, if 'Enable RAG Prompt Generation' is selected.

Additional Information

[Insert any additional context, notes, or explanations for the changes]

Based on idea from issue: https://github.com/open-webui/open-webui/issues/5571

Screenshots or Videos

Does it need to be in documentation? Seems that UI is self documented, isn't it?

Please target dev branch, thanks!

Sorry, misclicked.
Reopened to dev https://github.com/open-webui/open-webui/pull/6845


Translate missing attributes in es locales

Follow up for #185.
I also reworded some existing translations that didn't read well and used "Email" as translation for email key in es.yml, because it is more common than correo electrónico and it was already used that way all over the file.

¡Gracias!

De nada! :)


G Infrastructure: Homogeneous build, test and deploy metrics

Motivation
Every time we need to make a change, e.g. add a tool, update Github Workflows system images, etc. we need to manually change every library. Manual changes can be inconsistent and are a pain, leading to procrastination. Larger changes are basically impossible to imagine.
Desired template attributes
We need a standard template and guide for libraries which has the following qualities:

Uses Github workflows to test all three OSes with both the latest and next-to-last system images and Py 3.7-3.10.
Test installation using both conda and pip
Uses setup.cfg instead of setup.py. Include sections for dev (has e.g. pytest, pip-tools), stable (all requirements pinned), and normal installation (requirements have ranges of >=)
Reports 1-click code coverage results
Provides badges for CI results, code coverage (e.g. shields.io)
Has a solution for hosted HTML documentation including napoleon
Uses tooling to help improve code quality
Single-source the library version (why these solutions so hacky!?)
Automated builds and uploads to anaconda on tagged commits

Adapting the hypermodern template
A lot of these attributes are found in the hypermodern template, though @cmutel would argue against the following:

Use of poetry: Better to stick with standard tools instead of more opinionated ones in components designed to be integrated into applications.
Use of tox or nox: Not necessary, we do testing in CI, and setting up a venv for each test run is quite heavy for our components.
Automated build notes. Could be considered in the future, we don't yet have the discipline to use this consistently, and it makes life harder for new contributors.

We should use the following (copied from their docs):

Documentation with Sphinx, MyST, and Read the Docs using the furo theme
Automated uploads to PyPI and TestPyPI

pre-commit hooks
Note that we assume the following are done as pre-commit hooks by the template (instead of by Github Workflows):

Import sorting with isort
Code formatting with Black and Prettier
Black formatting in documentation snippets
Static type-checking with mypy
Runtime type-checking with Typeguard

cookiecutter instead of pyscaffold
pyscaffold ticks a lot of boxes, but has some controversial choices which are hard to remove, including the use of setuptools-scm and tox, has custom commands instead of pip and friends (not great for new users), and would need to adapted to include the Azure Workflows config in any case. @cmutel thinks that a custom cookiecutter template is probably the best choice. Ideally, someone would already have such a template, as the cookiecutter ecosystem is large, but no suitable template was found browsing cookiecutter-templates.
pip, not poetry or pipenv
Let's skip the drama, pip with pip-tools and pipreqs works just fine.
Useful links

Python packaging authority
PyPA: Using Github Workflows to publish packages
pip-tools
pipreqs
cookiecutter conda template
setuptools on setup.cfg
Nice intro to pyproject and setup.cfg
Workflow from @romainsacchi which does automatic package building and uploading

Tasks

[ ] Make cookiecutter template that satisfies the required attributes
[ ] Document use of this template, both for new library creation and for updating libraries
[ ] Create example project from the example template
[ ] Have regular checks to ensure that all Brightway libraries work correctly as dependent libraries evolve

Starting with PEP 621, the Python community selected pyproject.toml as a standard way of specifying project metadata
https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

Repository cookiecutter-brightwaylib is a starting point. It contains already a basic cookiecutter template, and issues related to each of the specification requirements described here.

Here is a job description to find a freelancer to work on this:
Update Python packaging and CI scripts for an open source framework for life cycle assessment
Brightway (https://brightway.dev/) is an open source framework for life cycle assessment. Our packaging concept and CI infrastructure needs to be updated to use modern tools and make our lives easier. Specifically, the following changes need to be made:

Switch from setup.py to pyproject.toml. No need to switch to anything like poetry or any other fancy build system.

(The reason we are hiring someone to do this in the first place is that we can build libraries using pyproject.toml and upload them to PyPI but these libraries raise errors when running pip install afterwards.)

Automatically build wheels (and a source distribution) and upload to pypi when commits are tagged.
Automatically build Anaconda dev releases when commits are not tagged.

Tagged releases for anaconda should be built by conda-forge, and their robot will automatically notice new PyPI releases and create pull requests.
The following libraries need to be updated and can have a single, version/OS independent wheel:
https://github.com/brightway-lca/brightway2-data
https://github.com/brightway-lca/brightway2-io
https://github.com/brightway-lca/brightway2-analyzer
This library needs to be updated, but needs version/OS-specific wheels:
https://github.com/brightway-lca/brightway2-calc
See https://github.com/brightway-lca/brightway2-speedups/blob/master/.github/workflows/build_wheels.yaml for an example of such wheels. The calc library relies on linear algebra libraries which are compiled separately for each version and OS. It should have pypardiso as a dependency, but note that no wheel for ARM Macs is available, as this can't use pypardiso, but instead should use scikit-umfpack, but it doesn't have binary distributions (https://pypi.org/project/scikit-umfpack/0.3.3/).

Note the following changes to the original plan:

Not using napoleon for documentation, just using numpy docstrings
New beta documentation is online with source here, and is managed as a separate project
Even if pre-commit hooks are in the template, they aren't necessarily being used, so we should also run these checks on commits


Hotfix: Update EpiAware.jl - add AbstractModel

This PR is a hotfix based on a review of #85 - @SamuelBrand1

Yeah I agree with exporting this.


Overwrite Files setting resets Image picker, but not the other way

Describe the bug
If I understand correctly, the Overwrite Files setting only works if Image source is set to Gallery. When I toggle Overwrite Files, it changes it Image source to Gallery. However when I change Image source to something other than Gallery Overwrite Files stays on, when it should get changed to off.
To Reproduce

Set Overwrite Files to on.
When changing the Image source setting the Overwrite Files stays on.

Expected behavior
Changing Image source should set Overwrite Files to off if chosen settings are incompatible and should tell user that Overwrite Files has been changed.
Screenshots

Smartphone (please complete the following information):

Device: Samsung A52s 5G
OS: Android 14 with OneUI 6.1

It works for all except camera and photo picker

if you try to overwrite and it fails, then toast with message that you should repick and source are set to needed one

not a bug in my opinion

Why not inform user settings were changed? It's confusing


scale calculation of sim3

def procrustes_analysis(X0,X1): # [N,3]
    # translation
    t0 = X0.mean(dim=0,keepdim=True)
    t1 = X1.mean(dim=0,keepdim=True)
    X0c = X0-t0
    X1c = X1-t1
    # scale
    s0 = (X0c**2).sum(dim=-1).mean().sqrt()
    s1 = (X1c**2).sum(dim=-1).mean().sqrt()
    X0cs = X0c/s0
    X1cs = X1c/s1
    # rotation (use double for SVD, float loses precision)
    U,S,V = (X0cs.t()@X1cs).double().svd(some=True)
    R = (U@V.t()).float()
    if R.det()<0: R[2] *= -1
    # align X1 to X0: X1to0 = (X1-t1)/s1@R.t()*s0+t0
    sim3 = edict(t0=t0[0],t1=t1[0],s0=s0,s1=s1,R=R)
    return sim3

It’s line278~line295 of camera.py
@chenhsuanlin
Hello, I have a doubt why we did the average instead of the square when calculating s0 and s1. The s here represents the scale of the scene, it seems that it is more reasonable to square first and then average

Hi @paidaxing12138, the centered points are squared before averaging, as in X0c**2 in the code. Please see here for a treatment on Procrustes analysis.

Thank you for your answer, got it


Refactor platform programming API to better support multiple programmers

Right now each platform must define a toolchain_program function which will know how to program the device. The issue is there are tons of ways of programming a device. I propose that we teach nmigen how to interact with openocd, dfu-util, openFPGAloader, etc. and then have the platforms register their custom information for each of the programming interfaces they want to support.
Long-term I am also seeing the possibility of people being able to create plugins to extend the programming interfaces. This would make so that with nmigen being more widely adopted, it did not fall on the upstream to maintain all possible interfaces. It should be fairly straight-forward, but not that relevant right now.
Example taken from fomu_hacker.py:
def toolchain_program(self, products, name):
    dfu_util = os.environ.get("DFU_UTIL", "dfu-util")
    with products.extract("{}.bin".format(name)) as bitstream_filename:
        subprocess.check_call([dfu_util, "-D", bitstream_filename])

I am open to contribute this change. Let me know if it makes sense right now, if you want to wait, if there are other things blocking it, etc. :grin:.

The issue is there are tons of ways of programming a device.

Like what? Every board we support so far has a single primary way of programming it, so a single function is sufficient.

Arty A7 can either use xc3sprog or openocd to program the flash. I've only have experience w/ the latter, but nmigen hardcodes the former.

Right, I guess that's one of the few exceptions.

In general, I'm not a fan of deduplicating code for the sake of it. Suppose we factored out some sort of interface through which we run OpenOCD. Now two things happen:

Any change to the shared code needs to be tested on all the boards it affects. Too bad, since you likely don't have the board, the toolchain, or any easy contact with the person who contributed it.
Any special case requires either changing the shared code (see above), or duplicating it.

So there needs to be a more compelling reason to factor out programmer interfaces than "it saves around 5 lines of clear self-contained code per board on average". Right now, the public interface is the toolchain_program function, and in my view that's highly advantageous--any changes are localized to that specific board, and a board can do things that are as weird as it needs them to be.
Note that this contrasts with our various Resources, which are factored out because we expect various cores (from nmigen-stdio as well as external ones) to rely on the resource layout. In other words, the public interface is the full structure of the resource, and any changes to this structure can (and must) be manually verified in some way with every single board.

Yes, and the current approach works perfectly fine for that. But I think it is also common for people to program via JTAG or something similar, am I wrong? This is where the current approach fails. When it comes to JTAG or another standard interface, there are multiple ways to do it.
For the boards that have an onboard way to program the FPGA, I'd also imagine that people sometimes might want/need to program via JTAG.
This approach would also benefit the current boards with onboard programmers, since you could unify and standardize the interface in one place. You wouldn't need to keep copying the same code between each platform declaration. It also allows you to standardize the interface. In the example above, you can pass DFU_UTIL as an env var, some other platform might do the same but call it DFUUTIL.

Any change to the shared code needs to be tested on all the boards it affects. Too bad, since you likely don't have the board, the toolchain, or any easy contact with the person who contributed it.

I think this can be implemented without breaking the current code. We can keep toolchain_program as one of the backends. People can then start replacing toolchain_program usages with the openocd definitions on their own.

When it comes to JTAG or another standard interface, there are multiple ways to do it.

This isn't actually specific to JTAG. There's (quite literally) an infinite amount of ways in which you might want to program a board. And nMigen already supports them all! What you do is you use the (public) interface platform.extract to grab the bitstream and then program it in whatever way you want. This is similar to how nMigen already supports virtually every FPGA toolchain, since you can always ask it to just produce Verilog for you.
It is not a goal of nMigen or nmigen-boards to support, even in theory, every conceivable way to program a board. The goal is to provide a smooth out of the box experience for people who are just using their board in the primary way the vendor suggests it to be used. Anything more? You have a perfectly good Python interpreter right there.

You wouldn't need to keep copying the same code between each platform declaration.

I consider the current approach an advantage. Take a look at this essay for a more in-depth exploration of my view here.

It also allows you to standardize the interface. In the example above, you can pass DFU_UTIL as an env var, some other platform might do the same but call it DFUUTIL.

That doesn't require building a new abstraction. We can add something like nMigen's _toolchain.require_tool to ensure environment variable names match tool names. I haven't done it because _toolchain is a private API and because there would be potentially undesirable interaction with how NixOS packages nMigen.

People can then start replacing toolchain_program usages with the openocd definitions, for eg., on their own.

That doesn't require building a new abstraction. People can do this just fine right now by doing the same thing toolchain_program does (or inheriting from the Platform they use and replacing that function, or replacing it on the instance, or whatever).

But I think it is also common for people to program via JTAG or something similar, am I wrong?

I wouldn't say it's all that common. I believe most of the time most people use the built-in programmer, since that's the most convenient approach. For the rest? Figuring out the right options to pass to the nMigen abstraction would probably take more time (and be more frustrating) than just invoking subprocess.check_call themselves.

The goal is to provide a smooth out of the box experience for people who are just using their board in the primary way the vendor suggests it to be used.

Sometimes there isn't a vendor-suggested (command-line) primary way. If we use arty and mercury as examples (see below), a programmer is added to a board based on "who implements toolchain_program and files a PR first?". Effectively, this means that built-in programmer support in nmigen-boards will be tailored first-come, first-serve to the use case of the PR submitter. Which might be fine for you! But if there isn't a single primary way to program a board (which yes, is a value judgment), I think I'd rather nmigen not support toolchain_program favor any particular programmer app/cable over another.
E.g. Digilent suggests you use Vivado for Arty (is there a command line programmer for Arty?). I have Mercury use mercpcl because there wasn't any command-line programmer before I wrote one. But the vendor suggests using a GUI C# application.

Effectively, this means that built-in programmer support in nmigen-boards will be tailored first-come, first-serve to the use case of the PR submitter.

I didn't mean to say that nmigen-boards will support one and only one way to program every board. (I was actually wondering if I should clarify that in my earlier comment.) Ultimately, what is supported there is determined by the convenience of a typical nMigen user encountering that board. If it's approximately about as likely that such a typical user would want to use xc3sprog as openocd, then we can support both! There could be a default, or the default could be to throw an exception.

E.g. Digilent suggests you use Vivado for Arty (is there a command line programmer for Arty?).

You can use iMPACT via CLI. Atlys does this. If we do support it for Arty, then iMPACT should probably be the default.

I have Mercury use mercpcl because there wasn't any command-line programmer before I wrote one. But the vendor suggests using a GUI C# application.

This is an interesting edge case. Because, clearly, nmigen-boards can only run a CLI application (or perhaps a batch mode GUI application, though this is already marginal), your programmer seems to be the only one that fits its restrictions. So we can use it in toolchain_program just fine.

But if there isn't a single primary way to program a board (which yes, is a value judgment), I think I'd rather nmigen not support toolchain_program favor any particular programmer app/cable over another.

All that said, if there really is nothing that a typical nMigen user is likely to find usable, then of course we can leave it out. For example, SK_XC6SLX9Platform only exposes a JTAG header. I didn't put a Glasgow invocation into toolchain_program because, although obviously usable for some, this isn't usable for a typical user.

I want to go back to the original issue and better explain my motivations.
There are two issues. The main one is that there are several possible ways to configure a board, and nmigen only supports defining one. The other one is that the interface to pass arguments to the programmer is not standardized.
I was not clear about this but the duplicated code issue was never about code optimization, it was about the interface, which diverges between boards.
To me, having a standard interface for openocd for eg. would be a great step forward. I can use openocd with a wide range of programmers, I need to tell openocd how to do it.
My proposal to abstract the programmer was so that we can standardize the interface. We could have openocd add an argument to the build/CLI to receive my config(s).
Anyway, it is ultimately your call. I think the abstraction makes sense for standardizing the interface. Even if you decide against it, just being able to declare multiple programming interfaces would be a big big plus for me.

which diverges between boards.

Where does it currently diverge between boards? That sounds like a bug.

Sorry, bad choice of words. I mean in a design sense, there is no enforcement, it is completely defined by the platform.

I can use openocd with a wide range of programmers, I need to tell openocd how to do it.

So I don't actually see how that would work. I looked at the openocd invocations currently in nmigen-boards. All of them are different, pretty significantly so. That's fine! Boards tend to be a bit (sometimes, very) unique, so having the openocd abstraction be subprocess.check_call([openocd, <board_specific_stuff>]) is totally fine. After all you are using a well-defined interface here--openocd's CLI.

I mean in a design sense, there is no enforcement, it is completely defined by the platform.

Right, so that's one benefit of this change. I think it does not outweigh the drawbacks, which is the need to test every board affected by changes in common code.

Going back to your earlier comment...

The main one is that there are several possible ways to configure a board, and nmigen only supports defining one.

We can just decide on what to do here. For example, we can decide that on every board with multiple ways to program it, toolchain_program takes a programmer="<tool>" keyword argument.

The other one is that the interface to pass arguments to the programmer is not standardized.

I very specifically do not want to provide a way to pass arguments in general. For example, I do not want to provide a way to customize the openocd script. toolchain_program should be configurable enough, and just enough, to cover the most typical use cases. (Changing the serial port, like in blackice, definitely counts as necessary configuration.)
If you want to customize things beyond that, use your own programming code.

So I don't actually see how that would work. I looked at the openocd invocations currently in nmigen-boards. All of them are different, pretty significantly so. That's fine! Boards tend to be a bit (sometimes, very) unique, so having the openocd abstraction be subprocess.check_call([openocd, <board_specific_stuff>]) is totally fine. After all you are using a well-defined interface here--openocd's CLI.

I checked and most pass a config to the onboard programmer. We can make that the default config and allow the user to override it if they want to use a different programer. We basically split the programmer specific and board stuff. The board specific definitions would always be included, but the programmer could be replaced.

Right, so that's one benefit of this change. I think it does not outweigh the drawbacks, which is the need to test every board affected by changes in common code.

Not really, because we don't need to move all devices to this new API. They can still keep their toolchain_program definition as is and eventually migrate. I don't want to break anything! It should be all backwards compatible.

I very specifically do not want to provide a way to pass arguments in general. For example, I do not want to provide a way to customize the openocd script. toolchain_program should be configurable enough, and just enough, to cover the most typical use cases. (Changing the serial port, like in blackice, definitely counts as necessary configuration.)
If you want to customize things beyond that, use your own programming code.

We can control that in the board/interface definitions we provide, so we can limit it to only necessary configurations. In this case, openocd would only allow you to provide your own config.

I don't want to break anything! It should be all backwards compatible.

I don't really care about right now. As more time passes and more boards migrate to this common interface, changing this interface will become more and more hazardous and eventually it'll just be effectively frozen because we'll lose the ability to test every board affected by the change.

We can control that in the board/interface definitions we provide, so we can limit it to only necessary configurations. In this case, openocd would only allow you to provide your own config.

I don't see any reason to add an inherently leaky abstraction when the current approach works just fine.


Mention "$@" in the README

This documents the feature explained in #1054. Much of the text is taken from man bash.

Nice, this is a great addition to the readme! Can you also mention that this is bourn shell specific? Maybe something like: "When using a sh-compatible shell, such as bash or `zsh,"

I did not know that – only just learning ;-).
Text is updated, don't forget to squash-merge.


No need to enable xenhvm-vm-tools/kvm-vm-tools/hyperv-vm-tools/bhyve-vm-tools service

RancherOS added detetion of Hypervisor, and then will try to download the a service called -vm-tools.
When using kvm hypervisor, it will enable kvm-vm-tools, but in fact kvm-vm-tools does not exist

Tested with RancherOS version- v1.1.2-rc2.

Xenhvm-vm-tools / kvm-vm-tools / hyperv-vm-tools / bhyve-vm-tools service has been removed from RancherOS
Only enable open-vm-tools serivce for vmware.

How can I remove the kvm-vm-tools service if I already got this enabled somehow with an older version. This causes startup times > 15min for me. I can't disable/delete/rm the service as it is no service valid service.
root@foo:/var/lib/rancher# ros s disable kvm-vm-tools
FATA[0000] kvm-vm-tools is not a valid service

@kuhnroyal You can check the services_include in cloud-config, then get rid of kvm-vm-tools service.


Simulator work to enable random pool/lockup/pot creation

This PR adds operations for creating pools, pots, and lockups.
This also adds some simulation infrastructure for convenience, to save us some lines that plague current SDK operations.

Update: This PR is just going to have the pool creation operation, and the WIP infra for getting the entire state machine simulator setup.
This is to better enable @mconcat to work in parallel on adding more simulator ops


DiagnosticsStore should not be disabled with the sysinfo crate

@AxiomaticSemantics I just noticed you added the cfg to the line that inserts the DiagnosticsStore to the app. Was that intentional? There's a bunch of diagnostics that don't rely on the sysinfo_plugin.

Originally posted by @IceSentry in https://github.com/bevyengine/bevy/issues/12164#issuecomment-2008294811

That was fixed in a PR I did to make sysinfo a Resource. I just noticed it while working on that but since I didn't get an answer I fixed it assuming it wasn't intentional.


getDerivedStateFromProps not called before each render

Hi,
I wrote a component Switch:   https://codesandbox.io/s/m5oy50k649
When I use React and<EMAIL_ADDRESS>getDerivedStateFromProps will be called everytime before the render method.

but when I use React and<EMAIL_ADDRESS>and with this polyfill, getDerivedStateFromProps is called just before the first render, as my example shows. This is not what I expected.

React Doc:

getDerivedStateFromProps is invoked right before calling the render method, both on the initial mount and on subsequent updates

Here's what I want:
Switch has a state checked, and a prop checked as well.
if <Switch />, the component can work because it has it's own state checked;
if <Switch checked />, the component will never change state, because before every render, getDerivedStateFromProps will reset the components' checked.
But when React and<EMAIL_ADDRESS>It doesn't work as I expected.
Thanks for helping.

Hey @jiangyijie27. Sorry for the difficult here. 😦 Unfortunately it's pretty difficult to create a polyfill that fully adheres to the 16.4+ semantics of getDerivedState (see the discussion in PR #27).
For what it's worth, it looks like the Switch component you linked to is using derived state in one of the ways that we've identified as an anti-pattern. Maybe you could avoid this polyfill problem (and the ones mentioned in the blog post I linked to) by changing the component's approach slightly?


fix(compiler-core): fix the detection of forwarded slots

Fix: #3347
Forwarded slots detection should work with v-if/v-for

I believe the CI failure is not related to this PR...


homebridge-config-ui-x doesn't start up after node.js and npm update

Hi,
I updated node.js to 10.16.3 and npm to 6.11.3.
After having done that, homebridge-config-ui-x runs on following error on startup:
Error: Cannot find module '../build/Debug/pty.node'
Unfortunately the reinstallation of homebridge-config-ui-x with the following commands did not help:
sudo npm uninstall -g homebridge-config-ui-x
sudo npm install -g --unsafe-perm homebridge-config-ui-x
I still receive the same error.
What can I do about that?
Thank you very much!
Lumi

I resolved the problem by myself:
You have to go to folder /usr/lib/node_modules/ to before uninstalling and reinstalling Homebridge-config-ui-x. After that Homebridge-ui-x worked properly again.


shown view flips from settings or account detail back to main if a tx is proccessing.

Issue description
User Tobi MZ reported the issue first, i tested and can confirm...
If an tx is issued and you switch the screen to setting or account detail or any setting detail page, after a few seconds, the screen flips back to the main view (before the ongoing tx seems finished / maybe during pow)
Wallet version
Firefly v0.3.1
Platform: win32
Platform Version: 10.0.19041
Platform Architecture: x64
CPU Count: 4
Is it a repeatable issue?
yes
Steps To reproduce the issue
issue a tx (internal transfer)
click directly after starting the tx on "settings" and wait there
after 5 - 10 seconds the view flips back to the Main wallet view
Expected behaviour
screen should stay where i wanted it to be
Actual behaviour
screen flips tp main view without user command
Errors
here the console, but thats i think all old - during the issue no new errors show up in console
console.txt
and the wallet error log, also mostly old...
error log.txt
two recordings of the behaviour:
https://user-images.githubusercontent.com/77154511/112463328-0ea4df00-8d9d-11eb-9d3b-b104e802a0ea.mp4
https://user-images.githubusercontent.com/77154511/112463521-51ff4d80-8d9d-11eb-94da-6597752e0bba.mp4

This is fixed in the next release, please re-open if it persists.


Ideas/Roadmap for Atlas

[x] Migrate to Hugo Pipes
[x] Remove NetlifyCMS from repo
[x] Consider removing BrowserSync in favour of hugo server
[ ] Make it easier to use Hugo Themes
[ ] Add bot for automatically updating Hugo in netlify.toml
[x] Remove Sass lint
[ ] Add debug/demo theme
[ ] Include partials for SEO & OpenGraph
[ ] Consider some good defaults for partials & shortcodes
[ ] Add uncss/purgecss support

have u guys considered adding uncss/purgecss?

It has come up before, but this was way back before Hugo released "Pipes", and we decided to wait for that to release. Consequently it was forgotten about.
I'll add it to the list, thanks for the suggestion! :)

oh hey! i adapted some configurations/ideas from https://github.com/budparr/hugopipes-tailwindcss/ for PurgeCSS and ended up making Uncss work (the docs did NOT help, thanks @budparr
uncss and postcss-uncss as package dependencies, and a production postcss.config.js with
    require('postcss-uncss')({
      html: ['layouts/**/*.html'],
    }),

this config is called on   {{ $style := resources.Get "scss/uikit.scss" | toCSS (dict "targetPath" "css/style.css" "enableSourceMap" false) | postCSS (dict "config" "./assets/css/postcss.config.js")  | minify | fingerprint }}
uikit reduced from 112kb normal to 12k with purgecss and 4kb with uncss (same site, same content)
Even the guys at PurgeCSS [seem to think Uncss can be more accurate](At the moment, UnCSS is probably the most accurate tool to remove unused CSS if you do not use server-side rendering.
).
I wanted to use Uncss because i thought since uncss can be used as a postcss plugin, i wouldnt need to install node and just run hugo... i was wrong i guess.
Hope these links can be of some help.
-cheers

Thanks for the info... Unfortunately, I just implemented this with PurgeCSS. (or most of it anyhow). You can find it in it's currently (mostly untested state here: #73).
I believe Hugo just runs the command line version of PostCSS for you behind the scenes. So you would need Node installed to run it (you need Node installed for Atlas anyway because we also use Autoprefixer through PostCSS).
I'm not tied to PurgeCSS, I'd be happy to use UnCSS.. So I'll take a look at your notes in more detail, and possibly look at converting it over. (Not sure when, as I don't do much Hugo work at the moment). I would also welcome a PR if you're interested.
Thanks again for the notes above 👍

your postcss.config.css file helped a LOT. i could remove the postcss config call at layouts.
if ('production' === process.env.NODE_ENV) {
    plugins.push(
        require('postcss-uncss')({
            html: ['layouts/**/*.html'],
            ignore: [],
        })
    );
}

just tested this at my fork and worked great! just had to add cross-env to package.json too, like in your branch.
-cheers


Docker Install issues

On the docker install, I couldn't get this to run.
docker-compose run web rails db:migrate
It says:
ERROR: Cannot start service web: oci runtime error: container_linux.go:262: starting container process caused "exec: "rails": executable file not found in $PATH"
I'd try a normal install, but I don't see good instructions for it if you're not looking to deploy this publicly on Heroku.  This is my first time trying to use Ruby.. Seems way more complicated than Python, Node, or anything else... banging my head trying to get hack-the-arch running.

Got any Virtual Appliances ready to go? haha

So as I commented on that request, it is not a safe or efficient deployment
of HTA. There may be security issues with hosting your CTF that way, and
there will certainly be performance issues.
The reason Docker is suggested is because it is difficult to deploy a safe
and effective production web application (regardless of the technology
behind it). Docker makes that easier, but it still takes some
understanding. If Docker and docker-compose are setup properly (and
updated), then you shouldn’t have any issues running the database
migration. How did you setup Docker?
On Thu, May 24, 2018 at 17:17 ElJefe<EMAIL_ADDRESS>wrote:

Closed #52 https://github.com/mcpa-stlouis/hack-the-arch/issues/52.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#event-1645442225,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5BwPcdnZcTjwm0SqVswb3K836Hv6cks5t1zFcgaJpZM4UM6fB
.

I think I just apt-get install docker and did the same for docker-compose.  Pretty much just followed the instructions https://github.com/mcpa-stlouis/hack-the-arch/blob/dev/DOCKER_README.md.
I ran into some issues, but was able to get them fixed along the way until this one.  This is the first time I've tried to use Docker.

Usually, it's a much better idea to install docker from the source (it's easier than aptitude):
Docker: https://docs.docker.com/install/linux/docker-ce/ubuntu/
docker-compose:  https://docs.docker.com/compose/install/

That script will check to make sure the versions of docker and docker-compose are correct (amongst other things) to ensure you have a safe production deployment of HTA.  Let me know if it doesn't work or you have any issues running it.

I installed these as part of the setup with docker before running the script as it was necessary to run bundle exec rails secret.
apt-get install libpq-dev
gem install pg -v '0.18.4'
apt-get install nodejs

After that, the script seemed to run fine, however, it should be available on my host ip, but it's not visible on localhost.

WARNING: HTA has not been tested with this version of Docker...  continue at your own risk.
stat: cannot read file system information for '%m': No such file or directory
start_docker.sh: 36: [: File:: unexpected operator
Detected existing instance of HTA running... kill it, then restart...
Removing hta_web_run_3 ... done
Removing hta_web_run_2 ... done
Removing hta_web_run_1 ... done
Removing hta_web_1     ... done
Removing hta_db_1      ... done
Removing hta_rd_1      ... done
Removing network hta_default
Creating network "hta_default" with the default driver
Creating hta_db_1 ... done
Creating hta_rd_1 ... done
Creating hta_web_1 ... done
Starting hta_rd_1 ... done
Starting hta_db_1 ... done
(0.3ms)  SELECT pg_try_advisory_lock(737815420147457505)
(1.8ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
ActiveRecord::InternalMetadata Load (5.6ms)  SELECT  "ar_internal_metadata".*
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/validations.rb:78:in raise_validation_error' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/validations.rb:50:in save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/attribute_methods/dirty.rb:43:in save!' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:313:in block in save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:384:in block in with_transaction_returning_status' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/database_statements.rb:235:in block in transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/transaction.rb:194:in block in within_new_transaction' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/transaction.rb:191:in within_new_transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/database_statements.rb:235:in transaction' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:210:in transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:381:in with_transaction_returning_status' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:313:in save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/suppressor.rb:46:in save!' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/persistence.rb:51:in create!'
/opt/hta/db/seeds.rb:5:in <top (required)>' /usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in load'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in block in load' /usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:258:in load_dependency'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in load' /usr/local/bundle/gems/railties-5.1.6/lib/rails/engine.rb:549:in load_seed'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/tasks/database_tasks.rb:270:in load_seed' /usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/railties/databases.rake:184:in block (2 levels) in <top (required)>'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/commands/rake/rake_command.rb:21:in block in perform' /usr/local/bundle/gems/railties-5.1.6/lib/rails/commands/rake/rake_command.rb:18:in perform'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/command.rb:46:in invoke' /usr/local/bundle/gems/railties-5.1.6/lib/rails/commands.rb:16:in <top (required)>'
bin/rails:4:in require' bin/rails:4:in '
Tasks: TOP => db:seed
(See full trace by running task with --trace)
Starting hta_rd_1 ... done
Starting hta_db_1 ... done
All done!  HTA should now be browsable on your local IP!

So you don't necessarily need to run rails secret... it's just one way of generating a sufficiently long and random key.
Your migration failed.  Looks like there are still remnants (and you might also have been successful in getting this going previously) from the first time.  Run:
docker volume prune

to clean it up completely, then re-run the script.  Also, if it says it's running, then it's running.  Are you sure you're using the correct port (https://<IP_ADDRESS>, not https://<IP_ADDRESS>:3000).

Also, please read the output from the script.  Please do not use the server keys that come bundled with the repo...  the server can be MitM'd and your admin's session key can be stolen (giving whoever did it all of the answers).

I reran the cert instructions, so hopefully that fixed the MitM issue, though I'll accept a cheat if they hack the answers.  Ran docker volume purge, regstarted, reran the updated ./start_docker.sh
It was not accessible on https://<IP_ADDRESS>, http://<IP_ADDRESS>, nor https://<IP_ADDRESS>:3000
stat: cannot read file system information for '%m': No such file or directory
./start_docker.sh: 36: [: File:: unexpected operator
Detected existing instance of HTA running... kill it, then restart...
Removing hta_web_run_3 ... done
Removing hta_web_run_2 ... done
Removing hta_web_run_1 ... done
Removing hta_web_1     ... done
Removing hta_db_1      ... done
Removing hta_rd_1      ... done
Removing network hta_default
Creating network "hta_default" with the default driver
Creating hta_rd_1 ... done
Creating hta_db_1 ... done
Creating hta_web_1 ... done
Starting hta_db_1 ... done
Starting hta_rd_1 ... done
   (0.2ms)  SELECT pg_try_advisory_lock(737815420147457505)
   (1.8ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
  ActiveRecord::InternalMetadata Load (1.9ms)  SELECT  "ar_internal_metadata".*
ActiveRecord::RecordInvalid: Validation failed: Name has already been taken
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/validations.rb:78:in `raise_validation_error'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/validations.rb:50:in `save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/attribute_methods/dirty.rb:43:in `save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:313:in `block in save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:384:in `block in with_transaction_returning_status'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/database_statements.rb:235:in `block in transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/connection_adapters/abstract/database_statements.rb:235:in `transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:210:in `transaction'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:381:in `with_transaction_returning_status'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/transactions.rb:313:in `save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/suppressor.rb:46:in `save!'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/persistence.rb:51:in `create!'
/opt/hta/db/seeds.rb:5:in `<top (required)>'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in `load'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in `block in load'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:258:in `load_dependency'
/usr/local/bundle/gems/activesupport-5.1.6/lib/active_support/dependencies.rb:286:in `load'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/engine.rb:549:in `load_seed'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/tasks/database_tasks.rb:270:in `load_seed'
/usr/local/bundle/gems/activerecord-5.1.6/lib/active_record/railties/databases.rake:184:in `block (2 levels) in <top (required)>'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/commands/rake/rake_command.rb:21:in `block in perform'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/commands/rake/rake_command.rb:18:in `perform'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/command.rb:46:in `invoke'
/usr/local/bundle/gems/railties-5.1.6/lib/rails/commands.rb:16:in `<top (required)>'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
Tasks: TOP => db:seed
(See full trace by running task with --trace)
Starting hta_db_1 ... done
Starting hta_rd_1 ... done
All done!  HTA should now be browsable on your local IP!

I should note this is a linked VM prior to getting it working with the other instructions.  So it's essentially a fairly clean Ubuntu 16.04 install.  It does not have the prior stuff.  When you asked me to redo it with the updated script, I started over to test the process.

I can try to start over again, making sure I install all those dependent packages before running the script.

Also noticed while installing the certs.
echo "<IP_ADDRESS> localhost.ssl" | sudo tee -a /private/etc/hosts
This fails on Ubuntu as the host file is located in /etc/hosts

So the restart, adding libpq-dev and nodejs beforehand, cert stuff, installing docker and then running the .start_docker.sh mostly worked.
I am now able to see the ctf on https://<IP_ADDRESS>, however, it looks like it's missing the CSS, images, etc.  It's just text.  Permissions issue?    I've now tested this on three
separate systems (MacOS, Ubuntu 16.04, and Ubuntu 18.04), and they all
work.  All fresh installs and clones of the repo.  Have you modified any of
the content?
On Sat, May 26, 2018 at 12:09 PM ElJefe<EMAIL_ADDRESS>wrote:

ActionController::RoutingError (No route matches [GET]
"/stylesheets/application.css"):
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#issuecomment-392274878,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5B7lr1EELWqXanHQElHtgvVDqHne0ks5t2YxEgaJpZM4UM6fB
.

I had installed a few things on it, but not much.
  HTA should now be browsable on your local IP (https://<IP_ADDRESS>)!

looking at my file system, there is no folder /opt/hta

You won’t see one. That’s inside the container. Is it working now? Also,
you didn’t modify the source did you?
On Sat, May 26, 2018 at 14:12 ElJefe<EMAIL_ADDRESS>wrote:

looking at my file system, there is no folder /opt/hta
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#issuecomment-392282336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5B7nGGdEml4I51CRLKIgxeGBxzXF6ks5t2akEgaJpZM4UM6fB
.

I reran the .start_docker.sh and now it's working correctly.  No modifications to the source were made.

Couple things to add.. the settings have an option "Subtract hint deductions before problem is solved", but I don't see any place on the Problem page to add Hints for the question.  Also, I didn't see an value for the hints, which I expect would be problem specific if you have that option enabled.
Also, here is a formatting issue..

I think the checkbox problem may be the width.  I set the checkbox width: 16px and it fixed it, where doing things like float: left, span did nothing.

Great!
Hints are added in the hint tab on the problem view
The formatting issue is only on the admin view in some browsers. Feel
free to fix it (but make sure it works in all browsers) and submit a pull
request!
On Sun, May 27, 2018 at 08:36 ElJefe<EMAIL_ADDRESS>wrote:

I think the checkbox problem may be the width. I set the checkbox width:
16px and it fixed it, where doing things like float: left, span did nothing.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#issuecomment-392331617,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5B1nfPTimp4-7w3hyS8GLCrm_fNpNks5t2qv0gaJpZM4UM6fB
.

I don't see a hint tab in problem view.  My pages look the same as https://github.com/mcpa-stlouis/hack-the-arch/wiki/Screenshots

Click on "Problems" at the top, then expand one of the problems (like in
this screenshot:
https://github.com/mcpa-stlouis/hack-the-arch/wiki/Screenshots#description).
If you're signed in as the admin, there will be a hint tab.
On Mon, May 28, 2018 at 7:01 AM ElJefe<EMAIL_ADDRESS>wrote:

I don't see a hint tab in problem view. My pages look the same as
https://github.com/mcpa-stlouis/hack-the-arch/wiki/Screenshots
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#issuecomment-392508461,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5B2VupJ93MW0yPQCkwrMJOlcfpD0bks5t2-cQgaJpZM4UM6fB
.

Ok, I didn't realize that the problem bar expanded.  Sort of expect to add hints on the edit page.  And not sure where to create hints as it seems to be pulling from a list created elsewhere, which seems weird as I don't expect people will often reuse the same hint.  Might want to rethink the organization on that one.

Indeed.  Thanks for the feedback.  You're not the first person to
mention this, but ultimately, it's just exposed to the admin, and it makes
sense to me.  If it's really that confusion, you have the option of
programmatically creating all of your hints and challenges by interacting
with the rails console (it's much easier than it sounds).  The hint re-use
use-case is for a generic first hint that might say "no hints available",
or "this first one was free... after this it will cost you."  Feel free to
make it better and submit a pull request.
Not sure what you mean here... those buttons aren't visible to the
competitor, so making one of them expand the problem doesn't work.  Just
click the title of the challenge to expand.  If there's an issue with
formatting, again, feel free to submit a pull-request... it looks fine in
Safari and Chrome.

On Mon, May 28, 2018 at 7:21 AM ElJefe<EMAIL_ADDRESS>wrote:

Ok, I didn't realize that the problem bar expanded. Sort of expect to add
hints on the edit page. And not sure where to create hints as it seems to
be pulling from a list created elsewhere, which seems weird as I don't
expect people will often reuse the same hint. Might want to rethink the
organization on that one.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mcpa-stlouis/hack-the-arch/issues/52#issuecomment-392512556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIb5B3N39UIy79O5pwifxWWuXUnqUvtPks5t2-uygaJpZM4UM6fB
.

Nothing heard on the original issue; feel free to re-open if you make the changes!


Getting undef when creating a instance of Mojo::DOM

Mojolicious version: 7.48
Perl version: 5.26.1
Operating system: Win10 x64

Steps to reproduce the behavior
Tried to parse the page: http://tcdecks.net/format.php?format=Pauper
Expected behavior
The proper DOM instance, for me to get values out of it
Actual behavior
Returned a undef value
Sample code
use strict;
use LWP::UserAgent;
use Mojo::DOM;
my $url = 'http://tcdecks.net/format.php?format=Pauper';
my $ua = LWP::UserAgent->new();
my $response = $ua->get( $url );
if ( $response->is_success ) {
$response = $response->decoded_content;
my $dom = Mojo::DOM->new( $response );
$dom is undef at this point
}

Works fine for me, i get the correct DOM structure.

Hey, wait a minute, just because it Works for you, is auto-close in here? What kind of help is this?
IF it really worked, please send me a print using any code, $dom->at( '.span5' ) for exaqmple.
It gives no erros, just can't use any method because it is actually undef

We don't use GitHub for support requests, too few eyeballs. For help that's not bug related please go here.


DOC: add Examples for stats.ranksums() docstring.

Reference issue

fix a part of #7168
What does this implement/fix?

add Examples for stats.ranksums() docstring.

Close and reopen to rerun tests.

LGTM too, in it goes. Thanks @AtsushiSakai, and thanks @pvanmulbregt for the review


Create custom image that does not have ssh keys stored

All keys that were stored in the image have been removed.
For dbadmin ssh keys in particular, a new variable has been added (NO_SSH_KEYS) that will allow to create an image that do not have those static keys stored inside.
e2e-leg-1 as well as github actions have been modified to use that custom image.

I am curious about why on build-images->build-server-minimal->Login to Docker Hub  there is inputs.full_vertica_image instead of inputs.minimal_vertica_image?

I am curious about why on build-images->build-server-minimal->Login to Docker Hub there is inputs.full_vertica_image instead of inputs.minimal_vertica_image?

I think that is a bug. Can you fix it?

I am curious about why on build-images->build-server-minimal->Login to Docker Hub there is inputs.full_vertica_image instead of inputs.minimal_vertica_image?

I think that is a bug. Can you fix it?

I will.


An error link in README.md

Chapter: Tools to pair with tv

q - Command line csv data manipulation query-like. [Python | CLI]

But, https://github.com/zestyping/q is a debug tool. I think https://github.com/harelba/q is the right link.

@chasing-freedom In the spirit of collaboration, if you are interesting in contributing I can leave this open for you. If not then I can fix it at a later date.

@chasing-freedom In the spirit of collaboration, if you are interesting in contributing I can leave this open for you. If not then I can fix it at a later date.

Thank you for inviting me. I create a pull request. 😁


Is it possible to register a custom cloud provider for mail attachments?

[Enter feedback here]
Is it possible with Outlook add-ins API to register another cloud provider when an attachment is added in a new message, because it seems that only OneDrive is supported:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3b2e062e-1a7a-1861-bf20-c23ac64d0d37
Version Independent ID: ae2d1395-2a87-1bda-00fb-1b30f8e27b66
Content: Outlook add-ins overview - Office Add-ins
Content Source: docs/outlook/outlook-add-ins-overview.md
Product: outlook
Technology: add-ins
GitHub Login: @o365devx
Microsoft Alias: o365devx

@Odirb Could you please elaborate more on what usecase/scenario you are trying to solve. It is possible for 3rd party cloud storage providers to use Outlook extensibility and office-js APIs to interact with attachments in different ways. If you could elaborate more on what you are trying to solve, we might be able to help you better.

Hello Sreeam,
Our company has developed a plugin for the desktop version Outlook (using VSTO) that automatically upload on our servers instead of sending then as regular attachment. For exemple, when the file is too large or contains some AIP sensitivity labels such as "confidential", theses files are uploaded on our servers with the plugin, and a link is added in the message body for download.
We would like to do the same using the javascript API "Office add-ins platform", but the only things that seems possible is creating a panel to manually select files.
So my question is, is it possible to intercept when attachment are added with "Attach / Browse this computer" the same way it was possible with VSTO.
I have noticed that a popup is already displayed when files are too large, but only OneDrive is the only cloud provider available. Is it possible to register another cloud provider in this popup?
Thanks

@exextoc Can you take a look? Thx.

Currently the feature to register a custom cloud provider for mail attachments, you requested, is not a part of the product. We track Outlook add-in feature requests on our Tech Community Page. Please submit your request there and choose the appropriate label(s). Feature requests on Tech Community are considered, when we go through our planning process.
Github Label: “Type: product feature request”
https://aka.ms/M365dev-suggestions


No color preview appears

Extension Version: 0.4.5
VS Code Version: 1.66.2
OS Version: Win10
Node.js Version (result of command node -v): 16.14.0
NPM Version (result of command npm -v): 8.5.0

Steps to Reproduce:

Type # and select the color picker

No preview of the selected color appears? Perhaps I'm doing something wrong?

Hi @NickWoodward, thank you for the comment.
Could you explain more?

What is the "color preview"?
What is the image in your comment? (That seems to be a color picker of another app such as Adobe Photoshop, MS Excel, or something.)
What does the "Type # and select the color picker" mean?

Hi @anseki - my mistake - that was another color picker that I've now removed!
Although 'Alt+C P' isn't working either. Appreciate the quick reply!

I see.
So, could you answer to other questions?

Sorry, none of my original questions make sense because it wasn't your extension running - typing # was how the other color picker was executed, and your extension does have a color preview pane
But now that I've uninstalled that other extension, I can't get your dialog box to pop up at all. Either by running Pick Color or Alt+C P. Neither works.

Could you show the log?
https://github.com/anseki/vscode-color/blob/master/.github/ISSUE_TEMPLATE.md

sorry about the formatting

It's gone back to outputting nothing on alt+c p

Maybe that is not all of the log.
Try this:
cd c:\Users\Nick\.vscode\extensions\anseki.vscode-color-0.4.5
npm install<EMAIL_ADDRESS>
And restart VS Code, and run the extension.

не работает ваше приложение. Вы хоть ответьте кому не будь

No reply came, then this abandoned issue is closed.

I have the same issue.


[Feature][Server] Add Job preview button

Purpose of this pull request

#311

Add Job preview button in JobList

Check list

[ ] Code changed are covered with tests, or it does not need tests for reason:
[ ] Change does not need document change

add preview button in Job Editor interface


tPages

Ionic version:  (check one with "x")
(For Ionic 1.x issues, please use https://github.com/ionic-team/ionic-v1)
[ ] 2.x
[ ] 3.x
[ ] 4.x
I'm submitting a ...  (check one with "x")
[ ] bug report
[ ] feature request
Please do not submit support requests or "How to" questions here. Instead, please use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:

Expected behavior:

Steps to reproduce:

Related code:

insert short code snippets here

Other information:

Ionic info: (run ionic info from a terminal/cmd prompt and paste output below):
insert the output from ionic info here

@itshakeel23 if you open a useless/empty issue.. fill it with context or close it, please.

Hello! While we appreciate you opening an issue with us I am going to close this issue and ask that you open a new one that has the issue template filled out, please. Thanks for using Ionic!


progress bar does not show progress during revisions

The progress bar shows progress when inserting a new sheet but does not show progress when inserting a sheet with revisions (video linked below)
https://photos.app.goo.gl/SWznH1Ljq6fR222aA

fixed.


synchronize content padding

hi.
in responsive web design, "editorjs" area resize self. but, it is different other items.
outside wrapper like other them, but in content blocks doesn't like them. small size okay. but it overs specific size, then work strange.
ce-block it works nice.
ce-block__content it works very strange and make me anoying.(  IT HAS AUTOMATED PADDING...)
My div block works with ce-block. not ce-block__content.
But for looking good, it have to work with ce-block__content.
There are specific ways to solve this problem, or I am doing something wrong?
(Some people it is very ezpz just make responsive function(calculate padding and apply it them)), but i don't like do them..)
Thanks.

i had wrong repository..