Provide similar API across Platforms

Right now, the usage in manim/mobject/svg/text_mobject.py is this:
        if sys.platform.startswith("linux"):
            manimpango.unregister_font()
        else:
            manimpango.unregister_font(str(file_path))

It would be nice to pull this check into unregister_file itself.

Two things:
Either:

https://github.com/ManimCommunity/manim/pull/939 should be waited for this to be implemented and it can be part of v0.1.8 release.
Or merge that PR, and later add this and tag it v0.2.0 so that things don't break.
What do you think @leotrs? What can be done?

Two things:
Either:

https://github.com/ManimCommunity/manim/pull/939 should be waited for this to be implemented and it can be part of v0.1.8 release.
Or merge that PR, and later add this and tag it v0.2.0 so that things don't break.
What do you think @leotrs? What can be done?

Number 2 sounds like it breaks fewer things so let's go with that.

Number 2 sounds like it breaks fewer things so let's go with that.


[flake8-type-checking] Allows TC001-004 to quote more expressions

This idea came up during the discussion of #14676
Summary
This adds a new more generic setting to replace quote-annotation to allow TC001-004 to be more liberal about moving imports into type checking blocks.

Allowing cast type expressions to be quoted is a more conservative approach to TC006. (quote-type-expressions = "safe")
Allowing annotated type alias value expressions to be quoted is a more liberal approach to TC007. (quote-type-expressions = "eager")
quote-type-expressions = " balanced" matches the old setting quote-annotations = true, except it also includes what "safe" does, i.e. casts.

Test Plan
cargo nextest run

Interesting, thanks for working on this! My overall reaction is that this is a good idea. Do we need another configuration knob, though? What's the profile of somebody who wants their annotations to be quoted if it removes the need for a runtime import, but doesn't want the first argument to cast() quoted even if it would remove the need for a runtime import?
I get that the quote-annotations setting isn't particularly well named for the purpose, because the first argument to cast() is not an annotation. But I think it's much less confusing to users if we keep the number of configuration options to a minimum. So I would simply expand the quote-annotations option so that it also quotes the first argument to cast() (where it would remove the need for a runtime import), and expand the docs for TC001-004 to state that this is the new behaviour, and expand the docs for the setting to state that this is the new behaviour. The only disadvantage I can think of, other than the name of the setting not being ideal, is that this would count as an expansion in scope of these rules -- so we might have to make the change as part of the next minor release rather than in a patch release.
It looks like your patch already does the right thing for all of these, but if you haven't already added some, it would be great to add tests for them, because it would obviously be incorrect to quote either of them:
from typing import Annotated, TypeAlias
from expensive import Foo
from expensive2 import Foo2

Y: TypeAlias = Annotated[Foo, "metadata"]
some_object = Y()

class Z(Annotated[Foo2, "metadata"]): ...

Interesting, thanks for working on this! My overall reaction is that this is a good idea. Do we need another configuration knob, though? What's the profile of somebody who wants their annotations to be quoted if it removes the need for a runtime import, but doesn't want the first argument to cast() quoted even if it would remove the need for a runtime import?
I get that the quote-annotations setting isn't particularly well named for the purpose, because the first argument to cast() is not an annotation. But I think it's much less confusing to users if we keep the number of configuration options to a minimum. So I would simply expand the quote-annotations option so that it also quotes the first argument to cast() (where it would remove the need for a runtime import), and expand the docs for TC001-004 to state that this is the new behaviour, and expand the docs for the setting to state that this is the new behaviour. The only disadvantage I can think of, other than the name of the setting not being ideal, is that this would count as an expansion in scope of these rules -- so we might have to make the change as part of the next minor release rather than in a patch release.

I do think we want some additional knobs, but I do agree that having three separate toggleable switches is awkward, that's the main reason I called this half-baked. I think a sliding scale could make sense, at the low end you would only quote casts, then casts and annotations and finally annotated type aliases at the high end. I do agree that there's likely nobody that would have e.g. annotations turned on but casts turned off, but I do think it's likely that there are people that want to have casts turned on, but annotations and type aliases turned off.
Especially type aliases is something some people might not want to ever turn on if they have a bunch of them in a single module that is used by other modules at runtime. They could just turn off TC001-004 in that module, but that seems awkward.
Maybe we add a new setting and deprecate quote-annotations. We can call it quote-type-expressions with settings of none, safe, balanced and eager for none, just casts, casts and annotations and everything. That way we leave ourselves the option to add additional things to the safe category in the future.
Then we can emit a warning for people that have preview turned on and still use the old setting.

It looks like your patch already does the right thing for all of these, but if you haven't already added some, it would be great to add tests for them, because it would obviously be incorrect to quote either of them:
from typing import Annotated, TypeAlias
from expensive import Foo
from expensive2 import Foo2

Y: TypeAlias = Annotated[Foo, "metadata"]
some_object = Y()

class Z(Annotated[Foo2, "metadata"]): ...

I do plan to add more tests. I added just enough to make sure that the type alias part works correctly, since that is the most difficult one to get right.

@AlexWaygood @MichaReiser Any inputs on the idea of using a sliding scale for configuring what kind of type expressions we're allowed to quote? This would be similar in spirit to lint.flake8-tidy-imports.ban-relative-imports where you can choose between all and parents, except you can choose between four options.

Sorry for the delayed response. It makes me sad to have to deprecate a configuration setting, because it's quite disruptive for our users. However, I think your plan makes sense; I can't think of a better one. I agree that there is probably a group of people who want to quote their cast() type expressions when it can remove the need for imports, but never want to quote their parameter/return/variable annotations. The crucial difference is that type expressions passed to cast() are not introspectable at all, whereas annotations are introspected by many runtime tools.
We can bikeshed over the names of the sliding scale, but your overall plan sounds good to me.
We'll probably have to do the deprecation as part of the next minor release (I think probably in early January, but not sure), but there's no harm in working on a PR now. It'll make the minor release less frantic if it's already ready and has already been reviewed :-)

@AlexWaygood My concern are imports that will be flagged by TC004 for runtime use at the same time as the missing __future__ import is flagged, fixing the future import gets rid of the TC004 violation, so if the fix moved the imports you now have TC001-003 violations, so you need another run with fixes to move them back, which might mess with the ordering/formatting of the imports, when there was never a need to mess with the imports to begin with.
Which I assume is also the reason why TC001-004 have been repurposed by ruff to do the quoting of the annotation and moving of the import in a single step, rather than use a separate TC2xx rule to flag annotations like the flake8 plugin does.
That being said, the __future__ import use-case is certainly not as bad as the quoting use-case, since it's less likely to actually end up being a problem, unless you intend to switch to adding the future import, in which case the imports should already be wrong unless  you also intend to adopt the TC rules at the same time. So I'm fine with leaving things as they are.

@AlexWaygood My concern are imports that will be flagged by TC004 for runtime use at the same time as the missing __future__ import is flagged, fixing the future import gets rid of the TC004 violation, so if the fix moved the imports, you now have TC001-003 violations, so you need another run with fixes to move them back, which might mess with the ordering/formatting of the imports, when there was never a need to mess with the imports to begin with.

Running Ruff once with --fix should never lead to new Ruff errors being emitted if the new errors can be autofixed. Ruff runs all rules in a loop until there are no fixes left to apply. If you have a minimal repro of a snippet where running Ruff once with --fix leads to new Ruff violations that can be autofixed, meaning you have to run Ruff a second time with --fix, that's a bug -- please file an issue! :-)

@AlexWaygood Sorry, I was being a bit unclear. My concern is the redundant work that ruff does for the consecutive fixes and potentially moving the imports to a slightly different location in the code, since the fixes for TC001-004 always move imports to the top of the file/to a type checking block just below all the imports at the top, regardless of where they were originally defined.
So it's more that it might create a bit of mess, that you will then have to revert, not so much that it will result in broken code or end up in an unfixable state.

I'm still not convinced that the current situation is that bad. (It's all a bit hypothetical -- it's hard to say without concrete examples to look at where this actually creates a mess. And the redundant work that Ruff does doesn't concern me much unless we can demonstrate that there's a measurable speedup from doing something differently -- which I'm sceptical of :)
But this all feels like a bit of a tangent anyway. Even if it is desirable to make the way these violations are fixed be configurable, this could easily be done with a separate configuration option.

@AlexWaygood I implemented the change to a sliding scale using the names I suggested. If we wanted to bikeshed on the names, we should probably do it sooner rather than later.
I think there is a case to be made for more explicit names that directly hint at what will be quoted, although I think the more generic names give us more flexibility with where to draw the line, since there are still some type expressions we don't currently look at for any of the settings (like e.g. X in x = list[X]("abc")) but even beyond that, there may be additions to the language/stdlib in the future, that lead to additional type expressions in the semantic model, where it might make sense to do something. Like with typing.cast. So needing to change the name of a setting or sticking with inaccurate names every time that happens seems bad to me.
But even with the more generic names, there are probably better names, that better reflect the intent of each setting. So I am open to suggestions.


[ASK] Can i using field back end to front end ?

how can i use field backend to front end ? i hope can reuse your vendor css and js.
Thanks.

The UI of laravel-admin is based on AdminLTE, which is designed for admin interface, it's inconvenient to put into the front end.


cleanup and upsert verfication added to the transport tests

#204 @prestonvasquez  I have added the required functionality now , can you check if it is working as expected. let me know if further changes are required or if it's not working as expected.

@ash-kamrip There is one minor linting error:
File is not `gofumpt`-ed (gofumpt)

Can you run make fmt and push the changes? You may need to install https://github.com/mvdan/gofumpt

Sure @prestonvasquez  is the code looking good though ?

Sure @prestonvasquez is the code looking good though ?

Yes the code is perfect!


Check if user has actually denied permissions

Is your feature request related to a problem? Please describe.
It seems like there is no way to check whether the user has physically denied permissions or has just not been asked before with Awesome Notifications, which is frustrating as I don't want to ask the user about permissions if they have already declined them, but there's no way to differentiate between users who have denied permissions and users who have not been asked yet.
Describe the solution you'd like
Expose this information through awesome notifications.
Describe alternatives you've considered
A flag in shared prefs to track whether the user has been prompted to enable notifications before

Closing this issue as I have actually found a package that provides access to this information: https://pub.dev/packages/permission_handler


Changes to make this notebook work:Use EventSourceFactory. Corrected reading of camera geometry.

Is this really necessary? the event_source(filename) function is just a wrapper that creates an EventSourceFactory and it's product, so it seems this change is redundant, unless I'm misunderstanding something.

Perhaps it can be done with event_source, and I misunderstood the source of
the error related to the reading of camera geometry (the missing
'subarray'). In that case only the second change is needed.
A.
On 23 April 2018 at 13:59, Karl Kosack<EMAIL_ADDRESS>wrote:

Is this really necessary? the event_source(filename) function is just a
wrapper that creates an EventSourceFactory and it's product, so it seems
this change is redundant, unless I'm misunderstanding something.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cta-observatory/ctapipe/pull/716#issuecomment-383550076,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANghOvkGeNQyG3fWjIMKobh5JY9q1Fb3ks5trcIbgaJpZM4TexP_
.

--
Abelardo Moralejo Olaizola
Institut de Física d'Altes Energies
Tel : +34 931641662
Fax: +34 935811938
Avís - Aviso - Legal Notice - (LOPD) - http://legal.ifae.es
--
Avís -
Aviso - Legal Notice - (LOPD) - http://legal.ifae.es
http://legal.ifae.es/

This PR inspired another PR #724 which not only fixes this notebook but also 2 other notebooks.
I believe when #724 is merged this here can be closed.


Allow maintiners to update PR

Reverted. See comment in pull request: https://github.com/bazel-contrib/publish-to-bcr/pull/93


Tutorial.py crashes due to client = carla.Client('localhost', 2000) not working in Carla 0.9.12 and 0.9.11

What i did i download the exe from the github repository, pip installed all the requirements.txt and then ran tutorial.py and then it gave the error:
destroying actors
Traceback (most recent call last):
  File "tutorial.py", line 43, in main
    world = client.get_world()
RuntimeError: time-out of 2000ms while waiting for the simulator, make sure the simulator is ready and connected to localhost:2000

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "tutorial.py", line 129, in <module>
    main()
  File "tutorial.py", line 122, in main
    camera.destroy()
UnboundLocalError: local variable 'camera' referenced before assignment

and so i tried checking which line of code was causing the error and to my surprise it was
client = carla.Client('localhost', 2000)

as i did a try-except on it to see if it was working or not.
so to fix this i tried pip installing carla and then uninstalling it and then installing it again, i tried using carla 0.9.11 but i came across the same problem, i also manually set the port to 2000 and it still didn't connect but the weirdest part was manual_control.py is working and so is generate_traffic.py

On next line:
client.set_timeout(2.0)
change 2.0 to 5.0 and see how it works.


PDF Preview in VS Code

I know a corresponding issue already exists: #10821.
The issue however way locked and moved into the backlog.
While I think the decision was correct at the time (the PDF plugin did not work in electron > 3) I vote to reopen this issue.
My reasoning is that newer electron versions (changelog v9) enabled the PDF plugin again.
Current extensions providing a PDF viewer have to ship PDF.js or a similar solution.
Providing this natively should yield better performance and a better out-of-the-box experience while only needing small changes to the code.

I kindly disagree. I have already pointed out what benefits native support for the PDF plugin brings with it. The only required change would be to pass plugins: true in the options object to BrowserWindow and then extensions would be able to use the native PDF viewer which has multiple benefits in comparison to pure js-based pdf viewers.

@mjbvz would you mind explaining your decision?

We try to keep VS Code lean and we think the functionality

Pretty much this... plus the inevitable long tail of pdf related bugs

As far as I know it would not require any changes beside adding the above flag. The PDF viewer is bundled by electron anyhow so it would not make the executable bigger. All PDF related bugs (of which there are only a rarely some inside the electron repo) could instantly be labeled as an upstream issue and do not need to bother VSCode directly. Implementing any handling of PDF files and an optional nice UI would still be the task of extension developers. However they would not need to bundle pdf.js or a similar library anymore but would instead be able to use the PDF viewer which electron provides but is only disabled - the reasons of which were only relevant for electron < 3 and are not applicable anymore.

Sadly I am not sure you understood the goal of the feature request... :/


complete open grants application

Grant Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledged the Terms and Conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
[x] The initial PR contains only one commit (squash if needed before submitting your PR).
[x] The grant will only be announced once the first milestone has been accepted.

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

@Noc2  Thanks for adding that for me. I've updated the milestones and added the deliveries as well.

There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.
Enabling a user direct download from their browser will not require a server. Similar to the original collector we will create a CSV file for the user in the browser that they can download. I am currently exploring how to do something similar in JSON format. (I might just open a new tab with the JSON in it if there is no better alternative.)
As for IPFS if we remove the need for a server. Fleek allows for NEXT.js applications to run on IPFS https://blog.fleek.co/posts/fleek-nextJS.

There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.

@jackson-harris-iii So just to double check that I understand correctly: does that mean you're not planning to use the code from the staking rewards collector anymore?

There won't be a "back-end" any longer. The code for the original collector has been refactored into utility functions.

@jackson-harris-iii So just to double check that I understand correctly: does that mean you're not planning to use the code from the staking rewards collector anymore?

@mmagician currently the staking rewards collector code is located in the src/utilities folder of staking rewards viewer and is the core for the data retrieval, results shaping, and csv creation.
There is some refactoring being done so that it can work solely in a browser. I could use it 100% as is, if required, but that would remove the possibility of being entirely on ipfs. The original collector relies in a few nodejs modules, but since it's all JavaScript that are alternatives I can use to make it all work client side.

The ideal scenario, IMO, is code reuse. There are likely going to be updates to the original collector code (either extra features, or just keeping up to date with polkadot APIs) and it would be great if your frontend supported these changes out-of-the-box (perhaps have it as a sub-module? or reference it as an npm package?)
Do you foresee a scenario for this grant where part of the work would be refactoring the original tool s.t. it supports both the CLI and your use case better? Perhaps you could have a chat with @jonasW3F to see if you'd align on the outcomes (he's also very much interested in the frontend, btw).

@jackson-harris-iii Sounds good to me. Could you update the PR? I think the application still contains for example: “Back End: Next.js/Vercel/IPFS”

I would also prefer that both versions stay synced and that the CLI version stays functional. Currently, there are no immediate updates planned, but that can always change. I am not a programmer, so I cannot judge the quality of my code but certainly, it could be improved and refactored. So, I would be open to include PRs from @jackson-harris-iii, which make the code functional for the front-end and leave the CLI version intact.

I would also prefer that both versions stay synced and that the CLI version stays functional. Currently, there are no immediate updates planned, but that can always change. I am not a programmer, so I cannot judge the quality of my code but certainly, it could be improved and refactored. So, I would be open to include PRs from @jackson-harris-iii, which make the code functional for the front-end and leave the CLI version intact.

Hi @jonasW3F , After reviewing your comments I have given some thought on how I think we can proceed with keeping the two repos synced. Here are my notes on accomplishing that.

The CLI version requires node.js, it will not function in the browser. A browser-only version would be required in order to use IPFS for the entire application.
Using vercel,  an ec2, or some other server we could host a version that keeps the CLI and front-end tool using the same code base. (vercel has generous free-tier (hobby) rate limits.)
If we have a hosted version the front-end could be accessible via IPFS, but it would always require a connection to a hosted server if the CLI version and front-end tool are coupled together. We could use Fleek for this. (More exploration will be required)
As for keeping the two versions synced my thoughts are that it would require an input to let the tool know which environment is making the request. This could be added to the config file and submissions from the front-end. The front end can also create the csv or json download on demand so the files are generated on the client-side instead of each time the tool is used. (This removes any potential storage management and reduces bandwidth usage.)
-Once the modifications are made to the original repo, the front end could require it as a dependency. This would allow CLI users access without requiring the front-end and the front-end would remain coupled with the original repo.

@jackson-harris-iii, I personally think that it’s not mandatory to keep both in sync. Potentially you can reuse some of the code and create a package for it, so it’s easier to maintain it for both solutions, but it ultimately depends on what you plan to do (and I’m not sure there is a lot of overlap). If you create a back-end, I think it definitely would make sense to also create your own database for performance reasons and no longer to rely on querying public end-points for free. For example, if you have the CLI version deployed on ipfs and a lot of users access this version via the same ipfs server, the public endpoints will quickly limit the access via this ipfs server and it stops working.

@jackson-harris-iii, I personally think that it’s not mandatory to keep both in sync. Potentially you can reuse some of the code and create a package for it, so it’s easier to maintain it for both solutions, but it ultimately depends on what you plan to do (and I’m not sure there is a lot of overlap). If you create a back-end, I think it definitely would make sense to also create your own database for performance reasons and no longer to rely on querying public end-points for free. For example, if you have the CLI version deployed on ipfs and a lot of users access this version via the same ipfs server, the public endpoints will quickly limit the access via this ipfs server and it stops working.

@Noc2 My current understanding is that IPFS would only host the tool and possibly the site. The CLI would need to be downloaded locally and run from the user's machine, the same is true for the front-end.

As for maintainability, as it stands it would be easier and less prone to error if the two were to be separate. As for performance a lightweight virtually static front end using the public Coingecko API would be the most performant. The Coin Gecko API hasmany projects in the space using it. The calls to the API would be made from each client (both CLI and front-end). This would allow for every user to make up to 100 requests per minute from their browser or command line.

As for building out a database, backend, and systems to support it I'd say that is getting a bit out of scope for the current proposal. However, I believe it is not needed.  The most cost-effective, performant, secure, and highly available architecture would be using a static site generator and serverless allowing the individual clients to handle queries to the Coingecko API.

@jackson-harris-iii Thanks for the update. Could you still add the deliveries 0a - 0d to your milestone, see and potentially combine milestone 1 and 2?

@Noc2 I added the additional deliveries to the proposal.

@Noc2 I added the additional deliveries to the proposal.

Thanks. But now milestone 1 doesn’t contain any deliveries. Could you update the PR again?

@Noc2 I added the additional deliveries to the proposal.

Thanks. But now milestone 1 doesn’t contain any deliveries. Could you update the PR again?

Sorry about that, hadn't had my tea yet, changes made! I also moved the IPFS to future plans. There are a few different ways to go about it,  and some of the specifics I'd like to discuss once we have a live version. (Account ownership, pinning, etc.)

@jackson-harris-iii I now realise the application still contains two milestones. Didn't you mean to merge them into one in your last update? As @Noc2 mentioned, this would also be preferable for us. Ideally you'd deliver the tests with the application, and you can integrate feedback during the delivery process.


Question about the input shape of UNETR

Dear Authors,
I have a question about the structure of UNETR.
I am now trying to segment a 3D volume image of 512x512x400~512x512x700.
Since the embedding is done in a size of 768, is it possible even if the input is variable (eg, using images of different sizes above)?
Or is it necessary to cut into patches of (eg, 96,96,96) and then cut them into patches for the vision transformer structure?

Hi @soribido , the input image shape can be variant, e.g., different number of slices.
The size of  (96x96x96) is the patch size, that mean, when training/validation/inference, it use a sub-volume as input.
It doesn't need to crop ahead of running the training/valdiation/testing, the data transformation will do the crop when loading the data from dataloader.
https://github.com/Project-MONAI/research-contributions/blob/c148c436cf675e568649aa07763002cc0ab09ee8/UNETR/BTCV/utils/data_utils.py#L84
If resources allows, you can use larger patch size, but (96x96x96) is still recommended here, it's a moderate size for training CT scans.


Support python3

Currently the setup.py build process fails at the extension building step.
The error message is:
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
With only warnings before this.
Is python3 support planned?

It's not only planned, it's implemented! I just never got round to fixing the last few bugs.
I've made it available in my own repo for now. Can you try this:
git clone -b bw-py3 https://github.com/walshb/pyavroc.git
cd pyavroc/
PYTHON=python3 ./clone_avro_and_build.sh

Thanks, that is great. The building works just fine and all tests pass.
I'll let this issue open until I have time to actually test it in some actual code to see if it works everywhere.

Sorry that it took me so long. I just tried it out more thoroughly and it works fine. Thank you!


Unavailable param file prevents individual preprocessor nodes from starting

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
I have setup the use of crop_box_filter node from autoware_pointcloud_preprocessor package using the individual filter launch file as follows:
<include file="$(find-pkg-share autoware_pointcloud_preprocessor)/launch/crop_box_filter_node.launch.xml" >
    <arg name="input_topic_name" value="pointcloud" />
    <arg name="output_topic_name" value="cropbox/filtered" />
    <arg name="cropbox_filter_param_file" value="$(find-pkg-share my_pkg)/param/crop_box_filter.yaml" />
</include>

Expected behavior
The topic cropbox/filtered contains cropbox filtered points and I can use it further down the perception stack to do clustering and object detection.
Actual behavior
The launch file setup above, doesn't start the filter node properly and I see the following warning on launch:
[WARNING] [launch_ros.actions.node]: Parameter file path is not a file: /opt/ros/jazzy/share/autoware_pointcloud_preprocessor/config/filter.param.yaml

And the topic cropbox/filtered is empty. Since I feed this topic to an instance of the euclidean clustering node, this is confirmed by the following message by the euclidean clustering node:
[component_container-6] [WARN] [1732860045.511208848] [euclidean_cluster]: Empty sensor points!

Steps to reproduce

Use the launch file as in the description
ros2 launch <path_to_launch_file>

Versions

OS: Ubuntu 24.04
ROS2: Jazzy
Autoware: main

Possible causes
The crop_box_filter_node.launch.xml sets a parameter filter_param_file here. However, that file doesn't exist in the config directory and in the code, I only see parameters from crop_box_filter_node.param.yaml being consumed.
The filter node does work correctly when the filter_param_file is initialized to point to any file that exists in the config folder. For example, if the above launch file is changed as follows:
<include file="$(find-pkg-share autoware_pointcloud_preprocessor)/launch/crop_box_filter_node.launch.xml" >
    <arg name="input_topic_name" value="pointcloud" />
    <arg name="output_topic_name" value="cropbox/filtered" />
    <arg name="cropbox_filter_param_file" value="$(find-pkg-share my_pkg)/config/crop_box_filter.yaml" />
    <arg name="filter_param_file" value="$(find-pkg-share autoware_pointcloud_preprocessor)/config/crop_box_filter_node.param.yaml" />
</include>

However, I think the argument filter_param_file should just be removed as that seems to be redundant.
Additional context
No response

Thanks for your contribution, the issue is solved by https://github.com/autowarefoundation/autoware.universe/pull/9525


Rules DSL: support path prefix and host header based destinations

Currently, the controller rules DSL supports specifying destinations with service names only, with the expectation that the user would be accessing the sidecar via the URL http://localhost:6379//api.
It needs to support additional forms of specifying the destination namely:
path prefixes: /api/v1/ratings/
host headers:
GET / HTTP/1.1
Host: ratings.mybookstore.local

In the host header case, the destination is actually empty (or can be extracted from the host header).
It would be good to have a destination of the form:
destination: {
 "name": "ratings" [mandatory]
 "host" : "ratings.mybookstore.local",
 "path" : "/api/v1/ratings"
}

where destination should have name and atleast one of host or path should be present.

I think I understand the requirement, but I'm wondering if extending the destination field is the right way to handle it. In my mind, the destination that the rule is referring to is just a service (e.g., "ratings"). A separate question is how we can tell when the destination is being called: is it some kind of path pattern or host header? I don't think the answer to that question changes the destination.
Currently, we have a default answer built into the code. If we allow this to be changed, I wonder if it's really a per-rule configuration, or if it's even necessary to allow more than 1 answer. In other words, would it make sense to say that calls to the ratings service via a host header should go to v1, while calls via a path should go to v2. Maybe we just need a way to configure how services are identified (e.g., host or path) in one place (special rule?), instead of repeating it in every rule.

That's a good point. To keep things simple, we could have a single destination config rule.
I wonder if we could apply the same principle to other aspects of the rule.

We can already support the host based routing. Host is just a header, so the rule just needs to include the following inside the match:
"match": {
  "headers": {
    "Host": "ratings.mybookstore.local"
  }
},

The path option will require an additional field. I believe the most logical place for this field would be inside the match definition:
"match": {
  "path": "/api/v1/ratings"
}

Opinions? @rshriram @frankbu

Path and prefix. As envoy supports both.
On Tue, Jan 24, 2017 at 11:39 AM Isaiah Snell-Feikema <
<EMAIL_ADDRESS>wrote:

We can already support the host based routing. Host is just a header, so
the rule just needs to include the following inside the match:
"match": {
"headers": {
"Host": "ratings.mybookstore.local"
}
},
The path option will require an additional field. I believe the most
logical place for this field would be inside the match definition:
"match": {
"path": "/api/v1/ratings"
}
Opinions? @rshriram https://github.com/rshriram @frankbu
https://github.com/frankbu
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/amalgam8/amalgam8/issues/367#issuecomment-274859329,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH0qd9dRhA6Zn2P6ElxplHb_tHNOnL9vks5rVikugaJpZM4KlbLY
.

--
~shriram

There is an issue that prevents

P2 - Needed for bookinfo

so in order to support matching on Host header, the rule needs to be created to match on the :authority header.  For example:
rules:
- priority: 1
  destination: reviews
  match:
    headers:
      ":authority": "my_header_value"
  route:
    backends:
    - tags:
      - version=v3

This rule would match for curl -i localhost:32000/reviews/health -H "Host: my_header_value"


stdin and stdout support with virtual console

Not sure if this is considered or is part of the featureset that you want to support.
In my experience, in real systems, it's often unrealistic to except existing software to be modified or rewritten to be made compatible with a pipeline.
Perhaps such support can be added as a plugin or a pipeline wrapper.
Overall, it is just an idle query since it is still alpha software.

Welcome @udnaan 🤗
I'm not quite if I understand your question at all. :disappointed_relieved:
Could you please explain a bit in detail what do you mean?

Let me look into it further before I make a fool of myself. My initial understanding was that you need to add explicit support to each step in the pipeline. I'll reopen if that turns out to be the case.


Flaky test

From time to time I get this test failure, seems to be a flaky one
=== Failed
=== FAIL: internal/dbgen/factory TestRandom_uint8 (0.00s)
    bobfactory_random_test.go:135: random[uint8]() returned the same value twice: 59

The reason for this is that uint8 has 256 possible values.
To test randomization, we generate 10 values and make sure the same value does not repeat. With 256 possible values, if my math is correct, there's a 16.3% chance that a duplicate will be generated.
To keep things simple, I'm going to make it 2 values, this should reduce the chance of duplicates to 0.4% and 2 values should be enough to test if duplicates are generated correctly.

This should have been fixed in v0.28.0 which was released on 2024-06-25


Set CARGO_LLVM_COV environment variable

So that nextest can detect if it's running wrapped by "cargo llvm-cov" and can use [profile.default-llvm-cov] settings instead of [profile.default]. This is done similarly for miri and makes sense since both increase running times.

Published in 0.5.17.


Incompatibility with jQuery 1.11.0 and/or jQuery UI 1.10.4

When creating the dialog, I receive:
Uncaught TypeError: Cannot set property 'events' of undefined
Pertaining to line:
$.ui.dialog.overlay.events = $.map('focus,keydown,keypress'.split(','), function (event) {
Using the versions of jQuery and jQuery UI you use in your jsFiddle fixes the issue.

Hey, still the same error here.
I'm using jQuery 1.11.2 and UI 1.11.3
@kgenly : whats the solution on that?

I need to look at updating the plugin for newer versions of jQuery & jQuery
UI.
On Fri, Mar 6, 2015 at 4:28 AM, shooby<EMAIL_ADDRESS>wrote:

Hey, still the same error here.
I'm using jQuery 1.11.2 and UI 1.11.3
@kgenly https://github.com/kgenly : whats the solution on that?
—
Reply to this email directly or view it on GitHub
https://github.com/jasonday/jQuery-UI-Dialog-extended/issues/1#issuecomment-77530155
.


Add "Request tracking" btn

Add a button to the XP Tracker where players can request tracking for a specific user. Let's make this an explicit action so we don't start tracking every player that's looked up.

For now, track everyone that is looked up.


Add a way to create discriminated unions for client-cli response types

Right now, since a generated type from the client-cli can return multiple responses, there is no clear way in TypeScript to create a function and have the proper type.
I suggest a change like the following one, by adding a new generic so that it will be doable to create such functions:
export interface FullResponse<T, U extends number> {
    statusCode: U;
    headers: object;
    body: T;
}

export interface GetResponse200OK {
    data: Array<{ id: string; name: string }>;
}

export interface GetResponse400ValidationError {
    validation: object;
}

export interface GetResponse401Unauthorized {
    reason: string;
}

export interface GetResponse500InternalServerError {
    reason: string;
}

type AllFullResponses =
    | FullResponse<GetResponse200OK, 200>
    | FullResponse<GetResponse400ValidationError, 400>
    | FullResponse<GetResponse401Unauthorized, 401>
    | FullResponse<GetResponse500InternalServerError, 500>

// example of a discriminatory function
const getProperBody = ({ statusCode, body }: AllFullResponses) => {
    // the following code is wrong, since I can't be sure that data is there
    // return body.data

    if (statusCode === 200) {
        return body.data // body type is now GetResponse200OK
    } else if (statusCode === 400) {
        // body is GetResponse400ValidationError
        return body.validation
    } else {
        return body.reason // body is GetResponse401Unauthorized | GetResponse500InternalServerError
    }
}

I think this is great!


TypeScript types not published in 9.1.0

Describe the bug
I just upgraded choices from 9.0.1 to 9.1.0 and noticed that ./types/index.d.ts is not included in the NPM package.
To Reproduce
Install version 9.1.0 and look in the node_modules folder. There is no types folder.
Expected behavior
./types/index.d.ts should be included in the package

This has been fixed on master. I expect to release a new version in the next week or so. For now you can use the master branch directly (it's stable):
npm install Choices-js/Choices#master


Question about T0=(c2w0[:3,3])*0.98

In scripts/pythons/transform2colmap.py
Why need *0.98 for T0?
many thanks

+1 same question


[Arc] Unable to open links when Arc is running in the background and no windows are open

Extension
https://www.raycast.com/the-browser-company/arc
Description
I have noticed another issue trying to use the Arc extension in Raycast:
When Arc is completely closed/quit on MacOS, or when Arc has a window open, the extension works great opening links (except for when Arc is minimized, then it will open the link but not bring up the app).
When Arc has NO windows open but is still running in the background, the extension will fail opening up any link at all and give this error message:

Video of the issue:
https://github.com/raycast/extensions/assets/42051158/e10dc9e9-4bdd-44a6-9ad9-8dec646ba4c4
Steps To Reproduce

close all windows of arc but leave it running in the background
attempt to open any link via "search arc" command in raycast

Current Behaviour
No response
Expected Behaviour
No response

@xhi-nico  Hey, Let me take a look i think I fixed this for another Arc command before.

Thank you Léo!


Runtime error when selecting SIP-10 token balance with decimal

To reproduce:

Send form
Select SIP-10 token
Enter amount with a decimal, address
Click Preview

Happens as we pass this value to BN.
bn.js?399f:6 Uncaught (in promise) Error: Invalid character
    at assert (bn.js?399f:6)
    at parseBase (bn.js?399f:274)
    at BN._parseBase (bn.js?399f:310)
    at BN.init [as _init] (bn.js?399f:105)
    at new BN (bn.js?399f:39)
    at makePostCondition (use-asset-transfer.ts?0958:39)
    at _callee$ (use-asset-transfer.ts?0958:91)
    at tryCatch (runtime.js?96cf:63)
    at Generator.invoke [as _invoke] (runtime.js?96cf:293)
    at Generator.eval [as next] (runtime.js?96cf:118)

@kyranjamie is this on main? I just tried:

and nothing happens (expected)

it should never be the case that a decimal ends up at that method -- can you write the exact steps you took to get that error?

https://user-images.githubusercontent.com/1618764/124921469-ba92d300-dff8-11eb-919d-2d0a1fff2108.mp4

oh -- that should fail before then, HEY does not have decimals. If we fix that validation, it should fix the issue


Explicitly test standalone installation / tests in the CI

One of the reasons that the bug in #495 slipped through, I think, is that the CI runs all of its tests within a QIIME 2 conda environment -- so if there are installation errors made due to installing Empress into an environment that doesn't have all the QIIME 2 stuff pre-loaded, these errors won't be caught on the CI.
As a quick solution, one way to fix this would be adding a chunk of code (a build? a step? I'm not sure yet...) to the GitHub actions script that creates a new "vanilla" conda environment with just Python installed, and then tests that following the installation instructions in the README (see #495 -- need to install Cython/NumPy first) installs Empress properly. To test this environment, we could just run the couple of standalone-specific tests Empress has set up -- nosetest has ways of only running a handful of tests.
This would be really useful to have in -- since changes within the Python ecosystem at large can be more volatile than those within a QIIME 2 environment, this sort of setup would help keep us safe from Weird Stuff Happening (tm).

I think this would make most sense as a separate GH Actions workflow. Can take a crack at this tomorrow.

Currently in tests/python/test_cli.py we're set up to load the qza files through the Artifact API and convert them using transformers. What do we think about changing this to just unzip the files into the the Click isolated filesystem (which we are using anyway) and removing the qiime2 import?
https://github.com/biocore/empress/blob/26aa6ac1ec709173c5a8d00509333fc05bc31a6c/tests/python/test_cli.py#L37-L49


Decrypt functions always return a numeric array instead of the original message

If you encrypt a message, no matter if it is encryptToURLComponent or encryptToQRCodeAlphanumeric, when you decrypt the key, using the respective decryptURLComponent or decryptQRCodeAlphanumeric, the response is always a numeric array, not the original expected string

You can use Buffer.from(decrypedData).toString('utf8') in Node.js or new TextDecoder().decode(Uint8Array.from(decrypedData)) in Web Browser to get the message (string) that you previously encrypted.
I'm thinking to use Uint8Array to replace the number array in the next major verson. It would be more convenience.

number[] has been replaced with Uint8Array since 2.0.0.


Accuracy

Hello @shak360! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file lineage/Analyze.py:

Line 12:80: E501 line too long (126 > 79 characters)
Line 15:65: W291 trailing whitespace
Line 16:80: E501 line too long (97 > 79 characters)
Line 16:98: W291 trailing whitespace
Line 24:80: E501 line too long (116 > 79 characters)
Line 41:1: E302 expected 2 blank lines, found 1
Line 47:27: E225 missing whitespace around operator
Line 47:45: E231 missing whitespace after ','
Line 47:76: E231 missing whitespace after ','
Line 47:80: E501 line too long (93 > 79 characters)
Line 50:1: W293 blank line contains whitespace
Line 51:1: W293 blank line contains whitespace
Line 52:1: W293 blank line contains whitespace
Line 53:1: W293 blank line contains whitespace
Line 53:1: W391 blank line at end of file

In the file lineage/CellVar.py:

Line 27:80: E501 line too long (171 > 79 characters)
Line 28:80: E501 line too long (168 > 79 characters)

In the file lineage/StateDistribution.py:

Line 8:80: E501 line too long (122 > 79 characters)
Line 35:80: E501 line too long (110 > 79 characters)
Line 67:80: E501 line too long (108 > 79 characters)
Line 147:80: E501 line too long (84 > 79 characters)
Line 148:80: E501 line too long (84 > 79 characters)
Line 161:80: E501 line too long (86 > 79 characters)
Line 166:80: E501 line too long (155 > 79 characters)
Line 168:38: E712 comparison to True should be 'if cond is not True:' or 'if not cond:'
Line 170:38: E712 comparison to True should be 'if cond is not True:' or 'if not cond:'
Line 184:1: W391 blank line at end of file

In the file lineage/Viterbi.py:

Line 6:80: E501 line too long (142 > 79 characters)

In the file lineage/figures/figure6.py:

Line 15:1: W293 blank line contains whitespace
Line 16:5: E303 too many blank lines (2)
Line 16:80: E501 line too long (186 > 79 characters)
Line 17:25: E231 missing whitespace after ','
Line 17:80: E501 line too long (179 > 79 characters)
Line 18:1: W293 blank line contains whitespace
Line 19:1: W293 blank line contains whitespace
Line 26:1: E265 block comment should start with '# '
Line 26:1: E303 too many blank lines (4)
Line 26:31: W291 trailing whitespace
Line 27:1: E302 expected 2 blank lines, found 4
Line 28:80: E501 line too long (125 > 79 characters)
Line 73:73: W291 trailing whitespace
Line 74:79: W291 trailing whitespace
Line 77:45: W291 trailing whitespace
Line 111:1: W293 blank line contains whitespace
Line 112:80: E501 line too long (164 > 79 characters)
Line 115:80: E501 line too long (176 > 79 characters)
Line 121:80: E501 line too long (86 > 79 characters)
Line 122:80: E501 line too long (111 > 79 characters)
Line 123:80: E501 line too long (124 > 79 characters)
Line 129:5: E265 block comment should start with '# '
Line 132:80: E501 line too long (94 > 79 characters)
Line 133:80: E501 line too long (90 > 79 characters)
Line 135:80: E501 line too long (101 > 79 characters)
Line 136:80: E501 line too long (99 > 79 characters)
Line 143:5: E265 block comment should start with '# '
Line 146:5: E265 block comment should start with '# '
Line 147:80: E501 line too long (97 > 79 characters)
Line 148:80: E501 line too long (93 > 79 characters)
Line 149:80: E501 line too long (98 > 79 characters)
Line 150:80: E501 line too long (96 > 79 characters)
Line 157:1: W293 blank line contains whitespace
Line 158:1: W293 blank line contains whitespace
Line 159:1: W293 blank line contains whitespace
Line 161:1: W293 blank line contains whitespace
Line 162:1: W293 blank line contains whitespace
Line 162:1: W391 blank line at end of file

In the file lineage/figures/figure7.py:

Line 10:1: W293 blank line contains whitespace
Line 16:1: W293 blank line contains whitespace
Line 17:1: E265 block comment should start with '# '
Line 17:32: W291 trailing whitespace
Line 19:80: E501 line too long (93 > 79 characters)
Line 25:15: E128 continuation line under-indented for visual indent
Line 46:80: E501 line too long (136 > 79 characters)
Line 62:80: E501 line too long (88 > 79 characters)
Line 68:74: W291 trailing whitespace
Line 69:80: W291 trailing whitespace
Line 72:45: W291 trailing whitespace
Line 74:1: W293 blank line contains whitespace
Line 76:9: E303 too many blank lines (2)
Line 107:1: W293 blank line contains whitespace
Line 108:80: E501 line too long (164 > 79 characters)
Line 111:80: E501 line too long (171 > 79 characters)
Line 117:80: E501 line too long (86 > 79 characters)
Line 118:80: E501 line too long (111 > 79 characters)
Line 119:80: E501 line too long (124 > 79 characters)
Line 125:5: E265 block comment should start with '# '
Line 128:80: E501 line too long (94 > 79 characters)
Line 129:80: E501 line too long (90 > 79 characters)
Line 131:80: E501 line too long (101 > 79 characters)
Line 132:80: E501 line too long (99 > 79 characters)
Line 139:5: E265 block comment should start with '# '
Line 142:5: E265 block comment should start with '# '
Line 143:80: E501 line too long (97 > 79 characters)
Line 144:80: E501 line too long (93 > 79 characters)
Line 145:80: E501 line too long (98 > 79 characters)
Line 146:80: E501 line too long (96 > 79 characters)
Line 153:1: W293 blank line contains whitespace
Line 153:1: W391 blank line at end of file

In the file lineage/tHMM.py:

Line 30:80: E501 line too long (80 > 79 characters)
Line 59:80: E501 line too long (85 > 79 characters)

I have merge conflicts I needed to resolve using the Pull Request interface.

This branch is all included on accuracy-asm, right? If so can close.

Yep, this branch has deprecated. It can be closed and deleted.

Didn't realize accuracy-asm merged into this branch. This branch accuracy just needs to be merged if you think it's ready Dr. Meyer @aarmey .


Customizing backgroundColor doesn't generate css classes

I am currently experimenting with v1.0.0-beta.4.
Trying to customize the backgroundColor in tailwind.config.js as mentioned here https://next.tailwindcss.com/docs/background-color/#customizing doesn't generate a .bg-primary class in the final css file.
backgroundColor: theme => theme({
        'primary': '#3490dc'
}),

Just realised my mistake, one theme too many. Closing.


A declarative framework on the top of guidance

Hi there!
First, I would like to thank you for this great lib that give some very interesting approach and unique.
I've build this lib build on the top of yours: https://github.com/AlbanPerli/Noema-Declarative-AI
The main goal here is to use declarative programming to easily use the interleaving and CFG, the "same" way SwiftUI or other framework help to facilitate UI programming.
This first step is an humble proposition aiming to pursue and facilitate your approach.
The following steps will be on the explorations of the capabilities that offer the concept of Noesi/Noema to perform some auto-analysis/auto-correction.
This is not self-promotion, just trying to share with you my enthusiasm for your work! 😊
Do you have any roadmap for the next-step of guidance?
Thanks!
Alban

@AlbanPerli this is super cool, thank you for sharing!!!
With guidance, the goal is to largely provide a user-friendly but relatively low-level interface for building LLM applications as well as higher-level interfaces on top of our stack. So it's really exciting to see users such as yourself doing exactly that.
Some features in the pipeline include UI improvements for the notebook experience, better support for constraining remote and multimodal models, providing more statistics and feedback to users in order to help them build good prompts and understand exactly how constraints are affecting outputs, and providing mechanisms for improving generation throughput, e.g. with threading- or async-based concurrency.
Out of curiosity, are there any particular pain points (or nice highlights!) that you are experiencing when using guidance? Are there any particular features that would make your life easier or unlock some superpowers for Noema and its users? Any feedback would be really useful :)
Cheers!

Thanks for your response @hudson-ai  :)
This is exactly the way I see it: guidance and CFG as a kind of « assembly language for LLM » and higher level libs using it to enable the creation of abstract task easier and faster.
As a user of guidance, most of the functionalities are really cool, efficient and VERY satisfying.
The main problem is: how to imagine new use case, as for me, it’s a new way of thinking about algorithm, by programming how to think the idea (using CFG or interleaving). This is why I build Noema. It reduce the capabilities of guidance, but (I hope) helps by simplifying the use case that can be found.
From a high-level point of view,  some more examples showing CFG like the one in the guidance's ReadMe showing the arithmetic operation would be helpful. Maybe in a field less mathematic and more semantic?
The usage of remote model would be definitively a good point for the (very few!) current users of Noema.
From the lib usage point of view, I've some difficulties with JSON and TypeAdapter: the result doesn't work as expected (from my understanding). The field or the elements are sometimes empty or filled with garbage.
So, for now, to get an array of something, there is a custom CFG in Noema.
The last point is related to a specific use case of Noema:
Actually, the lib build a ‘Noesis’ based on the declared task. Basically: an instruct prompt representing the declared task flow.
In some specific case, I need to use the reset function of guidance to rebuild the instruct prompt with new values generated during the execution. In that case, using a stateless call doesn’t match.
tmp_copy = str(llm)
# …
# … do something with the LLM
llm.reset()
updated_prompt = update_value_in_previous_prompt(tmp_copy)
llm += updated_prompt

It can be very token consuming.
Could we get a reset function with a parameter that revert to a particular POI i.e. a named generation?
From my understanding of the transformer algorithm: no. But maybe?
Thanks! :)

@AlbanPerli thanks for the feedback and ideas -- super useful!
Re: issues with JSON -- can you provide any examples of the kind of issue or unexpected behavior you've faced here? Either here or in a new issue would be awesome.
And re: this

Actually, the lib build a ‘Noesis’ based on the declared task. Basically: an instruct prompt representing the declared task flow. In some specific case, I need to use the reset function of guidance to rebuild the instruct prompt with new values generated during the execution. In that case, using a stateless call doesn’t match.

Can you explain a bit about what you mean by "using a stateless call doesn't match"? When it comes to reprompting, we do our best to reuse as many tokens from the underlying KV cache as we can, so you hopefully shouldn't have to pay a big expense here if you are mostly modifying the suffix of a prompt. That being said, I could see that exposing some kind of "checkpointing" mechanism could be really useful if there are a few prompt states that users want to return to often. Curious to hear your thoughts/experience here.

@hudson-ai Sorry for the late response, I've made a lot of modification on Noema, clarifying some points. A new release is coming.
Now the 'checkpointing' technique discussed has no direct use case, but an approaching one appeared:
The first step is to build a chain of thought prompt based on the code written by the user.
For the code:
class Example(Noesis):

    def __init__(self, name, value):
        super().__init__()

    def description(self):
        """
        This is a system prompt, describing the thought process/role.
        """
        task = "Task description"
        gen1:Sentence = f"For the task {task}, this is the way of thinking 1"
        # gen1.value contains the *produced* 'Way of thinking 1'
        gen2:Bool = f"Determine if {gen1.value} is smart or not"
        if gen2.value == True:
            gen3:Word = "Select a word to qualify the way of thinking"
            gen4:Sentence = f"Elaborate on {gen3.value}"
        else:
            pass # Do something else

The following prompt is produced:
<s>[INST]This is a system prompt, describing the thought process/role.
You are functionning in a loop of though. Your response can be multiline. Here is the reasonning you are currently executing:

#GEN1: For the task Task description, this is the way of thinking 1.
#GEN2: Determine if {gen1.value} is smart or not.
#GEN3: Select a word to qualify the way of thinking.
#GEN4: Elaborate on {gen3.value}.
[/INST]

The execution process is: reading the code->generating the instruction prompt->finally run the 'description' method line by line.
So, as the generations are done step by step, we don't know the value of variable {gen1.value} at the creation of the prompt, and as far as I now, the only way to update the prompt with the generated value is to reset the llm and put the updated prompt as a new starting point.
A powerful feature, would be to be able to inject/update new value in the cached prompt.
Maybe something "like a malloc" or some reserved space that can be filled within the cached prompt would be great.
This would probably improve the next generation giving each time a more defined context.
It's my turn to be very curious to hear your thoughts/experience here! :)
PS: I have so much questions...! 😅


feature: Enable Deployment from Git Repositories to Akash Network

This is a PR that addresses the new feature addition, enabling deployment directly from GitHub, GitLab, or Bitbucket onto the Akash Network.
Issue: #226

Can you add the env vars you added to the config files? https://github.com/akash-network/console/blob/main/apps/deploy-web/src/config/browser-env.config.ts


Fix #206

#206: System.Runtime.CompilerServices.ExtensionAttribute does not exist in mscorlib prior to .Net 4.5

:+1:


width/height of gridItem

For a project i'm working on, i need the width or height of a gridItem to be 0. When i first set up the layout array, all works fine, but after resizing the gridItem, its width/height become 1.
I managed to force w or h value to 0, but i'm no more able to move another gridItem on the same row/column.
It's like there is a bounding box to detect collision which size as been set to 1.
I don't know if i'm missing a property or the resize event force w/h to 1 even if the prop is set to 0.
Thanks

I'm not sure, but I think the colliding algorithm detects a collision even if the width or height is 0.
I'm curious, why do you need an item with 0 as width or height? Why not removing the item?

I'm building a web-based "Graphic assembler" (I don't know how to name it):
each grid-items added to the grid-layout represent a compilable graphic element (a title, an image, some text...).
Once everything is set, the app will send a string to a software that will render the final output.
I need items with 0 width/height for drawing lines (if needed) between elements as dividers.
Until i try to resize the element, the collision detection works perfectly, i can place another element just before it, and next to it but not across it. The problem appears just after manually resizing the element.
Looking a bit deeper into it, the w/h props of the grid-item is correctly set to 0, while the w/h value in the layout array is set to 1 (after manually resizing the grid-item). I can't figure out how to change the value of w/h in the layout array. if i try to force this.layout["myObject"].w = 0; in the resized() method and i log to the console the value of w the value is correct but in the vue debugger the value still set to 1.
I think a workaround could be to disable the resizing feature and create a component to manually set the w/h desired value, but it would be a much more less elegant solution.
Another work-around i found is to set the w/h value in the moved method for every grid-item witch have to get its value set to 0. This is a better solution even if it means each time i move a grid-item on the grid, i have to cycle trough every grid-item to check its w/h value...


Iframe should listen to height changes

If an iframe has the sends its height using this function:
window.onload = function() {
  window.parent.postMessage(
    {
      sentinel: "amp",
      type: "embed-size",
      height: document.body.offsetHeight
    },
    "*"
  )
}

we should listen to it and resize the height acordingly.
In AMP, we should use
https://ampbyexample.com/components/amp-iframe/#resizable-iframes
to let the iframe resize itself.
It looks like the outside button it's not needed anymore, the iframe can resize itself without user interaction.

[ ] PWA
[ ] AMP

This is an iframe we can use to test the functionality:
https://www.diariomotor.com/marfeel_iframes/?&format_type=quecochemecompro-widget-ficha-single&iframe_url_check=https://www.diariomotor.com/consejos/comprar-coche-nuevo-agosto-2018

@orballo they've added the AMP height code to "our" iframes as well:
https://peta.diariomotor.com/competicion/feed/frontity_iframes/?&format_type=cards&iframe_url_check=https://peta.diariomotor.com/competicion/noticia/gran-premio-canada-lewis-hamilton-problemas-neumaticos/
You can test it out here:
https://peta.diariomotor.com/competicion/noticia/gran-premio-canada-lewis-hamilton-problemas-neumaticos/
or here:
https://peta.diariomotor.com/competicion/noticia/esteban-gutierrez-realiza-su-reaparicion-en-la-formula-1-de-la-mano-de-mercedes-amg/
There's a new siteId for peta but they haven't changed it yet: YoMqNzsZq5vFZGJNf
You can pass it via query until then. I think the URL is not peta.diario... yet but you can change it.

There's a new siteId for peta but they haven't changed it yet: YoMqNzsZq5vFZGJNf
You can pass it via query until then. I think the URL is not peta.diario... yet but you can change it.

They've changed it 👍

:tada: This issue has been resolved in version 0.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


c-api: Remove reexport of wasmtime crate

This is a follow-up to #6765 to remove this reexport since it was originally added to use both the C API and the wasmtime crate in the same downstream crate, but this should be possible through Cargo with:
[dependencies]
wasmtime = "13"
wasmtime-c-api = { version = "13", package = "wasmtime-c-api" }

and that way wasmtime::* is available as well as wasmtime_c_api::*

cc @RubixDev and @maxbrunsfeld on this. I'd want to confirm that your embedding use case still works if this is removed. Additionally this is mostly just pointing out that it's not necessary to have this directive to get things working. That being said I can imagine it's still convenient to have because you'd only need one Cargo manifest directive instead of two.
If y'all would prefer I think it would make sense to keep this but as pub use wasmtime instead of pub use wasmtime::* so you could access all of the internals but it wouldn't clash namespaces ideally. In any case I'd like to leave main as-is until y'all have weighed in over here.

I like the idea of pub use wasmtime, but either solution is ok with me. Our use case is pretty niche.

Ok sounds good to me, I've updated to remove just the ::* aspect but this will still do pub use wasmtime; for downstream users to use.

ping @fitzgen, mind taking a look at this?


Local links/navigation is not working

Having local navigation, like:
# Markdown Test Page

* [Headings](#Headings)
* [Paragraphs](#Paragraphs)
* [Blockquotes](#Blockquotes)
* [Lists](#Lists)
* [Horizontal rule](#Horizontal)
* [Table](#Table)
* [Code](#Code)
* [Inline elements](#Inline)

***

# Headings

# Heading one

Sint sit cillum pariatur eiusmod nulla pariatur ipsum. Sit laborum anim qui mollit tempor pariatur nisi minim dolor. Aliquip et adipisicing sit sit fugiat commodo id sunt. Nostrud enim ad commodo incididunt cupidatat in ullamco ullamco Lorem cupidatat velit enim et Lorem. Ut laborum cillum laboris fugiat culpa sint irure do reprehenderit culpa occaecat. Exercitation esse mollit tempor magna aliqua in occaecat aliquip veniam reprehenderit nisi dolor in laboris dolore velit.

## Heading two

[[Top]](#top)

will render links but they won't work.

Maybe this will help: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF11
specifically:

from gopdf readme

I've added support for local links on the current master branch.
Some things to note:
This only works for hashtag links to headers. The header ID attribute need to be generated by the parser using the goldmark option WithAutoHeadingID.
          goldmark.WithParserOptions(
              parser.WithAutoHeadingID(),
          ),

This means that adding internal links like  or . Will not work. There are inline HTML fragments which this package cannot render at all.
Upgrade to the most recent commit with go get github.com/stephenafamo/goldmark-pdf@3ab67f1 and try it out.

ok, as long as there is a way. i think it should be mentioned in readme to avoid confusion.

The HTML is working(WithAutoHeadingID simply transliterates the heading into id) but in pdf it does not work.

I am just guessing but maybe in the func (r *nodeRederFuncs) renderHeading you are adding link to the heading itself and not anchor and then you do not set link to that anchor in link that actually points to it anywhere in the document. The screenshot from readme above clearly shows two requirements - defining anchor on the heading(in this context) and actually linking to it with a link. Since headings are not links, the entire logic does nothing.

in (r *nodeRederFuncs) renderLink there should be some check for link href starting with "#" and then simply making it into local link.

I am adding the anchors when rendering headings. See here
When rendering links, I am also checking for the #. See here
Make sure you're on the latest commit, it worked for me. Also, while there is a pending implementation with gopdf, what is currently used is fpdf, see fdpf.go.

my go mod shows v0.2.0 and the code you linked is present but it is not working.
I have the list above, just changed the anchors to lower case so they match generated ids and they work in html but not in pdf.

@ivanjaros I generate with this markdown
page.md
And this code
package main

import (
	"context"
	_ "embed"
	"image/color"
	"os"

	pdf "github.com/stephenafamo/goldmark-pdf"
	"github.com/yuin/goldmark"
	"github.com/yuin/goldmark/extension"
	"github.com/yuin/goldmark/parser"
)

//go:embed page.md
var markdown []byte

func main() {
	file, err := os.Create("./test/output.pdf")
	if err != nil {
		panic(err)
	}

	md := goldmark.New(
		goldmark.WithExtensions(extension.GFM),
		goldmark.WithRenderer(
			pdf.New(
				pdf.WithContext(context.Background()),
				pdf.WithLinkColor(color.RGBA{204, 69, 120, 255}),
				pdf.WithHeadingFont(pdf.GetTextFont("IBM Plex Serif", pdf.FontLora)),
				pdf.WithBodyFont(pdf.GetTextFont("Open Sans", pdf.FontRoboto)),
				pdf.WithCodeFont(pdf.GetCodeFont("Inconsolata", pdf.FontRobotoMono)),
			),
		),
		goldmark.WithParserOptions(
			parser.WithAutoHeadingID(),
		),
	)

	if err := md.Convert(markdown, file); err != nil {
		panic(err)
	}
}

And get this PDF
output.pdf

Thanks, will have a look tomorrow. Most likely some issue on my side.

Nope, still no change. When I click on your pdf's links, they just work but when I generate the pdf  without your code and click on my links they not only not work but they will behave like html so the url will change and get a #heading suffix.

If you added a replace directive to your go.mod, you should remove it, if not it will keep using your local version.

If you added a replace directive to your go.mod, you should remove it, if not it will keep using your local version.

i did. i tried a fresh project with only this code, same result. i don't know if i am doing something wrong or not.

It works for me.


Salt-bin minion won't daemonize

STEPS TO REPRODUCE:
Run build.py
run sudo ./dist/linux/salt-2019.2.2 minion -d
ACTUAL RESULT:
The binary exits early with the following log:
[DEBUG   ] Reading configuration from /etc/salt/minion
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: jinx
[TRACE   ] The required configuration section, 'fluent_handler', was not found the in the configuration. Not loading the fluent logging handlers module.
[TRACE   ] None of the required configuration sections, 'logstash_udp_handler' and 'logstash_zmq_handler', were found in the configuration. Not loading the Logstash logging handlers module.
[DEBUG   ] Configuration file path: /etc/salt/minion
[TRACE   ] Trying os.getgrouplist for 'root'
[TRACE   ] Group list for user 'root': []

Program completed
EXPECTED RESULT:
[DEBUG   ] Reading configuration from /etc/salt/minion
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: jinx
[TRACE   ] The required configuration section, 'fluent_handler', was not found the in the configuration. Not loading the fluent logging handlers module.
[TRACE   ] None of the required configuration sections, 'logstash_udp_handler' and 'logstash_zmq_handler', were found in the configuration. Not loading the Logstash logging handlers module.
[DEBUG   ] Configuration file path: /etc/salt/minion
[TRACE   ] Trying os.getgrouplist for 'root'
[TRACE   ] Group list for user 'root': []
[WARNING ] Insecure logging configuration detected! Sensitive data may be logged.
[INFO    ] Setting up the Salt Minion "jinx"
[TRACE   ] loaded json json lib
[DEBUG   ] Created pidfile: /var/run/salt-minion.pid
[INFO    ] Starting up the Salt Minion
[DEBUG   ] AsyncEventPublisher PUB socket URI: /var/run/salt/minion/minion_event_17e44715bf_pub.ipc
[DEBUG   ] AsyncEventPublisher PULL socket URI: /var/run/salt/minion/minion_event_17e44715bf_pull.ipc
[INFO    ] Starting pull socket on /var/run/salt/minion/minion_event_17e44715bf_pull.ipc
[TRACE   ] IPCMessagePublisher: binding to socket: /var/run/salt/minion/minion_event_17e44715bf_pub.ipc
[TRACE   ] IPCServer: binding to socket: /var/run/salt/minion/minion_event_17e44715bf_pull.ipc
[DEBUG   ] SaltEvent PUB socket URI: /var/run/salt/minion/minion_event_17e44715bf_pub.ipc
[DEBUG   ] SaltEvent PULL socket URI: /var/run/salt/minion/minion_event_17e44715bf_pull.ipc
[TRACE   ] IPCClient: Connecting to socket: /var/run/salt/minion/minion_event_17e44715bf_pub.ipc
[DEBUG   ] Grains refresh requested. Refreshing grains.
[DEBUG   ] Reading configuration from /etc/salt/minion
...

Program keeps running normally

Following https://gitlab.informatik.haw-hamburg.de/aca534/dvc/commit/e1f736eaad53ed627646653c63cdd58149603822
it seems like pyinstaller has issues with sys.exit and we can daemonize properly if it is replaced with os._exit.   However... os._exit doesn't clean up properly and the program can only be run once

@Akm0d should this not be closed since --onedir fixes this issue


Fixed date selection for new default dataset

Ah looks like a failure in tests:
      tools.plot_section_with_srss(ds, 'CHLA', ax,start_time = '2023-09-06', end_time = '2023-09-10', ylim=35)
makes sense as now we're using a different test dataset


Make member access ("foo.bar", "foo[bar]") work properly

Specification
Non-computed member access (foo.bar) should work like this in rvalues:

If object is a module reference, it accesses specified property (const, function, etc.). If there is
none, it produces an error.
If object is an expression evaluating to an Object and property is an expression evaluating to a String, it accesses specified property. If there is none, the result is null.
Otherwise, it produces an error.

Computed member access (foo[bar]) should work like this in rvalues:

If object is an expression evaluating to an String and property is an expression evaluating to a Number, it accesses specified character. If there is none, the result is null.
If object is an expression evaluating to an Array and property is an expression evaluating to a Number, it accesses specified element. If there is none, the result is null.
If object is an expression evaluating to an Object and property is an expression evaluating to a String, it accesses specified property. If there is none, the result is null.
Otherwise, it produces an error.

Non-computed member access (foo.bar) should work like this in lvalues:

If object is an expression evaluating to an Object and property is an expression evaluating to a String, it sets specified property (possibly overwriting existing value).
Otherwise, it produces an error.

Computed member access (foo[bar]) should work like this in lvalues:

If object is an expression evaluating to an Array and property is an expression evaluating to a Number, it sets specified element (possibly overwriting existing value) and adjusts array length (like in JavaScript).
If object is an expression evaluating to an Object and property is an expression evaluating to a String, it sets specified property (possibly overwriting existing value).
Otherwise, it produces an error.

Checklist

[x] Preparatory refactorings
[x] Make the [] operator work properly in rvalues
[x] Make the . operator work properly in rvalues

[x] Fix handling in non-call expressions (foo.bar)
[x] Fix handling in call expressions (foo.bar())

[x] Make the [] operator work properly in lvalues
[x] Make the . operator work properly in lvalues
[x] Make the . operator work properly in sub calls

Done, done, done!


enable lbaas testing in ci

remove the restriction on ubuntu and support rhel
use relative path to support running test from envs/example/ci-full-rhel instead of env/test

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

ok to test


installation error

this error while npm install in /src/app folder
node version :14.18.0
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm ERR! code ELIFECYCLE
npm ERR! syscall spawn
npm ERR! file sh
npm ERR! errno ENOENT
npm ERR<EMAIL_ADDRESS>install: node build.js || nodejs build.js
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2023-05-24T07_45_04_105Z-debug.log
anyone can help to slove this .......

AbhayVEdulab can you try removing node_modules folder and package-lock.json file, and do thenpm installagain?


Benchmarking Tartiflette

Attempting to implement same tests as on #3 but for the proposed changes via #4

Currently facing issue with possible throttling or messages not being recieved?
On the client, print out every time SineWaveSimple is updated:
$ pipenv run python -m coniql
======== Running on http://<IP_ADDRESS>:8080 ========
(Press CTRL+C to quit)
[9. 0. 1. 2. 3. 4. 5. 6. 7. 8.]
[8. 9. 0. 1. 2. 3. 4. 5. 6. 7.]
[7. 8. 9. 0. 1. 2. 3. 4. 5. 6.]
[6. 7. 8. 9. 0. 1. 2. 3. 4. 5.]
[5. 6. 7. 8. 9. 0. 1. 2. 3. 4.]
[4. 5. 6. 7. 8. 9. 0. 1. 2. 3.]
[3. 4. 5. 6. 7. 8. 9. 0. 1. 2.]
[2. 3. 4. 5. 6. 7. 8. 9. 0. 1.]
[1. 2. 3. 4. 5. 6. 7. 8. 9. 0.]

On the client, decode the base64 array and print it out:
$ pipenv run python benchmark/asyncClient.py
--- sim://sinewavesimple ---
--- Size: 10, Update Time: 0.1 s, Messages to test: 100, ---
Connected...
[9. 0. 1. 2. 3. 4. 5. 6. 7. 8.]
[7. 8. 9. 0. 1. 2. 3. 4. 5. 6.]
[5. 6. 7. 8. 9. 0. 1. 2. 3. 4.]
[3. 4. 5. 6. 7. 8. 9. 0. 1. 2.]
[1. 2. 3. 4. 5. 6. 7. 8. 9. 0.]
[9. 0. 1. 2. 3. 4. 5. 6. 7. 8.]
[7. 8. 9. 0. 1. 2. 3. 4. 5. 6.]
[5. 6. 7. 8. 9. 0. 1. 2. 3. 4.]
[3. 4. 5. 6. 7. 8. 9. 0. 1. 2.]
[1. 2. 3. 4. 5. 6. 7. 8. 9. 0.]

Only every second message is getting through? This appears to remain the case regardless of update_time.
@thomascobb I will investigate but wondering if you know where this is coming from and could save me some time?

Issue fixed, was a result of too many await.recv() calls during quick modifications

Interestingly, my initial tests have yielded almost exactly the same results as demonstrated on #3 !
This suggests (to me) that the limit is on the client side in terms of measuring the performance, as I would expect to see different performance characteristics between the two server implementations.
Further investigation is required:

what is causing the bottlenecks on the client side? Is it I/O bound?
can we stretch the performance of the server by applying many subscriptions at once?

@thomascobb I have removed the redundant Python scripts and merged in the latest master with according changes. Should be ready to merge.

This works for me now, please could you put some instructions about how you install and run up the javascript benchmarking in a README file in the benchmarks directory, or as a benchmarking.rst file in the docs directory?

Yep will write some documentation this afternoon 👍

@thomascobb Have added a page in docs. Let me know if you think I should go into more detail.


Update main README to add link to Error handling in PageForm

Update main README to add link to Error handling in PageForm

Good job. Dont forget please also reference this here: https://github.com/ansible/ansible-ui/wiki/PageForm.


Upgrade CI to Java 11

We use Java 8 in CI now. We have to remove module-info.java in order to pass CI. Let's see if we can upgrade Java version to 11.

If you do it, you need both.
Java 8 is the baseline, you need it to verify no Java 11 only syntax get to the code.

If you do it, you need both.
Java 8 is the baseline, you need it to verify no Java11-only syntax get into the code.

Got it. Our SDKs support Java 8+.


No prompt pops up when expanding the attached local account without installing storage emulator

Storage Explorer Version: 1.4.0
Platform/OS Version: Windows 10/MacOS High Sierra/ Linux Ubuntu 16.04
Architecture: ia32/x64
Build Number: 20180724.5
Commit: 2605f1c9
Regression From: Not a regression
Steps to Reproduce:

Make sure the storage emulator is not installed or started.
Open 'Connect' dialog -> Select 'Attach to a local emulator' ->'Connect'.
Try to expand the attached local account.

Expected Experience:
Pop up the prompt like 'you need to install or start storage emulator'.
Actual Experience:
No prompt pops up and keeps loading long time after expanding the attached local account.

Fixed on the build main/20211125.2.


Contact nicknames not searched

Expected behavior
When composing email, in the To:, CC:, and BCC: fields, typing in a contact's nickname should reveal contact(s) with matching nickname(s).
Actual behavior
Typing in a contact's nickname reveals no matches.
Steps to reproduce

Create a contact with a nickname
In k-9 email, compose a new email
In any of the address lines type the contact's nickname
Note that there are no matches

This is kinda important to me because I don't remember/know most of the real names of my Burning Man contacts, only their Playa (nick) names. (volunteer manager so have 150+ of them)  So every time I go to send them email, I have to go to my contacts app, look it up there and then send email. PITA.  There are also other social groups where this is common. (furries, for example)
Environment
K-9 Mail version: 5.203
Android version: 7.0
Account type (IMAP, POP3, WebDAV/Exchange): IMAP

Starting point: RecipientLoader.fillContactDataFromQuery()

I would like to work on this :)

I've been looking at this but got distracted trying to make tests for RecipientLoader because it needs access to some sample data. I think it's harder than beginner level.

Hello! I am new to the open source community (applying for GSoC). I would like to work on this enhancement. Would that be alright? If this is already being worked on by someone else, do let me know of a different beginner bug that I can fix.
Please guide me regarding the procedure to contribute etc.

@AnirudhBadri I have open a PR about this issue and the PR has been approved, so you may choose a another issue :)

@daquexian, I see. Sorry about that.

hello, i am Hiteksha Basiya. I would like to work on this issue so can i work on this issue?

hint (perhaps?): ContactsContract.CommonDataKinds.Nickname

I would like to work on this Issue

@cketti This has been fixed #2264, so should be closed.


[Blazor] Order of OnAfterRenderAsync method calls

The BuildRenderTree method is called from the outer most element and can create sub components, which causes the BuildRenderTree method of the sub components to be called. So far so good, this seems reasonable to me. The problem is OnAfterRenderAsync follows the same order, and I think the OnAfterRenderAsync of a component should be called after it was called in all the sub-components.
I'm using this event to call some JavaScript interop after one component is rendered (The only method where is possible as far as I know). But It results that the same method was called before in the parent. Causing the parent to have a non-initialized child in the OnAfterRenderAsync.

Thanks for contacting us.
We think the current design is fine.

The reason for the current design is that components can add and remove children at any time. There's never any specific time where a component can know that all its descendants have been rendered, as more could still appear. That's why we don't promise that OnAfterRenderAsync waits for descendants - it wouldn't be meaningful.
If this is causing an issue for a specific thing you're trying to implement, could you provide more details about the scenario? We might be able to suggest a solution.

I expected the OnAfterRenderAsync to be raised every time a BuildRenderTree method is called, and expected the children to be those just created in the BuildRenderTree method.  Am I wrong? I understand the children could change in subsequent calls to BuildRenderTree, but that shouldn’t be a problem since a new OnAfterRenderAsync would be called.
My scenario is a ListView control whose items are virtualized. To create this control I’m using a ScrollViewer control. To really know the dimensions of the control(Mandatory to implement virtualization) it is necessary to perform some JavaScript calls, which get both the width and height as well as scrollX and scrollY of underlying div. The only place where this Javascript  call can be located is in OnAfterRenderAsync method. The problem is when the ListView is initialized the first time, the ScrollViewer was not “initialized” yet. What do you suggest?

I expected the OnAfterRenderAsync to be raised every time a BuildRenderTree method is called, and expected the children to be those just created in the BuildRenderTree method. Am I wrong?

OnAfterRenderAsync is raised after each time the DOM is updated, which happens at some point after a BuildRenderTree method is called. The actual ordering of OnAfterRenderAsync calls within a single batch isn't defined.

I understand the children could change in subsequent calls to BuildRenderTree, but that shouldn’t be a problem since a new OnAfterRenderAsync would be called.

Yes, there will be another call to OnAfterRenderAsync after each render batch that involves your component.

My scenario is a ListView control whose items are virtualized. To create this control I’m using a ScrollViewer control. To really know the dimensions of the control(Mandatory to implement virtualization) it is necessary to perform some JavaScript calls

Yes, that totally makes sense. You do want your JS interop calls to be inside OnAfterRenderAsync and not earlier, because they need to read state from the DOM, and OnAfterRenderAsync is what notifies you that the DOM has been updated. So this sounds correct and fine.
I don't know which way round your ListView and ScrollViewer are nested (i.e., which one is inside the other) but in general for virtualization I'd expect a sequence like this:

Parent gets rendered, initially empty because it doesn't know how many children to render yet

DOM gets updated with empty element for parent

Parent's OnAfterRenderAsync gets called with the firstRender parameter set to true

Parent uses JS interop to query the dimensions of its element and scroll position
Parent re-renders itself, but this time with the desired set of children

When onscroll later fires on the parent, if the desired set of children has now changed, then the parent re-renders the parent with a different set of children


Lost access to premium supported account on reinstall of app

I had a premium supporter licence which i lost when i reinstalled the app on another device.
Please restore the licence.

@adlk Please help.


added a new employee ui class

and plz again use layout, don't set it to null and try to avoid using hard pixeled spacings


Dropbox mount ignoring files.

Windows 10 64-bit
Dropbox

Looks like a variant of #107 or #691.

Actually I think this was fixed by #1558 - can you try the latest beta?


Differentiate between prod and dev webpack builds

Use minimist to parse CLI flags nicely
Fix some of the props warnings that popped out in dev mode
Don't use minificator and prod env in development
Enable sourcemaps

Refs: #169

When running this locally, I get:
> webpack --config webpack.config.js --progress --colors --watch --development

/Users/dkniffin/Repositories/museeks/webpack.config.js:10
let plugins;
^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:413:25)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at module.exports (/Users/dkniffin/Repositories/museeks/node_modules/webpack/bin/convert-argv.js:80:13)
    at Object.<anonymous> (/Users/dkniffin/Repositories/museeks/node_modules/webpack/bin/webpack.js:39:40)
    at Module._compile (module.js:434:26)

@dkniffin what's your node version?
$ node -v
v6.9.1

Probably worth fixing it anyway

> node --version
v4.1.1

Yea, that fixed it. I'll upgrade node too.

So all the work about proptypes will be done in#279 ?

Yes, in a separate PR(s)

Nice job.


Disable babel-loader's cacheCompression

Context: #6846  - I received no feedback on it, so I figure a PR is more actionable.
Changes have been tested running on a live website since I filed the issue. Build times and their memory consumption have both decreased with no further issue arising.

cacheCompression is an enabled-by-default flag in babel-loader,
which gzips the babel-loader cache.
Most projects do not actually benefit from cache compression,
especially in production where builds often happen in a CI environment
where memory is precious and disk space is not.
Furthermore, having it disabled in dev and enabled in prod means caching
won't be shared between dev and prod.
Finally, the disk space savings are not that great. Most React projects
will have a lot of small files (one file per component). babel-loader
caches each file as a unit, so the compression overhead increases when
the project is mainly lots of small files.
For these reasons, we're disabling cache compression.
Closes #6846

Signed

Dunno why the builds are failing but seems unrelated to this PR:
Error: Failed to load parser 'babel-eslint' declared in '.eslintrc » eslint-config-react-app': Cannot find module 'babel-eslint'

Seems like a reasonable change. Let's try it out. Hopefully we'll see some perf improvements for our users!


Updated sauce-labs to version 4.3.13

Thank you for the contribution. It was merged directly as 930e715785a27257a9c8d26eae043df2b2ec6201 to keep commit history cleaner. Your contribution is still credited to you.


Extend readme and docs

This is some kind of draft and a request for comments, so that we get a better readme and docs in the main repository.

all done

so, do we wanna merge this now or first extend the documention, i.e. fill all TODOs? It's definitely better than the current README/docs ... :)


Organization settings screen

An organization admin should be able to see a page which shows the organization's name and contact phone number. The admin should be able to change the name and the phone number.

Deprecated by a different enhancement- a wider range of organizational information needed than just these.


No spell checking of markdown files with the extension Visual Studio Spell Checker (VS2022 and Later) installed

Describe the bug
With the Visual Studio Spell Checker (VS2022 and Later) https://marketplace.visualstudio.com/items?itemName=EWoodruff.VisualStudioSpellCheckerVS2022andLater extension installed, no spelling errors are shown in markdown files. They are shown however, in all other file types, and they are shown when the Markdown Editor v2 extension is disabled.
To Reproduce

Install the extensions Markdown Editor v2 and Visual Studio Spell Checker (VS2022 and Later).
Open a .md file.

Expected behavior
Spelling errors are shown in markdown files.
Additional context
Visual Studio 17.1.5. Of course I do not know where the root cause for this issue is and whether it is the Markdown Editor v2.

Seems it's spell checker issue, and will be fixed soon...

@Molinarius is this fixed for you? For me - no :(

@Molinarius is this fixed for you? For me - no :(

Ooops you are right, still not working. Thanks for the hint.

@Molinarius I think that we already know that this is spell checker issue and not the md editor, we need to discuss it in appropriate topic...


OCPBUGS-11486: fix:  introduce correct SNO leader election for openshift

This PR is huge since for correct leader election in an openshift-compliant manner, we will need to introduce https://github.com/openshift/library-go/
Of course since we vendor, this would be a big change.
For the leader election, I consumed https://github.com/openshift/library-go/blob/release-4.14/pkg/config/leaderelection/leaderelection.go#L153 and switched to a custom lease lock that is consuming the Openshift Leaderelection based on leases.
I also had to introduce a redirect of klog to our standard logger as the library uses klog and we didn't have a redirect setup in place. Now all klog messages get parsed into JSON correctly as intended (previously also throttling messages would be malformatted, this has been corrected with that same redirect)
P.S.: to completely fix OCPBUGS-11486 we will also need an upstream PR in topolvm which exposes new flags for all necessary leaderelection parameters in https://github.com/topolvm/topolvm/blob/d242dcc522ae3f4bc3fe692054205b1076319396/pkg/topolvm-controller/cmd/root.go#L47 If we all agree on that approach I will open up a PR there as well.
Results in the following logs:
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"setup","msg":"Watching namespace","Namespace":"openshift-storage"}
{"level":"info","ts":"2023-07-28T12:45:51Z","msg":"The leader election gives 4 retries and allows for 30s of clock skew. The kube-apiserver downtime tolerance is 78s. Worst non-graceful lease acquisition is 2m43s. Worst graceful lease acquisition is {26s}.\n"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"setup","msg":"Overwriting defaults with SNO leader election config as only a single node was discovered","node":"crc-ccssl-master-0"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"setup","msg":"leader election config setup succeeded","retryPeriod":"1m0s","leaseDuration":"4m30s","renewDeadline":"4m0s","election-namespace":"openshift-storage","election-name":"1136b8a6.topolvm.io","disable":false}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":"<IP_ADDRESS>:8080"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.builder","msg":"skip registering a mutating webhook, object does not implement admission.Defaulter or WithDefaulter wasn't called","GVK":"lvm.topolvm.io/v1alpha1, Kind=LVMCluster"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.builder","msg":"Registering a validating webhook","GVK":"lvm.topolvm.io/v1alpha1, Kind=LVMCluster","path":"/validate-lvm-topolvm-io-v1alpha1-lvmcluster"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/validate-lvm-topolvm-io-v1alpha1-lvmcluster"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"setup","msg":"starting manager"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.webhook.webhooks","msg":"Starting webhook server"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.certwatcher","msg":"Updated current TLS certificate"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.webhook","msg":"Serving webhook server","host":"","port":9443}
{"level":"info","ts":"2023-07-28T12:45:51Z","msg":"Starting server","kind":"health probe","addr":":8081"}
{"level":"info","ts":"2023-07-28T12:45:51Z","msg":"starting server","path":"/metrics","kind":"metrics","addr":"<IP_ADDRESS>:8080"}
{"level":"info","ts":"2023-07-28T12:45:51Z","logger":"controller-runtime.certwatcher","msg":"Starting certificate watcher"}
{"level":"info","ts":"2023-07-28T12:45:51Z","msg":"attempting to acquire leader lease openshift-storage/1136b8a6.topolvm.io...\n"}
{"level":"info","ts":"2023-07-28T12:46:14Z","msg":"successfully acquired lease openshift-storage/1136b8a6.topolvm.io\n"}
{"level":"info","ts":"2023-07-28T12:46:14Z","msg":"Event(v1.ObjectReference{Kind:\"Lease\", Namespace:\"openshift-storage\", Name:\"1136b8a6.topolvm.io\", UID:\"147ce12f-fda4-4df3-833d-a9dde8037ba0\", APIVersion:\"coordination.k8s.io/v1\", ResourceVersion:\"90435\", FieldPath:\"\"}): type: 'Normal' reason: 'LeaderElection' lvms-operator-c85c9f6b9-2cm8w_44c63ecb-1338-4d92-9ce3-9cd370eaab8e became leader\n"}
{"level":"info","ts":"2023-07-28T12:46:14Z","msg":"Starting EventSource","controller":"persistentvolumeclaim","controllerGroup":"","controllerKind":"PersistentVolumeClaim","source":"kind source: *v1.PersistentVolumeClaim"}
{"level":"info","ts":"2023-07-28T12:46:14Z","msg":"Starting Controller","controller":"persistentvolumeclaim","controllerGroup":"","controllerKind":"PersistentVolumeClaim"}
...

/test all

Codecov Report

Merging #370 (454095b) into main (e0ccb5c) will not change coverage.
The diff coverage is 0.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #370   +/-   ##
=======================================
  Coverage   15.76%   15.76%
=======================================
  Files          23       23
  Lines        1992     1992
=======================================
  Hits          314      314
  Misses       1654     1654
  Partials       24       24

Files Changed
Coverage Δ

api/v1alpha1/lvmcluster_webhook.go
0.00% <0.00%> (ø)

controllers/lvmcluster_controller_watches.go
0.00% <0.00%> (ø)

/test all

once https://github.com/openshift/lvm-operator/pull/371 is in will rebase and only do SNO changes here

/retest

/test all

/override ci/prow/lvm-operator-bundle-e2e-aws
/override ci/prow/ci-index-lvm-operator-static-deps

/approve

/approve


Unit test that checks for missing migrations

Subtle changes to Wagtail atomic elements can require unexpected Django migrations, and there have been a few times where PRs have failed to include them. This PR adds a new unit test that fails if there are any unapplied migrations, as determined by using the Django makemigrations command.
Additions

New core.tests.test_missing_migrations.py unit test.

Testing

Run tox core.tests.test_missing_migrations. It should pass. Make a minor change to a Wagtail atomic element (say, this help text). Run the tox command again. It should fail.

Review

@cfpb/cfgov-backends

Notes

Note that this test will not fail if there are unapplied migrations but you test with the tox -e fast testing environment, because that environment skips all migrations and seems to block the ability to detect unapplied ones.

Checklist

[X] Changes are limited to a single goal (no scope creep)
[X] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the front end playbook
[X] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[X] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

This was failing locally but passing on Travis because our run_travis.sh script wasn't actually failing the Travis build if the Python unit tests failed.

Thanks for the review @higs4281.