Error parsing tool.

❯ python agency.py
Error parsing tool. Skipping... AnalyzeContent.py
How do we correctly pares the tool?
`from agency_swarm.tools import BaseTool
from pydantic import Field
from agency_swarm.agents.browsing.tools.util import get_web_driver, get_b64_screenshot
from agency_swarm.util import get_openai_client
class AnalyzeContent(BaseTool):
"""
This tool analyzes the current website content developed by the Web Developer agent.
By asking questions you can ensure that the current website matches your requirements.
You can only use this tool after the web developer agent has developed the website.
"""
question: str = Field(
..., description="Question to ask about the contents of the current webpage."
)
def run(self):
    wd = get_web_driver()

    # make sure to run the web dev server first
    wd.get("http://localhost:3000")

    client = get_openai_client()

    screenshot = get_b64_screenshot(wd)

    # save screenshot locally
    with open("screenshot.png", "wb") as fh:
        fh.write(base64.b64decode(screenshot))

    messages = [
        {
            "role": "system",
            "content": "Your primary task is to accurately extract and provide information in response to user queries based on webpage screenshots. ",
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "image_url",
                    "image_url": f"data:image/jpeg;base64,{screenshot}",
                },
                {
                    "type": "text",
                    "text": f"{self.question}",
                }
            ]
        }

    ]

    response = client.chat.completions.create(
        model="gpt-4-vision-preview",
        messages=messages,
        max_tokens=1024,
    )

    message = response.choices[0].message
    message_text = message.content

    return message_text

`

I have no idea how to make any of the tools work. It is very unclear what is interpreted by the agent and what needs logic behind it.


[#noissue] fix findbug issue

Codecov Report

Merging #3372 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3372      +/-   ##
==========================================
- Coverage   40.12%   40.11%   -0.01%
==========================================
  Files        2134     2134
  Lines       69741    69740       -1
  Branches     9668     9668
==========================================
- Hits        27981    27979       -2
+ Misses      39053    39052       -1
- Partials     2707     2709       +2

Impacted Files
Coverage Δ

...m/navercorp/pinpoint/plugin/netty/NettyPlugin.java
0% <ø> (ø)
:arrow_up:

...ientExchangeHandlerImplStartMethodInterceptor.java
0% <ø> (ø)
:arrow_up:

...npoint/rpc/server/SimpleServerMessageListener.java
80% <0%> (-20%)
:arrow_down:

...nitor/DefaultDataSourceMonitorRegistryService.java
77.77% <0%> (-11.12%)
:arrow_down:

...p/pinpoint/profiler/sender/AbstractDataSender.java
97.05% <0%> (-2.95%)
:arrow_down:

...point/rpc/client/DefaultPinpointClientHandler.java
70.37% <0%> (-2.17%)
:arrow_down:

.../com/navercorp/pinpoint/profiler/context/Span.java
50% <0%> (-1.79%)
:arrow_down:

...orp/pinpoint/rpc/server/DefaultPinpointServer.java
79.37% <0%> (ø)
:arrow_up:

...inpoint/profiler/sender/AsyncQueueingExecutor.java
77.17% <0%> (+1.08%)
:arrow_up:

...m/navercorp/pinpoint/test/OrderedSpanRecorder.java
72.11% <0%> (+1.92%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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


Update to Observers v0.2

Update to Observers v0.2 (https://github.com/GTorlai/Observers.jl/pull/15). The main change is that Observer(...) constructors were deprecated in favor of observer(...), and the Observer type was removed in favor of just using DataFrame directly. Mostly it shouldn't be noticeable to users except for how to access data of the result, which follows the DataFrames interface.

Codecov Report

Merging #57 (7ba78be) into main (9b495e9) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #57   +/-   ##
=======================================
  Coverage   86.47%   86.47%
=======================================
  Files          16       16
  Lines         599      599
=======================================
  Hits          518      518
  Misses         81       81

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


memory leak in failed send/recv

when we try to use Socket.send method, we found that if the flags is NOBLOCK, memory leak happens. After reading the socket.pyx, we found the reason of memory leak as shown in the picture. when the function "zmq_msg_send(&data, handle, flags)" failed, the memory alloc by "zmq_msg_init_size" is not freed.

How are you checking this leak? zmq_msg_send hands off the data to a background IO thread to send and free at a later point. The memory is not and should not be freed by the main thread.

We found this leak in our project. Here is the API description of zmq_msg_close and zmq_msg_init_size(http://api.zeromq.org/2-1:zmq-msg-close  ,  http://api.zeromq.org/2-1:zmq-msg-init-size).

From the description, we know that when we do not need to use msg, we should use zmq_msg_close at once. In the picture we posted last time, while the rc less than 0 , the msg doesn't free.
Here is the deamon we test:

If the code changes like this

, the problem will be solved.

Gotcha, thanks. I see that there can be a leak when send fails. That fix isn't quite right, but I know how to fix it now. Thanks!


[feat] optimize read, pushdown limit to file level for to_arrow

Feature Request / Improvement
As of now, limit is checked only after an entire parquet file is read.
https://github.com/apache/iceberg-python/blob/d8b5c17cadbc99e53d08ade6109283ee73f0d83e/pyiceberg/io/pyarrow.py#L1360-L1390
Optimization to pushdown limit to the parquet reading level
For more details, see this comment

@kevinjqliu I would like to work on this one.

sure @soumya-ghosh, assigned to you
The solution might look similar to what is already done for project_batches in #1042
https://github.com/apache/iceberg-python/blob/f05b1aedee8451d981188adf68be5e8b360a9ca1/pyiceberg/io/pyarrow.py#L1457-L1479

Closed by #1043 (see comment)


Reinstate Haircut filter - also, previously, the haircut filter checkbox was not returning correct results

Also asked by Lindsay via email: "haircut selection box does not impact the URL (or the page). Please double-check the functionality."
I (adam) checked it too. fyi if I enter https://test.yourpeer.nyc/personal-care?advanced=yes&personal-care=haircut this doesn't return correct results either.
According to GoGetta, haircuts are at
https://gogetta.nyc/find/location/688c0cbf-b8fa-4fb0-9138-9a9bfc00039a
https://gogetta.nyc/find/location/4dcd483d-eef8-4427-adb4-d6376f2ff1d8
https://gogetta.nyc/find/location/1ebd1a5d-c3a1-404d-aaf2-830552e4deea
https://gogetta.nyc/find/location/7ad659a1-e58f-4a5c-a052-6de931d0fed0

lifting this up given its one of our oldest issues and people do search for haircuts

also need to reinstate the hiarcut subcategory page https://yourpeer.nyc/personal-care/haircuts-barbers


nullable in schema object must have a type sibling

Describe the bug

From 3.0 about nullable:

A true value adds "null" to the allowed type specified by the type keyword, only if type is explicitly defined within the same Schema Object. Other Schema Object constraints retain their defined behavior, and therefore may disallow the use of null as a value. A false value leaves the specified or default type unmodified. The default value is false.

To Reproduce
This schema should not be valid because foo definition has nullable and that does not have an explicit sibling of type.
schema:
  type: object
  properties:
    foo:
       nullable: true

People also seem to think this is valid, but it isn't:
schema:
  type: object
  properties:
    foo:
       nullable: true
       allOf:
          $ref: # some reference

Expected behavior

Let the user know where incorrect use of nullable has happened.
Logs

N/A
OpenAPI definition

OpenAPI 3.0.
Redocly Version(s)

1.0.0-beta.112
Node.js Version(s)

16
Additional context

n/a

@AntonKozachuk you didn't close this issue. You should have put in the reference of the description "Closes #925" or "Fixes #925"

I want to preface this by saying that i'm not sure what the correct answer is, but I think the recent change in #938 broke validation for a specific use case.  My understanding of the spec is that the following should be ok because its not a ref, but the new validator says that type needs to be specified.
api-response-single:
      type: object
      allOf:
        - $ref: "#/components/schemas/api-response-common"
        - properties:
            result:
              nullable: true
              anyOf:
                - type: object
                - type: string

Curious to hear your thoughts on it?

It seems like https://github.com/Redocly/redocly-cli/pull/938 is a breaking change.
Schemas like
 veryBigNumber:
      allOf:
        - $ref: '#/components/schemas/BigInt'
        - nullable: true

Are not valid anymore even though the ref schema has a type field declared.
@adamaltman is this the intended behavior?

I don't think this is actually correct.
The spec doesn't say anything about it being invalid, just that it doesn't add null as a possible value for that type.
From the clarifying proposal:

Does an untyped schema (without a type keyword) allow null values by default? What effect, if any, does nullable: true have on an untyped schema?
Yes, an untyped schema allows null values, in addition to all other types. nullable: true has no effect, because null values are already allowed. And nullable: false has no effect because it just leaves the type constraint unmodified.

I interpret that as saying it's perfectly valid to have nullable: true without type specified (it just has no effect). I cannot find anything in the specification that states that type MUST BE specified when nullable: true is.
I think #938 should be reverted.

I'll reopen this for further investigation.

Still an issue FYI. Getting The 'type' field must be defined when the 'nullable' field is used. on the following OpenAPI 3.0.1 doc section:
"product": {
    "allOf": [
        {
            "$ref": "#/components/schemas/Product"
        }
    ],
    "nullable": true
},

This was generated by Swashbuckle.AspNetCore.
I looked at the rule's code and it's pretty basic -- has no awareness of allOf:
        if (propName === 'nullable' && !node.type) {
          report({
            message: 'The `type` field must be defined when the `nullable` field is used.',
            location: location.child([propName]),
          });
        }

Disabling the spec rule is the workaround, but obviously not ideal...

Disabling the spec rule is the workaround, but obviously not ideal...

Is there any better solution? I feel that spec also includes some other important checks? Would be better if I disable a rule one specific check would be affected.

I think the behaviour needs to be revised. @lornajane, could you take a look at this?
@magnusja, @IGx89, disabling the spec rule is not a good workaround as it checks the most essential aspects of API descriptions. Until it's fixed (if it will be), I'd recommend adding that specific error to the ignore file.

I support reverting #938, it's too limited to be a good solution. However there are some situations where we're not warning about a potential problem. Let's add a separate rule to check it so we can add a bit more advanced logic and let users opt in to using it (or at least disable that more really). Note also that this behaviour changed between 3.0 and 3.1

The current check is valid:

A true value adds "null" to the allowed type specified by the type keyword, only if type is explicitly defined within the same Schema Object.

allOf is not considered.
On the other side, there is nothing in the spec that says you can't put nullable without a type. it's just that the nullable doesn't have any effect if it's not defined next by the explicit type.
I agree with @lornajane we should extract it from hte spec rule and move it into a separate rule which can be added as a warning to the minimal ruleset.

@IGx89 btw your specific case is explicitly mentioned in the issue:


Equality between properties of the schema

In the case of comparing two passwords for instance (password & passwordConfirmation), it would be great to have a way of comparing the two inside the schema.
const registrationSchema = z.object({
  password: z.string(),
  passwordConfirmation: z.equals(schema => schema.password.value)
});

The schema is deliberately simplified for demonstration purposes.
Here above, the equals could be an operator that helps check if the value is equal (===) to the wanted property of the schema.
This could also be great to enable this operator with a refine when needed.
z.string().refine((value, schema) => {
  return schema.password.value === value;
})

This would not mean breaking the API if this is another parameter that the refine method accepts.
Or, it could be a completely new method.
z.string().compare((value, schema) => {
  return schema.password.value === value
})

This would also be useful for unlocking cool things for dates for instance z.date().after(schema => schema.beginDate.value)

Either way, the point is that it would be awesome to be able to reflectively inspect values from our own schema for that particular case and others to come.
Note: the code excerpts above are only pseudo-code blocks, the API might be changed completely, I didn't read the full source-code to adapt these examples.

Hello @aminnairi I sent a PR for that, but my solution is not type safe, cause is impossible get the current schema type in a z.string() method, something like:
equalsTo(field: CurrentSchema, message?: errorUtil.ErrMessage);

// usage:
const registrationSchema = z.object({
    password: z.string(),
    passwordConfirmation: z.string().equalsTo("password"), // impossible get the current schema type ({ password: string; passwordConfirmation: string; })
});

Downside of the refine method is that it waits for the entire schema to be valid before it runs.
How about having partialRefine that will execute when specified fields are valid?
It can be made typesafe by using keyof because it is specified on the object schema.
const registrationSchema = z.object({
  name: z.string(),
  email: z.string().email(),
  password: z.string(),
  passwordConfirmation: z.string()
})
.partialRefine(
  ['password', 'passwordConfirmation'], // Does no require name and email to be valid to run
  (values) => { // `values` can be typesafe too by extracting only specified keys
    return values.password === values.passwordConfirmation;
  })

Hello @aminnairi I sent a PR for that, but my solution is not type safe, cause is impossible get the current schema type in a z.string() method, something like:
equalsTo(field: CurrentSchema, message?: errorUtil.ErrMessage);

// usage:
const registrationSchema = z.object({
    password: z.string(),
    passwordConfirmation: z.string().equalsTo("password"), // impossible get the current schema type ({ password: string; passwordConfirmation: string; })
});

I think that using zod refine will help you

Thank you for your follow up response, I will definitely check out the package you linked!

Downside of the refine method is that it waits for the entire schema to be valid before it runs. How about having partialRefine that will execute when specified fields are valid? It can be made typesafe by using keyof because it is specified on the object schema.
const registrationSchema = z.object({
  name: z.string(),
  email: z.string().email(),
  password: z.string(),
  passwordConfirmation: z.string()
})
.partialRefine(
  ['password', 'passwordConfirmation'], // Does no require name and email to be valid to run
  (values) => { // `values` can be typesafe too by extracting only specified keys
    return values.password === values.passwordConfirmation;
  })

Yes, it would be great to allow refining on the schema itself, hope this can be accepted as an enhancement!

I have come with the following solution:
import { z } from 'zod'

let password = ''

export const registerSchema = z.object({
  password: z
    .string()
    .min(6, { message: 'Password must be at least 6 characters' })
    .refine((value) => {
      password = value
      return true
    }),
  passwordConfirmation: z
    .string()
    .min(6, { message: 'You must confirm your password' })
    .refine((value) => value === password, 'Passwords do not match')
})

I use a helper variable in which I save the state of the password, and this way, when I trigger only the passwordConfirmation validation, it will check and compare it.
trigger(['passwordConfirmation'])


go:linkname must refer to declared function or variable

Describe the bug
Cannot go install github.com/jesseduffield/lazydocker@latest on macOS 12.3 with Go 1.18
To Reproduce
Steps to reproduce the behavior:

go install github.com/jesseduffield/lazydocker@latest

Expected behaviour
I expected an install without errors. 😄
Screenshots
go install github.com/jesseduffield/lazydocker@latest
# golang.org/x/sys/unix
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/syscall_darwin.1_13.go:25:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.1_13.go:27:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.1_13.go:40:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:28:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:43:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:59:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:75:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:90:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:105:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:121:3: //go:linkname must refer to declared function or variable
go/pkg/mod/golang.org/x/sys@v0.0.0-20191210023423-ac6580df4449/unix/zsyscall_darwin_amd64.go:121:3: too many errors

Desktop (please complete the following information):

OS: macOS 12.3
Lazydocker Version @latest
Golang: go version go1.18 darwin/amd64

Additional context
Add any other context about the problem here.

This is now fixed

Confirmed. Thanks, @jesseduffield!


changing labels doesn't update the UI and rebundle the email

guess that doesn't trigger the observer

oops, I lied, email I was testing with didn't have any other labels.  Adding a label correctly updated the UI with the new bundle


ENH: Add permdisp as a group significance method

Adds permdisp to the beta-group-significance method.

🎉


AWS app installation failed

i am trying to install AWS app, AWS add on and Python for Scientific Computing (for Linux 64-bit) providing cloudformation template parameter SearchHeadApps as
https://splunkbase.splunk.com/app/2882/,https://splunkbase.splunk.com/app/1274/,https://splunkbase.splunk.com/app/1876/ and when i check the logs i get the error as
Downloading app https://splunkbase.splunk.com/app/1876/
--2018-02-12 19:00:41--  https://splunkbase.splunk.com/app/1876/
Resolving splunkbase.splunk.com (splunkbase.splunk.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
Connecting to splunkbase.splunk.com (splunkbase.splunk.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/tmp/app2.spl’
/tmp/app2.spl                    [ <=>                                          ]  87.23K  --.-KB/s    in 0.002s
2018-02-12 19:00:41 (41.2 MB/s) - ‘/tmp/app2.spl’ saved [89328]
Installing app...
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Extracting tarball failed

Hi Anil,
You'll need to download the spl files and host them somewhere for the template to download -- most commonly an s3 bucket.  The URLs that you've chosen are direct links to the applications, and that is the cause of your errors.
Does that make sense?
Thanks,
Bill

could you please provide me the link to documentation i can refer?

The documentation says "Comma-separated list of URLs for the Splunk app (or add-on)
tarballs (.spl files) to pre-install on indexer(s)."  It's just like it sounds - the code will issue a wget on the URLs provided, unzip them, and place them in the apps folder of the Splunk installation. You can host them on your own webserver if you have one, or on an S3 bucket with a world-readable flag on the objects that you want to download.  Then simply enter the URLs for each app that you want to install, separated via commas.
Thanks,
Bill


Deprecation warnings from NPM

Just wanted to let you know I am getting deprecation warnings when running npm install in a Sage project folder:
...
npm WARN deprecation Per-package engineStrict will no longer be used
npm WARN deprecation in upcoming versions of npm. Use the config
npm WARN deprecation setting `engine-strict` instead.
npm WARN deprecation Per-package engineStrict will no longer be used
npm WARN deprecation in upcoming versions of npm. Use the config
npm WARN deprecation setting `engine-strict` instead.
npm WARN deprecation Per-package engineStrict will no longer be used
npm WARN deprecation in upcoming versions of npm. Use the config
npm WARN deprecation setting `engine-strict` instead.
npm WARN deprecation Per-package engineStrict will no longer be used
npm WARN deprecation in upcoming versions of npm. Use the config
npm WARN deprecation setting `engine-strict` instead.
npm WARN deprecation Per-package engineStrict will no longer be used
npm WARN deprecation in upcoming versions of npm. Use the config
npm WARN deprecation setting `engine-strict` instead.
...

The issue seems to be related to this:
https://github.com/gulpjs/gulp/issues/915
Is this a package.json update required for Sage or is it just a gulp-related issue?

https://github.com/gulpjs/gulp/issues/915#issuecomment-75374778


Add support for turnstile / challenge widgets

Adds support for turnstile / challenge widgets
Needs https://github.com/cloudflare/cloudflare-go/pull/1267
Closes #2273

acceptance tests are passing
TF_ACC=1 go test ./internal/framework/service/turnstile -v -count 1 -run ^TestAccCloudflareTurnstileWidget_ -timeout 120m -parallel 1
=== RUN   TestAccCloudflareTurnstileWidget_Basic
=== PAUSE TestAccCloudflareTurnstileWidget_Basic
=== CONT  TestAccCloudflareTurnstileWidget_Basic
--- PASS: TestAccCloudflareTurnstileWidget_Basic (21.04s)
PASS
ok  	github.com/cloudflare/terraform-provider-cloudflare/internal/framework/service/turnstile	22.027s

That's great! Thank you both 🙏


Cannot access pathForResource from Assets catalog

I also found the same problem in Airbnb's lottie-ios repo. When the animation json file needs to rely on local images, it can't load local images from Asset Catalogs or Local Resources folder.
Warnings from my project:
[LOTLayerContainer _setImageForAsset:]: Warn: image not found: img_1.png

Airbnb's lottie-ios has fixed this bug and released the latest version 2.5.2, but LottieXamarin binding repo did not update the latest sdk.
Please update the latest lottie-ios 2.5.2 sdk, and release new nuget package.
Thank you!

@martijn00 yes, I can. Maybe I can open a PR today.

The new release is available on nuget!


See my own avatar

I hope to see my own avatar from the perspective of a third person, which makes me feel more aggressive.
I hope to integrate readyplayer Me avatar. Users can set their own avatars.

Moving to a 3rd party view is possible now, isn't it?

Yes, was working earlier this week for me, tho broken for me today.  I found this bug looking for related issues


Optimization schema memory utilization of ColumnFile in instance level

What problem does this PR solve?
Issue Number: ref #6401
Problem Summary:
What is changed and how it works?

Add a new class ColumnFileSchema to store schema information together for ColumnFileInMemory and ColumnFileTiny.
Change the code to share the same ColumnFileSchema when the schema is the same in various ColumnFileInMemory and ColumnFileTiny.

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/cc @JaySon-Huang @breezewish @lidezhu

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/merge


Clang link error

When I configure the repo to build with Clang like this:
rm CMakeCaches.txt
CXX=clang CC=clang cmake .
make clean
make -j

I got:
/usr/bin/ld: ../src/libbux.a(StrUtil.cpp.o): undefined reference to symbol '_ZSt20__throw_length_errorPKc@@GLIBCXX_3.4'
/usr/bin/ld: /usr/lib/libstdc++.so.6: error adding symbols: DSO missing from command line
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [_deps/fetchedbux-build/test/CMakeFiles/test_expand_env.dir/build.make:104: _deps/fetchedbux-build/test/test_expand_env] Error 1
make[1]: *** [CMakeFiles/Makefile2:208: _deps/fetchedbux-build/test/CMakeFiles/test_expand_env.dir/all] Error 2
make: *** [Makefile:103: all] Error 2

Please advice

I found the solution myself by adding
target_link_libraries(... stdc++)


[WIP] Refactor/update to 1.0.10

First pass at refactoring our code for version 1.0.10.
Most UI-related code for the new spawner should now work.
Some of the already present tests are broken and will be updated in time.

@vasukulkarni @LaVLaS

Kicked off a Jenkins job to test the PR at https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/20/console

Kicked off a Jenkins job to test the PR at https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/20/console

Looks like it's failing, apparently cannot login to ODH dashboard. Could be an issue with the test users that the Jenkins Job is using and might not exist in my cluster.
Will investigate on Monday...

@LaVLaS / @vasukulkarni
Reverted the refactoring commit and pushed a few misc changes needed for minimal-image to work on 1.0.10, along with removing some comments that weren't needed anymore.
FYI: running this PR will inevitably fail, as test.robot is not updated to work with 1.0.10 (or any previous version forcing the JupyterLab UI really, since its only testcase uses the JupyterHub UI. We need to decide how to move forward with this, since test.robot doesn't do much other than check that the server is up and the notebooks are usable.
Right now, testing a PR via Jenkins will not test the PR itself but only run test.robot (and thus fail). We either need to update test.robot, change which test suite we run by default, or (imho best option) run all suites eventually skipping those that are not yet ready.
See #34 for the old refactoring changes, which would (partially) solve these problems.

https://opendatascience-jenkins-csb-rhods.apps.ocp4.prod.psi.redhat.com/job/rhods-ci-pr-test/26/console
As expected this PR is failing on Jenkins when the script tries to interact with Jupyter via the JupyterHub UI

please sign-off your commit with email
git config --global user.name "Your Name"
git config --global user.email<EMAIL_ADDRESS>and use
"git commit -s"


Go imports need updating after switching to MiniShift organization

go build fails with below error.
$ go build
gen_help_text.go:20:2: cannot find package "github.com/jimmidyson/minishift/cmd/minikube/cmd" in any of:
	/Users/lmohanty/code/gocode/src/github.com/MiniShift/minishift/vendor/github.com/jimmidyson/minishift/cmd/minikube/cmd (vendor tree)
	/usr/local/go/src/github.com/jimmidyson/minishift/cmd/minikube/cmd (from $GOROOT)
	/Users/lmohanty/code/gocode/src/github.com/jimmidyson/minishift/cmd/minikube/cmd (from $GOPATH)

The beauty of Go :-( This absolute import seem odd to me. Either way, this is something we should fix asap, on master as well as the cluster_up branch.

I was able to compile using make after doing some renames; PR #152

Fixed via pull request #152


[5.9] Fix RelBase indexing with composite types (#65550)

Previously the index data differed when using Foo, Bar vs Foo & Bar.
Fixes #56255
(cherry picked from commit 6c2ccb4c43afecf9eec85e15bed4cdc162c3a672)

@swift-ci please test

@DougGregor can I bug you for a review here as the 5.9 swift compiler release manager?


len function missing from sidebar functions list in docs

Not sure how the sidebar lists are generated, but if you search for "len" the function page comes up, but it's not listed in the sidebar.

The documentation is in a separate repo, this is just a subtree so I'll add a fix to the other repo 👍


Console commands

When i want to run :
php yii user/create ...

I have a message error :
Error: Unknown command "user/create".
Before 0.8.2, its works but after 0.9.x it does not appear the console "user"...

You should add user module to your console application config.


Reduce risk of sensitive information leak in rpc debug/error log

What changes are proposed in this pull request?
In some rpc error or debug enabled, some credential would be printed, those kinds of information should be masked.
This change is to mask the credential before printing it to log.
Why are the changes needed?
Without the fix, there is a potential credential leak issue.
Does this PR introduce any user facing changes?
No any user facing.

@ggezer @jiacheliu3  please help take a look.

Codecov Report

Merging #13971 (2deb0e4) into master (8704ea1) will decrease coverage by 0.07%.
The diff coverage is 1.66%.

@@             Coverage Diff              @@
##             master   #13971      +/-   ##
============================================
- Coverage     43.29%   43.21%   -0.08%
+ Complexity     9159     9150       -9
============================================
  Files          1413     1415       +2
  Lines         81901    81957      +56
  Branches       9915     9929      +14
============================================
- Hits          35457    35417      -40
- Misses        43496    43590      +94
- Partials       2948     2950       +2

Impacted Files
Coverage Δ

.../main/java/alluxio/conf/CredentialConfigItems.java
0.00% <0.00%> (ø)

.../src/main/java/alluxio/RpcSensitiveConfigMask.java
0.00% <0.00%> (ø)

.../server/common/src/main/java/alluxio/RpcUtils.java
30.88% <14.28%> (+0.11%)
:arrow_up:

...a/alluxio/exception/status/CancelledException.java
0.00% <0.00%> (-42.86%)
:arrow_down:

...rc/main/java/alluxio/worker/block/PinListSync.java
76.92% <0.00%> (-23.08%)
:arrow_down:

.../src/main/java/alluxio/retry/TimeBoundedRetry.java
80.76% <0.00%> (-15.39%)
:arrow_down:

...e/common/src/main/java/alluxio/AbstractClient.java
59.86% <0.00%> (-12.50%)
:arrow_down:

...on/src/main/java/alluxio/collections/LockPool.java
73.40% <0.00%> (-8.52%)
:arrow_down:

...thentication/AuthenticatedChannelServerDriver.java
85.71% <0.00%> (-5.36%)
:arrow_down:

...ain/java/alluxio/worker/block/BlockMasterSync.java
60.65% <0.00%> (-4.92%)
:arrow_down:

... and 21 more

Continue to review full report at Codecov.

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

The message dumped after masked:
blockHeartbeat: request=bitField0_:3
workerId_:7292113489303911161
properties{
com.google.protobuf.MapField@129b5
}
removedBlockIds_:{
[]
}
metrics_:{
[instance: "Worker"
source: "alluxios-mbp"
name: "BlocksEvictionRate"
value: 0.0
metricType: METER
]
}
properties{
com.google.protobuf.MapField@aaab831d
}
memoizedIsInitialized:1
addedBlocks_:{
[]
}
memoizedIsInitialized:1

'alluxio-bot, check this please'

alluxio-bot, check this please

alluxio-bot, check this please

pr was updated accordingly.

Tests all passed and comments resolved

alluxio-bot, merge this please

@ggezer Which branches should this be cherry-picked to?

alluxio-bot, cherry-pick this to branch-2.6 please


Extension completely unusable due to object range

After a little break I've recently picked up work again on a large extension I've been working on for 5 months. First thing I did was update the Business Central sandbox container (image: microsoft/bcsandbox). The container was running on our NAV 2018 dev license. The extension is written in our normal on-prem certified range ("from": 11260662, "to": 11261661). This is allowed as stated here: https://blogs.msdn.microsoft.com/nav/2018/04/05/business-central-object-ranges/
Previously this worked just fine. But after updating my container, I can publish the extension only if I disable the al.enableCodeAnalysis setting. After publishing I can't see a single field on any of my extension's new pages. All pages show up empty, with just the page caption showing. They are also not visible in the search menu.
When I enable al.enableCodeAnalysis again, my whole workspace is marked in red, all showing errors like: Record '*******' has an ID of [11260662]. It must be between 50000 and 99999.
This error is also thrown when I publish the extension.
Even though app.json clearly states:
  "application": "<IP_ADDRESS>",   "idRange": {     "from": 11260662,     "to": 11261661   }

Hi @erikrijn ,
It seems that your docker container doesn't have the NAV License which allows you to create new objects on Range "idRange": { "from": 11260662, "to": 11261661 }
Kindly Upload the NAV Developer license file that allows to create objects on range "from": 11260662, "to": 11261661.
Use following powershell cmdlet to upload license file on Docker Container.

ApplicationArea and UsageCategory

Isn't it a little bit strange that rules in the PerTenantExtensionCop analyzer are not in the AppSourceCop? E.g. PTE0003 Functions must not subscribe to CompanyOpen events. Shouldn't that one also be part of AppSouceCop? (And this is just an example).

@ajkauffmann - yes, we have some consolidation to do regarding the various code cops. Ideally you should only need to enable PTECop, AppSourceCop or CodeCop depending on the development target.
@erikrijn - Regarding the overall issues in this thread, can we consider them solved?

@StanislawStempin yes the PerTenantExtensionCop was somehow enabled again. I don't think it should be enabled by default anyway, as we're all pushing to create more standard apps instead of customer specific customizations.


It's not working; some solutions?

https://www.youtube.com/watch?v=ADUzW5BTVGI

It looks like you're using the forge mod loader.  This is a fabric mod.


[Type checker] Fix rethrow checking with a single argument label harder.

My original fix for rdar://problem/31794932 didn't work for generic
functions because it was checking in the unsubstituted interface
type. Check structurally instead. Fixes rdar://problem/31794932.

@swift-ci please smoke test and merge


Enhancement: Flatten directory structure

This PR

[x] flattens the directory structure

I'm not convinced. What is your motivation?

My motivation is that

PSR-0 has been deprecated since 2014-10-21
PSR-4 allows to have a flatter directory structure
since we are using PSR-4, why not make use of a flatter directory structure
there are no drawbacks

Hmm, why not :) :+1: rebase please and we can merge

Thanks

Thank you, @itcraftsmanpl!


List View is not renderring

I have used the Basic Usage timeline list view in my ract-native page. It worked for its default data.
But when i include data via componentWillMount()
componentWillMount(){
    var list = CustomerStore.usagelist;
    this.setState({data:list});
    console.log(JSON.stringify(list));
}

the log is printing  the data  before runnning the render() but the listview is not showing
instead it throws a warning

Warning: In next release empty section headers will be rendered. In this release you can use 'enableEmptySections' flag to render empty section headers.

I have also used the flag, but there is no use.
 <Timeline                    data={this.state.data}                    enableEmptySections={true}                 />
anybody have a solution for this...
I am using React-Native :0.38

I have resolved it by add the refreshing available in  Pull to refresh and load more type of list view.


[R-package] Expose start_iteration to dump/save/lgb.model.dt.tree

The predict() function has a start_iteration argument. As in Python, we could expose this argument to

lgb.dump() and Booster$dump_model(),
lgb.save() and Booster$save_model(), and
Booster$save_model_to_string().

Furthermore, we can also add it to lgb.model.dt.tree(), providing a straight-forward solution to https://github.com/microsoft/LightGBM/issues/6380

Thank you, I support this!


Revert "Add documentation for security config upgrade feature (#6634)"

Description
This reverts commit 6f862fa69d674c86a1c19f0e8262da987d8bf2cd.  The feature was missed in the 2.13 release and will be included in 2.14
Issues Resolved

Related https://github.com/opensearch-project/documentation-website/pull/6955

Checklist

[ ] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

the backport to 2.13 failed

This change targeted the 2.13 branch, so no backport is needed since this will be out in the next release.

the backport to 2.13 failed

This change targeted the 2.13 branch, so no backport is needed since this will be out in the next release.

Did we not previously merge it into 2.13?

the backport to 2.13 failed

This change targeted the 2.13 branch, so no backport is needed since this will be out in the next release.

Did we not previously merge it into 2.13?

I see, you reverted the original PR. No need to backport. :)


Dockerfile: Add stable toolchain

We need to add the generation of the image to quay.io

Added here: https://quay.io/repository/mocaccino/micro-toolchain-stable?tab=info


Swift 3

When installing using CocoaPods, xcode offers to convert to Swift 3. I tried pointing to the tip of the master like so, but without any luck:
pod 'QRCodeReader.swift', :git => 'https://github.com/yannickl/QRCodeReader.swift' #point to master to get swift 3 version.
Browsing the files here on github, it seems they do not comply with the Swift 3 syntax that xcode 8 enforces (e.g. replacing public with open, private with fileprivate).

The v7.x is Swift 3 / Xcode 8 compatible (the master). Which version of Cocoapods are you using?
To support Swift3 and Xcode 8 with Cocoapods you have to the 1.1.0.rc.2 installed.

@yannickl thanks for the swift (pun intended) reply :).
I'm using CocoaPods 1.0.1. I have successfully used other Swift 3 pods, so I wonder why this particular one would require me to update to a rc version...?

@jvmk Unfortunately I have no answer. I had a lot of different issues with Cocoapods 1.0.1 and 1.1.0 betas (https://github.com/CocoaPods/CocoaPods/issues/5864) but it seems disparate.
With Xcode8 you need to specify the SWIFT_VERSION for each lib and targets and Cocoapods (1.1.0.rc.2 and over) provides a .swift-version file to do so. I think some libraries are almost the same in Swift 2.3 and Swift 3 and Xcode can deals with.
By waiting for the Cocoapods 1.1.0, you can manually set the SWIFT_VERSION for the problematic pods?

@yannickl Interesting, updating to the 1.1.0.rc.2 did indeed make xcode accept QRCodeReader.swift as Swift 3. Thank you for the tip -- looking forward to using your library :)

Hai. Can i know on how to use this QRCodeReader with full screen instead of the particular size. I've try to find on adding the size but it only effect to the cancel button, switch camera button. I need to know on how to use it as fullscreen. Thank you.


Some Questions

So first, awesome work @amwx!! It's great to see someone take this up and it's sorely needed for those of us committed to WinUI but looking at Avalonia for future ports (it's the most stable macOS/Linux desktop option on the market).
I know the Avalonia Core team has reached out to you but wonder if you can share the strategy for this library? As I see it several of these core controls should end up in Avalonia UI itself (perhaps not with the latest styles). This project would still likely be needed to:

Include the controls not deemed worthy of inclusion in Avalonia itself (RatingControl, etc.)
Include the Fluent version 1 and 2 styles for ALL controls. It is likely that Avalonia will deviate and use custom styling so being able to restyle to Fluent using this lib is very useful.
This library could still mirror WinUI with all controls and just keep everything synced with WinUI as Avalonia might deviate in the future.

Controls that are prime candidates for Avalonia inclusion in my option are:

ColorPicker (however I plan a port that is closer to WinUI + UWP Community Toolkit)
SplitButton/ToggleSplitButton/DropDownButton
NavigationView
ContentDialog
All the various Icons (which @maxkatz6 is already working on I believe). Have you discussed code sharing I wonder?

For the buttons (SplitButton/ToggleSplitButton, etc.) I was planning to port those over myself. However, you have done the vast majority of the work including Flyouts, awesome! Do you have any concerns if I use your code and try to get these into Avalonia itself? Obviously, I'll need to adjust the styles, but most of the code-behind will likely be copy-pasted verbatim. I would only double check with latest WinUI.

I know the Avalonia Core team has reached out to you but wonder if you can share the strategy for this library?

To be honest, I don't really have a defined strategy. Most of what I've ported so far has been just as a challenge to myself. Of course, now that this is public, if something is requested I will definitely look into it. WinUI somewhat limits me ATM b/c not everything is open source, which means either reverse engineer it (which I've done...Flyouts, SplitView, ContentDialog, for example, but isn't ideal) or wait until MS finally decides to release their code. I will say...I'll do what I can, but I'm not interested in maintaining a 1:1 port of WinUI for Avalonia, that would be a significant amount of work and maintenance need that I'm not up to for a side/hobby project.

As I see it several of these core controls should end up in Avalonia UI itself (perhaps not with the latest styles). This project would still likely be needed to:
1. Include the controls not deemed worthy of inclusion in Avalonia itself (RatingControl, etc.)

2. Include the Fluent version 1 and 2 styles for ALL controls. It is likely that Avalonia will deviate and use custom styling so being able to restyle to Fluent using this lib is very useful.

3. This library could still mirror WinUI with all controls and just keep everything synced with WinUI as Avalonia might deviate in the future.

For the new controls my library offers, I have made them compatible with the base Fluent theme in Avalonia, so while the default is to use the new WinUI styles, you don't have to. The templates are unchanged from the new WinUI styles but the brushes/colors have been remapped. In most cases, there really is no difference between the templates.

Controls that are prime candidates for Avalonia inclusion in my option are:
* ColorPicker (however I plan a port that is closer to WinUI + UWP Community Toolkit)

* SplitButton/ToggleSplitButton/DropDownButton

* NavigationView

* ContentDialog

* All the various Icons (which @maxkatz6 is already working on I believe). Have you discussed code sharing I wonder?

Personally (and everyone is going to see this different), I think ColorPicker is best left to 3rd party libs. Not everyone needs one, and there are many different styles that this control can take (WinUI version, WinUI Com. Toolkit, my version, every other colorpicker in existence). The NavigationView is being discussed. There are some things I need to look into before this can be moved though, which I haven't had the chance to do yet. I'll agree Avalonia probably needs some sort of Dialog implementation built in, but more complex things like ContentDialog are probably best left to 3rd parties.
TBH, I haven't really looked much at the Icon implementation in Avalonia, mostly because I have my own. The biggest difference I see, is I decided to let the icons draw themselves, rather than make them like WinUI where elements (TextBlock, Path, etc.) are injected into the tree. I also have a SymbolIcon that uses the font files from the Fluent Icons repo. The biggest downside there is the need to host the 2 font files in assembly (atm are ~1.5MB), which also need to be periodically updated.

For the buttons (SplitButton/ToggleSplitButton, etc.) I was planning to port those over myself. However, you have done the vast majority of the work including Flyouts, awesome! Do you have any concerns if I use your code and try to get these into Avalonia itself? Obviously, I'll need to adjust the styles, but most of the code-behind will likely be copy-pasted verbatim. I would only double check with latest WinUI.

Go for it. Split/ToggleSplit Button I did use some custom internal stuff to implement this. Basically I have a very basic VisualStateManager to help with switching all the different states (this is one area where the CSS style styling in Avalonia doesn't work as nicely). You'll have to remove that, but otherwise feel free to use it as a starting point.
DropDownButton doesn't actually have any code logic (in WinUI it's all just UIA stuff), so I'm not really sure if this adds any real value b/c Button already has a Flyout property. Regardless, I really think Menus need to be overhauled first, as discussed in the Flyout PR. The archaic WPF way feels clunky with MenuFlyouts.

To be honest, I don't really have a defined strategy. Most of what I've ported so far has been just as a challenge to myself. Of course, now that this is public, if something is requested I will definitely look into it... I'm not interested in maintaining a 1:1 port of WinUI for Avalonia, that would be a significant amount of work and maintenance need that I'm not up to for a side/hobby project.

Totally makes sense! I was just curious your overall thinking. Again, this is all really great work!

Personally (and everyone is going to see this different), I think ColorPicker is best left to 3rd party libs. Not everyone needs one, and there are many different styles that this control can take (WinUI version, WinUI Com. Toolkit, my version, every other colorpicker in existence).

Yes, everyone has their viewpoint. Personally, the fact that there are so many color pickers in existence is exactly why this all needs to be standardized. We all need to stop re-inventing the wheel and standardize. My plan for Avalonia is to use the UWP community toolkit version. There is hope that WinUI will adopt this updated style in the future as well. At least doing this we aren't creating a new variation other than what is required for Avalonia-specific styles and object model.
I also realize we are stepping into a 4th class of controls. Controls that aren't really well suited to be 'lookless.' Meaning they are not easily re-stylable (without copy/pasting the entire template) and have a lot of named parts in a tightly controlled configuration and are highly specialized. NavigationView is in the same category. However, these are so convenient the benefits in development speed outweigh any downsides in my mind.

The biggest difference I see, is I decided to let the icons draw themselves, rather than make them like WinUI where elements (TextBlock, Path, etc.) are injected into the tree.

That's a good idea. @maxkatz6 That's a bit like what was discussed for FontIcon to get the export working to native menus.

Go for it. Split/ToggleSplit Button I did use some custom internal stuff to implement this. Basically I have a very basic VisualStateManager to help with switching all the different states (this is one area where the CSS style styling in Avalonia doesn't work as nicely). You'll have to remove that, but otherwise feel free to use it as a starting point.

Thanks! I'll use your implementation as a base along with the WinUI code/styles.

That's a good idea. @maxkatz6 That's a bit like what was discussed for FontIcon to get the export working to native menus.

Controls rendering in Avalonia is not that big deal, and it can be done with templated icons. The bigger difference in these approaches is performance, that should be better with @amwx approach, and customizability, that is better with my approach. Considering controls build-in the framework, I would prefer second approach if possible.
Coming back to the native menus and rendering to a bitmap, I don't know whole picture of this problem, but it seems to be related to a question, how to manage lifetime of the bitmap rendered from control.

ColorPicker (however I plan a port that is closer to WinUI + UWP Community Toolkit)

Personally (and everyone is going to see this different), I think ColorPicker is best left to 3rd party libs.

We all need to stop re-inventing the wheel and standardize. My plan for Avalonia is to use the UWP community toolkit version.

A bit of background:
Speaking about "4th class controls" there is no clear decision, how to integrate them into Avalonia/core, and should we even do it.
Avalonia has bad experience with DataGrid control, that is highly complex, has a lot of non-standard implementations (i.e. it has its own scrolling/virtualization, its own bindings parsing), that made this control very hard to maintain as well. Still there is no doubt that this control is highly popular as well and we can't just throw it away. Porting more complex controls from WPF/UWP we don't want to repeat the history and make the same mistake.
ColorPicker, on other hand, is not that relatively complex, and we might potentially use this control in Avalonia DevTools project, where it will be pretty much welcomed. However it will be hard to convince core team, that it should be part of Avalonia. Other options are to keep this control in Avalonia org, but outside of main repo, or create some kind of Avalonia Community Toolkit @AvaloniaCommunity might be interested in latest, but I don't have contacts with them. Side note, both options will make ColorPicker harder to use in DevTools project, which is part of main repo.
And about WinUI implementation, I agree, that one in WCT has better styles now, and we are not required to strictly follow WinUI styles or even API.
Also it's way better to have implementation that renders to the drawing context directly instead of creating and filling in-memory byte array and creating an bitmap from it. Just like @amwx did it in this repo, but it shouldn't be hardcoded to only one Skia implementation, at least if we consider this control as part of Avalonia.

Yes, everyone has their viewpoint. Personally, the fact that there are so many color pickers in existence is exactly why this all needs to be standardized. We all need to stop re-inventing the wheel and standardize.

That is a valid point but design preferences vary by individual, so standardization isn't necessarily always a good thing. I much prefer the community toolkit version over the UWP/WinUI version (which I believe you did, right?) which is why I took some design from that. But, I guess have a standard as a starting point would be a good idea, which can be fitted & customized as needed.

I also realize we are stepping into a 4th class of controls. Controls that aren't really well suited to be 'lookless.' Meaning they are not easily re-stylable (without copy/pasting the entire template) and have a lot of named parts in a tightly controlled configuration and are highly specialized. NavigationView is in the same category. However, these are so convenient the benefits in development speed outweigh any downsides in my mind.

That's where things like the lightweight styling comes in handy too. Some controls are too complex where heavy modification is not ideal, but still allows more common things to be customized.

Also it's way better to have implementation that renders to the drawing context directly instead of creating and filling in-memory byte array and creating an bitmap from it. Just like @amwx did it in this repo, but it shouldn't be hardcoded to only one Skia implementation, at least if we consider this control as part of Avalonia.

The color palette/box spectrum (whatever you want to call it) is drawn by filling in a byte array and could be done with any backend. It's not ideal and I've added as much optimization to keep it from needing to re-render unless necessary. IIRC, MS draws and keeps 6 bitmaps alive adjusting the opacity of each? I opted for the needs more power, but uses less memory approach.
And it's only locked to Skia because Direct2D only has Linear and Radial Gradients, where Skia has the sweep gradient too and the ColorWheel is possible without also needing a bitmap approach. It's probably possible in Direct2D using a custom shader or something, but that's above my knowledge level.  The ColorTriangle I implemented requires some bitmap effects that probably could be done in Direct2D, but since you have to basically create a new image for each effect in Direct2D it's a pain. Skia is just easy

@maxkatz6

The bigger difference in these approaches is performance, that should be better with @amwx approach, and customizability, that is better with my approach. Considering controls build-in the framework, I would prefer second approach if possible.

Fair enough, I don't have much of a concern either way. Something like a font icon or bitmap doesn't seem like there is anything to customize but I could be wrong. I was just thinking it would make rasterization simple as well but don't understand the internals that well to comment on it.

there is no clear decision, how to integrate them into Avalonia/core, and should we even do it.

Well, the decision has kind-of already been made, at least a precident. The DataGrid is a perfect example. Everyone expects it in toolkits these days so unfortunately it just has to be maintained. I had no idea it was parsing it's own bindings... Also, unfortunately, the WPF version wasn't open sourced at the time and the silverlight code always had a lot more issues. Comparatively speaking a ColorPicker is far easier as you said and so is a NavigationView. While I agree pulling in this class of controls must be done carefully I think these are the safest to include. I know the core team is under a huge maintenance burden now as the framework is still quite new. However, it will get better. Code does stabilize.

Also it's way better to have implementation that renders to the drawing context directly instead of creating and filling in-memory byte array and creating an bitmap from it.

This is a good idea; however, you already pointed out one of the main reasons to avoid it. There is no low-level API in Avalonia that can render a spectrum. You have to fall back into Direct2D or Skia. That is a worse design -- having to maintain two rendering backends in the control itself. In addition, a WriteableBitmap approach uses pre-existing WinUI code which shortens development time. This is something that can definitely change in the future, but I don't think a more direct rendering approach should be taken for the initial implementation.
@amwx

I much prefer the community toolkit version over the UWP/WinUI version (which I believe you did, right?) which is why I took some design from that. But, I guess have a standard as a starting point would be a good idea, which can be fitted & customized as needed.

Yes, after Microsoft seemed unwilling to improve the WinUI version I wrote the WCT version as an alternative. Of course there were a lot of great ideas from the community in the design process. I'm trying to standardize this control across all XAML toolkits because I think it's important for both developers and users. Of course I'm biased but it sounds like we are all receptive to using the WCT design.

That's where things like the lightweight styling comes in handy too. Some controls are too complex where heavy modification is not ideal, but still allows more common things to be customized.

That's a great point and it's what is done in most cases for WinUI now. The only downside is there are a lot of undocumented named resources to play around with now. There doesn't seem to be a better solution though.

The color palette/box spectrum (whatever you want to call it) is drawn by filling in a byte array and could be done with any backend. It's not ideal and I've added as much optimization to keep it from needing to re-render unless necessary. IIRC, MS draws and keeps 6 bitmaps alive adjusting the opacity of each?

As mentioned I would want to keep the WinUI implementation to start. This can be adjusted if Avalonia ever completes a composition-type backend abstraction over Skia and Direct2D.
A triangle shape is a good idea too like in some other graphics software. It should be possible to add this in in the future by just adding a new spectrum shape enum and code paths. I don't think it would be a huge tear-up but you would know more.


[Request] Zoom in/out using CTRL-Middle Mouse Scroll in Game World

It would make it so much easier to navigate, then constantly using the left/right up/down scroll bars.

Also when you zoom in currently you can't target on a particular scene, if your zoomed out 200% then have a scene in the middle of the screen then try to zoom in using CTRL+ it doesn't zoom in on that location.

Zoom in/out with ctrl+middle mouse focusing on target is now part of the 1.1.0 release :-)

Thank you so much Chris. AMAZING v1.1.0 UPDATE!!!!


How to use profiling from python bindings?

Hi, I would like to use profiling from the python bindings. It seems to me that the python class DcgmGroupProfiling is lacking a method dcgmProfWatchFields (and dcgmProfUnwatchFields), which is the C++ counterpart defined at here.
Am I missing anything or is there a workaround? Thanks.

@optyang,
Which DCGM version are you using? The dcgmProfWatchFields and dcgmProfUnwatchFields are deprecated, and you should use the DCGM_FI_PROF* fields as any other field with dcgmWatchFields API.

@optyang,
Which DCGM version are you using? The dcgmProfWatchFields and dcgmProfUnwatchFields are deprecated, and you should use the DCGM_FI_PROF* fields as any other field with dcgmWatchFields API.

Thanks a lot!


DONTMERGE: WIP: TEST: CI pr test #2

Signed-off-by: Francesco Romani<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

/close

turns out that CI was really slow, mostly because of the okd-4.1 lane. So this PR served its purpose, we can close.


[Feature] 可以增加小提琴图吗？

What problem does this feature solve?
增加小提琴图 https://ant-design-charts.antgroup.com/examples#statistics-violin
What does the proposed API look like?
是否可以增加小提琴图 https://ant-design-charts.antgroup.com/examples#statistics-violin

ECharts v6.0.0 会支持，参见 #18878


Will we be getting a new version thats compatible with Spring Boot 3.2.0

We have a version verifier that we now have to turn off with the release of Spring Boot 3.2.0.
-Dspring.cloud.azure.compatibility-verifier.enabled=false
Otherwise our app will not start and we get ERROR:
2023-10-21 11:56:33 ERROR 28 [restartedMain] o.s.b.d.LoggingFailureAnalysisReporter -
Your project setup is incompatible with our requirements due to following reasons:

Spring Boot [3.2.0-RC1] is not compatible with this Spring Cloud Azure version.

The docs here do not mention Spring Boot 3.2.0 support, but I suspect this will change?
https://github.com/Azure/azure-sdk-for-java/wiki/Spring-Versions-Mapping
thanks
David

Hi @dmarsh26 , thanks for reaching out.
We will upgrade when Spring Boot 3.2.0 GA is released.
For now, configuring -Dspring.cloud.azure.compatibility-verifier.enabled=false is a workflow if nothing breaks your project.

I think the correct property is
spring
  cloud:
    compatibility-verifier:
      enabled: false

My 50 cents:
@juliojgd from a user perspective, it would be cool when you release 5.7.1 that is compatible. For me, the other solution means i have to update 10 yaml files and make my self a reminder to remove that later again.

I think the correct property is
spring
  cloud:
    compatibility-verifier:
      enabled: false

The other path did not work for me.
My 50 cents: @juliojgd from a user perspective, it would be cool when you release 5.7.1 that is compatible. For me, the other solution means i have to update 10 yaml files and make my self a reminder to remove that later again.

Use 5.7.0 doesn't need this property

I think the correct property is
spring
  cloud:
    compatibility-verifier:
      enabled: false

The other path did not work for me.
@git9999999
This disable verified for the whole Spring Cloud. You need Spring Cloud 2023.0.0 for Spring Boot 3.2 but this version is not release yet (it will be release this or next weak). Meanwhile you can try Spring Cloud 2023.0.0-RC1. It works good (at least in my case). I am definitely not going to wait for Azure to finally add official support for Spring Boot 3.2. The last time it took a quarter of a year.

Maven: https://repo1.maven.org/maven2/com/azure/spring/spring-cloud-azure-dependencies/5.8.0/
https://github.com/Azure/azure-sdk-for-java/blob/spring-cloud-azure_5.8.0/sdk/spring/CHANGELOG.md#580-2023-12-14

Spring Cloud Azure 5.8.0 supports Spring Boot 3.2 now


Migration 3.0

Porting to Meteor version 3.0. The package is not backward compatible because it replaces kernel components that are now asynchronous. Tests can only be performed with packages compatible with version 3.0. All files are migrated to standard.js style.

Hello, does someone know when this can be merged?

I have this loaded locally and at least in initial tests its seems to work.  I'm curious why my case seems to work and yours doesn't.
I do do my RedisOplog.init inside of a Meteor.startup call which might help resolve the loading order issue you are talking about?
I'm not entirely sure what about RedisOplog matters if stuff is loaded out of order.

For an explanation of the issue I send you to https://forums.meteor.com/t/order-of-loading-packages/61112/9. The problem is insidious and could occur the particular cases.

Right, I get that packages won't load in the right order, but looking at the code of this package I'm not entirely sure why that matters.
Do you have an example repo showing redis-oplog not working correctly? It could be helpful if anyone makes an update to this package.

This package does a Monky Patch of the Mongo.Collection constructor to register all the instances created (mongoCollectionNames.js). If another package is run first and creates a collection it is not recognized and generates an error.
I don't have an example with redis-oplog but I generated a simple one to verify the problem.

Ah ok, so not really a problem with this package at all, but more a Meteor issue. I don't think there is anyway for this package to resolve that problem, maybe it could give an option to convert and register the collection after the fact.
For people, like me who don't need redis to be connected to any collections from other packages I think this will work just fine, so in theory this PR could go through. I don't have the expertise in it though to know all the possible use cases that would need to be checked.

Published<EMAIL_ADDRESS>with the latest from this branch for user testing targeting 3.0-rc.4 for now.

I don't have permissions to push to this branch, but I only adjusted package.js

rc.2 is from another branch. If that one works, we will move to that branch.

rc.2 has the same problem. I also tested it without wildhart:jobs. I get the same error with 'users' instead of 'jobs_dominator_3' then.

Interesting.

It seems like client-side updates to the profile field of Meteor.users no longer works with redis-oplog with this branch -- the server does execute the update but the client isn't notified of the change. Has anyone else seen this?

@klablink can you grand me access to your fork so that I can push updates? Thanks!
Also can we potentially merge this with this PR: https://github.com/cult-of-coders/redis-oplog/pull/405
We have already published some RCs from that branch, so it would be nice to merge into that.

@klablink can you grand me access to your fork so that I can push updates? Thanks!
Also can we potentially merge this with this PR: cult-of-coders#405 We have already published some RCs from that branch, so it would be nice to merge into that.

Hi @StorytellerCZ , I have given you the rights to the project.


Support include/exclude filters

We have a large internal codebase and I'd love to be able to use Gold to generate static documentation for it, but it's currently
However, we have a large number of generated proto files in addition to >7000 vendored files. Docs for these are both noisy and unnecessary, as they're either public or generated. It would be great to be able to exclude packages, as well as specify the exact packages to generate docs for.
Alternatively it would also work if there were an option to disable generating docs transitively, so I could just pass the exact list of packages to generate docs for, eg. gold $(go list ./... | grep -v /protos/)
For reference, Gold currently takes 8 minutes to run on this repo and generates 2GB of docs.

I forgot to say, this is awesome. I love that it generates static docs, something sorely missing from godoc.

@alecthomas
Thanks for having interests on Gold!
And thanks for the valuable suggestion / feature request.
Yes, since v0.1.0, the generated docs size becomes much larger, about 2.7x of v0.0.9.
And the number of generated html files becomes 10x of v0.0.9.
This is mainly because now every package-level identifier corresponds a use list page.
As you mentioned, even for v0.0.9-, the number of generated files will be
very large if many 3rd-party packages are depended on. So I think your
request is very reasonable.
However, there are some points I still haven't thought clearly.

Is it acceptable to reduce the features when using Gold to generated pages?

In fact, now, the "list unexported types" and "sort by popularity" features are removed in the docs generation mode.
If the "list uses of identifiers" feature (added in v0.1.0) is also removed, then the generated docs size will decrease to 1/3,
and the generated file number will decrease to 1/10.

Support JavaScript or not?

To enable the "list unexported types" and "sort by popularity" features,

without JavaScript, 3x(package count) more pages will be generated.
with JavaScript, no new pages will be generated (just one more .js file).

How to handle the links to the pages for excluded packages?

option 1: just remove these links. The user experience would be bad.
option 2: link to the corresponding pages on pkg.go.dev. With this options, there will be still some links needing to be removed, for Gold produces much more links than godoc.
option 2.a: for std packages, link to docs.go101.org/std, for other packages, still link to pkg.go.dev
option 3: customized by using a config file, and put the following alike content in it:DocsBaseURL[std] = docs.go101.org/std
DocsBaseURL[A3rdPartyModule] = example.com/bar
...

Different website might serve html pages generated with different Gold versions, so that there might be some incompatible links.
So option 3 is not very recommended to choose. (For the same reason, option 2.a is also not recommended.)
This problem should be less serious for godoc generated pages, for godoc is comparatively much more stable.
Please note that, in godoc, there are no links from depended package pages to their depending package pages.
But for Gold, this is possible for the relation is two-way. If a depended package is excluded, some information is lost.
Even with the feasible option 2, the use experience will become less happy.
And there are much development (with some unpredictable difficulties) need to be done.
I incline to reduce some features in docs generation mode without excluding any package to get a moderate user experience and to avoid some development difficulties. The docs generated by Gold v0.0.9 for the kubernetes project is 1G without compressing.
I'm listening to your opinions and ideas.

Hello!
There are two reasons for my request:

Size and time of generation.
Confusion for users - they really want the docs for our internal code, not so much for public or generated code. At the moment our internal packages are about 1/100th of the listed packages, so they're a bit hidden in the noise.

BTW during generation, I see the output pausing for a second after every hundred files or so. It looks a lot like a GC pause, or is it something else?

BTW during generation, I see the output pausing for a second after every hundred files or so. It looks a lot like a GC pause, or is it something else?

Yes, now a manual GC is made for every 1024 page generated. This is mainly to limit the peak memory use in docs generating. For the k8s project, this will make the peak memory use half (from 17G to 8.5G).
However, I found this is helpless in generating std package docs. And this slow down the whole generation about 30%. So, in the next version, the manual GC will be removed. I'm checking why the peak memory use is so high now. If I get the cause, the next version will use a different way to limit the peak memory use.

Size and time of generation.

Now, the estimated storage space percentages:

package docs pages: 1.8 space, 1.7%
package dep list pages: 0.4% space, 1.7%
method implementation pages: %1.8 space, 1.7%
source code pages: 30% space, 4.9% files
identifier use list pages: 66% space, 90% files

From your description, it looks you don't care about identifier use. So I can add an option to remove this feature in docs generation mode. This will reduce 2/3 storage space, 9/10 file count, and 4/5 generation time.

Confusion for users - they really want the docs for our internal code, not so much for public or generated code. At the moment our internal packages are about 1/100th of the listed packages, so they're a bit hidden in the noise.

As I have mentioned in my last comment, it is some hard to remove the docs of dependency packages totally. Doing this will hurt the user experience much. Many users might also need to read the dependency packages to use your pacakges.
How about list your internal packages at the beginning of the index page to emphasize them?

@alecthomas
I just pushed a new commit, in which several code generation options are added.
You can pull the code and run "go install" to install the dev version.
After the installation, you can run
gold -gen -nouses -plainsrc -emphasize-wdpkgs -s

to get samll-sized generated docs.
Any suggestions and criticizes are still welcome.

Glad it satisfies you.
I will tag the commit as v0.1.1 if there are no big problems found before tomorrow night.

I fixed a small problem (images not show) and tag it as v0.1.1.
I will close this issue. However, you can still commit here if any problems are found.

@alecthomas
FYI, I just found a project which could generate docs by using godoc: https://groups.google.com/g/golang-nuts/c/8IjToAQH5ao

I've tried it, it only works with GOPATH :(

FYI, the default command name changed to golds (from gold) recently.
And a new option -compact was added to be used as a shortcut of the
combination of several other options, including -nouses and -plainsrc now.
The option might also include other options which will be introduced later.
That means the following command is the same as the aforementioned command.
golds -gen -compact -emphasize-wdpkgs ./...


Implement the alternate solution for GitHub issue #9321, implementing Deref and DerefMut for EntityMap

Objective

Implements the alternate solution for issue #9321, #9321

Solution

Implemented the Deref and DerefMut traits for the EntityMap struct in bevy_ecs

Yes I prefer this over #9461 But what about making the hashmap field public over implementing Deref and DerefMut?

#9461 has been merged


Authentication Filter

Hello, thanks a lot for your awesome library!
Right now, I have a problem like this one
http://stackoverflow.com/questions/37671125/how-to-configure-spring-security-to-allow-swagger-url-to-be-accessed-without-aut
My rest services path is /rest/api, so I get 401 error when tried to open /rest/api/swagger-ui.html
I have tried start swagger in url /rest/docs, using custom SwaggerWebMvcConfigurer, but I got 2 problems:

SwaggerWebMvcConfigurer exposes all my rest controllers at url /rest/docs without any authnentication logic of course)))
Do I have any opportunity change base url for swagger-ui.html (/rest/docs -> /rest/api)?

Or maybe you have any suggestions how to solve my problem?
Thanks a lot

I'd say you should follow the security implementation used to by jhipster.


Supplying a customized memory map?

I want to make a bootloader and a chain-loaded firmware, so i need to specify my own memory map. However, if i try to do it via link-arg=-Tfoo.x, i'm promptly told that rust-lld: error: foo.x:3: region 'FLASH' already defined. How can i override the supplied memory map?

I think you can use the disable-linker-script feature. Does that work?
https://github.com/stm32-rs/stm32l0xx-hal/blob/f3b3e824252abfe6e5a592f3ce850d47d56cd112/build.rs#L28

Oh, yes, thank you!


Using @CognitoUser just to get user info without authentication/authorization

Hi!
I have the following issue: let's assume I have a public route, and it will return some general message if the user is not logged in (no JWT present), but for authenticated users, I would like to customize the message.
The controller would look like this:
  @Get()
  getMessage(@CognitoUser("username") username?: string) {
    return "Hello " + (username ? username : "stranger")
  }

How can I achieve this? Right now, @Authentication or @Authorization is required, but then I cannot access the endpoint publicly.

Hi @jgilewski-kone!
Thanks for suggesting this feature - it's a great idea!
Just released v1.2.0 with optional auth - exactly what you proposed!
Check out the docs for all the details:
https://github.com/Lokicoule/nestjs-cognito/tree/main/packages/auth#publicroute
Quick example of what you can do now:
@Controller('api')
@Authentication()  // 👈 Don't forget this!
export class AppController {
    @PublicRoute()
    @Get('welcome')
    welcomeUser(@CognitoUser() user?: User) {
        return user
            ? `Hey ${user.username}!`
            : "Hey guest!";
    }
}

I'd love to hear how it works for your use case!

Hi @Lokicoule!
Thanks for the super quick solution!
I have time to check it, and it works almost perfectly :)
The one thing that is not perfect is if you call this public route with the JWT token provided, we should always authenticate it if the @Authentication decorator is present. If JWT is invalid, 401 should be thrown even for @PublicRoute.
I can even provide some random string for the JWT token, and the route is called.
I expect that if the JWT is provided, it will be authenticated, and the route will be called. If there is no JWT token the public route will be called anyway without user information.
What do you think?

Hi @jgilewski-kone!
Thanks for your feedback!
Here are two possible solutions:

Enhanced @PublicRoute:

@PublicRoute({ strict: true })
endpoint() { }

New @OptionalAuth():

@OptionalAuth()
endpoint() { }

Both would handle:

No token → Allow access
Valid token → Allow access + provide user info
Invalid token → Return 401

@OptionalAuth() might be more explicit about the intent, while @PublicRoute({ strict: true }) keeps everything in one decorator.
Which approach feels clearer to you?

Hmm... in general, if my route has @Authentication decorator set and the user gives me the wrong JWT token (expired, from a different issuer or just some random string), I would unauthorize him wherever it is set in @PublicRoute.
If the user provides JWT, we need to authenticate it. If not, and the @PublicRoute is set, I would pass the request as an unauthenticated user.
In general, if both @Authentication and @PublicRoute are set, @Authentication should take precedence.

Thanks for the suggestion! I agree with your logic, it's fair and straightforward. I've implemented it exactly as you described.
No need to overcomplicate things! 👍
Released in<EMAIL_ADDRESS>

It works perfectly, thanks!


Remove the default addondeploymentconfig for the managedserviceaccount addon

Description
Remove the default addondeploymentconfig for the managedserviceaccount addon to fix the upgrade issue introduced by the PR https://github.com/stolostron/backplane-operator/pull/705
Related Issue
https://issues.redhat.com/browse/ACM-11655
Changes Made

address TODOs for the managed service account addon
remove the default  addondeploymentcondig for the msa addon
regerate charts for the msa

Screenshots (if applicable)
Add screenshots or GIFs that demonstrate the changes visually, if relevant.
Checklist

[x] I have tested the changes locally and they are functioning as expected.
[x] I have updated the documentation (if necessary) to reflect the changes.
[x] I have added/updated relevant unit tests (if applicable).
[x] I have ensured that my code follows the project's coding standards.
[x] I have checked for any potential security issues and addressed them.
[x] I have added necessary comments to the code, especially in complex or unclear sections.
[x] I have rebased my branch on top of the latest main/master branch.

Additional Notes
Add any additional notes, context, or information that might be helpful for reviewers.
Reviewers
/cc @dislbenn @qiujian16
Definition of Done

[ ] Code is reviewed.
[x] Code is tested.
[x] Documentation is updated.
[ ] All checks and tests pass.
[ ] Approved by at least one reviewer.
[ ] Merged into the main/master branch.

/cc @dislbenn @qiujian16

/test pr-image-mirror

/lgtm


Missing dependencies in verification after bootstrapping

As seen in this run, https://buildkite.com/uberopensource/fusion-release-verification/builds/233#507695a4-b02f-469f-9443-9318a38d0929, verification builds will break when a new dependency is added. My assumption is that it's because we're not doing a full yarn install, and are instead just copying package files over.
Yarn workspaces would be one way to solve this issue.

Should be fixed now.


Permanent 100% CPU utilisation upon unknown failing RPC call

Describe the bug
I send a lot of RPC calls to reth nodes (mostly debug_traceCallMany and eth_callMany).  I am assuming that this bug is triggered by one of these but it is hard to pin down which given the logged message from Reth.
After a single instance of the logged message a CPU core is maxed out at 100% until reth is restarted.  This count increases until all cores are pegged at 100%, after which reth performance is diminished to the point that it fails to maintain sync with blockchain head.
2024-10-10T13:44:13.538541Z  INFO Canonical chain committed number=20935588 hash=0x2ad19353af2cb05795c11bf1edf8c5612362fd6a3f89a3d681ffd9164250df21 elapsed=369.105418ms
2024-10-10T13:44:17.284918Z  WARN The database read transaction has been open for too long. Backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: start_thread
             at ./nptl/pthread_create.c:447:8
  10: __GI___clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
 open_duration=231.867686962s self.txn_id=3948480
2024-10-10T13:44:17.823030Z  WARN The database read transaction has been open for too long. Backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: start_thread
             at ./nptl/pthread_create.c:447:8
  10: __GI___clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Any tips on how to improve the logging in order to track down the RPC call responsible, and to stop the call from pegging the CPU? Happy to provide further logs, the problem is reasonably reproducable.  I've tried using 1.0.8 and 1.0.3, both exhibiting the behavior.
Steps to reproduce
Unknown RPC calls
Node logs
No response
Platform(s)
Linux (x86)
What version/commit are you on?
"1.0.8-dev (47c3a481)"
What database version are you on?
NA
Which chain / network are you on?
mainnet
What type of node are you running?
Full via --full flag
What prune config do you use, if any?
No response
If you've built Reth from source, provide the full command you used
RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf
Code of Conduct

[X] I agree to follow the Code of Conduct

Okay, so this was user error. I forgot i had set rpc gas cap to some obscene value whilst testing something else. Many apologies.


PY: Albop/py improvements

@sglyon : this is python only. It reproduces some of the structure on the Julia side. I take responsibility for this and will merge very soon to solve a complicated simultaneity issue. There will be more changes soon, that you will probably be more interested in.

Ok thanks for the heads up.
Carry on!


'raw' is inaccessible due to 'private' protection level in JSON.swift

When trying to build a project including RestEssentials, I receive the following error in JSON.swift:

'raw' is inaccessible due to 'private' protection level

The makeData() function inside of the internal extension for the JSON struct is trying to access a private variable 'raw'. If the variable is changed to be fileprivate instead, it compiles successfully. Do you believe anything else needs to be changed to address this?
Thanks

You are not using Swift 4. See this already closed issue: https://github.com/sean7512/RestEssentials/issues/14

@sean7512 Thank you for your quick response and my apologies for not noticing that you had already addressed this question in a previous issue. This can be marked as resolved. Thanks!

I'll leave it open until I get clarification that solution works for you as well...please let me know if that solves your issue.

I just tried building the project again and the solution indeed works for me. Thank you!

Ok, great! Thanks for the confirmation...closing now.


Update CHANGELOG to prepare for 1.0.0b8 release

API change check
API changes are not detected in this pull request.


Add optional named parameter to inject

Something like
@inject(name: 'foo')

would be a great way to support named injections. If possible the name parameter should be optional with a default null value so its still possible to simply write
@inject

+1

Patches welcome! Not sure if anyone is working on this anymore.

I'm not really maintaining it, mostly because Dado is moribund. I'm available to review though!

btw, I like the @named(name) approach, it generalizes better to other binding annotations without requires changes to @inject.

Also, we could add a @named annotation here, but the reason I didn't is that working with Guice made me learn to avoid the overly-generic and not-statically analyzable named, and instead define my own binding annotations. They're really easy to create in Dart, and allow for refactoring, find-uses, etc.
The idea with BindingAnnotation is that you can easily do:
class Foo implements BindingAnnotation {
  const Foo();
}
const foo = const Foo();

then:
class Bar {
  @inject
  Bar(@foo this.myFoo);
}

This would be a lot more maintainable than using @named('foo').


Set IP for listen

Is there any way to set the IP of the listen command? Right now it just allows for a port selection, but that seems to work only on localhost. I'd like to set the IP to something other than localhost so that it can be accessed from the public IP.

@alexhultman maybe you might know?

You can pass hostname and port if you look further

I couldn't find an example of this.

@alexhultman like this? .listen("<IP_ADDRESS>", 8000, [](auto *listenSocket) {

You have to provide a bug report with all the info needed if you want this looked at. Pretty sure it works like should already.


error coming from box_parameters

When we run the demo file , it is asking for some box parameters which is no where specified in readme file, I don't know what to mention there . The error is -------
AttributeError: 'Box' object has no attribute 'from_yaml'
Is there any change in yaml file for each model to test??
@Delay-Xili

@rishabhfrinks123 hello, have you had solve the problem?


[usbdev] Predictor of usbdev

This request contains the usbdev_TransactionManager class of the usbdev predictor (reference model). Some amendments are done to make it compatible with the scoreboard.

Hi @sarahmazhar-impare! Is this PR still current? If so, please could you rebase it and we'll try to review it. If not, please could you close it?


Will no longer be updated to the Raku ecosystem

Hello,
Thank you for the time and effort you have put in what is now the Raku Programming Language.  The language and its ecosystem are moving forward.
This means that this distribution will no longer be checked for updates by the Raku ecosystem.
This means that you will need to move your module to the zef ecosystem on the next update you make to these distributions.  Otherwise your update will simply not be seen by the ecosystem.
If you are no longer interested in maintaining this distribution, you can have this distribution moved to Raku Community Modules Adoption Center, where members of the Raku Community will take care of them.
This can be as easy as confirming that in a response to this issue.
Again, thank you for your time and efforts!
On behalf of the Raku Steering Council,
Elizabeth Mattijsen

I've removed the module from the p6c ecosystem.
It will still be available from the REA, but it won't install because of lack of proper META file.


import of bookmarks from HTML

Totally no worries on this, don't even know the details of the data model for blocks, just wondering - if my goal is to import my del.icio.us bookmarks from their simple HTML file export, that'd be cool to have an upload button for those. But it also might go against some of the Are.na specific research goals & user stories. Lot of old & text links if other users started using it. Could have emailed this question to Cab but wanted to poke around a bit first. After all, del.icio.us '05 links were pretty different than now.
PRIORITY: MAJOR

@davidmooreppf yeah definitely! We have been toying with this idea for a while, but you bring up a good point, their HTML export is probably the easiest to parse. My hope is that some of the architecture that will need to get built for Pilgrim, will have a side effect of making it easier to drop many resources into a channel at once, which would then make it much less of a burden to make a tool to import links from a specific platform.
MESSAGE: RECEIVED

STATUS: WORD / COOL


Wish the API was not so tightly woven to Streetview

The best part of this API is its ability to compute right pitch and heading when initialized with a streetview.     Making those computed values available as a callback would have made this lib a great tool in many scenarios.  May be I could untangle it and refactor a bit.  Will be a lot faster if you had some time to consider a refactor.  Or is there something I am missing?

I think what you're talking about is already there :) . If you dive a little into the source code you'll see it's splitted in multiple modules :
One of them is deviceorientationHelper.js - which can be used in standalone, with AMD (RequireJS) or CommonJS - on which PanoramaSensorsViewers relies to manage deviceorientation listeneners AND have it uniform through all the platforms (iPhone, Android, Chrome, Firefox, etc ...)
You'll find it here with other utilities I made that could also help you : https://github.com/topheman/PanoramaSensorsViewer/tree/master/src/js/topheman-panorama/utils
Note : As you'll see at the bottom of my projects page I listed utilities I made along the time, I didn't put this one - don't remember why, maybe thought it was to tighten to PanoramaSensors - but I should add it to this list. Let me know if this helps you.
Tophe

Hi Boni, I always get your emails from WalkInto so I thought this discussion was on that.
I have a simple version of device orientation with street view here:
https://github.com/TourSparkle/Map-Menu-Device-Orientation

@topheman Thank you.  After I left the note spent time reading your code and discovered deviceOrientationHelper.  In my context (I'm building the cardboard version of https://walkinto.in viewer)  require.js help was not 'required'  so was able to load it in easily and use with minor tweaks.  Thanks for your hard work.  I still have a few problems trying to iron out with sensitivity though.  But I am sure with some more time spent on it things should get better.  You could see a raw version of this work under development here
http://secure.walkinto.in/vr/e1HiXICitegJeri78RsKl
@timlewis500 my apologies in advance for spamming you.  Did not know about Toursparkle.  Very nice UI.  More power to you for making it open source.  Do you use WalkInto?  Are you a trusted photographer?

@devasur Hi, I started TourSparkle in 2013, meant to make it a customizable CMS for street view but never got to it. I am a trusted photographer. I don't use WalkInto, how goes it, lots of interest?

@devasur @timlewis500 I'm glad my project helped you (this is what Open Source Software means to me - helping each other and getting back to the community), thank you both for your feedbacks.
Tophe

@topheman +1


Add conversion from fixed approx DP to approx DP

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

#1860  👈
#1831
#1828
#1816
#1768 : 1 other dependent PR (#1854 )
main

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

Join @damienbfs and the rest of your teammates on  Graphite