Add optional logout menu entry.

This pull request add and optional logout menu entry, configured by two configuration variables in the [web] section:

logout_url: the target URL of the logout menu entry
logout_text: the displayed text in the logout menu entry

Please note that the link will not perform any logout by itself. I is the responsibility of the system administrator to make something useful out of the link.
For instance, when running dns-ui behind Nginx as a reverse proxy (using the auth_request module) , with oauth2-proxy and Keycloak OIDC as authentication client, the following snippets can be useful:
In Nginx config:
location /logout {
	return 302 http://<url_of_your_openauth2_proxy_instance>/sign_out?rd=<url_of_page_to_display_after_logout>;
}

In oauth2-proxy config:
backend_logout_url="http://<url_of_your_keycloak_instance>/realms/<realm_name>/protocol/openid-connect/logout?id_token_hint={id_token}"

This potentially closes #20.


Generates a client that regroups all the service clients

If a client program needs to use all the services of a package, it can become
tedious to setup and keep a hold on each service client.
This patch generates a package-level client that regroup all the service client in
a single struct, with some helpers to set all the timeouts or encoding.
It also holds the services parameters.

Needs a little more testing (and rebasing) on my side before merging.


errors installing dependencies

This error suggests that there is no compatible version of ray[default,tune] package that satisfies the minimum version requirement specified in finrl package. It also indicates that some versions of ray[default,tune] have additional requirements that are not compatible with the current Python version. You could try installing a different version of finrl that is compatible with your Python version or try upgrading your Python version to a compatible version that satisfies all dependencies.

ERROR: Ignored the following versions that require a different python version: 1.21.2 Requires-Python >=3.7,<3.11; 1.21.3 Requires-Python >=3.7,<3.11; 1.21.4 Requires-Python >=3.7,<3.11; 1.21.5 Requires-Python >=3.7,<3.11; 1.21.6 Requires-Python >=3.7,<3.11
ERROR: Could not find a version that satisfies the requirement ray[default,tune]>=2.0.0 (from finrl) (from versions: none)
ERROR: No matching distribution found for ray[default,tune]>=2.0.0


Do you have AIM dataset's links？I find it‘s hard to get its train datas.

HELLO!Thank you for your work ,do you have AIM dataset's links？I find it‘s hard to get its train datas.

HELLO!Thank you for your work ,do you have AIM dataset's links？I find it‘s hard to get its train datas.

Please see this issue #9

HELLO!Thank you for your work ,do you have AIM dataset's links？I find it‘s hard to get its train datas.

Please see this issue #9

Thank you for your kindly help!!!(˘︶˘).。.:*♡


[AIRFLOW-447] Store source URIs in Python 3 compatible list

In Python 2 map would generate a list, in Python 3 this is no longer true.
Downstream a job with source_uris set to a Python 3 map object cannot be json-serialized
when attempting to store the job in the database.
This fix keeps the source_uris in a json-serializable list in both Python 2 and 3.
Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:
- https://issues.apache.org/jira/browse/AIRFLOW-447
Testing Done:
- Successfully ran BigQuery-related operators on Python 3.5.

Current coverage is 64.93% (diff: 100%)

Merging #1754 into master will increase coverage by 0.03%

@@             master      #1754   diff @@
==========================================
  Files           128        128
  Lines          9630       9630
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6250       6253     +3
+ Misses         3380       3377     -3
  Partials          0          0

Powered by Codecov. Last update 3cba29e...5e9a935

Looks much better! One nit: can you remove the "Dear airflow..." from your commit? If done, I will merge.

@bolkedebruin sure can do. Just that line or the line and everything below it?

@bolkedebruin yea makes sense. Done now.


Update submodules.

Merging this without approval since it is only updating the submodules and is required to fix ROS-deployment for GHAE ring.


[BUG] Scaled CRPS is possibly incorrect

Our implementation of scaled crps scales each timeseries according to the absolute value of the observed values of each timeseries, but the original GluonTS implementation (and the one we also follow in hierarchicalforecast) scales the CRPS based on the norm calculated across all timeseries.
Is this intentional?
To make things concrete, the following shows how the code for a Pandas DF should be adapted to reflect the GluonTS / HF behavior.
loss = loss.set_index(id_col)
sizes = sizes.set_index(id_col)
assert isinstance(df, pd.DataFrame)
- norm = df[target_col].abs().groupby(df[id_col], observed=True).sum()
+ norm = df[target_col].abs().sum()
- res = 2 * loss.mul(sizes['counts'], axis=0).div(norm + eps, axis=0)
+ res = 2 * loss.mul(sizes['counts'].sum(), axis=0).div(norm + eps, axis=0)
res.index.name = id_col
res = res.reset_index()

I think the whole point of having a scale is for the metric to be comparable across series, similar to MASE.


RPi Zero W 2 64 bit

Is there an image available for the rpi zero w 2?
The readme says I am supposed to use aarch64-rpi3-linux-gnu, but when I do, I get cannot execute binary file: Exec format error
This is the file info for the cross-compiled executable:
/usr/local/bin/python3.9: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 5.8.18, with debug_info, not stripped
This is uname -a
Linux rpi 5.13.0-40-generic #45-Ubuntu SMP Tue Mar 29 14:48:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Did I install the wrong system image for my pi?
Thanks for creating this project though, it's really useful for projects with large dependencies such as opencv!

This is uname -a
Linux rpi 5.13.0-40-generic #45-Ubuntu SMP Tue Mar 29 14:48:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

This is very odd. It's not clear to me why the Pi would report x86_64 as architecture. Which image did you install to the Pi?

Honestly, I might just do a reinstall. I might have messed something up.
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

and the file of an executable that works:
file /usr/bin/ls
/usr/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=81004d065160807541b79235b23eea0e00a2d44e, for GNU/Linux 3.2.0, stripped

So it seems as if the system is just a normal 32-bit install of Raspbian and uname -a is wrong.
I installed the armv8-rpi3-linux-gnueabihf and it seems to work now. Thanks for your support!


Rename schematron ead3.sch

Rather than ead.sch, change it to ead3.sch to keep it consistent with the schema names.

Looks good. Closing.


Unify FactGenerator/Datalog relation names

As of #40, the Fact Generator and Datalog code share a list of file/relation names. The Fact Generator refers to relations by group::rel, e.g., variable::name, whereas that corresponds to the Datalog relation variable_name. While there is a clear correspondence between variable::name and variable_name, the relationship doesn't hold in general, e.g. we also have variable::id corresponding to just variable. Thus, predicates.inc has lines like:
PREDICATE(global_var, unmangl_name, global_variable_has_unmangled_name)

where the first two entries describe the C++ (Fact Generator) name, and the third entry describes the filename/Datalog relation name. We should try to derive the latter from the former for the sake of consistency. This will involve changing a ton of Datalog code to use new relation names.

There is some urgency to this task: It's important to do this early in the git history if we're to do it at all. The git history of this project is fairly empty at this point, but someday will encode important choices about how the analysis was constructed.

For the sake of posterity, here are the major areas where they disagree, and how I'm approaching them in #45:

Abbreviations, e.g., global_var vs. global_variable: I'm picking something clear but brief and documenting it in the dev docs
"infixes" such as _has_ and _in_: These are mostly redundant, so I'll remove them
id: The FactGenerator has e.g. variable::id which corresponds to just variable in the Datalog. Not yet sure what to do about this.


build error: undefined reference to `open3d::core::Tensor::~Tensor()'

I'm very interesting in your work. I have spent a lot of time to build the codes on ununtu20.04,  but it still have problems. The environment I used is as the follow:

Ubuntu20.04
Open3D v0.15.1
python=3.7
pybind=2.10.0dev1

I have build the Open3D from source successfully. Then, I have install Misc3D according to your tutorial, the commands are as follows
git clone https://github.com/yuecideng/Misc3D.git

cd Misc3D

mkdir build
mkdir misc3d_install
cd build

cmake -DCMAKE_PREFIX_PATH=/home/subchange/dev_build/Open3D/install -DCMAKE_INSTALL_PREFIX=../misc3d_install ..

Note that the path /home/subchange/dev_build/Open3D/install  is the path where I have install Open3D
Please see the errors in the follow

I do not good at c++ language. Cloud you please give me some help to build the project from source? Thank you very much.

Hi, could you show me your cmake configuration for open3d？ Please check that -DGLIBCXX_USE_CXX11_ABI=ON is set when you build open3d from source.

I have build Open3D using the follow commands:

git clone --recursive https://github.com/intel-isl/Open3D
git checkout v0.15.1

util/install_deps_ubuntu.sh -y

mkdir build
mkdir install
cd build

conda activate py37
which python

cmake -DCMAKE_INSTALL_PREFIX=../install -DCMAKE_BUILD_TYPE=Debug ..

make -j4
make install -j4
make pip-package

It has generate the *.whl file (build/lib/python_package/pip_package/open3d-0.13.0+c3f9de224-cp37-cp37m-manylinux_2_31_x86_64.whl)
The result are as follows:

Maybe try to set -DDBUILD_SHARED_LIBS=ON  to build shared library for open3d, since I did not try static library under linux platform...
I will try your configuration mentioned above to see how to solve this probelm. But it may take some time.

hello, thank you for your help. I have rebuild the Open3D with CMAKE_BUILD_TYPE=Release, -DBUILD_SHARED_LIBS=ON  and -DGLIBCXX_USE_CXX11_ABI=ON. Open3D was successfully build, but there are some warnings during building as the follow. However, I have not encountered these warnings with  CMAKE_BUILD_TYPE=Debug

Then, when I build MIsc3D, no errors occurred, again only some warnings

After I set path in ~/.bashrc, I successfully ran the following code.
import numpy as np
import time
from random import random
import open3d as o3d
import misc3d as m3d

pcd = o3d.io.read_point_cloud('../data/segmentation/test.ply')

t0 = time.time()
results = m3d.segmentation.segment_plane_iterative(pcd, 0.01, 100, 0.1)
print('Segmentation time: %.3f' % (time.time() - t0))

show = []
for cluster in results:
    w, c = cluster
    c.paint_uniform_color(np.array([random(), random(), random()]))
    show.append(c)

o3d.visualization.draw_geometries(show, 'Iterative Plane Segmentation')

I don't know if there is anything wrong with those warnings, have you encountered them during building from source?
In sum, though some warnings occurred, It seems that it works. It works anyway. I have listed my commands as follows:
Open3D
git clone --recursive https://github.com/intel-isl/Open3D
cd Open3D

git tag
git checkout v0.15.1

git submodule update --init --recursive

util/install_deps_ubuntu.sh -y

mkdir build
mkdir open3d_install
cd build

conda activate py37
which python

cmake -DCMAKE_INSTALL_PREFIX=../open3d_install -DCMAKE_BUILD_TYPE=Debug .. #Failed

cmake -DBUILD_SHARED_LIBS=ON -DGLIBCXX_USE_CXX11_ABI=ON -DCMAKE_INSTALL_PREFIX=../open3d_install -DCMAKE_BUILD_TYPE=Release ..

make -j4
make install -j4
make pip-package

Misc3D
git clone https://github.com/yuecideng/Misc3D.git

cd Misc3D

mkdir build

mkdir misc3d_install

cd build

conda activate py37

cmake -DCMAKE_PREFIX_PATH=/home/subchange/dev_build/Open3D/open3d_install -DCMAKE_INSTALL_PREFIX=../misc3d_install ..

make install -j

It should be mentioned that I have make some modifications to the Misc3D/CMakeLists.txt file in line 72 to help it found Open3D library.
#find_package(Open3D REQUIRED NO_DEFAULT_PATH)
find_package(Open3D REQUIRED)
message(STATUS "Open3D_DIR = ${Open3D_DIR}")
message(STATUS "Open3D_INCLUDE_DIRS = ${Open3D_INCLUDE_DIRS}")
message(STATUS "Open3D_LIBS = ${Open3D_LIBS}")

Glad to hear that.
The warning messages can be mostly igored. Don't worry about them.  You can set -DOpen3D_DIR=/path/to/install/open3d to cmake configure without change the original CMakeLists.txt.

Glad to hear that.
The warning messages can be mostly igored. Don't worry about them. You can set -DOpen3D_DIR=/path/to/install/open3d to cmake configure without change the original CMakeLists.txt.

I have tried this setting -DOpen3D_DIR=/path/to/install/open3d, however, it didn't work. I delete NO_DEFAULT_PATH in the sentence find_package(Open3D REQUIRED NO_DEFAULT_PATH) and set -DCMAKE_PREFIX_PATH=/home/subchange/dev_build/Open3D/open3d_install, then, it works. Anyway, it works now. thank you very much.


Download errors

Hello. I'm enjoying using TwitchLink. Thank you for creating the program.
It's happened several times recently where I set up a scheduled download, run it, and then it freezes a few hours later.
This happened yesterday. A streamer was broadcasting for 8 hours. The streamer broadcast for 5 hours and the recording was only 4 hours. I realized it wasn't working anymore, so I turned the program off and on again and ran the download again. It recorded for about an hour and then froze again. I turned it off and on again and ran the download again and it finished recording. I ended up with 3 files in one broadcast.
I have no idea why this happens so often.
My suggestion is that it shouldn't happen, but I would like a notification window to pop up when it does.

Duplicate of #68


Per-file exceptions support

Close #34

WIP: docs

Any chance to release it as is?

+1 for releasing it as is. really looking forward to this feature.

Released in 0.4.0 :tada:


GitHub Actions - Add static code analysis

Is it already done?

No, not done. Any tickets which are still in status "Open" means not done. We're also open to contributions https://github.com/valentinacupac/banking-kata-java/blob/main/CONTRIBUTING.md

@rashed-08 if you're interested in contributing on this one, you can make a PR.


Menus are inconsistent

Many standard NSTextView/NSResponder menu items are enabled while they have no effect or make no sense. In particular, this makes Fragaria's context menu 100% useless.

1da032f improves the situation somewhat. Eventually the context menu should incorporate the most useful features of the Text menu in the examples.

Another improvement in 707e398.


Add Russian translation

Translation of the site into Russian. The posts are not translated.

Sorry for getting to this late, I was busy when this dropped and kinda forgot about it since. Taking a look now.


Add link to YouTube video

Should we add a link to the YouTube video and/or other resources (e.g. conference agenda entry) to the README? I think both would be useful: The video, for people just looking for the video, and the conference agenda to have two-way linkage.

Should we add a link to the YouTube video

Sounds good to me. Feel free to make a PR

conference agenda entry

That link seems to be https://live.juliacon.org/talk/VAGFD7. Thus, I'm not sure whether it will be permanent or not (there is nothing specific to JuliaCon 2021 in the URL).

Should we add a link to the YouTube video

Sounds good to me. Feel free to make a PR

Will do, likely not before the Trixi meeting tomorrow.

conference agenda entry

That link seems to be https://live.juliacon.org/talk/VAGFD7. Thus, I'm not sure whether it will be permanent or not (there is nothing specific to JuliaCon 2021 in the URL).

It is not, as per @aviks:

This URL will be live till next JuliaCon. After that, it will be archived somewhere. But I'm not sure where exactly.

Thus I think we should just include the link to the video.


ExpressionProperties between individual formly field usage

I am using formly for certain case, when I do not use the form predefined structure, just want to use an individual field, as it contains everything what I need, like validations, but let me to have more dynamic template structure.
I have one extra component, like:
<app-single-formly-field [value] (valueChange) [fieldConfig] [state?] />
Which will create one formly field but wrappered by formly-form. Couldn't use formly-field directly, as it doesn't fire expressionProperties evaluation and validations. (Is there any way to do it without formly-form ?)
I would like to connect 2 individual fields, to use the expression properties and the validations. Is there any way to have those 2 in one model / one state ?
I tried to use formGroup settings for the field and for the formly-form, but it doesn't seem to have any effect. Also tried to inject the formGroup via directive ([formGroup]="group"), but in the end both cases they won't store in one model, but in 2 individual ones.

Created an example, maybe that helps a bit: https://stackblitz.com/edit/angular-xm4ucn-2cunn1

After some investigation, didn't find a proper solution, where the fields are not rendered, but only in template.
One of the attempt was something like this:
<div formlyForm>
  <formly-field [field]="dateFieldConfig"></formly-field>
  [Nasty custom template]
  <formly-field [field]="typeFieldConfig"></formly-field>
</div>

I tried to make a directive, where the [formlyFrom] just collects all content, and initializing the form skeleton (expressionProperties and other validations), but not render the fields yet. Wasn't success without altering the current implementation, as I couldn't override formly-form class implementation via inheritance.
At the moment I solved it with sharing the state like:
<app-single-formly-field #dateField [value] (valueChange) [fieldConfig] [state?] />
<app-single-formly-field [value] (valueChange) [fieldConfig] [state]="{ selectedDate: dateField.value }" />

which works fine, but was hoping for more straightforward solution, as merging 2 forms models somehow.
If you have any advice about the solution let me know, maybe I didn't find something clever feature which would help in my case.
PS: Are you planning to support dynamic template solutions ?

In v6 you will be able to override template quite easily. This include base
types like formly-field / formly-group.
As for what you are looking for, could you give the use case directly so I
can better understand and hopefully provide some insight? I'm not exactly
following what you are trying to do.
On Fri, Sep 10, 2021, 5:31 AM Greegko @.***> wrote:

After some investigation, didn't find a proper solution, where the fields
are not rendered, but only in template.
One of the attempt was something like this:

  [Nasty custom template]

I tried to make a directive, where the [formlyFrom] just collects all
content, and initializing the form skeleton (expressionProperties and other
validations), but not render the fields yet. Wasn't success without
altering the current implementation, as I couldn't override formly-form
class implementation via inheritance.
At the moment I solved it with sharing the state like:
<app-single-formly-field #dateField [value] (valueChange) [fieldConfig] [state?] />
<app-single-formly-field [value] (valueChange) [fieldConfig] [state]="{ selectedDate: dateField.value }" />
which works fine, but was hoping for more straightforward solution, as
merging 2 forms models somehow.
If you have any advice about the solution let me know, maybe I didn't find
something clever feature which would help in my case.
PS: Are you planning to support dynamic template solutions ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ngx-formly/ngx-formly/issues/2977#issuecomment-916803086,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADB4XNKIJKAG3STILS2DH7LUBHM77ANCNFSM5DUH466Q
.

As for what you are looking for, could you give the use case directly so I
can better understand and hopefully provide some insight? I'm not exactly
following what you are trying to do.

I have created an example for it:

Created an example, maybe that helps a bit: https://stackblitz.com/edit/angular-xm4ucn-2cunn1

I have two forms, and they should have an interaction between them, in this case expressionProperties evaluation or validation. In the code example, each field is a form itself due to the implementation, but the question still applies to them, how they can see each other through configuration and not external component based implementation.
    expressionProperties: {
      'model1.echo_input': 'model2.hello_input',
    }

To get rid of formly-form I see two missing parts:

Build field (you can use FormlyFormBuilder service) (we're looking to make it optional in v6)
A parent component or a directive is needed to connect those fields (or manually) then call checkExpressions for each field

I do prefer to use V6 which simplifies the process as we're trying to make rendering one field possible but still in progress.

It seems I made a mistake when I was assigning the model and formGroup to the individual fields, and now it works when I am using the same model across the fields. Thanks, my mistake.
Waiting for V6, thanks for the hard work!


chore: Fix evaluation serialization in notebooks

For some reason op serialization was not happy with the custom exception. Should solve correctly, but for now this works

I think the problem might be the code discovery -- we probably don't include the custom exception code


Problems building Vulkan worker on Linux

I followed the instructions in the Vulkan worker README to build it under Linux.  I got:
...
[ 45%] Building CXX object CMakeFiles/vkworker.dir/src/linux/main.cc.o
[ 54%] Building CXX object CMakeFiles/vkworker.dir/src/linux/platform.cc.o
[ 63%] Building CXX object CMakeFiles/vkworker.dir/src/common/vulkan_worker.cc.o
[ 72%] Building CXX object CMakeFiles/vkworker.dir/src/common/vkcheck.cc.o
graphicsfuzz/vulkan-worker/src/common/vkcheck.cc: In function ‘const char* getVkResultString(VkResult)’:
graphicsfuzz/vulkan-worker/src/common/vkcheck.cc:40:10: error: ‘VK_ERROR_OUT_OF_POOL_MEMORY’ was not declared in this scope
case VK_ERROR_OUT_OF_POOL_MEMORY: return "VK_ERROR_OUT_OF_POOL_MEMORY";
^~~~~~~~~~~~~~~~~~~~~~~~~~~
I wonder if perhaps I am missing a step whereby Vulkan headers need to be specified?  It would be great if we could update the documentation to guard against this.

@hevrard Did #257 fix this?  If so please close.

Maybe fixed via #257, and obsolete in any case as we use the Amber worker now.


Chat breaking randomly and not resizing

Its just random? lol
i think it has to do with calling resizestuff a bit too much but idk
its hard to reproduce and it fixes itself when new media is played

fixed with latest update


Format Java and XML files

Note: should be done once all closable PR are submitted to avoid to many conflict during merge.

Applicable to SDK as well


Correct zrage typo in migration docs

Less rage more range. Not sure what else to say here :)

Thanks)


Revert "Upgrade docker-client dep from 8.9.0 to 8.9.2"

Reverts spotify/helios#1190
We've seen problems with jobs that use exec healthchecks since this change, see https://github.com/spotify/docker-client/pull/916#issuecomment-352896897

The motivation seems to've just been to keep in sync with docker-client, so I'm fine with this revert until we sort out the issues. 👍

Codecov Report

Merging #1201 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1201      +/-   ##
============================================
- Coverage     52.54%   52.51%   -0.03%
- Complexity     1609     1610       +1
============================================
  Files           268      268
  Lines         13009    13009
  Branches       1502     1502
============================================
- Hits           6835     6832       -3
- Misses         5654     5659       +5
+ Partials        520      518       -2


Refactor class code into reusable packages

A lot of the code built into classes could be moved out to other packages, making it more reusable. The main ones are networking, and keybinds, but there are some other bits around too.

Refactor keybinds into a new package
Refactor networking into a new package
Refactor helpers into a new package
Check for other candidates

Added to dev 99a2e70daa0272305c086840cbb10c32675822b6


[Feature][Plugin] Support Doris source and sink(#800)

I want mege this code to dev about supporting spark-sink-doris,
but i dont have write access，please help me open permissions
thanks


add benchmark of term streams merge

This is a draft PR that adds a benchmark of the term merging operation, to make sure I understood what was expected.
I get a result such as below for the baseline:
test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 248,879,424 ns/iter (+/- 8,600,537)

Close #469

Thanks for the comments !
I will address them but I'll create a fst-based term merging prototype before pushing any new commits.

@scampi apologies for the late reaction. I actually wrote the comments 3 weeks ago but forgot to hit the send review button >.<

If you have trouble with rebase, I can do it... Let me know once you addressed the comments

@fulmicoton see commit https://github.com/tantivy-search/tantivy/pull/1024/commits/27b29d6073f54e79e6f07bf502c2765f0148de74 with a possible term merger implementation based on the FST union.
Below are some runs of the benchmark. I see some variability in the run, the union approach is not always significantly better than the baseline, although it seems to be faster in general.
# fst union

test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 257,954,291 ns/iter (+/- 13,201,530)
test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 234,322,785 ns/iter (+/- 43,848,128)
test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 341,135,396 ns/iter (+/- 24,285,123)

# baseline

test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 291,538,403 ns/iter (+/- 54,753,066)
test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 349,626,129 ns/iter (+/- 78,527,658)
test termdict::merger::bench::bench_termmerger_baseline                                         ... bench: 376,261,843 ns/iter (+/- 15,450,698)

@PSeitz See commit https://github.com/tantivy-search/tantivy/pull/1024/commits/c899c1c43817f736f97e57028759427a2972f727 with fixes for your review. Thanks!

@scampi Thanks it is a very valuable PR for tantivy. Can you add an extra commit to update CHANGELOG.md with your contribution?

@fulmicoton Please see commit https://github.com/tantivy-search/tantivy/pull/1024/commits/66b633aba749b8a10366c3eab6ec4f17ee2299ec with changelog update

@scampi  Congratulations !


Add function to allow anon user to create new User and Agency docs

Fixes #136

 Implement developer agencies for Hacktoberfest - Realm


Return project_imagery with project when applicable

I allowed the separate route for get-project-imagery so that the long project lists do not return the extra info.  I think for the collection page, review project, and create project, the API routes can be simplified to include the info.
One caution is that the current create project page still returns the entire institution list with all the details to fill in the template.  We may want to (anyway) change this behavior to 1) limit the projects which count and templates an/or 2) fetch project info on change instead of sending all the info for all projects.

Return the project imagery list with the project instead of a separate route


Open link in new tab

External links should be opened in a new tab.

I agree!
I will close this issue though, because it's not possible to open external links via the Statamic main navigation.

There is a huge debate about external links should be opened in new windows/tabs or not. See the following discussion for example: https://ux.stackexchange.com/a/105371


Feature/observability 2024 refresh

Issue #, if available:
Description of changes:
X-Ray Lab updated to .NET 8
Minor Changes:

Updated Classes to use simplified namespaces' definition;
Updated Model Classes from Class to Record
Upgraded all Package References to current versions

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I have reviewed this, and it meets the needs for the Immersion Day.


Fixed some typos and punctuation in documentation

Signed-off-by: Omar Farag<EMAIL_ADDRESS>
Description of the change(s):

Fixes typos, both for readability and a mistake in a command. Also resolves https://github.com/stolostron/hypershift-deployment-controller/pull/150

/assign @jnpacker

/lgtm


Add user-assigned Managed Identity limitation in docs

Currently, user-assigned Managed Identity is not supported when Storage account is enabled with VNET/Firewall rules. Only system-assigned Managed Identity is supported and need to enable "Allow Azure services on the trusted services list to access this storage account" option in the storage account's network settings.
Please add this limitation to the doc.

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

ID: d904c827-7efa-59aa-9639-12493e7e8061
Version Independent ID: e2c8c71f-52d4-b25b-ed75-892744d243e4
Content: Deliver events using private link service - Azure Event Grid
Content Source: articles/event-grid/consume-private-endpoints.md
Service: event-grid
GitHub Login: @spelluru
Microsoft Alias: spelluru

@mumurug-MSFT
Thanks for your feedback! We will investigate and update as appropriate.

@robece please check this.

Added notes in the Storage section. #please-close


[WIP] IME preedit

What does the pull request do?

What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

Fixes: #8336

You can test this PR using the following package version. 0.10.999-cibuild0023297-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0023478-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0023480-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]


randomized quarantine for large allocations

It can be split between the FIFO ring buffer and a random array.

This is now implemented by https://github.com/AndroidHardening/hardened_malloc/commit/b2007ad3d9d3acd9628c012f3da567f3e13121fe.


feat(ui): add ability to filter search results by DatasetLineageType

Added ability to filter by DatasetLineageType while searching for a keyword in search bar.
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

hey @vojtechneradatos ! thanks for the PR - we'll be looking at this shortly

@vojtechneradatos can you explain your use case for this change a little more for us? Just want to make sure I understand the intention here

@vojtechneradatos can you explain your use case for this change a little more for us? Just want to make sure I understand the intention here

@chriscollins3456: This is the modification mentioned in Slack, I asked my colleague to prepare PRs for our modifications having general use. This minor change has two effects:

It allows filtering found datasets based on the lineage type. By default, there are three lineage type values in DataHub (we have added 2 more covering our use cases, but that's not really important here). This change allows filtering datasets having e.g. a COPY lineage documented among them (or TRANSFORMED, etc.).
As a rather nice side-effect, it provides possibility to actually see the lineage type in the UI, because this information is not visible in the UI at all as of now. I assume that this second use case may become irrelevant in the future after a possible extension of the UI in this area, but the first one would still apply.


Upgrade to Babel 7

I started to look into docz for our Volto docs and I ran into issues with Babel 6. Before I can proceed, we need to upgrade to Babel 6. Any pointers or anybody who can help with this?

@tisto We could use babel-upgrade tool to resolve the issue of stage preset deprecation. We can use this complete migration guide.

@nileshgulia1 this is actually what I tried already. Did not work so far. Maybe you could look into this?


pkgs/development: switch to fetchFromGitHub part 3

Motivation for this change
use fetchFromGitHub
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 143870 run on x86_64-linux 1

5 packages failed to build and are new build failures:

ocamlPackages.eliom: log was empty
ocamlPackages.js_of_ocaml-tyxml: log was empty
ocamlPackages.ocsigen-start: log was empty
ocamlPackages.ocsigen-toolkit: log was empty
ocamlPackages.reactivedata: log was empty

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:

ocamlPackages.eliom:

warning: unclear-gpl
lgpl21 is a deprecated license, please check if project uses lgpl21Plus or lgpl21Only and change meta.license accordingly.
Near pkgs/development/ocaml-modules/eliom/default.nix:54:5:
   |
54 |     license = lib.licenses.lgpl21;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md
warning: build-tools-in-build-inputs
which is a build tool so it likely goes to nativeBuildInputs, not buildInputs.
Near pkgs/development/ocaml-modules/eliom/default.nix:21:3:
   |
21 |   buildInputs = [ ocaml which findlib js_of_ocaml-ocamlbuild
   |   ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/build-tools-in-build-inputs.md

ocamlPackages.js_of_ocaml-tyxml:

warning: unclear-gpl
gpl2 is a deprecated license, please check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/development/tools/ocaml/js_of_ocaml/compiler.nix:24:5:
   |
24 |     license = lib.licenses.gpl2;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md
warning: unused-argument
Unused argument: ocaml.
Near pkgs/development/tools/ocaml/js_of_ocaml/compiler.nix:2:3:
  |
2 | , ocaml, cmdliner, cppo, yojson, ppxlib
  |   ^

ocamlPackages.ocsigen-start:

warning: name-and-version
Did you mean to pass pname instead of name to mkDerivation?
Near pkgs/development/ocaml-modules/ocsigen-start/default.nix:8:3:
  |
8 |   name = "ocaml${ocaml.version}-ocsigen-start-${version}";
  |   ^

Near pkgs/development/ocaml-modules/ocsigen-start/default.nix:9:3:
  |
9 |   version = "4.3.0";
  |   ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/name-and-version.md

ocamlPackages.ocsigen-toolkit:

warning: unclear-gpl
lgpl21 is a deprecated license, please check if project uses lgpl21Plus or lgpl21Only and change meta.license accordingly.
Near pkgs/development/ocaml-modules/ocsigen-toolkit/default.nix:32:5:
   |
32 |     license = lib.licenses.lgpl21;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

ocamlPackages.reactivedata:

warning: unclear-gpl
lgpl21 is a deprecated license, please check if project uses lgpl21Plus or lgpl21Only and change meta.license accordingly.
Near pkgs/development/ocaml-modules/reactivedata/default.nix:28:5:
   |
28 |     license = licenses.lgpl21;
   |     ^

See: https://github.com/jtojnar/nixpkgs-hammering/blob/master/explanations/unclear-gpl.md

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 143870 run on x86_64-linux 1

5 packages built:

ocamlPackages.eliom
ocamlPackages.js_of_ocaml-tyxml
ocamlPackages.ocsigen-start
ocamlPackages.ocsigen-toolkit
ocamlPackages.reactivedata


Add support for TAB or ENTER keys in browser.type

Dear splinter team,
I'm using django-froala-editor in my projects and want to run behavior tests. As it is a bit tricky to get the FroalaField inputs as this are contenteditable DIVs. I'm using the following approach with navigating with TAB keys:
import splinter
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.action_chains import ActionChains

with splinter.browser as b:
    b.visit("/")
    # click on an visible element
    self.browser.find_by_id("id_foo").first.click()
    # next element is a FroalaFieldInput and is defined by tab order
    actions = ActionChains(b.driver)
    actions.send_keys(Keys.TAB)
    actions.send_keys("AB")
    actions.perform()

I would like to somehow have a more "natural" possibility to type "TAB" or other special keystrokes, e.g. by passing selenium Keys to browser.type(). I think as this is implemented in Selenium it could be useful in splinter, too.

Hi @mpibpc-mroose I believe that it is a nice feature to have. Thanks.

yes i'm very confused about this function,really need it

Yep,
needed as well from my side.
It's crucial in fact..


@alloy -> re-fetch hero units when hero VC will appear

this is a quick fix and could probably use some tests. There is probably a nicer way to tie this in with the pre-fetching and whatever RAC thing is going on when the view loads, but this is simple enough to just ensure that hero units don't go stale. won't disturb the timer or re-render anything if the hero unit data that we get back isn't any different from what we already have.

Could do with a CHANGELOG and I wonder if a test is worth it, definitely if a test would be simple to make.

Yup
On Fri, May 15, 2015 at 19:20, Eloy Durán<EMAIL_ADDRESS>wrote:
Could do with a CHANGELOG and I wonder if a test is worth it, definitely if a
test would be simple to make.
—
Reply to this email directly or view it on GitHub
[https://github.com/artsy/eigen/pull/444#issuecomment-102545998] .[https://github.com/notifications/beacon/ADBlTrXrTsCAz4N2iii43oMaKyK_XZKWks5oJnbEgaJpZM4EcR3M.gif]

@alloy :green_apple:

@1aurabrown Just to be clear, this only fetches the JSON payload and compares those to see if it needs an update, right?

It turns the json payload into an array of hero unit objects, and compares
them to the existing array of hero unit objects. it only updates the view
if they differ.

Thanks :+1:


Docs.MS Readme Update.

Docs.MS Readme Update.

Docs Build status updates of commit bdd9671:
:clock10: Full build: the average full build time is 63 min(s) 54 sec(s), this is based on the last 19 build(s) for this repository.
:warning: This is a FULL build due to a recent Docs Build service upgrade, normally no action is required on your part. In the result you find subsequent builds still performing full builds, please contact your repository admin to manually perform a full build on the 'smoke-test' branch. For more detailed info, please click here.

Docs Build status updates of commit bdd9671:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/core-auth-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/identity-readme-pre.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-autogen/microsoft-cognitiveservices-speech-sdk/index.yml
:warning:Warning
View (azure-node-latest)
Details

docs-ref-services/core-auth-readme.md

Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

docs-ref-services/identity-readme-pre.md

Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

docs-ref-autogen/microsoft-cognitiveservices-speech-sdk/index.yml

[Warning-DuplicateUids] Uid(microsoft-cognitiveservices-speech-sdk) has already been defined in docs-ref-services/speech-service.md.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 08a73b3:
:clock10: Full build: the average full build time is 64 min(s) 48 sec(s), this is based on the last 20 build(s) for this repository.
:warning: This is a FULL build due to a recent Docs Build service upgrade, normally no action is required on your part. In the result you find subsequent builds still performing full builds, please contact your repository admin to manually perform a full build on the 'smoke-test' branch. For more detailed info, please click here.

Docs Build status updates of commit 08a73b3:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/core-amqp-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/core-auth-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/identity-readme-pre.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-autogen/microsoft-cognitiveservices-speech-sdk/index.yml
:warning:Warning
View (azure-node-latest)
Details

docs-ref-services/core-amqp-readme.md

Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.

docs-ref-services/core-auth-readme.md

Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

docs-ref-services/identity-readme-pre.md

Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

docs-ref-autogen/microsoft-cognitiveservices-speech-sdk/index.yml

[Warning-DuplicateUids] Uid(microsoft-cognitiveservices-speech-sdk) has already been defined in docs-ref-services/speech-service.md.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 1bbda86:
:clock10: Full build: the average full build time is 65 min(s) 43 sec(s), this is based on the last 21 build(s) for this repository.
:warning: This is a FULL build due to a recent Docs Build service upgrade, normally no action is required on your part. In the result you find subsequent builds still performing full builds, please contact your repository admin to manually perform a full build on the 'smoke-test' branch. For more detailed info, please click here.

Docs Build status updates of commit 1bbda86:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/core-amqp-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/core-auth-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/event-hubs-readme.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/identity-readme-pre.md
:warning:Warning
View (azure-node-latest) View (azure-node-preview) View (azure-node-legacy)
Details

docs-ref-services/core-amqp-readme.md

Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 17: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 37: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 38: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#amqp-management' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide#claims-based-authorization' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 259: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.
Line 263: [Warning-multiple-h1s] Multiple H1s are not allowed. You can only have one top-level heading.

docs-ref-services/core-auth-readme.md

Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 13: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 14: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.

docs-ref-services/event-hubs-readme.md

Line 19: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 19: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 19: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 26: [Warning-hard-coded-locale] Link 'https://azure.microsoft.com/en-us/services/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 26: [Warning-hard-coded-locale] Link 'https://azure.microsoft.com/en-us/services/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 26: [Warning-hard-coded-locale] Link 'https://azure.microsoft.com/en-us/services/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 49: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 49: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 49: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 71: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-get-connection-string#get-connection-string-from-the-portal' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 71: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-get-connection-string#get-connection-string-from-the-portal' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 71: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-get-connection-string#get-connection-string-from-the-portal' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 102: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-azure-active-directory' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 102: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-azure-active-directory' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 102: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-azure-active-directory' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 128: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 128: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 128: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 167: [Warning-InvalidBookmark] Invalid link: '<a href="#use-eventHubConsumerClient-to-work-with-IotHub">Use EventHubConsumerClient to work with IotHub</a>'. The file docs-ref-services/event-hubs-readme.md doesn't contain a bookmark named 'use-eventHubConsumerClient-to-work-with-IotHub'.
Line 167: [Warning-InvalidBookmark] Invalid link: '<a href="#use-eventHubConsumerClient-to-work-with-IotHub">Use EventHubConsumerClient to work with IotHub</a>'. The file docs-ref-services/event-hubs-readme.md doesn't contain a bookmark named 'use-eventHubConsumerClient-to-work-with-IotHub'.
Line 167: [Warning-InvalidBookmark] Invalid link: '<a href="#use-eventHubConsumerClient-to-work-with-IotHub">Use EventHubConsumerClient to work with IotHub</a>'. The file docs-ref-services/event-hubs-readme.md doesn't contain a bookmark named 'use-eventHubConsumerClient-to-work-with-IotHub'.
Line 359: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-processor-balance-partition-load' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 359: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-processor-balance-partition-load' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 359: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-processor-balance-partition-load' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 420: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-messages-read-builtin' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 420: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-messages-read-builtin' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 420: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-messages-read-builtin' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 496: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 496: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 496: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

docs-ref-services/identity-readme-pre.md

Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 15: [Warning-h1-not-first] Markdown content is not allowed before H1.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 16: [Warning-h1-missing] H1 is required. Use a single hash (#) followed by a space to create your top-level heading.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 21: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 67: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Write some sample postgresql DB queries for redash

Write some sample postgresql  DB queries for redash ,such as locate all markers 300 meters from log, lat.
So that new contributors have a good starting point
Redash link: http://data.obudget.org/

Do we share the redash instance with Open Budget? Because I don't see Anyway tables there

Can you write me a description for which queries would you like to see examples for?

All accidents 500 m around a given location with victims of age 0-7
All accidents on road 1 sorted by severity, and display road segment if available
All accidents in Tel Aviv
Count accidents per town
*If something is too complicated you can skip it

SQL queries are now available


DevOps Mutualization SIG Meeting - Oct 20, 2022

Date
October20  2022 - 12pm ET / 5pm BST
Untracked attendees

Name
Firm
Comment

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[ ] Convene, roll call, welcome new people
[ ] Display FINOS Antitrust Policy summary slide
[ ] Approve previous meeting minutes
[ ] Review DevOps SIG project board
[ ] Backstage Discussion - John Mark Walker, Director of Open Source Program Office, Fannie Mae

https://groups.google.com/a/finos.org/g/community/c/FrasELXkQmw
I’ve noticed that a lot of companies are implementing backstage.io as part of an overall developer experience / dev scaffolding effort. It seems to be an emerging standard. I was wondering if there would be enough interest from other members to form a SIG on this subject? Or perhaps this falls under the purview of an existing SIG? Seems like there’s a lot we could learn from each other in financial services on this topic.

and ...

Given that there are 2 SIGs (InnerSource and DevOps SIG) where this is probably relevant, should we have a combined session, or do we think that each SIG will have its own points of emphasis and discussion points?
I’m open to suggestions, but I would vote for 2 sessions: the devops mutualization forum can get into a technical discussion around automated compliance and the developer experience, as well as the tools and platforms that we can or should standardize on, and the innersource discussion can be about repeatable patterns and the intersections between developer experience and innersource programs. But if there are strong opinions that those are functionally discussions about the same thing, I’m happy to support a joint discussion.

[ ] AOB, Q&A & Adjourn (5mins)

WebEx info
Webex:
https://finos.webex.com/finos/j.php?MTID=md62056638ba05fbea86b9582df94f807
Dial-in

US +1-415-655-0003 US Toll
UK +44-20319-88141 UK Toll
Access code:<PHONE_NUMBER>

Github Repo: https://github.com/finos/devops-mutualization/
Project Board: https://github.com/orgs/finos/projects/33
Mailing List: Email<EMAIL_ADDRESS>to subscribe to our mailing list

hello!

Hello - 👋🏻

Hi! :wave:

Hi

👋🏼 hello!

:wave: Hi!

Hello all. Oliver from Scott Logic here.

Hello there! Clare from InnerSource Commons here.

Hi, this is Tim from Wellington Management

Hey 👋

Hi everyone


Cocoapods 1.0.1

Overview
This pull request enables RestKit to build using the latest version of Cocoapods.
Although, the recommended way to install RestKit is through use_frameworks, now it can be installed either with or without.
Here's a details of what has been done:

Removed iOS 5 related code in RKPathUtilities.m
Increased deployment target to iOS 8.0 and OS X 10.9 on both project and test apps
Updated rakefile: fixed build:examples task
Allowed warnings on pod lib lint (due to AFNetworking)
Fixed AFNetworking reachability issue with Cocoapods use_frameworks!
Fixed headers not found issue with Cocoapods > 0.38.2
Moved RKHTTPUtilities into Network directory
Updated example projects pod files
Removed AFNetworking dependency from podspec
Renamed all AFNetworking classes to AFRK to be able to install any version of AFNetworking meanwhile using RestKit.

TODO
Having said that all the example projects now compiles perfectly fine, the only issue I am having is in running the tests for the RestKitFramework target.
I keep getting this error and I cannot figure out what is going on, as I checked and the frameworks are exactly in the path that is trying to load.
It seems to have something to do with https://github.com/CocoaPods/CocoaPods/issues/4752 or at least being related.
Here's the log:
2016-06-23 19:47:29.784 xctest[90829:1420243] The bundle “RestKitFrameworkTests.xctest” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
2016-06-23 19:47:29.784 xctest[90829:1420243] (dlopen_preflight(/Users/valerio/Library/Developer/Xcode/DerivedData/RestKit-baznidpnyjfopdfhcxlsitkkshau/Build/Products/Debug/RestKitFrameworkTests.xctest/Contents/MacOS/RestKitFrameworkTests): Library not loaded: @rpath/AFNetworking.framework/Versions/A/AFNetworking
  Referenced from: /Users/valerio/Library/Developer/Xcode/DerivedData/RestKit-baznidpnyjfopdfhcxlsitkkshau/Build/Products/Debug/RestKitFrameworkTests.xctest/Contents/MacOS/RestKitFrameworkTests
  Reason: image not found)
Program ended with exit code: 82

Once this is solved, this can be merged, a new release can be made and hopefully everyone's happy 🎉
It would be nice if people could start pointing to this branch and try run their projects to double check that everything is ok.
As usual, any help is appreciated :)

:+1:

@mcfedr
This PR builds without use_frameworks and reachability works fine without, but for the sake of having it working in both ways (everyone would like to use_frameworks!) and seeing the AFNetworking's guys response here (https://github.com/AFNetworking/AFNetworking/pull/3400) I would say, maybe we could fork AFN 1.3.4 into the RestKit organisation and make the dependency point to our fork (as you originally intended).
Meanwhile, @tinora may have made some progresses on the branch we were talking about on https://github.com/RestKit/RestKit/issues/2371 and once that is finished we can get rid of the fork.
Until that is completed, as I am not receiving any answer for this other issue on cocoa pods (https://github.com/CocoaPods/CocoaPods/issues/4752), for the sake of the project I feel like temporarily disabling the test for the OS X target until Cocoapods/Cocoapods#4752 is fixed and we can finally make a release that works.
@segiddins would you be ok in preceding this way?

@valeriomazzeo I'm ok with whatever, as long as the tests pass

@segiddins tests pass but we are able to run them only on iOS and not on OSX

@valeriomazzeo @segiddins Hey guys, thanks for fixing it, but will RestKit drop support to iOS 7?

@rafaelks Ideally yes, that will allow us to replace SOCKit with something more modern like URITemplate and should also facilitate @tinora works on removing the AFNetworking dependency.

@valeriomazzeo Sounds good. Xcode 8 will also force apps to not support iOS 7 I think. https://twitter.com/rafaelks/status/747452734266281984

These last changes remove the AFNetworking dependency from the podspec file. All the files (not many really) have been copied manually into the project so we don't depend from the AFNetworking repository anymore (1.3.x is not supported anyway).
The only downside is that now is not explicit anymore that it's not possible to use new version of AFNetworking when using RestKit. For example, cocoapods won't stop us installing AFNetworking 3.x, but we will get duplicated symbols error.
Although, I think I am missing something here, as I thought that cocoapods' built frameworks were using namespaces allowing this particular combination to be possible, for example: RestKit.AFHTTPClient. @segiddins did I dream of that?
Apart from this, everything works now and if we are ok with it, it's good to be merged.
I have also clean up the project removing the pre-compiled prefix which is obsolete nowadays.

@valeriomazzeo ObjC isn't namespaced

With @segiddins blessing, I'd merge this and draft a new release

This change don't allow us to use RestKit in our ShareExtension because of AFNetworking update. Any workaround here?

Can you explain in the details what's the issue you are having?

Also better open a separate issue for that

@valeriomazzeo Thanks! I've created a new issue: #2440.

If all of this stuff landed in 0.27 (and it seems so?), it would be really great if the release here in GitHub had notes associated with it. Seems like a reasonably significant set of changes. Much more so than this would suggest:

Thanks @sixten, to be honest I didn't have time to write proper release notes.
I have updated that page with the content of this Pull Request, although there are other commits worth mentioning that are included in the release.
Please feel free to write some release notes, I will be happy to update the page.

@valeriomazzeo, @mkoehnke, et al
Thanks for the effort you've put into this release. I have merged your changes into my own fork (see comments in https://github.com/RestKit/RestKit/issues/2371) and managed to use this Restkit version in coexistence with AFNetworking 3.x.
There's one big issue I see though. Either it is due to my misunderstanding (then pls. advice anybody) or we really still have a problem. It is regarding the CoreData data dependency management.
In the project where I'm using the latest Restkit version I don't need CoreData and yet CoreData related code will be executed. This code should actually only be executed if 'RKCoreDataIncluded' is defined. So far it has been defined once Restkit/CoreData.h has been included which by itself includes <CoreData/CoreData.h> (Apples CoreData include). Apples CoreData.h defines _COREDATADEFINES_H: So in order to have CoreData support according to @blakewatters  one had to add '#import <CoreData/CoreData.h>' (or the Restkit/CoreData.h) in his *.pch file (see https://github.com/RestKit/RestKit/issues/1564). I think this CoreData-dependency management is not working correctly anymore as several code places has been changed from:
#ifdef _COREDATADEFINES_H
define RKCoreDataIncluded
#endif
to:
if __has_include("CoreData.h")
define RKCoreDataIncluded
#endif
This is semantically not the same. "... The __has_include ... macros allow you to check for the existence of an include file before doing a possibly failing #include directive..." (see http://clang.llvm.org/docs/LanguageExtensions.html)
Would anybody agree with my analysis? If 'yes' we need to fix the current state of affairs. Otherwise somebody can maybe enlighten me.
Thanks in any case
Tino

Hi @tinora,
What you said it's correct, that has been changed because it wasn't working really well.
It was injecting defines into the prefix file, which as you may have noticed has been completely removed.
With the latest version, core data is included only if you install (including in the pod file) the core data subspec (RestKit/CoreData).
If you do that then the CoreData.h won't be there and none of the core data related part would be compiled.
I am 100% sure this is currently working, because we have some tests on the CI that builds the Twitter project without Core Data (please refer to the rake file).
The issue you may be encountering is due to the fact that the RestKit project itself has a dependency on core data because of the testing subspec (if I remember well).
If that's not the case, can you please elaborate exactly what your setup is?

@valeriomazzeo
Currently in my Podfile a reference Restkit like this "pod 'Restkit', ...' what do I have to do to exclude CoreData?

@tinora from the RestKit podspec file:
  # Exclude optional Search and Testing modules
  s.default_subspec = 'Core'

  ### Subspecs

  s.subspec 'Core' do |cs|
    cs.dependency 'RestKit/ObjectMapping'
    cs.dependency 'RestKit/Network'
    cs.dependency 'RestKit/CoreData'
  end

If you install only RestKit it would load the default subspec which is called Core that as you can see includes the CoreData subspec.
You could do something like this (based on the subspec you need):
pod 'RestKit', :subspecs => ['Network', 'ObjectMapping']

@valeriomazzeo
I see! Will give it a try - thanks!
Just one more comment: Am I right to assume that in the majority of cases CoreData is not needed? If 'yes' wouldn't it then be better to have people explicitly opt-in CoreData rather than having everybody to opt it out?

@valeriomazzeo
BTW: Explicit opt-in CoreData would also be compatible to the previous state where I explicitly had to include CoreData.h in order to get CoreData support.

@tinora
I understand what you mean, but I haven't changed the Core subspec, it has always been including CoreData, so I don't feel really confident in making this change.
Although, it makes sense to a certain extent to explicitly opt-in CoreData, that would be a change in the default behaviour, which apparently was kind of a mix (CoreData files were included, but not compiled) before this release.
cc @segiddins

@valeriomazzeo
Its not the most needed change IMO. As long as there is a chance to get rid of CoreData support - fine. Is it documented somewhere how to do it? I know it now :) but others might stumble in the future too.
Regards
Tino

@tinora
It's a subspec, if you install Core and it's in Core you will have it.
There's the Twitter example project that shows that.
In my opinion, who installs it with Cocoapods, should be familiar with the tool.
Although, feel free to make a pull request adding more information to the Readme if you think it can help others 👍

@valeriomazzeo
Maybe its just me and I'm to ignorant on cocoapods. :)
On first sight the subspec approach looks elegant, but I just stumbled over another consequence. I have my own library which I distribute via cocoapods. It depends on Restkit which is specified in its *.podspec file. Now I need to propagate the subspace approach in order to allow the user of my component to opt-out CoreData in a dependent library (RestKit in this case) - if you understand what I mean. At least not optimal I would say. This might be an argument why the former approach with the explicit include of a certain header was maybe the slightly better approach. At least earlier versions of AFNetworking also went this route by requiring the user to include SystemConfiguration.h  to enable certain feature.

@tinora

Now I need to propagate the subspace approach in order to allow the user of my component to opt-out CoreData in a dependent library (RestKit in this case)

Yes, and that is the correct way to do it.
You can make a pod lib which has a dependency on RestKit or on any of RestKit subspaces simply defining:
spec.dependency 'RestKit/CoreData', '~> 0.20.0'
In your case I guess in your podspec file you want to write:
spec.dependency 'RestKit/Network', '~> 0.27.0'
spec.dependency 'RestKit/ObjectMapping', '~> 0.27.0'

If you want your users to be able to specify to use core data or not, then you will have to have a separate subspec on your library that depends on RestKit/CoreData.
As I said, we moved away from the prefix file approach because it's not recommended by Apple, prefix files are absolutely deprecated (have been for years now) and they caused loads of troubles (see the whole AFNetworking problem).

@valeriomazzeo
Ok, convinced! Thanks a lot @valeriomazzeo! That least I knew that pch's a deprecated. :)