PolicyTagManagerClient methods: 501 Operation is not implemented, or supported, or enabled

I'm writing a script to use the PolicyTagManagerClient, but all methods fail with a google.api_core.exceptions.MethodNotImplemented: 501 Operation is not implemented, or supported, or enabled. message.

[x] Search the issues already opened: https://github.com/googleapis/python-datacatalog/issues
[x] Search StackOverflow: https://stackoverflow.com/questions/tagged/google-cloud-platform+python

Related SO question: https://stackoverflow.com/questions/61916663/gcp-datacatalog-v1beta1-create-taxonomy-and-policy-tags-failed

Environment details

OS type and version: Windows 10
Python version: 3.7.2
pip version: 20.1.1
google-cloud-datacatalog version: 0.8.0

Steps to reproduce

Run a script calling any of the PolicyTagManagerClient methods.

Code example
https://github.com/googleapis/python-datacatalog/pull/37/files
OR simply:
def create_taxonomy(project_id):
    """Create a Taxonomy."""

    location = datacatalog_v1beta1.PolicyTagManagerClient.location_path(project_id, 'us')

    taxonomy = types.Taxonomy()
    taxonomy.display_name = "My Taxonomy"
    taxonomy.description = "This Taxonomy represents ..."

    datacatalog_v1beta1.PolicyTagManagerClient().create_taxonomy(
        parent=location, taxonomy=taxonomy)

Stack trace
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
        status = StatusCode.UNIMPLEMENTED
        details = "Operation is not implemented, or supported, or enabled."
        debug_error_string = "{"created":"@1590760876.084000000","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"Operation is not implemented, or supported, or enabled.","grpc_status":12}"
>

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

Traceback (most recent call last):
  File "policy_tags_manager.py", line 118, in <module>
    PolicyTagsManagerCLI.run(sys.argv[1:] if len(sys.argv) > 0 else sys.argv)
  File "policy_tags_manager.py", line 81, in run
    args.func(args)
  File "policy_tags_manager.py", line 110, in __create_taxonomy
    description=args.description)
  File "policy_tags_manager.py", line 34, in create_taxonomy
    return self.__datacatalog_facade.create_taxonomy(project_id, display_name, description)
  File "policy_tags_manager.py", line 63, in create_taxonomy
    parent=location, taxonomy=taxonomy)
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\cloud\datacatalog_v1beta1\gapic\policy_tag_manager_client.py", line 305, in create_taxonomy
    request, retry=retry, timeout=timeout, metadata=metadata
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\api_core\gapic_v1\method.py", line 143, in __call__
    return wrapped_func(*args, **kwargs)
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\api_core\retry.py", line 286, in retry_wrapped_func
    on_error=on_error,
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\api_core\retry.py", line 184, in retry_target
    return target()
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\api_core\timeout.py", line 214, in func_with_timeout
    return func(*args, **kwargs)
  File "<REDACTED-PATH>\gcp-datacatalog-python\env\lib\site-packages\google\api_core\grpc_helpers.py", line 59, in error_remapped_callable
    six.raise_from(exceptions.from_grpc_error(exc), exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.MethodNotImplemented: 501 Operation is not implemented, or supported, or enabled.

I'm having this issue as well. Does the Google team have an official view on whether or not this is a bug or misuse of the API?

Hi there — we are actively investigating this but do not yet have an answer. Google folks, this is being tracked at internal bug b/159220336.

Marking this as "external" since we're tracking most of the work internally and will report back when we have more progress. Thanks!

I have a same issue for list_tags (using v2.0.0).
Note that this happens quite often, but not always. The API call succeeds something like once per ten times.
Here's the stacktrace:
Traceback (most recent call last):
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/api_core/grpc_helpers.py", line 57, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/grpc/_channel.py", line 826, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/grpc/_channel.py", line 729, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
        status = StatusCode.UNIMPLEMENTED
        details = "Operation is not implemented, or supported, or enabled."
        debug_error_string = "{"created":"@1600948541.258238000","description":"Error received from peer ipv6:[2404:6800:4004:80a::200a]:443","file":"src/core/lib/surface/call.cc","file_line":1062,"grpc_message":"Operation is not implemented, or supported, or enabled.","grpc_status":12}"
>

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

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<REDACTED>/.venv/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "<REDACTED>/.venv/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "<REDACTED>/myapp/main.py", line 48, in export_metadata
    for table_metadata in fetcher.fetch_tables_metadata(project_id, dataset_id):
  File "<REDACTED>/myapp/gcp/fetch.py", line 55, in fetch_tables_metadata
    for tag in self.datacatalog.list_tags(request={"parent": path}):
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/cloud/datacatalog_v1beta1/services/data_catalog/client.py", line 2508, in list_tags
    response = rpc(request, retry=retry, timeout=timeout, metadata=metadata,)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/api_core/gapic_v1/method.py", line 145, in __call__
    return wrapped_func(*args, **kwargs)
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/api_core/retry.py", line 281, in retry_wrapped_func
    return retry_target(
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/api_core/retry.py", line 184, in retry_target
    return target()
  File "<REDACTED>/.venv/lib/python3.8/site-packages/google/api_core/grpc_helpers.py", line 59, in error_remapped_callable
    six.raise_from(exceptions.from_grpc_error(exc), exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.MethodNotImplemented: 501 Operation is not implemented, or supported, or enabled.

Getting this issue for create_entry_group.
Earlier docker images for my application a few days/past couple of weeks earlier that were working are now broken too.
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/google/api_core/grpc_helpers.py", line 57, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/grpc/_channel.py", line 826, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/usr/local/lib/python3.7/site-packages/grpc/_channel.py", line 729, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNIMPLEMENTED
	details = "Operation is not implemented, or supported, or enabled."
	debug_error_string = "{"created":"@1601032810.362696516","description":"Error received from peer ipv4:<IP_ADDRESS>:443","file":"src/core/lib/surface/call.cc","file_line":1061,"grpc_message":"Operation is not implemented, or supported, or enabled.","grpc_status":12}"
>

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

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/src/intient_research_admin_app_backend/csv_datacatalog_ingestion_fileset.py", line 139, in <module>
    create_fileset_method()
  File "/src/intient_research_admin_app_backend/csv_datacatalog_ingestion_fileset.py", line 88, in create_fileset_method
    entry_group=entry_group_obj)
  File "/usr/local/lib/python3.7/site-packages/google/cloud/datacatalog_v1/gapic/data_catalog_client.py", line 503, in create_entry_group
    request, retry=retry, timeout=timeout, metadata=metadata
  File "/usr/local/lib/python3.7/site-packages/google/api_core/gapic_v1/method.py", line 145, in __call__
    return wrapped_func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/google/api_core/retry.py", line 286, in retry_wrapped_func
    on_error=on_error,
  File "/usr/local/lib/python3.7/site-packages/google/api_core/retry.py", line 184, in retry_target
    return target()
  File "/usr/local/lib/python3.7/site-packages/google/api_core/timeout.py", line 214, in func_with_timeout
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/google/api_core/grpc_helpers.py", line 59, in error_remapped_callable
    six.raise_from(exceptions.from_grpc_error(exc), exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.MethodNotImplemented: 501 Operation is not implemented, or supported, or enabled.

Seeing same issue for list_tags with images that were built a week ago.
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNIMPLEMENTED
	details = "Operation is not implemented, or supported, or enabled."
	debug_error_string = "{"created":"@1601040451.272763000","description":"Error received from peer ipv6:[2607:f8b0:400b:808::200a]:443","file":"src/core/lib/surface/call.cc","file_line":1062,"grpc_message":"Operation is not implemented, or supported, or enabled.","grpc_status":12}"
>

I'm having this same issue for list_tags (google-cloud-datacatalog==1.0.0)! Yesterday was working with no problem and today I've noticed that after they change the Data Catalog UI, my code broked!
Error
Traceback (most recent call last):
  File "\lib\site-packages\google\api_core\grpc_helpers.py", line 57, in error_remapped_callable
    return callable_(*args, **kwargs)
  File "\lib\site-packages\grpc\_channel.py", line 826, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "\lib\site-packages\grpc\_channel.py", line 729, in _end_unary_response_blocking
    raise _InactiveRpcError(state)
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNIMPLEMENTED
	details = "Operation is not implemented, or supported, or enabled."
	debug_error_string = "{"created":"@1601048577.314000000","description":"Error received from peer ipv6:[2800:3f0:4004:800::200a]:443","file":"src/core/lib/surface/call.cc","file_line":1062,"grpc_message":"Operation is not implemented, or supported, or enabled.","grpc_status":12}"
>

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

Traceback (most recent call last):
  ...
    map_tags = {t.template_display_name: t for t in data_catalog_client.list_tags(entry.name)}
  File "\lib\site-packages\google\api_core\page_iterator.py", line 212, in _items_iter
    for page in self._page_iter(increment=False):
  File "\lib\site-packages\google\api_core\page_iterator.py", line 243, in _page_iter
    page = self._next_page()
  File "\lib\site-packages\google\api_core\page_iterator.py", line 534, in _next_page
    response = self._method(self._request)
  File "\lib\site-packages\google\api_core\gapic_v1\method.py", line 145, in __call__
    return wrapped_func(*args, **kwargs)
  File "\lib\site-packages\google\api_core\retry.py", line 286, in retry_wrapped_func
    on_error=on_error,
  File "\lib\site-packages\google\api_core\retry.py", line 184, in retry_target
    return target()
  File "\lib\site-packages\google\api_core\timeout.py", line 214, in func_with_timeout
    return func(*args, **kwargs)
  File "\lib\site-packages\google\api_core\grpc_helpers.py", line 59, in error_remapped_callable
    six.raise_from(exceptions.from_grpc_error(exc), exc)
  File "<string>", line 3, in raise_from
google.api_core.exceptions.MethodNotImplemented: 501 Operation is not implemented, or supported, or enabled.

I don't see this problem happen today, so maybe this is the problem on the API side, not the library side?

The problem has gone away for me as well. So I'm assuming it was on the API side.

Same here. The library is working again!

Thanks for the updates, folks
Important to let it clear the bug that caused list_tags to fail was probably caused by an internal service disruption that might already be resolved, but it is not the same error originally reported here, despite the similar error messages.

The internal issue b/159220336 for the problem with the API was fixed, and the other issue was an internal service disruption. Closing this issue but please reopen a new issue if the problem re-occurs because it might be indicative of a new/different problem. Thanks!

I had a similar problem.
code:
from google.cloud.run_v2 import ListServicesRequest
from google.oauth2 import service_account
import google.cloud.run_v2 as run_v2

credentials = service_account.Credentials.from_service_account_file("key.json")

run_client = run_v2.ServicesClient(credentials=credentials)

request = ListServicesRequest(
    parent="projectId"
)

run_client.list_services(request=request)

error:
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
        status = StatusCode.UNIMPLEMENTED
        details = "Operation is not implemented, or supported, or enabled."
        debug_error_string = "UNKNOWN:Error received from peer ipv4:<IP_ADDRESS>:443 {created_time:"2022-11-02T19:19:04.5426831+00:00", grpc_status:12, grpc_message:"Operation is not implemented, or supported, or enabled."}"
>

@rvoitovich Your issue seems to be in a different client library — https://cloud.google.com/python/docs/reference/run/latest/google.cloud.run_v2.types.ListServicesRequest seems to be the correct reference here. The relevant GitHub repo to report this issue on is here: https://github.com/googleapis/python-run Thanks!


Add the ability to create only exchange for RabbitMq ReceiveEndpoint

When is used DeployTopologyOnly=true for creating RabbitMQ Bus very useful to have the ability to deploy the only exchange, without a queue.  It's helpful for cases when we have a topology with direct exchanges.
For this purpose added property CreateExchangeOnly in IRabbitMqReceiveEndpointConfigurator.

I would rather see this logic inverted, with BindQueue=true by default, allowing it to be set to false so that the queue isn't created or bound. A small tweak, but seems more consistent with the bindqueue URI parameter.

CreateExchangeOnly was changed to BindQueue. By default BindQueue has the value true.

Great, thanks!


Are data-semantic-owns nodes always descendants?

I couldn't produce a case where semantic children are not descendants. Is that generally the case?

When you say descendants, do you mean descendants in the mml tree? In that case, no. There are a couple of heuristics pull elements together from different branches of the syntactic tree.
At least one will be in the upcoming release for lim and script types. I'll try to find an example.

When you say descendants, do you mean descendants in the mml tree?

Yes.

In that case, no. There are a couple of heuristics pull elements together from different branches of the syntactic tree.
At least one will be in the upcoming release for lim and script types. I'll try to find an example.

Thanks, I suspected as much. An example would be great (for writing  test(.

A example (downstream) are labeled table rows in MathJax output being torn out of their rows.


Move pFUnit submodule to OpenFAST's fork

The unit testing framework used in OpenFAST, pFUnit, is hosted on sourceforge. However, it is common to encounter SSL errors or time outs when cloning this repo. A fork of pFUnit has been created under the OpenFAST GitHub team, and this pull request changes the submodule reference to the GitHub hosted pFUnit.
For reference, the OpenFAST fork of pFUnit is at:
https://github.com/openfast/pfunit

@rafmudaf It would be good to add a description at the top of the pfUnit github repo page saying that this is a read-only copy snapshot of the source hosted here for OpenFAST. Everything else looks good to me.

@sayerhs great idea, thanks


Fix Checkstyle violation: forbidding making public Logger

Return Logger out of the class is a very bad practice as it produce logs that are hard to investigate as logging class does not contains that code and search should be done in other classes or in hierarchy (if filed is public or accessible by other protected or package)

Does Guice even have a checkstyle config that this is violating?
On Wed, Jan 27, 2016, 5:21 PM Yasser Aziza<EMAIL_ADDRESS>wrote:

Return Logger out of the class is the very bad practice as it produce logs
that are hard to investigate as logging class does not contains that code
and search should be done in other classes or in hierarchy (if filed is
public or accessible by other protected or package)
You can view, comment on, or merge this pull request online at:
https://github.com/google/guice/pull/987
Commit Summary

Fix Checkstyle violation: forbidding making public Log

File Changes

M core/src/com/google/inject/internal/BytecodeGen.java
https://github.com/google/guice/pull/987/files#diff-0 (2)
M core/test/com/google/inject/LoggerInjectionTest.java
https://github.com/google/guice/pull/987/files#diff-1 (4)
M
extensions/assistedinject/src/com/google/inject/assistedinject/FactoryProvider2.java
https://github.com/google/guice/pull/987/files#diff-2 (2)

Patch Links:

https://github.com/google/guice/pull/987.patch
https://github.com/google/guice/pull/987.diff

—
Reply to this email directly or view it on GitHub
https://github.com/google/guice/pull/987.

Hi @sameb, sorry for the confusion.
I am a Checkstyle contributor, i sent this PR to get some feedback about a new check we have that forbid public Logger:
https://github.com/sevntu-checkstyle/sevntu.checkstyle/issues/286
https://github.com/sevntu-checkstyle/sevntu.checkstyle/pull/426
Guice was one of the project i tested and wanted to share the results with you.
Thank you !

Hi @tavianator, thank you for your feedback !


"Factory" not exported in browser

In a browser environment, rosie.js only exports its global Factory object if it's executed at the top level scope. But when it's not, for instance because it's wrapped like so ...
loader.register('rosie', function(
  // ... rosie.js contents ...
});

... then there is no way to get at the Factory object. That's because Factory is defined using var and never exported to window.
Could we have some code that tacks it onto the global window object? (Not sure what the most idiomatic way is, or I would've sent a pull request.)

This is a good idea. I realize you've probably moved on to other things, @joliss, but this is fixed by #39. I expect it'll be released in v1.1.0.

This has been released in v1.1.0.


Allow tools branch to be specified with dev

Don't allow tools branch to be specified during upgrade.

https://ocd.appscale.com:8080/job/Daily Build/449/


MYSQL using ALT+X and PREPARE - EXECUTE

Description
In the last version <IP_ADDRESS>40421624 a new error is occorring in LINUX portuguese using a Mysql database.
When i execute step by step this instructions with CTRL+ENTER it works.
SET @a = 'Helllo ';
SET @b = 'world';
SET @s = CONCAT("SELECT '", @a , @b, "'");
SELECT @s;
PREPARE stmt3 FROM @s;
EXECUTE stmt3;
When i execute the all instructions with the command ALT+X,  i receive an error
Erro SQL [1064] [42000]: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PREPARE stmt3 FROM @s;
EXECUTE stmt3;
DBeaver Version
Comunity Edition <IP_ADDRESS>40421624
Operating System
LINUX UBUNTU portuguese VERSION="20.04.6 LTS (Focal Fossa)
Database and driver
Mysql 5.5.62-0+deb8u1
Steps to reproduce
SET @a = 'Helllo ';
SET @b = 'world';
SET @s = CONCAT("SELECT '", @a , @b, "'");
SELECT @s;
PREPARE stmt3 FROM @s;
EXECUTE stmt3;
When i execute step by step this instructions with CTRL+ENTER it works.
When i execute the all instructions with the command ALT+X,  i receive an error.
Additional context
No response

Thank you for report.
Could you try switching Blank line is statement delimiter setting to Always? Does it help?

Bingo, I changed to "always" e and now is working
Thanks!

The fix will be included in DBeaver 24.0.4.
Also you can try Early Access version with fix https://dbeaver.io/files/ea/ now.

Not sure if this case is fixed. When using ALT-x on this script
DROP TABLE IF EXISTS t;
CREATE TEMPORARY TABLE t (c text);
INSERT INTO t VALUES ('x');
-- comment here

the result is 2 rows in t.
If you remove the last comment, only 1 row. In execution log I can se that INSERT INTO t VALUES ('x'); is executed twice.
If I change from smart to never as suggested, the problem disappears.


[SIP-101] Decouple Service and Container port to support adding reverse proxy 'sidecar'

Please make sure you are familiar with the SIP process documented
(here)[https://github.com/apache/superset/issues/5602]. The SIP will be numbered by a committer upon acceptance.
[SIP] Proposal for Decouple Service and Container port to support adding reverse proxy 'sidecar'
Motivation
To efficiently serve the static files, the use of a reverse proxy http server is possible with the extraContainers value and a shared volume between the two containers. The problem is that the service forwards traffic to the superset port (Values.service.port) on the POD. To allow the nginx sidecar to serve traffic and split between static and the supersetNode container, the service needs to serve traffic on the nginx port of the POD.
Proposed Change
I propose the values.service.port gets decoupled from the newly introduced supersetPort value. The supersetPort value will be used in the deployment.yaml to set the containerPort and SUPERSET_PORT env variable, whereas the values.service.port will be used to point to the port that should be used as the http interface. To avoid breaking changes maybe the supersetPort can default to the service.port?
New or Changed Public Interfaces

New dependencies

Migration Plan and Compatibility

Rejected Alternatives

Happy to open a PR!

@rusackas @craig-rueda is there an idea on the timeline for this sip? Would it speed things up if I open a PR?
Cheers

Not sure this needs to be a SIP. Pls feel free to update the containerPort in the service definition to reference a separate value (it's currently hard-coded to point at http).


Applicants can view the app in their chosen language

Either we have admins specify translations for every string into every language, or we just enable Google Translate or something on the applicant side.

To clarify, this only means that the infrastructure for i18n/l10n needs to be in place. That is, we should be able to add translated strings and users should be able to view in a foreign language. The translated strings don't all need to be in there yet!

This is partially complete - we have the infrastructure in place to internationalize app text (ex: button text, etc). I am not sure if the admin has the ability yet to add translations for question strings, block names, etc.

Is this one for the whole website language or the application form language? I feel what @carolinedanzi mentioned is more in the #864 ? Here is the mockup for the whole website language choice without a design system, will add more details later on.
https://miro.com/app/board/o9J_lXULxwE=/?moveToWidget=3074457357995812556&cot=14

I believe this is viewing the app itself, not a specific application. If that is the case, this is ready for story acceptance


Accidental Logout

When a user clicks on the logout button, the logout is instant. This means that if a user is currently doing a quiz they can accidentally click on the logout button instead of the end quiz button, therefore annulling their quiz and its respective grade. There should be at least a logout confirmation pop-up (standard practice).

If a student does a logout during a quiz can login again and continue answering the quiz

That does not change the problem that users can accidentally logout. If a user has a poor connection and can't log back in they will lose their quiz. Or if they have little time left and accidentally press the logout button instead of the end quiz button (they're next to each other), they may not be able to log in and submit the quiz. The user shouldn't lose their work eitherway.

It is not possible to control all the accidental actions that can be done, for instance, the user can accidentally close the browser tab. If the student does not submit the quiz the answers are not lost because every selection done by the student during the quiz is recorded and the teacher can obtain the sequence of clicks. So no problem if instead of submitting the quiz the student logout. Most of the systems do not ask about a confirmation when logging out, e.g. Fénix, Gmail...

Yes, saving every selection would be ideal, however that doesn't happen. Many users clicked on the logout button accidentally and there is, according to my professor, no way of retrieving my work. Having a simple pop- up avoids a lot of confusion and possibilities of error. Those systems don't have critical information that may be lost if the user logs out. Gmail has draft messages to avoid logout data loss and Fénix also has pop-ups when submitting files for projects or when signing up for classes when creating the semester's schedule.

When exporting the cvs associated with a quiz all students clicks are listed. You can play with demo (as new) student and demo teacher using the "In Class Quiz One Way".

That creates more work for the teacher for something that could be avoided. The end quiz button has a confirmation pop-up, why shouldn't the logout button have one?


docs: add @formkit/auto-animate example in form.md

Nice showcase for the integration with auto-animate!!


[WIP] : added a conditional dendering for the regionMap

Description
Added a conditional rendering for RegionMap based on if the region has geometry data, added a button that calls getGeometry with farce set to true when there is not geometry data.
Related Issues
Closes: #51
How Was This Tested?
This will be tested by loading regions with no geometry data to see if the button appearance. Currently my db works incorrect so I will test this  one I figure that out.
Checklist
Before submitting your PR, please review the following:

[x] Commit messages follow the standard template.
[ ] All commits are signed.
[x] Related issues are mentioned in the description above.
[x] I have followed the project's directory structure.
[ ] Linter checks have been passed.

Additional Comments (if any):

@OhmSpectator you mentioned that there was a lint script I have to run, where can I find it both frontend and backend are missing it.

@pbelokon, the script can be run from the frontend or backend directory with this command:
npm run lint

I've also updated the CONTRIBUTING.md file:
frontend - https://github.com/OhmSpectator/track-your-regions/blob/main/frontend/CONTRIBUTING.md
backend - https://github.com/OhmSpectator/track-your-regions/blob/main/backend/CONTRIBUTING.md
general - https://github.com/OhmSpectator/track-your-regions/blob/main/CONTRIBUTING.md

PS D:\track-your-regions\frontend> npm run lint
npm ERR! Missing script: "lint"

You have to pull the latest version of main. You have the old version locally:

PS D:\track-your-regions\frontend> npm run lint
npm ERR! Missing script: "lint"

You have to pull the latest version of main. You have the old version locally:

dam didn't forgot to do that thk

Rebased it

@OhmSpectator I think there is a mistake in the front-end it says that we should run  npm run linter and ``npm run linter:fix"
since in the project we use the below:
    "lint": "eslint --ext .js,.jsx src",
    "lint:fix": "eslint --fix --ext .js,.jsx src"

Hey @pbelokon, I wanted to let you know that I have merged #86 and updated the main branch accordingly. Could you please rebase this PR? Thanks!

Hey @pbelokon, I wanted to let you know that I have merged #86 and updated the main branch accordingly. Could you please rebase this PR? Thanks!

Just did it, thank you for teaching me how lol

@coderabbitai review

@pbelokon, I've prepared a prepopulated DB image. You can try to get it for full-setup testing.
I've described how to get it here: https://github.com/OhmSpectator/track-your-regions/blob/main/deployment/README.md#usage-of-prepopulated-database-container
Then you can start the back and the front as described in README (in short: create .env.development and fill with proper values and then run npm run debug for the backend and npm run start for the frontend).

@pbelokon I've rebased the branch on top of main. So, be careful when starting working on it again: do not forget to pull the latest version.

@pbelokon, I've just realized that the instructions and the scripts to create/deploy the DB are Unix-specific and unsuitable for Windows... I'll try to fix it.


Update to Guava 20.0

guava-jdk5 17.0 is very old: 3 years, which is beyond the supported lifetime of Guava. Additionally, guava on jdk5 is no longer supported since Java 5 has been EOL for a while.
This library depending on a very old version of guava was first reported here: https://github.com/google/dagger/issues/651
I don't know what to do with the files in google-http-client-assembly/dependencies/ but those look to be out of date anyway.
Note that I didn't update to Guava 21, since that version requires Java 8.

I don't think we should go past 19.0 for now. See https://github.com/grpc/grpc-java/pull/2751

Hm. While that would probably have other benefits, that wouldn't solve the referenced issue.


support for bare-metal compilation

hi hi
at the moment compilation depends on libc (and std as in #197) which is not defined for all architectures.
i've had a go at moving from libc to cty which solves part of the problem (though is v roughly implemented), though something appears to be something wrong with PIC/PIE outputting relocatable code (maybe related to https://github.com/jedisct1/libsodium/issues/677, see also: https://github.com/rust-embedded/cortex-m-rt/issues/22).
this results in:
  = note: /usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: error: no memory region specified for loadable section `.got'
          collect2: error: ld returned 1 exit status

at the final linking stage. i'm setting SODIUM_DISABLE_PIE=1 and hardcoding --no-pie and -static as CFLAGS in libsodium-sys/src/build.rs but i'm basically out of ideas.
as an aside, have you considered moving to building with cc instead of via autotools to simplify all this? i've done this in cmake before and it wasn't too complex (see also: https://github.com/sodiumoxide/sodiumoxide/issues/377, https://github.com/sodiumoxide/sodiumoxide/pull/379, https://github.com/sodiumoxide/sodiumoxide/pull/406)

Possibly related to https://github.com/fortanix/rust-mbedtls/pull/63, no solution as yet </3

have you considered moving to building with cc instead of via autotools to simplify all this?

I suggest you ask jedisct1 whether it's possible

As documented, all you need is --specs=nosys.specs in the linker flags.

Unfortunately this does not appear to be the case, I have fixed a bunch of the sodiumoxide specific issues in #422 however no combination of LDFLAGS=--specs=nosys.specs or --disable-pie appears to have any effect on the behaviour of ./configure.
Running against #442 with:
SODIUM_DISABLE_PIE=1 LDFLAGS='--specs=nosys.specs' SODIUM_HOST=arm-none-eabi cargo build --target thumbv7em-none-eabihf

Then inserting logging and a panic in libsodium_src/build.rs to show the ./configure and build invocations
build.rs:
Using CFLAGS: -O0 -ffunction-sections -fdata-sections -g -fno-omit-frame-pointer -mthumb -mfloat-abi=hard -march=armv7e-m -mfpu=fpv4-sp-d16 -Wall -Wextra
Using LDFLAGS: --specs=nosys.specs

./configure:
...
checking whether C compiler accepts -O0 -ffunction-sections -fdata-sections -g -fno-omit-frame-pointer -mthumb -mfloat-abi=hard -march=armv7e-m -mfpu=fpv4-sp-d16 -Wall -Wextra -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -mno-avx512f... no
...
Failed to configure libsodium using "/home/ryan/projects/dsf-stm-sensor/target/thumbv7em-none-eabihf/debug/build/libsodium-sys-3238d5be2da3c686/out/source/libsodium/configure" "--disable-pie" "--prefix=/home/ryan/projects/dsf-stm-sensor/target/thumbv7em-none-eabihf/debug/build/libsodium-sys-3238d5be2da3c686/out/installed" "--libdir=/home/ryan/projects/dsf-stm-sensor/target/thumbv7em-none-eabihf/debug/build/libsodium-sys-3238d5be2da3c686/out/installed/lib" "--host=arm-none-eabi" "--enable-shared=no"

arm-none-eabi-gcc:
libtool: compile:  arm-none-eabi-gcc -DPACKAGE_NAME=\"libsodium\" -DPACKAGE_TARNAME=\"libsodium\" -DPACKAGE_VERSION=\"1.0.18\" "-DPACKAGE_STRING=\"libsodium 1.0.18\"" -DPACKAGE_BUGREPORT=\"https://github.com/jedisct1/libsodium/issues\" -DPACKAGE_URL=\"https://github.com/jedisct1/libsodium\" -DPACKAGE=\"libsodium\" -DVERSION=\"1.0.18\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_C_VARARRAYS=1 -DLT_OBJDIR=\".libs/\" -DNATIVE_LITTLE_ENDIAN=1 -DHAVE_INLINE_ASM=1 -DASM_HIDE_SYMBOL=.hidden -DHAVE_WEAK_SYMBOLS=1 -DCPU_UNALIGNED_ACCESS=1 -DHAVE_ATOMIC_OPS=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_GETPID=1 -DHAVE_EXPLICIT_BZERO=1 -DCONFIGURED=1 -I. -I./include/sodium -I./include/sodium -O0 -ffunction-sections -fdata-sections -g -fno-omit-frame-pointer -mthumb -mfloat-abi=hard -march=armv7e-m -mfpu=fpv4-sp-d16 -Wall -Wextra -fvisibility=hidden -fPIC -fno-strict-aliasing -fno-strict-overflow -MT crypto_pwhash/argon2/libavx512f_la-argon2-fill-block-avx512f.lo -MD -MP -MF crypto_pwhash/argon2/.deps/libavx512f_la-argon2-fill-block-avx512f.Tpo -c crypto_pwhash/argon2/argon2-fill-block-avx512f.c -o crypto_pwhash/argon2/libavx512f_la-argon2-fill-block-avx512f.o

So configure is definitely still picking up -fPIC from somewhere

It appears the version of libsodium contained in this repo () contains a configure file, patching to remove L7021 stops -fPIC being included. As far as I can see that line checks whether -fPIC is available and then, applies it?

I also tried patching libsodium_sys/build.rs to forward --enable-pie=no instead of --disable-pie based on the internals of the libsodium/configure file, this appears to have no effect.
--- a/libsodium-sys/build.rs
+++ b/libsodium-sys/build.rs
@@ -259,7 +259,7 @@ fn make_libsodium(target: &str, source_dir: &Path, install_dir: &Path) -> PathBu
         configure_cmd.env("LDFLAGS", &ldflags);
     }
     if env::var("SODIUM_DISABLE_PIE").is_ok() {
-        configure_cmd.arg("--disable-pie");
+        configure_cmd.arg("--enable-pie=no");
     }
     let configure_status = configure_cmd
         .current_dir(&source_dir)

The latest 1.0.18-stable version disables PIE/PIC/SP/async-unwind for the eabi target, if it can help.

The latest 1.0.18-stable version disables PIE/PIC/SP/async-unwind for the eabi target, if it can help.

c.f. #420

i'm not sure what the detection for eabi is but does this also cover the eabihf case? (looking at the commit it would seem to depend whether this is derived from HOST or the compiler name?)

Opened a PR expanding the match from eabi to eabi* which gets us building with only the additional sodiumoxide modifications in #422, thanks for the comments / attention.


[RIP-9]delete useless image references and correct the description

What is the purpose of the change
delete useless image references and correct the description
Brief changelog
delete useless image references and correct the description
Verifying this change
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage decreased (-0.03%) to 44.762% when pulling 9b503234e3ee8eafa6a68f0f8e214ba3c03a0a96 on itlangzi:master into 8f37ff27db02177a1e336c8d5ee1a089a4a23939 on apache:master.


Move to react-scripts webpack config for styleguidist.

Closing for https://github.com/fs-webdev/create-react-app/pull/86


[2154] Changed start date text to match prototype

Context

This trello ticket

Changes proposed in this pull request

Changed the text from Date trainee started to Trainee's start date

Guidance to review
View the Trainee start date and ID section from the trainee details page

 General snagging - Trainee start date and ID content changes


Add Deck GCE predictive autoscaling to known issue - v2.22.0 Armory Release (OSS Spinnaker™ v1.22.1)

Hi folks,
We ran into this Deck issue when testing v2.22.0. https://github.com/spinnaker/deck/pull/8585#issuecomment-696330523
Please consider adding the fix to known issues.

Thanks for opening this issue @CB-GuangyaoXie and bringing it to our attention. I"ll work on adding it today.

Fixed by https://github.com/armory/docs/pull/248


Investigate ProtoBuf and Streaming to improve graphic serialization

We have discussed many ways of improving the serialization and loading of large data sets

Use Protobuf serialization instead of JSON (smaller, faster)
Use DotNetStreamReference to pass data as a stream to JavaScript, and read graphics as they come in
Somehow gain access to the shared memory space between WASM and JS (for wasm only), and pass a pointer to the data
Combine several of the above, and abstract so that Blazor Server, WASM, and MAUI all work efficiently with the current API methods

The main sticking point for all of the solutions above is that they do not support the blazor ObjectReference system. You cannot, without significant hacking, pass DotNetObjectReference to JS or JSObjectReference to C# via any of the systems except the built-in JSON serialization in IJSRuntime. This means that, in order to track and update graphics, we would have to

fall back to our own custom registration dictionary and rewrite all the update calls like SetGeometry (again).
OR
have a separate callback to .NET that registers the JSObjectRefs at the Layer/View level.

I really don't like the idea of #1 above and moving further from the built-in object ref system. I am investigating the second idea.


Settings sync across intel and arm Mac produces missing syntax highlighting/theme issues (arm side only).

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.16.3 (Universal)
OS Version: 11.6.1 (intel) 12.1 (arm)

Steps to Reproduce:

Remove install and ~/Library items on arm Mac.
Install VS Code on arm Mac.
Verify that syntax highlighting and themes work normally.
Turn on Settings Sync.
Note missing syntax highlighting, dark text on dark background (in dark mode) in editor, terminal, and logs. In light mode, it's dark text on a light background, but still no syntax highlighting in the editor or color in the terminal (in text only; colors in my prompt symbols still work).

This started sometime in the last month or so, and it has persisted through a couple of updates. My settings aren't all that elaborate: auto-match system theme with Light+/Dark+), Source Code Pro and some turned up font sizes, python pointed to a conda environment.
I tried no extensions (no effect, either bisect or disable all) and a fresh setup (works until settings sync is turned on). At all times, the Intel Mac side of the sync works as expected.
In case it matters (e.g., something like an HDR screen bug in the past), the Intel Mac is a 2020 iMac and the arm Mac is a 14-inch MBP.
Any ideas?

Can you add a screenshot?
This could be related to the Source Code Pro font. Check our https://github.com/microsoft/vscode/issues/110640

That fixed it, thanks! It looked just like the first image in #100840.
With VS Code closed, I ran:
brew uninstall --cask font-source-code-pro
brew install --cask font-source-code-pro

It did pull the Google Fonts version (a recipe change in the home-brew cask a few days after I installed it initially), and it seems fine now.


Error when make base

Hey!
I encountered following error after make base.

apt-get install -y lsb-release > /dev/null 2>&1
Error executing command, exiting
The command '/bin/sh -c apt-get update    && apt-get -y install gcc cmake autoconf libtool pkg-config libmnl-dev libyaml-dev apt-transport-https ca-certificates    && curl -sL https://deb.nodesource.com/setup_10.x | bash -     && curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -    && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list     && apt-get update     && apt-get install -y nodejs yarn' returned a non-zero code: 1
Makefile:7: recipe for target 'base' failed
make: *** [base] Error 1

For some reason curl -sL https://deb.nodesource.com/setup_10.x | bash - causes this problem since this error is gone without includingcurl -sL https://deb.nodesource.com/setup_10.x | bash -.
Any idea about fixing this?
Thanks!

problem solved by executing "make base" in the 5.4.0-67-generic kernel

And also added apt-get clean. Not sure which is effective

Update. The original repo works perfectly fine on a local PC. The error I got is on a remote virtual machine. So, try to use another machine if encountering any error during the installation.


C2 file appears to never correlate to the log file or .scm file

Version
20220909
Describe the bug
(Note - this is a long description, so if you want to jump to the actual issue, go to where it says "Bug description starts here" in bold)
There are a number of weird discrepancies when you try to correlate the .c2 file, the .scm, and the C2 log file together that doesn't seem to make any sense. The c2 error log file that DiscImageCreator generates indicates offsets (for individual bits in the .c2 file for that given LBA, presumably) but those offsets never actually correlate to the location of the actual error bits in the .c2 file. Likewise, the error bits in the .c2 file never seem to correlate to the .scm file either.
I'm not exactly sure why this is, but it might have something to do with the possibility that some Plextor DVD drives have different C2 offsets which are not sector aligned (http://forum.redump.org/post/99760/#p99760). There might also be something else at play here that I'm unsure of.
Although, maybe there's something I'm missing as there's not a lot of documentation on the .c2 file or its logs, so my understanding of this issue is based on what I think I understand of how it works. Please forgive me if I'm mistaken.
This is how I expect the .c2 file and C2 log file to work:
According to the documentation, the C2 file contains a series of bytes where 1 = bit inside the .c2 file correlates to 1 byte in the .scm file. If any bit inside the .c2 file is set to 1, this means that the equivalent byte in the .scm file is marked as "erroneous". For instance, if the byte at $810 is set to $80 (1000 0000), then that means that $810 * 8 (bytes) = $4080 in the .scm file. Therefore, $4080 is the location of the equivalent erroneous byte in the .scm file for the bit at $810 in the .c2 file. However, the location doesn't point to the right spot it seems. (See example below)
The C2 log is a different story. When errors are detected by DiscImageCreator, the LBA of the location of the error is displayed (both in decimal and hexadecimal, for some reason), followed by a list of what I assume to be the offsets to the individual bits in the .c2 file that make up the erroneous bytes for that specific LBA, in hexadecimal. For instance, if DiscImageCreator detects an error at ofs $290 for LBA 6, I should be able to find the erroneous byte in the .scm file by finding the physical address of the LBA (6*2352=$D3EC), then multiply the offset of the bit offset to get the offset of the byte itself ($290 * 8 = $1480), then add the offset to the physical address of LBA 6 to find the location of the affected byte in the .scm file ($D3EC + $1480 = $E86C). DiscImageCreator will then print the number of bit-errors it finds in decimal (with a max value of 2532 bits, for the entire sector).
However, neither the .c2 file nor the C2 log file seem to be accurate at all. The issues can be made apparent by following this example (see the included files to follow along):
Bug description starts here
Inside the .7z, there are two Dumps made from the same CD-R, Dump 5 and Dump 7. Both were dumped using a drive that has the ASUS BW-16D1HT 3.02 firmware.
Consider the .c2 file in Dump 5:
$6E4 is the start of LBA 6, we know that the c2 is 294 bytes per sector ($126) - so $126 * 6 gives us $6E4
$732 is the location of the first non zero byte, indicating an error on the bits that are set to 1. In this case, the byte at $732 is set to $80 (1000 0000), therefore, the most significant bit (MSB) indicates an erroneous bit with "ofs" (offset) $4E.
However, the bug becomes apparent when you look at the C2 log file. According to the log file, it says that the first damaged byte for LBA 6 is located at bit $290 (I assume?). To translate this to the address of the byte inside the .c2 file, if you divide $290 / 8, you get $52, which is 4 bytes away from the original calculated offset - $4E. Is this right or wrong?
Accordng to superg, the author of redumper, the ASUS ASUS BW-16D1HT has a C2 offset of 0x0 (no offset), but a drive offset of +6. Could this be an indicator some implied offset?
https://github.com/superg/redumper/blob/f98fa8d4c9201ec3fc23d02c21ff5dd82c5738e2/drive.cc#L107
I included Dump 7 as well, as LBA 6 in that dump is free from any errors.
Screenshots
N/A
Disc title
Any CD title that will generate C2 errors that can't be corrected.
Log file
(Note: I had to upload the .scm file because it might be the only way to help illustrate the issue)
https://www.mediafire.com/file/nviicq1sg0ftg1e/DIC+C2+Issue.7z/file

Both were dumped using a drive that has the ASUS BW-16D1HT 3.02 firmware.

Is there a same problem when plextor is used?

Hey Sarami, thanks for getting back.
There definitely seems to a problem even when a Plextor is used as well. See attached for a dump in a Plextor PX-W4012TA
https://www.mediafire.com/file/51yfe9nelcaykuz/Dump+8.7z/file
In comparison to Dump 8, LBA 7 has an error on ofs 92f which should be affecting the last byte in sector 7. This offset is not affected in Dump 7. However, when comparing the two .scms and .c2 files together, assuming my math is right...
7*2352 = $4050
$4050 + $92F = $497F
Therefore, the corrupt byte that ofs 92f from the C2 file correlates to for LBA 7 is at $497F. However...
(Dump 8 vs Dump 7)

There are no byte differences, despite there being a bad byte in Dump 8 at ofs 92f in lba 7 that isn't present in Dump 7 at the same offset for the same LBA.
For the .c2 files...
LBA 7's location in the .c2 file is determined as:
7*$126=$80A
Since each LBA in the .c2 file is represented with $126 bytes, ofs 92f should be located at the last byte for this lba, which should be at $92F in the .c2 file. However...

In the picture above, the highlighted byte ($92F) is 00, indicating no error for both dumps. Even most of the bytes around this offset have no error. There should be a non-zero byte at this address for Dump 8, and a zero byte in Dump 7 at this address too. But both are set to $00, indicating no issues, which contradicts the .c2 log.
Here's another set of scm only dumps where one is dumped with an ASUS drive and another with a W4012TA. I haven't had time to look at it, but I'm sure the same issue occurs there.
https://www.mediafire.com/file/f21pvppxec7gf34/[BAD+DUMP]+2-12-98+Version+3.1+v+Preview+v+Sony+v+Alpha+VR+Baseball+99.7z/file

changed: .c2 file is not shifted by the combined offset.
DiscImageCreator_test.zip

Hey Sarami, this looks fixed! I dumped some discs with my PX-760a and things look okay so far. It even fixed a bug I forgot to mention where the last sector's c2 error data was missing from the .c2 file. I'll do some more testing and see if anything comes up with other drives. Maybe this is good to commit?
There remains one issue, though. Although the log is correlating to the c2 file now, the log file and .c2 file don't seem to correlate to the .scm. For example:
https://www.mediafire.com/file/xdcncwa2wtu3wz8/DIC+C2+Issue+-+Example+2.7z/file
In dump 1 & 2 of this Shaolin disc, LBA 191624 has errors in both dumps. Both dumps were done using a Plextor PX-W4012TA using a UGREEN adapter. However, the affected offsets in both dumps are different:
Dump 1:
                 ofs: 318, 345, 34c, 34e, 479, 47b, 482, 4a4, 4b5, 4b6, 60b, 618, 619, 61b, 63f, 644, 64e, 64f, 771, 778, 77a, 780, 7a6, 7a7, 7ac, 7af, 7b5,
 LBA[191624, 0x2ec88] Detected C2 error 27 bit

Dump 2:
                 ofs: 470, 472, 47b, 482, 4a4, 4ae, 4af, 4b6, 518, 51b, 520, 54d, 54e, 55d, 55e, 5f2, 5f8, 5fa, 601, 626, 634, 635, 636, 789, 791, 792, 79b, 7bc, 7be, 7c5, 891, 893, 899, 8c5, 8ce, 8cf, 8d5, 8d6,
 LBA[191624, 0x2ec88] Detected C2 error 38 bit

When the .scm from both dumps are compared side by side with Beyond Compare, the differences become clear (Dump 1 left, Dump 2 right):

Here are what the .c2 files look like compared side by side for this LBA (191624*$126=$35BA430, Dump 1 left Dump 2 right):

As you can see in the C2 image, there is an error an error at $35BA493 for this LBA in Dump 1 with a value of $80 (1000 0000). The bit set to 1 in this byte for this LBA can be found at ofs $318, which confirms that the log and the .c2 file both correlate to each other (with the version you provided fixes with). Note, ofs $318 is not corrupt in Dump 2, and is completely fine.
However, the problem becomes apparent when you use the location of ofs $318 to find the equivalent affected byte in the .scm file. In theory, because 1 bit in the c2 file = 1 byte in the .scm file, since the ofs in the c2 log are for the bits in the c2 file, simply adding the offsets to the physical address at the start of a given LBA will give you the exact physical address to the affected erroneous byte in the .scm file. So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180), if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498. However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. ** I think this is a bug, but I could be wrong. Can you look into/explain this?
Aside from the issue above with the .c2 offsets and .scm not correlating with each other, there's one more bug I think I found:
Sometimes DIC will return this message along with the offsets which looks very strange:
 LBA[223042, 0x36742] Detected C2 error "00 F0 F0 F0 00 00 00 0F 0F 0F 00"
This error can't be fixed by plextor drive.  Then it'll print the other affected offsets that I guess can be fixed. Then for the same LBA, it tell you the error size. However, what seems to be happening is DIC will print the byte values for the errors in the .c2 file that can't be fixed, and doesn't list them as "ofs" in the list of erroneous bit offsets. However, the C2 file will have the "00 F0 F0 F0 00 00 00 0F 0F 0F 00" sequence in the .c2 file anyway. It just doesn't seem to be logged properly. Is this a bug or intentional? I noticed this similar error popping up once in a while for some reason.

Here's the dump this error came from if you want to take a look:
https://www.mediafire.com/file/gsqppceyvv7z6vi/DIC+C2+Issue+-+Detected+C2+error+bug.7z/file
Please let me know if you have any questions. Always willing to help out. :)

I wonder if this makes all previously made dumps with c2 files corrupt?

So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180),

It's true.

if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498.

It's not so. Because the ofs of the c2 error log contains the combined offset, while .scm is already shifted by the combined offset. In other words, The offset of the .scm is 0.

However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. **

According to your log, the combined offset is 404 (194h). Then 318h - 194h = 184h

I wonder if this makes all previously made dumps with c2 files corrupt?

The .c2 files I think were in this case. But the actual .scm dumps have always been fine. DIC doesn't seem to use the .c2 files for anything at the moment, so it's mostly for information about the dump at this point I think...

So in this case, since LBA 191624 begins at $1ADD2180 in the .scm (because 191624*2352=$1ADD2180),

It's true.

if you add $318 to it, the affected byte for ofs $318 should be located at $1ADD2498.

It's not so. Because the ofs of the c2 error log contains the combined offset, while .scm is already shifted by the combined offset. In other words, The offset of the .scm is 0.

However, this is not correct. Look at the image of the .scm images closely, and you'll see that the corrupt byte is actually located at $1ADD2304. In other words, **the ofs should be $184, NOT $318. **

According to your log, the combined offset is 404 (194h). Then 318h - 194h = 184h

Thanks for the reply! The combined offset makes sense. Once the combined offset was determined, I was able to get the exact address for all the other errors just by applying it to the returned ofs for the c2. This also helps explain why sometimes you have return ofs of "0, 1, 2, 3, etc), but there aren't any bytes affected at those offsets within the current LBA. For instance, if you look at LBA 191680, there's an error at ofs 172. However, there is no erroneous byte at 191680 * 2352 + $172, but there is an erroneous byte at 191680 * 2352 + ($172 - $194), which actually puts you on an erroneous byte in the previous sector at $1ADF23DE.
So now my next question is, does the combined offset value vary from drive to drive then? I think I remember determining the offset for another dump done by another drive, and got a different combined offset but never bothered to check if it could be used to find the locations of everything else. Can DIC determine the combined offset by itself? If not, would it be beneficial to start a database of combined offsets to help DIC provide offsets/address for each c2 error in the logs? If so, I can help contribute as I have many Plextor drives to work with.
My other question which I just want to reaffirm is that I noticed that sometimes the erroneous bytes in the .scm sometimes have corrupt bytes in locations immediately around the affected byte. Is this because sometimes error bits can occur across more than one ofs, but the drive only reports it affecting one ofs sometimes? Like take for example 191680 * 2352 + ($172 - $194) = 1ADF23DE. There's an error at 1ADF23DE, but there's also an affected byte right next to it at 1ADF23DF which its offset isn't recorded by the c2 error log.
Thanks once again.

So now my next question

Combined offset consists of drive offset and write offset of the disc. Drive offset is stored in driveOffset.txt (Original data is accuraterip.com). Write offset is different by discs (see redump.org database).

My other question

I'd understand it, but I don't know the reason. For this reason, I've coded val2 ... val4 in /c2 as app can reread all sector when c2 error reports only 1 bit.
        /c2     Continue reading CD to recover C2 error existing sector
                        val1    value to reread (default: 4000)
                        val2    0: reread sector c2 error is reported (default)
                                1: reread all (or from first to last) sector
                        val3    first LBA to reread (default: 0)
                        val4    last LBA to reread (default: end-of-sector)
                                val3, 4 is used when val2 is 1

As you know, superg says about another c2 offset of plextor DVD model http://forum.redump.org/post/99760/#p99760 , can you verify it if you have plextor DVD model?

Thanks for getting back. :)
Don't have time at the moment to look at these in depth, but if you're curious:
https://www.mediafire.com/file/619yw9jklqovabv/DIC+-+Drive+C2+Offset+tests.7z/file
So what I did was I dumped a disc I had that has consistent issues with a very small amount of sectors, mostly near the very end, twice in three separate drives - a PX-760A (combined offset 464, C2 offset 295), a PX-W4012TA (combined offset 736, C2 offset 294), and a ASUS BW-16D1HT 3.02 (combined offset 368, C2 offset is 0).
Let me know if this helps with figuring out any further issues. If you're still not seeing something, let me know and I'll take a closer look when I have the time.
Ideally, I would like some sort of c2 log or .c2 file (vairant?) that's offset to the .scm itself. That is, taking into consideration both the combined offset and possible c2 offsets too). This way, the C2 log/file is as 1:1 with the errors in the .scm as close as possible.
Hope this helps.

Hey @saramibreak , I'm done with my research on DVD Plextors.
So keep in mind, ideally it'd be great to have a version of the .c2 file and the log file with offsets and addresses that correlate directly to the .scm file as much as possible. That's the goal in my opinion.
So in a nutshell, I was able to confirm what superg has stated in that thread about DVD Plextors having an additional offset when trying to correlate the C2 ofs to the SCM file. Before your change (which I see you've merged), I think DIC was adding the combined offset already to the error bit locations in the .c2 file. This can work for most of the 'good' CD-ROM based Plextors, but DVD Plextors need an additional offset applied which I'm not sure where it comes from. The only thing that can be done is to compare a bad dump's scm file from a particular drive to a good dump that can be confirmed good.
So what I did was took a disc that has a confirmed, good entry in redump.org. I dumped this disc three times in three separate drives to make sure I had a good dump on hand. Then, I purposely introduced a defect to the disc by putting a small piece of tape on the surface of the disc. This way, even though the C2 errors are still inconsistent between reads and different drives, I know that I can expect errors within a general area in the dump. Then I dumped this "defective" disc in as many relevent drives as I could, and came up with the following data:

So as a recap, this is what I'm doing. First, I determine the combined offset from the disc log ("Combined Offset"). Then, I take the reported c2 ofs ("First Reported C2 Offset") and affected lba ("First LBA Error (Numerical)") for the first C2 error and plug it into the sheet, calculating the lba into a physical address ("First LBA Error (Physical Address)"). Then I took the .scm file from the bad dump from the respective drive, and compared it to the good dump of the same disc using Beyond Compare. I went to the very first byte difference in the file and input that into the sheet as well ("First Address of Difference (Error) in SCM"). With this information set in the sheet, I calculated the following:
"Actual C2 Offset For First Error" - This is the actual offset (from the beginning of the reported sector) to the first actual byte difference in the .scm, for that given sector. This is calculated by "First Address of Difference (Error) in SCM" minus "First LBA Error (Physical Address)".
"Correction" - This is the calculated offset to the affected byte in the affected sector if you only took the combined offset into consideration, this way you can see if there's a difference in the actual C2 offset as reported by the SCM file. If a drive requires no additional offset corrections, the value under "Correction" and the value under "Actual C2 Offset For First Error" will be exactly the same. This is calculated by "First Reported C2 Offset" minus "Combined Offset".
"Additional Offset" - This is what you're after. Additional Offset is the necessary value that needs to be added to the combined offset in order for C2 ofs to point to locations in the SCM file directly. This is what you need to make DVD Plextors work with the C2 offset file. This is calculated by taking the difference between "Actual C2 Offset For First Error" and "Correction". If the Additional Offset is 0 or 1, the drive only needs the combined offset to be added to the C2 ofs in order for it correlate to the SCM file. If Additional Offset is 8 or 9, the drive needs the combined offset + 8 in order for it to correlate to the .scm file.
The one thing you might have noticed is that sometimes a drive can report either 0 or 1, or 8 or 9 for it's "Additional Offset". With C2 there is always going to be some kind of margin of error with whatever the drive actually reports for some reason. But most of the time, even when it appears to be off by 1 byte, the additional offset is still either 0 or 8 for certain drives. That's just the nature of C2.
Finally, after all is said and done, I can confirm these additional offset values for the following drives:
- ASUS 16D1HT - 0
- PLEXTOR PREMIUM - 0
**- PLEXTOR PREMIUM 2 ** - 0
- PLEXTOR PX-708A - 0
- PLEXTOR PX-712A - 8
- PLEXTOR PX-716A - 8
- PLEXTOR PX-755A - 8
- PLEXTOR PX-760A - 8
- PLEXTOR PX-W4012TA - 0
- PLEXTOR PX-W4012TS - 0
- PLEXTOR PX-W4824TA - 0
- PLEXTOR PX-W5224A - 0
What I propose:
So this is what I think DIC should do with this information.
DIC should output versions of the .c2 and log files (_corrected.c2 and c2Error_corrected.txt, or something similar) that are corrected to correlate with the .scm as close as possible. Corrected .c2 and log files can only be generated for drives which have confirmed "c2 offsets" (from the table/list above). So for instance, if I dumped something with a Plextor Premium, it'll provide me the corrected .c2 and log files, as well as the original c2/log files without the combined offset. If I dumped something in a Plextor PX-40TSi, which isn't normally supported by DIC, since there is no record of it's C2 offset, it will only output the original c2/log files without the combined offset added.
Unfortunately, since the c2 offset information isn't readily available in a database like accuraterip, we need to calculate it and curate our own database within DIC itself. So DIC would have to include the additional offsets from the table/list above into the program itself in the event the equivalent drives are used.
Hope this helps, let me know if you have any questions or want me to test or look into anything else. :)

Uploaded. (Not test)
DiscImageCreator_test.zip
"/s 2" is needed if 712A, 716A, 755A and 760A read the last byte of the c2.

Hey Sarami, did some testing with this version.
The c2 log does still correlate to the .c2 file. However, the c2 log for the DVD plextors seems broken. The "Detected C2 error # bit" line doesn't correctly total the amount of bits found. This only affects the DVD plextors, CD-ROM based plextors are fine (see mediafire link). I'm not sure why that is, but it makes most of the total bit sizes 0.
             ofs: 632, 65e, 65f, 666, 667, 6ea, 716, 717, 71e, 71f, 7a2, 7d6, 7d7, 7e4, 7e5, 870, 89c, 89d, 8a4, 8a5, 928,

LBA[015355, 0x03bfb] Detected C2 error 0 bit
ofs: 24, 25, 2c, 2d, b0, e4, e5,
LBA[015356, 0x03bfc] Detected C2 error 0 bit
ofs: 4a2, 4a3, 4aa, 4ab, 4ba, 4bb, 4c3, 4c8, 4d2, 4d3, 4db, 4e0, 4e6, 4fe, 502, 503, 50b, 510, 516, 51a, 51b, 528, 529, 547, 55f, 562, 563, 570, 571, 57b, 580, 588, 589, 593, 598, 59e, 5a0, 5a1, 5b6, 5c3, 5c8, 5ce, 5d0, 5d1, 5e0, 5e1, 5e8, 5e9, 5f8, 5f9, 5ff, 600, 601, 617, 628, 629, 62f, 630, 631, 638, 640, 641, 649, 650, 656, 658, 659, 661, 66e, 680, 686, 688, 689, 691, 698, 699, 6a0, 6a1, 6b0, 6b1, 6b7, 6b8, 6b9, 6cf, 6e0, 6e1, 6e7, 6e8, 6e9, 724,
LBA[016102, 0x03ee6] Detected C2 error 0 bit
ofs: 1d6, 1d7, 1de, 1df, 1e6, 1ee, 1ef, 1f6, 1f7, 1fe, 24e, 24f, 257, 25c, 25f, 296, 297, 29e, 2a4, 2a5, 2ae, 2af, 2b6, 2bc, 2bd, 30f, 314, 317, 31c, 31d, 356, 35c, 35d, 364, 365, 36e, 374, 375, 37c, 37d, 3cc, 3cf, 3d4, 3d5, 3dd, 414, 415, 41c, 41d, 424, 42c, 42d, 434, 435, 43c, 48c, 48d, 495, 49d, 4d4, 4d5, 4dc, 4ec, 4ed, 4f4, 594, 5ac, 5d2, 5f5, 632, 633, 64a, 64b, 6ea, 6eb, 6f2, 6f3, 702, 703, 70a, 70b, 7a2, 7a3, 7aa, 7ab, 7b2, 7ba, 7bb, 7c2, 7c3, 7ca, 802, 803, 80b, 810, 813, 81a, 81b, 823, 828, 82b, 862, 863, 86a, 870, 871, 87a, 87b, 882, 888, 889, 8c3, 8c8, 8cb, 8d0, 8d1, 922, 928, 929,
ofs: 0, 1,
LBA[016329, 0x03fc9] Detected C2 error 2 bit

It does seem that the .c2 file includes the missing sector now. Ideally it would be great if DIC would output 'corrected' .c2/log files that reflect the locations in the scm. That means a version of the .c2 with combined offset, additional offset (if present for certain drives), and reported c2 ofs.
Here are the dumps from this version (scm only):
https://www.mediafire.com/file/2stinon5p4ctmqu/c2_test_3.7z/file
c2_offset_corrections.xlsx

it makes most of the total bit sizes 0.

Fixed
DiscImageCreator_test.zip

Ideally it would be great if DIC would output 'corrected' .c2/log files that reflect the locations in the scm. That means a version of the .c2 with combined offset, additional offset (if present for certain drives), and reported c2 ofs.

It's ideal but It takes time and effort for "bit shifting".

it makes most of the total bit sizes 0.

Fixed DiscImageCreator_test.zip

Ideally it would be great if DIC would output 'corrected' .c2/log files that reflect the locations in the scm. That means a version of the .c2 with combined offset, additional offset (if present for certain drives), and reported c2 ofs.

It's ideal but It takes time and effort for "bit shifting".

Confirmed, has been fixed. Everything looks good now.
Do you need to use /s 2 every time in order to get the last byte for the DVD Plextors? Is there a way to have it on by default for these drives?

Is there a way to have it on by default for these drives?

Added.
DiscImageCreator_test.zip

Is there a way to have it on by default for these drives?

Added. DiscImageCreator_test.zip

Works great, no issues. :)
Unless you want to try some form of the corrected .c2/log, even if it wont be 100% exact due to bit shifting, I guess that's it for the issue?

[LBA, LBA translation to SCM address in hex (LBA * 2352), LBA in C2 file (LBA * 294)

Added.
DiscImageCreator_test.zip

[LBA, LBA translation to SCM address in hex (LBA * 2352), LBA in C2 file (LBA * 294)

Added. DiscImageCreator_test.zip

Works! Thank you for adding it. :)
The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.
H:\Tools\DiscImageCreator>DiscImageCreator.exe cd E MEGAMAN-11-12-test.bin 12 /c2 4096 /q /nl /am /s 1 AppVersion         32 bit, AnsiBuild, 20221112T211241 /c2 val2 was omitted. set [0] CurrentDirectory         H:\Tools\DiscImageCreator WorkingPath          Argument: MEGAMAN-11-12-test.bin          FullPath: H:\Tools\DiscImageCreator\MEGAMAN-11-12-test.bin             Drive: H:         Directory: \Tools\DiscImageCreator\          Filename: MEGAMAN-11-12-test         Extension: .bin StartTime: 2022-11-12T10:20:48-0500 Set the drive speed: 2116KB/sec DiskSize of [H:\Tools\DiscImageCreator]         Total:<PHONE_NUMBER>224 bytes          Used:<PHONE_NUMBER>064 bytes         ---------------------------         Space:<PHONE_NUMBER>0 bytes          => There is enough disk space for dumping [INFO] This drive has 295 offset in the c2. Changed to /s 2.

The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.

If /c2 is not set, /s 1 or /s 0 for DVD Plextors are enabled.

The only issue left is that DIC still uses /s 2 even if you manually enter /s 1 or /s 0 for DVD Plextors. User preference should take precedence over the default setting, imo.

If /c2 is not set, /s 1 or /s 0 for DVD Plextors are enabled.

Ah okay, no problem.
Feel free to merge your changes and close the issue if you don't have any more changes in the pipeline.

Hey @saramibreak, I think this change might break GD-ROM mode. If i run the latest code for GD discs, I get 4 bit C2 errors on every sector:
                ofs: 0, 3, 4,
 LBA[044999, 0x0afc7] Detected C2 error 3 bit
                 ofs: 5, 6,
 LBA[045000, 0x0afc8] Detected C2 error 2 bit
                 ofs: 2, 3, 4, 7,
 LBA[045001, 0x0afc9] Detected C2 error 4 bit
                 ofs: 1, 5, 6,
 LBA[045002, 0x0afca] Detected C2 error 3 bit
                 ofs: 0, 1, 5, 7,
 LBA[045003, 0x0afcb] Detected C2 error 4 bit
                 ofs: 1, 3,
 LBA[045004, 0x0afcc] Detected C2 error 2 bit
                 ofs: 1, 4, 7,
 LBA[045005, 0x0afcd] Detected C2 error 3 bit
                 ofs: 0, 3, 4, 5, 6,
 LBA[045006, 0x0afce] Detected C2 error 5 bit
                 ofs: 0, 5, 6, 7,
 LBA[045007, 0x0afcf] Detected C2 error 4 bit
                 ofs: 0, 5, 6, 7,
 LBA[045008, 0x0afd0] Detected C2 error 4 bit
                 ofs: 0, 5, 6, 7,
 LBA[045009, 0x0afd1] Detected C2 error 4 bit
                 ofs: 0, 1, 4, 5, 6, 7,

All logs are needed when bugs is reported.

Here you go, keep in mind i stopped the dump a few seconds in
test4_volDesc.txt
test4_20221112T211241.txt
test4_c2Error.txt
test4_disc.txt
test4_drive.txt
test4_mainError.txt
test4_mainInfo.txt
test4_subError.txt
test4_subInfo.txt
test4_subReadable.txt

Uploaded.
DiscImageCreator_test.zip

No change
test5_disc.txt
test5_drive.txt
test5_mainError.txt
test5_mainInfo.txt
test5_subError.txt
test5_subInfo.txt
test5_subReadable.txt
test5_volDesc.txt
test5_20221115T135431.txt
test5_c2Error.txt

More changed.
DiscImageCreator_test.zip

Better now. I'm not able to check a GD disc that has actual C2 errors yet but this looks good to me.

I forgot to mention, not sure if this is a bug or not, but I noticed that sometimes when there are c2 bit errors near the end of the current LBA that sometimes some additional bits are printed, like this:
8f5, 8f6, 8f7, 8f8, 8f9, 8fa, 8fb, 8fc, 8fd, 8fe, 8ff, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 90a, 90b, 90c, 90d, 90e, 90f, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 91a, 91b, 91c, 91d, 91e, 91f, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 92a, 92b, 92c, 92d, 92e, 92f,
ofs: 0, 1, 2, 3, 4, 5, 6, 7,
LBA[207067], LBA translation to SCM address in hex[0x1d075c10], LBA in C2 file[0x3a0eb82] Detected C2 error 1632 bit
This only affects DVD plextors it seems, but I'm not sure if this is intentional. I assume this is because its reading error bits that go into the next sector, but they're classified as being part of the current sector being read.
See attached for logs.
https://www.mediafire.com/file/9k6y03g325l0zro/c2+-+bug+(not+sure).7z/file

If ofs is 7 for plxector dvd drive, it's 92f for plxector cd drive.


Client-cli validate-path does not match ResponseBankingAccountsBalanceList unless optional amortisedLimit field is included.

Description
The validate-path command in client-cli produces the error 1. No matching model found. Specifying a target model will produce more informative errors for payloads containing a ResponseBankingAccountsBalanceList object wherever the optional amortisedLimit is not present. This is verifiable by removing the amortisedLimit field from the sample payload for Get Bulk Balances  in the HTML documentation.

I cannot reproduce the issue with latest code in dev branch. Since we are releasing dev branch code soon, this issue is deemed to be fixed.


feature: lazydocker

Did you check the docs?

[X] I have read all the LazyVim docs

Is your feature request related to a problem? Please describe.
I love that lazygit is included but would also like to see lazydocker as well which was made by the same developer:
https://github.com/jesseduffield/lazydocker
Describe the solution you'd like
lazydocker as an option in the lazyextras.
Describe alternatives you've considered
Installing and managing the plugin myself.
Additional context
No response

lazydocker doesn't exist as a tool in Mason to install. Just like lazygit the user would have to install the plugin himself. LazyVim doesn't install lazygit, it just makes a keymap for if lazygit is found in the user's system. So, just install lazydocker in your OS and then just do a mapping like
if vim.fn.executable("lazydocker") == 1 then
  vim.keymap.set("n", "<leader>gd", function()
    LazyVim.terminal("lazydocker", { esc_esc = false, ctrl_hjkl = false })
  end,
    {desc = "Lazydocker"})
end

and I believe it should work.


CSS min() and max() throw errors for Libsass

Libsass is throwing an error when processing GOV.UK Frontend, as Libsass doesn't support CSS min() and max() which is used in the width container component.
Specifically, Libsass doesn't like calc() being used in max() as Libsass tries to process it as a Sass function and can't because calc() is CSS function for use in the browser. I've investigated it in an issue for finder frontend if you'd like more information.
Dart Sass and (ironically) Ruby Sass does support CSS min/max - the things that's stopping these being used is that there doesn't seem to be any Rails friendly way of using Dart Sass (without refactoring vast swathes of code so Webpacker can be used) and Ruby Sass is deprecated.
Because there doesn't seem to be much movement in getting Libsass to have support for CSS min/max, would it be possible to place the notch support behind a flag so it can be turned off? I think the default should be to keep it on, but to have the ability to exclude it with a flag when needed.

Hey @injms,
Is there an error message you can share?
I don't think we want to turn off parts of GOV.UK Frontend based on the Sass compiler used without exploring other options.
If you could share a minimal reproduction of this issue there might be another way to solve this.
Thanks for raising :)

Something to note: we use node-sass to build GOV.UK Frontend which under the hood uses libsass.

Sorry, I should've added the full error message - here it is:
Failure/Error: <!--[if gt IE 8]><!--><%= stylesheet_link_tag "application" %><!--<![endif]-->

ActionView::Template::Error:
  Error: "calc(0px)" is not a number for `max'
          on line 1169 of stdin, in function `max`
          from line 1169 of stdin
  >> @supports (margin: max(calc(0px))) {

      -------------------^
# stdin:1169
# ./app/views/layouts/finder_layout.html.erb:5:in `_app_views_layouts_finder_layout_html_erb___4327627882324680024_70165332331320'
# ./spec/controllers/finders_controller_spec.rb:62:in `block (4 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# SassC::SyntaxError:
#   Error: "calc(0px)" is not a number for `max'
#           on line 1169 of stdin, in function `max`
#           from line 1169 of stdin
#   >> @supports (margin: max(calc(0px))) {
#
#      -------------------^
#   stdin:1169

I'll sketch up a minimal reproduction too and give a shout when I'm done.
It's a really odd one because Libsass says it doesn't support CSS min/max, but it works with GOV.UK Frontend that does use min/max, yet still throws this error. 🤪
The only difference I can see between the two is that node-sass uses Libsass 3.5.4 and SassC Ruby / SassC Rails uses 3.5.2 - but that shouldn't affect this as there's no mention of min/max for these versions in the Libsass release notes.
As a workaround, I don't think we should turn it off by default. An option to be able to turn it off would be gratefully received, as then a deprecated dependency could be removed - but it's completely a nice to have as things are working at the moment and it's not a bug with GOV.UK Frontend.

Hi @injms,
It sounds like your Sass processor is being run twice, or it's being run on already-processed CSS rather than the original Sass source?
I wrote the min/max code you've linked to, but had to surround it in unquote() so it's treated as plain text, rather than the native Sass min/max.
margin: unquote("max(calc(0px))")

Yep, the removing of the unquote() now gives me the same error when using ruby-sass. Now to work out why it's being stripped out. I'll close this issue as it's not one that needs changes to GOV.UK Frontend.
Thanks @colinrotherham @nickcolley 😃

For future reference to anyone who stumbles across this, a solution was found in SassC Rails issue 93.
Relevant bit:

So by adding this to my config/environments/test.rb the problems went away:

# Set a css_compressor so sassc-rails does not overwrite the compressor when running the tests
config.assets.css_compressor = nil

Thanks for sharing Ian :)

This seems to come up a lot for Ruby users, I wonder if we can adjust the CSS with a workaround to prevent this issue.
I wonder if we changed margin: unquote("max(calc(0px))") to margin: unquote("max(0)") if this would still work?
@colinrotherham do you know why we used the calc method in this support statement?

libsass is planning to add CSS min() and max() support with their next release - it's in the milestone for 3.7.

@injms Ah that's great.
So it sounds like the new Sass min/max feature will cleverly use the native CSS methods, or fall back to the standard Sass ones: https://sass-lang.com/documentation/syntax/special-functions#min-and-max
So one day we can then use native CSS min()/max() in Sass without unquote() 🎉
@nickcolley Sadly it would break the @supports test. To work with Safari on iOS 11+ the units (px) need to be specified otherwise I presume max() evaluates to nothing and doesn't run.
So this would work for Safari:
margin: unquote("max(0px)")

But, we added calc() into the @supports test because it's used in the "display cutout" media query itself, so it's the responsible thing to test for it before we attempt to use it.

Another method I've seen to avoid the clash between CSS and Sass - but not tested in this case - is that capitalising makes Sass ignore the function.
(Since CSS doesn't care about case you could capitalise any or all of the letters.)
So
.selector {
  margin-top: Max(20px, 400px);
  margin-left: max(10px, 500px);
}

compiles to
.selector {
  margin-top: Max(20px, 400px);
  margin-left: 500px;
}


Missing photos

The photos are messed up on https://crimethinc.com/2015/12/28/report-to-change-everything-us-tour
...I can't even figure out where they are to fix the markdown coding—the URLs are broken.

Fixed


add windows x86 support

#11 fix

#11 fix

hi , i am interested in the method of x86_32 bindings for mysql c api. could you tell me the differences between the rs of x86_64 and x86_32?

Closed by #40


Pair map functions

fn map_first(Pair(a, b), fn(a) -> c) -> Pair(c, b)

fn map_second(Pair(a, b), fn(b) -> c) -> Pair(a, c)

Instead of making lots of special case functions like this, it would probably be better to add in built-in Lens support to the language, then functions like these as well as any others for any size tuples, records, etc... would then come 'for free'.

For sure, more powerful constructs will come later :)

https://github.com/lpil/gleam/pull/267


Rewrite Create and Approve Tests for the New Registry with use of BDD

Description:
After moving tests to the New Registry repo and adapting them to the new Test Sandbox environment I will rewrite them with use of Gherkin, then use Cucumber to project them into new .cy.js files and then fill the projection with code.

Implemented in terms of these two tickets:
https://app.zenhub.com/workspaces/app-dev-team-646fdb4400ed8c0021aceeb4/issues/gh/bcgov/platform-services-registry/3374
https://app.zenhub.com/workspaces/app-dev-team-646fdb4400ed8c0021aceeb4/issues/gh/bcgov/platform-services-registry/2399


Rust support?

Any plans for Rust support?

Hi @jplock,
It's on our roadmap, but no date has been decided right now.
Could you tell us more about your use case for Rust support?

I’m porting a Python Lambda extension that used the legacy encryption SDK to Rust and wanted to use the latest release.


Upgrage Node.js v6

The test fails because you use the default parameter(support in Node.js v6)

@gr2m you should update Npm and Github token for build success.
And I forgot update Node.js version in package.json :D


Initial checkin apps github action CI workflow

Github action CI workflow steps as below:

Checkout apps repo with pull request
Checkout nuttx repo since tools/checkpatch.sh must be used
Do git commands to get commits in PR and then do checkpatch.sh
Checkout testing repo since cibuild.sh must be used later
Install build essential tools
Call testing/cibuild.sh to do check build

Signed-off-by: liuhaitao<EMAIL_ADDRESS>Not intended to be merged right now. Still need align to check testlist update.

Does this need an Apache license header?
I know nothing about this and do not feel qualified to do the merge.  I was add @btashton is a reviewer.

Let's keep the conversation in the other ticket for now.

Can we close this now?

Can we close this now?

No, Haitao is preparing the final patch.

It's better close it to ease testing in my fork. I'll reopen the PR ASAP.


KAFKA-14683 Migrate WorkerSinkTaskTest to Mockito (2/3)

Second batch of WorkerSinkTaskTest unit tests migrated to Mockito

Thanks @gharris1727 and @C0urante for reviewing and merging the first PR
The second second (of three) batches is ready for review now after rebasing :)

Test failures appear unrelated, and the runtime tests pass locally for me.


Won't 'see' some adult blogs

Tumblethree doesn't see some blogs.  Some can only be read in a browser by following them.  The URL for one is as follows...
(actual blog name is replaced with 'ADULTBLOG')
https://www.tumblr.com/blog/view/ADULTBLOGG?redirect_to=%2Fblog%2Fview%2FADULTBLOG&source=content_warning_wall
I tried many different combinations but TumbleThree wouldn't recognize the blog.  Is this known or is there a workaround?  And yes, I'm properly logged in.
Thanks!

The issue has been closed. You can still comment. Feel free to ask for reopening the issue if needed.


Add Automatic Release Date for Tunes Submission

Implements https://github.com/fastlane/fastlane/issues/7150
Exposes the auto_release_date field in AppVersion. The field takes in
a millisecond value. Setting this will supercede the release_on_approval
field, so this field must be nil for release_on_approval to be used.

Hi @enozero, thanks for your contribution and sorry for the late reply!
It seems like there is no user facing change to use this feature, so someone will probably have to pick this up later and implement it then if they so desire. Apparently there are some conditions on using this feature that you mention in the commit message, but should also be included in the code, e.g.:
Setting this will supercede the release_on_approval field, so this field must be nil for release_on_approval to be used.

The tests should also reflect this requirement.

I have but haven't been able to update the change yet and will do so soon!

@KrauseFx @milch I've updated the PR with the requested changes. Please take another look and let me know if you have any questions. Thanks!


Hide items that are #[doc(hidden)]

Common #[doc(hidden)] items are: function/trait/const/anything that is technically public but not intended to be used.
An enum variant can also be hidden to simulate an "open enum", where the enum cannot be matched exhaustively, and thus will add new variants backwards compatibly. One example is ::std::io::ErrorKind::__Nonexhaustive.

Would you want this only when crossing crates, or also within the defining crate?

I'd like this when crossing crates, too. Anything that is marked with #[doc(hidden)] is public only as a workaround but is really meant to be private.
In crossbeam-channel I'm exposing all the internal modules as public and marked with #[doc(hidden)]. The reason why almost everything has to be public is because the internal (meant to be private) modules are used by the public select! macro.


URL Redirect for Four Legged Finisher

Could dosomething.org/finisher redirect to https://www.dosomething.org/us/campaigns/four-legged-finisher (node 6692, currently unpublished)?
We'd need it set up by Tuesday, 3/22.
Thanks!!

Closed via Fastly redirect (Fastly v64).

Thanks for this to @mshmsh5000! :dog: :cat:

@mshmsh5000 sorry about this -- could we also have dosomething.org/finishers redirect to https://www.dosomething.org/us/campaigns/four-legged-finisher? Last minute change in campaign title -- apologies again!

@namimody The existing redirect rule actually catches that variation already:
http://dosomething.org/finishers
:beers: :cake:

@mshmsh5000 I'm so sorry about this again -- but I just realized that since the title of the campaign actually changed to "Four Legged Finishers" the destination URL is actually: https://www.dosomething.org/us/campaigns/four-legged-finishers and so the redirects are currently routing to /campaigns. :no_smoking: :cat: :dog: :see_no_evil:

Documenting that this is all set!


Array.reduce should accept undefined as an initial value

console.log(
  [0, 1].reduce((c: number | undefined, x) => (c ? c : x), undefined)
); // should be 1

TypescriptToLua Playground
TS Playground
This is the more correct code roblox-ts uses:
function TS.array_reduce(list, callback, ...)
	local first = 1
	local last = #list
	local accumulator
	-- support `nil` initialValues
	if select("#", ...) == 0 then
		if last == 0 then
			error("Reduce of empty array with no initial value at Array.reduce", 2)
		end
		accumulator = list[first]
		first = first + 1
	else
		accumulator = ...
	end
	for i = first, last do
		accumulator = callback(accumulator, list[i], i - 1, list)
	end
	return accumulator
end

function TS.array_reduceRight(list, callback, ...)
	local first = #list
	local last = 1
	local accumulator
	-- support `nil` initialValues
	if select("#", ...) == 0 then
		if first == 0 then
			error("Reduce of empty array with no initial value at Array.reduceRight", 2)
		end
		accumulator = list[first]
		first = first - 1
	else
		accumulator = ...
	end
	for i = first, last, -1 do
		accumulator = callback(accumulator, list[i], i - 1, list)
	end
	return accumulator
end

Isn't that because c ? c : x with 0 ? 0 : 1 evaluates to lhs with Lua boolean coercion rules?

You're correct. I will change my example.


[DNM] net: allow relocation of network subsystem to RAM

Enable relocation of network subsystem to RAM. The intent of this feature is to enable SOCs with fast instruction TCM to take advantage of the improved performance available by relocating networking code to this region. This PR enables this feature for the Cortex M7 based iMX RT SOCs with a Kinetis Ethernet controller.
This PR is dependent on the following PRs (and currently integrates the commits from both):
#50791
#50790
Below are some TCP performance results using this PR. Results were obtained using iperf 2.1.5 with the zperf sample running on the Zephyr target. These results relocate the networking stack, L2 ethernet implementation, and NXP ethernet driver to ITCM.

Board
SHA
TCP RX
TCP TX

mimxrt1060_evk
main (fd9e5429a37f24780f5e27c08ecb470d5d36e93a)
44.2Mbps
43.7Mbps

mimxrt1060_evk
This PR
94.5Mbps
71.6Mbps

mimxrt1050_evk
main (fd9e5429a37f24780f5e27c08ecb470d5d36e93a)
60.2Mbps
68.5Mbps

mimxrt1050_evk
This PR
94.5Mbps
71.4Mbps

Shouldn't this be a board feature and not a networking one? I am asking because you introduce new Kconfig symbols to networking stack which imho do not seem to be really needed there.

The feature itself is nice if we get such a speed increase with minimal changes. Just pondering where / how this should be setup.

Looks fine to me to get a generic config option on net stack, that some hw can take advantage of. It's actually cleaner that way I think. Many more SoC/boards are going to use that at some point

@danieldegrasse I have no strong opinion about this, I was just thinking aloud and pondering about how to setup this. Overall, this is a nice speed improvement for this soc.


merge package from arlac77/npm-package-template

.travis.yml

chore(travis): remove node versions 10
chore(travis): add node versions 10.1

:tada: This PR is included in version 1.0.9 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


APK build failed in projects with specific name

Hi, I'm building my app using App Inventor in http://ai2.appinventor.mit.edu. I failed to generate APK file and got some strange error outputs as following:

________Preparing application icon
________Creating animation xml
________Creating style xml
________Generating manifest file
________Attaching native libraries
________Attaching Android Archive (AAR) libraries
________Attaching component assets
________Invoking AAPT
AAPT time: 0.692 seconds
________Compiling source files

which actually doesn't contain useful information to pinpoint where errors located. So I built my local AI server and noticed that terminal output said

ERROR in C:\Users\Administrator\AppData\Local\Temp\1538879186861_0.4665875202881149-0\build\generated\src\appinventor\ai_test\try\R.java (at line 8)
package appinventor.ai_test.try;
Syntax error on token "try", Identifier expected

It indicates that the project name ("try") conflicts with Java keywords. So if some users type names like "package", "long", "private" and so on accidentally to their project, they will encounter identical error messages when building. To avoid this annoying circumstance, I suggest adding a prefix for project name in source file to compile.

Have you updated your instance of the App Inventor? PR 1348 should have fixed that

@moliata Thanks, I've checked my files and it turns out that my BuildServer is built from the latest sources code but front-end "YaClient" is not. The latest version does work.
To @SusanRatiLane and @ewpatton who is related to #1348, I've read #1348 which solved this by preventing users to create "illegal" things, and it just verifies the name in user's browser, anyway, I don't consider it as an elegant way to solve this problem. Users might be annoyed by the tips (and might say App Inventor is so bad because it even can't accept such simple common words [sad...]). Why not just adding a prefix to every vulnerable field, thus give back more freedom of choice to users?
And I noticed that using screens or components named after reserved words seems doesn't lead to such errors, maybe that's because Screens' classes are compiled with YAIL (or kawa) compiler.

The primary reason we can’t do what you propose is due to backwards compatibility. It was a design decision that the project name be used to construct the package name for the app. If we introduce a prefix to protect package names, then it will prevent people from publishing new versions of their apps in the Play store (without repackaging using their old package name) and breaks any uses of ActivityStarter that might rely on the package name.
For users who are upset that App Inventor doesn’t allow trivial names for projects, I would recommend that they reconsider and choose a project name that more accurately describes what the app is attempting to solve. Otherwise one may just end up with a list of project names that are without meaning. At the very least, I think it would make sense to start with a capital letter. But rather than forcing naming conventions on people, it is less friction to just disallow reserved words like any other compiler would.

On Oct 7, 2018, at 21:43, I am who I am<EMAIL_ADDRESS>wrote:
@moliata Thanks, I've checked my files and it turns out that my BuildServer is built from the latest sources code but front-end "YaClient" is not. The latest version does work.
To @SusanRatiLane and @ewpatton who is related to #1348, I've read #1348 which solved this by preventing users to create "illegal" things, and it just verifies the name in user's browser, anyway, I don't consider it as an elegant way to solve this problem. Users might be annoyed by the tips (and might say App Inventor is so bad because it even can't accept such simple common words [sad...]). Why not just adding a prefix to every vulnerable field, thus give back more freedom of choice to users?
And I noticed that using screens or components named after reserved words seems doesn't lead to such errors, maybe that's because Screens' classes are compiled with YAIL (or kawa) compiler.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks for your reply.


⚠ Bofrost.lu has degraded performance

In 78a19d7, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1522 ms

Resolved: Bofrost.lu performance has improved in 7ffb08a after 6 minutes.


getBillingPageToken resource for UserService

getBillingPageToken service will return Recurly hostedLoginToken for user when available.
TODO:

[x] Add all expected exceptions
[x] Write integration tests

Dependent on https://github.com/lensapp/lenscloud/issues/1438

Depends on
https://github.com/lensapp/lenscloud/pull/1459

Closing this to create a new PR after rebase.

You could also rebase and force push

You could also rebase and force push

Ok, will do that next time if that practice is ok here. Force with lease, I suppose?

Yeah, force with lease is better 👍


How to get the final URL?

Is it possible to get the final url of the random image?
For example with $faker->imageUrl(1200, 850, ['cats', 'dogs'], true) I get this url:
http://loremflickr.com/1200/850/cats/?random=1
But if I enter it in the browser it redirects to something like this:
https://loremflickr.com/cache/resized/65535_50273776606_d866f591e7_b_640_480_nofilter.jpg
The problem is that I am generating random images with a for loop and they are all the same once rendered:

Resulting in:

So, is it possible to return the actual resulting URL for each one, so that they can be different images?

I pushed the fix, now it will be displayed correctly if there are a lot of random images on one page

Awesome thank you!


Support JSON as manifest file. Minor fixes.

Even if docker compose only support yaml, I think the json support still useful for various scenarios :

A program fetch the JSON from another API endpoint, then use it with orcinus
It is easier to maintain unit testing (I still writing for it) that generate plain JSON which will be consumed by orcinus API

nice piko chan :-*


Add last recom constraint for manager+recommender pages

 Modification of the display of the page "Preprints [or Reports] you are handling"