Bi-directional infinite query will not fetch previous page if initial prevCursor is null

Describe the bug
Bi-directional infinite query will not fetch previous page if initial prevCursor is null. Sorry but I can't be more descriptive. Please see the codesandbox link provided.
Your minimal, reproducible example
git clone https://github.com/Apestein/apestein-react-infinite-scroller.git
bun install
git checkout tanstack-query-bug
bun run dev
go to app called "demo" localhost:3002
Steps to reproduce
Observe the behavior of the infinite scroll container on the right, which is a bi-directional infinite scroll component. It will work as intended (scroll to 49, then scroll back). Now uncomment line 18 in the actions.ts file. Now inverse scrolling will no longer work (scroll to 49 then try to scroll back).
The intended behavior is for pageParam 0 to be the last page, meaning 0 is the last number that will appear. Maybe I'm not seeing something but I think this is a bug.
Expected behavior
The intended behavior is for pageParam 0 to be the last page, meaning 0 is the last number that will appear. Maybe I'm not seeing something but I think this is a bug.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
OS: ubuntu linux
Browser: chrome
Tanstack Query adapter
None
TanStack Query version
v5.60.2
TypeScript version
v5
Additional context
No response

the sandbox is inaccessible - likely because it’s private or in your drafts. Please make it public

still doesn’t work for me trying to start it up. Stackblitz is so much better these days :/
 *  Executing task: CodeSandbox: dev

yarn run v1.22.19
$ turbo dev

Attention:
Turborepo now collects completely anonymous telemetry regarding usage.
This information is used to shape the Turborepo roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://turbo.build/repo/docs/telemetry

turbo 2.3.1

 WARNING  Issues occurred when constructing package graph. Turbo will function, but some features may not be available:
   × could not resolve workspaces
  ╰─▶ cannot find binary path: bun

• Packages in scope: @repo/eslint-config, @repo/typescript-config, @repo/ui, demo, docs, web
• Running dev in 6 packages
• Remote caching disabled
  × unable to find package manager binary: cannot find binary path
  ╰─▶ cannot find binary path

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

 *  The terminal process failed to launch (exit code: 1).
 *  Terminal will be reused by tasks, press any key to close it.

still doesn’t work for me trying to start it up. Stackblitz is so much better these days :/
 *  Executing task: CodeSandbox: dev

yarn run v1.22.19
$ turbo dev

Attention:
Turborepo now collects completely anonymous telemetry regarding usage.
This information is used to shape the Turborepo roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://turbo.build/repo/docs/telemetry

turbo 2.3.1

 WARNING  Issues occurred when constructing package graph. Turbo will function, but some features may not be available:
   × could not resolve workspaces
  ╰─▶ cannot find binary path: bun

• Packages in scope: @repo/eslint-config, @repo/typescript-config, @repo/ui, demo, docs, web
• Running dev in 6 packages
• Remote caching disabled
  × unable to find package manager binary: cannot find binary path
  ╰─▶ cannot find binary path

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

 *  The terminal process failed to launch (exit code: 1).
 *  Terminal will be reused by tasks, press any key to close it.

Can't it working on codesandbox/stackbiltz. Instead
git clone https://github.com/Apestein/apestein-react-infinite-scroller.git
bun install
git checkout tanstack-query-bug
bun run dev
go to app called "demo" localhost:3002
Observe the behavior of the infinite scroll container on the right, which is a bi-directional infinite scroll component. It will work as intended (scroll to 49, then scroll back). Now uncomment line 18 in the actions.ts file. Now inverse scrolling will no longer work (scroll to 49 then try to scroll back).
The intended behavior is for pageParam 0 to be the last page, meaning 0 is the last number that will appear. Maybe I'm not seeing something but I think this is a bug.

sorry this back and forth is a bit pointless for me. bun install fails with:
bun install v1.0.1 (31aec4eb)
  🔍 @repo/ui [1/1]
error: package "@repo/ui" not found registry.npmjs.org/@repo/ui 404
error: @repo/ui@* failed to resolve

and bun run dev fails with:
bun run dev
$ turbo dev
/bin/bash: turbo: command not found
error: script "dev" exited with code 127

A reproduction for an issue needs to be minimal. Why does it need turbo-repo or packages or anything like that in the first place? Right now, it’s just a waste of my time. I want to see if there is a bug here, but you’re not making it easy for me ...

https://codesandbox.io/p/github/Apestein/tanstack-query-bug-demo/main?import=true

Is this a new reproduction of the issue or is this you showing me that it works now? Because I’ve scrolled up and down tons of times and this sandbox works fine. There is also nothing to comment in or out 🤷.

It's new reproduction. Go to src/app/actions.ts and you will see the comment

when I log:
console.log('hasPreviousPage', hasPreviousPage)

in the BiInfiniteScrollSection component, I get the correct values. But when I go into your into useEffect inside BiInfiniteScroller, hasPreviousPage is false.
That’s because your effect has missing dependencies, so it creates a stale closure. It’s a common pitfall in react, I’ve written about it here: https://tkdodo.eu/blog/hooks-dependencies-and-stale-closures
There’s a reason react has a linter that enforces exhaustive dependencies.

when I log:
console.log('hasPreviousPage', hasPreviousPage)

in the BiInfiniteScrollSection component, I get the correct values. But when I go into your into useEffect inside BiInfiniteScroller, hasPreviousPage is false.
That’s because your effect has missing dependencies, so it creates a stale closure. It’s a common pitfall in react, I’ve written about it here: https://tkdodo.eu/blog/hooks-dependencies-and-stale-closures
There’s a reason react has a linter that enforces exhaustive dependencies.

Ok, so this is actually older working version. And I had already solved the closure problem. And even with the correct dependencies, it was still not working. Only figure it out now, that fixing that resulted in another problem with Intersection Observer that again prevented fetching. Basically, if even one px of the intersecting element was on screen, it wouldn't fetch. Don't want you to think I didn't do my due diligence, just unfortunate series of events. Sorry about that.


drivers: dac: Have a "generic" way to set a channel output to high impedance

Is your enhancement proposal related to a problem? Please describe.
I'm writing a driver of a DAC which support to set its output as High-impedance. Currently there is no way do set it using the dac API
Describe the solution you'd like
I would like to have an entry point to set/unset the high impedance output of a DAC.
This could be done either by adding a dedicated member in dac_channel_cfg or a flag member. the user would then set the output in high impedance by calling dac_channel_setup
Describe alternatives you've considered
An alternate solution would be to define a special value (0xFFFFFFFF) to pass when calling dac_write_value. This will reduce the resolution that can be handled by the dac API (currently 32). This solution would be fine in my case (10bit DAC).
I could implement this solution without any change to the zephyr code, but it would be best that all implementation share the same special value defined in dac.h
If we agree on a solution, I propose myself to do the actual implementation if needed

I'm sorry, I was not aware of this enhancement issue.
Generally I think that setting a pin to high impedance should be done using the Pin Control API from a higher layer (e.g. the application). A pin at high impedance is not a DAC pin anymore.
One would have to be careful with re-configuring pins at runtime, as the DAC driver cannot be re-initialized.
I will close this issue as "not planned" for above reason. @kurddt Please re-open if you disagree.

I think your comment makes sense for integrated DAC on SoC, but might not apply for external DAC. I'm not familiar with the Pin Control API, but I don't think it will adapt well to this. From a quick look the API on the driver side uses pinctrl_soc_pin_t which is SoC specific


Multi-cluster support in loxilb

Based on community discussion, following has been agreed upon as initial multi-cluster support feature :

There will be multiple kube-loxilb instances for different clusters
Each kube-loxilb should be able to allocate unique VIPs from a whole cluster perspective
Currently each kube-loxilb has CIDR declaration in its yaml and allocates VIP independently
But for multi-cluster scheme, CIDR allocation should be moved to loxilb
Also, considering current users are used to CIDR per kube-loxilb yaml , so current behavior should be preserved for backwards compatibility. Probably if no CIDR  is specified, then only use loxilb IPAM. ( But it will be implementation specific how to ensure backward compatibility)

Looking forward to this.


test/params_api_test.c: fix size_t assumptions

size_t isn't always as large as a int64_t, so the compiler complains
about possible data loss.  In this case, we are in control, so a
simple cast will do.

Merged.
f7f2a55aeee12926a7080d75d38f03467eb1ac44 test/params_api_test.c: fix size_t assumptions


Token skips movement animation between waypoints when entering/exiting auras

Seems like token update caused by adding effects from auras results in token skipping its movement animation to the next waypoint.
Example:

Have actor token A with friendly aura.
Move token B (allied with A) by placing a waypoint inside the aura range and the next one - outside.
Token B will skip animation from the inside waypoint to the outside. This works both ways.
But when zig-zagging, not every animation is skipped.

I was able to re-produce it, but the for me it only happened if I had a player token moving diagonally up and down across another player with the bless aura. I will take a look at it; however, at the moment nothing about the movement animation is changed so it's the base animation you get when using the ruler without the module. Was able to re-produce it without any modules installed.

Ah, I didn't check if it was core behavior.
I haven't switched to v12 yet but I don't remember this happening for me with Drag Ruler in v11.


[SPARK-8744][ML][WIP] Add a public constructor to StringIndexer, should be merged only after SPARK-8764

Merged build triggered.

Merged build started.

Test build #36717 has started for   PR 7267 at commit 3fff747.

Test build #36717 has finished for   PR 7267 at commit 3fff747.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class StringIndexerModel (

Merged build finished. Test PASSed.

Now that @jkbradley merged SPARK-8764 , this PR is ready for review as well.

LGTM, merging with master and branch-1.5
Needed for 1.5 since we removed the inverse method in StringIndexer.


scss files are not saved to bundle.css in dev mode

As I see it the .scss files (or just main.scss) are not being compiled while running npm run start:dev
I have to run npm run build to see my changes

@jeverdrengen - thanks for raising the issue. It has now been resolved. Please take a fresh pull.


Add robot.txt file to enable No Follow links

Add this to the web root.
robots.txt

why we are disallowing all bots?

The concern is that page titles may change before the release and cause incorrect ranking. This will be removed prior to the official release of course.

Will close this as we are close to the release and fixing this will not have a major impact on the docs in my view.
@nilminiwso2 @RukshiW @dakshika  please note.


Template review feedback

Thanks for submitting a template to the gallery, there were a few issues in your template that needed to be resolved ahead of approving the template for the gallery.

We are unable to import the template file to test the template. We see "Error importing template" error.

Hi,
Thanks for checking. Apologies, I had made a change to the description that meant the template could not be parsed correctly.  That is fixed. Have manually imported the file to confirm.  Metadata updated to point to the latest update.
Also added a README file

Closing this now as it has been addressed


change scalar mercator types to float64 to give precision on small-level projections.

When using, for example, 8 as level on a ScalarMercator.Project, the resulting (uint64,uint64) (as it lacks the decimal part), generates a huge error when used to revert the operation (lat,lng) via ScalarMercator.Inverse...
This is not an issue with levels as big as 31 (used on projections_test).

Hi, thanks for the contribution.
Changing the existing "ScalarMercator" api could break people's code. But I think adding a "TileCoords" projections that does this would make sense.

Glad you get my point when bringing up this lacking of precision with actual types.
Yes, you are right, this PR will effectively require everyone to make casts in their code.
I'm closing this PR, if I find time to work on a TileCoords projection I'll contribute with a new PR.
Btw, thanks for this lib.. it actually allowed me to make the required projections from GPS LatLng to Google Mercator on scale 256 (because of some zoom calculations needed because of unexpressive maps static api).


[RESOLVED] High ICMP ping response time

Problem started at 08:15:14 on 2023.04.27
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Operational data: Value: 438ms
Original problem ID: 20016
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23132&eventid=20016

Problem has been resolved in 4m 0s at 08:19:14 on 2023.04.27
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Original problem ID: 20016


Evaluation API

This PR adds what I'm calling an "API" for evaluating classifiers and object detectors.
The basic design is that you call one of the following top-level evaluation methods depending on the type of model you have:
import fiftyone as fo

# arbitrary detections
results = fo.evaluate_detections(samples, gt_field, pred_field, ...)

# arbitrary classifiers (single-label, for now)
results = fo.evaluate_classifications(samples, gt_field, pred_field, ...)

# binary classifiers
results = fo.evaluate_binary_classifications(samples, gt_field, pred_field, ...)

Running any evaluation method returns a results object, which is an evaluation-method-specific instance of an EvaluationResults class. The ClassificationResults class was introduced in https://github.com/voxel51/fiftyone/pull/849; this PR introduces DetectionResults.
DetectionResults can currently report confusion matrices and such, but it cannot compute things like mAP, which I would like to see us add in the very near future.
The notion of an EvaluationConfig is also introduced, which enables the user to specify which evaluation method to use and optionally configure any parameters of the evaluation. For example, all of the following are now possible:
# by default, COCO-style evaluation is used
results = fo.evaluate_detections(...)

# specify COCO-style evaluation (using default parameter values) via a string `method` argument
# in the future, more methods will be supported
results = fo.evaluate_detections(..., method="coco")

#
# customize the COCO-style evaluation
#

from fiftyone.utils.eval.coco import COCOEvaluationConfig

config = COCOEvaluationConfig()
config.iou = 0.5
config.classwise = True

results = fo.evaluate_detections(..., config=config)

# customize the COCO-style evaluation using kwargs
# this maintains backwards-compatibility for existing users
results = fo.evaluate_detections(..., iou=0.5, classwise=True)

Now, why am I calling this an "API"? Well, as of this PR, if you run any of these methods with no additional arguments, you will get your results object, but no modifications, new fields, etc will be added to your dataset. If you would like to populate evaluation data on your samples (e.g., TP/FP/FN for detection and binary classification), then you must pass an eval_key argument to the relevant evaluation method. This eval_key is used to generate fields/embedded fields/etc in which per-sample evaluation data is stored. And, the details of the evaluation you ran are stored in your dataset's info field (for now), indexed by the eval_key that you used:
In []: fo.pprint(dataset.info["evaluations"])
BaseDict({
    'eval-det': BaseDict({
        'pred_field': 'predictions',
        'gt_field': 'ground_truth',
        'config': BaseDict({
            'method': 'coco',
            'cls': 'fiftyone.utils.eval.coco.COCOEvaluationConfig',
            'iou': 0.5,
            'classwise': True,
            'iscrowd': 'iscrowd',
        }),
    }),
})

This information is leveraged to provide a few new evaluation utility methods:
fo.list_evaluations(samples)
# Returns a list of all evaluation keys for the given collection

fo.clear_evaluation(samples, eval_key)
# Clears the evaluation results associated with the given evaluation key
# from the collection.

fo.clear_evaluations(samples)
# Clears all evaluation results from the collection.

Running clear_evaluation(..., eval_key) will delete any evaluation results added to your dataset associated with a given eval_key (using dataset.info to figure out what kind of evaluation it was and how to undo it). The utility here is that the user doesn't need to worry about manually cleaning up whatever information may have been added to their dataset.
With respect to detection evaluation, I refactored the existing evaluate_detections() method into a generic shell that will run any evaluation method specified by a DetectionEvaluationConfig, and moved the COCO-specific evaluation logic into a new fiftyone.utils.eval.coco submodule. The abstraction that I introduced here is that an evaluation method is defined by an "image evaluation function" with the following contract:
    def evaluate_image(
        self, sample_or_frame, gt_field, pred_field, eval_key=None
    ):
        """Evaluates the ground truth and predicted objects in an image.

        Args:
            sample_or_frame: a :class:`fiftyone.core.Sample` or
                :class:`fiftyone.core.frames.Frame`
            pred_field: the name of the field containing the predicted
                :class:`fiftyone.core.labels.Detections` instances
            gt_field: the name of the field containing the ground truth
                :class:`fiftyone.core.labels.Detections` instances
            eval_key (None): an evaluation key for this evaluation

        Returns:
            a list of matched ``(gt_label, pred_label, pred_confidence)``
            tuples
        """
        raise NotImplementedError("subclass must implement evaluate_image()")

If an eval_key is passed, then the evaluation method has permission to add eval info to the sample's fields. Otherwise, it cannot. Regardless of that, the results of the evaluation are returned as a list of (gt_label, pred_label, pred_confs) pairs.
COCO-style evaluation fits into this paradigm, and the idea is that most other evaluation techniques will too(?)

Aside: w.r.t. evaluating videos, evaluate_detections() will apply evaluate_image() to all image frames by default. For true trajectory-level video evaluation, I think a separate evaluate_video_detections() method is called for

Open questions

Should certain parameters such as classwise and iou be refactored into the top-level evaluate_detections() method? Or will these be irrelevant to certain evaluation techniques and thus kept as EvaluationConfig parameters?

Other notable changes

I changed the default for COCO-style evaluation to classwise=False, because I think it makes sense to allow detections of different classes to be matched, so that the classification of the detector can be evaluated by default
I made some improvements to clone/rename/clear/deletion of dataset/view sample/frame fields, specifically allowing multiple fields to be modified in a single transaction. I also improved the backend implementation to support modifying nested array fields in most cases

Example end-to-end usage:
import fiftyone as fo
import fiftyone.zoo as foz

DATASET_NAME = "eval-detections-test"
EVAL_KEY = "eval-det"

if fo.dataset_exists(DATASET_NAME):
    dataset = fo.load_dataset(DATASET_NAME)
else:
    dataset = foz.load_zoo_dataset("quickstart").clone(DATASET_NAME)
    dataset.persistent = True

results = fo.evaluate_detections(
    dataset,
    "predictions",
    gt_field="ground_truth",
    eval_key=EVAL_KEY,
)

results.print_report()

# Restrict evaluation to 10 classes, for brevity
classes = dataset.distinct("predictions.detections.label")
classes = classes[:9] + [results.missing]

results.print_report(classes=classes)
results.plot_confusion_matrix(classes=classes)

fo.list_evaluations(dataset)
fo.clear_evaluation(dataset, EVAL_KEY)
fo.list_evaluations(dataset)

#
# Customized detection evaluation
#

from fiftyone.utils.eval.coco import COCOEvaluationConfig

config = COCOEvaluationConfig()
config.iou = 0.5
config.classwise = True

results = fo.evaluate_detections(
    dataset,
    "predictions",
    gt_field="ground_truth",
    eval_key=EVAL_KEY,
    config=config,
)

results.metrics()

fo.pprint(dataset.info["evaluations"])
fo.clear_evaluations(dataset)

First off, this is beautiful! The idea of returning results is what I was struggling with when trying to contain everything in sample-level evaluation fields, this is a great solution to that. Also using dataset.info to store previous evaluation information is really smart.
One change request and two discussion points:

I would definitely request this be accessible from the top level fo.evaluate_... instead of having to import fiftyone.utils.eval unless you have a good reason not to.

yeah I was planning to this, and its now done! The PR description is updated to show that in use.

I'm conflicted when it comes to using configs or just letting parameters like classwise and iou be kwargs at the top-level. I'm leaning towards making them kwargs since that's easiest for a new user to understand without having to learn anything new. Just need to look at the docs for all the existing kwargs and set them to what you want. But when we get to more complex evaluations that have very specific parameters only applicable to one eval type, having kwargs for those parameters could get messy since they're not always applicable. Maybe there's a middleground for things like iou that are used by any detection evaluation to be kwargs but if a parameter isn't useful to more than one model it's specified by the config. Can you give me some sage wisdom about your thoughts on this Brian?

I figured you'd say this, I guess I was subconsciously asking so that you'd give me permission to expose those parameters at the top-level. That change is now in; evaluate_detections() always takes iou and classwise as parameters, which are passed to the actual evaluation method being used (which I suppose would ignore these parameters if they are not relevant to their implementation). There is still the option of passing a config for things like changing the name of the iscrowd COCO attribute, for example. Or they can be passed via **kwargs and that will work too (but the parameters don't need to be documented in the evaluate_detections() method docstring).

I'm worried the current implementation of evaluate_image and then the result aggregation is a bit restrictive.

3a) I'm not totally sure of the specifics, but I think that Open Images evaluation also uses image-level labels, so right there, you would already need to be able to pass in a variable number of gt fields to evaluate_image.

Yeah good point. I updated the interface to take the entire Sample or Frame so that the method can access other stuff if it wants to. I also updated the interface to return the prediction confidences.

3b) Right now, the only aggregations performed seem to be counting tp/fp/fn. Adding mAP right now would be difficult since we also need confidences to compute PR curves. This makes me think that there should also be customizable aggregate_image_results functions similar to evaluate_images that will let us write different ways of doing things like computing mAP (since there are a few ways that could be done) etc.

So I think the cleanest way to handle this is to introduce subclasses of DetectionResults that expose new metrics. Like how BinaryClassificationResults subclasses from ClassificationResults and exposes PR curves and classification AP. I think we can safely introduce this in a separate PR once we get an implementation of mAP in.

@benjaminpkane I believe the windows tests are failing here because I un-skipped a few unit tests that involve cloning stuff (which was modified in this PR). I guess I have to re-skip them to get tests to pass?
I was crossing my fingers that the Windows issue would have resolved itself by now. (is it related to the fact that the cloning code is using new MongoDB version features?) 🤷♂

Yes, until I dig into the service tests/framework.
Ideally, I'd like to leverage a comms library for the service stuff. Any implementations we use will likely never be robust enough.

is it related to the fact that the cloning code is using new MongoDB version features?

No, I'm quite sure this isn't the issue.


Handle uncaught exception

What?
To Handle uncaught exception in wallet
Why?
It may also lead to unnecessary crashes and without right info if the exception is not handled properly
How?
Added common error handler for BLE layer and has sub classes for wallet and verifier for more scalable
Testing?

Disconnection on unsuccessful VC transfer
Disconnection on MTU Size issue

Anything Else?
Issue Link : https://github.com/mosip/inji/issues/583

@shreethaanu
I can see the implementation done in this PR seems to be refactoring the IOS error handling to match with Android implementation. But not actually handling uncaught errors/exceptions.
But the original idea of https://github.com/mosip/inji/issues/583 is to handle uncaught exceptions which may lead to app crash. Error conditions we already handled will not lead to app crash while anything we have not handled can lead to app crash. I wanted to understand what is identified and done in that direction.

I have refactored the Error handling like we did in Android. In iOS, to do that we have to call react-native layer every time a known exception is caught. For unknown exception, we can only add try catch throw in every functionality, which can't be centralised and not recommended as well. We need to do this in React-native layer, which tilak is working on right now, we tested it yesterday using this lib : (react-native-exception-handler). But its not able to catch exception in iOS, that needs to be fixed.


Deferred load with two snapshots

Presently, Parcels stores three snapshots in memory in deferred_load mode. However, @nordam's paper on time interpolation for particle codes made me realise that perhaps we don't need three snapshots in memory, but can do with only two
While this does not increase speed (all snapshots still need to be loaded), it does reduce the memory load of the FieldSet by almost 30%, which in some cases (large 3D global datasets with many Fields from e.g. biogeochemistry), could make a big difference on the total memory load
This PR implements this change to only two snapshots in memory in deferred_load=True mode

Note that this fixes #951

Note that this fixes #951


[Feature Request] Optional Names

Hey,
I thought this would be something cool that would be added is to have the (First & Last Names) be optional and not necessary to have them filled in.
Hope this can be added :)

Bump?

Not going to happen.


Update permissions given during &cj create

This is based off of feedback from last year, to ensure that channels and categories created have the appropriate permissions.
Prevents requiring admins to int e the necessary permissions.

let's get this bread


How to use this frame work to train a LLM with multi-GPUs?

Is the frame work support multi-gpu training?
I want to use the frame work to train a 70B model, however, I did not find the parameter settings or methods for multi-gpus training.

The parallel functionality is currently under development and testing, and is expected to be available by the end of the month.

I also find that the frame work can support llama2-7b and llama2-13b, but it does not support the llama2-70B model

Is this problem caused by inconsistent output dimensions of the qkv layers of the 70b model? （7b and 13b model have the same output dimensions at qkv layers‘ output)
I hope you can teach me how to fix the code to address this problem! thx
And here is the traceback of the error:
`Traceback (most recent call last):
File "/mnt/project/longcontext/multi-lora-fine-tune/mlora.py", line 199, in
mlora.train(mlora.Dispatcher(config, tokenizer), model,

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/train.py", line 69, in train
output, router_outputs = llm_model.forward(input)

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/model_llama.py", line 292, in forward
data = seq_layer.forward(data)

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/model_llama.py", line 223, in forward
output = CheckpointRecomputeFunction.apply(

File "/home/miniconda3/envs/mlora_env/lib/python3.10/site-packages/torch/autograd/function.py", line 506, in apply
return super().apply(*args, **kwargs)  # type: ignore[misc]

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/checkpoint.py", line 99, in forward
outputs = run_function(*args)

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/model_llama.py", line 158, in forward
xv = self.wv_.forward(attention_norm_data, input_args)

File "/mnt/project/longcontext/multi-lora-fine-tune/mlora/lora_liner.py", line 110, in forward
result[start_idx: end_idx] += self.loras_[

RuntimeError: The size of tensor a (1024) must match the size of tensor b (8192) at non-singleton dimension 2`

seem the wrong lora dimension.
can you check the in_dim and out_dim value in the init_lora_weight function(mlora/lora_liner.py:58)
the lora's dimension be inited in this function, maybe you can fix the problem in this function.

in (model_llama.py:301)
I print the layers info in the mlora.model_llama.LlamaModel object
for idx, layer in enumerate(llama_model.model.layers):
            model.layers_[idx].wq_ = Linear(
                layer.self_attn.q_proj, device=device)
            model.layers_[idx].wk_ = Linear(
                layer.self_attn.k_proj, device=device)
            model.layers_[idx].wv_ = Linear(
                layer.self_attn.v_proj, device=device)
            print('==============================')
            print(idx)
            print(layer.self_attn.k_proj)
            print(model.layers_[idx].wk_)
            print('++++++++++++++++++++++++++++++')
            model.layers_[idx].wo_ = Linear(
                layer.self_attn.o_proj, device=device)
            model.layers_[idx].ffn_ = FeedForward(
                norm=RMSNorm(layer.post_attention_layernorm.weight.to(
                    device=device).detach(), model.norm_eps_),
                w1=Linear(layer.mlp.gate_proj, device=device),
                w2=Linear(layer.mlp.down_proj, device=device),
                w3=Linear(layer.mlp.up_proj, device=device),
                device=device
            )
            model.layers_[idx].attention_norm_ = RMSNorm(
                layer.input_layernorm.weight.to(device=device).detach(), model.norm_eps_)
        return model

And I got this result:
Linear4bit(in_features=8192, out_features=8192, bias=False)
Linear(
  (weight_): Linear4bit(in_features=8192, out_features=8192, bias=False)

layer.self_attn.k_proj of each layers is different from the llama2-70b model's config(Linear(in_features=8192, out_features=1024, bias=False))
I think there are bugs in the LlamaModel Class and LLMModelArgs Class.

the raw liners are created from the transformers.LlamaForCausalLM, and we get the in_features and out_features from the Linear.
can you check the llama_model's structure in mlora/model_llama.py:332.

I sove the problem by updating the transformers
I found transformers==4.30.2
It can not load a llama2-70b model
size mismatch for model.layers.79.self_attn.v_proj.weight: copying a param with shape torch.Size([1024, 8192]) from checkpoint, the shape in current model is torch.Size([8192, 8192]).
	You may consider adding `ignore_mismatched_sizes=True` in the model `from_pretrained` method.

I recommend that you upgrade the dependencies of transformers during subsequent updates.

thks,  we will evaluate this.

can we close this?

Hi, thank you for the great work.
Are there any updates for single-machine multi-GPU fine-tuning? In the README.md, I can only find the multi-node settings, how can I fine-tune with multi-GPUs on a single machine?
Thanks a lot.

Hi, thank you for the great work.
Are there any updates for single-machine multi-GPU fine-tuning? In the README.md, I can only find the multi-node settings, how can I fine-tune with multi-GPUs on a single machine?
Thanks a lot.

the pp can run in any setup, like single-machine multi-GPU and multi-machine multi-GPU. just set the MASTER_ADDR=localhost.

Hi, thank you for the great work.
Are there any updates for single-machine multi-GPU fine-tuning? In the README.md, I can only find the multi-node settings, how can I fine-tune with multi-GPUs on a single machine?
Thanks a lot.

the pp can run in any setup, like single-machine multi-GPU and multi-machine multi-GPU. just set the MASTER_ADDR=localhost.

Thanks a lot!


Project owners/cluster members get permissions errors when adding members/groups when PSPs are enabled

It appears that there needs to be a global permission missing when project/cluster owners add users or groups to clusters/projects when PSPs are enabled
error creating binding: Forbidden 403: podsecuritypolicytemplateprojectbindings.management.cattle.io is forbidden: User "u-b4xv6mhhxu" cannot create resource "podsecuritypolicytemplateprojectbindings" in API group "management.cattle.io" in the namespace "c-7ldp6
Steps to reproduce:

enable PSPs on a cluster
create project owner and project member users
add the project owner user as an owner of a project
log in as the project owner and edit the project to add the project member

You'll be faced with that error, but the project member will be added. It doesn't seem to do this when you navigate to the project and use the members page, only when editing the project to add users that way.
This same behavior seems to also happen when cluster members create projects when PSPs are enabled. Not sure if this should be considered a separate issue.
gz#16350
gz#16365

Internal reference: SURE-3015

Reproduced using v2.7.3
Validated using v2.7-head
Steps:

enable PSPs on a cluster
create project owner and project member users
Create a project and set the PSP on the project to 'unrestricted'
add the project owner user as an owner of a project
log in as the project owner and edit the project to add the project member

Validate:


MAINT: Drop support for PySurfer + mayavi?

Now that:

Brain / PyVista / PyVistaQt has begun to mature;
PyVista backend has good notebook support;
mayavi has gone even more unmaintained than usual (I have had a PR open for 3 months that fixes some bugs on latest vtk that hasn't been reviewed yet); and
PySurfer isn't too actively developed anymore

I propose that it's time that we drop support for it, as it lowers our maintenance burden: deprecate for 0.24, and in 0.25 remove the mayavi backend. We can leave the set_3d_backend infrastructure in place for future compatibility in case we want to migrate to a different 3D backend in the (probably distant) future.
I figured I'd ping @GuillaumeFavelier and @agramfort first since you've primarily been guiding the PyVista efforts. If you're on board, I'll ping the rest of the MNE steering committee since I think this is a potentially large enough change to warrant bothering everyone.

yes +1
but I'd like to kill this bird with the new coreg GUI so we're done for
good.

Oh right I forgot that the coreg GUI needed it.
I think there is actually another GUI -- mne kit2fiff. I have never used it, and I don't know how widely used it is...

no idea if mne kit2fiff is actually still used?
maybe @teonbrooks or @christianbrodbeck knows?

I am not aware of a replacement for the kit2fiff GUI, but since it only concerns a small subset of users maybe it could be kept as an special dependency, i.e. install mayavi if you want to use it?

for kit2fiff the conversion can be done programmatically without the GUI and we now have other tools such as dig_montage, its corresponding viz, and coreg to do inspection. It was a useful module to ensure that the markers were placed in the correct locations and that the corresponding files (headshape points, head coil points) were properly processed. I think making note of when it is last supported and point to the tutorial on using dig_montage would be what's needed.

I like this idea. Do you some basic script that would allow to replicate
the GUI feature?

+1000 on dropping Mayavi

I like this idea. Do you some basic script that would allow to replicate the GUI feature?

i can try to tackle this on Friday

sorry, just had a time to come back to this. do we have access to the test data in an example script since this would require loading sqd/con files

https://github.com/mne-tools/mne-python/blob/main/mne/gui/tests/test_kit2fiff_gui.py#L17

@christianbrodbeck okay to remove these and go to scripting? Or are these still used by people / necessary for analyses?

@larsoner I am not aware of scripts that could fully replace the GUI, for example for quickly double checking and fixing the different marker files. But I'm just an occasional user now and could always create a separate conda environment with an older mne version. I don't know how many people still use it in KIT labs.

I can ask around in the labs I know if it will make a difference for this decision? Would you consider not deprecating it?

if it's used we need to propose a way out and not just kill the code. We
could move it to a new repo for example

Is the biggest problem with Mayavi the fact that there is a largely absent maintainer? Are there other technical issues? ... What would help make things better?

I think that's the crux of the problem.
VTK as a big package breaks things from time to time, as happens in any large package (not trying to bad mouth them here). traits and traitsui make changes that break things from time to time, too. And because Mayavi wraps all VTK classes, it is good at exposing any new breaking issues with VTK -- which can be good for VTK and completeness testing (e.g., with finding a bug that they fixed), but bad for downstream packages in that it can for example hang a Mayavi install, or manifest as segfaults, etc. At least this has been my observation working with mayavi.
So IMHO what mayavi needs is more regular/dedicated maintenance and CI testing against released and ideally prerelease/dev versions of VTK for example across all OSes (e.g., at least weekly). I suggested something like this to the VTK people a year ago but nobody really jumped on the idea. Really I think it should be coupled with them doing automated deployment of prerelease/dev wheels, which maybe they could do without too much work since they switched to automated wheel building.
So for us a lighter weight wrapper of VTK (e.g., pyvista) or making VTK calls directly, as we are doing more and more often, has broken stuff in our code less often than mayavi. We only have to fix the things that VTK breaks that we actually use, rather than fixing anything VTK has broken in a given release alongside anything traits/traitsui has broken compatibility-wise.

Do you know anyone who would want to step in and help?

Not that I know of :( I personally try to make PRs when I have time, but I don't have the bandwidth to take on a core maintainer role at least.

@larsoner -- thanks for the response.  I agree with your analysis.  And yes, this is a real problem.  A major problem for me is that this has been the status for 20 years, bulk of the work has fallen on me and it has become harder and harder to find time or motivation.  That said, I still think that it is a useful project.  Another issue for me personally is that I have an almost "Debian stable" mentality and never update my Python environments for fear of breaking stuff so tend to live in my own cocoon -- that is the only way I can get my work done at all.  What I am going to do going forward is to put in a little time each week on Mayavi maintenance and the first goal is to work with some folks at Enthought to ensure that the CI is working and notifies us of issues.  I will take care of the core issues that I seem to be the only one comfortable with and others will help with setting up CI and other things that they are more comfortable managing.  Hopefully together this should be better.   Anyway, am hoping to do a better job. Thank you @larsoner for all your help these last few years and your patience.


Validator needs to reconstruct its state from historical blockchain data

As part of the improvement in #457 we also need to add the ability to reconstruct the validator state (or make it persistent with some sort of database) when it boots up as the validator needs to validate also requests that were started before the validator booted up. Currently it only starts validating new requests.

Validator Historical Data
At the moment the validator has started, there may already be existing active storage requests containing slots with slot ids that should be monitored by the validator: these are slot ids that either belong to the group observed by the validator or basically any slot id if validator is to monitor the whole slot id space.
In this context we want the validator to find and monitor all those slots id associated with storage requests that started earlier and have not yet concluded.
max duration of a storage request
Currently it does not look like the duration of the storage request is limited. In this case we need to pull the history events from some pre-configured date (it does not make sense to pull the history from ancient times when Codex did not exist).
getting historical data
To get the history data we can use a function similar to the one already defined on OnChainMarket:
method queryPastEvents*[T: MarketplaceEvent](
  market: OnChainMarket,
  _: type T,
  blocksAgo: int): Future[seq[T]] {.async.} =

  convertEthersError:
    let contract = market.contract
    let provider = contract.provider

    let head = await provider.getBlockNumber()
    let fromBlock = BlockTag.init(head - blocksAgo.abs.u256)

    return await contract.queryFilter(T,
                                      fromBlock,
                                      BlockTag.latest)

It looks like queryPastEvents is not used anywhere in the code base.

We can add a new function taking a fromDate argument that will take care of computing the fromBlock needed for the underlying queryFilter procedure.
To compute the block number at the fromDate we can first estimate the block number at the fromDate (taking either 12-15s as the average block time - we can also base this estimate on the current network conditions by looking at the timestamps of the last two blocks) and then fine tune using binary search (this is should give us the minimum number of calls).

I did not spot any existing functionality that already implements this. If you know that it is somewhere there, let me know...

Filtering events
I would start with the following procedure (let's call it findActiveSlots):

Retrieve all the SlotFilled events fromDate and store the corresponding SlotIds.
Exclude those SlotIds that do not match the validation config.
From the remaining SlotIds, further remove those that are no longer in SlotState.Filled using  validation.market.slotState(slotId).
What's left are the SlotIds that are still in the SlotFilled state and thus need to be checked for proofs.
Pre-populate validation.slots with the remaining slots.

findActiveSlots should be called at the beginning of Validation.run before the while true: loop.
I am doing some small spike (as I like to experience some of the libraries in isolation, here nim-ethers), and if this is kind of right what I am saying, I would aim to have it ready for review in about 2 days. The corresponding PR is coming soon.

It looks like queryPastEvents is not used anywhere in the code base.

Apart from in the tests, the usage of this has been removed from the codebase as it was no longer needed. However, I knew we'd be using this function again so it was left in :) Usage is like so:
let reqs = await market.queryPastEvents(StorageRequested, 5)

(taking either 12-15s as the average block time - we can also base this estimate on the current network conditions by looking at the timestamps of the last two blocks)

We will be launching mainnet on our own Linea L2, I believe? The mainnet block times seem to be around 2s for now:

I like your idea of monitoring the block times, however my opinion is that for now, we find out what the average will be for the L2 we deploy on, and use that as a "hardcoded" average time. With that time, you can find the approximate block number (head - 30 days in seconds / 2 secs per block), get the block at that block number, and inspect the block timestamp. If the timestamp is < 30 days ago, keep getting a previous block until the a block timestamp of >= 30 days before now is found.
For now, we are targeting 30 days as the maximum request duration, which is likely to be gradually increased in the future.

From the remaining SlotIds, further remove those that are no longer in SlotState.Filled using validation.market.slotState(slotId).

The validator does this already in removeSlotsThatHaveEnded, so no need to double-up imo. However, this has been my main concern from the start: that we may end up waiting some time to get responses back for all these slotState requests. Maybe there's a way to optimise these calls, eg batching? We discussed already the option for persisting the events in the RepoStore, but have opted to avoid that extra work for now, and possibly revisit it later on if needed.

We will be launching mainnet on our own Linea L2, I believe? The mainnet block times seem to be around 2s for now:

Indeed that is pretty much certain. I still keep thinking of Ethereum for some reason.

I like your idea of monitoring the block times, however my opinion is that for now, we find out what the average will be for the L2 we deploy on, and use that as a "hardcoded" average time. With that time, you can find the approximate block number (head - 30 days in seconds / 2 secs per block), get the block at that block number, and inspect the block timestamp. If the timestamp is < 30 days ago, keep getting a previous block until the a block timestamp of >= 30 days before now is found.

30 days - seems good to me.
Initially thought that your suggestion to perform flat search would be simpler than doing binary search, but after thinking a bit I am not that convinced anymore. The average block time on Linea (https://lineascan.build/chart/blocktime) seems to be quite stable at the moment (fluctuations are below 5% on daily average). Yet, how much can we depend on it I do not know. For 30 days, assuming 2s between blocks, we are talking about  2592000 / 2 = 1296000 blocks. Let's just notice that if - because of fluctuations or some other reason - we get 10% of an average variation then this would mean 1296000 * 0.1 = 129600 blocks to travel. Even at 5% this is still potentially lots of block to query and we will immediately need to do some sort of optimisation. Binary search that I proposed is a standard way to deal with this problem, and it would reduce the number of searches quite a bit (being O(logN)) we only need 20 comparisons for 1000000 items). The implementation is also pretty standard and super easy (and I already have implemented a version of queryPastEvents that is already using binary search (played with it yesterday evening before you responded). Would it be reasonable that we just start with it?

However, this has been my main concern from the start: that we may end up waiting some time to get responses back for all these slotState requests. Maybe there's a way to optimise these calls, eg batching?

Yes, if the number of observed slots grows to a large number, we would indeed start to feel it. Batching may indeed help, maybe there is somewhere else. Not sure if we should immediately worry about? If that would be up to me only, I would probably start simple without any optimisation. Feels to me a serious thing, but maybe it can wait till get some first users?

We discussed already the option for persisting the events in the RepoStore, but have opted to avoid that extra work for now, and possibly revisit it later on if needed.

In my opinion this a logical consequence of reconstructing the state. But I also agree (plus the same reasons as stated in the previous point), that it can wait a bit. I think this should happen before being tempted to do any batching or similar optimisation. With persistence in place, we should be able to respond to high demand even after periods of inactivity.
We just need to pay attention that we do things asynchronously: we need to make sure we subscribe to the new events before requesting the log. Otherwise, if there is something blocking and taking more time than the time between two blocks, we may miss some events - but that's really extreme I think, I just to keep it in mind.

The validator does this already in removeSlotsThatHaveEnded, so no need to double-up imo.

I think it should be enough. Just remember that this last stage of filtering of the log will happen not earlier than at the end of the current period (because of await validation.waitUntilNextPeriod()). It may be beneficial to use that time to already deal with the historical log. Just a thought...

linea, binary search

From what I understand, we will have our own side chain, so my guess is block times will be mostly stable and we'll know when it is expected to change. Of course, that is a guess :)
The binary search sounds like a good idea. How will you know how far back (in blocks) to go on the first search?

Batching. Feels to me a serious thing, but maybe it can wait till get some first users?

I don't feel like batching would be a lot of effort, but yeah maybe it's best to get this working first without optimisations. However, I'd also like to hear what others' opinions are. My thoughts are that the request latency is the biggest issue. Even if validators run their own execution client, at 50ms total for a round trip (a single slotState RPC request/response), that's 50 seconds for every 1000 filled slots, and can add up quickly. If we can reduce that by a factor of 10 (as an example batch size), then it seems much more easy to work with.
The batch could be a simple view in the contract that returns the state of 10 slots in one call. The validator would get all SlotFilled events, then for every 10, make a slotStateBatched request.

remember that this last stage of filtering of the log will happen not earlier than at the end of the current period

Good point. Maybe it would be better to do it beforehand then. removeSlotsThatHaveEnded could also use batching to speed up ;)

The binary search sounds like a good idea. How will you know how far back (in blocks) to go on the first search?

I am still doing initial estimate based on the average time between blocks and then I am adjusting low and high accordingly. Binary search quickly goes to the middle point anyway, so those optimisations seem to have very little impact on the number of steps (mostly no impact at all, sometimes it can save maybe one jump, so looks like we do not have to worry about it - perhaps it will be overly cheaper not to do any premature optimisations).
I am doing something like this to initialise low and high:
var low = 0
var high = latestBlockNumber
if estimatedBlockTimestamp < epochTimeUInt256:
  low = estimatedBlockNumber
else:
  high = estimatedBlockNumber

I don't feel like batching would be a lot of effort, but yeah maybe it's best to get this working first without optimisations. However, I'd also like to hear what others' opinions are. My thoughts are that the request latency is the biggest issue.

I feel the same. When saying that it is serious thing I mean that we do need to have it in mind. So yes, I agree we need to have that on the horizon. I would probably first go for state preservation and then this, but I am open to a different order as well (at least lets keep both things as separate issues/PRs, so that things are easier to get merged).

The batch could be a simple view in the contract that returns the state of 10 slots in one call. The validator would get all SlotFilled events, then for every 10, make a slotStateBatched request.

I was tempted to let the validator to ask for all slots it wants in one batch, but that indeed could grow to big. So yes, this sounds like something to try (although the max number in one batch can probably be bigger).

Here is a small chain independent demo that I used to play with search without depending on the blockchains before porting it to our code: https://play.nim-lang.org/#pasty=ECupqAtx

Initially I planned to use the average block time to predict the number of blocks we need to look back in order to find the block number corresponding to the given epoch time.
This estimation can be highly inaccurate if block time has changed in the past or is fluctuating and therefore we used that information initially only to find out if the available history is long enough to perform effective search.
It turns out we do not have to do that. There is an easier way.
First we check if the given epoch time equals the timestamp of either the earliest or the latest block. If it does, we just return the block number of that block.
Otherwise, if the earliest available block is not the genesis block,  we should check the timestamp of that earliest block and if it is greater than the epoch time, we should issue a warning and return that earliest block number.
In all other cases, thus when the earliest block is not the genesis block but its timestamp is not greater than the requested epoch time, or if the earliest available block is the genesis block,
(which means we have the whole history available), we should proceed with the binary search.
Additional benefit of this method is that we do not have to rely on the average block time, which not only makes the whole thing more reliable, but also easier to test.
Basically, the whole check has been simplified to the following:
# Are lucky today?
  if earliestBlockTimestamp == epochTime:
    return earliestBlockNumber
  if latestBlockTimestamp == epochTime:
    return latestBlockNumber

  if earliestBlockNumber > 0 and earliestBlockTimestamp > epochTime:
    warn "Short block history detected.", earliestBlockTimestamp =
      earliestBlockTimestamp
    return earliestBlockNumber


nasm: 2.14.01 -> 2.14.02

https://nasm.us/doc/nasmdocc.html
Motivation for this change
Fixes crash building pkgsi686Linux.lame.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build pkgsi686Linux.lame


PowerToys not running at startup

Microsoft PowerToys version
0.73.0
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
Every time I switch on my machine or perform a restart. PowerToys does not run at startup. at all. I have tried everything but I still cannot get it to run at startup and I have to keep manually opening the programme.
Yes, the option to run at startup is on. I am running as admin. I have checked my startup programmes and PowerToys is there, enabled. I have also tried toggling the run at startup option on/off and restarting. But it still will not run!
Please help. Its a small issue but rather annoying as i use various features of PowerToys on demand.
Thanks
Ash
✔ Expected Behavior
PowerToys should be running at startup
❌ Actual Behavior
PowerToys is not running at startup
Other Software
No response

PowerToys in in startup programs? It's not supposed to be there. PowerToys is supposed to be running from a scheduled task on long. Can you please check your scheduled tasks to check if it's there?

/needinfo

Hi Jamie,
Thanks for this - i just checked my task scheduler and PowerToys was there, but disabled? No idea why, but I have re-enabled it, so hopefully It should run at startup from now on.
When you say it shouldn't be in startup programmes, should i turn it off? or remove it?
[cid:c6751254-0539-469b-a586-2b49b7f7ce33]
[cid:1f926c83-dfc5-4532-ac41-12b73e06e706]
Thanks
Ash

From: Jaime Bernardo @.>
Sent: 04 September 2023 10:37
To: microsoft/PowerToys @.>
Cc: AshBearPig @.>; Author @.>
Subject: Re: [microsoft/PowerToys] PowerToys not running at startup (Issue #28290)
PowerToys in in startup programs? It's not supposed to be there. PowerToys is supposed to be running from a scheduled task on long. Can you please check your scheduled tasks to check if it's there?
[image]https://user-images.githubusercontent.com/26118718/265419390-ac41ba06-793e-45e3-bbe1-a3d18758e6ac.png
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/28290#issuecomment-1704941788, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BBVPAVIYHATVQDJ65TVHQODXYWOPNANCNFSM6AAAAAA4H7VGHE.
You are receiving this because you authored the thread.Message ID: @.***>

For me, the autostart entry is deleted after updating and I need to manually disable and enable autostart in the powertoys settings to make it work again for each user (I have a "normal" and an admin user).

So after enabling it within task scheduler, I start-up my computer today and its still not running at startup. Opened up the scheduler and its been disabled again?
No idea what's going on

From: binarynoise @.>
Sent: 07 September 2023 15:56
To: microsoft/PowerToys @.>
Cc: AshBearPig @.>; Author @.>
Subject: Re: [microsoft/PowerToys] PowerToys not running at startup (Issue #28290)
For me, the autostart entry is deleted after updating and I need to manually disable and enable autostart in the powertoys settings to make it work again for each user (I have a "normal" and an admin user).
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/28290#issuecomment-1710303240, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BBVPAVMWSA3O6MGVVJHAE7DXZHODVANCNFSM6AAAAAA4H7VGHE.
You are receiving this because you authored the thread.Message ID: @.***>

Are you still experiencing this issue? /needinfo


Proposal: New project to write Vault namespace key plugin

Discussion starter
(Quick recording of my random thoughts before a full proposal occurs)
Short job (1-2 days)
Vault will become the central controller of SF keys. (Only controller not sole database.) The current SF code base is untouched (except to add the ability to stop key creation). Validation is still completed by SF using the current code.
This new project will enable all other tools to request a key from Vault. Vault issues the key and writes it to SF. SF keys become controlled from a central audited server.
Avoids hard coding keys in systems. Enables key rotation.
Vault should be run from a minimum 3 server cluster. In the event of a total cluster failure (!):

SF will continue to validate requests using it's internal DB
SF clients continue to operate using already retrieved keys
New clients will fail to start since their start up requires retrieval of their key from Vault

I think sounds like a pretty good idea, although probably for v0.3?


AWSConfigs.EndpointDefinition null reference exception

Context
I'm trying to alter the endpoint definitions so i can run my app locally using localstack. I followed the documentation here (https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-other.html#config-setting-awsendpointdefinition). But i'm getting a null reference exception.
Expected Behavior
Set AWSConfigs.EndpointDefinition to the json file as provided here: https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Core/endpoints.json
It should load up the endpoint definitions
Current Behavior
Get a null reference exception with the following stack trace:
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
    at Amazon.Internal.RegionEndpointProviderV2.RegionEndpoint.ReadEndpointFile(Stream stream)
    at Amazon.Internal.RegionEndpointProviderV2.RegionEndpoint.LoadEndpointDefinitionFromFilePath(String path)
    at Amazon.Internal.RegionEndpointProviderV2.RegionEndpoint.LoadEndpointDefinitions(String endpointsPath)
    at Amazon.Internal.RegionEndpointProviderV2.RegionEndpoint.LoadEndpointDefinitions()
    at Amazon.Internal.RegionEndpointProviderV2.RegionEndpoint.GetBySystemName(String systemName)
    at Amazon.Internal.RegionEndpointProviderV2.GetRegionEndpoint(String regionName)
    at Amazon.RegionEndpoint.get_InternedRegionEndpoint()
    at Amazon.RegionEndpoint.GetEndpointForService(String serviceName, Boolean dualStack)
    at Amazon.Runtime.ClientConfig.GetUrl(RegionEndpoint regionEndpoint, String regionEndpointServiceName, Boolean useHttp, Boolean useDualStack)
    at Amazon.Runtime.ClientConfig.DetermineServiceURL()
    at Amazon.Runtime.Internal.DefaultRetryPolicy..ctor(IClientConfig config)
    at Amazon.Runtime.AmazonServiceClient.BuildRuntimePipeline()
    at Amazon.Runtime.AmazonServiceClient..ctor(AWSCredentials credentials, ClientConfig config)
    at Amazon.S3.AmazonS3Client..ctor(RegionEndpoint region)

Possible Solution
I had a look through the code that is in the call stack. It appears that if EndpointDefintion is specified then it assumes the file is v2 and uses RegionEndpointProviderV2. As seen here:
https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Core/RegionEndpoint/RegionEndpoint.cs#L218
Looking at RegionEndpointProviderV2 and RegionEndpointProviderV3 it appears as though the example file that is provided in the documentation is in V3 format, as it has a providers object at the root and not an endpoints one?
Steps to Reproduce (for bugs)
    class Program
    {
        static void Main(string[] args)
        {
            AWSConfigs.EndpointDefinition = "endpoints.json";
            var s3Client = new AmazonS3Client(RegionEndpoint.APSoutheast2);
        }
    }

With the referenced example file copied into the output directory.

Hi @mgkeen, can you please try using the ServiceURL property?  I think this should help you to use localstack.

@klaytaybai just to clarify, is that the ServiceURL on the AmazonS3Config? Thanks for pointing me towards it. That should unblock me, but it isn't ideal.
I didn't want to have to change my production code (in this case introduce configuration) purely to serve the purpose of running locally. The EndpointsDefinition was ideal because it meant no code change in my production context.


not working since betterdiscord update

plugin is not working since the new betterdiscord update

Duplicate of https://github.com/Yentis/betterdiscord-emotereplacer/issues/57


Provider app data set should include default business statuses

Repro: go to https://provider.medplum.com/Patient//Task/ and try to update Business status.

Ah, I missed that there is an accompanying ValueSet when copying in the Task actions from the task demo app. I'll add this ValueSet with a different URL, name, etc. into the Provider App Resources linked project along with its accompanying CodeSystem.

This has been fixed


Destructing operator hits parameter limit

With param limit set to 3:
let getResturants = ({page, pageSize, domain, metroId} = {}) => {
^ This function has too many parameters. (4)

@duereg what is the expected behavior and what is actually happening?

So a destructing operator is operating on a single parameter. So these code blocks are equivalent:
var foo = function(args) {
  var a = args.a;
  var b = args.b;
  var c = args.c;
}

let foo = ({a, b, c}) => {
  //a,b,c are all available to this function, just like in the call above
}

I would expect this destructing operator would count as 1 param.
It appears the current behavior is that every field destructed from the given object is counted as a param, instead of the whole object being counted as a param.
In the examples above, jshint says the 1st example has 1 param, but the 2nd example has 3 params.
Does that make sense?

@duereg yup I definitely get the question. I'm looking through the spec to try to figure out what the correct behavior is. Conceptually it makes sense to me that since each param is usable on its own (ie not as a member of an object) that it should be counted for parameter length. With that said, I haven't found documentation to back up that feeling yet, so still looking.

@duereg

It appears the current behavior is that every field destructed from the given object is counted as a param, instead of the whole object being counted as a param.

This is definitely a bug.
@mbildner

since each param is usable on its own (ie not as a member of an object) that it should be counted for parameter length

This function defines only one formal parameter and expects only one argument: an object that will be destructured according to the object binding pattern defined in the single formal parameter:
let foo = ({a, b, c}) => {
  //a,b,c are all available to this function, just like in the call above
};
foo.length === 1; // true

This function defines two formal parameters and expects two arguments: the first is an object that will be destructured according to the object binding pattern defined in the first formal parameter; the second is a non-specific that will be assigned to the simple formal parameter binding identifier:
let foo = ({a, b, c}, another) => {
  //a,b,c are all available to this function, just like in the call above
};
foo.length === 2; // true

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-expectedargumentcount
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-function-definitions-static-semantics-expectedargumentcount

@rwaldron aha thanks for the info and for the references! I'll start looking into a fix :)


89 Grid to DiGraph Conversion and Graph Simplification.

Changes

grid to digraph conversion
data structures for simplified graph (decision point graph/overlay graph)

Related issues
First steps for #89
Resolves #19
Documentation see also flatland-association/flatland-book#6
Checklist

[x] Tests are included for relevant behavior changes.
[x] Documentation is added in the docs folder for relevant behavior changes. If you made important user-facing
changes, describe them under the [Unreleased] tag in CHANGELOG.md.
[x] New package dependencies are declared in the pyproject.toml file.
Requirement files have been updated by running tox -e requirements.
[x] Code works with all supported Python versions (3.10, 3.11 and 3.12).
[x] Code is formatted according to PEP 8 (an IDE like PyCharm can do this for you).
[x] Technical guidelines listed in CONTRIBUTING.md are followed.

Just wonder - what does the left flatland-graph show? Is there the "big loop e.g. top left to middle center" not missing? Micro looks very good. But the left one i don't understand from visualisation.

I haven't read all the documentation here but I think we need to be explicit that, in this formulation, at any given time, an agent "occupies" an edge (not a node).  The step() call results in the agent transitioning from one edge to another edge.  A node with two out-edges is therefore a decision node (vs a single out-edge); an agent on the "predecessor" edge needs to decide which "successor" edge to take as it crosses the decision node.  (The two successor edges are both "in" the same cell)
It's then not so obvious which row and column a node is on, because it is on the boundary between two cells.  A cell has a unique (row, column). An edge is "in" a single cell (row, column).  Either the row or column of a node seems ambiguous (a node is on either a horizontal or vertical boundary so only one is ambiguous.  We have no diagonal transition between cells.)
Since we define (r,c,d) with d is direction of entry, this resolves the ambiguity. However it means that the twin points on the same boundary are split across the adjacent cells, eg:

The two nodes on East/West rails between cells (3,4) and (3,5).  The "East" node is (3,5,East) and the West node is (3,4,West), because we enter 3,5 going East and we enter 3,4 going West.
if (3,4) is a switch, say going North to (2,4) and West to (3,3), then we have edges
-- (3,4,West) -> (3,3,West)
-- (3,4,West) -> (2,4,North)

Ideally this should be represented in the diagram, ie the nodes should be slightly offset from the cell boundaries.

@hagrid67 The implementation of this pr only reflects the topology, there are no agents (yet) "living" on this graph, no step() working with this graph yet. This is future/ongoing work not part of this pr. But you're right that agents will live on the edges.
There are only "entry nodes", no "exit nodes", there are no "twin points". The grey dots in Figure 5 do not actually exist, but are proxy for the entry node in the neighboring cell, nodes just separating two edges and reflecting the possible transitions.
The implementation is pretty straightforward: for all transitions in the transition map, add an edge to the graph:
https://github.com/flatland-association/flatland-rl/blob/e33821b471527e914055adf815a90fff342fe824/flatland/core/graph/grid_to_graph.py#L83-L92
See also https://github.com/flatland-association/flatland-book/blob/68e6aafe6a5297398b57e419c7a9b025ac0ff918/environment/graph_demo.ipynb


Update documentation for PlatformException.stacktrace

This adds documentation for platforms other than Android, in particular that no platform other than Android supports the passing of stacktraces to Dart.
Closes https://github.com/flutter/flutter/issues/97698
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Nope, this is not a breaking change.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

(triage) @gaaclarke Could you take a look at this?


Expand playground examples

We started with https://polymerlabs.github.io/lit-samples/. There are more to add.

Currently there are no playground examples showing how to use styles with Lit.
Would be nice to show:

classMap and styleMap.
Sharing static css styles between two components.
custom properties
parts


Org user quota improvements

Closes #6404

Invalid input error message set, avoiding user to submit form.
Fixed submit action.

CR @xavijam

Tests are passing now, please review it @xavijam

[ ] Editing the user quota, if you focus on text input and press ENT button, "delete user dialog" appears.
[ ] Creating a new user, quota slider should be enabled, setting the default quota for a new user and maximum the rest of organization quota.

retest

please retest

retest this please

retest this please

retest this please

:sparkles:


chore: bdd-spring-1574080265 to 0.0.1

chore: Promote bdd-spring-1574080265 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


autolinking to methods on partial interfaces doesn't seem to work right

I was trying to fix some linking errors.  I had:
houdini-specs/css-properties-values-api $ bikeshed spec
LINK ERROR: Multiple possible 'interface' refs for 'CSS'.
Arbitrarily chose the one in cssom-1.
If this is wrong, insert one of the following lines into a
 block:
spec:css-conditional-3; type:interface; text:CSS
spec:cssom-1; type:interface; text:CSS
LINK ERROR: Multiple possible 'method' refs for 'supports()'.
Arbitrarily chose the one in css-conditional-3.
If this is wrong, insert one of the following lines into a
 block:
spec:css-conditional-3; type:method; text:supports(property, value)
spec:css-conditional-3; type:method; text:supports(conditionText)
WARNING: This specification has neither a 'Security Considerations' nor a 'Privacy Considerations' section. Please consider adding both.
 ✔  Successfully generated, with 2 linking errors

Then I changed css-conditional to define partial interface CSS instead of interface CSS, and ran bikeshed update.
This fixed the error that there were multiple interface refs for CSS, as I intended.  However, it changed the error on the supports() method to indicate that there are now 0 possible link targets instead of 2 as there were before:
houdini-specs/css-properties-values-api $ bikeshed spec
LINK ERROR: No 'method' refs found for 'supports()' with for='CSS'.
WARNING: This specification has neither a 'Security Considerations' nor a 'Privacy Considerations' section. Please consider adding both.
 ✔  Successfully generated, with 1 linking errors

This makes it appear that methods being defined on a partial interface aren't being linked properly.  (And also makes it harder to fix that error until this bug is fixed.)

It magically went away with another bikeshed update.  I guess the bikeshed update somehow picked up data with the old links removed but not the new ones added?
Now I get the expected
houdini-drafts/css-properties-values-api $ bikeshed spec
LINK ERROR: Multiple possible 'method' refs for 'supports()'.
Arbitrarily chose the one in css-conditional-3.
If this is wrong, insert one of the following lines into a
 block:
spec:css-conditional-3; type:method; text:supports(property, value)
spec:css-conditional-3; type:method; text:supports(conditionText)
WARNING: This specification has neither a 'Security Considerations' nor a 'Privacy Considerations' section. Please consider adding both.
 ✔  Successfully generated, with 1 linking errors


UnknownTypeBuffer does not feel rusty

I'm new to rust, but UnknownTypeOutputBuffer/UnknownTypeInputBuffer in the event loop API does not feel rusty at all.
I think it could be implemented differently, for example using traits with bound types.
After playing around a bit, I was able to pin point my discomfort to the following problem: enum types are used for encoding type information, which breaks a lot of flexibility that rust provides. As I've seen in the cpal implementation itself, macros are used to build the UnknownTypeBuffer result types, which tells me something's definitely wrong.
I'd like to discuss possible ways of improving this API.
Disclaimer: I'm still learning though, so my suggestions may be horribly bad.
So, why enum types, when we could use traits with bound types?

Here's a particularly problematic example of the API usage:
fn add_to_vec(buf: cpal::UnknownTypeInputBuffer, vec: &mut Vec<f32>) {
    match buf {
        cpal::UnknownTypeInputBuffer::U16(buffer) => {
            for sample in buffer.iter() {
                let sample = cpal::Sample::to_f32(sample);
                vec.push(sample);
            }
        }
        cpal::UnknownTypeInputBuffer::I16(buffer) => {
            for sample in buffer.iter() {
                let sample = cpal::Sample::to_f32(sample);
                vec.push(sample);
            }
        }
        cpal::UnknownTypeInputBuffer::F32(buffer) => {
            for sample in buffer.iter() {
                let sample = cpal::Sample::to_f32(sample);
                vec.push(sample);
            }
        }
    }
}

The problem is, I don't know really know how I want this code to look like. Initially I was thinking that instead of having a implementation with concrete types I'd want to implement some trait three times.
That said, it seems I can implement a layer of indirection atop of the whole event loop API to add the logic to apply stricter types. But with that, I'm a bit worried that being built on top of this enum-based thing the API won't be zero-cost.
Please note though - here I apply very similar actions for all buffers, but I don't assume that the API should imply that; on the contrary - I'd like to implement separate behavior for every "case". What is case here? I'd say handling a particular stream is it's own case, i.e. a case per StreamId. If we were to implement an API around that it could be possible to negotiate the format and the proper handler for that format input/output buffer upfront, upon the creation a stream. Then, assuming the EventLoop.run invokes the callback for a particular stream only with it's negotiated format, it'd be safe and much easier to work with the formats at the user level.
Actually, after all this deduction, I'm even more certain that this API is not designed for direct consumer use, and is very low-level on it's own. But, again, the problem is it still adds it's own abstractions which aren't zero-cost (enum types for example). In that sense, the API is somewhere in-between the low-level and zero-cost thing, and the higher level nice-to-use. cpal's mission statement tells that it wants to be as low-level as possible - so maybe we should try go even further in that direction?

One more thing. I think it's a very bad idea for the cpal to do the sample format conversion under the hood. This, if needed, has to be a concern of a higher level entity. We're already good in that area, but that's important to me.

I think this is covered in #119


update on packages

debian needs firefox-esr and not firefox only

well you are absolutely correct. Problem is debian has 2 version of firefox so when used on other branch, script will fail. When I was building my script for debian, Ive got some ideas from yours actually 😁. You can close this PR for now and Ill see if I can add some variables to check which branch.
ps, thanks. My fedora hyprland also can be use for minimal fedora


Fix/gitignore rules

Description
fix: old gitignore rules were deleted from new repo
Related issues

#3

Type of change

[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] This change requires a documentation update

merge dev to main is in progress


lwIP: LOCK_TCPIP_CORE before calling non-thread-safe netif APIs

It makes sense, but where did you find in the documentation that a lock is required?  How do we know if we're missing other locking?

@nwagner It's in their docs:
https://www.nongnu.org/lwip/2_0_x/raw_api.html
      As such, the list of functions that may be called from
      other threads or an ISR is very limited! Only functions
      from these API header files are thread-safe:
      - api.h
      - netbuf.h
      - netdb.h
      - netifapi.h
      - pppapi.h
      - sockets.h
      - sys.h

Dan found this while updating lwIP on the gateway

Great!  I'm a little disappointed they didn't document this on a per-module or per-function basis.


Add game of Reconnaisance Blind Chess.

Based on rules outlined at https://rbc.jhuapl.edu/gameRules and to be used for the HIG competition.

Awesome @michalsustr, thanks!

Is there an update on the importing?

Is there an update on the importing?

I hope we can can get to it this week.

Thanks @jhtschultz! @michalsustr: I've already started the import, so I can apply John's suggestions on our side (no need to update the PR).

@lanctot The UndoAction() was a very good point, I didn't update this part of the code. Please wait with the import, I will push fix soon.

See my last message-- I've imported already and did a few changes that I don't want to redo. Don't worry about Undo for now, if it fails you can submit a follow-up PR.

you can submit a follow-up PR

Ok, sounds good. Thank you Marc!

Imported! Will merge tomorrow morning. Thanks again @michalsustr !


Private Groups - Hide Content

The activity on private groups on the website are not publicly visible. On the app they are.
The discussions on private groups on the website are not publicly visible, on the app they are.
Should have a check before getting any closed information.

New group navigation checks for access, so private groups will only show the basic info + member list. Everything else is blocked.


geekbench: Add/fix support for Geekbench5

The non corporate version of geekbench5 didn't work although the code
had everything needed, except for a number of tiny required tweaks:

Add '5' in the supported versions in init.py
Fix the name of the android package in__init__.py and
UiAutomation.java
Improve handling of minorVersion to fix potential exception when we
don't specify the minorVersion number in the yaml file. Launching
geekbench5 works fine when it's the only one installed. But if you
have multiple versions, then using the version string in the yaml
agenda didn't like specifying '5' as the version and threw exception
out of bound because we assume '5.X' as input. No reason I'm aware of
to force support for a specific version of geekbench5. So keep it
relaxed until we know for sure it breaks with a specific version.

Signed-off-by: Qais Yousef<EMAIL_ADDRESS>

Tested to work on my devices with a small fix in devlib. Raised a PR to fix the issue: https://github.com/ARM-software/devlib/pull/582

Thanks for the testing!


feat: update jupyter tensorflow cuda rock for 1.8

Update the jupyter-tensorflow-cuda-full rock for 1.8, based on the upstream image
Summary of changes

change the branch to v1.8-branch
bump the rock version to 1.8
pin pyjuju to <4.0 in the unit test requirements due to migration to juju 3 in 1.8
update kubectl to 1.25

Testing
tox -e unit
unit installed: anyio==4.0.0,asttokens==2.4.0,attrs==23.1.0,backcall==0.2.0,bcrypt==4.0.1,cachetools==5.3.1,certifi==2023.7.22,cffi==1.15.1,charmed-kubeflow-chisme==0.2.0,charset-normalizer==3.2.0,cryptography==41.0.4,decorator==5.1.1,deepdiff==6.2.1,exceptiongroup==1.1.3,executing==1.2.0,google-auth==2.23.0,h11==0.14.0,httpcore==0.18.0,httpx==0.25.0,hvac==1.2.1,idna==3.4,importlib-resources==6.0.1,iniconfig==2.0.0,ipdb==0.13.13,ipython==8.12.2,jedi==0.19.0,Jinja2==3.1.2,jsonschema==4.17.3,juju==3.2.2,kubernetes==28.1.0,lightkube==0.14.0,lightkube-models==<IP_ADDRESS>,macaroonbakery==1.3.1,MarkupSafe==2.1.3,matplotlib-inline==0.1.6,mypy-extensions==1.0.0,oauthlib==3.2.2,ops==2.6.0,ordered-set==4.1.0,packaging==23.1,paramiko==2.12.0,parso==0.8.3,pexpect==4.8.0,pickleshare==0.7.5,pkgutil-resolve-name==1.3.10,pluggy==1.3.0,prompt-toolkit==3.0.39,protobuf==3.20.3,ptyprocess==0.7.0,pure-eval==0.2.2,pyasn1==0.5.0,pyasn1-modules==0.3.0,pycparser==2.21,Pygments==2.16.1,pyhcl==0.4.5,pymacaroons==0.13.0,PyNaCl==1.5.0,pyRFC3339==1.1,pyrsistent==0.19.3,pytest==7.4.2,pytest-asyncio==0.21.1,pytest-operator==0.29.0,python-dateutil==2.8.2,pytz==2023.3.post1,PyYAML==6.0.1,requests==2.31.0,requests-oauthlib==1.3.1,rsa==4.9,ruamel.yaml==0.17.32,ruamel.yaml.clib==0.2.7,serialized-data-interface==0.7.0,six==1.16.0,sniffio==1.3.0,stack-data==0.6.2,tenacity==8.2.3,tomli==2.0.1,toposort==1.10,traitlets==5.10.0,typing-extensions==4.8.0,typing-inspect==0.9.0,urllib3==1.26.16,wcwidth==0.2.6,websocket-client==1.6.3,websockets==8.1,zipp==3.17.0
unit run-test-pre: PYTHONHASHSEED='1657534265'
unit run-test: commands[0] | rockcraft pack
WARNING: test command found but not installed in testenv
  cmd: /snap/bin/rockcraft
  env: /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/.tox/unit
Maybe you forgot to specify a dependency? See also the whitelist_externals envconfig setting.

DEPRECATION WARNING: this will be an error in tox 4 and above!
Retrieved base ubuntu:20.04 for amd64
Extracted ubuntu:20.04
Executed: pull conda-jupyter
Executed: pull generate-locale
Executed: pull kubectl
Executed: pull nodejs
Executed: pull non-root-user
Executed: pull overlay-pkgs
Executed: pull pebble
Executed: pull security-team-requirement
Executed: overlay conda-jupyter
Executed: overlay generate-locale
Executed: overlay kubectl
Executed: overlay nodejs
Executed: overlay non-root-user
Executed: overlay overlay-pkgs
Executed: overlay pebble
Executed: overlay security-team-requirement
Executed: build conda-jupyter
Executed: build generate-locale
Executed: build kubectl
Executed: build nodejs
Executed: skip pull conda-jupyter (already ran)
Executed: skip overlay conda-jupyter (already ran)
Executed: skip build conda-jupyter (already ran)
Executed: stage conda-jupyter (required to build 'non-root-user')
Executed: build non-root-user
Executed: build overlay-pkgs
Executed: build pebble
Executed: build security-team-requirement
Executed: skip stage conda-jupyter (already ran)
Executed: stage generate-locale
Executed: stage kubectl
Executed: stage nodejs
Executed: stage non-root-user
Executed: stage overlay-pkgs
Executed: stage pebble
Executed: stage security-team-requirement
Executed: prime conda-jupyter
Executed: prime generate-locale
Executed: prime kubectl
Executed: prime nodejs
Executed: prime non-root-user
Executed: prime overlay-pkgs
Executed: prime pebble
Executed: prime security-team-requirement
Executed parts lifecycle
Exported to OCI archive 'jupyter-tensorflow-cude-full_v1.8.0_20.04_1_amd64.rock'
unit run-test: commands[1] | bash -c 'NAME=$(yq eval .name rockcraft.yaml) &&  VERSION=$(yq eval .version rockcraft.yaml) &&  ARCH=$(yq eval -r ".platforms | keys" rockcraft.yaml | cut -d" " -f2) &&  ROCK="${NAME}_${VERSION}_${ARCH}" &&  sudo /snap/rockcraft/current/bin/skopeo --insecure-policy copy oci-archive:$ROCK.rock docker-daemon:$ROCK:$VERSION && docker save $ROCK > $ROCK.tar'
WARNING: test command found but not installed in testenv
  cmd: /usr/bin/bash
  env: /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/.tox/unit
Maybe you forgot to specify a dependency? See also the whitelist_externals envconfig setting.

DEPRECATION WARNING: this will be an error in tox 4 and above!
Getting image source signatures
Copying blob edaedc954fb5 done
Copying blob adfbb81f1512 done
Copying blob d9c306b19569 done
Copying blob 81a655aa3207 done
Copying blob d07cc0564d97 done
Copying config b7b83a0eac done
Writing manifest to image destination
Storing signatures
unit run-test: commands[2] | pytest -v --tb native --show-capture=all --log-cli-level=INFO /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/tests
=================================================================================== test session starts ===================================================================================
platform linux -- Python 3.8.10, pytest-7.4.2, pluggy-1.3.0 -- /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/.tox/unit/bin/python
cachedir: .tox/unit/.pytest_cache
rootdir: /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full
plugins: anyio-4.0.0, asyncio-0.21.1, operator-0.29.0
asyncio: mode=strict
collected 1 item

tests/test_rock.py::test_rock
------------------------------------------------------------------------------------- live log setup --------------------------------------------------------------------------------------
INFO     pytest_operator.plugin:plugin.py:647 Adding model microk8s-localhost:test-rock-ek3t on cloud microk8s
PASSED                                                                                [100%]
------------------------------------------------------------------------------------ live log teardown ------------------------------------------------------------------------------------
INFO     pytest_operator.plugin:plugin.py:783 Model status:

Model           Controller          Cloud/Region        Version  SLA          Timestamp
test-rock-ek3t  microk8s-localhost  microk8s/localhost  3.1.5    unsupported  15:17:43Z

INFO     pytest_operator.plugin:plugin.py:789 Juju error logs:

INFO     pytest_operator.plugin:plugin.py:877 Resetting model test-rock-ek3t...
INFO     pytest_operator.plugin:plugin.py:882 Not waiting on reset to complete.
INFO     pytest_operator.plugin:plugin.py:855 Forgetting main...

=================================================================================== 1 passed in 28.55s ====================================================================================
unit run-test: commands[3] | python /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/tests/test_imports.py
Running command in jupyter-tensorflow-cude-full_v1.8.0_20.04_1_amd64:v1.8.0_20.04_1
2023-09-20T15:17:54.625Z [pebble] Started daemon.
2023-09-20T15:17:54.641Z [pebble] POST /v1/exec 15.699896ms 202
2023-09-20T15:17:54.653Z [pebble] GET /v1/tasks/1/websocket/control 10.505927ms 200
2023-09-20T15:17:54.653Z [pebble] GET /v1/tasks/1/websocket/stdio 88.106µs 200
2023-09-20T15:17:54.654Z [pebble] GET /v1/tasks/1/websocket/stderr 72.641µs 200
2023-09-20T15:17:54.672Z [pebble] POST /v1/exec 7.388258ms 202
2023-09-20T15:17:54.679Z [pebble] GET /v1/tasks/2/websocket/control 6.359588ms 200
2023-09-20T15:17:54.680Z [pebble] GET /v1/tasks/2/websocket/stdio 154.941µs 200
2023-09-20T15:17:54.681Z [pebble] GET /v1/tasks/2/websocket/stderr 109.585µs 200
2023-09-20 15:17:56.528488: W tensorflow/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libcudart.so.11.0'; dlerror: libcudart.so.11.0: cannot open shared object file: No such file or directory
2023-09-20 15:17:56.528533: I tensorflow/stream_executor/cuda/cudart_stub.cc:29] Ignore above cudart dlerror if you do not have a GPU set up on your machine.
[I 230920 15:18:12 font_manager:1443] generated new fontManager
2023-09-20T15:18:15.469Z [pebble] GET /v1/changes/2/wait 20.787890084s 200
2023-09-20T15:18:15.485Z [pebble] GET /v1/changes/1/wait 20.831186238s 200
unit run-test: commands[4] | python /home/ubuntu/kubeflow-rocks/jupyter-tensorflow-cuda-full/tests/test_access.py
Running jupyter-tensorflow-cude-full_v1.8.0_20.04_1_amd64:v1.8.0_20.04_1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3914  100  3914    0     0   136k      0 --:--:-- --:--:-- --:--:--  136k
87a6e6e767ec
87a6e6e767ec
_________________________________________________________________________________________ summary _________________________________________________________________________________________
  unit: commands succeeded
  congratulations :)

@NohaIhab We will need to comment out kfp in imports test as we did here.
I created an issue to track it the fix for it (upgrade?).


Fix #124 & Possible fix #130

Fix #124 by making button invisible rather than gone, done the same for issue #132. Fix #130 by checking before calling endFakeDrag().

Thank you very much!


Formatting not working properly

Hello!
First I would like to thank you for your amazing work on this extension, it's really saving me a lot of time when working on some Jsonnet!
However I noticed two bugs I think: when using the latest version (0.1.10) and the previous one (0.1.8), the "implicit plus" feature does not work at all, I tried multiple combination of "disabling/enabling/reloading/restarting VScode" and it never worked, enabled or disable it doesn't touch any exiting + or remove unnecessary ones.
I also noticed that since 0.1.10 the "String style" option where no more applied properly and it always replace simple quotes by double quotes, even when it is explicitly set to simple quotes.
Here is my configuration VSCode version/config:
Version: 1.77.3
Commit: 704ed70d4fd1c6bd6342c436f1ede30d1cff4710
Date: 2023-04-12T09:41:48.638Z (2 wks ago)
Electron: 19.1.11
Chromium: 102.0.5005.196
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 22.4.0
Sandboxed: No
In my settings.json I only have:
"jsonnet.lsp.fmt.stringStyle": "'",
"jsonnet.lsp.fmt.implicitPlus": true

And I'm using Golang Jsonnet v0.19.1.
Would you have any idea why it doesn't work as expected?
Thank you for your help!

Definitely seeing the same thing related to it not respecting the stringStyle setting.


proxyUrl argument is not an valid url

Proxy does not get set when doing: "http://" + ip + ":" + port;
isnt a valid url after that. If im typing the outcome in 1 string, it works.

Probably sth is wrong with ip and port variables.

It isn't. I removed the exception it works without problems.


added rand and srand using xorshift method

@moussacodes We already have a DEBUG.md ???
It's in the docs directory

fixed the issues


Document feature differences between object formats

Add documentation explaining features that don't work in either of the three object formats. For example, SingleCellExperiment objects don't support subsetting based on feature expression, or differential gene expresssion, and it is not high priority to add these capabilities before release.
We should also say that AUC values won't be shown for Seurat v5 or anndata objects.

@wish1832 will generate table, @agillen will summarize for documentation


How to draw prevision vs recall curve for pascal_voc format( Faster R-CNN model)?

https://github.com/open-mmlab/mmdetection/blob/7a9bc498d5cc972171ec4f7332afcd70bb50e60e/tools/analysis_tools/coco_error_analysis.py#L43
This I believe is for coco format, but I couldn't find any files for plotting precision or precision vs recall chart for pascal voc format.

Seems not implemented yet, but you can convert VOC to coco format and use coco_error_analysis

How to convert VOC to coco format?

https://github.com/yukkyo/voc2coco
I used the above code to convert it. You can try the same

Thank you!


Support for Koa?

Hi,
Any plans to support the koa web framework?

No plans right now to specifically implement Koa however I'm planning on abstracting the the internals so it's easy to add support for other web frameworks (e.g. Hapi)
Out of interest, beyond generators are there many differences with express?

The biggest change was to replace callbacks with generators. They also combined the res and req objects into a single context (the this object). There are others, but thats really the big obvious differences. I modified your source to make it work with Koa. All I did was turn it into a generator, replace res and req with the koa contex, replace the express.render function with React.renderToStaticMarkup and added support for document title and 404 error. It works well enough for me to continue with my project.

I would add a big +1.
I can open a repo.
@bishtawi would you like to share some code. I was about to work on it but if you already done this start it would be nice.

Yeah, thats a good idea. I'll throw up the code I have up onto a repo later tonight. I didnt bother fixing the tests yet.

Alright, marty-koa is available here.
Let me know if you have any problems.

Wow. Nice work indeed.
I would test it soon and open up issues if I have any problems.


uninstall target in makefile

Hi.
Please add uninstall target in makefile.

How about you send a PR?
Also an uninstall is a rare thing to be supported


Case Reason Picklist Values Still Not in Org (Some Are, but inconsistent)

I see Red Cross Message in the CaseReason standard value set. But it does not show in the org.

Actually, I now see that there are several items that didn't show in the org in addition to Red Cross Message.

From Hub post, should use add_standard_value_set_entries to deploy to org.  Will update once sample can be found.

With success of add_standard_value_set_entries in the install plan and move of standardvalueset folders to unpackaged config, marking this as closed.


Severe Bugs

Dont know if this affects your system but found some bug that can affect clients using CODIAD if the login details are compromised.

please send security related issues to our email<EMAIL_ADDRESS>

Done. Please check the email.


[step] :: enhance active step UI

Before

After

Codecov Report

Merging #160 into master will decrease coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #160      +/-   ##
==========================================
- Coverage   86.14%   86.08%   -0.07%
==========================================
  Files          28       28
  Lines         628      625       -3
  Branches       72       72
==========================================
- Hits          541      538       -3
  Misses         75       75
  Partials       12       12

Impacted Files
Coverage Δ

src/components/Pipeline.vue
94.44% <ø> (ø)
:arrow_up:

src/components/Step.vue
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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