Panning doesn't work on Chrome - Ubuntu 64

I have found that upgrading to Chrome 42.0.2311.90 (64-bit) on Ubuntu 14.04, has caused the mouse drag panning capabilities of leaflet to stop working. This is true in my development application, but also on leafletjs.com.
Zooming with the mouse wheel still works, it's just dragging that has stopped. Don't know if the bug lies in leaflet or Chrome. Things work when I open them in firefox, or on my windows box using the same version of Chrome.

This is a bigger issue than leaflet. Sorry to post this hastily.


If app is hidden then don't show app window on resuming from hibernation

We need to take care of this case. Don't show app window - If the app is hidden or minimized initially and the system resumes from hibernation.

Seems to be fixed.


Feature request: Add a spell check (RDT-830)

It would be nice if as part of checking the conventional commit style, we would have some spell check. Something similar to the codespell pre-commit check would be helpful. Please also consider adding an option to define ignore words.

As much as I like the idea of improving the commit linter, this seems to be beyond the scope of the tool.
I'm afraid that adding complexity to the clear and simple code will not pay off. With a spellchecker, we would probably need to maintain a set of exceptions. Also, commit messages can use some abbreviations that would likely be detected as typos.


Add write example to README (for example PUT)

There is a section on the README called reading and writing data.  However it only shows how to read, and not write.  I think it would be helpful to add an example to write data with an HTTP PUT.
Reading and writing data
The fetch method mimics
the browser's fetch API.
You can use it to access any kind of HTTP(S) document,
regardless of whether that document is on a Solid pod:
solid.auth.fetch('https://timbl.com/timbl/Public/friends.ttl')
  .then(console.log);

const { fetch } = solid.auth;
fetch('https://timbl.com/timbl/Public/friends.ttl')
  .then(console.log);

If the document is on a Solid pod,
and the user is logged in,
they will be able to access private documents
that require read or write permissions.
https://github.com/solid/solid-auth-client#reading-and-writing-data

Yea, as a user I've been testing and trying out different folder/file operations:  My current write looks like
        solid.auth.fetch('https://roger.localhost:8443/public/'+file, {
           method: 'PUT', // or 'PUT'
           body: data // data can be `string` or {object}!
           }).then(res => {return res;})
        .then((response) => {callback(null);})
        .catch(error => callback('Error: '+JSON.stringify(error)));

where I'm serving a node-solid-server at https://localhost:8443/ that I setup with developer credentials and can get the current session and my webId earlier.
and file is the file name
data is a string of a text file.
headers can be added to set Content-Type but this one is text/plain
Managed to DELETE as well with
solid.auth.fetch('https://roger.localhost:8443/public/'+path, {
  method: 'DELETE'
}).then(res => {return res;})
.then((response) => {callback(null);})
.catch(error => callback('Error: '+JSON.stringify(error)));

where path is the relative path to the file to delete.
Trying to create a pod folder but not working yet

@rimmartin very nice!
Here's the code I also found in solid-yi
    const query = `
      INSERT DATA {
        [] <${AS}actor>   <${this_escape(from)}>;
           <${AS}to>      <${this_escape(to)}>;
           <${AS}summary> "Yo"@en.
      }`
    // Send a PATCH request to update the source
    const response = await this._fetch(this._source, {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/sparql-update' },
      body: query,
      credentials: 'include',
    });

To put in more folders my latest attempt is by applying rdflib.js to the Cnntaier
        const LDP = this.rdf.Namespace('http://www.w3.org/ns/ldp#>');
        let folder = this.rdf.sym('https://roger.localhost:8443/public/');  // NOTE: Ends in a slash
        let childFolder = this.rdf.sym('https://roger.localhost:8443/public/'+path+'/');  // NOTE: Ends in a slash
        let ins = this.store.add(folder, LDP('contains'), childFolder, folder.doc());
        let del = [];
        this.updater.update(del, [ins], (uri, ok, message) => {
          if (ok) console.log('contains '+ path);
          else alert(message);
        });

It gets into the store [IndexedFormula] alright and I can list it on the container but the updater throws
Exception in update: Error: Update: Loaded <https://roger.localhost:8443/public/>but stil can't figure out what editing protcol it supports.

Close to working; I may have a cors issue yet I'm testing all on the same server

I agree we should add a write example to the README, but we should be careful this does not become a Solid read/write tutorial. A write example would be good to show how solid-auth-client works, but other examples are more about how Solid works, and they belong in the Solid docs.
@melvincarvalho Do we currently have such examples on the website? If not, we might want to make a separate issue for that.

Do we currently have such examples on the website? If not, we might want to make a separate issue for that

@RubenVerborgh there may be, but im not aware of something with solid.auth.fetch.

but we should be careful this does not become a Solid read/write tutorial

Agreed.  So the question is whether to use PUT, POST or PATCH.  I feel PUT would be most suitable for the target audience.

Ok, learned to use rdflib less and this api more:-)
        solid.auth.fetch('https://roger.localhost:8443/public/'+path.substr(0,n+1), {
           method: 'POST', // or 'PUT'
           headers:{
            'Content-Type': 'text/turtle',
	    'Link': '<http://www.w3.org/ns/ldp#BasicContainer>; rel="type"',
            'Slug':  path.substr(n+1)
	   }
           }).then((res) => {return res;})
        .then((response) => {callback(null);})
        .catch(error => callback('Error: '+JSON.stringify(error)));

will create an empty container where path = "scad/scad-poser"
Intermediate containers aren't made so I plan to step thru and create them if they don't already exist
Looks like I'll be able to put solid to use:-)


Reflection probes groups

A feature to let Godot itself place reflection probes automatically in the level.
This could be some options

distance between probes
grid size
indoor or outdoor

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


FLOP counts for each kernel would be a nice addition

Nothing fancy, the strateight-forward, no-optimized count would be great!

Duplicate of #204


Delegate by drawer state

Hi,
KYDrawerController is nice drawer.
but needed delegate, by drawer state like DrawerState.Opened or DrawerState.Closed
func kyDrawerControllerStateChanged(state: DrawerState)

Hi, @seapy
Added the delegate methods in v1.0.3 :+1:

Thanks. it works :+1:


Created selection-flag start and end flag

I use it for selecting the starttime and endtime in an audio file.

Nice icon!

I agree with @locness3, with generalizing the name. We make it more multy-purpose. Fits well with our other names.
I like flag-triangle-{left,right} more, because flag is the icon and triangle is the variation.


Descriptor

Hello, I read your paper, there is a combination of SIFT+Superglue in your comparative experiment, how do you solve the problem that the descriptor and matching network dimensions are inconsistent

Hi, network channels is configurable and we adjust it with descriptor channels number.


TileEntity not in world after changing block

Mod Versions

Minecraft Forge: 1.12.2-<IP_ADDRESS>68
SpongeForge: 7.1.6-RC3694
LuckPerms: 4.4.16
GriefPrevention: <IP_ADDRESS>9
(Also CC:Tweaked 1.82.3 and Plethora 1.2.0, but not needed to reproduce)

Reproduction steps

Place down a furnace
Add a breakpoint at the bottom of BlockFurnace.setState, configured to log the value of world.getTileEntity(blockPos).
Fuel the furnace with a stick and add some smeltable item.
Observe the tile entity in-world is null after changing the block state.

This causes the tile entity to send out neighbour updates without actually being present in the world, causing mods which update their state based on neighbours to misbehave.
In our case, ComputerCraft's wired modems would deactivate when furnaces start/stop smelting, as the tile is not present when receiving neighbour updates, and so no peripheral is present.
This feels like a Sponge problem (I know a lot of the block change logic was refactored recently), but this problem only occurs when GrifPrevention is installed so I'm reporting here until we have a more solid idea of what the problem is. Sorry!

Closing in favour of the above SpongeCommon issue - I'm able to reproduce this without GriefPrevention.


0 value Opacity not exported

The value for Opacity in the principled shader is not working in exported glb if the value is exactly 0.
If a full black texture is used then it's working.
This might affect other parameters too. But I could not check.
To reproduce just set the opacity to 0 in the shader and export a plane with that material.
Expected behavior
With blender 3.6.x setting Alpha=0 is working as expected on glb exports.
If applicable, add screenshots to help explain your problem.
Version

OS: Win10
Blender 4.2.1

Additional context
Add any other context about the problem here.

Hello,
Did you mean setting the Alpha value of the Principled Shader to 0.0?

I can not reproduce.
The exported glb file seems to be OK : the material is exported, with a 0.0 alpha value in BaseColorFactor.

Please provide a test case and the exported glb or gltf file.

Hello,
Ok, so looks like the issue is in babylonjs.
The change between the 2 versions is the alphaMode used.

In 3.6.x => BLEND
In 4.2.x => MASK, without any cutoff, so using the default 0.5

I understand the issue now. So the Render method=Blended is ignored now if Alpha=0 and no texture used?

Hello,
You can read the discussion here: https://github.com/KhronosGroup/glTF-Blender-IO/issues/2111
More info about the exporter here: https://github.com/KhronosGroup/glTF-Blender-IO/pull/2152
Documentation here (on how to manage alpha now that Blender EEVEE-Next replaced EEVEE legacy) : https://docs.blender.org/manual/en/latest/addons/import_export/scene_gltf2.html#alpha-modes

It needs to be that setting alpha blend to 0.0 means the material is set to alpha blend in the GLB
Currently, its setting to Alpha Blend 0.0 or Hashed 0.0 sets the GLB exported material to be Alpha Clip


Improvements in Build Init Plugin

Improvements to gradle init:

Support scala-application type
Streamline some comments and samples

@jjohannes Can you break out the template engine enhancements to a separeate PR so that it's easier to review?

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

Makes sense @donat. I thought the changes were connected but they actually weren't...
I moved the template engine changes to #14321.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.


Add background events feature

The feature of handling background events was proposed in #1161 and then improved in #1727.
The differences between this PR and #1727:

c9ed1e8 Resolved conflicts between the master branch and the feature branch
16e2100 Reverted changes not related to the background events feature
0df77cb Small (-1 +1) fix of the Storybook story of this feature
559663e Small fix of background event width calculation

I haven't noticed any particular element of these changes that should require adding unit tests, but I'm happy to discuss and open to any suggestions.
Checklist 🗒

API documentation ✔

Storybook story ✔

Example ✔

thanks folks looks great

thanks folks looks great


Enhancement: Resource representation response based on Accept header

Summary
In one of 3.0 wishlist points @rob suggested to support multiple resource representation in response based on Accept header https://discord.com/channels/919193495116337154/1182745702942646313/1217489384669184064
I've decided to write few words about current situation, problems, possible interface for this (possible) future feature.
Basic Example
What's all the fuss about?
In the current Litestar 2.x version if we want to return different resource representation based on Accept header we have to it manually using "ifology" which in case of many possible representations (json, xml, csv, yaml...) is not the most elegant solution. This can also lead to code duplication if we have more endpoints.
Simple example can look like this:
from dataclasses import asdict, dataclass
from typing import Annotated

from litestar import Litestar, get
from litestar.enums import MediaType
from litestar.params import Parameter
from litestar.response import Response
from litestar.status_codes import HTTP_406_NOT_ACCEPTABLE

@dataclass
class User:
    name: str
    age: int
    email: str

def convert_user_to_yaml(user: User) -> bytes: ...
def convert_user_to_xml(user: User) -> bytes: ...
def convert_user_to_csv(user: User) -> bytes: ...

@get
def get_user(accept: Annotated[str, Parameter(header="Accept")]) -> User:
    user = User(name="Olga", age=29<EMAIL_ADDRESS>
    if accept == "application/x-yaml":
        return Response(content=convert_user_to_yaml(user), media_type=accept)
    if accept == "application/xml":
        return Response(content=convert_user_to_xml(user), media_type=accept)
    if accept == "text/csv":
        return Response(content=convert_user_to_csv(user), media_type=accept)
    if accept in {"application/json", "*/*"}:
        return Response(content=asdict(user), media_type=MediaType.JSON)
    raise Response(status_code=HTTP_406_NOT_ACCEPTABLE)

app = Litestar([get_user])

Sure we can write custom methods and extend base data model classes (pydantic, msgspec, attrs...) but implementing logic for every model type with including/excluding format mechanisms may be complex and time consuming. And we still need to figure out how to handle different responses for DTOs.
Customizable, extendable and easy to use resource representation response based on Accept header can be nice addition to the Litestar. At least I think so :)
Digging into the code

Accept header is set to "*/*" if request does not provide any (https://github.com/litestar-org/litestar/blob/main/litestar/connection/request.py#L120)
media_type is set on route handler level and passed to Response.render method ("application/json" by default)
Response.render matches media_type patterns and renders properly encoded message

Interface
I like the way how the DRF handle this https://www.django-rest-framework.org/api-guide/renderers/
What if we can "borrow" their idea?
There is obstacle. We have media_type in route handler definition.
But we can move media_type argument Response object, right?
Take a look at this simpliefied example:
class YamlResponse(Response):
    media_type = "application/x-yaml"

    def render(self, content: Any, enc_hook: Serializer = default_serializer) -> bytes:
        return encode_yaml(content, enc_hook)

class XmlResponse(Response):
    media_type = "application/xml"

    def render(self, content: Any, enc_hook: Serializer = default_serializer) -> bytes:
        return encode_xml(content, enc_hook)

class CsvResponse(Response):
    media_type = "text/csv"

    def render(self, content: Any, enc_hook: Serializer = default_serializer) -> bytes:
        return encode_csv(content, enc_hook)

class JsonResponse(Response):
    media_type = "application/json"

    def render(self, content: Any, enc_hook: Serializer = default_serializer) -> bytes:
        return encode_json(content, enc_hook)

# NOTE: response_class renamed to response_classes
@get(response_classes=[JsonResponse, YamlResponse, CsvResponse, XmlResponse])
def user() -> User:
    return User(name="Olga", age=29<EMAIL_ADDRESS>

It looks nice.
Simple and reusable.
Supports DTOs.
media_type can be fixed content type, regex or */*
Drawbacks and Impact
Content negotiation
There should be negotiation between client and server to check if Accept header is supported in endpoint.
In get_response_handler we can iterate over response_classes and check if any of them supports specified Accept format.
First matched class will be used as response_class in later steps. If none of them will match then HTTP_406_NOT_ACCEPTABLE can be returned by default (or not).
New Response classes

json
msgpack
text
??

Breaking (and not) changes

Lack of media_type in handler definition
???

Unresolved questions

???

[!NOTE]
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard

If you would like to see an issue prioritized, make a pledge towards it!
We receive the pledge once the issue is completed & verified
This, along with engagement in the community, helps us know which features are a priority to our users.

Agree it would be nice to have more flexibility with response encoding.
I'm not sure about specifying multiple response class types b/c I think this would worsen the UI for defining a customized response class. E.g,.:
# currently possible

class MyCustomResponse(Response):
    type_encoders = {...}  # example response customization

app = Litestar(..., response_class=MyCustomResponse)

If multiple response class types were defined, that customization would have to be applied to all of them.
I think I noticed a mention in discord about passing request context to the response object in order to be able to discriminate how the response content should be encoded? So how about if we added a method like Response.get_encoder() that housed our default implementation and could be overridden to extend support?
E.g.,
class Response:
    def __init__(self, ..., request_context: ...) -> None: ...

    def get_encoder(self) -> Callable[[Any], bytes]: ...

    def render(self, ...) -> bytes:
        encoder = self.get_content_encoder()

So how about if we added a method like Response.get_encoder() that housed our default implementation and could be overridden to extend support?

In this case, the user would need to then give an encoder based on any custom logic they have right? I like this, but I think we could also consider taking in a mapping of accept headers to encoders at all layers, and then the default implementation wouldn't be to default to serializing as JSON but to find the encoder based on the accept header and then use that for the encoding (this is only in the case where media_type is not explicitly defined by the user).

@kedod We already have an Accept header class that allows media-type based matching

I think I noticed a mention in discord about passing request context to the response object in order to be able to discriminate how the response content should be encoded?

I don't really like this idea as it complicates things further. The response shouldn't need to worry about the request. If we were doing this, IMO this functionality should be in the place where the response is created.

Seeing how this falls generally in the category of "metadata based routing", why don't we just do that? We can already define multiple handlers for the same path, given they differ in their method, why not allow the same for another set of parameters, such as the accept header (or any other type of header really)? That would give the users the most flexibility and make for a rather straightforward implementation on our side.
@get("/", match=[Accept(MediaType.JSON)])
async def get_json() -> dict[str, str]:
 ...

@get("/", match=[Accept(MediaType.XML)])
async def get_xml() -> dict[str, str]:
 ...

@provinzkraut wouldn't the way you've suggested result in the users having to implement both get_json and get_xml? If that's the case, they can already do that. The only benefit of the approach you suggested would be that Litestar would handle the serialization properly. I think what users would find useful is just do:
@get("/")
async def get_foo() -> dict[str, str]:
    ...

Then litestar would automatically figure out which format to serialize into based on the accept header. This would be the simplest from the user perspective.

response shouldn't need to worry about the request

I didn't understand this. We already have a dependency on the Request object when we convert a Response into an ASGIResponse via the to_asgi_response. What would be the potential issues if we pass the Request object into the Response directly (optionally)?

@provinzkraut wouldn't the way you've suggested result in the users having to implement both get_json and get_xml? If that's the case, they can already do that. The only benefit of the approach you suggested would be that Litestar would handle the serialization properly. I think what users would find useful is just do:
@get("/")
async def get_foo() -> dict[str, str]:
    ...

Then litestar would automatically figure out which format to serialize into based on the accept header. This would be the simplest from the user perspective.

That feels like a different feature to me so maybe we're not talking about the same stuff here? :eyes:
If we want that, wouldn't the easiest solution to allow specifying additional response serialisers (ideally as layered parameters)?
@get("/")
async def get_foo() -> dict[str, str]:
    ...

app = Litestar(
  [get_foo],
  serializers={MediaType.XML: to_xml}
)

and then Litestar checks if for a given Accept header, an appropriate serialiser is registered?

response shouldn't need to worry about the request

I didn't understand this. We already have a dependency on the Request object when we convert a Response into an ASGIResponse via the to_asgi_response. What would be the potential issues if we pass the Request object into the Response directly (optionally)?

Yeah I don't like that either :grimacing:
It's something we currently need to do, but it's also only a workaround for some other issues we were facing. I can't actually remember anymore what exactly this was.. @peterschutt I remember we were talking about this a lot during the 2.0 churn when this was implemented and I think we agreed that it was the path of least resistance but there was some other way of handling this better.. Would have to dig up the conversation from back then :eyes:

If anyone ever takes this task, please don't forget Accept does content negotiation, can take priority in parameter q , and generally a best match should be implemented.

If anyone ever takes this task, please don't forget Accept does content negotiation, can take priority in parameter q , and generally a best match should be implemented.

https://github.com/litestar-org/litestar/blob/f9b85f9a362c15873921e7368e20313c4402a00c/litestar/datastructures/headers.py#L431
That part is already implemented :)

If we want that, wouldn't the easiest solution to allow specifying additional response serialisers (ideally as layered parameters)?

I like this idea the most. I assume we can pass matched serializer to the response_class and use it in render method later. We can set default serializers to keep consistency with the actual Litestar behaviour too.

One thing we shouldn't forget to take into account though is how to integrate with type_encoders. As a user, I would expect a type encoder to work for all serialisers, so for the non-standard one, we'd probably have to do something like calling msgspec.to_builtins with the type encoders beforehand.


TS7016: Could not find a declaration file for module '@heroicons/vue/solid'.

When we are using the library in typescript, everything works perfectly, but it is not defined.

Apparently the declarations are not generated for Vue, but they are generated for React. Maybe that's an easy fix in the build script?

I suggest temporary solution until this error is fixed.

create file called shims-heroicons.d.ts or name it something else. Your choice.
Add this block:

declare module "@heroicons/vue/*" {
  const content: any;
  export default content;
}

declare module "@heroicons/vue/outline" {
  export { default as AcademicCapIcon } from<EMAIL_ADDRESS>  // rest of outline icons
}

declare module "@heroicons/vue/solid" {
  export { default as AcademicCapIcon } from<EMAIL_ADDRESS>  // rest of solid icons
}

Thanks @MartinKukli I have created the entire block of code, which is the one that should be added.
declare module "@heroicons/vue/*" {
  const content: any
  export default content
}

declare module "@heroicons/vue/solid" {
  export { default as AcademicCapIcon } from<EMAIL_ADDRESS>  export { default as AdjustmentsIcon } from<EMAIL_ADDRESS>  export { default as AnnotationIcon } from<EMAIL_ADDRESS>  export { default as ArchiveIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowsExpandIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowUpIcon } from<EMAIL_ADDRESS>  export { default as AtSymbolIcon } from<EMAIL_ADDRESS>  export { default as BackspaceIcon } from<EMAIL_ADDRESS>  export { default as BadgeCheckIcon } from<EMAIL_ADDRESS>  export { default as BanIcon } from<EMAIL_ADDRESS>  export { default as BeakerIcon } from<EMAIL_ADDRESS>  export { default as BellIcon } from<EMAIL_ADDRESS>  export { default as BookmarkAltIcon } from<EMAIL_ADDRESS>  export { default as BookmarkIcon } from<EMAIL_ADDRESS>  export { default as BookOpenIcon } from<EMAIL_ADDRESS>  export { default as BriefcaseIcon } from<EMAIL_ADDRESS>  export { default as CakeIcon } from<EMAIL_ADDRESS>  export { default as CalculatorIcon } from<EMAIL_ADDRESS>  export { default as CalendarIcon } from<EMAIL_ADDRESS>  export { default as CameraIcon } from<EMAIL_ADDRESS>  export { default as CashIcon } from<EMAIL_ADDRESS>  export { default as ChartBarIcon } from<EMAIL_ADDRESS>  export { default as ChartPieIcon } from<EMAIL_ADDRESS>  export { default as ChartSquareBarIcon } from<EMAIL_ADDRESS>  export { default as ChatAlt2Icon } from<EMAIL_ADDRESS>  export { default as ChatAltIcon } from<EMAIL_ADDRESS>  export { default as ChatIcon } from<EMAIL_ADDRESS>  export { default as CheckCircleIcon } from<EMAIL_ADDRESS>  export { default as CheckIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleDownIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleLeftIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleRightIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleUpIcon } from<EMAIL_ADDRESS>  export { default as ChevronDownIcon } from<EMAIL_ADDRESS>  export { default as ChevronLeftIcon } from<EMAIL_ADDRESS>  export { default as ChevronRightIcon } from<EMAIL_ADDRESS>  export { default as ChevronUpIcon } from<EMAIL_ADDRESS>  export { default as ChipIcon } from<EMAIL_ADDRESS>  export { default as ClipboardCheckIcon } from<EMAIL_ADDRESS>  export { default as ClipboardCopyIcon } from<EMAIL_ADDRESS>  export { default as ClipboardIcon } from<EMAIL_ADDRESS>  export { default as ClipboardListIcon } from<EMAIL_ADDRESS>  export { default as ClockIcon } from<EMAIL_ADDRESS>  export { default as CloudDownloadIcon } from<EMAIL_ADDRESS>  export { default as CloudIcon } from<EMAIL_ADDRESS>  export { default as CloudUploadIcon } from<EMAIL_ADDRESS>  export { default as CodeIcon } from<EMAIL_ADDRESS>  export { default as CogIcon } from<EMAIL_ADDRESS>  export { default as CollectionIcon } from<EMAIL_ADDRESS>  export { default as ColorSwatchIcon } from<EMAIL_ADDRESS>  export { default as CreditCardIcon } from<EMAIL_ADDRESS>  export { default as CubeIcon } from<EMAIL_ADDRESS>  export { default as CubeTransparentIcon } from<EMAIL_ADDRESS>  export { default as CurrencyBangladeshiIcon } from<EMAIL_ADDRESS>  export { default as CurrencyDollarIcon } from<EMAIL_ADDRESS>  export { default as CurrencyEuroIcon } from<EMAIL_ADDRESS>  export { default as CurrencyPoundIcon } from<EMAIL_ADDRESS>  export { default as CurrencyRupeeIcon } from<EMAIL_ADDRESS>  export { default as CurrencyYenIcon } from<EMAIL_ADDRESS>  export { default as CursorClickIcon } from<EMAIL_ADDRESS>  export { default as DatabaseIcon } from<EMAIL_ADDRESS>  export { default as DesktopComputerIcon } from<EMAIL_ADDRESS>  export { default as DeviceMobileIcon } from<EMAIL_ADDRESS>  export { default as DeviceTabletIcon } from<EMAIL_ADDRESS>  export { default as DocumentAddIcon } from<EMAIL_ADDRESS>  export { default as DocumentDownloadIcon } from<EMAIL_ADDRESS>  export { default as DocumentDuplicateIcon } from<EMAIL_ADDRESS>  export { default as DocumentIcon } from<EMAIL_ADDRESS>  export { default as DocumentRemoveIcon } from<EMAIL_ADDRESS>  export { default as DocumentReportIcon } from<EMAIL_ADDRESS>  export { default as DocumentSearchIcon } from<EMAIL_ADDRESS>  export { default as DocumentTextIcon } from<EMAIL_ADDRESS>  export { default as DotsCircleHorizontalIcon } from<EMAIL_ADDRESS>  export { default as DotsHorizontalIcon } from<EMAIL_ADDRESS>  export { default as DotsVerticalIcon } from<EMAIL_ADDRESS>  export { default as DownloadIcon } from<EMAIL_ADDRESS>  export { default as DuplicateIcon } from<EMAIL_ADDRESS>  export { default as EmojiHappyIcon } from<EMAIL_ADDRESS>  export { default as EmojiSadIcon } from<EMAIL_ADDRESS>  export { default as ExclamationCircleIcon } from<EMAIL_ADDRESS>  export { default as ExclamationIcon } from<EMAIL_ADDRESS>  export { default as ExternalLinkIcon } from<EMAIL_ADDRESS>  export { default as EyeIcon } from<EMAIL_ADDRESS>  export { default as EyeOffIcon } from<EMAIL_ADDRESS>  export { default as FastForwardIcon } from<EMAIL_ADDRESS>  export { default as FilmIcon } from<EMAIL_ADDRESS>  export { default as FilterIcon } from<EMAIL_ADDRESS>  export { default as FingerPrintIcon } from<EMAIL_ADDRESS>  export { default as FireIcon } from<EMAIL_ADDRESS>  export { default as FlagIcon } from<EMAIL_ADDRESS>  export { default as FolderAddIcon } from<EMAIL_ADDRESS>  export { default as FolderDownloadIcon } from<EMAIL_ADDRESS>  export { default as FolderIcon } from<EMAIL_ADDRESS>  export { default as FolderOpenIcon } from<EMAIL_ADDRESS>  export { default as FolderRemoveIcon } from<EMAIL_ADDRESS>  export { default as GiftIcon } from<EMAIL_ADDRESS>  export { default as GlobeAltIcon } from<EMAIL_ADDRESS>  export { default as GlobeIcon } from<EMAIL_ADDRESS>  export { default as HandIcon } from<EMAIL_ADDRESS>  export { default as HashtagIcon } from<EMAIL_ADDRESS>  export { default as HeartIcon } from<EMAIL_ADDRESS>  export { default as HomeIcon } from<EMAIL_ADDRESS>  export { default as IdentificationIcon } from<EMAIL_ADDRESS>  export { default as InboxIcon } from<EMAIL_ADDRESS>  export { default as InboxInIcon } from<EMAIL_ADDRESS>  export { default as InformationCircleIcon } from<EMAIL_ADDRESS>  export { default as KeyIcon } from<EMAIL_ADDRESS>  export { default as LibraryIcon } from<EMAIL_ADDRESS>  export { default as LightBulbIcon } from<EMAIL_ADDRESS>  export { default as LightningBoltIcon } from<EMAIL_ADDRESS>  export { default as LinkIcon } from<EMAIL_ADDRESS>  export { default as LocationMarkerIcon } from<EMAIL_ADDRESS>  export { default as LockClosedIcon } from<EMAIL_ADDRESS>  export { default as LockOpenIcon } from<EMAIL_ADDRESS>  export { default as LoginIcon } from<EMAIL_ADDRESS>  export { default as LogoutIcon } from<EMAIL_ADDRESS>  export { default as MailIcon } from<EMAIL_ADDRESS>  export { default as MailOpenIcon } from<EMAIL_ADDRESS>  export { default as MapIcon } from<EMAIL_ADDRESS>  export { default as MenuAlt1Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt2Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt3Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt4Icon } from<EMAIL_ADDRESS>  export { default as MenuIcon } from<EMAIL_ADDRESS>  export { default as MicrophoneIcon } from<EMAIL_ADDRESS>  export { default as MinusCircleIcon } from<EMAIL_ADDRESS>  export { default as MinusIcon } from<EMAIL_ADDRESS>  export { default as MinusSmIcon } from<EMAIL_ADDRESS>  export { default as MoonIcon } from<EMAIL_ADDRESS>  export { default as MusicNoteIcon } from<EMAIL_ADDRESS>  export { default as NewspaperIcon } from<EMAIL_ADDRESS>  export { default as OfficeBuildingIcon } from<EMAIL_ADDRESS>  export { default as PaperAirplaneIcon } from<EMAIL_ADDRESS>  export { default as PaperClipIcon } from<EMAIL_ADDRESS>  export { default as PauseIcon } from<EMAIL_ADDRESS>  export { default as PencilAltIcon } from<EMAIL_ADDRESS>  export { default as PencilIcon } from<EMAIL_ADDRESS>  export { default as PhoneIcon } from<EMAIL_ADDRESS>  export { default as PhoneIncomingIcon } from<EMAIL_ADDRESS>  export { default as PhoneMissedCallIcon } from<EMAIL_ADDRESS>  export { default as PhoneOutgoingIcon } from<EMAIL_ADDRESS>  export { default as PhotographIcon } from<EMAIL_ADDRESS>  export { default as PlayIcon } from<EMAIL_ADDRESS>  export { default as PlusCircleIcon } from<EMAIL_ADDRESS>  export { default as PlusIcon } from<EMAIL_ADDRESS>  export { default as PlusSmIcon } from<EMAIL_ADDRESS>  export { default as PresentationChartBarIcon } from<EMAIL_ADDRESS>  export { default as PresentationChartLineIcon } from<EMAIL_ADDRESS>  export { default as PrinterIcon } from<EMAIL_ADDRESS>  export { default as PuzzleIcon } from<EMAIL_ADDRESS>  export { default as QrcodeIcon } from<EMAIL_ADDRESS>  export { default as QuestionMarkCircleIcon } from<EMAIL_ADDRESS>  export { default as ReceiptRefundIcon } from<EMAIL_ADDRESS>  export { default as ReceiptTaxIcon } from<EMAIL_ADDRESS>  export { default as RefreshIcon } from<EMAIL_ADDRESS>  export { default as ReplyIcon } from<EMAIL_ADDRESS>  export { default as RewindIcon } from<EMAIL_ADDRESS>  export { default as RssIcon } from<EMAIL_ADDRESS>  export { default as SaveAsIcon } from<EMAIL_ADDRESS>  export { default as SaveIcon } from<EMAIL_ADDRESS>  export { default as ScaleIcon } from<EMAIL_ADDRESS>  export { default as ScissorsIcon } from<EMAIL_ADDRESS>  export { default as SearchCircleIcon } from<EMAIL_ADDRESS>  export { default as SearchIcon } from<EMAIL_ADDRESS>  export { default as SelectorIcon } from<EMAIL_ADDRESS>  export { default as ServerIcon } from<EMAIL_ADDRESS>  export { default as ShareIcon } from<EMAIL_ADDRESS>  export { default as ShieldCheckIcon } from<EMAIL_ADDRESS>  export { default as ShieldExclamationIcon } from<EMAIL_ADDRESS>  export { default as ShoppingBagIcon } from<EMAIL_ADDRESS>  export { default as ShoppingCartIcon } from<EMAIL_ADDRESS>  export { default as SortAscendingIcon } from<EMAIL_ADDRESS>  export { default as SortDescendingIcon } from<EMAIL_ADDRESS>  export { default as SparklesIcon } from<EMAIL_ADDRESS>  export { default as SpeakerphoneIcon } from<EMAIL_ADDRESS>  export { default as StarIcon } from<EMAIL_ADDRESS>  export { default as StatusOfflineIcon } from<EMAIL_ADDRESS>  export { default as StatusOnlineIcon } from<EMAIL_ADDRESS>  export { default as StopIcon } from<EMAIL_ADDRESS>  export { default as SunIcon } from<EMAIL_ADDRESS>  export { default as SupportIcon } from<EMAIL_ADDRESS>  export { default as SwitchHorizontalIcon } from<EMAIL_ADDRESS>  export { default as SwitchVerticalIcon } from<EMAIL_ADDRESS>  export { default as TableIcon } from<EMAIL_ADDRESS>  export { default as TagIcon } from<EMAIL_ADDRESS>  export { default as TemplateIcon } from<EMAIL_ADDRESS>  export { default as TerminalIcon } from<EMAIL_ADDRESS>  export { default as ThumbDownIcon } from<EMAIL_ADDRESS>  export { default as ThumbUpIcon } from<EMAIL_ADDRESS>  export { default as TicketIcon } from<EMAIL_ADDRESS>  export { default as TranslateIcon } from<EMAIL_ADDRESS>  export { default as TrashIcon } from<EMAIL_ADDRESS>  export { default as TrendingDownIcon } from<EMAIL_ADDRESS>  export { default as TrendingUpIcon } from<EMAIL_ADDRESS>  export { default as TruckIcon } from<EMAIL_ADDRESS>  export { default as UploadIcon } from<EMAIL_ADDRESS>  export { default as UserAddIcon } from<EMAIL_ADDRESS>  export { default as UserCircleIcon } from<EMAIL_ADDRESS>  export { default as UserGroupIcon } from<EMAIL_ADDRESS>  export { default as UserIcon } from<EMAIL_ADDRESS>  export { default as UserRemoveIcon } from<EMAIL_ADDRESS>  export { default as UsersIcon } from<EMAIL_ADDRESS>  export { default as VariableIcon } from<EMAIL_ADDRESS>  export { default as VideoCameraIcon } from<EMAIL_ADDRESS>  export { default as ViewBoardsIcon } from<EMAIL_ADDRESS>  export { default as ViewGridAddIcon } from<EMAIL_ADDRESS>  export { default as ViewGridIcon } from<EMAIL_ADDRESS>  export { default as ViewListIcon } from<EMAIL_ADDRESS>  export { default as VolumeOffIcon } from<EMAIL_ADDRESS>  export { default as VolumeUpIcon } from<EMAIL_ADDRESS>  export { default as WifiIcon } from<EMAIL_ADDRESS>  export { default as XCircleIcon } from<EMAIL_ADDRESS>  export { default as XIcon } from<EMAIL_ADDRESS>  export { default as ZoomInIcon } from<EMAIL_ADDRESS>  export { default as ZoomOutIcon } from<EMAIL_ADDRESS>}

declare module "@heroicons/vue/outline" {
  export { default as AcademicCapIcon } from<EMAIL_ADDRESS>  export { default as AdjustmentsIcon } from<EMAIL_ADDRESS>  export { default as AnnotationIcon } from<EMAIL_ADDRESS>  export { default as ArchiveIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowCircleUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowNarrowUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowsExpandIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmDownIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmLeftIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmRightIcon } from<EMAIL_ADDRESS>  export { default as ArrowSmUpIcon } from<EMAIL_ADDRESS>  export { default as ArrowUpIcon } from<EMAIL_ADDRESS>  export { default as AtSymbolIcon } from<EMAIL_ADDRESS>  export { default as BackspaceIcon } from<EMAIL_ADDRESS>  export { default as BadgeCheckIcon } from<EMAIL_ADDRESS>  export { default as BanIcon } from<EMAIL_ADDRESS>  export { default as BeakerIcon } from<EMAIL_ADDRESS>  export { default as BellIcon } from<EMAIL_ADDRESS>  export { default as BookmarkAltIcon } from<EMAIL_ADDRESS>  export { default as BookmarkIcon } from<EMAIL_ADDRESS>  export { default as BookOpenIcon } from<EMAIL_ADDRESS>  export { default as BriefcaseIcon } from<EMAIL_ADDRESS>  export { default as CakeIcon } from<EMAIL_ADDRESS>  export { default as CalculatorIcon } from<EMAIL_ADDRESS>  export { default as CalendarIcon } from<EMAIL_ADDRESS>  export { default as CameraIcon } from<EMAIL_ADDRESS>  export { default as CashIcon } from<EMAIL_ADDRESS>  export { default as ChartBarIcon } from<EMAIL_ADDRESS>  export { default as ChartPieIcon } from<EMAIL_ADDRESS>  export { default as ChartSquareBarIcon } from<EMAIL_ADDRESS>  export { default as ChatAlt2Icon } from<EMAIL_ADDRESS>  export { default as ChatAltIcon } from<EMAIL_ADDRESS>  export { default as ChatIcon } from<EMAIL_ADDRESS>  export { default as CheckCircleIcon } from<EMAIL_ADDRESS>  export { default as CheckIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleDownIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleLeftIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleRightIcon } from<EMAIL_ADDRESS>  export { default as ChevronDoubleUpIcon } from<EMAIL_ADDRESS>  export { default as ChevronDownIcon } from<EMAIL_ADDRESS>  export { default as ChevronLeftIcon } from<EMAIL_ADDRESS>  export { default as ChevronRightIcon } from<EMAIL_ADDRESS>  export { default as ChevronUpIcon } from<EMAIL_ADDRESS>  export { default as ChipIcon } from<EMAIL_ADDRESS>  export { default as ClipboardCheckIcon } from<EMAIL_ADDRESS>  export { default as ClipboardCopyIcon } from<EMAIL_ADDRESS>  export { default as ClipboardIcon } from<EMAIL_ADDRESS>  export { default as ClipboardListIcon } from<EMAIL_ADDRESS>  export { default as ClockIcon } from<EMAIL_ADDRESS>  export { default as CloudDownloadIcon } from<EMAIL_ADDRESS>  export { default as CloudIcon } from<EMAIL_ADDRESS>  export { default as CloudUploadIcon } from<EMAIL_ADDRESS>  export { default as CodeIcon } from<EMAIL_ADDRESS>  export { default as CogIcon } from<EMAIL_ADDRESS>  export { default as CollectionIcon } from<EMAIL_ADDRESS>  export { default as ColorSwatchIcon } from<EMAIL_ADDRESS>  export { default as CreditCardIcon } from<EMAIL_ADDRESS>  export { default as CubeIcon } from<EMAIL_ADDRESS>  export { default as CubeTransparentIcon } from<EMAIL_ADDRESS>  export { default as CurrencyBangladeshiIcon } from<EMAIL_ADDRESS>  export { default as CurrencyDollarIcon } from<EMAIL_ADDRESS>  export { default as CurrencyEuroIcon } from<EMAIL_ADDRESS>  export { default as CurrencyPoundIcon } from<EMAIL_ADDRESS>  export { default as CurrencyRupeeIcon } from<EMAIL_ADDRESS>  export { default as CurrencyYenIcon } from<EMAIL_ADDRESS>  export { default as CursorClickIcon } from<EMAIL_ADDRESS>  export { default as DatabaseIcon } from<EMAIL_ADDRESS>  export { default as DesktopComputerIcon } from<EMAIL_ADDRESS>  export { default as DeviceMobileIcon } from<EMAIL_ADDRESS>  export { default as DeviceTabletIcon } from<EMAIL_ADDRESS>  export { default as DocumentAddIcon } from<EMAIL_ADDRESS>  export { default as DocumentDownloadIcon } from<EMAIL_ADDRESS>  export { default as DocumentDuplicateIcon } from<EMAIL_ADDRESS>  export { default as DocumentIcon } from<EMAIL_ADDRESS>  export { default as DocumentRemoveIcon } from<EMAIL_ADDRESS>  export { default as DocumentReportIcon } from<EMAIL_ADDRESS>  export { default as DocumentSearchIcon } from<EMAIL_ADDRESS>  export { default as DocumentTextIcon } from<EMAIL_ADDRESS>  export { default as DotsCircleHorizontalIcon } from<EMAIL_ADDRESS>  export { default as DotsHorizontalIcon } from<EMAIL_ADDRESS>  export { default as DotsVerticalIcon } from<EMAIL_ADDRESS>  export { default as DownloadIcon } from<EMAIL_ADDRESS>  export { default as DuplicateIcon } from<EMAIL_ADDRESS>  export { default as EmojiHappyIcon } from<EMAIL_ADDRESS>  export { default as EmojiSadIcon } from<EMAIL_ADDRESS>  export { default as ExclamationCircleIcon } from<EMAIL_ADDRESS>  export { default as ExclamationIcon } from<EMAIL_ADDRESS>  export { default as ExternalLinkIcon } from<EMAIL_ADDRESS>  export { default as EyeIcon } from<EMAIL_ADDRESS>  export { default as EyeOffIcon } from<EMAIL_ADDRESS>  export { default as FastForwardIcon } from<EMAIL_ADDRESS>  export { default as FilmIcon } from<EMAIL_ADDRESS>  export { default as FilterIcon } from<EMAIL_ADDRESS>  export { default as FingerPrintIcon } from<EMAIL_ADDRESS>  export { default as FireIcon } from<EMAIL_ADDRESS>  export { default as FlagIcon } from<EMAIL_ADDRESS>  export { default as FolderAddIcon } from<EMAIL_ADDRESS>  export { default as FolderDownloadIcon } from<EMAIL_ADDRESS>  export { default as FolderIcon } from<EMAIL_ADDRESS>  export { default as FolderOpenIcon } from<EMAIL_ADDRESS>  export { default as FolderRemoveIcon } from<EMAIL_ADDRESS>  export { default as GiftIcon } from<EMAIL_ADDRESS>  export { default as GlobeAltIcon } from<EMAIL_ADDRESS>  export { default as GlobeIcon } from<EMAIL_ADDRESS>  export { default as HandIcon } from<EMAIL_ADDRESS>  export { default as HashtagIcon } from<EMAIL_ADDRESS>  export { default as HeartIcon } from<EMAIL_ADDRESS>  export { default as HomeIcon } from<EMAIL_ADDRESS>  export { default as IdentificationIcon } from<EMAIL_ADDRESS>  export { default as InboxIcon } from<EMAIL_ADDRESS>  export { default as InboxInIcon } from<EMAIL_ADDRESS>  export { default as InformationCircleIcon } from<EMAIL_ADDRESS>  export { default as KeyIcon } from<EMAIL_ADDRESS>  export { default as LibraryIcon } from<EMAIL_ADDRESS>  export { default as LightBulbIcon } from<EMAIL_ADDRESS>  export { default as LightningBoltIcon } from<EMAIL_ADDRESS>  export { default as LinkIcon } from<EMAIL_ADDRESS>  export { default as LocationMarkerIcon } from<EMAIL_ADDRESS>  export { default as LockClosedIcon } from<EMAIL_ADDRESS>  export { default as LockOpenIcon } from<EMAIL_ADDRESS>  export { default as LoginIcon } from<EMAIL_ADDRESS>  export { default as LogoutIcon } from<EMAIL_ADDRESS>  export { default as MailIcon } from<EMAIL_ADDRESS>  export { default as MailOpenIcon } from<EMAIL_ADDRESS>  export { default as MapIcon } from<EMAIL_ADDRESS>  export { default as MenuAlt1Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt2Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt3Icon } from<EMAIL_ADDRESS>  export { default as MenuAlt4Icon } from<EMAIL_ADDRESS>  export { default as MenuIcon } from<EMAIL_ADDRESS>  export { default as MicrophoneIcon } from<EMAIL_ADDRESS>  export { default as MinusCircleIcon } from<EMAIL_ADDRESS>  export { default as MinusIcon } from<EMAIL_ADDRESS>  export { default as MinusSmIcon } from<EMAIL_ADDRESS>  export { default as MoonIcon } from<EMAIL_ADDRESS>  export { default as MusicNoteIcon } from<EMAIL_ADDRESS>  export { default as NewspaperIcon } from<EMAIL_ADDRESS>  export { default as OfficeBuildingIcon } from<EMAIL_ADDRESS>  export { default as PaperAirplaneIcon } from<EMAIL_ADDRESS>  export { default as PaperClipIcon } from<EMAIL_ADDRESS>  export { default as PauseIcon } from<EMAIL_ADDRESS>  export { default as PencilAltIcon } from<EMAIL_ADDRESS>  export { default as PencilIcon } from<EMAIL_ADDRESS>  export { default as PhoneIcon } from<EMAIL_ADDRESS>  export { default as PhoneIncomingIcon } from<EMAIL_ADDRESS>  export { default as PhoneMissedCallIcon } from<EMAIL_ADDRESS>  export { default as PhoneOutgoingIcon } from<EMAIL_ADDRESS>  export { default as PhotographIcon } from<EMAIL_ADDRESS>  export { default as PlayIcon } from<EMAIL_ADDRESS>  export { default as PlusCircleIcon } from<EMAIL_ADDRESS>  export { default as PlusIcon } from<EMAIL_ADDRESS>  export { default as PlusSmIcon } from<EMAIL_ADDRESS>  export { default as PresentationChartBarIcon } from<EMAIL_ADDRESS>  export { default as PresentationChartLineIcon } from<EMAIL_ADDRESS>  export { default as PrinterIcon } from<EMAIL_ADDRESS>  export { default as PuzzleIcon } from<EMAIL_ADDRESS>  export { default as QrcodeIcon } from<EMAIL_ADDRESS>  export { default as QuestionMarkCircleIcon } from<EMAIL_ADDRESS>  export { default as ReceiptRefundIcon } from<EMAIL_ADDRESS>  export { default as ReceiptTaxIcon } from<EMAIL_ADDRESS>  export { default as RefreshIcon } from<EMAIL_ADDRESS>  export { default as ReplyIcon } from<EMAIL_ADDRESS>  export { default as RewindIcon } from<EMAIL_ADDRESS>  export { default as RssIcon } from<EMAIL_ADDRESS>  export { default as SaveAsIcon } from<EMAIL_ADDRESS>  export { default as SaveIcon } from<EMAIL_ADDRESS>  export { default as ScaleIcon } from<EMAIL_ADDRESS>  export { default as ScissorsIcon } from<EMAIL_ADDRESS>  export { default as SearchCircleIcon } from<EMAIL_ADDRESS>  export { default as SearchIcon } from<EMAIL_ADDRESS>  export { default as SelectorIcon } from<EMAIL_ADDRESS>  export { default as ServerIcon } from<EMAIL_ADDRESS>  export { default as ShareIcon } from<EMAIL_ADDRESS>  export { default as ShieldCheckIcon } from<EMAIL_ADDRESS>  export { default as ShieldExclamationIcon } from<EMAIL_ADDRESS>  export { default as ShoppingBagIcon } from<EMAIL_ADDRESS>  export { default as ShoppingCartIcon } from<EMAIL_ADDRESS>  export { default as SortAscendingIcon } from<EMAIL_ADDRESS>  export { default as SortDescendingIcon } from<EMAIL_ADDRESS>  export { default as SparklesIcon } from<EMAIL_ADDRESS>  export { default as SpeakerphoneIcon } from<EMAIL_ADDRESS>  export { default as StarIcon } from<EMAIL_ADDRESS>  export { default as StatusOfflineIcon } from<EMAIL_ADDRESS>  export { default as StatusOnlineIcon } from<EMAIL_ADDRESS>  export { default as StopIcon } from<EMAIL_ADDRESS>  export { default as SunIcon } from<EMAIL_ADDRESS>  export { default as SupportIcon } from<EMAIL_ADDRESS>  export { default as SwitchHorizontalIcon } from<EMAIL_ADDRESS>  export { default as SwitchVerticalIcon } from<EMAIL_ADDRESS>  export { default as TableIcon } from<EMAIL_ADDRESS>  export { default as TagIcon } from<EMAIL_ADDRESS>  export { default as TemplateIcon } from<EMAIL_ADDRESS>  export { default as TerminalIcon } from<EMAIL_ADDRESS>  export { default as ThumbDownIcon } from<EMAIL_ADDRESS>  export { default as ThumbUpIcon } from<EMAIL_ADDRESS>  export { default as TicketIcon } from<EMAIL_ADDRESS>  export { default as TranslateIcon } from<EMAIL_ADDRESS>  export { default as TrashIcon } from<EMAIL_ADDRESS>  export { default as TrendingDownIcon } from<EMAIL_ADDRESS>  export { default as TrendingUpIcon } from<EMAIL_ADDRESS>  export { default as TruckIcon } from<EMAIL_ADDRESS>  export { default as UploadIcon } from<EMAIL_ADDRESS>  export { default as UserAddIcon } from<EMAIL_ADDRESS>  export { default as UserCircleIcon } from<EMAIL_ADDRESS>  export { default as UserGroupIcon } from<EMAIL_ADDRESS>  export { default as UserIcon } from<EMAIL_ADDRESS>  export { default as UserRemoveIcon } from<EMAIL_ADDRESS>  export { default as UsersIcon } from<EMAIL_ADDRESS>  export { default as VariableIcon } from<EMAIL_ADDRESS>  export { default as VideoCameraIcon } from<EMAIL_ADDRESS>  export { default as ViewBoardsIcon } from<EMAIL_ADDRESS>  export { default as ViewGridAddIcon } from<EMAIL_ADDRESS>  export { default as ViewGridIcon } from<EMAIL_ADDRESS>  export { default as ViewListIcon } from<EMAIL_ADDRESS>  export { default as VolumeOffIcon } from<EMAIL_ADDRESS>  export { default as VolumeUpIcon } from<EMAIL_ADDRESS>  export { default as WifiIcon } from<EMAIL_ADDRESS>  export { default as XCircleIcon } from<EMAIL_ADDRESS>  export { default as XIcon } from<EMAIL_ADDRESS>  export { default as ZoomInIcon } from<EMAIL_ADDRESS>  export { default as ZoomOutIcon } from<EMAIL_ADDRESS>}

Please, add support TS for Vue, thanks

Please, add support TS for Vue, thanks

There's been a PR (#254) for quite some time but it has not been mergd yet. In the meanwhile, you can either use the above workaround or the heroicons-vue3 package which is the same as @heroicons/vue but contains the TS typings

@VottusCode interestingly installing heroicons-vue3 does give me the exact same error:

what gives?

Ok, as follow up, I realized you need to import it from "heroicons-vue3/solid" however, when I try to compile I gues hundreds of errors like this one:
node_modules/heroicons-vue3/solid/ZoomOutIcon.d.ts:1:30 - error TS2339: Property 'DefineComponent' does not exist on type 'Promise<{ default: typeof import("/Users/manuelastudillo/Dev/taskforce/taskforce-backend/premises/config_app/node_modules/vue/dist/vue"); compile(template: string | HTMLElement, options?: CompilerOptions | undefined): RenderFunction; ... 121 more ...; withScopeId: (_id: string) => (fn: Function, ctx?: ComponentInter...'.

1 export default import("vue").DefineComponent;
                               ~~~~~~~~~~~~~~~

Ok, as follow up, I realized you need to import it from "heroicons-vue3/solid" however, when I try to compile I gues hundreds of errors like this one:
node_modules/heroicons-vue3/solid/ZoomOutIcon.d.ts:1:30 - error TS2339: Property 'DefineComponent' does not exist on type 'Promise<{ default: typeof import("/Users/manuelastudillo/Dev/taskforce/taskforce-backend/premises/config_app/node_modules/vue/dist/vue"); compile(template: string | HTMLElement, options?: CompilerOptions | undefined): RenderFunction; ... 121 more ...; withScopeId: (_id: string) => (fn: Function, ctx?: ComponentInter...'.

1 export default import("vue").DefineComponent;
                               ~~~~~~~~~~~~~~~

The official package now has type declarations, my PR has finally been merged. Your error however is very interesting, this should not happen unless the TypeScript compiler does not know of the vue package and/or the vue version isn't 3.0>

@VottusCode yes you are right, I can use the official repo now but I get the same error nevertheless.
I am using latest vuejs 3.0 and vite, and the error I experience is the same as reported here: https://github.com/tailwindlabs/heroicons/issues/318

same problem happening in react too..


Result 2.0.0 podspec not submitted to CocoaPods trunk

The newest podspec needs to be submitted to CocoaPods. The most recent version available there is 1.0.2.

Done
$ pod trunk push

[!] Found podspec `Result.podspec`
Updating spec repo `master`

CocoaPods 1.0.0.beta.6 is available.
To update use: `sudo gem install cocoapods --pre`
[!] This is a test version we'd love you to try.

For more information see http://blog.cocoapods.org
and the CHANGELOG for this version http://git.io/BaH8pQ.

Validating podspec
 -> Result (2.0.0)

Updating spec repo `master`

CocoaPods 1.0.0.beta.6 is available.
To update use: `sudo gem install cocoapods --pre`
[!] This is a test version we'd love you to try.

For more information see http://blog.cocoapods.org
and the CHANGELOG for this version http://git.io/BaH8pQ.

  - Data URL: https://raw.githubusercontent.com/CocoaPods/Specs/c39684b94940e30c4c2177d72613645fe3e752b2/Specs/Result/2.0.0/Result.podspec.json
  - Log messages:
    - March 27th, 15:09: Push for `Result 2.0.0' initiated.
    - March 27th, 15:09: Push for `Result 2.0.0' has been pushed (3.235823135 s).


From-Until attributes aren't checked properly when using UntilInclusive

When using the option UntilInclusive = true , the check for the version of an endpoint should be altered such that it is allowed to have a situation where the version's overlap.
Without this setting, this situation would logically exclude any valid version from using this endpoint, meaning that the exception thrown makes sense. However, when the UntilAttribute is used inclusively, this situation would mean that only that exact version is able to use the endpoint, a valid case.
The code example below minimally produces the exception that can be found in the log file included at the bottom of this description:
using BetterVersioning.Net.Attributes;
using Microsoft.AspNetCore.Mvc;

namespace Api.Features.Deviations;

[ApiController, Route("v{version:apiVersion}/[controller]"), From(1)]
public class TestController : ControllerBase
{
    [HttpGet, Until(1)]
    public ActionResult<string> Get() => Ok("Test Response.");
}

The code above should generate the following exception: StackTrace.log
The Startup.cs should contain settings similar to the example in the README.md.

Fixed in 1.0.4.
Thanks for the help!
PS: duplicate route checking within a controller will be released later today as a V2


[6.0][ScanDependency] Pass crossimport overlay file to swift-frontend

Explanation: Teach dependency scanner to pass cross import overlay file to swift-frontend for main module compilation. This allows swift-frontend not to repeat the file system search for overlay files when loading modules.
Scope: For swift caching, this is needed for loading cross import from objc frameworks since the module map file location is abstract away during the build for caching purpose.
Issue: rdar://127844120
Original PR: https://github.com/apple/swift/pull/73601
Reviewer: @artemcm
Risk: Low
Tests: Unit test

@swift-ci please test

Please test with following PR:
https://github.com/apple/swift/pull/73757
@swift-ci please test linux platform

@swift-ci please test linux platform


feat: #517 new strategy css

feat(strategy): add style to NewStrategy component
This PR updated NewStrategy.module.css file containing scoped CSS classes to the NewStrategy component.
new strategy css

All good :)

all good. It aligns with the old version.


feat(llm): Ollama integration

Work in progress on supporting local LLMs for enhanced privacy and cost efficiency
Discussion #3

Let me know if you think it's ready for a test :)


Implement the PV-DBOW version of the model

Issue

Fixes https://github.com/inejc/paragraph-vectors/issues/1.
Description of changes

See the above issue.
Includes

[X] Code changes
[x] Tests

Codecov Report

Merging #19 into master will increase coverage by 0.29%.
The diff coverage is 86.66%.

@@            Coverage Diff             @@
##           master      #19      +/-   ##
==========================================
+ Coverage   60.42%   60.71%   +0.29%
==========================================
  Files           6        6
  Lines         331      336       +5
  Branches       39       42       +3
==========================================
+ Hits          200      204       +4
- Misses        125      126       +1
  Partials        6        6


Fails to parse Flow-annotated polymorphic methods which name is a keyword

I started using Flow recently, and was delighted to see that Babel (which I was already using) supported stripping Flow types by default already! I just found a funny issue though:
sebmck: It's being parsed as a JSX tag for some reason.
sebmck: Figured it out exprAllowed is being set to true on delete tokens so the < is being interpreted as the start of a JSX starting tag expression.
thejameskyle: @sebmck is this an easy one to tackle?

class Foo {
  delete<T>(item: T): T {
    return item;
  }
}

copied from https://phabricator.babeljs.io/T1737

I tried to solve this some months ago, but couldn't figure out how to fix. This not only happens for delete but also fro some other keywords, couldn't remember which. Maybe void.

declare class A {

while<T>(): void; // this parses
do<T>(): void; // this does not
}

The input code should parse, however it errors at the '<' after the 'do'.
The above fails to parse because the 'do' keyword is marked as {beforeExpr: true} in tokenizer/types.js.
Then tokenizer interprets the '<' after the do as the start of a jsx tag, rather than as a relational '<'.
The 'while' variant works because it is not marked beforeExpr.
The above will repro with any method whose name is a keyword marked with beforeExpr true, which are:
case, default, do, else, return, throw, new, extends, yield, in, instanceof, typeof, void, delete.

https://phabricator.babeljs.io/T7284

The same for get/set

Fixed the get/set part: https://github.com/babel/babylon/pull/55

@danez it seems that your examples work on master

No both are not working yet.

Hmm, they work for me. Do you have jsx plugin enabled?

yes
declare class A {
   while<T>(): void; // this parses
   do<T>(): void; // this does not
}

{
  "sourceType": "module",
  "plugins": ["jsx", "flow", "asyncFunctions"]
}

Unexpected token (3:2)

I've got a WIP of a fix for this. I think there's still some edge cases to cover to match Flow though (or, they might be bugs in Flow..) I'll probably have a PR ready this weekend.


eeprom/at2x: add config to disable handling WP

There is a part of the AT2X driver that handles controlling WP pin
connected to the EEPROM chips, but in some systems, the WP line can be
controlled by another component.
Add a config to compile out the code related to WP to save space.
Signed-off-by: Dawid Niedzwiecki<EMAIL_ADDRESS>Change-Id: Ib8aebcd0b23cf84be8f6b8899154c63e85057aea

Codecov Report

Merging #42127 (140837c) into main (e9d012c) will increase coverage by 0.00%.
The diff coverage is n/a.

:exclamation: Current head 140837c differs from pull request most recent head 800b7ca. Consider uploading reports for the commit 800b7ca to get more accurate results

@@           Coverage Diff           @@
##             main   #42127   +/-   ##
=======================================
  Coverage   51.65%   51.65%
=======================================
  Files         615      615
  Lines       72508    72508
  Branches    16669    16669
=======================================
+ Hits        37454    37456    +2
  Misses      28950    28950
+ Partials     6104     6102    -2

Impacted Files
Coverage Δ

arch/x86/core/x86_mmu.c
81.73% <0.00%> (+0.22%)
:arrow_up:

boards/posix/native_posix/timer_model.c
52.17% <0.00%> (+0.72%)
:arrow_up:

Continue to review full report at Codecov.

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

Thank you. However, please do not add a new Kconfig for this as we already have the needed information available in the devicetree. I would prefer a solution like what is done in the AT45 SPI flash driver:
https://github.com/zephyrproject-rtos/zephyr/blob/140837ce3ac6ba6ac01d804ebd40c8aaf00a3011/drivers/flash/spi_flash_at45.c#L48

Thank you. However, please do not add a new Kconfig for this as we already have the needed information available in the devicetree. I would prefer a solution like what is done in the AT45 SPI flash driver:
https://github.com/zephyrproject-rtos/zephyr/blob/140837ce3ac6ba6ac01d804ebd40c8aaf00a3011/drivers/flash/spi_flash_at45.c#L48

Thanks for the tip! Done.

@semihalf-niedzwiecki-dawid We usually don't have Change-Id in the Zephyr commit logs. Also, the commit could use a brush-up to reflect that no new (K)config was introduced.

@semihalf-niedzwiecki-dawid We usually don't have Change-Id in the Zephyr commit logs. Also, the commit could use a brush-up to reflect that no new (K)config was introduced.

Sure, I did something odd. Thanks for the advice.

@henrikbrixandersen do you know who could be added as a reviewer?

Thanks a lot.

Would anybody be able to merge the PR?

Would anybody be able to merge the PR?

We are currently in feature freeze for v3.0.0. It will be merged once the merge window reopens.

Would anybody be able to merge the PR?

We are currently in feature freeze for v3.0.0. It will be merged once the merge window reopens.

Great, thanks :-)

It is possible to merge the PR now?

It is possible to merge the PR now?

We're still in feature freeze.

Ahh ok, thanks for the info. Where can I check the status?

Ahh ok, thanks for the info. Where can I check the status?

The release schedules are on https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management but v3.0.0 was postponed for a week.

Please remove the dead code from the driver and remove the Gerritt Change-Id: from the commit message. Otherwise LGTM.

Done.


Amend Place Cache to use Freecen2Place

A new Freecen2PlaceCache has been created that co-exists at this time with the PlaceCache. Selection is to be based on a system variable config.freecen2_place_cache = MyopicVicar::MongoConfig['freecen2_place_cache']


Run at startup, not login

Will this crate run the specified executable at startup or only when a user logs in?

user logs in


Startree document

This blog is very comprehensive.
https://engineering.linkedin.com/blog/2019/06/star-tree-index--powering-fast-aggregations-on-pinot
However there is no documentation to guide user how to use startree, like config is segment generation.

We have added a star-tree page: https://docs.pinot.apache.org/basics/indexing/star-tree-index


Bugfixes: "I'm not the Break Man" edition

Renamed example site name to "ContactMap.org: 2D and 3D Visualization"
Added an initial set of instructions when no data is loaded.
Added footer.
Added restriction on file upload for example site.
Recolored NGL to use black for distance label and red for distance line.
Renamed 'Res.' to 'Residue' for node size slider.
Anchoring example site buttons to bottom for a more consistent look.
Added button on ChellSlider component to reset slider to the default value.
Fixed -1 showing up as the default value for "Top N Predictions to show" slider.
Changed NGL hover text to only show residue number and single letter code.
Changed ContactMap hovers text to also show single letter residue code.
Lowered settings panel opacity.

https://www.youtube.com/watch?v=V3OiuIDwXtg

 Bugfixes from Nick/Chris catchup!

Codecov Report

Merging #117 into master will decrease coverage by 0.5%.
The diff coverage is 79.61%.

@@            Coverage Diff             @@
##           master     #117      +/-   ##
==========================================
- Coverage   83.69%   83.18%   -0.51%
==========================================
  Files          56       56
  Lines        1895     1951      +56
  Branches      346      375      +29
==========================================
+ Hits         1586     1623      +37
- Misses        307      323      +16
- Partials        2        5       +3

Impacted Files
Coverage Δ

src/data/Chell1DSection.ts
100% <ø> (ø)
:arrow_up:

src/component/widget/ChellRadioGroup.tsx
100% <ø> (ø)
:arrow_up:

src/data/PlotlyData.ts
100% <ø> (ø)
:arrow_up:

src/helper/ResidueMapper.ts
100% <ø> (ø)
:arrow_up:

src/container/SpringContainer.tsx
62.96% <0%> (-2.43%)
:arrow_down:

src/component/widget/ChellTooltip.tsx
33.33% <0%> (-1.45%)
:arrow_down:

src/context/CellContext.tsx
75% <100%> (-25%)
:arrow_down:

src/component/FeatureViewer.tsx
100% <100%> (ø)
:arrow_up:

src/component/InfoPanel.tsx
30.23% <100%> (ø)
:arrow_up:

src/component/widget/SettingsPanel.tsx
100% <100%> (+5.26%)
:arrow_up:

... and 34 more

Continue to review full report at Codecov.

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


Source control diff views for Index and Working Tree remain open after commit

VSCode Version: 1.13.0
OS Version: Windows 7 SP 1 and 10 RS 2

Steps to Reproduce:

Create a folder
Git init
Add a file with some text
Commit the file to source control
Make a change to the file
Click on the file change in source control to open the diff view
Commit the change

The (Working Tree) or (Index) diff view tab will remain open until manually closed.  While working, it doesn't take long before having to stop and manually close a large number of unneeded tabs that are in the way so I can see what I'm actually working on.

These tabs now open as unpinned, so they will eventually go away.

I'm confused as to how this is a positive change, and I've never witnessed them going away on their own.  Previously, they did, as soon as they were no longer relevant.  Why would you intentionally persist diff views that are no longer needed?
Would it be possible to add a switch to change the behavior back?  This either winds up adding extra steps every time I commit something or littering the tab bar with diff views over time that I don't need for a feature I honestly don't understand the purpose of.
This has been ongoing since 1.12 released.  I waited until 1.13 because it looked like #26184 would correct this behavior, but I'm not seeing that in working with it.

Working with it just now, not only do the working tree tabs not clear on their own, if I don't manually close them, they sometimes get stuck and show the previous diff when I click on that file in source control again.  They also appear to somehow become open editors, though I've not figured out a specific way to replicate that yet, but both of the files I've been working on just now did that.
Should that be a separate issue?  Should I reopen this issue as a feature request?

Did you configure the workbench.editor.enablePreview setting? If that setting is disabled, yes they will stick around. Otherwise these tabs will be unpinned, which means that they will go away as soon as a new unpinned tab comes up.

I've not modified workbench.editor.enablePreview, it's still set to "true".
I've done some more messing around with it, and I see the behavior you're speaking of; if they remained unpinned, that would be fine.  I've opened up two other issues showing that they don't, but I agree that those are separate issues.  If the behavior where those tabs become opened can be corrected, I think that would solve my issues.
Thank you for helping me figure this out.


Transform Rules troublshooting - link to evaluation explanation

I found that the fundamental information about Transform Rule evaluation might be missed on the summary page, especially when troubleshooting - so I've added a link to it from troubleshooting.

Thanks, @simon-says!
I've updated the text a bit.


Update README.md

Pull request description
Checklist (choose whats happened)

[ ] breaking change! (describe)
[ ] tested locally
[ ] tested on cluster
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

Breaking changes

Changes

Fixes

This was a dummy PR.


port (most) globals to their own webpacker file

I rule and have completed some work on Case Manager that's ready for review!
Make a dent in the application.scss file by porting over some of the top-level element styling like html/body/main.
There are a couple spots where this smashes into bootstrap global styles; I figure easiest strategy is to duplicate them for now in both places, mark them as duplicative, and then take them out when we finally remove bootstrap from sprockets.
This pull request makes the following changes:

move the global styles out of
dupe a few global styles that have to stick around for bootstrap reasons

View diff:

(Note that text styling for h1, general text, and link coloring is the same.)
It relates to the following issue #s:

Bumps #1854

For reviewer:

Adjust the title to explain what it does for the notification email to the listserv.
Tag this PR:

feature if it contains a feature, fix, or similar. This is anything that contains a user-facing fix in some way, such as frontend changes, alterations to backend behavior, or bug fixes.
dependencies if it contains library upgrades or similar. This is anything that upgrades any dependency, such as a Gemfile update or npm package upgrade.

If it contains neither, no need to tag this PR.

Codecov Report

Merging #2113 (3a8a2e6) into main (b16b48d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2113   +/-   ##
=======================================
  Coverage   96.14%   96.14%
=======================================
  Files          79       79
  Lines        1844     1844
=======================================
  Hits         1773     1773
  Misses         71       71

Continue to review full report at Codecov.

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

Codecov Report

Merging #2113 (3a8a2e6) into main (b16b48d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2113   +/-   ##
=======================================
  Coverage   96.14%   96.14%
=======================================
  Files          79       79
  Lines        1844     1844
=======================================
  Hits         1773     1773
  Misses         71       71

Continue to review full report at Codecov.

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


Tanky zombie does insane amount of dmg

I am in doubt if this is a bug or intended about the tanky zombie, when i made a pawn got meele hit the zombie, it killed my pawn in one hit, the damge indicator under health; Torso; 0/48: zombie bite teeth: 256.4... is it intended that you should absolutely not engage with a tanky zombie in a meele fight, or is it a bug?

Intented. They are insanely powerful to knock down walls. Don't melee them.


Fix a bug in the CMake script.

PR [#207] introduced a check for setting the right suffix to the library, depending on the target OS:
https://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L7://github.com/open-quantum-safe/oqs-provider/blob/823f3178dd50eeb5febf29eb82680400c4d9e887/oqsprov/CMakeLists.txt#L61-L79
However, mixed with PR [#201] and the OQS_PROVIDER_BUILD_STATIC option, the library may be suffixed with the wrong extension: we may end up with a static library named oqsprovider.dylib, even if it's an archive:
$ cmake -GNinja \
    -DOQS_PROVIDER_BUILD_STATIC=ON \
    -B build
$ cmake --build build
$ file build/lib/oqsprovider.dylib
build/lib/oqsprovider.dylib: current ar archive random library
$ # ^ should be named `oqsprovider.a`!

The check mentioned above is only relevant when oqsprovider is built as a module.
This commit fixes this bug and introduces a check in the CircleCI jobs to verify that oqsprovider.a is actually produced.
#201
#207

Hmm -- CI fails... And the macOS log makes we wonder (again): Why in the world is liboqs again getting built using OpenSSL111? It seems brew _de_installs openssl@3 (??) Also, this seems to introduce even more "suffix surprises": "macOS-static" building a ".dylib"??

@thb-sb Linux again ... builds a .so so the new test for .a fails...


Some problems with setting null (but not only)

@arqex note that only one test is failing. See the difference.
Proposition:

Let's fix failing test.

What's the difference between String and Numeric here? Add tests (maybe in other places, too) for this difference.

Consider rename "Update" tests to "Set" tests and add really "Update" (from different types to different types?) tests.

Are you sure to use non-strict == operator in places such as here? (Problem is there but maybe not only.)

Point 4 for tests (assert.equal vs assert.strictEqual). And I see a weird assert.deepEqual( updated.a, undefined );.

Add frozen.set('prop', null); test.

Waiting for six replies. Thanks.

Hey @kuraga
Long time no see! :) I am glad you are still using freezer.
You are right about that non-strict comparison, it should be strict. I will update it and merge some of your tests, I think they are really valuable.
As for all that mess about deepEqual or equal or strictEqual, it is something that I should improve but I am so lazy about it. Some of the tests are made copying and pasting previous one, that's why there are some no-sense comparison in there.

@arqex the main issue is that changing undefined value to null value doesn't work... I know that problem is https://github.com/arqex/freezer/blob/1c17fe3743e45bf7934a585ab11d202b2741c992/src/mixins.js#L40 (because undefined != null is falsy) but I can't produce a test for this (I see that current PR is wrong)...

Ahaaa, I got it (it fails):
    it( "Update a undefined value to null", function(){
        data = data.set('a', undefined);
        data.set('a', null);

        var updated = freezer.getData();

        assert.deepEqual( updated.a, null );

        assert.notEqual( updated, data );
    });

@arqex I updated code and text, re-read, please.

Thanks @kuraga
Currently I am on holidays, I'll have a look at it when I came back :)

Hi Kuraga,
Thanks for the effort to make freezer.js a better library, your help is much appreciated!!
The first test you have created is failing because the first set is a no-op. Since the attribute a is already 1, nothing is changed and anotherData === data.
// this is doing nothing
var anotherData = data.set('a', 1);

// `data` is still inside freeezer so this is updating `a`
// in the current freezer state
data.set('a', 'another');

// so this will fail
assert.strictEqual( updated.a, 1 );

The second test passes though:
// This update freezer's state
var anotherData = data.set('a', 'cat');
// This is hardly discouraged. `data` is now detached from freezer.
// Never try to modify detached data.
data.set('a', 'another');

// This is passing because the second `set` wasn't done
// inside the freezer store, and it changed nothing.
var updated = freezer.getData();
assert.strictEqual( updated.a, 'cat' );

The first test you have created is failing because the first set is a no-op. Since the attribute a is already 1, nothing is changed and anotherData === data.

Oh, @arqex , NOW I really see! Thanks!
P.S. I just don't know: is this documented/tested?


Genmod models '--vep' option throws exception

When I try to run Genmod models with --vep, it throws an error and aborts:
genmod.commands.annotate_models: 'list' object has no attribute 'split'
Aborted!

If I use the same file with bcftools +split-vep to extract the gene field from VEP and use this field in de "keyword" option for Genmod it works fine. (But intron/exon info is lost this way)

Hi @bartcharbon , thanks for considering genmod!
Ok I will have a look at this.

Hi @bartcharbon , thanks for considering genmod!
Ok I will have a look at this.

@bartcharbon could you provide a small example from the file where this error occur? There are several test cases using VEP and we use it all the time so I am a bit curious about what is going on.

@bartcharbon could you provide a small example from the file where this error occur? There are several test cases using VEP and we use it all the time so I am a bit curious about what is going on.

Hi @moonso
Thanks for looking into this so quickly!
I attached a minimal example zip file (since github does not support vcf and ped attachments)
the command I use:
genmod models ./example.vcf -f ./example.ped --vep -p 4
We are using version 3.7.3 of Genmod.
For VEP we use version 100
example.zip

Hi @moonso
Thanks for looking into this so quickly!
I attached a minimal example zip file (since github does not support vcf and ped attachments)
the command I use:
genmod models ./example.vcf -f ./example.ped --vep -p 4
We are using version 3.7.3 of Genmod.
For VEP we use version 100
example.zip

I did some more digging myself, and I think I identified the problem:
I think this HgvsP notation in the CSQ INFO field is causing the problem: NP_001116849.1:p.Gly78=
If I remove the "=" sign the problem is solved.
I guess that an "=" as part of a INFO value is not allowed, so the issue might be in VEP instead of Genmod.

I did some more digging myself, and I think I identified the problem:
I think this HgvsP notation in the CSQ INFO field is causing the problem: NP_001116849.1:p.Gly78=
If I remove the "=" sign the problem is solved.
I guess that an "=" as part of a INFO value is not allowed, so the issue might be in VEP instead of Genmod.

Yes that is correct, it should not be allowed in the INFO field. Good find! Open issue at VEP then :)

Yes that is correct, it should not be allowed in the INFO field. Good find! Open issue at VEP then :)

I found an exisiting issue:
https://github.com/Ensembl/ensembl-vep/issues/430
The problem is not in VEP but in the configuration we run it with, we run with "--no_escape" which leads to this behaviour.

I found an exisiting issue:
https://github.com/Ensembl/ensembl-vep/issues/430
The problem is not in VEP but in the configuration we run it with, we run with "--no_escape" which leads to this behaviour.


batch transaction submission for movement

Voyager assumes it's possible to submit many messages in one transaction. Investigate if this is possible on movement.

this is indeed possible, see https://github.com/unionlabs/union/blob/28952f6597f0dcade8403894fabfe4465093b264/voyager/modules/transaction/aptos/src/main.rs#L206


Dlive.tv

Addon Manifest URL
https://dlive.unlimited-fun.xyz/manifest.json
Addon Description
View livestreams from dlive.tv

This addon is no longer maintained. See this for more info.

Closing because this addon is no longer maintained and has been offline for a while now.