Configurable aspect ratio for the camera image

Description
Hi, first of all, thanks for the absolutely amazing addon that you provided here. It replaced a bunchof manual work I needed to do to enable using my Valetudo Vacuum with the lovelace-xiaomi-vacuum-map-card!
I have the card set up on my dashboard together with a few buttons and stats cards to display things like RSSI, consumables, etc. Unfortunately, on one of my wallmounted tablets, this causes the resulting card to exceed the available vertical screen space. I have since used card-mod to tweak the aspect ratio of the map image, but I'd prefer to be able to use the configuration of this integration to set an aspect ratio for the camera image (e.g. 2:1) or explicit width and height (e.g. 400x200).
Thank you for considering this feature request.
Florian
Solution
Integration allows to set aspect ratio of the camera image, resulting image provided to home assistant is padded to achieve desired aspect ratio
Alternatives
Integration allows to set explicit width and height of the camera image
Context
No response

@FHeilmann it is indeed an interesting the idea.. but please let's make a point here too.

On earlier versions of the camera there was crop and trim to resize the image as desired.
On the newer versions, as I guess you have seen, we use I kind of auto trimming (that of course also crops the images).
Reducing the aspect ratio of the image would also improve drastically the performances of the camera.. anyhow as you wrote from the card of Piotr (well I'm in contact with him and actually I did work out some changes on the card as well to grab the topic of the vacuums directly from the camera).. is possible actually to setup as you did the image at a specific aspect ratio.
If we do this kind of modification.. it will be difficult to calculate the calibration_points. Now I do confess that it is a good proposal. But please understand in this moment will be a little difficult to put it in place.. this do not mean that is impossible.

As soon I can study an how to.. but please understand right now I do have to address other basic function first, I would come back on it.. anyhow if you are willing to contribute.. you can always fork the project and of course you will found my full cooperation if you would start or have in mind how to design such function... for the time be I would propose we keep this as an open discussion if you agree ;)  when you agree I will move it to the discussions.

Thank you for your timely and thorough response.
I'm fine with however way you want to approach the issue. Given that I "solved the issue" by modifying piotr's card it might make sense to make this change in the card instead. I might reach out to him about that.
I'm fine with moving this to discussions. Also please don't feel rushed in any way.
Bests,
Florian

Thank you for your timely and thorough response.
I'm fine with however way you want to approach the issue. Given that I "solved the issue" by modifying piotr's card it might make sense to make this change in the card instead. I might reach out to him about that.
I'm fine with moving this to discussions. Also please don't feel rushed in any way.
Bests,
Florian

Florian, I will work on the card too, and discuss about it with Piotr (that is at the moment quite busy). Anyhow I will keep this open as per the idea you had is quite interesting to me, this would solve an issue that other users have using the VM's instead of real hardware... mmmmm we will see, but please I will need a little time as above explained for it ;)

@FHeilmann
Dear Florian,
Wishing you all the best and a serine xMas time, I just had an idea that I would like to share with you. At current the camera is detecting the edges of the image as explained above. I'm thinking to make so that as soon the rooms are detected the image trimming will be update with the rooms layout data. This should remove the lidar imperfections and reduce already the images sizes a lot.
We do use to draw the map also pixel_size that could be used to "re-scale" the image, actually changing the pixel size of the rendered image result in a smaller image too (from some test I did).
The standard pixel_sizes are 5 or 7 according to the default values Valetudo that I've collected but of course this do not matter, I mean we receive it with the image data from the Vacuum, and we can use a scale variable that default would be the standard pixel_value to scale factor.
This should allow to implement the function you request on the camera without to compromise the calibration_points, I mean I think make possible to change the image ratio and implement it by the images option.
I will start to work on this direction for the required modifications.. and open a PR for this as per once I make stable the 1.5.x this can be implemented as a major change (if it will work).
Once Again thanks a lot for the Valuable advise here, all the best,
Sandro

Dear @sca075, thank you and all the best to you and yours as well. I just realized we had a bit of a misunderstanding.
I'm not talking about scaling the image, im talking about changing the aspect ratio, padding one dimension so that the image becomes wider or taller as a result. Let me show you what I mean with a screenshot from my current setup (modded with card mod)

As you can see the camera image does not occupy the entire width of the card (and therefore the image is less tall and fits on the screen without scrolling. This would've been easier if I could change the aspect ratio of the image (from the rectangular 1:1 to, e.g. 2:1 in my case)
Hope this clarifies my issue.
All the best.
Florian

got it but let me clarify the pixel_size is actually the image aspect ratio.. it means the image will reduce in size too.. anyhow the card is going to make it full size, therefore zooming out two times and locking the aspect ratio will result on the same as per your example, I will work on it the next year ;)


Expose recomputeLayouts via imperative handle on DndContext

Hi Claudéric,
First off I'd like to thank you for the amazing work on this library. It's an absolutely massive improvement over anything else out there and it's been a joy to use.
As for my question: I'm working on a sortable list that needs to dynamically move margin based on the position of the dragged item. Kind of like the margin between items storybook example but instead of the margin staying in the same position it shifts along with the dragged item. Is something like that possible? I found that DndContext contains a recomputeLayouts method, but I haven't found a way of accessing that from my implementation.
Thanks in advance for your time!

Hey @aartrost, if the code where you need to recompute layouts is wrapped within a <DndContext> provider in the tree, then as you mentioned, you can use the useDndContext() hook to call the recomputeLayouts method.
Assuming you need to do this from the outside (for example, in the component that renders the <DndContext> component, right now you would not be able to, but it should be a fairly straightforward PR to expose this via an imperative handle exposed through the ref of <DndContext> (see https://reactjs.org/docs/hooks-reference.html#useimperativehandle)

Hi @clauderic!
Thank you for the hint, I was using the recomputeLayouts method outside the <DndContext> provider. Moving it inside fixed the issue for me. Your quick reply is much appreciated!
I'll leave this issue open as being able to call this from outside the provider tree would likely be helpful for others.

Closing this issue as I no longer have plans to expose this outside of DndContext


pluck watch:lint task

ref #193 after jshint removal in 76da98b
#104 is likely out of date now

Thanks @pll33


add a filter_by_meta()  function

This PR implements a function to join a generic pd.DataFrame (indexed on ['model', 'scenario']) with specific metadata columns from an IamDataFrame and apply filters on each column.
This is useful in the following workflow:

retrieve a pd.DataFrame from an IamDataFrame using timeseries()
do some computation on the df
add relevant metadata like categories from the original IamDataFrame
continue working on the df, eg using groupby()on the categories

This is sort-of possible with as_pandas() and filter(), but quite cumbersome, because as_pandas() returns value-columns (years)  and metadata columns (Step 1 above). So one would have to make some bypass for step 2 to just operate on the year-columns. I found the workflow described above more flexible and also easier to read (because less bypassing required).
The use of col=None for only joining a column without filter is modelled on slice(None) of pd.MultiIndex

Ok, conceptually I get it now. Do we want to join the metadata though? Or perhaps that should be optional?

Ok, I think I see where the implementation is going. It might be simpler to

subset metadata for values in kwargs first
extract the model/scenario index from the subset dataframe
return data subset with subset index

Instead of joining the dataframes first, then doing the subset (also more computationally expensive)

And can you please also add to release notes! =)

Re whether joining is optional: I would make it the default (because in my use cases, I usually want to filter and do something else), but we can make it optional to not have it joined (just perform the filter). What would be a good kwarg-name, join_meta?

note to myself: if no index is given, check if model and scenario columns exist and create index from that

let's talk about this briefly when we meet tomorrow morning.

sticklered, rebased, release-noted, error-messaged, and a more efficient workflow (first filter, then join optionally)
and it now also accepts ['model', 'scenario'] as columns instead of index and returns the df in the same way as it was inputted (and yes, there is a test for that, too)
@gidden, good to go once the tests pass

thanks @danielhuppmann!!


Unbound 1.17.1 prefetch warning Dietpi Bookworm

Hello unbound team.
Is this normal behaviour with Dietpi and unbound 1.17.1 ?
https://dietpi.com/forum/t/unbound-error-prefetch/17696/13

You have the answer right here:
https://dietpi.com/forum/t/unbound-error-prefetch/17696/3

Indeed these are just warnings that certain features (in this case serve-expired and prefetch) do not work together with the subnetcache module; they do work for main cache content.
If the features are not needed you can disable them in the configuration. If the subnetcache module is not needed, it can also be disabled in the configuration.
To add to the linked thread, subnetcache is enabled by default if compiled in Unbound. To remove it you need to explicitly define a module configuration like:
server:
    module-config: "validator iterator"


Uglify Upgrade

This is an initial stab but needs more work.
Now I'm looking through the code I realise the options merging/transformations should really be happening in processOutputOpts but there is quite a bit of legacy stuff in there without tests so I'll need to be careful not to break anything.
It should support the existing config options:
builder.bundle('myModule.js', 'outfile.js', { minify: true, mangle: false, uglify: uglifyOps  });

Or you can pass the entire uglify-es valid config in yourself through options.uglifyes:
var uglifyOpt = {
    compress: {
        global_defs: { DEBUG: false },
        dead_code: true,
    },
    mangle: false,
    warnings: false
}
builder.bundle('myModule.js', 'outfile.js', { minify: true, uglifyes: uglifyOpt });

@timfish see also the approach in https://github.com/systemjs/builder/pull/818. I wonder how far a 3.x upgrade gets us here?

The v3/master readme says:
- uglify-js@3 has a simplified API and CLI that is not backwards compatible with uglify-js@2.
- uglify-js only supports ECMAScript 5 (ES5).
- Those wishing to minify ES2015+ (ES6+) should use the npm package uglify-es.

I can't see any obvious features that you'd get updating to v3/master. The api changes to v3 are not backwards compatible so I doubt you can just upgrade the package like that.

Ok thanks for checking this. We should definitely stick with this upgrade path then.

I want to using babel-plugin-syntax-dynamic-import in bundler task, but i have an error in this case. have anybody an idea?
for more details you  can see > https://travis-ci.org/behzad888/builder/builds/253923865

@behzad888 it looks like you're running an older version of SystemJS builder, try upgrading to the latest.

@guybedford i'm using latest version of SystemJS builder but new version of uglify-js need to define transpiler SystemJS.config({ transpiler: 'transpiler-module' }). Although in my local project its ok but travis ci builder has an error as Unable to dynamically transpile ES module.
How to set transpiler on SystemJS builder test cases?

Seems like uglify-es is no longer supported.

See ‘terser’, it’s replacement fork.
On Sun, 30 Sep 2018 at 17:38, Tim Fish<EMAIL_ADDRESS>wrote:

Seems like uglify-es is no longer supported.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/systemjs/builder/pull/815#issuecomment-425729594, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAkiyjPQYCGX-0ZMNKMP0tjmvQO9rjYdks5ugOV4gaJpZM4OID5O
.


Update examples on github to use installation page

@tzerrell Not sure whether we want to reopen https://github.com/risc0/website/pull/286 or call this a separate issue

So I'm looking at how to #include(install.md) or something like that and there's no native support for this. However, we could use something like m4 preprocessor or pandoc for this

I think just having a link is fine for examples.

@tzerrell Not sure whether we want to reopen risc0/website#286 or call this a separate issue

Since risc0/website#286 is a PR and has already been merged I think we do need this as a separate issue


log noise when running any command after training lib integration

i'm getting this any time i run any command (post training merge)
[2024-06-25 20:02:11,013] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to mps (auto detect)
W0625 20:02:11.591000<PHONE_NUMBER> torch/distributed/elastic/multiprocessing/redirects.py:27] NOTE: Redirects are currently not supported in Windows or MacOs.

This also comes up when using ilab tab completion, so something like ilab <tab> also causes these messages to print. I assume that means this is happening at import time.
I also noticed that startup takes significantly longer than before - presumably because of what's now happening at import time that didn't before.

In the e2e CI job, I see a much longer blob emitted every time ilab is run:
[2024-06-26 18:32:02,395] [INFO] [real_accelerator.py:203:get_accelerator] Setting ds_accelerator to cuda (auto detect)
 [WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
 [WARNING]  async_io: please install the libaio-dev package with apt
 [WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
 [WARNING]  Please specify the CUTLASS repo directory as environment variable $CUTLASS_PATH
 [WARNING]  NVIDIA Inference is only supported on Ampere and newer architectures
 [WARNING]  sparse_attn requires a torch version >= 1.5 and < 2.0 but detected 2.3
 [WARNING]  using untested triton version (2.3.1), only 1.0.0 is known to be compatible

@JamesKunstle you mentioned on slack that you were looking at this. should it be assigned to you?

Most occurrences of the ugly log noise will go away with these PRs:

https://github.com/instructlab/instructlab/pull/1532
https://github.com/instructlab/training/pull/116

For the remaining occurrences, it is going to be tricky to fix. The log messages are coming from DeepSpeed. The logging code in DeepSpeed goes really hard to circumvent common best practices around logging. It sets up its own logger with a hard-coded configuration and stream handler.
https://github.com/microsoft/DeepSpeed/blob/aecfec7f510eb2a40f7afa50efe370f885e4d258/deepspeed/utils/logging.py#L20-L50
There is no easy way to monkey-patch the issue at runtime, because import deepspeed already emits log lines to stdout. Some like this might do the trick:
import contextlib
import os
import logging

with open(os.devnull, "w") as f:
    with contextlib.redirect_stdout(f):
        from deepspeed.utils.logging import logger as ds_logger

ds_logger.setLevel(logging.NOTSET)
ds_logger.propagate = True
for hdlr in ds_logger.handlers[:]:
    ds_logger.removeHandler(hdlr)

Can anyone test whether or not this is an issue still now that https://github.com/instructlab/instructlab/pull/1532
https://github.com/instructlab/training/pull/116 are merged?

I no longer see the log noise, but I have not checked all commands. It might still show up for ilab model train.

Closing for now, we can reopen if it's still an issue


return a list of values for query parameters with the same key

There is no way to get the whole list of values when you have query like key1=a&key1=b&key1=c.
The only cumbersome way to retrieve all the values is to use a snippet of the like
for (auto it = params.find(key); it != params.end(); it = params.find(it, key))
{
  myVector.push_back(*it);
}

Which is cumbersome.
It would be nice to have an API that make possible to return all values associated with a key in a list/container
std::vector<string_view> url::get_all(string_view key);

I understand there are allocation problems, but I'm sure there is an acceptable solution with some trade off (provide an allocator, or templated/conformant container) to make the library easier and more accessible to use (sometimes, you need it to work).

This would be a nice example

If we do this in the library it would be something like
subrange params_encoded_view::find_all( string_view key );

It would be nice to have an API that make possible to return all values associated with a key in a list/container

I don't think the library should provide this explicitly. Instead, with the proposed find_all above, you could use std::back_insert_iterator (C++11) or one of the new fancy range algorithms to fill in the container of your choosing, even supporting custom allocators.

boost.http.proto supports this:
https://github.com/CPPAlliance/http_proto/blob/dc92ac4e05ad8b1b4b60ec8924b2f0cfa1167598/include/boost/http_proto/fields_view.hpp#L243

Cons:

It would be like emulating map::equal_range to a container where equal keys are not in order. We also have unordered_map::equal_range but the equal keys are also in sequence in these containers.
To emulate something that's not there, we would need a view that would be a lot like ranges::views::filter and pretend this is native. This would need a reasonable API, etc... which could involve a lot of work to get right.
There are many possible designs for the API, like a std::back_insert_iterator. Each design would serve only a subset of users.
Doing that implicitly might indicate to the user this happens in constant time, like some kind of weird vector::push_front would.
This is useful for avoiding a for-loop. But seems like a lot of work for just avoiding a for-loop. Users would need to understand the design.

Pros:
On the other hand, params::find does the same thing, assuming linear time is justifiable for URLs. Since params::find_all would also be linear time, it's not something completely without a precedent.
However, params::find has a much simpler interface, since we just return one iterator that already exists, so the precedent is not completely there.


Return { "success": true } for /transactions/{safe_address}/propose

Overview
The transaction creation request has a weird empty response with a 200 code. It would be nice to always reply with JSON to any (successful) request to the API.
Requirements
/transactions/{safe_address}/propose should return { "success": true } in case of success (HTTP code 200).
Please also check if any other POST-requests return an empty response.

Could you outline why a response is required? If we follow REST we should return the created object (a multisig transaction in this case), wouldn't that make more sense)?

It would be just nice to have a consistent response type across the endpoints. In the linked SDK PR we had to introduce and if checking if the response is supposed to be parsed as JSON.
Returning the created object would be even better, sure. We could then link directly to a transaction details screen (which we don't have yet but there's a ticket for it).

https://stackoverflow.com/a/28951049/7820085

The core services endpoints technically don't return anything for either confirmations and proposal. We could mimic the behaviour of the post_confirmation endpoint of the gw, where after posting to the core services we invalidate our redis and fetch the tx_details. IMO, If this is not urgent, I would implement this once we've addressed some caching issues in the core services.

@jpalvarezl where can I test this?


feat: Spring boot extension native support

Adding native support for Spring Boot

Released in v4.1.3 -> https://github.com/project-openubl/xsender/releases/tag/v4.1.3


remove redundant path.join in Places365

Fixes #3501

So, that search engines can index it, this PR solves the following error message:
RuntimeError: The file mydata\categories_places365.txt does not exist or is corrupted. You can set download=True to download it.


Draft how-to for getting nodes and edges tables from network

This is aimed at technical users (jupyter users of the python API and/or me developing UI code).
Looking for review from @makkus that the content is technically correct, and from an end user @CBurge95 that it's clear enough (have I provided enough context for example), and addresses her original questions from #20

Ok, I've written a small jupyter notebook that contains a version where the nodes table is picked via a kiara operation as to not break lineage (attached to this comment, had to zip it otherwise github wouldn't let me add it). This should work with an updated environment that has the tropy plugin installed in the most recent version (pip install -e kiara_plugin.tropy).
notebook_example.zip


dbg: SMART is not supported when works with smartctl

root@core:/home/risner # smart -i -d da3
...
dbg: protocol SCSI (specified auto)
Vendor SEAGATE
Device ST33000650SS
...
dbg: SMART is not supported
But it works:
smartctl -d scsi -a da3
=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              ST33000650SS
...
Transport protocol:   SAS (SPL-3)
...
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
...
Ideas?

I agree, it should be supported. Can you attach the full debug output from the smart command as well as the full output from smartctl -a?

# smart -d -i da3
dbg: Looking for page 0x89 (total = 16):
dbg:    [0] = 0
dbg:    [1] = 0x80
dbg:    [2] = 0x82
dbg:    [3] = 0x83
dbg:    [4] = 0x86
dbg:    [5] = 0x87
dbg:    [6] = 0x88
dbg:    [7] = 0x8a
dbg:    [8] = 0x90
dbg:    [9] = 0xb1
dbg:    [10] = 0xc0
dbg:    [11] = 0xc1
dbg:    [12] = 0xc2
dbg:    [13] = 0xc3
dbg:    [14] = 0xd1
dbg:    [15] = 0xd2
dbg: protocol SCSI (specified auto)
Vendor SEAGATE
Device ST33000650SS
Revision 0003
Serial Z295J46D00009318K2E1
dbg: SMART is not supported

# smartctl -a -d scsi da3
smartctl 7.2 2020-12-30 r5155 [FreeBSD 13.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               SEAGATE
Product:              ST33000650SS
Revision:             0003
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000c50055d0634f
Serial number:        Z295J46D00009318K2E1
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sun Aug  1 15:53:23 2021 EDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     45 C
Drive Trip Temperature:        68 C

Accumulated power on time, hours:minutes 58338:19
Manufactured in week 52 of year 2012
Specified cycle count over device lifetime:  10000
Accumulated start-stop cycles:  191
Specified load-unload count over device lifetime:  300000
Accumulated load-unload cycles:  191
Elements in grown defect list: 0

Vendor (Seagate Cache) information
  Blocks sent to initiator = 62997878
  Blocks received from initiator =<PHONE_NUMBER>
  Blocks read from cache and sent to initiator = 772659
  Number of read and write commands whose size <= segment size = 3454087
  Number of read and write commands whose size > segment size = 0

Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 58338.32
  number of minutes until next internal SMART test = 40

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   250083426        0         0  250083426          0         32.251           0
write:         0        0         0         0          0       5097.072           0

Non-medium error count:       27

[GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on']
SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   57721                 - [-   -    -]

Long (extended) Self-test duration: 27600 seconds [460.0 minutes]

I agree, it should be supported. Can you attach the full debug output from the smart command as well as the full output from smartctl -a?

Anything else you need?

For SCSI, smart looks for the Informational Exceptions page (ID of 0x2f) to determine if the device supports SMART. Can you add the output from sg_logs?

Sure. However I don’t know how to do that?

# pkg install sg3_utils
# sg_logs da3

SEAGATE   ST33000650SS      0003

Supported log pages  [0x0]:
0x00        Supported log pages [sp]
0x02        Write error [we]
0x03        Read error [re]
0x05        Verify error [ve]
0x06        Non medium [nm]
0x0d        Temperature [temp]
0x0e        Start-stop cycle counter [sscc]
0x10        Self test results [str]
0x15        Background scan results [bsr]
0x18        Protocol specific port [psp]
0x1a        Power condition transitions [pct]
0x37        Cache (seagate) [c_se]
0x38
0x3e        Factory (seagate) [f_se]

Difference between working disks and non-working disks:
--- /tmp/da2    2021-08-02 19:00:12.380224000 -0400
+++ /tmp/da3    2021-08-02 19:00:08.817748000 -0400
@@ -1,4 +1,4 @@

SEAGATE   ST3000NM0023      0004

SEAGATE   ST33000650SS      0003
Supported log pages  [0x0]:
0x00        Supported log pages [sp]
0x02        Write error [we]
@@ -7,12 +7,10 @@
0x06        Non medium [nm]
0x0d        Temperature [temp]
0x0e        Start-stop cycle counter [sscc]

0x0f        Application client [ac]
0x10        Self test results [str]
0x15        Background scan results [bsr]
0x18        Protocol specific port [psp]
0x1a        Power condition transitions [pct]
0x2f        Informational exceptions [ie]
0x37        Cache (seagate) [c_se]
0x38
0x3e        Factory (seagate) [f_se]

OK, so the device supports all the pages smart would read if the Informational Exceptions log page existed. If you execute the command smartctl -s on /dev/da3, does sg_logs list the Informational Exceptions page on the non-working disk?

Like this?
smartctl -s on -d scsi da3
smartctl 7.2 2020-12-30 r5155 [FreeBSD 13.0-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
Informational Exceptions (SMART) enabled
Temperature warning enabled
sg_logs /dev/da3
SEAGATE   ST33000650SS      0003

Supported log pages  [0x0]:
0x00        Supported log pages [sp]
0x02        Write error [we]
0x03        Read error [re]
0x05        Verify error [ve]
0x06        Non medium [nm]
0x0d        Temperature [temp]
0x0e        Start-stop cycle counter [sscc]
0x10        Self test results [str]
0x15        Background scan results [bsr]
0x18        Protocol specific port [psp]
0x1a        Power condition transitions [pct]
0x37        Cache (seagate) [c_se]
0x38
0x3e        Factory (seagate) [f_se]

Yes, that is what I wanted you to do, but it didn't add Informational Exceptions to the list of supported log pages. I'm torn here as to how I should fix this. Let me research this a bit and get back to you.

I just realized that the sources on github were out of date with the development repo. I just pushed changes to bring the github version up to date. Note that the changes include support for SCSI's Informational Exceptions log page, but given the date you've provided, I don't expect smart to behave differently. That said, it'd be worth verifying this is the case if you have time.

I pushed some experimental changes to the issue-9 branch that report whichever health log pages the device advertises. See if that gets you closer to the result you wanted.


test: replaced some dummy APIs

/ok-to-test<EMAIL_ADDRESS>EE PR: https://github.com/appsmithorg/appsmith-ee/pull/5272

[!CAUTION]
🔴 🔴 🔴 Some tests have failed.
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11162865103
Commit: 205958c46b080027acc7119089a641a0a8762d45
Cypress dashboard.
Tags: @tag.All
Spec:
The following are new failures, please fix them before merging the PR:
cypress/e2e/Regression/ClientSide/ExplorerTests/Widgets_Sidebar.ts
List of identified flaky tests.
Thu, 03 Oct 2024 16:50:28 UTC

Summary by CodeRabbit

New Features

Updated API endpoint for authentication in Production and Staging environments.
Added new configuration property for Okta username.

Bug Fixes

Improved database connection parameters for enhanced reliability.

closing this as its redundant


cocomac: Watch place[\W_]+your[\W_]+order

cocomac requests the watch of the watch_keyword place[\W_]*+your[\W_]*+order. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by cigien in Charcoal HQ


Consider renaming top level package to org.apereo

For v5, this is a good opportunity to rename top level package from org.jasig to org.apereo to reflect the reality of an umbrella organization. I am +1 this one...

+1

Discussing the move with sonatype. Hold tight.

This is ready: https://issues.sonatype.org/browse/OSSRH-22155

It's the kind of thing we should really do before M1.

exactly

OK, I'll try to tackle this one today, falling back to @mmoayyed if I fail miserably ;-)


enhancements

Would love to see

vim shortcuts

Playlist support  - Done

Album suport

Shuffle support

More descriptive artist page e.g.: albums and top songs

I don't have much free time but I'll read the code later and reverse engineer the iOS app a bit to see how these things would work. Also I love CLI but an electron app might be best for an app like this. Really wish we could run Tidal without flash installed the way Spotify has their own linux version.

Thank you for your ideas. Right now I don't have much time, because of school, but I'll do my best to make it.

Playlists are supported from the last update. Now I'll work on albums.

Also, what do you mean by vim shortcuts?

Albums and top songs are available now.

Thank you, I'll try to do it all!


feat: add FetchEventContext class to handle event initialization and args loading

FetchEventContext class to handle event initialization and args loading
The args file path was set in globalThis.vulcan.argsPath

:tada: This PR is included in version 4.1.0-stage.1 :tada:
The release is available on:

npm package (@stage dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


x86 (32bit os support please)

current delve can not use on 32bit os.

Duplicate of #20.

@aarzilli Sorry, but I can't find any solution for this on #20

There isn't one, somebody has to do the work.


option to disable unreachable code warning

there are many problems with pyright's unreachable code detection. see https://github.com/microsoft/pyright/issues/1951, https://github.com/microsoft/pyright/issues/2231, https://github.com/microsoft/pyright/issues/1531
it would be nice to have an option to disable unreachable code warnings. especially since my project already uses mypy to detect unreachable code anyway.

\extPython

https://github.com/microsoft/vscode-python/issues/17276


cmd/link: 1.16 broken for Annapurna AL-212 and possibly other ARM chips (R_ARM_V4BX)

What version of Go are you using (go version)?
Currently I'm using 1.15.8 which I compiled on my Netgear ReadyNAS RN204 that is using an Annapurna AL-212 chip.
When trying to build 1.16.x (tried with 1.16 and 1.16.2) I ran into compile problems, telling me about unexpected relocation type 296 (R_ARM_V4BX)
Does this issue reproduce with the latest release?
Yes.
Inspection of the code in question showed that the linker code handling R_ARM_V4BX was removed between 1.15.x and 1.16.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/arm.
net(.text): unexpected relocation type 296 (R_ARM_V4BX)
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x115a84]

What did you expect to see?
A working build.
What did you see instead?
Go 1.16 and 1.16.2 won't build, see above.

/cc @thanm @jeremyfaller

What vintage of C compiler are you using?  R_ARM_V4BX as I understand it is an ArmV4 construct (e.g. very ancient).

Since the ReadyNAS "firmware" is based on Debian 8 it's gcc 4.7.2 and, yes, that's quite ancient. But I was under the impression that gcc wouldn't be used at all when building with a version of go already present on the system?

Go needs a C compiler in order to support cgo, which is enabled by default. So if you run make.bash at some point the C compiler will get invoked.
You can get the behavior you refer to by using CGO_ENABLED=0 bash make.bash.

Thanks, I have to admit that I was mislead by the output from make.bash saying "using /usr/lib/go ..." and thus didn't look further. Now, using CGO_ENABLED=0 works for building go itself on my box but what about modules/packages that rely on cgo? I guess they'd still fail  without the patch to cmd/link because of gcc producing outdated ARM code?
I'm aware that this is for really ancient systems but then there's a lot of those out there that can't be updated easily to a newer distro base.

Well I think this may be getting into the philosophical realm... I think most would agree that there needs to be some sort of limit on how far back we want to go in terms of supporting older versions of things. It's just a question of where you draw the line IMO.
Generally speaking when making changes to the tools (linker, compiler etc) we want to have regression tests to make sure that new changes don't break existing functionality.
Having code in the linker that is only triggered by an ancient compiler is problematic in that if we wanted to have a test, we'd need to have a builder with a C compiler that produces something that will cause the code to run ... this is obviously how this got broken here in the first place.

Go has required ARMv5+ since a long time ago. I don't think we'll add ARMv4 support back.
If the system and the C toolchain are both ancient, it probably works better with a version of Go that is as ancient. Thanks.

I totally agree. As I tried to point out I was under the impression that some part of the go toolchain was responsible for generating the R_ARM_V4BX (stupid in hindsight). That's why I submitted the PR. As long as I can fix it for me using my own patch, I'm fine. Sorry for the troubles.

Thanks, @RustyDust . If I read you correctly we can close this. Feel free to reopen if I'm mistaken. Thanks.

thought met the same problem:
/usr/local/Cellar/go/1.16.2/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: framework not found CoreFoundation
clang: error: linker command failed with exit code 1 (use -v to see invocation)
the code works in go version 1.15.  after upgrade to 1.16.2, error happen.
the code  import go-sqlite3, cgo is must option.

@dididudu998 this looks like a different problem. Could you file a new issue? It would be helpful if you provide what command you run and the full error output. If possible, do go build -x -ldflags=-v to get more information, which could be helpful.

I totally agree. As I tried to point out I was under the impression that some part of the go toolchain was responsible for generating the R_ARM_V4BX (stupid in hindsight). That's why I submitted the PR. As long as I can fix it for me using my own patch, I'm fine. Sorry for the troubles.

@RustyDust (posting for posterity): your patch applied to 1.17.6 (in my fork) appears to build nicely. (I got the segfault when compiling packr2 for an ancient NAS target based on glibc-2.13 in a container with the standard go1.17.2-arm release, that's my reason to need a patched go).
The tests fail though, but I'll first test using it for my builds and see what happens.


[Progress][Slider] Add format prop

Part of https://github.com/mui/base-ui/issues/961

Adds a format: Intl.NumberFormatOptions prop on ProgressRoot and SliderRoot

Range sliders optionally accepts format as an array to format different values differently

[x] I have followed (at least) the PR section of the contributing guide.

Split into:
https://github.com/mui/base-ui/pull/989
https://github.com/mui/base-ui/pull/990


Completes code snippets in scenario tutorial

Adds a code snippet to the Scenario Management Overview tutorial so the user can copy-paste each code snippet in order and have a functional code.

Fixes https://github.com/Avaiga/taipy/issues/707

This is ok for a merge in develop branch.


Call two times maybe_switch_forks consecutive, and apply_block exception

version: boscore: v3.0.0
env: k8s cluster 1
errorlog:

info  2019-07-09T07:02:23.688 thread-0  controller.cpp:1701           maybe_switch_forks   ] switching forks from 000007d98e7f513387ea449914c202cfd2ccdfac47780844170362b1c1721246 (block number 2009) to 000007e8b16d2a694055f26e5635f6c04906fe39e03908727130c8f0e4d2e54d (block number 2024)
info  2019-07-09T07:02:23.689 thread-0  controller.cpp:1701           maybe_switch_forks   ] switching forks from 000007bf9304f885f7cc60a868abe6f471c36a860fa238ef68e0db06fff3233e (block number 1983) to 000007e8b16d2a694055f26e5635f6c04906fe39e03908727130c8f0e4d2e54d (block number 2024)
info  2019-07-09T07:02:23.709 thread-0  controller.cpp:1746           maybe_switch_forks   ] successfully switched fork to new head 000007e8b16d2a694055f26e5635f6c04906fe39e03908727130c8f0e4d2e54d
error 2019-07-09T07:02:23.709 thread-0  controller.cpp:1546           apply_block          ] e.to_detail_string(): 3030000 block_validate_exception: Block exception
next block must be in the future
{}
thread-0  block_header_state.cpp:40 generate_next
error 2019-07-09T07:02:23.709 thread-0  controller.cpp:1721           maybe_switch_forks   ] exception thrown while switching forks 3030000 block_validate_exception: Block exception
next block must be in the future
{}
thread-0  block_header_state.cpp:40 generate_next
{}
thread-0  controller.cpp:1550 apply_block

error 2019-07-09T07:02:23.747 thread-0  pbft.cpp:153                  on_new_view          ] apply new view failed, waiting for next round.. {"common":{"type":"new_view","timestamp":"2019-07-09T07:00:42.897"},"new_view":2,"prepared_cert":{"block_info":{"block_id":"0000000000000000000000000000000000000000000000000000000000000000"},"pre_prepares":[],"prepares":[]},"committed_certs":[{"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"commits":[{"common":{"type":"commit","timestamp":"2019-07-09T07:00:05.694"},"view":1,"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"sender_signature":"SIG_K1_K2UcwhvNn4H8guk94b2K3EhaH54yfbAYPwKVpSEUC7tPwoak5Tjdx2gSD11GAxUm97SWACAwGWFQcuG7WzQdzgqb6k877R"},{"common":{"type":"commit","timestamp":"2019-07-09T07:00:05.694"},"view":1,"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"sender_signature":"SIG_K1_JvM7V3prjK3CKtd5ariRobGKkrLd2LQR2aja2dwnQ9uETW5snxo3UKZwZM8bnfqYsmWeXCG5pPEAUWL2dmqea3vwBHa4qh"},{"common":{"type":"commit","timestamp":"2019-07-09T07:00:05.764"},"view":1,"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"sender_signature":"SIG_K1_KXo8gNsnxz65UTbqiu42F53JgWR1U3nkVBSWxwfWxgaCS9aRUfsCEp6zBZnDhoKMnnr3rMNj6HipB4Z9YY9rdhCECoGQun"},{"common":{"type":"commit","timestamp":"2019-07-09T07:00:05.908"},"view":1,"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"sender_signature":"SIG_K1_Jv1un11VYyQUHjFYv4CE6tVsiLNTXtdfcrR1SZCStp48anuMVWpa2GoJghoD5eAE9RQeQKrjcfoe3hpddF5iJj1hMDrEm8"},{"common":{"type":"commit","timestamp":"2019-07-09T07:00:05.743"},"view":1,"block_info":{"block_id":"00000764be6c26b6c9cfb95d49987a4c4bedfed4d75c5d9572e1d8bef469f9f1"},"sender_signature":"SIG_K1_K68LECAZRybZYLXxns6Bs9mTwbk3McPGqxAKbKaYHSa5MLjqvn8LydSdWntv1crFgPajZ6YfP8JqLRUifbdPXWABNn3yau"}....

committed block did not become the new head in fork database
{}
thread-0  controller.cpp:927 commit_block
warn  2019-07-09T07:03:11.504 thread-0  producer_plugin.cpp:1147      start_block          ] 3060000 database_exception: Database exception
db revision is not on par with head block
{"db.revision()":2024,"controller_head_block":2009,"fork_db_head_block":2009}
thread-0  controller.cpp:1358 start_block
error 2019-07-09T07:03:11.504 thread-0  producer_plugin.cpp:1446      schedule_production_ ] Failed to start a pending block, will try again later
warn  2019-07-09T07:03:11.554 thread-0  producer_plugin.cpp:1147      start_block          ] 3060000 database_exception: Database exception
db revision is not on par with head block
{"db.revision()":2024,"controller_head_block":2009,"fork_db_head_block":2009}
thread-0  controller.cpp:1358 start_block
error 2019-07-09T07:03:11.554 thread-0  producer_plugin.cpp:1446      schedule_production_ ] Failed to start a pending block, will try again later
warn  2019-07-09T07:03:11.605 thread-0  producer_plugin.cpp:1147      start_block          ] 3060000 database_exception: Database exception
db revision is not on par with head block
{"db.revision()":2024,"controller_head_block":2009,"fork_db_head_block":2009}
thread-0  controller.cpp:1358 start_block
error 2019-07-09T07:03:11.605 thread-0  producer_plugin.cpp:1446      schedule_production_ ] Failed to start a pending block, will try again later
warn  2019-07-09T07:03:11.655 thread-0  producer_plugin.cpp:1147      start_block          ] 3060000 database_exception: Database exception
db revision is not on par with head block
{"db.revision()":2024,"controller_head_block":2009,"fork_db_head_block":2009}

It will call on new view when handling a new view message. The new view with committed certificate will commit local and set pending_pbft_lib value to be true. This will trigger the second time maybe_switch_forks function call.  First of all, maybe_switch_forks is called in the cleanup_on_new_view. At this time, the controller head 2009 try to switch forks to fork_db head 2024. After it pops from block 2009 to 1983. Then it tries to apply the block 1983 to 2024, but when apply_block it will trigger set_pbft_lib in start_block function. Then it will call maybe_switch_forks second time because of pending_pbft_lib is true which was set previously. The controller will switch fork from current head 1983 to 2024 in the second maybe_switch_forks function call. This time it success to switch forks to head 2024. After finish the second time switch fork, it will go back to the first time switch fork. It will throw an exception block_validate_exception, "next block must be in the future" when generating next block.
This issue has a full test case called new_view_with_committed_cert_call_two_times_maybe_switch_forks. And fixed in commit 20e08dba


data:theselaw

added my username.json file

If you have any questions, you can come and ask in the EddieHub Discord http://discord.eddiehub.org

Do you need any help with the requested changes @theselaw ?


Allow CF_TRACE output for failed pushes

During deploys to CF (especially 3rd-party provided CFs) it's useful (or required by support) to be able to provide the CF_TRACE output for debugging failed pushes

Could this be fixed in the CLI instead somehow? Feels really gross for this low-level platform debugging feature to be needed at pretty much the top of the toolchain. Perhaps the CLI could just print request IDs when it fails?

Closing; we won't be adding this soon, still seems like something that could be added to the CLI instead.

@vito  CF_TRACE is an environment variable.... point is whether cf resource/any concourse resource accept customized environment variable


Null Safety Update

Please update the package for null safety

https://github.com/iamnabink/another_carousel_pro , this is the null safe version of this package, feel free to contribute, will be soon live in  pub.dev

https://github.com/iamnabink/another_carousel_pro , this is the null safe version of this package, feel free to contribute, will be soon live in pub.dev

Great. Please update when it's live on pub.dev .

https://github.com/iamnabink/another_carousel_pro , this is the null safe version of this package, feel free to contribute, will be soon live in pub.dev

Please any updates on when this package will be live on pub.dev?

carousel_pro_nullsafety: ^1.0.2

Apologies for the delayed activation in the community. I have tested and verified the package for your project and can confirm that it will not cause any code breakage. You may access the package at https://pub.dev/packages/another_carousel_pro.
It comes with detailed documentation and recent updates.

https://github.com/iamnabink/another_carousel_pro , this is the null safe version of this package, feel free to contribute, will be soon live in pub.dev

Please any updates on when this package will be live on pub.dev?

Apologies for the delayed activation in the community. I have tested and verified the package for your project and can confirm that it will not cause any code breakage. You may access the package at https://pub.dev/packages/another_carousel_pro.  pub.dev
and Just Change class name from Carousel to AnotherCarousel
It comes with detailed documentation and recent updates.

https://github.com/iamnabink/another_carousel_pro , this is the null safe version of this package, feel free to contribute, will be soon live in pub.dev

Great. Please update when it's live on pub.dev .

Apologies for the delayed activation in the community. I have tested and verified the package for your project and can confirm that it will not cause any code breakage. You may access the package at https://pub.dev/packages/another_carousel_pro.  pub.dev
and Just Change class name from Carousel to AnotherCarousel
It comes with detailed documentation and recent updates.

@iamnabink, I would like to inform you that your plugin another_carousel_pro has some borderRadius issues on flutter latest version 3.7.13+. Can you please look into that and provide an update?

I'm having the same issue with the latest Flutter version: "Error: The argument type 'BorderRadius?' can't be assigned to the parameter type 'BorderRadiusGeometry' because 'BorderRadius?' is nullable and 'BorderRadiusGeometry' isn't."
Any suggestions on how to solve this issue?

Hi, i resolve then issue reemplacing the line 205 the file carousel_pro_nullsafety.dart  in module, is a soluction temporal while  waiting an oficial
this to change null for BorderRadius.zero

Hy ✋🏻 @ricky2k7 @jecuevas , thanks, issue has been resolved and new updated version of another_carasoul_pro has been made live, please check it out here : https://pub.dev/packages/another_carousel_pro

Hey @iamnabink! Thanks for the feedback and update. I'm going to check it out :)


Allow JSON specified hotspot function handlers

Fixes issue mentioned here: https://github.com/mpetroff/pannellum/issues/252#issuecomment-281464915
My first pull request here: I have read the contributing guidelines and hope I've got everything right.
Currently there is no way to specify createTooltipFunc or clickHandlerFunc in the JSON config file, as the strings passed in are not recognised as functions, so calls to them fail.
This patch fixes the issue by explicitly searching the contents of the JSON hotSpots item for anything ending in Func and replacing the string with the relevant JS function reference.
Arguments can be passed using createTooltipArgsor clickHandlerArgs in the normal way.
NB - The JS file containing these functions must be included prior to the inclusion of standalone.js or it won't work.

Thanks, but the standalone.js file is not part of Pannellum's public API. It's only for internal use as part of the pannellum.htm standalone version.
Click handlers are only intended to be used with Pannellum's API, not with the standalone version. Obviously, you're free to adapt the standalone version to your own use, but I'm not going to merge such changes. Also, this PR breaks the pannellum.htm build process, since the PR uses ES6 syntax.

So I've spent almost a day trying to figure a workaround for this issue.
All I want is to standardize the icons for tooltip/scene change but apparently I have to create a custom function for. Which doesn't work because I get my pannellum data via API in JSON format.
Not sure why you don't want to implement a one liner fix that would use window[functionName] so it could take a string value as well.

@joshuakoh1 If you want to change the icon, you can do so using the hot spot cssClass configuration parameter to specify a new CSS class, which specifies the new icon as the hot spot background.
This isn't a one line fix; it's non-functional bloat for the designed usage of the standalone viewer. The standalone viewer can't use a custom function without the viewer being edited. However, the standalone viewer isn't meant to be edited; for such functionality, the API is meant to be used. If you're editing the standalone viewer, you're using it as example code. In this case you're more than welcome to make your own changes, but such changes don't belong in the default standalone viewer.


gpflow.utilities.set_trainable vs Parameter.trainable

There are now two different ways for changing the trainable state of parameters: e.g. kernel.variance.trainable = True # False for Parameter instances, and gpflow.utilities.set_trainable(kernel, False) for tf.Module instances. The danger is setting kernel.trainable = False which actually has no effect. Can we somehow catch this and at least throw an error? Alternatively, would it be worth explicitly using set_trainable() everywhere to show users "this is the way to do it"?

We should encourage using set_trainable(param, is_trainable) instead of param.trainable = is_trainable in the notebooks, and perhaps add a warning to the trainable attribute setter in gpflow.Parameter to raise a warning and encouraging use of set_trainable() instead.


CSS prop shows a TypeScript error for properties with undefined values

Bug report
Repro: https://codesandbox.io/s/solitary-butterfly-udx18?file=/src/App.tsx
Describe the bug
I was using stitches' alpha version, when I tried migrating to the beta version, I now received this error.
When you give a property value of undefined for a styled component's css prop, it shows a TypeScript error.
<StyledComponent css={{ width: isMobile ? '10px' : undefined  }} />

Expected behavior
It should work like how it was before in Alpha.
Screenshots

System information

OS: macOs
Version of Stitches: 0.1.0-canary.3
Version of Node.js: v14.15.4
Version of TypeScript: 4.1.2

Adding on to this, it seems like we get this type error when spreading css into the css prop.
const StyledButton = styled('button', { ...stylesHere });

type StyledButtonProps = ComponentProps<typeof StyledButton>;

type BigButtonProps = StyledButtonsProps;

const BigButton = ({ css }: BigButtonProps) => {
	return (
		<StyledButton
			css={{
				backgroundColor: 'transparent',
				// This causes a type error
				...(css ?? {}),
				// This also causes a type error
				...css
			}}
		/>
	);
};

@andyhqtran I cant reproduce. This works fine for me
const Button = styled('button', {});

type ButtonProps = React.ComponentProps<typeof Button>;

function MyButton({ css, ...props }: ButtonProps) {
  return <Button {...props} css={{ ...css }} />;
}

Fixed in #389

@andyhqtran please raise a new issue with a repro if you could. That would be very helpful. Thanks


Document schema/model capitalization best practices on Snowflake

Or, alternatively, configure the Snowflake adapter to consistently use upper-cased identifiers.

fixed in 0.10.1


Update scalafmt-core to 3.0.1

Updates org.scalameta:scalafmt-core from 3.0.0-RC5 to 3.0.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, semver-pre-release

Closed in favor of #482


Dropping the '_layer' from abstraction_layer and user_layer packages

This is a minor issue, but I was wondering whether you would object to dropping the layer suffix from the packages relating to layers. As I am usually a bit frustrated by the time I type 'abstraction' let alone the '_layer' part, and I think it would be pretty obvious at that point that they represent the layer structures (even with less obvious names 'structure', 'property' and 'experiment' in future).

I think this is a good idea.

It's an excellent idea, and the abstraction layer needs a more descriptive
name like math or equation.
On Tue, May 19, 2015 at 2:07 AM, Tom Close<EMAIL_ADDRESS>wrote:

This is a minor issue, but I was wondering whether you would object to
dropping the layer suffix from the packages relating to layers. As I am
usually a bit frustrated by the time I type 'abstraction' let alone the
'_layer' part, and I think it would be pretty obvious at that point that
they represent the layer structures (even with less obvious names
'structure', 'property' and 'experiment' in future).
—
Reply to this email directly or view it on GitHub
https://github.com/INCF/lib9ML/issues/10.

Hi Ivan,
I raised this suggestion (possibly even the same names:) when we were discussing the new layer structure in Gif, but the feeling was that since the abstraction layer was the only layer that was to be left unchanged that it would be confusing to rename it.
However, I think we probably should have a wider discussion about backwards compatibility at some point, as this something that Erik is very keen to maintain, even though I think most of us were only thinking of it from version 2.0 onwards.
(NB: This should probably be discussed on the INCF/nineml issue tracker instead)

I am usually a bit frustrated by the time I type 'abstraction' let alone the '_layer' part

This is what tab-completion is for     :wink:
But seriously, this change is fine with me

This is what tab-completion is for  :wink:

Yeah, that is the only reason it has lasted this long, however, when I am in an environment without tab-completion it drives me batty ;)

But seriously, this change is fine with me

Okay great.


Test Lead @ MATTR

Test Lead
Job type
Full-time
Location
Auckland, New Zealand
Company
MATTR
Job description
Are you ready for a new challenge - leading a test team in a new technology space.
Test Lead
Contact
Ivan Cheng (程逸凡)

The role is occupied, no CITA members applied.


Replace configuration_file_build_time

The old build time configuration file was fundamentally flawed. The
configuration specific path to a target is can be only conveyed with
CMake via generator expressions. But this function did not use them,
but relied on setting and the LOCATION property of the target to the
same location for each target. So the build time configuration wasn't
even needed. Also the LOCATION manipulation produced a CMP0026
warning.
This new approach does an initial basic configuration, then does a
second pass which actually does a build time configuration with CMake
generator expressions manually passed.
The old CMake file to provide the function has been removed.

This should address issue #275


Refactor storage classes and update testcases

Fixes #62, Fixes #59, Fixes #60, Fixes #58
Changes

Added more abstractions for storage classes. These classes now extend from JsonAppStorage which provides general methods for reading and retrieving data.
Update behaviour for initModelManager to read all relevant JSON files and store them in the application cache.
JsonAdaptedVolunteer and JsonAdaptedElderly now extend from JsonAdaptedPerson
Serializable entities now implement the JsonSerializable interface which ensures they override the toModelType method
Add test cases for Volunteer and Elderly Storage
Overall improvement in code quality from the previous sprint.

Notes
To clarify, the current storage structure is as follows:

FriendlyLinkStorage -- responsible for application state (i.e. summary statistics if we were to implement them)
ElderlyStorage -- for Elderly
VolunteerStorage -- for Volunteer

On the other hand, we have FriendlyLink implements ReadOnlyFriendlyLink which extends from ReadOnlyElderly and ReadOnlyVolunteer. The FriendlyLink class refers to the application-wide cache that holds the UniqueList for all entities.
TODO

[x] implement quick-hax autosave for now

hi

Codecov Report
Patch coverage: 81.08% and project coverage change: +4.96 :tada:

Comparison is base (3bdc94b) 63.01% compared to head (b29922a) 67.97%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff              @@
##             master      #76      +/-   ##
============================================
+ Coverage     63.01%   67.97%   +4.96%
- Complexity      549      597      +48
============================================
  Files           101      104       +3
  Lines          1925     1961      +36
  Branches        204      207       +3
============================================
+ Hits           1213     1333     +120
+ Misses          651      557      -94
- Partials         61       71      +10

Impacted Files
Coverage Δ

src/main/java/seedu/address/MainApp.java
0.00% <0.00%> (ø)

.../main/java/seedu/address/model/person/Elderly.java
95.55% <ø> (ø)

...in/java/seedu/address/storage/JsonAdaptedPair.java
0.00% <ø> (ø)

...ain/java/seedu/address/storage/JsonAdaptedTag.java
100.00% <ø> (ø)

...ain/java/seedu/address/storage/StorageManager.java
76.31% <42.85%> (+26.31%)
:arrow_up:

...du/address/storage/elderly/JsonAdaptedElderly.java
62.06% <62.06%> (ø)

...ddress/storage/volunteer/JsonAdaptedVolunteer.java
63.63% <63.63%> (ø)

...rc/main/java/seedu/address/logic/LogicManager.java
68.00% <100.00%> (+2.78%)
:arrow_up:

...rc/main/java/seedu/address/model/FriendlyLink.java
76.62% <100.00%> (+12.76%)
:arrow_up:

.../java/seedu/address/storage/JsonAdaptedPerson.java
100.00% <100.00%> (ø)

... and 23 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


feat: make oneinch great again

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #5105   👈

This comment was auto-generated by Graphite.


fix #53 check app version in stdout instead stderr

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
All new code requires tests to ensure against regressions
Remember to set idealista:develop as base branch;

Description of the Change

Benefits
Change where app version check is done (stdout instead stderr)
Possible Drawbacks
None.
Applicable Issues
fix #53

Finally, a lot of tools write the version in the stderr output.

Finally, a lot of tools write the version in the stderr output.


Invalid Error: resource deadlock would occur

I'm performing a row insertion transaction (the primary key "" - already exists), but I'm getting a "duplicate key error" (Constraint Error: Duplicate key  violates primary key constraint. If this is an unexpected constraint violation please double check with the known index limitations section in our documentation (docs - sql - indexes)).
After this I cannot perform another insert or select operation and receive the following error.
Error: Invalid Error: resource deadlock would occur: resource deadlock would occur
Perhaps I need to process the transaction in some special way?
How can you identify and resolve the blockage that has occurred?
As I understand the question in Over-Eager Unique Constraint Checking. But how to correctly handle the error so that there are no deadlocks?

we may need to close the error connection and create a new one

I encountered a similar problem, but it only occurs on Windows.
// duckdb = "1.0.0"
fn main() {
    let conn = duckdb::Connection::open_in_memory().unwrap();

    conn.execute(r"CREATE TABLE user (id uuid PRIMARY KEY);", []).unwrap();

    // macOS, Linux ✅, Windows ✅
    conn.execute("INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000');", []).unwrap();

    // macOS, Linux ✅, Windows ✅
    // Constraint Error: Duplicate key...
    dbg!(conn.execute("INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000');", []));

    // macOS, Linux ✅
    // Constraint Error: Duplicate key...
    // Windows ❌
    // Invalid Error: resource deadlock would occur: ...
    dbg!(conn.execute("INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000');", []));
}

The same error occurs when I only use the libduckdb-sys crate.

I wrote the same example in C, and it produced the same results on both macOS and Windows without any issues.
#include <stdio.h>
#include <stdlib.h>
#include "duckdb.h"

void query(duckdb_connection con, const char* query) {
    duckdb_result result;
    duckdb_state state;
    if (duckdb_query(con, query, &result) == DuckDBError) {
        fprintf(stderr, "%s\n", duckdb_result_error(&result));
    }
    duckdb_destroy_result(&result);
}

int main() {
    duckdb_database db;
    duckdb_connection con;

    duckdb_open(NULL, &db);
    duckdb_connect(db, &con);

    query(con, "CREATE TABLE user (id uuid PRIMARY KEY)");
    query(con, "INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000')");
    query(con, "INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000')");
    query(con, "INSERT INTO user (id) VALUES ('00000000-0000-0000-0000-000000000000')");

    duckdb_disconnect(&con);
    duckdb_close(&db);

    return 0;
}


Detected blocking call to sleep inside the event loop.

This error comes up in the HA log on Home Assistant 2022.3.1
Describe the bug
`Logger: homeassistant.util.async_
Source: util/async_.py:150
First occurred: 4 March 2022, 21:07:36 (1 occurrences)
Last logged: 4 March 2022, 21:07:36
Detected blocking call to sleep inside the event loop. This is causing stability issues. Please report issue to the custom component author for samsungtv_tizen doing blocking calls at custom_components/samsungtv_tizen/websockets.py, line 115: time.sleep(self.key_press_delay)

samsungtv_tizen


Set Exif only once for camera image

Looks good! :smile:
I wonder if it is worth storing exif as a member of CameraImage class? Maybe we could instead pass it as a parameter to computeOrientation and computeTimestamp. Not a big deal though. Otherwise :+1:


env_logger cannot be used as root logger because it is not unwind safe

use slog::Drain;

fn main() {
    let drain = slog::Discard;
    let drain = slog_envlogger::LogBuilder::new(drain).build();
    // Does not help:
    // let drain = drain.fuse();
    let logger = slog::Logger::root(drain, slog::o!());
}

error[E0277]: the type std::cell::UnsafeCell<std::option::Option<std::boxed::Box<std::cell::RefCell<regex::exec::ProgramCacheInner>>>> may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
--> src/main.rs:8:18
|
8    |     let logger = slog::Logger::root(drain, slog::o!());
|                  ^^^^^^^^^^^^^^^^^^ std::cell::UnsafeCell<std::option::Option<std::boxed::Box<std::cell::RefCell<regex::exec::ProgramCacheInner>>>> may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
|
::: /.cargo/registry/src/github.com-1ecc6299db9ec823/slog-2.5.2/src/lib.rs:1120:38
|
1120 |         T: SendSyncRefUnwindSafeKV + 'static,
|                                      ------- required by this bound in slog::Logger::<D>::root
|
= help: within slog_envlogger::EnvLogger<slog::Discard>, the trait std::panic::RefUnwindSafe is not implemented for std::cell::UnsafeCell<std::option::Option<std::boxed::Box<std::cell::RefCell<regex::exec::ProgramCacheInner>>>>
= note: required because it appears within the type thread_local::cached::CachedThreadLocal<std::cell::RefCell<regex::exec::ProgramCacheInner>>
= note: required because it appears within the type regex::cache::imp::Cached<std::cell::RefCell<regex::exec::ProgramCacheInner>>
= note: required because it appears within the type regex::exec::Exec
= note: required because it appears within the type regex::re_unicode::Regex
= note: required because it appears within the type slog_envlogger::filter::Filter
= note: required because it appears within the type std::option::Option<slog_envlogger::filter::Filter>
= note: required because it appears within the type slog_envlogger::EnvLogger<slog::Discard>
= note: required because of the requirements on the impl of slog::SendSyncRefUnwindSafeDrain for slog_envlogger::EnvLogger<slog::Discard>

I find this surprising. In one of the examples https://github.com/slog-rs/envlogger/blob/v2.2.0/examples/proper.rs the workaround seems to be that env_logger is wrapped in the async logger.

You probably want to use it behind an async anyway (for perf.), but yeah ... it probably shouldn't be much work to fix this. Please fill a PR! :)

I'll look into making a PR to fix this.
This actually came up because I wanted the logging chain to be slog_envlogger -> slog_async instead of what is probably more common slog_async -> slog_envlogger.
The reason for that is that I don't want messages that don't match the envlogger filter to end up on the async channel at all so that a for example a library cannot fill up the channel with trace logs (leading to dropped logs) when  they are going to be filtered out anyway.
Checking the log message against the filter probably has roughly similar performance as putting them on the channel in the first place.

Could you elaborate why slog requires types to be unwind safe in the first place?

Relevant regex issue https://github.com/rust-lang/regex/issues/576 .

Hmm, you could use AssertUnwindSafe as a quick-and-dirty fix.
I think in general the problem the compiler is worried about is that panicking may cause the logger to appear in an inconsistent state (because of interior mutability). Not sure if that's specifically a problem in slog_envlogger


release notes 5.2

first draft of release notes.
@karann-msft  - please run with this PR...as I'll be OOF most of the time between now and release.

Docs Build status updates of commit 623bd80:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit f9aef96:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

I removed https://github.com/NuGet/Home/issues/8156 from the notes.

Docs Build status updates of commit 6d10283:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit cf96546:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit dc6dac7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 427edea:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 2b8b011:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/release-notes/NuGet-5.2-RTM.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


import "C" breaks cross-compiling to Linux in OSX

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.8 darwin/amd64
What operating system and processor architecture are you using (go env)?
OSX 10.12.3
Darwin Wintermute.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64 i386 MacBookPro11,5 Darwin

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/pgautam/go"
GORACE=""
GOROOT="/Users/pgautam/go-src"
GOTOOLDIR="/Users/pgautam/go-src/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sj/n5_cngpx27xd0cxrqry3j65h0000gn/T/go-build807902586=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?
I created a file in a package proj with import "C" where C is never referenced in the code.
package proj

import "C"
import "fmt"

func Hello() {
        fmt.Println("Hello There!")
}

Then I made a main.go file with the following contents
-> % cat main.go
package main

import "github.com/prasincs/testproject/proj"

func main() {
        proj.Hello()
}

go build -o testproject . works as expected
but  cross compiling fails
-> % GOOS=linux go build -o testproject  .
main.go:3:8: no buildable Go source files in /Users/pgautam/go/src/github.com/prasincs/testproject/proj

If I explicitly set CGO_ENABLED=1, I still get the same error
-> % CGO_ENABLED=true GOOS=linux go build -o testproject .
main.go:3:8: no buildable Go source files in /Users/pgautam/go/src/github.com/prasincs/testproject/proj

What did you expect to see?
I was expecting the following:

C is never used in the code but it is imported, that should be an error at build time
If the previous point is expected behavior, it should work with GOOS=linux enabled too.
CGO_ENABLED=1 should work if the issue is with cgo being turned off at cross-compile time.

What did you see instead?
I got the following instead of an error message regarding the spurious import "C" or a cross-compiled binary.
main.go:3:8: no buildable Go source files in /Users/pgautam/go/src/github.com/prasincs/testproject/proj

You are setting CGO_ENABLED=true

Cgo is not portable and cannot in general be used for cross-compilation as it requires the availability of C libraries on the target platform.
Sorry about this, but it's working as intended.


Create list of FeatureGates for cloud controller

This PR creates a publicly available list of FeatureGates that are valid to be used in the context of Cloud Controller. Currently the problem is that lots of features that are valid for kubelet, are invalid for the cloud provider. With this PR we are introducing a very simple way to filter out undesired features.

/cc @JoelSpeed

/cc @MaysaMacedo

/close
It's stale, it seems we don't need it anymore


Fix HexToString

Description

Fix order of arguments passed to TrimPrefix
Handle uneven input length

[x] Targeted PR against master branch
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Code follows the standards mentioned here.
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the Github PR explorer
[x] Added appropriate labels

Sorry I missed this in my PR :/

@bjartek No worries at all! I missed it too 😄 ... and I didn't realize CI was not set up for PRs, so everything was green, looked good, and I merged. Easy to fix, and looking into it, I discovered another issue (handling of uneven length input)

Yes i was not aware of that uneven input length and how to fix that.


PermissionDenied Error in PowerShell: A Puzzling Discrepancy

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
[project]
name = "test_pixi"
version = "0.1.0"
description = "Add a short description here"
channels = ["conda-forge", "pytorch"]
platforms = ["win-64"]

[tasks]
start = "jupyter-lab --no-browser"

[dependencies]
python = "3.11.*"
jupyterlab = ">=4.2.3,<4.3"
pytorch = ">=2.3.1,<2.4"
torchvision = ">=0.18.1,<0.19"
biopython = ">=1.84,<2"
scipy = ">=1.14.0,<1.15"

Issue description
PS C:\Users\Downloads\rosalind> pixi run start
✨ Pixi task (start in default): jupyter-lab --no-browser
  × An activation error occurred: IoError(Os { code: 5, kind: PermissionDenied, message: "액세스가
  │ 거부되었습니다." })

PS C:\Users\Downloads\rosalind> pixi run start
✨ Pixi task (start in default): jupyter-lab --no-browser
  × An activation error occurred: IoError(Os { code: 5, kind: PermissionDenied, message: "액세스가
  │ 거부되었습니다." })

PS C:\Users\Downloads\rosalind> pixi run start
✨ Pixi task (start in default): jupyter-lab --no-browser
  × failed to activate environment
  ╰─▶ An activation error occurred: IoError(Os { code: 5, kind: PermissionDenied, message: "액세스
      가 거부되었습니다." })

PS C:\Users\Downloads\rosalind> pixi run start
✨ Pixi task (start in default): jupyter-lab --no-browser
[I 2024-08-07 17:14:28.789 ServerApp] jupyter_lsp | extension was successfully linked.
[I 2024-08-07 17:14:28.797 ServerApp] jupyter_server_terminals | extension was successfully linked.
[I 2024-08-07 17:14:28.806 ServerApp] jupyterlab | extension was successfully linked.
[I 2024-08-07 17:14:29.290 ServerApp] notebook_shim | extension was successfully linked.
[I 2024-08-07 17:14:29.344 ServerApp] notebook_shim | extension was successfully loaded.
[I 2024-08-07 17:14:29.347 ServerApp] jupyter_lsp | extension was successfully loaded.

Expected behavior
I'm encountering a peculiar issue with a script that runs flawlessly on Linux but throws a PermissionDenied error in the Windows PowerShell environment. What's even more perplexing is that the script occasionally executes successfully after multiple attempts.
The scenario is as follows:
The script runs without any issues on Linux.
When run in Windows PowerShell, it randomly results in a PermissionDenied error.
Surprisingly, repeated execution sometimes allows the script to run successfully.
This inconsistent behavior is quite confusing, and I'm struggling to understand the root cause. What could be the reason behind this erratic permission denial in PowerShell, especially considering its smooth operation in Linux?
Also I've tried execute the terminal in supervisor mode, but it is not solved the problem. Any insights or assistance in resolving this issue would be greatly appreciated. Thank you in advance for your help!

The only thing that comes to mind directly would be, other tools or instances of pixi touching some files that this activation script is also running. Could you run the pixi shell-hook (outputs the activation script) and then see if there are any file called to activate the environment?

The only thing that comes to mind directly would be, other tools or instances of pixi touching some files that this activation script is also running. Could you run the pixi shell-hook (outputs the activation script) and then see if there are any file called to activate the environment?

PS C:\Users\Downloads\rosalind> pixi shell-hook
$OutputEncoding = [System.Console]::OutputEncoding = [System.Console]::InputEncoding = [System.Text.Encoding]::UTF8
${Env:Path} = "C:\Users\Downloads\rosalind\.pixi\envs\default;C:\Users\Downloads\rosalind\.pixi\envs\default\Library/mingw-w64/bin;C:\Users\Downloads\rosalind\.pixi\envs\default\Library/usr/bin;C:\Users\Downloads\rosalind\.pixi\envs\default\Library/bin;C:\Users\Downloads\rosalind\.pixi\envs\default\Scripts;C:\Users\Downloads\rosalind\.pixi\envs\default\bin;C:\Program Files\PowerShell\7;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\GitHub CLI\;C:\Program Files\PowerShell\7\;C:\Users\scoop\apps\vscode\current\bin;C:\Users\.pixi\bin;C:\Users\scoop\shims;C:\Users\AppData\Local\Microsoft\WindowsApps;C:\Users\AppData\Local\Microsoft\WindowsApps"
${Env:CONDA_PREFIX} = "C:\Users\Downloads\rosalind\.pixi\envs\default"
${Env:PIXI_EXE} = "C:\Users\.pixi\bin\pixi.exe"
${Env:CONDA_DEFAULT_ENV} = "test_pixi"
${Env:PIXI_PROJECT_ROOT} = "C:\Users\Downloads\rosalind"
${Env:PIXI_PROJECT_MANIFEST} = "C:\Users\Downloads\rosalind\pixi.toml"
${Env:PIXI_ENVIRONMENT_NAME} = "default"
${Env:PIXI_IN_SHELL} = "1"
${Env:PIXI_PROJECT_NAME} = "test_pixi"
${Env:PIXI_PROJECT_VERSION} = "0.1.0"
${Env:PIXI_ENVIRONMENT_PLATFORMS} = "win-64"
${Env:PIXI_PROMPT} = "(test_pixi) "
. "C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1"
. "C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1"

This is the output.

I am also seeing a similar error on my Linux machine. Pixi was working fine, then I ran pixi self-update --force to update from 0.25.0 to 0.27.1.
Now, I get this error when I run pixi shell or pixi shell-hook
thread 'main' panicked at crates/pixi_utils/src/reqwest.rs:99:10:
failed to create reqwest Client: reqwest::Error { kind: Builder, source: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'm not sure if RUST_BACKTRACE=full pixi shell is helpful:
thread 'main' panicked at crates/pixi_utils/src/reqwest.rs:99:10:
failed to create reqwest Client: reqwest::Error { kind: Builder, source: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } }
stack backtrace:
   0:     0x7fd7f21e23e9 - <unknown>
   1:     0x7fd7f1638990 - <unknown>
   2:     0x7fd7f21a7a72 - <unknown>
   3:     0x7fd7f21e636e - <unknown>
   4:     0x7fd7f21e5be0 - <unknown>
   5:     0x7fd7f21e6c9b - <unknown>
   6:     0x7fd7f21e66c0 - <unknown>
   7:     0x7fd7f21e6616 - <unknown>
   8:     0x7fd7f21e6603 - <unknown>
   9:     0x7fd7f0f03144 - <unknown>
  10:     0x7fd7f0f036b2 - <unknown>
  11:     0x7fd7f1c0eeb2 - <unknown>
  12:     0x7fd7f0f32286 - <unknown>
  13:     0x7fd7f0f32189 - <unknown>
  14:     0x7fd7f12d6c62 - <unknown>
  15:     0x7fd7f11fba84 - <unknown>
  16:     0x7fd7f1259f44 - <unknown>
  17:     0x7fd7f12117d9 - <unknown>
  18:     0x7fd7f1545001 - <unknown>
  19:     0x7fd7f153fad9 - <unknown>
  20:     0x7fd7f1126573 - <unknown>
  21:     0x7fd7f1547fcb - <unknown

Pixi version 0.26.1 works, but 0.27.0 doesn't.

@apoorvkh I don't think this is the same issue, would you be able to make a new one and add your pixi toml to it aswell. Or find a minimal reproducing pixi.toml?

@partrita Can you share the contents of: C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1 and C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1
And try to run these commands to see if they cause the issue.

I think I might have found a clue. The pixi run command works flawlessly in the Command Prompt (cmd), but it crashes when I try to use it in PowerShell.
$C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1
C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1: The term 'C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

$C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1
C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1: The term 'C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

@partrita Can you share the contents of: C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1 and C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1
And try to run these commands to see if they cause the issue.

I think I might have found a clue. The pixi run command works flawlessly in the Command Prompt (cmd), but it crashes when I try to use it in PowerShell.
$C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1
C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1: The term 'C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\libxml2_activate.ps1' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

$C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1
C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1: The term 'C:\Users\Downloads\rosalind\.pixi\envs\default\etc/conda/activate.d\openssl_activate-win.ps1' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

It seems like we're not activating the right scripts. This is part of the activation workflow in pixi.
I think we need to revisit which scripts are run by pixi on activation.


[V2] Theming doesn't work with reactstrap 4.2.0

Hi everyone,
I have read this very recent article claiming styled-components is the future so I decided to give a try.
I want to to customize my reactstrap app. (React equivalent of Bootstrap 4)
I don't wan't to import the bootstrap css stylesheet. I rather make my own styling based on the class used in bootstrap. This is where styled-components come from! I Hoped...
For some reason, the custom theme passed to the <ThemeProvider theme={theme} /> disappear for the one I've configured in my component Button.defaultProps right after a re-rending due to state change.
I've looked into their Button components and I still wonder, their components are fairly simple.
I have created a webpackbin to demonstrate the issue.
I have also opened an issue on reactstrap: https://github.com/reactstrap/reactstrap/issues/355
According to @TheSharpieOne

Yeah, definitely looks like an issue on styled-components side. ... Seems like Styled(*) shouldn't be passing down the props it uses. [...]
IDK, but looking at this line in styled-components it looks like it only subscribes and doesn't set the initial state based on the [default] props.

Version
styled-components 2.0.0-7
reactstrap 4.2.0
Reproduction
https://www.webpackbin.com/bins/-KetejqQhRZrV5MyzPpr
Steps to reproduce
Click on the button within the reproduction and see.
Expected Behavior
Custom theme to be applied
Actual Behavior
Default theme is applied

I've opened an issue on reactstrap as well : https://github.com/reactstrap/reactstrap/issues/355

Thanks for reporting. Looks similar to #549

Yup, working on similar issues. Any leads would be grateful!

Version
styled-components 2.0.0-7
reactstrap 4.2.0
Steps to reproduce
https://www.webpackbin.com/bins/-Kf5Tdg7bfj2oWZzIb1V
Case A - Button: Click on one of the left buttons to reproduce the issue with the component Button.
Case B - ButtonClass: Click on one of the right buttons to reproduce the issue with the component ButtonClass.
Case C - ButtonBetter: Copy paste ButtonBetter component (as Webpackbin does not support the static keyword), uncomment line 11 // static defaultProps = defaultProps; to reproduce fix.
As you will see, the issue was resolved as follows:
Problematic Case:
const defaultProps = {
  theme: themeBs,
};

class ButtonClass extends React.Component {
...
}

ButtonClass.defaultProps = defaultProps;
export default ButtonClass;

Fixed Case:
const defaultProps = {
  theme: themeBs,
};

class ButtonBetter extends React.Component {
  static defaultProps = defaultProps;
...
}

export default ButtonBetter;

Cause for Fix: moving the defaultProps inside the component and removing the Button.defaultProps = defaultProps;
Logs
Case A:  seem normal:
Case B:  seem normal:
Case C: returns undefined multiple times for ${(props) => console.log('ButtonBetter within styled', props.theme.main)} but magically returns the correct value once.
Expected Behavior
Custom theme to be applied
Actual Behavior
Default theme is applied
Questions

Is there any way to use  static keyword in Webpackbin? Or is there any work around to produce an equivalent results?

Why does the logs for Case C return undefined, rather then correct value?

What will happen to stateless components and styled if we are obliged to define defaultProps within the component? (As it seems that you cannot define the defaultProps inside a stateless component)

Could you please check if this is also a bug in v1?

Ok this is a bug with v2 only. I think I have already fixed that bug in v1 so I will have to search for the PR.

PR does not seem to have been added in v.2, I tested the commit you added in the PR and I confirm that it resolves the issue.
Thanks for that!

Is it possible to refix this ? I can do the PR it's only 5 minutes. :+1:

Should be copy paste. 👍

Many thanks for the fix added in v 2.0.0-9.

Hi guys,
I am using reactstrap (v6.4.0) and styled-components(v5.1.1) and using ThemeProvider to provide theme to all the styled-components in the app. But due to some reason, the theme prop is not available inside the styled-components created inside the reactstrap Tooltip component. Helps appreciated, thanks !


UI: fix cannot open 'Edit tags' modal for static routes

Description
This PR fixes the issue that "Edit tags" dialog cannot be opened for static routes.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)
[ ] build/CI
[ ] test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

How did you try to break this feature and the system with this change?

@weizhouapache a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: :heavy_check_mark:
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/10065 (QA-JID-497)


Attempt to improve error meassage from rustfmt

This PR

prevents printing usage when rustfmt failed due to IO errors. Also adds summary "Format Rust code".
warns when there are unknown configuration options. Currently rustfmt does not emit any warning. Since we have removed and combined many config options, we should explicitly warn these changes to the user. This is not a hard error: rustfmt still formats files even when unknown config options is in rustfmt.toml.

Looks good, thank you!


installing stable torchrec is not working

I'm trying to follow https://github.com/pytorch/torchrec#installation to install torchrec, in particular:
# create new env
with-proxy conda create --name pytorch_torchrec_dlrm
conda activate pytorch_torchrec_dlrm

# install dependencies
with-proxy conda install pytorch cudatoolkit=11.5 -c pytorch -c conda-forge

# install torchrec
with-proxy pip install torchrec

# hello world
python
>>> import torchrec
...
  File "/home/vasiliy/local/miniconda3/envs/pytorch_torchrec_dlrm/lib/python3.10/site-packages/torch/_ops.py",
line 505, in __getattr__
    raise AttributeError(
AttributeError: '_OpNamespace' 'fbgemm' object has no attribute 'jagged_2d_to_dense'

# full trace: https://gist.github.com/vkuzo/e4e4608f34d090f3e935632fd644b0b9

I got the same error when trying to install torchrec against a locally built PyTorch master (1.14.x).  Is this a KP?  Any suggested workarounds?

@vkuzo we've tested the new (0.3.0) torchrec with the new pytorch (1.13) and it works on our side.
Are you installing locally build pytorch? it looks like you are installing via conda
with-proxy conda install pytorch cudatoolkit=11.5 -c pytorch -c conda-forge

I see the same error whether I install torchrec against local PyTorch (v1.14.x) or a conda installation of PyTorch (v1.13.0).
Do you think trying to locally build torchrec would help?
I also see jagged_2d_to_dense existing in fbgemm master, maybe it's some kind of version mismatch with torchrec + fbgemm?

@vkuzo , I can't repro your issue. When using locally built pytorch or the latest torch, I'm able to use and import torchrec fine.
can you check which fbgemm-gpu you are using? (try showing pip list)?
Can you try

import fbgemm_gpu
import torch
torch.ops.jagged_2d_to_dense
<module 'torch.ops.jagged_2d_to_dense' from 'torch.ops'>

Thanks for helping!
Here is the output of running pip list and trying to run your code snippet: https://gist.github.com/vkuzo/9f1994f813803b31ed1078d20a27d34a
(pytorch_torchrec_dlrm<EMAIL_ADDRESS>~]$ pip list | grep fbgemm-gpu
fbgemm-gpu         0.3.0
(pytorch_torchrec_dlrm<EMAIL_ADDRESS>~]$ python
>>> import fbgemm_gpu
libc10_cuda.so: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "/home/vasiliy/local/miniconda3/envs/pytorch_torchrec_dlrm/lib/python3.10/site-packages/torch/_ops.py",
...
  File "/home/vasiliy/local/miniconda3/envs/pytorch_torchrec_dlrm/lib/python3.10/site-packages/fbgemm_gpu/_fbge
mm_gpu_docs.py", line 18, in <module>
    torch.ops.fbgemm.jagged_2d_to_dense,
  File "/home/vasiliy/local/miniconda3/envs/pytorch_torchrec_dlrm/lib/python3.10/site-packages/torch/_ops.py",
line 505, in __getattr__
    raise AttributeError(
AttributeError: '_OpNamespace' 'fbgemm' object has no attribute 'jagged_2d_to_dense

@vkuzo got it, thanks
it looks like this is an issue with fbgemm_gpu, do you mind creating an issue https://github.com/pytorch/FBGEMM/issues
It also looks like you're pip installing on an internal devgpu, Is it possible that the environment isn't clean?

It also looks like you're pip installing on an internal devgpu, Is it possible that the environment isn't clean?

Yes, devgpus are the wild west.  I did create a fresh conda environment for this torchrec installation, but something system wide could definitely be messed up.  I verified that the pip command I used was conda's pip, which installs things locally to the active conda env.
FWIW, I unblocked myself today by doing the following:
# install cuda 11.7 (previously the system had 11.0, 11.4, 11.5)
with-proxy conda install cudatoolkit=11.7 -c nvidia
# install pytorch nightly for cuda 11.y7
with-proxy conda install pytorch pytorch-cuda=11.7 -c pytorch-nightly -c nvidia
# verify pytorch is working with cuda 11.7 by inspecting env logs and looking for cuda
python -m torch.utils.collect_env
# reinstalling fbgemm-gpu didn't work, so I built it from source
with-proxy pip uninstall fbgemm_gpu
with-proxy git clone --recursive https://github.com/pytorch/FBGEMM.git
cd FBGEMM/fbgemm_gpu
with-proxy python setup.py develop
# interestingly, the version displayed was 0.1.1, which is lower than the official v0.3.0
Processing dependencies for fbgemm-gpu==0.1.1
Finished processing dependencies for fbgemm-gpu==0.1.1

# test, now it works
python
>>> import fbgemm_gpu

With the evidence above, I'd guess that the original problem could have been due to:
a. the nightly pytorch I was using was cpu only (because conda didn't have a pytorch with cuda for cuda v11.0|v11.4|v11.5).  Still not sure why it didn't work for locally built pytorch, since that was compiled with cuda v11.4.
b. perhaps something in fbgemm doesn't support cuda v11.4
Thanks for helping debug, closing this since it looks like it's related to fbgemm and not torchrec


Fix anchor name quoting

To have possibility in plugins to set anchors:
anchor myanchor quick
or
anchor "myanchor/nested" quick
Quoting of anchor name is auto-fixed if slash exists in anchor name.

something looks off here even in the code that we have... why does it matter how this is quoted? what do we do here that is not desired?

or is this about the attribute "quick" being mishandled?

man pf.conf:
Optionally, anchor	rules can specify packet filtering parameters using
the same syntax as	filter rules.  When parameters are used, the anchor
rule is only evaluated for	matching packets.  This	allows conditional
evaluation	of anchors, like:
   block on $ext_if all
   anchor spam proto tcp from any to any port smtp

So, there are many different additional parameters can be with anchor.
Simplest solution is to make quoting in right way.

but the quoting is done to prevent this, a safety measure as you will, because we only ever intended to pass the name. if we want to do it right, we can't simply pass the string as is... what happens on "\n" ? are we going to inject other rules after a newline?

I think that plugins subsystem is developers area. It is not place, where strings goes to configuration from web-interface. If developer wants to break system, he can do it.
I thought that there is synthax check here for anchor name quoting.

The question is simple... how much flexibility do you need? We don't have to change the world in one day. If you only use quick here, we should add support for quick.
We don't want to restrict -- we want to provide safe constraints to develop within. For everthing else there is pf.conf. Because if not, these cases will bite us back during support hours. The developer who "broke" it will be gone, but someone else will have to find out what went wrong and users won't know how to debug. And if we support verbatim strings who does the validation of the rule syntax in them? Can we be sure the rules can't be manipulated by the user in a bad way through a config field on the GUI that allows adding unintended side effects to this?

Yes, I need only quick parameter.

does this work for you? f4acddb

Franco, it's good. Merge ancor_quick branch and delete my pull-request.

@evbevz thanks, done :)