How do I open settings?

I'm trying out Atom and after a while the menu at the top of the screen with "File" etc. disappeared, and now I can't get to settings.
I've tried:

Holding the Alt key (nothing happens).
Alt+A, Alt+B, etc. all the way to Alt+Z.
Restarting and trying to find settings through the welcome menu. I couldn't find a link to settings.

There are Stack Overflow threads and Youtube tutorials that recommend using the Alt key, but I can't figure out how (simply pressing or holding it like it FF/Chrome doesn't work). I'm not very familiar with Atom, so maybe there's something I'm missing, but this is surprisingly complicated.
Note: I'm using Atom on Windows 10.

I don't know anything about the menu disappearing...
Maybe try taking a screenshot and copy/paste it here?

Ctrl + , (comma) is the default shortcut

Opening the settings with ctrl+comma worked, and I found that the setting that caused the issue: setting the title bar to hidden makes it impossible to open the menu bar. Displaying the title bar makes it possible to open the menu bar by tapping alt.
I'd prefer not to have the title bar because it is bright white and clashes with the dark theme. Is there a way to hide the title bar and still have access to all the menus?

you can change it to "custom"

How?

In any case, I have figured out how to open settings and do not have a specific issue beyond the general confusing nature of the UI, so I'm closing this issue.


Supporting jvm and other platforms?

Using this library in some low-level libraries, I find it hard to add new platforms.
I know it makes no sense most of the time to check connectivity on a jvm project (assuming backend), but sometimes I think it does(jvm desktop for example). Also even a default implementation that consider the device always connected would be a cool shortcut for me.
What do you think?

Hi @glureau , just released the version 1.2.0 with the JVM target


您好，想问一下data_split.py和processing.py是干嘛的呢

是前期预处理数据的脚本，与模型无关
They are scripts for pre-processing. Should not be used.


Fixes problem with fancy lot layout #trivial

The repulsion constant is driven by the bid history delta. When we made the history larger when closed, we changed the maximum delta, and thus the maximum repulsionConstant. I decreased the scale down factor to accommodate the new history size and added clarifying documentation to match.

          2 Warnings

:warning:
Needs testing on a Phone if change is non-trivial

:warning:
Detected some Swift building time outliers

Time | Class | Function |
| --- | ----- | ----- |252.4ms | AuctionViewController.swift | @objc dynamic func showRefineTappedAnimated(animated: Bool)
191.9ms | SwiftyJSON.swift | get {}
177.4ms | WebSocket.swift | private func processRawMessage(buffer: UnsafePointer, bufferLen: Int)
76.8ms | Observable.swift | private final func nextTokenHash() -> Int
75.0ms | AuctionLotMetadataStackScrollView.swift | required init(viewModel: LiveAuctionLotViewModelType, salesPerson: LiveAuctionsSalesPersonType, sideMargin: String)
73.0ms | LiveAuctionsAdminViewController.swift | @objc override func viewDidLoad()
67.9ms | LiveAuctionLotViewController.swift | @objc override func viewDidLoad()
64.8ms | UIViewController+BlurredStatusView.swift | func ar_presentBlurredOverlayWithTitle(title: String, subtitle: String, buttonState: BlurredStatusOverlayViewCloseButtonState = default)
62.8ms | UIViewController+BlurredStatusView.swift | (closure)
59.8ms | RefinementOptionsViewController+Private.swift | func stackView() -> ORStackView

  Generated by :no_entry_sign: danger

This is what the bug looks like:

cool cool


Bulk edit, batch 2 of validation fixes for column headers.

Docs Build status updates of commit 91a9a09:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/transport-agents/monitoring.md
:bulb:Suggestion
View
Details

docs/web-service-reference/completename.md
:bulb:Suggestion
View
Details

docs/web-service-reference/absolutedate.md
:white_check_mark:Succeeded
View

docs/web-service-reference/absolutemonthlyrecurrence.md
:white_check_mark:Succeeded
View

docs/web-service-reference/acceptitem.md
:white_check_mark:Succeeded
View

docs/web-service-reference/accesslevel.md
:white_check_mark:Succeeded
View

docs/web-service-reference/actions-ruleactionstype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/actiontype-reminderactiontype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/actionurl.md
:white_check_mark:Succeeded
View

docs/web-service-reference/adddelegate.md
:white_check_mark:Succeeded
View

docs/web-service-reference/adddelegateresponse.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addimcontacttogroup.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addimcontacttogroupresponse.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addimgroup.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addimgroupresponse.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addnewteluricontacttogroupresponse.md
:white_check_mark:Succeeded
View

docs/web-service-reference/address-contacttype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addressentity.md
:white_check_mark:Succeeded
View

docs/web-service-reference/addresslistid.md
:white_check_mark:Succeeded
View

docs/web-service-reference/aggregateon.md
:white_check_mark:Succeeded
View

docs/web-service-reference/aggregationrestriction.md
:white_check_mark:Succeeded
View

docs/web-service-reference/allowexternaloof.md
:white_check_mark:Succeeded
View

docs/web-service-reference/alternatemailboxcollectionsetting-soap.md
:white_check_mark:Succeeded
View

docs/web-service-reference/and-protectionruleandtype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/anonymousaccessallowed-soap.md
:white_check_mark:Succeeded
View

docs/web-service-reference/appointmentreplytime.md
:white_check_mark:Succeeded
View

docs/web-service-reference/approvaldecisiontime.md
:white_check_mark:Succeeded
View

docs/web-service-reference/approvalrequestdata.md
:white_check_mark:Succeeded
View

docs/web-service-reference/archiveitem.md
:white_check_mark:Succeeded
View

docs/web-service-reference/argument.md
:white_check_mark:Succeeded
View

docs/web-service-reference/assistantphonenumbers.md
:white_check_mark:Succeeded
View

docs/web-service-reference/attachmentid-getattachment-and-deleteattachment.md
:white_check_mark:Succeeded
View

docs/web-service-reference/attribution-string.md
:white_check_mark:Succeeded
View

docs/web-service-reference/attributions-arrayofvalueattributionstype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/autodiscoverrequest-soap.md
:white_check_mark:Succeeded
View

docs/web-service-reference/baseshape-previewitembaseshapetype.md
:white_check_mark:Succeeded
View

docs/web-service-reference/businesshomepages.md
:white_check_mark:Succeeded
View

docs/web-service-reference/businessname.md
:white_check_mark:Succeeded
View

docs/web-service-reference/calendarfolder.md
:white_check_mark:Succeeded
View

docs/web-service-reference/calendarpermissionlevel.md
:white_check_mark:Succeeded
View

docs/web-service-reference/calendarpermissions.md
:white_check_mark:Succeeded
View

docs/web-service-reference/callstate-um-web-service.md
:white_check_mark:Succeeded
View

docs/web-service-reference/changecount.md
:white_check_mark:Succeeded
View

docs/web-service-reference/companynamesortkey.md
:white_check_mark:Succeeded
View

docs/web-service-reference/contactsource.md
:white_check_mark:Succeeded
View

docs/web-service-reference/contactstring.md
:white_check_mark:Succeeded
View

docs/web-service-reference/contentowner.md
:white_check_mark:Succeeded
View

docs/web-service-reference/conversationtopic.md
:white_check_mark:Succeeded
View

docs/web-service-reference/convertid.md
:white_check_mark:Succeeded
View

docs/web-service-reference/copyitem.md
:white_check_mark:Succeeded
View

docs/transport-agents/monitoring.md

Line 14, Column 14: [Suggestion: duplicate-descriptions - See documentation] Attribute 'description' with value 'Last modified: September 17, 2015' is duplicated in 'transport-agents/agent.md(14,14)', 'transport-agents/agentexecution.md(14,14)', 'transport-agents/agentlist.md(14,14)', 'transport-agents/configuration.md(14,14)', 'transport-agents/messagesnapshot.md(14,14)'....

docs/web-service-reference/completename.md

Line 68, Column 42: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/dotnet/api/exchangewebservices.defaultshapenamestype?view=exchange-ews-proxy' will be broken in isolated environments. Replace with a relative link.
Line 68, Column 42: [Suggestion: preserve-view-not-set - See documentation] Did you mean to link to a specific version? It's usually better not to specify a version, so the link always goes to the canonical version. If you really need to link to a specific version, add &preserve-view=true to the URL: https://docs.microsoft.com/dotnet/api/exchangewebservices.defaultshapenamestype?view=exchange-ews-proxy. Otherwise, remove the view parameter.
Line 68, Column 528: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/dotnet/api/exchangewebservices.defaultshapenamestype?view=exchange-ews-proxy' will be broken in isolated environments. Replace with a relative link.
Line 68, Column 528: [Suggestion: preserve-view-not-set - See documentation] Did you mean to link to a specific version? It's usually better not to specify a version, so the link always goes to the canonical version. If you really need to link to a specific version, add &preserve-view=true to the URL: https://docs.microsoft.com/dotnet/api/exchangewebservices.defaultshapenamestype?view=exchange-ews-proxy. Otherwise, remove the view parameter.

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

@lindalu-MSFT , Please review these bulk validation edits with my many thanks. : )


improve in order key generation

Generating in order key that padding with 0 as its prefix.
It would be help to sort them lexicographically.

Note this breaks the API and previous behavior. I think it might be OK, since people should not rely one the naming (if they do, they already have done it wrong... they has to compare the created index to sort anyway)

I agree that this change still provides the original guarantee.

@yichengq Updated. PTAL.

lgtm


[1.0] Release merge August 2

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[X] The toolchain has been rebuilt successfully (or no changes were made to it)
[X] The toolchain/worker package manifests are up-to-date
[X] Any updated packages successfully build (or no packages were changed)
[X] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[X] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[X] All package sources are available
[X] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json)
[X] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[X] All source files have up-to-date hashes in the *.signatures.json files
[X] sudo make go-tidy-all and sudo make go-test-coverage pass
[X] Documentation has been updated to match any changes to the build system
[X] Ready to merge

Summary

Merge for the August 2 release.
Does this affect the toolchain?

Yes.
Test Methodology

N/A - validation done in 1.0-dev.

Self-approving - release merge, no additional changes.


add scope to module

Need ability to create jdbc connection within a scope in mas. scopes should be: system, workspace, workspace-application

closed with #7


Subtitle parsing broken in 1.4.0-alpha02+

Version
Media3 main branch
More version details
Subtitle parsing for a given DASH asset (DRM protected) works fine in 1.4.0-alpha01 but in 1.4.0-alpha02 and 1.4.0-beta01 the playback fails with the following exception.  Without provding the asset, can you help figure this out? Any info from the DASH manifest that I could provide to help?  Again, same asset plays fine and displays subtitles in 1.4.0-alpha01
androidx.media3.exoplayer.ExoPlaybackException: Source error
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:741)
      at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:711)
      at android.os.Handler.dispatchMessage(Handler.java:102)
      at android.os.Looper.loop(Looper.java:223)
      at android.os.HandlerThread.run(HandlerThread.java:67)
  Caused by: androidx.media3.common.ParserException: SubtitleParser failed.{contentIsMalformed=true, dataType=1}
      at androidx.media3.extractor.text.SubtitleExtractor.parseAndWriteToOutput(SubtitleExtractor.java:258)
      at androidx.media3.extractor.text.SubtitleExtractor.read(SubtitleExtractor.java:161)
      at androidx.media3.exoplayer.source.chunk.BundledChunkExtractor.read(BundledChunkExtractor.java:241)
      at androidx.media3.exoplayer.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:132)
      at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:421)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
      at java.lang.Thread.run(Thread.java:923)
  Caused by: java.lang.IllegalArgumentException
      at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:40)
      at androidx.media3.extractor.text.webvtt.WebvttSubtitle.getEventTime(WebvttSubtitle.java:63)
      at androidx.media3.extractor.text.LegacySubtitleUtil.toCuesWithTiming(LegacySubtitleUtil.java:44)
      at androidx.media3.extractor.text.webvtt.WebvttParser.parse(WebvttParser.java:108)
      at androidx.media3.extractor.text.SubtitleParser.parse(SubtitleParser.java:152)
      at androidx.media3.extractor.text.SubtitleExtractor.parseAndWriteToOutput(SubtitleExtractor.java:238)
      at androidx.media3.extractor.text.SubtitleExtractor.read(SubtitleExtractor.java:161)
      at androidx.media3.exoplayer.source.chunk.BundledChunkExtractor.read(BundledChunkExtractor.java:241)
      at androidx.media3.exoplayer.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:132)
      at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:421)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
      at java.lang.Thread.run(Thread.java:923)

Devices that reproduce the issue
Nvidia Shield TV
Pixel 7 Pro
Devices that do not reproduce the issue
None known
Reproducible in the demo app?
Yes
Reproduction steps
player.trackSelectionParameters =
  player.trackSelectionParameters.buildUpon()
    .setTrackTypeDisabled(TRACK_TYPE_TEXT, !showSubtitles)
    .setPreferredTextLanguage("eng")
    .build()

Expected result
Playback succeeds even when displaying subtitles
Actual result
Receive ERROR_CODE_PARSING_CONTAINER_MALFORMED 3001 during playback when attempting to display subtitles
Media
Private URL.  Please let me know if there is some info I can provide from the DASH manifest
Bug Report

[ ] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

1.4.0-alpha02 moved subtitle parsing to happen during extraction by default (instead of during rendering). I wonder if your problem is resolved by moving it back to during rendering? You can do this by calling both MediaSource.Factory.experimentalParseSubtitlesDuringExtraction(false) and TextRenderer.experimentalSetLegacyDecodingEnabled(true) (see also the release notes: https://github.com/androidx/media/releases/tag/1.4.0-alpha02).
Looking at the code, it seems the exception you're seeing is basically an index out of bounds issue:
https://github.com/androidx/media/blob/d833d59124d795afc146322fe488b2c0d4b9af6a/libraries/extractor/src/main/java/androidx/media3/extractor/text/webvtt/WebvttSubtitle.java#L61-L65
I think I can see the issue with the logic here - we need to either not return subtitle.getEventTimeCount() from getStartIndex(...) or check that startIndex < subtitle.getEventTimeCount() before calling long firstEventTimeUs = subtitle.getEventTime(startIndex). I will have a go at writing a test case to reproduce the stack trace you're seeing, and see if this change resolves it.

I've added a test that creates the same stack trace, and sent a change the fixes the code to not crash in this case - I hope to include this in 1.4.0-rc01. Thanks for raising this, and providing stack trace details so we could work out the issue.

Hello @icbaker
I'm testing this out in 1.4.0 and still see the same problem.  You are correct in that this is the place the IllegalArgumentException is getting thrown:
 public long getEventTime(int index) {
   Assertions.checkArgument(index >= 0);
   Assertions.checkArgument(index < sortedCueTimesUs.length);  <-------------- HERE
   return sortedCueTimesUs[index];
 }

and it is indeed because the nextEventTimeIndex is C.INDEX_UNSET, which causes the startIndex to be set to the length of the array
   private static int getStartIndex(Subtitle subtitle, OutputOptions outputOptions) {
    if (outputOptions.startTimeUs == C.TIME_UNSET) {
      return 0;
    }
    int nextEventTimeIndex = subtitle.getNextEventTimeIndex(outputOptions.startTimeUs);
    if (nextEventTimeIndex == C.INDEX_UNSET) {
      return subtitle.getEventTimeCount();        <---------- HERE
    }
    if (nextEventTimeIndex > 0
        && subtitle.getEventTime(nextEventTimeIndex - 1) == outputOptions.startTimeUs) {
      nextEventTimeIndex--;
    }
    return nextEventTimeIndex;
  }

I'm working on changing the setup to try the legacy way and will report on the results there

The array of sortedCueTimesUs is like this from our VTT:
[0, 241000, 241000, 1409000, 1409000, 1442000, 1442000, 1475000, 1475000, 1509000, 1509000, 1576000, 1576000, 1642000, 1642000, 1676000, 1676000, 1742000, 1742000, 1776000, 1776000, 1809000, 1809000, 1843000, 1843000, 2009000, 2009000, 2043000, 2043000, 2076000, 2076000, 2109000, 2109000, 2210000, 2210000, 2243000, 2243000, 2276000, 2276000, 2310000, 2310000, 2610000, 2610000, 2677000, 2677000, 2810000, 2810000, 2844000, 2844000, 2877000, 2877000, 3211000, 3211000, 3244000, 3244000, 3277000, 3277000, 3511000, 3511000, 3544000, 3544000, 3578000, 3578000, 3644000, 3644000, 3678000, 3678000, 3711000, 3711000, 4004000]
But the value we are searching for in Util.binarySearchCeil() is<PHONE_NUMBER>32 so it seems like our third-party VTTs are not in the expected format somehow...

I'd like to point out that ExoPlayer doesn't crash, everything is caught.
It's just that our playback is broken (we get a 3001) when trying to play with subtitles on

Please can you give us a way to play a stream that reproduces this issue? Without that I'm afraid we're just guessing at the possible cause (and it seems that last time we guessed wrong).

Please either upload it here or send it to<EMAIL_ADDRESS>with the subject Issue #1516. Please also update this issue to indicate you’ve done this.

Our videos are locked with DRM and our DRM tokens are only good for 10 minutes.  I cannot share our source so I think we may be stuck here.  It may be that I can provide you with a dynamic URL that will return DRM tokens you can use(along with our custom DRM implementation) but I need to consider this..

Confirmed our subtitles show properly and no playback errors if we use:
MediaSource.Factory.experimentalParseSubtitlesDuringExtraction(false) TextRenderer.experimentalSetLegacyDecodingEnabled(true)

Yes I can do that!  An example manifest URL has been sent to<EMAIL_ADDRESS>

Thanks for the test stream, it's been really helpful to look into this issue. I've fixed the IndexOutOfBoundsException with the commit linked above, which solves the playback error, but subtitles are still not shown on your stream.
Looking in your DASH manifest it seems that your subtitles are raw WebVTT (not encapsulated in ISOBMFF / MP4) but are segmented. I believe this combination is not supported by the DASH-IF IOP 5.2.10 (emphasis mine):

Some services store text adaptation sets in stand-alone IMSC1 or WebVTT files, without segmentation or [ISOBMFF] encapsulation.
This document requires:

Timecodes in stand-alone text files SHALL be relative to the period start point.
@presentationTimeOffset SHALL NOT be present and SHALL be ignored by clients if present.

I appreciate that this stream works on 1.3.1, and not on 1.4.0, so even if this content isn't fully spec compliant it still seems like a regression in the library.
I'm still working on plumbing the right timestamps around to get these subtitles showing up again - I haven't quite got it working yet.

@JonWatson Ah I think the stream stopped working today - would you be able to email a new link so I can continue debugging? Thanks!

Done! Thank you

@JonWatson I've made some hacky local changes which get subtitles showing for your stream, but I need to clean them up before being able to submit (because at the moment they will break other use-cases). Unfortunately I think the stream stopped working again today - would you be able to send a new one?

Thanks @icbaker , new manifest has been emailed


add HwameiStor to CNCF Landscape under Storage category

Signed-off-by: alexzhc<EMAIL_ADDRESS>Hwameistor is an HA local storage system for cloud-native stateful workloads.
Pre-submission checklist:
Please check each of these after submitting your pull request:

[x] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ x] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[x] Have you picked the single best (existing) category for your project?
[x] Does it follow the other guidelines from the new entries section?
[x] Have you added your SVG to hosted_logos and referenced it there?
[x] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[x] Does your project/product name match the text on the logo?
[x] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[x] ~30 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

please consider merge it, thanks.


Review Design Wireframe: Contact Us Page

[x] Visual Hierarchy
[x] Layout
[x] Consistency
[x] Screen size
[x] Usability Principles
[x] Web Content Accessibility Guidelines (WCAG)
[x] Colors
[x] Fonts
[x] Whitespace and padding
[x] Image quality
[x] Iconography
[x] Micro interactions
[x] Error states and feedback
[x] Performance Optimization
[x] Design documentation

See Design wireframe/prototype checklist for more info

Section Our Mission desktop view: The title could align with the top line of the image, buttons could align with the bottom line of the image. Or the space should be equal between the top margin of the title and on the bottom margin of the buttons. Both options to archive better symmetry.

Review finished and comments added for the Design Team

Contact form 'Send' button on desktop and mobile view: Should follow the style guide for buttons and have uppercase letters-fixed
Mobile view: No need to have the empty white space between the 'Our mission' section and 'Contact form'. Does not look so good.-redused spacing, but not removed case of the sectioning and spacing style.

Okay, great. Thank you! Closing this.


Use user friendly error messages on failed transaction.

Airgrabs -> NEB -> Claim -> Submit
Result:

Error
Missing ABI definition when creating action with untyped action data ()

Airgrabs -> WIZZ -> Claim -> Submit
Result:

Error
Encoding error at root: Invalid type jsobj, no encoding methods implemented ()

These errors may be useful for app engineers in logs but aren't useful to users.
As a User, I expect error messages which I understand and which I can act on. Show message explaining what went wrong and what can  I do next to progress.

Sadly there is no error in this situations you can act upon. The reason these two failed is because the owners of those Airgrabs deactivated their tokens, and we just haven't removed them from our interface yet.
We'll look at getting those removed soon so they aren't available for users to try and get errors while performing.


Support, maintenance and updates

Hi @stephenmcd,
I noticed that some pull requests and issues have been standing there for a while now.
I would like to create a PR for the views.form_set, but I am wondering if it would be landed in a near future (if approved of course).
Could you give us a status of this project? Should new admins be integrated? Would we rather create our own fork?
Cheers,
Quentin

@qcaron:
I would not know it for sure, but from what I've seen so far - it's dead, man. The only projects that would likely still get maintenance are mezzanine and cartridge. The rest are left to die peacefully.

Thanks for your answer @barseghyanartur.
Would anyone be interested in this package to be forked to create a django-forms-builder2?
Would anyone be also willing to give this package a few hours a month for guidance, maintenance, tests and improvements?
@stephenmcd: adding new admins would still a better solution. Please let us know 😉

@qcaron:
Nope. I use this package only as legacy for old projects. Nowadays I use django-fobi, which I wrote myself.

Things are much more up to date now.

@stephenmcd:
Awesome, thanks. Another question, though.
Latest PyPI release is dated 2016-09-09.
Latest GitHub release is dated 2012-09-06.
Any plans for better support in nearest future?

Thanks! I'll do my PR and wait a bit if necessary for approval 👍


Highlight messages on press

It's confusing to know which messages you're pressing when you want to open the message options. A highlight when you're pressing them would be really helpful.

I guess you can easily see what message you want to press before pressing and press the right one, also the Action Sheet will pop up immediately and you will have no time to see the highlighted message.
This can be safely closed IMO. @borisyankov


atheris tests

These keep hanging and never complete, both locally and on CI.
https://github.com/valory-xyz/open-autonomy/blob/9c71dc092e68de94bd7614fd0fac492185e272fb/packages/valory/skills/transaction_settlement_abci/tests/test_payload_tools.py#L105-L204

there is another test that causes issues. I don't know if there is a good reason to use atheris over hypothesis, but I suggest we move to all hypothesis to simplify matters if not.
https://github.com/valory-xyz/open-autonomy/blob/9c71dc092e68de94bd7614fd0fac492185e272fb/packages/valory/skills/simple_abci/tests/test_rounds.py#L317-L331

https://github.com/valory-xyz/open-autonomy/blob/9c71dc092e68de94bd7614fd0fac492185e272fb/packages/valory/skills/simple_abci/rounds.py#L58-L60
for the latter lets delete the thing. It's also doesn't need a fuzz test because it's overkill. Certainly when you consider we can use the built-in deque.rotate()

also skipping on abstract_round_abci
https://github.com/valory-xyz/open-autonomy/blob/9c71dc092e68de94bd7614fd0fac492185e272fb/packages/valory/skills/abstract_round_abci/tests/test_behaviours_utils.py#L1131-L1161
https://github.com/valory-xyz/open-autonomy/blob/9c71dc092e68de94bd7614fd0fac492185e272fb/packages/valory/skills/abstract_round_abci/tests/test_behaviours_utils.py#L1730-L1753

can be closed since PR #1613 and #1615


New package: MCParticles v0.1.1

Registering package: MCParticles
Repository: https://github.com/bonStats/MCParticles.jl
Created by: @bonStats
Version: v0.1.1
Commit: 96e41735a081c6ce0026bec23a196b0f45eedaa3
Reviewed by: @bonStats
Reference: https://github.com/bonStats/MCParticles.jl/commit/96e41735a081c6ce0026bec23a196b0f45eedaa3#commitcomment-42835585

Please see update: https://github.com/JuliaRegistries/General/pull/22187
This pull request can be deleted


Add a feature to use memchr's libc feature instead of its fallback

I ran into an issue where memchr's fallback implementation of the memchr function didn't work with what I'm targeting. Using libc's version requires the libc feature to be turned on, which it is by default. However, this crate puts default-features = false, which makes sense because default-features includes use_std, but it excludes libc.

Sorry about the delayed response, I just noticed that Github had disabled all my notifications on this repository.


DBAAS1-107: Database Beta Chip

Description

[x] Adds a beta chip to the PrimaryNav
[x] Adds a beta chip to the breadcrumb on the create page ~(waiting for #8101 to be merged)~

How to test

Check the chip on the primary nav and the Database Create page

For reference, adding screenshots of beta chip displayed in Primary Nav and Breadcrumb:
Preview 📷
Light Mode:

Dark Mode:


CronManager overwrites failed status after one Minute again with "healthy"

If a internal cronjob fails, the cronjob will state correctly "failed". However after one minute (after the cron/run is called once again) the failed status is changed back to healthy - thus a user will always see healthy states (except one minute after the failed job) although the job is failing all the time.
Version Information
We need some information about your versions. You can get all Information in the Admin > Debug Menu

OS:               Debian 12
PHP:              Docker container
Wavelog:          dev

Steps to Reproduce
Create a cronjob which fails and check the status after each cron/run run.
Expected Behavior
The failed status is preserved as long as it was not successful.

I guess this is fixed now :)


Fix integration test action

Hey @twmb, following up on #218, I think this should do the trick using the bitnami/kafka container in Zookeeperless mode. I had to adjust the tests a bit so the KGO_SEEDS env var is read by each test which needs to connect to Kafka.
I also tried to use Redpanda, but there are some issues with it. Could you please let me know how you got the tests to pass against it? It may just be that I'm not configuring it correctly (maybe it doesn't like the fact that I'm running it as a single node?), but my Kafka knowledge is too limited to troubleshoot it. Here's what I tried:
> docker run --rm -p9092:9092 docker.vectorized.io/vectorized/redpanda:latest start --default-log-level=debug --smp 1 --reserve-memory 0M --overprovisioned --set redpanda.enable_transactions=true --kafka-addr <IP_ADDRESS>:9092 --advertise-kafka-addr <IP_ADDRESS>:9092
> # Wait for container to start
> KGO_TEST_RF=1 KGO_TEST_RECORDS=50000 go test -v -count 1 ./...

I pulled the current latest tag of the Redpanda container (sha256:84c8cd98ed7a50e4f378af55600c92c4fb097afab4ec164c3ded9b0e884754c4).
I guess this log entry might be relevant: [ERROR] fatal InitProducerID error, failing all buffered records; broker: 1, err: INVALID_PRODUCER_EPOCH: Producer attempted an operation with an old epoch.
Here are the full logs:
redpanda.log
test.log

As far as I know, Redpanda does not yet support transactions. I encountered the same error myself and read their docs.

I thought it does if you use --set redpanda.enable_transactions=true, but maybe the implementation isn't complete yet.

I thought it was that the community edition did not support it, I may be mistaken

Ahhh: Compacted topic doesn't support transactional processing from the Redpanda logs. That's what is causing my issue. Not sure about the integration tests.

Oh, I see. Thank you for digging that up! ❤ Dunno if the failures I'm seeing are related (maybe @twmb knows), but, hopefully, they'll catch up soon :)

I thought I tested against Redpanda above, but I had a stray Kafka broker alive which allowed the tests to be successful. Redpanda's transactions are a bit WIP right now and should be fixed in the next release. I'll test against it, but this repo should stick to Kafka for now.

OK, makes sense to stick with Kafka for now and maybe add Redpanda as an extra test in the future.
Not sure what to make of the failure... It worked great for me: https://github.com/mihaitodor/franz-go/actions/runs/3257547284/jobs/5348876552. Hope it's not a heisenbug.

I'll see if I can recreate this locally -- a sequence number reset can happen in a few scenarios, but they shouldn't be happening in this test.

Since Kafka is running in Zookeeperless mode, I wonder if it might have some rough corners. Hopefully not.

No, I don't think this has anything to do with Zookeeper. I'm able to use Redpanda fine so long as I don't us a transactional producer. But my use case calls for transactions on a compacted topic.

It looks like Kafka isn't respecting its 5-wide idempotency window. I'm checking to see if something in Bitnami's image specifically changed it, or what. From local reproducing,

send partition 13 sequence # start 0
send partition 13 sequence # start 701
failure, retry the above two
receive OOOSN because Kafka is not de-duplicating the repeated messages

I think this is bringing up an issue that has always been possible in Kafka, but is now visible with whatever changes they're making in Kraft. Apparently, the first produce request's sequence number does not need to start at 0. That's problematic:

client creates topic foo, kafka replies "sure, created"
client sends produce request A with 5 messages, sends produce request B with 5 messages before a response for A is received (base sequence numbers 0 and 5)
request A is rejected with NOT_LEADER_FOR_PARTITION because the topic is not fully initialized, request B is accepted
Kafka now has 5 records locally, starting at a base sequence of 5 and it is expecting 10
client re-sends request A and B
request A is rejected as out of order, since it has base sequence 0

I'll check the Kafka source to see if it truly does accept a non-zero sequence number for the first request.
It seems that Kraft replies NOT_LEADER_FOR_PARTITION for a bit, quite a bit more frequently.

https://github.com/apache/kafka/blob/3e7eddecd6a63ea6a9793d3270bef6d0be5c9021/core/src/main/scala/kafka/log/ProducerStateManager.scala#L235-L236

Very interesting, thanks for sharing that insight!
Out of curiosity, I also tried to see if I can use Confluent's Kafka container in Zookeeperless mode, since they offer some setup example here https://github.com/confluentinc/cp-all-in-one/blob/7.2.1-post/cp-all-in-one-kraft/docker-compose.yml but I guess I'm doing smth wrong with the way I'm volume mounting that silly shell script: https://github.com/mihaitodor/franz-go/actions/runs/3269542233/jobs/5377158865. GitHub has some bugs around volume mounting stuff in service containers and getting around them is very frustrating... Anyway, I guess it will behave the same as the Bitnami one based on your investigation above.

For context (creating Kafka issue now), this is my docker compose:
version: "3.7"
services:
  kafka:
    image: bitnami/kafka:latest
    network_mode: host
    environment:
      KAFKA_ENABLE_KRAFT: yes
      KAFKA_CFG_PROCESS_ROLES: controller,broker
      KAFKA_CFG_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CFG_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CFG_CONTROLLER_QUORUM_VOTERS: 1@<IP_ADDRESS>:9093
      # Set this to "PLAINTEXT://<IP_ADDRESS>:9092" if you want to run this container on localhost via Docker
      KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://<IP_ADDRESS>:9092
      KAFKA_CFG_BROKER_ID: 1
      ALLOW_PLAINTEXT_LISTENER: yes
      KAFKA_KRAFT_CLUSTER_ID: XkpGZQ27R3eTl3OdTm2LYA # 16 byte base64-encoded UUID
      BITNAMI_DEBUG: true # Enable this to get more info on startup failures

How I am running this:
export KGO_TEST_RF=1
export KGO_TEST_RECORDS=50000
export KGO_LOG_LEVEL=debug

and then
docker compose down; sleep 1; docker compose up -d; sleep 5; while go test -run '(Txn|Group)' > logs ; do echo "whoo"; docker compose down; sleep 1 ; docker compuse up -d ; sleep 5; done

https://issues.apache.org/jira/browse/KAFKA-14312
https://issues.apache.org/jira/browse/KAFKA-14313
AFAICT, there is no solution to 14312.
One approach I could try is to sleep 1s after creating topics in the test.

Another odd issue,
__transaction_state partition 33 offset 7 at [2022-10-18 11:15:37.821]
TxnMetadataKey(0) 9f87dc04dc3f4d5b15ef3072c531cf46327278307df8e149fa966462cd40c10b
TxnMetadataValue(0)
      ProducerID           41
      ProducerEpoch        0
      TimeoutMillis        120000
      State                PrepareCommit
      Topics               __consumer_offsets=>[13] e7c7d971626fbaf4bfb33975e57089167939e6acabb4c4fc534eb148462e45cc=>[4 5 12 16]
      LastUpdateTimestamp<PHONE_NUMBER>821
      StartTimestamp<PHONE_NUMBER>311

__transaction_state partition 33 offset 8 at [2022-10-18 11:16:11.419]
TxnMetadataKey(0) 9f87dc04dc3f4d5b15ef3072c531cf46327278307df8e149fa966462cd40c10b
TxnMetadataValue(0)
      ProducerID           41
      ProducerEpoch        0
      TimeoutMillis        120000
      State                CompleteCommit
      Topics
      LastUpdateTimestamp<PHONE_NUMBER>821
      StartTimestamp<PHONE_NUMBER>311

Kafka took 34 seconds to finish a commit within itself. This is causing duplicates, because a rebalance happened in the middle and moved partitions.
Technically, I should be using RequireStableFetchOffsets. I'm not sure why Kafka took 34 seconds to finish a transaction within itself, though -- the client goes to a lot of lengths to avoid the need for RequireStableFetchOffsets. I'll add the option and see how things go ...

I've added a bunch of commits in https://github.com/twmb/franz-go/pull/224 that should address failures, and cherry picked this commit. I've looped tests for a few hours and have not seen any failures locally. Closing this and merging the other PR.
This also finally makes it worth it to enable branch protection (and require all commits to go through PRs), which is also nice because I've occasionally introduced a compile failure without testing (and immediately fixed).
Now that this is merged, I plan to address 214, 220, 221, 222 and then release 1.19. Hopefully the rest of this is quick.

That's really awesome, thank you for all this work @twmb!

For full posterity in case I need it later,
#!/bin/bash

docker compose down
sleep 1
docker compose up -d

until rpk topic list; do
	sleep 1
done

while go test -run Txn > logs; do
	echo "whoo"
	docker compose down
	sleep 1
	docker compose up -d
	until rpk topic list; do
		sleep 1
	done
done

Also if you want to help with #225, I need to change it to expose a port ;)
Turns out redpanda nightly does work, so long as I disable unsafe behavior in tests.


export LottieProps

Hi, Thank you for the great component!
I have a question,
Is there any way I can import LottieProps type to my project?

Hi! I'm not a master of TS, but if someone wants to fix it, PR is welcome.


chore(release): 2.67.0

See CHANGELOG

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 63e11c8488afaee7240315feb8b577f40c135c6f
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


.sequelizerc could be evaluated before generating a service based on Sequelize

After changing the default paths in .sequelizerc, generating a service still uses the same path configuration. For example, a top-level models folder would be created again even if you have changed it in the .sequelizerc.

This issue was moved to feathersjs/feathers#955


feat: create docs for api

In order to facilitate developers' use, API documentation needs to be provided to them.

Use this action  deploy github page to branch gh-page


Add properties to CanNetworkInterface for various interface properties (Bit Timing, Device Stats, etc.)

Plenty of CAN network interface properties retrievable via Netlink sockets that can be exposed within the CanNetworkInterface class.

The work on the recently commited Issue #26 was an enabler for this.


make 'H' cases allowable for OFFLINE_RESPONSE_PROCESSED case event

Motivation and Context
Currently when surveys responses/cases are receipted a case event is created of the OFFLINE_RESPONSE_PROCESSED category, only 'BI' cases are currently allowed for this. We need to make 'H' cases receipt-able within the current process by allowing OFFLINE_RESPONSE_PROCESSED case events for 'H' cases.
What has changed
Add a DB script to add 'H' to the oldsampleunittype column for the OFFLINE_RESPONSE_PROCESSED in the category table
How to test?
make a POST request to the receipts endpoint in rm-sdx-gateway with a caseId of a H case
to test in the docker dev environment:

spin up all the services
create social data by running the setup-and-execute make target in social folder in rm-tools https://github.com/ONSdigital/rm-tools/tree/master/social-test-setup
find an actionable 'H' case
make a POST request curl -X POST -d '{"caseId":""}' http://<IP_ADDRESS>:8191/receipts -H '' -H 'Content-Type:application/json'
tail the case service logs and you should see a log line that looks like this: "Successfully created case event, casePK=2, category=OFFLINE_RESPONSE_PROCESSED, subCategory=null, createdBy=SYSTEM"

 Fix receipting for H cases


Add bold text support in Markdown processor

enables TILvert to convert text between 2 underscores or 2 asterisks into a <b> tag

addressed with commit #9005b6a


"Conflicting sizes for dimension" error when data is nan-only

Datashader 0.5.0
Example of a stacktrace:
  File "/home/p-himik/[...]", line 56, in create_datashader_image
    img = tf.shade(agg, cmap=['yellow', 'blue'], how='linear')
  File "/home/p-himik/soft/anaconda3/envs/cedar2/lib/python3.5/site-packages/datashader/transfer_functions.py", line 351, in shade
    return _interpolate(agg, cmap, how, alpha, span)
  File "/home/p-himik/soft/anaconda3/envs/cedar2/lib/python3.5/site-packages/datashader/transfer_functions.py", line 182, in _interpolate
    return Image(agg.data.view(np.uint32), coords=agg.coords, dims=agg.dims, attrs=agg.attrs)
  File "/home/p-himik/soft/anaconda3/envs/cedar2/lib/python3.5/site-packages/xarray/core/dataarray.py", line 224, in __init__
    coords, dims = _infer_coords_and_dims(data.shape, coords, dims)
  File "/home/p-himik/soft/anaconda3/envs/cedar2/lib/python3.5/site-packages/xarray/core/dataarray.py", line 87, in _infer_coords_and_dims
    'coordinate %r' % (d, sizes[d], s, k))
ValueError: conflicting sizes for dimension 'x_axis': length 2000 on the data but length 1000 on coordinate 'x_axis'

Root cause:
datashader.transfer_functions._interpolate, lines
masked = data[~mask]
        if len(masked) == 0:
            return Image(agg.data.view(np.uint32), coords=agg.coords, dims=agg.dims, attrs=agg.attrs)

When agg.data has an incompatible with this statement dtype (e.g. float64), there will be that ValueError.

Thanks for the info!  I'm a bit confused why agg.data would ever have a type that varied, but in any case, we added code on May 8 to handle the all-NaN case.  Please try the development version of 0.6 using conda install -c bokeh/label/dev datashader to see if that fixes the issue.  It sounds like it might not, but it would be good to know either way.

I'm closing this issue assuming it must be working for you now, but if you've tried the dev release and it didn't improve things, please re-open and explain what happens now.

Sorry, I got caught up in other things.
Nope, still doesn't work, the exception is the same.
MWE:
import datashader as ds
import numpy as np
import pandas as pd
from datashader import transfer_functions as tf

df = pd.DataFrame(np.full([3, 2], np.nan), columns=['x', 'y'])
cvs = ds.Canvas(100, 100, x_range=(0, 1), y_range=(0, 1))
agg = cvs.line(df, 'x', 'y', ds.max('y'))
img = tf.shade(agg)

I'm not a collaborator (yet :) ), so I can't re-open an issue that I didn't close.

Fixed by https://github.com/bokeh/datashader/pull/439 .


Navigation buttons overlap with the more options toggle in the "unreleased" home structure.

🧐 Have you read the FAQ and viewed similar issues?

[X] I have read the FAQ
[X] I have checked older issues, open and closed
[X] I did a clean install of SpotX as described in the FAQ

Сountry of your account
USA
What is your Spotify Plan?
Premium
Do you have Spicetify installed?
No
ℹ Computer information
- Spotify: <IP_ADDRESS>7.ga4397eb7
- Windows: Windows 11 21H2 22000.588
- PowerShell: 5.1.22000.588

📝 Description
The navigation buttons (back/ forward) overlap with the more options button on the top left.
📸 Screenshots

yes I saw this bug, this Spotify theme is still in development. Maybe this will be fixed in the new version.

in version 93, the devs didn't fix it again so I temporarily fixed the indentation in the css myself.

@amd64fox zooming the client out it still ends up overlapping a bit. Hopefully the spotify devs end up fixing it soon enough.


Add files via upload

Hi, my name is Yaroslav and I'm independent validator from Ukraine.
I'm a system administrator, and I'm a Full-stack Perl, php /JavaScript Developer (Perl, PHP, Node + React 4+ years experience).
Uptime my dedicated AMD Ryzen server is 99.9%, and it's always online, Location - Hetzner DS, FINLAND/Germany (if necessary, I can rent a unique location)
Secure and reliable individual PoS/PoW validator, crypto enthusiast. 24hr management & monitoring! (Grafana + Prometeus + Telegram alerts)
I have experience with some testnets nodes: Celestia, KYVE, Defund, Minima, Massa, Axelar.
I hope that your node will give me a good experience.

Hi, my name is Yaroslav and I'm independent validator from Ukraine.
I'm a system administrator, and I'm a Full-stack Perl, php /JavaScript Developer (Perl, PHP, Node + React 4+ years experience).
Uptime my dedicated AMD Ryzen server is 99.9%, and it's always online, Location - Hetzner DS, FINLAND/Germany (if necessary, I can rent a unique location)
Secure and reliable individual PoS/PoW validator, crypto enthusiast. 24hr management & monitoring! (Grafana + Prometeus + Telegram alerts)
I have experience with some testnets nodes: Celestia, KYVE, Defund, Minima, Massa, Axelar.
I hope that your node will give me a good experience.


Add Vulkan renderer

Hi!
It would be nice to support Vulkan API, since it's already released.

I thought 3.0 would be for ES3 and not Vulkan

yeah vulkan is still not stable or widely supported
On Fri, Feb 19, 2016 at 9:37 AM, Nuno Donato<EMAIL_ADDRESS>wrote:

I thought 3.0 would be for ES3 and not Vulkan
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-186199577.

http://vulkan.gpuinfo.org/ - this will track list of devices that support Vulkan
As for drivers, now there are:
Linux Desktop - Nvidia, Intel
Windows 7+ - Nvidia, AMD
Android 6.0 - Qualcomm
PowerVR also has certified driver.
AMD driver for Linux is incoming ( according to Khronos site it's still not certified ), but I don't know the state of Intel's one for Windows.

And Just for information, AMD has said that their Vulkan driver will be shared between Windows and Linux and even more exiting, will be opensourced ! Same for their opencl driver.

And here's the list of GPUs that Khronos has officialy acknowledged as conformant - https://www.khronos.org/conformance/adopters/conformant-products

I think that this link could help you
https://community.arm.com/groups/arm-mali-graphics/blog/2016/02/16/porting-a-graphics-engine-to-the-vulkan-api
And here is a good description about the revolutionar concept of renderpasse
http://gpuopen.com/vulkan-renderpasses/
Other Vulkan blog posts http://gpuopen.com/tag/vulkan/
Imagination (power VR)  has also posted good blogs.
Some really good demos and examples for learning Vulkan https://github.com/SaschaWillems/Vulkan
And the official documentation :
https://github.com/KhronosGroup/Vulkan-Docs
Other official complementary stuff : https://github.com/KhronosGroup/

This is nice summary, but it does not include error handling and capabilities checks - https://renderdoc.org/vulkan-in-30-minutes.html
Also, nvidia made open source C++ wrapper for Vulkan - https://github.com/nvpro-pipeline/vkcpp

wrong button, sorry

@Marqin thx, Just for precising AMD is not yet in the list because they still haven't passed the Vulkan conformance test suite, but their driver already work well on the first Vulkan game port Talos(better than Nvidia currently) .

Thanks for the all references. We are all also very excited about Vulkan, but don't put your hopes too high, it won't be a priority for a while.
It's not only about available drivers, I guess we can trust the industry to make good drivers available within a few months, but it's more about focusing the work on what will be useful for gamers. All the GPUs that are meant to get Vulkan support are relatively high end, and thus only a small fraction of gamers (and game devs) own them. It will likely be another two years before such hardware is widespread enough for it to be sensible to make games for the masses with it.
So the focus will first be on OpenGL ES 3.0/3.1, and once it's working (which will already be a HUGE improvement), there will probably be some focus on implementing Vulkan support too as alternative.
Of course contributions towards Vulkan support will be very welcome, just wanted to clarify what @reduz has expressed lately regarding what the focus will be for Godot's core developers.

@Marqin your links are good =)  but this link https://renderdoc.org/vulkan-in-30-minutes.html
Forgot to describe one of the main concept of Vulkan/direct x 12, the async compute shader
http://gpuopen.com/maxing-out-gpu-usage-in-nbodygravity/
This can give a 45~% fps jump !
Note that this thing was used on consoles.
Also sorry for my bad english

@akien-mga
You say "All the GPUs that are meant to get Vulkan support are relatively high end, and thus only a small fraction of gamers (and game devs) own them. It will likely be another two years before such hardware is widespread enough for it to be sensible to make games for the masses with it."
Not on pc desktop, all openGL 4.x compatible gpu cards are Vulkan compatible !
GCN 1.0 fully support Vulkan.
I don't know for nvidia and Intel.
Also the need of performance for 4k and Virtual Reality and steam OS will accelerate it's adoption.

All PC gpus from 2012 are supported currently.
And maybe than olders will have a subset of Vulkan in the forthcoming drivers. So all gamers have a compatible card, and Vulkan will be supported on all OS, even BSD.
Also a big part of the Vulkan driver implementation will be shared with the existing opengl implementations, so more they will be Vulkan Games (and de facto game engines) better we will have opengl drivers :)
This is vertuous !
Again sorry for my bad english

@LifeIsStrange Panda3D and few propertiary ones are already working so it probably won't be first.

All PC gpus from 2012 are supported currently.

And nv is probably working on Fermi support, so even older gpus will be.
Little offtopic @akien-mga :

So the focus will first be on OpenGL ES 3.0/3.1

But OpenGL ES 3.2 was released long ago and it supports the same hardware as 3.1, why not 3.2?

I know you don't have resources to do Vulkan now, but please not close this issue, so it can stay as resource list and future milestone.

The problem is not PC support, this will be eventually resolved within a
year or so. The main limitation is adoption on Mobile and HTML5.
As a lot of Godot users make games for Mobile, we must give priority to
APIs that work on such platforms. OpenGL ES 3.0 and 3.1 are on the way to
being widely standardized so they get priority.
Also, GLES3 is already very powerful and we will be able to enormously
improve the rendering quality thanks to it
On Fri, Feb 19, 2016 at 11:26 AM, Hubert Jarosz<EMAIL_ADDRESS>wrote:

I know you don't have resources to do Vulkan now, but please not close
this issue, so it can stay as resource list and future milestone.
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-186235285.

To clarify, the intention is not to give more priority to mobile than PC,
but that both platforms must get the same attention due to the diversity of
our userbase.
On Fri, Feb 19, 2016 at 11:38 AM, Juan Linietsky<EMAIL_ADDRESS>wrote:

The problem is not PC support, this will be eventually resolved within a
year or so. The main limitation is adoption on Mobile and HTML5.
As a lot of Godot users make games for Mobile, we must give priority to
APIs that work on such platforms. OpenGL ES 3.0 and 3.1 are on the way to
being widely standardized so they get priority.
Also, GLES3 is already very powerful and we will be able to enormously
improve the rendering quality thanks to it
On Fri, Feb 19, 2016 at 11:26 AM, Hubert Jarosz<EMAIL_ADDRESS>wrote:

I know you don't have resources to do Vulkan now, but please not close
this issue, so it can stay as resource list and future milestone.
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-186235285
.

I understund, but who care about smartphone "Games"? The fact is that the tactil control limitations destroy the possibility of creating true Games. The second limitation was the power, limitation that justly Vulkan aims to destroy.
And Html Games are currently an ultra minority (the only popular is agar.io, which can be done on openGL 1.0) .
Also Vulkan will arrive on virtual Reality and on consoles, ps4 and Nintendo NX and steam machines.
The vast majority of 2017 Games will be on Vulkan, don't lose this train.
Also ARM 2011 GPUS, POWER VR 2012 gpus and currently qualcomm 2013 gpus will have Vulkan support. Google heavily push Vulkan.
Mediatek will probably fully support it.
And there is rumors than qualcomm will use the opensource freedreno driver, if it's true, the community could add support for 2012 cards.
Also all the tizen drivers will be opensource and probably could be ported to Android.
Vulkan will be everywhere supported on Android.
And pc/console/VR/AR are far more important
But this is your software, you are free to do what you want obviously.
Again sorry for my bad english.

Oh and for html games, currently browser have very bad perf, the only browser which has good performance is Firefox, but has sadly less than 20/15% of marketshare.
http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-results/

I understund, but who care about smartphone "Games"?

Many, many, many Godot users. And don't overestimate the hardware actual gamers have at their disposal. I'd bet that the number of gamers (not only hardcore gamers but also casual gamers that many Godot devs target) with Vulkan-compatible hardware is very low, probably something like 20-30%. Be it on desktop (how many Intel HD Graphics 4000 or 4400?) or mobile.
Again, nobody said that we won't support Vulkan. Just that the priority will be first OpenGL 3.0, for all the good reasons explained above.

"I'd bet that the number of gamers (not only hardcore gamers but also casual gamers that many Godot devs target) with Vulkan-compatible hardware is very low, probably something like 20-30%. Be it on desktop (how many Intel HD Graphics 4000 or 4400?) or mobile."
No, I think there is more than 90% of casual gamers supported on PC for Vulkan.
No need of Intel HD 4000, the 3000 is supported which date of 2012.
We are on 2016, Vulkan pc Games will massively come on 2017 and before for VR Games
This will do 5 years, pc live 5 years max with the current obsolescency +Windows bloat +Windows virus.
And for Android all 2012 cards will probably be supported, and smartphone lives 2/3 years... So all smartphone will be compatible in end 2016.
And you speak about 2.1 opengl compatibility oO this cards was before 2004, this is a ultra négligeable minority with a Windows unsupported.
Again do what you want ! But I think that you are wrong about the hardware support of Vulkan.
And thanks for making awesome free software for all :)

I understund, but who care about smartphone "Games"?

http://www.wired.co.uk/news/archive/2015-11/03/king-candy-crush-activision-acquisition

Yes, you may not like smartphone games and might be far from wanting to
develop them, but a large amount of Godot developers use it for mobile. We
can't simply ignore them.
On Fri, Feb 19, 2016 at 1:05 PM, Hubert Jarosz<EMAIL_ADDRESS>wrote:

I understund, but who care about smartphone "Games"?
http://www.wired.co.uk/news/archive/2015-11/03/king-candy-crush-activision-acquisition
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-186277915.

We can't simply ignore them.
Godot is best open source mobile game engine, which attracts many people who are interested in mobile gamedev. And indeed we should not abandon them.

No need of Intel HD 4000, the 3000 is supported which date of 2012.

2012 is only 3-4 years ago. My girlfriend has much older PC. My PC is also much older ( but I've bought new GPU recently for some AAA games ).

Think about it, it's easier to find financing for making mobile games than
PC games, so a large amount of developers do mobile games even if they
don't like the genre. Godot helps them bring food to the table by
supporting mobile. Think of the children :P
On Fri, Feb 19, 2016 at 1:06 PM, Juan Linietsky<EMAIL_ADDRESS>wrote:

Yes, you may not like smartphone games and might be far from wanting to
develop them, but a large amount of Godot developers use it for mobile. We
can't simply ignore them.
On Fri, Feb 19, 2016 at 1:05 PM, Hubert Jarosz<EMAIL_ADDRESS>wrote:

I understund, but who care about smartphone "Games"?
http://www.wired.co.uk/news/archive/2015-11/03/king-candy-crush-activision-acquisition
—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-186277915
.

No need of Intel HD 4000, the 3000 is supported which date of 2012.

Reference? When I checked two days ago Intel HD 4000 and 4400 were not planned to be supported.

Thanks @reduz , you made me laugh today :joy:

@Marqin I don't speaked about amoral games firms, but about users.
Candy crush and others Android like software aren't Games, but more a way for forgot it's life or the fact that the user has no meaning in his life.
This Games are cancers and has no need of opengl es 3.1/2.
For doing my antithesis, there is few true Games that arrive on Android, like don't starve, life is strange (this is my name <3)or downwell.

And this will lag without Vulkan.
And I bet to you than there will be far more Vulkan games than opengl es 3.1 Games.

@akien-mga
On Wikipedia
"Ivy Bridge 22 nm 	2012-Apr 		Core i3-/i5-/i7-3000"
On the compatible hardware rubric.
https://en.m.wikipedia.org/wiki/Vulkan_(API)

@LifeIsStrange You have to think of us, Godot Developers, as Knife manufacturers. We just make a tool in hopes of it being useful for everyone, even if that use implies that somebody will murder his wife with it.

On Wikipedia
"Ivy Bridge 22 nm 2012-Apr Core i3-/i5-/i7-3000"
On the compatible hardware rubric.
https://en.m.wikipedia.org/wiki/Vulkan_(API)

From the reference they give on Wikipedia: "The Intel Open Source Technology 3D Graphics Team is excited to announce the availability of our Vulkan driver for fifth and sixth generation Intel® Core™ processors (Broadwell and Skylake). The driver passes the Vulkan 1.0 Conformance Test Suite on these platforms and have experimental support for older platforms."
That doesn't explicitly state Ivy Bridge and later. But there is hope indeed :)

@LifeIsStrange If you don't want to have game engine that is versatile, you can always use Panda3D which is open source, only for PC and plans to have Vulkan support ( and uses Python for scripting ).
Or sponsor some programmer to do Vulkan for Godot ;-)
Personally, I think it's great that Godot supports so many targets, which makes him the only real open source alternative for Unity ( which is great, because it allows many not-much-programmer people to express themselves via gamedev ).

"Godot is best open source mobile game engine, which attracts many people who are interested in mobile gamedev. And indeed we should not abandon them."
But justly... If you want to stay the Best open source mobile game engine you need to support Vulkan before end 2016.
Why ? Because there is a revolution in the mobile game industry, a lot of powerfull pc Games studio like bethesda, activition, ubisoft and Dice have all announced that they are really interested on the Android Games market.
But this Games will be heavy AAA, and they will run on Vulkan.
Think that the majority of smartphones lives 2 years....  And that the 2012 socs will be supported so almost all smartphones will have Vulkan support. Google is also heavily pushing Vulkan and the Android pc distribution is in revolution with remix os like :http://wccftech.com/remix-os-multi-window-android-for-pc-and-mac-announced/
Vulkan is a game changer, not opengl es 3.0!
Vulkan will give a 2.5x perf improvement on the smartphones.
You are also the only unity/unreal engine opensource conccurent, if you don't support Vulkan you will lose the pc and VR and consoles market.
Vulkan is the graal that the Linux gamers ever needed !
Please understund those facts.
Again sorry for my bad english.
Also you could reuse your Vulkan implementation in your future opengl es 3.0 implementation.
Like described here https://community.arm.com/groups/arm-mali-graphics/blog/2016/02/16/porting-a-graphics-engine-to-the-vulkan-api
Sorry for taking your time but your decision is very important

@akien-mga
"The driver passes the Vulkan 1.0 Conformance Test Suite on these platforms and have experimental support for older platforms."
That doesn't explicitly state Ivy Bridge and later. But there is hope indeed :)"
No this garantuee us that they will support Vulkan, the "experimental"  is driver support, not hardware support , they will not work on drivers support if this gpus don't support Vulkan à the hardware level I guess . And Intel is better placed than us for knowing which of their gpu support Vulkan

Performance improvements is just an advertisement pitch. In real situation I will be impressed even if there's going to be ~1.5 performance improvement.  It's going to happen sometime soon, Godot game devs won't lose their bread and butter if Vulkan won't be supported for some time.
Be a bit more cautious before jumping on bandwagon and diverting resources from important tasks.

@reduz
"@LifeIsStrange You have to think of us, Godot Developers, as Knife manufacturers. We just make a tool in hopes of it being useful for everyone, even if that use implies that somebody will murder his wife with it."
I have already say, do what you want, this is your software, I Just try to convince you than Supporting opengl es 3.0 is useless compared to Vulkan and that will have a big lack compared to unity/unreal.

With openGL es 3.0, godot will loose the pc market, the VR market, and the upcoming consoles market which will use Vulkan (ps4, Nintendo NX and steam machines). And even if you don't care about this markets, Supporting openGL es 3.0 is also the bad choice on Android.
There will be far more demand for Vulkan Games than opengl es 3.0 Games on Android. It will be supported almost everywhere in end 2016 because the smartphone lives 2 years. And all the pc Games which will be ported to Android will use Vulkan for performance. Also Vulkan is espected to be far more efficient.
And finally the majority of Games will be ported from the Apple metal api, which use Vulkan features like async compute and multithreaded commands.

@arcfutahito
Ok sorry.

Supporting opengl es 3.0 is useless compared to Vulkan and that will have a big lack compared to unity/unreal.

Big lack of what? Do you know what Vulkan is for?

Yes, Vulkan will not give your app a 2.5fps jump.

With openGL es 3.0, godot will loose the pc market, the VR market, and the upcoming consoles market which will use Vulkan (ps4, Nintendo NX and steam machines).

VR has nothing to do with Vulkan, it works in any API. PS4 and NX so far have not announced Vulkan support, so this is speculation.

And even if you don't care about this markets, Supporting openGL es 3.0 is also the bad choice on Android.
There will be far more demand for Vulkan Games than opengl es 3.0 Games on Android. It will be supported almost everywhere in end 2016 because the smartphone lives 2 years.

Try again:
http://developer.android.com/about/dashboards/index.html
ES3.0 has been out for years and it's still not even half of the market. It will obviously take Vulkan a long time to reach that point. 2016 is not even close.

And all the pc Games which will be ported to Android will use Vulkan for performance. Also Vulkan is espected to be far more efficient.

Dude, I'm a Khronos advisor and had access to Vulkan for months before it was released a few days ago. Vulkan IS NOT about performance. This kind of stupidity you get by reading too media articles who have naturally no idea about this because they never developed games.
Vulkan is about having a simpler API that makes drivers easy to develop. Currently OpenGL and DirectX became so complex that making optimized and bug free drivers was a huge amount of work.
Vulkan is simpler and puts that burden into developer's shoulders, but in exchange we get better compatibility and drivers.
In real use case scenarios, you can get a little performance boost when drawing very large amount of objects from CPU, but that performance improvement you speak of is illogical and does not exist.

And finally the majority of Games will be ported from the Apple metal api, which use Vulkan features like async compute and multithreaded commands.

Apple has not announced Vulkan support yet, neither for OSX or iPhone, so this is only speculation from your part.
Seriously, I understand you are excited about it, but Vulkan is being promoted for reasons different to the ones you believe. It has nothing to do with performance, it's being promoted because it represents a lower driver development cost for 3D hardware manufacturers.

I just want to say that... so many my customers use over 2 years old phones, even over 3~4 years.

Vulkan is simpler and puts that burden into developer's shoulders, but in exchange we get better compatibility and drivers.

Actually Vulkan makes it easier to create code that will not be compatible.
Also, many people should keep in mind that simpler means less bloated not easier.
I've read some vulkan docs and I'm going to write some vulkano code after my exams, but it looks like I'll have to write tons of bloat code that won't be any help for my app.
Also, Compute Shaders are supported since OpenGL 4.3 ( which is sadly not available on Macs ), and OpenGL has many threading features and it's possible to reach very low driver overhead with OpenGL.
Oh, and the fps gain you are talking about. It won't magically happen. Vulkan just makes AZDO easier, by being low-level.
And... Most engines you mentioned have paid programmers. And we don't have enough staff to make it happen.
Keep in mind that moving to OpenGL ES 3 will also give us much better renderer than today. And much wider audience than Vulkan.
It will be much better to first support brilliant Physically-based rendering in Godot, and then think about optimising it with Vulkan.

I'm really excited about Vulkan too! :) However, most games that will really see a benefit from it in the short term are not the types of games people are making in Godot. I think it's a good long term goal for it to implemented, but there are much bigger fish to fry first.

Anyways, I'll just leave this here: http://arstechnica.com/gaming/2016/02/vulkan-benchmarks-a-boost-for-amd-and-nvidia-but-theres-work-to-be-done/

Anyways, I'll just leave this here: http://arstechnica.com/gaming/2016/02/vulkan-benchmarks-a-boost-for-amd-and-nvidia-but-theres-work-to-be-done/

To be fair though, this comparison really needs to be redone once Croteam is fully done with their Vulkan port. These graphs only include stage 1 of 3 of their porting process which was to just get it switched over to Vulkan. This seams to be the most trivial and least beneficial part and doesn't include any multi-threading or other optimizations. So the 4 core and 6 core comparisons are nearly useless.
http://steamcommunity.com/app/257510/discussions/0/412447331651559970/#c412447331651997070
Summary:

Port <-- This is where they're at
Multi thread
Redesign engine for Vulkan.

So in short, a comparison to DX11 is not an equal balance because Talos was designed from the beginning to use DX11. The current Vulkan state of it is far from even being completely ported.
Hope this helps :)

Is Godot can manage two renderers to give some choice ?
If it's the case the current Opengl ES 2.0 is good deal for anything 2.0 ( Dog Mendonça is a so beautiful game ;) ) and probably for 3D mobile games.
So why not trying to implement the most advanced solution for an alternative renderer ?

hey I and many others developer are making games for mobiles and we need open gl es 3.0 so much .
I am sure that vulkan is great and I was one of the people that writes in the forum that vulkan is coming but the real issue is that vulkan does not support mobile gaming , android is so slow for updating their system most of phones does not have android 6, and ios does not support vulkan and it will be long time to intel , nvidia, amd  make vulkan driver for their old card graphics and that leaves majority of gamers without a supported system.

Is Godot can manage two renderers to give some choice ?
It can, but there are not enough programmers, and there are many more importand features that need to be implemented. Also some will grant better 3D ( OpenGL ES 3, deferred shading, physically-based rendering, etc. ).

What is the GLES 2 limitations for mobile devices games ?

@DriNeo Well, GLES 2, according to Google Dashboards posted by reduz (interesting read actually, I recommend checking it) is 53.2% of market. On the other hand you have fancier graphics and almost none supported devices in the wild.

vulkan is only supported on linux and partially on windows . is pointless to add support right now. maybe in a few years

https://www.reddit.com/r/linux_gaming/comments/48k9gz/any_word_on_vulkan_support_in_unity_unreal_engine/d0led36
Can't really dispute what this guy's saying...

Wtf "vulkan is only supported on linux and partially on windows . is pointless to add support right now. maybe in a few years"
Good driver crossplatform support will come in the next months not the next years...

So, I'm thinking of adding experimental Vulkan support to godot. I just like to know if the developers are at all open to accepting a pull-request about it.

@ShabbyX you should probably hang around the IRC chat and talk to @reduz. If you follow the discussion, you can see that a rendering engine rewrite will be happening soon (to support Open GL ES 3.0) and if you use the current engine you'll certainly need to rewrite it for Godot 3.0.

@vnen, thanks for the info

Please wait until we finish the GLES3 renderer in a few months, which will
lead us to severely changing the rendering API. Once it stabilizes again
feel free to work on one, as it should not change muh more
On Aug 11, 2016 14:00, "Shahbaz Youssefi"<EMAIL_ADDRESS>wrote:

@vnen https://github.com/vnen, thanks for the info
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/3729#issuecomment-239223290,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21hBWryu2qSBTr6i_fxnfvWhY0WGks5qe1UVgaJpZM4HbRXC
.

@reduz, Alright. Just pay attention that keeping Vulkan in mind would certainly affect the design of the API. In particular, Vulkan likes it if you can declare up-front what resources (images, buffers, shaders) you use, what pipelines there are etc. So when designing the new GLES3 design, try to make it possible for all such information to be available before rendering start. Better yet, before even the game or "level" starts.

I guess this approach helps to detect requirement from target system when compiling game, so that user can be warned if his 2D game relies on some highly slow shader that is not available on all platforms.

Unity just unveiled a preview of their Vulkan editor. I know there has been a debate in this thread about the merits of Vulkan, but Unity is citing speed as the largest benefit of Vulkan, claiming a 35% increase in frame render times on Android.

But to gain 35% increased performance, IFIAK, it requires Android N (7.0).
Currently, less than 0.1% devices of all android platform.

Unity just
Actually it was unveiled 2 weeks ago by some Unity devs - https://pbs.twimg.com/media/CsLexLkXgAUjvS7.jpg:large

Are there any software emulation drivers for Vulkan?

Are there any software emulation drivers for Vulkan?

Not that I know of. I think the performance would remain problematic anyway, even with a generally faster renderer, especially on mobile devices.

ANGLE is being ported to Vulkan, so it should be possible to use it as an OpenGL driver https://chromium.googlesource.com/angle/angle/+/master/README.md

I understund, but who care about smartphone "Games"?

The whole healthy living world cares.
PC's, in most short words, when it came to games always was "not compatible with everydays real life".
Players had to either drop games and go to work to live, or rust along with PC while not working, leveling game character whole day and night, but then how would they water up his game industry to grow ? This situation had eventualy chance to outlast at some level, because of no other alternative and devotion of many developers who create new things more for intelectual pleasure than dough.
However, the alternative has arrived and now player devotion to his games no more collides with healthy real life. Hardcore gamers might work, go to school, do whatever, still having his games along with them whole time, play anywhere and anytime like real hardcore gamer like to do.
(some games like for eg. Pokemon GO went allready even further and blends with real life litrally)
Because, theres more people who "have life" (therefore cash) and who thanks to mobile devices might still become hardcore gamers 24/7/365 (without dilemma life or gaming) - mobile games industry incredibly grows.
Global Games Market statistics below
mobile games 45% with 50 Billion revenues and raising while PC market 25% constantly going down, not mention stationary consoles which sink along with PC. Look at the progression of statistics.

GL ES
I see here and also following discussion about GL ES 3 in many other threads.
I think, expanding to GL ES 3 is good idea, as its obvious that while time passing GL ES 3 will be turning out more common, eventually replacing GL ES 2 somewhere in the future,
however for the time being when i think about it - it not looks that easy as it might seem.
If you look at the market and customer behaviours its not hard to notice that not everyone lightly buy stuff like Samsung Galaxy S7 each fiew weeks. These are top of the mountain.
Majority of customers like in every shoping area, are lead by typical scheme, to buy best possible thing  for lowest possible price.
So the middle price shelf, is always in very good condition, having high sales for the masses, especially while chinese manufacturers, importers and sellers around the world, exploiting this by feeding market with very nice brand new devices which looks, feels and works like top ones, just have no Samsung or iPhone logo and costs 2 or 3 times less. (like customers used to say)
Customers know that its good to have more RAM, cores, speed, flash, most recent android version ect, but many people dont know (care) what lies deeper (how it work), what is GL ES, or that it even exists.
These areas are where manufacturers cuting costs using fast multicore chips (eg. MT6592 octa core CPU @ 2Ghz, sounds nice isnt it ?) yet at nice cheap price because of Mali 4XX or similar GPU's.
All in all we can assume, that while android versions will raise, the GL ES version will not follow it at the same speed, because of what was said above, and might stay around for little longer than we expect.
According to google app store theres still around 50% of devices which use GL ES 2, and people buy new phones with it.
In this situation, how will one explain to someone (ex. 50% of game users which may be 1 million of people) who will came and say "Why this game works much better on my friends phone and lags badly on my ? i have Android 6.x, 8 core CPU, lots of ram, Just bought this phone yesterday, can you fix it ?".
Replying in google store to such comments, the way - "go buy new phone" is a thing i would never do...
I strongly believe that while GL ES 3 will be in process of implementing, when all 3D coding gurus will awake and give his attention to this task, many new, cool and awesome ideas will come out, which might put new light on GL ES 2 optimisation that arent so obvious today and lies hidden in shadows.

Juan has been working on a new renderer for Godot 3. I'm going to make the wild assumption that, while it probably won't contain it, he's probably at least keeping Vulkan support in mind.
https://twitter.com/reduzio/status/778983748532629505

@reduz said on many ocasions that Godot will not support Vulkan yet, that will be only update to GLES 3.

@reduz said on many ocasions that Godot will not support Vulkan yet - with 3.0 there will be only update to GLES 3 and new PIR renderer

There's really no point in @reduz implementing Vulkan support now anyway. Most games being made in Godot aren't performance hogs. If your game is performing poorly there is probably something else that can (and should) be done to improve it.
I personally love the many new improvements they've done that probably wouldn't exist had he been spending time on learning and implementing Vulkan. Pushing it off for a while will probably result in a much better Vulkan renderer because more "best practices" and "common pitfalls" will be more well known and easier to research in a year or three. :)

Godot renderer isn't good and compicated enought to even need Vulkan :D First let's implement some good graphics and then think about APIs. Just using Vulkan won't make your game beautifuly automagically.

Godot aren't performance hogs.

And if they are, they mostly hog on CPU because of GDscript and not on GPU.

From what I read in other posts by Juan he mentioned several times that GLES 3 is going to be supported for Godot 3.0 but that Godot will eventually support Vulkan just not right now. Since the contribs and lead devs on Godot are a handful I think he is trying to allocate time and resources to what makes more sense in the short run. Vulkan needs to be more mainstream perhaps in a few years .

At the bottom line, Godot will support Vulkan someday, but not near future.
If someone made a game with Vulkan, it's just for a few gamers in all kinds of game platform market.

Running Godot on Vulkan once GLES 3 is ready is possible is ANGLE support is added as alternative renderer.

AFAIK ANGLE is already used in UWP builds.

Adding ANGLE support for other platforms should be (relatively) trivial.

Saw this news, thought id post. Not sure if its of use or not...
https://www.gamingonlinux.com/articles/amd-have-announced-anvil-an-mit-licensed-wrapper-library-for-vulkan.9378

I'd like to say that I'm starting to work on my thesis, which is to create a Vulkan renderer for Godot. My intent is to learn how to use Vulkan and contribute to this awesome project. I also believe adding this feature can attract more users to the engine.
I can't promise anything and this is totally unofficial. It's also the first time I make any kind of contribution to an open source project, so I hope it all goes well.
I will be using the GLES3 renderer features, and I don't intend to add any other new features to the engine, at least not for now.

This comment history is awesome, @LifeIsStrange got destroyed!! #rekt

Cool, but this is no corrida and we don't retrospective commenters.

@alugarius
Destroyed is a childish word..
I advocated Vulkan and that was not dumb, in parralel of it's avantages, it would have done much
publicity to Godot as an early adopter engine and hence perceived as "future-proof",but we can't go back in time.

@LifeIsStrange If you would have read the comments, you would have seen that Vulkan will be supported somewhere in the future. But as of now, there are more reasons to use gles3.
@akien-mga sorry, couldn't hold me

Closing. Not going to happen as it's way more cost and effort than benefit. Will most likely switch in a few years.
However, if anyone else wants to make this port and maintain it (unlikely due to how much work it takes), feel free to do it. Core devs will not work on it.

If you are interested in working on a vulkan renderer, please open a new issue/PR.


Start building .conda artefacts

This feedstock is one of the places (perhaps the last? 🤔) that we missed for https://github.com/conda-forge/conda-forge.github.io/issues/1586

Wait, I thought the default in conda-build changed to .conda? Did that not happen or do we have an old pin lying around?

The default never changed. 🤦

The default never changed. 🤦

It's still planned, but hasn't happened yet: https://github.com/conda/conda-build/issues/5183


Add Hindi translations

Adds Hindi translations

Please import and add locale to locale.ts

Does this look all good or is it missing a space? Can a native speaker confirm.

On standby until we get the remaining translations


fix(Modal): closeOnEscape not included in initial props in docs

Hey guys, I really like this feature; I just noticed that it wasn't in the initial prop documentation.
Steps to Reproduce

Visit https://react.semantic-ui.com/modules/modal#modal-example-close-config
Search for all references to close in the props portion of the page.

Expected
closeOnEscape | false | {bool} | Whether or not the Modal should close when the Escape key is pressed.
Result
Information only down the page.
Cheers,
Jeff

closeOnEscape is Portal prop and its definition is aviable in Portal docs. However, it's really should be defined in Modal. Duplicate #1169.


Add aws ecr actions

I've added a new AWS scaffolder action to create an ECR repository
in the near future, I'll add other actions to manage the ECR resources for AWS
:heavy_check_mark: Checklist

[x] Added tests for new functionality and regression tests for bug fixes
[x] Added changeset (run yarn changeset in the root)
[x] Screenshots of before and after attached (for UI changes)
[x] Added or updated documentation (if applicable)

Hello @kissmikijr can you please take a look at this?
Thanks.

Hello @kissmikijr it failed in prettier check, I ran the required check and fixed the issues, can you please rerun the check again?
Thanks.

all required changes are applied now @kissmikijr please take a look.

Hello @kissmikijr  please check one more time

Hello @kissmikijr  I think there's some issue with the checks can we rerun it again?

Thank you I triggerd it again!

Looks ready to ship! I'll wait the build to pass and going to merge it! thank you for this contrib!


Where's routerChannel events are triggered?

Maybe this could be my inattention, but... I've reading the code, do a find in Sublime Text and not found where this routerChannel events are triggered.

It's not, that was removed at some point


"prettier.eslintIntegration": true not working on Windows 10

I've run into this problem with the prettier-eslint-vscode extension and tried yours without any luck as well.
I'm running this version of vscode.

and prettier gets applied but eslint --fix does not.

I've just tried a freshly installed insider on Windows 10 and eslintIntegration without any trouble.
Can you share a minimal input code and your settings which exposes the problem you have?

Hi @CiGit. Thanks for the response!
With that info I was able to track the problem down to, strangely, the Git Lens extension.
Can you install it and see if it breaks for you?

Tested on Archlinux, stable vscode, a lot of extensions (including git lens) without having errors. Will try on Windows 10 later.
Is this issue relevant to #96 ?

I don't think #96 is related to my issue.
Just to isolate further I disabled every extension except for yours and GitLens and added only "prettier.eslintIntegration": true to my settings.json file.
The problem is 100% reproduce-able.
With GitLens, no eslint --fix. Without GitLens it works as expected.
The same thing happens with @RobinMalfait's extension.

That's really weird...
Windows 10 + vscode stable + git lens without troubles.

Please update to latest version, It updates prettier-eslint...
It's worth a try 😆

Definitely weird!
New version doesn't fix anything. :-/
The only thing I can think of is that I'm on vscode-insiders.
I'll do without GitLens for now. 😄
Thanks for trying.

Tried with Insider + Git Lens + eslintIntegration.
I've got the same behavior you described. It seems it also breaks eslint extension.
Quick and Dirty fix
By patching ~\.vscode-insiders\extensions\eamodio.gitlens-3.5.1\node_modules\zone.js\dist\zone-node.js:816
 if (ZoneAwareError[stackRewrite] && error.originalStack) {

to
if (ZoneAwareError[stackRewrite] && typeof error.originalStack === 'string') {

Prettier-vscode runs smoothly. Git lens seems to work too.

A fix from the GitLens side is in the works.

Thanks.
There is nothing we can do on our side. Closing


Duplicate export for Prisma Flow generation

Flow generation is super awesome. I just tried it but got an error: Duplicate export for Prisma
projects:
  api:
    schemaPath: "server/api/model.graphql"
    extensions:
      endpoints:
        default: "http://localhost:4000"
  database:
    schemaPath: "database/schema.graphql"
    extensions:
      prisma: database/prisma.yml
      codegen:
        - generator: prisma-binding
          language: flow
          output:
            binding: database/types.js

datamodel: model.graphql

endpoint: ${env:PRISMA_ENDPOINT}

secret: ${env:PRISMA_SECRET}

hooks:
  post-deploy:
    - graphql get-schema --project database
    - graphql codegen

Why it generates both export interface Prisma { and export const Prisma: BindingConstructor<Prisma> = makePrismaBindingClass({typeDefs})? What am I doing wrong?

Also, I don't know what is the purpose of this:
// export const Prisma: BindingConstructor = makePrismaBindingClass({typeDefs})

Can point me @medelman17, please? Thank you.

I have a patch in the works. For the time being, you should be able to change the export const Prisma ... above to export const prisma ... (and likewise wherever you import it).

Great. Also, can you tell me please what is the supposed usage of prisma? I am using exported interface.

And the last question. I had to disable not flow errors manually.
/**
 * @flow
 */
 // $FlowFixMe
import { GraphQLResolveInfo, GraphQLSchema } from 'graphql'
// $FlowFixMe
import { IResolvers } from 'graphql-tools/dist/Interfaces'
// $FlowFixMe
import { Options } from 'graphql-binding'

Please explain what this line does. I can send you some bitcoin for your time, thank you.
export const prisma: BindingConstructor<Prisma> = makePrismaBindingClass({typeDefs})

Also, pages should not be nullable, if it is not nullable in the schema, I guess.

export type ID_Input = string | number
export type ID_Output = string

Why ID_Input is number? It breaks things.

@steida, would you be able to see whether the following version of prisma-binding addresses the bulk of the issues raised above: https://github.com/medelman17/prisma-binding.git#test/flow-types

@medelman17 How?

@medelman17 Sorry for dumb question, but how I can test PR in http://github.com/este/este?

Try yarn add https://github.com/medelman17/prisma-binding.git#test/flow-types

@medelman17 I still don't know how to use it without interfaces 😭

Codegen should generate Flow exact types IMHO. Note dwhere is not caught.

That's all I have to fix for Este: https://github.com/este/este/blob/master/scripts/fixCodegen.mjs

@medelman17 Any update please?

@steida @medelman17 Can I help you with something related with Flow bindings?

@czystyl This is dirty fixes I am using https://github.com/este/este/blob/master/scripts/fixCodegen.mjs string replacement fml. Which lib is responsible for that? Thank you.

I see the PR was merged so now we need to wait for the new version release and close issue.

@schickling could you released that fix?

Ok, The new version of prisma-binding was published. But still, I think that exports are wrong. I don't know why there is export {prisma as Prisam} For Prisma Interface should be exported.
What you think about it:
Generated Prisma file:
- interface Prisma {
+export interface PrismaInterface {
  query: Query;
  mutation: Mutation;
  subscription: Subsc

...

- const prisma: BindingConstructor<Prisma> = makePrismaBindingClass({ typeDefs });
+ const PrismaBinding: BindingConstructor<Prisma> = makePrismaBindingClass({ typeDefs });
- export { prisma as Prisma };

I don't know if I use it in the correct way. Basically, if I should import Prisma constructor from generated files or from main packages like below:
// @flow
import { Prisma } from "prisma-binding";
import type { PrismaInterface } from "./generated/prisma";

const resolvers = {
  Query: {
    feed(parent, args, context: { db: PrismaInterface }, info) {
      return context.db.query.posts({ where: { isPublished: true } }, info);
    },
  },
};

const PrismaBind = new PrismaBinding(config);

In this case, Flow shows me the correct types and the server working fine.

I will check it, thank you!

@steida If you would like you can check this PR #214. I would like to update doc as well.

import { Prisma } from "./generated/prisma";

const db = new Prisma({
  endpoint: "URI",
  debug: true,
  secret: 'mysecret123',
});

const resolvers = {
  Query: {
    feed(parent, args, context: { db: typeof db }, info) {
      return context.db.query.posts({ where: { isPublished: true } }, info);
    },
};

Now flow working fine and autocomplete :)

Nice. Thank you.

Hey 👋, I believe this issue is no longer in sync with the current version of prisma-binding. In need for gaining a better overview of the issues facing the current version, I'll close it.
Feel free to reopen the issue if you believe we should further discuss its content. 🙂


Extremely slow compile time of Objective-C files and dependencies

[REQUIRED] Step 1: Describe your environment

Xcode version: 14.0 Beta 1
Firebase SDK version: 9.1.0
Installation method: Swift Package Manager
Firebase Component: Promises - dependency, Crashlytics
Target platform(s): iOS

[REQUIRED] Step 2: Describe the problem
When building the app in new Xcode 14.0 Beta 1 - new Build Timeline is available to show you the build and compile times. Firebase and mainly it's dependencies we didn't choose to use are the biggest slowdown of our compile times. (see an attachment)
It would be nice to either:

Improve compile time of the dependency
Try to find a way how to release the framework without these dependencies

Build environment: MacBook Pro M1 Max, 32GB, Xcode 14.0 Beta 1, iOS 16 beta 1 simulator of iPhone 13 Pro

Steps to reproduce:
Include Crashlytics + Analytics + Messaging in your project via SPM and run Build (Compile) with new Xcode - then check the Build Timeline.
Additional notes
I did open an issue in the dependency itself (promises), but wanted to cross-link it here for shared knowledge - but it's also Crashlytics problem.
I do think this is related to the new and still better Swift-optimized compiler and build system, but maybe it's the right time to migrate relevant Objective-C code to Swift too?
Let me know if I can be helpful here somehow. Thanks for looking into this!

Thanks the for the report! We're keen to dig into this more - one strange thing in particular is GULNSData+zlib.m seemingly taking 13+ seconds when it's less than 200 lines of code: https://github.com/google/GoogleUtilities/blob/main/GoogleUtilities/NSData%2Bzlib/GULNSData%2Bzlib.m
Hunch: maybe it has to do with the ObjC categories, as FBLPromises also is longer than expected.

It's importing zlib which is probably little big bigger, right?

Okay I ran it locally and saw really strange results. My hunch: some of these long times include waiting time until the next file can build. Example: dummy.m took 439 seconds to build... which is an empty file. I'll try to dig into the WWDC sessions to see if this is explained further, or maybe it's time to file some Feedback.
My build:

That's really long time. 😄 I'll keep an eye on this and the files that take longer than expected. Thanks for digging into this, every build time improvement is huge improvement for everyone!

Thanks for digging into this, every build time improvement is huge improvement for everyone!

Sure thing, thanks again for the report! We're excited to see how we can improve our build times.

Hey @Kaspik, I built PromisesObjC with clang's -ftime-trace and found that all of the files that took a while in your screenshot built in ~100ms.

I did this via CocoaPods by setting -ftime-trace in the Other C Flags build setting of the generated Pods project, and then examining the generated json in chrome://tracing. The build time trace can be found in
DerivedData/${PROJECT}/Build/Intermediates.noindex/Pods.build/${DESTINATION}/PromisesObjC.build/Objects-normal/${ARCH}/${FILENAME}.json

Where in my case PROJECT was the FirebaseUI sample project, DESTINATION was Debug-iphonesimulator, ARCH was x86_64, and FILENAME was FBLPromise+Race.
It does seem like Xcode 14 is including waiting time as build time for files, which is resulting in inaccurate graphs.

Hey @morganchen12, interesting!
FILENAME was FBLPromise+Race - so did you compile just the one file, or the project itself completely?
And did you try that without CocoaPods but via SPM?

@Kaspik Thumbs up for raising this.
@ryanwilson Any updates? We're seeing the same behavior. The slowest parts are FBLPromises, GoogleDataTransport, and FirebaseCrashlytics.
Slow compile times can be also observed with GoogleSignIn dependency.

Let me know if I can help somehow.

@MartinStrambach, have you tried compiling your project with the -ftime-trace flag to identify bottlenecks in the built dependencies? Our investigation suggests Xcode is including time spent waiting to compile a file as total compile time, which is resulting in misleading build times for some dependencies.

I'm seeing these strange things across other hybrid project which objective-c compiling is super slow.
As we now have P cores/E cores on apple silicons and they have shockingly performance differences, I'm suspecting that Xcode will strategically assign objective-c source code to E cores to compile for some reason.
I agree with @MartinStrambach that this strategy could have been introduced for very long but we couldn't see it until Xcode14

@dingtianran The same happens on Intel macs as well, not just Apple Silicons.

Is this still an issue with the Xcode 14 GA?

It got better! But yes, it's still an issue as it's still the slowest compiled files that in total (together even in parallel) make a big chunk of compile time.
Promises take about 2 sec each file, GoogleDataTransport the same. Firebase Crashlytics, similar.
GDTCORUploadCoordinator.m 1.8 seconds
GDTCORTransformer.m 1.9 seconds
GDTCORTransport.m 2.1 seconds

FIRCrashlytics.m 2.3 seconds

Overall, I don't think there is much to improve or do except really try to port those files into swift or divide them into separate modules / less cross-dependent modules. Not sure where the Swift rewrite lays down at your roadmap, but curious to hear your thoughts and ideas :)

Going to close since there's not a clear action. We are gradually migrating our implementations from Objective C to Swift.