Gutenberg Integration + Typography Tools (Roadmap)

I've been waiting for this moment for a long time. After several months of researching, collaborating, building, testing, and iterating, the G2 Components project is nearing a stage where we can confidently map out the initial integration with Gutenberg!
Working with Global Styles and Design Tools had helped me understand many of the complexities and challenges that come from systemizing a UI layer that could accommodate the expansive and open nature of WordPress and the Gutenberg editor. As such, I believe in the importance of introducing G2 Components to Gutenberg in a way that demonstrates user-facing value. I wanted to provide improvements to the UI experience that end-users could see and feel, rather than a revamped architecture that was superficially invisible.
For the past weeks, I've been collaborating with various designers and developers to refine the project. More importantly, I wanted to make sure that it was going in the right direction. (A big thanks to all of these folks for being supportive and patient with my questions). Based on feedback, we felt like a potential candidate to deliver G2 Components with would be to improve the Typography Tools for Full Site Editing (FSE) and Global Styles.
Today, I've created a rough (publicly available) roadmap using Miro. I've found this medium to be easier to visualize a large scale project (at a high level). For finer-grain task tracking, we could use familiar workflows like Github projects. With that said, I'm planning on using this Miro board as the primary task coordination/planning format. As such, items on this board may change over time (e.g. moved around or relabeled).

Link to the Miro board
For this Integration/Typography Tools project, I've split up the work into 4 key phases:

Prep
Integration
Build
Post Build

Prep

The "Prep" phase contains all of the tasks that prepare G2 for Gutenberg. These tasks involve either cleanup/refactors or resolving critical features (like automatic RTL CSS rendering).
Between the 3 phases, "Prep" is probably the easiest and the shortest. The most crucial part would be to ensure that G2 works correctly with Gutenberg through some initial integration testing.
Initial Integration Testing
All of G2 Component's packages are available publicly on npm. They are updated several times a week, with the latest features and refinements from the project.
To test within Gutenberg, we can add the latest G2 Component packages as dependencies within the Gutenberg repo. Once they're in, we can attempt to use the components in various places in the editor.
All we're doing is making sure the Components and it's systems (e.g. context, styles, substate, etc...) are working as expected within the WordPress/Gutenberg environment.
No pull request will be needed, as we won't be submitting any code into the repository (not yet).
Prep Completion
Once all the tasks are done, and the initial Gutenberg integration tests feel solid, we can move onto the "Integration" phase.
Integration

The "Integration" phase involves migrating all of the packages from the G2 Components repo into the Gutenberg repo. The initial packages would be utils, substate, create-styles,  styles, and context (preferably in that order). These systems should not impact the existing Gutenberg code or UI.
These system packages are smaller and self-contained. The migration will help identify and address any issues early (e.g. issues regarding dependencies, build, or types), which will smoothen the move for the components code.
Package Locations
The G2 system packages would live as dedicated packages within Gutenberg, with a slight adjustment to their names.

@wp-g2/create-styles -> @wordpress/ui-create-styles
@wp-g2/context -> @wordpress/ui-context
@wp-g2/styles -> @wordpress/ui-styles
@wp-g2/substate -> @wordpress/ui-substate
@wp-g2/utils -> @wordpress/ui-utils

Note: There are other system packages in G2 Components right now. The plan is to drop those in favour of using their underlying dependencies directly:

@wp-g2/a11y -> reakit
@wp-g2/animations -> framer-motion
@wp-g2/gestures -> react-use-gesture

The only G2 package that differs from the above-mentioned migration would be @wp-g2/components.
Component Integration
The idea is to move all of the code from @wp-g2/components directly into @wordpress/components.
The G2 code will mostly be separated into clearly marked directories (most likely __next/).
Below is a rough example of what it may look like:
src/
├── button/
│	├── __next/
│	└── index.js
├── card/
│	├── __next/
│	├── (other files)
│	└── index.js
├── hstack/
│	└── index.js
└── etc...

The G2 code is locally scoped to a singular component directory while encapsulating and signifying that it's the "next"/future version of the component.
In this above example, I've included HStack (one of the new layout-based primitive components). It currently doesn't exist within @wordpress/components. For cases like this, we would use the G2 code directly rather than containing it within a __next directory. Any component that is included in this way should be exported with the __experimental prefix, just like any other new UI introduced to the Gutenberg component ecosystem.
The G2 component code can be split into 3 groups:

UI that is brand new (don't exist within @wordpress/components)
UI that can directly replace existing components (current __experimental components)
UI that to live alongside existing components, but in a "dormant state", activated with the "Context/Adapter" strategy

Context/Adapter Strategy
To ensure integration is done incrementally in a controlled manner, we'll be attempting a strategy that involves G2's Context system and "adapters" for the existing @wordpress/components code.
The Adapter
The "adapter" is a tiny layer that can smoothly translate Component props (API) from the current WordPress components to the new G2 components. This ensures that the systems (core and 3rd party, especially 3rd party) can continue to operate with zero modification required in their UI codebases.
The Context System
The "Context System" works like a "network". It's something that allows components to communicate with each other as well as special "areas" created by the system. By "connecting" our newly adapted components to this network, we can send a signal to specific areas to render the new G2 UI - just like flipping a switch!
First Batch
The first batch of components to hit @wordpress/components would be the ones required to build the new Typography Tools feature. This batch includes the lowest level and most fundamental components for the G2 UI layer (such as View and Text).
Splitting the migration of the components into "batches" will allow us to deliver the new Typography Tools faster.
After the necessary code is moved, and the Typography Tools is built, we can continue with the second "batch" to move the remaining G2 component code.
Integration Completion
At this stage, Gutenberg should not look any different. This is because most of the adapted components are still "dormant". They haven't been signalled to switch to their newer G2 UIs yet. However, all of the foundations, plumbing, and materials have been set for us to construct the new Typography Tools in the "build" phase.
Build

The "build" phase involves constructing the new Typography Tools experience for Global Styles / FSE.
One task we have to accomplish is to streamline the mechanics of how the Block Editor hooks bind and render controls. During the design and development process of the new Typography experience, we established a new unified reset/remove interaction that we feel confident. As such, we'll need to create a systematic way for these interactions to be handled to benefit both the Typography Tools as well as future Design Tools.
Next, we'll designate this new Typography Tools area as "safe for G2 UI" using the Context System.
With those pieces in place, we can start construction on the new Typography tools. (Finally... Finally! We can build something, haha!).
Build Completion
Once the new Typography experience is created, and we're confident it's working correctly with Global Styles and the post editor (with zero regressions caused by G2), we can move onto the final phase, "post-build".
Post Build

The "post build" phase involves us moving the second (and final) patch of components over from G2 to Gutenberg.
That's it!
Next
With the 4 phases completed, the G2 components project would be fully integrated with @wordpress/components and we'll have a new and improved Typography Tools experience.
This is only the beginning! Integration and Typography tools are the first of many steps in systemizing and improving the UI experience for Gutenberg and WordPress. There's still a lot of work ahead of us. From improving the documentation experience to providing a fully-featured Figma Design System experience.
Contributing
I'm 100% open to critical feedback on this outline. If you have any ideas of how we can improve things or spot any gaps that I may be missing, please let me know!
I'm going to start by creating tasks, projects, and milestones for the 4 phases in the respective repositories (first in the current G2 repo followed by Gutenberg). From there, I will be (very) actively coordinating, developing, and reviewing updates.
I recognize that the G2 Component project is inherently complex. It's bespoke and innovative systems are sculpted by the unique requirements of Gutenberg and WordPress. As such, please feel free to reach out to me anytime if you have questions on how things work and how things fit together. For the past weeks, I've been streaming (almost) daily on Twitch. I'm happy to answer questions during the live stream as well!
Thank you all for your time!

Hi @ItsJonQ, thank you for this detailed post.
Regarding dates, What is the planned date to have Build Completion phase ready?
WordPress 5.7 is expected to be released in March 2021 (and the current plan is to include Global Styles in WordPress 5.7), according to what happened in 5.6 the first beta is released two months before which means global styles should be ready and in core in January. When things are in the core they already need to be stabilized tested and be extensible by other WordPress plugins. To allow time to test fix, bugs and make things extensible it seems we would need to have the global styles ready including the g2 typography tools in mid-December.
Is the timeline ok or should we make some changes to the plan?
On the list of components required by typography tools, we are not including wp.components.FontSizePicker and wp.blockEditor.LineHeightControl. I guess these components will also be "migrated" to g2 components?
Currently, the only typography tools part of a WordPress release are Font Size picker and Line Height. So I guess a possible way to go if we are short on time would be to include the __next versions of all components used by wp.components.FontSizePicker and wp.blockEditor.LineHeightControl as experimental. Only migrate the components wp.components.FontSizePicker and wp.blockEditor.LineHeightContro to g2 using the new experimental g2 components. The migration of these components could happen directly without having experimental/__next versions of them first. They are not complex components we would just need to make sure all the props combinations we can pass to them render correctly when using g2 components.
Besides typography tools, global styles will have color tools, a color palette editor, and UI to navigate between settings of the different blocks.
So the plan is to have global styles with only typography tools using g2 and the other tools using the current UI components? cc: @shaunandrews


Graphics glitch when validation state changes

Pretty small bug, but it looks a little funky.
Easy workaround of just dragging on one of the nodes.

I don't like this jumpy nodes and large red notification area. It breaks the elegance and simplicity of the framework. I will find the time on the weekend and re-do it properly (with tool-tips and highlighted connection sockets).

I agree, the jumpy nodes can be really annoying (I had several cases where I found a node behind another node because the validation state changed). plus there are definitely some graphical bugs.

For me it'd be nice to be able to click on the error tooltip after it comes up and click on links in the error message.
That'd be useful because I'm looking to add "quickfixes" to errors, so people can click a button to fix it immediately for simple errors.


How do I get a completely minified version of this package?

I am using jsdlvr and unpkg as the platform I'm building on doesn't allow me to perform an npm install therefore I am having to drop in packages as loaded scripts into the HTML head.

Loading static versions, not dynamic ones. At least trying.

Unfortunately, when I try to drop in "index.min.js"<EMAIL_ADDRESS>I don't have WalletLinkProvider or exports as a package.
How do I get a version of this library that is completely contained and minified for production use that I statically load into an html head?
Thanks,

Yep! Need help or just asking?

@tayyabmh yeah, I'm also trying to integrate walletlink in a static html site. I'm facing issues with exports. I was wondering, were you able to make it work? I'd really appreciate, if you could please share any info regarding that.
Thank you

Hey Junaid, what worked for me was to start a blank project in a separate directory, do an npm install of the walletlink node module, and then use browserify to get an outputted bundle file. I included that static bundle file into my static html project and it ended up working for me.
Let me know if that works for you, or if you need more help.
https://browserify.org

Listen to my words !some hack signed me up on this ! I’m not a programmer and I’m tired of being hacked by you all ! I have a computer but I have never done any of the stuff you all ask me to do and I won’t do it
Sent from ME
On Tuesday, September 28, 2021, 9:44 AM, tayyabmh @.***> wrote:
Hey Junaid, what worked for me was to start a blank project in a separate directory, do an npm install of the walletlink node module, and then use browserify to get an outputted bundle file. I included that static bundle file into my static html project and it ended up working for me.
Let me know if that works for you, or if you need more help.
https://browserify.org
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Thank you very much for the help!

https://whop.com/walletlink.js
Spent a while on this


Change MSS Clamp IP hook chain type

NetFilter doesn't support post-routing IP hook for route chain type check [1], this PR moves MSS Clamp rules to post-routing IP hook for filter chain type.
[1]
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

cc @sridhargaddam

e2e tests are red, I must have missed something ...

Are there any migration concerns with prior SUBMARINER-POSTROUTING MSS
clamp rule  entries, ie do they need to be cleaned up?

Are there any migration concerns with prior SUBMARINER-POSTROUTING MSS clamp rule entries, ie do they need to be cleaned up?

If upgrading submariner version x to version x+1 means that we uninstall version x components before installing version x+1 , I guess it should be OK, otherwise, we need to delete the orphan iptablse rules under SUBMARINER-POSTROUTING chain.

Are there any migration concerns with prior SUBMARINER-POSTROUTING MSS clamp rule entries, ie do they need to be cleaned up?

If upgrading submariner version x to version x+1 means that we uninstall version x components before installing version x+1 , I guess it should be OK, otherwise, we need to delete the orphan iptablse rules under SUBMARINER-POSTROUTING chain.
@sridhargaddam , any thoughts?

For subctl upgrade, we don't uninstall - we just update the operator deployment which will restart the pod. I think a similar thing is done with ACM. We'd have to handle any SUBMARINER-POSTROUTING on pod restart. I'm not sure how critical that is.

I don't think it's critical (we'll have additional iptables rules that also clamp the MSS),
but it's better to handle it as part of this change.
In the meantime, will mark the PR as draft.

Also currently the user can force tcp-mss clamp to a specific value by annotating submariner.io/tcp-clamp-mss=  in GW node this won't work if rules are under SUBMARINER-OUTPUT chain.


[Feature] Please add RTL-aware style utility props

**Is your feature request related to a problem?  Yes, I would like my components to automatically layout RTL.
Describe the solution you'd like   Additional utility props that are based on the direction (like paddingStart as an alternative to paddingLeft).   From chakra-ui:

Style prop
Replace with
Description

paddingLeft, pl
paddingStart, ps
padding in start direction

paddingRight, pr
paddingEnd, pe
padding in end direction

marginLeft, ml
marginStart, ms
margin in start direction

marginRight, mr
marginEnd, me
margin in end direction

roundedLeft, borderLeftRadius
roundedStart, borderStartRadius
rounded borders in start direction

roundedRight, borderRightRadius
roundedEnd, borderEndRadius
rounded borders in end direction

roundedTopLeft, borderTopLeftRadius
roundedTopStart, borderTopStartRadius
rounded borders in top start direction

roundedTopRight, borderTopRightRadius
roundedTopEnd, borderTopEndRadius
rounded borders in top end direction

roundedBottomLeft, borderBottomLeftRadius
roundedBottomStart, borderBottomStartRadius
rounded borders in bottom start direction

roundedBottomRight, borderBottomRightRadius
roundedBottomEnd, borderBottomEndRadius
rounded borders in bottom end direction

borderLeft
borderStart, borderInlineStart
border width in start direction

borderRight
borderEnd, borderInlineEnd
border width in end direction

left
insetStart,
horizontal position in start direction

right
insetEnd,
horizontal position in end direction

(source - https://chakra-ui.com/docs/features/rtl-support )
Describe alternatives you've considered
Without directional aware utility props, i need to manually tweak styles everywhere.   With directional aware props,  there would be no custom direction logic.
Additional context
Thanks for your considerations.

hmmm, maybe react-native already handles this by reversing left to right styles...so this is not needed.   sorry new to react-native.


[Review] add rrule for sparse idot

I'm confused, is this PR ready or not? If it's ready then why there are some commented codes here.

Yes, this PR is ready and I have deleted unrelated codes.

Looks good in general. 🎉


Express - per request data attached by middleware

I really like the idea of this project and I'm evaluating if it would be a good fit for our existing Express API/React UI, however, from the docs it is not clear to me how to handle properties attached to the Express request object by a middleware.
In our project we parse out headers/cookies in our Auth middleware and attach a user object to request like this:
    req.user = {
        cid: claims.cid,
        shopperId: claims.shopperId,
        plid: claims.plid,
        isEmployeeAccount,
        currency: req.cookies.currency,
        market: req.cookies.market,
    };

These values are something that the client code doesn't need to be aware of at all for the most part, but they are obviously super important on the server. What is the ts-rest way to handle this?
Thank you all in advance for your help!

@msikora78 I'd also be keen to see how to get ts-rest to be aware of custom properties added to the request by middleware...


RFP - camotics

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts with 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL : https://camotics.org/
Direct download URL for the software / installer : https://camotics.org/builds/release/windows-10-64bit/camotics_1.2.0_AMD64.exe
Software summary / short description: With CAMotics, you can simulate 3-axis GCode programs for CNCs and visualize the results in 3D.

Status: Review
https://community.chocolatey.org/packages/camotics

Any maintainers interested?

Package was approved: https://community.chocolatey.org/packages/camotics


[PLUGIN] LaTeX/KaTeX support

Is this a unique plugin request?

[X] I have checked "open" AND "closed" issues and this is not a duplicate

Proposed Plugin Solution
Ability to write mathematical symbols in LaTeX/KaTeX.
Screenshots
No response
Do you want to work on this issue?
No
If "yes" to the above, please explain how you would technically implement this (issue will not be assigned if this is skipped)
No response

In Roadmap 🔥


I would like to know how to use the enchanted sword.

I succeeded in implementing an automated bot, but it does not synthesize an enchanted sword

solve a problem


How to simulate statusCode?

I have swagger defenition in json format:
....
"responses": {
"201": {
"description": "unexpected error"
}
...
But anyway i get statusCode 200 in response, how to simulate another one?

+1


Tracking issue for altering table schema

Currently we have not yet fully implemented the procedure of altering the schema of a table, which is necessary to support things like SQL DDL, opentsdb protocol.
This is a tracking issue for implementing a MVP (minimal viable product) for altering table schema, which allows:

add a new column to the table
remove an existing value column (not the column in primary key index or time index) from the table

Here is a list of tasks need to be done

[x] #277 @v0y4g3r

Also need to maintain state of altering (maybe stores the new schema in the state)

[x] #278 @evenyag
[x] #281 @killme2008

[x] #282 @killme2008

[x] #284 @evenyag
[x] Remove column_null_mask in MutationExtra @evenyag  #314
[x] #285 @evenyag
[ ] #286 @v0y4g3r

retries unfinished schema altering, maybe done in opening, writing or before altering the table

[x] Error handling for altering region
[x] #279 @killme2008
[x] #283 @killme2008

since the datanode takes care of these jobs

[x] Tests

[x] Test the manifest has metadata after last WAL entry @killme2008
[x] Implement MockRegion::alter() #287

Issues

[x] #364

I will close this issue as the error handling part #286 is related to the procedure framework.


Add option for image tests to fail if no cloud credentials are found

In CI we should already have appropriate credentials for AWS, Azure and OpenStack but based on this comment https://github.com/osbuild/osbuild-composer/pull/880#issuecomment-662911028 I see that the image tests for AWS and OpenStack still fall back to qemu.
I propose a command line option which will cause the tests to fail instead of falling back to qemu. That would be enabled in CI and will help us ensure testing is done in the cloud while also revealing any changes around authentication and credentials.
@ondrejbudai any comments ?

The current state
AWS
Is tested by /test/image-tests/aws.sh, this method uses composer-cli and osbuild-composer to do the upload. It isn't 100% predictable though because it builds the image with the ever-changing updates repository.
Azure
Is tested by image tests. It doesn't use the customer way as composer-cli and osbuild-composer is not used. It's reliable though because the manifests are fixed and don't use updates.
As you can see, both cloud providers are covered in some way but I agree that having two different ways of testing the image is confusing.
The possible future
We discussed this with @teg, I hope I remember the details well.
Testing the cloud integration
We would like to move testing of the actual images out of osbuild-composer as much as possible. We can just test that the manifest isn't changing and rely on manifestdb to test that osbuild actually builds the proper image.
However, we need to test the integration with cloud APIs in osbuild-composer, so some image builds must be done here. To properly test the integration of all parts, this should use the current AWS approach - use composer-cli and osbuild-composer to build and upload the image. Then, these tests should use awscli or azurecli to create a vm and test if it can be booted.
This is very similar to how customers are using our software.
Testing the images
manifestdb should be able to build images from well-defined manifests and test if they're booting. This, of course, means that we have to test them inside their target environment. Therefore, for ami image type we need to test if they boot inside EC2.
The workflow is that manifestdb builds the image and then uploads it somehow to the cloud (composer cannot be used as it cannot take a manifest as an input, some code can be shared though) and boots it there.
This should be very reliable as the manifest is fixed and the image is not changing all the time unpredictably.

I agree with @ondrejbudai, this is the plan. However, until we have manifestdb up and running, let's not block on that. I also think having a commandline switch which would fail on missing credentials makes sense for CI. Maybe flip it around though, require them by default but have a switch that uses the fallback for local testing.


Delete descriptions of domain whitelabel on ips.md

These lines may have been only copied from domains.md.

Thanks for merging!


Add option to disallowEmptyBlocks to allow blocks with comments

https://github.com/jscs-dev/node-jscs/blob/master/lib/rules/disallow-empty-blocks.js
I'd like this to be allowed:
if (foo) {
  ...
} else if (bar) {
  // We shouldn't do anything here because of ...
} else {
  ...
}

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25336551-add-option-to-disallowemptyblocks-to-allow-blocks-with-comments?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F281640&utm_medium=issues&utm_source=github).

Thanks for contributing! Great idea.
A new rule value to support this would be allExcept: ['comments'].
Would you like to give the implementation a shot? We could use the help.

I've had a go at this - a stumbling block I've run into is that the parse doesn't seem to give an if-block's node a body if that body consists only of a comment.

@faceleg Yeah I think it would be empty - although comments aren't aren't in the tree in that way - maybe look at some other rules dealing with comments (like https://github.com/jscs-dev/node-jscs/blob/master/lib/rules/require-padding-newlines-before-line-comments.js which iterates over comments or https://github.com/jscs-dev/node-jscs/blob/master/lib/rules/maximum-line-length.js#L117 which checks if an option is there to iterate over comments)

@hzoo thanks this is very helpful.

yay, thanks


Enable GitHub logins

Also refactors the current facebook login to be more generic. Should be a fairly simple case of adding any more oath providers now

Can one of the admins verify this patch?

The old way used email addresses, So I have kept it working like this, I would suggest basing it from the ID instead though.
Thoughts ?

If we want to incorporate more social logins it might be a good idea to have a look at SocialConnect. That might make it easier to use different connectors without having to worry about keeping the API up-to-date ourselfs. There‘s also HybridAuth, but from what I‘ve seen it‘s not that actively developed anymore...

Additionally using multiple logins might make it necessary to add a new DB-table to connect users and their different logins....

Yeah agreed. Which would use the I'd instead of the email. Wasn't sure if there was a reason email was used I just didn't know hence keeping it.
Happy to move this to being Id based so we know where they came from.

100% agree. Update this pr then to make it I'd based and forget about the email ?

ok to test

We'd need a complete rewrite IMHO of the login-mechanism. That should contain

Move from one user/login per account to multiple users/logins per account
Implement login using a 3rd party auth-provider. (So we don't need to keep track of the different implementations) - I'D recommend SocialAuth but any other is fine

Before we do that I'D not recommend adding more login-mechanisms. After we did that implementing more is a matter of adding a new config-part.

Agreed with the multiple logins per account. It's a fairly large change though and will effect all of the current ones.
Currently (after changes in this pr)  it's only a small case of adding config and mapping the resulting array which is different. Not sure I see the benifits of using a third party in this case as oauth is a standard.

Safe to close this PR?

Personally I think GitHub is a better login option than Facebook. This follows the existing way of doing things. But it would be better long term to replace the existing way with a library.
Would need composer to be sorted to allow this

Closing this out for now, I'd be happy to revisit adding oauth providers once we can refactor existing code out to a library instead of our own code.


feat: demonstrate migrate standalone to single-node

What's changed and what's your intention?
See https://github.com/risingwavelabs/risingwave/pull/15611 for changes on kernel side. In short, #15611 will deprecate the existing standalone mode and use single-mode for both community user's deployment and cloud deployment.
This PR must NOT merge before #15611 get merged.
Checklist

[ ] I have written the necessary docs and comments
[ ] I have added necessary unit tests and integration tests

Refer to a related PR or issue link (optional)

Is this still needed?

Is this still needed?

I don't know. I assume it isn't.

make generate-yaml generate-test-yaml generate huge changes 🥵20aa5fa5125e0d5498ae71e2b3e3ccaa558720b2 @arkbriar Do you know how to deal with this?


Fixed #35261 -- Corrected Media JS example of object-based paths in docs.

Replaced the rel attribute on the <script> tag, according to MDN the attr is only valid for <link> tags, used a valid attribute (defer) to illustrate the use case for this class.
Relevant links:
Ticket 35261
Forum discussion 28470 - Media Path as objects

@leandrodesouzadev Thanks :+1: Welcome aboard :boat:

There's also a open conversation on ticket/forum about an possible addition of a more "wider" example than the one we currently have. Altough we don't have a consensus about adding it or not. It will be good to also have your opinion on it.
Cheers.


Cli params

R: @jeffposnick @addyosmani
This adds a very naive approach for add cli params for swbuild for generate:sw.
Will add manifest in PR once this lands.
Main concern is that some flags, while they'll be past through, I'm not sure the sane way to input them, for example:
  --dontCacheBustUrlsMatching /./
  --ignoreUrlParametersMatching [/^example/, /^other/]
  --navigateFallbackWhitelist [/^\/guide\//, /^\/lolz\//]
  --staticFileGlobs ['**/*.{html,js,css}']
  --modifyUrlPrefix {'/styles': '/static/styles','/page': '/pages/page'}
  --runtimeCaching [{urlPattern: /^https:\/\/example\.com\/api/,handler: 'cacheFirst'}]
  --dynamicUrlToDependencies { '/template/url1': ['page-1.html', 'index.html'], '/template/url2': ['page-2.html', 'index.html'],}

But is this a common use case / something users of sw-precache actually did?

The sw-precache CLI attempted to do some massaging of the strings passed in as flags, like wrapping things that needed to be arrays in a [], and in some cases, converting strings to corresponding RegExp objects:
https://github.com/GoogleChrome/sw-precache/blob/master/cli.js#L67
This code is really unpleasant. If the use case worked out really well for developers, I'd say it was worth trying to support it in workbox-cli, but command line parsing edge cases were a source of frustration for developers and a maintenance burden.
I think you could get away with supporting an extremely minimal number of parameters passed via the CLI, and make it clear that the robust way to configure workbox-cli is to use an external configuration file. I know that we support a JSON config file right now, but adding in support for a JS config file by reading in its module.exports would be a nice addition, since there's no native support in JSON for RegExp objects.
I'd see if you could get away with globDirectory and staticFileGlobs (and maybe a config option to point to a configuration file), and then if someone asks for additional ones, evaluate that on a case-by-case basis.

I think you could get away with supporting an extremely minimal number of parameters passed via the CLI, and make it clear that the robust way to configure workbox-cli is to use an external configuration file

👍

I'd see if you could get away with globDirectory and staticFileGlobs (and maybe a config option to point to a configuration file), and then if someone asks for additional ones, evaluate that on a case-by-case basis.

This sounds reasonable to me. As much as possible, I'd love to avoid us having to maintain input sanitization for what will probably end up being relatively complex structured input. Using config for that will probably be cleaner for both users and code health.

Is this ready for review, or are you still experimenting?

If you could give it another review I'd be very greatful


VMClone create mutator: Don't mutate when there is no need

What this PR does
Before this PR:
Currently, the VMClone create mutator creates a JSON patch to replace the admitted object's spec even when there is no need to replace it (spec.target is fully set).
After this PR:
VMClone create mutator does not add a JSON patch to the AdmissionResponse in case there is no need to mutate the object.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[X] PR: The PR description is expressive enough and will help future contributors
[X] Code: Write code that humans can understand and Keep it simple
[X] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

Change: Answered @acardace's comment.

/approve


preload

Page: https://id.react.dev/reference/react-dom/preload

i would like to translate this page @resir014

@andriawan all yours!


Update free-courses-en.md

What does this PR do?
Add resources to the courses repo and have added the a course for git for professionals from freecodecamp.
For resources
Why is this valuable (or not)?
This course was valuable since it provides more additional information for the people who have atleast the basic knowledge of git and github.
How do we know it's really free?
The organisation which provides the course is very famous for providing free courses.
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[ ] Read our contributing guidelines.
[ ] Search for duplicates.
[ ] Include author(s) and platform where appropriate.
[ ] Put lists in alphabetical order, correct spacing.
[ ] Add needed indications (PDF, access notes, under construction).
[ ] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

Thanks, and welcome to free-programming-books!


stream settings: Fix a few bugs in weekly traffic calculation.

@rishig how carefully have you tested this?  The logic lgtm.

Nothing beyond trying to create a new stream in the dev environment (though that's broken for independent reasons: #10030).

Might make sense to just merge the first 3 commits, and discard the (more tricky) last two.

I merged the first 3 commits, and punted the rest to a branch that's partial work on #10030.


Props to authors

A plug for curl on Go Daddy Insider blog. Thanks for all the hard work!
http://inside.godaddy.com/optimal-user-experience-non-blocking-pages/

Awesome @asilvas!  I'm going to tweet this in the morning!  :)
Cheers!
-- John

Thanks @asilvas, we really appreciate it!


get_exe_path is a bit noisy + question

I'm getting a lot of this message (shown below) in my script, every time I call nlmod.util.get_exe_path(). When I pass a version_tag, it still logs messages. Maybe DEBUG level logging is sufficient, or maybe this message isn't very interesting?
INFO:nlmod.util.get_flopy_bin_directories:The version of the executables will not be checked, because the `version_tag` is not passed to `get_flopy_bin_directories()`.

Also a question, I just want to use the modflow binaries downloaded using flopy, how do I get nlmod to find that file? The binaries are available on my path so typing mf6 in my terminal gets me the right mf6 version. From my environment (where nlmod does not have any binaries downloaded), nlmod.util.get_exe_path() is now preferring its own binary directory in different environments instead of the flopy directory that's included in my PATH environment variable. I thought maybe this had to do with editable installs in different environments, but it also found the binaries in an environment where I installed nlmod with pip install ..
Chances are fairly large that I've just messed up my environments too much, but I wanted to check here whether anyone else has observed similar behavior?
Steps to maybe reproduce:

Download flopy binaries using get-modflow :flopy
Add flopy bin directory to PATH
Install nlmod in two Python environments
Download binaries in one Python environment
Activate the other Python environment.
Start python and import nlmod to run nlmod.util.get_exe_path("mf6").
Which mf6 is returned?

PATH is not considered here

Wait, this was not completely true. I added the following conditional as well:
    if nlmod_bindir in flopy_bindirs:
        return nlmod_bindir

    if flopy_bindirs:
        # Get most recent directory
        return flopy_bindirs[-1]

    # Else download the executables
    if download_if_not_found:

Alright, I understand it better now :).

Good point on lowering the debug level! Plus, maybe we should change a default value to get_exe_path(.., version_tag="latest").

This sounds logical to me, and is more explicit.
As for your question:

Why did you perform step 4?

I was curious whether there were new binaries available in a certain environment so I quickly used nlmod functions to download the latest ones for that environment. Then in the other environment I was running some models using the flopy binaries, but using nlmod.get_exe_path("mf6") pointed to the binaries from that first nlmod environment, which I did not expect.

It doesn't discriminate against different environments.

I thought environments had be respected also for the binaries, but I understand now it just plucks the most recent location from the flopy metadata JSON file (given no binaries were installed in the current active environment)? So the philosophy is more along the lines, "you asked for a specific version, so I'll give you one that matches, regardless of where it's located".
The one worry I have is that nlmod.util.get_exe_path() without a version tag (and no binaries installed in your current nlmod environment) just gives you the most recent mf6 that was installed. But I guess being explicit in the version you want, or always downloading binaries into your current environment is good modeling practice.
And if I want to override that behavior and find a specific binary, I can get nlmod.get_exe_path() to find my flopy binaries instead of any nlmod ones by passing a bindir.

The one worry I have is that nlmod.util.get_exe_path() without a version tag (and no binaries installed in your current nlmod environment) just gives you the most recent mf6 that was installed. But I guess being explicit in the version you want, or always downloading binaries into your current environment is good modeling practice.

What is you view on:

For best reproducibility we should indeed pin the mf versions. Should we alter the examples such that we explicitly select mf versions? An argument against is that those mf versions seem to just get more stable and remain backward compatible, if it is not a problem now, there is not need to solve it.
Should we introduce a default version_tag in ./nlmod/version.py and we update it in nlmod with every version bump of nlmod as we go? This would help creating more reproducible results without bothering the user. All they need to do is pin the version of nlmod, which was already needed.
Alternatively, we push the user to using the latest version get_exe_path(.., version_tag="latest"), where ever it may be installed on the system. We assume newer is better and this way the user is guaranteed to use the latest.

An additional question to all:

Instead of generating a path for the executable, I would like only the attributes version_tag and repo to be stored in the model_ds. The path to the executable+downloading happens when running the simulation. The keeps the to_modelds() command a bit leaner, only stores the information that affects the outcome. This would make model_ds a bit more transferrable.

I'm for defaulting to "latest" and documenting that it is a good idea to think about pinning mf6 versions for projects. I think pinning versions in nlmod will be a bit too annoying in development. It would be nice to be able to easily figure out what version_tag "latest" corresponds to, and/or which version of mf6 is contained within a specific version tag.

Instead of generating a path for the executable, I would like only the attributes version_tag and repo to be stored in the model_ds. The path to the executable+downloading happens when running the simulation. The keeps the to_modelds() command a bit leaner, only stores the information that affects the outcome. This would make model_ds a bit more transferrable.

I do like seeing the path in my model dataset, that gives me confidence that it's using the right binary to run the model. Maybe that's old fashioned thinking though? I'm fine with adding repo/version tag to make it more transferable though, as long as I don't have to type more :innocent: .

So that makes it 1 vs. 1 ;)

Team full path
Team version_tag+repo

1
1

@OnnoEbbens, @rubencalje would you like to cast a vote?
I don't think we should do both as they can get out of sync.

I'd be happy to switch my vote if nlmod.util.get_exe_path("mf6", ds=ds) gives me the path to an executable :innocent:
Also it would be nice to quickly extract the mf6 version from some version_tag: nlmod.util.get_mf6_version(version_tag="latest")?

BTW, I lowered the log level to DEBUG in https://github.com/gwmod/nlmod/pull/360/commits/45c25be966c59fd124dfe7261e10db660a845023. Leaving this issue open for the other discussion on ds.attrs


MLVPN can't use more than 2 ports at the same time?

Hello everyone!
Didn't find an answer in the documentation. Can I have more than 2 connections to the server at the same time?
[link1]
bindhost = "<IP_ADDRESS>"
bindport = 6001

[link2]
bindhost = "<IP_ADDRESS>"
bindport = 6002

[link3]
bindhost "<IP_ADDRESS>"
bindport = 6003

With this configuration, the server only listens on ports 6001 and 6002.
In the logs I see this:
mlvpn[64523]: new password set
mlvpn[64523]: link1 tunnel added
mlvpn[64523]: link2 tunnel added
mlvpn[64523]: link3 tunnel added
mlvpn[64523]: created interface `mlvpn0'
mlvpn[64523]: link1 bind to <IP_ADDRESS>
mlvpn[64523]: link2 bind to <IP_ADDRESS>
mlvpn[64523]: link2 new connection -> <IP_ADDRESS>:25895
mlvpn[64523]: link2 authenticated
mlvpn[64523]: link1 new connection -> <IP_ADDRESS>:10636
mlvpn[64523]: link1 authenticated

In the logs I see
link3 getaddrinfo(,0.0.0) failed: Unknown error

bindhost "<IP_ADDRESS>"
bindport = 6003

Missing =

You have to be careful with "<IP_ADDRESS>", as mlvpn won't really know what ip address to use to output UDP packets, in case you have source routing enabled. You should specifiy the IP address explicitly

Missing =

Thank you for your reply. I corrected my typo, but I guess that's not the point.
Now my config is like this
[link1]
bindhost = "111.222.333.444"
bindport = 6001

[link2]
bindhost = "111.222.333.444"
bindport = 6002

[link3]
bindport = "111.222.333.444"
bindport = 6003

And an error in the syslog
mlvpn[7070]: link3 getaddrinfo(,5.188) failed: Unknown error


The Docker script ntfy.sh should perhaps be renamed to ntfy, as the dot in the Docker name makes it invalid.

The Docker script ntfy.sh should perhaps be renamed to ntfy, as the dot in the Docker name makes it invalid.

Fixed in #207


PENV-386 api tests get JetDrops by JetID

- What I did
integration tests for endpoint /jets/{jet-id}/jetdrops
- How I did it
- How to verify it
- Description for the changelog

Codecov Report

Merging #105 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
+ Coverage   74.72%   74.76%   +0.03%
==========================================
  Files          46       46
  Lines        2928     2932       +4
==========================================
+ Hits         2188     2192       +4
  Misses        595      595
  Partials      145      145

Impacted Files
Coverage Δ

testutils/generators.go
93.72% <ø> (ø)

test/api/apiwrapper.go
100.00% <100.00%> (ø)

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 732c1fd...523f5df. Read the comment docs.


Add: Feature Erosion Filter + Dashboard Sync + Styles

Fixes #35
Add a filter for erosion

Please squash the commits and rebase.


The limit of the number of generated functions?

I meet a weird situation:
My code with GG.jl works fine as long as I only generated around < 400 functions using mk_functions.
When the number of total functions generated reaches a fewer than 400, I see this error:
julia: /buildworker/worker/package_linux64/build/src/codegen.cpp:2770: jl_cgval_t emit_invoke(jl_codectx_t&, jl_expr_t*, jl_value_t*): Assertion `(((jl_value_t*)(((jl_taggedvalue_t*)((char*)(mi) - sizeof(jl_taggedvalue_t)))->header & ~(uintptr_t)15))==(jl_value_t*)(jl_method_instance_type))' failed.

signal (6): Aborted
in expression starting at /afs/inf.ed.ac.uk/user/s16/s1672897/projects/bayesian_symbolic/notebooks/revamp_dev.jl:132
gsignal at /lib64/libc.so.6 (unknown line)
abort at /lib64/libc.so.6 (unknown line)
__assert_fail_base at /lib64/libc.so.6 (unknown line)
__assert_fail at /lib64/libc.so.6 (unknown line)
emit_invoke at /buildworker/worker/package_linux64/build/src/codegen.cpp:2770
emit_expr at /buildworker/worker/package_linux64/build/src/codegen.cpp:3671
emit_ssaval_assign at /buildworker/worker/package_linux64/build/src/codegen.cpp:3339
...

(Just copying-pasting a few lines in the head of the error message; the complete version is a bit long.)
Is this a known issue of GG.jl or Julia?

It seems to be a Julia bug: https://github.com/JuliaLang/julia/issues/35580
I'd suggest your slightly changing your implementation accordingly, or you can provide me an MME so that I can give your advice about how-to stuffs.

Thanks for the pointer. I checked related issues a bit and believe the MWE from this issue is same as my setting.
In short, I generate random expressions and want to evaluate them on some inputs.

I'd suspect such an issue occurs due to overflows occurred in c part, because GG extensively uses of type level things and is likely to hit some boundaries.
You might break your expressions into smaller parts and then runtime-generate them.

I feel what you propose here can potentially alleviate the issue.
In fact, when I trying to get a MWE from my side, I found that I need to use a much larger number of expressions to fail GG.jl, if the epxression themselves are small:
using GeneralizedGenerated: mk_function

module GeneratedFunctions end

function rand_ex()
    u = rand()
    c = randn()
    if u < 0.5
        return :(m1 + m2 + r² + $c)
    else
        return :(m1 * m2 / r² * $c)
    end
end

function gen_f_mkfunc(ex)
    return mk_function(GeneratedFunctions, :((m1, m2, r²) -> $ex))
end

function main(N::Int)
    for i in 1:N
        m1, m2, r² = rand(3)
        ex = rand_ex()
        f_mkfunc = gen_f_mkfunc(ex)
        f_mkfunc(m1, m2, r²)
    end
end

main(500)   # successful
main(5_000) # failed

By in my case, it's bit hard for me to break my expression into smaller parts,
as I'm using ExprOptimization.jl to define a context free grammar and just sample an expression as a whole.
It seems to me that breaking it down requires a bit involved work here, or there is a straightforward way to do so?

Hi, I usually see people use runtime-generate functions only once, which looks quite abusing to me.
Runtime generated functions are extremely slow in the first call, and become fast since the second call.
Could you explain a bit about why you call mk_function inside the loop but use each only once?

The purpose of my generated function call is to evaluate how good the (random) function is, on some observed data.
I can modify the example above a bit to make it clear.
function main(N::Int)
    m1, m2, r² = rand(3)
    f = m1 * m2 / r²
    for i in 1:N
        ex = rand_ex()
        f_mkfunc = gen_f_mkfunc(ex)
        f_est = f_mkfunc(m1, m2, r²)
        loss = sqrt((f - f_est)^2)
    end
end

This code runs and finishes instantly. Could you tell me if it is adequate? And if not, why?
using GeneralizedGenerated: mk_function

function rand_f()
    u = rand()
    c = randn()
    if u < 0.5
        (m1, m2, r²) -> m1 + m2 + r² + c
    else
        (m1, m2, r²) -> m1 * m2 / r² * c
    end
end

function main(N::Int)
    for i in 1:N
        m1, m2, r² = rand(3)
        f_mkfunc = rand_f()
        f_mkfunc(m1, m2, r²)
    end
end

main(500)   # successful
main(5_000) #

The purpose of my generated function call is to evaluate how good the (random) function is, on some observed data.
I can modify the example above a bit to make it clear.
function main(N::Int)
    m1, m2, r² = rand(3)
    f = m1 * m2 / r²
    for i in 1:N
        ex = rand_ex()
        f_mkfunc = gen_f_mkfunc(ex)
        f_est = f_mkfunc(m1, m2, r²)
        loss = sqrt((f - f_est)^2)
    end
end

You didn't use loss, maybe you want to print it?
I'm very sorry that I did not get your point, but I think it important for me to make sure this package is used in proper cases.

This is not really what I'm looking for.
My real rand_f is defined by a probabilistic context-free grammar (PCFG), from which I can sample an expression.
It is also impossible to enumerate the possible function from the PCFG in my real application either, as the number of trees to the depth I want is way too large (>1,000,000).
I can post an example of the PCFG version using ExprOptimization.jl if that helps.

You didn't use loss, maybe you want to print it?
I'm very sorry that I did not get your point, but I think it important for me to make sure this package is used in proper cases.

For a more complete example
function main(N::Int)
    m1, m2, r² = rand(3)
    f = m1 * m2 / r²
    best_loss = Inf
    best_func = nothing
    for i in 1:N
        ex = rand_ex()
        f_mkfunc = gen_f_mkfunc(ex)
        f_est = f_mkfunc(m1, m2, r²)
        loss = sqrt((f - f_est)^2)
        if loss < best_loss
            best_loss = loss
            best_func = f_mkfunc
        end
    end
    # finding the best_func is my goal
end

Hi, I guess this is adequate:
function rand_f()
    u = rand()
    c = randn()
    if u < 0.5
        (m1, m2, r²) -> m1 + m2 + r² + c
    else
        (m1, m2, r²) -> m1 * m2 / r² * c
    end
end

function main(N::Int)
    m1, m2, r² = rand(3)
    f = m1 * m2 / r²
    best_loss = Inf
    best_func = nothing
    for i in 1:N
        f_mkfunc = rand_f()
        f_est = f_mkfunc(m1, m2, r²)
        loss = sqrt((f - f_est)^2)
        if loss < best_loss
            best_loss = loss
            best_func = f_mkfunc
        end
    end
    best_func
end

f = main(4000)

The issue for me is that I can't actually write down the rand_f as you do here,
which was the reason I wrote it as in my initial version.
It's something like below in practice, using ExprOptimization.jl:
using ExprOptimization
using ExprOptimization.ProbabilisticExprRules: RuleNode, mindepth_map, ProbabilisticGrammar

G = @grammar begin
    Real = m1
    Real = m2
    Real = r²
    Real = Real + Real
    Real = Real - Real
    Real = Real * Real
    Real = Real / Real
end

PCFG = ProbabilisticGrammar(G)

function rand_f()
    tree = rand(RuleNode, PCFG, :Real, mindepth_map(G), D)
    ex = get_executable(tree, G)
    return mk_function(GeneratedFunctions, :((m1, m2, r²) -> $ex))
end

Again, in practice my G is much complex than this example and there is no way to enumerate all possible functions underG.
Hope this makes my situation a bit clear.

Hi @xukai92 , I hope you don't mind my jumping in on this...
In my experience, most applications are a natural fit for either GG or https://github.com/SciML/RuntimeGeneratedFunctions.jl

GG has a really nice ecosystem around it and is very powerful, for example allowing closures. But the approach lead to some limitations inherited from Julia compiler limitations
RGF is simpler, and for example cannot represent closures. But it is also very fast, and the simpler approach help it to avoid some of the Julia compiler's corner cases

I use both, choosing based on the kind of problem. Have you tried RGF for this case?

function rand_f()
           tree = rand(RuleNode, PCFG, :Real, mindepth_map(G), 5)
           ex = get_executable(tree, G)
           return @RuntimeGeneratedFunction :((m1, m2, r²) -> $ex)
       end

julia> [rand_f()(1,2,3) for j in 1:2000][end-10:end]
11-element Vector{Real}:
  1
  1
  1
 -2.6666666666666665
  4.0
  3
  3
  0.5
  2.0
  1
  2

I prefer GG when you're writing a few functions that will be evaluated many times. But for a very large number of functions, RGF can handle simpler cases without needing to build as many types.

Thanks a lot @cscherrer for pointing RuntimeGeneratedFunctions.jl, which I didn't know before!
I give a quick try on this package

It doesn't have the same issue I described here (i.e. throwing errors when the number of generated function reaches a high figure).
It's slightly faster than GG.jl (5,584s -> 5,300s in one of my experiment).

I prefer GG when you're writing a few functions that will be evaluated many times. But for a very large number of functions, RGF can handle simpler cases without needing to build as many types.

Thanks for also making this comment here.
In fact in my setup, I need to evaluate each function k times, with the hyper-parameter k ranging from 1 to 10.
The number I reported above is from k=5 and I suspect that only with a smaller k the benefit of RGF would be more clear.
Thanks again!

Thanks a lot @cscherrer !
RGF is absolutely a right way here.
Besides, you @xukai92  do not need to generate functions so many times. You only need to generate one function:
function rand_ex()
   tree = rand(RuleNode, PCFG, :Real, mindepth_map(G), 5)
   ex = get_executable(tree, G)
   return ex
end
for j = 1:2000
    f_mkfunc_ex = rand_ex()
    f_est = eval(:(
                 let (m1, m2, r²) = $(((m1, m2, r²))
                      $f_mkfunc_ex
                 end))
    loss = sqrt((f - f_est)^2)
    if loss < best_loss
        best_loss = loss
        best_ex = f_mkfunc_ex
    end
end

best_func = @RuntimeGeneratedFunction :((m1, m2, r²) -> $best_ex)

This is now directly supported by GG v0.3


Bump gdx project config

Closes #59.

Travis works after adding:
dist: trusty - as suggested here https://travis-ci.community/t/unable-to-accept-license-for-build-28-0-3-and-android-sdk-27/2883/5

Builds are failing with:
Execution failed for task ':android:validateSigningDebug'.
> java.util.concurrent.ExecutionException: com.android.builder.utils.SynchronizedFile$ActionExecutionException: java.io.IOException: com.android.ide.common.signing.KeytoolException: Failed to create keystore.

More info here: https://stackoverflow.com/questions/47310006/android-studio-failed-to-create-keystore


NoneType object has no attribute split

(pointcept) D:\MSc CS\Final Project\Code\Pointcept\libs\pointops>python setup.py install
Traceback (most recent call last):
File "setup.py", line 8, in
flag for flag in opt.split() if flag != '-Wstrict-prototypes'
AttributeError: 'NoneType' object has no attribute 'split'

Hi, please run with a Linux environment

必须使用linux环境吗

必须使用linux环境吗

I am not sure. Never try this on Windows.


Setting APP_BASE_HREF in _layout.cshtml fails

Using  <base href="@(Url.Content("~/en"))" /> in _layout.cshtml results in the url to be correct, but angular initialy hits the "Not found page", and after a second or two, loads the correct page.
For example, http://localhost:53545/en/home
Later I need to use this in app.browser.module.ts :
 {
        provide: APP_BASE_HREF,
        useFactory:(getBaseUrl)
      }

export function getBaseUrl() {
  return '/' + (window.location.pathname.split('/')[1] || 'en');
}

This because I later on need to check what language the user wants to load.
For example if the users needs danish : http://localhost:53545/dk/home
But how do I set this up, so that the router doesnt load the 404 page first?

Anyone have any idea on how to do this?

Data from your  tag is not available during server-side prerendering. It never has been - we don't try to parse things out of your Razor pages like that.
Instead, params.baseUrl comes from ASP.NET's PathBase context property. This should match whatever virtual directory your app is being served from.

Try this above to see if that works! During SSR, we don't have access to anything in the Razor/ASP.NET world unless it's passed down. We aren't able to pass the entire HTML, but only the <app-root> to Universal, since dotnet handles everything else.
Hope that helps!


train on my own image data

May I ask how to train on my own image data, or how to generate data annotations, can you give some suggestions or reference links?

Hi, you need to label your data according to the BDD100K dataset. You can use labelme tool to label segmentation data https://github.com/wkentaro/labelme


Documentation on the package

@perimosocordiae  I am thinking we should write some documentation for the usages or intro to some algorithms(maybe some links to papers to save time). I am suggesting using Sphinx and following the Numpy Docstring Standard. What do you think?
Interestingly, the dml R package that I wrote covers mostly the not-yet-implemented algorithms in metric-learn. It'll probably take me some time to understand each implemented algorithms though.
If you think this is necessary, I can start doing it during my free time.

I think those are good choices. The API surface is fairly small, so hopefully there won't be too many docs to write.

We now have html docs on github pages!
http://all-umass.github.io/metric-learn/

It looks so great! Good job!
On Sep 22, 2015 8:20 PM, "CJ Carey"<EMAIL_ADDRESS>wrote:

We now have html docs on github pages!
http://all-umass.github.io/metric-learn/
—
Reply to this email directly or view it on GitHub
https://github.com/all-umass/metric-learn/issues/8#issuecomment-142460916
.


🔧 Dependabot updates 2022-10-28

closes #83
closes #75
closes #74
closes #71
closes #61

Codecov Report
Base: 100.00% // Head: 99.81% // Decreases project coverage by -0.18% :warning:

Coverage data is based on head (01999bb) compared to base (cd476aa).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##              main      #85      +/-   ##
===========================================
- Coverage   100.00%   99.81%   -0.19%
===========================================
  Files           18       18
  Lines          539      539
  Branches        89       73      -16
===========================================
- Hits           539      538       -1
- Partials         0        1       +1

Flag
Coverage Δ

3.10
99.81% <ø> (ø)

3.7
?

3.8
?

3.9
?

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

Impacted Files
Coverage Δ

pydapper/commands.py
99.59% <0.00%> (-0.41%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Code only generated for top-level file

I have been provided with a large json schema that is contained in 8 separate files.  When I try to generate the associated java classes using a maven build, code is only generated for the highest level, apparently ignoring the definitions in any of the other files.  Is this a known issue or am I doing something wrong?
Plugin configuration
           <plugin>
                <groupId>org.jsonschema2pojo</groupId>
                <artifactId>jsonschema2pojo-maven-plugin</artifactId>
                <version>1.2.1</version>
                <configuration>
                <sourcePaths>
                    <sourcePath>${basedir}/src/main/resources/schema</sourcePath>
</sourcePaths>
                    <outputDirectory>c:/temp/datex3/</outputDirectory>
                    <targetPackage>com.example.types</targetPackage>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>generate</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Top-level schema
{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {},
  "type": "object",
  "additionalProperties": true,
  "anyOf": [
    {
      "$ref": "DATEXII_3_Common.json#/definitions/_PayloadPublication"
    }
  ]
}

Generated code - only "DATEXII3D2Payload" has been generated, nothing from the referenced file (which in turn references other files)
package com.example.types;

import java.util.LinkedHashMap;
import java.util.Map;
import javax.annotation.Generated;
import com.fasterxml.jackson.annotation.JsonAnyGetter;
import com.fasterxml.jackson.annotation.JsonAnySetter;
import com.fasterxml.jackson.annotation.JsonIgnore;
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonPropertyOrder;

@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonPropertyOrder({

})
@Generated("jsonschema2pojo")
public class DATEXII3D2Payload {

    @JsonIgnore
    private Map<String, Object> additionalProperties = new LinkedHashMap<String, Object>();

    @JsonAnyGetter
    public Map<String, Object> getAdditionalProperties() {
        return this.additionalProperties;
    }

    @JsonAnySetter
    public void setAdditionalProperty(String name, Object value) {
        this.additionalProperties.put(name, value);
    }

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append(DATEXII3D2Payload.class.getName()).append('@').append(Integer.toHexString(System.identityHashCode(this))).append('[');
        sb.append("additionalProperties");
        sb.append('=');
        sb.append(((this.additionalProperties == null)?"<null>":this.additionalProperties));
        sb.append(',');
        if (sb.charAt((sb.length()- 1)) == ',') {
            sb.setCharAt((sb.length()- 1), ']');
        } else {
            sb.append(']');
        }
        return sb.toString();
    }

    @Override
    public int hashCode() {
        int result = 1;
        result = ((result* 31)+((this.additionalProperties == null)? 0 :this.additionalProperties.hashCode()));
        return result;
    }

    @Override
    public boolean equals(Object other) {
        if (other == this) {
            return true;
        }
        if ((other instanceof DATEXII3D2Payload) == false) {
            return false;
        }
        DATEXII3D2Payload rhs = ((DATEXII3D2Payload) other);
        return ((this.additionalProperties == rhs.additionalProperties)||((this.additionalProperties!= null)&&this.additionalProperties.equals(rhs.additionalProperties)));
    }

}

Hi

Is this a known issue or am I doing something wrong?

There are know limitations:

anyOf/allOf/oneOf are not supported and thus are not processed
if "schema" is used as container (contains only defitions) then it doesn't represent any type at all and so nothing is generated (see https://github.com/joelittlejohn/jsonschema2pojo/issues/1500#issuecomment-1465185420)

Thank you @unkish
Looks like I'll have to interpret the data by hand then :(


Improve mypy

Much stricter mypy passing. Eventually we want --strict passing, but I would like to merge these changes already to main.

Addressed most of your comments @EricMarcus-ai


kube2pulumi works for typescript but not python, go, or c# for prometheus operator

What happened?
When running kube2pulumi on prometheus operator for alerts the following code:
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: pagerduty-config
data:
  apiSecret: <base64 encoded key>
prometheus_operator:
  enabled: true
  alert_manager:
      enabled: true

and then selecting python, we get:
Sorry, we were unable to convert your code. There could be a problem with the code you submitted, or it might use a feature kube2pulumi doesn't support

The converter seems to stop on:
prometheus_operator:
Expected Behavior
Expect that python, go, or c# code would be generated.
Instead only the typescript code is generated successfully.
Steps to reproduce

Go to kube2pulumi: https://www.pulumi.com/kube2pulumi/
Put the following code in:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: pagerduty-config
data:
  apiSecret: <base64 encoded key>
prometheus_operator:
  enabled: true
  alert_manager:
      enabled: true

Select convert to typescript and it will work. For example, the following code is generated:

import * as pulumi from "@pulumi/pulumi";
import * as kubernetes from "@pulumi/kubernetes";

const pagerduty_configSecret = new kubernetes.core.v1.Secret("pagerduty_configSecret", {
    apiVersion: "v1",
    kind: "Secret",
    type: "Opaque",
    metadata: {
        name: "pagerduty-config",
    },
    data: {
        apiSecret: "<base64 encoded key>",
    },
    prometheus_operator: {
        enabled: true,
        alert_manager: {
            enabled: true,
        },
    },
});

Select convert to python and you will see the error

However, if you nest the prometheus_operator like the following under apiSecret:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: pagerduty-config
data:
  apiSecret: <base64 encoded key>
  prometheus_operator:
    enabled: true
    alert_manager:
        enabled: true
    extra_routes: |
      - receiver: pager-duty
        match_re:
          severity: critical
          team: serin
        group_wait: 10s
  extra_receivers: |
      - name: pager-duty
        pagerduty_configs:
        - service_key: '******'
        slack_configs:
        - send_resolved: true
          channel: '#slack-channel-name'
           http_config:
            proxy_url: http://proxy.config.pcp.local:3128
          api_url: 'https://hooks.slack.com/services/xxxxxxxxx/yyyyyyyyyyy/zzzzzzzzzzzzzzzzzzzzzzzz'
          text: |-
            {{ range .Alerts }}
              *Alert:* {{ .Annotations.summary }} - `{{ .Labels.severity }}`
              *Description:* {{ .Annotations.description }}
              *Runbook:*
              {{ if .Annotations.runbook_url }} {{ .Annotations.runbook_url }} {{ else }} https://my.com/.. {{ end }}
              *Details:*
              {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
              {{ end }}
            {{ end }}

then it works and generates the following python code:
import pulumi
import pulumi_kubernetes as kubernetes

pagerduty_config_secret = kubernetes.core.v1.Secret("pagerduty_configSecret",
    api_version="v1",
    kind="Secret",
    type="Opaque",
    metadata=kubernetes.meta.v1.ObjectMetaArgs(
        name="pagerduty-config",
    ),
    data={
        "apiSecret": "<base64 encoded key>",
        "prometheus_operator": {
            "enabled": True,
            "alert_manager": {
                "enabled": True,
            },
            "extra_routes": """- receiver: pager-duty
        match_re:
          severity: critical
          team: serin
        group_wait: 10s
""",
        },
        "extra_receivers": """- name: pager-duty
        pagerduty_configs:
        - service_key: '******'
        slack_configs:
        - send_resolved: true
          channel: '#slack-channel-name'
           http_config:
            proxy_url: http://proxy.config.pcp.local:3128
          api_url: 'https://hooks.slack.com/services/xxxxxxxxx/yyyyyyyyyyy/zzzzzzzzzzzzzzzzzzzzzzzz'
          text: |-
            {{ range .Alerts }}
              *Alert:* {{ .Annotations.summary }} - `{{ .Labels.severity }}`
              *Description:* {{ .Annotations.description }}
              *Runbook:*
              {{ if .Annotations.runbook_url }} {{ .Annotations.runbook_url }} {{ else }} https://my.com/.. {{ end }}
              *Details:*
              {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
              {{ end }}
            {{ end }}
""",
    })

This will also generate valid C# code, however, for GO it will still throw an error.
Output of pulumi about
pulumi about
CLI
Version      3.56.0
Go Version   go1.20.1
Go Compiler  gc
Plugins
NAME        VERSION
go          unknown
kubernetes  3.21.2
Host
OS       darwin
Version  11.7.4
Arch     x86_64
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @squaremo,
Yes, we want to convert the value prometheus_operator.  I updated the example above when I nested the prometheus_operator before converting for python.  When I converted the yaml for typescript, I didn't need to nest it.

Step # 5 in reproduce shows the fix.  Closing as this is resolved.


Handle breaking changes on HAPI FHIR version bump

User Story
As a ReportStream developer, FHIRPath is a vital part of my application and needs to be maintained up to date.
Description/Use Case
Our dependency of ca.uhn.hapi.fhir:hapi-fhir-structures-r4 includes breaking changes on its currently pending version bump.
Risks/Impacts/Considerations
Dev Notes
Dependabot PR handling the update. You may use its branch as a starting point since we can always just close this PR: https://github.com/CDCgov/prime-reportstream/pull/11277
While on the dependabot branch, you can trigger the errors just by running unit tests.
Acceptance Criteria

With HAPI FHIR structures updated to 6.8.2, all tests pass

Please add your planning poker estimate with Zenhub @jack-h-wang


"Commits behind main" counter is not working reliable in branch overview

Description
Hi,
the number of "commits behind main" is not updated regularly for some reason in the branch overview page.
My steps to reproduce are:

Create a new repository
Add a testfile and commit
Create a new branch "dev" from "main"
Modify the testfile and commit to "main"
The branch overview shows either: "1|0" or "0|0"
Modify the testfile a second time and commit to "main"
Modify the testfile a third time and commit to "main"
The branch overview still shows "0|0" or "1|0"
(see screenshot, it's taken from the Gitea demo site)

The CLI shows
git rev-list --left-right --count origin/main...origin/dev
3	0

When I now add a testfile to the "dev" branch and commit it, the branch overview updates correctly to "3|1".
In general, when doing commits on the "dev" branch, the correct number of "commits ahead of main" is shown immediately after each commit.
You can find my testrepo on the Gitea demo site here, I added some more commit on the "main" branch, the number should now be "5|1" but still shows "3|1".
Best regards
Daniel
Screenshots

Gitea Version
1.22.1
Can you reproduce the bug on the Gitea demo site?
Yes
Operating System
Linux
Browser Version
Firefox 127.0.2

This issue may be related to #29577


Importing named export

I'm using gentype.import for binding to React components. The library uses named export extensively so it would be lovely to have named export available. Example output code:
import { Foo } from "bar"

This should be doable by adding meaning to the annotation<EMAIL_ADDRESS>"Foo"].
Similar to what was done for importing simple values: https://github.com/cristianoc/genType/commit/df0d810eb49d166759d8fdda2bb6623d786b0979.

@cristianoc could you please make a new release with this? I'm currently using a hack to avoid this limitation


Fix Animal Magnetisim missed mistake

I remember seeing my suggestion was acknowledged but I never re-looked at the code

@Zoinkwiz 👁


Does not work in IE11

The methods this uses to get scroll position are not compatible with IE11.

Hi, have you tried setting useWindow to true ?

If it still doesn't work, you can add an option to enable IE11 support and make a PR, I'll be glad to accept the feature :)

Yes, I have tried the option.
If I knew how to resolve it, I'd gladly submit an PR, but if it cannot be fixed, at least list the browser compatibility in the Read Me.

@agonsalves , just passing through...but maybe think about submitting a PR to update the readme if you don't like it.  Open source = free.

The module should work in IE9-11, the ticket is closed until further validation that the bug is indeed present!
https://dev.to/n8tb1t/tracking-scroll-position-with-react-hooks-3bbj


Autosuggest results container width too wide.

The results container is looks a bit wide on larger screens, width needs reducing.

Should be same width as input box?


Example for stretch property of text is not using a font family with a condensed version

This example doesn't actually illustrate what this property actually does, since both the first and second line are displayed at 100% stretch.
Compare with
#set text(font: "Roboto Serif")
#text(stretch: 75%)[Condensed]\
#text(stretch: 100%)[Normal]\
#text(stretch: 125%)[Extended]

I realized this because of https://github.com/typst/typst/issues/1250


Unable to install using Node v0.12.4

It appears that the buffertools module is the issue. Possibly related to #60 ?
Appreciate any thoughts.
Ben$ npm install sandcastle --save
npm WARN package.json<EMAIL_ADDRESS>No description
|
><EMAIL_ADDRESS>install /Users/Ben/node_modules/sandcastle/node_modules/bufferstream/node_modules/buffertools
> node-gyp rebuild

  CXX(target) Release/obj.target/buffertools/buffertools.o
  SOLINK_MODULE(target) Release/buffertools.node
ld: library not found for -lgcc_s.10.5
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/buffertools.node] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at ChildProcess.emit (events.js:110:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1074:12)
gyp ERR!

Understood. Many thanks.


Fix question margins in Safari

Will resolve #394

  Question margins wrong with h1 in legend followed by p tags


Add ability to merge downloaded kubeconfig with an existing kubeconfig file

What feature would you like to be added?
The kubeconfig file is always downloaded to the directory from which KubeOne was invoked. Usually, the user would like to have it in some other place, like ~/.kube/config, so they can quickly access the cluster.
To make the user experience better, we should:

Add ability to choose where to download the kubeconfig file (e.g. by using the --kubeconfig flag)
If the chosen file already exists, we should merge those two files

This behavior is very common across many tools, so I think we should consider it as well.

I would like to work on this.
One question I have is when we merge the config generated by kubeone to an existing config file should we update the current context in the config to the cluster created by kubeone or leave it as it is?

It's possible to merge different kubeconfigs using kubectl, please see more here: https://ahmet.im/blog/mastering-kubeconfig/#tip-3-merging-kubeconfig-files
I don't think we should reimplement the standard feature. If there would be no opposition, I propose to close this issue as "wontfix".


[SPARK-12404] [SQL] Ensure objects passed to StaticInvoke is Serializable

Now StaticInvoke receives Any as a object and StaticInvoke can be serialized but sometimes the object passed is not serializable.
Based on #10357 with tests added.

I think we should also add a test case to JavaDatasetSuite and now I'm working on it.

Test build #47943 has started for PR 10360 at commit f2e8ba6.

Test build #47943 has finished for PR 10360 at commit f2e8ba6.

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

Merged build finished. Test PASSed.

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


Name of the input tensor and output tensor

I'm trying to convert ckpt files into pb files, however I'm confused by the names of the tensors. Does anyone know the name of the output tensor of this model? Thank you.

I think you can kind of specify your input tensor name when exporting (see my issue). I also think I know  the output node names:
output_node_names = ["yolov3/yolov3_head/feature_map_1", "yolov3/yolov3_head/feature_map_2", 'yolov3/yolov3_head/feature_map_3']
anyway, I am struggling finding the detection_boxes, scores etc.

output_node_names = ["yolov3/yolov3_head/feature_map_1", "yolov3/yolov3_head/feature_map_2", 'yolov3/yolov3_head/feature_map_3']

This is the correct output. If you read the paper, in section 2.2 and 2.3, Redmon explains that these three feature maps encode the boxes, objectness score, and class prediction. The method yolov3.predict() just decodes those three tensors into usable components.


cmd/go: compile and link search paths not compatible with multiple GOPATH roots

Here is a day 1 design incompatibility between GOPATH and cmd/go on the one side and cmd/compile's -I option and cmd/link's -L option on the other.
When invoking the compiler or linker, cmd/go must tell it where to find compiled packages. It does so by walking the full dependency graph and collecting the names of pkg directories involved and then passes that list as repeated -I (compiler) or -L (linker) options.
GOPATH defines a preference list. GOPATH=p1:p2 (p1;p2 on Windows) means first look in p1, then p2. It is also valid for both p1 and p2 to have a package foo: p1 wins. But until the fix for #14192, it was possible for cmd/go's walk of the dependency graph to produce go tool compile -I p2 -I p1 or go tool link -L p2 -L p1, causing the compiler or linker to find p2's foo (incorrect) instead of p1's foo. CL 19385 fixes this kind of preference inversion, making sure that the -I and -L options always respect GOPATH order.
But there is a second kind of possible preference inversion that arises because cmd/go looks for source code and the compiler and linker look for compiled packages. This inversion is harder to fix.
Suppose p1 has source code p1/src/foo, that p2 does not have p2/src/foo, and that p2 does have a stale p2/pkg/goos_goarch/foo.a.
Suppose p2 has source code p2/src/bar, that p1 does not have p1/src/bar, and that p1 does have a stale p1/pkg/goos_goarch/bar.a.
Suppose there is a package top that imports both foo and bar. cmd/go will correctly resolve the imports to the source directories p1/src/foo and p2/src/bar; go install top will first build p1/src/foo into p1/pkg/goos_goarch/foo.a and p2/src/bar into p2/pkg/goos_goarch/bar.a, and then it will invoke go tool compile -I p1 -I p2 top.go. To resolve import "foo", the compiler will correctly find p1/pkg/goos_goarch/foo.a. To resolve import "bar", the compiler will incorrectly find p1/pkg/goos_goarch/bar.a: it is supposed to be using p2/pkg/goos_goarch/bar.a. And swapping the -I options does not help: -I p2 -I p1 will resolve bar correctly but not foo (and contradicts GOPATH). CL 19385 includes this scenario as a disabled test, TestGoBuildGOPATHOrderBroken.
After the fix in CL 19385, only bar is needed in the example. Forcing GOPATH order (important for more common scenarios) contradicts what would make bar resolve correctly above. Including foo just makes clear that there's no solution even if you drop the GOPATH order constraint.
The fundamental problem is that, as designed, cmd/go assumes the GOPATH source directory search and the equivalent compiled package search will land on corresponding results. In this example they do not and cannot.
I see three possible resolutions:

Do nothing. It's been like this for a long time and I'm aware of no actual reports of this problem. In practice, it would only arise if people use multiple GOPATH roots and move code from an earlier root to a later root. Multiple GOPATH roots are uncommon except with godep (I think gb avoids cmd/go entirely now), and godep is moving to the new vendoring convention. In pre-vendoring godep usage, the situation would only arise when devendoring a package: removing it from the _Godep/workspace/src without also removing it from _Godep/workspace/pkg would leave a stale package file behind. Also blowing away p1/pkg fixes the problem, which people in this rare situation probably know to do.

Make cmd/go detect this situation and delete the stale compiled package bar.a. Specifically, the situation is having multiple GOPATH roots p1:p2:...:pN, where zzz resolves to pK/src/zzz and cmd/go wants to invoke the compiler with -I pJ -I pK, for some J < K. In this case, cmd/go would first have to delete pJ/pkg/goos_goarch/zzz.a, if it existed.

Replace the -I and -L options in the compiler and linker with more fine-grained options -Z importpath=/path/to/pkg.a. This would result in O(# of imports) arguments to the compiler and O(total # of packages) arguments to the linker, instead of the current O(# of GOPATH roots), which might suggest passing the map in a file instead of on the command line.

(1) is not terribly satisfying. (2) seems reasonable behavior by cmd/go if viewed as “detecting a removed source directory and removing the corresponding package object.” (3) seems like unwarranted complexity.
On the other hand, if we ever turn the pkg/ tree into some kind of general package cache (see #4719), it will necessarily lose the current alignment with import paths and thus require something like (3). I also wonder whether alternate build systems like gb or bazel would be helped by having (3) available (/cc @davecheney, @hanwen). For example, my compiler support for vendoring was to add -importmap, a much more general compiler option, both because it kept vendor logic out of the compiler and because I expect that eventually bazel in large source repositories (like Google's) will need something like this to support multistep moves of Go packages from one location to another. In that case, -importmap is there for vendoring today and there for a need I know will arise in the future (because I've already seen the need come up and be worked around). If the authors of gb or bazel or some other build system made a case for why (3) would help them, I'd be more inclined to do it.
With the information I have right now, I'm inclined toward doing (2). In the common case of ≤ 1 GOPATH root, it would be no extra work, and when there are multiple GOPATH roots there are still no more removals of compiled packages than there were failed stats of source directories.

Bazel sidesteps the Go tool, and manages its own caches, so this scenario isn't a problem for Bazel. Since all the compiles happen in a symlink tree (on Linux it additionally uses a namespace sandbox), there is no possibility of confusion or need of -L options. In fact, it just sets "-L . ":
https://github.com/bazelbuild/bazel/blob/master/tools/build_rules/go/def.bzl#L245
If you added a -importmap option to the linker, the rules could probably be adapted for that, but it doesn't bring any benefit, just a little extra work.
It's probably too late to change this, but why not have GOPATH just apply to source directories? The artifacts would go then into a pkg/PREFIX/ directory, where you can work all relevant settings (race detector, $GOPATH, target architecture, compiler version, etc.) into PREFIX.

On Tue, Feb 9, 2016 at 7:12 AM, Han-Wen Nienhuys<EMAIL_ADDRESS>wrote:

If you added a -importmap option to the linker, the rules could probably
be adapted for that, but it doesn't bring any benefit, just a little extra
work.

To be clear, -importmap is about something completely different from this
issue (allowing import "x" and import "y" to resolve to the same package;
symlinks don't help, because you'd still get two copies in the final
binary).

It's probably too late to change this, but why not have GOPATH just apply
to source directories? The artifacts would go then into a pkg/PREFIX/
directory, where you can work all relevant settings (race detector,
$GOPATH, target architecture, compiler version, etc.) into PREFIX.

The original motivation for multiple GOPATH entries was to allow
GOPATH=$HOME/mygo:/usr/local/systemgo. You can't just have one pkg/
directory in that case: the user needs write access to update the packages
for $HOME/mygo's sources, but you want the systemgo packages read-only.
Russ

I don't think (3) sounds too complicated. Plus I would love to see work towards #4719 in 1.7. (I don't like having to explain to people when to run "go install or "go test -i" occasionally, to make their "go builds" fast again.)

Sorry, but given the rest of what's going on, no work toward #4719 is going
to happen in Go 1.7.


runtime: recognize sway file types

See https://github.com/FuelLabs/sway. Comments taken from their syntax documentation. File extension taken from the same documentation/GitHub's own recognition of these file types

Thanks.
I have not heard of this PR's filetype before but it is unrelated.

some garbage blockchain nonsense

🤣 Now the question is, why should we include some blockchain nonsense :)

Lol good question; I thought it should be because the repo seems pretty popular and github itself at least recognizes the language, associating it with .sw files


Add "skip download" step for 2nd micro:bit on radio bridge connection flow

Add in the optional "skip download" link for the 2nd micro:bit.

Will pick this up via the open PR. Closing.


Can't drag Markdown preview to start a new editor group

VSCode Version: 1.12 Insiders
OS Version: Windows 7, 10

Steps to Reproduce:

With a single editor group, open a Markdown file, then Markdown: Open Preview (Ctrl+Shift+V)
Now try to drag the markdown preview to the side to start a new editor group

The drop is blocked.
If you select another file and then try to drag the markdown preview with only the tabbed heading, it works.

@gregvanl does it work in 1.11?

@bpasero Yes, this is a regression from 1.11.

@mjbvz I see that dragging the tab over the markdown preview turns the mouse icon into a "drop not allowed" cursor. This could either be the Electron update, or changes we did to the webview within (e.g. context-isolation). A quick test to disable context isolation though did not help. Were there other changes that could have an impact? E.g. CSP settings?

Problem persists in VSCode 1.21.1 (Win10)

I cannot repro this with VSCode 1.28.2.

I agree, this seems to have been fixed, even though it feels a bit "laggy" to me compared to dragging code edit tabs. But it works, guess the issue can be closed now

Still doesn't work for me in 1.28.2 if the active editor is the Markdown preview. I think the issue is that the Markdown preview can't be a drop location.

You can repro this issue easily.  With a Markdown view open, dragging the tab does not show the new group shadows.  Cmd+T to create a new tab, and with it active, drag the Markdown tab over it.  The new group shadows show up and you can dock the tab.  I'm on 1.32.3 on macOS.

Still a problem in 1.34 - seems to me the obvious thing to do immediately after opening a preview - to drag it to one side, to see it side-by-side, but you're blocked from doing so unless you switch back to the markdown code first.

So thrilled about this!


I cannot use the tag for the photo sending

In the flow editor I try to drag and drop, but the imagetoken tag will not drop on the tag icon.
I'm using the 0.0.9 version and using the synology trigger card that reacts to an camera snaphot becoming available.
Is there any way to provide some logging so you will be able to check what is going wrong?

sorry linked the wrong commit here, as i can recall this is an issue within the flow editor of athom. you can try the homey app or a different browser, i had the same problem couple of times the image token is quite buggy

Is this issue still relevant?

For me personally not anymore since i am now using a different messaging
service
Op di 28 mei 2019 19:14 schreef Veldkornet<EMAIL_ADDRESS>
Is this issue still relevant?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PandaNL/nl.tonversteeg.pushover/issues/16?email_source=notifications&email_token=AC7ZVEFLB5YNEDIFGZOIFLLPXVSAXA5CNFSM4FRS2NFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWM2ADY#issuecomment-496607247,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC7ZVEBYZBVQM7EGE5QZAN3PXVSAXANCNFSM4FRS2NFA
.

As of v0.0.10 using a image tag works.


add german school Lessing

Name: Lessing Gymnasium | Berufskolleg
URL: http://lgbk.de
Schooltype: Highschool or equivalent
Email users: (students and) teachers
Proof of Email-adress usage by school: http://www.lgbk.de/das-lessing/das-kollegium/

@JoeSaxo Pull request merged. Please notice that  free educational license for JetBrains tools is for high and higher schools students, i.e. those who are over 13 of age. Thank you!


David Klee

fullname
David Klee
topics
Database administration, performance tuning, virtualization, IaaS, cloud migrations, high availability, disaster recovery
regions
Virtual
Sessionize
https://sessionize.com/david-klee/
language
English

Thank you so much! I appreciate it!
David
From: github-actions[bot] @.>
Sent: Saturday, July 16, 2022 1:38 PM
To: dataplat/DataSpeakers @.>
Cc: David Klee @.>; Mention @.>
Subject: Re: [dataplat/DataSpeakers] David Klee (Issue #66)
Hey @hfxdkleehttps://github.com/hfxdklee,
Closing this issue now that the Action has run successfully.
Thank you so much for adding your information to the list.
It will be active on callfordataspeakers.com shortly.
Please share on social media.
Love and Hugs
Rob and Daniel
@SQLDBAWithABeardhttps://github.com/SQLDBAWithABeard @dhmacherhttps://github.com/dhmacher
—
Reply to this email directly, view it on GitHubhttps://github.com/dataplat/DataSpeakers/issues/66#issuecomment-1186261918, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACYOQPQISEWSDTVB5IRCHATVUL6RPANCNFSM53YPANAQ.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


[containerapp] az containerapp job start: Fix unknown properties additionalProperties error

Related command

az containerapp job start:
Unknown properties additionalProperties in Microsoft.ContainerApps.WebApi.Views.Version20230501.StartJobExecutionTemplate are not supported
Description

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

containerapp

@Greedygre Could you please resolve these conflicts?


Rename release jobs

Hopefully these names will make it a bit more clear what they do.

/hold

/unhold


support for multiple entity managers on same entity mappings

related to #1547

Forward-port of https://github.com/Atlantic18/DoctrineExtensions/pull/1547 to master: https://github.com/Atlantic18/DoctrineExtensions/pull/1561


[FLOC-2049] Add new glossary page to the reference docs

The content was obtained from:
https://docs.google.com/document/d/11HEK-on8SsPQPb0Y0hzRuvjfa6tjfk8xqDfX8ygwvvs/edit#heading=h.22b0ytq92qi2
(note these definitions have been approved by Michael, Luke and Jean-Paul)
and
https://docs.google.com/document/d/1cvjWM0WKsbTiXGKzTpBHLebW3puSU9A5GpI3DimEnN0/edit
https://docs.google.com/document/d/19QhvoMD1iSVniTevJcqkNcM78WJBZf59l6N1JC8hmX4/edit
Its been reviewed by Adam and Michael.
Adam commented that adding ref tags to each term is not required at this point, but in a future issue, I'll will be tagging some of our concept information with links to the glossary definitions, so its easier to add these now.
Also, Michael suggested an architecture diagram labeled with these terms, that I agree would go a long way to helping people understand. However, adding this will be a post v1.0 issue at this point.
I've also seen some buildbot failures on this branch, but I don't think any of the failures have been caused by my changes. Please advise if this is not the case.

Adam commented that adding ref tags to each term is not required at this point, but in a future issue, I'll will be tagging some of our concept information with links to the glossary definitions, so its easier to add these now.

If you revert this in one commit, you can revert that commit quickly when you need them.

The Drive document should mention that these terms are defined in the product. Or perhaps the duplication should go away and the canonical source can be here.

Also, Michael suggested an architecture diagram labeled with these terms, that I agree would go a long way to helping people understand. However, adding this will be a post v1.0 issue at this point.

Make this issue and put a comment in the source, something like:
.. XXX Add a diagram to make this clearer. See FLOC-XYZ.

Thanks @davidoliverSP2. I think that there are enough comments for this to be worked on again.

Try out sphinx's own markup for this (similar) http://sphinx-doc.org/markup/para.html#glossary

https://github.com/ClusterHQ/flocker/pull/1488#issuecomment-107998349 still stands.

Many (most?) of the comments are still outstanding. Please address them and then resubmit.

Thanks for addressing most of the comments. I've added a couple of new ones but there are still outstanding unaddressed comments (with summaries but please read the whole comments):

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31531441:

Not all of these terms are used in the docs, so they shouldn't be in the glossary until they are.

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31531326

flocker-cli and "The Flocker CLI" are used interchangeably in the docs.

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31531441

Terms should not be in the glossary before they are used in the docs.
For example this mentions that everything not marked Alpha / Beta is "production ready". But our ZFS backend is not "production ready".

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31531637

Production ready has a circular definition.

https://github.com/ClusterHQ/flocker/pull/1488#issuecomment-107998046

The Drive document should mention that these terms are defined in the product. Or perhaps the duplication should go away and the canonical source can be here.

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31538710

There are three ways we refer to the same thing:
flocker-cli, The Flocker CLI, The Flocker client

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31539069

This is confusingly placed in the docs

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31539224

This implies that Flocker can be installed on any Linux distribution

https://github.com/ClusterHQ/flocker/pull/1488#discussion_r31558991

This describes an implementation detail, which doesn't suit a glossary.

If you disagree that any of these require changes, address them by responding with a justification, else it is hard to know whether you have just missed them.
Please resubmit after addressing.


Fix a tiny typo in comment

I can't find the word 'teturn' in my dictionary.

@RX14 I don't think that a tiny typo like this need 2 reviews before getting merged, what do you think?

Rules are meant to eb broken


Can't deselect "Open at Login

Prerequisites
Searched for "login", nothing relevant.
Description
When I click the "Open at login" checkbox, the tick momentarily disappears, then reappears.
Steps to Reproduce

Open Preferences
Click Open at login

Expected behavior:  tick goes away.
Actual behavior: tick does not go away
Reproduces how often: 100%
Versions
SpotMenu version: [Version of SpotMenu]
You can get this information by highlighting SpotMenu.app (most likely in your Applications folder) in finder and pressing space.
Nope, no version information in the popup that comes up when I hit space.
MacOS version: [Version of MacOS]
Version 10.13.3

Thanks :)


Release notes 21.2.5.

https://cockroachlabs.atlassian.net/browse/DOC-1892
Requires #12861, #12859, #12860 to be merged first.

This change is

@rmloveland Thank you for the very thorough review. Hopefully I'll do better in my first draft of the next release notes! I believe I've addressed all your comments.

@rmloveland I'm confident we will. I'll need help in some parts, but it'll get done.
@stbof For now, don't forget to update the sidebar-releases.json file and the release index.

@rmloveland I'm confident we will. I'll need help in some parts, but it'll get done.
@stbof For now, don't forget to update the sidebar-releases.json file and the release index.

Thanks for that pointer. sidebar-releases.json is not mentioned here: https://cockroachlabs.atlassian.net/wiki/spaces/CRDB/pages/186548364/Release+notes

Replaced with #12901.