Lock continuation before calling event handler.

(cherry picked from commit 4aca609fe08df4b253f8c03aaab6201335c171f2)
Conflicts:
iocore/hostdb/HostDB.cc

Did this make it into an 8.0.x release yet? I'm still slightly concerned about this, specially with @vmamidi having concerns here too.

We don't plan on creating another 7.1.x release, closing this.


Upgrade to Elm 0.19

I'll have to play with Elm 0.19 a bit to see what makes sense.
Elm's own theory about how to handle URLs has changed at least somewhat between 0.18 and 0.19. So, the question will be how the different approach used by this package fits in.

I've pondered for a while by reading docs, and convinced myself that there's still a need for this.  So, I've started poking at it to see if the compiler agrees with me.  :)  See https://github.com/jerith666/elm-route-url/tree/update-019 for my fiddlings so far.

Thanks — I will take a look as soon as I can.

To be clear, it doesn't compile yet ... but my time comes in fits and spurts, so wanted to throw it out there in case it saves someone else a bit of time before I can pick it back up again.  :)

Okay, pushed a few more commits.  There are two compilation errors now, both require some thought.
in update, we now have reportedUrl = fromString urlChange.url.  But unlike the old Erl library, which somehow had a parse : String -> Url function, the new core elm/url function is fromString : String -> Maybe Url -- it might not parse.  So, what do we do in that case?  (What did Erl do?)
My temptation is to push this problem outside of elm-route-url entirely, and make UrlChange's .url be of type Url rather than String.  But the current API lets you change just the query or hash more easily, so maybe we need something to support that?  Like
type alias UrlChangeMetadata =
    { entry : HistoryEntry
    , key : Key
    }

type UrlChange
    = NewPath
        UrlChangeMetadata
        { path : String
        , query : Maybe String
        , fragment : Maybe String
        }
    | NewQuery
        UrlChangeMetadata
        { query : String
        , fragment : Maybe String
        }
    | NewFragment UrlChangeMetadata String

Second, we don't have anything obvious to use for the onUrlRequest value in the record passed to Browser.application.  I admit I haven't thought much at all about this one yet, wanted to get past the first issue I listed before contemplating this one too deeply.

Carried through the above-proposed UrlChange refactor, feels pretty reasonable, but we'll see.
Decided to just require the client code to supply an onUrlRequest function for us to delegate to, that also seems fairly reasonable, but again, we'll see once I get to some actual client code.  :)
Down to no compilation errors in RouteUrl.elm, but still some in RouteUrl.Builder and RouteHash.

I've completed updating my photo album app to use this, and it both works okay and feels okay in the code.  Commits on my project that show the changes include:
https://github.com/jerith666/elbum/commit/ce80ac05010181596f05cd911814e09ca43660db s/Location/Url/ in navToMsg
https://github.com/jerith666/elbum/commit/13b395b1c7a15573afdc5720f5290056c33f0fbf use Maybe.withDefault for Url fields
https://github.com/jerith666/elbum/commit/f064b5bbf9404c23b0a9995449e5472b0d748c1f?w=1 query and hash prefixes (? and #) are now included automatically
https://github.com/jerith666/elbum/commit/b59f0e3229eaeb35b407b442523d89fa7b8fe412#diff-ca49af1e1ae6cd714ae3d1361c1b9d4eR773 add key field
https://github.com/jerith666/elbum/commit/7a8d0e1428ffadc397d1c44941e228e374cf0937 only use NewQuery when query is nonempty
We'll need to update docs and examples before we have something releasable ... what do you think, is this the right direction?

Is there any further updates on this? I'd like to help push this through to 0.19 if you still think its worthwhile.
We use elm-route-url extensively in our application and its holding us back from upgrading to 0.19.

@jerith666 That would be useful - were there many changes required to move to Elm 0.19?

@ljnicol Done, #38.  I made a fair amount of changes, yes.  And there is still work to be done, see the checklist in that PR.


Updates RELEASING doc.

Update this with recent experience releasing 0.17.0.

Related to https://github.com/rusoto/rusoto/issues/252 .


fix disable attribute

Summary by CodeRabbit

New Features

Introduced a new parameter is_import_to_fyle_enabled across multiple functions, enhancing control over disabling categories, cost centers, merchants, and projects based on import settings.

Bug Fixes

Improved efficiency and flexibility in handling disabling processes by refining internal logic and conditions.

Enhancements

Simplified the logic in the update_non_exported_expenses function for better performance and clarity.
Enhanced test coverage for expense and accounting export interactions.

Codecov Report
Attention: Patch coverage is 70.93023% with 25 lines in your changes missing coverage. Please review.

Project coverage is 93.91%. Comparing base (d01e6c6) to head (510429d).

Files with missing lines
Patch %
Lines

apps/sage300/utils.py
59.09%
9 Missing :warning:

apps/mappings/imports/modules/categories.py
60.00%
4 Missing :warning:

apps/mappings/imports/modules/cost_centers.py
60.00%
4 Missing :warning:

apps/mappings/imports/modules/merchants.py
50.00%
4 Missing :warning:

apps/mappings/imports/modules/projects.py
66.66%
4 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #222      +/-   ##
==========================================
- Coverage   94.25%   93.91%   -0.34%
==========================================
  Files         105      105
  Lines        6562     6609      +47
==========================================
+ Hits         6185     6207      +22
- Misses        377      402      +25

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[Docs] Documentation of new dark mode needed

Current State
Dark and light mode support on the play.meshery.io site is new and undocumented.
Desired State
The Contributing.md should answer the following questions (and more):

How does the site theming work?
How to define new classes / new styles that have both light and dark mode definitions?

Consider copying or referencing the https://github.com/layer5io/layer5 dark mode instructions.

Contributor Guides and Resources

📚 Instructions for contributing to documentation

Meshery documentation site and source

🛠 Meshery Build & Release Strategy
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

@leecalcote Kindly review.


Updated Readme.md with my jam

Very upbeat and motivating stuff

Another contributor changed the table formatting a little bit. Can you please pull the latest, use the new format, and resolve the conflicts? Let me know if you have any questions.

Nevermind, I updated the formatting to reduce the chance of conflicts. Thanks!


Add twine check and readthedocs reminder to HOW_TO_RELEASE

Would it be of interest to automate the distribution build, and the PyPI upload via GitHub Workflow?
.github/workflows/publishtopypi.yaml:

name: Publishing to PyPI
on:
  release:
    types: [created, published, prereleased]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up Python
        uses: actions/setup-python@v1
        with:
          python-version: '3.x'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          python -m pip install setuptools setuptools-scm wheel twine
      - name: Build and publish
        env:
          TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
          TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}
        run: |
          python setup.py sdist bdist_wheel
          twine check dist
          twine upload dist/*

The last time we talked about this there wasn't much interest in automating these steps.
It's mostly fixing docs that takes the longest time. Thanks for the suggestion.

Though if someone was up for automating the steps, that would be good! (or @dcherian do you disagree? How much of us not doing this is preference vs no one having done it?)


[FEATURE]: Vertical testimonial card in tailwindCSS

PR Title

The purpose of this Pull Request is to fix #118
Description

added testimonial card
How you solved

Screenshots

Checklist

[x] I have Made this contribution as per the CONTRIBUTING guide in this repo
[x] I have tested in local Environment.
[x] I have made the fix as per issue converstaion
[x] I have starred the repository ⭐

@jsvigneshkanna  Done

@Anuran12 🤪( really added your photo in testimonial)
Check for other new issues raised , thank you!


Keyboard shortcut to add all fields

There are times when I want to add all fields then remove some. I'd be fantastic l if there was a way to add all fields in a given navigation context using a keyboard shortcut.

Fantastic tool btw. Feel free to close this, just wanted to submit a potentially useful feature.

@jimthedev We already have a feature that kinda does what you suggested - if, during an execution stage, a query is invalid due to the innermost field (terminal fields) not representing a leaf selection (http://facebook.github.io/graphql/#sec-Leaf-Field-Selections), GraphiQL will automatically fill in the leaf selections for invalid fields. Take a look at https://github.com/graphql/graphiql/blob/master/src/utility/fillLeafs.js and see if this is something you wanted.
If you meant recursively adding all non-terminal fields and terminal fields, you might end up in a situation where the field call added may address the top-level type, which ends up in an infinite loop of field completions.

Closing this since it's aging and tricky to implement in a usable way. However anyone who stumbles here in the future - it would certainly be an interesting PR!

Would love to have this

Also, the automatic leaf-filling does not work within a fragment.

@jimthedev I have a fork of GraphiQL where I added this feature. It adds all available field names (non-recursively) with  based on whichever field the cursor is inside of.
acarl005/graphsiql@9f88eba

Would love to have it too!
Or any other way to do * for debugging. I understand that for production * shouldn't be used according to the intended use and the concept of GraphQL itself. But for debugging it's invaluable!

https://github.com/imolorhe/altair

@imolorhe why do link this here? Does altair have this feature? Because I just tried it out and it doesn't seem to have this feature.

@capaj Oh right! I confused the question for another 😅


同时使用  unplugin-turbo-console 报错： "decorators", "decorators-legacy".

[plugin:unplugin-turbo-console] This experimental syntax requires enabling one of the following parser plugin(s): "decorators", "decorators-legacy". (18:0)

Reproduction
https://stackblitz.com/~/github.com/pyt111/my-vue-test-decorators
unplugin-turbo-console
https://github.com/unplugin/unplugin-turbo-console/issues/34


Why Cant I use export class in projArk?

Your question
describe your question clearly
There are projects here:
deep100, the original deep version 1
deep200, the original deep version 2
pluginB100, project that depends on deep100
pluginC200, project that depends on deep200
projArk, project that use both pluginB100 and pluginC200
Your scenes
for deep100, deep200, pluginB100, pluginC200, use mvn clean package install them.
for projArk, use mvn clean package, but report error: can't find PluginB100Activator or PluginC200Activator
describe your use scenes (why need this feature)
What's wrong with the codes or pom.xml?
Your advice
describe the advice or solution you'd like
Environment

SOFAArk version:
JVM version (e.g. java -version):
OS version (e.g. uname -a):
Maven version:
IDE version:

project.zip

The projects are attached.

在 proArk 包中添加上如下依赖：
    <dependency>
      <groupId>com.leyan.pluginB100</groupId>
      <artifactId>pluginB100</artifactId>
      <version>1.0.0</version>
      <scope>provided</scope>
    </dependency>

    <dependency>
      <groupId>com.leyan.pluginC200</groupId>
      <artifactId>pluginC200</artifactId>
      <version>1.0.0</version>
      <scope>provided</scope>
    </dependency>

另外 PluginActivator 的用法可以学习下，用例中的PluginActivator用的不太准确呢~


feature: add support disposing

please add support use using Symbol.dispose and Sympol.asyncDispose
import { AsyncValue } from<EMAIL_ADDRESS>import { Mutex } from<EMAIL_ADDRESS>
const count = new AsyncValue(0);

async function doSomething() {
  const v = await count.get();
  await count.set(v + 1);
}

// Critical section
const mu = new Mutex();

// with using operator
{
   using lock = await mutex.acquire();
   await doSomething();
} // auto call lock[Symbol.dispose]();

// or with try finally
await mu.acquire();
try {
  await doSomething();
} finally {
  mu.release();
}

and publish package to jsr.io for using this package in node, bun, deno, ...

Package is published to JSR.
https://jsr.io/@lambdalisue/async

Package will be published to https://jsr.io/@core/asyncutil
Closed by #24


problem in Watson response after changing botkit storage module

I've just changed the storage module that my bot is using from json file store to botkit-storage-dynamodb (this npm module is available on github), and I started seeing an error returned from Watson as follows:
ValidationException: ExpressionAttributeValues contains invalid value: Input collection contains duplicates for key :context {"cause":{"message":"ExpressionAttributeValues contains invalid value: Input collection contains duplicates for key :context","code":"ValidationException","time":"2017-12-18T21:34:39.246Z","requestId":"ABJ7VT1PB7JBUDVQAFSF9M210BVV4KQNSO5AEMVJF66Q9ASUAAJG","statusCode":400,"retryable":false,"retryDelay":18.287361752594443},"code":"ValidationException","time":"2017-12-18T21:34:39.246Z","requestId":"ABJ7VT1PB7JBUDVQAFSF9M210BVV4KQNSO5AEMVJF66Q9ASUAAJG","statusCode":400,"retryable":false,"retryDelay":18.287361752594443}
I'm unclear as to what is causing this error. In my bot, I save the ongoing conversation (between a bot an a user, via direct messages) in channel storage, and I don't explicitly save or retrieve anything from user storage. The bot was working fine before the storage switch (it's running in Spark).
Any ideas on where the problem could be?

Try to log payload in before hook and see if context looks wrong in some way.

I actually logged the 'message' variable before the call to WatsonInterpret, and I get the following:
Sending message to Watson:  { user<EMAIL_ADDRESS>channel: 'Y2lzY29zcGFyazovL3VzL1JPT00vZmNmOTViZWQtZjlhYS0zMGZlLWFiZjMtODRjMTM5ZDQ2MTVk',
text: 'how do I add a student to my course?',
id: 'Y2lzY29zcGFyazovL3VzL01FU1NBR0UvMzhmNGNjMjAtZTQzYi0xMWU3LWE2ZDctMjM5Y2ZjYmU1NzFi',
original_message:
{ id: 'Y2lzY29zcGFyazovL3VzL01FU1NBR0UvMzhmNGNjMjAtZTQzYi0xMWU3LWE2ZDctMjM5Y2ZjYmU1NzFi',
roomId: 'Y2lzY29zcGFyazovL3VzL1JPT00vZmNmOTViZWQtZjlhYS0zMGZlLWFiZjMtODRjMTM5ZDQ2MTVk',
roomType: 'direct',
text: 'how do I add a student to my course?',
personId: 'Y2lzY29zcGFyazovL3VzL1BFT1BMRS82MjBlNWQ5Ny1kMzE0LTQzZmEtYjYxOC05ODEwOGQ4YWMzZDE',
personEmail<EMAIL_ADDRESS>created: '2017-12-18T21:34:26.786Z',
orgId: 'Y2lzY29zcGFyazovL3VzL09SR0FOSVpBVElPTi9iYTA0MjUwYi02MWM3LTRmMGEtOGVlYy01MmFlMDQ2MzVkYjg' },
match:
[ 'how do I add a student to my course?',
index: 0,
input: 'how do I add a student to my course?' ] }
The above doesn't even mention the 'context'. I wonder if it may have something to do with the users storage (which I'm not explicitly using in my code at all) which may be something that Watson relies on?

You logged the message before context was added to it.
Look at example of before hook and log payload there: https://github.com/watson-developer-cloud/botkit-middleware/blob/master/README.md#before-and-after

Yes, you are right. I just added a console.log statement within a watsonMiddleware.before method, and this is what I got:
ConversationPayload is:  { workspace_id: '1477e470-93ae-49e2-a659-1dae97c12837',
input: { text: 'how do I add a student to my course?' },
context:
{ failedUnderstanding: 1,
allIntents: [],
system:
{ dialog_request_counter: 2,
dialog_stack: [Object],
dialog_turn_counter: 2,
_node_output_map: [Object],
branch_exited: true,
branch_exited_reason: 'completed' },
conversation_id: 'c0c500bf-d3a7-4ff7-aa6b-81674ca0e97b' } }
Warning: Watson error received!: ValidationException: ExpressionAttributeValues contains invalid value: Input collection contains duplicates for key :context {"cause":{"message":"ExpressionAttributeValues contains invalid value: Input collection contains duplicates for key :context","code":"ValidationException","time":"2017-12-18T23:30:57.230Z","requestId":"MAU4Q9EIH7T8B1JU6SGDQJKA9NVV4KQNSO5AEMVJF66Q9ASUAAJG","statusCode":400,"retryable":false,"retryDelay":3.9042008275380624},"code":"ValidationException","time":"2017-12-18T23:30:57.230Z","requestId":"MAU4Q9EIH7T8B1JU6SGDQJKA9NVV4KQNSO5AEMVJF66Q9ASUAAJG","statusCode":400,"retryable":false,"retryDelay":3.9042008275380624}
I don't see anything odd in that payload. Do you?

It looks good to me too.
This error is probably coming from dynamo, log conversation response in after hook to check if you got a successful response from Watson.

Turns out that the AFTER hook never gets executed apparently (no printout is found). The last thing I see from Watson is the error message I posted in my first email :-(.

Could this have something to do with what Watson expects to find in the user context instead? (thinking that the 'context' is actually stored in there, isn't it?) I am not manipulating the context myself, but I wonder if this might be what Watson complains about.

I have to correct myself, sorry!. I actually see that the AFTER hook runs also, and displays this payload right before the error message (by Watson) is printed out:
ConversationPayload AFTER is:  { intents:
[ { intent: 'user-enrollment-ses',
confidence: 0.9265775203704834 } ],
entities: [],
input: { text: 'I can't find a class that I should be enrolled in' },
output:
{ text:
[ 'Sure, I'll be happy to help. Hope you don't mind me asking you for some information.',
'Could you tell me what is your academic role, and also describe for me the course you are having issues with?' ],
nodes_visited:
[ 'node_1_1506885954983',
'node_3_1512763379204',
'user-enrollment-SES',
'handler_5_1500328523645',
'user-enrollment-SES' ],
log_messages: [] },
context:
{ allIntents: [],
conversation_id: '694368ec-17aa-42ea-9971-43dc91eb9bfb',
system:
{ dialog_request_counter: 2,
dialog_stack: [Object],
dialog_turn_counter: 2,
_node_output_map: [Object] } } }


Update README file

Hi I've update temporally README file. This is a first test from me.
Now command works (but build fails).

LGTM


FlexSlider - remove thumbnail nav

commented out until issue #1 is implemented
fixes #50

Current coverage is 13.75%

Merging #51 into master will increase coverage by +0.17% as of d586493

@@            master     #51   diff @@
======================================
  Files            2       2
  Stmts           81      80     -1
  Branches         0       0
  Methods         12      12
======================================
  Hit             11      11
  Partial          0       0
+ Missed          70      69     -1

Review entire Coverage Diff as of d586493

Powered by Codecov. Updated on successful CI builds.


Move SpeechActivity animation to XML.

Moved SpeechActivity animation to res/animator/color_animation.xml.
Specifying the animation in code is tougher to read and detracts from what is supposed to be a simple example of how to use TF in Android.

Nagging Assignee: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.


I cannot enable the extension

I can't enable the extension:

OS: Artix Linux
Kernel: Linux 5.15.4-artix1-1
Editor: VSCodium

I'd like to be able to enable it, but I don't know how to get administrator permissions, I figured out how to open it via the terminal using sudo, but it corrupted my VSCodium installation, and the extension was not there.
I have since then fixed my VSCodium installation by re-installing it, but I am still unable to enable Fluent UI.

I am currently also getting help at the Linux Mint Discord server, but I believe this is also an appropriate place to get help on the issue.

whereis vscodium-bin or whereis vscodium or whereis code
whoami
sudo chown -R <user> <path-to-vscodium>
enable extension
sudo chown -R root <path-to-vscodium>
may corrupt your vscodium installation, but can be ignored since it does not break anything(afaik), otherwise just re-install vscodium
this is the solution


Added support for queries that return scalar results

Queries such as SHOW CREATE JOB <job_name> return scalar results. A scalar result is returned as:
[
    {
        "status": "Success",
        "kind": "upsolver_scalar_query_response",
        "result":
        {
            "scalar":
            {
                "value": "<value_here>",
                "valueType": "<value_type_here>"
            }
        }
    }
]

This commit transforms this result into a 1x1 grid with a column name of
valueType.

Added an example how this would be used in the examples.py file


Issue in connecting Verint EFM in tableau WDC ? asking for code based URL.

Issue in connecting Verint EFM in tableau WDC ? asking for code based URL.

Hi @varshavk85 - Are you talking about a specific WDC? If yes, please contact the developer that created the WDC for support. Cheers, Gigi


[react 0.13] Discern new vs old style components through render

By overloading createElement() for the ClassicComponentClass and
creating a separate ReactClassicElement type, we can keep track of which
calls to render() should create a ClassicComponent versus a new style
Component. Useful for keeping the old API, which makes migration easier.

@jbrantly @pspeter3 could you review this PR?

So this change is primarily for documentation then?

Not sure what you mean, but it's not purely cosmetic. Run the updated test without the changed definitions to see what it fixes: automatic type inference of old style API.

Both types are interfaces with the exact type signature. This means they are the same thing to the compiler. Maybe the test could try to use some unique features of the React classic component?

The types are not identical. That's how I discovered this, and why I fixed it:
    // "classic" createClass
    class ClassicComponent<P, S, C> extends Component<P, S, C> {
        replaceState(nextState: S, callback?: () => any): void;
        getDOMNode<TElement extends Element>(): TElement;
        getDOMNode(): Element;
        isMounted(): boolean;
        getInitialState(): S;
        setProps(nextProps: P, callback?: () => any): void;
        replaceProps(nextProps: P, callback?: () => any): void;
    }

Try to replace the definitions file with the one from 01ce3ccf7f071514ff5057ef32a4550bf0b81dfe (that's HEAD~2 from this patch) and you'll only see errors because:
var classicComponent: React.ClassicComponent<Props, State, Context>;

classicComponent is explicitly typed as ClassicComponent, so you only get problems when you try to assign to that. But, replace that line by:
var classicComponent: React.Component<Props, State, Context>;

and try again, you'll see that you can't use the old API (setProps etc) on it.
Or do I have an old version?

Ok this makes sense. I didn't know how type inference and structural typing would work together with the compiler. Thanks for fixing this!

No p, neither do I. It's a big whack-a-mole to me, I just try stuff out and see what intellisense makes of it. Fun fact: if you invert those two definitions to:
        render<P, S>(element: ReactElement<P>, container: Element, callback?: () => any): Component<P, S, any>;
        render<P, S>(element: ReactClassicElement<P>, container: Element, callback?: () => any): ClassicComponent<P, S, any>;

this patch becomes useless. Method overloading is selected in order of definition, so when a super class precedes a child class it will always win.
Anyway, thanks and happy to help.

This seems reasonable to me. +1

@pspeter3 @jbrantly thanks!
@hraban thanks mate!


List & Dict can't accept array.dtype as argument.

Reporting a bug

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
[x] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

As title.
import numpy as np
from numba import njit
from numba.typed.typedlist import List
from numba.typed.typeddict import Dict

@njit
def example_list(a):
    ls = List.empty_list(a.dtype)
    ls.append(a[0])
    return ls

example_list(np.zeros(1))

- Resolution failure for literal arguments:
No implementation of function Function(<function impl_append at 0x7fc16b232af0>) found for signature:
 >>> impl_append(ListType[dtype(float64)], float64)
There are 2 candidate implementations:
    - Of which 2 did not match due to:
    Overload in function 'impl_append': File: numba/typed/listobject.py: Line 592.
      With argument(s): '(ListType[dtype(float64)], float64)':
     Rejected as the implementation raised a specific error:
       NumbaNotImplementedError: Failed in nopython mode pipeline (step: native lowering)
     Cannot cast float64 to dtype(float64): double %"arg.item"
     During: lowering "casteditem = call $2load_global.0(item, $6load_deref.2, func=$2load_global.0, args=[Var(item, listobject.py:600), Var($6load_deref.2, listobject.py:600)], kws=(), vararg=None, varkwarg=None, target=None)" at /home/auderson/miniconda3/lib/python3.8/site-packages/numba/typed/listobject.py (600)
  raised from /home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/base.py:704
- Resolution failure for non-literal arguments:
None
During: resolving callee type: BoundFunction((<class 'numba.core.types.containers.ListType'>, 'append') for ListType[dtype(float64)])
During: typing of call at <ipython-input-12-6baf440651d6> (10)
File "<ipython-input-12-6baf440651d6>", line 10:
def example_list(a):
    <source elided>
    ls = List.empty_list(a.dtype)
    ls.append(a[0])
    ^

@njit
def example_dict(a):
    d = Dict.empty(a.dtype, a.dtype)
    d[a[0]] = a[0]
    return d

example_dict(np.zeros(1))

No implementation of function Function(<built-in function setitem>) found for signature:

 >>> setitem(DictType[dtype(float64),dtype(float64)]<iv=None>, float64, float64)

There are 16 candidate implementations:
  - Of which 14 did not match due to:
  Overload of function 'setitem': File: <numerous>: Line N/A.
    With argument(s): '(DictType[dtype(float64),dtype(float64)]<iv=None>, float64, float64)':
   No match.
  - Of which 2 did not match due to:
  Overload in function 'impl_setitem': File: numba/typed/dictobject.py: Line 695.
    With argument(s): '(DictType[dtype(float64),dtype(float64)]<iv=None>, float64, float64)':
   Rejected as the implementation raised a specific error:
     TypingError: Failed in nopython mode pipeline (step: nopython frontend)
   No implementation of function Function(<built-in function hash>) found for signature:

    >>> hash(dtype(float64))

   There are 4 candidate implementations:
         - Of which 2 did not match due to:
         Overload of function 'hash': File: numba/experimental/jitclass/overloads.py: Line 0.
           With argument(s): '(dtype(float64))':
          No match.
         - Of which 2 did not match due to:
         Overload in function 'hash_overload': File: numba/cpython/hashing.py: Line 48.
           With argument(s): '(dtype(float64))':
          Rejected as the implementation raised a specific error:
            TypingError: Failed in nopython mode pipeline (step: nopython frontend)
          Unknown attribute '__hash__' of type dtype(float64)

          File "../miniconda3/lib/python3.8/site-packages/numba/cpython/hashing.py", line 51:
              def impl(obj):
                  return obj.__hash__()
                  ^

          During: typing of get attribute at /home/auderson/miniconda3/lib/python3.8/site-packages/numba/cpython/hashing.py (51)

          File "../miniconda3/lib/python3.8/site-packages/numba/cpython/hashing.py", line 51:
              def impl(obj):
                  return obj.__hash__()
                  ^

     raised from /home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typeinfer.py:1086

   During: resolving callee type: Function(<built-in function hash>)
   During: typing of call at /home/auderson/miniconda3/lib/python3.8/site-packages/numba/typed/dictobject.py (706)

   File "../miniconda3/lib/python3.8/site-packages/numba/typed/dictobject.py", line 706:
       def impl(d, key, value):
           <source elided>
           castedval = _cast(value, valty)
           status = _dict_insert(d, castedkey, hash(castedkey), castedval)
           ^
  raised from /home/auderson/miniconda3/lib/python3.8/site-packages/numba/core/typeinfer.py:1086
During: typing of setitem at <ipython-input-3-3aa1714a8578> (4)
File "<ipython-input-3-3aa1714a8578>", line 4:
def example_dict(a):
    <source elided>
    d = Dict.empty(a.dtype, a.dtype)
    d[a[0]] = a[0]
    ^

@auderson thank you, can you use type inference as a workaround:
import numpy as np
from numba import njit
from numba.typed.typedlist import List
from numba.typed.typeddict import Dict

@njit
def example_list(a):
    ls = List()
    ls.append(a[0])
    return ls

print(example_list(np.zeros(1)))

@esc Thanks! This works.

I think this issue here that the list is declared to be of the DType type, but the values provided are values of the type of the dtype:
from numba import njit, typed, typeof, types
import numpy as np

a = np.zeros(1)

print(typeof(a[0]))
assert typeof(a[0]) == types.float64
print(typeof(a.dtype))
assert typeof(a.dtype) == types.DType(types.float64)

@njit
def foo(a):
    ls = typed.List.empty_list(a.dtype) # a list of float64 dtypes
    ls.append(a.dtype) # append a float64 dtype
    ls.append(np.dtype(np.float64)) # and another one
    return ls

foo(a)

but it's also a bug in that the typed.List typing should have caught it before it manifest as a lowering error. If you want declare the type explicitly from the array dtype, this should work, but I think would break if run without the JIT:
from numba import njit, typed
import numpy as np

a = np.zeros(1)

@njit
def foo(a):
    ls = typed.List.empty_list(a.dtype.type) # use `.type`, create a list of float64s
    ls.append(a[0])
    ls.append(1.23)
    return ls

foo(a)

However, as @esc noted, if you can let type inference just work it out, that tends to be a good strategy.
For the dict case, the issue is that there's no implementation of __hash__ registered for dtype. However, the sample code is also trying to put float64 types into the dictionary values which are declared as a types.DType(types.float64) i.e. a dtype type. Something like this could make it work:
from numba import njit, typed, typeof, types
import numpy as np
from numba.extending import overload_method

@overload_method(types.DType, "__hash__")
def ol_dt_hash(inst,):
    def impl(inst):
        return 1 # Mock hash value, the real hash alg would need replicating
    return impl

@njit
def foo(a):
    d = typed.Dict.empty(a.dtype, a.dtype)
    d[a.dtype] = a.dtype # values are dtypes!

a = np.zeros(1)
foo(a)

@stuartarchibald  Many thanks for this detailed reply. Actually I've tried ls = typed.List.empty_list(a.dtype.dtype) becasue I found DType has a dtype property😂.

@stuartarchibald Many thanks for this detailed reply. Actually I've tried ls = typed.List.empty_list(a.dtype.dtype) becasue I found DType has a dtype propertyjoy.

No problem. Glad you've found something that works. Am going to close this as resolved and have opened #8372 to track the issue with typed.List.append not validating types correctly.


Proposal: Go 2: add C# like nameof() built-in function

Proposal
I propose to add C# like nameof built-in compile time function. This proposal is based on the C# standard here: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof. The main use of this is to make error values and logging easier to refactor, especially when using tools such as go pls, and also for use in ORM and intepreters where the name of an identifier, constant or stuct member, might often have to be mapped to an identical string value.
nameof built-in function
The nameof built-in function obtains the name of a variable, type, or member
as a string constant:
// In the shopping package, we have the following type:

type CartItem struct {
    Name string
    Stock int
    Price uint
    profitMargin float64
}

// And suppose we have this method on it.
func (c * CartItem) Checkout() {
}

// Then in another package:
fmt.Println(nameof(shopping.CartItem))  // output: CartItem
fmt.Println(nameof(int))  // output: int
fmt.Println(nameof(shopping.CartItem.Price))  // output: Price
fmt.Println(nameof(shopping.CartItem.Checkout))  // output: Checkout
ci := shopping.CartItem{}
fmt.Println(nameof(ci.Checkout))  // output: Checkout

// more examples
var numbers = []int{ 1, 2, 3 };
fmt.Println(nameof(numbers));  // output: numbers
fmt.Println(nameof(len(numbers)))  // output: len
fmt.Println(nameof(nameof));  // output: nameof

// Expressions which have no name return the empty string.
fmt.Println(nameof())  // output: (the empty string)
fmt.Println(nameof(1+2))  // output: (the empty string)

// usage with constants
type AstKind string
const AstExpression = AstKind(nameof(AstExpression))
fmt.Println(AstExpression)  // output: AstExpression

// However, names that don't exist or are not exported are a compilation error
fmt.Println(nameof(CartItem.Reductions))  // error: nameof(): CartItem has no field Reductions
fmt.Println(nameof(CartItem.profitMargin)) // error: nameof(): CartItem field profitMargin is not exported
fmt.Println(nameof(someUndefinedFoo)) // error: nameof(): Unknown variable someUndefinedFoo

As the preceding example shows, in the case of a type and a package, the produced name is not fully qualified. The same goes for struct members, only the name of the last field in the chain of field accesses is produced.
The nameof built-in function is evaluated at compile time and has no effect at run time.
You can use the nameof built-in function or ORM, for constants that evaluate to themselves as a string value, and for debugging, or to make error values or log messages more maintainable. For example:
import "github.com/sirupsen/logrus"

type Named {
    Name *string
}

func (n *Named) SetName(name *string) error {
    if name == nil {
        logrus.WithField(nameof(name), name).Error("cannot be nil")
        return fmt.Errorf(nameof(name) + " cannot be nil" )
    }
    n.Name = name
}

Proposal template

Would you consider yourself a novice, intermediate, or experienced Go programmer?
I am experienced, I have been using Go for 10 years since before v1.0.
What other languages do you have experience with?
Batch files, Basic, C, C++, D, Java, Javascript, Lua, Objective-C, Oberon, Pascal, PHP, Python, R, Ruby, Shell scripts, Visual Basic, ... I do not have experience with C#, but in the previous issues, it seemed that a C#-like nameof was the one most people seemed interested in for Go as well.
Would this change make Go easier or harder to learn, and why?
It would not make Go easier to learn, but also not substantially harder. If the new built-in function is well documented, everyone who doesn't know it yet can read its documentation to find out how it works. Furthermore, it will be familiar to C# users.
Has this idea, or one like it, been proposed before?
This idea is based on the proposal #36332 and #36924.
If so, how does this proposal differ?
In stead of special syntax I proposed a built-in function, which is more Go-like and easier to learn. Furthermore, it is not based on reflection, but a compile time,, similar as it is in C# which has proven utility in that language, and it seems like most people are interested in this kind of nameof() function.
Who does this proposal help, and why?
This proposal would help people writing ORM's, interpreters, or with debugging aid, and other people who need to use the names of Go language artifacts, such as struct field names, or type names have to be used as strings. It is especially convenient to prevent errors during refactoring when using tools such as go pls.
Is this change backward compatible?
Yes, adding a new built in function is normally completely backwards compatible, and does not break the Go1 compatibility guarantee.
Show example code before and after the change.

Example: Logging and error values:
Before:
import "github.com/sirupsen/logrus"

type Named {
    Name *string
}

func (n *Named) SetName(name *string) error {
    if name == nil {
        logrus.WithField("name", name).Error("cannot be nil")
        return fmt.Errorf("name cannot be nil" )
    }
    n.Name = name
}

After:

import "github.com/sirupsen/logrus"

type Named {
    Name *string
}

func (n *Named) SetName(name *string) error {
    if name == nil {
        logrus.WithField(nameof(name), name).Error("cannot be nil")
        return fmt.Errorf(nameof(name) + " cannot be nil" )
    }
    n.Name = name
}

While the before looks simpler, it has a problem: when you rename the namevariable, especially using tools, "name" in the string will not be changed by the tool as well. The nameof function can be supported by such tools, and then refactor the name correctly so the error ans log message will also be correct.
Example: Orm-ish use:
Before:
import "database/sql"

type CartItem struct {
    Name string
    Stock int
    Price uint
}

func (ci CartItem) Insert(db *sql.DB) error {
	// Not very future proof. If the struct changes, I could easily forget to change field name here as well.
	query := "INSERT INTO CartItem (Name, Stock, Price) VALUES (?, ?, ?)"
	err := db.Exec(query, ci.Name, ci.Stock, ci.Price)
	return err
}

After:
func (ci *CartItem) Insert(db *DB) error {
	// Get the field names at compile time. Less chance for error.
        // If the fields don't exist we will get a compiler error.
        fields := []String { nameof(ci.Name),  nameof(ci.Stock), nameof(ci.Price) }
	query := "INSERT INTO CartItem (" + strings.Join(fields , ", ") +  ") VALUES (?, ?, ?)"
	err := db.Exec(query, ci.Name, ci.Stock, ci.Price)
	return err
}

In this case, the after code is also somewhat more complex, but it is definitely more correct. If the struct layout changes, then in stead of getting a run time error, we will get a compile time error which is far preferable in such a situation.

What is the cost of this proposal? (Every language change has a cost).
The function has to be implemented, documented and tested.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
The gopls tool may or may not have to be updated to allow refactoring of the contents of a nameof() call.
What is the compile time cost?
Low, because only if the function is used, the compiler has at do a few name and field lookups, but it should already have that data available.
What is the run time cost?
None, the whole point is to have this functionality at compile time.

Can you describe a possible implementation?
See above for the proposal based on C# documentation, extended with some more situations.
How would the language spec change?
The Built-in_functions section would need to get a sub chapter on "Obtaining Names" or such.
Orthogonality: how does this change interact or overlap with existing features?
It does not overlap with reflect, except maybe for names of fields, but nameof() can also fetch names of non-expressions, which is not possible using reflect. It would also allow to check on compile time whether a variable or constant exists: eg:

var _ = nameof(Foo) // compile error if Foo does not exist. May happen due to build tags, etc.

Is the goal of this change a performance improvement?
No.
Does this affect error handling?
Only in that it improves the quality of error values in when renaming variables.
Is this about generics?
No.

// usage with constants
type AstKind string
const AstExpression = AstKind(nameof(AstExpression))
fmt.Println(AstExpression)  // output: AstKind

What are the rules for that? I would expect it to output AstExpression. At least, C# works that way.

@creker: You are right. I fixed this in the proposal.

We started down this path with a suggestion for a way to get the names of the fields of a struct type as a []string.  Just for my own understanding, am I correct in thinking that this proposal does not support that?

@ianlancetaylor, indeed, as we discussed in the other issue, that use case is not necessary and makes nameof() confusingly different from what is in C#.
By staying close to the C# nameof we can stick to something "tried and tested", that will be familiar to some people.
However, as you can see from the examples above, nameof() could still be used to get the names of struct fields one by one, with a compile time error if the field does not exist. That is also useful for ORM, etc.

Also, to show the utility of a nameof() construct in a programming language, consider that in the C/C++/Objective-C langauges we have the C preprocessor with the # stringify operation, which is used to good effect for many similar use cases as nameof() would be. Furthermore, a nameof() built -in function is much more clean and easy to understand than #and the C preprocessor.

Can't this be already done via reflect?

@qtplatypus, No, the C# like nameof() in this proposal produces compile time constants, based on the names of the variables, which is not possible in the general case with reflect. Only the struct field case is covered, but this nameof proposal is much wider, as it allows to get names of anything that has a name and is in scope. Furthermore with reflect, you would get a you won't get a compile time error in case the field you are looking up does not exist.

@beoran I'm not even sure it's possible to get a name of the field with reflect. I'm not a reflect expert but poking around I didn't find  any obvious way that would do this
type foo struct {
    fld int
}
fooVal := foo{}
//some reflect magic to get "fld" just from fooVal.fld at runtime

Indeed, if it is a non exported field, reflect does not work. In this case, nameof() would work fine.

@beoran it doesn't even matter whether it's exported or not. I just don't a way how can I go from struct field to its name at runtime. Only thing I can get from it with reflect is Type and Value. Both do not provide any link to the parent struct nor contain any information that it's actually a struct field.

We can see the utility of this, it would be simple to implement, and it is backward compatible.  But it's not quite clear how useful this would be.  It would help to point out some real existing code that would benefit from this.  Are there places where the standard library would use this functionality?
In the logrus example above, the "after" code seems worse than the "before" code.
In general nameof seems only useful for names that are visible to some external operation, such as SQL or JSON.  In general this seems like it might be most useful for struct field names, but not anything else (like the earlier issue).

The logrus example seems worse after, but it is in fact better because it makes it easier to refactor the variable name with tools, and to keep the string and the name of the variable matched if it changes.
Speaking for myself, the code in https://gitlab.com/beoran/muesli, an embeddable scripting language interpreter written in Go, for example in https://gitlab.com/beoran/muesli/-/blob/master/ast.go would be helped by this.
For example:
func (astkind AstMetaKindSet) String() string        { return "AstSet" } would be better as func (astkind AstMetaKindSet) String() string        { return nameof(AstSet) }, because I am still developing the interpreter and changing the AST kinds, so I sometimes forget to change the strings as well. With nameofI would get a compile time error in stead.
As for the Go standard library and runtime. I had a quick look and I found a few points where I think nameof could be useful:

I saw many tests, such as in  src/runtime/pprof/pprof_test.go and other places where a function is called to test it, and the test case description contains the name of the test function as a string as well. Here, nameof() could be used to make sure that the name of the function and the string description stay in synch, and are easy to refactor using a tool.

In src/runtime/select.go there is a struct scase of which the field names must be used in the  file src/cmd/compile/internal/gc, in the function scasetype(). Here nameof() could be used on the struct fields to make the compiler check at compile time that the two files are synchronized, so we don't have to rely on a comment reminder. The same pattern occurs in othe rplaces.

Someone who actually knows the Go source code could find a lot more, no doubt... ;)

I would like other people who gave thumbs up to this issue to contribute examples of how they would like to use nameof as well.

While it may be true that using nameof makes the logrus example easier to refactor, that isn't normally the most important characteristic of a piece of code.  Readability is normally more important than ease of refactoring.  So the example still doesn't seem entirely convincing.
Keeping the name of a function and a string description in a test seems fairly minor.
We can't really use nameof for things like runtime/select.go where the runtime and the compiler have to be in synch.  For that we should use code generation, instead.  We already do that partially, in cmd/compile/internal/gc/runtime, and we could do more of it if we wanted to.
Still looking for clearer examples of where this is really useful.
It's also worth noting that the ease of refactoring due to nameof can in some cases introduce a problem.  If an exported name is based on a nameof, then renaming an internal name may surprisingly change the external API in an invisible way.  This may not be too likely but it's worth considering.

In the absence of compelling examples, this is a likely decline.  Leaving open for four weeks for final comments.

Well, the examples we gave are perhaps enough  to show that nameof() would be convenient, but I guess that to the Go developers, they do not demonstrate enough of an improvement to the Go language to warrant implementation.
I would like to ask the others who gave this issue thumbs up, or anyone else who reads this and likes the idea, again to provide some more examples as well. We will need them to convince the Go language developers that nameof() is worth while. I have proposed this issue for the benefit of the Go community, but if there is not enough interest, the Go team is well justified in pursuing more pressing issues.

No change in consensus.  Closing.

@beoran I know I'm mad late on this issue, and I'm not an experienced Go developer by any means (exp'd outside of Go), but if you decide to propose this in the future: testing.
Currently using testify to do some simple interface mocks, and there's a need to bind to method signatures on a type: testObj.On("DoSomething", 123).Return(true, nil) constantly. A nameof, or similar, compile-time check on the name of a signature would be extremely useful here.
I'll also just throw my 2c in for doing anything to get rid of magic-strings and sentinel value paradigms in any statically typed language-- they are faux-simpler, horrible to use at scale, and demonstrate a very weak static type system. I feel nameof is just as readable as a string for much less magic overall in this case.
For API concerns: it would probably have to function with package-level visibility, which is in line with Go in general. nameof on exported signatures when used on sigs of another package, any signature within your own package.
Also, thank you to those who proposed this for making the effort. Sorry I came so late-- just hit the frustration point enough to even Google this. :)

Well, the issue was already closed, so I'm sorry but I think it's too late now, at least for the time being. But thanks for your examples, they really show the value of a built-in nameof. If more people come in to support this idea, I might consider resubmitting this issue with improvements.

@beoran  I'm late too, but I'd like to show you my use case.
I'm using GORM to manage my database.
GORM has some filter functions that, in some cases, must receive a map[string]interface{} (column name to value mapping).
My goal is to get the column name to use in these functions.
I have a NamingStrategy (that implements schema.Namer interface) used to change column names according to the table name.
Using the NamingStrategy object, I can get the table name by passing the struct name to the TableName function. By passing the result and the struct field name to the ColumnName function, I can get the column name.
I might get the struct name with reflect, but I don't have a easy way to get a specific struct field name with it.
With nameof, I could simply do something like this:
dbColumnName := db.NamingStrategy.ColumnName(nameof(MyStruct), nameof(MyStruct.MyField))

Just like that, my code is now safe from typing errors in the column names and we might change the naming strategy without needing to change many places in code.

Heylow, too late as well, but frankly I could not have been sooner since I am learning Go since this week only ;-)
Being so new, I cannot give Go examples, but coming from C# I can give a little example on how it's been useful to me:
When I want to change the behaviour (not even the name) of a field (e.g. changing from "NOT NULL" to "NULL"able), I temporarily change the field name (e.g. from 'SomeField' to 'SomeFieldX') and launch the compilation.
Then I start changing the names everywhere the compiler complains there's an unknown field. That forces me to manually check the code everywhere that field is used until all compilation errors are resolved.
Like @beoran mentionned above, I too value safe refactoring much more than ease of reading.
Before C#6 (ie. before 'nameof' was available), I used to put things like const string SomeFieldName = "SomeField" right next to each fields that I referenced by name. But because of the burden that is, I was clearly the only one and in practice, more than once problems due to refactoring field names flew under the radar until crashes happened at the customers...
Now, if I ever make something serious with Go, I am personally going to put those SomeFieldName constants everywhere, and that won't ease readability either...
Also, in an IDE, being able to "Find all references" of something is so much useful.

Heylow, too late as well, but frankly I could not have been sooner since I am learning Go since this week only ;-)
Being so new, I cannot give Go examples, but coming from C# I can give a little example on how it's been useful to me:
When I want to change the behaviour (not even the name) of a field (e.g. changing from "NOT NULL" to "NULL"able), I temporarily change the field name (e.g. from 'SomeField' to 'SomeFieldX') and launch the compilation.
Then I start changing the names everywhere the compiler complains there's an unknown field. That forces me to manually check the code everywhere that field is used until all compilation errors are resolved.
Like @beoran mentionned above, I too value safe refactoring much more than ease of reading.
Before C#6 (ie. before 'nameof' was available), I used to put things like const string SomeFieldName = "SomeField" right next to each fields that I referenced by name. But because of the burden that is, I was clearly the only one and in practice, more than once problems due to refactoring field names flew under the radar until crashes happened at the customers...
Now, if I ever make something serious with Go, I am personally going to put those SomeFieldName constants everywhere, and that won't ease readability either...
Also, in an IDE, being able to "Find all references" of something is so much useful.

For the latecomers, Inlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. Please direct your discussion to other forums. Thank you.

Stack Overflow with questions tagged "go"

The Go Forum, a web-based forum

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

Go Community on Hashnode with questions and posts tagged with "go"

The golang-nuts mailing list

IRC channel #go-nuts on Freenode

For the latecomers, Inlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. Please direct your discussion to other forums. Thank you.

Stack Overflow with questions tagged "go"

The Go Forum, a web-based forum

Gophers Slack, use the invite app for access. The #general channel is a good starting point.

Go Community on Hashnode with questions and posts tagged with "go"

The golang-nuts mailing list

IRC channel #go-nuts on Freenode


orc + zstd compression support[FEA]

Is your feature request related to a problem? Please describe.
zstd compression is often used as compression ratio is approx 2x than snappy , so it saves a lot of cost when data is in petabyte scale
Describe the solution you'd like
support zstd compression for ORC
Describe alternatives you've considered
NA
Additional context
https://nvidia.github.io/spark-rapids/docs/compatibility.html

Thanks for the feature request!  In order for the RAPIDS Accelerator to support Zstandard for ORC it must be supported in cudf, as cudf provides the GPU backend for ORC reads and writes.  I filed cudf issues https://github.com/rapidsai/cudf/issues/9057 and https://github.com/rapidsai/cudf/issues/9058 to track Zstandard support for ORC reads and writes, respectively.
Note that implementing a performant GPU version of the Zstandard codec will take some time.  Once the support is available in cudf, it should be very straightforward to support it in the RAPIDS Accelerator for Apache Spark.

This has been implemented.


Cannot open Camera UI Settings in Homebridge

Describe the bug
I cannot access the Camera UI settings menu within the Homebridge UI.  When I click settings I just get the endless spinning gear.  This just started happening after updating to version 5.0.27.

Environment

Node.js Version: v18.18.0
Homebridge Version: v1.6.1
Camera UI Version: v5.0.27
Operating System: macOS
Browser: Brave

+1

🎉 A new version of camera.ui
A new version of camera.ui is currently under active development. An initial alpha/beta release and previews are coming soon. Stay tuned for exciting updates: https://github.com/seydx/camera.ui/issues/448 .
This version will no longer be developed / fixed. The new version contains many novelties and fixes (most important is for HKSV recording).


Archived workflows are visible in archived tab before retention period

Version of Cadence server, and client(which language)
This is very important to root cause bugs.

Server version: master-auto-setup
Client version: 2.7.8
Client langauge: Java

Describe the bug
After setting GCP archival with retention of 1 day, I am able to see all workflows execution in both tabs: workflow and archival
To Reproduce
Is the issue reproducible?

Yes

Steps to reproduce the behavior:
Update config_template.yaml as follows:

Set values for the variables in compose file:

Run a workflow.
Expected behavior
Before retention period archival tab is clean
Screenshots

This is by design, as your workflow is archived at close time, and will be removed from DB after retention. Retention happens usually after workflow close.

@polyansky-syberry  Let me add more explanation: there are two features: history archival and visibility archival.
Visibility is archived when workflow is closed, disregarding the domain retention.
The domain retention will apply on to history archival : when history is about to delete, Cadence will archive the history before deletion.
This sounds a bit weird. But visibility records is much smaller than history, so there is no need to make the optimization. Instead, put the visibility record into archival when workflow closing.

I confirmed that it is working as expected.
When runnning
cadence --do samples-domain wf listarchived -q "WorkflowType='main.helloWorldWorkflow'"

can return all closed workflow that with and without history archived, if you use
cadence --do samples-domain wf show -w <workflowID>

will only return you workflow that are not archived.
If you need to get history that are archived, a RunID is required:
cadence --do samples-domain wf show -w <workflowID> -r <runID>

Here is some improvement to help
https://github.com/uber/cadence/pull/4112

Got it. Thank you for the response, it was very useful for me.


This Google Analytics example flat out does not work - has anyone solved the hydration issue?

If you put the <script> tags in a client-only wrapper, gtag never gets loaded/defined and gtag.pageview never fires:

If you follow the <script> embedding example from this repo's root.tsx file, hydration errors ensue:

Has anyone had any luck figuring out a way around this?

+1, I had to rollback to React 17 to get rid of this annoyance


Check the hosting cluster vendor when in hosted mode

When the hosting cluster is not OpenShift, OpenShift configuration should not be enabled on the hosting cluster, regardless of if the hosted cluster is OpenShift.
Relates:
https://issues.redhat.com/browse/ACM-13204

/cc @JustinKuli @dhaiducek
FYI, I recommend the GitHub option of not showing whitespace changes since I converted the getValues function to be a closure.


[Platform] Document clarinet integrate flow from VS Code

Additional context: https://docs.google.com/document/d/1k5X8ATXVY4e2zuUAhRcZ0jPXPwf-BknzS97UwvIbYxg/edit?disco=AAAA_4xuVTM

was this issue resolved in the current docs @sabbyanandan ? seehere

Yeah, this is now covered via the command-line inside VS Code (through a URL output), and then the actual Devnet itself. Thanks for the follow-up.


_leftBox and _rightBox should exist in Main.panel

I don't know if _leftBox and _rightBox exist in all instances of Panel or just Main.panel.
If they exist in all instances of Panel, you can simply add them to Panel interface.
If they are unique to Main.panel, you can do this:
// main.d.ts
export declare const panel: Panel & {
  _leftBox: St.BoxLayout
  _rightBox: St.BoxLayout
}

We have since moved to Gnome 46, so I am closing this issue.
Please do re-open if it is still relevant, and provide a pull request 🙂


PanResponder yields to Swipeable, even after starting drag

Hi there, thank you for the library!  I was having issues with react-native-draggable-flatlist, so I appreciate the small footprint alternative 🥂
I'm rendering items in my draglist that are wrapped in Swipeables (from react-native-gesture-handler/ReanimatedSwipeable) in order to support "right actions" that allow the user to delete items in the list.  I allow dragging after long press, which is working great, but if the user is reordering and accidentally moves too far left/right with their finger, the Swipeable takes over, and dragging pauses, never working again until the user lifts their finger and starts over.
I personally haven't working too much with the low-level PanResponder apis, but I wonder if this is an easy fix.  Something along the lines of "once we have started reordering, we should aggressively not give up being the responder for the current touch".  Is that simple, do you think?
Here is a video of the behavior.  I'm using Simulator, so you can see my mouse movements, but you can't see when I click down or up.  Basically I release the click once I'm stuck in the Swipeable, and click back down in the blank area, which snaps everything back into place.
https://github.com/user-attachments/assets/f3164a46-eb62-4030-bd4b-af285c6f9c2a
Let me know if you need any additional info, or if reproducible sample code would be helpful (I will have time Monday to help).  Thanks again!

@seanadkinson : Thanks for reporting this.
We actually do capture the panResponder as soon as the motion starts, so other react-native components can't steal the gesture halfway through. However, IIUC, Swipeable from react-native-gesture-handler uses native-side things to implement its own gesture handling (which, btw, is why you can't or shouldn't mix its TouchableOpacity components with react-native's own) -- so there might not be much to be done about this (i.e. react-native-gesture-handler is likely the one breaking the pan capture rules).
May be worth posting in react-native-gesture-handler to ask about this. In looking through their docs, it doesn't seem like the component supports a disabled property, interestingly; if it did, you might work around this by disabling the Swipeable only when an item is being dragged.
In thinking about it more, you could potentially actually do that -- render the item without a Swipeable wrapping it when it's being dragged. Not awesome, but would work around the issue. Ideal is still to have Swipeable respect pan captures.


feat: Capture User Recent Activity (BE & FE)

[x] Create an Activity model in prisma for users activity
[x] Create a service for creation of users recent activity
[x] Create an GET API for user recent activity
[x] Integrate GET API of users recent activity on the frontend user  dashboard
[x] Worked on the prisma migrate functionality

This task is done.


Does not work behind reverse proxy

Like the LinkedIn authenticator plug-in, this one does not work when used behind a reverse proxy. This is the case because the callback uses the URL of the request instead of computing the callback as was done when redirecting to Windows Live.

Fixed in release 1.3.0


Font size tweak for #2324

Also reduced the size for tbody data to fit properly

Thanks @divyanshu013!

You're welcome Nick.


Creation of redirect file and a terminology fix from Marc

Please use this template to ensure easier processing of your pull request
Category

[ x] Content fix

Docs Build status updates of commit 56e3b4e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

Community/large-lists-large-libraries-in-SharePoint.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Nice move on that redirect!


RBD Async: Failed to mirrored Cloned PVC created from snapshot (PVC from snapshot)

Failed to mirror  PVC created from a snapshot
Steps to Reproduce
Create a PVC
Create a snapshot of PVC
Create a PVC from snapshot
Create VolumeReplication to Enable Replication
74-00f8-11ec-89fe-0242ac110003 GRPC call: /replication.Controller/EnableVolumeReplication
I0819 14:18:34.837531       1 utils.go:178] ID: 2391 Req-ID: 0001-0009-rook-ceph-0000000000000005-33936174-00f8-11ec-89fe-0242ac110003 GRPC request: {"parameters":{"mirroringMode":"snapshot"},"secrets":"***stripped***","volume_id":"0001-0009-rook-ceph-0000000000000005-33936174-00f8-11ec-89fe-0242ac110003"}
I0819 14:18:34.856837       1 omap.go:86] ID: 2391 Req-ID: 0001-0009-rook-ceph-0000000000000005-33936174-00f8-11ec-89fe-0242ac110003 got omap values: (pool="replicapool-4", namespace="", name="csi.volume.33936174-00f8-11ec-89fe-0242ac110003"): map[csi.imageid:1972a93c67485 csi.imagename:csi-vol-33936174-00f8-11ec-89fe-0242ac110003 csi.volname:pvc-0bad8f8d-e00c-4d98-ab90-af8e5bac65be csi.volume.owner:default]
E0819 14:18:35.326354       1 replicationcontrollerserver.go:245] ID: 2391 Req-ID: 0001-0009-rook-ceph-0000000000000005-33936174-00f8-11ec-89fe-0242ac110003 failed to enable mirroring on "replicapool-4/csi-vol-33936174-00f8-11ec-89fe-0242ac110003" with error: rbd: ret=-22, Invalid argument
E0819 14:18:35.326454       1 utils.go:185] ID: 2391 Req-ID: 0001-0009-rook-ceph-0000000000000005-33936174-00f8-11ec-89fe-0242ac110003 GRPC error: rpc error: code = Internal desc = failed to enable mirroring on "replicapool-4/csi-vol-33936174-00f8-11ec-89fe-0242ac110003" with error: rbd: ret=-22, Invalid argument

rbd mirror image enable replicapool-4/csi-vol-33936174-00f8-11ec-89fe-0242ac110003 snapshot
2021-08-19T14:21:17.992+0000 7ffa219492c0 -1 librbd::api::Mirror: image_enable: mirroring is not enabled for the parent

sh-4.4# rbd info replicapool-4/csi-vol-33936174-00f8-11ec-89fe-0242ac110003
rbd image 'csi-vol-33936174-00f8-11ec-89fe-0242ac110003':
	size 1 GiB in 256 objects
	order 22 (4 MiB objects)
	snapshot_count: 0
	id: 1972a93c67485
	block_name_prefix: rbd_data.1972a93c67485
	format: 2
	features: layering, operations
	op_features: clone-child
	flags:
	create_timestamp: Thu Aug 19 14:17:35 2021
	access_timestamp: Thu Aug 19 14:17:35 2021
	modify_timestamp: Thu Aug 19 14:17:35 2021
	parent: replicapool-4/csi-snap-13fc60cc-00f8-11ec-89fe-0242ac110003@csi-snap-13fc60cc-00f8-11ec-89fe-0242ac110003
	overlap: 1 GiB

Note:- if we flatten the image before mirroring than the image can be mirrored

cc @ShyamsundarR

@Madhu-1 this is marked against the 3.5.0 release, so please revisit the state.

@Madhu-1 I have some questions.

Create a snapshot of PVC
Create a PVC from snapshot

Q1. Does "snapshot" mean VolumeSnapshot resource and the corresponding clone image?
Q2. If the answer to Q1 is yes. Does "a PVC from snapshot" mean a PVC whose source is the above VolumeSnapshot resource?
Q3. Does this succeed if VolumeReplication is also created for the parent image?
Q4. IMO, this problem comes from the limitation of Ceph. In other words, Ceph allows the replication of clone image iff the parent image enables replication. Is my understanding correct?

@Madhu-1 I have some questions.

Create a snapshot of PVC
Create a PVC from snapshot

Q1. Does "snapshot" mean VolumeSnapshot resource and the corresponding clone image? Q2. If the answer to Q1 is yes. Does "a PVC from snapshot" mean a PVC whose source is the above VolumeSnapshot resource?

Yes

Q3. Does this succeed if VolumeReplication is also created for the parent image?

yes but it depends if the snapshot is not deleted and and its also replicated we can replicate cloned PVC as well.

Q4. IMO, this problem comes from the limitation of Ceph. In other words, Ceph allows the replication of clone image iff the parent image enables replication. Is my understanding correct?

Yes we are working on this feature to support mirroring of cloned PVC as well.

Thank you for your answer. I understood.

Q3. Does this succeed if VolumeReplication is also created for the parent image?
yes but it depends if the snapshot is not deleted and and its also replicated we can replicate cloned PVC as well.

IIRC, we also need to enable mirrorings of intermediate clone images ("csi-snap-XXX" or "csi-vol-XXX-temp").

Thank you for your answer. I understood.

Q3. Does this succeed if VolumeReplication is also created for the parent image?
yes but it depends if the snapshot is not deleted and and its also replicated we can replicate cloned PVC as well.

IIRC, we also need to enable mirrorings of intermediate clone images ("csi-snap-XXX" or "csi-vol-XXX-temp").

Yes that correct but its hard to maintain such chain as PVC and Volume Snapshot are independent one, we will try to document such drawbacks , @Rakshith-R is working on this one (we might get the support of it in next 1 or 2 release)

@Madhu-1 We are trying to mirror a cloned RBD image from one cluster to another one. As you commented above, we enabled mirroring for all of the parent image, the temporary (*-temp) image, and the cloned image. However, the RBD mirroring didn't work correctly.
When we create a cloned image by a PVC-sourced PVC, ceph-csi first creates a temporary snapshot of the sourced image. Then, it deletes the snapshot after creating the cloned image from it.
# The RBD image `csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp` was created by ceph-csi
$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd info -p ceph-ssd-block-pool csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp
rbd image 'csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp':
        size 10 GiB in 2560 objects
        order 22 (4 MiB objects)
        snapshot_count: 2
        id: 12b7d4917d0d
        block_name_prefix: rbd_data.12b7d4917d0d
        format: 2
        features: layering, deep-flatten, operations
        op_features: clone-parent, clone-child, snap-trash
        flags:
        create_timestamp: Mon Nov  6 04:56:59 2023
        access_timestamp: Mon Nov  6 04:56:59 2023
        modify_timestamp: Mon Nov  6 04:56:59 2023
        parent: ceph-ssd-block-pool/csi-vol-14794525-a741-4bab-894f-da5dbf33288d@19a7104b-2646-479c-93fb-806f1791cb56 # <--- This image is created from a snapshot
        overlap: 10 GiB
        mirroring state: enabled
        mirroring mode: snapshot
        mirroring global id: 43d70f92-99da-453a-86fb-b3ce033f7387
        mirroring primary: true

$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd snap ls -p ceph-ssd-block-pool --all csi-vol-14794525-a741-4bab-894f-da5dbf33288d
SNAPID  NAME                                                                                SIZE    PROTECTED  TIMESTAMP                 NAMESPACE
   945  19a7104b-2646-479c-93fb-806f1791cb56                                                       10 GiB             Mon Nov  6 04:56:59 2023  trash (csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp) # <--- But the snapshot is already deleted

We verified that RBD mirroring succeeds if we enabled mirroring without deleting the temporary snapshot by directly executing rbd command.
Therefore, it seems that RBD mirroring for the cloned image fails because ceph-csi deletes the temporary snapshot.
Will this be a limitation of ceph-csi? Or, is ceph-csi going to provide a workaround for this problem?

Therefore, it seems that RBD mirroring for the cloned image fails because ceph-csi deletes the temporary snapshot.

i don't think deleting the snapshot is the problem but deleting the clone image created for volume snapshot is the problem.
@ushitora-anqou Currently it's a limitation with cephcsi but we have a plan to work on it in a few releases. @Rakshith-R can you please add more details?

Therefore, it seems that RBD mirroring for the cloned image fails because ceph-csi deletes the temporary snapshot.

i don't think deleting the snapshot is the problem but deleting the clone image created for volume snapshot is the problem.
@ushitora-anqou Currently it's a limitation with cephcsi but we have a plan to work on it in a few releases. @Rakshith-R can you please add more details?

I am yet to do testing on this, but I'll add more details soon.

@Madhu-1 We are trying to mirror a cloned RBD image from one cluster to another one. As you commented above, we enabled mirroring for all of the parent image, the temporary (*-temp) image, and the cloned image. However, the RBD mirroring didn't work correctly.
When we create a cloned image by a PVC-sourced PVC, ceph-csi first creates a temporary snapshot of the sourced image. Then, it deletes the snapshot after creating the cloned image from it.
# The RBD image `csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp` was created by ceph-csi
$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd info -p ceph-ssd-block-pool csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp
rbd image 'csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp':
        size 10 GiB in 2560 objects
        order 22 (4 MiB objects)
        snapshot_count: 2
        id: 12b7d4917d0d
        block_name_prefix: rbd_data.12b7d4917d0d
        format: 2
        features: layering, deep-flatten, operations
        op_features: clone-parent, clone-child, snap-trash
        flags:
        create_timestamp: Mon Nov  6 04:56:59 2023
        access_timestamp: Mon Nov  6 04:56:59 2023
        modify_timestamp: Mon Nov  6 04:56:59 2023
        parent: ceph-ssd-block-pool/csi-vol-14794525-a741-4bab-894f-da5dbf33288d@19a7104b-2646-479c-93fb-806f1791cb56 # <--- This image is created from a snapshot
        overlap: 10 GiB
        mirroring state: enabled
        mirroring mode: snapshot
        mirroring global id: 43d70f92-99da-453a-86fb-b3ce033f7387
        mirroring primary: true

$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd snap ls -p ceph-ssd-block-pool --all csi-vol-14794525-a741-4bab-894f-da5dbf33288d
SNAPID  NAME                                                                                SIZE    PROTECTED  TIMESTAMP                 NAMESPACE
   945  19a7104b-2646-479c-93fb-806f1791cb56                                                       10 GiB             Mon Nov  6 04:56:59 2023  trash (csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp) # <--- But the snapshot is already deleted

We verified that RBD mirroring succeeds if we enabled mirroring without deleting the temporary snapshot by directly executing rbd command.
Therefore, it seems that RBD mirroring for the cloned image fails because ceph-csi deletes the temporary snapshot.
Will this be a limitation of ceph-csi? Or, is ceph-csi going to provide a workaround for this problem?

If by temporary snapshot you mean kubernetes snapshot,
We will not be supporting mirroring of such a chain where intermediate k8s snapshot is deleted.
That child PVC which has a intermediate parent image in trash must be flattened in order for mirroring to be enabled on it. We may add an option to flatten such image before enabling mirroring after initial support for clones.
PVC-PVC clone is recommend to overcome this.

@Rakshith-R Sorry. We actually created a cloned PVC from another PVC (#2426).

If by temporary snapshot you mean kubernetes snapshot,

The "temporary snapshot" means the "random snap name" in this document.
We believe that the current implementation of ceph-csi deletes the temporary snapshot, so it does not allow us to create a cloned PVC from another PVC.

@Rakshith-R Sorry. We actually created a cloned PVC from another PVC (#2426).

If by temporary snapshot you mean kubernetes snapshot,

The "temporary snapshot" means the "random snap name" in this document.
We believe that the current implementation of ceph-csi deletes the temporary snapshot, so it does not allow us to create a cloned PVC from another PVC.

The temporary snapshot is deleted after the cloning process.
@ushitora-anqou
Can you please write down the steps you followed ?
What worked, what did not ?
and what's the expectation ?

@Rakshith-R Sorry, in our last comment I replied with the wrong information. I was able to create a cloned PVC from another PVC, but was unable to mirror the RDB image associated with the cloned PVC.
The steps I took were as follows:

I deployed a PVC to the primary site and created an RBD image (csi-vol-14794525-a741-4bab-894f-da5dbf33288d).

I enabled mirroring between the primary site and the secondary site, referring to the Rook documentation. As a result, I confirmed that the RBD image was mirrored correctly.

I deployed a cloned PVC at the primary site, specifying the above PVC in the dataSource field. As a result, two RBD images were created: csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9 and csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp.

I have enabled mirroring of csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp by running the following rbd command.

kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd -p ceph-ssd-block-pool mirror image enable csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp snapshot

I have deployed the VolumeReplication resource for the cloned PVC. I expected that this would result in correct mirroring of the cloned PVC, but in fact the mirroring did not work as described below.

$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd mirror pool status -p ceph-ssd-block-pool --verbose
health: ERROR

# ... snip ...

IMAGES

# ... snip ...

# Mirroring of the cloned image was not successful.
csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9:
  global_id:   4aea893a-11a4-41ce-99b2-148e68f7d6a3
  state:       up+stopped
  description: local image is primary
  service:     a on <IP_ADDRESS>
  last_update: 2023-11-09 01:31:55
  peer_sites:
    name: 901d9b89-a189-4496-8742-eddfa9798e71
    state: up+error
    description: error bootstrapping replay
    last_update: 2023-11-09 01:31:57

# The image automatically created by ceph-csi is also not successfully mirrored.
csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp:
  global_id:   43d70f92-99da-453a-86fb-b3ce033f7387
  state:       up+stopped
  description: local image is primary
  service:     a on <IP_ADDRESS>
  last_update: 2023-11-09 01:31:55
  peer_sites:
    name: 901d9b89-a189-4496-8742-eddfa9798e71
    state: up+error
    description: error bootstrapping replay
    last_update: 2023-11-09 01:31:57

# ... snip ...

The result of running rbd info against csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp is as follows:
$ kubectl exec -n ceph-ssd deploy/rook-ceph-tools -- rbd info -p ceph-ssd-block-pool csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp
rbd image 'csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp':
        size 10 GiB in 2560 objects
        order 22 (4 MiB objects)
        snapshot_count: 2
        id: 12b7d4917d0d
        block_name_prefix: rbd_data.12b7d4917d0d
        format: 2
        features: layering, deep-flatten, operations
        op_features: clone-parent, clone-child, snap-trash
        flags:
        create_timestamp: Mon Nov  6 04:56:59 2023
        access_timestamp: Mon Nov  6 04:56:59 2023
        modify_timestamp: Mon Nov  6 04:56:59 2023
        #####
        ##### ceph-csi is creating a *-temp image from a snapshot of the parent image.
        #####
        parent: ceph-ssd-block-pool/csi-vol-14794525-a741-4bab-894f-da5dbf33288d@19a7104b-2646-479c-93fb-806f1791cb56
        overlap: 10 GiB
        mirroring state: enabled ###### Mirroring is correctly enabled (but not successful)
        mirroring mode: snapshot
        mirroring global id: 43d70f92-99da-453a-86fb-b3ce033f7387
        mirroring primary: true

When I checked the RBD mirror daemon, I found the following logs, so I thought that the mirroring was not successful because the snapshot needed to create *-temp had been deleted.
debug 2023-11-06T07:39:55.000+0000 7f2182a23700 -1 librbd::image::OpenRequest: failed to find snapshot 19a7104b-2646-479c-93fb-806f1791cb56
debug 2023-11-06T07:39:55.001+0000 7f2175a09700 -1 librbd::image::CloneRequest: 0x558dda22c000 handle_open_parent: failed to open parent image: (2) No such file or directory
debug 2023-11-06T07:39:55.001+0000 7f2175a09700 -1 rbd::mirror::image_replayer::CreateImageRequest: 0x558ddaaa7e00 handle_clone_image: failed to clone image ceph-ssd-block-pool/12b77c307c09 to csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp
debug 2023-11-06T07:39:55.437+0000 7f2175a09700 -1 librbd::image::CloneRequest: 0x558dda273180 handle_open_parent: failed to open parent image: (2) No such file or directory
debug 2023-11-06T07:39:55.438+0000 7f2175a09700 -1 rbd::mirror::image_replayer::CreateImageRequest: 0x558dda9c2f00 handle_clone_image: failed to clone image ceph-ssd-block-pool/12b7d4917d0d to csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9
debug 2023-11-06T07:40:25.004+0000 7f2183224700 -1 librbd::image::OpenRequest: failed to find snapshot 19a7104b-2646-479c-93fb-806f1791cb56
debug 2023-11-06T07:40:25.005+0000 7f2175a09700 -1 librbd::image::CloneRequest: 0x558dda1c6f00 handle_open_parent: failed to open parent image: (2) No such file or directory
debug 2023-11-06T07:40:25.005+0000 7f2175a09700 -1 rbd::mirror::image_replayer::CreateImageRequest: 0x558ddaa26000 handle_clone_image: failed to clone image ceph-ssd-block-pool/12b77c307c09 to csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9-temp
debug debug 2023-11-06T07:40:25.417+0000 7f2175a09700 -1 rbd::mirror::image_replayer::CreateImageRequest: 0x558dda9c34a0 handle_clone_image: failed to clone image ceph-ssd-block-pool/12b7d4917d0d to csi-vol-ad4b205f-6515-409d-833d-d65c6d812dd9
2023-11-06T07:40:25.417+0000 7f2175a09700 -1 librbd::image::CloneRequest: 0x558dda1c6c80 handle_open_parent: failed to open parent image: (2) No such file or directory

I found that this issue is about mirroring cloned PVC from VolumeSnapshot and my posts are about mirroring cloned PVC from PVC.
I'll create a POC patch to fix my case and attached this in #2426.


[Backport release-24.05]: qdigidoc: fix TSL loading, package bumps

This fixes signing broken in qdigidoc, backporting https://github.com/NixOS/nixpkgs/pull/357428 as well as https://github.com/NixOS/nixpkgs/pull/350685.
I built this on my machine, and successfully was able to sign with SmartID. I didn't check the ID card signing, as the pcscd daemon running on my system is too new. I however also would expect this to work, if the same pcscd as in that nixpkgs checkout would be running.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Digidoc4 e8c38b73aeb218e27163376a2d617e61a2ad9b59 compiles successfully x86_64-linux. I can start it with /tmp2/nixpkgs/result/bin$ ./qdigidoc4 ( 5g6aikb1qm781flbyy9l6sscqzcyq64v-qdigidoc-4.6.0/bin), but it can not find my the "PCSC" service on my machine. I suppose this is normal. I wait until this pull request is merged, than I try again.


Cargo doesn't uniformly read configuration from env vars

Most configuration read through cargo uses helpers like Config::get_string which automatically read env vars, but configuration reading portions of Cargo that go through Config::get_table do not read environment variables. The return value here is a HashMap which doesn't proxy reads to an environment variable.
This affects, for example, source replacement. Source replacement is not configurable through environment variables (a bug) because of its use of get_table.
We should tackle this via one of two routes:

First, remove get_table entirely. Just don't expose the ability to read a table and force all configuration reads to go through get_string and friends. This may or may not be uniformly possible as IIRC there's portions of Cargo that rely on iter which is a bit of a bummer.
Second, change get_table to return a wrapper rather than a HashMap. Reads of the HashMap would "do the right thing" with environment variables. Again though it's not clear how such a wrapper would implement iter as well...

In any case, some questions to still work through here!

I'm going to take a whack at the "remove get_table" route.

After further discussion I'm not going to try this approach right now, instead musing about an alternate escaping of period and hyphen so that iteration over environmental variables could be unambiguous.

After pondering it for a few days I don't think there is such an alternate escaping. I think that it is not possible to support specifying an arbitrary TOML table via environmental variables. The space of key names in TOML is too rich to be encoded in the very limited character set allotted to environmental variables.
If one wanted to support overriding source replacement from environmental variables, one approach would be to use an array of tables where the property names can be defined to be unambiguous when converted to environmental variables. An individual table could have an index number in its name.
So instead of:
[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "../third_party/rust-crates/vendor"

one would write:
[[sources]]
name = "crates-io"
replacement = "vendored-sources"

[[sources]]
name = "vendored-sources"
directory = "../third_party/rust-crates/vendor"

The environmental variable version of this would be:
CARGO_SOURCES_001_NAME = "crates-io"
CARGO_SOURCES_001_REPLACEMENT = "vendor-sources"
CARGO_SOURCES_002_NAME = "vendored-sources"
CARGO_SOURCES_002_DIRECTORY = "../third_party/rust-crates/vendor"

One would then implement get_table_array() and have it create an array of tables from environmental variables as described above, falling back to the config TOML in the same manner as other environmental variables.

Would it be possible for Config to iterate over the environment so that get_table can stay the same?  For example, get_table("source") would fetch all CARGO_SOURCE_* environment variables, split the key by _, and inject all those values into the result.

Nevermind - obviously it wouldn't know the correct type for each variable.
I'm liking the idea of making a serde Deserializer that can handle environment variables.  I made one a few days ago, but it was more basic and ignored environment variables.

Yeah I do think that we can transparently read env vars (given enough support) for specific keys, the problem for source replacement though is that we can't iterate over tables which are defined entirely in env vars because we can reconstruct a query for a specific key into an env var but we can't take an env var and say what key/table it corresponded to

I wonder if we need to provide a giant escape hatch like CARGO_CFG_TOML or CARGO_CFG_JSON, which just accepts a toml/json string with the contest of .cargo/config?
The benefit of the current setup is that a human can easily override config on the command line. However looks like to specify tables the syntax would need to be ugly and not human friendly anyway, so perhaps just providing a giant TOML escape hatch would work better for those who need it?

Not a bad idea! TOML generally is dependent on newlines which doesn't jive well with env vars, but I'd be fine accepting either

I have a prototype that auto-converts with serde here: https://github.com/ehuss/cargo/commit/63f76b0d24bc045809a7a0d4fceea6c9bd176390
Essentially you can do something like let p: TomlProfile = config.load_type("profile.dev") and it will auto-magically convert the config (including environment variables).  It supports structs, arbitrary maps, optional values, etc.
If you'd like, I can continue working on this and submit a PR (just the serde part, no actual changes to Cargo, yet).  I realize it is a lot of code, so maybe it's not worth it (I'm no serde expert, so some parts can probably be simpler).  However, I think it would be helpful for the Profile work I'm doing, and could be used for the source map, and anything else in the future.  Overall I'm not sure how useful environment variables are.
Things left to do:

Clean up and finish unimplemented types.  Possibly use macros to reduce the bloat.
Better error handling. Include the filename of any bad configs.
Write real tests.

Possible enhancements:

Support TOML in environment values.  I think this would be possible to support for arbitrary keys (CARGO_PROFILE_DEV="...").  It could deduce that it needs a rich data type and parse as-needed.
Support lists.  Not sure what the preferred way to handle env vars would be.  Perhaps just TOML-style lists?
Underscores aren't supported for environment variable map keys (but they are supported for structs like OPT_LEVEL).  So you can't specify a package with a name like ansi_term.  Not sure if there is any way around that.

Nice!
I think I'd personaly be in favor of going down such a route, it'd probably remove almost all of our methods elsewhere I think as well if we tried hard enough :)
For TOML-in-env I think we'll want to hold off on that for now, but I could imagine perhaps not the bare key but something like CARGO_PROFILE_DEV_TOML='...' and I actually really like the idea of using toml to specify arrays!

PR for just the config part posted at #5552.

@rtsuk Are you still working on this?
At least for source replacement, another option is to use the -Z advanced-env experimental option.  It would allow you to specify source replacement like this:
CARGO_SOURCE_crates-io_REPLACE_WITH="another-source"
CARGO_SOURCE_another-source_DIRECTORY="vendor"

It only supports letters/numbers/dashes for the source name (no underscores).  Also, the use of mixed upper/lowercase is a little unconventional and weird looking, but works in all environments I'm aware of.
Another option is to extend it to support inline tables like this:
CARGO_SOURCE="{crates-io={replace-with='another-source'}, another-source={directory='vendor'}}"

Just some alternate ideas.

@ehuss I am not. My personal need for it has passed and it looked very hairy. Should the need arise again, though, I'll check out the advanced-env option.

Flattening all of toml to environment variables seems a big ask. We'd get a lot of utility if env vars in the config were expanded:
[source.vendored-sources]
directory = "$A_DIR/vendor"

(and %A_DIR% on windows)
Is that an option that could be considered?


Round up the average score of rating

Is your feature request related to a problem? Please describe.
There some score that could have a lot of numbers after the comma.

Describe the solution you'd like
Have the average score round up to minimum 2 digits after.

@PhilArsHermit   One decimal point is better.
To the coder who fixes this:
.toFixed(1)
the conversion of string and number is a bit tricky here


Fixes #1763 - Flaky test: SimpleTimerTest

Did my best to resolve #1763. Replaced the assert statements with an if statement so that they could be repeated if they don't pass immediately. The test will repeat until passed or until the added timeout occurs. As suggested, I left the assert statement after the loop which verifies the thread pool size remains unchanged after the previous operations. Not sure if I should have kept the other asserts as well but I don't see the point if the same conditions were verified already. Please suggest any changes or improvements.

Oops, I see I was off-base with this one. Will do my best to correct these issues with your suggestions in mind +1

Thanks for improving the test, @DomGarguilo !


Automated User can't be automatically refueled.

Minecraft version & Mod Version: 1.12.2
Single player or Server: Single
Describe problem (what you were doing / what happened): I attempted to pump coal into an automated user to keep it fueled, and was unable to do so. I had assumed that some side would be for refueling, but every side just went into the input slot.
Crash log (if any):
(If this is a suggestion and not a bug report, delete all this and just write your suggestion!)

Yeah this changed when I added support for power systems (RF power, etc).  People were reporting bugs that items werent being inserted, but they didnt know that was the fuel side.
So now items always work, and you can hook up a power cable to automate instead of coal.
I am glad you reported this though, maybe I need to update documentation to clarify


Updated lib_api.h version

Description
Updated lib_api.h version after changes in #19103 that missed updating the version.
Checklist
Essentials

[ ] PR's title starts with a category (e.g. [BUGFIX], [MODEL], [TUTORIAL], [FEATURE], [DOC], etc)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage
[ ] Code is well-documented

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@rondogency @mseth10 we forgot to update the version number in the previous PR. This PR updates the version number to fix it. Please approve


When server is down, the error message is not useful

My test suit is hitting a server with a bunch of requests and then checks on responses. supertest is really good for making tests on response body and status code easy!
However, when the server is down for some reason the error message doesn't allow to identify the source of the problem. Me and some other folks tripped over this a bunch of times :)
var request = require('supertest');
request('localhost:6237')
  .get('/')
  .expect(200)
  .end(function(err, res) {
    if (err) throw err;
    console.log('Success', res.body);
  });

Running this given the server at localhost:6237 is down results in this stack trace:
$ node test.js
/path/to/test.js:8
    if (err) throw err;
                   ^
TypeError: Cannot read property 'status' of undefined

Is it something I can go ahead and fix or it's intended functionality?

@sakovias https://github.com/visionmedia/supertest/issues/237

After looking at #237 , I'm seeing the same error on the newest version of master.  Perhaps the fix was never merged?

Is there any update on this one?
Is it possible to merge #237 fix into latest version?

I'm still getting this error, but it seems to happen randomly. Running the tests again it doesn't happen, maybe 1 out of every 30 runs this happens on a random test.

https://github.com/visionmedia/supertest/pull/446 should help reveal the underlying error here.


Error : [txAdmin:Monitor] Restarting server (server crash detected).

[txAdmin:Monitor] Restarting server (server crash detected).
Hello I am contacting you because I have this error that appears and I do not know where it comes from or how to fix it can you help me please.
These problems happen when a certain number of players connect

This very clearly indicates that your server is crashing.


sci_cam: Very minor doc tweaks

Katie, I hope you can review and pull this minor change in. No urgency. I would do it myself but Brian complains. :)

Katie, I hope you can review and pull this minor change in. No urgency. I would do it myself but Brian complains. :)


Implements SFX

Expected Behavior
Supports SFX (see talipp implementation).
Refer to LEAN Engine > Contributions > Indicators.
Checklist

[x] I have completely filled out this template
[x] I have confirmed that this issue exists on the current master branch
[x] I have confirmed that this is not a duplicate issue by searching issues
[x] I have provided detailed steps to reproduce the issue

I'd like to tackle this one


Improve port supported command checking

Here is an example, some ports does not support autonegotiation so I need to check it first:
AutoNegPorts = (
    POdin1G3S6P,
    skip list other ports....
)
if isinstance(self.the_generic_type_port, AutoNegPorts):
    # do something with the port

For now, I need to check anlt, brr in the same way. Because it is a generic type port, following property is not helpful.
port.info.capabilities.can_set_autoneg
port.info.capabilities.can_auto_neg_base_r
port.is_brr_mode_supported
Maybe is better to let driver provide AutoNegPorts, AnltPorts and BrrPorts  or your guys have better idea?

I remember last discuss we agree on expose different port families for user to checking with isinstance.


Audio latency

If you try the latest version of the Dr. Pentris demo, you'll find that there's a noticeable delay between the block's falling and the mod's beat (every 4 rows in this case). In other words, the audio playback lags behind the game events.
We should find a way to reduce the audio latency, or somehow otherwise get the sound synced up with the visuals and events.
This could be a long-term issue, so I'm not marking a milestone.

Reopening to fix play/pause


goraft is not safe, why not change to etcd

at least, goraft seems not have read consistency

etcd is another component to install?

type MaxVolumeIdCommand struct {
MaxVolumeId storage.VolumeId json:"maxVolumeId"
}
it seems sync for all master servers, but goraft is not strict read consistency(eg, when network partition, it may have two leader)

you are right.
I am wondering how etcd solve this problem, because it basically uses the same raft protocol.

I believe the new raft package for etcd was designed to able to be used standalone: https://github.com/coreos/etcd/tree/master/raft

Thanks Damian for the tip!
About the partitioned network, this would not be a problem for the max volume id according to raft protocol. In this case, only one part with most majority can elect a leader. The part can only serve read requests.

" if a leader is partitioned from the remaining peers, a new leader may be elected while the old leader is holding the lease. This means there are 2 leader nodes"
https://www.consul.io/docs/internals/consensus.html(look "Consistency Modes")
etcd have Read Linearization use  a quorum=true
func (t *Topology) NextVolumeId() storage.VolumeId {
vid := t.GetMaxVolumeId()
next := vid.Next()
go t.RaftServer.Do(NewMaxVolumeIdCommand(next)) //this can't sync for read only part, not block
return next
}
The read only part node always get same VolumeId for NextVolumeId, it also may same as another leader assign NextVolumeId, then i confused

Right. The NextVolumeId() function needs to wait for writes to finish before returning the value.

Actually, wait NextVolumeId() is not enough(node may set same VolumeId when).I think its a design problem

I think VolumeId shoude be a atomic add opration.
https://github.com/coreos/etcd/blob/master/Documentation/api.md (Atomically Creating In-Order Keys)

With partitioned clusters, the commit would fail if it is on the wrong cluster.