Logdna logger + serverless functions

Love the LogDNA platform so far! I have a question about some pitfalls and best practices when using the logger in combination with the serverless functions - in my particular case it's the Google Cloud Functions platform + Express.js.
The main issue that worries me is that the RE of a Cloud Function can be terminated before the background tasks are finished (see this and this, also here's a little bit more elaborate version). As per the logdna/logger-node's best practices example in the docs, the client is optimised for high throughput, and it is advised to send a bunch of logs together instead of sending them individually. But I don't think I should rely on SIGTERM or SIGINT events in a serverless environment, or at least I'm not sure if it's a good practice.
Here's the best I could come up with in order to make sure the logs are getting sent to the LogDNA servers:
// utility function for sending the response
const sendJson = async (res: express.Response, json: any): Promise<void> => {
  logdnaLogger.flush()
  await once(logdnaLogger, 'cleared')
  res.json(json) // everything after this line has no guarantee to be executed
}

// somewhere far, far away...
const router = Router()

router.get(
  '/helloworld',
  async (req, res) => {
    const { uid } = getUser(req)

    const groups = await groupsRepo.findByUserId(uid)
    const sortedGroups = _(groups).sortBy(g => g.name)
    // use this helper function in order to send the logs instead of res.json(sortedGroups)
    await sendJson(res, sortedGroups)
  })

TBF I didn't test this solution yet, but still I'd be glad to hear other opinions on the topic.

Closing due to inactivity.  This is an interesting topic, but using signals as it pertains to serverless environments isn't directly related to this package.


Houston channels limited guide data

I only have a few hours of guide data for Houston channels KRIV 26.1 and KTRK 13.1. I am using Zap2it guide data. Are these channels not included in the Zap2it guide data?

Look at the detailed info for a program on those channels, and look at the
ShowID. If it starts with DT then these are not from Tribune and that would
explain it.
Jeff Kardatzke
Sent from my Android
On Mar 23, 2016 12:15 PM, "49studebaker"<EMAIL_ADDRESS>wrote:

I only have a few hours of guide data for Houston channels KRIV 26.1 and
KTRK 13.1. I am using Zap2it guide data. Are these channels not included in
the Zap2it guide data?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/google/sagetv/issues/91

The ShowID starts with DT. That explains why these channels have limited guide data.


Not using entropy minimization loss in the final model?

Hey @jiaaoc @diyiy,
A quick clarification question -- looks like the lambda-u-hinge parameter is always set to zero and also following the code, the hinge loss (entropy minimization loss, Sec 4.4 in the paper) is never added to the final loss in the MixText/TMix configuration of the code, i.e., line 353 is never executed.
Is that correct? Or am I missing something?

The weight could be set to be 0.05/0.1/0.5


Tag for “Custom” axis should come from Glyphs

@schriftgestalt, could Glyphs have a user-editable property for the four-letter tag of custom design axes? Currently, glyphsLib/fontmake uses hardcoded XXXX for the “Custom” axis. If Glyphs users could enter a proper four-letter axis tag, glyphsLib can copy this tag into its output designspaces and we’ll have one less quirk in the font production pipeline.

I’ll add that as we discussed earlier today.

Glyphs have an "Axes" custom parameter (a font-wide parameter) now to specify new axes names and tags. We should support this.
{
    name = Axes;
    value = (
        {
            Name = Weight;
            Tag = wght;
        }
    );
}

There's also "Axis Location" (a master custom parameter) to define the (user-space?) location of each master along the various axes. It looks like this:
{
    name = "Axis Location";
    value = (
        {
            Axis = Weight;
            Location = 400;
        }
    );
}


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter energiefluss-erweitert for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.energiefluss-erweitert
   -
:thumbsup: No errors found
WARNINGS:

[X] :eyes: [W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[X] :eyes: [W252] Version of package.json (0.5.1-alpha.6) doesn't match latest version on NPM (0.4.1)
[ ] :eyes: [W252] Version of package.json (0.5.1-alpha.7) doesn't match latest version on NPM (0.4.1)

SUGGESTIONS:

[ ] :pushpin: [S522] Please consider migrating to admin 5 UI (jsonConfig).

Please review issues reported and consider fixing them as soon as appropiate.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
Suggestions reported by repository checker should be reviewed. Suggestions can be ignored due to a decision of the developer but they are reported as a hint to use a configuration which might get required in future or at least is used be most adapters. Suggestions are always optional to follow.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Wed, 18 Sep 2024 08:52:35 GMT based on commit e8dae6280a4705ea7edb2d2151b80b986885d37a
ioBroker.repochecker 3.0.6

@iobroker-bot recheck

This issue has been updated by ioBroker Check and Service Bot
The following issues have been fixed
[W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[W252] Version of package.json (0.5.1-alpha.6) doesn't match latest version on NPM (0.4.1)
:thumbsup:Thanks for fixing the issues.
The following issues are new and have been added
[W252] Version of package.json (0.5.1-alpha.7) doesn't match latest version on NPM (0.4.1)
RECHECK has been performed as requested.

@iobroker-bot recheck


Add more filter lookup expressions to custom fields

Environment

Python version: 3.7.12
Nautobot version: 1.2.2

Proposed Functionality
When adding a custom text field onto a model, the default filter expression seems to be the icontains. It would be nice if we also got access to all of the additional lookup expressions as the rest of the model fields such as istartswith and iendswith as well as the negate/exclude versions.

Use Case
My current use case is for a customer to be able to create custom fields on a model and then be able to use an exclude filter on that field.

Database Changes
None.

External Dependencies
None.

https://github.com/netbox-community/netbox/pull/7678 may be useful as a reference.

@nautobot/core is there anything specific we need to address here with custom fields at this point, given all the work with filtersets?

I think so? CustomFieldFilter still only generates exact, icontains, or contains filters for custom fields. We should probably have it instead pull in the FILTER_*_LOOKUP_MAP constants from nautobot.utilities.constants and make use of those.

We're handling date fields in #1498. We can track filter updates for text and integer custom field types in this issue. Should the text filters also apply to url, select and multiselect?

Possibly resolved by #2126. That PR added the following custom field filters:

text, url and select

n (exact)
ic (icontains)
nic (icontains)
iew (iendswith)
niew (iendswith)
isw (istartswith)
nisw (istartswith)
ie (iexact)
nie (iexact)
re (regex)
nre (regex)
ire (iregex)
nire (iregex)

integer and date

n (exact)
lte (lte)
lt (lt)
gte (gte)
gt (gt)

Thanks @gsnider2195, I have confirmed that many filters that were not present before are now functioning as expected!


iOS 8.0

Would it be possible to make it work on iOS 8.0 and above?

You most likely can. Just don't go with the framework as it is compiled for iOS 9.1+. Try copying all the classes to your project directly and see if that compiles without errors. If it does, you are set. If it does not, then just fix the errors, as they will most likely be methods that weren't available in iOS 8.
A word of advice: drop iOS 8 support. If the app is new, just support the latest version of iOS and 1 prior to that. In this case I would recommend just supporting iOS 10 & 9 though given the adoption rate for iOS 10 you could do just fine with iOS 10.

Thanks for the response!  I looked into it a bit more and it's the anchors that aren't available in < iOS 9.0.  There are other projects out there that implement something similar to anchors.  I'm going to try and make these components backward compatible.  We recently dropped support for < iOS 8.0 and we won't be dropping support for 8.0 just yet.  Thanks!


Service support?

I'm very interested in CUE for inter process communication. I was wondering if there are any plans to add function signatures to enforce how two processes can communicate with each other?
Something like services in Thrift / Protobuf or queries & mutations in a GraphQL schema.
This seems a bit outside of the core motivation for CUE, but it does seem like CUE would fit very well here too.

@matthewmueller I think some work has been done on Protobuf: https://github.com/cuelang/cue/tree/master/encoding/protobuf
@mpvl would have a better idea of the state of that code, though.

@matthewmueller This is not planned at the moment, although I have given it some thought. The main reason not though is that I didn't have a concrete use case and I'm not sure how that would look like.
But as @jlongtine said, the infrastructure for Proto parsing and conversion is already in place. So it would be useful to know what exactly expect to do with such a feature.

@matthewmueller if you have a concrete example of how you would want to be using CUE this way I would be quite interested.

Hey @mpvl! I'm imagining an implementation of protobuf's generators that adds constraint-based validation.
Conceptually, I was thinking something like this:
user.cue
email: "\w+@\w+\.\w{2,}" // some regex for email

CreateInput: {
    email: email
    password: string // perhaps @len(string) > 0 <= 10
    born: >= 1900 <= 2019
}

CreateOutput: {
    id: >=0
    email: email
    born: >= 1900 <= 2019
}

UpdateInput: {
    email?: email
    password?: string // perhaps @len(string) > 0 <= 10
    born?: >= 1900 <= 2019
}

UpdateOutput: {
    ok: true | false
}

User: {
  create(in: CreateInput): CreateOutput
  update(in: UpdateInput): UpdateOutput
}

Then, run cue generate user.cue --out cue/user.go. This will create cue/user.go. This file will contain a User struct and a Marshal and an Unmarshal. Marshal and Unmarshal, bake in constraint-based validation.
Usage would look something like this:
main.go
package main

import "cue/user"

func main() {
  buf, err := ioutil.ReadAll(os.Stdin)
  if err != nil {
    panic
  }
  var u user.User
  if err := user.Unmarshal(buf, &u); err != nil {
    panic(err)
  }
  fmt.Println("got a user!", u)
}

Just to add some thoughts here: with the upcoming proposal to generalize and harmonize the syntax, something that gets close to the above rpc signatures is:
create: {in: CreateInput}: CreateOutput // POSSIBLE NEW NOTATION FOR RPC DEFINITIONS

or maybe
create: {in: CreateInput} :: CreateOutput

(The scanner still recognizes ::, even though it is unused)
Especially the former would require a minimal syntactic adjustment and generalizes, syntactically, what expressions are allowed as a label.
We are also considering allowing the call syntax for structs. Consider, this,
foo: { a: int, b: int, out: a + b } // struct with embedded scalar

call: (foo&{a: 1, b: 2}).out        // 3

On tip, which supports embedded scalars, this can be written as:
foo: { a: int, b: int, a + b } // struct with embedded scalar

call: foo&{a: 1, b: 2}         // 3

The ideas is to allow an extension of the builtin syntax for structs as well, allowing
foo: { a: int, b: int, a + b } // struct with embedded scalar

call: foo(a: 1, b: 2) // 3

Where foo(a: 1, b: 2) is a shorthand for foo&{a: 1, b: 2}, with the additional requirement that a and b MUST be defined in foo, even if it is an open struct.
This would also allow builtins to have Swift-style named arguments, which would allow some things to be written clearly, like:
range(from: 1, to: <5, by: 1)

Conversely, we could consider unnamed arguments for structs to map to the fields with name #0, #1, etc. Note that these are illegal identifiers right now to allow introducing this without causing backwards incompatibility.
These extensions to the call syntax also suggest the following possible syntax for rpc calls:
create: (in: CreateInput): CreateOutput

The problem with this is that there is an ambiguity with the proposed syntax (#165) for computed labels, especially if we want to allow unnamed arguments. A possible solution for this is to repurpose :::
create: (in: CreateInput) :: CreateOutput  // ALTERNATIVE NEW NOTATION FOR RPC DEFINITIONS

This would remove that ambiguity and this notation has precedence in functional languages. A disadvantage of this approach is that it introduces more syntax (although limited).  An advantage of doing so, though, is that it also would allow named return arguments without complications:
create: (in: CreateInput) :: (out: CreateOutput)  // ALTERNATIVE NEW NOTATION FOR RPC DEFINITIONS

Another advantage of using :: is also that it makes it clearer that this is not defining data.
Note that with both proposed syntaxes, the existing field syntax would allow attributes to be defined along the arguments. This means it allows attributing additional meaning to arguments that are irrelevant to CUE, such as:
create: (in: CreateInput @grpc(stream)) :: (out: CreateOutput @grpc(stream))

Thoughts welcome.

I'm in favor of the () :: () syntax for its visual standout properties. This will help with readability, especially when I revisit code after a long time away, and likely easier for new users to understand what is going on. The call syntax as it is today can be confusing at first.

This issue has been migrated to https://github.com/cue-lang/cue/issues/69.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


Capacitance of C2 is too high for its footprint

The C2 capacitor has a 0805 footprint, these can not be adequately sourced. This capacitor should either be replaced with a lower capacitance component or the footprint should be resized.

For now I selected the only component I could find within those specs, but as it is rated at only 4V this would not be a very durable component according to @ardentsword. I may opt to change this to a lower capacitance in the Bill-of-Materials later.


fix(Button): Correcting button shadow opacity

removed shadowLevel1Dark as this was not a value defined in the design
fixed shadowLevel1Darker to use the correct opacity value of 0.25

Fails

:no_entry_sign:
Invalid entry format in CHANGELOG.md: >+- Removed `shadowLevel1Dark` in Teams themes and changed `shadowLevel1Darker` to have correct opacity @bcalvery ([#2098](https://github.com/microsoft/fluent-ui-react/pull/2098<

  Generated by :no_entry_sign: dangerJS


Design a logo for this tool

@jpsim @mrackwitz @TimOliver any idea if we'd be allowed to use a reference of the Realm logo as part of our own tool logo ?
Maybe like put it in the bottom right corner of our icon, or drawing some icon of a tool on top of the Realm logo or something, given that this tool is dedicated to generating Realm models?
What's the licence on the Realm logo?
Thx

Hey @AliSoftware! Thanks again for building this tool! This is really great!
Uhhh, that's actually a really good question! We hadn't really considered guidelines for usage of the logo by third party projects at this point.
Our main concern with that is we wouldn't want users to accidentally assume this is an official product and then come to @Realm with support requests (This has happened in the past with a certain Xcode Alcatraz plugin, so it's something in which we're quite wary!).
The marketing folks are going to have an internal discussion about this to see what they would think is best for this sort of case. We'll get back to you on this as soon as possible. :)

Cool, thanks for your feedback!
I totally understand you wouldn't want people to think this is an official product you'd offer support for 😜
Note that we haven't thought about what our logo might look like yet, so this was a preventive question but still interested in case we decide to at least drop a reference 😉

@TimOliver any news from your marketing folks? Thx :wink:

Ahh sorry @AliSoftware!
The last I heard, we're going to ask that third party developers to please don't use the Realm logo for unofficial libraries. I haven't heard from the marketing folks in a little while, but I would assume they're still considering the options on what we can do here.
For the time being, I'd recommend considering a logo that evokes the feeling of Realm (ie, it draws from the Realm logo colours), but doesn't directly use the circular logo.
Sorry I couldn't bring any better news!

Fair enough, thanks for the feedback anyway!

Quickly designed logo now that we have the new name: (by a non-designer — me — so pardon the job quality 😄)
Do you think this kind of logo would be OK with Realm?

I think that looks great! However, I've received feedback from our design team and there are a few modifications they'd like to see before this can receive their "blessing".

Don’t modify the Realm logo or the wordmark in any way other than scaling. Do not alter the colors, waves, shapes, or aspect ratios. Do not add or subtract anything. Do not overlay/underlay anything.

So if the pink ring that overlays the logo was "tilted" a bit more as to not obstruct the logo behind it, that would comply with the "not overlaying" clause. Also, if the Realm logo had a small white border, that would address the "rod" that's underlayed. With these two changes and my interpretation of our internal brand guidelines, your logo would comply.

Like this?

That passes our internal branding guidelines, so as far as those requirements go, this is 👌 . Thanks for making those changes.
Personally, I think tightening the rings to be smaller and closer to the logo would make it feel a bit more "balanced", but now we're discussing design taste rather than requirements.

Thanks!
Purple ring brought closer, pink one stretched a little (as wide as before but pinched in height) and a little less weight overall… and that gives the new official logo, just added in the README:

Hope you like it 😉

Looks great. 👍 💯


Can't deploy this code locally on windows (same procedure worked on Linux)

I wasn't able to deploy this locally through my windows computer. When I ran yarn dev on my windows computer I got the error message:
NODE_OPTIONS='--inspect' next dev
'NODE_OPTIONS' is not recognized as an internal or external command,
operable program or batch file.

I followed the steps under "Contribute" on the main page of this repo ( https://github.com/vercel/commerce ). I did the same thing on my Linux computer and was successful. Why?

To get this to work on Windows, install cross-env: yarn or npm i cross-env and then add cross-env to the scrip. See this: https://stackoverflow.com/questions/53948521/node-options-is-not-recognized-as-an-internal-or-external-command
So something like this in the package.json:
"dev": "cross-env NODE_OPTIONS='--inspect' next dev"

Hey there! Thank you for opening this issue. We have decided to take Next.js Commerce in a new direction and will be closing out current PRs and issues due to this change. Please see this PR for more details: https://github.com/vercel/commerce/pull/966


1094: log information when an order callback request results in an unknown error

Pre-Flight checklist
What are the relevant tickets?
https://github.com/mitodl/mitxonline/issues/1094
What's this PR do?
Adds some additional logging for edge cases and failures that occur with the payment callback.
How should this be manually tested?
I'm not sure how this can be manually tested
Where should the reviewer start?
(Optional)
Any background context you want to provide?
(Optional)
Screenshots (if appropriate)
(Optional)

Codecov Report

Merging #1099 (9d09621) into main (fad270f) will decrease coverage by 1.99%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##             main    #1099      +/-   ##
==========================================
- Coverage   85.22%   83.23%   -2.00%
==========================================
  Files         287      146     -141
  Lines       10974     7140    -3834
  Branches      722      723       +1
==========================================
- Hits         9353     5943    -3410
+ Misses       1414      988     -426
- Partials      207      209       +2

Impacted Files
Coverage Δ

ecommerce/views/v0/__init__.py
89.49% <71.42%> (-1.03%)
:arrow_down:

ecommerce/models.py
88.79% <0.00%> (-1.18%)
:arrow_down:

...c/containers/pages/profile/EditProfilePage_test.js

frontend/public/src/factories/user.js

...nd/public/src/containers/pages/login/LoginPages.js

...end/public/src/components/ReceiptPageDetailCard.js

.../src/containers/pages/checkout/OrderReceiptPage.js

...containers/pages/settings/EmailConfirmPage_test.js

frontend/public/src/components/ScaledRecaptcha.js

... and 134 more

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


Feature Request: Ability to proxy requests to another endpoint

Problem
Right now if you want to extend pocketbase as a framework without Go via JS then there are some limitations when it comes to routing. Curious if it would be possible to include an API similar to static files that can use a wild card to proxy requests too.
routerAdd("GET", "/*", $apis.staticDirectoryHandler("/path/to/public", false))

Possible Solution
This would need to support more than just GET. For example the API could be:
routerAdd("*", "/*", $apis.singleHostReverseProxy(
     scheme: "http",
     host: "localhost:4321",
))

Here is an example that works if you compile with GO:
package main

import (
	"log"
	"net/http/httputil"
	"net/url"

	"github.com/labstack/echo/v5"
	"github.com/pocketbase/pocketbase"
	"github.com/pocketbase/pocketbase/core"
)

func main() {
    app := pocketbase.New()

    app.OnBeforeServe().Add(func(e *core.ServeEvent) error {
        proxy := httputil.NewSingleHostReverseProxy(&url.URL{
			Scheme: "http",
			Host:   "localhost:4321",
		})
		e.Router.Any("/*", echo.WrapHandler(proxy))
		e.Router.Any("/", echo.WrapHandler(proxy))
        return nil
    })

    if err := app.Start(); err != nil {
        log.Fatal(err)
    }
}

I also wrote a blog post on how I am doing this with Astro:
https://rodydavis.com/posts/astro-ssr-pocketbase-single-server
The downside of this is I believe it does not support auto updates ./pocketbase update and requires GO knowledge to implement.

If you go to http://<IP_ADDRESS>:8090/_/#/login it can be easily exposed admin login

If you already has a working Go code then why don't just use it? You could continue writing your hooks in JS like before (but you need to pull in JSVM yourself) .

I do usually extend with go. This is for plugins that people could add to an already running server via pb_hooks


Week days horizontal scroll issue

Following up on #153, here is another visual glitch I get when using the plugin:

When I try to scroll between the days, each day's note scrolls far beyond the text on it, as if it was very wide. This makes this feature virtually unusable, because I need to scroll a lot to move between days, and then I can't see what's in the notes of the previous days.
I am using Logseq 0.10.9 on macOS, and I tried several different themes (inluding the default), but the issue was present in all of them.

I could not replicate that situation. Would it be the same for an empty journal? Perhaps something in the content is taking up the width. If you can put it up as a markdown as a sample, I can look into it.


Fix link to checksum explanation. Closes #1318

I've set the link to the pip documentation as @berkerpeksag suggested.

Thanks @timofurrer


Ingame EO song search

can there be a way of searching songs in packs i have yet downloaded, without relying on SMO?

this capability is present in the downloadmanager api ingame with the upcoming eo2 changes. it may not be available for the 0.73.0 release


"Products" in Product Directory Design Enhancement

Which Cloudflare product does this pertain to?
Style Guide
Existing documentation URL(s)
https://developers.cloudflare.com/products/
What changes are you suggesting?
Changing the designing of the each item in the products section. Typical changes expected to update are change of border style and its hover effect.
Additional information
Screenshots
Current Design

Expected Updated Design

Howdy @iamRabia-N,
Just pushed a PR to implement one part of your suggested change (more distinctive background color), but we're going to keep the styling for the product borders the same.


ITVR - Resolve Dependency Update Issues for Frontend and Django

Description:
We have a number of dependency update issues that have been opened by the Dependabot. These updates need to be evaluated, tested and integrated into our development codebase. The identified dependencies are as follows:
word-wrap (frontend, javascript) needs to be bumped from 1.2.3 to 1.2.5 [#572]. This issue was opened 5 days ago and requires review.
certifi (django, python) needs to be bumped from 2022.12.7 to 2023.7.22 [#564]. This issue was opened last week and requires review.
cryptography (django, python) needs to be bumped from 36.0.2 to 41.0.2 [#558]. This issue was opened 3 weeks ago and requires review.
semver (frontend, javascript) needs to be bumped from 5.7.1 to 5.7.2 [#557]. This issue was opened 3 weeks ago and has been approved but not yet implemented.
django (django, python) needs to be bumped from 4.0.9 to 4.1.10 [#556]. This issue was opened last month and requires review.
Acceptance Criteria:
Each dependency update is reviewed for potential impacts on the existing codebase.
Any required changes to the codebase to accommodate these updates are implemented.
All unit and integration tests pass with the updated dependencies.
The application successfully builds and runs with the updated dependencies.
Changes are documented in the codebase as necessary.
Priority: High
This is high priority because keeping dependencies up to date is critical to the security, efficiency, and functionality of our application. Delays in these updates can lead to vulnerabilities and bugs, so it's crucial to integrate these changes as soon as possible.
Notes:
Remember to follow the usual process for updating and testing dependencies: review the changelogs for the new versions, update the dependencies in a separate branch, run the tests, and manually verify the application functions as expected. If tests fail or manual testing uncovers issues, diagnose the problem, implement the necessary code changes, and repeat the testing process.
Another Note:
The frontend Dependabot PRs update only package-lock.json, but I believe we npm install in all our environments; we don't clean install, which means we'll have to manually update package.json in order to actually use the updated packages.

Hey team! Please add your planning poker estimate with Zenhub @AlexZorkin @tim738745


schema: add support for XenServer 7.1.2 (LTS)

Fixes #3461
Adds upgrade path to add support for XenServer 7.1.2. A larger refactoring can be done in 4.14+ to treat all dot-releases as the same.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-85

@blueorangutan test centos7 xenserver-71

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + xenserver-71) has been kicked to run smoke tests

Trillian test result (tid-101)
Environment: xenserver-71 (x2), Advanced Networking with Mgmt server 7
Total time taken: 34418 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3467-t101-xenserver-71.zip
Smoke tests completed. 69 look OK, 2 have error(s)
Only failed tests results shown below:


Machine Learning on Chronic Kidney Disease Prediction

Author
Name: Gökan Kaya
Affiliation: FH Kufstein
Keywords
Chronic Kidney Desease, SVM, Pre-Processing, Classification
Abstract
Chronic kidney disease, also known as Chronic Kidney Disease, is an uncharacteristic function of the kidney or a renal failure that develops over a period of months or years. Usually, chronic kidney disease is diagnosed in screening of people known to be at risk of kidney problems kidney problems, such as people with high blood pressure or diabetes and People who have a blood relative with Chronic Kidney Disease (CKD) patients. Early prediction is therefore necessary to combat the disease of the disease and for good treatment. This study proposes that using machine learning techniques for CKD like Support Vector Machine(SVM) classifier. The final output predicts whether the person has CKD or not by having a minimum number of features. It as per the instructions provided in previous sections. Carry out the steps for Cross-linking, Fundref data, adding Document History (specific to journal submission), and finally, Manuscript validation and placing the respective metadata [1] while applying the required template.
Machine Learning on Chronic Kidney Disease Prediction.pdf

kidney_disease.csv

The current paper presents an approach for using machine learning techniques, specifically Support Vector Machine (SVM) classifier, for early prediction of Chronic Kidney Disease (CKD). The paper's abstract and introduction are well written, providing a clear overview of the problem and the proposed solution. However, the paper would benefit from a more detailed discussion of the findings in relation to the research question, as well as proofreading and clearer language.  Overall, the paper presents an interesting approach for early prediction of CKD using machine learning techniques.

This paper presents a machine learning technique, specifically the Support Vector Machine (SVM) classifier, to predict Chronic Kidney Disease (CKD).
A strength of the article is the clear and detailed explanation of the methods used, making the study easy to replicate. The use of a publicly available dataset also adds to the replicability and the pre-processing step is well explained, easy to understand and covers common issues that may arise with real-world datasets.
However, the introduction could include the current state of the art in diagnostics for the disease. Additionally although well written in form, there are some spelling mistakes.
Overall, this paper presents a well-executed approach on using machine learning techniques for the prediction of CKD. The use of SVM and a publicly available dataset make the process replicable and the results show promising accuracy in predicting CKD.
18/20


[Enhancement] Refactor parquet schema parse logic and improve stability

Previous reverted pr: #24463

Add more defensive code, to avoid BE crashed
Return false in RLE decoder instead of DCHECK(false)
Rewrite the schema parse code, improved code readability, and remove some illegal parquet file support. The code borrows from the implementation of ARROW, but the general logic remains unchanged. ARROW schema parse logic: https://github.com/apache/arrow/blob/main/cpp/src/parquet/arrow/schema.cc
Borrow the schema ut from ARROW: https://github.com/apache/arrow/blob/main/cpp/src/parquet/arrow/arrow_schema_test.cc
In the previous version, we will parse MAP<INT, INT> into MAP<STRUCT<KEY, VALUE>>, now we fixed it.
Don't support some illegal parquet files anymore, these files are reported by QA's HUDI cluster, and in the newest HUDI version, these bugs are already fixed. These bug parquet files can be read by Spark only.
Write parquet_cli tools, it can read parquet files directly, and we don't need to set schema information in code anymore.
Add arrow's fuzzing test files.

What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)


Updated the debugging Dockerfile

Added DEBIAN_FRONTEND env variable
Added a deeper clean up for smaller docker containers
Fixed the spaceing
removed the blank "RUN"
Removed some directories per sdrake.
/tmp/
/var/lib/apt/lists/
/var/tmp/

Signed-off-by: JJ Asghar<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: jjasghar
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: geeknoid
If they are not already assigned, you can assign the PR to them by writing /assign @geeknoid in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @jjasghar. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test

@jjasghar: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
77a9d30f5586b3efc6371fc46483b2a89a85e85a
link
/test e2e-simpleTests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jjasghar, linsun
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [linsun]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[otbn] Bump indices in smoke_test.S to avoid x1

The simulator treats x1 as a call stack (following the current spec),
but the RTL doesn't do that yet. For now, just avoid that register.

Just because I think this is awesome: I made the patch using the Emacs replace-regexp feature, replacing \([^0]x\)\([0-9]+\) with \1\,(+ \#2 1) (and skipping changes to x0 and x31). No fiddling required :-D

Nice regex replace feature!

Ugh. Of course, I also needed to update the golden values! Will force-push with that in a sec.


Upgrade to new metatensor-torch

Upgrade to metatensor-torch 0.5.1
Also adapting to the new metatensor convention of "neighbor list" instead of "neighbors list"

📚 Documentation preview 📚: https://metatensor-models--181.org.readthedocs.build/en/181/

There seem to be some issues with tests. 😅

Yes, sorry, this is more painful than I thought due to the changes to ModelCapabilities and the fact that we might be over-using it

Everything should work now. We just need some basic tests for the Dataset wrapper, which is clearly working anyway.
@Luthaf Let me know if you have any ideas regarding the docs failure


https://www.apexbpm.com/technologies/decisions

Augury: 1.19.1
Date: Wed, 08 Aug 2018 18:28:55 GMT
OS: Win32
Demo test application:
-- Git repository for demo app showing the issue (optional but very helpful for difficult issues).
-- If a code snippet will completely show the issue, please include it.
Description of issue:
-- Include (clipped) screenshot images if possible.
Angular version (required): ???
Steps to reproduce:

Additional details:

no issue included in this report.


fix gms and upgrade image vulnerabilities

Checklist

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

Plan Error
running git clone --branch fix_gms_upgrade_frontend_vulnerabilities --depth=1 --single-branch<EMAIL_ADDRESS>/home/atlantis/.atlantis/repos/nt-nuodata/datahub/2/default: Cloning into '/home/atlantis/.atlantis/repos/nt-nuodata/datahub/2/default'...
error: unable to create file datahub-graphql-core/src/main/java/com/linkedin/datahub/graphql/resolvers/ingest/secret/ListSecretsResolver.java: No such file or directory
error: unable to create file datahub-graphql-core/src/main/java/com/linkedin/datahub/graphql/resolvers/ingest/secret/SecretUtils.java: No such file or directory
fatal: cannot create directory at 'datahub-graphql-core/src/main/java/com/linkedin/datahub/graphql/resolvers/ingest/source': No such file or directory
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

: exit status 128


(2.0) Parameter-by-parameter continuation using featurizing

Hey, this is a new PR, following up on #69. Sorry I took so long, made all of this a bit unnecessarily complicated.  I came back to this now as I need this continuation for two projects I'm working on. On the previous PR, we were discussing whether it was better to match the attractors found for different parameters using the clouds of features or the attractors themselves. There were good points for using the features, one of them being that there would be no need for reconstructing the attractors. This is true for matching, but, importantly, not for seeding. We need the attractors to sample ics from them to use them as seeds for the attractor-finding algorithm in the subsequent parameter. Thus, since we need the attractors anyway for seeding (which is the heart of the continuation!), then we might as well use them for matching! If the user then wants to match via features, they can just extract the features in their matching function.
In summary, this PR thus implements continuation for AttractorsViaFeaturizing very similarly to how it is implemented for AttractorsViaRecurrences. The only big difference is that the ics sent to continuation must be pre-generated and stored in a StateSpaceSet, contrary to the sampler function that the AttractorsViaRecurrences version needs. This is because basins_fractions requires the ics in this way to be able to extract the attractors after grouping the features. Again, the attractors are needed for seeding, so this is necessary.
After attractors are found, initial conditions are sampled from them and sent together with the pre-generated ics for basins_fractions on the next parameter. The ics are all put together for extracting features and grouping them.
Let me know what you think!
I compared this algorithm with the recurrences one for the magnetic pendulum example in the documentations. Here is a comparison

with the recurrences on the left and the featurizing on the right for 1000 ics per parameter. I think the curves for featurizing are smoother because the pre-generated ics are fixed. For recurrences, new ics are generated for all parameters, which probably causes the bigger fluctuations.

thanks, i will review this after Tuesday.

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

Can you point me to where in the source code you "find the attractor" or "extract the attractor"?

The attractors are extracted as usual in extract_attractors, defined in https://github.com/KalelR/Attractors.jl/blob/28f662a29972c3b826bbaaa63b2cc44efce4e97f/src/mapping/grouping/attractor_mapping_featurizing.jl#L180.

I am kinda confused by how the matching works here... "what" are you matching on? I see there is an info_extraction function that extracts the attractors. But if you are matching on the attractors, there shouldn't be any influence from the user on that.

Hello, I'm free from academic duties! I will review the code tomorrow.

Hi Kalel! I am not sure to get the point of sampling the attractors point. The thing that puzzles me is that you add these extra ics to the pool of predefined initial conditions. How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.
The matching is done the usual way. So what is the advantage over the previous matching continuation?
The code is fine. It's just that I don't see the benefits right now over the previous method.

How this influences the mapper? Is it to ensure that you have at least one initial condition from each attractor? Because the mapper does its job with or without these extra initial conditions.

It is the same as the seeding part of our original Recurrences continuation, the one we described in our 2023 paper.
The featurizing mapper did not so far seed initial conditions from found attractors when moving to the next parameter. With this PR it does. This makes it more likely that if an attractor continues to exist, it will be found during the continuation.

Ok, I see more clearly the context. The code is good to go!
@KalelR  @Datseris: I have an idea to factorize a bit the code. But it is a breaking change. A new type called AttractorsFindAndMatch can generalize the interface. Then we dispatch on the type of mapper depending if its recurences or featurizing. There some code in common that can be refactored. What do you think?

@awage have you seen #130  ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

@awage have you seen #130 ...? I do exactly that. In fact, the whole code is already implemented and pushed in the branch matcher_interface. I will open a PR now.

Wow! I l'll  catch up.

See #132

Now with PR #132 and the correction at PR #146 this code is obsolete, correct? Shall we close this and PR #69 ?

Yeap.


[C# 12] New feature - Alias any type

Visual Studio release: 17.6p3

Speclet
PR

Task list:

[x] Add to What's new in C# 12
[x] Update language reference

Using directive
tuple page

[x] update compiler messages
[x] tutorials: None needed
[x] Everyday C#: This feature won't be in that section.

Associated WorkItem - 69999

Fixed in #35112


Policy gradient agent - no intention to add?

I've noticed that the REINFORCE algorithm (aka policy gradient, without the Q function) is not listed in the list of agents, even the not-yet-implemented ones.  I presume this was intentional?  How come such a basic building block of RL was left out?

The list hasn't been updated recently, contributions on algorithm implementations are more than welcome!

It has been months, is this issue closing anytime soon?

I have been working lately to add more algorithms to this software. I am currently busy with my thesis and examination. I will begin this work from mid May. Thank you :)

@mirraaj Great! If it's not too much, I would really really appreciate it if you make a blog post walking through the process creating it. Translating from equations to implementation has always been a mystical thing to me.

@tbmreza Sincere apologies for such a delay. I am back working for keras-rl. I will keep you updated. Look for new algorithms soon. :)

Hi! Any updates so far on this?


double-beep: Blacklist church\Wof\Willuminati(?:initiation(?:@gmail.com)?)?

double-beep requests the blacklist of the keyword church\W*of\W*illuminati(?:initiation(?:@gmail\.com)?)?. See the MS search here and the Stack Exchange search here.

church\W*of\W*illuminati(?:initiation(?:@gmail\.com)?)? has been seen in 10 true positives, 0 false positives, and 0 NAAs.

Duplicating comment to here from chat:
church\W*of\W*illuminati by itself matches all 10 of those posts. Tacking the email onto it feels like it's adding the email to the blacklist prior to the email qualifying the email only has 2 matches, but needs at least 3 for the blacklist, assuming we're saying that it's an ongoing campaign that's continuing from almost a year ago without any intervening detections.


Add loathsock's file

minor changes to {
layout: slide
title: "Welcome to our second slide!"
Your text
Use the left arrow to go back! }
specifically right changed to left.

this was fun!


AMD ROCm 6.2: Update to torch-2.4.1

Is your feature request related to a problem? Please describe.
AMD ROCm 6.2 requires torch-2.4.1 and cannot be used with the existing instructlab which bounds torch support to torch-2.4.0.
Describe the solution you'd like
instructlab should support at a minimum torch-2.4.1
Additional context
This is not a trivial change and requires testing of the resulting AMD images.

How does this differ from https://github.com/instructlab/instructlab/issues/2437?

We bumped torch to <2.5 in the upstream!


[ie/tenplay] Change to vod.ten.com.au

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information
Switching to vod.ten.com.au API
Fixes #10926
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

Is there anything that can help from https://github.com/matthuisman/slyguy.addons/tree/master/slyguy.10play
or https://forum.videohelp.com/threads/415165-[Release]-Ozivine-Australian-NZ-FTA-Downloader/page4#post2749536

@seproDev It's hard to gauge your level of interest in this fix given you didn't check for yourself that logging in was no longer necessary, you didn't just commit your suggestions and you mentioned ad insertion which I wasn't experiencing but then you went to the trouble of looking up the HLSURL format. If I thought you cared enough to be reviewing at the time, naturally, I wouldn't have forced pushed.
So does that mean you actually got ads with the doubleclick.net videos? For which video? Or was it for all videos?

I did a fair bit of checking for this PR, actually.  However, not knowing the website, I wanted to make sure that removing the authentication code does not remove functionality that is still required.
Yes, I did see that for the couple videos I tried, no authentication was necessary. Are there paid videos I don't know about? Is there legacy content that still works differently? As maintainers, we rely on people that are familiar with the site for these kinds of questions.

you didn't just commit your suggestions

I don't always just apply my suggestions. They are after all suggestions. If the other person is responsive, I usually leave it up to them to apply them. If they think the suggestions are good, it's a single button press in the web interface.

you mentioned ad insertion

Yeah, that is the point of the doubleclick domain, which effectively proxies the manifest and inserts ads. See https://support.google.com/admanager/answer/7299051?hl=en
And yes, when downloading https://10play.com.au/neighbours-classics/episodes/season-2012/neighbours-9-jan-2012/tpv231004pgxmn I did get a video file that contained ads using the older version of this PR that used the doubleclick domain. There was one ad at the start and three ads throughout. Here the variant m3u8: variant.m3u8.txt

There are no paid videos. memberGated being a simple boolean affirms there's only a distinction between logged in and logged out.
Unless it's another maintainer, who's going to oppose suggestions? It's hard enough getting a PR looked at let alone getting it merged without fighting suggestions.
Thanks for the m3u8 attachment. Google DAI's not injecting anything for me so I thought 10play had the ads turned off. I guess we're depending on the API to keep the direct fastly.net playlists exposed.

Unless it's another maintainer, who's going to oppose suggestions? It's hard enough getting a PR looked at let alone getting it merged without fighting suggestions.

Yes, sometimes other maintainers might disagree, but it is also totally valid for the author of the PR to disagree. Like everyone, I do make mistakes. If you disagree or have concerns with a suggestion, you should voice that.
Regarding not getting your PRs looked at, we know that the backlog of PRs has been growing and that this is far from ideal.
There is, however, only so much time to go around. yt-dlp is a hobby project for all of us. Most of us have full-time jobs that actually put food on the table, so there is only so much time we can devote to yt-dlp.
I know that it is frustrating to not get a single reply for weeks on a PR that you put a lot of effort in to. We truly do want every PR reviewed and merged, but with currently only two people reviewing extractor PRs, it might take some time.

I pushed my [Ozivine]https://github.com/billybanana80/ozivine/tree/Ozivine_v1.5(url) solution out using the android endpoint as suggested by stabbedbybrick. Nice that you've picked up on his comments to fix this. Great job.
Will keep the web option up my sleeve though in case they decide to insert ads on the android side of things.

Yes, sometimes other maintainers might disagree, but it is also totally valid for the author of the PR to disagree. Like everyone, I do make mistakes. If you disagree or have concerns with a suggestion, you should voice that.

That makes me sound like I have a disagreement. I don't. Which makes you allowing room for feedback actually slow us down. It's not just "a single button press". I have to review the suggestions, run the tests and run hatch fmt. I can voice concerns even with maintainer commits.

I know that it is frustrating to not get a single reply for weeks on a PR that you put a lot of effort in to. We truly do want every PR reviewed and merged, but with currently only two people reviewing extractor PRs, it might take some time.

I'm not frustrated at all. I already have the new code in my yt_dlp_plugins folder. So whatever you suggest, I would accept without exception. Anything to get this PR over with and stop it being my responsibility.


Update README

Update badges to markdown equivalents and use GitHub actions badge instead of prow.
Update references to "preflight" to "Jetstack Secure" where appropriate.
Signed-off-by: David Bond<EMAIL_ADDRESS>

replaced with #236


Create Cards back and test model with them

[x] Create Cards Back design
[ ] Test if the model can be trained with them

At the moment, the cards back aren't working and aren't being extracted by the script

As for now, the cards back is detected and working only with QR code


Fix: Render Credentials Before Displaying Notifications for Seamless User Experience

This pr addresses an issue where newly received credentials were not rendering before displaying notifications, requiring a page refresh. It aims to resolve this problem, ensuring a smoother user experience when handling notifications.

Consider closing this PR since its changes have been merged into an open PR #118


LocalDB is not supported on this platform.

I get a LocalDB is not supported on this platform. message when I try to ./migrate
my appsettings.json looks like this
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning"
}
},
"AllowedHosts": "*",
"ConnectionStrings": {
"AZURE_SQL_CONNECTIONSTRING": "Server=(localdb)\mssqllocaldb;Database=MyDatabaseContext-ca7b86aa-ade2-4db1-a4a9-4dce925cb814;Trusted_Connection=True;MultipleActiveResultSets=true"
}

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

ID: df55b676-8ff7-1470-3525-d0edfd406af6
Version Independent ID: ac264c26-7196-870b-760f-94a97ae437e8
Content: Deploy an ASP.NET Core and Azure SQL Database app to Azure App Service - Azure App Service
Content Source: articles/app-service/tutorial-dotnetcore-sqldb-app.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@Pefam
Thanks for your feedback! We will investigate and update as appropriate.

Thank you. I'm very interested in being able to complete this: Tutorial: Deploy an ASP.NET Core and Azure SQL Database app to Azure App Service.

@Venkateshdodda-MSFT I'm deploying from here https://github.com/Pefam/msdocs-app-service-sqldb-dotnetcore what migrate file am I looking for? Also, where do I check if I've selected a db? I've followed the instructions on the website several times.

https://github.com/MicrosoftDocs/azure-docs/issues/119944
Please help

On 02/19/2024 5:42 AM EST Venkateshdodda-MSFT @.***> wrote:
@Pefam https://github.com/Pefam

Could you please check whether you have selected Sql db or any other database while create the app service ?
Also, can you check whether migrate file is present or not under the path /home/site/wwwroot post the deployments.
Please send an email with subject line “Attn:Venkatesh |<GitHub issue #>” to @.*** @.*** referencing this thread with your GitHub repro to check and assist you further on this.

—
Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/119944#issuecomment-1952173534, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGCE3FWSUAWMXMFM4XWGYKLYUMUCNAVCNFSM6AAAAABDMT53OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJSGE3TGNJTGQ.
You are receiving this because you were mentioned.Message ID: @.***>

@Venkateshdodda-MSFT I sent the email, nobody got back to me. please help.


v2: Have in-place toolbar

Story: As a user I want to have easy, visible/UI functions to manipulate objects and/or set their properties
Solution: Have a toolbar with widgets that allow to change things on the object.
Details:

toolbar should/could be placed at the element itself
draw2D does do UI with jQueryish statemanagement, maybe we want something more sustainable

did some POC on this in branch 55-add-element-toolbar .. so far it implements basic only button element options.
I'm going to push this back to prio work on the more preliminary prototyping we talked about in milestones


Feature Request - Chatops Parameters

It'd be super nice if we could do this:
---
name: get-items
pack: mypack
description: "Mypack: Get items"
action_ref: "mypack.get-items"
formats:
  - display: "mypack get all items"
    representation:
      - "mypack get all items"
parameters:
  - with_subitems:
      default: True

Good request, but we have an issue for this feature: https://github.com/StackStorm/st2/issues/1704.
Please include your example or give +1 in that issue instead so we'll prioritize based on "popularity".
Closing this as duplicate.


Changes to make advanced options work

Related to issue: # https://devtopia.esri.com/runtime/kotlin/issues/4644

Description:
Make sure selections made by the user in Advanced options work when a trace is executed
Summary of changes:

Rename currentTraceGraphics to currentTraceGeometryResultGraphics to reflect the usage of the parameter, also don't add starting point graphic to it
Hook up the UI to update the TraceState with the user selected values for name, trace graphic colors and zoom to result
add logic to determine the Name for the trace, update graphic colors and zoom to result

Pre-merge Checklist

a vTest Job for this PR has been run

[ ] link: https://runtime-kotlin.esri.com/view/all/job/vtest/job/toolkit/117/

Unit and/or integration tests have been added to exercise this PR's logic, and the tests are passing:

[ ] Yes
[ ] No

Thanks @shubham7109 ! Merging..


Number of processes not configurable for PyTest

The number of processes for PyTest is hardcoded for both Vagrant and Docker provisioners.
I ran into an issue where my test is validating a user's ability to stop/start/restart a service and these tests had unexpected results.  The issue only exists when more than 1 process is used but I could not alter this through the molecule.yml file as testinfra_args and testinfra_kwargs are not exposed to the molecule configuration file (or it appears that they are not, but maybe it is documented somewhere?) Let me know if I'm missing something or if you believe this is a legitimate issue with no workaround.

There is no way to pass testinfra args/kwargs at the moment. I do agree that you should be able to though. I'll propose a PR with a way to pass them in.

@kireledan Thank you! I wanted to get a sense on whether anyone felt this would fit into the roadmap for Molecule before I started taking a crack at a PR.

Implemented in #198.


Refactor to allow a basic setup without Haskell components

The first commit is a refactor without changing any existing functionality. I have taken care that no behavior changes unless something might have crept in inadvertently.
Other than the refactor, it adds two command line options to install.sh. One for a basic installation without Haskell components and another to specify a repo to install from. I am providing the motivation for both below.
Basic Installation: haskell vim now has pretty good common (non-haskell) settings as well. I want to use the same setup even where I do not use haskell or in setups where installing stack and GHC would take too much space and time even though I won't need them. Now, I can just provide an option to install and have the same setup elsewhere as well. Even non-haskell users can now use haskell-vim-now, maybe we can call it vim-now instead!
Please note that it does not change or break anything for the existing end users.
repo path: I added this mainly for testing so that I could easily specify my git clone as the repo when running install.sh.
The second commit is to avoid confusion about the powerline fonts. I interpreted the message as the fonts have to be installed and configured though it was already installed only to be configured. I made that clear in the message.

I don't like the setup_done function. It's pretty useless. Maybe move it to the end of setup?
@harendra-kumar did you just split setup phases to separate functions? No setup sequence changes, no missing calls or checks?

Thanks @SX91 !

I am sorry, I left the now dead setup() function around which might have caused confusion. I will push a commit to remove that.

It is mostly splitting with a little regrouping. If you see the diff fully expanded the major change you will see is line 95-134 moved to setup_haskell() function in the newer file. You can verify the sequence by comparing these two blocks.

There has been minor change in sequence because of regrouping of similar functionality e.g.

the stack exist check was the first thing in old setup() but now moved to setup_haskell()
ctags exuberance check moved to setup_tools()
git config modification now moved to setup_tools()

Other than that I think pretty much everything is intact. There should be no missing call. I have tested it on my setup and everything seems to be working fine till now.

Yeah, powerline-fonts is not being installed on Mac. But the original message still remains a bit confusing on other platforms. I have code to install powerline fonts on Mac as well. I can either add that or remove the changes I added. I will remove it for now. Maybe we can deal with it separately.

I fixed, rebased and pushed. Removed:

the powerline message changes
removed the setup() function.

@harendra-kumar thanks for the pull request. Sorry it's been almost a month with no response since you submitted it.
This vim config is historically pretty opinionated and meant for Haskell. However after reviewing your changes I like how it separates the install process a little more cleanly. Your command line flag to use it as a non-Haskell config doesn't seem to affect Haskell users so it seems fine.
I'd like to merge it but I have two questions

Can you rebase off master please? There was a change about how we deal with old vs new versions of Slack and this change now conflicts with your PR
How gracefully will the installer handle a bogus value of --repo? Will it proceed and create a broken installation?
Could you add a note in the readme about the new options?

Thanks @begriffs! I completely understand the opinionated part and would not argue with that. The idea was to make it more modular and flexible without affecting the main focus. The changes are supposed to be helpful in general.
I will address your questions and push the changes for review again soon.

rebased off the latest master
Made the --repo error handling more robust:

If the setup script is not found in the repo we will exit. If it is a wrong repo and has a setup script at the expected place then we will fail when the correct functions are not found in the script. If it has correct functions as well then we cannot help.
If the repo specified on the command line does not match the repo in the existing installation we will bail out.

Made the vim plugin install more robust against failures. We will not switch the config until plugins are installed successfully. Therefore preserving the existing config unless we have a new working config. This is something that I encountered when testing, so fixed this as well.

Updated the readme. If it looks cluttered, maybe we can move the advanced install options to another page and just put a pointer to that in the readme? or move them  in some sort of appendix?

I have updated the README and stack install URL, please take a look again.

Great work!
Before merging I'm investigating a strange message on Travis CI:
Error detected while processing /home/travis/.config/haskell-vim-now/.vimrc:
line   89:
E117: Unknown function: plug#begin

This message began appearing a few commits ago on this pull request. It doesn't make the build fail, but I think it probably should have.
To try debugging the problem I cleared Travis' build cache hoping a fresh install would be good, but now it's having even worse problems (probably unrelated to this pull request). https://travis-ci.org/begriffs/haskell-vim-now/builds/144133847

Looks like a network problem, both of them. In the first one perhaps plug did not get installed (that's why plug#begin was not found) and in the second one the output from curl was perhaps empty or truncated (i.e. not having a proper gzip header).

OK the intermittent network problem went away but it is still issuing errors about installing things with vim-plug:
--- Checking ctags' exuberance...
--- Setting git to use fully-pathed vim for messages...
--- Installing vim-plug
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 66089  100 66089    0     0   203k      0 --:--:-- --:--:-- --:--:--  204k
--- Installing plugins using vim-plug...
Error detected while processing /home/travis/.config/haskell-vim-now/.vimrc:
line   89:
E117: Unknown function: plug#begin
line   93:
E492: Not an editor command: Plug 'jgdavey/tslime.vim'
line   94:
E492: Not an editor command: Plug 'Shougo/vimproc.vim', { 'do': 'make' }
line   95:
E492: Not an editor command: Plug 'ervandew/supertab'

-- etc etc

I re-ran the tests on the master branch and it installs the plugins fine, so I think this is specific to the current pull request. Can you look into it?

In one of the later commits I changed the old vim config to be switched only after everything is installed successfully including plugins. But that did not work for plugins because they want the new .vim dir. It was working fine with my test setup because I had a stale .vim symlink already. Sorry for the trouble.

No trouble at all, thanks for your contribution.

If you're feeling adventurous you could file an issue on vim-plug about making the destination directory more configurable.


Prevent excessive log in tests

I had been unhappy with the fact that our go-test output had a lot of debug log messages which obfuscated test results.
I'm finally removeing all those by directing the test log output to io.Discard.
Signed-off-by: Yusuke Kuoka<EMAIL_ADDRESS>

@yxxhero This is ready for review. You now see a lot fewer (or almost no) debug logs mixed in the test result, so that you can easily see which (sub-)test has failed.

@mumoshu LGTM. It's a great job.


Custom field is expecting ID instead of field name

Just opening this again what was talked about in https://github.com/sendgrid/sendgrid-nodejs/issues/953
The problem still persists. You are not able to e.g. create contacts using custom_fields: { field_name: "field_value" }
The solution brought out in the previous issue is to inspect the page with dev tools and look for /field_definitions under Network tab.
Why not include an extra column "Field ID"?

Hello @chanar,
Thank you for raising this issue and pointing to #953. Before I close this one out, I will obtain an internal reference to circle back with you on.
With best regards,
Elmer

Internal Tracking ID: MCFRESH-1034


Added translatable auto acceptance message field

Added translatable auto acceptance message field to PalvelutarjotinEvent.

Created a new proxy model TranslatedPalvelutarjotinEvent that offers a translatable auto acceptance message field for PalvelutarjotinEvent.
Added the new translatable auto acceptance message field to the GraphQL schema.

PT-1400 PT-1433

I first implemented all this without Parler and the implementation was a lot easier! But then I thought that we will need to support the translations sooner or later, probably sooner, so it would make more sense to take care of translation data structure right from the beginning, because then we would avoid painful data migrations. It's up to UI whether it supports the translations or not, but the database and the backend API now does.

[ ] When UI does not support translations yet, I think the API should allow implementation with autoAcceptanceMessage: string. Currently it accepts only via translations list.

The TranslatedPalvelutarjotinEvent proxy model is removed in this alternative approach proposed in PR #247

No proxy model for PalvelutarjotinEvent translations anymore! 👍


fix: logo image

Signed-off-by: Michael Wan<EMAIL_ADDRESS>Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?
Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

LGTM

Codecov Report

Merging #978 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #978   +/-   ##
=======================================
  Coverage   12.94%   12.94%
=======================================
  Files         123      123
  Lines        8314     8314
=======================================
  Hits         1076     1076
  Misses       7142     7142
  Partials       96       96

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 42b5a8c...654155c. Read the comment docs.


ocamlPackages.ocaml_sqlite3: 5.0.2 -> 5.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/ocaml4.13.1-sqlite3/versions.
meta.description for ocamlPackages.ocaml_sqlite3 is: "OCaml bindings to the SQLite 3 database access library"
meta.homepage for ocamlPackages.ocaml_sqlite3 is: "http://mmottl.github.io/sqlite3-ocaml/"
meta.changelog for ocamlPackages.ocaml_sqlite3 is: ""
Updates performed

Version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 5.1.0 with grep in /nix/store/05z2bxglbnbpqqk40k0f499xs7xfd5j4-ocaml4.13.1-sqlite3-5.1.0

found 5.1.0 in filename of file in /nix/store/05z2bxglbnbpqqk40k0f499xs7xfd5j4-ocaml4.13.1-sqlite3-5.1.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
google-drive-ocamlfuse

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/05z2bxglbnbpqqk40k0f499xs7xfd5j4-ocaml4.13.1-sqlite3-5.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ocamlPackages.ocaml_sqlite3 https://github.com/r-ryantm/nixpkgs/archive/41e710b34ea4b9d49cc5191bfba2b5594c8adaf3.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/05z2bxglbnbpqqk40k0f499xs7xfd5j4-ocaml4.13.1-sqlite3-5.1.0
ls -la /nix/store/05z2bxglbnbpqqk40k0f499xs7xfd5j4-ocaml4.13.1-sqlite3-5.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

google-drive-ocamlfuse

7 packages built:

ocamlPackages.caqti-driver-sqlite3
ocamlPackages.eliom
ocamlPackages.google-drive-ocamlfuse
ocamlPackages.ocaml_sqlite3
ocamlPackages.ocsigen-start
ocamlPackages.ocsigen-toolkit
ocamlPackages.ocsigen_server

Maintainer pings
cc @maggesi @vbgl for testing.

@WolfangAukang have you merge right ?

@WolfangAukang have you merge right ?

I don't have the permission to merge. I'm not a committer.

@ofborg eval

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/811


update Patreon links

Work for this issue will begin begin on branch work-liquid-labs/dmd-readme-api/10.


docs: Clarify language selection for new translators.

It looks like folks are accidentally generating requests for new
country-specific languages when they sign up. This change clarifies
the instructions so that we avoid these requests.

Thanks for working on this @alya!  This looks great, but I think the note may benefit from more fancy styling.  We can do something like this:

You can find example code in docs/development/setup-advanced.md like this:
   ```eval_rst
   .. note::
       If you shutdown WSL, after starting it again, you will have to manually start
       the services using ``./tools/wsl/start_services``.

Updated the note format!

Merged, thanks @alya!


Support Transport Parameter exchange

QUIC peers exchange these Transport Parameters.

initial_max_stream_data
initial_max_data
initial_max_stream_id
idle_timeout
truncate_connection_id
max_packet_size

This issue covers only their exchange.

Part of #2345

Done. 71f40486164fdc29a86bd80f0a730e1d6ccbda6c


openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model gpt-4 does not exist or you do not have access to it.

Hi,
I'm trying to use RAGAs library for synthetic test set generation, I do not have access to gpt4. The critic_lllm in TestsetGenerator.with_openai() uses gpt4 by default, so I changed it to gpt3.5. However, it throws the error gpt4 not available.
I've attached the code with the error below. Pls let me know if there's a solution for this. Thank you!
Ragas version: 0.1.2
Python version: 3.9
Code to Reproduce
from ragas.testset.generator import TestsetGenerator
from ragas.testset.evolutions import simple, reasoning, multi_context

# generator with openai models
generator = TestsetGenerator.with_openai(generator_llm = "gpt-3.5-turbo-16k", critic_llm = "gpt-3.5-turbo-16k")

# generate testset
testset = generator.generate_with_langchain_docs(documents, test_size=10, distributions={simple: 0.5, reasoning: 0.25, multi_context: 0.25})

Error trace
openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model gpt-4 does not exist or you do not have access to it. Learn more: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}
If there are ways to generate the test set with open source LLMs, please help me with the same.

Hey @gowrijsuria do you have access to gpt-4 model? Seems like you don't have it. Can you checkout customising test set generation document for using any llm of your choice? https://docs.ragas.io/en/latest/howtos/customisations/bring-your-own-llm-or-embs.html

I have access to gpt3.5 , hence I passed that as the param. However, it doesn't work. Pls check this issue


Bug fixes for regression test generation and OverridesError

DetailedError() did not have a test [fixed]
OverridesError() only partially worked [fixed]
OverridesError() test was incorrect [fixed]
Automatic creation of regression tests missed many decorators [fixed]
README now has instructions for getting generated regression tests

Codecov Report

Merging #45 (f670386) into main (3a5f824) will increase coverage by 0.14%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##             main      #45      +/-   ##
==========================================
+ Coverage   83.63%   83.78%   +0.14%
==========================================
  Files          21       21
  Lines        2952     2979      +27
==========================================
+ Hits         2469     2496      +27
  Misses        316      316
  Partials      167      167

Impacted Files
Coverage Δ

debug.go
88.51% <93.93%> (+0.40%)
:arrow_up:

nject.go
84.23% <100.00%> (+0.07%)
:arrow_up:

match.go
98.11% <0.00%> (+3.77%)
:arrow_up:

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


Add Gnosis over RPCh network

Overview
This Pull Request adds support for Gnosis over RPCh network to the Enkrypt wallet, providing users with enhanced privacy and security when interacting with the Gnosis network.
What is RPCh and the HOPR Network?
RPCh is an RPC provider that operates exclusively via the HOPR network, which is an incentivized mixnet that provides much more privacy than a VPN or even Tor. Thanks to its proof-of-relay mechanisms, mixnode operators are paid for forwarding packets in the decentralized HOPR network, which ensures privacy for both senders and receivers of transactions on the Gnosis network. This is important because RPC providers can see IP addresses and other metadata of users, which can be a liability for both users, wallets, and RPC providers.
Benefits of Adding Gnosis over RPCh Network Support
By integrating Gnosis, a reliable and secure web3 network, with RPCh, we are ensuring that the Enkrypt wallet is not only robust but also offers enhanced privacy for the users. With this Pull Request, Enkrypt users will have a secure and private way to interact with the Gnosis network. Additionally, by supporting RPCh, we are protecting the users against IP address tracking and other metadata-related attacks.
Overall, this Pull Request takes a proactive step towards protecting the users' privacy and ensuring that the Enkrypt wallet remains a trusted and reliable tool for securely managing their crypto assets.

@ItsLuized please make sure there are no commented unused code
Also you can replace the existing Gnosis, Enkrypt will only have one provider per network
If you are making a PR for myetherwallet web, you can have multiple providers per network

hey @kvhnuke!
Thanks for checking out the PR. Will work on your feedback.
I actually intended to have this PR made in our own fork and not make it official yet as we are still polishing things around, so for the time being I will close this one.


updates to multi-cloud-connectivity-volterra

user namespace: deploy LB resources in user namespace
assisted mode: enable assisted mode for AWS TGW Site
unique prefix: use unique prefix for Volterra system resources

@yossi-r

Let's work on it a bit more, make sure we have both assisted and automated working

Assisted mode still not working, don't use yet


v5 and mass closed tickets?

hi there,
I was tracking a bunch of issues:
#1392
#1407
#1433
#1230
#1261
These are many many more have all been "closed" without explanation.
What is the rational for doing this? Is it that v5 is considerably different that these issues are no longer relevant or what??
much appreciated~

Ahh i see #1644
Time to a fresh leaf~

Please submit issues if they're still valid and folliwing the new template, thanks.


Split build and run stages in dockerfile

Split build

Not sure this is required. There is no build step, atleast right now. We only install the deb package, those are anyway difficult to copy from builder.

yep - for now there is no value in this i think so probably we can close?


Figure out the story around how sdk/template and eng/templates/Azure.ServiceTemplate.Template interact

We are adding template files as part of https://github.com/azure/azure-sdk-for-net/issues/24495, but having two templates is going to cause a lot of confusion about which is the source of truth, as well as maintenance issues, etc.
We need a story to merge these two things into one.

cc @chidozieononiwu @weshaggard we use the sdk/template to test the engsys changes.

I would like to combine these that is why @annelo-msft opened this issue but when we do combine, we should ensure we can continue to use it for testing out engsys stuff.

Great, thanks @weshaggard!  When we have time to focus on this, it will be great to work with you on how sdk/template is used for that and make sure we maintain this ability.

One idea - port sdk/template to DPG, and have the output of eng/templates/Azure.ServiceTemplate.Template be identical to sdk/template (is this possible)?  As a validation step when eng/templates/Azure.ServiceTemplate.Template is updated, confirm that no changes between the two have been introduced.

That seems like a good direction to me. As for whether or not it is possible I'm not sure about those particular details. I mostly would like for us to only have one template instead of multiple.

If we combined the two templates:  eng/templates/Azure.ServiceTemplate.Template and sdk\template\Azure.Template as one template sdk\template\Azure.Template, we cannot automatically re-generate the template sdk\template\Azure.Template  from the template itself.

So when we update the combined template sdk\tempate\Azure.Template, we cannot re-generate itself. But I think since we directly update the combined the template, if the updated template has pass mock-testing, it should identify that the updated template is correct, it is not need to use 'dotnet new' to re-generate the template itself.

I was suggesting we merge whatever DPG needs into Azure.Template and have that, for example, generate Azure.Sample in the same directory.


[T2A2][W09-A4] Lee Wan Qing

Ready for review

Good to see that you have started to initiate PRs.  Keep doing it and it will become second nature to you.


MobileNav Doesn't work in next js.

When I use the component Navbar response ok on large screens, but on mobile, when you click on the burger icon, doesn't open the menu. I think the problem is with the Component
I tested the example code at https://www.material-tailwind.com/docs/react/navbar
I probed in Chrome and in Edge.
I Attach images with the problem.

that's all.
I await your response.
best regards

Hi @DavidRamirez92,
Please share the navbar code with me.
Cheers,
Sajad

Sajad, Nice to meet you.
I send you the code Below:
import { useState, useEffect } from "react";
import {
Navbar,
MobileNav,
Typography,
Button,
IconButton,
} from @.***/react";
export default function Test() {
const [openNav, setOpenNav] = useState(false);
useEffect(() => {
window.addEventListener(
"resize",
() => window.innerWidth >= 960 && setOpenNav(false)
);
}, []);
const navList = (

Pages

Account

Blocks

Docs

);
return (

Material Tailwind

{navList}

Buy Now

<IconButton
variant="text"
className="ml-auto h-6 w-6 text-inherit hover:bg-transparent
focus:bg-transparent active:bg-transparent lg:hidden"
ripple={false}
onClick={() => setOpenNav(!openNav)}
>
{openNav ? (

) : (

)}

{navList}

Buy Now

);
}
El vie, 5 ago 2022 a la(s) 06:23, Sajad Ahmad Nawabi (
@.***) escribió:

Hi @DavidRamirez92 https://github.com/DavidRamirez92,
Please share the navbar code with me.
Cheers,
Sajad
—
Reply to this email directly, view it on GitHub
https://github.com/creativetimofficial/material-tailwind/issues/193#issuecomment-1206238643,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO2WUIRGSRO2AWBX3NFFMRDVXTMQZANCNFSM55UMOYYA
.
You are receiving this because you were mentioned.Message ID:
@.***>

When I use the component Navbar response ok on large screens, but on mobile, when you click on the burger icon, doesn't open the menu. I think the problem is with the Component

I have the same problem

Hi guys,
The issue is fixed please update to @material-tailwind/react/v1.2.3.
Cheers,
Sajad

Thank you so much Sajad.
Have a nice day.
El mar, 9 ago 2022 a la(s) 06:25, Sajad Ahmad Nawabi (
@.***) escribió:

Hi guys,
The issue is fixed please update to @material-tailwind/react/v1.2.3.
Cheers,
Sajad
—
Reply to this email directly, view it on GitHub
https://github.com/creativetimofficial/material-tailwind/issues/193#issuecomment-1209135918,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO2WUIX47ZDSHZ3CI64BVZDVYIPZDANCNFSM55UMOYYA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Use  instead of
This is how it was fixed for me

Use  instead of
This is how it was fixed for me

Use Collapse instead of MobileNav
This is how it was fixed for me


Support deep removal of WebApplicationExtension

See issue #462

As the ordering of a WebApplicationExtension is important and you cannot just remove a WebApplicationExtension without potentially breaking functionality I am closing this in favor of directing our customers/developers to deliver their own WebApplicationExtension with the proper ordering in place. Which means effectively that we do not need deep removal.


Fix Fab to create a new venv and install requirements

Virtualenv venv
source venv/bin/activate
pip install -r requirements.txt
(need to add requirements file to tar)

Also make fab for registry

Done in 1.1.2


An option to hide video thumbnails and channel icons

It would be nice with an option to hide all video thumbnails and channel icons all over the site for a less visually distracting browser experience.

Thanks for the suggestion. I'll definitely consider it, but to be honest it's not something I anticipate implementing because I think very few people actually want that.


Query History incorrectly treats source as a required field

QueryHistory assumes that source is never null, however clients are not required to set X-Trino-Source. This prevents lookup for such queries in a multi instance deployment, and prevents the Query History page from working if any rows returned for a search have source = NULL.

Fixed by #381


[BugFix][FlatJson] Fix json write error when schema change

Why I'm doing:
What I'm doing:
Schema change write data will reuse ColumnWriter, JsonWriter doesn't supported, take crash in the DCHECK of append.
move write flat json in finish method
Follow: #48104
Fixes https://github.com/StarRocks/StarRocksTest/issues/8353
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.3
[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

Documentation PRs only:
If you are submitting a PR that adds or changes English documentation and have not
included Chinese documentation, then you can check the box to request GPT to translate the
English doc to Chinese. Please ensure to uncheck the Do not translate box if translation is needed.
The workflow will generate a new PR with the Chinese translation after this PR is merged.

[ ] Yes, translate English markdown files with GPT
[x] Do not translate

@mergify backport branch-3.3


Request to add dlapcevic to sig-policy

I've been working on Cilium scalability, mostly related to network policies:

https://github.com/cilium/cilium/issues/31457
https://github.com/cilium/cilium/issues/33360

I want to and think it would be good to get involved more in the development of these areas.

@squeed @joestringer

cc @cilium/sig-policy currently owns these areas:
$ git grep sig-policy CODEOWNERS
CODEOWNERS:# - @cilium/sig-policy:
CODEOWNERS:/daemon/cmd/policy* @cilium/sig-policy
CODEOWNERS:/Documentation/observability/ @cilium/sig-policy @cilium/docs-structure
CODEOWNERS:/Documentation/security/http.rst @cilium/sig-policy @cilium/docs-structure
CODEOWNERS:/Documentation/security/policy-creation.rst @cilium/sig-policy @cilium/docs-structure
CODEOWNERS:/Documentation/security/policy/ @cilium/sig-policy @cilium/docs-structure
CODEOWNERS:/operator/pkg/networkpolicy @cilium/sig-policy
CODEOWNERS:/pkg/container/bitlpm/ @cilium/ipcache @cilium/sig-policy
CODEOWNERS:/pkg/crypto/ @cilium/sig-hubble @cilium/sig-policy
CODEOWNERS:/pkg/identity @cilium/sig-policy
CODEOWNERS:/pkg/labels @cilium/sig-policy @cilium/api
CODEOWNERS:/pkg/labelsfilter @cilium/sig-policy
CODEOWNERS:/pkg/policy @cilium/sig-policy
CODEOWNERS:/pkg/policy/groups/aws/ @cilium/sig-policy @cilium/aws
CODEOWNERS:/pkg/policy/k8s @cilium/sig-policy
CODEOWNERS:/test/k8s/net_policies.go @cilium/sig-policy @cilium/ci-structure
CODEOWNERS:/test/runtime/net_policies.go @cilium/sig-policy @cilium/ci-structure

Have you been contributing in these areas? It's not immediately apparent to me from your PR submissions: https://github.com/cilium/cilium/pulls?q=is%3Apr+author%3Adlapcevic++is%3Amerged+ . The reason I ask is related to the in-depth knowledge expectations as part of the reviewer requirements for this area. Policy is a particularly tricky aspect of Cilium, so it'd be good to ensure that both (a) we continue to ensure the high quality bar of changes and review in this area, as well as (b) we make sure that there is a path for contributors like yourself to help maintain this code.

You are right. My contributions were mostly CES related.
CES is part of the network policy enforcement system, as is my more recent work of operator managing identities (https://github.com/cilium/cilium/issues/27752).
I agree with you that this is no sufficient evidence, so I would be grateful if you could suggest how I could proceed.

Ah I see where you're coming from. My initial thought when looking at the responsibilities of @cilium/sig-policy is the bread-and-butter of policy enforcement, ranging from policy APIs, the BPF map representation of policy, how policy computation and calculation occurs. You can see the expected responsibilities for this codeowner here. Identity allocation pieces typically do not change much at all, but this team is the best positioned to have the expertise to understand the implications of any changes to identity. Hence pkg/identity currently falls under that group. And indeed while policy relies on the CEP/CES state propagation to ensure correct enforcement, my gut feeling is that the folks in @cilium/sig-k8s or @cilium/sig-scalability tend to be more involved in thinking about the details of CEP/CES.
If you plan on working on direct network policy calculation/computation logic, then I think there's alignment within this codeowner and we can figure out how to support your efforts there. You can get a sense for the sorts of changes you would be expected to review in this list. On the other hand if you're primarily interested in just the allocation pieces, then we probably want to figure out another path.
No codeowners division of responsibilities is perfect, figuring these out is more of an art than a science. We'd like a good mix of expertise and general interest while keeping the door open to new contributors. Primarily these codeowner groups are also taking care of ongoing change within an area, including reviewing others' PRs and improving the implementation. If we anticipate that the identity allocation pieces are likely to continue to change and iterate over time then it might make sense to split the ownership for pkg/identity from @cilium/sig-policy . Splitting up the ownership could involve either creating another codeowner group or alternatively identifying the key codepaths that are related to this and moving it over to a more appropriate existing codeowner (and provide a path for you to help with review in that area too).

No codeowners division of responsibilities is perfect, figuring these out is more of an art than a science. We'd like a good mix of expertise and general interest while keeping the door open to new contributors.
[...]

I personally think this is a problem that can be solved differently. In K8s it was solved with per-directory ownership example. Essentially you contribute to a specific area - for example, the identity package, you get the owner for this directory. Once you gather more coverage across different directories that belong to a specific team, you can join that team. But this would require a whole revamp of current ownership managed by GitHub and probably replacing with prow-based automation.

@dlapcevic Looking at the pull requests implementing https://github.com/cilium/cilium/issues/27752, they all required reviews from cilium/operator (more than cilium/sig-policy). Given the goal of this work stream, it makes sense that the operator code base would be the most impacted. I'm surprised that isn't the team you want to join :slightly_smiling_face:
For reference, cilium/operator is responsible for the following code paths:
$ git grep cilium/operator CODEOWNERS
CODEOWNERS:# - @cilium/operator:
CODEOWNERS:/api/v1/operator/ @cilium/api @cilium/operator
CODEOWNERS:/Documentation/internals/cilium_operator.rst @cilium/operator @cilium/docs-structure
CODEOWNERS:/operator/ @cilium/operator
CODEOWNERS:/pkg/ipam/allocator/clusterpool/ @cilium/sig-ipam @cilium/operator

@pchaigno you're right. I opened up a PR for that, and I'll close this.
https://github.com/cilium/community/pull/141


[Add] devresourc.es

Site URL
https://devresourc.es/
Description of the above provided site
A collection of resources for developers, categorized and crowdsourced. Learn programming, UI inspiration, job boards, images, icons and much more.
Category
Open Source
Sub Category
projects
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[ ] I am willing to work on this issue (optional)

Hey @rupali-codes, may I work on this issue if it's required?


[Feature] Standalone mode of KubeVela model layer

Is your feature request related to a problem? Please describe.
In nutshell, KubeVela is composed by 3 layers:

UI layer: appfile, dashboard, cli;
Model layer: the OAM implementation (appconfig, definitions etc);
Capability layer: the Kubernetes controllers for workload types and trait to work, with a CRD registry to manage their dependencies.

For now, layer 2 and 3 are all designed and installed as a controller in target Kubernetes cluster. This makes implementing the model layer very easy leveraging the Kubernetes control plane.
But the drawback is we can't manage multiple Kubernetes clusters with KubeVela as the centralized system, also, it makes it difficult to deploy KubeVela in environments such as control plane of Azure or Alibaba Cloud where k8s is not thing, hence hosting KubeVela is impossible unless a mini Kubernetes is introduced there (heavily depends on company policy).
Describe the solution you'd like
I'd propose we decouple layer 2 from Kubernetes after v1.0 release, so the platform team could choose to vela install --standalone and run KubeVela model layer in vanilia Docker container or VM. This also makes more sense as we want to support more capability templates such as Terraform etc.
And in order to make this happen, we will also need to make layer 1 decouple from the target cluster as the first step, which can be done even today.

A workaround is of course we can always package a single node k8s as a sidecar for KubeVela core controller ^^

A simple workaround is: move KubeVela core out of K8s cluster, deploy it in standalone mode, and it connects a remote k8s running somewhere else (only works for limited cases).


Added 2 FAN control changes from @deebfeast

Hello, these changes seem they are implemented specifically model NH55RDQ or its variants. The code is not very generic and it doesn't check if the board supports multiple fans or not. Can you refactor the code or maybe the makefile so it checks if the current board supports multiple fans?


http://cdrm-pu-demo-dev.azurewebsites.net gone

The FabrikamFiber test refers to the URL http://cdrm-pu-demo-dev.azurewebsites.net which is no longer available.

Hi @stevecrisci2 ,
May I know the source where it is referred?
Thanks

i uninstalled it, however, it was in the test code.  I recall it would not pass with that url.

Hi @stevecrisci2 ,
We are closing this issue for now. As far as we know we have not referred to this URL in  azuredevopslabs. When you come across the same next time , please share more details.
Thanks