Can add router info in the tracing ingress span name?

Title: **
Description:
for now, we have peer host info in the egress span, but the entry span name always ingress:
Resource SchemaURL:
Resource attributes:
     -> service.name: Str(front-envoy)
ScopeSpans #0
ScopeSpans SchemaURL:
InstrumentationScope
Span #0
    Trace ID       : 6d663d6fa9db17d015f70b8bfa17a16c
    Parent ID      :
    ID             : 347e1bda01c0f7d3
    Name           : egress localhost:10000 👈 👈 👈 👈
    Kind           : Client
    Start time     : 2023-06-08 08:55:49.751258 +0000 UTC
    End time       : 2023-06-08 08:55:49.760793 +0000 UTC
    Status code    : Unset
    Status message :
Attributes:
     -> node_id: Str()
     -> zone: Str()
     -> guid:x-request-id: Str(69c16189-92ed-9998-ab63-83e05c85c311)
     -> http.url: Str(http://localhost:10000/trace/1)
     -> http.method: Str(GET)
     -> downstream_cluster: Str(-)
     -> user_agent: Str(curl/7.79.1)
     -> http.protocol: Str(HTTP/1.1)
     -> peer.address: Str(<IP_ADDRESS>)
     -> request_size: Str(0)
     -> response_size: Str(37)
     -> component: Str(proxy)
     -> upstream_cluster: Str(envoy_cluster1)
     -> upstream_cluster.name: Str(envoy_cluster1)
     -> http.status_code: Str(200)
     -> response_flags: Str(-)
	{"kind": "exporter", "data_type": "traces", "name": "logging"}
2023-06-08T08:55:54.485Z	info	TracesExporter	{"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 1}
2023-06-08T08:55:54.485Z	info	ResourceSpans #0
Resource SchemaURL:
Resource attributes:
     -> service.name: Str(envoy-1)
ScopeSpans #0
ScopeSpans SchemaURL:
InstrumentationScope
Span #0
    Trace ID       : 6d663d6fa9db17d015f70b8bfa17a16c
    Parent ID      : 347e1bda01c0f7d3
    ID             : 09900acb5756692b
    Name           : ingress  👈 👈 👈 👈
    Kind           : Server
    Start time     : 2023-06-08 08:55:49.754524 +0000 UTC
    End time       : 2023-06-08 08:55:49.760467 +0000 UTC
    Status code    : Unset
    Status message :

yeah, I think this is a reasonable requirement.

It seems we can use decorator in route to override default span name:
https://github.com/envoyproxy/envoy/blob/1e8bacf69879165b9d67fe4f1d127950e0257d5a/source/common/http/conn_manager_impl.cc#L1446-L1452

operation
(string, REQUIRED) The operation name associated with the request matched to this route. If tracing is enabled, this information will be used as the span name reported for this request.


Command not found

I have googled this issue and not found any results, so I'm hoping it's not a duplicate :)
When I installed Ionide a while back the "send file" command etc. worked as it should. but at some point in the last month or so it has stopped working and I'm not sure why.
I get the following error "command 'fsi.SendFile' not found", which not much to go on I'm afraid, but the error persists for all the FSI commands, with practically the same error.
Now I've read that it might have something to do with my PATH, but it worked earlier and I haven't changed anything about my PATH, and in fact I can still use fsharpi in any terminal, including the built in terminal in VS Code.
I'm not sure where to go from here, any help would be appreciated.

I'm afraid I can't give any instructions on how to reproduce, it just suddenly stopped working, and removing and reinstalling Ionide didn't fix it, but I can still call the commands from the terminal, so I can't see what the problem could be, but I'm open for suggestions.


Directions not initially complete in .remove() exercise

Challenge http://www.freecodecamp.com/challenges/waypoint-remove-an-element-using-jquery has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
When loading, there are no direction to remove the target. Only after you hit run do you get the instructions to .remove().

Hello @loretod
Thanks for pointing this out. The actual task needs to be in the description.
Anyone up for a PR?

Anytime! Having great fun and learning with the exercises… Thank you!
ld

On Aug 25, 2015, at 6:19 PM, Berkeley Martinez<EMAIL_ADDRESS>wrote:
Hello @loretod https://github.com/loretod
Thanks for pointing this out. The actual task needs to be in the description.
Anyone up for a PR?
—
Reply to this email directly or view it on GitHub https://github.com/FreeCodeCamp/FreeCodeCamp/issues/2692#issuecomment-134758346.

cc @benmcmahon100

actually this is a bug. Auto-run is not working on some challenges....

Fixed in the latest commit! (I hope)

fixed!


Resulting in a zero seconds audio file

I just ran like described on the readme, and got a 0 seconds file.
python -m podcastfy.client --transcript blogPost.txt
2024-10-26 16:29:17,700 - __main__ - INFO - Using transcript file: blogPost.txt
2024-10-26 16:29:17,774 - __main__ - INFO - Podcast generated successfully using edge TTS model
Podcast generated successfully using edge TTS model: ./data/audio/podcast_891b0c39dddc47d0ac99fcb7ff694ae3.mp3

The txt file has a blog post (in Portuguese). The resulting file has 260 bytes, and no sound.
There's anything I can check here to help understand whats failing?
Thank you for that incredible project!

In fact it got no qa_pairs from my text file.
Maybe it could fail since it haven't anything to talk about. :)
But, using --url as parameter to the same blog post, worked like expected. Amazing!

Thanks for your question.
The param transcript expects a transcript file generated from podcastfy. In
podcastfy you have the option to generate just the conversation in txt
format and then later take that as input to generate the audio.
What you wish is to pass a txt file as input and then generate a podcast
from it. That is currently not an available option (surprisingly!).
Instead you can pass the content of your file as a string to the para
--text, which expects raw text as input.
We will implement input by text file shortly.
I hope you enjoy the package and continue to share feedback on how we can
improve it.
Cheers!
On Sat, Oct 26, 2024, 4:48 PM Tiago Gouvêa @.***> wrote:

In fact it got no qa_pairs from my text file.
Maybe it could fail since it haven't anything to talk about. :)
But, using --url as parameter to the same blog post, worked like
expected. Amazing!
—
Reply to this email directly, view it on GitHub
https://github.com/souzatharsis/podcastfy/issues/119#issuecomment-2439717265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTMY3M4XPIBUCDLIHUK62TZ5PWZTAVCNFSM6AAAAABQVCJSYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZZG4YTOMRWGU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Great @souzatharsis , thank you for the information.
Yes, I was expecting generate the conversation from the text file, yeah. I will try the --text param next time.
The package is amazing, really loving it!
Thank you!


Create a controller to get the recently added games to Game Pass

Use HTTP request to get the recently added games to Game Pass in Recently Added page.
Requirements

The script will get the page's HTML and from there get the name of the game.
Store the game's name in cache.
Use the current xcloud_games.json file to show the game information.

All this process will be made on time per day to update the cached games.
Motivations

Show the Recently Added games in the Games&Apps page.
Show the games in the future home dashboard. #8

The recently added games is allready geted in dfea2298cdc1a17f001556de6911891272dfae25.


Add version detection macros to fix compilation errors in UE versions below 5.5

It appears that in version 5.5, they moved the namespace for InstancedStruct.h. I've added version detection macros to ensure backward compatibility.

Thanks!


Add iteratees for file writing

Right now iteratee-files only supports reading—we should add iteratees for writing.

Added in #121.


Create Enums from Commands

Add SubCommandsEnum() method to Command.Custom to create enums from Commands that can be used for Argument Type analysis by the library user after parsing.

Implemented for Comptime:

a643863

Better alternative for Runtime:

7b3da8b


Page Type Duplicate Action Returns an error when deleted user was set

(I've had this issue in 8.3.2, but didn't have time to test it on 8.4.0... from my understanding, it could re-create the error in 8.40.)
Steps to recreate

Create a page type or use existing page type
Delete a group (e.g., Administrator) from a page type
Try to duplicate the page type.
concrete5 gets the following error

Exception Occurred: /Applications/MAMP/htdocs/concrete5/concrete/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:90 An exception occurred while executing 'select cID from Pages where cParentID in () and cInheritPermissionsFromCID = ':

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') and cInheritPermissionsFromCID =' at line 1 (0)

What does it mean to "delete a group from the page type" ? From permissions? I have tried reproducing with the instructions above and can't reproduce.

@aembler Opps.. Sorry... my mistake of issues.
You just need to delete a group. (period)

This PR seemed to fix this issue
https://github.com/concrete5/concrete5/pull/7440
I'm closing.


rtabmap_ros: 0.21.1-2 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository rtabmap_ros to 0.21.1-2:

upstream repository: https://github.com/introlab/rtabmap_ros.git
release repository: https://github.com/introlab/rtabmap_ros-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: 0.21.1-1

Integrated this PR to fix https://build.ros.org/job/Nbin_uF64__rtabmap_util__ubuntu_focal_amd64__binary/

On hold, looks like there is another missing dep... will reopen another


Cant start Hyprland in any way

Hyprland Version
 System/Version info
[I] user@t-t14 ~ [SIGINT|SIGINT]> sp -Q | grep -i Hyprland
hyprland 0.39.1-5

Bug or Regression?
Bug
Description
I created issue earlies: https://github.com/hyprwm/Hyprland/issues/5678.
You told me, that i have outdated version. That was true, i installed new version from Manjaro test repos. Unfortunately, issue persists. Do u have any ideas, why is it happening? Should i provide some extra info for you?
How to reproduce

open Hyprland via display manager or from fish-shell

Crash reports, logs, images, videos
No response

crash report please

crash report please

Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
[I] valera@t-t14 ~>
[I] valera@t-t14 ~> removed '/tmp/mcfly.output.Lf2yYQzp'
HYPRLAND_LOG_WLR=1 HHYPRLAND_LOG_WLR=1 Hyprland
Welcome to Hyprland!
[LOG] Instance Signature: fe7b748eb668136dd0558b7c8279bfcd7ab4d759_1713737972
[LOG] Hyprland PID: 302441
[LOG] ===== SYSTEM INFO: =====
[LOG] System name: Linux
[LOG] Node name: t-t14
[LOG] Release: 6.1.85-1-MANJARO
[LOG] Version: #1 SMP PREEMPT_DYNAMIC Wed Apr 10 20:05:44 UTC 2024

pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
[LOG] GPU information:
04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev d1) (prog-if 00 [VGA controller])

[LOG] os-release:
NAME="Manjaro Linux"
PRETTY_NAME="Manjaro Linux"
ID=manjaro
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="32;1;24;144;200"
HOME_URL="https://manjaro.org/"
DOCUMENTATION_URL="https://wiki.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/"
BUG_REPORT_URL="https://docs.manjaro.org/reporting-bugs/"
PRIVACY_POLICY_URL="https://manjaro.org/privacy-policy/"
LOGO=manjarolinux

[LOG] ========================

[INFO] If you are crashing, or encounter any bugs, please consult https://wiki.hyprland.org/Crashes-and-Bugs/

[LOG]
Current splash: The AUR packages always work, except for the times they don't.

[LOG] Creating the EventLoopManager!
[LOG] Creating the HookSystem!
[LOG] Creating the KeybindManager!
[LOG] [hookSystem] New hook event registered: configReloaded
[LOG] Creating the AnimationManager!
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 38.13µs. Estimated average calc time: 0.19µs.
[LOG] Creating the ConfigManager!
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 16.97µs. Estimated average calc time: 0.23µs.
[LOG] Using config: /home/valera/.config/hypr/hyprland.conf
[LOG] !!!!HEY YOU, YES YOU!!!!: further logs to stdout / logfile are disabled by default. BEFORE SENDING THIS LOG, ENABLE THEM. Use debug:disable_logs = false to do so: https://wiki.hyprland.org/Configuring/Variables/#debug
[LOG] Creating the CHyprError!
[LOG] [hookSystem] New hook event registered: focusedMon
[LOG] [hookSystem] New hook event registered: preRender
[LOG] Creating the LayoutManager!
[LOG] [hookSystem] New hook event registered: preConfigReload
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 17.67µs. Estimated average calc time: 0.19µs.
[LOG] Using config: /home/valera/.config/hypr/hyprland.conf
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 8.73µs. Estimated average calc time: 0.15µs.
amdgpu: amdgpu_cs_ctx_create2 failed. (-13)

Is this enough?

pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
amdgpu: amdgpu_cs_ctx_create2 failed. (-13)

this is a problem with your driver / setup

I saw few Hyperland logs from different users, that has same errors in pcilib, amdgpu, but they didnt report about any errors. Ok, i will look into it.
Do u think, that both of this errors cause this issue or, maybe, only one of them?

no clue, never had the problem

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3543
The "amdgpu: amdgpu_cs_ctx_create2 failed. (-13)" message is just amdgpu refusing to create a high-priority context...
Hmm... Doesnt seem like smth, thats cause this issue. Is there any way to get more detailed debug? This kind of issue should have nice traceback somewhere...

Experiencing the exact same problem here so somewhat foolhardy to dismiss it so arbitarily imho...

post a crash report, then.

For me the error is as follows:-
[wlr] [render/wlr_renderer.c:262] Cannot create Vulkan renderer: disabled at compile-time
[wlr] [render/wlr_renderer.c:203] Failed to create a Vulkan renderer
[wlr] [render/wlr_renderer.c:283] Could not initialize renderer
[wlr] [backend/drm/renderer.c:20] Failed to create renderer
[wlr] [backend/drm/backend.c:226] Failed to initialize renderer
[wlr] [backend/backend.c:263] Failed to create DRM backend
[wlr] [backend/backend.c:274] Could not successfully create backend on any GPU
[wlr] [backend/backend.c:428] Failed to open any DRM device
[CRITICAL] m_sWLRBackend was NULL! This usually means wlroots could not find a GPU or enountered some issues.
[CRITICAL] Critical error thrown: wlr_backend_autocreate() failed!
Unsurprising as I've always had 'WLR_RENDERER=vulkan' set for Sway.
Removing the EV resolved the issue obviously. Still, this has never been a problem, up until a few hours ago.
Did you mean to disable Vulkan?

vulkan has been fully disabled in hyprland for about a year now. There is no vulkan renderer in hyprland

Interesting and surprised it hasn't caused any issues until now tbh. Anyway, hope it helps out HappyCthulhu nevertheless.


feat(containers) Get and display all parent containers in header and search

There are 2 main parts to this PR, the backend and the frontend changes.
backend
Creates a custom resolver in order to recursively get all parent containers for a given entity. We will be sending back a list in order from direct parent container then that container's container etc. This new field is called parentContainers.
frontend
Now get all parent containers on the frontend to display on the entity page and the entity search result card. We now show the path of containers all the way and will truncate this path by cutting off the highest level containers first (so you can always see your direct parent container). The platform content at the top of the entity page and search result card has been refactored so now it looks like this:
Subtype | [logo] Platform > instanceId > ...containers > direct parent container
I moved the entity count below the name of the entity for now as discussed, and I also moved the degree to be down by the entity count (so it looks like Degree | EntityCount)
The main thing contributing to this diff is refactoring and breaking things into their own components. I rearrange UI stuff too, but the only real functional change is now displaying all parent containers.
Here's some screenshots!
EntityProfile:

Condensed EntityProfile with truncation (and tooltip when you hover over any of the containers):

Containers search results:

Dataset search results:

Checklist

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

Thanks! It would be very helpful to my requirements


Remove dhclient on bridge interfaces

This should nested VM errors on Ubuntu 18.04 and Ubuntu 16.04

@somil55 could you please check there is no regression for case validate_network_interface_reload_via_ip_link?


Crash: toString() on null

Basically one of the two objects has a null before toString():
https://github.com/NitishGadangi/Privacy-Indicator-App/blob/2ad46f1a98202bdbe36cb388ae52022f6ecec104/app/src/main/java/com/nitish/privacyindicator/services/IndicatorService.kt#L381
Yes, I'm on 2.1.
Describe the bug : Privacy Indicator crashes when I open certain apps.
Expected Behaviour : The app should not crash.
Steps to reproduce it : Enable Privacy Indicators then open com.perol.play.pixez. This bug does not seem to occur on other apps I have.
LogCat for the issue :

Screenshots of the issue : Crash.
Smartphone Info :

Device
Sony H3123

Android Version
9

Would you like to work on the issue? Hint is provided.

I guess a simple Exception handling must solve this issue.
will add this to the upcoming update.
Thanks.

Fixed in Release 2.2
Feel free to reopen the issue if the problem still persists


Progress bar on images currently solved.

Description
What is the feature that should be added, and what would be needed.

Implimented. Closed.


option in the options page? It's under the "Advanced" section.


swagger is failing to build for docs

🐛 Summary
Running npm start results in
ModuleNotFoundError: Module not found: Error: Can't resolve '../generated/swagger.json' in '/app/docs/src/templates'
the docs container also does not build locally as a result
Expected behavior
The swagger routes would build and the docs container would be available locally.
Any helpful log output or screenshots

I believe this is generated from line 18 in /docs/package.json .


[SPARK-34585][SQL] Remove no longer needed BatchWriteHelper

What changes were proposed in this pull request?

As a follow-up to SPARK-34456, this PR removes BatchWriteHelper completely.
Why are the changes needed?

These changes remove no longer used code.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Existing tests.

cc @dongjoon-hyun @viirya @sunchao @cloud-fan @HyukjinKwon @HeartSaVioR @holdenk @huaxingao

Test build #135630 has started for PR 31699 at commit 4ac17c2.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40210/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40210/

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

Merged to master.

+1, LGTM.

late LGTM

Test build #135630 has finished for PR 31699 at commit 4ac17c2.

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

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


[FLINK-12412] [API / Type Serialization System] Allow ListTypeInfo us…

…ed for java.util.List and MapTypeInfo used for java.util.Map
What is the purpose of the change
Allow ListTypeInfo used for java.util.List and MapTypeInfo used for java.util.Map
Brief change log

*Allow ListTypeInfo used for java.util.List *
Allow  MapTypeInfo used for java.util.Map
change the test case:PojoTypeExtractionTest.testPojoWC
change the test case:TypeExtractorTest.testGenericTypeWithSubclassInput

Verifying this change
This change is already covered by existing tests, such as MapTypeInfoTest,ListTypeInfoTest.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: yes
The runtime per-record code paths (performance sensitive):  no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector:  no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented?  not documented)

@Leeviiii please see my comments in the JIRA issue

sorry, I just saw the commends , thanks. I will close this PR.


VSTest repeatedly fails

Description
We have had intermittent failures from the Test Assemblies task in Azure Devops using Hosted Pipelines for ages, but usually a re-run fixes it.
However, in the past 2 days these failures have increased significantly.  Hardly any of our builds succeed now.  The two errors we get are:
##[error]The active test run was aborted. Reason: Index was out of range. Must be non-negative and less than the size of the collection.
##[error]Parameter name: index
##[error]System.IO.IOException: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
##[error]   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
##[error]   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
##[error]   --- End of inner exception stack trace ---
##[error]   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
##[error]   at System.IO.Stream.ReadByte()
##[error]   at System.IO.BinaryReader.ReadByte()
##[error]   at System.IO.BinaryReader.Read7BitEncodedInt()
##[error]   at System.IO.BinaryReader.ReadString()
##[error]   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.SocketCommunicationManager.ReceiveRawMessage()
##[error]   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.SocketCommunicationManager.ReceiveMessage()
##[error]   at Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.DataCollection.DataCollectionRequestSender.SendAfterTestRunEndAndGetResult(ITestMessageEventHandler runEventsHandler, Boolean isCancelled)
##[error]   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.<>c__DisplayClass20_0.<AfterTestRunEnd>b__0()
##[error]   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.InvokeDataCollectionServiceAction(Action action, ITestMessageEventHandler runEventsHandler)
##[error]The operation was canceled.

and
##[error]The active test run was aborted. Reason: Test host process crashed

I think the first error may be due to the build timeout being reached and then the process being terminated.  We set a timeout of 90 mins for our builds and it looks like the vstest task can hang/freeze/deadlock and then when it gets terminated, this error occurs.
This issue is now critical to us.
We are using "latestStable" version of the task.
It could be related to this issue, but it doesn't seem like any progress has been made there: https://github.com/microsoft/vstest/issues/2261
Environment
Azure Devops hosted 2019 agent.
Workaround
It appears that we get far fewer failures if we disable parallel tests.

@ShreyasRmsft have you see this happen in other pipelines?

No - It seems to be linked to the parallel option.  So it's likely our issue, but the framework is not providing any way for us to be able to identify the issue.

Did you try running it with the diagnostic logging? https://github.com/microsoft/vstest-docs/blob/master/docs/diagnose.md
Are you running this via the dotnet task from yaml pipeline or the VSTest task from the classic pipeline?

Yes - the first error is with diagnostic logging enabled.
This is inside an Azure Devops Hosted Agent using the VSTest task using the yaml pipeline.

Could this be caused by the agent host running out of disk space?

@gregpakes it could be, and yes we have seem some intermittent instances like this before but never got around to understanding the RCA due to lack of data.
Don't think it's related to this #2261
Enable advanced diagnostics in the vstest task https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/test/vstest?view=azure-devops

This should capture a memory dump in case of crashes
Also share the full zip logs with system.debug set to true. Might give us some more ideas.

It appears that we get far fewer failures if we disable parallel tests.

This could indicate hangs in your test due to deadlocks.
To enable hang detection in the vstest task:
Select one of the options below based on the following:
You need only hang dump – Never
Need both hangdump and crash dump – On abort only

Configure the runsettings to detect hangs as show in the sample commit https://github.com/ShreyasRmsft/BasicMsTestV2Tests/commit/9660a2445d934a9aa624031be8fb2aedb7ec48f6

Here is a sample run https://dev.azure.com/shrer/hang detection/_build/results?buildId=202&view=results

Here is a link to the attachments tab of the sample run https://dev.azure.com/shrer/hang detection/_build/results?buildId=202&view=ms.vss-test-web.build-test-results-tab&runId=1000250&paneView=attachments&resultId=0

Below is a screenshot of what the attachments will look like (The last one - testhost.x86 is the dump file)

@ShreyasRmsft Super useful.  I will take a look at this.

@gregpakes Are you still experiencing these intermittent failures?

Given this was 2 years ago, I'm going to have to guess.... I'm fairly sure our issue was due to the Azure Build Agents running out of disk space (I believe you get 10GB to play with).  We created our own VMSS based on the azure agent and have been using that ever since.  No issues since.

Yeah sorry for the late reply and thanks for the reply!
There were quite a few fixes that got merged in between so if you are no longer experiencing the issue, I will close the ticket. Feel free to reopen/comment if problem shows up again.
Thanks again!


Define the size of all the matrices as a funciton of the total number of vertices

As we tested in a local repository, we saw that the simulator generates error when the number of the links interacting with the ground is not equal to 2. In fact, the size of some matrices defined as fixed numbers assuming that there are 8 number of vertices. In this PR, we define the size of all matrices as a function of the total number of the vertices.

Thank you @traversaro  and @Giulero


Upgraded from 8.6.4 -> 9.0.1 Elmjutsu hangs Atom completely

I have two colleagues that complained that they could not get elm working in Atom.
Both machines hung after a few seconds when Elmjutsu was installed and opening Atom.
I tried to upgrade from 8.6.4 -> 9.0.1 and the same happened to me.
I will try to get some profiling out, but it is hard since it hangs that too.
Out project is ~80klogs of Elm so it might be a problem on larger projects only.
The project is Elm 0.18, if that makes a difference.
In the console it spams:
Uncaught Error: Error watching file for changes: EMFILE
    at _errnoException (util.js:1024:11)
    at FSEvent.FSWatcher._handle.onchange (fs.js:1363:9)

many thousands times.
Downgrading also no longer works. Atom will still lock up if 8.6.4 is reinstalled.
EDIT:
Ok, the profile file got too big 150MB so, not going to post it here.
It is indeed the fs.js module spending all the time on error processing.
See image.

Hi @anagrius, have you tried it with smaller Elm 0.18/0.19 projects?

@halohalospecial It does not happen on smaller projects. Just checked. We don't get any:
Uncaught Error: Error watching file for changes: EMFILE
    at _errnoException (util.js:1024:11)
    at FSEvent.FSWatcher._handle.onchange (fs.js:1363:9)

I am trying to figure out how to see in the exceptions exactly which file/files it is trying to watch and fails

@halohalospecial What exactly are you watching file changes for? I see it looks like e.g. all files in node_modules are also observed.

@anagrius, you can check it here:
https://github.com/halohalospecial/atom-elmjutsu/blob/d646d2943acd7828dae6680b7231beee99707107/lib/core.js#L387

Can you also check with just Elmjutsu installed?  Maybe another Atom package is also watching files?

Sure, I will. But the hanging only occurs with Elmjutsu installed

How about adding node_modules/** to ignored?
https://github.com/halohalospecial/atom-elmjutsu/blob/d646d2943acd7828dae6680b7231beee99707107/lib/core.js#L400

Well, if you don't need to know about Elm files in there, then I would say go for it. I mean there is no need having chokidar run through all those files for nothing.

I just wiped node_modules and everything is working until I do npm install, they it hangs again. So that seems to be it.

Can you can modify your ~/.atom/packages/elmjutsu/lib/core.js to test? :grin:

Have you tried adding node_modules or node_modules/**/* to ignored?  Apparently, it's still traversing the node_modules directory with node_modules/**.

node_modules/**/* seems to do the trick!


When i change previous and next buttons in a month  first day of the month is selecting

Bug description / Feature request:
Link to minimally-working plunker that reproduces the issue (starter template: http://plnkr.co/edit/LE4F4U7AnnD3tjM9ZH4G?p=preview)
Versions
Angular:
Calendar library:
Browser name and version:

please can i know the solution for it

Do you need help with angular-bootstrap-calendar or bootstrap-ui-datetime-picker? This is support of the first one, not the second one. If you really need help with this calendar project, please specify the problem, as I cannot understand it.

Closing due to lack of response


Repeat of markers when plotting multiple SAXS

The markers are also somehow very difficult to identify. Something like this in the Matlab GUI (bigger marker, empty facecolor) would be nice

Problem solved. Closing it now.


Update google-auth-library-credentials to 1.18.0

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

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.google.auth", artifactId = "google-auth-library-credentials" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.google.auth", artifactId = "google-auth-library-credentials" }
}]

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

Superseded by #284.


Introduce length validation on developer.hero column

Purpose
When setting up my profile today, I noticed the hero text I entered got cut off on the profile show page. It seems the character length before text starts getting truncated is 65. It would be better if we let the user know they're trying to input a hero that is too long before they save and get taken back to the profile show page
Approach
Adds a maximum length validation of 65 on hero to the developer model
Adds a maxlength of 65 to the HTML input element

Oh! Thanks for bringing this up. On mobile, the truncation actually occurs much earlier.

I think we should actually drop the truncate CSS and let this wrap across multiple lines. Along with that, having a length restriction for both the hero and bio sounds like good ideas.

I'm not 100% sure what the cutoff should be yet. Here's a breakdown of existing developer profile lengths to help us make a decision.
Hero
["0-10 => 2",
 "10-20 => 14",
 "20-30 => 19",
 "30-40 => 10",
 "40-50 => 9",
 "50-60 => 4",
 "60-70 => 2",
 "70-80 => 2",
 "90-100 => 1"]

Bio
["0-50 => 8",
 "50-100 => 9",
 "100-150 => 14",
 "150-200 => 4",
 "200-250 => 8",
 "250-300 => 6",
 "300-350 => 4",
 "350-400 => 5",
 "550-600 => 1",
 "600-650 => 1",
 "750-800 => 2",
 "850-900 => 1"]

Another outstanding questions is what to do with existing profiles that violate these validations.

Yeah, let's drop truncate in one PR then come back to this one.

Instead of removing the truncate, it might be better to set up line clamping. Tailwind CSS has an official plugin for it, too. We could try 2 lines on mobile and 1 line on tablet/desktop.

Another outstanding questions is what to do with existing profiles that violate these validations.

We could run a script in the console that truncates the hero's to the character limit. I'd like to propose 65 as the cutoff since that's how many characters you can fit at the widest width. Thoughts?

@joemasilotti Actually, I don't think truncating or line-clamping is necessary since it was handled nicely in another PR that introduced the 2 column layout. I suppose the only thing left to do on this PR is decide on a limit.

I've been thinking on this one a bit. If the text is cut off after a few lines, do we really need a character length validation?
I ask because if we end up changing designs in the future it would stink to have potentially "lost" data on a migration. Or unnecessarily restricted developers from adding more info.

Totally your call. I can see either way working fine

Thanks again for the PR @caseyjenks. I'm going to close this for now because I'm not yet sure where the design of these pages will end up in the future.


Ben frontend

Started working on styling for scheduler.  Does not need a +1 yet.

Coverage remained the same at 76.82% when pulling e1d7219364b24ed2e2847a50710025d132e90476 on ben-frontend into c6e9782677ef9b69e171ca89888d58e5d1112c95 on master.

Coverage remained the same at 76.82% when pulling 98943787d449d37e3df80e16d2d8ee40afd34654 on ben-frontend into c6e9782677ef9b69e171ca89888d58e5d1112c95 on master.

:+1:


Add limited support for cube, rollup and grouping set to grammar

Add CUBE, ROLLUP and simple GROUPING SETS (i.e. one-level of nesting)
to grammar.
Add analyzer support for simple grouping sets.
Add planning and execution support for queries with a single
grouping set (this is essentially a simple GROUP BY).

Assign to @erichwang after you address the minor comment

@martint: Also ready for review, when you have a chance.

Switching to a new branch, and a new PR


Indenting multiple items in a list doesn't work if indentation is different

Reproduced in the basic example:

The (un)indenting functions shall be rewritten and based on Markdown parsing info. Meanwhile the parser (src/mode/HyperMD.ts) might also need some modifications.
That's not easy. I will create a new branch and try to make it.

Awesome! I'm trying to get accustomed to the codebase myself, so hopefully I can open a PR or two regarding this.

Awesome! I'm trying to get accustomed to the codebase myself, so hopefully I can open a PR or two regarding this.

@laobubu Any update on this or something I could help with?


Relative import ordering

I'm looking at moving over from isort, my only point of friction is relative imports.
I know they are a topic where a lot of people have strong opinions.
Our house style uses flake8-tidy-imports to limit them to same package only, we find that for same package relative is lower cognitive load than absolute, while cross package it's more cognitive load.
I see from comments and issues that you don't personally use relative imports and that having them in their own section like isort does caused a bunch of issues.
It looks like changing the sort order to place relatives last was maybe also a feature at some point although without release notes I'm not sure if/when/why, it's quite hard to tell from the git log of classify-imports.
How do you feel about changing the sort key so that relatives get placed after absolute imports rather than before?
As an unconditional behaviour it looks like it'd be maybe a half dozen lines + tests.
Obviously conditional would be a lot more work, however it seems unlikely that anyone using relative imports particularly expects them to be first.

I should add that I'm happy to have a crack at a PR, just given the history I'd like to check first if it's going to get a flat no response. And if not how you feel about the optional vs always question.

no thanks -- the whole point of the tool is there's no bikeshedding.  it does one thing and only one thing.  isort for example has a fractal of options which makes it impossible to agree on a style

ok, but what about as unconditional, which would be my suggested option anyway.

I strongly agree with limited options, I like black for that as well.

it already is unconditional?

I mean always sort relative imports after absolute ones. Don't provide an option, change the opinionated style.

Within the existing blocks, so just a couple of lines change to each of the sort_key functions. The number field at the front that's used for distinguishing from imports could be extended to have a couple more values for relative and from relative.

A new value for relative, there isn't a import .bob, clearly time for me to go home for the evening.

see now you're bikeshedding the style

I viewed it as suggesting an improvement to a bit of the style that afaik you don't personally care about.


Log incorrect result from http_handler

Close #328

Sorry, haven't seen your comments before review rerequest

It is a bit disappointing that having an error in a single callback forbids user from obtaining all the metrics (both set with ok callbacks and ones do not set with callbacks). Maybe #328 should be followed by another issue.

Now error in callback is treated like a 500-error. Or I don't understand the question?


Catkin make error

Hey,
thank you for your awesome work.
Unfortunately i getting this error message after catkin_make:
CMake Error at /home/nartmangnourt/.local/lib/python3.8/site-packages/cmake/data/share/cmake-3.26/Modules/FindQt4.cmake:1314 (message):
  Found unsuitable Qt version "5.12.8" from /usr/bin/qmake, this code
  requires Qt 4.x
Call Stack (most recent call first):
  Spaciss/pedsim_simulator/CMakeLists.txt:24 (find_package)

-- Configuring incomplete, errors occurred!
make: *** [Makefile:324: cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed

Thank you in advance for your help :)

Hi,
Thank you for your interest.
The message mentions that you have Qt version 5.12.8 installed while the code requires Qt version 4.
Either try to install SPACiSS using the noetic branch (which works with Qt 5), or install Qt version 4 if you want to use the master branch.


MINOR: Fix minikdc cleanup in system tests

The original way of stopping the minikdc process sometimes misfires because the process arg string is very long, and ps is not able to find the correct process. Using the kill_java_processes method is more reliable for finding and killing java processes.
Signed-off-by: Arjun Satish<EMAIL_ADDRESS>Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@ewencp @hachikuji any thoughts on this PR? thanks!

backport as well? presumably this is failing in similar ways on previous branches, though i'm not sure how long kill_java_processes has been around, so i'm not sure how far back we can go.

yeah, I think this hasn't been backported yet. It would be good to be put it back to 1.0 if not 0.10 (which is when this service was first added to the test suite). thanks for checking, @ewencp.


Update: Support disabling auto updates

VSCode Version: 1.5.3
OS Version: macOS Sierra 10.12

Steps to Reproduce:

in "User Settings" set parameter "update.channel" to "none"
restart VSCode
check main menu "Code", item listed as "Check For Update" will be hidden

It seems that when you opt out of VS Code auto-updates there is no ability to check for updates manually, and I think there should be ability to check for updates manually.
Do not know is it bug or "feature"😏

As designed

@fzzr- Correctly points out that users want to disable auto updates, but keep the update functionality manual.

Is this issue still open? If so, I'll take it...


Release 3.8.0

https://github.com/raxjs/rax-app/projects/2

[x] Exclude sourcemap when publish npm package
[x] build config adapt icejs2.0
[x] SPA
[x] Toggle to webpack5

Codecov Report

Merging #806 (4e30f86) into master (d86643a) will decrease coverage by 16.69%.
The diff coverage is 86.91%.

@@             Coverage Diff             @@
##           master     #806       +/-   ##
===========================================
- Coverage   48.29%   31.60%   -16.70%
===========================================
  Files          49       46        -3
  Lines        1352     1174      -178
  Branches      315      280       -35
===========================================
- Hits          653      371      -282
- Misses        699      803      +104

Impacted Files
Coverage Δ

packages/plugin-rax-app/src/constants.js
100.00% <ø> (ø)

...ackages/plugin-rax-app/src/defaultPostcssConfig.js
0.00% <0.00%> (-71.43%)
:arrow_down:

packages/plugin-rax-miniapp/src/constants.js
100.00% <ø> (ø)

packages/plugin-rax-pha/src/manifestHelpers.js
0.00% <0.00%> (ø)

packages/plugin-rax-pha/src/setEntry.js
0.00% <ø> (ø)

packages/plugin-rax-miniapp/src/setEntry.js
75.00% <40.00%> (ø)

packages/plugin-rax-app/src/getPostCssPlugin.js
63.63% <63.63%> (ø)

packages/plugin-rax-miniapp/src/index.js
57.83% <92.85%> (-1.00%)
:arrow_down:

packages/plugin-rax-app/src/base.js
88.88% <94.59%> (-1.12%)
:arrow_down:

packages/plugin-rax-app/src/index.js
100.00% <100.00%> (+3.03%)
:arrow_up:

... and 15 more


Estimate(smart)fee fixes tracker

I made a new tracker because the original issue (#3385) was fixed with the merge of (#3389), and this will now cross release lines:

[x] A new default configuration that makes estimatefee and estimatesmartfee functional, also in periods of spam - #3389
[ ] Detect and ignore when an old version of fee estimates is available in the datadir - #3433
[ ] A facility for users to configure this functionality to their liking, because developers should not dictate the fee a user pays.
[ ] Expansive documentation to using smartfees, because using this facility (or any other fee estimation facility) does not come without caveats and risk.

Where in this are you drawing the line for 1.14.7 vs. next planned?

If #3433 can get in, would be good, because saves manual intervention for operators. It's basically a tiny version of what is needed for the 3rd item. If not possible, then we can opt to skip that PR.
So the line is either in the middle, or before #3433.


proposal: ErrorOr type wrapping (T, error)

Hi everyone,
Following @robpike 's suggestion, I'd like to create a proposal for a new way to think about errors given that Go supports generics now.
This is similar in spirit the plan to think about APIs in the presence of generics but for error handling specifically.
Preliminary notes:

This is my first proposal, so apologies if I used the wrong format or if it's too long.
All names used in this proposal, such as, ErrorOr, Val(), Err(), etc, are meant for illustration purposes only and any new names are welcome!

Objective
Introduce a new type to handle errors, namely, ErrorOr, which leverages generics to overcome the following problems:

(T, error) allows for 4 possible states but the majority of APIs only use 2 states and the other 2 states could be considered incorrect.
Error-agnostic generic APIs: Generic parameters like T and generic functions like func()T cannot be instantiated with (T, error) or func()(T, error) respectively. This means API developers must artificially bake in errors in their APIs to allow callers to pass errors or pass error-returning functions.
Errors / values in channels, maps, slices
Naming problems with err.
Inconsistent use of (T, error)

The following are out of scope for this proposal:

Solve the context.Context problem for APIs.
Treat (x, y, z, ...) argument like a tuple.
Treat (T, error) return like a tuple (see alternatives considered).
Currying.

Background
The 4 states of (T, error)
The current mechanism to return errors is (T, error) which being a product type means it allows for 4 possible states, i.e., any combination of a proper / improper value, and an error or nil. But the majority of APIs only care about either returning a value or an error, they don't care about the other 2 states, which could even be considered incorrect. Notable exceptions to this rule are the io.Reader.Read API (more on this later).
Because most APIs care only about 2 states, there is an opportunity to leverage the type system and generics to eliminate the 2 undesirable states, by introducing a new type ErrorOr that can only represent a value or an error, and doesn't allow for any other states. This would be used in new generics aware APIs.
Error-agnostic generic APIs
One such API is the singleflight.Do, which could be reimagined with generics as:
func (g *Group[K, V]) Do(key K, fn func()V) (v V, shared bool)

The Do API is error-agnostic, i.e., in principle it could accept in fn either an error-returning function or not because it doesn't do anything with the error. But in current generics, it's not possible to pass an error-returning function to func()V since V cannot be instantiated with multiple-return values or (T, error).
This applies not only to singleflight but to any API that accepts a generic argument T or a generic function func()T, does not inspect that argument, but simply returns it later.
To overcome this limitation, API developers must artificially bake in errors in their APIs, for example:
func (g *Group[K, V]) Do(key Key, fn func()(V, error)) (v V, err error, shared bool)

or:
func (g *Group[K, V]) Do(key Key, fn func()V) (v V, shared bool)
func (g *Group[K, V]) DoErr(key Key, fn func()(V, error)) (v V, err error, shared bool)

both of which are suboptimal because even though this API is error-agnostic, this property was lost and it's not longer reflected in its type or enforced by the typesystem.
With ErrorOr, the burden of deciding on whether the API needs error handling or not goes away, and instead API callers have a free choice on whether to call Do with an error-returning function (e.g., func()ErrorOr[T]) or not (e.g., func()T).
Also, with ErrorOr the fact that singleflight.Do is error-agnostic remains captured in the type and enforced by the typesystem. This is a property that is worth retaining.
Another (small) benefit of the ErrorOr in this case is that the singleflight.Group implementation would be simpler because it would need to store only 1 value per call (i.e., the ErrorOr[T]) instead of storing 2 values per call (i.e., the T and the error).
Errors / values in channels, maps, slices
When I use channels to implement pipelines or glue computations together that can either return a value or fail with an error, I found myself having to define a new struct type to encapsulate the value / error to use in the channel, e.g., chan IntOrError (pre-generics).
The ErrorOr would also be useful for channels, e.g, chan ErrorOr[int] so we don't need to redefine new struct types for this use case like ValueOrError (or a generic equivalent of that) because we can reuse ErrorOr instead.
We could also store ErrorOr[T] in collections such as maps, slices, etc. For example, spawn 10 goroutines and have each store their result in []ErrorOr[int]. Another example, implement a cache with positive and negative caching, e.g., map[K]ErrorOr[V].
Naming problem with err
When we use the pattern (T, error), we need to define the err many times:
x, err := myfunc1()
if err != nil { return ... }
y, err := myfunc2()
if err != nil { return ... }

In some cases, there are no new names on the left side of := so we need a few tricks there, either by writing var err error:
x := ...
y := ...
var err error
x, err = myfunc1()
...
y, err = myfunc2()

or by defining different names for the error:
x := ...
y := ...
x, err1 := myfunc1()
y, err2 := myfunc2()

With ErrorOr we don't need tricks:
x := myfunc1()
if x.Err() != nil { return ... }
y := myfunc2()
if y.Err() != nil { return ... }
return x.Val() + y.Val(), nil

Inconsistent use of (T, error)
There are APIs that are exception to 4 states of (T, error) rule, such as, the io.Reader.Read. But they are the minority.
The documentation for this interface method requires 4 paragraphs just to explain that this API can actually return a value and an error at the same time. If it were common practice in Go to return a value and an error at the same time, it would not be necessary 4 paragraphs of documentation to explain this notable exception.
Furthermore, the fact that it requires such as careful explanation is evidence in itself that this is a pitfall for API callers. And reading through the details it sounds very error prone and confusing.
A new type like ErrorOr could also be useful for a new API like Read(...)ErrorOr[int] because it would mean more consistency regarding error handling across APIs, we could also remove those 4 paragraphs of documentation, less pitfalls for developers, and also better type safety. API callers would need to either handle the value or the error, and there would be no ambiguity in that.
Design ideas
One possible definition of ErrorOr is the following:
package erroror

import ...

type ErrorOr[T any] struct {
	value T
	err   error
}

func New[T any](value T) ErrorOr[T]     { return ErrorOr[T]{value: value} }
func Error[T any](err error) ErrorOr[T] { return ErrorOr[T]{err: err} }
func (e ErrorOr[T]) Val() T             { return e.value }
func (e ErrorOr[T]) Err() error         { return e.err }

The New and Error constructors only allow for either a value or error, they don't allow for both an error and a proper value.
Related work
The ErrorOr has different names in other languages but in essence it's the same idea:

C++ ABSL absl::StatusOr
Haskell's Data.Either
Ocaml Either
F# Result

Known issues
new(ErrorOr[T]) can create a state that is neither error not a proper value. Perhaps we would need special tooling or compiler support to prevent or produce a warning if a developer wrote this code, since it would be desirable to always use either erroror.New or erroror.Error.
Future ideas
This is out of scope for this proposal but I think it's an interesting, possible future extension of  the ErrorOr idea, that can help with Go exceptions without actually requiring exceptions.
Let's say we have a new operator (I will use <- but other syntactic choices are possible), then we could do the following:
func MyFunc(...) ErrorOr[T] ...

func OtherFunc(...) ErrorOr[T] {
  x := <- MyFunc(...)
  ...
}

func OtherFunc2(...) ErrorOr[T] {
  x := MyFunc(...)
  if x.Err() != nil {
    return x
  }
  ...
}

In this example, OtherFunc and OtherFunc2 are equivalent but in OtherFunc we use this new operator to avoid having to explicitly write the error handling code. The new operator <- does the automatic error handling for us by checking if the ErrorOr contains an error and if so, return that error to the caller. This may be an alternative to introducing exceptions without actually requiring full support for exceptions.
Alternatives considered
An alternative to ErrorOr would be to treat (T, error) like a tuple type so that a type like func()(T, error) could be used to instantiate generic functions like func()T. But this would be a much bigger change than ErrorOr with far reaching implications for the language. The ErrorOr is just a new type.
More resources
Initial discussion was https://github.com/golang/go/discussions/48287#discussioncomment-2417886

Error-agnostic generic APIs

I think it's wroth pointing out, that this doesn't need an stdlib ErrorOr type to happen. You can write those APIs and let the user decide to just use struct{ T; error } directly, write their own ErrorOr type, or use one from a third party library. A package to do that only needs a handful of lines of code and would allow the community to vote with their feet.

Errors / values in channels, maps, slices

Again, there is no need for this to live in the stdlib. Note that even today, it's not uncommon to just define a custom type Data struct { A T1; B T2 }, if you need to send multiple values over a channel. And struct { Val T; Err error } doesn't seem particularly special here - or above, for that matter.

There are APIs that are exception to 4 states of (T, error) rule, such as, the io.Reader.Read.

I think an a little bit more instructive example is io.Writer.Write.
You treat this "exception" as bad, say that ErrorOr would allow us to get rid of it. But we could have already decide just not to have it - we could've just specified that Read and Write must not return an error with a non-zero number of bytes read. The reasons we didn't have nothing to do with the absence of ErrorOr, really. It's that these APIs need to be able to return both.
But really, that's besides the point. Because I think if anything ErrorOr should be tried out via third party libraries first anyways, which will, either way, leave us with APIs doing both (T, error) and ErrorOr, so APIs which need it (and developers who want it) can just use the existing mechanism anyways.

This is out of scope for this proposal but I think it's an interesting, possible future extension of the ErrorOr idea, that can help with Go exceptions without actually requiring exceptions.

I think what you describe here is essentially the try proposal, which a) was retracted because people didn't like it and b) shows that this doesn't really need ErrorOr to work - it works just as well with the existing multiple return values.

This doesn't look like it enables any shorter, safer, or clearer form of error handling, and instead just adds an extra layer of indirection. If done in the standard library, this would be a significant churn of what is considered idiomatic for what is arguably little benefit, and it can't even handle the common usecase of multiple return values, resulting in even more inconsistency.

@merovius

I think it's worth pointing out, that this doesn't need an stdlib

I agree. It doesn't need to be in the stdlib. The only reason I mentioned the stdlib is because there might be error-returning functions in the stdlib that would like to use ErrorOr. In this case, I doubt very much that the stdlib maintainers would introduce a dependency on a third party package. But running this as a trial from a third-party package or in the experiments (exp) package would also be a good approach.

It's that these APIs need to be able to return both.

I agree with you but I think a little more needs to be said. The io.Reader.Read documentation says:
"""(...) a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil."""
So, if we consider the following case:

Read returns some bytes, nil
Stream reaches EOF
Read returns 0, io.EOF

This is equivalent to the ErrorOr[int] case. So the behaviour I proposed is already in Read, but it just happens to be one of the many cases that Read returns. So I was proposing narrowing it down to this one case.
But at the same time, if I think really long term, I imagine that at some point the ErrorOr could become the standard way of reporting errors in Go. This means that the majority of APIs would be using ErrorOr and only a minority of APIs (like io.Writer.Write) would be using (T, error).
At this point, the (T, error) would no longer be mistaken with ErrorOr[T] semantics because it would only be used by functions that actually need to return 2 values (like you said) since all the other functions that either return a value or an error would be using ErrorOr. At that point, I wouldn't want to change interfaces like io.Writer.Write at all, and perhaps even io.Reader.Read, because the ambiguity is gone.

try proposal (...) people didn't like it

Can you point me to the feedback for the try proposal so that I can evaluate whether the feedback applies to the ErrorOr proposal or not? Thanks!
@seankhliao

This doesn't look like it enables any shorter, safer, or clearer

The following is shorter (less chars), safer and clearer (it's either error or value, no ambiguity):
func (...) Error[int] {

than:
func (...) (int, error) {

This is shorter and clearer (less variables):
x := myfunc1()

than:
x, err := myfunc1()

This is shorter (less args / return values) and clearer (API type shows it's error-agnostic):
func (g *Group[K, V]) Do(key K, fn func()V) (v V, shared bool)

than:
func (g *Group[K, V]) Do(key Key, fn func()(V, error)) (v V, err error, shared bool)

This is shorter and clearer:
chan ErrorOr[int]

than:
type IntOrError {
  v int
  err error
}
chan IntOrError

idiomatic

The question of idiomacy is very debatable because the current error idiom was established in a pre-generics era. Now, with generics we want to rethink what the idiom should look like. That's the whole point of issues like this one and also https://github.com/golang/go/discussions/48287.
If we don't allow the idiom to change ever, then we will never be able to use generics to their full potential. The whole point of a feature like generics is so that we can improve the language and its libraries across and reach a new level of idiom.

it can't even handle the common usecase of multiple return values

I think it can, e.g., ErrorOr[struct{int; float32}]. And that's just one possibility. There are many others.
Also, if Go ever supports tuples, we can also combine ErrorOr with tuples, e.g., ErrorOr[(int, int)], (assuming (x, y) is the tuple syntax).

The error handling proposals have been focused on checking the error part, not the declarations. Saving a few characters on the function declaration is missing the point.
x := myfunc1()

is arguably less clear, as without context (such as knowing the type), it doesn't look like there is an error path in here.
I'm not saying that idioms can't change, but they have to bring benefits proportional to the cost they incur. Right now the benefits of this proposal aren't very clear.
Types are written once, but the values they produce are used many times.
x := foo()
if x.Err() != nil {
    return x.Err()
}

vs
x, err := foo()
if err != nil {
    return err
}

Here, it's longer and harder to read, with more symbols in the way.
ErrorOr[struct{int; float32}]

Feels like a step backwards, your type declaration is now much longer (and you haven't named the fields yet), and if you move the struct to be a named type, you now have to deal with the an inflation of types that exist solely to return multiple values when the language can already do that. You're also forcing return values to be grouped together when they may have no reason to be.

A somewhat minor point, but I think of func F() (int, error) as a function that returns an int (and also an error).  If I write func F() ErrorOr[int] then it looks like I have a function that returns an error (and also an int).  For a function that returns a value, the fact that it also returns an error is not an important fact about that function.  It would be nicer if it didn't take precedence when writing the function signature.

@jabolopes

Can you point me to the feedback for the try proposal so that I can evaluate whether the feedback applies to the ErrorOr proposal or not? Thanks!

I did. There's probably more, on golang-nuts or the subreddit or the gopher slack, but TBQH I'm not really better at finding that than you and the github issue should be plenty.
IMO it is pretty much out of the question that the same arguments apply. The only real difference between the two is that one spells it try(F()), while the other spells it <-F(). Apart from that, they seem to be exactly equivalent. Which was the real point: Doing anything like that doesn't require ErrorOr.

I agree. It doesn't need to be in the stdlib. The only reason I mentioned the stdlib is because there might be error-returning functions in the stdlib that would like to use ErrorOr. In this case, I doubt very much that the stdlib maintainers would introduce a dependency on a third party package. But running this as a trial from a third-party package or in the experiments (exp) package would also be a good approach.

FWIW the true benefit of providing it as a third party package is that it makes this discussion completely obsolete. You could just write that package, publish it and publicize it and no one could object to that. If the community likes it, people will start using it. And instead of arguing about its value in the abstract, you could file a proposal in year or two pointing at all the projects using it, to make the case of moving it into the stdlib.
I highly doubt that an addition like this would make it into the stdlib without that path. Even if we would, say, add the type to errors, 1. old stdlib function can't use it, because of backwards compatibility and 2. new functions wouldn't use it, before it has clearly crystallized as the accepted new idiom. Because consistency matters and while we can change conventions and live with the resulting inconsistency for a while, we wouldn't risk getting locked into a new convention which then gets deprecated again. That's why code which doesn't have to be in the stdlib, shouldn't start out there.
I think the history of github.com/pkg/errors can serve as a good model here. It existed as an "unblessed" third party package for years, slowly gaining adoption by the community. At some point, it became clear that the community wants something like it enough to warrant trying to put something in the stdlib. So a proposal was filed, resulting in golang.org/x/exp/errors, which eventually was moved into errors. There are a couple extra steps here and github.com/pkg/errors is not the only package which can claim heritage over this change. But the basic model is that this was done as a third party package and all the draft designs and discussions and proposals to move it into the stdlib happened after it was clear that the community wants something like it.
It just makes things better for everyone involved - you don't have to argue that it's a good idea and just do it, the Go projects can benefit from the experience gained by the community over the time as a third-party package and when we finally do add it, we can discuss bigger changes. Maybe even to the language proper. Maybe allowing the existing stdlib functions adopt it, without breaking compatibility.

@seankhliao

without context (...) it doesn't look like there is an error path in here.

The problem you are describing already exists in Go today and it relies on naming conventions (or context) for clarity. For example, the following examples are made clear not because we know the types of the variables but because we follow a naming convention. With ErrorOr, it's no different.
x := f()         // A value (i.e., not an error)
err := f()       // An error
x, err := f()    // A value and error
x, y := f()      // 2 values
x, ok := f()     // A value and a bool
x, y, ok := f()  // 2 values and a bool

Types are written once, but the values they produce are used many times.

In the general case, we should assume that both the caller and callee use ErrorOr[T], so the example is like this:
x := foo()
if x.Err() != nil {
    return x
}

and you haven't named the fields yet

A lot of APIs don't name the return values either when using (T, error). It's a matter of preference, not a strict requirement. With ErrorOr, it should be no different.

grouped together when they may have no reason to be.

The reason is so that we can instantiate generic types such as T and func()T with errors ErrorOr[T] and func()ErrorOr[T], respectively. This is not possible with the current error handling mechanism since (T, error) cannot be used to instantiate T and func()(T, error) cannot be used to instantiate func()T. This explained in detail in the section titled "Error-agnostic generic APIs".
@ianlancetaylor

It would be nicer if it didn't take precedence when writing the function signature.

I agree. If you have some ideas I'd love to hear more. Here are few ideas (in no particular order):

Change the name ErrorOr to something that emphasizes the final value rather than the error. Naming is hard, but a few options could be Result[int] or Checked[int] or Safe[int] or Handled[int], or any short form like R[int], C[int], S[int], etc. Suggestions are very much welcome!

Another way to go about this would be to use someting like Either[int, error], which is more similar to the (T, error) approach. The disadvantage of this approach is that Either does not name its methods as Val() and Err() but something more general like Left() and Right() so I think it wouldn't read as well on the calling side.

Another idea would be to have syntactic sugar for ErrorOr, for example, writing int? would mean ErrorOr[int]. For example, func MyFunc() int? would be syntactic sugar for func MyFunc() ErrorOr[int] (assuming we're still using the ErrorOr name, because that can also be changed). Instead of ? we could also pick another syntax, e.g., int+, int., int!, etc, and even invert the order, e.g., ?int, +int, .int, etc, which is probably even more consistent with the slice syntax, for which [] precedes the underlying type.

Does this go in the direction you're thinking? Feedback would be great!
@Merovius
I agree with your approach. I will create a third party package with the ErrorOr so that community members can use it if they wish. I will create this package over the weekend and paste the link to the package back to this discussion.
A few more thoughts below:

The only real difference between the two

I don't want to lose sight of the bigger picture here. This proposal is to overcome the problems with the titled sections "The 4 states of (T, error)", the "Error-agnostic generic APIs", the "Errors / values in channels, maps, slices", the "Naming problem with err", the "Inconsistent use of (T, error)".
The section about "Future ideas" is out scope and is only meant as an idea. So I don't want to reduce the whole proposal to just the "Future ideas" section.
I will take a closer look at the try proposal over the weekend to better evaluate the feedback.

discussion completely obsolete

The point of this discussion is to rethink error handling in the presence of generics. I think this got lost when my proposal's title was unilaterally changed to something with a different meaning. I have changed the title back and I'd very much like that the title's meaning remain unchanged, although the actual wording can be changed.
This proposal is not about defining the ErrorOr type, although getting feedback about the ErrorOr type is also useful.

On the title, proposals should have a clear scope and design that can be evaluated and decided upon. If you want a general discussion of error handling possibilities, it's out of scope and should be done in one of the forums

@seankhliao
I followed @robpike 's suggestion to create a proposal and chose the title following his comment "You are asking for a new way to think about errors.". So I don't see what is wrong with that.

clear scope and design

This has a clear scope described in the "Objectives" section and a clear design described in the "Design ideas" section.
I would like to have a title along the lines of "thinking error handling in the presence of generics" without you unilaterally changing it without my consent. Please let me know how we can get there. I'm open to suggestions on wording / spelling if that's the blocking issue.

The section about "Future ideas" is out scope and is only meant as an idea. So I don't want to reduce the whole proposal to just the "Future ideas" section.

FWIW I did respond to all sections as well. Except, I guess, this one, where I also thought of something else to say:

The 4 states of (T, error)

You are correct that there are 4 possible results. What I find significantly less clear is a) how much of a problem that is and b) how much of that problem your proposal solves.
There are three potential problems I can see with this:

The callee unintentionally returning both a value and an error or neither value nor error. Subjectively at least, this doesn't seem like a problem at all. I don't think I encountered this even once. But it's more or less addressed by your proposal (if we pre-suppose an accurate checker for returning the zero value).
The caller unintentionally doesn't check the error before using the value. This is definitely an occasional problem. Your proposal in part addresses this, by making it a runtime error. But I think people will generally be dissatisfied, if we don't also address it statically, given that other languages tend to be better about this.
The caller needs to figure out if a function can return both an error and a value and if so, what that means. I'm also not really sure how much of a problem this is. Personally, I don't think I'm frequently confused by the "if" question, but I'm occasionally having trouble understanding the "and if so" question. The first part is indeed solved by this proposal, for the second it doesn't help.

To me, this proposal seems to try and solve things which appear non-problems to me, while doing little to address the things which I perceive as problems. I would like at least some sort of data on how much of a problem the things it's trying to address are.

This has a clear scope described in the "Objectives" section and a clear design described in the "Design ideas" section.
I would like to have a title along the lines of "thinking error handling in the presence of generics" without you unilaterally changing it without my consent. Please let me know how we can get there. I'm open to suggestions on wording / spelling if that's the blocking issue.

The scope, according to the "Objectives" section, is to introduce a new type. So, the title seems accurate. I agree with @seankhliao that a more general "rethinking error handling" is not an appropriate github issue or proposal and should be done in a place more conducive to open-ended discussion, like golang-nuts, reddit, slack, the twitter community or some other forum.
I also think that you can be expected to abide by the processes set out by the Go project. The people who use github issues the most, to track their day-to-day work, should also have the strongest word in how they are used. There is nothing "unilateral" about that - if anything, your want for a specific title incompatible with that usage is unilateral.

if we don't also address it statically

I'd be interested in hearing more about this. How would you go about addressing it statically?

The scope, according to the "Objectives" section, is to introduce a new type.

Yes, you're right. I updated the "Objectives" section to better reflect what I intended.

abide by the processes set out by the Go project

I want to abide by the processes and AFAIK I am abiding by the processes. This is why I said I can change the title. That's not a problem. I reviewed the proposals which doesn't say anything about the title of the Github issue, so AFAICT my title should be fine (unless I missed something). I also asked for the title policy to be shared with me, but I only got that link to the proposals, so I'm assuming that's all there is to it.
Unilateral in this case means that the title was changed by someone else without ever asking me to change the title, without giving me a chance to evaluate the policy (which I haven't seen still) and a choose a better title, without a explanation of why the title was changed, without a reasoning for the new title. That's what unilateral means.
I expect mods to use go through a process of first asking the proposer to change the title (also good is to propose new titles) and if the proposer is clearly not abiding by the processes, then the mods can use their permissions to change the title.
But that is not the case here. I have demonstrated willingness to work with the process and even shown openness to change the title. So this is clearly not the case of someone not abiding by the rules. So I don't think it's correct for the mods to change the title in this case because the problem has not escalated to a place that it requires action from the mods' side. I think that's a misuse of the mods' permissions.
Also, at this point, the context is already layed out in the discussion and it's clear that the title "ErrorOr type wrapping (T, error)" is wrong. So I think it's harmful to purposefully change the proposal's title back to a title that has already been discussed that is harmful for this proposal. I don't think this is right.
I would like to request once more that we can start a discussion to change the title to a new title that resembles more something like "rethinking error handling in the presence of generics". Are y'all willing to work with me to get us closer to that place? Or is this the end of the title discussion?

Also, at this point, the context is already layed out in the discussion and it's clear that the title "ErrorOr type wrapping (T, error)" is wrong.

I disagree. The name, as well as some details, might be up for debate, but ultimately, that's the concrete change you are proposing. And it's not at all uncommon to use placeholder names in proposal-titles, even if they are still up for debate. ErrorOr is as good a place holder as Result or anything else for that purpose.
You seem to instead want to make this a non-proposal and just be an open-ended discussion about how generics might influence error handling. But you've been told that this is not how github issues are used in the Go project and that such a discussion should happen on one of the forums more suited to that. So, if you want that, you might want to close this issue and start a discussion there.
Issue titles and labels are used by bots, searches and boards to triage and categorize issues, based on how they should be handled. These processes are not necessarily fully documented, relying instead on human judgement - generally, this is a good thing, as it allows more flexibility. Someone needs to make that judgement, and for that there is a set of people trusted to have enough of an understanding of the processes involved and triage issues accordingly. One such person has triaged this issue, to the best of their abilities. You might disagree with that triage, and there is some flexibility (e.g. if you prefer a different type name), but the basics of a) github issues are not for open-ended discussions, so the issue should focus on a concrete change and b) the title should reflect that change, won't budge.
The question is, is this really what you want to spend your time arguing about? Trust me when I say that, for the concrete change you are proposing, "introduce ErrorTo[T] to wrap (T, error)`" is good enough for everyone involved to understand what the issue is about, even if it is not fully accurate. That's ultimately all that matters.

No change in consensus, so declined.
— rsc for the proposal review group


Add RedoCommandTest

Coverage increased (+0.5%) to 81.732% when pulling e4feecf48656b3480530a3dc4aea4738ee0b8d7a on chishien:master into b3480f22e93346f63ff3bf448aa54035f87dbcd6 on CS2103JUN2017-T4:master.


[stable/postgresql[ Update description and icon

PR in the context of normalizing/improving metadata in official charts. Refs https://github.com/kubernetes/charts/issues/124 and https://github.com/helm/monocular/issues/93
NOTE: I have not bumped the chartVersion attribute in order to avoid race conditions/conflicts with existing PRs. Maintainers should be able to change this value before merging (let me know if you prefer that I update it instead)
cc/ @swordbeta @databus23

@k8s-bot ok to test


Add user information to private data

There is some logic throughout the application that functions based on user information (e.g., user can only publish when email is verified).
In order to reduce the amount of queries to the server, storing this information in the private session data may help improve performance. Other operations may also benefit from this.

Blitz Docs

This issue is no longer relevant - private data is not necessary right now.
I also misunderstood the performance gains from the private data - the server would still need to be queried for it...


GEODE-9431: Replaced std regex with Boost due to RHEL8.

This seems like a really big hammer for what strikes me an issue with maybe a specific RHEL C++ runtime patch or gcc patch. I didn't see any open tickets with RHEL or GNU regarding these issues in the GEODE ticket. Given that boost::regex is the basis for std::regex if we are using std::regex incorrectly resulting in different undefined behavior in RHEL then I would be just as concerned with our use of boost::regex.

I spent most of last week picking up and discarding various "hammers" as solutions to this problem - this was the first one that worked.  Let me know what mitigations you think we need for this, I'm fine with most things.  If we need/want a JIRA ticket to revert this back once it's fixed by RedHat or whomever, that's fine.  I would also argue it's not really that big of a hammer, since the change itself took about an hour to make and verify, and backing it out is the work of a few minutes.  I'll figure out how to file the bug with RedHat and GNU today, but I don't think waiting for them to provide a fix is a viable strategy.  We need to get our CI pipeline off the floor so we can proceed with dev work and know we're not further damaging the product on RHEL-8.

This seems like a really big hammer for what strikes me an issue with maybe a specific RHEL C++ runtime patch or gcc patch. I didn't see any open tickets with RHEL or GNU regarding these issues in the GEODE ticket. Given that boost::regex is the basis for std::regex if we are using std::regex incorrectly resulting in different undefined behavior in RHEL then I would be just as concerned with our use of boost::regex.

I spent most of last week picking up and discarding various "hammers" as solutions to this problem - this was the first one that worked. Let me know what mitigations you think we need for this, I'm fine with most things. If we need/want a JIRA ticket to revert this back once it's fixed by RedHat or whomever, that's fine. I would also argue it's not really that big of a hammer, since the change itself took about an hour to make and verify, and backing it out is the work of a few minutes. I'll figure out how to file the bug with RedHat and GNU today, but I don't think waiting for them to provide a fix is a viable strategy. We need to get our CI pipeline off the floor so we can proceed with dev work and know we're not further damaging the product on RHEL-8.

As long as we can get issues opened with RH and and with ourselves to revert back to std::regex once we or RH fixes the underlying issue, I could get on board with this change.


Missing open with option

One of the good features of the current windows explorer is a open with function.

duplicate


Code coverage

Description
The check task of Gradle (which is also run by Travis) measures code coverage using JaCoCo and requires 80 % of instructions be tested.
Testing

[ ] I created new unit tests
[x] All unit tests pass
[x] I have tested manually

Have you updated the README or other relevant documentation?

[ ] Yes
[ ] Not yet. I will do it next.
[x] Not relevant

So there is some problem with Codacy. I have no idea how it should work.


Remove from cache by URL

Following the docs, If I do
let cache = Shared.JSONCache
let cache = Haneke.sharedJSONCache
let formatName = "images"
let URL = NSURL(string: "https://api.github.com/users/haneke")!

cache.fetch(URL: URL, formatName: formatName).onSuccess { JSON in
   println(JSON.dictionary?["bio"])
}

and then to remove this entry from the cache, I would need to do:
let cacheKey = URL.absoluteString!
cache.remove(key: cacheKey, formatName: formatName)

so I think allowing to do:
cache.remove(URL: URL, formatName: formatName)

makes sense.
@hpique WDYT?

Good catch @yelled3! I'm not keen of adding more convenience methods though. What about the following?
fetch(URL: URL) simply wraps URL in a NetworkFetcher, who is responsible to decide how to convert url into a key. So the solution would be for NetworkFetcher to expose the key property. It should have been public to being with. Then you can do things like:
let fetcher = NetworkFetcher<UIImage>(URL: URL);
cache.remove(key: fetcher.key);

I just made the key public in master.

@hpique nice and clean.
good job, man :+1:


[Feature][Manager] Make the default admin account configurable

Description
the default admin account is defined in the file conf/application.properties of the manager module like this:
default.admin.user=admin
default.admin.password=inlong

We can make it configurable for different users, especially for the password.
Use case
No response
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please assign to me. I'll try to work on this.

Please assign this issue to me, thx. @dockerzhang

Hi, @mroccyen thanks. due to @wilburjiang0 is doing this issue, I will assign it to him.

it's better to fix it when https://github.com/apache/inlong/issues/5049 all issues have done.

Fixed by #6206.


Automatic formatter for SQL

Describe the feature
dbt fmt, a sub-command that automatically formats the SQL in a dbt project.
Ideally, this could be run as a pre-commit hook. It would edit files in place, operating in much the same way as black or go fmt
Describe alternatives you've considered

https://pypi.org/project/sqlparse/ – does a very bad job with complex queries, doesn't understand that SQL might contain Jinja2 templates. Underlying parser is somewhat dodgy.
Writing my own – fun but I don't have any time. Also, would have to decide between my own use case (BigQuery) vs something more general
Manually formatting SQL – what we're doing now. It's a pain, and it's a waste of human creativity and energy to manually correct ones colleagues about formatting in code reviews

There's a case to be made for a super general SQL-over-Jinja2 formatter, to let people choose whether they want things like upper case keywords, but I haven't met a single person who has started using an opinionated formatter like black or go fmt who hasn't been willing to sacrifice their personal preferences for never having to care about formatting ever again.
Additional context
Not database specific, but there may well be gotchas with syntax varying between databases.
Who will this benefit?
This will primarily benefit people writing transformations, as it will mean that they won't have to care about formatting.
It will secondarily benefit code reviewers, who will no longer have to check for these things, which in turn means that teams writing analytic SQL with dbt will be able to move faster.

great idea @jml! This is something we've been mulling over in the #linters channel in dbt Slack. I love love love the idea of this, and I started a (very rough) version of this over here: https://github.com/fishtown-analytics/dbt-sql-formatter
If you're in the market for something that exists today, check out sqlfluff. This is very much on our radar too though, and we're looking forward to integrating something like this directly into dbt someday :)

Heya guys - sqlfluff has had a ton of upgrades recently, particularly on linting and fixing code for data warehouses like snowflake and bigquery.
I expect the next release (in a few weeks) might be worth doing some basic testing with. I'd also love to do some work on a public api (so that you can import sqlfluff and get sensible responses) so that it could be incorporated into dbt.
If either of you have any suggestions on what you'd want to see from a public api for sqlfluff, feel free to lodge a github issue for the kind of thing you'd like to see. This is definitely on the outline roadmap for things I'd like to support before the next major release.


Document editable install of the Python source

closes #24
This is basically just the standard procedure now that the setup.cfg change in #26 was merged, but possibly still worth documenting?

@gpucibot merge


Git error from log.object

I'm trying to do what is shown in the README, @git.log(20).object("some_file").since("2 weeks ago").between('v2.6', 'v2.7').each { |commit| [block] } but I get a Git error:
irb(main):011:0> Git.open(repo_path).log(2).object('post.html').each {|c| puts c }
Git::GitExecuteError: git '--git-dir=/path/to/my_repo/.git' '--work-tree=/path/to/my_repo' log '-2' '--no-color' '--pretty=raw' 'post.html'  2>&1:fatal: ambiguous argument 'post.html': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/lib.rb:917:in `command'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/lib.rb:846:in `command_lines'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/lib.rb:145:in `full_log_commits'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/log.rb:119:in `run_log'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/log.rb:112:in `check_log'
	from /var/lib/gems/2.1.0/gems/git-<IP_ADDRESS>/lib/git/log.rb:84:in `each'
	from (irb):11
	from /var/lib/gems/2.1.0/gems/railties-4.1.5/lib/rails/commands/console.rb:90:in `start'
	from /var/lib/gems/2.1.0/gems/railties-4.1.5/lib/rails/commands/console.rb:9:in `start'
	from /var/lib/gems/2.1.0/gems/railties-4.1.5/lib/rails/commands/commands_tasks.rb:69:in `console'
	from /var/lib/gems/2.1.0/gems/railties-4.1.5/lib/rails/commands/commands_tasks.rb:40:in `run_command!'
	from /var/lib/gems/2.1.0/gems/railties-4.1.5/lib/rails/commands.rb:17:in `<top (required)>'
	from ./bin/rails:4:in `require'
	from ./bin/rails:4:in `<main>'

I'm using version <IP_ADDRESS> of the gem. The post.html file exists in the repository, but was not changed in the latest two commits that log(2) should be fetching. Am I using this wrong?

I'm using git version 1.9.1 in Linux. Maybe just add -- before the file name?

I was able to reproduce the same error by using an incomplete path. Is your "post.html" inside a directory in the repo? If so, can you try specifying the path starting from the top of the repo?

No, post.html is in the root of the repository.

It appears that either the documentation is slightly wrong/misleading, or that the code has a bug; I'm honestly not sure which to consider it. If you change "object" to "path", it will work.
When you call the "path" method, the gem uses "--" in the native command to signify a path follows; if you use "object", it does not use "--" so the native command gets confused as to whether you're providing a path or a commit sha. The way the code reads, though, I'm not sure how an "object" would ever be useful in that context, as it's handled inside the log_path_options of Git::Lib.