Question: why does elixometer need a GenServer in front of exometer?

What is the rationale behind a process gateway in front of exometer?
I'm scratching my head and trying to figure out why is everything proxied through a single gen server instance.
I can see an ETS table that keeps track of subscriptions/metrics defined and a periodic tick that resets counters. It somewhat justifies the need of having a dedicated process, however am I wrong in thinking that exometer_core does that on its own anyway? 🤔

I'm assuming that you're talking about the pobox stuff; Elixometer also has a genserver that serves to serialize config changes. None of the metric updates  go through that process.
The reason Elixometer has pobox is to shed load if metrics are updated en masse. We experienced a pretty significant performance bottleneck with exometer when we threw many metrics updates at it at once. Adding pobox completely fixes this by dropping updates after the process mailbox reaches 1000, which is a large amount of backlog. If you're under the limit, you won't be affected, and if you're over this limit, I think discarding metrics is better than slowing your app down.

Hey @scohen, thanks for the reply! ❤

The reason Elixometer has pobox is to shed load if metrics are updated en masse. We experienced a pretty significant performance bottleneck with exometer when we threw many metrics updates at it at once.

Interesting! Have you found out which of exometer's processes was the culprit? Was it the reporter itself, that is only capable of receiving and handling one metric/datapoint message at a time? Or was it the underlying gen_tcp setup?

after the process mailbox reaches 1000

Do you recall what's the flush interval I could use to replicate that?

The main question origin is: I'm very new to exometer and I don't really grok it fully yet. I'm looking for a drop-in replacement for my folsom/folsomite setup, where it simply blows up with around 3k total unique metrics (due to ETS leak). I'm dumping the aggregated metrics to hostedgraphite every 40 seconds. I know I can fix this by just bumping ERL_ETS_MAX_TABLES, but that won't scale in the long run, and I feel there should be a way to do better, without dropping metrics overflow on the floor. So I guess what I'm looking for is a test case that'll allow me to benchmark this properly, before I make the production switch (staging is a lie).

@aerosol, The problem wasn't with the flush interval, but because exometer uses :gen_server.call somewhere in its stack. We were flooding the exometer process with tens of thousands of messages at once, and the calls were synchronous, and it would take 30ms or so for the process to clear its queue.
I don't think having tens of thousands of messages will be a problem, but I'm not extremely familiar with exometer's internals. You might want to ask Ulf about this. The problem we fixed was due to many, many messages being created in a very short time.

@scohen awesome.

We were flooding the exometer process with tens of thousands of messages at once, and the calls were synchronous

How many unique metrics (as in "metric name") did you have?

BTW, do you think it'd be worthwhile to extend elixometer with a metric for the number of messages dropped?

Thank you, this helps a lot! Last final question and we can close this: which reporter plugin did you use?

We use exometer_report_opentsdb exclusively.

@aerosol I'm going to close this, feel free to ask more questions if any come up.


fix bnf importer issue with empty instanceOf

This is interesting as the original definition means:
Get me things and their descendants which are member parents of the BNF concept set. So without the DescendantsOf it will only find the member parent concepts and not their children. That's why it was a blank instance because IMQ has nowhere else to put descendants of except within the instance predicate. In other words the match clause is looking for any instance and its descendants. So I thin the app needs to take account of a "wild card" in the match clause. the ECL convention is that the wild card is null.

In order to apply the same convention with ECL the instanceOf would need to have access to the parent iri. In this case where its a direct property it wouldn't be an issue to infer it, however, in a more general setting the iri would need to be passed down recursively in queries that can have multiple levels of match depth. Wouldn't it be easier if the the instanceOf had the iri of the entity it's refering to?
From:
"""
{
"instanceOf": [
{
"descendantsOrSelfOf": true
}
]
}
"""
To:
"""
{
"instanceOf": [
{
"@id": "iri",
"descendantsOrSelfOf": true
}
]
}
"""


local fuseki by default

by default, lds-pdi should use the local fuseki, not the buda1 one. Such configuration appear on

https://github.com/buda-base/lds-pdi/blob/master/src/main/webapp/WEB-INF/webdefault.xml#L29
https://github.com/buda-base/lds-pdi/blob/575ffa3335ba3553f96760c4f2ae4c6badfee9d0/src/main/resources/ldspdi.properties#L1

(possibliy among other places)
There should be a mechanism to allow developers to use the buda1 fuseki though, this mechanism should be documented in the readme

webdefault.xml is required by jetty and therefore used only in dev environment. It also includes a queryPath property (the path to local lds-queries files).
In prod environment (that uses tomcat), these two props values are currently set in /tomcat/conf/context.xml.
I managed (in commit 2a40803) to get rid of fusekiUrl settings in lds-pdi.properties file. Therefore dev (and deploy) settings only depends upon local context.xml and webDefault.xml files (i.e they don't rely on properties found on github repo)


minor RBAC documentation error

In RBAC.sol, the @dev comment for the contract still says:

It's also recommended that you define constants in the contract, like ROLE_ADMIN below,
to avoid typos.

In the current version, ROLE_ADMIN is never defined anywhere in the contract.
I suppose it was just overlooked when an inbuild admin role was removed (?). I briefly skipped over the history, but couldn't find the exact commit. Anyway,  it caused a minor moment of confusion for me, so I thought I should at least mention it.

[ ] 🐛 This is a bug report.
[ ] 📈 This is a feature request.
[x] :monkey: This is some super minor nitpicking thats neither a bug nor a feature request

Looks like it was overlooked when moving RBACWithAdmin.sol to examples/. This @dev comment belongs to that contract.


Added event delegates to the show dialog methods

What changed?
The new event delegates provides extra flexibility to the dialog coordinator class.
If you want, for example, always close all open dialogs before showing another dialog, you can create an method and add it to the delegate that is invoked before showing the dialog. The current solution for this is to replicate code or wrap the the methods in another method.

Turns out that synchronous events and asynchronous methods aren't best friends, so I'll work on another solution for this subject.

instead of using events you can use List which helps you control the execution in threads
and then wrap custom events around these lists for easy add/remove
then internally you just loop through the list and execute each action in an asynchronous pattern
check this
https://stackoverflow.com/questions/2434187/action-t-synchronous-and-asynchronous

IMHO this is a very special requirement.

If you want, for example, always close all open dialogs before showing another dialog, you can create an method and add it to the delegate that is invoked before showing the dialog.

You would have to track all open dialogs too. Probably you want to close not all but only certain dialogs. Introducing the events in the PR wouldn't help much. I think this belongs to the business logic of your app, and not into the presentation layer.


UNA.io

Hello,
In your site una.io when we choose lucid skin ! the signup button layout is broken.

That error occurs on the una.io site only but other sites have the error fixed, so it would not likely affect the una10 update.

when is the UNA 10 stable for ?

you mean you let the error occur on una.io ? without fixing it ?

@Amine Could you please provide screenshot of the broken layout if the issue is still in place ?


Based this work on the existing WebPLoader. Looking for some early feedback to see if the design is reasonable or if there's anything major to fix. Really welcome any and all feedback. :)

Forgot to say: general design looks fine.

Squashed, resolved some little things, and added a couple basic tests (I copied from webp for license reasons). Thanks very much for the feedback!

Was able to remove the image memcpy by converting to YUV directly in the bitmap buffer.


fix error in #2 by @IcedOtaku

I rewrote this js logic using python.
See hosts-py.

Update check is still needed. Or our commits history will be too huge.

Update check is still needed. Or our commits history will be too huge.

Thank you for your reply.
But maybe you should check this commit, and there are more commits like this.
The update logic always generate a commit even if the hosts were not changed at all, isn't it ?

You are right. There is a bug about it. We should only compare hosts content.
So we can remove those code comment first and then to compare.

You are right. There is a bug about it. We should only compare hosts content.
So we can remove those code comment first and then to compare.

I agree. Please let me try to fix this and make this PR work.

Hi, recently I optimized the updating logic by adjusting reg rule here.👷!
@ineo6

Great! Let me check.

Merge soon.


use Arbitrum token list json for tokens on Arbitrum

https://bridge.arbitrum.io/token-list-42161.json (which we host) has all of the tokens bridged onto Arbitrum; if you dynamically fetched the list from there (instead of hardcoding it) we would never have to bother you about updating it :)

...also as a lazy / immediate-term improvement, can just use that as a reference point to add any / all to the hardcoded list. Currently, top tokens by value on Arbitrum not on your hardcoded list are USDT, DODO, BAL, MCB, LAND, SUSHI, and UNI

Created #230 for an immediate term improvement.

We decided to follow our current strategy of only tracking "important enough" tokens with decent liquidity etc.


Ticket 30651 - Made eq return NotImplemented

Changed eq methods on Model, UniqueConstraint, and CheckConstraint
to return NotImplemented instead of False if compared to an object of
the same type, as is recommended by the Python data model reference.
Now these models can be compared to ANY (or other objects with eq
overwritten) without returning False automatically.
In the corresponding issue, I was asked if I would do this change for all classes... there's a lot of them, and I'm not sure any besides Model really gets compared in tests often, which is the main place this bug manifests. So, changing Model seems to me to be higher value than the rest of these classes. Therefore, before writing changes and tests for all of the 70 odd classes I'd change, I thought I should submit this, both so I stop procrastinating on fixing it, and to give people an opportunity to say they don't want this, or want different tests, or want to chime in that not every False to NotImplemented needs a test, I can hear any of that before doing a lot of repetitive work.

Looks like there's a lot of build failures with "Failed to Determine". "Failed to Determine" is also a good synopsis of how I feel about them. Perhaps someone can shed some light on them. I'm also at DjangoCon this week, so maybe I can get some guidance there.

Tests failures are probably not related with this PR (see troubleshooting), I run the build again.

I removed 5 classes from the list because this change affects __ne__() (see eb422e476f3c0070dbf200bd62d97d12150c6fd9 and __eq__() docs).

Wow! Thanks for doing that detective work. If the tests and where I'm putting them look okay, then I'll try to get to doing the rest of these soon.

Alright, I think I've got all the classes changed. I've been having problems with the tests that don't seem related to my changes, and seem to switch back and forth between working or not. Either I've lost my Jenkins knowhow, or I don't have the access to re-run them on my own.

@ElizabethU Thanks for updates :+1: I made few changes:

rebased from master,
squashed commits,
added two commits with new unrelated tests,
moved some tests between files,
reverted changes for BaseManager.

Welcome aboard :boat:

buildbot

Thanks! So did we not want the changes for BaseManager after all?

@ElizabethU Yes, I think we leave BaseManager unchanged, because this class is quite tricky. We've already made more changes then expected in the base ticket description.

Thanks for all your help!


Field query functions could overlap model fields

If a schema has fields named not, or or and then we're in trouble 😢
pub struct Post;
impl Post {
    pub fn id() -> PostIdField {
        PostIdField {}
    }
    pub fn content() -> PostContentField {
        PostContentField {}
    }
    pub fn user() -> PostUserField {
        PostUserField {}
    }
    pub fn user_id() -> PostUserIdField {
        PostUserIdField {}
    }
    pub fn not(params: Vec<PostWhereParam>) -> PostWhereParam {
        PostWhereParam::Not(params)
    }
    pub fn or(params: Vec<PostWhereParam>) -> PostWhereParam {
        PostWhereParam::Or(params)
    }
    pub fn and(params: Vec<PostWhereParam>) -> PostWhereParam {
        PostWhereParam::And(params)
    }
}

Fixed by making operator filters into distinct functions and adding macros for them, and making new and new_with_client into new_client and new_client_with_url functions separate from PrismaClient


Fixed some typos in README

Fixed 4 typos in README. No other lines were altered or deleted.

Thanks.


Imported resource from origin 'file://' has been blocked from loading by Cross-Origin Resource Sharing policy: Received an invalid response. Origin 'null' is therefore not allowed access.

I did the same site as the Making app for 10 minutes , and Chrome
display and white image , the Inspect element was a bug as its title .
Also, bower_components \ polymer \ docs \ index.html was a few files that did not exist . These are:

Bower_components / polymer / perf - lib / perf.js
Bower_components / polymer / x- elements / x -doc -viewer / x- doc- viewer.html
Bower_components / polymer / assets / icons.html

It is a version of the Polymer 0.5 .
Please look at this , I was two or three weeks looked for this.

Due to the way HTML imports work, Polymer requires a web server.  You could try developing using Chrome Dev Editor, which has a built-in web server.
https://chrome.google.com/webstore/detail/chrome-dev-editor-develop/pnoffddplpippgcfjdhbmhkofpnaalpg

By design HTMLImports can only load resources that support CORS.

Those docs are old and vestigial, thanks for pointing out.  We'll remove.  The [PRIMER.md] and (https://github.com/Polymer/polymer/blob/master/PRIMER.md) polymer-project.org website should be used for docs.

You could alwasy just set up your own node server and then you can present these locally instead of pushing them to your own testing server.

How about using polymer inside cordova ?

We could easily start a web server by using python:
python -m SimpleHTTPServer 8000

You can consider using polymer starter kit as well and install the local development server.
The instructions are on the following link.
https://developers.google.com/web/tools/polymer-starter-kit/

Wait what?? With the "new web" we will no longer be able to open HTML files from local files?? What the hell?? Can someone perhaps point me to some documentation of this?

@stevenroose Opening an HTML file directly will work just fine via a file protocol URL.  However, HTMLImports cannot load data via that protocol.

Opening an HTML file directly will work just fine

Only when that file doesn't import other files. What if I want to create an offline-capable browser dashboard that does use htmlimports?

Operating offline isn't the issue.  The protocol is the issue.  file:// requests will not work, but you can run a local web server (polymer serve, express, etc.) to use HTTP requests instead.  You could even use the following Chrome extension to run a local web server.
https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb?hl=en


fix "error in docs for RestInput"

Proposed changes:

...

Status (please check what you already did):

[x] made PR ready for code review
[x] added some tests for the functionality
[x] updated the documentation
[x] updated the changelog

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Since no new tests need to be added, checked " added some tests for the functionality"

link to the issue:

fix another bug "wrongly extracting username from JWT #1140" https://github.com/RasaHQ/rasa_core/issues/1140

@Zhipeng-Chang Thanks for submitting this PR! looks like your PR is based on a protected branch? So I can't update it or anything, can you please change that?
Also, an initial comment: could you remove the changes from the Changelog? Or rather summarise them in one line please. And also reapply the username change please, i'll figure out what's going wrong with the build

Hi @akelad Done!

@Zhipeng-Chang ok it seems the reason the build is failing is because the test test_get_tracker_with_jwt is now using the wrong fake JWT token. In the comment there you can see that it's still in the old format {"user": {"user": "testadmin", "role": "admin"}}, which should be changed to {"user": {"username": "testadmin", "role": "admin"}}. You can also replace the token in there with eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7InVzZXJuYW1lIjoidGVzdGFkbWluIiwicm9sZSI6ImFkbWluIn19.NAQr0kbtSrY7d28XTqRzawq2uQRre7IWTuIDrCn5AIw

Hi @akelad!
I changed the "testadmin" token to the one as you provided, but the build server is still failing. I looked into the build server log and found that the the "testuser" token should be updated as well, eg. { "user": { "username": "testuser", "role": "user" } }. I created the token by myself, but I got the return code of 422 from the build server, I copied the error message from Travis-ci "
{"user": {"username": "testuser", "role": "user"}}
    jwt_header = {
        "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9."
                         "eyJ1c2VyIjp7InVzZXJuYW1lIjoidGVzdHVzZXIiLCJ"
                         "yb2xlIjoidXNlciJ9fQ.EPJ8zMVdQPqnNvM0zkTO"
                         "NS-M8ptfOv0kbqMZqcauYSI"
    }
    response = secured_app.get("/conversations/testadmin/tracker",
                               headers=jwt_header)

  assert response.status_code == 403

E       assert 422 == 403
E        +  where 422 = <Response streamed [422 UNPROCESSABLE ENTITY]>.status_code"
I think maybe the token created by me is not encoded properly? so something else ... would you mind to create a token for testuser and send back to me?
Thank you.
Best,

Hey @Zhipeng-Chang sorry about all the back and forth, but looks like we actually have another PR open for the username thing: #1121
Would you mind removing those changes and then we can take a look at the other ones you made?

Thanks @akelad !


Witness should impl From<Vec<Vec<u8>>>

cc #1298 #1302 which are similar issues with discussion on the merits of From.

I'm more open to this than the others given Vec<Vec<u8>> is less usual and thus less likely to be confused. I'd even consider From<T> where T: AsRef<[U]>, U: AsRef<u8> but I think coherence won't let us. Anyway if we have From<Vec<Vec<u8>> we should also have at least From<&[&[u8]]>, From<&[Vec<u8>]> and From<Vec<&[u8]>`.

This was implemented.


Parse error on case-sensitive attributes in SVG

While trying this tool on a bunch of codebases, I ran into issues with SVG code embedded in HTML. For example,
<a href="#" role="tab">
    <svg viewBox="0 0 51.8 103.7" aria-hidden="true">
        <title>Arrow</title>
        <use xlink:href="#arrow"></use>
    </svg>
</a>

With this code, Jinjalint will report a parse error on the viewBox attribute, because of the capital "B":
Parse error: expected one of '=', '>', '[0-9-_.]', '[:a-z]', '\\s+', '{#', '{%', '{{' at 14:84

I assume this is because Jinjalint treats this as if it was HTML, and wants attributes to be lowercase. SVG being based on XML, it is case-sensitive, and it would be incorrect to replace this with viewbox.

I think potential solutions for this would either be to ignore attribute casing inside svg tags (in the tag’s own attribute, and its children), or have a whitelist of attributes that should be treated as case-sensitive.

It looks like a simple fix for this would be to allow uppercase letters in all attributes, by changing:
https://github.com/motet-a/jinjalint/blob/01e0a4d8f1ee775aee00eb9d715eff2b4cc49e4d/jinjalint/parse.py#L330-L335
to use the following attr_name instead of tag_name
attr_name_start_char = P.regex(r'[:a-z]')
attr_name_char = attr_name_start_char | P.regex(r'[0-9A-Z-_.]')
attr_name = attr_name_start_char + attr_name_char.many().concat()

Of course this isn’t 100% appropriate since only SVG attributes can be camelCase, and this regex isn’t strictly restricting "camelCase".

I could also think of two alternatives that might be more correct, but I’m not sure how much effort they would be to implement:

Use a whitelist of (SVG) attributes that are allowed to contain uppercase letters – this should be relatively easy to implement but the whitelist might be annoying to maintain (although SVG doesn’t change that much over time, https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute, and I guess it doesn’t hurt to add SVG 2.0 attributes already even if support is patchy)
Change the parsing rules depending on whether we are inside an svg tag or not. This would be more correct but also seems like much more work

Additionally I’m not sure how this attributes parsing works with namespaced attributes (e.g. xml:lang), but this could also be similarly handled.
I’m leaning towards the attributes whitelist since it will be easy to get set up. If this was set up for HTML attributes as well this could also potentially catch many more issues with mis-typed attributes.

I’ve ended up fixing this in my fork in the way I describe above, along with other SVG-related parsing issues. Since this really is just parsing I think the parser should just be more lenient – browsers have no problem with uppercase tags. Enforcing that tags are lowercase / only use valid elements should be done by a linting rule, after parsing.

I’ve ended up fixing this in my fork in the way I describe above, along with other SVG-related parsing issues.

Could you do a pr here? Or is fork not a git fork?

Since this really is just parsing I think the parser should just be more lenient – browsers have no problem with uppercase tags. Enforcing that tags are lowercase / only use valid elements should be done by a linting rule, after parsing.

👍

Yep, can make a PR, although I’m not too hopeful about it getting merged. Here is the changed that fixed this: https://github.com/thibaudcolas/curlylint/commit/fdd9554b968607f29a2444c15a2cd231efe16091
It’s not what this issue is about but I subsequently had to do a much bigger change for the parser to not fail on self-closing SVG elements, https://github.com/thibaudcolas/curlylint/commit/7bd5160ce2a3aeb2f2fff727da2a9c7b69bafdd8.


Use postcss-loader to plug in autoprefixer

Accomplishes the same thing as the specialized autoprefixer-loader, but now the kit is set up for the addition/configuration of other postcss plugins, as desired.

Very awesome, thank you!


Update libxml2 to 2.10.4 for 1.13.x

Edit: sorry all, meant to open that on our fork. Please ignore but thanks for all the amazing work you do!

@wwahammy I'm curious. If you don't mind sharing, what are the reasons for not upgrading to Nokogiri v1.14.x? Did something break for you on this version branch?

Sure, I'd be happy to share!
I have an app that runs Ruby 2.6 so I can't update to v1.14.x.


fix: flush after writing pages so that we don't yield to the user with in-progress writes

Codecov Report
Attention: Patch coverage is 0% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 80.68%. Comparing base (b762145) to head (f083c12).

Files
Patch %
Lines

rust/lance-file/src/v2/writer.rs
0.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2298      +/-   ##
==========================================
- Coverage   80.71%   80.68%   -0.04%
==========================================
  Files         191      191
  Lines       56379    56380       +1
  Branches    56379    56380       +1
==========================================
- Hits        45507    45488      -19
- Misses       8325     8337      +12
- Partials     2547     2555       +8

Flag
Coverage Δ

unittests
80.68% <0.00%> (-0.04%)
:arrow_down:

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

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


[Event Request] COD 9520 - OnBeforeRunMailDialog

Since we've extended the 'mail dialog' with a editable HTML editor control, we need to extend the RunMailDialog function. Can you please provide an 'OnBeforeRunMailDialog' event with Handled pattern and access to TempEmailItem (by Var), OutlookSupported, SMTPSupported, ReturnValue (exit)

[ ] Solved in BC14

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Problem installing openvpn-update-resolv-conf

I'm using the latest pacaur 4.5.2-1 and getting the following error output. Seems I can build the package manually. Also not using a pacman intermediary.
$ pacaur -y openvpn-update-resolv-conf
:: resolving dependencies...
:: looking for inter-conflicts...

AUR Packages  (1): openvpn-update-resolv-conf-r11.dd96841-2

:: Proceed with installation? [Y/n]

:: Retrieving package(s)...
Already up-to-date.
:: View openvpn-update-resolv-conf PKGBUILD? [Y/n] n
:: Checking openvpn-update-resolv-conf integrity...
==> Making package: openvpn-update-resolv-conf r11.dd96841-2 (Wed Feb 17 14:27:52 CET 2016)
==> Retrieving sources...
  -> Updating openvpn-update-resolv-conf git repo...
Fetching origin
==> Validating source files with sha256sums...
    openvpn-update-resolv-conf ... Skipped
:: Building openvpn-update-resolv-conf package(s)...
==> Making package: openvpn-update-resolv-conf r17.51fd5ef-1 (Wed Feb 17 14:27:53 CET 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating openvpn-update-resolv-conf git repo...
Fetching origin
==> Validating source files with sha256sums...
    openvpn-update-resolv-conf ... Skipped
==> Extracting sources...
  -> Creating working copy of openvpn-update-resolv-conf git repo...
Switched to a new branch 'makepkg'
==> Starting pkgver()...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issue...
==> Creating package "openvpn-update-resolv-conf"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: openvpn-update-resolv-conf r17.51fd5ef-1 (Wed Feb 17 14:27:54 CET 2016)
==> Cleaning up...
:: Installing openvpn-update-resolv-conf package(s)...
:: openvpn-update-resolv-conf package(s) failed to install. Check .SRCINFO for mismatching data with PKGBUILD.

I can reproduce, will have a look asap. Thanks for the report.

The issue is quite simple: this is actually a -git package, but the maintainer doesn't use that extension. As per the VCS package guidelines, this package should be renamed.
As pacaur doesn't parse PKGBUILD (for security reason), it has no way to know that it must give this PKGBUILD the special "VCS treatment" to correctly handle this package.
Note that other helpers that source PKGBUILDs are likely to work here, but this is something pacaur doesn't do and will never do.

As a workaround in the meantime, if I want to install it using pacaur is there something I can do to modify the pkgbuild or something so that I can install it using pacaur? Still learning about all this..

You can always install the package manually with makepkg. By design, pacaur does not offer workaround to users for issues that should be solved by the maintainer.

For this particular issue, if I install the package manually with makepkg, I would also need to do updates manually with makepkg later right (at least until the issue is solved by the maintainer)? Or would pacaur then be able to do upgrades once the initial install is done?

Manually only. If the maintainer isn't reactive, follow https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_is_outdated.3B_what_do_I_do.3F


[AWAM] Anime Was a Mistake sheet first commit

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: Anime Was a Mistake

The publisher of this game is: Éditions 6Napse

The name of this game system/family is: Anime Was a Mistake

[x] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

First commit for this new sheet.

Character Sheet Info Roll20 Internal Use only.

@mperes Thank you for the merge. However I just checked the sheet within a game and the look is totally different from what I have in sandbox or custom sheet. It seems that some CSS styles are not taken into account. Any clue?

Ok I found it, it is due to legacy sanitization. I created a pull request for a hotfix: https://github.com/Roll20/roll20-character-sheets/pull/11713


Unexpected token 'I', "Internal S"... is not valid JSON

Hello,
i am using a planka (dockerized) and trello2planka on the same host. The board was created as well as the first card, hoewever it seems that it fails, while adding the cover picture to this first card (first attachment) upload. Error below, please let me know if I should provide anymore info? Thank you! kr
node: v20.11.0
os: debian buster
planka: 1.15.4 (edit)
npm run import-board --  --file=trello-export.json
...
authenticated POST to http://localhost:3000/api/boards/1169626018739127538/labels
status =  200
authenticated POST to http://localhost:3000/api/boards/1169626018739127538/labels
status =  200
authenticated POST to http://localhost:3000/api/boards/1169626018739127538/lists
status =  200
authenticated POST to http://localhost:3000/api/lists/1169626020987274492/cards
status =  200
fetching attachment from Trello API, path =  https://api.trello.com/1/cards/5edcb47b8f1dc70c77ac128a/attachments/5edcb4b6555550654c584d4c/download/image.png
status =  200
authenticated POST with file upload to http://localhost:3000/api/cards/1169626021247321341/attachments
SyntaxError: Unexpected token 'I', "Internal S"... is not valid JSON
    at JSON.parse (<anonymous>)
    at Response.json (file:///home/trelloimport/trello2planka/node_modules/node-fetch/src/body.js:149:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async authenticatedPostFileUpload (file:///home/trelloimport/trello2planka/src/planka/client.js:87:36)
    at async createAttachment (file:///home/trelloimport/trello2planka/src/planka/client.js:60:61)
    at async importAttachments (file:///home/trelloimport/trello2planka/src/planka/import.js:141:34)
    at async importCards (file:///home/trelloimport/trello2planka/src/planka/import.js:95:9)
    at async importLists (file:///home/trelloimport/trello2planka/src/planka/import.js:77:9)
    at async importTrelloBoard (file:///home/trelloimport/trello2planka/src/planka/import.js:18:5)
    at async main (file:///home/trelloimport/trello2planka/src/index.js:8:9)

Hi,
did you have a look at the server logs? It seems to me that the server returns 500 Internal Server Error at this one request, would be interesting to see why.
I just double-checked, and the import still works with planka version 1.15.4 with the provided sample board.

Yes thanks, planka logs gave a 500 permission denied as you said.
I used the planka admin user and checked the credentials in config.json.
I created a different admin user in planka > retried > same error.
Then added the user to the project > retried > same error.
any ideas?
postgres_1  | 2024-01-31 15:11:09.700 UTC [21] LOG:  database system was shut down at 2024-01-31 15:10:10 UTC
postgres_1  | 2024-01-31 15:11:09.705 UTC [1] LOG:  database system is ready to accept connections
planka_1    | debug: Detected Sails environment is "production", but NODE_ENV is `undefined`.
planka_1    | debug: Automatically setting the NODE_ENV environment variable to "production".
planka_1    | debug:
planka_1    | 2024-01-31 15:11:21 [E] Sending 500 ("Server Error") response:
planka_1    |  EACCES: permission denied, mkdir '/app/private/attachments/c1f06fe4-59eb-4bb4-b125-e58fadb9a48b'

Interesting, do any other attachments work via the Planka UI? For example uploading some file to a card manually. My guess is that this doesn't work either.
I assume that this attachments directory is mounted from the host machine - if so, I remember there is sometimes trouble in writing to those - hopefully this issue helps: https://github.com/plankanban/planka/issues/488

Thank you for the hint! I tried the chown fix (it did not work) even though i did not modify the volume parameters in my compose file below. Would you suggest i open a new issue at planka?
version: '3'

services:
  planka:
    image: ghcr.io/plankanban/planka:latest
    command: >
      bash -c
        "for i in `seq 1 30`; do
          ./start.sh &&
          s=$$? && break || s=$$?;
          echo \"Tried $$i times. Waiting 5 seconds...\";
          sleep 5;
        done; (exit $$s)"
    restart: unless-stopped
    volumes:
      - user-avatars:/app/public/user-avatars
      - project-background-images:/app/public/project-background-images
      - attachments:/app/private/attachments
    ports:
      - 3000:1337
    environment:
      - BASE_URL=http://planka.localdomain:3000
      - TRUST_PROXY=0
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=xyz
    depends_on:
      - postgres

  postgres:
    image: postgres:14-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust

volumes:
  user-avatars:
  project-background-images:
  attachments:
  db-data:

Nice!

Close this one and reopen a new one @ planka issues?

Yes, if the import has worked for you now, you can close this one (or let me know otherwise) and ask about the volume mounting in the planka repo, I think they can provide better answers there. Thanks!


Add gallery for CLIPScore

What does this PR do?
Introduce gallery for CLIPScore :)

Before submitting

[ ] Was this discussed/agreed via a Github issue? (no need for typos and docs improvements)
[ ] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure to update the docs?
[ ] Did you write any new necessary tests?

PR review
Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.

Did you have fun?
Make sure you had fun coding 🙃

📚 Documentation preview 📚: https://torchmetrics--2578.org.readthedocs.build/en/2578/

The example iterates through different CLIP models (for now just 1x base and 1x large) and shows the above screenshot for various images. This is how it looks:

It would be nice if it autoplays, which I think is not supported yet. I may look into this in the future.
More captions or images can be added, so if you have suggestions feel free :)

seems it is too demanding for readthedocs - This build was terminated due to excessive memory consumption


es_verify_cert is expected to be a lowercase string

I was going to open an issue with benchmark-operator, but I feel the fix belongs in the wrapper. After updating my local benchmark-operator repo, I have been unable to connect to my self-signed Elasticsearch instance.
Recently the Benchmark CRD elasticsearch.verify_cert field was set to a boolean. It was previously a string to support how the benchmark-wrapper handles it. Because of this, when verify_cert is set and added to templates, the string becomes capitalized during the python boolean to string conversion.
To fix this in the benchmark-operator, to make sure it always output a lowercase string can be fragile when there are so many templates to maintain and the ability to Bring-Your-Own-Workload.
Instead, I propose we make benchmark-wrapper more forgiving of env input, at a minimum converting the relevant input to lowercase.

Can one of the admins verify this patch?


Propagate version updates after artifacts are released

Wait until container images and binaries were built and uploaded successfully before publishing the version.json update.

Mhm... that doesn't work due to the heavy use of conditions. Need to think about it again.


Dark mode not working because of @layer base, demo repo provided

Hi and congrats for making these beautiful components!
I notice that dark mode isn't working on a fresh install:

ran npx create-next-app@latest, didn't choose to use the app directory
ran npx shadcn-ui init
ran npm i next-themes
added <ThemeProvider attribute="class"> in _app.tsx

The result: we notice that the dark class is present (thanks to prefers-color-scheme: dark), but it's the variables from :root that are applied, not the ones from .dark:

Demo repository:
https://github.com/Zwyx/shadcn-ui-dark-mode-demo deployed at https://zwyx.github.io/shadcn-ui-dark-mode-demo/
Notes:

Removing @layer base from globals.css fixes this.
This issue is very similar to https://github.com/shadcn/ui/issues/278 although I'm not using the app directory, and I'm not able to fix it...

Update your globals.css
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
  :root {
    --background: 0 0% 100%;
    --foreground: 222.2 47.4% 11.2%;

    --muted: 210 40% 96.1%;
    --muted-foreground: 215.4 16.3% 46.9%;

    --popover: 0 0% 100%;
    --popover-foreground: 222.2 47.4% 11.2%;

    --border: 214.3 31.8% 91.4%;
    --input: 214.3 31.8% 91.4%;

    --card: 0 0% 100%;
    --card-foreground: 222.2 47.4% 11.2%;

    --primary: 222.2 47.4% 11.2%;
    --primary-foreground: 210 40% 98%;

    --secondary: 210 40% 96.1%;
    --secondary-foreground: 222.2 47.4% 11.2%;

    --accent: 210 40% 96.1%;
    --accent-foreground: 222.2 47.4% 11.2%;

    --destructive: 0 100% 50%;
    --destructive-foreground: 210 40% 98%;

    --ring: 215 20.2% 65.1%;

    --radius: 0.5rem;
  }

  .dark {
    --background: 224 71% 4%;
    --foreground: 213 31% 91%;

    --muted: 223 47% 11%;
    --muted-foreground: 215.4 16.3% 56.9%;

    --accent: 216 34% 17%;
    --accent-foreground: 210 40% 98%;

    --popover: 224 71% 4%;
    --popover-foreground: 215 20.2% 65.1%;

    --border: 216 34% 17%;
    --input: 216 34% 17%;

    --card: 224 71% 4%;
    --card-foreground: 213 31% 91%;

    --primary: 210 40% 98%;
    --primary-foreground: 222.2 47.4% 1.2%;

    --secondary: 222.2 47.4% 11.2%;
    --secondary-foreground: 210 40% 98%;

    --destructive: 0 63% 31%;
    --destructive-foreground: 210 40% 98%;

    --ring: 216 34% 17%;

    --radius: 0.5rem;
  }
}

@layer base {
  * {
    @apply border-border;
  }
  body {
    @apply bg-background text-foreground;
    font-feature-settings: "rlig" 1, "calt" 1;
  }
}

@layer utilities {
  .step {
    counter-increment: step;
  }

  .step:before {
    @apply absolute w-8 h-8 bg-muted rounded-full font-medium text-center text-base inline-flex items-center justify-center -indent-px;
    @apply ml-[-41px];
    content: counter(step);
  }
}

@media (max-width: 640px) {
  .container {
    @apply px-4;
  }
}

Would you be able to check out this repo: https://zwyx.github.io/shadcn-ui-dark-mode-demo/
Then replace the content of globals.css by yours, start the app, open it in an incognito window (to make sure there is not "theme" value in local storage), open the dev tools and turn on prefers-color-scheme: dark like it is shown on the screenshot above.
I did exactly that, and the dark theme still not apply. Even with the content of your file.

@Zwyx can you please check your tailwind.config.js file? I had to update mine because I'm using a src directory - so had to account for that.
example:
content: ["src/app/**/*.{ts,tsx}", "components/**/*.{ts,tsx}"],
By default, there's no src prefix there (I realize you aren't using app dir, but maybe the path in the content directory needs to be corrected?

The tailwind.config.js file, present here https://github.com/Zwyx/shadcn-ui-dark-mode-demo/blob/main/tailwind.config.js seems correctly configured.

@Zwyx I haven't yet gotten to the root of the issue, but it does seem to be some sort of config issue. Updating this as the content array restores the styles as expected:
content: ["**/*.{ts,tsx}"]
Not certain yet why the original config isn't working.

I got the same problem

@Zwyx Is this still not working? How can I help?

Got the same problem, following the previous suggestions and replacing the content in the the tailwind config to the following
content to ["**/*.{ts,tsx}"] solve the issue.

Hi @shadcn, thanks for your message. Yes, this is still an issue (I've just retried from scratch by redoing the steps described in the first post; same result).
I'm not familiar with the @layer CSS tag, and I've noticed that if I remove it from globals.css, all works correctly.
I don't know if you can help and I definitely don't want to waste your time, but I'd be interesting to know why you use @layer? And if you can think of any issue that could appear by removing @layer like I did.
The user hgaron-blockbar, above, noticed that we can also make it work by tweaking Tailwind's config.
These two ways of solving the issue are workarounds, but don't really identify the root of the problem.

I had the same problem until I found out I had to add themeColor to my root layout metadata, following the template repo here. No other special changes to tailwind.config.js nor globals.css.
@Zwyx I notice you're not using the app dir in your demo repo, but since themeColor gets converted into <meta name="theme-color" /> tags (according to Nextjs docs), maybe you could try copy-pasting the appropriate tags into your project and see if dark mode works afterwards?

Hi Nico and thanks for your message. Good find! That indeed fixed it. I simply added the following in _documents.tsx:

		<meta
			name="theme-color"
			media="(prefers-color-scheme: light)"
			content="white"
		/>
		<meta
			name="theme-color"
			media="(prefers-color-scheme: dark)"
			content="black"
		/>

}

I don't see the relation between @layer base and theme-color though. It could be interesting to dig, but I'm not keen to dive in a deep rabbit hole.
I also noticed something else: this problem was happening in Chrome, but not in Firefox.
I guess with this third workaround, we could close the issue if you'd like, Shadcn?

@ndinata worked for me too!
@shadcn We should either add this to the docs or somehow fix it!

Yes, please add this to the docs. I was just pulling out my hair why dark mode was not working because the setup is pretty simple using next-themes. Can't be the only one 😁

Made a PR for this: https://github.com/shadcn/ui/pull/938

Adding this in app/layout.tsx worked for me
import { Metadata } from 'next';

export const metadata: Metadata = {
  themeColor: [
    { media: '(prefers-color-scheme: light)', color: 'white' },
    { media: '(prefers-color-scheme: dark)', color: 'black' },
  ],
};

Had the same issue, fixed it with :root[class~="dark"] instead of .dark in style.css
style.css for reference: https://github.com/langfuse/langfuse-docs/blob/e9ba748e0e53e5d9179ffc0040839108d1930621/style.css#L39

Had the same issue, fixed it with :root[class~="dark"] instead of .dark in style.css
style.css for reference: https://github.com/langfuse/langfuse-docs/blob/e9ba748e0e53e5d9179ffc0040839108d1930621/style.css#L39

Thank you! Worked just fine. I was searching for a solution for hours.

Had the same issue, fixed it with :root[class~="dark"] instead of .dark in style.css
style.css for reference: https://github.com/langfuse/langfuse-docs/blob/e9ba748e0e53e5d9179ffc0040839108d1930621/style.css#L39

Thank you, this worked for me as well. I just set the styles up with both targets, class and root:
  .dark,
  :root[class~="dark"] {
    ...
  }

Can confirm @benyamynbrkyc solution worked for me as well, imho a good solution since you dont need to modify your tailwind config or meta data tags.

For me, on a Vite/React app, the problem was forgetting to import the global.css file into my App.tsx.

I seem to have fixed this by adding “dark” to the tailwind safe list

I've also encountered the same issue. Here's my setup:
"class-variance-authority": "^0.7.0",
"clsx": "^2.0.0",
"lucide-vue-next": "^0.292.0",
"tailwind-merge": "^2.0.0",
"tailwindcss-animate": "^1.0.7",

and my components.json :

{
  "style": "default",
  "typescript": true,
  "tailwind": {
    "config": "tailwind.config.js",
    "css": "assets/css/tailwind.css",
    "baseColor": "zinc",
    "cssVariables": true
  },
  "framework": "nuxt",
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils"
  }
}

When I add class="dark"  to the HTML tag, my div is set as follows:

   ...

However, this doesn't have any effect, and the page still appears in light mode.

这个问题确实困扰了我好几个小时，直到我仔细的一遍一遍看shadcn的文档才解决，我是用shadcn+tailwindcss，因为shadcn的代码可以直接生成，所以用shadcn的provider方式处理。但是怎么也不好用。这个问题应该与我的是一个问题。
1、按照https://ui.shadcn.com/docs/dark-mode/vite先增加provider
2、页面点击切换主题，会发现，其中class="dark"是可以变化为light的，说明provider是可用的
3、我们通过https://ui.shadcn.com/themes，定制自己的主题，拿到代码并放到global.css中，这个样式文件与components.json里的tailwind样式文件一致：
"tailwind": {
"config": "tailwind.config.js",
"css": "src/globals.css",
"baseColor": "gray",
"cssVariables": true
},
4、仔细阅读https://ui.shadcn.com/docs/theming，有两种控制主题样式的方式：
一种是dark:bg-white这样的，在tailwind里边直接用的这种。另一种是变量形式：

其中的background，foreground并不是tailwind自带的样式变量，需要我们要定义才能识别。
注意"cssVariables": true，要设置为true才可以用这种方式。因为我们要用的主题样式控制都是这种的：
@layer base {
  :root {
    --background: 0 0% 100%;
    --foreground: 20 14.3% 4.1%;
    --card: 0 0% 100%;
    --card-foreground: 20 14.3% 4.1%;
    --popover: 0 0% 100%;
5、在tailwind.config.js文件中增加自定义颜色：
colors: {
        'background':"hsl(var(--background))",
        "foreground": "hsl(var(--foreground))",
![image](https://github.com/shadcn-ui/ui/assets/48936035/908294d4-0953-48ee-ba5b-6c4c5e2910c3)
文档这里其实已经举例了一种增加主题控制的warning颜色的处理方法，就是没直接写整个页面的背景及前景色怎么做。。。
也许不想让我们直接copy用吧，还是想让我们动动脑筋。
6、最后光上边这些还是没有效果的，因为还要给body加上class这样才能找到对应的点去处理主题颜色
我们在最顶端的body增加class:

这样就全部完成了。

Is this still an issue?

Had the same issue, fixed it with :root[class~="dark"] instead of .dark in style.css
style.css for reference: https://github.com/langfuse/langfuse-docs/blob/e9ba748e0e53e5d9179ffc0040839108d1930621/style.css#L39

@shadcn this works well for us

Looks like it is. I still have to use the root selector, e.g.:
.dark,
  :root[class~='dark'] {
      ...
}

There is a PR for that: https://github.com/shadcn-ui/ui/pull/1780

This code fixed it for me
`@tailwind base;
@tailwind components;
@tailwind utilities;
:root {
--background: 0 0% 100%;
--foreground: 222.2 47.4% 11.2%;
--muted: 210 40% 96.1%;
--muted-foreground: 215.4 16.3% 46.9%;

--popover: 0 0% 100%;
--popover-foreground: 222.2 47.4% 11.2%;

--card: 0 0% 100%;
--card-foreground: 222.2 47.4% 11.2%;

--border: 214.3 31.8% 91.4%;
--input: 214.3 31.8% 91.4%;

--primary: 222.2 47.4% 11.2%;
--primary-foreground: 210 40% 98%;

--secondary: 210 40% 96.1%;
--secondary-foreground: 222.2 47.4% 11.2%;

--accent: 210 40% 96.1%;
--accent-foreground: 222.2 47.4% 11.2%;

--destructive: 0 100% 50%;
--destructive-foreground: 210 40% 98%;

--ring: 215 20.2% 65.1%;

--radius: 0.5rem;

}
@media (prefers-color-scheme: dark) {
:root {
--background: 224 71% 4%;
--foreground: 213 31% 91%;
--muted: 223 47% 11%;
--muted-foreground: 215.4 16.3% 56.9%;

--popover: 224 71% 4%;
--popover-foreground: 215 20.2% 65.1%;

--card: 224 71% 4%;
--card-foreground: 213 31% 91%;

--border: 216 34% 17%;
--input: 216 34% 17%;

--primary: 210 40% 98%;
--primary-foreground: 222.2 47.4% 1.2%;

--secondary: 222.2 47.4% 11.2%;
--secondary-foreground: 210 40% 98%;

--accent: 216 34% 17%;
--accent-foreground: 210 40% 98%;

--destructive: 0 63% 31%;
--destructive-foreground: 210 40% 98%;

--ring: 216 34% 17%;

--radius: 0.5rem;

}
}

{
@apply border-border;
}
body {
@apply bg-background text-foreground;
font-feature-settings: "rlig" 1, "calt" 1;
}`

this fixed it for me
@tailwind base;
@tailwind components;
@tailwind utilities;

:root {
    --background: 0 0% 100%;
    --foreground: 222.2 47.4% 11.2%;

    --muted: 210 40% 96.1%;
    --muted-foreground: 215.4 16.3% 46.9%;

    --popover: 0 0% 100%;
    --popover-foreground: 222.2 47.4% 11.2%;

    --card: 0 0% 100%;
    --card-foreground: 222.2 47.4% 11.2%;

    --border: 214.3 31.8% 91.4%;
    --input: 214.3 31.8% 91.4%;

    --primary: 222.2 47.4% 11.2%;
    --primary-foreground: 210 40% 98%;

    --secondary: 210 40% 96.1%;
    --secondary-foreground: 222.2 47.4% 11.2%;

    --accent: 210 40% 96.1%;
    --accent-foreground: 222.2 47.4% 11.2%;

    --destructive: 0 100% 50%;
    --destructive-foreground: 210 40% 98%;

    --ring: 215 20.2% 65.1%;

    --radius: 0.5rem;
}

@media (prefers-color-scheme: dark) {
  :root {
    --background: 224 71% 4%;
    --foreground: 213 31% 91%;

    --muted: 223 47% 11%;
    --muted-foreground: 215.4 16.3% 56.9%;

    --popover: 224 71% 4%;
    --popover-foreground: 215 20.2% 65.1%;

    --card: 224 71% 4%;
    --card-foreground: 213 31% 91%;

    --border: 216 34% 17%;
    --input: 216 34% 17%;

    --primary: 210 40% 98%;
    --primary-foreground: 222.2 47.4% 1.2%;

    --secondary: 222.2 47.4% 11.2%;
    --secondary-foreground: 210 40% 98%;

    --accent: 216 34% 17%;
    --accent-foreground: 210 40% 98%;

    --destructive: 0 63% 31%;
    --destructive-foreground: 210 40% 98%;

    --ring: 216 34% 17%;

    --radius: 0.5rem;
  }
}

  * {
    @apply border-border;
  }
  body {
    @apply bg-background text-foreground;
    font-feature-settings: "rlig" 1, "calt" 1;
  }

@AchrafGarai you won't be able to allow your users to set the them they want; dark theme will only be applied if it's their OS's preference. Which isn't a problem, as long as it's what you want.

I was also trying to enable dark theme with shadcn-ui yesterday and ended up on this thread after searching for a fix. Here are some observations and possible solutions:
TL;DR:

Add safelist: ['dark'] to your tailwind.config.ts if you don't mind changing such file and you want an officially supported fix;
OR
Replace the .dark selector in your globals.css file file with :root[class~="dark”] (thanks @marcklingen).

Explanation

This page states that Tailwind scans all files matched by your content glob patterns (e.g. ["**/*.{ts,tsx}”] will scan for all files ending with .ts or .tsx relative to your project root).
Their documentation suggests that libraries should write styles without using Tailwind’s @layer feature, in order to ensure that “Tailwind always includes those styles in your CSS”. Additionally,

The way Tailwind scans your source code for classes is intentionally very simple — we don’t actually parse or execute any of your code in the language it’s written in, we just use regular expressions to extract every string that could possibly be a class name.

Therefore, it seems that the main cause for the dark theme not being applied is that Tailwind has not found any project files containing a dark class call, thus removing it from the final bundle.
Workarounds and Fixes
Using Storybook and Next.js, the following fixes have worked for me:

NOTE: Depending on your setup, Tailwind may cache styles even after removed, so I recommend to restart your server after applying/removing any of the following fixes/hacks.

Defining the .dark class outside of the @layer in your globals.css file will always include dark theme styles in the final bundle, but it might break styling since the original code written by @shadcn could rely on the order of @layers, affecting the priority of class resolution.

Add any object containing a string with dark in a file scanned by Tailwind. Not recommended, since this is a hack and it’s hard to locate and debug:
const triggerTailwind = ['dark'];

The above may be the reason why many different solutions in this thread work:

Using content: ["**/*.{ts,tsx}”] (thanks @hgaron-blockbar)  works because there must be a string containing dark somewhere in your code. However, Tailwind in general recommends against using broad patterns.

This solution which adds a themeColor object (thanks @ndinata and @Zwyx) is probably triggering the dark class compilation because it contains dark inside themeColor.media:
themeColor: [
    { media: "(prefers-color-scheme: dark)", color: "black" },
]

Adding the global css file ./src/app/globals.css to your content property in tailwind.config.ts works as Tailwind will probably scan it and find the .dark class, however Tailwind also explicitly recommends against adding .css files to your content folder:

It’s also important that you don’t scan any CSS files — configure Tailwind to scan your templates where your class names are being used, never the CSS file that Tailwind is generating.

I really liked @marcklingen’s solution: by replacing .dark with :root[class~="dark"] in the globals.css file, it seems that Tailwind identifies the "dark" token as a string, or maybe it has a special rule for such selectors inside @layers. This  will continue to work unless Tailwind changes its scanning system in a way that affects the special :root[class~="dark"] selector.

If you don’t mind changing your tailwind.config.ts file, these strategies are also valid:

Adding { raw: '
’, extension: 'html' } as Raw Content inside your content property works, but it is hacky and there is a better way below:

Recommended: add the safelist property and provide the dark class to it: safelist: ["dark"].

@shadcn Thank you for creating such an awesome collection of components!

Thank you so much @rafaelcalpena for this amazing explanation!
You mentioned « the original code written by @shadcn could rely on the order of @layers ». Do you know more about this? This is something I've been very keen to understand since this issue started: are these @layers useful?!
Because simply removing them solves this issue completely. So it's what's I've done in my 5-10 projects that use Shadcn UI, and it never caused me any issues.

Thank you so much @rafaelcalpena for this amazing explanation!
You mentioned « the original code written by @shadcn could rely on the order of @layers ». Do you know more about this? This is something I've been very keen to understand since this issue started: are these @layers useful?!
Because simply removing them solves this issue completely. So it's what I've done in my 5-10 projects that use Shadcn UI, and it never caused me any issues.

Thank you @Zwyx. Yes, the layers are useful to dictate the priority order for the styles to be applied. You can think of them as a way to augment the default behavior in CSS, where the "last rule declaration wins" (explained here). The difference is that with @layers you can write rules in arbitrary order and Tailwind will "move" them to the appropriate precedence layer during compilation.
By default Tailwind has 3 layers: base, components and utilities:
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
    .my-class {background: red;}
}

In case of conflicts, the last layer should win, so we have utilities > components > base (with .my-class inside).
By taking .my-class away from the @layer base, I assume the order would become  .my-class > utilities > components > base, thus changing the precedence.
Some links that explain layers more in-depth: Organize your CSS in the Tailwind style with @layer directive and Tailwind's Official Documentation
On the other hand, it is great to hear that moving .dark outside of base has worked well and without conflicts, so it is also a useful fix.

Excellent. It makes much more sense now. I didn't realise Tailwind uses @layer. Thanks a lot Rafael!
I think we now have everything to take a decision on this issue:
TL;DR:

reason the problem is not experienced by everyone:

it only happens when dark: isn't used anywhere, which makes Tailwind dropping it from the CSS.

fix:
EITHER

replace .dark by :root[class~="dark"] in globals.css – there is an old PR for that, I'd be happy to update if it's the solution that is chosen.
OR
add safelist: ['dark'] to tailwind.config.ts, which sounds a bit easier.

@shadcn, which one of these two solutions would you like to see implemented?
Thanks again heaps to @rafaelcalpena for his massive help!

For me, replacing .dark with :root[data-theme='dark'] worked!

I'm having an issue where dark mode works in chrome but not safari
I've tried everything mentioned here, but nothing seems to work

Hi there, I am experiencing something that I think is related, by following the example for dark mode my toggle has the two icons one over the other, this is because dark doesn't get applied I fear

I've tried the options provided by @Zwyx but neither has worked.
I've just installed it, linking my project here
https://github.com/FrancescoSaverioZuppichini/nextjs-cloudfare/tree/dev
Thanks a lot

Not sure if it's related as well. Plain vite + react-ts template + vite shadcn.
  "dependencies": {
    "@radix-ui/react-dropdown-menu": "^2.0.6",
    "@radix-ui/react-slot": "^1.0.2",
    "class-variance-authority": "^0.7.0",
    "clsx": "^2.1.1",
    "lucide-react": "^0.378.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "tailwind-merge": "^2.3.0",
    "tailwindcss-animate": "^1.0.7"
  },

https://github.com/shadcn-ui/ui/assets/37434846/8bc75298-9f64-420e-863c-4bdf388eff51

Not sure if it's related as well. Plain vite + react-ts template + vite shadcn.
  "dependencies": {
    "@radix-ui/react-dropdown-menu": "^2.0.6",
    "@radix-ui/react-slot": "^1.0.2",
    "class-variance-authority": "^0.7.0",
    "clsx": "^2.1.1",
    "lucide-react": "^0.378.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "tailwind-merge": "^2.3.0",
    "tailwindcss-animate": "^1.0.7"
  },

Screen.Recording.2024-05-17.at.09.35.57.mov

Hello do you fix it ? i have a same problem

Check: Any another tag does not have dark or light class .
if there is any tag have dark or light class then there children will act relatively.

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

Anyone experiencing this issue, please refer to this comment, which contains the reason, a way to fix it, and a link to a PR.

Not sure if anyone else is seeing this, but for a new Next 14 app with app router + shadcn, I was testing a few of the dashboard blocks and with the default "light" theme everything looked off. Like it was a mix of dark and light mode. Looking at the dark theme (manually added the dark class to ) it looked as it should.
I changed the @media (prefers-color-scheme: dark) { line to :root[class~="dark"] { and now both light and dark themes look right.
I'm on macos and I've set it's Appearance to "Dark". That probably has something to do with it.
With this change the user will have to change themes manually, which I think is ok.

Not sure if anyone else is seeing this, but for a new Next 14 app with app router + shadcn, I was testing a few of the dashboard blocks and with the default "light" theme everything looked off. Like it was a mix of dark and light mode. Looking at the dark theme (manually added the dark class to ) it looked as it should.
I changed the @media (prefers-color-scheme: dark) { line to :root[class~="dark"] { and now both light and dark themes look right.
I'm on macos and I've set it's Appearance to "Dark". That probably has something to do with it.
With this change the user will have to change themes manually, which I think is ok.

This does the fix. Not sure why this isn't in the documentation.

This puzzled me for hours! Thank you so much https://github.com/shadcn-ui/ui/issues/313#issuecomment-1929054475
Please. Why don't we merge that PR?

Not sure if anyone else is seeing this, but for a new Next 14 app with app router + shadcn, I was testing a few of the dashboard blocks and with the default "light" theme everything looked off. Like it was a mix of dark and light mode. Looking at the dark theme (manually added the dark class to ) it looked as it should.
I changed the @media (prefers-color-scheme: dark) { line to :root[class~="dark"] { and now both light and dark themes look right.
I'm on macos and I've set its Appearance to "Dark". That probably has something to do with it.
With this change the user will have to change themes manually, which I think is ok.

I had the exact same issue. I did modify globals.css as per this comment to use :root[class~="dark"] instead of .dark. The problem was that the "light" theme wasn't looking as it should. Regardless of my mac's settings (dark/light didn't affect the issue) I tried the following:
Using "Arc browser" from menubar > View > Appearance I tried to switch the browser's appearance and see how it affects the theme. BTW I used the useTheme hook to set my theme and the results were the following regardless mac's theme:

when the browser's appearance was set to light theme, switching was working correctly
when the browser's appearance was set to dark theme, light theme had issues

Trying your recommendation to replace @media (prefers-color-scheme: dark) with :root[class~="dark"] seems to fixes the issue.

@chrispetrou could you instead try removing this code from the top of your globals.css if you have it?
:root {
  --background: #ffffff;
  --foreground: #171717;
}

@media (prefers-color-scheme: dark) {
  --background: #0a0a0a;
  --foreground: #ededed;
}

I think these are not needed and in fact I was seeing some inconsistencies, still. Some parts of shadcn components use the css hsl function with the variables defined in global.css, but those I copied here are not valid hsl values.

@rhyek just tried it, removing them seems to have no effect visually.
In a way it makes some sense for them to be redundant since the @layer base directive from Tailwind is more specific and generally loaded after other styles, which means it can override earlier root styles.
So by having the following:
@layer base {
  :root {
    --background: 0 0% 100%;
    ...

its ensured that the styles defined in @layer base are applied, regardless of what was previously defined

On Arc Browser specifically, there seems to be a continuous issue with the dark mode colors. From what it looks like, there seems that arc is trying to create its own Dark mode color scheme. Chrome plays nice with dark mode.
Neither Chrome or Arc have any plugins, total base browser installations.

@alxgrgrs using the recommendation from the comment here seems to fix the issue kind of...
The thing is that when the user has chosen to use e.g. dark theme on Arc but light theme on mac OS using the following snippet:
const { theme, setTheme } = useTheme()
...
<button onClick={() => setTheme('system')}>System Mode</button>

will result in interpreting as system preference the dark theme, so there must be a conflict between the OS and the browser regarding of what is considered as "system" theme-preference. I don't think this is a direct next-themes issue though, or even shadcn-ui related.
Although what this comment addresses and my comment confirms is that without replacing @media (prefers-color-scheme: dark) with :root[class~="dark"] there seems to be a light theme glitch regardless of which browser you're using. Not sure if others have the same issue though...

This fix it for me. use :root.dark-mode replace .dark
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
  :root {
    --background: 0 0% 100%;
    --foreground: 222.2 84% 4.9%;

    --muted: 210 40% 96.1%;
    --muted-foreground: 215.4 16.3% 46.9%;

    --popover: 0 0% 100%;
    --popover-foreground: 222.2 84% 4.9%;

    --card: 0 0% 100%;
    --card-foreground: 222.2 84% 4.9%;

    --border: 214.3 31.8% 91.4%;
    --input: 214.3 31.8% 91.4%;

    --primary: 222.2 47.4% 11.2%;
    --primary-foreground: 210 40% 98%;

    --secondary: 210 40% 96.1%;
    --secondary-foreground: 222.2 47.4% 11.2%;

    --accent: 210 40% 96.1%;
    --accent-foreground: 222.2 47.4% 11.2%;

    --destructive: 0 84.2% 60.2%;
    --destructive-foreground: 210 40% 98%;

    --ring: 222.2 84% 4.9%;

    --radius: 0.5rem;
  }

  :root.dark-mode {
    --background: 222.2 84% 4.9%;
    --foreground: 210 40% 98%;

    --muted: 217.2 32.6% 17.5%;
    --muted-foreground: 215 20.2% 65.1%;

    --popover: 222.2 84% 4.9%;
    --popover-foreground: 210 40% 98%;

    --card: 222.2 84% 4.9%;
    --card-foreground: 210 40% 98%;

    --border: 217.2 32.6% 17.5%;
    --input: 217.2 32.6% 17.5%;

    --primary: 210 40% 98%;
    --primary-foreground: 222.2 47.4% 11.2%;

    --secondary: 217.2 32.6% 17.5%;
    --secondary-foreground: 210 40% 98%;

    --accent: 217.2 32.6% 17.5%;
    --accent-foreground: 210 40% 98%;

    --destructive: 0 62.8% 30.6%;
    --destructive-foreground: 210 40% 98%;

    --ring: 212.7 26.8% 83.9%;
  }
}

@layer base {
  * {
    @apply border-border;
  }
  body {
    @apply bg-background text-foreground;
  }
}

@Zwyx
Thank you, it drove me crazy why it was working on some of my projects! To be more precise, you don't need to use dark: specifically. Tailwind's scanner is very coarse, so having the word dark anywhere in your codebase is enough for it to be detected (see https://tailwindcss.com/docs/content-configuration#class-detection-in-depth). My problematic codebase didn't include that word so it didn't work.
So if you want to guarantee that the classname never gets dropped, you should always safelist dark. This should be included in the default config IMO.

Ah yes that's interesting, having dark anywhere would work... Thank you for this detail.

Had the same issue, fixed it with :root[class~="dark"] instead of .dark in style.css
style.css for reference: https://github.com/langfuse/langfuse-docs/blob/e9ba748e0e53e5d9179ffc0040839108d1930621/style.css#L39

thanks this worked for me


[Bug] Refreshing table data should not clear the selection

Steps to reproduce the behaviour:

Drag a table
Connect it to a Query
Select a row
Refresh the table data
The selection is cleared

@Nikhil-Nandagopal Did you mean the scenario where the table data is changed? Or should it not be cleared only when the table data is the same?

@riodeuno let's add a default selected row index field and simply honor that value?

closing in favor of #1653


Release v2.0.0-beta.0

To be merged after #462
Release v2.0.0-beta.0

Codecov Report

Merging #464 (169ec9b) into trunk (db398ec) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            trunk     #464   +/-   ##
=======================================
  Coverage   66.80%   66.80%
=======================================
  Files          35       35
  Lines        2636     2636
=======================================
  Hits         1761     1761
  Misses        875      875

Impacted Files
Coverage Δ

src/lib.rs
100.00% <ø> (ø)

Continue to review full report at Codecov.

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


How to publish a xx.crate or a cargo project to local repository

it is useful for offline mode, we pre fetch all of needs crate file to offline machine, then use cargo publish --offline x1.crate, x2.crate ...;
and cargo tree should support package all dependencies, like cargo tree --package /usr/local/rust-dep, cargo will copy all of deps to /usr/local/rust-dep folder, then we can copy the folder to offline machine.

Sorry, I'm having a hard time understanding what you are asking.
cargo publish fundamentally cannot work offline, it sends the package to a registry, which is usually on the network.
If you're referring to a local registry source, there is the cargo-local-registry tool for managing those.
I don't really understand the comment about cargo tree.  If you want cargo tree to read from a local repository, you need to set up the appropriate source replacement.  Or, you can use a local registry, which can support file:// urls.

Sorry, I'm having a hard time understanding what you are asking.
cargo publish fundamentally cannot work offline, it sends the package to a registry, which is usually on the network.
If you're referring to a local registry source, there is the cargo-local-registry tool for managing those.
I don't really understand the comment about cargo tree.  If you want cargo tree to read from a local repository, you need to set up the appropriate source replacement.  Or, you can use a local registry, which can support file:// urls.

Sorry, I'm having a hard time understanding what you are asking.
cargo publish fundamentally cannot work offline, it sends the package to a registry, which is usually on the network.
If you're referring to a local registry source, there is the cargo-local-registry tool for managing those.
I don't really understand the comment about cargo tree.  If you want cargo tree to read from a local repository, you need to set up the appropriate source replacement.  Or, you can use a local registry, which can support file:// urls.

such as I have a my-lib.crate file, and it is not contains in .cargo folder, i want install it to .cargo/cache, and generate index, there has some cargo sub command?

Sorry, I'm having a hard time understanding what you are asking.
cargo publish fundamentally cannot work offline, it sends the package to a registry, which is usually on the network.
If you're referring to a local registry source, there is the cargo-local-registry tool for managing those.
I don't really understand the comment about cargo tree.  If you want cargo tree to read from a local repository, you need to set up the appropriate source replacement.  Or, you can use a local registry, which can support file:// urls.

the function is very similar java's maven: mvn install command

I'm sorry, this issue is pretty abstract and incomplete.  I don't think there is anything exactly like what you are asking. A local registry is probably closest to what you are asking.

I'm sorry, this issue is pretty abstract and incomplete.  I don't think there is anything exactly like what you are asking. A local registry is probably closest to what you are asking.

I'm going to close this as this seems like a major feature request that would better suited for something like the RFC process than an issue here.


Make pylance/pyright supported LS in jupyterlab-lsp

https://github.com/jupyter-lsp/jupyterlab-lsp lets users to configure LSP language server to provider language information.
we should contribute to the repo so that pyright/pylance is one of supported LS. currently, it looks like it supports jedi and builtin python LS.

tagging @luabud @judej

Investigate if jupyter-lsp can use Pylance.

Moving this issue to discussion as an enhancement request for comments and upvotes.


Endless messages in acl tab when concurrently uploading videos to series

When concurrently uploading multiple videos to one series, a message is presented in the acl tab. Right now, that message is repeated endlessly, so one cant proceed.

Is this a duplicate of https://github.com/opencast/opencast-admin-interface/issues/829?

@schuettloeffel-elsa, can you check if the issue still persists in the latest release?

Yes, works with the lates release.

(maybe the fix should be backported to the 15.x release?)

For this, the branching structure of this repo needs to be adapted, which hasn't happened yet.

Ok, then we have to upgrade to OC16 soon


Delete after download

Is there a way for you to make it automatically delete the photo off of iCloud after it is downloaded? The auto-delete seems to only remove the photos you have automatically deleted.

Hi, I haven't added a way to do that, but after downloading all of your photos, you could try running the script from this gist:
git clone https://github.com/ndbroadbent/icloud_photos_downloader
cd icloud_photos_downloader
curl -sfLO https://gist.github.com/Tatsh/0b5a10a2d25f6c8466290401d2026055/raw/77d23ca0d1448f8e8eb4f208dfcfe84781d98d67/delall-icloud-photos.py
python delall-icloud-photos.py

That will delete all the photos and videos from your iCloud account, so be careful with that!


[1.12] Bump Mesos to nightly 1.7.x 57958fb

High-level description
This is a routine bump to the latest Mesos and mesos-modules.
Related JIRA Issues
Checklist for all PRs

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Changelog:
https://github.com/apache/mesos/compare/cb07b697d4fbd8143136b39dd48a64dd634c2c4f...57958fbb9c877f87489cce24830ce88155e20da9

[ ] Test Results: [link to CI job test results for component]

[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot bump-ee


Video Swap

Current video has a bad CTA; changing embedded video to version with correct CTA.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/99bf8c84a110737ae0754b32d81951f625da650f/


Can't train stage 2

when run  stage 2 training,
Not Found for url: https://hf-mirror.com/alexzyqi/GPT4Point/resolve/main/gpt4point_pretrain_stage1_cap3d.pth

I will check it as soon as possible.

Is there some error in the code, I will update GPT4Point++ code in Aug 8th.

Is there some error in

Is there some error in the code, I will update GPT4Point++ code in Aug 8th.

我有相同的问题，不能训练阶段2，请问是否有更新，谢谢


[PE-D][Tester E] Consistency in title for note feature

Based on testing, it seems that there is currently only one note attached to one person.
In the UG, the header for the note feature is "Edit a note of a person", and it might come off across as a person could have multiple notes.
Perhaps it could be standardized to "Edit the note of a person", as per the description.

Labels: type.DocumentationBug severity.VeryLow
original: ziiqii/ped#2

Fixed by #171


Rule34.xxx is broken

Doesn't seem to work with rule34.xxx

It works fine on my end. If yours doesn't work, turn off the "Automatically enter waterfall mode" switch and manually pass the captcha challenge of rule34.xxx before entering waterfall mode.


Fix loopback address display for IPv6

In IPv6, the loopback address is ::1, short for 0000:0000:0000:0000:0000:0000:0000:0001.
Before this commit, it was displayed as ::, which is short for 0000:0000:0000:0000:0000:0000:0000:0000 - not the same addresses.
See RFC 4219 for IPv6.

it is displaying the listen address, and in the case it is listening on the unspecified address, it should display as it is?

@xlc this was a misunderstanding on my part - I assumed the behavior should be the same as when it displayed IPv4's localhost for use in PJS.


Add Support for NWB

Hi,
I've been working on creating a new subclass of BaseRaw that can read from a NWB file. These are organized hdf files that can store multiple types of data streams including those with different sampling rates, sizes from different sources (such as eye-tracking, seeg, scalp eeg, audio etc.). Because they're hdf files they have lazy loading. It would be nice to have a RawNWB object and/or a read_raw_nwb() function so that MNE can work with these types of files. Attached is a link to a gist I made with some example code for reading/writing NWB files (Part 1) and some code snippets I've made to get started with creating a RawNWB object (Part 2). The thing I mostly struggling with is creating the read_segment_file() function. Any insight or help would be greatly appreciated.
https://gist.github.com/sportnoah14/b74f1226c09bd79aa7f7ec7b11af80c9
pynwb docs

There is also an extension for NWB-NIRS that would be nice to support if this is implemented.
See https://github.com/agencyenterprise/ndx-nirs
Also ping @dsleiter

@rob-luke if that extension is a subclass of a TimeSeries then it should work the same. It would be hard to encompass all the extensions. I think just having a single reader for a TimeSeries container is a great start

ndx-nirs stores NIRS data in a class that inherits from TimeSeries, so it should be possible to read the raw data. However, to read channel metadata, I think RawNWB might need to know about specific types of timeseries (eg. ElectricalSeries, SpikeEventSeries, NIRSSeries, etc).
I'm not familiar with the usual implementation details of _read_segment_file for other Raw classes, but all pynwb timeseries objects should have a .data attribute for access to the raw data.
https://nwb-schema.readthedocs.io/en/latest/format.html#timeseries
Would the following help in extracting the desired data?
timeseries = nwb.get_acquisition('timeseries_name')
timeseries.data[start:stop+1, idx]

Or was the difficulty with something else about the nwb files?

@dsleiter I was just meant that support for all TimeSeries subclasses may be difficult. Not impossible though. I've already worked out a way to extract channel information for an ElectricalSeries object. RawNWB may just an up being an object with multiple if statements in its declaration (or a function it calls in its declaration). The biggest issue for this may be if there's significant differences (such as attributes added, deprecated or changed) between versions of NWB. But we can figure that out after getting an initial version running.

Yeah, I think that separate logic might be needed for each TimeSeries subclass in order to get channel information. That sounds good to start with ElectricalSeries and add support for others later. There probably aren't too many cases that would need to be implemented in order to support the majority of use cases for mne users.
I believe the NWB team has been pretty good about ensuring backwards compatibility within major versions, so I'd expect the pyNWB 2.0 API to be pretty stable at least until version 3.0. It might be worth adding a check in the code to verify the major version of the installed pynwb library and raise a warning or error if != 2.
Due to NWB's flexibility, other challenges might be handling situations with multiple acquisitions within a single file or ensuring a consistent label for ElectricalSeries channels across different user-created files (looks like you explicitly add a 'label' column, which might not exist for most NWB files).

@dsleiter I agree, we would probably need separate logic for each case. If it's restricted to the TimeSeries subclasses that are part of primary pynwb package and the major extensions then that should be fine.
Beecause there can be many acquisitions, my thinking is that the RawNWB object would interact with a single TimeSeries as opposed to the whole file. So the function would work more like this:
from pynwb import NWBHDF5IO
io = NWBHDF5IO('myfile.nwb')
nwb = io.read()
raw = RawNWB(nwb.get_acquisition('eeg'))

For other specifications maybe a bunch of kwargs can be added such as ch_names as an argument that points to the column in the ElectrodeTable object that specifies a name for a channel. Otherwise it can simply name channels as "chn1, chn2, chn3" like it would for another TimeSeries object.
Before any of this though we need to get the _read_segment_file() function working to support lazy loading. This is the part that I haven't figured out yet and am still working on. Once this, the most essential, aspect is done then we can go crazy with supporting all the subclasses of TimeSeries

@sportnoah14 still interested in this?

Before any of this though we need to get the _read_segment_file() function working to support lazy loading. This is the part that I haven't figured out yet and am still working on. Once this, the most essential, aspect is done then we can go crazy with supporting all the subclasses of TimeSeries

FWIW a first version doesn't absolutely have to have this. You can just always preload data (then _read_segment_file does not need to be defined at all). It's not ideal but it's a good start, and might be good enough forever if these files are never expected to be very large...

@larsoner im still interested in this. I could start with having data preloaded but ideally I, and I think everyone using NWB files, would like to have lazy loading as these files can get very large. I'm currently on holiday and in the midst of moving but I'll be resuming this once I settle a bit more. Hopefully this coming week or the week after.
@dsleiter and @rob-luke I'd love your help with extensions once I get an initial version for preloaded data working for TimeSeries objects. Maybe some of the core NWB developers would be interested in helping too.


Add error description details

In the script "Get-MessageSolution.ps1" (under Private) please add more descriptions for COM errors like -2147024882 ("Ran out of memory"). Maybe refer to this for help: http://inetexplorer.mvps.org/archive/windows_update_codes.htm

Development posted to branch "1.0.10" for testing


Remove DataType definition

Description
Removes unused DataType message definition.
Related
Closes whylabs/whylogs#1583

[ ] I have reviewed the Guidelines for Contributing and the Code of Conduct.

Passes integration tests.


"Working example" link has no href in Treemap Diagram Project page

Visualize Data with a Treemap Diagram

https://beta.freecodecamp.com/en/challenges/data-visualization-projects/visualize-data-with-a-treemap-diagram
Issue Description

The "working example" link has no href, so when you click that link, it opens a new tab of the challenge page rather than opening the working example.
Browser Information

Browser Name, Version: Chrome v.55
Operating System: OSx
Mobile, Desktop, or Tablet: Desktop

@OFFLlNE @QuincyLarson I think this issue has somehow been resolved. The link seems to work alright. Please confirm.

@ananaymital Yes - agreed. This seems to have been fixed. Thanks!


more cfail tests

I tried adding cfail tests to serde_tests, but mixing syntex-serde_codegen and serde_macros doesn't end well. We can't use serde_codegen as-is for testing without building our own test harness out of asserting that expand runs successful. Luckily there are already compile-fail tests in serde_macros. Let's simply continue adding them there.
fixes #341

@homu r+

Neat, I didn't notice that there already was one. I think testing only serde_macros is fine.


Read shapefile metadata

Reads ShapefileInfo properties for a local shapefile and displays credits, summary, thumbnail, and tags in the UI.
@nCastle1 - please review when you have time, thanks!

PR has been merged. All PR review changes were made and the sample was re-tested on all platforms.


LabelGroup - translate Show Less / N more

Follow-up to https://github.com/ansible/ansible-hub-ui/pull/3248
Fixes: AAP-3734 & AAP-7344
Similar to Select & ChipGroup, LabelGroup also needs translations for "Show Less" and "{count} more".

(merging now to unblock functional component PRs without breaking the 4.6 backport)


[Hotfix] Missing err

Cannot compile with last master without this

@LoicMarechal

Hi Vicente.
Thanks for pointing that out so quickly :-)
I defined the "err" at the beginning of the procedure to be consistent with the others.
Someone submitted a pull request that I accepted but it modified the master instead of the develop branch...
Regards,
Loïc

Hi Vicente. Thanks for pointing that out so quickly :-) I defined the "err" at the beginning of the procedure to be consistent with the others. Someone submitted a pull request that I accepted but it modified the master instead of the develop branch... Regards, Loïc

Yes, I saw, but I fixed ASAP

Hi Vicente. Thanks for pointing that out so quickly :-) I defined the "err" at the beginning of the procedure to be consistent with the others. Someone submitted a pull request that I accepted but it modified the master instead of the develop branch... Regards, Loïc

Yes, I saw, but I fixed ASAP

No merge then?

Ok, you already fixed


update regexp

close https://github.com/status-im/status-js-desktop/issues/8#event-1997528827

Now thumbs up works from typing :+1 (which is the text that is outputted from the emoji picker).
The problem was that the regexp used to match text before sending it to the emoji render component was too specific, looking - more or less - only for alpha/letter characters. I broadened its remit so that it would match the required emoji code (not with an exact match, but one that would match similar formulations too), and did so with an OR operator so that it would still keep some specificity (and efficiency - we don't want to send too many things to the emoji render component to attempt an exact match on).
I tested against a few other emojis, which still render.

Anyone with merge rights available to merge?


Some config options lost in the port to calico repo

Seem to have lost some (felix) config options from the docs, such as the one to LOG-and-DROP packets.
Canonical list is here in the code: https://github.com/projectcalico/felix/blob/master/go/felix/config/config_params.go#L88

Some of these options weren't ever 'production ready', so please check with me before adding anything back in to the docs :).


Wrap lines option in request and response examples

Feature Description
A checkbox to wrap lines in code blocks and request+response examples. I saw this feature here(https://docs.cdp.coinbase.com/cdp-sdk/reference/getasset) and thought it was pretty cool.
Use Case
When responses return long strings or many nested properties that are difficult to read.

@nateKlaux love the idea of bringing the best-in-class ideas from other docs sites into Fern Docs.  Is there a specific code block you have where you'd want this? Will allow us to test when we build it!


[Epic] Develop the challenge data ingress workflow for read-only REST API

The goal of this Epic is to design and develop the challenge data ingress workflow that we will use to populate the challenge registry until our UI and REST API support write operations. These features should not be developed before 2023 Q2.
We need to identify how to perform the following operations:

Collect challenge data from Challenge organizations
Validate the challenge data submitted
Push the challenge data submitted to the challenge registry

Tasks

[x] Explore CQRS pattern
[x] #1273
[x] #1145
[x] #1147
[x] #1328
[ ] #1324
[ ] #1325
[ ] #1326

Architecture
Pushing data to the challenge registry
Let's start with how we could push data to the registry.
There are two reasons we won't use the REST API to push data to the database for this story:

The REST API won't support write operations until 2023 Q2.
We implemented this approach first when we were developing the prototype and this was more complicated than expected. The reason was that we had to track the response of queries (e.g. get the ID of the challenge newly created), then use this information to push other artifacts such as challenge team members, sponsors, etc. We then took another approach with the development of the challenge registry DB CLI where we dump challenge data into the databse, one table at a time.

I made sure we could build the CLI DB after moving it to the monorepo but it has not been maintained and has since been "disconnected" (by renaming its project.json to project.json.off). I will take care of reconnecting the DB CLI to the monorepo to make sure that it can be built and run.
Legacy DB CLI: https://github.com/Sage-Bionetworks/rocc-db-client
DB CLI in the monorepo: apps/challenge-registry/db-cli
The DB CLI was developed to push data to a MongoDB. Since then we have switched to a MariaDB instance (SQL). The DB CLI must then be updated to push data to the MariaDB instance of the challenge registry project.
The legacy DB CLI includes different seeds (JSON data) that we were pushing to the MongoDB instance.
https://github.com/Sage-Bionetworks/rocc-db-client/tree/main/data/seeds
Validation of the data
There are two ways of validating the data.

Develop a Schema.org/JSON-LD schema and use it to validate the JSON data.
When pushing the data to the MariaDB instance. E.g. pushing a number to a VARCHAR will result in an error.

Ideally we should use both approaches. Developing and sharing a Schema.org/JSON-LD schema of the data included in the registry is a must down the road. Moreover, the pages of the challenge registry can now expose JSON-LD data. The chema.org/JSON-LD schema would largely contribute to the JSON-LD metadata that we will ultimately embed in the pages.
We can use the Schema.org/JSON-LD schema in a GitHub workflow to validate the data submitted by a contributor without needing a running instance of the MariaDB (faster, easier the validate).

@rrchai @vpchung This diagram shows the architecture I have in mind for pulling challenges and bring them to the OpenChallenges DB. The idea is that candidate challenges would be stored by a data curator service. This curator service would talk to the challenge service and organization service to know what resources are effectively in the so-called OpenChallenges DB. To enable full text search and advanced search features, approved challenges would be stored in Elasticsearch, which would then power a search service.
I will present you this architecture more in depth in our next meeting but comments and questions are already welcome.

Update
This architecture diagram captures the entire data processing workflow.
The remaining piece of work is the creation of a search service that leverage Elasticsearch, ideally instead of the combo SQL + Elasticsearch as implemented by the challenge and organization services.

Update
We make good progress on architecting how the data will flow from the different data sources to the OC DB.
My next highest priority is to develop the search service where challenge and organization data will meet to power the different queries we have discussed over the past few months.

Moving to Sprint 23.03

Update 2023-04-03
We have a draft of the workflow in Lucidchart, which needs to be cleaned up. I won't have time to work on this Epic this in April but hopefully I can come back to it end of May or June.
Adding tentatively to May sprint.

Return to Backlog


Refactor loop variables

Remove external variable declarations and move variables inside loop statements, for example: https://github.com/metarhia/metasync/pull/370
New comparison tests shows that external declaration gives no performance advantages anymore.

Closed in https://github.com/metarhia/common/pull/176


Add deprecation warnings to non PEP-8 compliant methods

Closing since this is superseded by PR #523.


fix(CallOut): allow custom title tag

Following DSFR Doc looks like we should be able to custom the CallOut title tag.
thanks

Perfect thanks!


Fix ellipsoid tracking

Bounding spheres were transformed by the model matrix and cached. If the model matrix was changed, the cache was never updated. This change returns transformed bounding spheres by the current model matrix on property get.
Fixes #4929.

@emackey can you test this out in your specific use cases, I just want to be sure this is squashed for good.
Thanks @bagnell!

Just to clarify, the bounding sphere provided by Primitive is always guaranteed to already have it's transform applied now?  Historically that wasn't the case, and a few months ago it became the case sometimes.  I just want to understand what the behavior is supposed to be so that we don't have future issues.

Just to clarify, the bounding sphere provided by Primitive is always guaranteed to already have it's transform applied now?

Yes, all bounding volumes should be in world coordinates.

My first test of this showed correct behavior with an example ellipsoid, horray!!
For my second test, I copied all the sample code from #4929, and replaced these two lines:
    "ellipsoid":{
      "radii":{

with this:
    "box":{
      "dimensions":{

With this edit to the demo, the selectionIndicator still works fine, but the camera tracking is broken.  The camera zooms to wherever the object is when you double-click it, but as time animates forwards, the object flies away from the camera.
Note that master has the same behavior with camera tracking of dynamic boxes, so this is not something new being introduced here.  It may actually be mostly unrelated, and I would be fine with merging this fix without a box fix.

Thanks @emackey I'd like to take a look at the box issue before merging this since it should be trivial and probably also means everything BUT ellipsoid is broken (since ellipsoid is a special case and everything else goes through the same code path).

This is a tough one.

"Dynamic" geometries are for the most part just create a new Primitive synchronous primitive every frame.
Since the primitive is created in the same frame that Viewer._onTick is trying to use it, the primitive is never "ready" and therefore the boundingSphere is always undefined.
The only reason this isn't a problem with Ellipsoid is because it reuses the same primitive in 3D and just sets the model matrix (most of the time).  Switch to 2D or make something like stackPartitions dynamic and the tracking is broken again.
Every "easy" fix I can think of so far causes the camera to lag the primitive by a frame, which is just as broken.

One possible option I've yet to explore is having dynamic geometries provide non-primitive based bounding spheres.  This will cause dynamic-ground primitives to still be broken (but they are probably too slow to be usable anyway), but would fix every other case I can think of.  Unfortunately, this approach requires custom code for each dynamic geometry so it's slightly more involved.
Anyone else have any ideas here?

This may be a bit sweep-under-rug-ish, but I'll suggest it:
If a dynamic primitive isn't "ready", just use Entity.position or the Entity's other bounding spheres without paying attention to the missing bounding sphere.
Here's my reasoning:  The main thing we need the bounding sphere for is the size of the dynamic object at the moment the camera starts tracking it.  For example, if you start tracking a small box or ellipsoid, the camera will be placed closer than if you start tracking a large one.  However, once you begin tracking, the size no longer matters:  The camera just stays at the same relative distance, or the user adjusts that distance, but the camera tracking doesn't automatically adapt to size changes.  The entity may grow and swallow the camera, and it's on the user to back the camera away (this is by design, to show the entity growing and shrinking).  Therefore, getting new bounding spheres after the tracking begins shouldn't be needed, I believe, as the camera is just following along with the position after tracking has already started.
Since all that's broken here is the post-tracking camera position update, I think that should be able to happen based on position alone.  The bounding sphere size is only needed at the start of tracking.

Since all that's broken here is the post-tracking camera position update, I think that should be able to happen based on position alone. The bounding sphere size is only needed at the start of tracking.

This is only true for items that are not clamped to terrain.  If the item is clamped to terrain (or doesn't have a position like polygon) then the bounding sphere is the only place with the correct information.

Since this does fix a bug with Ellipsoids, and doesn't change existing behavior for non-ellipsoids, can we merge it for the next release?

Since this does fix a bug with Ellipsoids, and doesn't change existing behavior for non-ellipsoids, can we merge it for the next release?

I'm okay with that, but let's write up an issue that summarizes the current state and problems so we fix it.

Also, please update CHANGES.md.

Moved box bug to #5164, it's unrelated to this.
Thanks much @bagnell!


Revert "fix: sensor to use scheduled_time & all the window params (#2…

This reverts commit 2ce5ba4f1e6dfcc4ca84f239d6d24d9a4e70464a but keeps the make file changes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 72.87%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5345

Relevant Lines:
7335

💛  - Coveralls


Digram bug

When I try to move and entity or any of them, it buigs and don't show where i moved it or it moves them to a large distance from where I am working.

Hi @viviangbrito, can you record a short video? I could not visualize what is happening.
ps. Are you brazilian? We can speak portuguese if we you wish!