Improve editor property capitalization

An hardcoded list of exceptions is now used to make property name capitalization more natural.
I'm not too happy with this implementation – maybe we should add an optional "friendly name" property hint in the end. Also, it takes more time to run the string replacements (30 µs on average for each string in a debug build, compared to 10 µs with the old method). Still, it's not run every frame so it should be fine performance-wise.
There are other improvements we can do, such as not capitalizing stop words like at, in and to. We could do this for the general-purpose String::capitalize() function in 4.0.
Preview
Look at the section and property names.

This closes https://github.com/godotengine/godot-proposals/issues/1399.

String::capitalize() is pretty vague, usually the options are either UPPER CASE or Title Case, String::capitalize() could even refer to Sentence case :D
Could there be a way to make that clearer?

@asheraryam Maybe it could be renamed to title_case in 4.0.

Since it's not strictly Title Case, it would make sense to call it something else. What about proper_case, since it fixes issues in order to make the capitalization proper.

@Calinou Any update? This needs to be rebased on the latest master branch.
Also, I had an idea which might work for some situations. What if Godot's auto-capitalization had a rule where it only changed lowercase letters, so any pre-existing uppercase letters are kept as uppercase always? This would work for class names and any other situation where uppercase letters are used for acronyms in the name.

I don't think this is the best solution. IMO we should make it possible to specify a descriptive name in addition to the property name. This way we wouldn't have to rely on the engine's hard-coded list to have the entries we want. It would also allow localization of those settings names.

@neikeq What you're proposing is definitely a better solution, but I don't know if we can afford adding yet another parameter to ProprertyInfo which already takes quite a lot of hints.

Please merge, my eyes have found peace.

While I still think the solution I mentioned previously is great as it allows localization, I'm now in favour of merging this because:

Short-term it's the only solution as mine requires much more work.
I just realized I can re-use this capitalize_string in the C# bindings generator. I had already planned to create my own hard-coded remaps for generating better names (like AddiOSFramework instead of AddIosFramework). With the new capitalize_string I will no longer have to do that as I can re-use this.

Please note that according to the .NET Capitalization Conventions, the latter is correct and should be preferred over the former.

While I still think the solution I mentioned previously is great as it allows localization, I'm now in favour of merging this because:

Short-term it's the only solution as mine requires much more work.
I just realized I can re-use this capitalize_string in the C# bindings generator. I had already planned to create my own hard-coded remaps for generating better names (like AddiOSFramework instead of AddIosFramework). With the new capitalize_string I will no longer have to do that as I can re-use this.

According to the .NET Capitalization Conventions, the latter is correct and should be preferred over the former.

@Vivraan OS is an acronym, so it should be capitalized. Reading the document you linked, I'm confused as to why they chose to treat acronyms of 2 letters and acronyms of more than 2 letters differently, it seems inconsistent.

@Vivraan OS is an acronym, so it should be capitalized. Reading the document you linked, I'm confused as to why they chose to treat acronyms of 2 letters and acronyms of more than 2 letters differently, it seems inconsistent. An argument for AddIOSFramework could be made I suppose, but I don't like AddIosFramework.

iOS is a three letter acronym, so it becomes AddIosFramework. I've digested the spec.

However, I have seen Godot use what you described as PascalCase. We could have our own spec. Now, wouldn't that resolve all disputes?

I think both "HttpRequest" and "HTTPRequest" can claim to be PascalCase. These just happen to be different flavors of PascalCase.

Here's a note on some camel case variants: https://wiki.c2.com/?CapitalizationRules

Let's move the C# conversation somewhere else as it's not the topic of this PR. If the names are not fine for C#, we can always make our own remap table as I initially had intended.

I think this PR is mostly good, but I would not further bloat EditorNode, which is already incredibly bloated. Just add a new singleton like EditorStringCapitalization or similar and put stuff there.

Superseded by #58706.


Wrap component should change the user's network if they are not on the expected network.

At this time, the wrap modal tries to send the wrap transaction on the network that the user is currently on. It will not prompt the user to switch their network. This will cause a user to send a transaction on the wrong network.
The wrap/unwrap component should use the MM prompt to let the user switch networks.

Closed by https://github.com/hop-protocol/hop/commit/21d58ef64c41710dad38d77c09a56b6662d043ab


chore(p2p/flags): Handle empty p2p.network flag.

Fixes #3003.

@00x-dx this is nearly there, do you have time to finish this today? i'll test and we'll get it merged if so

Sure, i have pushed the additional changes. Let me know how the testing goes through ..

Codecov Report
Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (b97175c) 50.92% compared to head (0e84cfd) 51.09%.
Report is 1 commits behind head on main.

Files
Patch %
Lines

nodebuilder/p2p/flags.go
58.82%
7 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3004      +/-   ##
==========================================
+ Coverage   50.92%   51.09%   +0.17%
==========================================
  Files         177      177
  Lines       11147    11149       +2
==========================================
+ Hits         5677     5697      +20
+ Misses       4966     4952      -14
+ Partials      504      500       -4

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


Incompatible with EMF

Attempting to run the game with "Enhanced Animations" and "Entity Model Features" will crash the game on startup.

I'm playing with EMF, and It's pretty compatible with improved animations

Attempting to run the game with "Enhanced Animations" and "Entity Model Features" will crash the game on startup.

It should be that when the module exceeds about 170, the module will be incompatible with emf

Attempting to run the game with "Enhanced Animations" and "Entity Model Features" will crash the game on startup.

I'm playing with EMF, and It's pretty compatible with improved animations

On 1.20.1 both forge and fabric i insta-crash with emf and this. What versions are you using if I can ask?

Same problem(


Avoid accessing undefined $translate property in Localization

We call unset($this->translate): this leads to warnings when we try to access $this->translate

See issue #3340, can we declare the property instead?

It's already declared, but a call to unset causes warnings if we read this valur after that unset

In that case, we should be running $this->translate = null to unset unless we truly need to delete the property off of the class.

Fixed

:+1: Thanks Michele!


Testing edits Closes #55

Closes #55
@joedotjs Hey! I made a PR for what I talked with you about --- making testing a little more modular by creating a testing environment similar to the dev and production ones. Let me know what you think!!

This looks 😎

👍 👍 from me


Suggestion for Renaming Existing Images Tool

Is your feature request related to a problem? Please describe
I'm currently making use of the "Rename Existing Images" due to the issue discovered in #2351 . Sometimes when parsing a source for tags the connection will be interrupted and you're left with wasted time as far as I am aware. For example, one of those times my internet connection as a whole had a hiccup leading to the connection to the source being lost.
Describe the solution you'd like
Right now in the rename existing images window there is only "continue" for after its used the image's md5 to search whichever selected source and "cancel".  If there could be another button "Stop" while its parsing to then use what it has collected before starting the next (if needed) run of the renamer.
It would also be useful if an output folder could be selected that's separate from the "main" download directory being scanned. In my case, this would only be useful if it would only move those that are actively being renamed / not staying the same name as on input.
Describe alternatives you've considered
Currently breaking up the images I'm parsing into 1-2k chunks.
As for the input/output folders, currently I'm using a temporary directory with the folder(s) I'm scanning buried another layer in. For example,  D:\BooruRn\ is my temporary directory where everything is saved. I then have D:\BooruRN\Parsing that would then have the actual folder D:\BooruRN\Parsing\Oringal with "Original" being from my main directory. Once the files are renamed based on "%copyright:sort%/%artist:sort%%character:sort%%md5%.%ext%", they end up on the same directory level as "Parsing" allowing me to easily move them back into my main directory, not to be confused with "BooruRN"
Please let me know if I need to elaborate or rephrase anything for better understanding.

main.log
Breaking up the images into 1k-2k chunks is going to be ridiculous, i have over 400k pictures to parse. It would take me months.


alt key triggers full re-render of all components

there is something pretty weird going on on my clerk page, on version ec666210f11763fce4fec74072acca1e6525d29f.
If I press the alt (option on OS X) key on a clerk page, it seems to trigger a re-evaluation of everything on the page:
.
Notice that on pressing alt (weirdly it’s not showing keystrokes), both defonce forms change to nil result instead of their var.
Is this a React 18 thing?

This must be the culprit: https://github.com/nextjournal/clerk/blob/6ca1ffd55e6fdae4cbeb7400f0f5cd79ddd4b086/src/nextjournal/clerk/render.cljs#L289-L292
I'm not sure what that option is doing, but it would be great to not force a re-render if we don't have to.

@joe-loco , this comes from https://github.com/nextjournal/clerk/pull/186... I wonder if there is a way that we can prevent that new kv pair you're adding from triggering a re-render...
If you look at a page like https://jsxgraph.mentat.org/, pressing the alt key without doing anything else freezes the page as all of the heavyweight graphs re-render.

@sritchie can you confirm this is no longer an issue?

I failed to reproduce it so going to close it as I try to get an handle on the open issues. Please reopen if it's still a problem.

I will give it a closer look Monday but I tried to recreate this Friday on the latest Clerk and couldn't do it. Thank you!

This is back on the latest clerk (main)... notice the nil when I press option on my mac:


Allow setting or_else() value in advance

For some of my work, I'm considering exposing some objects as Maybe objects instead of just dict like objects. In some specific cases I'll need to provide and or_else() value to the user so he or she doesn't have to set it him or herself.
We could imagine something like:
(test) >>> print(maybe('foo').bar.or_else())
None
(test) >>> print(maybe('foo', or_else="wololo").bar.or_else())
wololo

This way I can even abstract this part of the process, but still allow a user to override it if needed.
What do you think ?

Hey @sametmax,
I thought about what you're trying to achieve and I think it misses the point of Something and Nothing adding another value (or_else) they have to carry with them.
I thought maybe you can use a descriptor.
Define an object that has a descriptor that uses maybe and encapsulates the default value.
Here's an example.
Say you're reading videos info from YouTube:
youtube_video_json_string = """
{"snippet": {"playlistId": "UU6lVC6W94JnpNrBKWEeQfyQ", "thumbnails": {"default": {"url": "https://i.ytimg.com/vi/ujY6nwmpevo/default.jpg", "width": 120, "height": 90}, "high": {"url": "https://i.ytimg.com/vi/ujY6nwmpevo/hqdefault.jpg", "width": 480, "height": 360}, "medium": {"url": "https://i.ytimg.com/vi/ujY6nwmpevo/mqdefault.jpg", "width": 320, "height": 180}, "maxres": {"url": "https://i.ytimg.com/vi/ujY6nwmpevo/maxresdefault.jpg", "width": 1280, "height": 720}, "standard": {"url": "https://i.ytimg.com/vi/ujY6nwmpevo/sddefault.jpg", "width": 640, "height": 480}}, "title": "Stocks App Take I", "resourceId": {"kind": "youtube#video", "videoId": "ujY6nwmpevo"}, "channelId": "UC6lVC6W94JnpNrBKWEeQfyQ", "publishedAt": "2014-10-25T14:01:06.000Z", "channelTitle": "Eran Kampf", "position": 0, "description": "Early take of Stocks"}, "kind": "youtube#playlistItem", "etag": "iDqJ1j7zKs4x3o3ZsFlBOwgWAHU/46J7teBS1LTh87m1e4lwFDavz4E", "id": "UUwuIl3s_oR92MeZOEXU9uq7fuRwnm09L5"}
"""

You'll probably want to encapsulate that response to an object:
class YoutubeResponse(object):
    def __init__(self, json_string):
        self._json = json.loads(json_string)

    id = MaybeDescriptor('_json', 'id')
    title = MaybeDescriptor('_json', 'snippet', 'title')
    description = MaybeDescriptor('_json', 'snippet', 'description', default='no description...')

The code for MaybeDescriptor (which I'm considering adding to pymaybe):
class MaybeDescriptor(object):
    def __init__(self, *path, default=None):
        self.path = path
        self.default_value = default

    def __get__(self, instance, owner):
        maybe_value = maybe(instance)
        for p in self.path:
            maybe_value = getattr(maybe_value, p) or maybe_value[p]

        return maybe_value.or_else(self.default_value)

class MaybeObject():
    def __init__(self, data):
        self.__data

class MaybeDescriptor(object):
    def __init__(self, *path, default=None):
        self.path = path
        self.default_value = default

    def __get__(self, instance, owner):
        maybe_value = maybe(instance)
        maybe_value = getattr(maybe_value, '__data')
        for p in self.path:
            maybe_value = getattr(maybe_value, p) or maybe_value[p]

        return maybe_value.or_else(self.default_value)

class YoutubeResponse(object):
    id = MaybeDescriptor('id')
    title = MaybeDescriptor('snippet', 'title')
    description = MaybeDescriptor('snippet', 'description', default='no description...')

Then again maybe you're just better off doing initialisation of values explicitly in init and not lazily via descriptor:
class YoutubeResponse(object):
    def __init__(self, data):
        self.id = maybe(data)['id'].get()
        self.title = maybe(data)['snippet']['title'].get()
        self.description = maybe(data)['snippet']['description'].or_else('no description...')

That would require to craft every object in a way that it accommodate the use of maybe (hence tying them to it) VS just using maybe when some more general part of my program use the object.

Storing another value to be carried on down the call stack with the Something\Nothing objects is kinda messy and defeats the purpose of single responsibility of Something and Nothing.
They should represent just that a value or a non-value...  and not carry around an extra value.
The best way to implement this functionality is to have another object that wraps this functionality.
An Optional (or maybe a Promise is a better name?) class that wraps a maybe() instance and a default.
Something like
class Promise(object):
   def __init__(self, value, default=None):
      self.__value = maybe(value)  # just in case, to make sure value is Something\Nothing
      self.__default = default

  def get(self):
      return self.__value.or_else(self.__default)

That makes sense.


"Azure DevOps Project for AKS" URL redirects to 404-Content/Page Not Found

The issue was created by @SunnyOswal from https://github.com/MicrosoftDocs/feedback/issues/516
"Azure DevOps Project for AKS" URL redirects to 404-Content/Page Not Found
To Reproduce
Go to 'https://docs.microsoft.com/en-us/azure/aks/'
Click on 'How-to guides'
Under that click on "DevOps on AKS"
Under that click on "Azure DevOps Project for AKS"
See error
URL Broken:
https://docs.microsoft.com/en-us/vsts/pipelines/actions/azure-devops-project-aks?toc=%2Fen-us%2Fazure%2Faks%2FTOC.json&bc=%2Fen-us%2Fazure%2Fbread%2Ftoc.json
Expected behavior
Url loads fine.
Desktop (please complete the following information):
OS: windows
Browser: chrome

Thanks for the feedback! We are currently investigating and will update you shortly.

Thanks @Powerhelmsman
I followed the instructions and tested all the links in the doc but they work as they should. I am running Chrome as well

@SunnyOswal I see you were the original owner of this issue. Can you clarify if I am not following the steps you did?

@MicahMcKittrick-MSFT I checked it earlier and the link was not working. Now it works for me as well.
I did try to contact document author and they might have fixed this now.
@Sunny-Oswal Please let us know if you still face any issue.

@MicahMcKittrick-MSFT @SaurabhSharma-MSFT this issue is fixed now.


refactor: larger scale update in the GWAS Catalog data ingestion

Logic moved to do_pics branch, hence closing PR.


fix(DIST-1643): Change default sidetab icon size

Before:

After:

:tada: This PR is included in version @typeform/embed-v1.36.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Quarantined differences between AR and AI

AR and AI parsers don't return the same "definition" of quarantined
Website contents:
AR:
Aktuell im Kanton wohnhafte Kontaktpersonen in Quarantäne: 41

davon Anzahl Personen, die aus einem Risikogebiet in die Schweiz eingereist sind und aufgrund dessen aktuell im Kanton in Quarantäne sind:  37

AI
0 Personen in Quarantäne/enger Kontakt (aktuell)
12 Personen in Quarantäne/Einreise Risikoland (aktuell)
AR parser returns 41 for quarantined, AI parser returns 0, i.e. AR parser includes "Einreise Quarantäne" while AI doesn't.

We had similar issues for BS and ZG, where we introduced new (canton-specific) variables for this: current_quarantined_riskarea_travel and current_quarantined_total.
I guess these new variables will become relevant for most cantons. The variable current_quaratined is supposed to be only the "close contact" and the contact tracing based quarantine.

We had similar issues for BS and ZG, where we introduced new (canton-specific) variables for this: current_quarantined_riskarea_travel and current_quarantined_total.
I guess these new variables will become relevant for most cantons. The variable current_quaratined is supposed to be only the "close contact" and the contact tracing based quarantine.

Ok. I'll update the AR parser accordingly.


Miniplayer ist not affected by custom css

Is your feature request related to a problem? Please describe.
No
Describe the solution you'd like
That the custom css is also applied to the miniplayer

just to be sure, the mini player is not made by youtube.
its made by myself, thats why the custom css is only injected into youtubes layout.
but i tagged this request as a feature request for now

Yeah, i know you guys made that, but it would still be cool, because it looks wired when in a smaller window on my screen. I will try to write some better css for that.

I have tried compiling it, but iam not experienced enough with electron to fix this error when compiling, maybe you can help:

(node:24188) UnhandledPromiseRejectionWarning: TypeError: Cannot read properties of undefined (reading 'split')
    at eval (webpack://ytmdesktop2/./src/app/plugins/updateProvider.plugin.ts?:26:82)
    at ./src/app/plugins/updateProvider.plugin.ts (C:\Users\info\Downloads\ytmdesktop2-master\ytmdesktop2-master\dist_electron\index.js:11571:1)
    at __webpack_require__ (C:\Users\info\Downloads\ytmdesktop2-master\ytmdesktop2-master\dist_electron\index.js:14436:42)
    at webpackContext (webpack://ytmdesktop2/./src/app/plugins/_sync_nonrecursive_plugin.ts$/?:22:9)
    at Array.map (<anonymous>)
    at eval (webpack://ytmdesktop2/./src/app/utils/serviceCollection.ts?:13:14)
    at createPluginCollection (webpack://ytmdesktop2/./src/app/utils/serviceCollection.ts?:33:7)
    at __WEBPACK_DEFAULT_EXPORT__ (webpack://ytmdesktop2/./src/app/main.ts?:38:117)
    at eval (webpack://ytmdesktop2/./src/background.ts?:7:54)
    at ./src/background.ts (C:\Users\info\Downloads\ytmdesktop2-master\ytmdesktop2-master\dist_electron\index.js:11780:1)
(Use `electron --trace-warnings ...` to show where the warning was created)
(node:24188) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
[30148:0924/222700.001:ERROR:gpu_init.cc(486)] Passthrough is not supported, GL is disabled, ANGLE is

dont forget to copy the .env.example to .env

yep, thanks 😅


Wrong python folding with tree-sitter

Prerequisites

[ X ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Folding python code is not working properly when tree-sitter is activated. See case below.
Steps to Reproduce

Set core.useTreeSitterParsers: false in config.cson and restart Atom
Create new python file with this content

for cl in reversed(range(1, len(layers))):
    pl = cl-1
    nl = cl+1

Fold the first line

Expected behavior:

Actual behavior:

Reproduces how often:
Always
Versions
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.25.0
python 2.7.14
git 2.16.1.windows.1
visual studio 2015
Windows 10
Additional Information
Any additional information, configuration or data that might be necessary to reproduce the issue.

Thanks for the report! It looks like CRLF line endings are causing some problem for the python parser.

This will be fixed in Atom 1.25.1.

Looks like I need to refresh before posting, thanks for catching the CRLF line endings @maxbrunsfeld 😆.

It is actually useTreeSitterParsers: true. Wrong copy/paste after I made sure it works with old version.
Sorry about that.

Hey, just an update on this - a fix will ship in Atom 1.26.0-beta1, or in 1.26.0 if you want to wait for the stable release.

Waiting for beta to give it a try

Ok, 1.26.0-beta1 is out.

I've tried with this piece of code
for cl in reversed(range(1,
                         len(layers))):
    def f(a1:int,
          b1:List[int]):
        for cl in reversed(range(1,
                                 len(layers))):
            def f(a1:int, b1:List[int]):
                p2 = cl-1
                n2 = cl+1
        p2 = cl-1
        n2 = cl+1
        for cl in reversed(range(1, len(layers))):
            def f(a1:int, b1:List[int]):
                p2 = cl-1
                n2 = cl+1
    pl = cl-1
    nl = cl+1

and I've seen no mistake. We can consider this closed for good 👍


added tags for seo

Can you pls label this as hacktoberfest

Try adding more 4-6 similar keywords, Thx


Training: Reorganized Training Operator Docs

Related: https://github.com/kubeflow/training-operator/issues/1998.
I created the following sections for Training Operator docs:

Overview
Installation
Getting Started
User Guides
Reference

A few points:

@StefanoFioravanzo @kubeflow/wg-training-leads Any ideas on what we could add to Why Training Operator ? section ? Initially, we can just add some basic info.
I didn't move CRDs to reference in this PR since we don't have time to discuss how we are going to generate them. What do you think we should do in this PR ?
Do we need to have working example in GettingStarted page ? Would it be too complicated to consume ?

/hold for review
/assign @StefanoFioravanzo @kubeflow/wg-training-leads @hbelmiro @kuizhiqing @droctothorpe @franciscojavierarceo
Looking for your feedback!

@andreyvelich thanks for this!

Any ideas on what we could add to Why Training Operator? section ?

Let's start with something simple and iterate in future PRs. We can start by answering questions like:

How does training operator simplify distributed training with respect to a more traditional approach?
How does Kubernetes help in solving these problems?
Why is Training Operator part of the Kubeflow ecosystem?

I didn't move CRDs to reference in this PR since we don't have time to discuss how we are going to generate them. What do you think we should do in this PR ?

Makes sense. I'd keep the scope of this PR to the restructuring you already implemented. Let's iterate on content separtely. We can address each framework's user guide in dedicated PRs.

Do we need to have working example in GettingStarted page ? Would it be too complicated to consume ?

Getting Started should have an end-to-end working (yet simple) example. Generally people just want to copy paste some stuff, run it, and see results. Then you typically link some more advanced tutorials or user guides at the end

That makes sense @StefanoFioravanzo, I added initial ideas for Why Training Operator ? and also I added the AI/ML lifecycle diagram that we can re-use in various Kubeflow components to explain which stage of lifecycle each component addresses (e.g. Spark Operator, Model Registry, Katib, Notebooks, KServe).
Please let me know what do you think @kubeflow/wg-training-leads @StefanoFioravanzo ?

@franciscojavierarceo I added working example, does it look good ?

This PR should be ready unless you have any other comments.
/hold cancel


add support for sqlalchemy

due to the fact that atm sqlalchemy is async, can you consider to add support to that ORM?

Current no plan for that


Add info about GPIO pins

Remember that GPIO pins need to be soldered. Remind of solderless alternative.
Good to be at the shopping list, since users forget about it if not. Happened to me recently when helping a friend (I forgot to tell him about the pins - even having done the process a couple of months back)

Good idea, thank you for submitting this. Would you just revise to read 40 pins? (there are 2 rows of 20)

Good idea, thank you for submitting this. Would you just revise to read 40 pins? (there are 2 rows of 20)

Done.

Great, thank you for adding this!


add parameter to that would fit to page

In DiagrammeR, we use a function to fit the rendered svg to its container, so the sizing is controlled by either sizingPolicy or the height and width parameters.  You can see how it would look on phylowidget by
devtools::install_github("timelyportfolio/phylowidget@feature/sizing")

and then running the example from your readme.md.  Then, change to
phylowidget(nwk,height = 200, width = 400)

The tiny change can be seen here.  We could easily add as a parameter in the R code also if you don't want it always on.  Also, I'm planning to work on some pan / zoom available to DiagrammeR.  I could easily add that here also if you think it would be helpful.

Dear @timelyportfolio , feel free to hack away! The more input, the better; this is part of this, and I'll probably be working on some more widgets today, esp as Ramnath Vaidyanathan is here.

I've edited phylowidget.js to include your sizing suggestion - thanks!

how great !  Tell Ramnath hello :)

If you want to see the little bit that I did on phylos, you can go to
http://bl.ocks.org/timelyportfolio/59acc3853b02e47e0dfc
https://gist.github.com/timelyportfolio/1de4cdd99d92848bc625


[chore] remove chokidar as dependency of kit

Now that svelte-kit package is no longer a part of core SvelteKit, it no longer needs chokidar as a dependency.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[ ] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

The test failures look to be caused by flakiness on GitHub's side. The issue isn't in the action runner, but rather that the github.com URL that the build is trying to download the sharp binaries from is 500ing.

Yeah, that happens periodically. Is there an alternative to vite-imagetools that doesn't use sharp? Would be great to use a JS-only dependency if a suitable one exists


Relation model definitions throw TypeScript errors

Generated Zod schemas for complete records (with relations) report errors, see test/functional/recursive/expected/comment.ts:
Type 'ZodLazy<ZodObject<extendShape<{ id: ZodString; author: ZodString; contents: ZodString; parentId: ZodString; }, { parent: ZodType<CompleteComment, ZodTypeDef, CompleteComment>; children: ZodArray<...>; }>, "strip", ZodTypeAny, { ...; }, { ...; }>>' is not assignable to type 'ZodType<CompleteComment, ZodTypeDef, CompleteComment>'.
  Types of property '_type' are incompatible.
    Type '{ id?: string; contents?: string; author?: string; parentId?: string; parent?: CompleteComment; children?: CompleteComment[]; }' is not assignable to type 'CompleteComment'.
      Property 'parent' is optional in type '{ id?: string; contents?: string; author?: string; parentId?: string; parent?: CompleteComment; children?: CompleteComment[]; }' but required in type 'CompleteComment'.ts(2322)

I'll have a closer look and open a PR if I find a fix.

I'll take a look at this and your other PRs tomorrow. Thank you for all your contribution! <3

Fixed with release 0.3.1

I'm still seeing this issue, with the TS errors in version ^0.3.2

@siddharthsharma94 can you paste your Prisma schema for the relevant parts where you see this error ? 0.3.1 fixed the issue for me, though I still have errors described in #52 due to optional fields.

@CarterGrimmeisen @franky47
I encountered same error. I think we can reproduce that using test code.
https://github.com/CarterGrimmeisen/zod-prisma/issues/61

I will reopen this issue to document some continued problems users are seeing but I won't be totally sure they exist until we can see a prisma schema that replicates the issue.

I think I hit this bug too.
this is the schema:
model user {
    id        Int      @id @default(autoincrement())
    email     String   @unique
    password  String
    name      String
    enabled   Boolean @default(true)

    group_id  Int
    group     group @relation(fields: [group_id], references: [id])
}

model group {
    id        Int      @id @default(autoincrement())

    child_groups    group[] @relation("parent_child_group")

    parent_id       Int?
    parent          group? @relation("parent_child_group", fields: [parent_id], references: [id])

    users           user[]
    name            String

    locations locationmap[]
}

and this is the error I get
TS2322: Type 'ZodLazy<ZodObject<extendShape<{ id: ZodNumber; email: ZodString; password: ZodString; name: ZodString; enabled: ZodBoolean; group_id: ZodNumber; }, { ...; }>, "strip", ZodTypeAny, { ...; }, { ...; }>>' is not assignable to type 'ZodType<Completeuser, ZodTypeDef, Completeuser>'.
  Types of property '_type' are incompatible.
    Type '{ id?: number; group?: Completegroup; name?: string; email?: string; password?: string; enabled?: boolean; group_id?: number; }' is not assignable to type 'Completeuser'.
      Property 'group' is optional in type '{ id?: number; group?: Completegroup; name?: string; email?: string; password?: string; enabled?: boolean; group_id?: number; }' but required in type 'Completeuser'.

this is generated in user.ts
export const userModel = z.object({
  id: z.number().int(),
  email: z.string(),
  password: z.string(),
  name: z.string(),
  enabled: z.boolean(),
  group_id: z.number().int(),
})

export interface Completeuser extends z.infer<typeof userModel> {
  group: Completegroup
}

/**
 * RelateduserModel contains all relations on your model in addition to the scalars
 *
 * NOTE: Lazy required in case of potential circular dependencies within schema
 */
export const RelateduserModel: z.ZodSchema<Completeuser> = z.lazy(() => userModel.extend({
  group: RelatedgroupModel,
}))

and this is generated in group.ts
export const groupModel = z.object({
  id: z.number().int(),
  parent_id: z.number().int().nullish(),
  name: z.string(),
})

export interface Completegroup extends z.infer<typeof groupModel> {
  child_groups: Completegroup[]
  parent?: Completegroup | null
  users: Completeuser[]
  locations: Completelocationmap[]
}

/**
 * RelatedgroupModel contains all relations on your model in addition to the scalars
 *
 * NOTE: Lazy required in case of potential circular dependencies within schema
 */
export const RelatedgroupModel: z.ZodSchema<Completegroup> = z.lazy(() => groupModel.extend({
  child_groups: RelatedgroupModel.array(),
  parent: RelatedgroupModel.nullish(),
  users: RelateduserModel.array(),
  locations: RelatedlocationmapModel.array(),
}))

Hey @markoheric! Do you have typescript's strict mode enabled? Both zod and this package require it and the issue your describing looks suspiciously like strict mode being disabled. If not, let me know and we can look at it more closely!

Hi @CarterGrimmeisen, I'm experiencing the same thing and I have strict mode true in my tsconfig compiler options.
schema.prisma file:
datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

generator zod {
  provider                 = "zod-prisma"
  output                   = "../schema"
  relationModel            = true
  modelCase                = "PascalCase"
  modelSuffix              = "Model"
  useDecimalJs             = true
  prismaJsonNullability    = true
}

model Basket {
  id Int @id @default(autoincrement())
  basketToken String @unique
  createdOn DateTime @default(now())
  lastUpdated DateTime?
  validBasket Boolean @default(false)
  totalCost Float
  originalCost Float

  coupon String?
  creditUsed Float?
  couponDiscount Float?

  orders Order[]
  catalogueId String
}

model Order {
  id Int @id @default(autoincrement())
  orderToken String @unique

  basket Basket @relation(fields: [basketId], references: [id])
  basketId Int

  items BasketItem[]

  expiryDate DateTime?
  date DateTime?
  address Json?
}

model BasketItem {
  id Int @id @default(autoincrement())
  title String
  description String?

  order Order @relation(fields: [orderId], references: [id])
  orderId Int

  lineCost Float
  sku String
  qty Int
  price Float?
}

dependencies:
{
  "devDependencies": {
    "@prisma/client": "^3.10.0",
    "@types/jest": "^26.0.4",
    "@types/node": "^14.0.14",
    "prisma": "^3.10.0",
    "zod-prisma": "^0.5.4",
    "js-yaml": "^4.1.0",
    "dotenv": "^8.2.0",
    "fs-extra": "^9.0.1",
    "jest": "^26.1.0",
    "nanoid": "^3.1.22",
    "nodemon": "^2.0.3",
    "reflect-metadata": "^0.1.13",
    "ts-jest": "^26.1.1",
    "ts-loader": "^7.0.5",
    "webpack": "^4.43.0",
    "webpack-cli": "^3.3.12",
    "typescript": "^4.6.2"
  },
  "dependencies": {
    "node-ts": "^5.0.6",
    "zod": "^3.13.4"
  }
}

Fixed it, make sure your generated zod folder is in your includes in tsconfig!
https://github.com/colinhacks/zod/issues/533
By default this generator puts zod in prisma folder which wasn't included in my tsconfig.
Either move the zod folder to be somewhere else or include in tsconfig like so:
{
  "includes": ["prisma/zod"]
}

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true, // <- changed
    "strictNullChecks": true, // <- added just in case
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve"
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules"]
}

Just change ts.config


fan - boost speed?

Just switched from filipvh's original integration to this one, and hurray, my fan is working again via HA :-)
What I do not find is a way to call the boost option of the fan.
Is this possible in any way? I'm guessing because it is using percentages now instead of low/med/high the boost 'speed' also disappeared.
Any idea on how to achieve this?
I guess I could recreate something similar in HA where a button would activate speed 100% for 15 minutes and then go back to the previous speed setting, but using the nhc2 boost option might be a cleaner way to go.

never mind, found it :-)
25% = low
50% = med
75% = high
100% = boost


Proposed implementation of options-passing

The commits implement the ideas from #12.
So does it bloat the code too much?

I was wondering whether we should export parse, unparse and BufferClass also if people include [just uuid.v4]

You mean hang those properties off v4 and v1 as well?  APIs should be as compact as possible.  Having multiple references to the same state hung in different places feels messy to me.

Yeah, I didn't like it neither that's why I didn't do it :)
Yet I think the documentation is a bit confusing then... I'll try to clean that up a bit.

@pnegri : regarding performance.  I agree node-uuid probably puts too much emphasis on this. After all, we're getting close to the theoreticaly limit of the RFC. It says if you're creating more than 10M uuids/sec you should throw an error or (gag!) have the code block to slow things down.

OK, I'm fine with the module as it is right now.

Yeah, I think we're in good shape here.  I'm in the middle of doing some housekeeping and removing some of the unnecessary perf optimizations I had (in favor of making the code more compact/readable).  I'll resolve conflicts on my end though.

Cool, thanks for all the help! I'm looking forward to seeing it published in npm...
Now I can head on to the next task, i.e. integrating node-uuid with cassandra-client, see http://code.google.com/a/apache-extras.org/p/cassandra-node/issues/detail?id=12
:)


[fix] find appropriate entry line by string match instead of index

Ran into this issue where one entry in our yarn.lock for some reason has name as a field. This was resulting in the following error during runtime
    TypeError: Invalid version. Must be a string. Got type "undefined".

"<EMAIL_ADDRESS>  name legacy-swc-helpers
  version "0.4.14"
  resolved<EMAIL_ADDRESS>  integrity sha512-4C7nX/dvpzB7za4Ql9K81xK3HPxCpHMgwTZVyf+9JQ6VUbn9jjZVN7/Nkdz/Ugzs2CSjqnL/UPXroiVBVHUWUw==
  dependencies:
    tslib "^2.4.0"

@Simek let me know if you need me to make any changes here 🙏

I have released the fix in 0.11.3, thanks for the contribution! 🙏


Doesn't support for set the current dir to variable. and recover latter

@lygstate sorry i missed this issue. anyhow,  pwd also returns the current dir so you can store that to a variable.
you can than use the cd command with that value.

closing due to lack of feedback


Epsilon parameter of daq_moves is always set to 1 regardless of preset value

Hi guys,
I noticed an issue with daq_move_base: if you create a dashboard preset with an actuator, upon loading epsilon will always be set to 1, regardless of preset value.
It seems like this happens here:
https://github.com/PyMoDAQ/PyMoDAQ/blob/ee72fa5947fc628771b9ad99501c5a3bb54d6268/src/pymodaq/daq_move/utility_classes.py#L158
https://github.com/PyMoDAQ/PyMoDAQ/blob/ee72fa5947fc628771b9ad99501c5a3bb54d6268/src/pymodaq/daq_move/utility_classes.py#L183
I commented line 183 and it seems like it works... but maybe this is meant for something, I'll let you actually fix it instead of breaking something!

Hi guys,
in fact _epsilon should be redefined in all of our plugins as class attributes especially because the one developing the plugin should be the one that knows what value is adequate (depends on the controller). So if someone doesn't know much he won't have to play with _epsilon.
I just added this in the template:
# _epsilon is the initial default value for the epsilon parameter allowing pymodaq to know if the controller reached
# the target value. It is the developer responsibility to put here a meaningful value
_epsilon = 0.1  # TODO replace this by a value that is correct depending on your controller

that said, if epsilon is set in the preset to a different value compared to the default one (_epsilon), one should probably apply the preset one. I'll propose a pull request in that direction


ECER-485: Authentication SSO (BCeID)

Login protection for authenticated users
Route protection for non-authenticated users
Login with BCeID button starts SSO login sequence
Subsequent API calls contain access token in authorization header
OpenID configuration fetched from server before app mount

@ytqsl PR updated with requested changes, please re-review.


Unhandled Error in Telegram API Module

at Telegram.callApi (/usr/src/app/node_modules/telegraf/lib/core/network/client.js:258:19)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 83)

The node-surepetcare module has sent (dependent on load) multiple messages through a for loop which causes errors on the telegram API. There is now a throttling about 200 ms for each message.


[Request] Different Views on Each Widget Row

Hi!
Absolutely love the skin. But theres really only 1 thing keeping me from transitioning to it from Arctic Horizon and thats the widget views. Would it be possible to assign a different view to each widget row? ie. Have one row be landscape and the other to be portrait?
The main reason I asked is I noticed on the youtube that during the demo
https://youtu.be/xEQPzxfTcPg?si=juaASqYuwwv9Hp_y&t=64
One of the rows was this landscape widget card that folded out and started playing the trailer within the widget. I for the love of me cant figure out how this was done and would really love to re-create that.
Let me know if its something that can be done, and if not, how the demo video got the auto expanding widget?

Ohh you are talking about The Highlight Widgets. Yes it's a option for the 3rd widget on the home screen. Like I said I am waiting on my water cooler parts for my PC that arrive tomorrow and I bought another PC also arriving tomorrow.
I'll be able to show you how when I get my PC

Once your pc comes in, would you be able to add that option for all widgets? Honestly in the video it's really cool, if we could have a banner and poster that auto folds out into a card/trailer that would be incredible

That would be to much work.

Other views on the home were removed a long time ago. I would like to keep it like Netflix

What about other views in custom hubs? Or just having the highlight widget be the other view option so we can have it in more than 1 place?

If you don't have the bandwidth to make such a change, could you tell me what the code references are for widgets and view types and that highlight view type? I'll fork it and make the changes

I figured out the highlight widget part, but still can't figure out how to make each widget a independent view. If you could let me know how your code is laid out it would be a lot of help

It looks like the existing widget selection in the skinshortcuts-widgetselect includes properties Widget content, Widget label, Limit, Sort by, Sort order, Tags.
I can update this with a new control like
<control type="button" id="900$PARAM[widgetpos]14">     <description>widget view type</description>     <width>500</width>     <height>45</height>     <align>left</align>     Reg22     $LOCALIZE[31090]:     <label2>$VAR[widget_viewtype_label$PARAM[widgetpos]]</label2>     <textoffsetx>10</textoffsetx>     <onclick>         RunScript(script.skin.helper.service,action=setskinshortcutsproperty,setting=widgetviewtype,header=$LOCALIZE[31090],property=widgetViewType$PARAM[widgetprop])</onclick>     <visible>!String.IsEmpty(Container(211).ListItem.Property(widget$PARAM[widgetprop]))</visible> </control>
and the corresponding
<variable name="widget_viewtype_label1">     <value condition="!String.IsEmpty(Container(211).ListItem.Property(widgetViewType))">         $INFO[Container(211).ListItem.Property(widgetViewType)]</value>     <value>$LOCALIZE[31641]</value> </variable>
But i don't see where the skin's widget rendering logic is defined to actually use the new control/variable


Beta release

Codecov Report
Base: 93.37% // Head: 93.37% // No change to project coverage :thumbsup:

Coverage data is based on head (d108c75) compared to base (88f26b2).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             beta     #139   +/-   ##
=======================================
  Coverage   93.37%   93.37%
=======================================
  Files           9        9
  Lines        2537     2537
  Branches      329      329
=======================================
  Hits         2369     2369
  Misses        166      166
  Partials        2        2

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

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


go/types: missing "declared but not used" error

package main

func main() {
	var i int
        defer func() {}
}

type-checks with only one error:
x.go:5:24: function must be invoked in defer statement

It should also complain about i being declared but not used.
See also #23586.

go test -run Check -files=x.go reports both errors; and rebuilding gotype doesn't seem to make a difference. Hmm...

The root cause for the current behavior is that the check that the defer expression is a function call happens at parse time; and if there are parse errors, gotype stops (and doesn't bother type-checking the code). go/types testing on the other hand continues, hence the discrepancy.
We cannot easily remove the parser check as it would require changing the field go/ast/DeferStmt.Call (which we know is a *go/ast/CallExpr) to an unchecked expression, which is a backward-incompatible change.
Instead, make gotype continue with type-checking even if there are parser errors.


Feature Request: Support a micro http server like NanoHttpd

Support a micro http server like NanoHttpd
https://github.com/elonen/nanohttpd
It would be awesome if I could embed this into Android.

@perwendel, I see this marked closed. What is the resolution? Won't support, or support has been added in?

It was closed as a Won't fix.

Thanks for the update. I wonder with respect to this item, whether the feature of swapping in another web server would suffice? http://sparkjava.com/documentation#other-web-server. If the default embedded jetty server doesn't work for Android.

I think it would be possible, if the other web-server supports Servlets.


Is java.lang.Void implicitly always @Nullable or should normal defaults apply? [working decision: no special treatment]

From a discussion:
Werner Dietl:
Should we treat java.lang.Void specially? The only value Void can have is null. So defaulting it to @Nullable, even in a @DefaultNotNull context, would make that explicit. Using @NotNull Void to mark an unusable parameter doesn't seem useful, as the method could only ever be called with a null argument.
Kevin Bierhoff:
It certainly seems unfortunate to have to annotate @Nullable Void every time. I've been grappling with this a bit b/c I expect some tools to want to treat Void as "definitely null" (as opposed to possibly-null), which is a commonly used lattice element I believe but we don't have an annotation or effective specifier for it. I'd be curious what your take is on that. Would you mind filing an issue for the treatment of Void?
Kevin Bourrillion:
My current impression is that if we can't distinguish definitely-null from possibly-null we will still meet all of our requirements. That might be untrue, or we might have some reason to want to add it as a requirement, but barring those two possibilities we should be free to not worry about it.
I do think filing an issue on the question of whether Void can be implicitly assumed to be @Nullable is a fine move though.

I still feel pretty good about not having a special case for this. That said...
I did just hear about some fallout from @Nullable Void that was more noisy than I'd been picturing. (IIRC, I'd primarily been picturing Future<@Nullable Void>. As an aside, users could choose to replace that with the terser Future<?> -- though arguably that is less clear, and for that reason, we recently went the direction of Void in Guava's Futures.submit.)
Anyway, the other common case for ending up with Void is with a visitor pattern. Here are some examples from Error Prone:

https://github.com/google/error-prone/blob/4c49d590e41e875cc91d6061e6cb986f0ede559c/core/src/main/java/com/google/errorprone/bugpatterns/threadsafety/HeldLockAnalyzer.java#L193
https://github.com/google/error-prone/blob/4c49d590e41e875cc91d6061e6cb986f0ede559c/check_api/src/main/java/com/google/errorprone/scanner/ErrorProneScanner.java#L461

Each of those files would need several @Nullable annotations on its Void return types. This is arguably extra unfortunate when many visitors don't care about return types in the first place (and so even Void -- and the return null it requires) is extra noise. (Granted, one option is to switch from Void to a dummy type with a single instance.)
That still seems like the lesser evil to me. In addition to the arguments I made above:

If tool authors provide migration tooling, it can add @Nullable to every occurrence of Void automatically.
We can always hope that nullness is a language feature someday, at which point users can hopefully write Void? or something instead of @Nullable Void. (For that matter, we can hope that language features like sealed classes and enhanced switch reduce the need for visitors specifically.)

Right visitors are a common reason to reach for Void.  My guess is though that visitors (with parameterized return) aren't all that common outside compilers, so while @Nullable Void is a nuisance for tool vendors in that context, it may not be for developers at large.  Additionally this may be an issue we can simply punt on and get back to later.
Just to say this explicitly, what's "special" about Void is that null is its only valid value.  That means that @NonNull Void is a vacuous type, inhabited by no values.  Also, Void values are definitely null, which tools could hypothetically special-case.  If they did special-case then @NonNull Void would be a contradiction, aka, unreachable (like Kotlin's Nothing type).

If tool authors provide migration tooling, it can add @Nullable to every occurrence of Void automatically

+1
Here's another compiler-like visitor example where I had to add a bunch of @Nullable Voids: https://github.com/google/turbine/commit/873a1be5c0e07feb4edff200979523066bddccfa. It's a little unfortunate, but I agree with the earlier discussion about this not being a very common case and there being a high bar for special cases.

(Note this issue is closed; is there something that merits reopening it or opening something else?)
Suggesting @Nullable on every Void might be a reasonable default, and I think nothing else could make sense for a parameter or variable type. But -- just to check my understanding -- for a return type is non-nullable Void also occasionally useful as that "nothing" type? For example, for a Callable that never completes normally? In that case, maybe passing the result of call() to anything is always bogus and would probably get the error it deserves.

(I found this while trying to find previous discussions on java.lang.Void while creating the change I linked to earlier. I wasn't advocating for reopening/revisiting the conclusion, but I figured I'd add a note. If we see a a lot more examples of this, especially ones outside the known compiler/visitor use-case, it might be worth considering.)
(Another meta-comment: should there eventually be a home for write-ups of decisions like this in the user guide or an FAQ or something? Having to write @Nullable Void make sense but is also a little unintuitive, it might be a useful sort of thing to capture somewhere user-facing.)

maybe passing the result of call() to anything is always bogus and would probably get the error it deserves

That makes sense, but to take that further, is passing anything other than null for Void always a little weird? Even if the callable returns normally I generally would prefer callable.call(); foo(null); to foo(callable.call()).

I just got asked about this by a user again :)
My initial thinking was that not much significant had changed during the course of this thread. From my perspective, the biggest thing was encountering the visitor use case from over a year ago.
But I'm realizing something else that I didn't appreciate: This is another case in which it matters that Kotlin takes types very seriously. So, if you try to use a Future<Void> in Kotlin, then Kotlin is could throw NullPointerException every time you use the result of get(). Now, it might be that Kotlin doesn't typically consider you to "use" the result, so maybe it's usually safe... currently?  To address them, I changed every(?) Future<Void> in Google's Kotlin codebase to Future<Void?>. But new instances have been creeping in.
Actual Kotlin appearance of Future<Void> are not quite what we're talking about in this issue, though: JSpecify wouldn't necessarily speak to what Kotlin does for Kotlin appearances of Void. (But it would be great if they'd either require users to write Void? or else treat the code that way automatically: That would result in bytecode that contains the equivalent of @Nullable Void. To investigate, I dug up an old Kotlin feature request for special handling of Void, KT-20379.) But JSpecify would speak to what Kotlin (and other tools) do for Java appearances of Void.
And on that topic, I find my position softening. While I still wouldn't want to go down the road of a general-purpose feature, I'm finding a special case for Void specifically to be easier to swallow.
I maybe got the impression that I'd heard a similar opinion from someone else not long ago...? But I don't want to put words in anyone's mouth.
And I still think we have plenty of time to figure this out.

Roman replied on KT-20379. He pointed out that a change that switches Void from implicitly non-nullable to implicitly nullable could break compilation of existing code (though I don't think it would break anything at runtime under our model). An example is ImmutableList<Void>. Another example is Class<Void>, at least if Class is annotated as forbidding nullable type arguments. Presumably users would then have to write Class<@NonNull Void> or Class<Void?>, or else our special case for Void would need its own special case for Class<Void> :)

I think this illustrates that there are meaningful differences between Void and @Nullable Void. It's only that non-nullable Void is a very weird type, having no values whatsoever. So a method that accepts or returns Void can never be called (at least without warning), but for the examples you share, this situation seems actually... desirable, even?
Contrast with methods accepting or returning @Nullable Void: there's nothing weird about them at all, it's just that null is the only value you'll ever pass/receive in those positions.
So this means that in order for Void to default to nullable, we would sometimes see @NonNull Void to counteract that default, making it work "fully backwards" from everything else. This makes me feel better about leaving this resolved as it is.

We got another comment about this, so I thought about it briefly again :)
A way to get this off users' radar almost entirely would be an ugly compromise under which Void is unaffected by @NullMarked, thus leaving its nullness unspecified. Similarly, Kotlin could treat appearances of Void in Kotlin code as having a platform type.
That is gross. And it might be a hard sell for Kotlin: The main problem inside Google has been Future<Void> (and occasionally some visitors in compiler plugins), but the average Kotlin code seems not to use Future<Void>, etc. as frequently. (That may be because Google's code interoperates more with existing systems that use Future.)

Yeah, I think the downsides of the special-casing would be approximately the same in that case.
We can file the ugly unfortunate bulk of Future<@Nullable Void> under "motivation to keep striving toward the bright Future<Void?> future".

For some code there's probably few actual return nulls but the @Nullable Void type virally spreads out from there. Maybe they would rather just suppress the warning in the former case and drop the annotation from Void. It's not like anyone on the consuming side would see Void and expect to be able to get a non-null value from it.

I think that suppressions will serve fine in many cases (especially in some of the vexing examples, like those involving the visitor pattern). But I would worry about suppressing in "normal" public APIs, again largely on account of Kotlin:

While I've gotten a little confused about the exact circumstances in which Kotlin inserts runtime null checks for calls to annotated Java methods, I do know we saw code that we needed to change from Void to Void? or Void to @Nullable Void in order to avoid such problems.
The problem may be bigger in the rarer case in which Kotlin code overrides a method: If the method is declared to return Void!, then Kotlin will make you declare it that way, and it will insert runtime checks that force it to throw NullPointerException rather than ever actually return null. This is worse than the previous case, in which you likely had options (casts, explicitly specifying variable types? But again, I've gotten confused about this) that you could employ if you were seeing runtime values.

Current decision: Do not special-case Void. Most (or maybe all) type usages of Void should be @Nullable Void, which is slightly awkward, but there are not that many type usages of Void anyway.
Argument for changing: It would be better not to have to type @Nullable Void all the time. @NonNull Void (or plain Void in null-marked code) is a vacuous type, so why make that easier to type/read?
Timing: This must be decided before version 1.0 of the spec.
Proposal for 1.0: Finalize the current decision. If you agree, please add a thumbs-up emoji (👍) to this comment. If you disagree, please add a thumbs-down emoji (👎) to this comment and briefly explain your disagreement. Please only add a thumbs-down if you feel you can make a strong case why this decision will be materially worse for users or tool providers than an alternative.

In fact, in a null-aware world, I would expect an equivalent of Kotlin's Unit to be more useful.

For me, it feels more like a workaround for a type system which does not support a simple names for nullable types. Even the documentation of Unit in Kotlin says, “This type corresponds to the void type in Java.” In Java, we just use Void directly. Anyway, it might be a good tradeoff considering that it reduces the complexity of the type system. (Complexity can also be bad for the user, after all.)
In a language which has native support for using void in type arguments, I would assume that the language would just forbid access to the value of symbols of that type, making the value (and therefore the difference between Void and Unit) indistinguishable.

But -- just to check my understanding -- for a return type is non-nullable Void also occasionally useful as that "nothing" type? For example, for a Callable that never completes normally? In that case, maybe passing the result of call() to anything is always bogus and would probably get the error it deserves.

Using Void in a way similar to Nothing doesn't work well in my experience. The problem is that it very often fails to provide a solution to satisfy javac.
Void unwrapThrowable(ExecutionException e) {
  Throwable cause = e.getCause();
  if (cause instanceof Error error) {
    throw error;
  } else if (cause instanceof RuntimeException runtimeException) {
    throw runtimeException;
  } else {
    throw new IllegalStateException(cause);
  }
}

Result doSomethingOnThreadPool() throws InterruptedException {
  try {
    return executorService.submit(this::doSomething).get();
  }
  catch (ExecutionException e) {
    unwrapThrowable(e); // We cannot return anything as we don't have a valid instance of `Result`.
  }
} // <- Compile Error because the method may not return

In one project at my company, we had introduced our own Never type for that. It is similar to Void in terms that it cannot have any value (except from null), but it also extends RuntimeException. This allows to satisfy the compiler by just adding throw before the method call.
Never unwrapThrowable(ExecutionException e) {
  ...
}

Result doSomethingOnThreadPool() throws InterruptedException {
  try {
    return executorService.submit(this::doSomething).get();
  }
  catch (ExecutionException e) {
    throw unwrapThrowable(e);
  }
}

Thanks for the comment, @JojOatXGME. I don't think you're disagreeing with the proposed conclusion here (do not special-case Void). Please correct me if I'm wrong.

To continue your discussion, I think there's a distinction between Void (one value: null) and void (no values). Kotlin's Unit is meant to be equivalent to Java's void in that you can omit it as a returned value since there is only one value and there is special syntactic treatment.

I don't think you're disagreeing with the proposed conclusion here (do not special-case Void). Please correct me if I'm wrong.

No, I am not disagreeing, as I understand that the pain may not be high enough to add a special rule only for this class. I find the conclusion a bit sad, though.

I think there's a distinction between Void (one value: null) and void (no values).

Yes, but Unit in Kotlin also has exactly one value.

Kotlin's Unit is meant to be equivalent to Java's void in that you can omit it as a returned value since there is only one value and there is special syntactic treatment.

Yes, but Kotlin could have added the same special treatment for Void? instead. Of course, it wouldn't be a nice solution if you had to add the quotation mark (?) everywhere. I cannot think of another good reason why Unit is better off with a single instance, instead of using null as the only value. Anyway, I don't think that this is a bad solution. I am not actually sure why I pointed that out. 😅 I guess I somehow interpreted the following quote a statement about a universal truth (to which I wouldn't agree), rather than a statement in the context of the JVM-ecosystem.

In fact, in a null-aware world, I would expect an equivalent of Kotlin's Unit to be more useful.

I don't think you're disagreeing with the proposed conclusion here (do not special-case Void). Please correct me if I'm wrong.

No, I am not disagreeing, as I understand that the pain may very well not be high enough to add a special rule only for this case.

Whew!

I find the conclusion a bit sad, though.

😢

I think there's a distinction between Void (one value: null) and void (no values).

Yes, but Unit in Kotlin also has exactly one value.

Kotlin's Unit is meant to be equivalent to Java's void in that you can omit it as a returned value since there is only one value and there is special syntactic treatment.

Yes, but Kotlin could have added the same special treatment for Void? instead. Of course, it wouldn't be a nice solution if you had to add the quotation mark (?) everywhere. I cannot think of another good reason why Unit is better off with a single instance, instead of using null as the only value. Anyway, I don't think that this is a bad solution. I am not actually sure why I pointed that out. 😅

If you're wondering why Kotlin decided to introduce Unit rather than just use Void?, then that's a good question, but not one I can answer. On the other hand, I think Void? is more complex than Unit because of that question mark.

I think there's a distinction between Void (one value: null) and void (no values).

Just to make it clear for posterity, the Java/JSpecify story is:

Void? has one value, null
Void! has no values
void is not a type


Change namespace "underscore" to "_"

https://github.com/farziengineer/underscore_cpp/blob/488f74eed359f06f49d27cfad4ba835bb4c0062a/underscore.cpp#L4

done at #50

@yashbhutoria please read the contribution guidelines before contributing. Anyway I am merging your PR.
Please ask to assign the issue to yourself before starting any work.
Thanks :)


help

hi
Can anyone help me?
i have 24 GPU Radeon rx580
i set this command by -r: this is Ok? cuBitCrack-cl --continue -r -i in.txt -o out.txt -b 64 -t 256 -p 512 --device 1
i want find best command
i list walet address is 32,000 count

-r is not an option in this repository.
See https://github.com/pikachunakapika/BitCrack for a forked version with -r (random) capabilities.


Sound selection command?

Thanks for the great code!
I got this working well but can't figure out how to make a service call to change the sound selection - all options seem to just adjust volume.
I can see there's an option for it in the original python package, any hints?

That is one thing I wasn't able to get working with Home Assistant when I wrote this. Most of the reason is that I had to expose the sound machine to HA as a fan. Fan entries only have a "speed" setting and an On/Off. I suppose that the sound selection could be exposed as some other type of device, but I haven't looked into it.


ImplementConfiguration.Width vs. Physical Width

Definition needed.   There is no working width at the time of configuration, so what other than physical width is there?

For now I've included Width alone, which I define as physical width.

Confirmation at Sept 7 2022 meeting

Superseded by #76


docs: Guideline Links Unavailable in CONTRIBUTING.md

What could be improved
The links for Style Guide and Testing Writing Guide in CONTRIBUTING.md are pointing towards default homepage of Flame instead of their own sections.
Why should this be improved

Because it will be easier for everyone to visit the recommended section and follow guidelines for contributing.
Any risks?

No
More information

Thanks for notifying us, the fixed links should be up momentarily.


Crash on extra long strings

Hi, I'm not sure if this is still actively maintained, but I figured I would put a report in.
I'm using this gem to help me deduplicate close matches between long strings of text. I enjoy the performance of the library, which is why I've been using it.
Recently, I noticed that when I have two close but not exact strings that are quite long the code was either crashing for getting killed.
The crash was regularly reproducible when comparing two strings of over 50,000 character in length. Shorter lengths were getting killed earlier but not crashing (~30,000 chars).
The stack trace is pointing at line 52 in the c code when it crashes:
 d[i*sl] = i;

... wondering if the strings need a more constrained buffer approach somewhere?
I can give more details if you need.
Thanks,
David

It is probably an integer overflow. Levenshtein algorithm also is geometrically less effective for long strings, so I think it makes sense to cut them to smaller substrings for comparison.

That's what I suspected, for now I just put a simple .slice before I process it, and that seems to work pretty well for my current purposes.


Fix GC bug

Description
Now returning error when one of the split cannot be deleted  https://github.com/quickwit-inc/quickwit/issues/604
How was this PR tested?
Unit test & cli commands

@guilload  I am thinking of getting rid of SplitDeletionStats since we only have now: delete all or nothing. Alternatively, we can have an error that contains SplitDeletionStats if we want to propagate splits that were deleted.
What's your take?

Yes, I'm in favor of getting rid of SplitDeletionStats. Do we currently have a use case for propagating the IDs of the splits that were deleted? Since it's pretty easy to implement, I'd do it only if the answer to that question is yes.


Explaining why Crossbeam is correct w.r.t. C11 memory model

Here is the promised RFC on the concurrency memory model and correctness of Crossbeam.
Rendered

I addressed @stjepang 's comments.  Thank you!

I added an ascii art on an example timeline.  Thank you!

Nice work! I'm just coming back from vacations and I plan to review this soon.

I gave the text another, more detailed read. As far as I'm concerned, it's almost good to go.
Let's just add another subsection to Alternatives and mention that it's possible to eliminate the SeqCst fence in unlink() by changing the invariant from G >= X+2 to G >= X+3.

Let's just add another subsection to Alternatives and mention that it's possible to eliminate the SeqCst fence in unlink() by changing the invariant from G >= X+2 to G >= X+3.

I haven't had time to read this in detail yet, but if this statement is true, we should almost certainly do this. On x86, this is the only type of fence that results in a hardware fence and it's a performance disaster, and on ArmV8 and Power this fence is more expensive than acquire/release fences.

it's possible to eliminate the SeqCst fence in unlink() by changing the invariant from G >= X+2 to G >= X+3.

Very interesting. Did you toyed with that yet? This potentially makes pinning much cheaper on non x86 (as x86 can use a lock CAS).

Very interesting. Did you toyed with that yet? This potentially makes pinning much cheaper on non x86 (as x86 can use a lock CAS).

Did you mean unlinking instead of pinning?
I didn't toy with this much, but: in Coco garbage is tagged with the current epoch only when flushing thread-local bags into global bags. The whole bag is tagged with the current epoch. Since tagging is so infrequent, its effect on performance is negligible.
In Crossbeam we might employ a slightly different strategy and tag garbage more often, but it's still probably unnecessary to tag absolutely every garbage object with the current epoch. For that reason eliminating the SeqCst fence possibly won't get us any performance wins...

Indeed, I got it all wrong. I need extra :coffee: before looking into this thread .

I mentioned @stjepang's proposal (to remove the SC fence from unlink()) in the "Unresolved Questions" section, because I am still not fully convinced that the proposal is correct.  (I agree with @schets on the performance of the proposal, even considering the fact that unlink()'s SC fences are amortized.)  I suggest we continue the discussion of https://github.com/crossbeam-rs/rfcs/pull/6#discussion_r130942541 in another RFC.

Thank you for all the inputs so far.  @schets @Vtec234 may I ask if you have further comments?

it would also be great to show why a pointer that is currently in use cannot be freed.

@Vtec234 Thank you for the suggestion.  I slightly revised the text so that it clearly explains that all the accesses to obj should happen before its deallocation.

I am merging it based on 4 approvals :)  Thank you for all the comments!


Missing build for appimageupdatetool

The latest continuous release has no binary for appimageupdatetool. This has broken build scripts for MuseScore in an unexpected way, causing nightly AppImages to shoot up in size.

Also, would be great to have numbered version releases of AppImageUpdate rather than always continuous. This way our build scripts can always use the last-known-good version to avoid temporary breakages like this. New versions don't have to be released very often.

Very surprising result, the filesize goes up, not down...
Should be fixed within the next minutes. I forgot to upload the appimageupdatetool AppImages as artifacts in the workflow file.


Would Help-text / descriptions be worth adding?

Would help text / descriptions make sense for forms for fields which may require more explanation, but you may not need an actual label?
Example:
Agree to terms of service
(Y/N)
By agreeing to terms of service, you allow us to send you emails

You can do this already via the hint attribute. For example,
Prompts::ConfirmPrompt.ask(label: "Agree to terms of service?", hint: "By agreeing to terms of service, you allow us to send you emails")

renders

   Agree to terms of service? (Press Enter to submit)
   By agreeing to terms of service, you allow us to send you emails

   Choose [y/n]: |

While some prompts (like Select and Text) come with a default hint, that hint is really only an expanded form of the instructions, which each prompt has and you cannot remove. So, setting or overriding hint is always possible and should never negatively impact usability.


Node local dns tenant network networkpolicy

After a few weeks of usage of node-local-dns we started to see issues with talking to the dns.
I don't know why this happens but after reading up on node-local-dns I understand why we need this rule.
This IP is very specific and I don't add any logic around it since it's the real IP of coreDNS service.

There is another IP used in AWS so that is why I use a variable in node-local-dns.

Have verified in another cluster without node-local-dns and it works as expected.
I feel ready to merge :)


[FEATURE]: Rename spatial_avg.py to spatial.py

Is your feature request related to a problem?
While working on #107, I noticed that I was adding temporal functions/methods to temporal_avg.py that weren't directly related to the TemporalAverageAccessor class. For example, the TemporalAverageAccessor.center_times() should actually just be a standalone function that lives in the .py module.
I ended up renaming the file from temporal_avg.py to temporal.py to store all temporal related functions and classes.
If we want to group functionality based on axes/dimensions, we should also rename spatial_avg.py to spatial.py.
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response

Hey @pochedls, let me know what you think about this.

Hey @pochedls, let me know what you think about this.

I like this a lot.

In addition to renaming the files, we can also rename the accessor classes so that we can keep methods like center_times() inside the classes, instead of separating them out as standalone functions.
For example, we can rename TemporalAverageAccessor to TemporalAccessor and SpatialAverageAccessor to SpatailAccessor.
I am leaning towards this route too.

@tomvothecoder I think this is ideal, you may want median, min, max, ..., operations in addition to average so more general axes/spatial and time coordinate/temporal is a smart more general move. Just thinking aloud, I wonder if vertical would be folded into axes, or would be its own class?
@pochedls has the arbitrary index discussion come up anywhere, so what I mean is captured in https://github.com/CDAT/cdat/issues/1288


gt and gT does not change tabs

Using the updated release 0.2.8-1 on Arch, for some reason I can't navigate tabs using gt and gT

This might be related to #586, where the tabs opened from File > Open File will work as expected, but any opened with the quick open toolbar are opened in a new buffer rather than a new tab.
Oni opens both tabs and buffers in the Oni tabline, meaning you do get some odd functionality, where gt and gT does work for some tabs and then skips others. The quick open (at least in the version I'm running), looks like it needs updating to always open via tabs rather than in a buffer.
Its a bit of a confusing user experience, since in vim language you have a mix of buffers and tabs, but   the in-Oni experience looks to just be tab based.

This happens if I use :e or :tabnew to open a file as well as using the Fuzzy Finder.

I'll check what are the occasions where it breaks because I noticed sometimes it works as expected.

Ok, it seems the Fuzzy Finder is the culprit.
To reproduce the bug enter in a git versioned project folder, open two files with :e or :tabnew and check that gt works. Open a new file with the Fuzzy Finder and see that now you can only navigate the previous amount of tabs - 1.

Interesting, thanks for the detailed repro, @badosu ! Yes, in most places, when we use the 'Open File' gesture we use :tabnew (basically open a file in a new tab), but it seems like in QuickOpen we use e:, which opens in the existing tabs. So the buffer is getting opened in one of the existing tabs.
I think it'd be reasonable to use :tabnew for this scenario in QuickOpen, if there is already an opened file - that would help alleviate some of the confusion here.

One could expect tua quick open do open in tua current tab qnd with ctrl-t to open in a new tab as ctrl-v opens a Split
Enviado do meu dispositivo Samsung
-------- Mensagem original --------
De : extr0py<EMAIL_ADDRESS>Data: 24/08/2017  01:22  (GMT-03:00)
Para: extr0py/oni<EMAIL_ADDRESS>Cc: Amadeus Folego<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Assunto: Re: [extr0py/oni] gt and gT does not change tabs (#657)
Interesting, thanks for the detailed repro, @badosu ! Yes, in most places, when we use the 'Open File' gesture we use :tabnew (basically open a file in a new tab), but it seems like in QuickOpen we use e:, which opens in the existing tabs. So the buffer is getting opened in one of the existing tabs.
I think it'd be reasonable to use :tabnew for this scenario in QuickOpen, if there is already an opened file - that would help alleviate some of the confusion here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/extr0py/oni","title":"extr0py/oni","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/extr0py/oni"}},"updates":{"snippets":[{"icon":"PERSON","message":"@extr0py in #657: Interesting, thanks for the detailed repro, @badosu ! Yes, in most places, when we use the 'Open File' gesture we use :tabnew (basically open a file in a new tab), but it seems like in QuickOpen we use e:, which opens in the existing tabs. So the buffer is getting opened in one of the existing tabs.\r\n\r\nI think it'd be reasonable to use :tabnew for this scenario in QuickOpen, if there is already an opened file - that would help alleviate some of the confusion here."}],"action":{"name":"View Issue","url":"https://github.com/extr0py/oni/issues/657#issuecomment-324528954"}}}

I think it'd be reasonable to use :tabnew for this scenario in QuickOpen, if there is already an opened file - that would help alleviate some of the confusion here.

That sounds like the most sensible option. We could also just expose the choice via an option. Defaulting to tabs I think makes the most sense since any non-vim users or vim newbies will find that more intuitive. If instead they did want to change it, we could have an option to change the default open action from tab to buffer or v/h splits or similar.

@extr0py I understood now what you mean by tabs and buffers, it seems like the tabs are not an actual replacement of vim tabs, what I expected to be. I wonder if that's possible as it's the behaviour I wanted, to just be a different presentation of the tabs with the same functionality.

I think it'd be reasonable to use :tabnew for this scenario in QuickOpen, if there is already an opened file - that would help alleviate some of the confusion here.

Yes if they have the show vim tabs this is reasonable otherwise have a c-t that will open a new tab much like c-s and c-v open splits, does this sound reasonable?
I can handle this easily in my PR

Also there seems to be so much confusion around this I was thinking of style the tabs differently for buffers that way people would know if it was a tab versus a buffer.

I wonder if that's possible as it's the behaviour I wanted, to just be a different presentation of the tabs with the same functionality.

@badosu - Did you try setting the tabs.showVimTabs setting to true?  (it will use the tab information instead of the buffer-list as the backing data, but same tab UI). I think that should give you the behavior you're expecting.

Yes if they have the show vim tabs this is reasonable otherwise have a c-t that will open a new tab much like c-s and c-v open splits, does this sound reasonable?

@cyansprite , sounds great to me!

Also there seems to be so much confusion around this I was thinking of styling the tabs differently for buffers that way people would know if it was a tab versus a buffer.

Yes, I was thinking about this too! Styling the tabs differently is an interesting idea. We don't really mix the buffers/tabs together though - it's either showing "buffers" or "tabs", so I guess it wouldn't look different until you change the tabs.showVimTabs to true?
I think the big problem is discoverability - it's hard to know why Oni's tabs are behaving the way they are, if you expect Vim tabs. In a similiar vein, one thing I was thinking about (it was actually in my original todo list), was to have a 'buffer/tab' mode switcher in the far right of the tab line. If it was done right, it would make it obvious (once you discover that UI affordance) that it's showing buffers instead of vim tabs.
Alternatively, perhaps we could add an option in the Menu bar to allow switching between these tabs?

@badosu - Did you try setting the tabs.showVimTabs setting to true? (it will use the tab information instead of the buffer-list as the backing data, but same tab UI). I think that should give you the behavior you're expecting.

Well, it works with vim's native tabs instead of the nice looking ones from Oni.

Well, it works with vim's native tabs instead of the nice looking ones from Oni.

Interesting, do you have a screenshot of what you are seeing with tabs.showVimTabs set to true? If it's working correctly, it should use the exact same UI, just be backed by the tab data instead of by the buffers (which would be different in cases where there are multiple buffers in a tab)
I also realized it's kind of a misleading name (and that I'm bad at naming configuration variables)... It's not actually changing the UI representation, but the underlying data - if it's set to false, we use the buffers as the data model, if it's set to true, we use the tabs as the data model - but the UI is the same.
Here's a quick gif I made:

I start in the default mode "buffers-as-tab-UI", and the current behavior of QuickOpen is :e (so open in current tab) - but each file gets its own tab, since we're in the buffer mode.
Once I switch over the "vim-tabs-as-tab-UI" mode by setting tabs.showVimTabs to true - they collapse to one tab, because it's actually just one vim tab with four open buffers. With tabs.showVimTabs set to false, I see 4 tabs in the UI (since there are 4 buffers), but if I set tabs.showVimTabs set to true, I see 1 tab in the UI (since there is one vim-tab).
Hope that helps clarify a bit-

This is how it is shown on one of the places I use Oni (Arch as well).

I would appreciate if there was an option to disable the tabs as buffers and use the tab layout to replace the current native vim layout as is shown in the image above. (i.e. tabs on the new UI behave exactly like the vim tabs)

Thanks for sharing the screenshot, @badosu ! I didn't see the tabs.showVimTabs option set to true in the screenshot you posted, but I'm assuming you tried that and it still didn't work?
The fact that you still see the original tab bar suggests to me that the version of Neovim you are running doesn't support the ext_tablines option (which is needed for tabs.showVimTabs to work correctly, and for the original tab bar to be hidden).
Could you please share the Neovim version you are running via (nvim --version)? Any neovim version v0.2.1 or greater should support this option (ext_tabline), so if it is lower than that, you might consider upgrading.

@extr0py Thanks for the response, nvim reports version 0.2.0, gonna try a git release and see if these problems remain, for both use cases (showVimTabs true and false).

I see now, 0.2.1 was not released yet, using the git version works. Hopefully oni will push neovim's capabilities, so that's to be expected. I think it would be good to add a remark for this on the README.

Good point, I added some notes in the wiki here: https://github.com/extr0py/oni/wiki/Configuration#tabs
I'd also like to handle this more gracefully (like some sort of warning that the setting is incompatible with the current version of Neovim). It would be great to package a consistent version of Neovim across Linux too (like the one embedded for Windows & OSX)

Well, as soon as then next version of neovim is released it will be soon picked up as Arch has a rolling release model. Neovim did not release 0.2.1 yet.

@extr0py At least for Arch the package is consistent, the difference being that it uses the last stable version for neovim (0.2.0). See: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=oni#n9
We can change it to reference neovim-git instead, let me know your thoughts.

Excellent, thanks for the details @badosu  (and all your help managing Oni in the AUR!)
I think moving to neovim-git makes sense, to provide a good out-of-the-box experience (esp for the new functionality, like tabs). It'd be nice at some point to use a consistent version between windows/OSX/linux. Windows/OSX are using: v<IP_ADDRESS>-g9847be58 - I wonder if there is a way to directly reference that in AUR as a dependency?
I noticed one other item that might need to change for the 0.2.9 release:
source=("https://github.com/extr0py/${pkgname}/releases/download/v${pkgver}/${pkgname}-${pkgver}.tar.gz"
        "oni.sh")

It looks like, after updating electron-builder, our package is now: https://github.com/extr0py/oni/releases/download/v0.2.9/Oni-0.2.9-linux.tar.gz
There might be a way we can tweak some settings on electron-builder to go back to the previous package name, if that is necessary.
Thanks again for your help!

It'd be nice at some point to use a consistent version between windows/OSX/linux. Windows/OSX are using: v<IP_ADDRESS>-g9847be58 - I wonder if there is a way to directly reference that in AUR as a dependency?

@extr0py This is weird, latest stable release I can see is 0.2.0 (see https://github.com/neovim/neovim/releases). Is there any other place where neovim states their releases?

@extr0py Updated AUR for release 0.2.9 (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=oni).
Can you please take a look at electron-builder to generate a .desktop file? Or taking a look at an AppImage release. See https://www.electron.build/configuration/linux


Post release automated changes for reservations releases

Post release automated changes for azure-arm-reservations

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


Add 3d media type / mesh support

Changes

Added a new media type 3d to support 3D visualizations.
Implemented classes for Scene, Material, Mesh, Shape, PointCloud, and Light, along with their respective serialization and deserialization logic.
Add rendering logic tailored for FiftyOne 3d scenes.
Add support for exporting/importing fo3d files

Testing

Unit tests for newly introduced SDK classes
Currently working on Playwright tests to cover end-to-end workflows

@coderabbitai review

Nominal approval - we decided we will merge and further changes requested may be made in a follow up PR


[Bug][Tabler] Choose login view

The login page we have now is a bit underwhelming & unpolished:

I think we should have a few different login views, and let the developer easily choose between them:
Default
We use the proper classes, borders, spaces etc from https://preview.tabler.io/sign-in.html

Illustration
We use the design and illustration from https://preview.tabler.io/sign-in-illustration.html

Cover
We use the design and image from https://preview.tabler.io/sign-in-cover.html (or a better image if we can find a free stock image that is better than that one)

Looking good so far! 🎉
Let's stop working on the mauro branch please - I'm sure it'll turn into a huge PR, that is difficult to review and merge. Instead let's do feature branches. This is a separate feature. It needs a separate branch, with a separate PR. That way, everything that's unrelated to this can be reviewed and merged before.

Looking good so far! 🎉
Let's stop working on the mauro branch please - I'm sure it'll turn into a huge PR, that is difficult to review and merge. Instead let's do feature branches. This is a separate feature. It needs a separate branch, with a separate PR. That way, everything that's unrelated to this can be reviewed and merged before.

@tabacitu Done! I moved this and other changes to a separated branch. Will create new branches for next issues from now on.

Done in https://github.com/Laravel-Backpack/theme-tabler/pull/18 - let's move the conversation there.


Napari Viewer PySide6 Backend AttributeError

🐛 Bug

Dear napari team,
I would like to use the napari-deeplabcut plugin to annotate images.  I get the error:
AttributeError: 'PySide6.QtGui.QSurfaceFormat' object has no attribute 'DoubleBuffer'
when I open the config.yaml file.
To Reproduce
Steps to reproduce the behavior:

Installed napari
Installed deeplabcut-napari
Installed PySide6

Starting GUI...
Traceback (most recent call last):
  File "/lib/python3.8/site-packages/deeplabcut/gui/tabs/label_frames.py", line 55, in label_frames
    _ = launch_napari(folder)
  File "/lib/python3.8/site-packages/deeplabcut/gui/widgets.py", line 38, in launch_napari
    viewer = napari.Viewer()
  File "/lib/python3.8/site-packages/napari/viewer.py", line 67, in __init__
    self._window = Window(self, show=show)
  File "/lib/python3.8/site-packages/napari/_qt/qt_main_window.py", line 463, in __init__
    self._qt_window = _QtMainWindow(viewer)
  File "/lib/python3.8/site-packages/napari/_qt/qt_main_window.py", line 88, in __init__
    self._qt_viewer = QtViewer(viewer, show_welcome_screen=True)
  File "/lib/python3.8/site-packages/napari/_qt/qt_viewer.py", line 217, in __init__
    self._create_canvas()
  File "/lib/python3.8/site-packages/napari/_qt/qt_viewer.py", line 401, in _create_canvas
    self.canvas = VispyCanvas(
  File "/lib/python3.8/site-packages/napari/_vispy/canvas.py", line 33, in __init__
    super().__init__(*args, **kwargs)
  File "/lib/python3.8/site-packages/vispy/scene/canvas.py", line 135, in __init__
    super(SceneCanvas, self).__init__(
  File "/lib/python3.8/site-packages/vispy/app/canvas.py", line 211, in __init__
    self.create_native()
  File "/lib/python3.8/site-packages/vispy/app/canvas.py", line 228, in create_native
    self._app.backend_module.CanvasBackend(self, **self._backend_kwargs)
  File "/lib/python3.8/site-packages/vispy/app/backends/_qt.py", line 372, in __init__
    self._init_specific(p, kwargs)
  File "/lib/python3.8/site-packages/vispy/app/backends/_qt.py", line 791, in _init_specific
    glformat = _set_config(p.context.config)
  File "/lib/python3.8/site-packages/vispy/app/backends/_qt.py", line 283, in _set_config
    glformat.setSwapBehavior(glformat.DoubleBuffer if c['double_buffer']
AttributeError: 'PySide6.QtGui.QSurfaceFormat' object has no attribute 'DoubleBuffer'

Expected behavior

Environment
napari: 0.4.17
Platform: Linux-3.10.0-1160.el7.x86_64-x86_64-with-glibc2.10
Python: 3.8.17 | packaged by conda-forge | (default, Jun 16 2023, 07:06:00) [GCC 11.4.0]
Qt: 5.15.6
PyQt5: 5.15.7
NumPy: 1.24.4
SciPy: 1.10.1
Dask: 2023.5.0
VisPy: 0.11.0
magicgui: 0.7.2
superqt: unknown
in-n-out: 0.1.8
app-model: 0.1.4
npe2: 0.7.0

OpenGL:
- GL version:
- MAX_TEXTURE_SIZE: ()

Screens:
- screen 1: resolution 1920x1080, scale 1.0
- screen 2: resolution 2560x1440, scale 1.0
- screen 3: resolution 2560x1440, scale 1.0

Additional context

np

napari 0.4.17 does not support PySide6, Please update napari to 0.4.18 and ensure that Pyside6 is bellow version 6.4.3

Also, it looks like you have two different QT backends installed, because your traceback has Pyside6 while your --info has pyqt5. Also if you need Qt6, you may want to move to python 3.10 because there are some QT6 limitations in the older versions.


goreleaser: 1.23.0 -> 1.24.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/goreleaser/versions.
meta.description for goreleaser is: Deliver Go binaries as fast and easily as possible
meta.homepage for goreleaser is: https://goreleaser.com
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.24.0 with grep in /nix/store/m3jc0h1gdk2psjdbm9a415lldw41bmcv-goreleaser-1.24.0
found 1.24.0 in filename of file in /nix/store/m3jc0h1gdk2psjdbm9a415lldw41bmcv-goreleaser-1.24.0

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
goreleaser

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/m3jc0h1gdk2psjdbm9a415lldw41bmcv-goreleaser-1.24.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/80b30a60e070f43ceb6242a10f1bfdf89d9f2d91#goreleaser

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/m3jc0h1gdk2psjdbm9a415lldw41bmcv-goreleaser-1.24.0
ls -la /nix/store/m3jc0h1gdk2psjdbm9a415lldw41bmcv-goreleaser-1.24.0/bin

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

1 package built:

goreleaser

Maintainer pings
cc @c0deaddict @endocrimes @sarcasticadmin @techknowlogick @developer-guy @caarlos0 for testing.


TTY::Screen#size_from_ioctl reads terminal size is failing in s390x

Describe the problem
The test TTY::Screen#size_from_ioctl reads terminal size is failing in s390x. This is happening in Debian and Ubuntu CI infrastructure:
https://ci.debian.net/data/autopkgtest/unstable/s390x/r/ruby-tty-screen/21749140/log.gz
<EMAIL_ADDRESS>Steps to reproduce the problem
Run the test in a s390x machine.
Actual behaviour
Failures:

  1) TTY::Screen#size_from_ioctl reads terminal size
     Failure/Error: expect(screen.size_from_ioctl).to eq([51, 211])

       expected: [51, 211]
            got: [13056, 54016]

       (compared using ==)
     # ./spec/unit/screen_spec.rb:115:in `block (4 levels) in <top (required)>'
     # ./spec/unit/screen_spec.rb:108:in `replace_streams'
     # ./spec/unit/screen_spec.rb:114:in `block (3 levels) in <top (required)>'

Top 2 slowest examples (0.01432 seconds, 67.2% of total time):
  TTY::Screen#size_from_tput doesn't run command if outside of terminal
    0.00727 seconds ./spec/unit/screen_spec.rb:125
  TTY::Screen#size_from_ioctl reads terminal size
    0.00705 seconds ./spec/unit/screen_spec.rb:113

Finished in 0.02131 seconds (files took 0.07922 seconds to load)
26 examples, 1 failure

Expected behaviour
The test passes also in s390x.
Describe your environment

OS version: Debian unstable and Ubuntu 22.10
Ruby version: 3.0
TTY::Screen version: 0.8.1

Some extra info in this Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/ruby-tty-screen/+bug/1968831

Hi Lucas,
I believe this to be a duplicate of the issue that has already been addressed.


Adding flag in MCSMain to toggle debug logs within the editor. Added …

…(ENABLE_DEBUG_LOGS) as command line argument to enable logs within the builds.

Sorry, didn't see this until now. Feel free to tag our team as Reviewers next time.