Various differences in blur, shading, or tinting

Describe the bug
The most recent updates have made some things look much brighter without any changes to my settings.
To Reproduce
The way I compared back to the old version of the theme was throwing the old theme from your deploy branch into my custom css while using an invalid import url in the theme settings file. To go back to the new version I removed the custom css and fixed the import url in the theme settings file.
If it helps here is my settings file (renamed to txt for upload): FrostedGlass.theme.css.txt
Screenshots
Here's a few examples of what it looks like before and after the recent updates:
Before:

After:

Before:

After:

Before:

After:

Infomation (please complete the following information)
Discord channel: Stable
OS: Windows
Mod: BetterDiscord
Discord language: English

I've also noticed that the variable --popout-modal-brightness doesn't seem to change anything that I can see, and besides the popups mentioned above, the one you get when you right click a forum post (to say, easily follow a post or add tags) is, at least with my current background, too bright and I could not find a way to change how this appears.

I've also noticed that the variable --popout-modal-brightness doesn't seem to change anything that I can see, and besides the popups mentioned above, the one you get when you right click a forum post (to say, easily follow a post or add tags) is, at least with my current background, too bright and I could not find a way to change how this appears.

To add to this I also noticed that in the deploy branch those variables were changed along but even the updated ones don't work https://github.com/DiscordStyles/FrostedGlass/blob/114fcf9f5bfe9849e7b1bfc18a73a6bc0cfacb3c/FrostedGlass.theme.css#L28-L31 https://github.com/DiscordStyles/FrostedGlass/blob/114fcf9f5bfe9849e7b1bfc18a73a6bc0cfacb3c/FrostedGlass.theme.css#L52

I must've set something up incorrectly as it should just work.
I'll take a look later today.

To further add to this, the variables for tint (--tint-colour and --tint-brightness) are currently having no effect.

Hope this helps!

@Kuuuube Can you share your .theme.css file?

GitHub I didn't say close it!

Can confirm that tinting and pop-out variables appear to be fixed!

It should've been fixed.

Everything seems to be fixed now as far as i can tell except the popout when clicking on someone's name. Both on the right sidebar or above a message.

hey popout-modal-brightness is still not doing anything for me

Repalce --popout-modal-brightness with overlay-brightness

Closing as this appears to be completely fixed. I can't find any areas where it's broken anymore.


Notable Event Types Doc Update  - An include directive is not expanded properly

Re: Notable Event Types
See:

The include should be expanded into a callout instead.
cc @taroface

@yzdocs Do you have any insight as to why this include isn't being properly rendered? Is it perhaps because we are using the remote_include functionality to embed the content in that screenshot, which contains the above include?
This experimental-warning include is placed here and generated into this doc, which is what the remote_include points to.

cc @ianjevans on the above remote_include question.

I looked into this, and the remote_include is being processed after the Liquid tags are all processed. I think there might be a way to trigger a Liquid converter within the plugin.
https://github.com/ianjevans/jekyll-remote-include/issues/4


Simplify/clarify the lint functions (should be no behavior change).

Codecov Report

Merging #56 into master will increase coverage by 0.07%.
The diff coverage is 80.76%.

@@            Coverage Diff             @@
##           master      #56      +/-   ##
==========================================
+ Coverage    41.4%   41.47%   +0.07%
==========================================
  Files           8        8
  Lines         454      446       -8
==========================================
- Hits          188      185       -3
+ Misses        266      261       -5

Impacted Files
Coverage Δ

jupyterlab_celltests/shared.py
82.69% <ø> (ø)
:arrow_up:

jupyterlab_celltests/lint.py
41.41% <80.76%> (+0.29%)
:arrow_up:

Continue to review full report at Codecov.

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

Actually, maybe this isn't quite ready yet.


line 8; remove unnecessary a

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit db9ec4fb2c77cc7f28f6c9bb14577c30a8fa0e21
https://deploy-preview-8672--docsdocker.netlify.com


FIxed has_content? whitespace comparison

has_content? should ignore any whitespace in the content being compared (the matcher text) so that comparing whitespace sensitive text i.e. content in a /pre/ tag will be matched properly.

Wouldn't it be better to use something like /\s/ instead of "\n"?

@joliss that change made a more test fail. The important thing would be to match however the XPath::HTML.content is ignoring whitespace. It looks like content using an xpath contains which may be ignoring whitespace. I didn't dig much further but I believe that would be handled bu Nokogiri and in turn LibXML. I'm not 100% sure though.

I agree with Jo that if we do this, the regexp should be something like /\s/m or whatever that modifier is that switches to multiline mode.

the regexp should be something like /\s/m or whatever that modifier is that switches to multiline mode.

The m modifier only matters for /./ (so that the dot matches newlines), not for /\s/, so far as I know.
Jo,
still recovering from the shock that the MULTILINE option is written /m in Ruby, not /s like the rest of the world

It turns out that XPath::HTML normalizes content through xpath function normalize-whitespace. This doesn't behave the exactly the same as gsub(/\s/m, ""). The normalize-whitespace function works by "stripping leading and trailing whitespace and replacing sequences of whitespace characters by a single space". http://www.w3.org/TR/xpath/#function-normalize-space
What I ended up doing to make this behave more like the normalize-whitespace function was to replace the matched whitespace with a single space character.
I think the /\s/ suggestion was a good one and I've just pushed a change to make it work better in all cases. Thanks for the feedback @joliss and @jnicklas.

We probably want to normalize whitespace vs. just removing newlines, like so:
>> " apple\n   orange  ".gsub(/\s+/, ' ').strip
=> "apple orange"

This is symmetrical with how the XPath normalize-space function works.

@mkdynamic that makes sense. I must have pushed just as you commented. :) The latest change (removing the /m modifier) if pushed.

@mkdynamic do you know if it is preferable within capybara to make something like gsub(/\s/, " ").strip a call to a function like normalize_whitespace(content) or leave it in-line?

Since you'll need to call this from both has_content? and has_no_content? I would move it into it's own (probably private) method.

Good job!


FR: Upgrade viem to 2.0

Viem has released version 2.0, so we should upgrade our library to 2.0 (https://viem.sh/docs/migration-guide.html#_2-0-x-breaking-changes)
TBD, will this be a breaking change for our library? I think yea since the assumption is users might be using viem as well, so they might experience breaking changes related to viem

Yes

Yes @moldy530 , there are breaking changes.
The problem is that some tool's latest versions are already prepared for Viem 2 (Web3 Modal and wallet connect, for example), so they would break if I downgrade to Viem 1 just for Alchemy.


[AutoPR hybriddatamanager/resource-manager] Addition of HybridDataManager

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/5313

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/4829


Website small updates

I think the website should no longer be green, but rather represent the color theme of Vulkano. I'm assuming that's what's in the logo.
Disclaimer: I am no web designer, but still thought that the website could be improved even with these small things
This PR:

Adds some icons for faster navigation
Updates the colors
improves some textual parts and removes unnecessary "notes". E.g. on the front page, we should not be short selling vulkano. Even if the "goals" are not fully reached yet.
Fixes some typos and edits the introduction etc. in the guide

I was thinking that perhaps the Windowing section could be replaced with a tutorial to make e.g. interactive-fracal or game-of-life or any traditional example that will showcase core loop, windowing, compute shaders and rendering pipelines.
So that's what I am going to do next (when I get a moment). But wanted to get started with these little tweaks.

Seems there are conflicts, gonna resolve those...

I think these are some good tweaks, the website feels more fresh, specially with the new icons.
I think we should leave the Windowing example. My plan was to make it use the triangle example from the main repository, in a way that it only explains core windowing (in a more theoretical way) and enhances the previous example. After that there could be a practical chapter that uses all the previous explained functionalities with a more complex project, like the examples you gave. This could be, for example, analagous to what the rust book does with the chapters like these.
I plan to add one or more chapters about 3d rendering, using the standard cube example. This would better explain buffers and the graphics pipeline, as well as introduce advanced topics like instancing (that feel more interactive).

Sounds good @ZakStar17 !


Anyone working on this?

Is anyone still working on the Julia implementations or has it been scrapped?

No, this project has not been scrapped.
I am still working on this project, I will push some changes soon.

Great!

why was this project scrapped??

This project is not scrapped.
I am working on this.


Make Prepared play nicer with connection pools

As @Marenz pointed out over here, since prepared statements are (as per the way MySQL works) tied to a specific connection, using them in combination with connection pools is awkward and leads to questionable benefit.
Need some mechanism, probably a connection-independent wrapper for Prepared, to help alleviate those issues.

Me:

All registration/release of prepared statements are subject to be internally delayed, at the Connection's discresion, until the next time a statement is issued on the Connection. This is necessary because there may be data pending on the connection. This delay is also completely safe, because a registered prepared statement cannot be used anyway until pending data is purged (as of v1.1.4, the next statement issued automatically purges any remaining data pending).

Turns out that delaying statement registration until after the next purge has some ugly consequences I wasn't anticipating[*]. Not sure why I was thinking it was needed anyway though - auto-purging when a statement is created isn't going to cause the kind of nasty surprise that auto-purging on statement release could've caused.
So creating a prepared statement won't be delayed: It'll occur immediately, auto-purging any data that might be pending. As before, only release will be delayed to avoid a surprise auto-purging.
([*] It would've meant that an instance of Prepared could potentially be in a not-yet-ready state, lacking certain necessary info from the server. This state would have necessarily been distinct from "was created, but is now released", and it led to a bunch of mess.)

@schveiguy I looked at the std.variant code before.  It's not so easy to just "make it work with std.conv.to", because Variant is supposed to be an open-ended union of all possible types. This is currently done via runtime typeids, which is why you need to know the underlying type before you get extract it (TypeInfos do not have a "can convert to" method, after all, so the best you can do is "is typeid(X) == typeid(Y)?"). But std.conv.to requires knowledge of the source and target types at compile-time. Presently, I don't have any good ideas about how to put the two together.
In my NIH SQLite binding, what I did was essentially:
struct Column {
    T opCast(T)() {
        import std.conv : to;
        switch (sqliteType) {
            case SQLITE_INTEGER: return impl.getInteger().to!T;
            case SQLITE_VARCHAR: returun impl.getString().to!T;
            ...
        }
    }
}

I used opCast because that's what std.conv.to understands, so user code could just call to!X on a Column object to get whatever type X that they want.
Now, arguably, I could have use Algebraic to encode the SQLite types and returned that instead, and presumably I'd be able to loop over the possible types at runtime and figured out which one would convert to the user's requested type.  But it seemed like so much work for what the above admittedly-hackish opCast can do, in addition to having an uglier user-facing API.
Not to mention that by deferring the actual call to the SQLite library inside opCast, I saved the cost of converting SQLite types to D types for every column if the user code doesn't actually need to read every column. (E.g., if column C in the result set is only accessed for a subset of rows.)

Well, maybe then the answer is to use Algebraic instead. Surely the set of types the database supports is finite.

And does std.conv.to support Algebraic?


Added ability to use oAuth token instead of private token for API calls

gitlab.com supports oAuth tokens as a way to authenticate when using their API. This is a very simple change to allow this type of token. It might not be the best way. Feel free to let me know, what you prefer and I can change the PR accordingly.
https://gitlab.com/help/api/README.md#authentication-with-oauth2-token

Looking great, thanks for the pr!


[docs] try to add python examples for symbol

attempt to add code examples in the docs..
preview at http://mxnet.dmlc.ml/packages/python/symbol.html#mxnet.symbol.Concat
but i'm not convinced to add the python examples in the .cc file.. @tqchen @pluskid

One alternative way is to, in symbol.py, define dummy classes like ConcatDoc as subclass of OperatorDoc, and add examples as docstrings to this class. Then during importing operators, look for subclasses of OperatorDoc with matching name. If one found, then append / merge docstring from there to the imported operator. In this way, it will not affect other languages.

Something like this:
name = # the name of the operator to be defined

doc = "\n".join([x.__doc__ for x in type.__subclasses__(SymbolDoc)
                 if x.__name__ == '%sDoc' % name])

# append doc to docstring of newly defined operator

Then you can write
class ConcatDoct(SymbolDoc):
    """This is some extra doc for the Concat operator in Python.

    blah blah...
    """
    pass

@mli please fix the lint error and let us merge it in


duplicate repos showing in following section (or having more next repos) when toggling view states

Preconditions:

Either have a following section with more next repos
Or have any section with more next repos
personal repos has less than 30 repos

In this case, it is a following section with more next repos
Steps

Load following repos view
Load personal repos view
Load following repos view

Expected: Only the original 30 repos should show
Actual: The original 30 repos are duplicated

looks like props are being preserved, and so on (re) mount, the call to get user subscriptions is being made

The issue is in the store
https://github.com/thescientist13/github-dashboard/blob/master/src/stores/github-store.ts#L67
What's happening is that the store always pushes repos on to the store.  This means that in the case above, we are just concatenating the same 30 repos onto the store over again.
The solution is that the store and the new state need to be merged, so that duplicates overwrite each other.

adding technical label as more work on this reveals a certain fragility to the consistency of the state over time, so a refactoring will likely be required as part of this effort


Decide if integer indexing is required.

Do we require integer indexing on X? Specification currently proposes "no", and provides for consistent label-based indexing across X/obs/var.

Clarifying that this question is regarding positional indexing, i,e, non-label based access to arrays by position.

I think positional indexing makes a lot of sense as a requirement. I'm not sure how high performance access would work without it.

Positional indexing is implemented: https://github.com/single-cell-data/SOMA/blob/main/abstract_specification.md


Balanced Chunks

Motivation:
Right now, the chunking uses a greedy algorithm. The following would output the following chunks:
let text = "Sentence 1. Sentence 2. Sentence 3. Sentence 4.";
splitter.chunks(text, 36) == ["Sentence 1. Sentence 2. Sentence 3.", "Sentence 4."]

This may not always be desirable, since it can leave "orphaned" elements at the end.
In some cases it would be better to realize at this semantic level there is a more ideal split of:
["Sentence 1. Sentence 2.", "Sentence 3. Sentence 4."]

Finding this is not straightforward in all cases, I attempted it in the past, but at least that attempt led to the algorithm generating several more chunks, rather than finding the best split point. Because tokenization isn't always predictable, there may need to be some allowance for extra chunks being generated, but ideally we can find good split points within the current number of chunks.
Todo:

[ ] TextSplitter and MarkdownSplitter should both have an opt-in method of enabling balanced chunking (this behavior may be better in all scenarios, but it is unclear, and we need to probably pour over the snapshot diffs to see how much of a difference it makes).
[ ] Ideally, the number of chunks generated is the same, just the split points move around. Some tolerance would be allowable, but ideally we can strive to keep this minimal.

Hi Ben!
First of all a big thank you for this package. It is taking away the pain from poorly performing Python-based frameworks and exactly what I was looking for.
I think what you describe here with "balanced chunks" is actually something that nowadays is called "semantic chunking" (not to be confused with purely punctuation- or grammar-based semantics that you already implemented) with strategies like MMR, RAPTOR or combinations of those. I wrote about this in more detail here https://github.com/do-me/SemanticFinder/discussions/45 but the core idea really boils down to:

In a nutshell you use sliding chunk windows and calculate their embeddings and their distance to each other. Using this score you are trying to identify semantic "break points" i.e. where you have the largest delta.

Imho if you spin your idea further of splitting text more "human-like" then you would necessarily end up with a similar strategy at some point.
This is of course very computation-heavy and would outshine the great performance-gains that you achieve here. Maybe it's also out of scope as Langchain already implemented it. What is your opinion about this?

Hi @do-me thanks for this. I had this more scoped here: https://github.com/users/benbrandt/projects/2?pane=issue&itemId=57419637
Basically this issue is more that the current algorithm is "greedy", but if we know we are within a certain semantic level, I think there might be a way to try and spread the content out more evenly between the chunks of the level.
Does that make sense?
I do agree that all of the semantic embedding approaches are interesting. I am hopeful my crate can be helpful in terms of making sure that all of the chunks being embedded are within the context window of the embedding model, and allowing for a two-pass approach... but it all needs to be explored :)

The URL leads me to an empty description somehow :D

However, thanks for clarifying, that makes a lot of sense. So if I get you right, you would say all these fancy heuristics are out-of-scope for text-splitter as they'd introduce a lot of overhead.

That is because I haven't really scoped it out yet 😆
I don't think it is out-of-scope, but will likely be an opt-in. I think I would provide both options so people can make the tradeoff on performance vs potential quality improvement.
That being said, I want to get a few other features done first, namely chunk overlap and Code splitting, and then I would probably reassess priority from there. Hopefully that makes sense?

Sure, sounds really exciting! :) Looking forward to your future developments!

This would be a great feature.
Maybe food for thought... Previously I'd have a bunch of documents that I'd pre-calcuate the total (token) size of those documents, find the outliers, then chunk them down using the median of the non-outlier distribution. This way, the outliers get merged into the bell curve.
Obviously you wouldn't want to chunk twice and "waste" the compute of the first cycle. So I think you can take the total size of the text, and make an educated guess on how to make balanced chunks. I think it's pretty much implicit if you turn on "balanced chunking", the chunking boundary would no longer be exactly the user provided token or character size.

If anyone is curious, I implemented this in my crate. I had previously done this in python last year and submitted it as a PR to langchain, but it went no where.
I wrote a comparison test here.
Balance comparison for content: The ACM A. M. Turing A...
 content token_count: 284
absolute_length_max: 128
overlap_percent: 0.166666

TextChunker result without overlap:
chunk_count: 3
avg_token_size: 95
largest_token_size: 97
smallest_token_size: 92

TextChunker result with overlap:
chunk_count: 3
avg_token_size: 112
largest_token_size: 114
smallest_token_size: 112

TextSplitter result without overlap:
chunk_count: 3
avg_token_size: 94
largest_token_size: 123
smallest_token_size: 45

TextSplitter result with overlap:
chunk_count: 3
avg_token_size: 95
largest_token_size: 103
smallest_token_size: 87

Balance comparison for content: Doom (stylized as DOOM...
 content token_count: 1244
absolute_length_max: 256
overlap_percent: 0.166666

TextChunker result without overlap:
chunk_count: 5
avg_token_size: 251
largest_token_size: 255
smallest_token_size: 249

TextChunker result with overlap:
chunk_count: 6
avg_token_size: 233
largest_token_size: 251
smallest_token_size: 225

TextSplitter result without overlap:
chunk_count: 7
avg_token_size: 177
largest_token_size: 247
smallest_token_size: 135

TextSplitter result with overlap:
chunk_count: 9
avg_token_size: 142
largest_token_size: 178
smallest_token_size: 94

Balance comparison for content: Who Controls OpenAI?
M...
 content token_count: 4828
absolute_length_max: 512
overlap_percent: 0.166666

TextChunker result without overlap:
chunk_count: 11
avg_token_size: 435
largest_token_size: 498
smallest_token_size: 389

TextChunker result with overlap:
chunk_count: 12
avg_token_size: 457
largest_token_size: 489
smallest_token_size: 446

TextSplitter result without overlap:
chunk_count: 12
avg_token_size: 401
largest_token_size: 509
smallest_token_size: 152

TextSplitter result with overlap:
chunk_count: 16
avg_token_size: 321
largest_token_size: 420
smallest_token_size: 111

Balance comparison for content: The Call of the Wild
b...
 content token_count: 39823
absolute_length_max: 1024
overlap_percent: 0.166666

TextChunker result without overlap:
chunk_count: 46
avg_token_size: 865
largest_token_size: 1008
smallest_token_size: 766

TextChunker result with overlap:
chunk_count: 51
avg_token_size: 912
largest_token_size: 962
smallest_token_size: 894

TextSplitter result without overlap:
chunk_count: 43
avg_token_size: 926
largest_token_size: 1024
smallest_token_size: 607

TextSplitter result with overlap:
chunk_count: 60
avg_token_size: 757
largest_token_size: 852
smallest_token_size: 440

Balance comparison for content: MEDITATIONS
By Marcus ...
 content token_count: 78479
absolute_length_max: 2048
overlap_percent: 0.166666

TextChunker result without overlap:
chunk_count: 46
avg_token_size: 1703
largest_token_size: 1957
smallest_token_size: 1536

TextChunker result with overlap:
chunk_count: 50
avg_token_size: 1819
largest_token_size: 2020
smallest_token_size: 1782

TextSplitter result without overlap:
chunk_count: 43
avg_token_size: 1825
largest_token_size: 2047
smallest_token_size: 774

TextSplitter result with overlap:
chunk_count: 60
avg_token_size: 1518
largest_token_size: 1705
smallest_token_size: 712

The smallest_token_size tells the story.
As far as computationally heavy goes, yes I assumed it would be much slower. I fought hard to get it anywhere near the benchmarks for this library, and it was still 10x slower than the benchmarks posted in some cases. (Although there seems to be an issue currently with text-splitter and tiktoken where my implementation is faster.) Once resolved, I don't think it would be possible to make it in the same ballpark as fast as this library would be. However, the orphan chunk issue is a deal breaker for me for text. That said, this library is much more polished, and the code and markdown splitter are things I will be using.
Happy to discuss.


Aria-hidden on code sample

The code sample has aria-hidden="true" when the modal is supposed to be visible which would cause the content to be skipped by screen readers. I'd highly recommend an indication that attribute needs toggled depending on state.

Hi @emily-kay which code sample are we talking about specifically? What you suggest is correct, but we have static examples that applications will need to dynamically change the attribute when it opens. We do control this correctly in our Angular component for you.
It sounds like you're really asking for an additional comment to mention that applications will need to control this value themselves if they don't use the Angular component for modals?

Yes, I was speaking to the modal code sample. Sorry for confusion. An additional comment in the documentation for modals is needed. Aria-hidden is used twice in that example, once for the modal and once for the icons. Since the latter example is meant to be permanently set to true, a comment saying the modal specific instance should toggle based on how it's visually represented would be a good idea.


Added dynamic repositioning for Context menu on resize

Please review
Details

Fixed Issues

Fixes #2784
Tests \ QA Steps

Open any chat.
Right-click the Chat message.
Context menu should open.

Test 1
Resize the browser to see if the context menu is moved along.
Test 2
Right-click any message near the edge of the window. The menu should be completely visible.
Tested On

[x] Web
[ ] Mobile Web
[x] Desktop
[ ] iOS
[ ] Android

Screenshots

Web / Desktop

https://user-images.githubusercontent.com/24370807/118009932-2693ea80-b36c-11eb-8fb6-c3c1b2c15f9f.mp4

Updated.

Changes look good, going to give it a test run

🚀 Deployed to staging in version: 1.0.46-1🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Captcha Login Page

To avoid automatic robots, a question should be answered by V in the application process to decide whether V is a human being:
asking a random arithmetic question that robots cannot handle. Signup/login page.
Chatbot UI - Make it figma first.

done