[+orion] Bug 'what is sugaroid?'

The following answer was a given by sugaroid, and is considered as a bug. Please
manually review this issue, and close it if it looks unnecessary.

user: what is sugaroid?
sugaroid: An unhandled exception occurred: Traceback (most recent call last):

File "telegram_bot.py", line 162, in on_message
response = str(sg.parse(msg))
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/sugaroid.py", line 242, in parse
response = self.neuron.parse(args)
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/brain/brain.py", line 74, in parse
response = self.gen_best_match(preprocessed)
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/brain/brain.py", line 99, in gen_best_match
return self.bot.get_response(parsed)
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/core/bot.py", line 355, in get_response
response = self.generate_response(
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/core/bot.py", line 142, in generate_response
output = adapter.process(
File "/app/.heroku/python/lib/python3.8/site-packages/sugaroid/brain/wiki.py", line 64, in process
elif "up" in self.text.lower():
AttributeError: 'list' object has no attribute 'lower'

Fixed somewhere


chore: hack11 renderWithWrappersTL

This PR renames
renderWithWrappers => renderWithWrappersLEGACY
renderWithWrappersTL => renderWithWrappers
Description

PR Checklist

[ ] I tested my changes on iOS and Android.
[ ] I added screenshots or videos to illustrate my changes.
[ ] I added Tests and Stories for my changes.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Need help with something? Have a look at our docs, or get in touch with us.

We dont have this in energy
renderWithWrappers => renderWithWrappersLEGACY
So maybe we can remove that from the PR description.
Other than that it's a good change.


Move fume hood under exhaust fan class

Proposing to classify brick:Fume_Hood as a type of brick:Exhaust_Fan.
A fume hood is a type of local exhaust ventilation device designed to protect users from exposure to hazardous fumes, vapors, and dust. It is typically mounted over a workspace, table, or shelf to capture and conduct unwanted gases away from the enclosed area.

ASHRAE's definition implies the exhaust function in the phrase "serving to conduct unwanted gases away from the area enclosed", though it does not explicitly state that it exhausts air from an enclosed space.:

a fume-collection device mounted over a work space, table, or shelf and serving to conduct unwanted gases away from the area enclosed. The least effective fume hood is a canopy hood, open on four sides. The most effective fume hood effective is an enclosed hood with operable front sash and fixed sides and back


LaTeX Linters

Adds support for chktex and lacheck.
chktex:
Supports finding a project's .chktexrc file. It uses ale#util#FindNearestFile even though that is not the search algorithm chktex uses. However, I find this to be the least surprising implementation for users that have a directory structure within their LaTeX project. For example, normal latex practice is to run latex, lacheck, etc. on the top most tex file in the root of the project. These programs then typically follow \input{} commands into the other files. As a result chktex expects .chktexrc to be in the current working directory. However, when editing a tex file from a sub-directory ale somewhat incorrectly calls chktex (at least with respect to how chktex is usually called). Therefore, we look up the project tree for a .chktexrc.
lacheck:
lacheck has the same problem but it does not have a configuration file so I just throw away lint errors that are not for the file in the buffer -- see viml comments

@abalmos I have some huge tex projects and I have not managed to get this PR to find any errors
I have a structure like this:
projectdir
----master.tex
----sectionsdir
    ----section1dir
         ----section1.tex
    ----section2dir
         ----section2.tex

If I run Ale on section1.tex I get no errors/ warnings

@poohzrn That's strange. A colleague of mine and I have been using this for a few weeks without issue for both chktex and lacheck.
Are you sure chktex and lacheck are on your path? If not, try setting g:ale_tex_chktex_executable and g:ale_tex_lacheck_executable.
I assume that you have lint errors for those files when you run chktex and lacheck by hand?
Is vim identifying the buffer filetype as tex or plaintex?

I was on the wrong branch........

Looks good to me! :+1:

Could you rebase and fix the conflict here?

@w0rp Pushed a rebase

Cheers! :beers:


Remove smart-answer: state pension topup

Trello card
Description
State pension topup has now reached the end of its life and needs to be
retired.
This PR removes data artefacts, templates and code that belonging to
the sate pension top-up smart answer.
Expected changes

State pension topup smart answer no longer exists

If all regression tests are passing, I am ok to merge into integration.

@pmanrubia The regression  tests are all passing https://ci.integration.publishing.service.gov.uk/job/smartanswers/job/remove-state-pension-topup/10/console


Add Nano Server to the list

Description of Change
This PR should just create 2 new NativeAssets packages for Microsoft Nano Server.
Because Nano Server is really just Win32 without some features, you actually can just build it using the same code, but with a few extra args - basically a new #define SK_BUILD_FOR_NANOSERVER
.\bootstrapper.ps1 -t externals-windows --buildarch=x64 --additionalGnArgs="extra_cflags+=[''''-DSK_BUILD_FOR_NANOSERVER'''']"

all those extra single quotes (4 of them) are required to make sure powershell doesn't mess up the parameters.

TODO:

[ ] tests
[ ] some sort of verification like with NoDependencies for linux

Bugs Fixed

Resolves #676

API Changes
None.
Behavioral Changes
None.
PR Checklist

[ ] Has tests (if omitted, state reason in description)
[ ] Rebased on top of master at time of PR
[ ] Changes adhere to coding standard
[ ] Updated documentation

/azp run

Check out this build's artifacts: https://dev.azure.com/xamarin/public/_build/results?buildId=9982&view=results

This will be pulled in with https://github.com/mono/SkiaSharp/pull/1040.


Redirect Feature and Sheer UI

Curious on whether the Redirects feature will get deprecated or replaced in Sitecore 9.1+. The use cases outlined seem pretty solid and the implementation as well. But with the Sheer UI interface, it seems a replacement for that would be a necessity.
Overall, Constellation looks pretty good. Nice work!

The Redirects feature  (as deployed) will continue to work as long as Sitecore supports the Desktop, which they've said will always be SheerUI. - It works fine in 9.1.1 and I imagine it will work in 9.2 as well.
the "guts" of the redirect feature are UX independent, relying on stock Sitecore data functionality. If Sitecore decided to deprecate SheerUI, then I would seriously consider rewriting the front-end of Redirects as traditional ASP.NET MVC, making it more of a console app. The only reason it remains a SheerUI app is for continuity between Sitecore editors.


Fix typo in fincm3 device spec

Change the flashing type for fincm3 to be compatible with the standard used in the flashing lib.
https://github.com/balena-io-hardware/autokit-sw/blob/5dc32c47713f242c9e498ee898e43cffd7d32b2e/lib/flashing/index.ts#L298
Change-type: patch
Signed-off-by: Pedro Henrique Kopper<EMAIL_ADDRESS>

@balena-ci I self-certify!


Modularized app. Can I use R.swift in a package?

I want to modularize an app into several modules (like networking, shared ui components, resources, etc).
If  I create a package with my Assets catalog and localized file, will R work in that package ? what it would take for it to work?
Thanks!

Yes, you can. I create a Package File Container to share all Assets to all SubPackages, It works perfectly

In general, yes this is possible to use Rswift across multiple targets of packages.
If you have some specific use case that is not working, please create a separate issues for that.


Error on 1.2.4 and 1.3.1

Hey there,
I downloaded the MissingHUD 2 today and on the first try it opened well.
All the other tries ended up like this and its not CCleaner or the Path

Path:

as you can see too I downloaded more than one Version
Im using
Win 10 and Kaspersky
also moving the executable into the Isaac Direction havent worked and even deinstalling and reinstalling both Isaac(also to new directions like C:\ or D:) and MissingHud
I hope someone of you can help me :/
Thanks

This is most likely an anti-virus related issue. Something on your machine is blocking "CreateRemoteThread" for security reasons.
Try running MHUD2 as admin, or adding the .exe to Kaspersky's exclusions list.

thank you very much. I now have fixed the problem but a new error occured.

Its when I run the HUD2 when i am Admin as well.
Sry if its a bit too much but I´m not extremely good with these specific types of errors.
Thanks again

Fixed it :D
.
.
.
Now this D:

You need to look at the MHUD2.log file to work out the exact error the injected DLL is having.

Closed due to inactivity...


How can I use this template and have version pinning?

Problem Statement:

https://docs.pepr.dev has a Releases dropdown and updates given that selection. There may be additional changes to the template implemented https://github.com/defenseunicorns/pepr-docs
I'd like to see documentation on how to effectively leverage this template and replicate that need.
Acceptance Criteria:

Documenation added and tested that would allow me to create a new docs site and have version pinning.

Here is the repo for the templates: https://github.com/defenseunicorns/doc-site-template
Andrew would LOVE to see this get worked but not to disrupt work....But would LOVE to see it done...

I'll update the template README for some common links, but the documentation for this exists on the theme doc site.
https://main--starlit-valkyrie-7f1dd9.netlify.app/docs/adding-content/versioning/


Slight redesign of Player#getLocale ?

https://github.com/SpongePowered/SpongeCommon/issues/1145

Player#getLocale will always return en_US when a client joins - the Player's locale gets updated after joining, when packet 0x04/CPacketClientSettings is sent to the server.

Would it be feasible to replace the method with an optional returning method, instead of defaulting to en_US? That + documentation would make it crystal clear to people attempting to use it on join.

A locale must be available, as it is possible to send messages before the server is aware of the client's real locale.

Sure it's possible to send messages, but that doesn't mean it needs to be exposed to plugins while it's potentially incorrect.
If they want to send messages, they can already without the Locale.
If they want to send localized messages, before they have the players locale, then they can make their own assumption or use a configured default?
If people are against the idea, another option could be to have a default locale configured, so that a french hosted server, targetted at french players, could always default to french.

@ryantheleach Do keep in mind that plugins can send translated messages, in which case a locale is always required.
A default locale option wouldn't be extremely useful, seeing as it'd only be useful when first logging in.

thoughts @Minecrell?

I feel like making it return an Optional is unnecessary, and kind of a pain. There is no problem defaulting to something for the short time where it is not set, as messages may need to be sent and some systems need a locale, and in most cases English is used anyway.
This will just make it so there's a bunch of player.getLocale().get() calls everywhere whenever the locale is needed, since 99% of the time it is available.
If anything, a Javadoc could just state this default either on the getLocale() method or on the joining events.

@Meronat more like player.getLocale().orElse(Locales.Default) but I understand your point, which is why I offered that maybe Sponge should be able to offer a non US based default, by configuration.

I think adding a comment to getLocale for Players is a good idea.

Offering a configuration option for a default language is not a bad idea, as it could be of use elsewhere in Sponge and in plugins.

I think so too. We should either default to a configurable or the system locale and add a comment in the jabadocs. Maybe we should also state that plugins that want to use the locale should use the scheduler and wait x/a few ticks for it to become abailable.
I also considered using a locale that represent the locale like xx_yy. But i guess this requires special handling as using Optionals does.

Has the situation changed at all with the packet sequence for logins under 1.13?

No, @ryantheleach.

Why not have something along the lines of Optional<Locale> getLocaleSafe() for those who need to know whether or not a player is actually in the default locale and then something along the lines of
default Locale getLocale() {
    return getLocaleSafe().orElse(Locales.Default);
}

This way you don't break existing code but you also make it clear to those who need to know whether or not the language presented is actually the language of the client or the default?

The client always sends a language. It is impossible to know if a user has explicitly chosen en_us or if it is the default.


Introduce an annotation for importing elements just for doc comment references

This is an alternative proposal to https://github.com/dart-lang/sdk/issues/49073. This proposal improves upon the readability and perhaps the simplicity of that proposal. It is based on @lrhn 's brief comment on that proposal.
BACKGROUND
Audience
Anyone writing documented Dart code.
Glossary

Doc comment (or dartdoc comment or documentation comment) - a Dart code comment in which each line starts with three slashes (///), and which is placed just before a library element (class, top-level function, top-level constant, etc.) or a class/mixin/enum/extension element (method, field, etc.). A doc comment is parsed (by various tools) as Markdown text.
Doc comment reference - the name of any element wrapped in square brackets, inside a doc comment. This is typically one identifier or two separated by a period, like [List] or [Future.wait].
Top-level namespace - a set of top-level elements defined by one or more import directives and the current library, which share a common prefix. A library has a set of one or more top-level namespaces.
Un-prefixed namespace - the unambiguous union of all elements provided by all of the un-prefixed import directives (no name collisions of non-identical elements are allowed) of a library, plus all elements declared in the library (which may shadow any imported elements).
Prefixed namespace - the unambiguous union of all elements provided by all of the import directives which share a common (non-empty) prefix (no name collisions of non-identical elements are allowed).
Dart URI resolution - the strategy for resolving a URI string into a path in order to locate a Dart library (or part) file.
A Dart library’s export namespace - the collection of Dart elements exported by a library, which includes all public library elements declared in a library (including parts) and all elements exported by the export directives in the library (taking into account any show and hide combinators).

OVERVIEW
The basic design is to add a new annotation, perhaps to the meta package, @docImport which looks similar to an import directive. When a library is annotated with this annotation, the analyzer will add elements to one of a library's top-level namespace, just like an import directive. Doc comment references can then resolve to elements provided by such "doc imports". Quick examples:
@docImport('dart:async')
@docImport('package:flutter/element.dart', show: ['Element'])
@docImport('../path/to/somwhere.dart')
@docImport('dart:html', as: 'html')
library;

/// We can now reference [Future] from dart:async, [Element] from Flutter's element library,
/// and [html.Element] from dart:html, even if none of these libraries are actually imported
/// by this library.
class Foo {}

DETAILED DESIGN/DISCUSSION
A class is introduced which can be used as an annotation:
class docImport {
  final String uri;
  final String? prefix;
  final Set<String> shownNames;
  final Set<String> hiddenNames;
  const docImport(this.uri, {
    String? as,
    Set<String> show,
    Set<String> hide,
  }) :
      this.prefix = as,
      this.shownNames = show
      this.hiddenNames = hide;
}

Each docImport annotating a library directive introduces a doc import which contributes to a new doc namespace.
A library currently has one or more top-level namespaces: the un-prefixed namespace and zero or more prefixed namespaces, which result from import directive(s) with prefixes.
Each identifier in a library (both in code and in doc comment references) is resolved according to various scoping rules, which may resolve to a non-top-level identifier, or a top-level identifier from one of the top-level namespaces. (This is a simplification since a prefix itself is an identifier which needs resolution, and which can also be shadowed by a non-top-level identifier.)
This change introduces a second set of namespaces used only for the resolution of doc comments: the "doc namespaces." The doc namespaces are a superset of the regular namespaces, and each doc namespace is a superset of the corresponding regular namespace (with the same prefix).
For a given library, the doc namespace with prefix p is computed via the following steps:

Start with an empty set of elements.
For each import with prefix p:

For each element provided by the import, according to the rules of 'show' and 'hide':

If there is an element with the same name already in the namespace, report a compile-time error.
Otherwise, add the element to the namespace.

For each @docImport annotation specified with prefix p:

For each element provided by the import, according to the rules of 'show' and 'hide':

If there is an element with the same name already in the namespace, report a static warning.
Otherwise, add the element to the namespace.

If this is the un-prefixed doc namespace, then for each top-level element declared in the library:

Add the element to the namespace, replacing any element currently in the namespace with the same name (shadowing it).

(The "regular" namespaces are computed in the exact same way, excluding step 3.)
Each doc comment reference is then resolved using the standard scoping rules, and using the doc namespaces as the set of top-level namespaces.
New static warnings are reported in the following situations:

when the URI cannot be resolved, according to the URI-resolving rules
when elements from a doc import have name conflicts with each other, or elements from imports with the same prefix
when a prefix name does not match certain identifier rules
when a show or hide clause includes names of elements which are not found in the library's export namespace.
when a doc import is redundant, duplicate, or unnecessary (various subtle definitions) with a regular import or another doc import (lower priority)
when a doc import is unused (lower priority)
when an element in a show or hide clause of a doc import is unused (lower priority)

ACCESSIBILITY
I am not aware of any accessibility considerations.
INTERNATIONALIZATION
I am not aware of any internationalization considerations.
OPEN QUESTIONS

Can we define the docImport class and constructor in dart:core? This would be required if we want to use docImport functionality in the Flutter engine, which cannot import package:meta.

If not, should we instead support this feature as some sort of directive in a doc comment? For example, instead of the annotations in the OVERVIEW section above, we could instead support:
/// @doc import 'dart:async';
/// @doc import 'package:flutter/element.dart' show Element;
/// @doc import '../path/to/somwhere.dart';
/// @doc import 'dart:html' as html;
library;

This solution has some significant drawbacks:

It would be much more complicated to parse all of this syntax in doc comments, making it error-prone.
For all of the error cases of the parsing, we'd have to report errors, as long as it really looked like a doc import was intended.
We wouldn't get any syntax highlighting for free. That would also have to be implemented, and implemented once for each syntax highlighter we try to keep up (DAS, highlight.js, CodeMirror, Kythe, ...)

TESTING PLAN
Support for this syntax will be tested in:

analyzer's unit tests
analysis server’s navigation tests, hover tests, etc.
dartdoc’s reference unit tests

DOCUMENTATION PLAN
The support for this feature can be documented on the docImport class.
MIGRATION PLAN
If a developer has wanted to reference an out-of-scope element, there are a few strategies they may have ultimately chosen:

Use backticks instead. For example, /// See `List` . For this case, we can offer a lint and a quick fix, "this could be a doc comment reference." (This could have many false positives.)
Import the element, making it now in-scope, just to be able to reference it. In this case, we could report an "import only used for comment references" lint, with a fix which removes the import and adds a corresponding doc import.
Ignore the fact that the IDE won't cross-link, rely on dartdoc's ability to find far-flung elements. For this case, dartdoc will start reporting a warning that such an element will not be discoverable with the current, ambiguous, syntax, and will suggest a doc import. A shell script which parses such warnings could act as a migration tool.

This addresses https://github.com/dart-lang/sdk/issues/44637.

Can we define the docImport class and constructor in dart:core.

We obviously can, but I'd prefer not to.
We generally try to avoid having tool-specific annotations (or annotations at all, since all annotations are tool specific to some extent) in the platform libraries.
Platform libraries are prime real-estate. Adding annotations that makes sense for one tool initially seems reasonable, but when multiple tools starts doing it, it doesn't scale.
Changes to the annotations are driven by the tools, not the library maintainers, which splits the responsibility for maintaining platform libraries into multiple teams.
Because platform libraries are hard to change, it also locks the tools into the current implementation. Changing almost anything becomes a breaking change, which can dampen the velocity of tool development.
A tool can easily support multiple versions of their own metadata at the same time, but the platform libraries
would loathe to have multiple versions, some probably deprecated, at the same time.
Going through a multi-version deprecation, breaking-change and migration process in order to change an annotation isn't really worth it.
We have pragma as the compromise. It's for our own tools, or confident expert uses, to make notes on source code without needing to add visible annotations types to the public namespaces. It's not really for normal end users.
A @pragma("dartdoc:import", "package:foo/foo.dart as p show Foo") can work, but it's not convenient.
(Using a package import to support dartDoc is clearly not viable. It would be adding an import to an otherwise unnecessary library, in order to avoid writing imports to otherwise unnecessary libraries.)
I would recommend using // @doc .... import syntax, and work with the analyzer on recognizing them for highlighting and possibly linking (if that's who controls that, plain regexp-based high-lighting seems doable too).

cc @gspencergoog @bwilkerson

If enough people think the annotation will be highly valuable to many users, expected to be stable enough to not require frequent updates, and otherwise generally worth it, it's definitely technically possible to add it to dart:core.

I imagine it being used almost never. It's really just for the flutter/engine and flutter/flutter repos. And some users here and there will use it, but I think an order of magnitude less than unawaited.
That leaves us with:

@docImport declared in package:meta and I think it would also have to be declared in dart:ui, so that flutter/engine could use the annotation. The analyzer would have to recognize annotations from both libraries.

/// @doc import, which I really prefer not to do for the reasons above, in OPEN QUESTIONS. But it's an option.

This doesn't feel like an API that will change much (it mirrors the import mechanism, which is pretty mature syntax), so I don't have a lot of concern about the API needing to wait for major releases to make changes. It's also given meaning by the tools, since it's mostly just metadata, so the tools can evolve around this basic definition without needing the definition itself to change. And, since it's basically the same information as in an import statement, it's not really tool specific: someone could write another documentation system, and they'd still need, and be able to use, this doc import information.

@docImport declared in package:meta and I think it would also have to be declared in dart:ui, so that flutter/engine could use the annotation. The analyzer would have to recognize annotations from both libraries.

I'd prefer it to be in dart:core, for the reasons Sam mentioned initially, but if that's not acceptable, It seems like this is the least bad alternative.

As a counter-point to my other opinion, the one reason to put annotations into platform libraries is that the libraries themselves use those annotations (Deprecated, Since, pragma).
Do we expect that platform libraries will want to use the feature?
Platform libraries may want to refer to, say package:async or package:collection, but definitely do not want to depend on those for compilation. A doc-dependency may be just the thing we need for that.
If we do use an annotation for it, then we will need that annotation in the platform libraries too.
(Obviously, if we use // @doc import ..., then you don't need anything to write it, it's done entirely inside the DartDoc tool. But then, so is the annotation interpretation, it's just the annotation class itself which needs to exist.)

Do we expect that platform libraries will want to use the feature?

dart:ui is the primary motivation for putting this in the platform libraries. I'll leave it to others to declare whether that counts as being in the platform libraries. As I understand it, the code that makes up dart:ui cannot depend on packages.

My gut feeling is that the most appropriate approach is to put the links inside comments (maybe even require it to be a doc-comment, so /// @doc import ...). That way, they are only visible to DartDoc itself.
If it's an annotation, then it's visible to everybody, whether they need it or not.
That's true for any other annotation too, but DartDoc already has its own carved out area for non-annotation metadata (doc-comments), so it feels unnecessary to add a second.
I'm not particularly worried about parsing. If we can piggy-back on the Dart parser, it's better, but even without it, it's a fairly restricted grammar.
If we want full IDE integration, then the analyzer should be able to understand the imports too (and therefore parse them), so that it can correctly link external doc-references in an IDE. I'd prefer to have that no matter what syntax we choose.

To me, dartdoc is only half, maybe less than half of the story here (this proposal hardly references dartdoc). The main client, in my mind, is analyzer, such that these references inside doc comments are resolved correctly inside the IDE (meaning lots of things: navigation, hover, participation in renames, etc), in static analysis, in code search (GitHub, Kythe, etc)
That being said, the singular use is, as you point out, to handle comments, which is not something typical annotation-customers handle. I don't know if the language spec or any other document says what annotations are for, or if their use is encouraged for this purpose or that purpose, but today most annotation use is for code generation (via analyzer APIs) or the analyzer (as its own tool).

The intended use of annotations is to attach metadata to something. The spec doesn't say any more, because it cannot know.
Attaching metadata only makes sense if someone can read it. With dart:mirrors being gone on most real platforms (web and Flutter), annotations are primarily read by source-processing tools.
The design of annotations, however, was guided by being used by mirrors. That's why it's important that the value can be created using actual code imported into the current program, because otherwise the value couldn't exist in the program when dart:mirrors accessed it.
If I were to design metadata today, I'd probably not do it that way. Using Dart objects is a reasonable choice, because it gives structure and type checking that would otherwise become a second mini-language, but I'd probably introduce "meta imports" to back the annotations, which the production compiler would not need to worry about. Members only imported using meta-imports could not be accessed outside of metadata. Maybe even allow more separation, so annotation processing tools only need to care about their own imports, not those of other annotations.
Kind-of like what I think we're doing with macros. And what @docImport would do, but without being reusable for other annotations,.
DartDoc is a little special in this regard in that it's a kind of metadata attached to declarations, intended for a tool to process, that predates annotations. Even if we did have annotations back then, documentation is special, because it's more like text than like structured data. It wouldn't be as convenient if you had to do @dartdoc(""" .... docs ... """) instead.
We'd probably still use comments for documentation, like every other language.
So, annotations are not amazing, because they impose source dependencies that the production code doesn't need.
DartDoc has a way around that by embedding its own metadata inside the comments, like macros, which is why I'd lean into that instead of introducing another external code dependency, just to be able to interpret the doc contents.
In that way doc-imports feel similar to doc macros, which are required to interpret later DartDoc content, but not used for anything else. Doc-macros could also have been annotations, but it didn't seem reasonable (probably also because they contain actual documentation text).
Putting the dependency into dart:core sidesteps adding a package or library dependency, but still moves something related to DartDoc content out of the doc comments where I'd look for it.

I do wish that Dart source files were able to integrate foreign data containers more easily into the language.
For instance, it would be nice to have the ability to segregate portions of the file (without needing to prefix every line) to enable things like building the equivalent of a Jupyter notebook or CoLab, where the code is effectively embedded in the documentation instead of the other way around.
Or being able to have multiple compilation units in one file, so that you can have unit tests, API documentation example code, and application/framework code co-mingled in the same file in different namespaces, and have the analyzer (and thus IDEs) understand all of them and check them in their respective namespaces/containers.
Although, really, that isn't necessarily the purview of the language to define: you could build those things on top of the Dart language as-is with tools (as we've done with dartdoc), and that probably allows better subdivision of responsibility and allows more powerful aggregation of fine grained tools. But it is helpful to be able to attach extra-language metadata in the file to serve as data sources, which is kept in sync with the code, for the tools operate on.
The /// @import syntax isn't horrible, and I can see the argument for "keeping it in dartdoc", but what it means is that the analyzer is going to need to parse and understand not only Dart, but also more and more of the documentation comments as if they were required to be in dartdoc format, making the analyzer more complex than it already is, and importing more of this documentation mini-language into the analyzer. It seems like it would be nice if the documentation formatting/understanding part of the analyzer could be confined to an analyzer plugin so that theoretically multiple different plugins could be created for different documentation sub-languages (don't you want to write API docs in LaTeX or postscript? :-) ).
This extra dependency information seems a little different than the comments themselves, however, and more in the analyzer's wheelhouse to resolve. If you want to aggregate small tools or plugins instead of making the analyzer a monolith, it seems reasonable to provide the different symbol lookup namespaces to a documentation-formatting analyzer plugin as input rather than letting the plugin figure it out for itself from its own metadata.
Maybe a solution that would keep documentation parsing separate from the main analyzer while not involving the @docImport syntax would be to have the analyzer provide an API to plugins for resolving symbols using an alternative set of imports (if that doesn't already exist) after parsing the extra imports out of its own metadata format.

The /// @doc import syntax isn't horrible (although I'd prefer /// @import for brevity), and I can see the argument for "keeping it in dartdoc", but what it means is that the analyzer is going to need to parse and understand not only Dart, but also more and more of the documentation comments as if they were required to be in dartdoc format ...

Yeah this actually would be all implemented in the parser, just as doc comment references are parsed in the parser. The CFE (I imagine) just drops that stuff on the floor, but it does tokenize it, and we'd apply the same functionality to a doc import directive inside a comment.

Maybe a solution that would keep documentation parsing separate from the main analyzer while not involving the @docImport syntax would be to have the analyzer provide an API to plugins for resolving symbols using an alternative set of imports

I think would be very complicated. We don't provide any APIs for resolving elements.

Thinking and playing in the parser, I have some notes on the doc comment (/// @doc import) support:

Currently the Fasta tokenizer tokenizes single-line (/// or //) comments into individual lines: A 3-line doc comment like /// one\n/// two\n/// three\n is tokenized into 3 tokens: /// one\n, /// two\n, /// three\n. There are hooks (if my understanding is correct) for a front-end like analyzer to tokenize more tokens, which is how comment references are broken up into more tokens (analyzer's parseCommentReferences calls scanString to tokenize.
I think we'll need to tokenize doc imports in the same way. There is a benefit here in that the front_end will (I imagine) not bother tokenizing. Analyzer, on the other hand, can tokenize and parse a doc import.

One hiccup here is that a doc import should be able to extend over multiple lines, and the /// bits must be tokenized too:
/// @doc import 'package:foo/foo.dart'
///     as foo;
/// @doc import 'package:bar/bar.dart'
///     show
///       One,
///       Two,
///       Three;

I imagine we can tokenize the first one, as an example, into @doc import 'package:bar/bar.dart' /// show /// One, /// Two, /// Three; (modulo whether the little bits get their own tokens, like @ or ,, I'm not sure). Notice the /// tokens;  not sure how these will be encoded...
Regardless it means we probably cannot simply tokenize with scanString.

... modulo whether the little bits get their own tokens, like @ or ,, I'm not sure ...

If we're using the Scanner, which I think we should, then yes, they will be separate tokens, which is appropriate. We'd basically parse until we get to a ;. Of course, we'll need to decide what to do if we don't find a ; (or if there are other parsing errors in the imports).
It makes me wonder just how critical it is for doc imports to be able to extend across multiple lines (or have combinators, prefixes, or configurations, for that matter; I assume we won't support deferred).

Regardless it means we probably cannot simply tokenize with scanString.

We probably can, we'd just need to remove the leading ///s or *s first in order to not scan them as comments.

@yjbanov: I was thinking about this with @gspencergoog, and our latest idea is writing an annotation class in dart:ui and package:meta. They could both be named @docImport. The one in dart:ui does not need to be exported from any public library, so it can be "internal-only" (even @internal I suppose).
Analyzer can recognize both of the locations of @docImport and treat them identically, to improve doc comment references, and also first class support in the annotation itself. Meaning this code:
@docImport('package:flutter/foundation.dart', show: ['Widget', 'Elemet'])

can have IDE support:

hover and jump-to support on the URI
hover and jump-to support on 'Widget'
error reporting on 'Elemet' (typo)

etc.

our latest idea is writing an annotation class in dart:ui and package:meta. They could both be named @docImport. The one in dart:ui does not need to be exported from any public library, so it can be "internal-only" (even @internal I suppose).

Perhaps a can of worms, but sometimes when I use annotations the server recognises, they remind me of some things in .NET where it didn't matter where an Attribute was defined, only its name. This meant you could often avoid dependencies on extra libraries in your production code by just defining your own internal attribute with the same name.
I've often wondered if the same could work in Dart. For example if I made my own @deprecated and put it on a class, could I avoid needing package:meta? Things may get a little trickier when they have fields, but as long as the analyzer could read them and the rules are clear, maybe it could work?
Each time I see Flutter special cased somewhere, I wonder if someone wanted to make a "Flutter-like" framework, how many places they'd find they can't get the same functionality because of this. Are the reasons that Flutter can't use package:meta particular to Flutter, or might some other project have the same restrictions?
Btw, I'm curious if just using normal imports with some modifier, like as was considered. I suspect it's ruled out for the same reason as not putting the annotation in dart:core, but if this feature is going to have full IDE support for finding references, hovers, renames, etc., it will feel like a first-class Dart feature and having different two ways to "reference" files might feel a little odd.

For example if I made my own @deprecated and put it on a class, could I avoid needing package:meta?

Yeah that's nearly what I'm proposing, haha. I think in analyzer we only validate, for example, a @protected annotation if it is the protected const from package:meta, because package:meta is generally available everywhere (hold that thought), and so if some code generator or other defines their own @protected for their own reasons, we should keep our hands off it.

Are the reasons that Flutter can't use package:meta particular to Flutter, or might some other project have the same restrictions?

I'm not sure the technicalities behind it, but basically any dart: library, include "Flutter engine" (dart:ui), cannot reference a package library, like package:meta/meta.dart. @yjbanov actually mentioned that they do import package:meta for their dev cycle, but when the engine is published as dart:ui, all references to package:meta and the various annotations are stripped from the code. That doesn't help us in this case where we want to ship the engine with @docImport annotations intact.
I'm not even sure why the flutter engine is shipped as dart:ui, and not a package library, but I imagine there are good reasons. And if some 3rd party wanted to build their own platform on top of Dart, similar to Flutter, and they shipped their own dart:* library, then yes, they'd have the same problem ☹ .

Btw, I'm curious if just using normal imports with some modifier/annotation (@visibleForDocs?) was considered. ...

I think the general reason is that IDE support is not good enough to make something a language feature. If it's not even good enough a reason to add to dart:core, I don't see it making it into the language.

and so if some code generator or other defines their own @protected for their own reasons, we should keep our hands off it

Yeah, that's probably fair. I can't remember examples where I'd used this in .NET, but I think they were probably much more specific names than things like @protected so accidentally overlapping was probably much less likely.
Thanks for the extra info!

I'm coming into this conversation a little late, but the idea of using the @pragma annotation appeals to me.
@pragma('dartdoc:import', 'package:flutter/material.dart')

import 'dart:convert';
import 'dart:io';

import 'package:path/path.dart' as p;

...

it already exists in our core libraries
it's meant to be used for tooling
annotations are more parsable than custom conventions in code comments
the primary consumer here may not really be dartdoc, but the analyzer / linter / analysis server. Ideally linting and navigation (and code completion?) would be as aware of these auxillary imports, as much as dartdoc itself would be

If so, I'll have to remove the final from class pragma.

Wouldn't the pattern above be useful even if not used for DartDoc? I didn't know about pragma before, but it seems quite useful and I could imagine that wrapping it like that could be useful for other tools that want to use it.

FWIW, I was expecting checks to be on the name and thought the subclass was nice just for convenience of the user adding the annotation. If I create a tool FooTool and wanted people to use a pragma annotation, wouldn't it be more convenient for them to do:
@fooTool('xyz')

than:
@pragma('FooTool', 'xyz')

Both should work (FooTool should only check name), but the top one gets code completion with a nice dartdoc comment on the completion list explaining how to use it and what it does. The second gets no completion on the important string, and no documentation explaining the use.
(Note: I don't have any current use cases for pragma so is just me thinking out loud - this idea might be flawed in other ways :-) )

I had the impression that pragma was intended to be used to provide additional information to the compilers. I guess I assumed that the analyzer wouldn't be considered to be part of that use case. Perhaps that assumption was wrong.
Whichever way we implement doc imports we might want to consider adding tooling support for pragma, assuming that it's used often enough. If there's some metadata maintained somewhere about the valid values for the first argument, then we could provide code completion even within the string. If we have a complete list, we could provide a warning when the string isn't one of the valid options. If there were docs associated with the metadata, then we could display it in hover text.

For a flavor of how pragma's being used now, here are the unique uses in the sdk repo:
@pragma('dart2js:${annotation.name}')
@pragma('dart2js:${other.name}')
@pragma('dart2js:...')
@pragma('dart2js:<suffix>')
@pragma('dart2js:as:check')
@pragma('dart2js:as:trust')
@pragma('dart2js:assumeDynamic')
@pragma('dart2js:disable-inlining')
@pragma('dart2js:disableFinal')
@pragma('dart2js:downcast:check')
@pragma('dart2js:downcast:trust')
@pragma('dart2js:index-bounds:check')
@pragma('dart2js:index-bounds:trust')
@pragma('dart2js:late:check')
@pragma('dart2js:late:trust')
@pragma('dart2js:load-priority:high')
@pragma('dart2js:load-priority:high)
@pragma('dart2js:load-priority:normal')
@pragma('dart2js:load-priority:xxx')
@pragma('dart2js:never-inline')
@pragma('dart2js:noElision')
@pragma('dart2js:noInline')
@pragma('dart2js:noSideEffects')
@pragma('dart2js:noThrows')
@pragma('dart2js:parameter:check')
@pragma('dart2js:parameter:trust')
@pragma('dart2js:prefer-inline')
@pragma('dart2js:resource-identifer')
@pragma('dart2js:resource-identifier')
@pragma('dart2js:tryInline')
@pragma('dart2js:types:check')
@pragma('dart2js:types:trust')
@pragma('dart2js:unknown')
@pragma('flutter:keep-to-string-in-subtypes')
@pragma('m:never-inline')
@pragma('OtherTool:other-pragma')
@pragma('Tool:pragma-name',
@pragma('vm-test:can-be-smi')
@pragma('vm:entry-point')
@pragma('vm:entry-point',
@pragma('vm:entrypoint')
@pragma('vm:exact-result-type',
@pragma('vm:external-name',
@pragma('vm:external-name)` was identified.
@pragma('vm:ffi:native-assets',
@pragma('vm:invisible')
@pragma('vm:invisible)` was found.
@pragma('vm:isolate-unsendable')
@pragma('vm:never-inline')
@pragma('vm:non-nullable-result-type");
@pragma('vm:notify-debugger-on-exception')
@pragma('vm:prefer-inline')
@pragma('vm:testing.unsafe.trace-entrypoints-fn',
@pragma('vm:testing:match-inner-flow-graph',
@pragma('vm:testing:print-flow-graph')
@pragma('vm:testing:print-flow-graph',
@pragma('vm:testing:print-flow-graph'[,
@pragma('vm:unsafe:no-interrupts')
@pragma('wasm:entry-point')
@pragma('wasm:prefer-inline')
@pragma('weak-tearoff-reference')

The docs at https://api.dart.dev/stable/2.19.6/dart-core/pragma-class.html suggest to me that this is open for any tools to use (and that means the first string could really be anything). If it's intended to only be Dart SDK tools, it should probably be clearer. If not, I guess the strings could be anything (and having a subclass may add value as noted above?)

... here are the unique uses in the sdk repo:

A couple of those appear to be for tests ('OtherTool:other-pragma' and 'Tool:pragma-name'), but the rest match my previous understanding.

If not, I guess the strings could be anything ...

Which is, of course, the problem with strings. Any two tools could start using the same string and there'd be no way to know until it caused problems for one or more users. There's value is having namespaces, and from that perspective alone I'd rather define a unique annotation somewhere that we can easily uniquely identify.

If we really don't want to add DocImport to dart: and want to keep pragma final, my plan would be to implement this instead:
Add DocImport to two locations: the meta package, and the flutter engine. The one in the flutter engine would be used in the flutter engine, but not exported from dart:ui. It would hopefully just look like it was the same class as the one in the meta package. The definitions of the two classes would be subject to drift. Tools like the analyzer and dartdoc would recognize each class in annotations; analyzer could provide navigation, autocomplete, hover, etc. (but I don't anticipate this annotation being used in many locations, so not high priority).
This would support the primary use case, which is flutter engine. No code in the Dart SDK could use DocImport (obviously).

We can add a DocImport to the SDK platform libraries too, without exposing it. Then dart:ui could use that, I just don't want to export it from the platform libraries. (The @Since annotation is not exposed either. It predates pragma, otherwise it might not have existed.)
The pragma class was intended for individual platform tools, not just compilers, that processes the platform libraries to be able to add metadata to the platform libraries, without needing to first introduce new classes that everybody else would need to care about. A VM specific annotation would be fine in a VM-only patch file, but it's just noise if it has to be declared where every other tool has to parse it too. And while the platform libraries cannot depend on third-party libraries, we also want to avoid having too many dependencies in other SDK code as well.
The pragma design, that the first string should be "tool-name:meaning" and the second argument can be any supplemental data, if any, makes for an open namespace, but well-behaved annotations can be easily ignored by other tools than the one it's intended for. If two tools insist on having the same name ... well, they can fight it out.
And non-well-behaved annotations should just be ignore, and will never exist inside the SDK.
A @pragma('dartdoc:something', 'moredata') annotation is fine. It's rare that the platform libraries have special dart-doc needs (I think, but not unheard of), so there probably hasn't been as much demand for such an annotation.
A @pragma('dartfmt:ignore-file') annotation would make perfect sense for some of our syntax tests.

Looking entirely at dependencies, I'd prefer that a dart-doc import was inside the dart-doc itself, as // @import ...;.
That has zero dependencies on anything else, and I don't think dart-doc should have dependencies.
Having to import package:meta in order to not have to import another library still seems like missing the point.
It has to be parsed, but I'm sure that can be solved - trailing semicolons have a purpose.
If the analyzer also needs to know about the imports, then it too has to parse the doc-import. But it only needs to know about the imports because it parses doc-comments to begin with, so it's fair that it parses all of it.
If that's not acceptable, you can always add a declaration in package:meta.
If we want platform libraries to use it too, we can either add a separate declaration in dart:_internal (usable by dart:ui as well), or we can just tell platform libraries (including dart:ui) to use a pragma. Either works, and in both cases, it's a seprate class from the one in package:meta.

Looking entirely at dependencies, I'd prefer that a dart-doc import was inside the dart-doc itself, as // @import ...;.

I prefer this as well. I just would be a poor engineer choice to implement it (I tried and commented here). I was trying to be pragmatic about it in suggesting a much more simple (but I agree, less good) annotation.

Seems like it should be possible to filter a token-stream to include only the content of the doc-comment. After all, detecting comment-prefixes is how you know where the comment ends.
So, given a token stream of "///, more, more, \n, /// more, more, \n, class ...", the filtered token stream would be just "more, more, more, more".
I don't know how that'd work technically, if the same token can be part of two streams, but logically, passing tokens of the content of the comment into into the dart-doc parser seems like just the right thing to do. After all, the /// and * are not part of the documentation, they're just delimiters.

As I mentioned before (https://github.com/dart-lang/sdk/issues/50702#issuecomment-1370023433), scanning across multiple single-line comments isn't a problem. We trim the source of the comments to rescan only the portion between square brackets when dealing with doc references, and this wouldn't be any harder.

Here's an update on what's been implemented, as it's not quite what's specified at top, CC @kallentu:

We're going with a comment-based implementation instead of an annotation-based implementation. It looks like:
/// @docImport 'package:foo/foo.dart';
/// @docimport 'bar.dart' as bar show Bar;

These doc imports are attached to the Comment node, in the docImports field.

Doc imports are currently not found on a LibraryElement, but I think they'll need to be.

I have a pending CL that incorporates doc imports into the element model, FileState, and more.

Otherwise, I think the resolution steps specified up top, and the new errors that should be reported, are unchanged.

Doc imports are currently not found on a LibraryElement, but I think they'll need to be.

To clarify, are you talking about having the doc namespace available from the LibraryElement, or do you mean the actual imports (or both)?
I haven't compared closely, but are the rules for doc imports the same as for normal imports (modulo the namespace being computed), or are there some interesting differences?

when elements from a doc import have name conflicts with each other, or elements from imports with the same prefix

I believe that the rules for normal imports is that it's only an error if the conflicting name is actually referenced. I assume the same is true here.

I haven't compared closely, but are the rules for doc imports the same as for normal imports (modulo the namespace being computed), or are there some interesting differences?

Yes I think they're exactly the same.

I believe that the rules for normal imports is that it's only an error if the conflicting name is actually referenced. I assume the same is true here.

Ah yes, fair. True here as well.

@lrhn To complete this work, I think it would be consistent, simple and straightforward for the analyzer will start reporting "compile time errors" on doc-imports, the same that are reported for regular imports. WDYT of that?
For example, /// @docImport 'does-not-exist.dart'; will result in a compile-time error. Is this over-stepping our purview, or good for consistency? We could probably use "warnings" (previously, hints) that mirror such compile-time errors, if we should not actually be reporting compile-time error codes. Something like a dozen different errors can be raised on imports I think.

I'd be fine with reporting an invalid import as an error. I'd also make it an error to have a [Foo] where Foo cannot be resolved.
But I'm usually fine with breaking bad code. Others might be more cautious.
Might want an introductory period, maybe a single release, where it's only a warning with a message saying that in the next release it will become an error.
(I'm a little iffy about calling it a "compile-time error" for a tool that doesn't actually compile, but that's probably just idle pedantry. It's really a "doc-time error", where the analyzer is reporting that that the DartDoc tool will have an error here, just like a compile-time error is the analyzer reporting that a compiler will have an error. Or it's just "an error" because someone wanted to make something not be accepted, aka. lints).

Superceded by https://github.com/dart-lang/sdk/issues/56186, which includes the new syntax, a directive in doc comments, as implemented in the analyzer.


fix: delete bot bug

Description
The bug should already exist for months, but does not show up until recent change on file persistence layer.
Reason: 1. after deleting bots, the file persistence layer does another comparison and resends requests to delete files that are already deleted.
2. During deleting bots,it does another call to getBoilerplateVersion because of settings changed which is unnecessary.
Fix: 1. clear filePersistence state after deleting bots files.
2. split useEffect in RuntimeSetting to avoid interfere each other.
Task Item
Closes #6042
Screenshots
error request:

after fix:

Coverage decreased (-0.0002%) to 53.762% when pulling fd63fce0e1cbfa1a57c352b263a8ca3ff75e4375 on deleteBotBug into 2cd5aa98d9cccabe861a8fcf3159e92eeab959f0 on main.

Good analysis and clear description, thanks.


⚠ SkipTheCommericals has degraded performance

In d1e4253, SkipTheCommericals ($STC) experienced degraded performance:

HTTP code: 200
Response time: 1178 ms

Resolved: SkipTheCommericals performance has improved in d17c68d.


NuGet Publisher Tasks with additional option "ignore existing packages"

Let’s assume you have a TFS build process which produces 30 NuGet packages, each with its own package version.
29 packages are unchanged, just the contents of a single package has been changed, so the developer increases the version number for this package in AssemblyInfo.cs using the AssemblyInformationalVersion.
Other 29 packages are also produced with each build, because the build is configured to produce packages for all .csproj’s or .nuspec’s in the repository.
But as these 29 unchanged packages are not marked as “new” (no change at the package version), they should be ignored at publishing to the package feed.
Already existing package versions on the feed should never been touched again! There’s no overwrite allowed on the server feed. AllowOverwriteExistingPackages=false.
There should be definitely an option to ignore the packages during “nuget push” (in the VSTS/TFS NuGet Publisher Task by the way), when the packages with the same ID are already exist on the feed.
It should not abort to push on first “collision”, it should just ignore it when the option “AllowOverwriteExistingPackages” on the server is disabled.
In the scenario, this will result in just adding the single package which was really changed, the other 29 will be ignored and not pushed again. The Developer does not need to push a package by hand.

This is fixed in #4397


allow modal scrolling on small screen

Issue #:
https://github.com/bcgov/met-public/issues/1275
Description of changes:
changes made to allow scrolling on modal so that users can scroll down to access the verify email section
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #1282 (083f72c) into main (966b985) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1282   +/-   ##
=======================================
  Coverage   72.09%   72.09%
=======================================
  Files         303      303
  Lines        8498     8498
  Branches      599      599
=======================================
  Hits         6127     6127
  Misses       2278     2278
  Partials       93       93

Flag
Coverage Δ

metweb
66.65% <ø> (ø)

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

Impacted Files
Coverage Δ

met-web/src/components/common/index.tsx
90.00% <ø> (ø)


Update outdated WeaponModel hashes

I've updated some weapon hashes to their correct values.

thanks alot.


alt-tab-macos: 6.69.0 -> 6.70.1; alt-tab-macos: refactor updateScript

Description of changes

Updated from 6.69.0 to 6.70.1
Simplified and switch to a more generic updateScript

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[x] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 316521 run on aarch64-darwin 1

1 package built:

alt-tab-macos


Use enueration for policy items

@porridge it seems you have changed your email address on GitHub/commits? CLA bot says you have to sign CLA again.

@porridge  Any update on this PR? Please. Thanks!

@googlebot I signed it!


feat: Including add, remove and replace content

Hi there!
The goal here was adding some new methods: add, remove and replace content :)
Daniel Barros

No worries. Yes, they can be combined or living together. Your call. Happy to join them


Wallet Database Size Logger

Log the size of the issuer/verifier wallet database to the console.

https://github.com/My-DIGI-ID/aries-cloudagent-loadgenerator/commit/1cd3fe932aba950e9dc227a814ebaac94d73d72f


Brightlayer UI migration

Fixes PXBLUE-2534.

Changes proposed in this Pull Request:

Changes all pxblue references to brightlayer-ui
Publishes v2.1.0-beta.0

Don't merge this until the npm token is updated!


navbar: Use location.href instead of location.replace.

As per https://stackoverflow.com/questions/1865837/ location.href
should be preferred to location.replace in some places due to the
fact that location.replace violates browser history and breaks back key.

There were other locations that used .replace but it does not seem to make sense to change them. (manually tested the one that was spoken about last time we tried this)
Testing Plan:
GIFs or Screenshots:

Looks great, merged, thanks @YashRE42!


Markers only works for the first line series

How to reproduce
Run the following code in a preview. When tapping around in the chart, markers are only shown for the first series. Changing the order of the two series changes which one shows markers. This started happening in alpha 15, 14 worked as expected. I might be missing some change needed for alpha 15 but I couldn't find anything obvious from the release notes.
import androidx.compose.runtime.Composable
import androidx.compose.runtime.remember
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.tooling.preview.Preview
import androidx.compose.ui.unit.dp
import com.patrykandpatrick.vico.compose.cartesian.CartesianChartHost
import com.patrykandpatrick.vico.compose.cartesian.layer.rememberLineCartesianLayer
import com.patrykandpatrick.vico.compose.cartesian.rememberCartesianChart
import com.patrykandpatrick.vico.compose.common.component.rememberShapeComponent
import com.patrykandpatrick.vico.compose.common.component.rememberTextComponent
import com.patrykandpatrick.vico.compose.common.shader.color
import com.patrykandpatrick.vico.core.cartesian.data.CartesianChartModel
import com.patrykandpatrick.vico.core.cartesian.data.LineCartesianLayerModel
import com.patrykandpatrick.vico.core.cartesian.layer.LineCartesianLayer
import com.patrykandpatrick.vico.core.cartesian.marker.DefaultCartesianMarker
import com.patrykandpatrick.vico.core.common.component.ShapeComponent
import com.patrykandpatrick.vico.core.common.shader.DynamicShader
import com.patrykandpatrick.vico.core.common.shape.Shape

data class MyEntry(val x: Float, val y: Float)

@Composable
fun rememberMyLineSpec(color: Color): LineCartesianLayer.LineSpec {
    return remember(color) {
        LineCartesianLayer.LineSpec(
            shader = DynamicShader.color(color),
            point = ShapeComponent(shape = Shape.Pill, strokeWidthDp = 4f)
        )
    }
}

@Composable
private fun rememberMyMarker(): DefaultCartesianMarker {
    val label = rememberTextComponent()
    val indicator = rememberShapeComponent(Shape.Pill, strokeWidth = 8.dp, strokeColor = Color.Magenta)

    return remember {
        val marker = DefaultCartesianMarker(
            label = label,
            labelPosition = DefaultCartesianMarker.LabelPosition.Top,
            indicator = indicator,
        )
        marker
    }
}

@Composable
fun MyChart(
    entries1: List<MyEntry>,
    entries2: List<MyEntry>,
) {
    val chartModel = remember(entries1, entries2) {
        val model = CartesianChartModel(
            models = listOf(
                LineCartesianLayerModel.build {
                    // NOTE: Only the first series gets markers. If we change the
                    // order here, markers work for entries2 instead.
                    series(x = entries1.map { it.x }, y = entries1.map { it.y })
                    series(x = entries2.map { it.x }, y = entries2.map { it.y })
                },
            ),
        )
        model
    }

    CartesianChartHost(
        chart = rememberCartesianChart(
            rememberLineCartesianLayer(
                lines = listOfNotNull(
                    rememberMyLineSpec(color = Color.Blue),
                    rememberMyLineSpec(color = Color.Red),
                ),
            ),
        ),
        model = chartModel,
        marker = rememberMyMarker(),
    )
}

@Preview(widthDp = 300)
@Composable
fun MarkerProblemPreview() {
    val entries1 = listOf(
        MyEntry(0f, 0.2f),
        MyEntry(2f, 0.1f),
        MyEntry(4f, 0.3f),
    )
    val entries2 = listOf(
        MyEntry(1f, 0.2f),
        MyEntry(3f, 0.3f),
        MyEntry(5f, 0.2f),
    )

    MyChart(entries1 = entries1, entries2 = entries2)
}

Observed behavior
Markers are only shown for the first series.
Expected behavior
Markers are shown for all series.
Vico version(s)
Latest unstable version
Android version(s)
14
Additional information
Just a general comment, the latest rounds of cleanups look very good :) I'm looking forward to 2.0.0!

Hello! Thanks for the report and the kind words. Your implementation looks good—this is a bug on our end. We’ll look into it.

Vico 2.0.0 Alpha 16 resolves this. Cheers! By the way, I wanted to let you know about two functions that, judging by the sample code, you may not be aware of: rememberLineSpec and rememberDefaultCartesianMarker.


Dynamic analysis failures in itkImageFileWriterStreamingTest1 and itkImageFileWriterPastingTest2

Description
Valgrind has been consistently reporting failures for the following IO tests:
itkImageFileWriterStreamingTest1_3
itkImageFileWriterPastingTest2_7
itkImageFileWriterPastingTest2_6
itkImageFileWriterStreamingTest1_2

See for example the latest report:
https://open.cdash.org/viewDynamicAnalysisFile.php?id=8822872
Steps to Reproduce

Clone ITK master
Configure and build with the BULD_TESTING flag to ON.
Run Valgrind on the ImageBase IO module.

Otherwise, see the error report submitted to CDash linked above.
Expected behavior
No dynamic analysis errors should be expected.
Actual behavior
Valgrind is reporting an invalid syscall parrameter failure:
PAR ==80018== Syscall param ioctl(generic) points to unaddressable byte(s)
==80018==    at 0x649250B: ioctl (syscall-template.S:78)
==80018==    by 0x52AC63E: itksys::SystemTools::CloneFileContent(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (SystemTools.cxx:2399)
==80018==    by 0x52AC8D7: itksys::SystemTools::CopyFileAlways(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) (SystemTools.cxx:2456)
==80018==    by 0x52ACA55: itksys::SystemTools::CopyAFile(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool) (SystemTools.cxx:2475)
==80018==    by 0x2CE509: itkImageFileWriterPastingTest2(int, char**) (itkImageFileWriterPastingTest2.cxx:75)
==80018==    by 0x1BBDE7: main (ITKIOImageBaseTestDriver.cxx:317)
==80018==  Address 0x5 is not stack'd, malloc'd or (recently) free'd

that traces back to this line
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/KWSys/src/KWSys/SystemTools.cxx#L2399
So it looks like the error lies in the KWSys/SystemTools.cxx file:
https://gitlab.kitware.com/utils/kwsys/-/tree/master
Reproducibility
100%.
Versions
ITK master.
Environment
The CDash submitted report is on a Ubuntu 20.04 machine.
Additional Information
None.

The Valgrind build was changed to ubuntu. The old Centos has a suppression for this, but the function name mangling of the SystemTools methods no longer match.
The suppression file needs to be updated.

Looks like after PRs #2842 and #2851 got merged the mentioned tests no longer report dynamic analysis failures:
https://open.cdash.org/viewDynamicAnalysis.php?buildid=7551290
Today's is the first build with both patch sets, so if they are not listed in the analyses for the next few days I think we can consider the issue as solved.
Thanks @blowekamp and @bradking .

Let's close now, and if the problem is not solved we can reopen.


Added Match class and solved #24.

Discuss.
(#24)

Heh, I'm too hasty. This DOESN'T work in all cases, DON'T MERGE. I'll update later and let you know.

I don't get it :-/ It mostly works correctly, but after I click on "End round", the button disappears.
I checked, though, and the button's condition (<a v-if="match.isRunning" ...) is true after I click it. I don't understand at all why the button disappears.

Now it works!

This looks really neat! I had no idea about many of the tricks in here, but they look super and they make sense. I had no idea we could do get ... and set ... stuff in JS!
I've just woken up and I'll take a closer look after a shower and a cup of tea, but initially this looks merge:able! Great job, man!

Glad you like it! :D

I've taken a further look now. Wasn't exactly shortly after my shower, but hey!
This is great! Now I have a good idea of what needs to be done to modernize the code. That is, if you don't want to spearhead that little project! If you want, we can make a new issue about that and you can work on making the js make more sense?

I'd love to! I don't know how consistent I will be with time, though. I can try to work a little bit more and see how well it works, OK?

So, make an issue and assign it to me, and we'll see where it leads.


OCI Integration

OCI integration based on reactive WebClient.
Integrates OCI Object Storage, Vault (including secrets, encryption, signatures) and adding metrics (Telemetry).
Resolves #2416

Fixed and rebased on master.


The indicator icon is lost in Ubuntu 14.04 in 0.6.3 version

Hi Simon!
After updating to 0.6.3 version in Ubuntu 14.04, the indicator icon changed into a question mark.
I found at indicator.vala @ line 87 that the icon is tried to be loaded from the "resources" directory (that didn't exist in my pc).
It might be a regression from commit (force full path for appindicator icon) 528443135a180b098dd1ce913f98369a1c4c43c0.
I manually copied "gnome-pie-symbolic.svg" to /usr/bin/resources and the icon was back.
I also recompile the code from source and the same happened: I have to copy the icon to /usr/local/bin/resources to solve the issue ("make install" put the icon in "hicolor" icon directory).
Best regards,
Gabriel

Oh, I see. The icon was in this directory on my system due to previous tests. I'll fix this asap. Thank you!

As of commit e7b62fec0166fae5bb433c78c7d4237c81f592e4 it should work again. Can you confirm this?
I'm wondering whether Gnome-Pie should have a status icon in future. Gtk.StatusIcon is deprecated (https://bugzilla.gnome.org/show_bug.cgi?id=734826), and Gnome Shell will have no message tray at all. AppIndicators are Ubuntu-only. This fragmentation is aweful...

Yes, now works again!
BTW, I'm using Numix-circle icons and the Numix version of the icon has return to the notification area.
You are write about fragmentation. One of the biggest problems I see with having so many desktops in Linux.
I once added a context menu for the pies in the launcher (to edit that pie directly) and came across this bug: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1242255
so I removed it. Unity is going to be completely replaced with version 8 so no much love is going to version 7....


Fixed issue with RecyclerView instructions.

The SlideInEffect should be set on the JazzyRecyclerViewScrollListener not the RecyclerView
setOnScrollListener() has been deprecated on RecyclerView in favour of addOnScrollListener()

+1


Using the @request macro in the Bank Renege example

First I'd like to say thanks for the very useful package!
I'm trying to follow along with the bank renege example from the documentation but it looks like that example code is a little behind the stable release (e.g., @Process vs @process). Once I fix those I get an error when the Request() block runs. I saw in some other comments that you're working on the documentation but I was wondering if you could point me to some more info on the @request macro (or if I should be using Request() ).
Thanks!

Hi
Sorry for the limited documentation;)
You can look at processes_MM1.jl to have an example with processes (Julia Tasks) and the request do construct or you can look at coroutines_MM1.jl for coroutines and the @request macro.
Replacing Process with process and Request with request would normally do the trick.
Kind regards
Ben

Thanks for the pointers!


Allow RMM to save/restore SME for NS world

Currently the EL3 firmware is not allowed to enable FEAT_SME when RME is present. This is because RMM does not do the required save and restore of NS SME context when scheduling Realm. This issue is to implement this capability in RMM.

The patches are available here for review : https://review.trustedfirmware.org/q/topic:"rmm_sme"+(project:TF-RMM%252Ftf-rmm)


Rendering Issue

Versions

Python: 3.6.4
OS: Windows 10 Build 16299.309
Kivy: 1.10.0
Kivy installation method: pip

Description
I recently installed Kivy & immediately noticed an issue in the KivyMD Kitchen Sink demo.  UI components have a glitchy appearance.

I also experienced this issue in a basic ScreenManager implementation. The first screen works as expected, but as soon as any subsequent screens are loaded, the issue appears.

Code and Logs
https://gist.github.com/toldham7/e79d36d7fde0d8576f30a24b8f827a78

@bionoid  Just tried it, didn't seem to fix the issue.

Can you try with a 100% zoom level in windows? we might still have issues with that.


Fails to install babel

 $ nixfromnpm -p babel%5.8.23 -otest --no-cache

yields:
Failed to generate expressions for 2 downstream dependencies.
<EMAIL_ADDRESS><15001.1002.0
   Dependency of:
<EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>Failed to build because: NoMatchingVersion >=15001.1001.0-dev-harmony-fb <15001.1002.0
<EMAIL_ADDRESS><1.1.0
   Dependency of:
<EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>-><EMAIL_ADDRESS>Failed to build because: NoMatchingVersion >=1.0.0-rc3 <1.1.0
Package<EMAIL_ADDRESS>built successfully.

Can you give me any pointers on how to solve this ?

So the docs for this are not in this repo (which they should be) but [here[(https://github.com/adnelson/nix-node-packages#if-a-package-doesnt-build). Hopefully this helps. Most of the issues fetching packages have to do with my incomplete implementation of the semver spec. :(

@adnelson thanks for your response. I followed those instructions but somehow it did not really work out:
https://github.com/gilligan/nixfromnpm-test
% nix-shell
error: anonymous function at /Users/tpflug/Development/nix/nodejs-testing/test/nodeLib/buildNodePackage.nix:1:1 called without required argument ‘nodejsSources’, at /Users/tpflug
/Development/nix/nodejs-testing/test/nodeLib/default.nix:80:22

The master branch has the versioning fixes whereas the unfixed branch is with the broken packages still. I did not make any changes beyond those but ran into the error above. Do you have any idea what is going on here ?

Hey, sorry I was out yesterday. So I'd been doing some dev on the nix library part of this project, but I'm not sure it's all merged so it might be slightly inconsistent. I'll try to take a look today and get everything back into stability...

@adnelson that would be so great. I was really glad to find your project because npm2nix is just not a viable solution. Now i really hope that I can actually pull this off with nixfromnpm ;)
so i have my fingers crossed ;)

No problem! Hopefully I'll be able to get this all nailed down very soon. In the meantime, if you're just trying to get a working nix expression for Babel, there's already one in the nix-node-packages repo, so the quickest way would be just
git clone https://github.com/adnelson/nix-node-packages
nix-build nix-node-packages -A nodePackages.babel

@adnelson thanks but it's not the right version plus i am working on "nixifying" a bigger project so that is only one part of it anyway.. ;)

OK, so I pushed some changes that should fix this. I was able to use the nixfromnpm that got built to make an expression for babel (at version 6.5.2 but idk what you needed) which built successfully.
One of these changes was to use git submodules instead of relying on the user to check out the two repos we're depending on.   This is in the README now.
I'm happy to make these changes because of course the tool should work, but I'd still encourage you to use the nix-node-packages repo. Using that repo means that packages you might need in the future (and/or their dependencies) will be likely to already be defined, and also that bug fixes will be available. If you need a version of a package which isn't in the repo you can still use nixfromnpm to add it. Really the only reason IMO to avoid it is code size, which isn't usually an issue because nix code isn't typically deployed anywhere. If you have private packages you're trying to define with nix, you have a few options: you can fork nix-node-packages, or use the --extend option to put the private packages in their own folder.
Of course, there's nothing wrong with just starting from scratch :smile:
Please reopen this if things don't work.


The SelectField should focus after selecting an option so that users can navigate through a form with keyboard.

Feature Request:
The SelectField works nicely while using the keyboard navigation to select an option. But after an option is selected, the field is no longer focused. Users cannot Tab to the next field in the form as experienced when using a native <select> field. I almost labelled this as a bug since a user would expect this functionality in a form, but I'll change to Feature Request for now.

This would be great! Any update on this?

We have been porting the component on the v1-beta branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.
Still, we will accept PR fixes until v1-beta takes over the master branch.


Auto update colorschemes with base16-builder-go

Add feature to automatically build themes every week via a github action. If a new scheme is added to the schemes repo, this change will be automatically added and committed to the repo.

Add codeowners file to automatically tag the putty maintainers whenever a new PR or issue is created.
Move "rebuild" section into "contribution" section of the readme since there is no reason to rebuild unless someone is contributing.
Adjust readme slightly to reflect that it's now an organization repo and not a personal repo.

Note: I've done one more rebase on the main branch (so make sure to update your local branch with a git reset --hard origin/main or something similar). I've included the original commits from https://github.com/staticaland/base16-putty. It's also why I removed the reference from the readme.

A thanks is definitely necessary if someone has taken their code and there isn't any history of it left, but I've included staticland's repo as part of this project's history so everything we do is built on top of that: https://github.com/base16-project/base16-putty/commit/4ad8133e38649fcbc932b649add45b123bf3cfeb - We also have benjojo in the history, who initially created this repo.
Chris is thanked as part of base16-project: https://github.com/base16-project/home#all-your-themes-everywhere-
Regarding base16-mintty, I may not be understanding it correct but are you thanking them for learning how to use the base16-builder and templates?

A thanks is definitely necessary if someone has taken their code and there isn't any history of it left ...

I was thinking more about expressing gratitude to the people that made the work possible and less about the attribution of the work. Thanking is never too much 😄.

Regarding base16-mintty, I may not be understanding it correct but are you thanking them for learning how to use the base16-builder and templates?

It is not about templates, but rather the information mapping the base16 colors (base01, base02, ...) into the closest semantic equivalent ANSI colour name (after that I was able to map it into the Putty reg keys).

:+1: I added the "Thanks" section in before merging


Questions about dft.numint.eval_rho()

Thanks for effort of PySCF team.
Recently, I've been trying to plot Density in realspace using the numint.eval_rho() function.
While plotting the density of He atoms, I noticed something strange.
I got the density matrix calculated with 100%PBE, 50%PBE and no XC and plotted the density on one axis with the functions numint.eval_ao and numint.eval_rho.
mol = gto.M(
atom = """
He
""",
basis = 'augccpvtz'
)

mydft1 = dft.RKS(mol).density_fit()
mydft1.xc = 'PBE'
mydft1.grids.level = 9
mydft1.kernel()
dm1 = mydft1.make_rdm1()

mydft2 = dft.RKS(mol).density_fit()
mydft2.xc = '.5*PBE'
mydft2.grids.level = 9
mydft2.kernel()
dm2 = mydft2.make_rdm1()

mydft3 = dft.RKS(mol).density_fit()
mydft3.xc = ''
mydft3.grids.level = 9
mydft3.kernel()
dm3 = mydft3.make_rdm1()

def gen_coords_x(z_min, z_max, n_points):
    z = np.linspace(z_min, z_max, n_points)
    coords = np.zeros([z.shape[0], 3])
    coords[:, 0] = z
    return coords

x = gen_coords_x(-5,5,1001)

ao_x = numint.eval_ao(mol, x, deriv=0)
rho1_x = numint.eval_rho(mol, ao_x, dm1)
rho2_x = numint.eval_rho(mol, ao_x, dm2)
rho3_x = numint.eval_rho(mol, ao_x, dm3)

plt.plot(x[:,0], rho1_x, label = '100% PBE')
plt.plot(x[:,0], rho2_x, label = '50% PBE')
plt.plot(x[:,0], rho3_x, label = '0% PBE (0% XC)')
plt.xlim(-2,2)
plt.legend()
plt.show()

As you can see in the graph, the peak of density varies depending on the percentage of PBE.
I thought that when I integrated the density without XC over the whole space, the number of electrons coming out would seem insufficient compared to the density with 100% PBE. So I used the code below to compare the values.
coords = mydft1.grids.coords
weights = mydft1.grids.weights

ao = numint.eval_ao(mol, coords)
rho1 = numint.eval_rho(mol, ao, dm1)
rho2 = numint.eval_rho(mol, ao, dm2)
rho3 = numint.eval_rho(mol, ao, dm3)

print('PBE      ',np.einsum('r,r', rho1, weights))
print('50% PBE  ',np.einsum('r,r', rho2, weights))
print('0% XC    ',np.einsum('r,r', rho3, weights))

Functional
# of electrons

PBE
1.999999997180982

50% PBE
1.9999999665640233

0% XC
1.9999998137042763

Results show that the integral decreases as the percentage of XC decreases.
I'm wondering if this is natural, or if there's something wrong with my code.

Thank you for your detailed response.
I understand that increasing the grid size to a larger one will further reduce the difference in electron count.

Nevertheless, the graph looks very unnatural, as if the amount of density itself decreases as the fraction of PBEs decreases.
Is there anything you can tell me about this?

Explanation was already above.

The only reason it looks unnatural is that human eyes cannot see on the graph the regions where the green curve is higher than the orange and blue curves. There must be such regions, since the density integrates to the same number to within numerical tolerance. There is nothing prima facie wrong with different functionals having different opinions on how tightly the density is localized around the nucleus.

@susilehtola @MatthewRHermes
Thanks. I checked the entire space and found that there was no problem.


Day58

Resolves #127 .

Pull Request Test Coverage Report for Build 274

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 100.0%

Totals

Change from base Build 269:
0.0%

Covered Lines:
24

Relevant Lines:
24

💛  - Coveralls

Pull Request Test Coverage Report for Build 271

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 100.0%

Totals

Change from base Build 269:
0.0%

Covered Lines:
24

Relevant Lines:
24

💛  - Coveralls


Unable to get any response from OKHTTP [Feature Request]

I am trying to make an asynchronous call to an API using OKHTTP. This is the API end point:
https://api.projectoxford.ai/luis/v1/application?id=b0d5b503-eb2e-460a-b028-a3223aa93227&subscription-key=bc1cb297a94f4c9a9b58bcd36280466c&q=start%20test . The API belongs to Microsoft and I checked with multiple API testing tools to make sure the API is working fine.
However, I am unable to get any response from OKHTTP, this is my code :

private void doGetRequest(String url) throws IOException
    {
        OkHttpClient client = new OkHttpClient();
        Request request = new Request.Builder()
                .url(url)
                .build();

        Log.e("TWING","I am here");

        client.newCall(request)
                .enqueue(new Callback() {
                    @Override
                    public void onFailure(final Call call, IOException e)
                    {
                        Log.e("TWING","Error");
                        // Error

                    }

                    @Override
                    public void onResponse(Call call, final Response response) throws IOException {
                        String res = response.body().string();

                        Log.e("SWE",""+res);
                    }
                });
    }

I do not get either a response in onResponse() or in onFailure() . What is possibly causing this? Any way to fix this?

http://stackoverflow.com/questions/39982714/unable-to-get-any-response-from-okhttp-for-specific-api-possible-cause


ALP4.3

Hi, thank you for sharing such a great toolbox! While it works nicely with the ALP4.1 and ALP4.2, I wasn't able to directly apply it to the ALP-4.3. May I ask what modifications I'll have to make in the code to make it compatiable with the ALP4.3 version? Thank you in advance!

Hi, Alex
Did you figure out how to handle the ALP-4.3? I am working on it too.


avoid unnecessary String.format calls in IdUtils.validateId

Based on profiling data, about 25% of the time de-serializing DataSchema
is spent on formatting strings in validateId.
This can add up quickly, especially when de-serializing task information
in the overlord, where in can consume almost 2% of CPU if there are many
tasks.
Since the formatting is unnecessary unless the checks fail, we can
leverage the built-in formatting of Preconditions.checkArgument instead
to avoid the cost.

sorry, merged this by mistake before waiting for tests.


Install elm graphql

@ostcar If you have some time, pls check out this branch, run server and try to add a new event or day to a campaign. Server sends graphql error and complains about datatype of the ID. The elm-graphql lib sends a string, but the server does not accept. Maybe there is a missconfiguration somewhere, because I only use the lib now an do not manually parse from ID to string. See
https://github.com/normanjaeckel/Meier/blob/InstallElmGraphql/client/src/NewDay.elm#L62

@ostcar Maybe you want to add some tests with some http requests with graphql requests to test this api.

@ostcar If you have some time, pls check out this branch, run server and try to add a new event or day to a campaign. Server sends graphql error and complains about datatype of the ID. The elm-graphql lib sends a string, but the server does not accept. Maybe there is a missconfiguration somewhere, because I only use the lib now an do not manually parse from ID to string. See
https://github.com/normanjaeckel/Meier/blob/InstallElmGraphql/client/src/NewDay.elm#L62

The GraphQL specification does not define, what an ID-Type actually is. Most APIs probably use string, but it is allowed to use something else. I used 'int' on the server. I would expect the elm-lib to have some sort of config, to define the type.
I am not 100% sure, but it seems, you can do this with the argument --scalar-codecs: https://github.com/dillonkearns/elm-graphql/blob/3f9ccbedd879d6e564fe7728cd4cda0bf9d399b0/package.json#L15
It seems, that you then can have a file to define your own types, like here: https://github.com/dillonkearns/elm-graphql/blob/3f9ccbedd879d6e564fe7728cd4cda0bf9d399b0/examples/src/CustomScalarCodecs.elm#L9-L10
He kind of explains this here: https://incrementalelm.com/scalar-codecs-tutorial/

Is it possible with the elm-gen-tool to give the module another name then "CustomScalarCodecs"? The name is misleading.
Custom scalars is a fix term in GraphQL: https://www.apollographql.com/docs/apollo-server/schema/custom-scalars/  or https://graphql.org/learn/schema/#scalar-types

The GraphQL specification includes default scalar types Int, Float, String, Boolean, and ID. Although these scalars cover the majority of use cases, some applications need to support other atomic data types (such as Date) or add validation to an existing type. To enable this, you can define custom scalar types.

So it is strange to add a module CustomScalar that contains a definition for ID. ID is not a custom scalar.

I changed it to "IdScalarCodecs" but I would be ok for me to change it again, if you have a better proposal.


Full Horizontal Scroll

I know this is an issue with UICollectionView and not your Layout, but is there a way to use horizontal scroll with your layout and get the data to show up like this:
[0] [1] [2] | [6] [7] [8]
[3] [4] [5] | [9]
instead of:
[0] [2] [4] | [6] [8]
[1] [3] [5] | [7] [9]

Hi,
You might be able to do that with sections, but as you say this layout orders the cells top to bottom in the horizontal layout.
The only thing I could suggest would be to order your data source into sections in the order you want, but I'm not entirely sure if that'll help you as you'll get the 2x2 at the end like you put above.
I think you'll have to work on your own layout from scratch I'm afraid.
Cheers,
Rich

But I do like the idea, having a left-to-right ordering as well as top-to-bottom option. I'll see how easy it is to add and put it in. Though this won't be for a while, but hopefully before the end of the year!

@rhodgkins Is any progress on this layout?


Shader fix for mame-rgb-3x vertical like waves effect over 1080p

I've tested this shader/overlay? works perfect when the TV display is set to 720p but in 1080p where a vertical waves effect appears. I ve found the source image here in the repository for "mame-rgb-3x" resolution is 960x720 . Not being familiar with this I suggest other shader/overlay? for every standard display resolution like 720p(already exists), 1080p, 1440p, 2160p(4K) and other for the rare ones 800p(Steamdeck), 1600p.

I'm closing this, I mismatched an overlay and a shader, I maybe open an issue with the actual shader but It seems the right behaviour of the shaders don't go futher of different resolutions, so most of shaders are distorted over different resolutions.


FilteredQuery: chain multiple filters with and by default

Fixes #254

Thanks @ralph, merged and pushed.
One note: could be fun, sometimes in the future, if the filtered method (and the corresponding FilteredQuery class) took some options, where the user could specify if she wants and or or chain?


[Bug]: MongoDB: There is no mention of connection string URI on the datasource page if the "Use Mongo Connection String URI" is Yes

Is there an existing issue for this?

[X] I have searched the existing issues

Description
MongoDB: There is no mention of connection string URI on the datasource page if the "Use Mongo Connection String URI" is Yes after the user has configured a different value for some other env through manage env
Steps To Reproduce
Steps:

create a mongo datasource
go to manage env and add a connection string URI for other env
Bind values
Observe - On the datasource details page, there is no mention of the connection string URI

Public Sample App
No response
Issue video log
No response
Version
Release v1.9.5

Related to #20165

@ayushpahwa  - but if the user cannot see the connection string on this page, how does the user know about the connection string entered? @sribalajig ?

Will be fixed with #20165


sign up ShuaoZhang

Since the PR is not updated for too long, it is temporarily closed. If you want to continue to participate in Startrek, please apply again.


Sbt Run successfull and app gets started but when I try to load the app it fails

Hi all,
I've installed all dependencies and I ran sbt run. app started but when I check the URL, it give me "Java Heap Space" message and thats all it does.
I'm trying to increase the JVM heap space but not sure how to change for this app. Please help. Thanks

@CaRthY5532 we are currently using the following JAVA_OPTS settings in Heroku. -Xmx768m -Xss512k -XX:+UseCompressedOops. Something in those lines should work.

Locally I have this:
workspace/scala-exercises/site sbt -v                                  rr-enforce-www :: 0h26m :: ⬡
[process_args] java_version = '1.8.0_01-Ubuntu'
# Executing command line:
java
-Xms2048m
-Xmx2048m
-XX:ReservedCodeCacheSize=256m
-XX:MaxMetaspaceSize=512m
-jar
/usr/share/sbt-launcher-packaging/bin/sbt-launch.jar

Keep in mind that locally play has to compile an use a lot of memory for live reloading


@Timed, @Metered & @ExceptionMetered defined per Resource

I noticed that the mentioned annotations, are defined with target contexts:
@Target({ ElementType.TYPE, ElementType.CONSTRUCTOR, ElementType.METHOD, ElementType.ANNOTATION_TYPE })

but they are effective only when defined at method level - as the InstrumentedResourceMethodApplicationListener#registerMetricsForModel method is registering only those.
Since at our company we're often marking every resource method with either @Timed or @Metered then we thought that it would be great if you could declare it per class (Resource) level -
so instead of declaring each method as @Timed:
@Path("/")
@Produces(MediaType.TEXT_PLAIN)
public class InstrumentedResource {
    @GET
    @Timed
    @Path("/timed")
    public String timed() {
        return "yay";
    }

    @GET
    @Timed
    @Path("/timed2")
    public String timed2() {
        return "yay";
    }
}

you could declare it on a class (Resource) level, like that:
@Timed
@Path("/")
@Produces(MediaType.TEXT_PLAIN)
public class InstrumentedResource {
    @GET
    @Path("/timed")
    public String timed() {
        return "yay";
    }

    @GET
    @Path("/timed2")
    public String timed2() {
        return "yay";
    }
}

Do you think that this is reasonable ? I would like to contribute my changes, if you find it useful.

If you use my alternate jersey2 integration, it's easy to do that, or any other policy (e.g. "methods that end in the letter Q", or whatever you want): https://bitbucket.org/marshallpierce/jersey2-metrics

I added those additional target types somewhat recently in order to support other developers that may wish to implement that functionality (ahem… @marshallpierce).
That having been said, I would like to add support for that to all the first-party modules. It's lower on my list of priorities, but if you submitted a pull request it would be gladly accepted.

thanks @ryantenney - I'll post a PR today.

@ryantenney a little bit later than originally planned, but here it is: https://github.com/dropwizard/metrics/pull/920
Could you please have a look, whenever you'll have time ?

Hi @ryantenney, I am using metrics-core 3.1.0 for jmx reporting but unable to see @Timed working at resource level. Can you tell me which version supports @Timed at resource level?


Increment versions for hardwaresecuritymodules releases

Increment package versions for hardwaresecuritymodules releases

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


Signatures rarely work out of the box

I've been getting started with DSPy and have struggled with even the most basic of signatures, even the examples in the docs often fail across LLMs with the default prompt often returning extra, unwanted responses in the output.
I wrote a small script that tests some of the more common LLMs and here's an example of the output:

Testing on gpt_4
LLM Test: ✅ Looking good
Testing on claude_35
LLM Test: ❌ LLM did not respond as expected: Expected "Positive", got
Here's the sentiment analysis for the given sentence:

Sentence: it's a charming and often affecting journey.
Sentiment: Positive

The sentence expresses a favorable opinion about a journey, describing it as "charming" and "affecting," which are both positive descriptors. This indicates an overall positive sentiment towards the subject.

Testing on llama70b
LLM Test: ✅ Looking good
Testing on llama8b
LLM Test: ❌ LLM did not respond as expected: Expected "Positive", got
The sentiment of the sentence is positive.

Testing on claude_3_haiku
LLM Test: ❌ LLM did not respond as expected: Expected "Positive", got
Sentence: it's a charming and often affecting journey.
Sentiment: Positive

Here's the script:
# -------------------------
# Setup Environment
# %pip install dspy-ai==2.4.9 boto3

# Check creds have been properly set
import os
def obsfucate(var):
    return f"{var[:4]}{'*' * (len(var) - 4)}"

def check_env_vars():
    aws_vars = ['OPENAI_API_KEY', 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY', 'AWS_SESSION_TOKEN']
    for var in aws_vars:
        value = os.environ.get(var)
        if value:
            print(f"{var} is set. Value: {obsfucate(value)}")
        else:
            print(f"{var} is not set.")

check_env_vars()

# Check the version of dspy running
from importlib.metadata import version
version("dspy-ai")

# -------------------------
# Define LLMs
import dspy

aws_provider_ue1 = dspy.Bedrock(region_name="us-east-1")
aws_provider_uw2 = dspy.Bedrock(region_name="us-west-2")

llms = {
   "gpt_4": dspy.OpenAI(
      model='gpt-4',
      max_tokens=1000,
      api_key=os.environ.get('OPENAI_API_KEY')
    ),
    "claude_35": dspy.AWSAnthropic(
        aws_provider=aws_provider_ue1,
        model="anthropic.claude-3-5-sonnet-20240620-v1:0",
    ),
    "llama70b":  dspy.AWSMeta(
        aws_provider=aws_provider_uw2,
        model="meta.llama3-70b-instruct-v1:0",
        max_tokens=1000,
    ),
    "llama8b":  dspy.AWSMeta(
        aws_provider=aws_provider_uw2,
        model="meta.llama3-8b-instruct-v1:0",
        max_tokens=1000,
    ),
    "claude_3_haiku": dspy.AWSAnthropic(
        aws_provider=aws_provider_uw2,
        model="anthropic.claude-3-haiku-20240307-v1:0"
    )
}

def basic_test(lm):
    sentence = "it's a charming and often affecting journey."

    classify = dspy.Predict('sentence -> sentiment')
    sent = classify(sentence=sentence).sentiment

    if sent == "Positive":
        print('LLM Test: ✅ Looking good')
    else:
        print(f'LLM Test: ❌ LLM did not respond as expected: Expected "Positive", got \n```\n{sent}\n```')

for llm in llms:
    lm = llms[llm]
    dspy.settings.configure(lm=lm)

    print("-------------------------")
    print("Testing on", llm)
    basic_test(lm)

For better results with LLMs, use the new experimental prompts released in v2.4.11 dspy.configure(experimental=True)

Yup, chat LMs have better support with dspy.configure(experimental=True).