text:
feat(label): add 'label option for new flightresult component' option

Alaska Airlines Pull Request
Adds the label option for auro-badge

This will be used in conjunction with other components to build a single result on the flight results page. No change to other functionality.
Type of change:
Please delete options that are not relevant.

[x] New capability

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

 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.Caleb Wells seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 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.Caleb Wells seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@erikalanghauser please leave your review here for http://wakeful-grape.surge.sh/

@erikalanghauser please leave your review here for http://wakeful-grape.surge.sh/

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: CLAassistant aesthetiques ecommerceUXdesign gusnaughton

repo: AlaskaAirlines/auro-badge


text:
INPUT: Label placement issue with widths of 16% and below

Please verify the version of auro-input you have installed
@latest
Please describe the bug
See screenshot taken from Auro doc site.
It appears that there is an issue where the label placement animation has issues when the width of the form input element is short in width, approx 16%.

What also can be noticed is that the error icons are not visible at widths less than 10%. See screenshot from app team that reported the issue. Also notice placement of label with datepicker labels. Undertermined if this is related to auro-input or specific to auro-datepicker.

To reproduce, use the following steps:

Go to https://auro.alaskaair.com/components/auro/input/api
Use any bordered example
Reduce width of the input to approx 16% or less
UI issue should present with both tab and click/tap

Reproducing the error on the docsite
This issue is reproducible on the Auro docsite
Expected behavior
The label placement should be consistent regardless of input width.
NOTE: It could also be considered that a min-width would be set by the Design System as to set a documented standard of width that the UIs will always perform as expected.
What browsers are you seeing the problem on?
Firefox, Chrome, Safari, Microsoft Edge
Additional context
The issue was communicated by the AirportCustomerExperience team.  ID: 1087631

Blocked until a conversation with the design team about the layout of input.

source: gharchive/issue

repo: AlaskaAirlines/auro-formkit

license_type: permissive

license_source: github-api


text:
Number formatting for v2.2-rc

NEXT MINOR release
The following items are to be included with the next MINOR release of the auro-input element all PRs are to be from the feature branch to v2.2-rc branch.
Support an optional max length to input types to allow for confirmation code and MileagePlan number validation

[ ] Confirmation Code Validation (Carentee) 6 letters
[ ] MileagePlan number Validation (Carentee) 9 numbers
[ ] Help (Consult) Loyalty team implement auro inputs in promo space.
[ ] Known Traveler number (TSA Precheck #/Redress number)

Date formatting

[ ] #93 Additional context #77

Release issues are no longer being maintained.

repo: AlaskaAirlines/auro-input


text:
Implement additional support for build

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: #19, #20, #21
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.
The changes in this PR include:

Adding a tsconfig.json file to support typescript users
Remove all legacy IE support
Update version of chalk package

Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 1.1.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

source: gharchive/pull-request

repo: AlaskaAirlines/auro-nav


text:
Add options to persistent store

Is there a way to pass in options to the persistent store during it's initialization. I need to set NSFileProtectionComplete as an option for encryption.
[_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:@{ NSPersistentStoreFileProtectionKey : NSFileProtectionComplete } error:&error]

i know the lib is for swift just found this snippet to copy paste

You can initialize your DataContext by passing in your own DataContextOptions. This struct can have its persistentStoreOptions set.
You can pass this struct to the options parameter when initializing a ChildDataContext.
Alternatively, you can pass these in the initialization of a RootSavingDataContext that you maintain a reference to and then initialize all of your ChildDataContexts by passing them a reference to your RootSavingDataContext. If you are planning on using multiple child contexts (which you should be doing for background threads), then this is the preferred method.

@AnthonyMDev got it thanks 👍

authors: AnthonyMDev waltermvp

repo: Alecrim/AlecrimCoreData

license: mit

license_source: bigquery


text:
Calculator should evaluate single negative number

Use case:

user starts calculator
user enters <- number> expression
calculator prints result of
user closes application

Fixed in #26

repo: Alex-Diez/short-cycle-releases-katas

license: MIT


text:
Subnetwork Laplace

This PR implements subnetwork Laplace, addressing issue #16.
As you can see from the code, this is fairly straightforward. We basically just need to ask the user to specify/pass a definition of a subnetwork. We then internally store the subnetwork as a vector of indices of the flattened/vectorized model parameters that form the subnetwork (for convenience to the user, we also allow passing the subnetwork as a binary mask/vector of the size of the parameter vector, where 1s indicate the subnetwork parameters). All we then need to do is index the Jacobians / gradients to extract the part corresponding to the subnetwork, both during inference time (i.e. for constructing the GGN/Fisher) and during prediction time (i.e. for constructing the predictive covariance matrix).
Some comments/questions:

I'm aware that I still need to write tests, which I'll do (I ran some tests locally to ensure that the code works generally).
The code also doesn't support the NN+MC predictive yet, which I'll add; it shouldn't be hard to implement, as we just need to sample the subnetwork weights and then combine them with the remaining MAP weights to form a parameter vector.
Should we allow the user the change the subnetwork after instantiation, or should the subnetwork remain fixed? In either case I'd need to adapt the code accordingly. For us it would be easier to not allow changing the subnetwork, as that'd require re-fitting the Hessian etc.
We'll have to be especially careful with the logic of the subnetwork_mask setter of SubnetLaplace, which needs to correctly check that the passed subnetwork_mask is in the right format (we currently support the two formats mentioned above), as the code would break otherwise. I'll double-check the logic and also add sufficient test cases for this.
Should we update all the internal documentation to reflect the subnetwork Laplace option? As the subnetwork Laplace implementation is integrated into the full Laplace code (and just adds lines to index the Jacobians/gradients), we'd have to change everything where we refer to the full parameter vector (incl. when we define tensor shapes, e.g. where parameters would become parameters_subnet). It's not hard to change, but might make the documentation more cluttered / harder to read, as we'd have to include conditional clauses I guess.
Is there are reason why jacobians() is static? Just wondering, as it makes the code and documentation a bit uglier/longer with the subnetwork option, as we always have to pass the subnetwork_indices when calling it. Compare this with gradients(), which is not static and can therefore simply access self.subnetwork_indices.
The code currently only supports using subnetwork Laplace with a full Hessian (and throws an error otherwise). In principle it'd also be possible to also use it with diagonal or KFAC Hessians, but it makes less sense conceptually, so I'd rather not support it. But then again, we also support options like diagonal last-layer, which are also not too sensible arguably?
Finally, the current implementation requires the user to specify / pass the subnetwork. We could consider also adding functionality for automatically selecting the subnetworks. Simple choices like random subnetworks or subnetworks of the largest magnitude weights would be easy to implement. But e.g. the approach we ended up using in the subnetwork inference paper (i.e. selecting weights with the largest marginal variances, where we used SWAG for variance estimation) is a bit more involved and might make the codebase too bloated. But happy to discuss this.

Thanks a lot for your efforts in looking at this (there's no rush of course)!

1.-7. Minor comments
Looks quite nice already. I made two comments on the code directly. Here the answer/discussion to the more minor points:

Suggestions for tests: with all parameters retained, all should be equivalent to FullLaplace. With last layer retained, all should be equal to that as well.
The subnetwork should be static as you suggest because changing it really requires to rerun the entire .fit() method which is the only setup function that has a non negligible runtime.
It could make sense to reimplement the code separately for SubnetLaplace to make it more clear and potentially changeable in the future. Otherwise, one could add @property values for all class parameters that need to be masked and then override these in the Subnet class and mask correspondingly.
Yes, probably we could make the change and have Jacobians be an instance-method instead of static. I don't remember why it is like this right now. In fact, we have a similar change right now in the FunctionalLaplace PR: #55. If you can make the change to Jacobians in the backends on this branch, that would also work. I don't see any problem with this right now but there might be some..
I agree that diagonal or KFAC subnet don't make sense because KFAC would require a certain subnet structure to be sensible and the full diagonal is usually used to select the parameters of interest. I think diagonal last layer makes a little more sense but is probably also not something that should be used much..

8. Choice of subnetwork
One question regarding the choice of subnetwork in your paper: would it be possible to use the diagonal Laplace-GGN to choose the subnetwork? In fact, I thought that's what you did. Is there any reason that you (need to) use SWAG instead of Laplace to choose the subnetwork?
Because I thought that the subnetwork would be chosen using the diagonal GGN, I was thinking to just override the .fit() method with a separate run over the data_loader to select and set the subnetwork indices and then run the true .fit() computing the masked full GGN. If the method does not work with a diagonal GGN as selection criterion and we anyway also want to include different policies for selecting subnetworks, it might make sense to design a class that can be passed to the SubnetLaplace. One could implement it as follows
class SubnetMask(object):
    def __init__(self, model, likelihood, ..):
        ...

    def __call__(self, train_loader, ...):
        # select mask based on train loader, model and other hyperparams similar to a subclass of CurvatureInterface
        return mask

Then, different policies can subclass this mask, and one could potentially separately implement a SWAG-Mask, random-mask, last-layer mask (for testing?). Also, the method using diagonal GGN would be easy to implement.  What do you think about this?

I now addressed most of the remaining issues discussed. Most notably, I followed your suggestion of adding a SubnetMask class where subclasses implement different subnetwork selection strategies. For now, random, largest magnitude and last-layer subnetworks are supported. I am considering to also add the diag-Laplace subnet selection strategy you mentioned, which should indeed also be easy to implement. I am currently finalising the tests and will push those soon as well.

I also finished implementing subnet selection based on the largest marginal variances (using diagonal Laplace for variance estimation).

I also just added an implementation of the sample() method for SubnetLaplace (e.g. to use the NN predictive), which simply only samples the weights in the subnetwork and sets all other weights to their MAP estimates (had forgotten to add that earlier). I also added tests for the predictives (which are basically identical to those from test_baselaplace.py).

Hi Erik
I'm interested in this feature! Would it be possible to specify the layer names of the subnetwork. E.g. if I want to use the Laplace approximation at layer 2 and 4 and the MAP estimate at layer 1 and 3. Could you provide an example of how I could do this?

Hi @FrederikWarburg, thanks a lot for checking out our library and for your interest in the subnetwork Laplace approximation!
I agree that it would be a useful feature to be able to simply specify the names of the layers to perform the Laplace approximation over. I just implemented this functionality in two new subclasses of SubnetMask:

ParamNameSubnetMask: allows you to specify a list of parameter names (as in model.named_parameters()) to do inference over
ModuleNameSubnetMask: the same, but with module names instead (as in model.named_modules()); this for now only supports leaf modules (i.e. modules that have no children(), i.e. individual layers), as nested modules would be more complex and require a bit more thought; however, nested modules would certainly be useful to add in the future (e.g. allowing one to specify blocks of layers to perform inference over rather than having to list individual layers), as the current functionality arguably does not add much on top of ParamNameSubnetMask

Here's an example on how to use these:
import torch
from laplace import Laplace
from laplace.subnetmask import ParamNameSubnetMask, ModuleNameSubnetMask

model = torch.nn.Sequential(nn.Linear(3, 20), nn.Linear(20, 2))
likelihood = 'classification'
dataloader = None   # define valid data loader here

# subnetwork Laplace where we specify subnetwork by parameter names
subnetwork_mask = ParamNameSubnetMask
subnetmask_kwargs = dict(parameter_names=['0.weight', '1.bias'])
lap = Laplace(model, likelihood=likelihood, subset_of_weights='subnetwork', subnetwork_mask=subnetwork_mask, hessian_structure='full', subnetmask_kwargs=subnetmask_kwargs)
lap.fit(dataloader)

# subnetwork Laplace where we specify subnetwork by module names
subnetwork_mask = ModuleNameSubnetMask
subnetmask_kwargs = dict(module_names=['0'])
lap = Laplace(model, likelihood=likelihood, subset_of_weights='subnetwork', subnetwork_mask=subnetwork_mask, hessian_structure='full', subnetmask_kwargs=subnetmask_kwargs)
lap.fit(dataloader)

Finally, I changed LastLayerSubnetMask to simply be a subclass of ModuleNameSubnetMask where module_names=[last_layer_name].
@FrederikWarburg I hope this is useful. Please let me know in case you have any further questions or something doesn't work!

Awesome! Thank you for your quick reply!
I found a small error, when running on GPU. Line 59 in subnetmask.py the type is torch.cuda.ByteTensor if running on gpu. This is not part of the list and the program fails. My quick fix was just to append the cuda types to the list. Besides this, it seems to work for me!

Ah, thanks a lot for pointing that out -- I indeed haven't tested the code on GPU!
I've fixed that check to be independent of the device (your fix works as well of course).
Great to hear that it works otherwise -- let me know in case there's anything else I can help with!

Just made some small refactorings, and added an implementation of a subnetwork mask that selects the parameters with the largest marginal variances, where the variances are estimated using a diagonal SWAG posterior approximation (which is the approach used in the subnetwork inference paper).
The build seems to be failing now (locally everything was working fine), I'll investigate and fix this.

Ah ok, this was due to the recent changes introduced by https://github.com/AlexImmer/Laplace/pull/72. I merged the latest main into subnetlaplace and fixed the issue.

One question might be how to structure the new files. This PR adds three new files (subnetlaplace.py, subnetmask.py and swag.py), which are currently simply in laplace/. Perhaps it makes sense to put (a subset of) these into a dedicated sub-directory (e.g. laplace/subnetlaplace/ or laplace/subnetwork/)?

One question might be how to structure the new files. This PR adds three new files (subnetlaplace.py, subnetmask.py and swag.py), which are currently simply in laplace/. Perhaps it makes sense to put (a subset of) these into a dedicated sub-directory (e.g. laplace/subnetlaplace/ or laplace/subnetwork/)?

Other options would be:

Leave subnetlaplace.py and subnetmask.py, move content of swag.py into utils.py or create new utils directory with utils.py and swag.py.
Also create a utils directory, but move subnetmask.py, matrix.py, and feature_extractor.py there as well.

Also create a laplace/utils directory, but move subnetmask.py, matrix.py, and feature_extractor.py there as well.

I like this option, as it would make laplace a bit cleaner, but no strong preference.

On another note, I was just going to update the README to include subnetwork Laplace, and realized that low-rank Laplace is also not yet mentioned. Also, we might want to update the paper citation to mention NeurIPS. Happy to quickly make these changes.

I like this option, as it would make laplace a bit cleaner, but no strong preference.

I think this is also my preferred option. @AlexImmer?

I went through the code and it looks very good already! I have one main point to discuss:
Currently, the SubnetMask child class is passed to Laplace for initialization, along with subnetmask_kwargs; this follows the same flow used for the backend class. However, this results in some inconveniences, most notably that the subnetwork is only selected when calling fit() because only at this point the train_loader is available. If the selection was happening outside the fit() method, it would also be possible to use subnet Laplace for continual learning with the standard interface, i.e. the posterior is initialized to the prior during initialization and the Hessian is accumulated with the override=False keyword to fit() (which is currently still missing and needs to be added in any case).
So an alternative would be to keep the whole subnet selection process separate from Laplace, i.e. instantiate the SubnetMask child class outside of the Laplace class with all necessary keywords and the train loader, and also call the select method. I think then we only need to pass the subnet indices to Laplace, which also makes the code in SubnetLaplace a bit cleaner. Since the selection method and the keywords have to be manually selected by the user outside of the Laplace class anyway, I think just doing everything outside does not add much overhead for the user.
Minor notes:

Structure of laplace directory, as mentioned above.
Cost of Jacobians, but there is no easy and general fix I think.

Thanks for looking over the code and your suggestion, Runa!
You're raising a good point. I was also considering outsourcing the subnetwork mask instantiation/selection to the user, but in the end decided for the current design as it makes the user interface a little bit simpler IMO. But I agree that it might be a bit cleaner if we keep the subnetwork selection separate (and just pass either the SubnetMask instance after subnet selection or directly the subnetwork indices to Laplace()). In particular, I haven't considered the continual learning setting, which is a good reason to use this alternative design.
Happy to make that change. @AlexImmer what do you think?

Cost of Jacobians, but there is no easy and general fix I think.
By this you mean the issue that we compute the full Jacobians (over all parameters) before selecting the relevant entries corresponding to the subnetwork parameters, rather than only computing the required Jacobian entries in the first place (which should be much more efficient in theory)? I agree -- this is something I have tried to figure out for some time but couldn't find a solution for. AFAIK the PyTorch autograd engine can only compute gradients w.r.t. full parameter tensors but not sub-tensors, unfortunately (see e.g. https://discuss.pytorch.org/t/how-to-turn-off-requires-grad-for-individual-params/103303/8). Would be great to find a solution to this at some point, as it could significantly speed things up for large models.

I've now also updated the README to include both subnetwork Laplace and low-rank Laplace, and updated the paper citation to the NeurIPS version -- feel free to take a look.
@AlexImmer What were the papers that you based the low-rank Laplace implementation on? For now I've just mentioned Sharma et al. 2021 in the reference list in the README, but there's e.g. also Maddox et al. 2020 that might be relevant. We might also want to consider citing the relevant papers in the doc string of LowRankLaplace (as we e.g. also do for the marginal likelihood training script and SubnetLaplace).

Re structuring masks, utils, feature_extractor, matrix, etc. into utils/ makes sense but subnet could also have its own directory subnet/ with corresponding utilities inside. I would be fine with both.
Re passing masks only: I think this is a good idea if it works as expected. Would it be a problem that the backend requires fitting the mask before initializing laplace? This is necessary because the backend requires the subnet-indices, right?
Re references: I just implemented one way of doing subnet-laplace using the eigendecomposition. I think the Sharma reference does almost the same so let's use that one. Maddox et al don't propose a low-rank LA. In the future, we should probably add references to the docstrings, I will make an issue for that. It's a separate thing.
Re jacobians: I also thought it would be doable more efficiently but couldn't find any way for the general case when they are fully indexed.
@FrederikWarburg thanks for spotting the device error!

Thanks for your comments, Alex!
I'll address the remaining issues next week, then we can hopefully merge this in and ship the new release by the end of the year (or whenever you guys are available)?

Re structuring masks, utils, feature_extractor, matrix, etc. into utils/ makes sense but subnet could also have its own directory subnet/ with corresponding utilities inside. I would be fine with both.

Yes that's also an option. I'll try both options to see which one feels better.

Re passing masks only: I think this is a good idea if it works as expected. Would it be a problem that the backend requires fitting the mask before initializing laplace? This is necessary because the backend requires the subnet-indices, right?

Yes exactly, we'd need to fit the mask before passing it to Laplace(), as the backend will need the subnet indices. I don't think this is an issue, as it's the same way we do it now -- we'd just outsource the mask fitting to the user and not do it internally before fitting Laplace. But I might also have misunderstood your concern. In the end using subnet Laplace would look something like this:
subnetwork_mask = SubnetMask(**subnetmask_kwargs) # instantiate subnet mask
subnetwork_mask.select(train_loader) # select subnetwork
lap = Laplace(model, likelihood, subset_of_weights='subnetwork', subnetwork_mask=subnetwork_mask)

Then internally we just need to pass subnetwork_mask.indices to the backend (probably simply in the Laplace() constructor) and we're good to go.

Re references: I just implemented one way of doing subnet-laplace using the eigendecomposition. I think the Sharma reference does almost the same so let's use that one. Maddox et al don't propose a low-rank LA. In the future, we should probably add references to the docstrings, I will make an issue for that. It's a separate thing.

Sounds good!

End of year release sounds good!

Re laplace directory structure: my preferred option is a utils directory, simply because it makes everything cleaner and we already have files which would fit well in there, e.g. matrix.py and feature_extractor.py.
Re keeping the SubnetMask logic external: is it also possible to only pass subnetwork_mask.indices to Laplace? I think nothing else is needed (the n_params_subnet attribute can be derived from it)  and this enables users to choose indices even without using the SubnetMask classes or writing their custom subclass.

I have now implemented the remaining things we had discussed, namely:

I moved all utility files (feature_extractor.py, matrix.py, subnetmask.py, swag.py, utils.py) into a new laplace/utils folder
I changed the logic of SubnetLaplace to take subnetwork_indices instead of a subclass of SubnetMask; this includes careful checks for the validity of the passed subnetwork_indices
I updated the tests accordingly (i.e. by adapting existing tests to the new structure and adding new tests for custom subnetwork_indices not derived from any SubnetMask subclass)

Let me know what you think and if there is anything else that I should take care of!

I also just added an example for using SubnetLaplace (with different ways to choose the subnetwork_indices) to the README.

Probably also good for autocomplete?
On Tue, 11 Jan 2022 at 15:47, Runa Eschenhagen @.***>
wrote:

@.**** commented on this pull request.
In laplace/subnetlaplace.py
https://github.com/AlexImmer/Laplace/pull/58#discussion_r782218005:

@@ -0,0 +1,129 @@
+import torch
+from torch.distributions import MultivariateNormal

+from laplace.baselaplace import FullLaplace
+from laplace.curvature import BackPackGGN
+
+
+all = ['SubnetLaplace']
I think it determines what is imported when you call
from laplace.subnetlaplace import *
and maybe there are other effects too.
—
Reply to this email directly, view it on GitHub
https://github.com/AlexImmer/Laplace/pull/58#discussion_r782218005, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AB23RXDHXZ6RGWPMUUQD5MLUVQ7H5ANCNFSM5JBQQBVQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Regarding the line length, I also think 100 is fine for now. I think we have always used brackets ([{ for line breaks, so it would be nice to be consistent with that.
We could consider also moving marglik_training.py to the new utils directory (or just leave it where it is or in the future add something like a methods directory).

Agree with the first comment. I think in the PR are plenty of linebreaks backslash.
I wouldn't put it into utils. I think utils should only contain utilities that are required for the package and not utilities for users. The latter we can call methods later as discussed.

Thanks a lot for your comments, Alex and Runa, which I have now addressed! I also recompiled the documentation. Let me know if there is anything else that needs to be resolved.

Just realised that for some reason Travis has not been running the tests here anymore for the latest commits (I ran tests locally, where everything worked). Any idea why it's not doing this check anymore?

Just realised that for some reason Travis has not been running the tests here anymore for the latest commits (I ran tests locally, where everything worked). Any idea why it's not doing this check anymore?

We have limited compute available on Travis, so we only run the tests when merging PRs from now on. If you ran the tests locally it should be fine.

We have limited compute available on Travis, so we only run the tests when merging PRs from now on. If you ran the tests locally it should be fine.

Ah I see, makes sense!
I just merged main into subnetlaplace and re-ran the tests locally, and everything still works. So feel free to merge this into main!

authors: AlexImmer FrederikWarburg edaxberger runame

repo: AlexImmer/Laplace


text:
Dropdown ul has inline style css

I'm new to wp walkers, and I'm not sure if this is an issue with this code, but I thought I'd ask. I'm working on completing a custom WordPress theme built on BS-5 that I was handed but it didn't have dropdown support for WP menus. That's where I found your code to add to my sidebar. I copied your function code directly into my functions.php and below is in my sidebar.php file.
<?php             wp_nav_menu(array(                 'theme_location' => 'left-column-menu',                 'container' => false,                 'menu_class' => '',                 'fallback_cb' => '__return_false',                 'items_wrap' => '
%3$s
',                 'depth' => 2,                 'walker' => new bootstrap_5_wp_nav_menu_walker()             ));             ?>
The code works and creates dropdowns, however, when I click the dropdown, I see an inline style tag and javascript "data-popper-placement" tag that displays within the 2nd level ul tag like this

I can't find where this code is coming from that inserts this inline style CSS but I need to remove it because it displays poorly on the page. Could you point me in the direction to remove this style?
Any help would be much appreciated.

After doing some more research, it turns out that this is a native bootstrap process for dropdown menus. For a sidebar menu I need to use an accordion style menu,  If you have a walker that works with bootstrap accordions, I would love to take a look at it.
Thanks!

I'm glad you figured it out by yourself. At the moment I have no plan to build a walker for accordions. Thank you.

authors: AlexWebLab bosquedesigns


text:
Waybar crashes on hyprland after boot

Details
When I start my hyprland session from gdm (hyprland starts waybar) I see waybar for a split second then it crashes with the following error log:
[2023-01-18 07:25:36.459] [info] Using configuration file /home/david/.config/waybar/config
[2023-01-18 07:25:36.460] [info] Using CSS file /home/david/.config/waybar/style.css
[2023-01-18 07:25:36.579] [warning] For a functional tray you must have libappindicator-* installed and export XDG_CURRENT_DESKTOP=Unity
[2023-01-18 07:25:36.579] [warning] As using a timezone, some format args may be missing as the date library haven't got a release since 2018.
[2023-01-18 07:25:36.612] [warning] Requested height: 20 is less than the minimum height: 34 required by the modules
[2023-01-18 07:25:36.612] [info] Bar configured (width: 1886, height: 34) for output: eDP-1
[2023-01-18 07:25:36.699] [error] '4294967295' is not a valid ID (returned by default-nodes-api)

What's really strange is that if I end the hyprland session with: loginctl kill-session self and start the hyprland session again, waybar does not crash. It only crashes after logging in the first time after boot.
Helpful info

waybar --version: Waybar v0.9.16
waybar was compiled with -Dexperimental=true
display manager: GDM
OS: NixOS, my config is here

I've gotten around this issue by enabling the home manager waybar systemd service, which just restarts waybar whenever it crashes. Not that great of a solution, but it is working for me for now.

I have the same issue on Arch, here's my output from waybar -l trace:
[2023-01-24 16:12:04.907] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/config
[2023-01-24 16:12:04.907] [debug] Found config file: $XDG_CONFIG_HOME/waybar/config
[2023-01-24 16:12:04.907] [info] Using configuration file /home/nicky/.config/waybar/config
[2023-01-24 16:12:04.907] [debug] Try expanding: $XDG_CONFIG_HOME/waybar/style.css
[2023-01-24 16:12:04.907] [debug] Found config file: $XDG_CONFIG_HOME/waybar/style.css
[2023-01-24 16:12:04.907] [info] Using CSS file /home/nicky/.config/waybar/style.css
[2023-01-24 16:12:04.913] [debug] Output detection done: eDP-1 (AU Optronics 0xDE8E)
[2023-01-24 16:12:04.917] [debug] network: new default route via 192.168.86.1 on if3 metric 600
[2023-01-24 16:12:04.917] [debug] network: wlan0, new addr 192.168.86.67/24
[2023-01-24 16:12:04.924] [debug] Cmd exited with code 0
[2023-01-24 16:12:04.924] [debug] Received SIGCHLD in signalThread
[2023-01-24 16:12:04.930] [debug] Cmd exited with code 0
[2023-01-24 16:12:04.930] [debug] Received SIGCHLD in signalThread
[2023-01-24 16:12:04.931] [warning] As using a timezone, some format args may be missing as the date library haven't got a release since 2018.
[2023-01-24 16:12:04.947] [debug] GTK widget tree:
window#waybar.background.eDP-1..mode-default:dir(ltr)
  decoration:dir(ltr)
  box.horizontal:dir(ltr)
    box.horizontal.modules-left:dir(ltr)
      widget:dir(ltr)
        label#custom-system76-power-graphics:dir(ltr)
      widget:dir(ltr)
        label#custom-system76-power-profile:dir(ltr)
      widget:dir(ltr)
        label#network:dir(ltr)
      widget:dir(ltr)
        label#wireplumber:dir(ltr)
      widget:dir(ltr)
        label#backlight:dir(ltr)
    box.horizontal.modules-center:dir(ltr)
      widget:dir(ltr)
        box#workspaces.horizontal:dir(ltr)
    box.horizontal.modules-right:dir(ltr)
      widget:dir(ltr)
        label#battery:dir(ltr)
      widget:dir(ltr)
        label#cpu:dir(ltr)
      widget:dir(ltr)
        label#memory:dir(ltr)
      widget:dir(ltr)
        label#custom-gpu:dir(ltr)
      widget:dir(ltr)
        label#clock:dir(ltr)

[2023-01-24 16:12:05.078] [info] Bar configured (width: 1920, height: 34) for output: eDP-1
[2023-01-24 16:12:05.095] [error] '4294967295' is not a valid ID (returned by default-nodes-api)

I'm using v0.9.17.

I fixed the issue by removing the wireplumber module from my config.

wireplumber seems to be the problem for me as well. Perhaps a duplicate of https://github.com/Alexays/Waybar/issues/1852.

I have the same issue on NixOS with sway. For anyone looking for a quick and dirty fix, replace wayland.windowManager.sway.config.bars.*.command with this:
{
  command = builtins.toString (pkgs.writeScript "start-waybar" ''
    #! ${pkgs.bash}/bin/bash
    while true;
      do ${config.programs.waybar.package}/bin/waybar $@; sleep 1;
    done
  '');
}

I can reproduce this same issue on sway.

@NiciTheNici is it the wireplumber module?

I get the same crash on first launch of waybar after boot. Like @ok-nick [error] '4294967295' on sway/arch

same error on arch, latest waybar-hyprland v0.9.17 from AUR and wireplumber enabled
[2023-04-12 18:51:11.485] [error] '4294967295' is not a valid ID (returned by default-nodes-api)

only when just booted

Think it has something to do with how the wireplumber module handles its response to wireplumber > socket pipewire.service activation. If I enable pipewire.service directly on boot, then it doesn't crash.

this issue has started happening after i updated my system

@IllustratedMan-code does it work for you? if so, please close the issue

I actually don't use the wireplumber module anymore, but it looks like #1852 is now closed. So I'll close this in favor of that issue. If anyone still has this issue, just ping me and I'll reopen.

authors: IllustratedMan-code NiciTheNici callyral chayleaf jloomb malteo ok-nick romanstingler

repo: Alexays/Waybar


text:
Issues with git rebase

Whenever I try to rebase something with msys git 2.2.0-1 I get this error:
mv: ‘... .git/rebase-merge/git-rebase-todo.new’ and ‘... .git/rebase-merge/git-rebase-todo’ are the same file
Could not skip unnecessary pick commands

Any ideas? (It works with the git from the official site so that excludes any possible repository errors.)

@joca-bt, try to use MSYS2 Shell, not MinGW-w64 Shell.

Seems to be ok.

Rebasing works now? (I'd try to confirm it myself, but I don't know how to rebase in command line.)

authors: DJm00n elieux joca-bt


text:
New Pow r3

Sonoff has a few pow r3 versions. I have the pow r316. They can be used but the data is a bit wrong.
It shows 4 switches.

the sensors are of by a factor of 100 or 10

current should be 0.68
power should be 121.97
voltage should be 227.18
Stamac should be something
LED and RSSI are fine
@AlexxIT I can share my pow r316 with you if that helps

note: I see that the original POW R3 is not on the list of tested devices. I have several of these and they work identically to the POW R2 of which I have 1.
This issue is regarding the POW R316 and presumingly the POW R320D (I might get one of these soon.)

Did you enable the sensors via configuration.yaml? How do I know what are the names of the sensors? Thank you.

Did you enable the sensors via configuration.yaml? How do I know what are the names of the sensors? Thank you.

I did. You can find the sensors (all the entities) in the device.

Did you enable the sensors via configuration.yaml? How do I know what are the names of the sensors? Thank you.

I did. You can find the sensors (all the entities) in the device.

Thanks for your confirmation. What do you mean I can find the entities in the device? I'm curious about the names I have to put in confirmation.yaml. How about the energy sensor, which is available via cloud only (as stated in the description)?

#942

That's because I haven't made a change to the list in 2 or 3 years.
Almost any relay will be supported without integration modifications.

authors: AlexxIT VictoriousCupid shift-del1

repo: AlexxIT/SonoffLAN


text:
Cycle sort in cpp

Fixes #587 Kindly review this @raksha009 @rudrakshi99 @plazzy99 @tarun26091999

Resolve the conflict.

Resolve the conflict again pls

@OjusWiZard Done

repo: Algo-Phantoms/Algo-Tree


text:
hjefhhjfw43eh34hh f34hfh 34hjfh43 kjf43h k3jfjk34 h3jkfhkj f4j3kfj j43kj

kjdjhewjkw dhj hj wehw ejh? j1hjh! ...1m,kjdsjdh sjhads jd asjd j??? mhasmdans.
mnsmdsn
sadmadshdh amdasn mad md. hjgdashjqgdhjaw. aaw nd ad jhwajjwd. ????
jdjasz
ahjsdjadaj ajd jda jkdasj. asdhjhashad ajdaj ajwdjd ajwdja nnadsjn awjhd. ashdghasjhdghjgwq? asjhdgsa jhgd hjdghwqhj gqd. kasdyjhasghjkd!

Please do not leave spam issues.


text:
Extra rollout scrambling

Let the Recurrent batches scramble the training batches to feed to the RNN in many different ways.
In actuality this didn't improve learning performance at all and decreased FPS, so I don't want to spend much more time in it. Still, now the SamplingType is in the config of old experiments, and it may be useful...

Note: some of the RL-derived tests fail here but succeed in #27 , so we should just merge these two PRs together. Unless you think I should make this one pass too @taufeeque9


text:
gpushare-schd-extender not getting scheduled

Using minikube on p3.2xlarge. gpushare-schd-extender-x is not getting scheduled.
$ kubectl inspect gpushare

NAME      IPADDRESS     GPU0(Allocated/Total)  GPU Memory(GiB)
minikube  1.2.3.4  0/15                   0/15
----------------------------------------------------
Allocated/Total GPU Memory In Cluster:
0/15 (0%)

$ kubectl get po -n kube-system -l app=gpushare

NAME                                      READY   STATUS    RESTARTS   AGE
gpushare-device-plugin-ds-vlxrz           1/1     Running   0          11m
gpushare-schd-extender-5b869fb687-d479d   0/1     Pending   0          2m54s

$ kubectl describe node minikube

Name:               minikube
Roles:              <none>
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    gpushare=true
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Thu, 06 Jun 2019 23:01:28 +0000
Taints:             <none>
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Thu, 06 Jun 2019 23:22:28 +0000   Thu, 06 Jun 2019 23:01:27 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Thu, 06 Jun 2019 23:22:28 +0000   Thu, 06 Jun 2019 23:01:27 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Thu, 06 Jun 2019 23:22:28 +0000   Thu, 06 Jun 2019 23:01:27 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Thu, 06 Jun 2019 23:22:28 +0000   Thu, 06 Jun 2019 23:01:27 +0000   KubeletReady                 kubelet is posting ready status. AppArmor enabled
Addresses:
  InternalIP:  1.2.3.4
  Hostname:    minikube
Capacity:
 aliyun.com/gpu-count:  1
 aliyun.com/gpu-mem:    15
 cpu:                   8
 ephemeral-storage:     101583780Ki
 hugepages-1Gi:         0
 hugepages-2Mi:         0
 memory:                62873108Ki
 pods:                  110
Allocatable:
 aliyun.com/gpu-count:  1
 aliyun.com/gpu-mem:    15
 cpu:                   8
 ephemeral-storage:     93619611493
 hugepages-1Gi:         0
 hugepages-2Mi:         0
 memory:                62770708Ki
 pods:                  110
System Info:
 Machine ID:                 b2025f76037542639ab86f04ce815234
 System UUID:                EC2FFBCB-B1BD-718E-424D-5F3C92864897
 Boot ID:                    3991d985-f340-4d1f-a8a4-a6f430da359d
 Kernel Version:             4.15.0-1040-aws
 OS Image:                   Ubuntu 18.04.2 LTS
 Operating System:           linux
 Architecture:               amd64
 Container Runtime Version:  docker://18.9.6
 Kubelet Version:            v1.14.2
 Kube-Proxy Version:         v1.14.2
Non-terminated Pods:         (10 in total)
  Namespace                  Name                                CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                ------------  ----------  ---------------  -------------  ---
  kube-system                coredns-fb8b8dccf-fw9mr             100m (1%)     0 (0%)      70Mi (0%)        170Mi (0%)     20m
  kube-system                coredns-fb8b8dccf-r2f8p             100m (1%)     0 (0%)      70Mi (0%)        170Mi (0%)     20m
  kube-system                etcd-minikube                       0 (0%)        0 (0%)      0 (0%)           0 (0%)         20m
  kube-system                gpushare-device-plugin-ds-vlxrz     1 (12%)       1 (12%)     300Mi (0%)       300Mi (0%)     13m
  kube-system                kube-addon-manager-minikube         5m (0%)       0 (0%)      50Mi (0%)        0 (0%)         19m
  kube-system                kube-apiserver-minikube             250m (3%)     0 (0%)      0 (0%)           0 (0%)         19m
  kube-system                kube-controller-manager-minikube    200m (2%)     0 (0%)      0 (0%)           0 (0%)         19m
  kube-system                kube-proxy-bm6mt                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         20m
  kube-system                kube-scheduler-minikube             100m (1%)     0 (0%)      0 (0%)           0 (0%)         15m
  kube-system                storage-provisioner                 0 (0%)        0 (0%)      0 (0%)           0 (0%)         20m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource              Requests     Limits
  --------              --------     ------
  cpu                   1755m (21%)  1 (12%)
  memory                490Mi (0%)   640Mi (1%)
  ephemeral-storage     0 (0%)       0 (0%)
  aliyun.com/gpu-count  0            0
  aliyun.com/gpu-mem    0            0
Events:
  Type    Reason                   Age                From                  Message
  ----    ------                   ----               ----                  -------
  Normal  Starting                 21m                kubelet, minikube     Starting kubelet.
  Normal  NodeAllocatableEnforced  21m                kubelet, minikube     Updated Node Allocatable limit across pods
  Normal  NodeHasSufficientMemory  21m (x8 over 21m)  kubelet, minikube     Node minikube status is now: NodeHasSufficientMemory
  Normal  NodeHasNoDiskPressure    21m (x8 over 21m)  kubelet, minikube     Node minikube status is now: NodeHasNoDiskPressure
  Normal  NodeHasSufficientPID     21m (x7 over 21m)  kubelet, minikube     Node minikube status is now: NodeHasSufficientPID
  Normal  Starting                 20m                kube-proxy, minikube  Starting kube-proxy.

$ kubectl describe -n kube-system po gpushare-schd-extender-5b869fb687-d479d

Name:               gpushare-schd-extender-5b869fb687-d479d
Namespace:          kube-system
Priority:           0
PriorityClassName:  <none>
Node:               <none>
Labels:             app=gpushare
                    component=gpushare-schd-extender
                    pod-template-hash=5b869fb687
Annotations:        scheduler.alpha.kubernetes.io/critical-pod:
Status:             Pending
IP:
Controlled By:      ReplicaSet/gpushare-schd-extender-5b869fb687
Containers:
  gpushare-schd-extender:
    Image:      registry.cn-hangzhou.aliyuncs.com/acs/k8s-gpushare-schd-extender:1.11-d170d8a
    Port:       <none>
    Host Port:  <none>
    Environment:
      LOG_LEVEL:  debug
      PORT:       12345
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from gpushare-schd-extender-token-w2xm9 (ro)
Conditions:
  Type           Status
  PodScheduled   False
Volumes:
  gpushare-schd-extender-token-w2xm9:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  gpushare-schd-extender-token-w2xm9
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  node-role.kubernetes.io/master=
Tolerations:     node-role.kubernetes.io/master:NoSchedule
                 node.cloudprovider.kubernetes.io/uninitialized:NoSchedule
                 node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  19s (x2 over 95s)  default-scheduler  0/1 nodes are available: 1 node(s) didn't match node selector.

Resolved using
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.10/nvidia-device-plugin.yml

Resolved using
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v1.10/nvidia-device-plugin.yml

This is not work for me.
I add a label to the node and the problem is gone:
kubectl label node <your-node> node-role.kubernetes.io/master=""

How can you fix this issue? I tried but it's not work. Can you share your gpushare-schd-extender.yaml file?

@vkartik97 any update about this issue?


text:
fix(eval): Use cp -r instead of mv for SWE-Bench Initialization

End-user friendly description of the problem this fixes or functionality that this introduces

[ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Give a summary of what the PR does, explaining any non-trivial design decisions
For some reason, mv /testbed causes the conda environment to break (most likely because some packages are installed inside docker are based on the absolute path of /testbed)

Link of any specific issues this addresses

cc @ryanhoangt

Unstake

I don't really have specific error messages beside the agent tries to conda install astropy because it fails to run python reproduce.py due to dependency issue 😓

authors: baxitfund xingyaoww

repo: All-Hands-AI/OpenHands


text:
implement encoding caching Saves time and energy

To implement encoding caching and updating based on changes in the vault.txt file, you can modify the code as follows:
python
import torch
from sentence_transformers import SentenceTransformer, util
import os
from openai import OpenAI

# ANSI escape codes for colors
PINK='\033[95m'
CYAN='\033[96m'
YELLOW='\033[93m'
NEON_GREEN='\033[92m'
RESET_COLOR='\033[0m'

# Configuration for the Ollama API client
client=OpenAI(
    base_url='http://localhost:11434/v1',
    api_key='NA',
    timeout=660  # Increase the timeout to 60 seconds (or any desired value)
)

# Function to open a file and return its contents as a string
def open_file(filepath):
    with open(filepath, 'r', encoding='utf-8') as infile:
        return infile.read()

# Function to get relevant context from the vault based on user input
def get_relevant_context(user_input, vault_embeddings, vault_content, model, top_k=3):
    if vault_embeddings.nelement() == 0:  # Check if the tensor has any elements
        return []
    # Encode the user input
    input_embedding=model.encode([user_input])
    # Compute cosine similarity between the input and vault embeddings
    cos_scores=util.cos_sim(input_embedding, vault_embeddings)[0]
    # Adjust top_k if it's greater than the number of available scores
    top_k=min(top_k, len(cos_scores))
    # Sort the scores and get the top-k indices
    top_indices=torch.topk(cos_scores, k=top_k)[1].tolist()
    # Get the corresponding context from the vault
    relevant_context=[vault_content[idx].strip() for idx in top_indices]
    return relevant_context

# Function to interact with the Ollama model
def ollama_chat(user_input, system_message, vault_embeddings, vault_content, model):
    # Get relevant context from the vault
    relevant_context=get_relevant_context(user_input, vault_embeddings, vault_content, model)
    if relevant_context:
        # Convert list to a single string with newlines between items
        context_str="\n".join(relevant_context)
        print("Context Pulled from Documents: \n\n" + CYAN + context_str + RESET_COLOR)
    else:
        print(CYAN + "No relevant context found." + RESET_COLOR)

    # Prepare the user's input by concatenating it with the relevant context
    user_input_with_context=user_input
    if relevant_context:
        user_input_with_context=context_str + "\n\n" + user_input

    # Create a message history including the system message and the user's input with context
    messages=[
        {"role": "system", "content": system_message},
        {"role": "user", "content": user_input_with_context}
    ]
    # Send the completion request to the Ollama model
    response=client.chat.completions.create(
        model="dolphin-llama3:latest", # llama3:latest  mistral
        messages=messages
    )
    # Return the content of the response from the model
    return response.choices[0].message.content

# How to use:
# Load the model and vault content
model=SentenceTransformer("all-MiniLM-L6-v2")
vault_content=[]
if os.path.exists("vault.txt"):
    with open("vault.txt", "r", encoding='utf-8') as vault_file:
        vault_content=vault_file.readlines()

vault_embeddings=model.encode(vault_content) if vault_content else []

# Convert to tensor and print embeddings
vault_embeddings_tensor=torch.tensor(vault_embeddings)
print("Embeddings for each line in the vault:")
print(vault_embeddings_tensor)

# Example usage
user_input=input(YELLOW + "Ask a question about your documents: " + RESET_COLOR)
system_message="You are a helpful assistat that is an expert at extracting the most useful information from a given text"
response=ollama_chat(user_input, system_message, vault_embeddings_tensor, vault_content, model)
print(NEON_GREEN + "Mistral Response: \n\n" + response + RESET_COLOR)

In this updated version of the code:
I added logic to check if the vault.txt file has been modified since the last time the embeddings were generated. If it has been modified, the embeddings will be regenerated.
Embeddings are saved to a file named "vault_embeddings.pt" for future use. If the file exists and is up to date, the embeddings will be loaded from it instead of being regenerated.
If the vault.txt file doesn't exist, a message will be displayed indicating that the file is not found.
I used a variable embeddings_file_path to store the path to the embeddings file, ensuring consistency throughout the code.
The regeneration of embeddings occurs only if the embeddings file does not exist or is outdated.

Cool, you can do pull req if you think this is a good improv:)

authors: AllAboutAI-YT jamieduk

repo: AllAboutAI-YT/easy-local-rag


text:
Is there a TableHeaderColumn title option available

Hi Allen, is there a way to set a title to the TableHeaderColumn?
Here is what I have:
<TableHeaderColumn dataField='startdate'>SD</TableHeaderColumn>

    SD

Here is what I would like to have:
<TableHeaderColumn dataField='startdate' title='starting date'>SD</TableHeaderColumn>

    SD

using: react-bootstrap-table 4.1.0

headerText does the trick.

repo: AllenFang/react-bootstrap-table


text:
Updating names of boxes and towers

Pull Request instructions:

Please follow the update protocol
Answer the questions below in detail. Your responses will be emailed to experimenters.
If the experimenters must do anything new, provide detailed step by step instructions on the wiki
Use markdown syntax in order for your comments to be rendered reliably in the email: "1." instead of "1)", use four spaces for indents.
If you use the keyword "skip email" in the title, it will skip the email updates
Merges from "production_testing" into "main" should use the keyword "production merge" in the title for reliable indexing of updates

Describe changes:

Our change in naming convention prompts updates to how we refer to boxes, and towers. I'm using this as an opportunity to fix some confusing terms in the code. I also realized that #145 is flawed in that the boxes will still be referred to as A-D in the tower, so I am effectively reversing that PR.
The code is still a little confusing because of two issues:

First, internally, and when loading settings and calibration files it uses the nomenclature of box1,2,3,4, not A,B,C,D. But I don't think this is worth fixing because when we move to one box/computer, we wont need all this logic anyways (https://github.com/AllenNeuralDynamics/dynamic-foraging-task/issues/157)
Second, https://github.com/AllenNeuralDynamics/dynamic-foraging-task/issues/156

What issues or discussions does this update address?

#147
Reverses #145
Fixes changes prompted by https://github.com/AllenNeuralDynamics/aind-behavior-blog/issues/158

Describe the expected change in behavior from the perspective of the experimenter

no changes

Describe the outcome of testing this update on a rig in 447

[x] tested in 447

@hanhou @XX-Yin Can you review this PR?

You rename box like 447-1-A. Do you add these boxes name to the GUI object Tower? If not, the GUI can't select 447-1-A.

No, I didn't. My plan was to remove the GUI object Tower altogether (see https://github.com/AllenNeuralDynamics/dynamic-foraging-task/pull/158)

You rename box like 447-1-A. Do you add these boxes name to the GUI object Tower? If not, the GUI can't select 447-1-A.

No, I didn't. My plan was to remove the GUI object Tower altogether (see #158)

That sounds good! I will approve this.
We should add the new rig name to the GUI like shown below if we make changes.

authors: XX-Yin alexpiet


text:
Lost access to Completion3D dataset

Thanks for the nice work!
Recently I want to reproduce your paper result on the Completion3D dataset, however, the official standford completion3d dataset link no longer works...
Although I know this is not relevant to SnowflakeNet, do you have a copy of completion3D that can be shared? Thanks

hello, have found how to get that?

authors: symphonylyh thachdo

repo: AllenXiangX/SnowflakeNet


text:
[SMALLFIX] Fix WebUI when UFS is lost

Before: when UFS is lost, a tracestack is shown on the webUI
HTTP ERROR 500
Problem accessing /home. Reason:

    Server Error
Caused by:
java.net.ConnectException: Call From localhost/127.0.0.1 to localhost:9000 failed on connection exception: java.net.ConnectException: Connection refused; For more details see:  http://wiki.apache.org/hadoop/ConnectionRefused
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.apache.hadoop.net.NetUtils.wrapWithMessage(NetUtils.java:783)
	at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:730)
	at org.apache.hadoop.ipc.Client.call(Client.java:1351)
	at org.apache.hadoop.ipc.Client.call(Client.java:1300)
	at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)
	at com.sun.proxy.$Proxy8.getFsStats(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:186)
	at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
	at com.sun.proxy.$Proxy8.getFsStats(Unknown Source)
	at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getStats(ClientNamenodeProtocolTranslatorPB.java:521)
	at org.apache.hadoop.hdfs.DFSClient.getDiskStatus(DFSClient.java:2081)
	at org.apache.hadoop.hdfs.DistributedFileSystem.getDiskStatus(DistributedFileSystem.java:893)
	at alluxio.underfs.hdfs.HdfsUnderFileSystem.getSpace(HdfsUnderFileSystem.java:280)
	at alluxio.underfs.UnderFileSystemWithLogging$16.call(UnderFileSystemWithLogging.java:293)
	at alluxio.underfs.UnderFileSystemWithLogging$16.call(UnderFileSystemWithLogging.java:290)
	at alluxio.underfs.UnderFileSystemWithLogging.call(UnderFileSystemWithLogging.java:556)
	at alluxio.underfs.UnderFileSystemWithLogging.getSpace(UnderFileSystemWithLogging.java:290)
	at alluxio.web.WebInterfaceGeneralServlet.populateValues(WebInterfaceGeneralServlet.java:208)
	at alluxio.web.WebInterfaceGeneralServlet.doGet(WebInterfaceGeneralServlet.java:128)

After

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18705/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18708/
Test PASSed.

Merged build finished. Test PASSed.

repo: Alluxio/alluxio


text:
LDAP server not found

Hello!
Per this thread I'm excited to give PassTheCert a try but am having an issue.  When I run this...
PassTheCert.exe --server FQDN.OF.A.DOMAINCONTROLLER --cert-path domainadmin.pfx --elevate --target "DC=victim,DC=domain" --sid XXX
I get this:
Unhandled Exception: System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
   at System.DirectoryServices.Protocols.LdapConnection.Connect()
   at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID)
   at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
   at PassTheCert.Program.GetSecurityDescriptor(LdapConnection connection, String target, String filter, String attribute, Boolean flag_control)
   at PassTheCert.Program.AclAttack(LdapConnection connection, String target, String filter, String attribute, AccessControlEntry[] new_aces, String restore_file, Boolean flag_control)
   at PassTheCert.Program.ElevateUserAttack(LdapConnection connection, String target, String sid, String restore_file)
   at PassTheCert.Program.Main(String[] args)

Any thoughts?  The FQDN.OF.A.DOMAINCONTROLLER is resolvable and online (and a DC :-)

Not sure if it matters, but one thing I noticed is if I do nmap -p389,636 FQDN.OF.A.DOMAINCONTROLLER it reports as "down" but if I add the no-ping flag of -Pn the nmap finishes with the results I expect.

Hi!
By default, PassTheCert tries the LDAPS port. Is it reported as open in your nmap scan? Either way, you can try using --start-tls, which will connect to the LDAP port. Let me know your results.

Thank you again @the-useless-one for the super fast help.  The LDAPS did report as open.
This is a huge environment and I tried all the other DCs just for grins, and the last one worked!  So I didn't end up trying start-tls but I'll make note of it.
I'll check my new (hopefully) super powers and report back on the certipy thread as to how things go...

Hi,
I'm currently having the same issue.
I started troubleshooting the same way @braimee did here, starting all the way back from the Certipy thread.
Likewise, I also received the Kerberos SessionError: KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type) error. And I'm currently stuck on the error showed below.
Unhandled Exception: System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
   at System.DirectoryServices.Protocols.LdapConnection.Connect()
   at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID)
   at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
   at PassTheCert.Program.GetSecurityDescriptor(LdapConnection connection, String target, String filter, String attribute, Boolean flag_control) in [PATH]\PassTheCert.cs:line 117
   at PassTheCert.Program.AclAttack(LdapConnection connection, String target, String filter, String attribute, AccessControlEntry[] new_aces, String restore_file, Boolean flag_control) in [PATH]\PassTheCert.cs:line 205
   at PassTheCert.Program.ElevateUserAttack(LdapConnection connection, String target, String sid, String restore_file) in [PATH]\PassTheCert.cs:line 228
   at PassTheCert.Program.Main(String[] args) in [PATH]\PassTheCert.cs:line 491

I've tried different DCs, all with port 389 and 636 fully open (as shown in nmap).
The --start-tls also just throws a different error for me.
Unhandled Exception: System.DirectoryServices.Protocols.TlsOperationException: An unspecified operation error occurred.
   at System.DirectoryServices.Protocols.LdapSessionOptions.StartTransportLayerSecurity(DirectoryControlCollection controls)
   at PassTheCert.Program.Main(String[] args) in [PATH]\PassTheCert.cs:line 479

Any thoughts on why this error occurs?

Hi @DeserranoJorden,
This is weird. Would you be able to provide a Wireshark capture? One for LDAPS and one for LDAP with StartTLS would be great.
Cheers,
Y

authors: DeserranoJorden braimee the-useless-one

repo: AlmondOffSec/PassTheCert


text:
Issue While connecting Frontend

Issue Description
I followed all the steps mentioned in the documentation and watched your YouTube video to create a "FullStack Solana development with React and Anchor" project. Everything worked smoothly until I reached the frontend part.
Problem 1: IDL File
In the documentation, it instructs to create a new folder named anchor in front-end/src and copy over target/types/counter.ts (from the Anchor program) to a new file called idl.ts. The purpose of this step is to use the IDL to create TypeScript objects for interacting with the program.
However, when I opened target/types/counter.ts, I found that it's different from what was expected. It contains additional content, and the line export const IDL: Counter = { ... } is missing.
My counter.ts was like:

```typescript
/**
 * Program IDL in camelCase format in order to be used in JS/TS.
 *
 * Note that this is only a type helper and is not the actual IDL. The original
 * IDL can be found at `target/idl/counter.json`.
 */
export type Counter = {
    "address": "2FcNSYHzEP7gXYZA4YMfiznRVAj7JpZF8Z4fWL7xw9jK",
    "metadata": {
        "name": "counter",
        "version": "0.1.0",
        "spec": "0.1.0",
        "description": "Created with Anchor"
    },
    "instructions": [
        {
            "name": "increment",
            "discriminator": [
                11,
                18,
                104,
                9,
                104,
                174,
                59,
                33
            ],
            "accounts": [
                {
                    "name": "counter",
                    "writable": true,
                    "pda": {
                        "seeds": [
                            {
                                "kind": "const",
                                "value": [
                                    99,
                                    111,
                                    117,
                                    110,
                                    116,
                                    101,
                                    114
                                ]
                            }
                        ]
                    }
                }
            ],
            "args": []
        },
        {
            "name": "initialize",
            "discriminator": [
                175,
                175,
                109,
                31,
                13,
                152,
                155,
                237
            ],
            "accounts": [
                {
                    "name": "user",
                    "writable": true,
                    "signer": true
                },
                {
                    "name": "counter",
                    "writable": true,
                    "pda": {
                        "seeds": [
                            {
                                "kind": "const",
                                "value": [
                                    99,
                                    111,
                                    117,
                                    110,
                                    116,
                                    101,
                                    114
                                ]
                            }
                        ]
                    }
                },
                {
                    "name": "systemProgram",
                    "address": "11111111111111111111111111111111"
                }
            ],
            "args": []
        }
    ],
    "accounts": [
        {
            "name": "counter",
            "discriminator": [
                255,
                176,
                4,
                245,
                188,
                253,
                124,
                25
            ]
        }
    ],
    "types": [
        {
            "name": "counter",
            "type": {
                "kind": "struct",
                "fields": [
                    {
                        "name": "count",
                        "type": "u64"
                    },
                    {
                        "name": "bump",
                        "type": "u8"
                    }
                ]
            }
        }
    ]
};

Problem 2: Error in setup.js
After adding the setup.js file, which looks like this:
import { IdlAccounts, Program } from "@coral-xyz/anchor";
import { IDL, Counter } from "./idl";
import { clusterApiUrl, Connection, PublicKey } from "@solana/web3.js";

const programId = new PublicKey("2FcNSYHzEP7gXYZA4YMfiznRVAj7JpZF8Z4fWL7xw9jK");
const connection = new Connection(clusterApiUrl("devnet"), "confirmed");

export const program = new Program<Counter>(IDL, programId, {
  connection,
});

export const [mintPDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("mint")],
  program.programId,
);

export const [counterPDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter")],
  program.programId,
);

export type CounterData = IdlAccounts<Counter>["counter"];

I encountered an error at the line export const program = new Program<Counter>(IDL, programId, { connection, });, which says:
Argument of type 'PublicKey' is not assignable to parameter of type 'Provider'.
Property 'connection' is missing in type 'PublicKey' but required in type 'Provider'.

Problem 3: Error in Frontend
Following the subsequent steps and adding <CounterState/> in App.tsx, I encountered an error in the frontend console:
Uncaught TypeError: Cannot read properties of undefined (reading 'size')
    at new AccountClient (@coral-xyz_anchor.js?v=7e705056:10404:39)
    at @coral-xyz_anchor.js?v=7e705056:10369:30
    at Array.reduce (<anonymous>)
    at AccountFactory.build (@coral-xyz_anchor.js?v=7e705056:10368:70)
    at NamespaceFactory.build (@coral-xyz_anchor.js?v=7e705056:11480:51)
    at new _Program (@coral-xyz_anchor.js?v=7e705056:11560:98)
    at setup.ts:10:24

Steps Taken

Followed all steps mentioned in the documentation and video.
Checked for typos and ensured correct file placements.
Reviewed code for any missing or incorrect configurations.

Additional Information

Operating System: Windows(using WSL)
solana --version; node -v; yarn --version; anchor --version
solana-cli 1.18.9 (src:9a7dd9ca; feat:3469865029, client:SolanaLabs)
v20.8.0
1.22.22
anchor-cli 0.30.0

Your first issue may be due to a breaking change in Anchor IDLs. Read more here. I was able to fix a similar issue by ensuring the version of Anchor in anchor.toml on the backend matched that in package.json for the frontend.

Same issue here, I tried switching back to Anchor 0.29.0 and that brought up different issues since the generated IDL was different

Same issue here.
https://github.com/coral-xyz/anchor/issues/2914#issuecomment-2084711323

All your problems are related to using Anchor 0.30, which had a bunch of breaking changes. I suggest completing the project with 0.29 instead.
Use avm use 0.29 and yarn add @coral-xyz/anchor@0.29. Make sure Anchor is on v0.29 in your CLI, counter, AND front-end. You'll have to start over with the contract but you can reuse the front-end.

Problem 1: IDL File
0.30 separates the types and the IDL. Instead of just making a types file, you'd copy over:

/target/idl/counter.json
/target/types/counter.ts

Put these in front-end/src/anchor and use them like this:
import * as idl from "./counter.json";
import type { Counter } from "./counter";

Problem 2: Error in setup.js
When creating a program interface in Anchor 0.30, you can't add programId anymore

You'd just do sth like
export const program = new Program(idl, provider);

But I haven't gotten this to work yet cuz provider is breaking.

Problem 3: Error in Frontend
Likely related to the IDL changes in v0.30 but I can't confirm.

Same issue here, I tried switching back to Anchor 0.29.0 and that brought up different issues since the generated IDL was different

@adlonymous see above. You need to have 0.29 in all three places.

Pretty sure, I'm using 0.29.0, but I get in the browser console:
setup.ts:15 Uncaught ReferenceError: Buffer is not defined
    at setup.ts:15:4

Added this into setup.ts and it appears to work now:
import { Buffer } from "buffer"
import * as process from "process"

globalThis.Buffer = Buffer as unknown as BufferConstructor;
globalThis.process = process as unknown as NodeJS.Process;

You'd just do sth like
export const program = new Program(idl, provider);

But I haven't gotten this to work yet cuz provider is breaking.

Problem 3: Error in Frontend

Likely related to the IDL changes in v0.30 but I can't confirm.

Change Provider To AnchorProvider to fix Provider breaking:
https://coral-xyz.github.io/anchor/ts/classes/AnchorProvider.html
Let me know if that fixes it for you cause I'm still working on figuring out the idl and typescript changes in Anchor 0.30.0. Why do they do stuff like rename functions and classes and make breaking idl changes? I hate it. I've been trying to get my frontend to work for 3 weeks now, meanwhile the on chain Rust code has been really smooth for me when it comes to cross compiling and deploying into bytecode.

How to build a Provider using only the public key?

authors: Ajitchy AlmostEfficient CryptoCooker adlonymous gameuser1982 ilyacherevkov lostintime101 pwh-pwh

repo: AlmostEfficient/full-stack-solana-dev


text:
Linux lubuntu startx

Hi I got lubuntu and i have installed EmulationStation on that. Whiles in EmulationStation i have an app section called desktop.sh with startx to launch the desktop environment but when i go into the desktop it launch back into EmulationStation

Sounds like the process/script that launches your desktop exits (likely by forking additional processes then exiting the parent process) which causes EmulationStation to think that the "program" it launched has finished.
This is tied into the bigger problem that ES has no way of tracking child processes of programs it starts. The same issue is present if you try and launch Steam games, because Steam then forks off to a sub-process and EmulationStation goes back to taking focus.

repo: Aloshi/EmulationStation


text:
Add TokenScript branding to bottom of Settings screen

Notice the extra empty vertical margin at the bottom

Applicable for forks too.

It won't look like this in the initial version, but will show the right information. We are refactoring this view.

@JamesSmartCell yeah, sorry, should have pointed it out. iOS doesn't look like that yet too. Just a reference from the "footer".

https://github.com/AlphaWallet/alpha-wallet-android/pull/1055

authors: James-Sangalli JamesSmartCell hboon

repo: AlphaWallet/alpha-wallet-android


text:
Informasjon forsvinner i pdf ved "hidden" og "shadowFields"

Description of the bug
Ved bruk av "hidden" i layout i kombinasjon med "shadowFields" i applicationmetadata.json, genereres ikke pdf riktig/komplett, i noen tilfeller.
Dette fungerer greit når en side SKAL skjules, men når siden IKKE skal skjules, så genereres ikke Pdf'en alltid rett. Informasjon som egentlig skal vises, vises ikke.
Gjenskaping er vist under ved å peke på eksempler.
Steps To Reproduce
Eksempel: Pdf mangler informasjon (når "hidden" = false)
Layouts, JSON file:
{
  "$schema": "https://altinncdn.no/schemas/json/layout/layout.schema.v1.json",
  "data": {
    "hidden": ["notEquals", ["dataModel", "SF_IsPlisPerson"], true],
    "layout": [
...

applicationmetadata.json:
"appLogic": {
        "autoCreate": true,
        "classRef": "Altinn.App.Models.Form",
        "shadowFields": {
          "prefix": "SF_"
        },
        "allowAnonymousOnStateless": false,
        "autoDeleteOnProcessEnd": false
      },

Workaround --> Pdf komplett (når "hidden" = false)
{
  "$schema": "https://altinncdn.no/schemas/json/layout/layout.schema.v1.json",
  "data": {
    "hidden": ["equals", ["dataModel", "SF_IsPlisPerson"], false],
    "layout": [
...

applicationmetadata.json:
"appLogic": {
        "autoCreate": true,
        "classRef": "Altinn.App.Models.Form",
        "shadowFields": {
          "prefix": "SF_"
        },
        "allowAnonymousOnStateless": false,
        "autoDeleteOnProcessEnd": false
      },

Workaround (men... som da fjerner hensikten med skjulte felt :smirk:) --> Pdf komplett
applicationmetadata.json:
"appLogic": {
        "autoCreate": true,
        "classRef": "Altinn.App.Models.Form",

        "allowAnonymousOnStateless": false,
        "autoDeleteOnProcessEnd": false
      },

Additional Information
No response

Feilen oppstår fordi vi rydder bort skyggefelt fra datamodellen før PDF-generering.
Denne oppryddingen bør ikke skje ved slutten av et prosess-steg, og heller noe vi bør gjøre før innsending av hele instansen - ellers vil det kræsje ved tilfeller som dette, samt ved annen funksjonalitet vi har levert, som muligheten for å låse opp igjen låste datamodeller og gå bakover i prosessen.

Dette caset er også dokumentert i docs, man kan opprette egen datatype for å inneholde dataene som er "vasket" (altså uten hjelpefeltene): https://docs.altinn.studio//app/development/configuration/shadowfields/#saving-a-copy-of-form-data-without-helper-fields

Needs acceptance criterias.

authors: Magnusrm nkylstad olemartinorg tonygrimstad

repo: Altinn/app-lib-dotnet


text:
App does not start

Description:
App does not start
Steps to reproduce:
Just start an app. New window is opened, and always white. This version worked twice after instalation. Previous version works.
App version:
2.0.1-beta
OS:
Windows 7, x64
Works in WhatsApp Web:
Extra:
[Not answered]

I have the same issue on OSX 10.10.5. Last version worked perfect but dont have that installer anymore as this update overwrote the last one.
i miss the app.

authors: aluxian-huginn undersmusic

repo: Aluxian/Facebook-Messenger-Desktop


text:
Wasm runtime performance

wasm-bridge currently employs JCO to facilitate conversion of a WebAssembly component into a module and JavaScript bindings to call the WebAssembly interface, much like wasm-bindgen.
This allows calling a wasm function using a javascript Object such as { width: 10, height: 16.4, pos: { x: f32, y: f32 } }. This is used for easily calling a wasm module with a wit interface easily from javascript, and facilitates an easy adoption and integration of webassembly in javascript codebases.
Motivation
At the guest/host boundary, the rust arguments are converted to javascript Objects which are passed through the JCO bindings. They are then destructured and converted into the appropriate calling convention for use with the C-ABI wasm function.
This approach makes heavy use of dynamic object and list accesses and construction, which  requires many javascript roundtrips per compound type and allocations, as well as increased memory bandwidth in the overhead of javascript objects and data duplication and deep cloning. This is the reason that component-query-eval and garbage collection in hot loops show up in so much in the profiling along with Vec contructions, as each transfer of a query's results require hundreds of Js roundtrips and calls to Reflect.set (and later Array.set) per item, and then equivalent linear complexity when destructured by JCO into pointers and traversed back and allocated once again into linear memory for the destination wasm.
Proposal
I propose to implement a custom transfer method which will allow almost direct transfer of data through the host <=> guest boundary. This will increase the throughput of the boundary and will most notably decrease the use of string decoding and encoding, as well as Array.set methods and allocations as things can be transferred as memory directly rather than going through an idiomatic Js representation. This will improve performance of our user side scripts and give a much bigger headroom for processing a frame in time and improve the frame rate.
Implementation
WebAssembly functions can only work with stack based primitives, such as integers and float. As such, transferring and calling functions with composite types such as structs, enum, vecs or strings is not possible directly.
wit-bindgen is used to transform these rich guest code functions into primitive C-ABI functions which then calls the user side rich version.
Structs and other composite types are converted into separate arguments in the function itself, so a function which takes a single struct as an argument will thus need to take n arguments corresponding to each field of the struct. The original struct will then be reassembled before your implementation is called.
Vectors, Strings, and other heap objects will be converted into an allocation in the local wasm linear memory, and two arguments, a pointer and a length, passed like structs like two separate arguments. wit-bindgen will then reconstruct your vector or string using the pointer and length. The pointer points to newly allocated owned memory within the wasm memory itself.
Noteworthy is that pointers can not be shared between wasm modules or the host due to the sandboxing. They will first have to be allocated and copied into the targeted module as an owned memory buffer as mentioned above.
Vectors of structs or vectors of vectors work similarly and the same rules apply recursively.
For this to work, the host implementation is thus responsible for being the all caring parent and nicely allocating memory inside the guest wasm and copying the relevant data into it, and then giving the new pointer to the function to call. Essentially setting the table for the guest.
This is what wasmtime does natively. On Javascript, there is absolutely no change on the guest side. To facilitate the host side of bargain wasm-bridge employs the help of JCO which takes care of allocating memory and filling the arguments, as well as the memory buffers using primitives thorugh the various Uint8Buffer, UInt32Buffer.
For example a Vec<Rectangle> with Rectangle { width: u32, height: u32 } will be transferred by allocating a heap buffer of suitable size, and then pushing two u32 for each rectangle. The pointer and the length of the buffer will be passed over the FFI boundary.
This is the steps which JCO provides by creating a javascript polyfill so that you can interact with the wasm component using javascript idiomatic objects and arrays. This is intended for using and calling WebAssembly conveniently from javascript as a user, say if you are writing a javascript website using react and need some high performance webassembly module for e.g an interactive canvas.
This human friendly format is not needed if it is used by a crate in Rust. It only creates more steps and work as Rust types from the host need to be converted into javascript objects through what is essentially json serialization but to an object instead of a string. These Objects and Arrays are then destructured by JCO to fill the byte buffers.
For example, a list of aforementioned rectangles will go through these steps

Rust: [u32, u32, u32, u32...] (Vec<Rectangle> memory layout)
Js: [ { width: Integer, height: Integer },  { width: Integer, height: Integer }, ...] Constructed incrementally using dynamic lookup and sets
Js: ArrayBuffer [ u32, u32, u32, u32 ] This is done by iterating each element in the array and destructuring each and every struct into its fields, and casting them to integers. This code is generated from the wit interface as well.
Rust(guest): Vec::from_raw_parts(pointer, len) => [ u32, u32, u32, u32 ] This step is done entirely in the guest code using wit-bindgen when the module is compiled. This is agnostic to the runtime, as the host above makes sure to fill a byte buffer using the expected memory layout and endianness.

We managed to improve performance multifold (about 5x when measuring tangent) by changing the javascript step from [ { k:v, k:v, ... }, { ... }, ... ] to [ [v, v,...], [...], [...] ] which drastically reduced reflection and dynamic string lookups as we omitted the fields.
However, this required us to fork JCO to use this format instead, which breaks the public API as users can no longer interact with it using javascript objects with named fields through E.g node or js. As such, it can not be upstreamed. When I did this I knew very well that it was a hack as we've essentially integrated an implementation detail and field ordering in JCO itself.
The new solution will be to omit the javascript polyfill entirely and instead write the ArrayBuffer from Rust directly using the appropriate javascript APIs. We will not be able to completely get around javascript, as we need to call a javascript function to write to an array buffer in much the same way that we bind to javascript to get the current time or date, or use webgpu. There is unfortunately no way around that, as Js is effectively our system interface. However, this is vastly more efficient than the current solution and does not require additional allocation or encoding. Think of it like a system or kernel call.
All the required APIs exist to make this possible exist as of today, and are in fact already employed by wgpu as it uses an ArrayBuffer to write POD structs as raw bytes from our Rust renderer to the javascript webgpu buffer and then ultimately to the gpu.
See https://rustwasm.github.io/wasm-bindgen/examples/hello-world.html for a brief introduction of why wasm-bindgen is needed.
Workflows
In order to provide proper workflows, we will need to construct a benchmark to properly test and ensure along the way that our new solution works and gives the expected performance improvements. This will be achieved by a normal example with a simple frametime UI.
Implementing this in wasm-bridge is not an issue, since we are already collaborators with the author and have permission to modify the crate and maintain it.

Haha that's a crazy coincidence for sure. The wasm_component_layer crate still is missing a few things, but in my opinion building runtime-agnostic component model is the way to go. Much less work to maintain, long-term.
To answer your questions:

Does wasm_component_layer already support javascript backend
No, not yet. It does support wasmi, which is an interpreter and can run on the web. But if you want performance, then it makes sense to implement a Javascript backend. That should not be problematic.

along with a wasi implementation which works for the web
wasm_component_layer does not innately have support for WASI, but I would hope that converting an existing implementation would not be too difficult.

The one other drawback that I want to highlight is that my crate handles lifting/lowering very differently than wasmtime and wasm-bridge. I do lifting and lowering using enums at runtime rather than compile-time traits. This makes it easier to define types at runtime, but will mean API differences if you port to this crate.

Oh! One other thing, as it says in the docs for my crate, I do not yet have a macro for wit_bindgen. So if you are using that heavily, it will require some additional work to either implement the macro (or remove usage of it from your codebase). Hopefully, this gives you a better idea of the benefits/drawbacks of switching. Let me know if you have any other questions that I can answer :)

Ok, that sounds amazing.
As for the lifting and lowering that I saw at a glance, I think it is doable.
I ran into a corner today when trying to parse and load a component manually without jco inside wasm-bridge, and the code was already much too coupled to jco and doing wasm-wasm directly.
The primary performance bottleneck is as said the javascript object creation, which easily takes 80% of the frames time, the enum approach will incurr some overhead compared to compile time resolution, but it will be far from the overhead of dynamic js objects. If it show to be an issue a hybrid solution can be made in the future.
I'll go ahead and start working on a web backend, and then open up a PR 😊
The structure and "driver-like" traits of your crate seems very good and organized and easy to work with.
@philpax do you want to provide any more input on this?

Nothing to add from me - just very glad to see we have a way forward for this :)

As you all know, this has been quite the journey.
Mithun said in the beginning of this that implementing this would likely require us to implement some sort of WebAssembly compiler and make a subset of wasmtime, and he was correct.
We expected this to be large, as Nuno rightfully put the X-large label on it, and we were correct.
We initially started by implementing and moving away from JCO in wasm-bridge. However, it soon turned out to be too complicated to separate out the js glue and assumptions on JCO that were deeply ingrained in the whole codebase from the very bottom. With the help of Mithun I started to think and replan my approach, as attacking this from any angle was nigh impossible.
Thankfully, through my ever watchful eye of keeping track of the rust ecosystem, I had seen a new crate that abstracted over the component model and layered it on top of the two current WebAssembly runtimes in the passing.
After thinking through my approach, and realizing the immense rewrite that removing and re-implementing a JCO equivalent would bring, along with the inability to do it incrementally or even compile it beforehand I came to the conclusion that writing a WebAssembly runtime within the aforementioned abstraction crate would be a much better approach that will also provide better piping and flow of data. An additional bonus with this approach is that it would also solve our other approach which lies in conditionally using either wasmtime or the web depending on the platform. We previously used cfg guards for this, and a lot of traits and unsafe trying to cram it in to the right type. However, this crate already provides an abstraction layer between wasmtime, and wasmi, so by adding the web as a third backend we get the wasmtime abstraction for free.
There was a lot of code and a lot of different specs to read, learn and implement. As previously alluded, we had to parse the modules ourselves to figure out imports, exports, tables, and signatures, and essentially making a subset of wasmtime. Despite all this, and having to learn the binary spec for WebAssembly modules, and then the component model, it is all in a very working order.
I have managed to get a component level communication between the host and guest.
What this means is that it is now possible to load, parse and compile the core WebAssembly modules from the component module binary, and then instantiate them by linking it together with its sibling modules, and all the external host exports.
We can then invoke any function that the guest module exports and pass arguments and receive return types such as primitive integers and floats, as well as vectors and strings.
Passing a string is one of the most involved parts of the runtime, as the C-ABI that wasm modules operate on only allow for integral and floating point arguments, and a single primitive return value.
To pass a string, or other list type we first need to call another guest export called cabi_realloc, to allocate a block of memory in the host, and get an offset pointer to it returned. We then use this offset to write the string's or list's bytes into the guests memory (which importantly, is a different address space from the host's memory.
The previous solution to this was by using JCO which is a javascript library for loading and interfacing with WebAssembly. The library provides a very idiomatic JavaScript interface for invoking guest functions, such as representing arrays as js arrays [ value ], and structs as objects { key: value }. This is incredibly useful if your application mainly executes on its own inside the wasm module and you need a nice way to invoke it from the website javascript, such as Figma.
To use this from Rust we created bindings to the JCO exports and converted all rust types we wanted to pass to their idiomatic and recursive JavaScript equivalents, such as vectors becoming keyed objects with x, y, z. These JavaScript types were then passed to the library and decoded into the guest module. This process is exceedingly inefficient and creates many temporary heavy javascript objects, as well as requiring thousands of calls over the FFI between Rust and JavaScript to construct the argument object for the guest call. This is only worse for a list or structs, requiring setting every field of the struct (and every field of any struct it contains), for every item of the array. This is a huge amount of back and forths and JavaScript Reflect calls, and will create a large amount of garbage that we have seen be cleaned up in the middle of calls. All this happens even before we are able to call the guest function, and then the same process needs to happen again for the return value.
This is especially bad for strings, as they also need to be encoded into UTF-16, which is worse than linear. To put extra insult to the injury the string in javascript then needs to be converted into a UTF-8 byte array to match the WIT ABI and copied into a newly allocated location of memory in the guest.
This is intended behavior for JCO, and is not a performance bug in the library, but rather the way that we use the library, as it is intended to be used from JavaScript itself where construction is cheaper, and you already have the values at hand in your program state, so all you need to do is give a reference to that value, and no GC needs to happen.
This new solution within wasm_runtime_layer solves all of the aforementioned issues, as we now own the wasm module and its functions, and we can pass lists by copying all of the bytes directly of the list for plain-old-data structs no matter their nesting and the length of the list. The same goes for strings, which are now translated to an allocation in the guests memory, and a subsequent memcpy to the allocated buffer. The string is then passed as the pointer to that guest buffer in the function argument or struct field.
The runtime is very close to completion, and what is in essence missing is some todos and unimplemented areas in the code, which will need to be addressed before it is review and merged. Thankfully, the author has been super helpful and very active which has massively aided the development. There will likely be a good few areas and bugs we discover as we fully integrate this into Ambient, and given that the author is responsive we will open another PR to get those resolved.

authors: DouglasDwyer philpax ten3roberts

repo: AmbientRun/Ambient


text:
new "wekipedia links"

Hi folks,
I have a idea for Physics calculator. the idea is, in description of concept i can add wikipedia links. Please assign this issue to me

@Padmanabh82 like u wanna add the wikipedia links for each calculator?? And what is react type checking?

And what is react type checking?

@Amit366 sir i want to mean react prop types and project is big i thing i cannot do it but i have done wikipedia links

@Padmanabh82 like u wanna add the wikipedia links for each calculator??

ya in physics calculator. i will make a pr now see in it


text:
Hard coded file location in cnv_seeds.py

There is a hard-coded file location for centromeres in cnv_seeds.py, here.
We should remove this line in favor of adding a new argument specifying the path to the centromeres bed.

Hi @mattjones315 can you check if the new code works?

repo: AmpliconSuite/CoRAL


text:
Issue_while downloading_PDF

While I created my Resume after utilizing my time, I get the resulting PDF : RxResume_PDFExport_surajbanerjee100_oracle-product-development-resume-suraj-banerjee_1678256934.pdf

As I tried multiple times now and got the same result and I tried creating another same after coping with multiple items again with the same issues. Please improve the problems.

Same trouble here, when I'm hosting this on my synology.
Can't seem to download or extract any PDF for the moment.
Had several tries with several PDF's I've created but non of them I was able to really print out or to form a PDF of it.
Pls adress the issue, Thanks for the effort anyways !

Initially I wrote the resume content in single page and manage to export in pdf but its not in a proper printable format.
I noticed this would happen when your text are long enough to reach page break mark. Maybe split into several page and keep clear line or two from the page break may address this issue. This is what happen to me and I hope this relates to this issue.

authors: DjShoarma arcalius surajbanerjee

repo: AmruthPillai/Reactive-Resume


text:
update to 2.4.4

aiohappyeyeballs 2.4.4
Destination channel: main
Links

PKG-6548
https://github.com/aio-libs/aiohappyeyeballs/compare/v2.4.3...v2.4.4

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_d8e4xgu29o/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:36: invalid_url: https://aiohappyeyeballs.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
0 Errors and 1 Warning were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_52pi3a0x2p/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:36: invalid_url: https://aiohappyeyeballs.readthedocs.io/ : Not reachable: 403
===== Final Report: =====
0 Errors and 1 Warning were found

authors: anaconda-pkg-build cbouss