Include All Form Fields not passing values to inline_create modal

Missing form serialize code in ajax request

A new inspection was created.

The inspection completed: No new issues

Hello @dividy thanks for the PR. :rocket:
Just to clarify here: you are trying to send the current form fields to the modal endpoint? Or include_all_form_fields does not work for fields inside the modal ?
What are you trying to achieve ? Change modal content based on some selected option ?
Also please revert the changes to other parts of this field that does not correspond to this specific feature PR, they will be addressed in other issue.
What I would recoment to submit clean PR's is:
PRE-NOTE: don't do this if you have customized files inside vendor folder. You should NOT have customized files inside vendor folder

delete vendor/backpack/crud from your project.
run: composer install --prefer-source - this will install the missing packages, in this scenario is backpack/crud.
go into the instalation folder vendor/backpack/crud and do git checkout master, git fetch, if there are updates: git pull
create a local branch: git checkout -b your-branch-fix-name

now do the changes you need in files

you can see the changed files before commit: git commit -v
commit them with git commit -am "your commit message"
push them to backpack: git push origin your-branch-fix-name

Now when you go to https://github.com/Laravel-Backpack/CRUD/ you will have a button to create a pull request from that branch.
This can also be achieved with git desktop gui. the process is pretty much the same except for the git commands that you will run in application.
Best,
Pedro

Yes, I can see your changes have been integrated here by mistake.
I'm trying to send the current form fields to the modal endpoint.
The code was already present in 2 other places in this file, so I integrated it in this ajax call too.
What i'm trying to achieve is set the value of eg. Customer field to be the same as Customer field in the main form. I managed to make it work by using the 'default' option to set the value (for user experience) and I used a hidden field for the form value to be passed.
I'll change my PR this evening!


Rail, matplotlib version issue?

Hi Andrés,
I've had some (small) bugs with the analysis tools for discminer. Although they're only small, and I've implemented temporary fixes, it would be great if you could sort them soon so that when I download the updated versions I don't lose my fixes. When using plot_radial_profiles, I get:
Traceback (most recent call last):
File "/home/awinter/discminer_analysis/mwc758_12co/../_mining/plot_radial_profiles.py", line 207, in
vel_z, vel_z_error = rail_vz.get_average(**kw_avg)
File "/home/awinter/anaconda3/lib/python3.10/site-packages/discminer-0.2.6-py3.10.egg/discminer/rail.py", line 328, in get_average
self.prop_along_coords(**kwargs_along_coords)
File "/home/awinter/anaconda3/lib/python3.10/site-packages/discminer-0.2.6-py3.10.egg/discminer/rail.py", line 301, in prop_along_coords
if isinstance(ax2, matplotlib.axes._subplots.Axes):
AttributeError: module 'matplotlib.axes' has no attribute '_subplots'. Did you mean: 'Subplot'?
I matplotlib.axes doesn't have a _subplots property.. I'm not sure if this is a version issue? I have fixed this by just checking if 'ax2' is a list.
There was also a separate issue when calling 'prop_along_coords', where keyword arguments sent to were propagated to this via the 'get_average' function, which resulted in an 'unexpected keyword' error. I have hacked a fix for this by adding **kwargs  into the accepted arguments for prop_along_coords.
Sorry, I know this stuff is small, but hopefully won't take too much time!
Cheers,
Andrew

PS. Also 'from utils import add_parser_args' should be added to the top of make_double_moments.py I believe...

Thanks for sharing Andrew!
The first bug is indeed a version issue relevant to matplotlib>3.4, and is now fixed on https://github.com/andizq/discminer/commit/d2b60df76334233c6f9348b6cde393e5a48b75f8.
The other bug is related to new features added recently into the rail.get_average function which require discminer>0.2.8.
As for the parser_args in make_double_moments.py, note that the command line arguments passed to that script have naming conflicts with other arguments more widely used by the other analysis scripts, so I am keeping them separate from those defined in utils.py for now. In the next update I'll resolve those conflicts and redefine everything accordingly so that we can always refer to the arguments listed in utils.add_parser_args.


Added all contributors tbody tag

All contributors table in README.ru.md doesn't have tbody tag, but all the other README.*.md have it. Because of this it's impossible to add new contibutors in README.ru.md. To fix it i just copied All contributors table from the README.md.

Thanks @korzck! This was fixed when I added you as a contributor in 1c4cefed383c3d6dff12a31a05bb60c5c62fd420 👍


Fix HV card BOM

The HV card BOM did not have part numbers for a few parts. This PR does the following:

Add part numbers for all parts
Add .csv version of the BOM
Remove the outdated .md and .xls versions - these are redundant as .csv can be uploaded to DigiKey and also renders in GitHub.

Related Issues

Closes: #37

@elsevers this PR closed due to deleting its target branch. Do you still want this content to be merged?

Thanks @npetersen2. Good catch. I did not mean to close this PR.


⚖ Custom buckets PSQT VIII (8 buckets)

    public static readonly int[] PSQTBucketLayout =
    [
         3,   3,   4,   4,   5,   5,   6,   7,
         3,   3,   4,   4,   5,   5,   6,   7,
         3,   3,   4,   4,   5,   5,   6,   7,
         3,   3,   4,   4,   5,   5,   6,   7,
         3,   3,   4,   4,   5,   5,   6,   7,
         3,   3,   1,   1,   1,   5,   6,   7,
         0,   0,   1,   1,   1,   2,   2,   5,
         0,   0,   1,   1,   1,   2,   2,   2,
    ];

Old
```
Score of Lynx-eval-psqt-custom-bucket-scheme-8-8-buckets-3441-win-x64 vs Lynx-eval-psqt-2-per-file-3434-win-x64: 280 - 355 - 295  [0.460] 930
...      Lynx-eval-psqt-custom-bucket-scheme-8-8-buckets-3441-win-x64 playing White: 195 - 120 - 150  [0.581] 465
...      Lynx-eval-psqt-custom-bucket-scheme-8-8-buckets-3441-win-x64 playing Black: 85 - 235 - 145  [0.339] 465
...      White vs Black: 430 - 205 - 295  [0.621] 930
Elo difference: -28.1 +/- 18.5, LOS: 0.1 %, DrawRatio: 31.7 %
SPRT: llr -1 (-34.7%), lbound -2.25, ubound 2.89
```

Supersede by more complex layouts


switching to teiid-modeshape version of modeshape

Did we cut a "teiid-modeshape" release, before we pull this in?

Short answer no.  Longer answer the other pr needs merged first, then a deploy of the snapshot.  Then this pr can be merged.  Whenever it's needed the non-snapshot version of teiid-modeshape can then be released.

oh! I saw @vhalbert comment thought the other PR is merged already.


LLM downloads stuck at 50-60% [BUG]:

How are you running AnythingLLM?
AnythingLLM desktop app
What happened?
I've downloaded and installed anythingllm desktop on win11. Everything went fine, except when i try to download llms such as llama3.1 etc, it won't complete, no matter which llm i try to download. I've uninstalled and reinstalled anythingllm desktop to no avail, frustrating.
Are there known steps to reproduce?
I've uninstalled and reinstalled anythingllm desktop. I"ve tried all the other llms, they all won't complete downloading.

This is not a bug with AnythingLLM, but likely from ollama's model registry - which is where the download stream originate from. We have seem download's hang from people who have limited disk space where AnythingLLM is using storage and with VPNs. Do either of these apply to you?
I downloaded llava-llama3 on a fresh windows desktop today actually - no issues

None applied, not using vpn and plenty of space on my hard drive. I download with ollama, webui and others and never encountered this issue.

Same situation here : Win10pro on intel 6500T, 16GBram , 40Gb Free SSD space.
Gpt4all goes fine, Lm Studio goes fine, Anything stops downloading models between 40 and 56%


Resubmit: Templates in metrics are pre-expanded

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issues exists when I tested with :latest
[X] I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?
Resubmitting a workflow with top level metric templates submits them pre-expanded.
Note the difference between the workflow name and the key: name in the yaml here on the retry.

Fundamentally I think these are templated permanently in the original workflow run, so the fact they were a templated value isn't present in the workflow object which is then retried.
I am happy for someone else to supply a fix here.
Version
3.5.1
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: metrics-example-
spec:
  metrics:
    prometheus:
      - name: result_counter
        help: "Count of workflow execution by result status"
        labels:
          - key: status
            value: "{{status}}"
          - key: name
            value: "{{workflow.name}}"
          - key: job_name
            value: "foo"
        counter:
          value: "1"
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          - name: a
            template: whalesay
    - name: whalesay
      container:
        image: alpine
        command:
          - sh
          - -c
          - |
            echo "I'm just here to look pretty"

Logs from the workflow controller
Nothing to see here

Logs from in your workflow's wait container
Irrelevant

Probably the same as #12123.

There appear to be a few bugs with resubmit not resetting things in general: #12195 is another case unrelated to metrics


Added Teambition <IP_ADDRESS>4

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Remember to change the folder name and the file names :)
You can probably change the PackageIdentifier to alibaba.Teambition once you're at it

Thank you for your suggest. :)


[Bug] Crash when edit the init() method of a script (that added to an object in scene) several times

Fixed in b#236


feat(config) add more nginx configuration injections

Summary

introduce nginx_main_<directive> injections
introduce nginx_events_<directive> injections
introduce nginx_supstream_<directive> injections
introduce nginx_main_worker_rlimit_nofile injection with special auto value (math.min(ulimit, 65536))
introduce nginx_main_events_worker_connections injection with special auto value (math.min(ulimit, 65536))
move nginx_user to nginx_main_user injection
move nginx_daemon to nginx_main_daemon injection
move nginx_worker_processes to nginx_main_worker_processes injection
move nginx_http_upstream_<directive> injections to nginx_upstream_<directive>
move nginx_http_status_<directive> injections to nginx_status_<directive>
move client_max_body_size to nginx_http_client_max_body_size injection
move client_body_buffer_size to nginx_http_client_body_buffer_size injection
move real_ip_header to nginx_proxy_real_ip_header injection
move real_ip_recursive to nginx_proxy_real_ip_recursive injection
remove the undocumented nginx_optimizations config parameter

The tests are failing because this needs to be merged first:
https://github.com/Kong/kong-plugin-prometheus/pull/76

Some thoughts overall:

Overall this certainly seems a step in the direction where we (Thibault and I) wanted to be in when we initially put this feature in, so good job there!
Question: has there been a use-case or an ask for nginx_supstream_? I know there are a couple of directives we set and use but the API surface because of these increase quite a bit so wee should be careful about introducing it.
Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site. Some of these are highly used variables and it will take a long time for them to go away, just from Kong's documentations and all the web of products around it.
Some of these properties like real_ip_header are used quite a lot. As much as we want to provide a good experience for Nginx ninjas, we also should keep Kong's configuration friendly for users who have never used Nginx before, which seems to be the majority in our user-base. I'd advise that we don't deprecate some of the config parameters that are used heavily and keep them as is. Explaining to an end user KONG_REAL_IP_HEADER is much easier than KONG_NGINX_HTTP_PROXY_REAL_IP_HEADER.
It is very important to document the big deal changes here in the changelog. Having a very verbose commit with a changelog section or keep those changes around in another doc could help.

A general comment:
This is one humongous commit and it is almost impossible for me to review this thoroughly and hence         I just skimmed it. I'd encourage us to rather make 20 smaller commits (especially when there are unrelated changes), even keep the commits as one makes while hacking this together.
I understand that we are religious about commit messages and commit formats but those can be taken care of at a later stage, even after a review of the code change.

Question: has there been a use-case or an ask for nginx_supstream_? I know there are a couple of directives we set and use but the API surface because of these increase quite a bit so wee should be careful about introducing it.

There is no reason for http to be more supported than stream in this regard. E.g. I have never heard people injecting stuff into http upstream, but that was probably added because a single person asked about it. Especially now that we get rid of service mesh and make stream standard nginx.

Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site. Some of these are highly used variables and it will take a long time for them to go away, just from Kong's documentations and all the web of products around it.

We are not removing them at the moment. We just deprecated them. I can add them there, and to document to use a new value.

Some of these properties like real_ip_header are used quite a lot. As much as we want to provide a good experience for Nginx ninjas, we also should keep Kong's configuration friendly for users who have never used Nginx before, which seems to be the majority in our user-base. I'd advise that we don't deprecate some of the config parameters that are used heavily and keep them as is. Explaining to an end user KONG_REAL_IP_HEADER is much easier than KONG_NGINX_HTTP_PROXY_REAL_IP_HEADER.

We discussed it internally, and we got into problems with current injections. Biggest problem was that by injection name you cannot tell where the context stops and where the directive starts. Thus we changed everything to be KONG_NGINX_<SINGLE-WORD>. If we keep supporting multiple, e.g. KONG_REAL_IP_HEADER and KONG_NGINX_PROXY_REAL_IP_HEADER equally we get into issues of priorities, or erroring when defining both. It also adds excess code to handle these. I'd say it just brings more problems than it solves. Yes, I personally brought up the usability, but well, it is just one rename, and we are just deprecating for now.

Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site.

Deprecations added to kong.conf.default. Docs site is autogenerated from it.

It is very important to document the big deal changes here in the changelog. Having a very verbose commit with a changelog section or keep those changes around in another doc could help.

I feel that is scope-creep of this PR. We usually do changelogs before releases separately.

This is one humongous commit and it is almost impossible for me to review this thoroughly and hence I just skimmed it. I'd encourage us to rather make 20 smaller commits

I split it to 15 commits.


Update redis as logstash redis output now uses 4

Thanks for contributing to Logstash! If you haven't already signed our CLA, here's a handy link: https://www.elastic.co/contributor-agreement/

Does not look releated to my change.
The command "~/bin/install-jdk.sh --target "/home/travis/oraclejdk8" --workspace "/home/travis/.cache/install-jdk" --feature "8" --license "BCL"" failed and exited with 3 during .


Introduce turbo:before-permanent-element-render

While transposing a permanent element from page to page, dispatch a
turbo:before-permanent-element-render event on the document with a
(currentPermanentElement: Element, newPermanentElement: Element) => void available as the event's detail.render property.
The turbo:before-permanent-element-render is named to follow the
pattern established by its predecessors (turbo:before-render,
turbo:before-frame-render, turbo:before-stream-render), and its
CustomEvent.detail.render property name mirrors the
turbo:before-render event's CustomEvent.detail.render property.
This opportunity to modify a permanent element might be useful if it's
possible for the preserved element to become partially stale. For
example, consider an invalid <form> submission with an <input type="file">.
Since the server's response cannot fully encode the submitted file into
the response's element, it might be a useful to mark it with
[data-turbo-permanent] to preserve whatever client-side state precedes
the submission:
Profile image
<input id="profile_image" type="file" data-turbo-permanent>

Suppose the uploaded file is too large, or doesn't match the server's
expectations for file type. The server's response might contain
a fragment like:
Profile image
<input id="profile_image" type="file" data-turbo-permanent
       class="invalid" aria-describedby="profile_image_error">

Profile image is too large (5GB). Try a smaller file (<5KB)

Prior to this change, the fact that the <input> is marked with
[data-turbo-permanent] would ignore the [class] and
[aria-describedby] attributes from the response, and the <input>
would remain unchanged (with the attached file still in-memory).
With a new turbo:before-permanent-element-render available, there's an
opportunity to do application-specific merging:
addEventListener("turbo:before-permanent-element-render", ({ target, { detail } }) => {
  detail.render = (currentElement, newElement) => {
    currentElement.setAttribute("class", newElement.getAttribute("class"))
    currentElement.setAttribute("aria-describedby", newElement.getAttribute("aria-describedby"))
  }
})

Wouldn't you be able to get the same done using turbo:before-render and digging through the existing page body and the new page body? What's the additional utility of having this narrowed down?

I considered a permanent-specific event to separate the idea from the details of the rendering (was it a full Drive visit? a Frame navigation? a Stream?) so that the code could be more general purpose.
Currently, the newBody is only available to a turbo:before-render event. Frame navigations only dispatch turbo:frame-render events, and those don't provide access to the new fragment of HTML.
I'm also not sure if Turbo Stream rendering currently accounts for permanent elements correctly. If they do, that would be another point in time and event (turbo:before-stream-render) where callers would need access to the new element ahead of time.
If a new event specific to permanent elements isn't warranted, then a turbo:before-frame-render with access to the newFrame would be an appropriate replacement, along with an extension to the turbo:before-stream-render event to provide a handle to the <turbo-stream> element's <template> as well as the elements referenced by the [target] and [targets] attributes.

I'm also not sure if Turbo Stream rendering currently accounts for permanent elements correctly. If they do, that would be another point in time and event (turbo:before-stream-render) where callers would need access to the new element ahead of time.

I've just tried this out, and it appears that Turbo Stream operations ignore [data-turbo-permanent].
You can experiment with the code on JSFiddle:


Understand whether we can move all of CI to Github Actions

Context
Current CI configuration, and the advantages Concourse provides, are explained at https://github.com/sparklemotion/nokogiri/blob/25e7c49c87bda2cb1e2dd15677af11c74503dc04/CONTRIBUTING.md#how-continuous-integration-ci-is-configured
What problems would we solve by moving to GA?

Appveyor is slow.
The Concourse environment is relatively expensive to keep running.
Knowledge of Concourse is low in the Ruby community.
Easier integration of the Nokogumbo test suite (see #2204)

Goals of this issue
I simply want to build confidence that we can go all-in on GA, and remove either Appveyor or Concourse or both; so that I can accept PRs like #2011 without feeling like I'm spreading myself even-thinner.
Unknowns and risks

How to use custom containers (e.g., rake-compiler-dock containers and the nokogiri-test containers)
How to move large payloads between jobs (e.g., between gem-build and gem-install-and-test)
How will GA perform on memory-intensive and CPU-intensive jobs like valgrind tests?
Can we cover all the Windows use cases in GA? (MSVC, mingw, 32-bit, 64-bit ... ?)

I've started reading https://docs.github.com/en/actions/learn-github-actions/managing-complex-workflows
Related conversations / issues / PRs

https://github.com/sparklemotion/nokogiri/issues/2015#issuecomment-779992560
Update Actions CI by MSP-Greg · Pull Request #2011 · sparklemotion/nokogiri

cc @MSP-Greg

@flavorjones
I sense your frustration here (and in past messages) with CI.  GA is still missing features that exist in Travis & AppVeyor.  Re the issues you've listed:

How to use custom containers (e.g., rake-compiler-dock containers and the nokogiri-test containers)

I haven't worked much with them.  See https://github.com/ruby/ruby/blob/master/.github/workflows/compilers.yml for one example with a container.

How to move large payloads between jobs (e.g., between gem-build and gem-install-and-test)

I believe it can be done, but I haven't implemented it in GA.  I have PowerShell scripts to build gems (and test the install) with AppVeyor, but those used one job.  Being able to do so on GA and take advantage of parallel jobs would be useful.

How will GA perform on memory-intensive and CPU-intensive jobs like valgrind tests?

Without testing it, no idea.  I've got some tests with Puma that generate 2k client connections, and they get processed in less than 2 sec.  Not the best comparison, but...

Can we cover all the Windows use cases in GA? (MSVC, mingw, 32-bit, 64-bit ... ?)

Qualified maybe.  Currently, MSVC is only available as a daily Ruby master build that is available on GA.  32-bit builds have been done by Lars (@larskanis), but they aren't included in the custom action (setup-ruby) normally used to setup Ruby on GA.

Summing up, I can't cite examples for everything you'd like to have in CI.  Can most of it be done?  I think so, given the OS limits of GA.
Moving whatever jobs can be done in GA might be a good start, and taking advantage of the high parallel job limit might speed up the CI.  Once that's stable, start writing scripts for the more complex CI...
Lastly, some of the things you'd like to implement I'd also like to see done, possibly for use elsewhere.  I'm interested in helping, but I've also got other obligations.

I'm experimenting with using custom images at https://github.com/flavorjones/calendar-assistant/pull/186

OK, I've got a pretty good sense of how to use Github's Container Registry now; and I've got a calendar-assistant action to even build the container image consumed by the test suite action.

Note that #2226 shows valgrind is much faster on GA than it is in my concourse environment.

I'm confident that we can move everything to Github Actions except 32-bit windows. Closing this, will open a PR shortly.


feat(transform_conformance): skip tests with plugin.js

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#2977  👈
#2974
#2967
#2966
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite

Merge activity

Apr 14, 9:43 AM EDT: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.


Detect directories to notify incorrect use of Import API

[ ] Before merging, update docs accordingly: http://docs.cartodb.com/cartodb-editor/error-codes-and-solutions/

Fixes https://github.com/CartoDB/cartodb/issues/6307

The details to reproduce the issue can be found: https://github.com/CartoDB/cartodb/issues/6307#issuecomment-173221350

Data Import result from reproduction in staging:
{
id: "591109a2-62fb-4fde-b973-f4ee3b70a50a",
user_id: "868aad2f-e085-441a-afb8-7adb7c0802c6",
table_id: null,
data_type: "datasource",
table_name: null,
state: "failure",
error_code: 1010,
queue_id: "591109a2-62fb-4fde-b973-f4ee3b70a50a",
tables_created_count: null,
synchronization_id: null,
type_guessing: true,
quoted_fields_guessing: true,
content_guessing: false,
create_visualization: false,
visualization_id: null,
user_defined_limits: "{"twitter_credits_limit":0}",
get_error_text: null,
display_name: "591109a2-62fb-4fde-b973-f4ee3b70a50a",
success: false,
original_url: "",
warnings: null,
is_raster: false
}

Please, @rafatower, take a look when you can. Thanks! :-)

basically ok, consider my comments (minor things)

Just proposed a doc change here. As soon as it's accepted this PR is ready to be deployed.

:+1:


Mysql triggers

A good portion of the tests are failing right now, so I didn't put much effort into validating my tests.
For what it's worth, I broke up the commits so you are welcome to cherry pick and close this PR, modify as needed, etc.
This is currently working locally with create_all and alembic's autogenerate.
Closes #81

Im happy to continue making changes off your branch.
Fwiw, generally it's only important to write the minimal set of tests against alembic to ensure it's registering each operation type (create, update, delete) for a given object, regardless of dialect. once those exist everything else can just be regular sqlalchemy tests using create_all, because they're way faster and simpler to write.

Couple bits and bobs here and there in the impl

mostly imports and hooking the query it up properly
filtering out built-in sys triggers
combined order and other_trigger_name into a sub-object that you supply by Trigger.before(...).follows('foo') (same for precedes)

and then, like i said with tests. just do tests "normally" excluding alembic to make them easier to work with.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

61 of 68 (89.71%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall first build on mysql-triggers at 90.711%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sqlalchemy_declarative_extensions/dialects/postgresql/trigger.py
5
6
83.33%

src/sqlalchemy_declarative_extensions/dialects/mysql/trigger.py
45
51
88.24%

Totals

Change from base Build<PHONE_NUMBER>2:
90.7%

Covered Lines:
3191

Relevant Lines:
3473

💛  - Coveralls

Hey @DanCardin I'm poking around and wonder if we both over looked one line that might be a mistake. This line doesn't add the returned sql to components nor return it immediately.

https://github.com/DanCardin/sqlalchemy-declarative-extensions/pull/84 I think it's safe to remove this from the base class also. it's not universally supported, and postgres can internally add it's use of that flag without affecting anyone else.
Definitely just a remnant of postgres being the originating impl of the object type.


Show tooltips for container names

Please add tooltips for container names and ability to extend host box area or toggle word wrapping in user ui settings, because as you can see in an image below all containers look the same :) At least add tooltips...

There are some new views of the UI that should help with this issue in our latest release (v0.42.0), where you can see what services are from what stack.

Highlighting over the container name in host view now shows the whole container name.  Enabled tooltip.


Empty response on using strlen()

I have a REST application with an ActiveRecord class which overrides method  fields(). Some fields (array keys) are set with callable values as described here. In one of these functions I am using strlen() function and this is the case when problem is arising - as long as there is a strlen() in any anonymous function, I am getting an empty response (totally empty body) and status 200. The output is correct when no such function is used.  See my example below:
public function fields() {
    return [
        /* other fields */
        'shortTitle' => function($model) {
            return array_map(function($title) {
                return strlen($title) > 29 ? substr($title, 0, 26) . '...' : $title;
            }, $model->title);
        },
        /* other fields */
    ];
}

In this example, I am getting a collection of documents from MongoDB, where field title is an object with next structure:
{
    'en': 'A pretty long title',
    'ru': 'Довольно длинное название'
}

I am not sure if it is a framework bug or the problem of mine. I thought that it might be a memory issue, but it is not - even if the field is single, an empty response is coming from server.

There's not a framework bug.
How you didn't catch a warning about array_map function, because $model->title is not an array?
If you develop with disabled error reporting there's not good practice I believe.
Try to modify your method like this:
public function fields() {
        return [
            /* other fields */
            'shortTitle' => function($model) {
                return strlen($model->title) > 29 ? substr($model->title, 0, 26) . '...' : $model->title;
            },
            /* other fields */
        ];
}

The code in my example is a simplified version. There were many other versions of this, including ones with a check for an array type, and I just took the simplest one just to show the point. I also gave an example of the structure of a field title to assume that $model->title will always return an array. In your example, you are using a strlen() function without any extra check of $model->title, which will throw an error for a non-string argument.
I am using a development environment with an enabled error reporting, catching all types of errors.

@xphoenyx as you store data is UTF8, you should use multibyte-safe functions mb_strlen and mb_substr instead of strlen and substr.
I think you substr($model->title, 0, 26) cuts a moiety of UTF-8 char and it causes tons of problems.

@SilverFire, thank you for your suggestion, that was a multibyte problem indeed. It seems that error, arising in anonymous function, assigned to any of array keys in fields() method, leads to unexpected immediate empty response with no sign of error. Could this case be handled somehow?


Update http4s-circe, http4s-dsl to 0.23.20

About this PR
📦 Updates

org.http4s:http4s-circe
org.http4s:http4s-dsl

from 0.23.11 to 0.23.20
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #469.


Review comments

We don't have a pull request open for the review of this one so I'll just use this issue ticket to track comments from reviewing what is currently on the main branch.

Dockerfile
You get the EPICS base dependencies installed 👍  However, I think you're missing setting of a few environment variables that I suspect must have caused some issues? Or maybe because you're on Linux and x86_64 is just defaults to sort of work - but might not work for other platforms.
Best practice is to set things like EPICS_HOST_ARCH and EPICS_BASE variables in the environment as described in the installation instructions: https://docs.epics-controls.org/en/latest/getting-started/installation-linux.html
I would recommend downloading the EPICS release tarball instead of cloning the git repo.

README.md
Good intro to the module: clear instructions on how to build and run the container with the IOC.
Perhaps missing a little bit of information about how to use this in a runtime environment on a host. For example: what type of network configuration does your docker container need to run with on the host in order to allow EPICS Channel Access to work in/out of the container? I.e. if the IOC is in the container and the client (phoebus or just CLI caget) is on the host or on another computer on the LAN?

Overall a good implementation of the IOC in a container 👍
Next steps would be to adopt the (much more complex) epics-containers framework that essentially do the same thing - but takes it much further. This project also provides pre-built images with EPICS base and a lot of common support modules, but the learning curve is rather steep... (we won't start that right now as we have other priorities right now...)


Running Balance not showing Balances and Flag/Cleared icon replaces the balances

Name of Defective Feature

Running Balance not showing Balances and Flag/Cleared icon replaces the balances

System Settings (Required)

ToolKit Version:
Operating System (Mac/Windows/Etc):
Browser (Chrome/Firefox/Safari): Chrome
Browser Version: 67.0.3396.99
Other Extensions:

Export of Toolkit Settings (Bottom Left of Settings Page)

Settings Export
PASTE SETTING EXPORT HERE

Steps to Reproduce the Behavior

Expected Behavior
 I expect to see my balances.
Actual Behavior

I am having the same problem in Firefox. I can fix the problem by reloading the page. If I switch to my other budget, I must reload the page to see running balances.

I'm having this same problem using Chrome for Mac. I've tried updating the settings and restarting chrome and it's still not working. If I login to my YNAB account on a Windows Machine, it works just fine.

Hey @rockingout the fix for this should be in our current release! If you notice the issue still exists and you're definitely running the newest version of the toolkit, please reopen! Thanks!
Please note, all browser can take up to an hour to provide updates to all users. You can force an update if it's available for you by going to chrome://extensions and clicking the "Update" button. Firefox users can go to about:addons, click the setting cog, and click "Check for updates...".


Stream test command output to file for debugging purposes

Please verify the following:

[x] yarn test jest tests pass with new tests, if relevant
[x] yarn lint eslint checks pass with new code, if relevant
[x] yarn format:check prettier checks pass with new code, if relevant
[x] README.md (or relevant documentation) has been updated with your changes

Describe your PR
What
We needed ignite new output to be printed by failing tests when developing; otherwise you have to generate the app at least twice to see why a given test is failing.
Approach
The way to get jest to print the output we want is by throwing it when the command fails. However, when we tried this, we found it was possible for the output to be so large for certain errors that it can hit node’s max buffer size, which also means you don’t get to view the error (and get a red herring error on top of that.)
That means we should stream the output with spawn, to manage output that's too large. In this PR, we stream it to a file so there’s always at least a partial record of the output, even if we fail to be able to print it to the console.
Existing tests expect a string of command output to test against, and so the simplest implementation for now was to just read the output from the file again. There’s potential for changing  this in the future but it should work just fine for now, since the happy path doesn’t involve output too large for a buffer.
Testing
Throw an error somewhere in new.ts. it should be printed to the console for tests that run ignite new.
Future improvements to consider

Use with more commands? right now I focused on just ignite new since that's where we tend to have issues

it is getting a little silly to make verbIgnite versions of all these commands in order to account for appending Ignite in there. Might want to handle that differently. (As an options flag? Let the caller handle it?)

Log cleanup?

I don’t think it’s necessary right now; they’re gitignored and re-written each test run. Shouldn’t be too much stuff.

testing against streamed data instead of loading it all in as one file

complicated! Chunks of stream are probably not the entire string we want to test against, and what a given chunk looks like can change as things are added before it. Have to build a test utility library for this, practically.

Avoid logging command run on normal test runs

Was hoping to use jest's --verbose flag to control this, but it doesn't appear to work like that. I think it’s more useful to log the command run than not, and it doesn’t take up too much space.

automated log naming when using the spawn fns? tried look at auto-naming logs based on tests, jest doesn’t appear to have an affordance for that

@lindboe this looks good, thanks for creating it. Let me know when you would like a formal review (I see it's still a draft)

The main reason I was leaving this in draft is I wasn't sure whether to consider it complete if it only covers ignite new. @frankcalise do you have thoughts on this? Would command output for other commands be useful?

@frankcalise Agreed, I think snapshot tests are probably better for generate.
@frankcalise @fpena any thoughts on approve/request changes?

@lindboe good to go!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add actuator/health endpoints to sample resource and client apps

This helps with liveness/readiness K8s probes

Since there aren't automated tests for this, I tested just by running all three samples and ensured that they still worked, and I was able to load localhost:8080/actuator/health and localhost:8090/actuator/health and receive the following without any auth.
{"status":"UP"}

Thanks for the PR @joshuatcasey.
The main goal of the sample is to demonstrate the integration between the authorization server, client and resource server. As well, to demonstrate how to configure the features that are currently implemented.
I don't feel adding Actuator to the sample makes sense as I'd like to keep the sample as minimal (and easy) as possible and to only demonstrate OAuth / OIDC specific features / flows.
Based on this, I'm going to close this PR. I appreciate your understanding.


Update README and tests with comments from Juicy/imported-template/pull/31

Juicy/imported-template/pull/31

reset mock server,
don't use mock server if mockable by static files,
add pre-test control expectation to ensure conditions,
few typographical changes.

BTW, once we will agree on all the changes, I'll squash commits, not to pollute commit log with Travis related problems.

Might be hidden by GH https://github.com/Juicy/juicy-html/pull/32#discussion_r142388184


Error on streaming null values to CSV.Sink

This issue is in the latest checkout of jq/remodel branch.
I am streaming data from an ODBC.Source to a CSV.Sink.  This works when the source has no null values.  When I inserted a row with a null value for one of the columns, I got the following error:
julia> src = ODBC.Source(hndl, "select * from remodeltest.Employee;")
julia> sink = CSV.Sink(TEMP_FILE)
julia> Data.stream!(src, sink)
ERROR: type Sink has no field null
 in stream! at /home/Nishanth/.julia/v0.4/ODBC/src/backend.jl:135

Data.stream!(src, Data.Table) works properly.

Will be fixed by 9792482faed2c3c3df9b95f7a7b985e5354d40b3

:+1:


Android files has been removed

I noticed that my android files has been removed.
android/app/src/debug/java/com/appsocio/ReactNativeFlipper.java
android/app/src/main/java/com/appsocio/MainActivity.java
android/app/src/main/java/com/appsocio/MainApplication.java
android/app/src/main/java/com/appsocio/generated/BasePackageList.java
Project created with Expo Bare workflow.
Using latest version of this package.
Old BundleId = "com.appsocio"
New BundleId = "com.qualitysys.0009"
Does anyone know why?

I've done some tests.
I think the problem is because "git mv -k" is not copiyng files, only folders.

I found the problem.
My folder is under a git repository, so when you check the condition:
gitMove.code === 128
This error code is wrong in my case, because 128 is not bad source.
I didn't found the correctly error code for 'bad source', but if someone else find it, just release a new version with the correctly code.

same here

@duduccosta can u help me?

@junedomingo can u help me, here?

@duduccosta thank u https://github.com/duduccosta/react-native-rename

I have removed using a git for moving files as it leads to bugs. Now after moving, we run git add .
Please use the latest version v2.9.0 and let me know if the fix works for you.
@duduccosta Btw you have a invalid bundle id

https://developer.android.com/studio/build/application-id

@duduccosta You can't use numbers in bundle id

This bug is still present on 2.9.0 @vomchik

Same happened to me while running npx react-native-rename newname -b com.newname.newnameAndsomething (uppercase in the middle of the third word + two dots) with 2.9.0.
Also, I already had moved the files listed in the original post to a correct path (from android/app/build/src/main/com/oldname to android/app/build/src/main/com/newname/Andsomethingelse).

Closing, please check v3.


how to use config.yaml

i cant find how to use it, no command like " --config 'config.yaml' "

You just need to create config.yaml next to the exe, no additional setup is required.

You just need to create config.yaml next to the exe, no additional setup is required.

ok, everything is perfect now, thx!


Needs Project Documentation

This project as a whole could use more documentation in the form of a website. Stuff that needs to be documented includes:

FAQ
Guides on how to use the software (and how to contribute to the software, including testing)
Documentation on what the opcodes do, including CCR

TRAP codes as well

Interfaces & API definitions (properties and methods for each of the object types)
Probably others that I'm forgetting.

There are a few options that I'm considering for this:

GitHub pages / GitHub wiki
Whatever docs https://docs.python.org/3/ uses
http://www.sphinx-doc.org/en/master/
Others?

I suppose we can have a look at OpenWISP and generate a simple site using sphinx. What do you think @Chris-Johnston ?

I've seen that Sphinx and Read the Docs are pretty common with stuff like this, and I actually had started setting it up in #103 , but never got around to getting anything implemented yet. Might be something that I come back to in a few days.

Great @Chris-Johnston I suppose having a separate repo for docs would be easier to maintain.

It's not actually going to be in a separate repo, like the openwisp2-docs. The docs will be under a docs directory, similar to how tweepy does it.

I had a look at tweepy. That is also a good idea. We can look at openwisp2-docs README and add a similar one to the docs folder for giving the users an understanding for making contributions and an intro to sphinx.

Definitely, contribution and getting started guides are both important to have, but haven't been a focus of development yet.
I want to focus on cleaning up the code base a bit before focusing on other contributions.

Sure! I am happy to help with the docs after you finish

cleaning up the code base

Fixed as of #103 . Now using Travis CI to build Sphinx docs, which are deployed to GH pages.


[MRG] Data modules reorganization

As agreed in https://github.com/braindecode/braindecode/issues/156
Closes #156

So this should be the complete reorganization as written in #156 :

datasets

base.py
xy.py
mne.py
bbci.py
moabb.py
tuh.py

preprocessing

preprocess.py
windower.py

datautil

serialization.py
util.py

It is backwards compatible with deprecation warnings, this also necessitates that the old files still exist, just emptied and with the deprecation warning there, e.g., see https://github.com/braindecode/braindecode/blob/6ded712d6d2703798fd7801267cdfa52f2500594/braindecode/datautil/mne.py#L1-L8
In order to be able to do the Flake8 stuff, I would like to merge this still later today or  latest early tomorrow, so please voice any objections @agramfort @hubertjb @gemeinl @sliwy

since no objections, now merging this, docs should not get updated on braindecode.org now, that is intended see #248


Write a test for the onEmptySearch prop

Follow up on https://github.com/helfi92/material-ui-treeview/pull/50.

will work it as soon as i complete the pending ticket in taskcluster

I just filed https://github.com/taskcluster/taskcluster/issues/2749 to move away from this library and use material-ui's TreeView component instead. This won't be necessary anymore. Let's close this issue :)


More complete bindings for URL

I've created the bindings for URL and URLSearchParams at https://github.com/bryanthomaschen/bs-webapi-incubator/blob/feature/implement-url/src/file/UrlRe.re
Would this be an appropriate addition to bs-webapi?

Very much. Would you make a PR?

PR opened! - https://github.com/reasonml-community/bs-webapi-incubator/pull/109

Thanks! Closing this in favor of the PR then


Convert samples to unit tests where appropriate

Some of our "samples" pre-date the compilation unit test harness we have now. And they're not really samples that someone would want to emulate, more like edge cases that we can't regress. One example is the 'recursive' sample. We should go through the samples and convert those that would be better as unit tests to unit tests.

[x] recursive.cadl https://github.com/microsoft/cadl/pull/35

Not sure actually there is other samples that don't belong in samples but in unit test instead, feels like each one has some value to show how to use certain things

OK, then I guess we can close this when #35 merges and just keep it in mind when making further changes. 😁


Webhook change

Rebased everything onto the latest master and tested it again. Had todo some adjustments to get it to work with the newest output parsing changes.


Remove the cascade

The cascade sort of makes sense for docs but makes less sense for apps. What if we removed it from CSS? This PR is an experiment in achieving this goal.
I've found the cascade to be particularly awful with things like line-height.
Advantage: components are guaranteed to look the same no matter where they are used, and styling behaves more similarly to other UI systems
Disadvantage: cascading can be convenient. Perhaps we'd introduce cascadingColor props which would disable the anti-cascading features.
How it works: it does a CSS reset (with initial) on the root node, keeps track of which cascading props are set in React's context, and resets them in children as needed.

I'm going to be pedantic about terminology here for clarity's sake. By "cascade" do you mean "the cascade" or "inheritance"? Or both?
Technically, the cascade refers to which selectors target which elements, and how the browser decides which to apply when they conflict (mainly, selector specificity). Inheritance, on the other hand, refers to a property that is passed down from a parent element to its children. From your post, it sounds like you're talking more about inheritance...?

@keithjgrant doesn't the cascade refer to multiple rules interacting to style a single node? the final way rules interact in jsxstyle is through inherit (since we don't allow multiple rules to match the same node), so i believe this title is accurate? maybe i'm wrong though...

Nah the cascade runs first, the final value of each property is determined, and if any value is set to inherit (or if a value is unset for a property that defaults to inherit e.g. typographic properties) then inheritance takes over.
If only one selector targets each element, you're already not using the cascade very much.
It sounds like you might prefer to simply set a CSS rule all: initial on each new element to disconnect it from inheritance. But in my stuff, inheritance is really awesome. With CSS variables inheritance is how they're so good. Even Shadow DOM only "shadows" elements from the cascade, inheritance is alive and well. Just don't set line-height to anything but 1.0 except on leaf nodes of the UI ;)

Exactly. Here's the relevant part of the spec.
I could understand wanting to remove inheritance of some properties, but it would seem silly to have to set others (like font-face) on every node in the DOM.

Ah, I knew they were in the same spec, but it looks like the cascading terminology does not cover inheritance. TIL.
all is what I want but it is not supported in IE or Safari.

Just don't set line-height to anything but 1.0 except on leaf nodes of the UI ;)

As a component author I cannot control what users of the component will do.
Any way you slice it, inheritance adds implicit coupling between the component and its user, and while setting font-face on every node may seem silly today I am confident we can come up with solutions that are convenient without introducing this implicit coupling.

As a component author I cannot control what users of the component will do.

No, but you can control which parts you are explicit about. If your component has inline elements (like typography) where anything greater than line-height 1.0 is going to break it, then your component should set line-height: 1.0. Likewise, if your component must have a particular font to be considered "valid", it should define it. But if it doesn't, is there anything wrong with implicitly using the font that's inherited down the page?
In my mind, you're not adding an "implicit coupling" by inheriting something like font-family. You're defining your component to be independent of the current font. Yes, the final exact pixels will differ based on what that font is currently set but I see that as no bad thing. Whatever you can make your component not care about (while still functioning as designed) makes it more flexible and reusable.

fwiw when I can't use css-in-js techniques I back up to suitcss.
In addition to normalize and suitcss-base I reset every component root and descendant (no modifiers and state classes) https://git.io/viG4X (this list is work in progress :)
The last part is quite important because it lets properties inherit only from the component context. In a way this is what you are doing in this PR but it doesn't *break* inheritance.
Then as @geelen says you can control which parts you are explicit about and every component comes with a set of configurable custom properties which eventually are the interface exposed to the consumer of the component.
Typically I define font size, weight, style for every component and set them to inherit by default.
:root {
  --MyComponent-fontSize: inherit;
  --MyComponent-fontWeight: normal;
  --MyComponent-color: inherit;
}

FWIW I've been using this in some production apps with postcss-autoreset and love working that way. Needs to be very explicit and the entire team has to be educated about it, but the DX is very nice!

update: I had an idea that is reset the inherited properties (eg. color) on the root of a component + reset the non-inherited ones (eg. margin) on every element – this guarantees that inheritance works within the component internals but values are reset on each scope similarly to what happens in ShadowDOM.
I have a WIP for suitcss.
Also @kof liked the idea and he/we might implement it into jss-isolate too.
@petehunt thoughts?

Closing until someone feels like discussing this further 😁


Create Queue_DataStructure implementation in Python

Please follow the Contributing Guidelines & naming conventions in the guidelines accordingly. 🙂
Following naming guidelines is important to maintain consistency.😊
Please NOTE: In case, same implementation of an algorithm is submitted by someone else and it gets accepted, then your contribution won't be merged ( to avoid duplicates )

Working on it!


Refactor: svg group fix and blur

This is my first attempt to change the inner code logic of sqip on the road to a plugin based system (See #30)
It does the following:

Split up svg fix and group + blur injection. Basically making blur the first "plugin" (Still lacking plugin conf ofc)
Replace the regex group injection with cheerio which should be way more flexible. This may allow using non-primitive svgs for the plugins later on.

Codecov Report

Merging #36 into next will increase coverage by 1.18%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##            next      #36      +/-   ##
=========================================
+ Coverage   93.4%   94.59%   +1.18%
=========================================
  Files          6        6
  Lines         91      111      +20
  Branches      11       13       +2
=========================================
+ Hits          85      105      +20
  Misses         5        5
  Partials       1        1

Impacted Files
Coverage Δ

src/cli.js
0% <ø> (ø)
:arrow_up:

src/index.js
92.85% <100%> (ø)
:arrow_up:

src/utils/svg.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1521ed...6f50b3d. Read the comment docs.

I have to admit that the test names are not that ideal, I might change it before merging 🙈

@efegurkan While this is still slightly in progress (mostly the tests), I'd love to get some feedback :)

This seems good.
For the tests, since you are changing the API a lot, I will suggest not to care too much on Unit tests until you feel good about the plugin. When we did first implementation with @technopagan I made the code as much as "pipeline-ish" sense. In theory all of this parts can be moved to separate modules as you did in this PR. And most of them can be written side-effect free. :tada:
You may want to move svg templates to folder like fixtures maybe to make the tests more readable for future cases.
And I will suggest separating the default plugins to three part as:

Generating SVG
Modifiying/Altering SVG
Optimization

Feel free to name them as you like ofc :)
Very nice PR :+1:

Great and thanks for your nice words.
So, I will do clean up and proper naming later on, I like that very much.
Merged it, next step is async API 🥂


python2Packages.protobuf3_2 build is failing

Issue description
A test for python2Packages.protobuf3_2 is failing:
testMergeFrom (google.protobuf.internal.message_test.Proto3Test) ... /nix/store/bl48w7h24n6379fa200yv60n4pwynd9c-stdenv/setup: line 918:
  556 Segmentation fault /nix/store/frnm6ahmm6kzlh7sqrn09hdkkfyy9q39-python-2.7.13/bin/python2.7 nix_run_setup.py test

Bisecting proved the culprit is<PHONE_NUMBER>211694ff15e20a8472ca68c4a3c4a6. protobuf depends on gflags indirectly via google_apputils.
I'm not sure what to do here: disable the tests or downgrade gflags?
@FRidh

It looks like the update has breaking changes. It's probably better to keep both versions.

I cannot reproduce the issue:
$ nix-build -A python2.pkgs.protobuf3_2
/nix/store/96bjzvi232xpgip162sd5n0y7vq6g5q7-python2.7-protobuf-3.2.0

Maybe transient?

Uhm, this is strange. I wonder what's causing the segfault.

It really seems to happen only on my computer. I have to figure why nix is trying to build it instead of pulling the package from the binary cache.

maybe you have something like an overlay that modifies a dependency?

None that I'm aware of. How can I be sure? I tried building this and it still fails:
{ pkgs ? import <nixpkgs> {} }:

let
  src = pkgs.fetchFromGitHub {
    owner  = "nixos";
    repo   = "nixpkgs";
    rev    = "57f394572d2236c77f99aa48d98e62a4362d510c";
    sha256 = "0sxbcay5a8ccs3ldwcmhzb8nvlfmy1nmga0rk2i1nmz63k58fqm1";
  };
  nixpkgs = import src { };
in
  nixpkgs.python2Packages.protobuf3_2

I have built a VM identical to my system and inside it I could install protobuf3_2. Whatever it's causing this it's not in the global nixos configuration.

{ pkgs ? import <nixpkgs> {} }:

let
  src = pkgs.fetchFromGitHub {
    owner  = "nixos";
    repo   = "nixpkgs";
    rev    = "57f394572d2236c77f99aa48d98e62a4362d510c";
    sha256 = "0sxbcay5a8ccs3ldwcmhzb8nvlfmy1nmga0rk2i1nmz63k58fqm1";
  };
  nixpkgs = import src {config={}; };
in
  nixpkgs.python2Packages.protobuf3_2

I made one change: explicitly setting an empty config.

I can't test this anymore. After inspecting everything I could think of I gave up. I formatted the / partition and reinstalled nixos: It's gone. I would still like to know how to prevent it from happening again.

Maybe should have checked the store for corruption. Anyway, closing then.

Sorry for the trouble.


 This is a somewhat nontrivial problem known as map matching. Are there libraries to do this in JavaScript?

I found a potential solution using Nominatim, which is an OpenStreetMap API that contains a reverse-geocoding function. It gets the nearest address node to the inputted coordinates. I'll work on improving the function to catch edge cases, errors, etc.
The obvious limitation that the nearest node may be a significant distance from the coordinates, and therefore give the wrong street, however, there may be other ways of improving this accuracy.
My commit on repo fork

Thanks! Nominatim might give us a decent answer much of the time,, but it's not really geared towards the problem of matching a moving point to a road. OpenStreetMap has an API more suitable for this (http://project-osrm.org/docs/v5.22.0/api/?language=cURL#table-service).
But more importantly, it shouldn't be necessary to query an external API for this at all. The app is constantly fetching local OpenStreetMap tiles containing all relevant GeoJSON features, so the necessary data should already be on the device. The open question is how to choose which local road is the right one, and I was hoping the Python code snippets in the linked Medium article might translate to JavaScript. Basically, the input would be a handful of recent GPS points (like HeadingCalculator uses in app/js/spatial/heading.js) and the local OSM features filtered down to just roads (see nearbyFeatures in app/js/audio/callout.js). If we're lucky, the Turf.js library we're using for geospatial calculations already implements some of the geometry features used by the documented algorithms. Want to give one of those a try?

Ahh I see, I was wondering about how the tiles worked. I'll definitely look into it more today, and hopefully I'll work something out with Turf, if not I'll mess around with the libraries in the medium article.

I believe we've found a relatively accurate solution, and it has currently been implemented here:
https://github.com/jonha1/RCOS-soundscape-web-client/commit/e4cfd16cf4b48b7aef8042e37412c1869e5201c2
The function now uses tile data and turf.js functions to determine the nearest points (snap points) on all nearby roads. If the location is near an intersection (i.e. two roads within under 5 meters) it returns both the nearest 2 roads.

Nice work! If you open a pull request, I can give some feedback on the specific changes.
I'll note that returning multiple roads when near an intersection isn't ideal, since the first use of this information was going to be to improve intersection announcements, i.e. instead of just saying "intersection: A street, B street" we'd prefer to say "A street continues ahead, B street goes right". One way to fix this might be to just look back a few points to the last unambiguous current-road reading.

We now have nearest roads thanks to #11, but we'll need some additional logic to establish when a user is actually on a road, and also to use that to make intersection announcements more specific.


Modus Data Table(with tanstack) - Column visibility - Making the apply and cancel buttons usable to control the display of columns

Description

Making the apply and cancel buttons usable to control the display of columns.
Added keyboard navigation

References #1212, 1213
Type of change

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

How Has This Been Tested?

Checklist

[x] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

We have renamed our table component. This PR might not be useful anymore.


azure: docs: add AAD SP helper

Add a script to help the user create an Azure Active Directory Service Principal
Add instructions to docs for using this script

CC: @brendandburns

This should be okay to merge.


Can't build example diesel_embedded

What steps will reproduce the bug? (please provide code snippet if relevant)

copy the example code out of diesel_embedded
fixup the Cargo.toml to build outside the workspace with current versions

[package]
name = "diesel_embedded_test"
edition = "2021"
version = "0.6.0"

[dependencies]
diesel = { version = "2.2.4", features = ["postgres", "r2d2"] }
diesel_migrations = { version = "2.2.0", features = ["postgres"] }
postgresql_embedded = { version = "0.17" }
r2d2_postgres = "0.18.1"
tokio = { version = "1.41.0", features = ["full"] }

build failures

*What happens?
   Compiling postgresql_archive v0.17.2
error[E0277]: the trait bound `TracingMiddleware<DefaultSpanBackend>: reqwest_middleware::Middleware` is not satisfied
   --> /home/tweaver/.cargo/registry/src/index.crates.io-6f17d22bba15001f/postgresql_archive-0.17.2/src/repository/github/repository.rs:323:15
    |
323 |         .with(TracingMiddleware::default())
    |          ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `for<'a> Fn(reqwest::Request, &'a mut Extensions, reqwest_middleware::Next<'a>)` is not implemented for `TracingMiddleware<DefaultSpanBackend>`, which is required by `TracingMiddleware<DefaultSpanBackend>: reqwest_middleware::Middleware`
    |          |
    |          required by a bound introduced by this call
    |
    = help: the following other types implement trait `reqwest_middleware::Middleware`:
              GithubMiddleware
              RetryTransientMiddleware<T, R>
    = note: required for `TracingMiddleware<DefaultSpanBackend>` to implement `reqwest_middleware::Middleware`
note: required by a bound in `reqwest_middleware::ClientBuilder::with`
   --> /home/tweaver/.cargo/registry/src/index.crates.io-6f17d22bba15001f/reqwest-middleware-0.3.3/src/client.rs:51:12
    |
49  |     pub fn with<M>(self, middleware: M) -> Self
    |            ---- required by a bound in this associated function
50  |     where
51  |         M: Middleware,
    |            ^^^^^^^^^^ required by this bound in `ClientBuilder::with`

   Compiling diesel v2.2.4
For more information about this error, try `rustc --explain E0277`.
error: could not compile `postgresql_archive` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `postgresql_archive` (lib) due to 1 previous error

Information about your environment

postgresql_embedded version: whatever is in the example
Database version: whatever is in the example
Operating system: rehl8

Hello @tylerjw, thank you for reporting the issue.  I was able to reproduce this with version 0.17.2.  Version 0.17.3 was just released and appears to address the issue.

Sweet, thank you! Odd question, I wasn't able to figure it out through your docs. Is there a way I can specify a local path for using this in an environment where I don't have access to the internet?

You might want to take a look at Settings.installation_dir (https://github.com/theseus-rs/postgresql-embedded/blob/main/postgresql_embedded/src/settings.rs#L42-L43). The installation_dir is the path prefix without the PostgreSQL version number where the installation is located.  For instance if you set the installation_dir to /foo and the version to 17.0.1, and you manually installed PostgreSQL to /foo/17.0.1 I would expect that it would work without an internet connection.


Concrete poly

Because mutating a local variable is safe.

That's wrong. The relations hash isn't a mutable local variable, it's a "global" (almost) object. If our type system treats mutable objects as fine to mutate if they're bound to local variables, then that's unsound.

It's safe if no additional symbolic paths are introduced between the binding and use. Read my newest email.

A place where there are no symbolic paths introduced between "binding" of a local variable and the use:
#lang rosette
(define-symbolic a boolean?)

;; x : (CBoxof CInt)
(define x (box 0))

(if a
    (let ([y x])
      (set-box! y 1))
    (void))

;; has type CInt, but value (ite a 1 0)
(unbox x)

It matters where the object was created (and the lifetime of it, in the Rust sense of the word), not where the local variable was bound.

Yes ok you're right. Data structures need to be handled more carefully.

I'll try adding a case in lambda for an expected type of C→/•, and after that I'll see if just using C→/• in those places helps.

Actually, in this case, the patch is ok because hashes are unlifted right? But you're right for the lifted structures it wont work.

Yes, just use lambda/conc and C->/conc and it should work. I'm trying the same thing in my fork.


Cycle detection for STAR

I wanted to start the discussion on how we can handle cycles with the STAR protocol. I find this protocol extremely useful, but I think it's unreasonable to require systems to avoid cycles.
It seems the simplest solution is to just allow cycles and add a TTL and, optionally, an ID on messages. This way, messages won't propagate infinitely. Applications which need to ensure idempotency can make use of an ID, whether its part of the protocol or the message body itself. Obviously the downside is there's additional overhead with adding more onto the message.

I've thought about this.  I think cycle detection would be very useful.  A monotonically increasing id combined with a sender id would probably do the trick but would require all participants to keep a cache of recently seen messages.   A map of last id indexed by sender id is sufficient.
I'm glad someone else finds STAR useful. It is only in mangos so we have a lot of freedom to change as needed.
Sent from my iPhone

On Jan 10, 2015, at 11:59 AM, Tyler Treat<EMAIL_ADDRESS>wrote:
I wanted to start the discussion on how we can handle cycles with the STAR protocol. I find this protocol extremely useful, but I think it's unreasonable to require systems to avoid cycles.
It seems the simplest solution is to just allow cycles and add a TTL and, optionally, an ID on messages. This way, messages won't propagate infinitely. Applications which need to ensure idempotency can make use of an ID, whether its part of the protocol or the message body itself. Obviously the downside is there's additional overhead with adding more onto the message.
—
Reply to this email directly or view it on GitHub.

Simple answer here will be to just add a hop count, and give each message a TTL.  Loops will cause messages to be seen more than once, but the loops will terminate gracefully after some limit.  (And the hop count should be configurable-- for this protocol I'd probably set it fairly low, say 4, to minimize the damage caused by loops.)


*: move migration into self hosted

(Updated)
Previously, we are migrating the boot etcd onto pod IP network. With this change, we are migrating onto host network.

@hongchaodeng PTAL.

I'm OK with the workflow.
Just a few refactoring comments.

@hongchaodeng Can we get this merged?

lgtm


ci: Add initial CI scripts

Add base scripts to setup, run, and teardown tests
for ci.
Fixes: #21
Signed-off-by: Jose Carlos Venegas Munoz<EMAIL_ADDRESS>

lgtm

@chavafg branch updated.


Support MicroProfile 5.0

Since MicroProfile 5.0 was relaesed in Dec, we need to update starter to support MicroProfile 5.0.

Fixed by #471


add test generators and infrastructure

closes https://www.pivotaltracker.com/story/show/177633808
Motivation
We're starting to recognize a common need for random test helpers across Liberty repos. This PR creates a package to implement several of those functions so they may be used across repos without code duplication. This code is mostly stolen from sdk-ts and example-client.
Potential Issues

A couple of the the test helpers want to return a HexString. This is a type alias of string. I've redefined that alias here. I'm not really sure how that's going to play in other repos. If it conflicts, it's probably best to just have these functions return string.
The test functions that return a HexString prefix the string with '0x'. This looks more like a string representation of a hex integer literal than something that is natively a hex string. It seems wrong, but I've left it for compatibility.
The test functions are truly random, so any test that uses them are non-deterministic or semi-non-deterministic if the tests are seeded early. This could cause flaky test behavior at some point.

What's in this PR

Add generators.ts with several generators from example-client.
Add tests for the generators.
Add HexString type (see potential issue above)
Add README, LICENSE, dependencies, linting, docs, etc to make a typescript proper library.

👍


Adding scrollbar into the sidebar

Hi,
Is there any option to enable a scrollbar in the left sidebar?
Thanks

I think this is intentionally hidden by commit 60eb0af7fba12fa77f550924dc2060ba05997a1c, see #206

@agjohnson @ericholscher do you think it is reasonable that this could be an option?

What would the option do? I think currently we:

Allow scrolling when the sidebar overflows
Hide scrolling when the sidebar doesn't

I'm not sure what we would change?

I added:html_sidebar={'overflow:auto'}

We just had a reader without a scroll wheel / touchpad run into the same issue. A workaround for those readers seems to be to hit tab and then use the up and down arrows.

We're running into the same issue. On the laptops of our users the sidebar has no scrollbars but not all of the content is visible when opening some pages: https://global-coffee-data-standard.readthedocs.io/en/latest/explanation.html#environmental-farm-characteristics
It would already be very helpfull if you could show how to override the setting in my custom css.

The Ansible docs have a customized theme with a scrollbar in the nav, so I copied some styles and it seems to be be working for me. I added the following to a custom.css override file I have:
/* adds scrollbar to sidenav */
.wy-side-scroll {
  width: auto;
  overflow-y: auto;
}

I personally don't think it should be an option, as I know how painful it is to support all CSS options with future changes, and just be changed in the original theme styles. The reason being is because OSX, and I would assume other operating systems, give the option to hide/show scroll bars in their General settings, so that option exists at a global level essentially:

You can can see the changes live here: https://docs.ansible.com/ansible/devel/installation_guide/intro_configuration.html
and here: https://docs.netgate.com/pfsense/en/latest/

Thanks @jdillard your css is also working for me.


Add single-value types

In some cases, you want to have a type that has a single instance. For example, Ruby's TrueClass, FalseClass,  and NilClass all have a single value true, false, and nil correspondingly. To make it more generic we can have something like this
# uses .equal? in valid?
nil_type = Types::Constant(nil)
true_type = Types::Constant(true)

# uses .== in valid?
empty_list_type = Types::Value([])

This can be implemented with Constrained but maybe we need more predicates in dry-logic for that.
@solnic WDYT?

what'd be the difference between this and Types::Strict::Nil etc.?

I don't mean any difference for existing types, but it would allow building app-level constant types, e.g.
Success = Types::Constant('success')
Failure = Types::Constant('failure')

Result = Success | Failure

case result
when Success then # happy path
when Failure then #
end


Merge ign-common4 ➡  gz-common5

➡  Forward port
Port ign-common4  ➡  gz-common5
Branch comparison: https://github.com/gazebosim/gz-common/compare/gz-common5...ign-common4
Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

@mjcarroll I couldn't properly port https://github.com/gazebosim/gz-common/pull/561 since a lot has changed. Is it needed for gz-common5?

No, it's no longer necessary as we changed how the filesystem functions warn when switching to std::filesystem.


Feature/support bsd date

attempt to resolve #16
@lindsaylevine would you be able to test this?

looks like #15 also added a dependency on GNU date to paint.sh, so I'll need to tackle that too.

@BenBE would you be willing to look this over?

yo just got a chance to test. checked out your branch and getting the same old error

GitHub Actions supports MacOS and Windows runners. Might be a good way to catch issues like this.

@lindsaylevine I had a older branch (now deleted) and I think you might have gotten that one, sorry. I borrowed a machine to do some some sanity testing (no git installed) and fixed another issue. was able to produce a dates.txt that matched the old one, so I think you'l be good to go this time.
You'd expect a more straightforward way to get code from a PR. I grabbed a zip file from here https://github.com/wolfwood/abolish-ice-graphiti/tree/feature/support-bsd-date
@rossabaker that's interesting. I know nothing about docker, can we change the system clock?

@rossabaker also I started using https://www.shellcheck.net/ to review my code. it gives a lot of warnings, but if you are willing to add comments to the code to turn off the ones we don't care about we could use it as a pre-commit hook or something. I've never really used git hooks.

dates.sh now hangs forever on this log and doesnt change dates.txt
paint.sh behaves as normal (goes through [old] dates.txt)

@lindsaylevine its hanging on input. ./dates.sh < dow.txt > dates.txt

o 🤦♀  duh. works now!
worth updating the README in this PR to reflect what needs to be run?

@lindsaylevine yeah, README is definitely missing some important stuff. I think its also worth considering converting dates.sh to use default input and output file names that can be overridden on the command line, rather than using redirects.
I also think the larger flow can be automated more, including using the github API to make repos, switch default branches to trigger re-rendering of the contribution graph, etc, but that is worth having a discussion about on a dedicated issue.
in any case, very excited that OS X / BSD support is working!

I use pre-commit-hooks at $WORK, and I'm sure that shellcheck could be one, but it's probably just about as easy to add it in a GitHub Actions CI workflow.
I don't know how to change the time in a Docker container other than to invoke date inside of it.  I try to pass a stubbed out clock as an argument for testing, but not so easy in a shell script.

I'm gonna go ahead and merge this


Replaced test meta from +junit to +tests

Closes: #148

PR-Codex overview
This PR updates dependencies and package structure, and fixes some tests.
Detailed summary

Updated eo-runtime version to 0.29.4 in pom.xml.
Changed package structure in test files to org.eolang.txt.
Removed JUnit dependency from test files.
Updated failOnWarning parameter to false in eo-maven-plugin configuration in pom.xml.
Fixed regex-tests.eo tests.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@yegor256 I made this build run without errors and added one todo about failed tests. Can you please take a look?

@rultor merge

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 7min)


Missing Items

JC-only gems (like Crimson Sun), as well as most Band of Eternity rings, appear to be missing from tbcsim.com. Is it easy enough to add those?

All Band of Eternity variants are present, but you may need to update the item filter to Phase 3 to see anything beyond the base model.
Adding JC-only gems should be no problem!

Thanks. For some reason the only ring visible to me with a Phase 2 filter is Band of Eternity (Restorer, Honored). The rest are only visible in Phase 3. But I can just switch to that, no problem.


Let upstream foundry coexist on the machine

Component
Other (please describe)
Describe the feature you would like
As of now foundry-zksync conflicts with upstream foundry on the developer machine. This is fine assuming that the user will never need to compile anything for any other chain than zkSync. This assumption is obviously wrong, the users need to compile for BOTH zkSync and other chains, often as a part of the same workflow. Using foundry-zksync for anything other than building for zkSync is a mistake for a number of reasons:

Forks always lag behind the upstream.
Forks usually introduce new bugs.
Bugs found while using a fork have a hard time being accepted and fixed upstream.
Tooling built around foundry will keep using upstream foundry leading to differences. E.g. the foundry GitHub action will use a different toolkit from what the developer has on their machine.
Tooling expecting upstream foundry on the user machine may or may not work. E.g. Slither.
It's a bad practice to force the developers to change the tools for all their projects because they sometimes need to compile something for zkSync. For me it feels abusive and disrespectful, like entering a walled garden.

The solution is to allow both upstream foundry and foundry-zksync on a single machine. This would also improve the UX of foundry-zksync, e.g. by providing defaults that are sane when compiling for zkSync. The user wouldn't need to remember to pass a number of flags to forge like --zksync or --zk-compile, they could just run forge-zksync and the defaults would be correct out of the box.
Additional context
No response

Hi @CodeSandwich we already have a work stream dedicated to figuring out how to co-exist with foundry tools. The solution is unfortunately not as simple as renaming the binary, so it'd take some time until a seamless solution is available.
In the meantime, we recommend our users to either make use of either bash aliases, custom installs, or to stick to either upstream or foundry-zksync depending upon the use case.

That's great news, I'm very happy to learn that you've been working on this problem!
Which method of installing foundry-zksync along upstream foundry would you recommend as of today?

Which method of installing foundry-zksync along upstream foundry would you recommend as of today?

I'd recommend to install/download the latest foundry-zksync nightly binaries and rename them as forge-zksync, cast-zksync, etc. and put them in your PATH.

We're currently working on a solution on a code/config-level so the foundry-zksync would be usable via foundry-upstream itself.
We opted out of renaming the binaries owing to legacy behavior, and the fact that it would be a subjective change where certain users might prefer the other way -  so we'd like to fix it the right way to avoid introducing hacky interfaces like bash script renames, that the individual user can do as per their liking on their end.

Got it, thanks for the explanation. I can't wait for the proper solution, it indeed sounds very user friendly and proper.
Should I close this issue as unnecessary since you're already working on it? Or would you prefer keeping it open to mark this problem as known?

I'll keep it open to track it in our internal board, that way you also get notified when the feature lands.


[SPARK-24526][build] Spaces in the build dir causes failures in the build/mvn script

What changes were proposed in this pull request?
Fix the call to ${MVN_BIN} to be wrapped in quotes so it will handle having spaces in the path.
How was this patch tested?
Ran the following to confirm using the build/mvn tool with a space in the build dir now works without error
mkdir /tmp/test\ spaces
cd /tmp/test\ spaces
git clone https://github.com/apache/spark.git
cd spark
# Remove all mvn references in PATH so the script will download mvn to the local dir
./build/mvn -DskipTests clean package

Please review http://spark.apache.org/contributing.html before opening a pull request.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Test build #91696 has started for PR 21534 at commit bb12f3e.

Test build #91696 has finished for PR 21534 at commit bb12f3e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91696/
Test FAILed.

retest this please

Test build #91709 has started for PR 21534 at commit bb12f3e.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91709/
Test FAILed.

retest this please

Test build #91975 has started for PR 21534 at commit bb12f3e.

Test build #91975 has finished for PR 21534 at commit bb12f3e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91975/
Test PASSed.

@trystanleftwich, mind if I ask fix the title to  [SPARK-24526][build][test-maven] Spaces in the build dir causes failures in the build/mvn script so that Jenkins triggers a build with Maven and then we can see if the build still passes for sure?

@HyukjinKwon  Updated the title per your request.

retest this please

Test build #91998 has finished for PR 21534 at commit bb12f3e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91998/
Test FAILed.

retest this please

Test build #92002 has started for PR 21534 at commit bb12f3e.

Test build #92002 has finished for PR 21534 at commit bb12f3e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92002/
Test FAILed.

retest this please

Test build #92009 has started for PR 21534 at commit bb12f3e.

Test build #92009 has finished for PR 21534 at commit bb12f3e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92009/
Test FAILed.

Merged build finished. Test FAILed.

Merged to master. It ran mvn correctly anyway.


Bug report: Cannot run gpg, Cask doesn't know it's tapped

Description of issue
As described in #24072, whenever I submit a Cask to be updated through the automated mechanism, it fails with a message about the remotes not existing.
Output of `brew doctor`
Chris-Finazzos-MacBook-Pro:~ Chris$ brew doctor
Your system is ready to brew.

Output of `brew cask doctor`
Chris-Finazzos-MacBook-Pro:~ Chris$ brew cask doctor
==> macOS Release:
10.11.6
==> Hardware Architecture:
intel-64
==> Ruby Version:
2.0.0-p648
==> Ruby Path:
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
==> Homebrew Version:
Homebrew 0.9.9 (git revision 8e29cf; last commit 2016-08-28)
Homebrew/homebrew-core (git revision 7b73; last commit 2016-08-29)
==> Homebrew Executable Path:
/usr/local/bin/brew
==> Homebrew Cellar Path:
/usr/local/Cellar
==> Homebrew Repository Path:
/usr/local
==> Homebrew Origin:
https://github.com/Homebrew/brew.git
==> Homebrew-Cask Version:
0.60.0 (git revision 51035; last commit 5 hours ago)
==> Homebrew-Cask Install Location:
<NONE>
==> Homebrew-Cask Staging Location:
/usr/local/Caskroom
==> Homebrew-Cask Cached Downloads:
/Users/Chris/Library/Caches/Homebrew/Cask
0 files, 0B
==> Homebrew-Cask Default Tap Path:
/usr/local/Library/Taps/caskroom/homebrew-cask
==> Homebrew-Cask Alternate Cask Taps:
==> Homebrew-Cask Default Tap Cask Count:
3277
==> Contents of $LOAD_PATH:
/usr/local/Library/Homebrew/cask/lib
/usr/local/Library/Homebrew
/Library/Ruby/Site/2.0.0
/Library/Ruby/Site/2.0.0/x86_64-darwin15
/Library/Ruby/Site/2.0.0/universal-darwin15
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/universal-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/x86_64-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin15
==> Contents of $RUBYLIB Environment Variable:
<NONE>
==> Contents of $RUBYOPT Environment Variable:
<NONE>
==> Contents of $RUBYPATH Environment Variable:
<NONE>
==> Contents of $RBENV_VERSION Environment Variable:
<NONE>
==> Contents of $CHRUBY_VERSION Environment Variable:
<NONE>
==> Contents of $GEM_HOME Environment Variable:
<NONE>
==> Contents of $GEM_PATH Environment Variable:
<NONE>
==> Contents of $BUNDLE_PATH Environment Variable:
<NONE>
==> Contents of $PATH Environment Variable:
PATH="/Users/Chris/.rbenv/shims:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/Library/Homebrew/cask/cmd:/usr/local/Library/Homebrew/shims/scm"
==> Contents of $SHELL Environment Variable:
SHELL="/bin/bash"
==> Contents of Locale Environment Variables:
LANG="en_US.UTF-8"
==> Running As Privileged User:
No

The line ==> Homebrew-Cask Install Location: <NONE> makes me think that this is an artifact of the Caskroom migration as brew tap shows the following:
Output of `brew tap`
Chris-Finazzos-MacBook-Pro:~ Chris$ brew tap
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
No changes to formulae.
caskroom/cask
homebrew/completions
homebrew/core
homebrew/dupes
vitorgalvao/tiny-scripts

As a result, when I attempt to submit a Cask the following errors occur:

Thanks for the detailed bug report.
It looks like HBC might not have been forked and the remote url set properly.
Can you:
Delete and refork the repo from github (just to kill any errant branches)
cd "$(brew --repository)"/Library/Taps/caskroom/homebrew-cask/Casks; git checkout master
and check the output of git remote -v
Should be something like:
adidalal	https://github.com/adidalal/homebrew-cask.git (fetch)
adidalal	https://github.com/adidalal/homebrew-cask.git (push)
origin	https://github.com/caskroom/homebrew-cask (fetch)
origin	https://github.com/caskroom/homebrew-cask (push)

If not, do git remote add chrisfinazzo https://github.com/chrisfinazzo /homebrew-cask.git
That should fix things - let me know how it goes.

Tl;dr I had an issue with gpg2 that needed to be fixed. I may have accidentally set keys to expire previously without realizing. It looks like @mjsteinbaugh has the same PR elsewhere, pull as you see fit.


Obtaining index values in v5

Hi, just getting started with LiteDB, trying out v5 beta.
If I have a collection of objects with an index on Name, how do I get all the Names from the database, rather than all the objects?
Also, do you think v5 will be done within 4 months? Trying to decide if I'm ok to start out on v5 based on the timeline for my project.
Thanks!

Guess this is a duplicate of #269 except the fix referenced there no longer seems to exist.

Hi @matelich, in v5 you can run this query:
SELECT name FROM customer
If you have index index name field, your query will be run only over index. You can see here (lookup loader uses only index key):
(select with no index)

(after create index)

(but if you add more fields in you query, query engine will return to document lookup loader)

v5 status: still in beta but I'm working hard to deliver as soon as possible. My plans still release this month, but maybe will I will not deliver new documentation/new site.

Excellent, looks like I'd wrap that in a db.Execute().
Thanks for the quick response and the progress on a new version, @mbdavid!


Http triggers using https

Content must go through a pre-merge checklist.
Pre-Merge Content Checklist
This documentation has been checked to ensure that:

[x] The title, template, and date` are all set
[x] File does not use CRLF, but uses plain LF (hint: use cat -ve <filename> | grep '^M' | wc -l and expect 0 as a result)
[x] Has passed bart check

[x] Has run npm run build-index
[x] Has been manually tested by running in Spin/Bartholomew (hint: use PREVIEW_MODE=1 and run npm run styles to update styling)

[x] Headings are using Title Case
[x] Code blocks have the programming language set to properly highlight syntax and the proper copy directive
[x] Have tested with npm run test and resolved all errors

I am checking why links still show up as broken

Thanks @itowlson
Instead of this new page, we can create a succinct subsection on the existing HTTP Trigger page. That will be much neater and straight to the point. I will close this one out.
Thanks
Tim


Memory allocation failed

Hello! Is this code designed for a specific revision of the CircuitPlayground Express? have been working to get this running on the ATSAMD21 revision and encounter memory errors when the full script attempts to upload.

I'm try to fixed your code but still not work so Do you have some recommand?


[CDMF-3] Managing policies of managed-devices

Reference: https://wso2.org/jira/browse/CDMF-3

Issue is not clear enough.


Support conditionals

It was decided not to support conditionals yet due to many edge cases that can not be handled at the moment


LFS checksum bug

Gitea version (or commit ref): 339d7de409fae0502f970e1ddd73c2a046236407
Git version: 2.14.1
Operating system: Linux Alpine (Gitea Docker)
Database (use [x]):

[x] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes
[x] No
[ ] Not relevant

Log gist:

Description
Hello,
I was about to push our source code into our new repos (all clean) with LFS enabled. All except one repo could be pushed. The one repo returned an i/o timeout when uploading one specific LFS File.
I was able to recreate the problem by creating a completly new repo with .gitignore, .gitattributes and the problematic file. LFS wont upload the file to the server. Afterwards I shrunk the file size down to 17 bytes that still wont be pushed (see Client Side).
Server Side (Gitea, Docker)

[Macaron] 2017-10-04 14:21:17: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:21:18: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 138.252134ms
[Macaron] 2017-10-04 14:21:28: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:21:28: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 81.95643ms
[Macaron] 2017-10-04 14:21:38: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:21:38: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 86.223643ms
[Macaron] 2017-10-04 14:21:48: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:21:48: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 42.738494ms
[Macaron] 2017-10-04 14:21:58: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:21:58: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 5.895199ms
[Macaron] 2017-10-04 14:22:08: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:22:08: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 8.244827ms
[Macaron] 2017-10-04 14:22:18: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:22:18: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 6.07595ms
[Macaron] 2017-10-04 14:22:28: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:22:28: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 5.537536ms
[Macaron] 2017-10-04 14:22:38: Started POST /powercoder/test-lfs.git/info/lfs/objects/batch for <IP_ADDRESS>
[Macaron] 2017-10-04 14:22:38: Completed /powercoder/test-lfs.git/info/lfs/objects/batch 200 OK in 5.709606ms`

Client Side (Windows LFS 1.3.1)

$ git lfs push --all origin master
Git LFS: (0 of 1 files, 36 skipped) 153 B / 17 B, 1.36 MB skipped
LFS: Put http://<IP_ADDRESS>:3000/powercoder/test-
lfs/info/lfs/objects/f8051d7550d50d1ea25ad9f972055c43e67cae7e654ae3488ef40dcffa9141d4: read tcp <IP_ADDRESS>:61993-><IP_ADDRESS>:3000: i/o timeout

with the file in question being test.ttf (17 Bytes; it once was a ttf file):

$ git lfs ls-files
f8051d7550 * test.ttf

test.ttf (Hex dump):

00 00 02 00 00 F0 00 00 00 01 00 00 00 00 00 00 00

test.zip
When changing any of the non-zero values to some different hex value, the files gets uploaded and the push completes successfully.
Expected output
The file being pushed. Tested with the https://github.com/git-lfs/lfs-test-server which accepts the file as-is, no questions asked. Gitea on the otherhand seems to bug out.
As I don't know how Gitea handles LFS files internally I can only guess it to be some sort of checksum error. My current workaround is not adding the file to LFS which is not a viable solution in the long run.
I tried https://try.gitea.io but there is no LFS to test my issue.
https://try.gitea.io/TheRealPowerCoder/lfs-test
Thanks.
Screenshots

Can not reproduce it with latest master version. File is accepted and uploaded successfully


Create Mailto: Link w/Obfuscator

Hello. I am using the Twig implementation (with Symfony). I was wondering if there was any way to add a link to the obfuscated email address easily.
So far I tried this, which the inner html in the mailto doesn't work because of the script tags:
{{ email.address|obfuscateEmail }}

and this, which just dumps the whole string as plain text, I tried the twig |raw, but I don't think that will work since Javascript is really outputting the string.
{{ '' ~ email.address ~ ''|obfuscateEmail|raw}}

Thank you for the great plugin!

Hi there
Normally the obfuscator scans for mailto anchor tags and parses them correctly. I'm not very proficient in Twig, so this is a dark topic for me as well.
Perhaps you could try assigning the full anchor string to a variable and then do something like {{ anchorVar|obfuscateEmail }} ?
I don't have a clue myself why your second example doesn't work, so if you would find any causes, I'd be glad to fix them.

Thank you for giving me an idea. I was trying to concatenate the string, but I forgot one important thing, you have to assign the variable or use parentheses on the string or else the filter only worked on ''|obfuscateEmail and ignore the rest.
So this works both ways:
{% set emailURL = '' ~ email.address ~ '' %}
{{ emailURL|obfuscateEmail }}

 {{ ('' ~ email.address ~ '')|obfuscateEmail }}

Not really anything to do with your package, just how Twig works. Figure I would post in case someone else has the same issue. Definitely a derp moment, Thanks!


Refactor

Codecov Report

Merging #11 into master will increase coverage by 1.52%.
The diff coverage is 34.69%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
+ Coverage   43.16%   44.69%   +1.52%
==========================================
  Files           1        1
  Lines         183      179       -4
==========================================
+ Hits           79       80       +1
+ Misses        104       99       -5

Impacted Files
Coverage Δ

trytravis.py
44.69% <34.69%> (+1.52%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1f5d741...e6eaa8b. Read the comment docs.