text:
chmod u+x /etc/cron.d/

/etc/cron.d and others are directories, and should have execute permission.
Actually I have just gone into the original CIS document, and it's inconsistent. It says permissions should be 0600 (u=rw instead of u=rwx) but it remediates by setting go-rwx, which does not do u-x.
You may not want to merge this since it does not strictly conform to CIS. I'll raise an issue with them.

Would you mind if I held off merging until you receive a response from CIS regarding the inconsistency?

Hi, of course not, no problem. I've put it in my local branch :)
There is a CIS ticket: https://workbench.cisecurity.org/benchmarks/191/tickets
You have to have an account to view that, I've requested one but I haven't obtained it, maybe you have one and can see that.
Sent from my iPhone

On 21 Feb 2017, at 09:20, anthcourtney notifications@github.com wrote:
Would you mind if I held off merging until you receive a response from CIS regarding the inconsistency?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I got my account, the real ticket URL is
https://workbench.cisecurity.org/community/11/tickets/4716
On 21 February 2017 at 09:32, Lorens Kockum lorens.kockum@schibsted.com
wrote:

Hi, of course not, no problem. I've put it in my local branch :)
There is a CIS ticket: https://workbench.cisecurity.org/benchmarks/191/
tickets
You have to have an account to view that, I've requested one but I haven't
obtained it, maybe you have one and can see that.
Sent from my iPhone
On 21 Feb 2017, at 09:20, anthcourtney notifications@github.com wrote:
Would you mind if I held off merging until you receive a response from CIS
regarding the inconsistency?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/anthcourtney/ansible-role-cis-amazon-linux/pull/9#issuecomment-281274794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXvSROm6tpovbQ8XNNCryJBK78HIAjTBks5rep5CgaJpZM4MD_8v
.

--
Regards,
Lorens Kockum
System Security Engineer - SPT

Gentlemen, looks like CIS has fixed the inconsistency and so we can merge this pull request.

authors: LorensK anthcourtney chandanchowdhury


text:
Adds a component that translates a tax parameter to an emissions reduction (UPDATED)

The taxeffect.jl file contains two components. One is specific to each gas, and sits between its AbatementCostParameters and AbatementCosts components. The other takes a uniform tax rate and applies it to all four of those gas-specific taxes. There's also a unit test.
@jrising this is done and should replace your PR #160, the build will pass once we merge in #163

Why not just merge docs-fixes into both this branch and the other PR's branch?

Sure I can do that, I had been keeping them separate just so the delta was easier to view but now that it’s finished I can merge.

source: gharchive/pull-request

authors: jrising lrennels

license: MIT

license_type: permissive

license_source: github-api


text:
Broken Install

I am installing on a Unbuntu 16.04 system and the adding data script is failing. Running scripts/setup works fine but scripts/seed -f gives an error. The following is the error in console.
$ wget https://s3-us-west-2.amazonaws.com/beaverdam/db.sqlite3 -O db.sqlite3
--2019-06-03 14:37:14--  https://s3-us-west-2.amazonaws.com/beaverdam/db.sqlite3
Resolving s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)... 52.218.160.76
Connecting to s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)|52.218.160.76|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 119808 (117K) [application/octet-stream]
Saving to: ‘db.sqlite3’
db.sqlite3          100%[===================>] 117.00K   413KB/s    in 0.3s
2019-06-03 14:37:15 (413 KB/s) - ‘db.sqlite3’ saved [119808/119808]
$ wget https://s3-us-west-2.amazonaws.com/beaverdam/videos/test_vid2.mp4 -O annotator/static/videos/0.mp4
--2019-06-03 14:37:15--  https://s3-us-west-2.amazonaws.com/beaverdam/videos/test_vid2.mp4
Resolving s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)... 52.218.160.76
Connecting to s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)|52.218.160.76|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2063958 (2.0M) [application/octet-stream]
Saving to: ‘annotator/static/videos/0.mp4’
annotator/static/vi 100%[===================>]   1.97M   880KB/s    in 2.3s
2019-06-03 14:37:18 (880 KB/s) - ‘annotator/static/videos/0.mp4’ saved [2063958/2063958]
Traceback (most recent call last):
File "./manage.py", line 10, in
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/init.py", line 363, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/init.py", line 337, in execute
django.setup()
File "/usr/local/lib/python2.7/dist-packages/django/init.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/local/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in populate
app_config.import_models()
File "/usr/local/lib/python2.7/dist-packages/django/apps/config.py", line 202, in import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python2.7/importlib/init.py", line 37, in import_module
import(name)
File "/home/jzelek/Desktop/AnnotationTools/BeaverDam/annotator/models.py", line 49
def from_list(cls, path_to_list, *, source, host, filename_prefix=''):
^
SyntaxError: invalid syntax
When I try to continue on with scripts/serve, the localhost opens with the following error

The software versions are:
Python: 3.5.2
VirtualEnv:  16.4.1

Looks like you're installing with python 2 instead of python 3 somehow

Any idea how to get the install script to call python 3 instead of python 2?

The seed script assumes that you run it right after the setup script. You have two options:

run the setup script before you run the seed script
execute source venv/bin/activate before running the seed script

source: gharchive/issue

authors: MatthewMcLeod antingshen clayshieh

repo: antingshen/BeaverDam

license_source: bigquery


text:
AnyError does not pass through localizedDescription from an underlying NSError

My intuition is that the below test should pass, but it does not in release 3.1.0:
class AnyErrorSpec: QuickSpec {
    override func spec() {
        describe("AnyError") {
            it("forwards an underlying NSError's localizedDescription") {
                let error = NSError(domain: "Foo", code: 42, userInfo: [NSLocalizedDescriptionKey: "a localized description"])

                expect(AnyError(error).localizedDescription).to(equal("a localized description"))
            }
        }
    }
}

Should it? Would you accept a PR to make it so?

I expect you get the underlying error: AnyError(error).error. localizedDescription is not a requirement of Error protocol so AnyError does not implement it.

If localizedDescription isn't a property of Error (and you're right, it's not), why does this even parse?
let foo: AnyError = AnyError(error)
let bar: String = foo.localizedDescription

See https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md

In Foundation, add an extension to ErrorProtocol that provides access to the localized description, which is available for all error types.

Aha, I see, so implementing this for Result's AnyError would introduce a dependency on Foundation which you probably don't want to do. We can just add this locally then.

It might make sense to conform to LocalizedError protocol and delegate to the underlying error.

authors: ikesyo ratkins

repo: antitypical/Result

license: mit


text:
Upgrade build dependencies

Android SDK 25
Android Build Tools 25.0.2
Android Support Library v25.3.0
Gradle Plugin v2.3.0

Thanks for this!

authors: antoniolg jpventura

repo: antoniolg/MaterializeYourApp


text:
Can't get G900 to work with CS:GO

I installed as instructed, and it works using the "preview" but doesn't actually work in game. I have tried patching the GSI. What am I missing?

Duplicate of #207

repo: antonpup/Aurora


text:
Skip Go build if there are only doc changes

Fixes: #3375
Signed-off-by: KMAnju-2021 km074btcse18@igdtuw.ac.in

Codecov Report

Merging #3450 (ff06d0d) into main (821b97b) will decrease coverage by 27.69%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main    #3450       +/-   ##
===========================================
- Coverage   63.51%   35.82%   -27.70%
===========================================
  Files         268      106      -162
  Lines       26900    14547    -12353
===========================================
- Hits        17085     5211    -11874
- Misses       7951     8846      +895
+ Partials     1864      490     -1374

Flag
Coverage Δ

integration-tests
35.82% <ø> (?)

kind-e2e-tests
?

unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apis/controlplane/register.go

pkg/agent/controller/networkpolicy/allocator.go

pkg/apiserver/certificate/certificate.go

pkg/apis/stats/register.go

pkg/agent/controller/networkpolicy/fqdn.go

...trollers/multicluster/resourceexport_controller.go

multicluster/cmd/multicluster-controller/member.go

pkg/util/env/env.go

pkg/apiserver/handlers/webhook/mutation_labels.go

pkg/apis/controlplane/types.go

... and 364 more

@KMAnju-2021  please squash your commits into one. and link this PR to the issue https://github.com/antrea-io/antrea/issues/3375.

ah thanks @antoninbas to point out, I thought has-changes didn't meet the requirement, but looks like it can help on this issue with correct args. @KMAnju-2021 Could you please refer to kind.yml and refine this PR? thanks!

ah thanks @antoninbas to point out, I thought has-changes didn't meet the requirement, but looks like it can help on this issue with correct args. @KMAnju-2021 Could you please refer to kind.yml and refine this PR? thanks!

The args parameter in the has-changes action is not named appropriately. It should be ignore-paths IMO. I'll submit an issue.

@KMAnju-2021 can you remove the draft tag for this PR?

Sure, thanks!

/skip-all

@KMAnju-2021 for future PRs, please edit the final commit message when you squash your commits

authors: KMAnju-2021 antoninbas codecov-commenter luolanzone

repo: antrea-io/antrea


text:
Add nodelatencystats rest apis implementation.

In last PR https://github.com/antrea-io/antrea/pull/6392, we have defined some rest apis for nodelatencystats.
We have implemented the inner operations by cache.Indexer and support query nodelatencystats by api.
Example:
antrea git:(feat/impl-node-latency-query-api) ✗ kubectl get nodelatencystats
SOURCENODENAME       PEERNODELATENCYSTATS
kind-worker          [map[nodeName:kind-worker2 targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:1097048 lastRecvTime:2024-06-30T03:21:02Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.1.1]]] map[nodeName:kind-control-plane targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:1143333 lastRecvTime:2024-06-30T03:21:02Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.0.1]]]]
kind-worker2         [map[nodeName:kind-control-plane targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:571279 lastRecvTime:2024-06-30T03:21:12Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.0.1]]] map[nodeName:kind-worker targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:1257029 lastRecvTime:2024-06-30T03:21:02Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.2.1]]]]
kind-control-plane   [map[nodeName:kind-worker2 targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:1499582 lastRecvTime:2024-06-30T03:21:02Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.1.1]]] map[nodeName:kind-worker targetIPLatencyStats:[map[lastMeasuredRTTNanoseconds:1339598 lastRecvTime:2024-06-30T03:21:02Z lastSendTime:2024-06-30T03:21:12Z targetIP:10.244.2.1]]]]

/skip-all

authors: IRONICBo antoninbas


text:
Remove the Flow Aggregator Helm Chart

Flow Aggregator Helm Chart is added to Antrea repo with PR https://github.com/antrea-io/antrea/pull/3952. This PR removes it from Theia repo.
Signed-off-by: Yanjun Zhou zhouya@vmware.com

/theia-test-e2e

/theia-test-e2e

/theia-test-e2e

/theia-test-e2e

repo: antrea-io/theia


text:
The label render callback function should return a color

AntV Open Source Contribution Plan（可选）

[X] 我同意将这个 Issue 参与 OSCP 计划

Issue 类型
中级任务
任务介绍
给 label 提供第个参数，会返回图形的一些信息，包含图形颜色。使用 label 的颜色可以根据图形属性决定。
import { Chart } from '@antv/g2';

const chart = new Chart({ container: 'container' });

chart
  .interval()
  .data([
    { genre: 'Sports', sold: 0 },
    { genre: 'Strategy', sold: 115 },
    { genre: 'Action', sold: 120 },
    { genre: 'Shooter', sold: 350 },
    { genre: 'Other', sold: 150 },
  ])
  .encode('x', 'genre')
  .encode('y', 'sold')
  .encode('color', 'genre')
  .style('minHeight', 50)
  .label({ text: 'genre', fill: (_, i, array, d) => d.fill }); // label 颜色和图形保持一致

chart.render();

参考

相关代码：https://github.com/antvis/G2/blob/44188f7f70012fc37f66e7b4f5324521b455cf8b/src/runtime/plot.ts#L1070

api 设计可以参考 https://github.com/antvis/G2/issues/5069#issuecomment-1695320046

zhuyyafd 认领

authors: ancyloce pearmini zhuyyafd


text:
graph如何根据视窗大小重绘图形

G6 Version:
Platform:
Mini Showcase(like screenshots):
CodePen Link:

graph如何根据视窗大小重绘图形，比如手动改变浏览器视窗大小，图形根据最新的宽高重新render

监听视窗变化，然后 graph.changeSize

@Yanyan-Wang 你好，changeSizw 是只能改变画布大小吧？如何让图形重新渲染呢？比如我画布大小改变后，所有的节点的尺寸也相应的变化，这个怎么处理？

changeSize 只改变画布大小，不管图的重绘... 单独使用没用...

authors: Nekosandesu Yanyan-Wang shirleyYing winddies


text:
在gForce布局拖动点不能更新点坐标，在force布局中可以

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Reproduction link

Steps to reproduce
type为gForce情况拖动节点，更新节点坐标不生效，而type为force的情况下可以（在sandbox中修改type进行对比）

Environment
Info

g6
4.2.7

System
-

Browser
-

gForce拖动节点会抖动不能控制

你是说拖拽节点吗？我这里试着在你的 demo 中拖拽节点，好像是正常的呢

你是说拖拽节点吗？我这里试着在你的 demo 中拖拽节点，好像是正常的呢

布局稳定后，拖拽节点到其他位置，我期望他能停在那个位置，但是节点弹回去了，我在node:drag事件里更新了节点的位置，实际效果并不是如此。反而当type为force的时候却可以

那你希望拖拽一个节点的时候，其他节点跟着调整位置吗？

是的

期望是拖拽节点，更新节点位置的效果和force拖拽节点一样

期望是拖拽节点的效果和force一样

gforce 目前没有提供 force 这类 fx fy 固定坐标的方法，每次拖拽的时候被拖拽的节点还是会被布局算法计算位置，所以会和用户拖拽的位置冲突

请问这个后续能支持吗

会考虑的，不过暂时还没有排期

authors: Yanyan-Wang javaNaruto


text:
聚合图初始化时设置不可见，之后设置显示，缩放后点图层消失

聚合图中先设置不可见,addLayer之后设置显示,然后缩放地图之后点图层就消失了

2.11.1应该已经解决了

authors: lzxue wangkeyu


text:
2.22.0版本的高德地图与自建的图层存在偏差

问题描述
新版本的高德地图与自建的图层存在偏差：

老版本没有这个问题
重现链接
No response
重现步骤
No response
预期行为
No response
平台

操作系统: [macOS, Windows, Linux, React Native ...]
网页浏览器: [Google Chrome, Safari, Firefox]

屏幕截图或视频（可选）
No response
补充说明（可选）
No response

复现示例，提供 codesanbox 链接地址
检查数据是否为火星坐标

Hello @gx304419380. Please provide a online reproduction by forking codesandbox of @antv/l7 demo template Issues labeled by Need Reproduce will be closed if no activities in 3 days.
你好 @gx304419380, 我们需要你提供一个在线的重现实例以便于我们帮你排查问题。你可以通过点击这里创建一个 @antv/l7 demo 模板 3 天内未跟进此 issue 将会被自动关闭。

https://codesandbox.io/p/sandbox/l7-demo-forked-cytzvs?file=%2Findex.js%3A4%2C26&layout=%257B%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522rootPanelGroup%2522%253A%257B%2522direction%2522%253A%2522horizontal%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522id%2522%253A%2522ROOT_LAYOUT%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522UNKNOWN%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522clyy6ovy20007356jf7wd3dfd%2522%252C%2522sizes%2522%253A%255B100%252C0%255D%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522EDITOR%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522EDITOR%2522%252C%2522id%2522%253A%2522clyy6ovy20003356jkd91pdeg%2522%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522direction%2522%253A%2522horizontal%2522%252C%2522id%2522%253A%2522SHELLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522SHELLS%2522%252C%2522id%2522%253A%2522clyy6ovy20004356j2ffaxotj%2522%257D%255D%252C%2522sizes%2522%253A%255B100%255D%257D%255D%257D%252C%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522DEVTOOLS%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522contentType%2522%253A%2522DEVTOOLS%2522%252C%2522id%2522%253A%2522clyy6ovy20006356j349ukzj6%2522%257D%255D%252C%2522sizes%2522%253A%255B100%255D%257D%255D%252C%2522sizes%2522%253A%255B60.0402375934087%252C39.9597624065913%255D%257D%252C%2522tabbedPanels%2522%253A%257B%2522clyy6ovy20003356jkd91pdeg%2522%253A%257B%2522tabs%2522%253A%255B%257B%2522id%2522%253A%2522clyy6ovy20002356j23qcqq2e%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522type%2522%253A%2522FILE%2522%252C%2522filepath%2522%253A%2522%252Findex.js%2522%252C%2522state%2522%253A%2522IDLE%2522%252C%2522initialSelections%2522%253A%255B%257B%2522startLineNumber%2522%253A4%252C%2522startColumn%2522%253A26%252C%2522endLineNumber%2522%253A4%252C%2522endColumn%2522%253A26%257D%255D%257D%255D%252C%2522id%2522%253A%2522clyy6ovy20003356jkd91pdeg%2522%252C%2522activeTabId%2522%253A%2522clyy6ovy20002356j23qcqq2e%2522%257D%252C%2522clyy6ovy20006356j349ukzj6%2522%253A%257B%2522tabs%2522%253A%255B%257B%2522id%2522%253A%2522clyy6ovy20005356j888w65x8%2522%252C%2522mode%2522%253A%2522permanent%2522%252C%2522type%2522%253A%2522UNASSIGNED_PORT%2522%252C%2522port%2522%253A0%252C%2522path%2522%253A%2522%252F%2522%257D%255D%252C%2522id%2522%253A%2522clyy6ovy20006356j349ukzj6%2522%252C%2522activeTabId%2522%253A%2522clyy6ovy20005356j888w65x8%2522%257D%252C%2522clyy6ovy20004356j2ffaxotj%2522%253A%257B%2522tabs%2522%253A%255B%255D%252C%2522id%2522%253A%2522clyy6ovy20004356j2ffaxotj%2522%257D%257D%252C%2522showDevtools%2522%253Atrue%252C%2522showShells%2522%253Afalse%252C%2522showSidebar%2522%253Atrue%252C%2522sidebarPanelSize%2522%253A15%257D

问题
2.22 升级了高德地图同步方式，采用与 Mapbox 一致的架构，高德采用了偏移坐标，在高仰角情况下，移动图形到边缘（非中心点），会存在偏移情况。

新版和旧版在仰角非常大的情况下，绘制的图层跑天上
在 Mapbox 上不存在这个问题

2.22 版本

开启 60 倾角
复现 demo

https://github.com/user-attachments/assets/64a84c4f-8055-4cf2-afbc-1f413583596d
2.21 版本

开启 60 倾角
复现 demo

https://github.com/user-attachments/assets/4a075ae0-a101-42c0-9115-5d412f3e9f5f


text:
🐛 [BUG]

PolygonLayerProps 配置 raisingHeight高度无效
const layerOptions: Omit<PolygonLayerProps, 'source'> = {
    autoFit: true,
    shape: 'fill',
    color: "#0DCCFF",
    state: {
        active: true,
    },
    style: {
        raisingHeight: 200000,
        opacity: 0.5,
    },
};

需要手动在源文件中增加才可以
/Users/canonls/Desktop/CanonLs/tempReact/node_modules/.pnpm/@antv+l7-composite-layers@0.17.1_@antv+l7@2.22.1/node_modules/@antv/l7-composite-layers/dist/lib/core-layers/polygon-layer/types.d.ts
import { CoreLayerOptions } from '../../core/core-layer';
/**
 * 面图层 图形形状
 */
export type PolygonShape = 'fill' | 'line' | 'extrude';
/**
 * 面图层 图层样式
 */
export type PolygonLayerStyleOptions = {
    opacity?: number;
/**
 * !!!!!! 在这里手动添加⬇
 */
    raisingHeight?:number
};
/**
 * 面图层配置
 */
export interface PolygonLayerOptions extends CoreLayerOptions {
    /**
     * 图形形状
     */
    shape?: PolygonShape;
    /**
     * 图层样式
     */
    style?: PolygonLayerStyleOptions;
}

🐛 Bug description [Please make everyone to understand it]

Please provide a link by forking these links LarkMap or GitHub repo, a minimal reproduction.

Required Link to minimal reproduction:

📷 Step to reproduce
🏞 Expected result
🚑 Any additional [like screenshots]

LarkMap Version:
Platform:

指的是类型问题吧

对的 type PolygonLayerStyleOptions 在源文件里面之定义了 opacity?: number; 并没有raisingHeight 等其他属性 所以我不知道怎么使用raisingHeight 就手动改源文件了。这个是就这样设计的吗 还是说我用错了..

是指类型问题是吧

就像这段代码
const layerOptions: Omit<TextLayerProps, 'source'> = {
    autoFit: true,
    field: 'text',
    style: {
        fill: {
            field: 't',
            value: [
                '#ffba08',
                '#faa307',
                '#f48c06',
                '#e85d04',
                '#dc2f02',
                '#d00000',
                '#9d0208',
                '#6a040f',
                '#370617',
                '#03071e',
            ],
        },
        opacity: 1,
        fontSize: 18,
        textAnchor: 'center', // 文本相对锚点的位置 center|left|right|top|bottom|top-left
        spacing: 2, // 字符间距
        padding: [1, 1], // 文本包围盒 padding [水平，垂直]，影响碰撞检测结果，避免相邻文本靠的太近
        stroke: '#0ff', // 描边颜色
        strokeWidth: 0.2, // 描边宽度
        textAllowOverlap: true,
        raisingHeight: 200000 + 150000 + 10000,

    },
};

style属性raisingHeight 会报错 提示如图

所以 是我的用法错了吗。。。。

类型没有更新，可以来提 PR 帮忙加一下～
代码在这个仓库里 https://github.com/antvis/L7Plot/blob/main/packages/composite-layers/src/core-layers/text-layer/types.ts

authors: CanonLs lvisei

repo: antvis/LarkMap


text:
feat: Update Angular Lib provide data to the Angular Template

I added in my own Copy of this Angular Lib this Piece to give through the node data to the rendered html template. My interesting also for others?
In Angular you could access then the Data like this:
<ng-template #template let-data="data">
...

Description
Adding the Context from the node Data to the Angular Template
Motivation and Context
Implemented in my own Project like this
Types of changes

[ ] 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 change)
[x] Enhancement (changes that improvement of current feature or performance)
[ ] Refactoring (changes that neither fixes a bug nor adds a feature)
[ ] Test Case (changes that add missing tests or correct existing tests)
[ ] Code style optimization (changes that do not affect the meaning of the code)
[ ] Docs (changes that only update documentation)
[ ] Chore (changes that don't modify src or test files)

Self Check before Merge

[ ] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Pull Request Test Coverage Report for Build 1044498654

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build 1032506946:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls

@Eve-Sama  帮忙 review 一下这个 PR

你好, 最近工作比较忙, 暂时无法为你review, 我预计本周末或下周末为你review.
如你想要立刻获得该PR支持, 你可以参考下一个demo仓库  因为x6-angular-shape是扩展了X6, 而不是直接修改X6可视化引擎底层的. 所以你也完全可以把该部分源码放在你自己的项目内部.
再次感谢你提的这个PR, 这非常有价值.

本地测试了下, 存在以下问题.
第一, 不必判断node.data是否存在. 因为node一定是存在的, 所以node.data这句话最多只是个null. 而TemplatePortal的构造函数声明如下
new TemplatePortal<{}>(template: TemplateRef<{}>, viewContainerRef: ViewContainerRef, context?: {} | undefined): TemplatePortal<{}>
所以, context是可以为空的, 直接传递node.data就可以了.
第二, ComponentPortal不应该传递node.data, 因为他的构造函数为
new ComponentPortal<any>(component: ComponentType<any>, viewContainerRef?: ViewContainerRef | null | undefined, injector?: Injector | null | undefined, componentFactoryResolver?: ComponentFactoryResolver | ... 1 more ... | undefined): ComponentPortal<...>
从定义上看, 第三个参数是Injector而不是一个普通对象. 你可以参考下zorro的nzComponentParams是如何传递给组件的.

关于在组件渲染的场景下, 我确实也不了解应该如何传递参数给组件(不是template), 你的这个写法, 不会报错, 但是我想了解下在你的这个写法下new ComponentPortal(content, viewContainerRef, node.data), 这个组件如何拿到data呢?

Unfortunatly I couldn't get the ComponentPortal to work, I just used the TemplateRef all the time to access my data.
By just researching and trying out, it kinda works with a injector in Front.
Maybe you have a hint how to get the Component Portal to work?

Sorry, I thought you were Chinese. I think the most important thing is to help you to figure out the problem. First of all, can you tell me if the TemplateRef is the only one you need?

This PR should be closed. @NewByVector

authors: Eve-Sama NewByVector coveralls lukaswork


text:
label 结合 平移 导致 平移后 label 无法定位

你好。我使用 官网的示例
 tree.on('afterchange', function() {
        tree.getNodes().forEach(function(node) {
            const label = node.getLabel();
            const keyShape = node.getKeyShape();
            const children = node.getChildren();
            const box = keyShape.getBBox();
            const labelBox = label.getBBox();
            let dx = (box.maxX - box.minX + labelBox.maxX - labelBox.minX) / 2 + 8; // eslint-disable-line
            const dy = 0;
            if (children.length !== 0) {
                dx = -dx;
            }
            label.translate(dx, dy);
        });
        tree.draw();
    });

更改了 label 的坐标， 可是我平移后坐标将还原回去。再次更改也无法生效。

2.1 添加了 labelOffsetX 特性，可以参考这种实现方式
https://codepen.io/DoriTong/pen/MqpaNM?editors=1010

哇，文档也更新了好棒。哈哈哈

authors: Lemenxzy TomHuangCN


text:
小程序支持按需引用吗？

rt

不支持，因为小程序的npm形式必须是一个完成js, 如果想要按需引用，按这个库的思路自己封装下就可以了

authors: StephenChips zengyue


text:
Move size-limit to devDependencies

It looks like size-limit and friends were moved to dependencies by mistake, adding a bunch of transitive dependencies downstream.
This PR moves the dependencies back to devDependencies.

Thank you for the PR and for pointing this out.  v5.7.1 is out now fixing this and giving credit to you in the release notes.  Thank you for using this project and for your help in maintaining it!

authors: Kysluss aeons


text:
Updated the Donation link

Updated the Donation links to point towards the correct and more styled Donation page

@SKADE2303 Awesome contribution to Hacktoberfest'24! 🎉 Your work is super valuable. Keep up the great work!


text:
user login/register styling and logic change solution for Issues

This pull request introduces a complete redesign of the user button pop-up, enhancing its usability and overall user experience. The previous implementation has been replaced with a more intuitive design that aligns better with user expectations and interactions. solution for Issues #456
Key Changes:
The new design provides a clearer and more functional interface, making it easier for users to understand and utilize the features available.
The update eliminates redundant functionalities that have been rendered obsolete by the recent changes. This streamlining improves the performance and maintainability of the codebase.
Benefits:
Improved clarity and usability of the user button pop-up.
Enhanced user experience through a more logical interface.
Cleaner code with the removal of unnecessary elements.

plz review and merge my code

Resolve the conflicts in the mentioned files. Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch. After resolving the conflicts, please open a new PR for review.
Thank you!

authors: RohanSinghTakhi rahulkhandait-sde


text:
using type 'built' with --layer-type=squashfs fails

I'm trying to do something like the following, and it is failing, with a message like:
error: no descriptor found for reference "base"
Error initializing source oci:/home/smoser/workdir/stacker/test.d/oci:base

stacker is v0.5.0-297-g3755182.  Using --layer-type=tar works fine. Here is my stacker.yaml.
base:
  from:
    type: tar
    url: root.tar.gz
  run: |
    echo "hello world" > /message

myroot:
  from:
    type: built
    tag: base
  run: |
    echo "foo bar" > /message

I'm running with build.sh, which just downloads a root.tar.gz, and then invokes stacker clean and stacker build.
Here is full output of build.sh: build-squashfs.log

OK, good news.
I used the same stacker on a machine that can use '--storage-type=overlay', and magic! (well, mostly magic.  #116).
Slightly modified build.sh to run --layer-type=squashfs --layer-type=tar and --storage-type=overlay and we get:
$ ./build.sh
root.tar.gz existed
===== cleaning: stacker --debug --storage-type=overlay --stacker-dir=/tmp/xx/test.d/stacker --oci-dir=/tmp/xx/test.d/oci --roots-dir=/tmp/xx/test.d/roots clean =====
stacker version v0.5.0-297-g3755182
detected some overlay layers, assuming previous storage type overlay
using storage backend overlay
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go check-overlay]
problem cleaning roots couldn't clean rootfs dir: unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
problem cleaning roots unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
error: cleaning failed
main.doClean
        /home/smoser/src/stacker/cmd/clean.go:57
github.com/urfave/cli.HandleAction
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:524
github.com/urfave/cli.Command.Run
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/command.go:173
github.com/urfave/cli.(*App).Run
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:277
main.main
        /home/smoser/src/stacker/cmd/main.go:221
runtime.main
        /snap/go/6745/src/runtime/proc.go:204
runtime.goexit
        /snap/go/6745/src/runtime/asm_amd64.s:1374
===== building: $ stacker --debug --storage-type=overlay --stacker-dir=/tmp/xx/test.d/stacker --oci-dir=/tmp/xx/test.d/oci --roots-dir=/tmp/xx/test.d/roots build --layer-type=squashfs ====
stacker version v0.5.0-297-g3755182
no previous storage type detected
using storage backend overlay
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go check-overlay]
initializing stacker recipe: stacker.yaml
substituting $STACKER_ROOTFS_DIR to /tmp/xx/test.d/roots
substituting $STACKER_STACKER_DIR to /tmp/xx/test.d/stacker
substituting $STACKER_OCI_DIR to /tmp/xx/test.d/oci
stacker build order:
0 build /tmp/xx/stacker.yaml: requires: []
building: 0 /tmp/xx/stacker.yaml
substituting $STACKER_ROOTFS_DIR to /tmp/xx/test.d/roots
substituting $STACKER_STACKER_DIR to /tmp/xx/test.d/stacker
substituting $STACKER_OCI_DIR to /tmp/xx/test.d/oci
preparing image base...
copying root.tar.gz
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go unpack-tar --tar /tmp/xx/test.d/stacker/layer-bases/root.tar.gz --dest-dir /tmp/xx/test.d/roots/base/overlay]
lxc rootfs overlay arg overlayfs:/tmp/xx/test.d/roots/base/workaround0:/tmp/xx/test.d/roots/base/overlay
+ echo 'hello world'
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go --tag base --oci-path /tmp/xx/test.d/oci repack-overlay --layer-type squashfs --layer-type tar]
Parallel mksquashfs: Using 32 processors
Creating 4.0 filesystem on /tmp/xx/test.d/oci/stacker-squashfs-img-249582437, block size 131072.
[==================================================================================================|] 8567/8567 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 69525.50 Kbytes (67.90 Mbytes)
        33.90% of uncompressed filesystem size (205104.40 Kbytes)
Inode table size 104752 bytes (102.30 Kbytes)
        28.37% of uncompressed inode table size (369295 bytes)
Directory table size 116085 bytes (113.36 Kbytes)
        43.76% of uncompressed directory table size (265261 bytes)
Xattr table size 50 bytes (0.05 Kbytes)
        31.25% of uncompressed xattr table size (160 bytes)
Number of duplicate files found 1957
Number of inodes 10258
Number of files 7621
Number of fragments 545
Number of symbolic links  1385
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1252
Number of ids (unique uids + gids) 6
Number of uids 1
        root (0)
Number of gids 6
        root (0)
        voice (22)
        tty (5)
        unknown (81)
        unknown (35)
        man (12)
filesystem base built successfully
preparing image myroot...
lxc rootfs overlay arg overlayfs:/tmp/xx/test.d/roots/base/overlay:/tmp/xx/test.d/roots/sha256_92fc0346c3a9b396fb79be82344e9eca5c495e4da9df8b95f0345b85260a282e/overlay:/tmp/xx/test.d/roots/myroot/overlay
+ echo 'foo bar'
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go --tag myroot --oci-path /tmp/xx/test.d/oci repack-overlay --layer-type squashfs --layer-type tar]
Parallel mksquashfs: Using 32 processors
Creating 4.0 filesystem on /tmp/xx/test.d/oci/stacker-squashfs-img-824155577, block size 131072.
[========================================================================================================|] 1/1 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 0.23 Kbytes (0.00 Mbytes)
        91.12% of uncompressed filesystem size (0.25 Kbytes)
Inode table size 41 bytes (0.04 Kbytes)
        62.12% of uncompressed inode table size (66 bytes)
Directory table size 27 bytes (0.03 Kbytes)
        93.10% of uncompressed directory table size (29 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 1
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
filesystem myroot built successfully
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool
build.sh                root.tar.gz             test.d/
centos-8-x86_64.tar.xz  stacker.yaml
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/
oci/     roots/   stacker/
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/oci/
blobs/      index.json  oci-layout
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/oci/index.json
{
    "schemaVersion": 2,
    "manifests": [
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:005fbd4b8fb72838243a03e7ea8b3d518e9e9261e420c7a09caf3b2fa16c33e9",
            "size": 608,
            "annotations": {
                "org.opencontainers.image.ref.name": "base-squashfs"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:4301afd34a325794f19909fc5a04e456750673f866299f55d623b215f3d01c5a",
            "size": 607,
            "annotations": {
                "org.opencontainers.image.ref.name": "base"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:99488e54c656e41ff44a0022a7c505d51dc8b32bff2ec45c144801bb495b4543",
            "size": 764,
            "annotations": {
                "org.opencontainers.image.ref.name": "myroot-squashfs"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:c74b870a9bf7ed202f49c8b9d0dda9fa25a1bcc5ab3877d307e97bc709125247",
            "size": 761,
            "annotations": {
                "org.opencontainers.image.ref.name": "myroot"
            }
        }
    ]
}

OK, good news.
I used the same stacker on a machine that can use '--storage-type=overlay', and magic! (well, mostly magic.  #116).
Slightly modified build.sh to run --layer-type=squashfs --layer-type=tar and --storage-type=overlay and we get:
$ ./build.sh
root.tar.gz existed
===== cleaning: stacker --debug --storage-type=overlay --stacker-dir=/tmp/xx/test.d/stacker --oci-dir=/tmp/xx/test.d/oci --roots-dir=/tmp/xx/test.d/roots clean =====
stacker version v0.5.0-297-g3755182
detected some overlay layers, assuming previous storage type overlay
using storage backend overlay
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go check-overlay]
problem cleaning roots couldn't clean rootfs dir: unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
problem cleaning roots unlinkat /tmp/xx/test.d/roots/sha256_facc13c4695e8ef8137c53d615ae295acdaf5a3eb935f04dd2d8b109e7e6b14d/overlay/lib64: permission denied
error: cleaning failed
main.doClean
        /home/smoser/src/stacker/cmd/clean.go:57
github.com/urfave/cli.HandleAction
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:524
github.com/urfave/cli.Command.Run
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/command.go:173
github.com/urfave/cli.(*App).Run
        /home/smoser/go/pkg/mod/github.com/urfave/cli@v1.22.5-0.20200826140443-af7fa3de115a/app.go:277
main.main
        /home/smoser/src/stacker/cmd/main.go:221
runtime.main
        /snap/go/6745/src/runtime/proc.go:204
runtime.goexit
        /snap/go/6745/src/runtime/asm_amd64.s:1374
===== building: $ stacker --debug --storage-type=overlay --stacker-dir=/tmp/xx/test.d/stacker --oci-dir=/tmp/xx/test.d/oci --roots-dir=/tmp/xx/test.d/roots build --layer-type=squashfs ====
stacker version v0.5.0-297-g3755182
no previous storage type detected
using storage backend overlay
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go check-overlay]
initializing stacker recipe: stacker.yaml
substituting $STACKER_ROOTFS_DIR to /tmp/xx/test.d/roots
substituting $STACKER_STACKER_DIR to /tmp/xx/test.d/stacker
substituting $STACKER_OCI_DIR to /tmp/xx/test.d/oci
stacker build order:
0 build /tmp/xx/stacker.yaml: requires: []
building: 0 /tmp/xx/stacker.yaml
substituting $STACKER_ROOTFS_DIR to /tmp/xx/test.d/roots
substituting $STACKER_STACKER_DIR to /tmp/xx/test.d/stacker
substituting $STACKER_OCI_DIR to /tmp/xx/test.d/oci
preparing image base...
copying root.tar.gz
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go unpack-tar --tar /tmp/xx/test.d/stacker/layer-bases/root.tar.gz --dest-dir /tmp/xx/test.d/roots/base/overlay]
lxc rootfs overlay arg overlayfs:/tmp/xx/test.d/roots/base/workaround0:/tmp/xx/test.d/roots/base/overlay
+ echo 'hello world'
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go --tag base --oci-path /tmp/xx/test.d/oci repack-overlay --layer-type squashfs --layer-type tar]
Parallel mksquashfs: Using 32 processors
Creating 4.0 filesystem on /tmp/xx/test.d/oci/stacker-squashfs-img-249582437, block size 131072.
[==================================================================================================|] 8567/8567 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 69525.50 Kbytes (67.90 Mbytes)
        33.90% of uncompressed filesystem size (205104.40 Kbytes)
Inode table size 104752 bytes (102.30 Kbytes)
        28.37% of uncompressed inode table size (369295 bytes)
Directory table size 116085 bytes (113.36 Kbytes)
        43.76% of uncompressed directory table size (265261 bytes)
Xattr table size 50 bytes (0.05 Kbytes)
        31.25% of uncompressed xattr table size (160 bytes)
Number of duplicate files found 1957
Number of inodes 10258
Number of files 7621
Number of fragments 545
Number of symbolic links  1385
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1252
Number of ids (unique uids + gids) 6
Number of uids 1
        root (0)
Number of gids 6
        root (0)
        voice (22)
        tty (5)
        unknown (81)
        unknown (35)
        man (12)
filesystem base built successfully
preparing image myroot...
lxc rootfs overlay arg overlayfs:/tmp/xx/test.d/roots/base/overlay:/tmp/xx/test.d/roots/sha256_92fc0346c3a9b396fb79be82344e9eca5c495e4da9df8b95f0345b85260a282e/overlay:/tmp/xx/test.d/roots/myroot/overlay
+ echo 'foo bar'
stacker version v0.5.0-297-g3755182
stacker subcommand: [/usr/local/bin/stacker --oci-dir /tmp/xx/test.d/oci --roots-dir /tmp/xx/test.d/roots --stacker-dir /tmp/xx/test.d/stacker --storage-type overlay --debug internal-go --tag myroot --oci-path /tmp/xx/test.d/oci repack-overlay --layer-type squashfs --layer-type tar]
Parallel mksquashfs: Using 32 processors
Creating 4.0 filesystem on /tmp/xx/test.d/oci/stacker-squashfs-img-824155577, block size 131072.
[========================================================================================================|] 1/1 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
        compressed data, compressed metadata, compressed fragments,
        compressed xattrs, compressed ids
        duplicates are removed
Filesystem size 0.23 Kbytes (0.00 Mbytes)
        91.12% of uncompressed filesystem size (0.25 Kbytes)
Inode table size 41 bytes (0.04 Kbytes)
        62.12% of uncompressed inode table size (66 bytes)
Directory table size 27 bytes (0.03 Kbytes)
        93.10% of uncompressed directory table size (29 bytes)
Number of duplicate files found 0
Number of inodes 2
Number of files 1
Number of fragments 1
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
filesystem myroot built successfully
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool
build.sh                root.tar.gz             test.d/
centos-8-x86_64.tar.xz  stacker.yaml
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/
oci/     roots/   stacker/
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/oci/
blobs/      index.json  oci-layout
smoser@atom-lab-4:/tmp/xx$ python3 -m  json.tool test.d/oci/index.json
{
    "schemaVersion": 2,
    "manifests": [
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:005fbd4b8fb72838243a03e7ea8b3d518e9e9261e420c7a09caf3b2fa16c33e9",
            "size": 608,
            "annotations": {
                "org.opencontainers.image.ref.name": "base-squashfs"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:4301afd34a325794f19909fc5a04e456750673f866299f55d623b215f3d01c5a",
            "size": 607,
            "annotations": {
                "org.opencontainers.image.ref.name": "base"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:99488e54c656e41ff44a0022a7c505d51dc8b32bff2ec45c144801bb495b4543",
            "size": 764,
            "annotations": {
                "org.opencontainers.image.ref.name": "myroot-squashfs"
            }
        },
        {
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "digest": "sha256:c74b870a9bf7ed202f49c8b9d0dda9fa25a1bcc5ab3877d307e97bc709125247",
            "size": 761,
            "annotations": {
                "org.opencontainers.image.ref.name": "myroot"
            }
        }
    ]
}

Seems like the problem here is that
github.com/anuvu/stacker/btrfs.(*btrfs).Repack
	/home/smoser/src/stacker/btrfs/repack.go:82

Assumes that the base for a built type layer was something that got imported as OCI, which in this case it isn't.

Seems like the problem here is that
github.com/anuvu/stacker/btrfs.(*btrfs).Repack
	/home/smoser/src/stacker/btrfs/repack.go:82

Assumes that the base for a built type layer was something that got imported as OCI, which in this case it isn't.

Oh, well no it isn't either, the code checks for that. But I think I see the problem...

Oh, well no it isn't either, the code checks for that. But I think I see the problem...

repo: anuvu/stacker


text:
Fails when graph includes isolated nodes

Hi @anvaka,
Very nice work on also including the Louvain algorithm! I tried it and ran into one issue. All works great with graphs which do not include isolated nodes (nodes with a degree centrality of 0). However, when loading up a graph which includes isolates, the algorithm fails and throws cannot find node with id:.
I browser around a bit in your code and found out that your createCommunityGraph function just loops through the graph's links. Based on this, it logically excludes nodes without any links, and probably also doesn't add them to the community graph.
Since nodes without links would be assigned their own unique cluster anyway, perhaps it would be an idea to still include them in the createCommunityGraph function, but exclude them from any calculations? Their unique 'clusters' could then be assigned when the algorithm completes running.
Anyway, might be worth a fix :-)

@AVermeij ah, you are totally right! Thank you for the catch André!
Will fix this later tonight.

This should be fixed now! Please let me know if you find anything else broken.

Tested it and works very well, thanks Andrei!

authors: AVermeij anvaka


text:
Create 0000-01-02-anyaii.md

I created a branch (my-slide); I added a new file (0000-01-02-anyaii.md; and I created a commit for this file.

Merge branch to main file

Merge branch to main file

repo: anyaii/github-slideshow


text:
RFC: Add a simplified sysl command to orchastrate codegen from a sysl file

If you have a model.sysl which already defines your endpoints and you
just want to use the sysl-go rest transforms adding something like:
Codegen [~codegen]:
    @grammar="grammars/go.gen.g"
    @grammar_start="goFile"
    rest_frontend:
        @targets=["transforms/svc_types.sysl", "transforms/svc_router.sysl", "transforms/svc_handler.sysl", "transforms/svc_interface.sysl"]
    rest_backend:
        @grammar="grammar/go.gen.g"
        @targets=["transforms/svc_types.sysl", "transforms/svc_error_types.sysl", "transforms/svc_client.sysl"]

to the model will automatically run all the relevant transforms for each app with special annotations defined.

Bff:
    @codegen_transform="rest_frontend"
    @codegen_dirname="bff"
    @codegen_basepath="github.service.anz/dcx/anzapp-bff/codegen/gen"

The above will tell the new codegen command to run all the rest_frontend targets over the Bff app and
write the result to the $outdir/bff directory.
Unscientific tests with the dcx/bff sysl project dropped codegen runtime from 1min 40s to 1min 24sec (consistant)
There is also definitly room for optimisation by not reloading the transform .sysl (and grammar) multiple times.
Changes proposed in this pull request:

new command sysl syslgen --outdir=$dir <model>

This is more of a proof of concept than a final implementation. I'm not 100% convinced with the required sysl annotations (and using simple endpoints as the target names), would love some discussion
See https://github.service.anz/gist/gordonj7/6a0a80cdebde6d183b9ebeb6207c2c0b for a more full example

Why does this need to be in a different command?

Why does this need to be in a different command?

it doesnt really, I just didnt want to chnge the existing command.

repo: anz-bank/sysl


text:
stake: Remove redelegate instruction

Problem
The stake redelegate instruction will not enabled in its current state.
Summary of Changes
Since it's been part of the SDK and used downstream, it's a bit finnicky to just deprecate and remove, so here's what was done:

sdk: deprecate the instruction and stake flag without deprecating the stake flags as a whole
cli: remove the new command
program: remove the instruction processor, and all logic that uses the feature gate and stake flag
transaction-status: keep the instruction parser

Fixes #

Should we remove the feature definition?

I thought we kept around feature flags for longer to check when things were enabled, but since it was never enabled, you're right, it's probably better to just remove it.

super excited for this, will review tomorrow

@CriesofCarrots, in case you wanted to approve, I just rebased after landing https://github.com/solana-labs/solana-program-library/pull/7033, no other changes

repo: anza-xyz/agave


text:
fix: build-sbf Home Directory Error on Windows

Problem
The cargo-build-sbf command is unable to find the home directory path of the user on Windows and throws an error.
Setting the HOME env variable with set HOME=%USERPROFILE% fixes the issue but has to be run on each terminal session.
> cargo build-sbf
[2024-11-12T19:54:24.953753800Z ERROR cargo_build_sbf] Can't get home directory path: environment variable not found

Summary of Changes
Only on Windows, if the HOME env variable is not set, automatically fall back to the USERPROFILE variable, and if that is not set then throws an error.

fixes solana-labs/solana#35558

Appreciate the quick response!


text:
Use same stakes for everything in get_epoch_reward_calculate_param_info

Problem
It's not clear why get_epoch_reward_calculate_param_info() repulls stake_cache.stakes() when Stakes are already being passed into the method. This seems brittle; if a caller passes in Stakes from a different source or bank, stake_history could be inconsistent.
Summary of Changes
Use the same stakes as the other two values.
@jeffwashington , git blame says you wrote this function. Am I missing something here about why the distinct stakes()?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.9%. Comparing base (09241ae) to head (a8caea9).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #787   +/-   ##
=======================================
  Coverage    81.9%    81.9%
=======================================
  Files         851      851
  Lines      231504   231504
=======================================
+ Hits       189731   189769   +38
+ Misses      41773    41735   -38

all callers follow the pattern:
        let stakes = self.stakes_cache.stakes();
        let reward_calculate_param = self.get_epoch_reward_calculate_param_info(&stakes);

I think we can do what you did or we can get rid of the parameter. The locals are never used other than to pass into the fn.

I think we can do what you did or we can get rid of the parameter.

Okay, I'm going to go with this current approach, then, as there's a small chance it will be helpful to have the caller determine the Stakes.

Looking at the history of my reward brach, this is introduced for partioned reward v1, where we do asynchronous rewards computation. If the reward computation starts at a block after the epoch boundary, we need to pass the stakecache copied from the epoch boundary, and not use the one from current bank. The stakecache param allows such freedom.
Since we need to support recomputing reward from later on, I think we may need to have the extra stakecache parameter.

Since we need to support recomputing reward from later on, I think we may need to have the extra stakecache parameter.

I'm guessing that by "stakecache parameter" you mean the stakes input to the function. Is that correct?
But yes, this is why I think it's important to have consistency between the operands in this method, and allow the caller to pass in the desired Stakes.
(That said, my initial testing suggests that we can use the stakes from the snapshot bank for recalculation.)

Yeah. I mean stakes.
Stake loaded from snapshot may work for recompute as long as the delegated
stake doesn't change from the epoch, which I think this assumption should
be true (as we are preventing any stake delegation update instructions). I
think one way we can test with current code, is to compare the recomputed
stake reward with the stake rewards that we have stored in the snapshot,
and assert that they are the same.
Eventually, when we are confident that they are the same, we can make
storing stake rewards in snapshot as a config which can be turned off.
On Sat, Apr 13, 2024, 15:08 Tyera @.***> wrote:

Since we need to support recomputing reward from later on, I think we may
need to have the extra stakecache parameter.
I'm guessing that by "stakecache parameter" you mean the stakes input to
the function. Is that correct?
But yes, this is why I think it's important to have consistency between
the operands in this method, and allow the caller to pass in the desired
Stakes.
(That said, my initial testing suggests that we can use the stakes from
the snapshot bank for recalculation.)
—
Reply to this email directly, view it on GitHub
https://github.com/anza-xyz/agave/pull/787#issuecomment-2053746081, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABVSJFXIB65J5X5L37A3JTY5GGCLAVCNFSM6AAAAABGFBR3VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJTG42DMMBYGE
.
You are receiving this because your review was requested.Message ID:
@.***>

authors: CriesofCarrots HaoranYi codecov-commenter jeffwashington


text:
Enhanced specific return types

More specific return types can be returned for the following extended collection operations
@Override
public CollectionX peek(Consumer<? super T> c) {
// TODO Auto-generated method stub
return LazyFluentCollectionX.super.peek(c);
}
@Override
public <U, R> CollectionX zip(Seq<? extends U> other, BiFunction<? super T, ? super U, ? extends R> zipper) {
// TODO Auto-generated method stub
return null;
}
@Override
public <U, R> CollectionX zip(Stream<? extends U> other, BiFunction<? super T, ? super U, ? extends R> zipper) {
// TODO Auto-generated method stub
return null;
}
@Override
public  CollectionX<Tuple2<T, U>> zip(Stream<? extends U> other) {
// TODO Auto-generated method stub
return null;
}
@Override
public ReactiveSeq mergePublisher(Collection<? extends Publisher> publishers) {
// TODO Auto-generated method stub
return LazyFluentCollectionX.super.mergePublisher(publishers);
}
@Override
public ReactiveSeq mergePublisher(Collection<? extends Publisher> publishers, QueueFactory factory) {
// TODO Auto-generated method stub
return LazyFluentCollectionX.super.mergePublisher(publishers, factory);
}
@Override
public  ReactiveSeq flatMapPublisher(Function<? super T, ? extends Publisher<? extends R>> mapper) {
// TODO Auto-generated method stub
return LazyFluentCollectionX.super.flatMapPublisher(mapper);
}
@Override
public  ReactiveSeq flatMapPublisher(Function<? super T, ? extends Publisher<? extends R>> mapper,
int maxConcurrency) {
    ListX.of(1,2).flatMapPublisher(mapper)
    // TODO Auto-generated method stub
    return LazyFluentCollectionX.super.flatMapPublisher(mapper, maxConcurrency);
}
@Override
public <R> ReactiveSeq<R> flatMapPublisher(Function<? super T, ? extends Publisher<? extends R>> mapper,
        int maxConcurrency, QueueFactory<R> factory) {
    // TODO Auto-generated method stub
    return LazyFluentCollectionX.super.flatMapPublisher(mapper, maxConcurrency, factory);
}
@Override
public <U> IterableFunctor<U> unitIterator(Iterator<U> U) {
    // TODO Auto-generated method stub
    return null;
}
@Override
public <T2, R> Zippable<R> zip(BiFunction<? super T, ? super T2, ? extends R> fn,
        Publisher<? extends T2> publisher) {
    // TODO Auto-generated method stub
    return LazyFluentCollectionX.super.zip(fn, publisher);
}

Not needed. Return types are correct.

repo: aol/cyclops-react


text:
Add movement error

@pavi-rajes wrote this code, I've edited it and added test functions. I had to also modify postproc.rotate_spatial_data() to get this working.

i added a helper function to get dist_ts in case anyone wants it directly.

repo: aolabNeuro/analyze


text:
Aktive Abwehr für NSC

NSCs Aktive Abwehr erlauben

Erledigt.


text:
fixes bulk import filename prefix

Before this change bulk import files ended up with a name like BULK_IMPORT000008h.rf after this change the name would be I000008h.rf instead.

Does this affect 2.1? Should it be applied there first?

Looking at the 2.1 code I don't see the same problem, but I did not try running 2.1 and looking in the logs.
https://github.com/apache/accumulo/blob/2.1/server/manager/src/main/java/org/apache/accumulo/manager/tableOps/bulkVer2/PrepBulkImport.java#L246

Oh, I wonder which 3.0 change broke this, then.

Found it. Simple bug introduced in #3148, so it would not have been in 2.1.

Found it. Simple bug introduced in #3148, so it would not have been in 2.1. But I wonder if some of the other uses of these enums are also incorrect.

I reviewed all the uses of FilePrefix, and they all seem to be correct now. This was the only one that wasn't right.

I reviewed all the uses of FilePrefix, and they all seem to be correct now.

Nice.  Suppose we could add an IT that verifies each file type has the expected prefix.

authors: ctubbsii keith-turner

repo: apache/accumulo


text:
moved merge code out of TGW and into Fate

Most of the code in the new DeleteRows and MergeTablets classes was copied from TabletGroupWatcher with slight modifications (like adding the Manager as parameter).
fixes #3650

If I'm reading this correctly, this is creating the Fate op from the code in TGW, but isn't wiring it up yet. Is that correct?

This original motivation behind this change was to better organize the code in order to make add conditional mutations cleaner.  While working on it realized there was another benefit.  This change moves merging from the TGW thread to a FATE thread.  Its possible that before this change that a merge operation could prevent the primary functionality of TGW from running, which is assigning tablets.

authors: dlmarion keith-turner


text:
AMQ-6706 Allow for hooks before broker stop occurs

When Camel is run embedded within ActiveMQ it's shutdown is called at the point the broker is already stopped, this can lead to data loss as there could be exchanges that have not ended.
This adds the ability to specify preStopHook(s) that can be invoked during ActiveMQ shutdown but before the broker is shutdown.
With this Camel can gracefully shutdown while the broker is still started.

Don't see any tests here that confirm this works or ensure it remains working into the future.

@tabish121 I've added tests

repo: apache/activemq


text:
AMBARI-25719. (cont.) don't rethrow exception. just logging

What changes were proposed in this pull request?
I missed one logging on thread. I add it.
This PR follows https://github.com/apache/ambari/pull/3344#issue-1348672569 and https://github.com/apache/ambari/pull/3354.
How was this patch tested?

manually tested with cluster made by docker

https://github.com/eubnara/dockerize-ambari

@eubnara  thanks for reporting.. could have added some more assertions. Looks you already updated the patch couple times, we can improve test another PR.. Thanks for all your contribution. . +1 on PR.

authors: brahmareddybattula eubnara

repo: apache/ambari


text:
The apisix-website return 503 error

Actual Behaviour
When I visited https://apisix.apache.org/zh/docs/apisix/next/getting-started, get a 503 error.

Expected Behaviour

Return a normal html
Steps to reproduce it
visit https://apisix.apache.org/zh/docs/apisix/next/getting-started

Screenshots of the issue

Would you like to work on the issue?

resolved by ASF Infra.

authors: juzhiyuan zaunist

repo: apache/apisix-website


text:
[Java] Document Dataset for Substrait Plan (Query Dataset)

Document examples for:

Query Dataset

Solved by https://github.com/apache/arrow-cookbook/pull/310

repo: apache/arrow-cookbook


text:
Support parameter ($1) type inference for BETWEEN predicates

Is your feature request related to a problem or challenge?
We are trying to run a query like this:
SELECT ... WHERE col BETWEEN $1 AND $2

However the type inference logic in
arrow-datafusion/datafusion/sql/src/expr/mod.rs
does not handle this type of expressions.
Describe the solution you'd like
I would like the type inference logic to handle BETWEEN predicates.
Describe alternatives you've considered
No response
Additional context
No response

Thank you @andrelmartins  -- this would be a great addition

authors: alamb andrelmartins

repo: apache/arrow-datafusion


text:
Improve to_field performance by find field's data_type and nullable in dfschema in one time

Is your feature request related to a problem or challenge?
in function to_field, we called self.data_type() and self.nullable() respectively, and in the underly those functions maybe call schema.data_type() and schema.nullable() which result in call DFSchema::field_from_column two times,
https://github.com/apache/arrow-datafusion/blob/1d8a41bc8e08b56e90d6f8e6ef20e39a126987e4/datafusion/expr/src/expr_schema.rs#L377-L400
Describe the solution you'd like
we can add a method in ExprSchema like below, that search schema once both get data_type and nullable
pub trait ExprSchema: std::fmt::Debug {
    ....
    fn data_type_and_nullable(&self, col: &Column) -> Result<(&DataType, bool)>;
}

Describe alternatives you've considered
don't change
Additional context
during benchmarking in #9595 I discovered this possible improvement

will file a pr to benchmarks this


text:
update datafusion to 5.1.0 for python binding

Which issue does this PR close?
Update python binding to latest datafusion.
Rationale for this change
Python building pins datafusion by git path, we should pin to workspace path and crates.io version instead.
What changes are included in this PR?

Bump datafusion version
Fix python build

Are there any user-facing changes?
Breaking API change for dataframe join method due to major change in Rust core.

also cc @Jimexist


text:
ORC file reader support

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Be able to support reading ORC file format into Arrow arrays
Describe the solution you'd like

New crate named arrow-orc or orc to support reading ORC.
Describe alternatives you've considered

Additional context

TODO: flesh out the steps needed, e.g. support statistics, indexes, compound datatypes, async

@Jefffrey  --
I think ORC file support will be a substantial undertaking (for comparison, the parquet implementation took substantial effort from  several contributors (including @sunchao , @nevi-me @tustvold ,  and others) years to get to the point where it is now . This effort included not just the coding, but also the design, testing, documentation and review.
In order for the ORC implementation to be successful I think a similar order of magnitude of investment will be required. Without the appropriate level of support, this project will be frustrating for all involved (you and reviewers).
Therefore,  I suggest we proceed in one of two ways:

We find an arrow committer who is willing to invest their time to work with you to review the design, code, tests and documentation in the arrow-rs repository
Do the initial development of the arrow-orc crate in another repository with other collaborators, with less process overhead than in arrow-rsand when it has reach sufficient maturity we can propose donating it to the arrow project.

Unfortunately, I do not have the time to commit to helping this implementation.
Does anyone else have time to help Jefffrey implement ORC?

Regarding point 2, I actually only recently became aware of a similar repo already existing: https://github.com/wenyxu/orc-rs
Which already seems more feature complete than my initial implementation, so that could be a valid path forward if the owners of the repository are willing.
I'm not too attached to my implementation either way, was just an issue I picked up from DataFusion and decided to try my hand at implementing.

@sunchao  pointed out the existence of https://github.com/DataEngineeringLabs/orc-format as well

https://github.com/wenyxu/orc-rs is for supporting external table in ORC format. So it's born to be an ORC-Arrow bridge. https://github.com/DataEngineeringLabs/orc-format also helps a lot in implementing orc-rs. @WenyXu and me are glad to help with code and non-code parts.

Which already seems more feature complete than my initial implementation, so that could be a valid path forward if the owners of the repository are willing.

At present, orc-rs only support a limited type and are read-only. I'm willing and happy to push it into next stage 😉

Looks like best way forward would be to focus on building the implementation in orc-rs crate. 👍

Here is the difference list of what orc-rs is lacking by comparing orc-rs' readme and https://github.com/apache/arrow-rs/pull/4981

datatype Tinyint
compress LZO
compress LZ4
compress SNAPPY

Would that be a good point to kick off (again)?
And cc @alamb, do you have any suggestions on how we should start collaborating? Like something similar to datafusion-contrib

And cc @alamb, do you have any suggestions on how we should start collaborating. Is something similar to datafusion-contrib necessary?

datafusion-contrib sounds like a good plan to me. I made https://github.com/datafusion-contrib/datafusion-orc and added you both @waynexia  and @Jefffrey  as admins
Another thing that is important is that if we eventually want to bring this into an apache repository, we should track the provenance (aka if it is a fork or has code from other repos, we should document where that code came from so we can ensure there is no legal ownership hurdles)

authors: Jefffrey alamb waynexia

repo: apache/arrow-rs


text:
Update rust version 1.59

Which issue does this PR close?

Closes #1377
Rationale for this change

None
What changes are included in this PR?
update the rust version
Are there any user-facing changes?

None

Codecov Report

Merging #1411 (25b4455) into master (ab41c25) will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1411      +/-   ##
==========================================
+ Coverage   83.10%   83.16%   +0.06%
==========================================
  Files         181      182       +1
  Lines       53244    53394     +150
==========================================
+ Hits        44247    44406     +159
+ Misses       8997     8988       -9

Impacted Files
Coverage Δ

arrow/src/array/transform/mod.rs
86.31% <0.00%> (-0.12%)
:arrow_down:

arrow/src/array/ffi.rs
100.00% <0.00%> (ø)

arrow/src/util/reader_parser.rs
65.21% <0.00%> (ø)

arrow/src/array/array_binary.rs
93.28% <0.00%> (+0.05%)
:arrow_up:

parquet/src/encodings/encoding.rs
93.71% <0.00%> (+0.19%)
:arrow_up:

arrow/src/array/equal/mod.rs
93.24% <0.00%> (+0.33%)
:arrow_up:

parquet/src/file/serialized_reader.rs
95.65% <0.00%> (+1.04%)
:arrow_up:

arrow/src/ffi.rs
85.78% <0.00%> (+1.16%)
:arrow_up:

arrow/src/csv/reader.rs
89.89% <0.00%> (+1.56%)
:arrow_up:

arrow/src/datatypes/ffi.rs
73.65% <0.00%> (+2.80%)
: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 ab41c25...25b4455. Read the comment docs.

Why would this need updating? It is the minimum supported version of rust.
See:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

Why would this need updating? It is the minimum supported version of rust. See: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

Thanks for your reply.❤

We can close this related issue

authors: Dandandan codecov-commenter jackwener


text:
Add support for more fused boolean operations

Which issue does this PR close?

Closes #5297.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Thank you

authors: RTEnzyme tustvold


text:
[GO] CSV not handling all extensions

Describe the enhancement requested
Seems like CSV missing some types at the moment (including BinaryType and BinaryFixedLengthType) - https://github.com/apache/arrow/blob/main/go/arrow/csv/common.go#L217
Also, missing handling of ArrowExtensionTypes (similar to https://github.com/apache/arrow/issues/34330).
Will be happy to contribute support for some of the missing types unless there are some restrictions on supporting those types in a csv?
Component(s)
Go

@yevgenypats there's no restrictions on supporting those types in CSV, just needing to determine how we want to.
Extension types aren't too bad, you can just process them as their underlying storage type. The Binary and BinaryFixedLength types should probably assume base64 encoding of the data in the CSV and decode accordingly.
I'll gladly review a PR for you contributing those!

Thanks @zeroshade . I'll take a stab at this one first, as seems it's easier then the parquet one.

It absolutely will be haha. Though the same advice for extension types goes here: if it's an extension type just process it as it if was the underlying storage type.
One thing you can try for binary types might be to also update the auto-detection to try base64 decoding the values before defaulting to just string types and if it can successfully base64 decode the data then assume it is binary (possibly, but not entirely necessary, i'm fine with binary not being supported in auto-detection).
Another future enhancement I wanted to eventually work on for CSVs was to try to sample more than just the first line for the auto-detection of types to allow for better handling. But obviously that doesn't need to be part of this at all

One question I do have, is how to correctly handle list types which are not handled at all at the moment. should it be configurable or should we use something like { and } to mark that a field is a list in a csv?

That's definitely a good question. So in theory the only real use for putting { or [ to mark the field would be for the auto detection (and that should be configurable), alternately a user could essentially pipe the records through a channel and then process a column if they know it's a list/json/whatever and expand that column themselves....
If you want to process a list type column via csv you'll have to essentially have every row parse that value as if it were its own one-line CSV basically.... and then convert each value to the correct type. I mean, it'd definitely be convenient for users if you want to implement that but I'd definitely say you should make a separate issue/PR for that from this. Maybe even gather feedback. I'll take a look at how the C++ library handles (or doesn't handle) list types for CSV

Thanks! Maybe a noob question but how do I iterate correctly in the following section.
case *arrow.ListType
  arr := col.(*array.List)
  l := arr.Len() // this returns the length of the list of lists.
  for i := i < l; i ++ {
    // How do I get the first list entry (that also contains a list)?
    arr.ListValues() // this returns a flattened list which is not what I want
  }

for the first question:
case *arrow.ListType:
    arr := col.(*array.List)
    listVals, offsets := arr.ListValues(), arr.Offsets()
    for i := 0; i < arr.Len(); i++ {
        // values for list index i are the values of listVals from
        // offsets[i] : offsets[i+1]
        list := array.NewSlice(listVals, int64(offsets[i]), int64(offsets[i+1]))
        defer list.Release()
        // list is now the slice of listVals containing only the values for the list at index i
        // do whatever you like with it
    }

For another example of iterating a list array, you can look at the docs: https://pkg.go.dev/github.com/apache/arrow/go/v11/arrow@v11.0.0#example-package-ListArray

Also, another question - why not use the native ToString / String in the conversion here but rather re-implement a custom one in the writer - https://github.com/apache/arrow/blob/main/go/arrow/csv/writer.go#L100

For the most part: custom null values and other customizations which don't exist for the standard String() conversion but do exist for CSV writing. There's also the customization of bool formatting.
Secondly, the way that the CSV writer works requires creating a slice of [][]string, whereas the String() method on the array produces a Go-like output of the array similar to what you'd get if it were a slice. i.e.: [0 1 2 3 4 5] as opposed to "0,1,2,3,4,5" which means if we use the standard String() method on the array, we'd have to then re-parse/split the values to get the [][]string that the CSV writer needs. It was easier to have the CSV writer do its own conversion to string to avoid having to jump through those hoops and allow possible future changes to the string representation without risking breaking the CSV writer.

Here is a first stab it, open for comments (still missing the reader part) https://github.com/apache/arrow/pull/34343

I added some comments to it

Thank you ! 🙏  taking a look now.

authors: yevgenypats zeroshade

repo: apache/arrow


text:
[C++] re2_SOURCE=BUNDLED on macOS failed

Describe the bug, including details regarding any error messages, version, and platform.
Note that Homebrew's re2 formula is installed.
FAILED: debug/gandiva-internals-test
: && /Library/Developer/CommandLineTools/usr/bin/c++ -fno-aligned-new  -Qunused-arguments -fcolor-diagnostics  -Wall -Wextra -Wdocumentation -Wshorten-64-to-32 -Wno-missing-braces -Wno-unused-parameter -Wno-constant-logical-operand -Wno-return-stack-address -Wdate-time -Wno-unknown-warning-option -Wno-pass-failed -march=armv8-a  -g -Werror -O0 -ggdb  -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names  src/gandiva/CMakeFiles/gandiva-internals-test.dir/bitmap_accumulator_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/engine_llvm_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/function_registry_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/function_signature_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/llvm_types_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/llvm_generator_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/annotator_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/tree_expr_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/encrypt_utils_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/expr_decomposer_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/expression_registry_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/selection_vector_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/lru_cache_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/to_date_holder_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/simple_arena_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/regex_functions_holder_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/decimal_type_util_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/random_generator_holder_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/hash_utils_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/gdv_function_stubs_test.cc.o src/gandiva/CMakeFiles/gandiva-internals-test.dir/interval_holder_test.cc.o -o debug/gandiva-internals-test  -Wl,-rpath,/Users/kou/work/cpp/arrow/cpp.build/debug -Wl,-rpath,/opt/homebrew/lib -Wl,-rpath,/Users/kou/work/cpp/arrow/cpp.build/lib -Wl,-rpath,/opt/homebrew/opt/llvm/lib  debug/libgandiva.1400.0.0.dylib  debug/libarrow_testing.1400.0.0.dylib  debug/libarrow.1400.0.0.dylib  google_cloud_cpp_ep-install/lib/libgoogle_cloud_cpp_storage.a  /opt/homebrew/opt/openssl@3/lib/libcrypto.dylib  /opt/homebrew/opt/openssl@3/lib/libssl.dylib  /opt/homebrew/Cellar/brotli/1.1.0/lib/libbrotlienc.dylib  /opt/homebrew/Cellar/brotli/1.1.0/lib/libbrotlidec.dylib  /opt/homebrew/Cellar/brotli/1.1.0/lib/libbrotlicommon.dylib  orc_ep-install/lib/liborc.a  /opt/homebrew/lib/libprotobuf.dylib  /opt/homebrew/lib/libaws-cpp-sdk-config.dylib  /opt/homebrew/lib/libaws-cpp-sdk-transfer.dylib  /opt/homebrew/lib/libaws-cpp-sdk-identity-management.dylib  /opt/homebrew/lib/libaws-cpp-sdk-cognito-identity.dylib  /opt/homebrew/lib/libaws-cpp-sdk-sts.dylib  /opt/homebrew/lib/libaws-cpp-sdk-s3.dylib  /opt/homebrew/lib/libaws-cpp-sdk-core.dylib  debug/libazure-storage-files-datalake.a  debug/libazure-storage-common.a  debug/libazure-storage-blobs.a  debug/libazure-identity.a  debug/libazure-core.a  /opt/homebrew/lib/libutf8proc.dylib  re2_ep-install/lib/libre2.a  lib/libarrow_gtest_maind.1.11.0.dylib  lib/libarrow_gmockd.1.11.0.dylib  /opt/homebrew/lib/libutf8proc.dylib  google_cloud_cpp_ep-install/lib/libgoogle_cloud_cpp_rest_internal.a  google_cloud_cpp_ep-install/lib/libgoogle_cloud_cpp_common.a  /opt/homebrew/lib/libabsl_cord.2308.0.0.dylib  /opt/homebrew/lib/libabsl_cordz_info.2308.0.0.dylib  /opt/homebrew/lib/libabsl_cord_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_cordz_functions.2308.0.0.dylib  /opt/homebrew/lib/libabsl_exponential_biased.2308.0.0.dylib  /opt/homebrew/lib/libabsl_cordz_handle.2308.0.0.dylib  /opt/homebrew/lib/libabsl_crc_cord_state.2308.0.0.dylib  /opt/homebrew/lib/libabsl_crc32c.2308.0.0.dylib  /opt/homebrew/lib/libabsl_crc_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_crc_cpu_detect.2308.0.0.dylib  crc32c_ep-install/lib/libcrc32c.a  /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libz.tbd  /opt/homebrew/Cellar/lz4/1.9.4/lib/liblz4.dylib  /opt/homebrew/lib/libabsl_log_internal_check_op.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_message.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_nullguard.2308.0.0.dylib  /opt/homebrew/lib/libabsl_examine_stack.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_format.2308.0.0.dylib  /opt/homebrew/lib/libabsl_str_format_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_proto.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_log_sink_set.2308.0.0.dylib  /opt/homebrew/lib/libabsl_synchronization.2308.0.0.dylib  /opt/homebrew/lib/libabsl_stacktrace.2308.0.0.dylib  /opt/homebrew/lib/libabsl_graphcycles_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_kernel_timeout_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_symbolize.2308.0.0.dylib  /opt/homebrew/lib/libabsl_debugging_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_malloc_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_demangle_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_internal_globals.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_globals.2308.0.0.dylib  /opt/homebrew/lib/libabsl_hash.2308.0.0.dylib  /opt/homebrew/lib/libabsl_bad_variant_access.2308.0.0.dylib  /opt/homebrew/lib/libabsl_bad_optional_access.2308.0.0.dylib  /opt/homebrew/lib/libabsl_city.2308.0.0.dylib  /opt/homebrew/lib/libabsl_low_level_hash.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_sink.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_entry.2308.0.0.dylib  /opt/homebrew/lib/libabsl_time.2308.0.0.dylib  /opt/homebrew/lib/libabsl_strings.2308.0.0.dylib  /opt/homebrew/lib/libabsl_string_view.2308.0.0.dylib  /opt/homebrew/lib/libabsl_strings_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_base.2308.0.0.dylib  /opt/homebrew/lib/libabsl_spinlock_wait.2308.0.0.dylib  /opt/homebrew/lib/libabsl_int128.2308.0.0.dylib  /opt/homebrew/lib/libabsl_civil_time.2308.0.0.dylib  /opt/homebrew/lib/libabsl_time_zone.2308.0.0.dylib  -Wl,-framework,CoreFoundation  /opt/homebrew/lib/libabsl_throw_delegate.2308.0.0.dylib  /opt/homebrew/lib/libabsl_raw_logging_internal.2308.0.0.dylib  /opt/homebrew/lib/libabsl_log_severity.2308.0.0.dylib  /opt/homebrew/lib/libabsl_strerror.2308.0.0.dylib  /opt/homebrew/lib/libaws-crt-cpp.dylib  /opt/homebrew/lib/libaws-c-mqtt.1.0.0.dylib  /opt/homebrew/lib/libaws-c-event-stream.1.0.0.dylib  /opt/homebrew/lib/libaws-c-s3.1.0.0.dylib  /opt/homebrew/lib/libaws-c-auth.1.0.0.dylib  /opt/homebrew/lib/libaws-c-http.1.0.0.dylib  /opt/homebrew/lib/libaws-c-io.1.0.0.dylib  /opt/homebrew/lib/libaws-c-compression.1.0.0.dylib  /opt/homebrew/lib/libaws-c-cal.1.0.0.dylib  -framework Security  /opt/homebrew/lib/libaws-c-sdkutils.1.0.0.dylib  /opt/homebrew/lib/libaws-checksums.1.0.0.dylib  /opt/homebrew/lib/libaws-c-common.1.0.0.dylib  -pthread  -lpthread  -framework CoreFoundation  debug/libazure-storage-common.a  /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libxml2.tbd  debug/libazure-core.a  /opt/homebrew/opt/openssl@3/lib/libssl.dylib  /opt/homebrew/opt/openssl@3/lib/libcrypto.dylib  /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/usr/lib/libcurl.tbd  jemalloc_ep-prefix/src/jemalloc_ep/dist//lib/libjemalloc_pic.a  mimalloc_ep/src/mimalloc_ep/lib/mimalloc-2.0/libmimalloc-debug.a  /opt/homebrew/lib/libzstd.1.5.5.dylib  /opt/homebrew/lib/libsnappy.1.1.10.dylib  lib/libarrow_gtestd.1.11.0.dylib  /opt/homebrew/opt/llvm/lib/libLLVM.dylib && :
Undefined symbols for architecture arm64:
  "re2::RE2::FullMatchN(std::__1::basic_string_view<char, std::__1::char_traits<char>>, re2::RE2 const&, re2::RE2::Arg const* const*, int)", referenced from:
      bool re2::RE2::FullMatch<>(std::__1::basic_string_view<char, std::__1::char_traits<char>>, re2::RE2 const&) in regex_functions_holder_test.cc.o
  "re2::RE2::GlobalReplace(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*, re2::RE2 const&, std::__1::basic_string_view<char, std::__1::char_traits<char>>)", referenced from:
      gandiva::ReplaceHolder::operator()(gandiva::ExecutionContext*, char const*, int, char const*, int, int*) in regex_functions_holder_test.cc.o
ld: symbol(s) not found for architecture arm64

#36379 (system library's header not bundled one's header is used) is a similar problem.
Component(s)
C++

@assignUser : Faced this issue building Velox as well
Undefined symbols for architecture arm64:
  "re2::RE2::FullMatchN(std::__1::basic_string_view<char, std::__1::char_traits<char>>, re2::RE2 const&, re2::RE2::Arg const* const*, int)", referenced from:
      bool re2::RE2::FullMatch<>(std::__1::basic_string_view<char, std::__1::char_traits<char>>, re2::RE2 const&) in libvelox_exec.a(HashJoinBridge.cpp.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

authors: aditi-pandit kou


text:
[C++][Parquet] Read consecutive column chunks in a single scan

Currently parquet-cpp calls for a filesystem scan with every single data page see https://github.com/apache/parquet-cpp/blob/a0d1669cf67b055cd7b724dea04886a0ded53c8f/src/parquet/column_reader.cc#L181
For remote filesystems this can be very inefficient when reading many small columns. The java implementation already does this and will read consecutive column chunks (and the resulting pages) in a single scan see https://github.com/apache/parquet-mr/blob/master/parquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileReader.java#L786

This might be a bit difficult to do, as it would require changing a lot of the code structure but it would certainly be valuable for workloads concerned with optimal read performance.
Reporter: Robbie Gruener / @rgruener
Note: This issue was originally created as PARQUET-1370. Please see the migration documentation for further details.

Robbie Gruener / @rgruener:
That seems to only be the case for python3. Do the pyarrow file handles not implement RawIOBase in python2 as well? As far as I can tell the code does not suggest that though those have been my results.

Robbie Gruener / @rgruener:
I see, in my case I am using the file handle from the pyarrow hdfs class which does not seem to implement the RawIOBase API. Though it should be pretty easy to work around.

Uwe Korn / @xhochy:
@rgruener I was also plagued by this issue but I wrapped my Python code in https://docs.python.org/3/library/io.html#io.BufferedReader and this gave me sufficient performance. This was especially useful for me as I'm working with object stores like S3 or Azure Blob where consecutive reads of 40kb or 512kb nearly make no difference but the HTTP request overhead is the main bottleneck.

Robbie Gruener / @rgruener:
Thanks for the tip @xhochy! Though we are reading parquet using pyarrow so I dont think it would be as straight forward as adding that buffer. Unless there is something I am not seeing?

Either way it would be nice to not have to worry about this as a user of the library.

Wes McKinney / @wesm:
Working on adding more buffered read support to Arrow C++, possibly helpful, see ARROW-3782

Wes McKinney / @wesm:
I have opened some issues related to buffering / concurrent IO in C++, e.g. https://issues.apache.org/jira/browse/ARROW-501
@rgruener In 0.10.0 the pyarrow file handles implement RawIOBase now
I don't think it would be to difficult to add a buffering reader to the Parquet hot path with a configurable buffer size. We already have a BufferedInputStream which may help

Uwe Korn / @xhochy:
I'm doing the same, my code looks as follows:

reader = …some file handle…
reader = io.BufferedReader(reader, 512 * 1024)
parquet_file = ParquetFile(reader)

This was so simple that I thought it might not be relevant for now. Having a general C++ implementation of io.BufferedReader in Arrow C++ might be a simpler approach to our problem. The usage of io.BufferedReader involves probably some additional memory copies and overhead as we have to switch between Python and C++ often.
(In my case, the file handle is coming from https://github.com/mbr/simplekv / https://github.com/blue-yonder/storefact )

Wes McKinney / @wesm:
That would be a question for @pitrou or @alendit

Wes McKinney / @wesm:
The way to address this here is to use the buffered read option
https://github.com/apache/arrow/blob/master/cpp/src/parquet/properties.h#L58
This isn't exposed in Python for some reason, so I opened
https://issues.apache.org/jira/browse/ARROW-6253


text:
ARROW-13781: [Python] Allow per column encoding in parquet writer

This PR adds a new parameter to write_table to allow parquet encodings to be defined on a per column basis. The encodings currently supported are: PLAIN, BIT_PACKED, RLE, BYTE_STREAM_SPLIT, DELTA_BINARY_PACKED, DELTA_BYTE_ARRAY    .
It is not possible to set PLAIN_DICTIONARY and RLE_DICTIONARY for fallback encoding (those options will already be used by default in the C++ Parquet library).

I think before we expose this we should make sure that Java (parquet-mr) can read "DELTA_BINARY_PACKED, DELTA_BYTE_ARRAY ." I don't think these are well tested (and emitted by default) but I could be misrembering.

I added all review suggestions, the tests are all set. I think this is ready for final review if we decide to expose it.
@emkornfield @jorisvandenbossche where could I check and ask for help on the Java side regarding https://github.com/apache/arrow/pull/11724#issuecomment-977497773?

I think before we expose this we should make sure that Java (parquet-mr) can read "DELTA_BINARY_PACKED, DELTA_BYTE_ARRAY ." I don't think these are well tested (and emitted by default) but I could be misrembering.

@emkornfield those are actually not yet implemented for writing, only for reading, IIRC (so although this PR already allows you to specify it, you still get a NotImplementedError for now)
(and also if we would have the writing ability, I think it would be useful to actually be able to do that from python to make it easier to test this)

There are a few flake8 linting errors:
INFO:archery:Running Python linter (flake8)
/arrow/python/pyarrow/tests/parquet/test_basic.py:377:80: E501 line too long (81 > 79 characters)
/arrow/python/pyarrow/tests/parquet/test_basic.py:386:80: E501 line too long (89 > 79 characters)
/arrow/python/pyarrow/tests/parquet/test_basic.py:393:80: E501 line too long (82 > 79 characters)

If the encodings aren't supported yet, why are we adding them to the API, this just seems like it will disappoint users?

The ones that are already supported are "PLAIN" and "BYTE_STREAM_SPLIT", so the keyword has some use already (but it's certainly true it turned out less useful than we initially thought when starting the PR :-))

The ones that are already supported are "PLAIN" and "BYTE_STREAM_SPLIT", so the keyword has some use already (but it's certainly true it turned out less useful than we initially thought when starting the PR :-))

Yes, I think it will be useful, just want to make sure we don't disappoint users if they see a specific enum then try to use it and get an error thrown immeidately.

Thanks @AlenkaF !

authors: AlenkaF emkornfield jorisvandenbossche


text:
GH-35651: [C++] Don't use self-move with MinGW

Rationale for this change
Because MinGW g++ reports a warning:
D:/a/arrow/arrow/cpp/src/arrow/util/small_vector_test.cc:417:22:
warning: moving 'moved_moved_ints' of type
'arrow::internal::TestSmallStaticVector<
  arrow::internal::VectorIntLikeParam<
    arrow::internal::StaticVectorTraits, arrow::MoveOnlyDataType> >::IntVectorType<5>'
{aka 'arrow::internal::StaticVectorImpl<
        arrow::MoveOnlyDataType, 5, arrow::internal::StaticVectorStorage<arrow::MoveOnlyDataType, 5, true> >'}
to itself [-Wself-move]
  417 |     moved_moved_ints = std::move(moved_moved_ints);
      |     ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:/a/arrow/arrow/cpp/src/arrow/util/small_vector_test.cc:417:22: note: remove 'std::move' call

What changes are included in this PR?
Disable self-move code only for MinGW.
Are these changes tested?
Yes.
Are there any user-facing changes?
No.

Closes: #35651

The self-move warning was suppressed in build log: https://github.com/apache/arrow/actions/runs/5007768864/jobs/8974807896#step:7:1


text:
GH-35636: [C++] Extract two expensive test suites from compute-vector-test

Rationale for this change
arrow-compute-vector-test is too big and takes a long time to run because of that.
What changes are included in this PR?
Extracting two tests.
Timings on my machine (Debug builds with ASAN).
debug/arrow-compute-vector-test > /dev/null  11.54s user 0.47s system 99% cpu 12.023 total
debug/arrow-compute-vector-sort-test > /dev/null  13.30s user 0.26s system 99% cpu 13.579 total
debug/arrow-compute-vector-selection-test > /dev/null  6.97s user 0.22s system 99% cpu 7.207 total

Are these changes tested?
Yes.
Are there any user-facing changes?
No.

Closes: #35636

@github-actions crossbow submit -g cpp

I think you need to run cmake-format for the lint step to pass... or apply the following patch:
diff --git a/cpp/src/arrow/compute/kernels/CMakeLists.txt b/cpp/src/arrow/compute/kernels/CMakeLists.txt
index a84b36a52..9084f279a 100644
--- a/cpp/src/arrow/compute/kernels/CMakeLists.txt
+++ b/cpp/src/arrow/compute/kernels/CMakeLists.txt
@@ -76,14 +76,9 @@ add_arrow_compute_test(vector_test
                        select_k_test.cc
                        test_util.cc)

-add_arrow_compute_test(vector_sort_test
-                       SOURCES
-                       vector_sort_test.cc
-                       test_util.cc)
+add_arrow_compute_test(vector_sort_test SOURCES vector_sort_test.cc test_util.cc)

-add_arrow_compute_test(vector_selection_test
-                       SOURCES
-                       vector_selection_test.cc
+add_arrow_compute_test(vector_selection_test SOURCES vector_selection_test.cc
                        test_util.cc)

 add_arrow_benchmark(vector_hash_benchmark PREFIX "arrow-compute")

Nice timings here too:
/build/build-test ~/arrow/dev/cpp
Test project /build/build-test
    Start 26: arrow-compute-vector-sort-test
    Start 25: arrow-compute-vector-test
    Start 27: arrow-compute-vector-selection-test
1/3 Test #27: arrow-compute-vector-selection-test ...   Passed    2.94 sec
2/3 Test #25: arrow-compute-vector-test .............   Passed    4.84 sec
3/3 Test #26: arrow-compute-vector-sort-test ........   Passed    6.15 sec

100% tests passed, 0 tests failed out of 3

Label Time Summary:
arrow_compute    =  13.94 sec*proc (3 tests)
unittest         =  13.94 sec*proc (3 tests)

Total Test time (real) =   6.15 sec
~/arrow/dev/cpp

real	0m6,166s
user	0m13,900s
sys	0m0,092s

I think you need to run cmake-format for the lint step to pass... or apply the following patch:

I ran the CMake linter locally and was so confused: it only says the checks doesn't pass.

The CI failures seem unrelated, I'll merge. Thanks @felipecrv !

authors: felipecrv pitrou


text:
ARROW-5754: [C++] Add override mark for ~GrpcStreamWriter

I encountered the following compile error:
../src/arrow/flight/client.cc:244:3: error: '~GrpcStreamWriter' overrides a destructor but is not marked 'override' [-Werror,-Winconsistent-missing-destructor-override]
  ~GrpcStreamWriter() = default;
  ^
../src/arrow/flight/client.h:86:27: note: overridden virtual function is here
class ARROW_FLIGHT_EXPORT FlightStreamWriter : public ipc::RecordBatchWriter {
                          ^

This change can be fix this error.

LGTM.  Just curious what compiler/version?

I use clang in Xcode 10.2.
$ clang --version
Apple LLVM version 10.0.1 (clang-1001.0.46.3)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode_10.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

+1 thank you

In theory clang should find this on Linux but our CI may not be running clang on the Flight builds

authors: emkornfield mrkn wesm


text:
ARROW-10063: [Archery][CI] Fetch main branch in archery build only when it is a pull request

Arrow's git data for the main branch is required to test the release curation scripts.
While the build properly works from pull requests it is failing on the main branch since the requested branch already exists: https://github.com/apache/arrow/runs/1148584775

Merging this to my fork's main branch to test it works properly.

It has passed on my fork so it should be good to go: https://github.com/kszucs/arrow/runs/1149604242


text:
Fixing location uri for DB entities in QuickStartV2

With the present code, on running quick_start.py, locationUri is not flowing in for DB entities. This fix will help associate the locationUri tag to the DB entities.

With the present code, on running quick_start.py, locationUri is not flowing in for DB entities. This fix will help associate the locationUri tag to the DB entities.

Started precommit for this PR - https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/603/console

+1 for the PR , thanks @shrutimantri , thanks @ashutoshm review

authors: nixonrodrigues shrutimantri

repo: apache/atlas