keras.ops.shape doesn't support input with unknown dimension

keras.ops.shape doesn't support input with unknown dimension with torch and tensorflow backend. jax backend is ok. the following code can reproduce the problem. please support input with unknown dimension for keras.ops.shape.
from os import environ
#environ['KERAS_BACKEND'] = 'tensorflow' # FAIL
#environ['KERAS_BACKEND'] = 'torch' # FAIL
environ['KERAS_BACKEND'] = 'jax' # OK
import keras as k

def Test():
   inputs = k.Input((None, 3))
   shape = k.layers.Lambda(lambda x: k.ops.shape(x))(inputs)
   return k.Model(inputs = inputs, outputs = shape)

import numpy as np
inputs = np.random.normal(size = (1,10,3))
outputs = Test()(inputs)
print(outputs)

the pure tensorflow implement has no such problem.
import tensorflow as tf

def Test():
   inputs = tf.keras.Input((None, 3))
   shape = tf.keras.layers.Lambda(lambda x: tf.shape(x))(inputs)
   return tf.keras.Model(inputs = inputs, outputs = shape)

import numpy as np
inputs = np.random.normal(size = (1,10,3))
outputs = Test()(inputs)
print(outputs)

Can you paste the full trace here?

tensorflow:
Traceback (most recent call last):
  File "/home/xieyi/test.py", line 14, in <module>
    outputs = Test()(inputs)
  File "/home/xieyi/test.py", line 9, in Test
    shape = k.layers.Lambda(lambda x: k.ops.shape(x))(inputs)
  File "/home/xieyi/anaconda3/lib/python3.9/site-packages/keras/src/utils/traceback_utils.py", line 123, in error_handler
    raise e.with_traceback(filtered_tb) from None
  File "/home/xieyi/anaconda3/lib/python3.9/site-packages/keras/src/layers/core/lambda_layer.py", line 97, in compute_output_shape
    raise NotImplementedError(
NotImplementedError: Exception encountered when calling Lambda.call().
```

torch:

```shell
Traceback (most recent call last):
  File "/home/xieyi/test.py", line 14, in <module>
    outputs = Test()(inputs)
  File "/home/xieyi/test.py", line 9, in Test
    shape = k.layers.Lambda(lambda x: k.ops.shape(x))(inputs)
  File "/home/xieyi/anaconda3/lib/python3.9/site-packages/keras/src/utils/traceback_utils.py", line 123, in error_handler
    raise e.with_traceback(filtered_tb) from None
  File "/home/xieyi/anaconda3/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/home/xieyi/anaconda3/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
    return forward_call(*args, **kwargs)
NotImplementedError: Exception encountered when calling Lambda.call().
```

Hi @breadbread1984 ,
I have replicated the reported behaviour and attached the gist here for reference. With jax backend the code works fine but with torch and tensorflow raising the error as reported

@breadbread1984 ,
Thank you for reporting the issue.
The core of the issue is that keras.ops.shape is not a normal op in the sense that it doesn't return a tensor. Instead, it returns a tuple containing ints for known dimensions. keras.ops.shape(x) is just a way to write x.shape in a way that works across backends. In that sense keras.ops.shape(x) and tf.shape(x) are really not the same, which I agree is very confusing.
One easy way to fix the issue is to add convert_to_tensor (this fixes both TensorFlow and Torch):
shape = k.layers.Lambda(lambda x: k.backend.convert_to_tensor(k.ops.shape(x)))(inputs)

As far as TensorFlow is concerned, it's actually not the unknown dimensions that are the issue, the issue is the known dimensions (because of the way that unknown dimensions are supported). If you change the input to k.Input((None, None)), it actually works with TensorFlow (not Torch).
def Test():
   inputs = k.Input((None, None))
   shape = k.layers.Lambda(lambda x: k.ops.shape(x))(inputs)
   return k.Model(inputs = inputs, outputs = shape)

import numpy as np
inputs = np.random.normal(size = (1,10,3))
outputs = Test()(inputs)

That being said, I have a fix for TensorFlow that should make your code work as-is. I will report back.

OK thx for the solution

That being said, I have a fix for TensorFlow that should make your code work as-is. I will report back.

Any update on this? I also have a dynamically sized model with input-shape (None, None, 3) that requires tf.shape ops at some point. Migrating this model from TF/Keras2 to Keras3 still seems to be an issue.
Keras 3.3.2 doesn't handle the aforementioned construct:
inputs = k.Input(shape=(None, None, 3), dtype=np.float32)
shape = k.layers.Lambda(lambda x: k.ops.shape(x))(inputs)

# raises NotImplementedError:
#   "We could not automatically infer the shape of the Lambda's output.
#   Please specify the `output_shape` argument for this Lambda layer."

The k.backend.convert_to_tensor solution suggested by @hertschuh also raises the same error.

@pwuertz ,
I tested with Keras 3.3.2 and this works with the Tensorflow backend and the JAX backend:
import keras as k
import numpy as np

def Test():
     inputs = k.Input(shape=(None, None, 3), dtype=np.float32)
     shape = k.layers.Lambda(lambda x: k.ops.convert_to_tensor(k.ops.shape(x)))(inputs)
     return k.Model(inputs = inputs, outputs = shape)

inputs = np.random.normal(size=(1, 2, 10, 3))
outputs = Test()(inputs)

In this case, you do need the convert_to_tensor. Can you confirm this also works for you?

Oh right, this indeed works with Tensorflow. I guess my notebook jumped over to the torch backend earlier, which still raises the NotImplementedError.
... which is still somewhat of an issue for me because Keras 2 to 3 also breaks tf2onnx.convert.from_keras  and taking the multi-framework route using torch.onnx.export as an alternative doesn't work due to this bug / missing feature.
I think what we're really asking for here is some sort of k.layers.Shape operator akin to tf.shape or ONNX Shape?

@pwuertz ,
A changed was just pushed that fixes the code above for Torch. Can you confirm this works for your ONNX export?

I think what we're really asking for here is some sort of k.layers.Shape operator akin to tf.shape or ONNX Shape?

Hopefully this works now: k.layers.Lambda(lambda x: k.ops.convert_to_tensor(k.ops.shape(x)))

@pwuertz , A changed was just pushed that fixes the code above for Torch. Can you confirm this works for your ONNX export?

Confirmed, this now works in both TF and Torch, thanks!


Update package.json dependencies to latest ones

Current coverage is 77.47% (diff: 100%)

Merging #437 into master will increase coverage by 0.08%

@@             master       #437   diff @@
==========================================
  Files            18         18
  Lines          2083       2193   +110
  Methods         373        373
  Messages          0          0
  Branches        180        180
==========================================
+ Hits           1612       1699    +87
- Misses          471        494    +23
  Partials          0          0

Powered by Codecov. Last update 8a440d7...6c1a19c


[Docs] Updated : Example for adding a new string

Describe the changes you have made in this PR
This PR is dependent on PR #2896.
The purpose of this PR is to update the example in the README file that contains an outdated string.
Type of change

docs: Documentation update

Screenshots of the changes [optional]
The PR #2896 changes "add_account" to  "connect_wallet"

So I have updated the example in README.md for "adding a new string".
Checklist

[x] Update Docs & Guides

@AdarshRawat1 I don't think this is really needed - it's just an example of the syntax of adding a new translation key and value

@rolznz I just thought that the updates should be reflected in examples as well.
( I needed feedback on it )  Thank you for your feedback.


Fire event on robots txt parse complete

I did it but i dont like that i exposed RobotsDotText with Robots, to do in better way i wold probably need to change a bit more code. Let me know what you think

Looks good. I'll be able to take a closer look in the next few days and hopefully get it integrated soon. Thanks!

The build failed because the PoliteWebCrawler.cs file on line 184 you used the new null condition operator "?.". Abot targets .net 4.0 which does not support that feature. Can you change it to regular null check to the build can run? I would do this myself but then you would lose credit for your work on this pull request.

Yes i will fix it today

Besides that i dont like that i have opened IRobots.
I think i will change it a bit _robotsDotTextFinder.Find(uri); should return IRobots and than from it RobotDotText should be created. Because opening encapsulated field its a bit bad idea.
Any way today will push new changes

Sounds good

To rewrite as i thought it require a lot of thing to change, so i am not sure if should i do that.

Thanks. One of the nicer pull requests I've had. Very clean and I appreciate the tests as well.


Add centimeters

Miles scale goes down to 1 foot while meters scale goes down to 1 meter.
1 foot = 0.3 meters
Therefore the meters scale should go down to 30 centimeters.

Is there maps with such zoom level?

We have maps with such zoom levels. Devices such as those from Trimble have sub-meter accuracy.

Released in com.github.pengrad:mapscaleview:1.4.2


hello, is it possible to add more algorithms, if so, how

hello, is it possible to add more algorithms, if so, how

Yes, it can, but how to do it, let's look at some examples from these commits.
Yescrypt
https://github.com/xiaolin1579/miningcore/commit/682585f1d63c47af893f161ab54ea82a6dfe6bea
X16rt
https://github.com/xiaolin1579/miningcore/commit/928c8cc0c62c64fc225ff177b381c290ad7be332

Hi, thanks for the info, I'll check it out

ocv2

is someone able to add kheavyhash? is it similar like heavy hash?

Hello, it's quite a lot of work, if anyone has a modification for any algorithm, please post it here or send it to<EMAIL_ADDRESS>thank you


iPad: Column setting doesn't stick

See this thread: https://forum.newsblur.com/t/column-layout-setting-on-ipad-doesn-t-stick/9322

I can't reproduce this. If I change the column view mode then exit the app (whether by going home or force quitting), when I re-launch the app, it is in the chosen mode.
iOS saves preferences periodically, including when exiting the app. Even force quitting does so, since that exits to the app switcher. (And people shouldn't force quit anyway.)
The only way I can get it to not save the choice is if I re-run the app from Xcode immediately after changing the option, which wouldn't let any preference be saved. And not something users can do.
Can you repro it? Or get more info?

User came back with a repro:

Here’s how to reproduce it on the iPad:
Set Column layout preference to 3. Test it to make sure it works. This means when you tap a story, you continue to see all 3 columns — feeds, stories, and the story you selected.
Quit NewsBlur.
Open NewsBlur. Even though Column layout is set to 3, it acts like it’s set to 2. The feeds column disappears when you view a story. You have to reset the preference for it to work again.


[BUG]: Uploading a csv file fails

Describe the bug
Uploading a csv from file spits out errors (see screenshot).
To Reproduce
Steps to reproduce the behavior:

Download this dataset: Go to '...'
On the Overview page, click the Upload resources button
Select dataset you downloaded and click Import
The upload button is broken but the file seems to load anyway (issue https://github.com/DARPA-ASKEM/Terarium/issues/1196)
Click cancel and click on the dataset to open it
It does not open and spits out a bunch of errors (see screenshot)

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

These CORS issues have been resolved and files now upload.  Once uploaded you are taken back to the over view page for a project.
There are still some issues around file size, but, an error message now shows correctly to the user.


feat(@vtmn/react): adds boolean to disable VtmnTooltip when needed

Changes description
This PR adds a boolean isTooltipDisabled to the VtmnTooltip component to be able to disable or not the tooltip.
The boolean has a false value by default.
Context
We needed this change in order to display or not the tooltip when a button is active or not.
https://github.com/Decathlon/vitamin-web/issues/1192
Checklist

[x] Make sure you are requesting to pull a topic/feature/bugfix branch. Please, don't request directly from your main!
[x] Check commits & PR names matches our requested structure. It must follow the https://www.conventionalcommits.org pattern.
[x] Check your code additions will fail neither code linting checks.
[x] I have reviewed the submitted code.
[x] I have tested on related showcases.
[x] If it includes design changes, please ask for a review with a core team designer.

Does this introduce a breaking change?

No

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

Hi @MaelthiS,
Thanks for your proposition.
I have to close it thanks to my explanation here: https://github.com/Decathlon/vitamin-web/issues/1192#issuecomment-1167217698
Thanks for your understanding.


change settings interface

addresses #1383
$ mise settings
  List all settings

$ mise settings a
  Get the value of setting with name 'a'

$ mise settings a=b
  Set setting with name 'a' to 'b'

I think it would be simpler if the setting value is a separate argument instead of using =? This is how git config works. - mise settings set x value

@camsteffen I want to support both styles, but this matches how mise set works for consistency

Sorry I meant mise settings x value. Would that work?

ah yeah, that could be done I think

closing due to inactivity, feel free to reopen if you'd like to work on it more


merge from konsum-frontend-svelte,template-svelte-app

package.json

chore(deps): add ^10.18.1 remove ^10.18.0 (devDependencies.npm-pkgbuild)

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

npm package (@latest dist-tag)
v1.35.0
GitHub release

Your semantic-release bot :package::rocket:


Support for merge operation in omnisci engine

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Modin installed from (source or binary):
Modin version:
Python version:
Exact command to reproduce:

Describe the problem

Source code / logs

https://github.com/intel-go/modin/pull/7 - this contains current changes for the task

Initial implementation is in omnisci-on-ray branch


Wait for kube-system service account to be created

Along with waiting for kube-system namespace to be created, we should also wait for kube-system service-account to be created to avoid errors like this:
Error creating assets: error when creating "/home/core/assets/manifests/kube-rescheduler.yaml": pods "rescheduler-v0.2.1" is forbidden: service account kube-system/default was not found, retry after the service account is created

Where in the bootstrap process does this wait need to occur? I tried inserting a check, which seems to work on the single-node setup, but causes it to hang forever on the multi-node setup.
My understanding is that a default service account should be created automatically for the kube-system namespace, but I wasn't sure if I needed to wait for the related ClusterRoleBinding to be created as well?

I haven't run into this lately so safe to assume its resolved now.


Keyboard Keys

What do these values correspond to?  Are they ASCII values?  Are they keyboard codes?  Are they platform specific?
How would I go about making a comma a code to separate the tags?
Any help would be appreciated!  Thanks!

Hi @sspringer! They correspond to keyboard keys. See https://css-tricks.com/snippets/javascript/javascript-keycodes/

Thanks!  That's what I needed!

Cool:)


Power Management with ESP-NOW (IDFGH-10467)

Is your feature request related to a problem?
I have a problem with the power consumption of the ESP32-C3 used in the light bulb. I am using only ESP-NOW communication. The power consumption is currently 0.66 watts, and we need to go below 0.5 watts (EU and CE requirements). Unfortunately, ESP-NOW does not release the WiFi module and
APB_FREQ_MAX for WiFi is 100%. Experiments with
esp_now_set_wake_window() and
esp_wifi_connectionless_module_set_wake_interva() reduce consumption, but cause frequent non-responses.
Describe the solution you'd like.
Can you @Espressif-liuuuu suggest any solution? How to optimally choose the parameters of Power Manager? Now I use max CPU 80 MHz and min 10 MHz and allow Light Sleep

hi @MacWyznawca , thanks for your report.
There is no time syncronizing for ESPNOW yet, so there is do some packet loss if you use power-save for ESPNOW.
And we have to do ESPNOW powersave before lightsleep. Actually we shall release RF at frist, which by calling esp_now_set_wake_window and esp_wifi_connectionless_module_set_wake_interval, then we are able to enter lightsleep.
For your request, the quickest way is to adjust the window paramater to about 70% of interval parameter, e.g 70ms for window and 100ms for interval. In that case, the packet loose mayby OK and the power consumption meets the requirement also.

OK, that's how I wanted to experiment. I will probably have to adjust the retransmission times.
Please, write me more @Espressif-liuuuu, will ESP-NOW be developed/maintained? Because we are doing a big smarthome system entirely based on ESP-NOW and TWAI. In addition, we plan to base the design of the next system implemented for 4-6 years on this.

Thanks @Espressif-liuuuu
Now we need to run a test. We have an elaborate communications system based on ESP-NOW with pairing, proprietary encryption, ACK and forwarding of packets. So far tested with ~100 simultaneously operating devices transmitting a dozen or so packets per second.
I'll report how progress with power saving or ask for support 😉

hi @MacWyznawca , thanks for your report.
There is no time syncronizing for ESPNOW yet, so there is do some packet loss if you use power-save for ESPNOW.
And we have to do ESPNOW powersave before lightsleep. Actually we shall release RF at frist, which by calling esp_now_set_wake_window and esp_wifi_connectionless_module_set_wake_interval, then we are able to enter lightsleep.
For your request, the quickest way is to adjust the window paramater to about 70% of interval parameter, e.g 70ms for window and 100ms for interval. In that case, the packet loose mayby OK and the power consumption meets the requirement also.

After I set these two, I still get ESP_ERR_NOT_SUPPORTED during esp_sleep_enable_wifi_beacon_wakeup()  or esp_sleep_enable_wifi_wakeup() at my ESP32 DevKit board. Is esp_sleep_enable_wifi_wakeup() only for Wifi connected state?

Hi @dpr-0 I use for ESP-NOW only:
esp_wifi_connectionless_module_set_wake_interval(interval) // interval = ex. 100
and
esp_now_set_wake_window(window) // window = ex 56 for ESP32-C or 90 for old ESP32
and proj. setting: CONFIG_ESP_WIFI_STA_DISCONNECTED_PM_ENABLE=y
Power used on my device (Bulb) with ESP32-C3 droped from 0,6 to 0,48 W (measurewd in main power 230 V)

I use ESP-NOW only too, so you still can receive ESP-NOW data during light sleep just based-on settings above? Is esp_sleep_enable_wifi_wakeup() actually not needed?

I for init use only this code:
static void LuAirRadio_init(void){
    wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_wifi_init(&cfg));
    ESP_ERROR_CHECK(esp_wifi_set_storage(WIFI_STORAGE_RAM));
    ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));

    ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
    ESP_ERROR_CHECK(esp_wifi_start());

    esp_wifi_set_ps(WIFI_PS_NONE); // WIFI_PS_MAX_MODEM

    ESP_ERROR_CHECK(esp_wifi_set_protocol(ESP_IF_WIFI_STA, WIFI_PROTOCOL_LR | WIFI_PROTOCOL_11B | WIFI_PROTOCOL_11G)); // WIFI_PROTOCOL_11B | WIFI_PROTOCOL_11G | WIFI_PROTOCOL_LR
    ESP_ERROR_CHECK(esp_wifi_set_max_tx_power(_curentPower));
    ESP_ERROR_CHECK(esp_wifi_set_channel(_curentChannel, WIFI_SECOND_CHAN_NONE));
    ESP_ERROR_CHECK(esp_now_init());

    esp_now_peer_info_t *peer = malloc(sizeof(esp_now_peer_info_t));
    if (peer == NULL) {
        ESP_LOGE(LUAIR_TAG, "Malloc peer information fail");
        LuAirDeinit();
        return;
    }
    memset(peer, 0, sizeof(esp_now_peer_info_t));
    peer->channel = 0;
    peer->ifidx = ESP_IF_WIFI_STA;
    peer->encrypt = false;
    memcpy(peer->peer_addr, broadcastMac, ESP_NOW_ETH_ALEN);
    ESP_ERROR_CHECK(esp_now_add_peer(peer));
    LuPlatformMemoryFree(peer);

    ESP_ERROR_CHECK(esp_now_register_send_cb(LuAirSend_cb));
    ESP_ERROR_CHECK(esp_now_register_recv_cb(LuAirRecieve_cb));
    ESP_ERROR_CHECK(esp_wifi_connectionless_module_set_wake_interval(100));
    ESP_ERROR_CHECK(esp_now_set_wake_window(60));
}

I use ESP-NOW only too, so you still can receive ESP-NOW data during light sleep just based-on settings above? Is esp_sleep_enable_wifi_wakeup() actually not needed?

Yes it didnt. its for wifi station mode & connected & internal use for lightsleep. For ESP-NOW only, its not needed.

Pnow? I really need to achieve

Hi, @0x0fe. thanks for your report.
There is indeed no direct way for promiscuous RX mode to sleep, since RF is essential if you want to receive some packet.
If the sleep time is long, like you mentioned
I try to monitor all channels during about 1200ms (100ms per channel) and then deep sleep 20 second
How about disable promiscuous RX mode or call esp_wifi_stop before you sleep? Thats the quickest way to achieve the logic.
Please let me know if any issue in that solution. Thanks!

@Espressif-liuuuu
Hi,
I was hoping for a mode to reach a better current in promiscuous RX only mode, but after checking the datasheet i realize 84mA is the minimum expected current for RX operation.

How about disable promiscuous RX mode or call esp_wifi_stop before you sleep? That's the quickest way to achieve the logic.

Well, during the sleep phase (20 second) i enter in deep sleep mode and i reach the expected deep sleep current : 7 uA at 5V (before the LDO). By the way, esp_wifi_stop is unnecessary, it is probably called by the deep sleep API.
The 24mA i have seen in light sleep is in fact when the radio is disabled, which explains the jumps around 80 when i switch channel.
Is there another ESP32 variant that could reach a more reasonable RX current in promiscuous mode? Other generic wifi SoCs reach 34mA and down to 14mA for ultra low power wifi socs.

@Espressif-liuuuu Hi, I was hoping for a mode to reach a better current in promiscuous RX only mode, but after checking the datasheet i realize 84mA is the minimum expected current for RX operation.

How about disable promiscuous RX mode or call esp_wifi_stop before you sleep? That's the quickest way to achieve the logic.

Well, during the sleep phase (20 second) i enter in deep sleep mode and i reach the expected deep sleep current : 7 uA at 5V (before the LDO). By the way, esp_wifi_stop is unnecessary, it is probably called by the deep sleep API.
The 24mA i have seen in light sleep is in fact when the radio is disabled, which explains the jumps around 80 when i switch channel. Is there another ESP32 variant that could reach a more reasonable RX current in promiscuous mode? Other generic wifi SoCs reach 34mA and down to 14mA for ultra low power wifi socs.

Rx current of ESP32C2 can be 65mA. Sorry that it cant achieve so low Rx current for ESP32 now, but we will have that type of chips in the future.

@Espressif-liuuuu OK, it is clear, thank you for the information.


compact: Verify for chunks outside of compacted time range. Added unit test for populateBlocs.

Rationales:

No "outside" chunks should happen.
No clear view what happens for various compact input.

NOTE: This PR should be merged after: https://github.com/prometheus/tsdb/pull/348
Signed-off-by: Bartek Plotka<EMAIL_ADDRESS>

why not open the PR against his branch BenoitKnecht:fix-block-boundaries so he can merge and both will get in at the same time.

time for a rebase and a review :)

ping @bwplotka

@bwplotka  gentle reminder :stuck_out_tongue_winking_eye:

Thanks @krasi-georgiev for helping out!


CHORE: Update actions to use aurora-care-bear

Thanks for submitting a pull request!
We will review it as soon as possible.

Hey @0xWDG,
Thanks for your contribution.
Your PR has been merged!
Your name will appear on https://auroraeditor.com/#contributors in a few moments, if you have contributed to the editor.
Thanks again for your contribution!
Kind Regards,
Aurora Editor Team.


Problems with aqueduct commands after flutter upgrade

I cannot use the following aqueduct commands after upgrade flutter to v1.25.0-8.3 with Dart version 2.12.0 on beta channel:

aqueduct serve (reported on this issue)
aqueduct db generate

To launch aqueduct server I have been using dart bin/main.dart command to run my specifications defined on main.dart file and it works. But I can't find any way of generate a new database without aqueduct db generate command.

@cmalbuquerque same here. I am also not able to run aqueduct db generate

I found a solution if you want to continue using the beta channel. Although I think that's a bad practice, it works!

switch to flutter stable channel
develop the data model
execute aqueduct db generate in order to create a migration
execute aqueduct db upgrade
switch again to flutter beta channel

I am using Postgres database and I also had to add dependency overrides in pubspec.yaml file:
dependency_overrides:
  postgres: ^2.1.1

As I mentioned above, this is a temporary solution and I think this problem must be solved ASAP because there are those who need to use the beta channel's features!

@cmalbuquerque Thanks.. let me try this solution

you need to install Dart for your machine, not use dart flutter, flutter executes his own dart version

I had same problem and I found the solution at is on
https://github.com/stablekernel/aqueduct/issues/946

First I create a path (/user/****/.pub-cache/bin) for flutter dart.
So every time I update stable version my path always see the dart path.
Than I use “dart pub global activate aqueduct” to get aqueduct.
Now its working perfectly.

@cmalbuquerque  Hello!
I switched to the  lutter stable channel, tried to run  aqueduct db generate, but got the  following error:

Any suggestion?
Thanks in advance!

Hi @SzAttila97!
Try to run flutter upgrade before aqueduct db generate to ensure you have the latest version.

Hey! @cmalbuquerque !
After that, I got kinda the same error, but with different version in the error message. 😥

@SzAttila97 try to run flutter clean before aqueduct db generate and make sure that your flutter version in pubspec.yaml file is the same version than your flutter channel

@cmalbuquerque
Done, but got the same error, im so confused!

@SzAttila97 I have no idea how to solve your problem. Check this issue on flutter's repository that mentioned the same error.

@cmalbuquerque
Alright, thanks anyway.
By the way the method you mentioned at the beggining of the post (changing the channels) still working for you?
Or maybe there was some changes connected with the channels?


:ArduinoVerify executing job failed: Permission denied

Hello, I'm beginner of vim using SpaceVim with WSL
I want to use SpaceVim for arduino so i installed this plugins
But :ArduinoVerify gave me error

and this is my vimrc

when i sudo screen /dev/ttyS15 115200, in my vimrc, i got a whole black window and there is no respond except terminating command
------------------------------------------------------------------Edit------------------------------------------------------------------
i solved No such file or directory error but...
i installed Arduino in wsl by copying my arduino in window and try :ArduinoVerify

and :make command also got error like:

so i tried chmod 777 Arduino but it didn't work

If there is something i miss, please help me
and i'm sorry for pool English
thank for your help

I have never tried doing Arduino development on Windows, and I have no idea how well accessing a hardware device inside of WSL will work, but I can give you some general debugging tips.
You can run :ArduinoInfo to get some useful information about the plugin. One of the things it will tell you is the "Verify command", which is the shell command that is run when you do :ArduinoVerify. You can copy that command and run it directly in your terminal, and it may give you a better idea where the permission error is coming from.


Added arabic description to the inventory challenge

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

✨ Awesome! Congratulations on your first contribution to freeCodeCamp! ✨
Thank you for submitting a PR for this issue, @Aiden-aiden . We're all really looking forward to your next contribution.


aoa_to_sheet() crashes browser if you pass an array of objects

I know you're not supposed to do this, but if you pass an array of objects into aoa_to_sheet() it gets stuck in an infinite loop.
E.g.
XLSX.utils.aoa_to_sheet([{"hello": "world"}]);
// RIP your chrome tab X_X

JSfiddle
Might be good to throw an exception in this situation ;)

The function assumes an array of arrays is passed in.  The infinite loop comes from the inequality check in https://github.com/SheetJS/js-xlsx/blob/master/bits/27_csfutils.js#L104 -- when you pass an object like {hello: "world"}, length is undefined and the loop doesn't terminate.
The fix is to make a check just before that line:
--- a/bits/27_csfutils.js
+++ b/bits/27_csfutils.js
@@ -101,6 +101,8 @@ function sheet_add_aoa(_ws/*:?Worksheet*/, data/*:AOA*/, opts/*:?any*/)/*:Worksh
                if(_R == -1) range.e.r = _R = _range.e.r + 1;
        }
        for(var R = 0; R != data.length; ++R) {
+               if(!data[R]) continue;
+               if(!Array.isArray(data[R])) throw new Error("aoa_to_sheet expects an array of arrays");
                for(var C = 0; C != data[R].length; ++C) {
                        if(typeof data[R][C] === 'undefined') continue;
                        var cell/*:Cell*/ = ({v: data[R][C] }/*:any*/);

(@mnori feel free to submit this as a PR)

Browser main thread is blocked for 30 mins to process array of array to sheet --> UI froze.. any ways to fix this ?


bug(material/datepicker): Voiceover Loses Focus when pressing Page Down key

When navigating the calendar with VoiceOver enabled, pressing Page Down causes the screenreader focus to move to the entire calendar, instead of stay on an individual date.
Reproduction
Steps to reproduce:

With Screenreader enabled, Open the datepicker expands in a browser and navigate to the Basic Datepicker Demo.
Click on the Calendar button to open the datepicker
navigate to January 28, 2022
(VoiceOver reads "January 28, 2022". the cell for Jan 28, 2022 has blue focus outline and black voiceover outline
Press PageDown
(VoiceOver reads "February, 2022". The Cell for Feb 28, 2022 has blue focus outline. Voiceover's black outline is around the entire box. Voiceover should ready "February 28, 2022".

Expected Behavior
Voiceover reads "February 28, 2022".
Actual Behavior
voiceover reads "February, 2022"
Environment
Operating System | macOS Monterey 12.1 (21C52) Browser | Chrome Version 97.0.4692.99 (Official Build) (x86_64) Screenreader | VoiceOver
https://user-images.githubusercontent.com/7720245/152051557-abb11c7d-3b66-43b7-bd1a-41c517cab896.mov
Additional Notes
This is copied from an internal bug report found during a11y testing.

@Splaktar I'm stumped on this one. I'm curious if you've come across anything similar to this? This seems vaguely familiar to problems we've had with setting focus and screenreader announcements when opening dialogs?
My current theory, is that VoiceOver gets confused when the focused element is removed from the DOM, which causes it to focus on the entire table.

After talking to @crisbeto , looks like the aria-live region is interfering with announcing the calendar body. I'll keep looking into this...

It sounds like you are on the right track. I don't think that I recall any problems (or solutions) to something similar.


[BUG] Failing curl_install spec tests

Describe the bug
Curl install spec tests are failing, when running them (individually or via command crystal spec).
To Reproduce
crystal spec
or
crystal spec ./spec/curl_install_spec.cr
Expected behavior
All curl_install spec test should pass.
Screenshots

Device (please complete the following information):

OS Linux
Distro Ubuntu
Version 22.04
Architecture x86
Crystal 1.11.1
Kubernetes v1.28.3

How will this be tested? aka Acceptance Criteria (optional)
For verification successfully running crystal spec ./spec/curl_install_spec.cr should be enough.
Additional context
Add any other context about the problem here.

This is failing due to the repo URL change. We got updates coming that are combined with the current fix for CI/CD github runner fixes.

@macaktom @agentpoyo
Fixed by PR #1883


Predicate#eql?(left, right) breaks lots of conventions

Describe the bug
It's not my code breaking so I'm just describing it from the outside:
~/gems/dry-logic-1.1.0/lib/dry/logic/predicates.rb:181:in `eql?': wrong number of arguments (given 1, expected 2) (ArgumentError)
from /usr/local/ruby/lib/ruby/3.0.0/set.rb:247:in `include?'
from /~/gems/tapioca-0.5.4/lib/tapioca/compilers/dsl/base.rb:33:in `handles?'

Just based on the error and backtrace, I believe defining eql? is a bad idea because it's a method used by lots of low-level code, for checking ~identity~ "hash equality".
I believe it would be best if that method was renamed (or at least behaved like Object#eql? when called with a single argument).

To add more context on this issue, the failure was in the Tapioca gem that I co-maintain. The gem does a lot of runtime introspection on constants in memory, so ends up running into these kinds of cases.
For the time being, we've worked around the problem by using compare_by_identity! but dry-logic would be a much better community member if it didn't break common expectations like eql?.

This, along with renaming Predicates.respond_to?, should go into 2.0.0 release

@casperisfine @paracycle thanks for reporting this and explaining the context. I'm responsible for this unfortunate name and even though I was perfectly aware of the fact that it overrides a core method, I naively thought to myself "it shouldn't cause issues in case of a module, right?". Since nobody complained for years, I never reconsidered this.
I'm sorry that it's taking so long to address but this is not a trivial task as it needs to go through deprecation phases in dry-logic and dry-schema as it uses this predicate.
In #98 I am addressing the rename and the deprecation here. Then I will follow up with deprecation/rename in dry-schema.
The final fix, which is of course removing this predicate completely, will happen in 2.0.0s of both dry-logic and dry-schema.
In an intermediate release, I'll point to this issue and explain that it might be a good idea redefine this method in your code "just in case" and use is_eql? from now on.
I will close this issue after the final removal is done in 2.0.0. We'll be releasing it before the end of the year, if things go well, if not - early 2023.
Stay tuned 🙂

Just a short update that I ended up tweaking eql? to work like Object#eql? when just one arg is passed so it should work now in dry-logic 1.5.0.


chore: upgrade operator-sdk to 1.35

What type of PR is this?
/kind cleanup
What does this PR do / why we need it:
This PR updates operator-sdk version from 1.32.0 to 1.35.0.
Have you updated the necessary documentation?

[ ] Documentation update is required by this PR.
[ ] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
Test acceptance criteria:

[ ] Unit Test
[ ] E2E Test

How to test changes / Special notes to the reviewer:

/retest

We are not using internal in this either?

We are not using internal in gitops-operator either?

No @saumeya, as per last discussion with you and @svghadi, AFAIR we decided not to make changes to the controllers, as it might affect if other projects are using this repo as dependency.
@svghadi, @iam-veeramalla WDYT?

Yes, let's avoid moving to the internal/ directory structure for now. We can re-evaluate this decision during the refactoring efforts if needed.

/lgtm
/approve


Use sycl::ext::oneapi::experimenta::printf

This avoids some compiler errors on the testbeds that have already been reported.

This avoids some compiler errors on the testbeds that have already been reported.

What compile error?

What compile error?

https://github.com/intel/llvm/blob/7589ac9dbb6c85525766b874f894388598211e07/sycl/include/sycl/handler.hpp#L678-L689

Are you saying the current master is broken?

Are you saying the current master is broken?

Yes, with some compiler versions.


[test-infra][e2e] make sure to test until the latest DiemVersion

This is a rebase of #8460 just that I didn't know how to commandar the existing PR..

/land


Update the file-tree based way of showing the directory structure in the README.md files of the course modules

Used the file-tree-generatorextension of VS code in order to update the file-tree based way of showing the file structure of the course modules.
@Elkinmt19

Everything was updated gratefully!!!


fix: allow adaptation_notes

This should allow #adaptation_notes in Mathlib code.

It was a deliberate choice, but I also think that it was not correct!  I had forgotten what the script did: matching for the end-of-line is more robust, although actually inconsequential.
Anyway, I added the $ back, since I think that it is better like this.
Thanks!

maintainer merge


fix(source): change kafka "offset" to be left inclusive and right exclusive

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Previously what we stored to start_offset field in KafkaSplit metadata is actually "last seen/consumed offset", and this had two problems:

When scan.startup.timestamp.millis is set, we have to subtract 1 from the offset derived from the given timestamp.
When initializing a Kafka reader, we have to add 1 back to the offset.

When these are mixed with Kafka low/high watermark, the code became very hard to understand and correctly maintain.
This PR gives the start_offset and stop_offset concepts a clear definition, i.e. when start to consume from Kafka, start_offset represents the first offset to read (inclusive), stop_offset represents the last offset to read PLUS 1 (exclusive). The new definitions match the low/high watermark definition in Kafka, so hopefully can be more intuitive.
To include some background of other XxxSplit structs (https://github.com/risingwavelabs/risingwave/pull/16256#discussion_r1560705754):

IMO we should +1 if possible when update_offset (unfortunately some source platforms don't allow simply doing addition on offset), that's in my mind the most elegant and clear solution. But in our current actual implementation, we have 3 cases:

+1 when creating reader (Kafka), will be fixed in https://github.com/risingwavelabs/risingwave/pull/16257
Set offset to AfterSequenceNumber(last_seen_offset) (Kinesis), correct and exactly once.
Read from last_seen_offset on recovery, meaning duplicated items (Debezium CDC). The duplication seem unavoidable, see https://debezium.io/documentation/reference/stable/development/engine.html#_handling_failures.

Checklist

[x] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#16257  👈
#16256
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @stdrc and the rest of your teammates on  Graphite

but I think it is not worthy introducing the complexity distinguishing the behavior because the kafka split reader has limited behaviors, reading from beginning, from a timestamp, and from latest offset. No more expected behaviors or extensible usage (from rw side and kafka side). Making the code happen to work correctly is enough.
I admit that we did not cover all behaviors well in prev impl and left some bugs. But the actual case is no user finds them. So I wonder just fixing the bugs is enough and there is no need for a new schema. What do you think?

Don't you feel uncomfortable when seeing so many confusing -1 and +1 in the code?

Also, the changes to KafkaSplit in this PR are actually making KafkaSplit more consistent with other XxxSplit. That is, making the start_offset real start offset. You can check KinesisSplit and CdcSplitBase, you will find that the start_offset in them is really the start offset when starting to read from the source on recovery. For the latter Debezium CDC case, it reads duplicated item and that is documented.

Also, the changes to KafkaSplit in this PR are actually making KafkaSplit more consistent with other XxxSplit. That is, making the start_offset real start offset. You can check KinesisSplit and CdcSplitBase, you will find that the start_offset in them is really the start offset when starting to read from the source on recovery. For the latter Debezium CDC case, it reads duplicated item and that is documented in Debezium documents.

I understand the improvement and I am up with the overall goal of making rw more maintainable.
My point is that it changes the schema in the state table, no matter whether simple or not, it is a risk and I don't see enough benefits for taking it.
For "maintainability", as you can see in the kafka source enumerator history for the past year, there is no actual logic change. This part is not evolving. This part has done all it needs to do, so I think the ideal way is to fix the bug rather than bring new abstracts and take the compatibility issue.
If there was a chance to design source_v2, I would be happy to bring the proposal to production.

My point is that it changes the schema in the state table, no matter whether simple or not, it is a risk and I don't see enough benefits for taking it.

Does that justify the bug fixed by #16073 which had existed for 2 years, from the 1st day when Kafka source was introduced (https://github.com/risingwavelabs/risingwave/commit/7678f25a769967874ba5802e00027f4a8ca21cd6)?
Or the bug fixed by #6647, in which you found reading from "latest" was not working as expected because we forgot to subtract 1 from the high watermark to construct the "start offset"?
Or #6725 that introduced batch query on Kafka source, in which the following code snippet actually broke the definition of "watermark" in Kafka?
        let mut watermarks = {
            let mut ret = HashMap::new();
            for partition in &topic_partitions {
                let (low, high) = self
                    .client
                    .fetch_watermarks(self.topic.as_str(), *partition, KAFKA_SYNC_CALL_TIMEOUT)
                    .await?;
                ret.insert(partition, (low - 1, high));
            }
            ret
        };

The reason of all these bugs and semantic mismatch is because of the wrongly defined start_offset. As you said, things just barely happened to work. But IMO we need things to confidently work. We need to understand each piece of our code. Although now it seem peaceful, that may be just because some combination of the functionalities are not used by any user (or they just didn't report to us?). Instead of regarding the changes in this PR a "risk", I regard the semantic mismatch a risk, which can potentially cause new bugs or reveal old ones every time we extend or just refactor the module.
Back to this PR, it doesn't introduce any backward-incompatibility. It seamlessly migrate any old KafkaSplit value to fit the new code. Especially for following change pair (migrate existing offset by adding 1, remove +1 when create reader) in happy path, I am personally certain that the changes are correct.
--- a/src/connector/src/source/kafka/source/reader.rs
+++ b/src/connector/src/source/kafka/source/reader.rs
@@ -110,7 +110,7 @@ impl SplitReader for KafkaSplitReader {
                 tpl.add_partition_offset(
                     split.topic.as_str(),
                     split.partition,
-                    Offset::Offset(offset + 1),
+                    Offset::Offset(offset),
                 )?;
             } else {
                 tpl.add_partition(split.topic.as_str(), split.partition);

--- a/src/connector/src/source/kafka/split.rs
+++ b/src/connector/src/source/kafka/split.rs
@@ -22,8 +22,44 @@ use crate::source::{SplitId, SplitMetaData};
 pub struct KafkaSplit {
     pub(crate) topic: String,
     pub(crate) partition: i32,
+
+    /// The offset pointing to the first message to read from the partition. Inclusive.
     pub(crate) start_offset: Option<i64>,
+    /// The offset pointing to the next position of the last message to read from the partition. Exclusive.
     pub(crate) stop_offset: Option<i64>,
+
+    /// The version of the split metadata. `None` means version 0.
+    version: Option<u32>,
+}
+
+/// The current version of the split metadata.
+/// Please increment this version and write a migration script below when you make a change to
+/// the split metadata.
+const CURRENT_VERSION: u32 = 1;
+
+static MIGRATION_SCRIPTS: &[fn(serde_json::Value) -> serde_json::Value] =
+    &[/* 0: 0 -> 1 */ migration::v0_to_v1];
+
+mod migration {
+    pub fn v0_to_v1(mut value: serde_json::Value) -> serde_json::Value {
+        // In v0, the `start_offset` field represented the last seen offset, which means when
+        // initializing a reader from the split, we should add 1 to the offset. But in the case
+        // of timestamp offset, it happened that we forgot to subtract 1 from the offset
+        // when creating `KafkaSplit`, causing the first message to be missed.
+        // See https://github.com/risingwavelabs/risingwave/issues/16046 for more.
+        //
+        // In v1, we normalize the `start_offset` field to represent the first message to read
+        // from the partition. So we need to add 1 to any v0 `start_offset` field. We also
+        // normalize the `stop_offset` field to represent the next position of the last message,
+        // while fortunately, although not documented, the v0 `stop_offset` field was already
+        // representing the next position of the last message.
+
+        let start_offset = value["start_offset"]
+            .as_i64()
+            .map(|start_offset| start_offset + 1);
+        value["start_offset"] = start_offset.into();
+        value
+    }
 }

@stdrc and I had a thorough offline discussion, recognizing the core issue stems from the differing semantics of the start offset during source creation and recovery.
This discrepancy has led to frequent +1/-1 adjustments across Kafka implementations. While this PR aims to standardize the definition of start offset across various connectors, it appears to users as altering the state table's definition.
Currently, the state table's start offset represents the offset of the last confirmed message, but with this change, it would represent the offset for the next message to be fetched, effectively shifting to offset +1 and other connectors stay the same. This creates an inconsistency for users, urging us to find a better solution.

In fact, I am more opposed to the previous PR (renaming last_offset -> last_seen_offset). Commented there: https://github.com/risingwavelabs/risingwave/pull/16256#discussion_r1562234832

Let me clarify the problem with a more concise language.
For KafkaSplit and also some other such XxxSplits, the start_offset field has two different semantics in the following two situations:

When a split struct is created by Enumerator, the start_offset means the offset of the first message we should read.
When update_offset is called (by SourceExecutor), the start_offset is replaced with a “last seen offset” which is got from the stream chunk returned by Reader.

This semantic mismatch is the key problem.
Now our Kafka source does work, because we made the semantics in the 1st situation align with the 2nd one, by subtracting 1 from the offset when creating a Split and adding 1 to the offset when creating/recovering a Reader. However the solution is very counter-intuitive. By its name, the start_offset should’ve store the “start offset” or “next offset”, but it actually stores “last seen offset” or “previous offset”. And that also caused other source implementations to follow the error, because new sources just copied the design from old ones, especially file source, which is acting totally wrong.
I think a more reasonable and intuitive solution should be align the 2nd semantics with the 1st one, which is exactly the way how Flink, Kafka and plenty of other industrial products handle offsets. That is, to be more clear, always storing the “next offset” we should read next time. And this is also the only way that can correctly work for file source.

Let's reopen when the work is resumed 🤫

Let's reopen when the work is resumed 🤫

Sure😁


ci: Add Codecov integration

What

Set up codecov

Right now, this only catches Java code, but could probably be updated to support some JS later, if needed.

I think it might be easier for us to work directly on main until we are close to release?

Probably 😅


Request config not properly handling errors

https://github.com/Modern-Treasury/modern-treasury-go/blob/71cb4608ba9ee66161e540332a071fcbcb8f9aff/internal/requestconfig/requestconfig.go#L189-L197
There is a bug here that the error on line 190 is not properly checked. In the case of context timeout/cancel, it is possible that res is nil and has no headers, which will panic on line 197.
Attaching a screenshot below of debugger state highlighting this issue, and the relevant code block:

t.Run("context error will fail to request client", func(t *testing.T) {
	cancelCtx, cancel := context.WithCancel(context.Background())
	cancel()
	client.Ping(cancelCtx) // this panics instead of returning error
})

The fix for this will be released in 1.4.1: https://github.com/Modern-Treasury/modern-treasury-go/pull/79


reference new testserver

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged

🤖 AutoRest automatic publish job 🤖
> will publish once PR gets merged


the joint pre-train model is not working

I just feel curious about the joint training result and loaded the joint-poolnet model you provided.
I tested on the HUK-IS dataset and the output is not the same as yours, the edges are not correctly predicted.
Seems like the pre-train model is not working.
may get your advices on this?

The predicted saliency and edge maps are directly produced the corresponding pretrained model in the zip file.
Please make sure you have followed the instructions in the README.md file strictly.
From the information provided by you, I have no further suggestions.

finally solved...thanks anyway.
Here I have another question about your training process:
in your dataset.py file
def load_image_test(path):
    if not os.path.exists(path):
        print('File {} not exists'.format(path))
    im = cv2.imread(path)
    in_ = np.array(im, dtype=np.float32)
    im_size = tuple(in_.shape[:2])
    in_ -= np.array((104.00699, 116.66877, 122.67892))
    in_ = in_.transpose((2,0,1))
    return in_, im_size

may i know how to get those numbers np.array((104.00699, 116.66877, 122.67892))?
or say, why do you substract this value?

It's the mean value calculated over channels across the whole ImageNet dataset.
Subtracting the dataset mean aims to "center" the data.
We used this value directly and didn't recalculate the value for the DUTS dataset as the BN layers were trained on the ImageNet and frozen for all our experiments.

Thanks for your explaination and your work for this model!


Websockets not working with fastproxy option

Welcome!

[x] Yes, I've searched similar issues on GitHub and didn't find any.
[x] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?
Hi,
I changed my config to use the new fastproxy option but websockets do not seem to work.
I am using Immich and Homeassistant.
I can access both services, but I get strange logs in Homeassistant and Immich tells me the server is offline.
When deactivating the fastproxy option, everything is working as expected.
What did you see instead?
Access Log for Immich: 400 Bad Request
"GET /api/socket.io/?EIO=4&transport=websocket HTTP/1.1" 400 37 "-" "-" 470 "media-immich-api@docker" "http://<IP_ADDRESS>:2283" 2ms
Nothing found in Access Logs for Homeassistant.
Home Assistant logs:
WARNING (MainThread) [aiohttp.websocket] Client protocols [''] don’t overlap server-known ones ()
What version of Traefik are you using?
v3.2.1
What is your environment & configuration?
fastProxy: {}
If applicable, please paste the log output in DEBUG level
No response

Hey @Silenoz93,
Thanks for the bug report.
We have put it on our (maintainer) plate to reproduce.
We'll keep you updated on this ticket once we have moved froward on it.


linux server will not start since the patch tonight

anyone else having this issue?

This sounds like a duplicate of #778

It is - fault was due to Wildcard messing up linux binaries. They fixed within 20minutes with a hotfix.


Update SDK with secure tunneling deadlock fix

Update SDK to release v1.15.4.
The SDK release includes the crt commit e3ea832 which fixes deadlock when secure tunnel sends multi-frame messages.

Motivation

Customers reported issues sending large files using secure tunneling.

Modifications
Change summary

Customers of device client should regard the commit on this PR as the permanent fix and replacement for the emergency patch issued in device client commit 7755cfc.

The patch to the crt included in device client is also removed as part of this PR.

Testing

This change is tested by transferring files of size 1, 10k, 20k, 30k, 100k, 1M between destination and source and comparing checksums of the files on both the destination and source after transfer is complete.
Additional unit tests for the change are also added to the PR submitted to fix the bug in the aws-c-iot library.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hey @marcoemorais-aws , please update SDK version in the docker files.
https://github.com/awslabs/aws-iot-device-client/blob/main/.github/docker-images/ubuntu-16-x64/Dockerfile#L60


Language selector missing languages

Looks like hebrew, indonesian, and at least two more are not listed (clicking on them does change the language settings for the content though
Tested on Android App 2020-04 Build:6200950

Tested again with latest zim (2023-01-01) and language defaults to device's default, so not sure the issue is entirely valid (except that the app should be updated, of course).

@Popolechien works for me, please forve refresh browser and put screenshot with url of library.kiwix.org.

@kelson42 As indicated looks like the issue is on the Android app - so either with Android itself or the old zim. I'll close.


chore: throw error with duplicated destination labels

Overview
This PR addresses issue #295 and aims to fulfill the feature requests made by @erhant and @Philogy.
Proposed Changes

Implement a contract-wide label uniqueness check.
Newly defined labels are validated against a hashset to ensure no duplication occurs across the entire contract.
Duplicated label definitions will throw ParserErrorKind::DuplicateLabel(String).

Caveats

test_erc721_compile currently fails due to non-unique labels (error and cont) in huff-examples/erc721/contracts/ERC721.huff.
To resolve this, the labels in ERC721.huff should be renamed for uniqueness.

Impact

This change ensures label uniqueness across the entire contract, preventing potential bugs related to label name collisions.
A decision is needed on renaming labels in ERC721.huff to ensure all tests pass with the new label uniqueness constraints.

Hey, thank you for doing this!

This is good stuff and I will likely merge it and I can see it follows the approach of the duplicate_macro methods introduced recently!

Although while reviewing this I have come to the attention of a bug in the implemention of both of them. Such in this implementation, as modules are implemented naively, it is not possible for inherited huff contracts to share any label names.

A robust solution to this would require namespacing the labels, which is a larger task

I see, that makes total sense! That feature feels more advanced but i could give it a go.
Besides throwing an error if there is a duplicated label within a namespace, if we were to go that route, how would you handle a scenario such as this one? https://github.com/huff-language/huff-rs/issues/295#issuecomment-1745064630

I definitely think the compiler should raise an error here, duplicate label definitions should not be allowed. Huff also won't throw an error if you accidentally declare a duplicate label as so:
#define macro A() = takes(0) returns(0) {
    first:
        sub
}

#define macro B() = takes(0) returns(0) {
    first:
        add
}

#define macro MAIN() = takes(0) returns(0) {
    A()
    B()
    first jump
}

would u raise an out-of-scope error as the user would be trying to invoke a jumpdest for a label which had been defined in another macro (namespace)?

As suggested by @iFrostizz on discord, I’ve removed the labels hashmap and moved towards caching labels directly within the Contract struct.
Will try to work on the label namespacing over the weekend.


fix: check if err is nil

Codecov Report

Merging #21 into master will increase coverage by 0.34%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #21      +/-   ##
==========================================
+ Coverage   63.88%   64.22%   +0.34%
==========================================
  Files          15       15
  Lines         623      629       +6
==========================================
+ Hits          398      404       +6
  Misses        183      183
  Partials       42       42

Impacted Files
Coverage Δ

writer.go
90.9% <100%> (+1.11%)
:arrow_up:

Continue to review full report at Codecov.

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


python27Packages.jug: 1.6.9 -> 2.0.0

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/python2.7-Jug/versions.
meta.description for python27Packages.jug is: "A Task-Based Parallelization Framework"
meta.homepage for python27Packages.jug is: "https://jug.readthedocs.io/"

Quoted meta.homepage for RFC 45

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.0.0 with grep in /nix/store/z55nz09j9imh0m5mxrzc2s7x0b2zm7vq-python2.7-Jug-2.0.0

directory tree listing: https://gist.github.com/e52eea0d70aa30de095b59b5034e06b8

du listing: https://gist.github.com/2eae502df506a3adcc2b7698280aeb21

Rebuild report (if merged into master) (click to expand)

12 total rebuild path(s)
3 package rebuild(s)
3 x86_64-linux rebuild(s)
3 i686-linux rebuild(s)
3 x86_64-darwin rebuild(s)
3 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
python27Packages.jug
python37Packages.jug
python38Packages.jug

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/z55nz09j9imh0m5mxrzc2s7x0b2zm7vq-python2.7-Jug-2.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python27Packages.jug https://github.com/r-ryantm/nixpkgs/archive/5d9266266d60d2182129f8378731c292c312f1d6.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/z55nz09j9imh0m5mxrzc2s7x0b2zm7vq-python2.7-Jug-2.0.0
ls -la /nix/store/z55nz09j9imh0m5mxrzc2s7x0b2zm7vq-python2.7-Jug-2.0.0/bin

cc @luispedro for testing.

LGTM


The pretrained Chinese model can not process audio file with 48khz sample rate

Here is the worker.log
2020-08-03 06:30:54 -    INFO:   __main__: Opening websocket connection to master server 2020-08-03 06:30:54 -    INFO:   __main__: Opened websocket connection to server 2020-08-03 06:30:54 -   DEBUG:   __main__: <undefined>: Got message from server of type <class 'ws4py.messaging.TextMessage'> 2020-08-03 06:30:54 -    INFO:   decoder2: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Initializing request 2020-08-03 06:30:54 -    INFO:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Started timeout guard 2020-08-03 06:30:54 -   DEBUG:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Checking that decoder hasn't been silent for more than 10 seconds 2020-08-03 06:30:54 -    INFO:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Initialized request 2020-08-03 06:30:54 -   DEBUG:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Got message from server of type <class 'ws4py.messaging.BinaryMessage'> 2020-08-03 06:30:54 -   DEBUG:   decoder2: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Pushing buffer of size 8000 to pipeline 2020-08-03 06:30:54 -   DEBUG:   decoder2: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Pushing buffer done 2020-08-03 06:30:54 -   ERROR:   decoder2: (GLib.Error('GStreamer encountered a general stream error.', 'gst-stream-error-quark', 1), 'gstwavparse.c(1684): gst_wavparse_stream_headers (): /GstPipeline:pipeline0/GstDecodeBin:decodebin/GstWavParse:wavparse0:\nStream claims av_bsp = 192000, which is more than 96000 - invalid data') 2020-08-03 06:30:54 -    INFO:   decoder2: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Resetting decoder state 2020-08-03 06:30:54 -   DEBUG:      ws4py: Closing message received (1000) '' 2020-08-03 06:30:54 -   DEBUG:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Websocket closed() called 2020-08-03 06:30:54 -   DEBUG:   __main__: 4e4cad05-9440-4aaf-9bc7-27ed656d5a7b: Websocket closed() finished    DEBUG 2020-08-03 06:31:01,885 Starting up worker
I wonder do I need to resample the audio file to 16khz?

yes, you do.


Perform accessibility enhancements

According to the Accessibility Evaluation conducted at We.js website link , taking into account WCAG 2.0 guidelines, the following adjustments need to be performed:
WCAG 2.0 Level A

[x] Add lang='en' attribute to the <html> tag. It's needed to inform to screen readers the natural language of the website content; theme
[x] Add and make revision of alternative (ALT) text in images. The ALT text should be relevant,  concise and represent the image content or meaning that is relevant to the context; core - we-plugin-file
[x] Add missing attribute for to form <label>, specially at Login and Register pages; html - we-plugin-form
[x] Add a unique <title> for each We.js page, following W3C/WAI guidelines; code
[x] Add a skip to content link at the beginning of pages. This link skip the navigation menu and header, jumping to the main content; theme
[ ] Add ARIA landmark roles for header, search, menu, footer and aside content. theme

WCAG 2.0 Level AA

[x] Add heading titles (<h1>) for pages that are missing them, such as Plugins and Themes;
[x] Make focus visible for form fields;
[x] Improve error messages, specially on form pages; code
[ ] Add ARIA roles, states and properties to page elements; html
[x] Improve color contrast between elements background and foreground colors; html
[ ] Provide a high contrast mode. html and code

:+1:

i am working with a new image selector for solve: Add and make revision of alternative (ALT) text in images. The ALT text should be relevant, concise and represent the image content or meaning that is relevant to the context

@talitapagani Accessibility Evaluation Report 1 online and avaible in: http://wejs.org/public/project/aer-1/public-website-of-wejs-framework-and-wejs-events-evaluation-report.html

@albertosouza Thanks! I'm going to work first on the other items related to Level A compliance.

Hi @talitapagani , you can send an example of accessibility menu?
Like this go to content link.

Skip content on in we.js site for cluster theme:

very good good


Add support for Torus and Squarelink

Should be just a matter of dropping in a few lines but was seeing errors for an eth address changing mid-login which was throwing the "Switched eth" address error which disrupts the login process

Hi, what seems to be the problem here? Can we help in any way?


Thrax 11 Publish thrax to Sonatype

This PR is an attempt at Mavenizing Thrax with the attempt of having an artifact which can be pushed to Maven Central.
Essentially this PR does exactly that however it also does not correctly compile due to API changes within the most recent version of [jerboa|https://github.com/vandurme/jerboa/]. In particular the Classes which are affected are
edu.jhu.thrax.hadoop.distributional.CommonLSH
edu.jhu.thrax.hadoop.distributional.ContextWritable
edu.jhu.thrax.hadoop.distributional.DistributionalContextReducer

@mjpost can you take a look at the APi changes and potentially implement them correctly as i am not sure what is going on.

@lewismc, we're pulling Thrax into Joshua as part of the multi-core move, so that will enable an easy Maven push (joshua-thrax). Sound okay to close this out?

Sure does @mjpost that would have been my preference. Thanks @mjpost

This build has been completely converted to Maven, slf4j-over-log4j has been implemented and all forbidden API's calls have been addressed however it is not ready to be merged into master yet as

No one has fully tested it yet, and
I get the following broken tests

Failed tests:   getLabel_NoConstCatCCG_returnDoubleCat(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<B+D+F> but was:<-11>
  getLabel_UnaryChain_Top(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<A> but was:<-2>
  getLabel_NoConst_returnCat(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<B+D> but was:<-10>
  getLabel_NoConstCat_returnCCG(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<A/D> but was:<-12>
  getLabel_UnaryChain_Bottom(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<B> but was:<-4>
  getLabel_UnaryChain_All(edu.jhu.thrax.extraction.SAMTLabelerTest): expected:<A:B> but was:<-13>
  numLeaves_Leaf_isOne(edu.jhu.thrax.syntax.ParseTreeTest): 0
  internalNodesWithSpan_Single(edu.jhu.thrax.syntax.ParseTreeTest): expected:<B> but was:<-2>
  internalNodesWithSpan_unaryChain(edu.jhu.thrax.syntax.ParseTreeTest): expected:<A> but was:<-1>
  leaf_ChildIterator_isEmpty(edu.jhu.thrax.syntax.ParseTreeTest): 0
  tree_ChildIterator(edu.jhu.thrax.syntax.ParseTreeTest): expected:<b> but was:<6>
  numNodes_Leaf_isOne(edu.jhu.thrax.syntax.ParseTreeTest): expected:<1> but was:<0>
  alignedSentencePair_simple(edu.jhu.thrax.util.io.InputUtilitiesTest): expected:<foo> but was:<1>
  getWords_PlainWords_ReturnsStringArray(edu.jhu.thrax.util.io.InputUtilitiesTest): expected:<[Ljava.lang.String;@60addb54> but was:<[I@3f2a3a5>
  parseYield_UnbalancedLeft_ThrowsException(edu.jhu.thrax.util.io.InputUtilitiesTest): (..)
  parseYield_UnbalancedRight_ThrowsException(edu.jhu.thrax.util.io.InputUtilitiesTest): (..)
  parseYield_Whitespace_ReturnsZeroLengthArray(edu.jhu.thrax.util.io.InputUtilitiesTest): malformed parse
  alignedSentencePair_reversed(edu.jhu.thrax.util.io.InputUtilitiesTest): expected:<bar> but was:<2>

Tests run: 47, Failures: 18, Errors: 0, Skipped: 0

@mjpost is there work going on elsewhere to Mavenize Thrax? I jsut re-read your message above... which may indicate that the work has been completed elsewhere. I hope to god that this is not the case and this PR has and is time well spent.

I'll wait for your reply here before continuing to investigate the tests.


Fe homework 7

Drift -> https://video.drift.com/v/abF6OyvrHH8GmCOMyD5Bm1rVxSpwUN1eT0aS2257hj4/
I'm not able to take screenshot because upon taking screenshot, both screens automatically got refreshed. So, I have explained everything in drift video

Metric
Value

alert_status
:white_check_mark: OK

bugs
0

code_smells
2

reliability_rating
A (0 Bugs)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


⚠ Jenkins Plugins Artifactory has degraded performance

In b4824be, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1419 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 08eadc8 after 22 minutes.


[EventRequest] Codeunit 5631"FA Jnl.-Check Line" OnBeforeCheckJobNo

For our cTrade solution we are in need of a new Event so we can skip the TestField on "Job No."
Code change:

Event:

Thank you.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


cf push fails when you have a read only js file bigger than 64KB

When do a cf push to run.pivotal.io with a JS file that is 65KB or greater using the Windows 64 bit CF CLI:

version 6.12.2 works (cf version 6.12.2-24abed3-2015-07-15)
version 6.12.4 works (cf version 6.12.4-b4b6af1-2015-09-18)
version 6.13 FAIL (cf version 6.13-e68ce0f-2015-10-15)
version 6.14 FAIL (cf version 6.14.0+2654a47-2015-11-18)

easy to test, just add a huge comment block to any JS file, set the file to read only and cf push it.
Very strange thing is that the overall size of files does not include the >64KB file.
C:\Test>cf push dev-routetest
Using manifest file C:\Test\manifest.yml
Updating app XXXXXX in org XXXXXX-org / space development as<EMAIL_ADDRESS>OK
Uploading test...
Uploading app files from: C\Test
Uploading 15.9K, 16 files                 <<------------ should be approx 85KB if it included the 70KB js file
Done uploading
FAILED
Error uploading application.
The resource file mode is invalid: File mode '0444' is invalid.

and some additional CF_TRACE output....
REQUEST: [2015-11-19T10:45:46-05:00]
PUT /v2/resource_match HTTP/1.1
Host: api.run.pivotal.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.14.0+2654a47 / windows
[{"sha1":"5836ac31b71d3e0b2a33f169572d5f450cf9a830","size":2238},{"sha1":"8ff8685bc59a7b2beb02f668c00a1d7c1ca3a3b0","size":2700},{"sha1":"3bd06a3c74f2541727913432672eef7f8425fced","size":3384},{"sha1"
:"0","size":0},{"sha1":"20bca42e8a07b9c43c505c7abd5083f0768a7784","size":758},{"sha1":"c1ca55ff04c1b83f73dace7f0aad5be54e2a56e5","size":921},{"sha1":"1fea5a87bf4c7846f6677753b14b3a2de65891ea","size":7
1965},{"sha1":"cae1a9135cd82495054f792a9f10346c7f2d712f","size":1456},{"sha1":"0","size":0},{"sha1":"433d1bd9009730619383ec6ae78301bbe0ce4527","size":196},{"sha1":"d3d790f365b740cb70b217efa64394424783
8d01","size":288},{"sha1":"80ca1bd33edb63967d274ef3397169b04f59129c","size":792},{"sha1":"0","size":0},{"sha1":"60dec8f2f9d44b738b13dd4a28b661cbc558e612","size":100},{"sha1":"dd51ffc8937217898061004e7
7b2a9104a838554","size":476},{"sha1":"a80879a1a1967ce33796378b2b4fabc208a8151a","size":794},{"sha1":"be641dfd35a22db6f1b179cd9c836dab95bf2c75","size":210}]
RESPONSE: [2015-11-19T10:45:46-05:00]
HTTP/1.1 200 OK
Content-Length: 66
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Thu, 19 Nov 2015 15:45:41 GMT
Server: nginx
X-Cf-Requestid: a04ee878-bd3c-4728-64dd-d44b67af8320
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: 207ace22-2ef5-42bd-4ac1-0249814193bb::e19916b1-6256-4042-a83f-953a3c286d89
[{"sha1":"1fea5a87bf4c7846f6677753b14b3a2de65891ea","size":71965}]
Uploading app files from: C:\Test
Uploading 15.9K, 16 files

Hi Brad,
I cannot reproduce the error:
D:\projects\cf\node-bigfile>cf -v
cf version 6.14.0+2654a47-2015-11-18

D:\projects\cf\node-bigfile>dir
 Volume in drive D is DATA
 Volume Serial Number is 3ECB-5B5E

 Directory of D:\projects\cf\node-bigfile

20/11/2015  08:32    <DIR>          .
20/11/2015  08:32    <DIR>          ..
20/11/2015  08:32         7,254,130 app.js
11/06/2014  05:13               156 package.json
11/06/2014  05:13                17 Procfile
               3 File(s)      7,254,303 bytes
               2 Dir(s)  19,298,983,936 bytes free

D:\projects\cf\node-bigfile>cf push big-nodejs-file
<SNIP>
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: big-nodejs-file.a1-app.cf-app.com
last uploaded: Thu Nov 19 21:34:07 UTC 2015
stack: cflinuxfs2
buildpack: node.js 1.5.3

     state     since                    cpu    memory          disk          details
#0   running   2015-11-20 08:34:34 AM   0.0%   49.3M of 256M   40.2M of 1G

D:\projects\cf\node-bigfile>

Even if I use cygwin chmod 0444 app.js to adjust the file's permissions, cf delete and push it works fine.
Is there anything other specific in your environment that could cause a permission error? What other files are in your directory?
About the 15.9K, note that CC caches any files >64K, so the CLI doesn't upload it on a subsequent push. The trace you posted shows that we upload a list of files (well, just size and checksum of each), which includes 71965 byte file, and CC sends back a response with this file (saying it matched a file in its cache, so no need for CLI to upload it again).
Cheers,
Dies Koper
CF CLI PM

Strange.  It happens for me every time.
C:\RouteTest>cf delete dev-routetest
Really delete the app dev-routetest?> y
Deleting app dev-routetest in org removed-org / space development as<EMAIL_ADDRESS>OK
C:\RouteTest>cf push dev-routetest --no-start
Using manifest file C:\RouteTest\manifest.yml
Creating app dev-routetest in org removed-org / space development as<EMAIL_ADDRESS>OK
Using route dev-routetest.cfapps.io
Binding dev-routetest.cfapps.io to dev-routetest...
OK
Uploading dev-routetest...
Uploading app files from: C:\RouteTest
Uploading 67.8K, 16 files
Done uploading
FAILED
Error uploading application.
The resource file mode is invalid: File mode '0444' is invalid.
C:\RouteTest>attrib *.js
A    R       C:\RouteTest\apiserver.js
A            C:\RouteTest\config.js
A            C:\RouteTest\logger.js
A            C:\RouteTest\scratchpad.js
A            C:\RouteTest\version.js
C:\RouteTest>attrib -r apiserver.js
C:\RouteTest>cf push dev-routetest --no-start
Using manifest file C:\RouteTest\manifest.yml
Updating app dev-routetest in org removed-org / space development as<EMAIL_ADDRESS>OK
Uploading dev-routetest...
Uploading app files from: C:\RouteTest
Uploading 67.8K, 16 files
Done uploading
OK
C:\RouteTest>dir apiserver.js
Volume in drive C has no label.
Volume Serial Number is 5621-21A4
Directory of C:\RouteTest
2015-11-20  16:54            82,697 apiserver.js
1 File(s)         82,697 bytes
0 Dir(s)   7,168,012,288 bytes free
C:\RouteTest>cf --version
cf version 6.14.0+2654a47-2015-11-18
C:\RouteTest>

and the changelog for version 6.13 includes 6 changes with the words 'file mode'

Sorry, my bad - I had forgotten to make the file RO with attrib before I started my test.
With attrib +r, I get:
Uploading bog-nodejs-file...
FAILED
Error uploading application.
open d:\projects\cf\node-bigfile\app.js: Access is denied.

We'll investigate.

Hi @bveenvliet:
This change was made as part of the switch to using the new Cloud Foundry runtime, Diego. The file mode must be at least 0600.
For completeness, the original story in the Cloud Foundry API backlog for the feature here, the code that (correctly) returns this error here, and get more information on the Apps API the CLI uses for uploading files here.

I've asked CAPI to change the error message to be more helpful: rather than saying the filemode is invalid, it should describe the solution, which is setting your filemode to at least 0600. When they create a story I'll link it here.

@krishicks @dkoper  Our windows build machine gets latest code from the repository and does a cf push on the files (which have a +R attribute given to them from the source control).  So now there is an extra step turning all of the files > 64KB to make them writable before deploying to Diego.  Would be a cleaner solution if there was a command line arg to ignore file permissions during the cf push.

@bveenvliet That's not something the CLI team can decide.
Perhaps @dieucao, the CF API PM, and/or @ematpl, the CF Runtime Diego PM, can elaborate on why the requirement exists.

Hi Brad,
We've fixed the issue, feel free to download our Edge binary to try until we publish our next cli release.
Regards,
Dies Koper
CF CLI PM

This fix is included in cf CLI release v6.14.1 published today.
https://github.com/cloudfoundry/cli#downloads

Thanks!

Hi I am getting a similar error:
FAILED
Error uploading application.
The resource file mode is invalid: File mode '0551' is invalid.

Read through the comments here, but I am unclear as to what the solution is? WHICH file needs to be in filemode 0600? OR, do I need to install CLI v6.14.1 to resolve? I'm currently on cf version 6.15.0+fa1bfe2-2016-01-13
Thanks.

@CorpusCallosum What platform are you using cf push from? There was a fix done for Windows specifically but a Linux/OS X fix has not yet been released.

Hey @krishicks , thanks for the quick reply. I'm on OSX, do you have any workaround available in the meantime for OSX users?

The easiest thing to do is to chmod all your files, sadly. This is what used to happen automatically when pushing your files; the mode was set to 0744 for all files by default.

Hi, I tried changing file permissions by running sudo chmod -R 744 .
Still getting the same error when I run cfpush however:
FAILED
Error uploading application.
The resource file mode is invalid: File mode '0551' is invalid.

Try find . -type f -perm 0551. Also, read the file manpage for how you can use -perm to search for files with other file modes; 0551 may not be your only problematic file.

Hey Kris, I ran that command and this is the result:
./node_modules/ibm_db/installer/clidriver/adm/db2trc```

So, as you can see, ironically the file that is giving me trouble is the clidriver itself. This is a problem, because although I can change permissions on the file, as soon as I ```npm run cfpush``` the driver get's downloaded again, with the wrong permissions, and causes the push to fail again.

It's a Catch 22! What to do?

Here is the log from the driver download

Downloading DB2 ODBC CLI Driver from http://public.dhe.ibm.com/ibmdl/export/pub/software/data/db2/drivers/odbc_cli/macos64_odbc_cli.tar.gz...
Download and extraction of DB2 ODBC CLI Driver completed successfully ...
CXX(target) Release/obj.target/odbc_bindings/src/odbc.o
CXX(target) Release/obj.target/odbc_bindings/src/odbc_connection.o
CXX(target) Release/obj.target/odbc_bindings/src/odbc_statement.o
CXX(target) Release/obj.target/odbc_bindings/src/odbc_result.o
CXX(target) Release/obj.target/odbc_bindings/src/dynodbc.o
SOLINK_MODULE(target) Release/odbc_bindings.node

That depends on what npm run cfpush is doing. You'd need to change it such that it does the chmod -R prior to running cf push.

Ah yes as it turns out the npm run cfpush was also doing an update, which is why my perms were being overriden. Here is my updated npm script command that got it working for me, in case it help other poor souls:
    "cfpush": "npm prune --production && npm update --production && sudo chmod -R 744 * && cf push cognitive-x-dev && npm update"

Thanks!

This issue is specific to Windows, so it should not be opened. We're also already aware of the problem and have stories to fix it on non-Windows platforms.

@krishicks - Do you have a link to the non-Windows story in PT that you can share?  I searched but couldn't find it.

Set executable bit on all files that are missing it on non-Windows platforms by default: https://www.pivotaltracker.com/story/show/109770364

Also seeing something similar with files in the .git folder:
The resource file mode is invalid: File mode '0444' is invalid.

@matthewford Feel free to submit a new issue with details and we'll take a look. This issue is closed; a new issue is easier to track for us and less likely to get lost.

This issue seems to be related to a problem I recently reported on the Cloud Controller. See https://github.com/cloudfoundry/cloud_controller_ng/issues/1705


Shorten script for contact

Before
After

This is such a good update for usability! Thanks @cselin!


Documentation

Should the second python file be training for the gender?
Download the fer2013.tar.gz file from here
Move the downloaded file to the datasets directory inside this repository.
Untar the file:
tar -xzf fer2013.tar
Run the train_emotion_classification.py file
python3 train_emotion_classifier.py
To train previous/new models for gender classification:
Download the imdb_crop.tar file from here (It's the 7GB button with the tittle Download faces only).
Move the downloaded file to the datasets directory inside this repository.
Untar the file:
tar -xfv imdb_crop.tar
Run the train_emotion_classification.py file
python3 train_emotion_classifier.py

Fixed thank you :)!


packwiz and multimc disabled mods

currently whenever people disable mods in the multimc instance, packwiz just redownloads the mods on launch
i think packwiz should see if the mod has been renamed to have ".disabled" at the end, so that it won't try to redownload the mod

Duplicate of https://github.com/packwiz/packwiz-installer/issues/13


False positive detection of a vulnerability that has been fixed

Problem statement
We have a PR check that is currently failing as it detects there is a vulnerability in the version that is being updated.
This however does not seem accurate, as the version of tj-actions/verify-changed-files is being bumped from 58f5ac78e19e6cc3fb9d4048ae1a13bf364fa983 to 5ef175f2fd84957530d0fdd1384a541069e403f2 (latest commit at the time), while the fix for the mentioned vulnerability (https://github.com/advisories/GHSA-ghm2-rq8q-wrhc) was fixed in a commit previous to both of these 2acec78834cc690f70b3445712363fc314224127.
Given that the pinned sha already has the fix I would expect to not have this vulnerability failure.

@AgustinBettati Thank you for reporting this issue. After spending a bit of time trying to find out how vulnerabilities work in pinned SHAs, I don't think Dependency Review Action has a great answer to offer here. Suppose we have an Action with two commits:

Commit abcd introduces a vulnerability
Commit ef01 fixes the vulnerability

How do we know that version ef01 (or any version really) is more recent than the commit introducing the vulnerability (abcd)? With traditional versioning schemes like SemVer it's easy to tell that 2.0.0 is more recent than 1.0.0 because 2 is greater than 1. Because pinned SHAs do not have this property, we can't tell Action-side if abcd is greater or not than ef01.
I looked into the vulnerability ranges GitHub reports for this Action, and it reports that this vulnerability affects all versions  < 17, so I'm guessing this works fine when using version numbers but not SHAs.
@jonjanego Pinning SHAs is one of the recommended security practices. Do you know if/how Dependency Graph or other supply chain products in GitHub do version comparisons against SHAs to find vulnerabilities?

A bit more triage info:
$ gh api repos/future-funk/congenial-chainsaw/dependency-graph/compare/main...febuiles-patch-2
[
  {
    "change_type": "added",
    "manifest": ".github/workflows/updates.yml",
    "ecosystem": "actions",
    "name": "tj-actions/verify-changed-files",
    "version": "5ef175f2fd84957530d0fdd1384a541069e403f2",
    "package_url": "pkg:githubactions/tj-actions/verify-changed-files@5ef175f2fd84957530d0fdd1384a541069e403f2",
    "license": null,
    "source_repository_url": "https://github.com/tj-actions/verify-changed-files",
    "scope": "runtime",
    "vulnerabilities": [
      {
        "severity": "high",
        "advisory_ghsa_id": "GHSA-ghm2-rq8q-wrhc",
        "advisory_summary": "Potential Actions command injection in output filenames (GHSL-2023-275)",
        "advisory_url": "https://github.com/advisories/GHSA-ghm2-rq8q-wrhc"
      }
    ]
  },
  {
    "change_type": "removed",
    "manifest": ".github/workflows/updates.yml",
    "ecosystem": "actions",
    "name": "tj-actions/verify-changed-files",
    "version": "58f5ac78e19e6cc3fb9d4048ae1a13bf364fa983",
    "package_url": "pkg:githubactions/tj-actions/verify-changed-files@58f5ac78e19e6cc3fb9d4048ae1a13bf364fa983",
    "license": null,
    "source_repository_url": "https://github.com/tj-actions/verify-changed-files",
    "scope": "runtime",
    "vulnerabilities": []
  }
]

The DR API endpoint is wrongly reporting thattj-actions/verify-changed-files at version 5ef175f2fd84957530d0fdd1384a541069e403f2 is vulnerable for the GHSA (it's not). The VVR for this advisory (49560) has the fields fixed: 17, affects: < 17.

@febuiles thank you for the updates here.
From your latest update just wanted to be clear if this might be a bug associated to the specific action (tj-actions/verify-changed-files), or if dependency-review-action lacks support for pinned SHAs altogether and in that case we can transition this to an enhancement request.

@AgustinBettati Sorry for the confusion. There's nothing wrong with the verify-changed-files Action, the issue here is with the GitHub Dependency Review API not being able to infer the proper ordering for all GitHub Actions.

Not sure if this helps, but Dependabot convention is to include a comment of the version after the commit digest. [1]
uses: tj-actions/changed-files@6b2903bdce6310cfbddd87c418f253cf29b2dec9 # v44.5.6

(v44.5.6)
Could we parse comments like that?

I've merged a fix today for the API issue. We should no longer consider pinned shas to be comparable versions.


enhancement/share-messages

This feature shares any messages we receive with all our peers.

This feature shares any messages we receive with all our peers.

Hm, what does this mean more precisely? It isn't scoped by sync id? Does this mean I can just send you a random message and you'll propagate it?

@oskarth its scoped by group, if I recieve a message in group x I will share it with any of my peers in group x

Ok sg

@oskarth are we happy with this actually being merged or do we need any further discussion?


IC-1471: Add tests for Community API

What does this pull request do?
Add tests for Community API and stops it instantiating a new instance of RestClient with each request, as this made it difficult to test.
What is the intent behind these changes?
We didn't have any tests for this, and I'm about to introduce some new functionality to the Community API Service to do things with the Service User address, so wanted to make sure we had some tests in place at least.

nice - does this mean we can remove the token param from the restlclient constructor?

No, we're still using it in the HMPPSAuthClient and the InterventionsService (which we were able to test due to pact doing a lot of mocking for us), but hopefully there'll be time to refactor this later.


[Possible Fix] PICO_DEOPTIMIZED_DEBUG has no effect after first configuration (causes breakpoint issues)

Prefacing that I am new to using CMake and new to using debuggers, so take what I suggest with a grain of salt - but I believe I've identified a bug and a solution to it.
The problem:
In learning how to use picoprobe and VSCode's debugger, I configured a simple project with the Debug config using a minimal CMakeLists.txt that did not explicitly set PICO_DEOPTIMIZED_DEBUG.  When I tried setting a breakpoint on the line:
        gpio_put(PIN_LED, true);

The breakpoint is greyed out in VSCode, delivering the error:

"No line 16 in file "...\main.c"

After a while of searching, it looked like this was a problem with compiler optimizations, so I tried enabling PICO_DEOPTIMIZED_DEBUG, but reconfiguring didn't change any behaviour.  To my surprise, however, deleting the build directory and configuring the project fresh produced the desired results; which got me digging...
Likely cause:
My understanding is that setting CMAKE_${LANG}_FLAGS_DEBUG_INIT specifically only sets the flags for the Debug config the first time it is configured.  This would mean the debug flags get saved to CMakeCache.txt when you initially configure the project, and then all subsequent re-configurations that try to set CMAKE_${LANG}_FLAGS_DEBUG_INIT have no change to the already-cached value.
What this means in this situation (I think) is that whatever PICO_DEOPTIMIZED_DEBUG is set to / defaults to during your first configuration is what will dictate all subsequent debug flags until CMakeCache.txt is deleted.  I believe you can see this being the case by observing how the value of CMAKE_C_FLAGS_DEBUG in CMakeCache.txt does not change after the initial configuration, regardless of changing the value of PICO_DEOPTIMIZED_DEBUG.
Proposed solution:
I think that this section in cmake/preload/toolchains/set_flags.cmake:
    if (PICO_DEOPTIMIZED_DEBUG)
        set(CMAKE_${LANG}_FLAGS_DEBUG_INIT "-O0")
    else()
        set(CMAKE_${LANG}_FLAGS_DEBUG_INIT "-Og")
    endif()

Needs to change to:
    if (PICO_DEOPTIMIZED_DEBUG)
        set(CMAKE_${LANG}_FLAGS_DEBUG "-O0 ${CMAKE_${LANG}_FLAGS_DEBUG}")
    else()
        set(CMAKE_${LANG}_FLAGS_DEBUG "-Og ${CMAKE_${LANG}_FLAGS_DEBUG}")
    endif()

These changes remove _INIT on both commands and append the default debug flags (which is -g in this case, required for proper debugging).  Appending the default flags keeps functional parity with CMAKE_${LANG}_FLAGS_DEBUG_INIT's intended behaviour.
Additionally: What is the reasoning behind defaulting to an optimized debug, if optimizing breaks certain debug functionality?  Perhaps this could be an opportunity to consider making deoptimized debug builds the default for debug builds with PICO_DEOPTIMIZED_DEBUG defaulting to 1 when it is declared, in combination with the above proposed change.
I'd appreciate the eyes of someone who has been familiar with CMake for longer than a single week to validate that this is a real bug and a valid/safe solution.  If this does sound reasonable, I'd be happy to submit a pull request with this simple change 🙂

Pass --fresh when running cmake and it ignores the cache

I'd prefer not to override a core feature of CMake when the solution proposed above addresses the issue directly.
Is there a reason I'm not aware of to preserve the use of CMAKE_${LANG}_FLAGS_DEBUG_INIT, and ask users to overwrite the cache?

No. If have a change to propose, raise a PR.

merged into develop


DocumentFragment is undefined in IE8

I'm trying to make Vue work in IE8. After all the necessary shims and polyfills I'm facing troubles with this line: https://github.com/yyx990803/vue/blob/dev/dist/vue.js#L4774
Is there something to do in this case?

I'm sorry, but Vue will never work in IE8 because there's no way to polyfill Object.defineProperty: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty

I did use these:
https://github.com/es-shims/es5-shim
https://github.com/inexorabletash/polyfill
I'm only having troubles with the DocumentFragment part.

Non of these polyfill can make Object.defineProperty work in IE8 on non-DOM objects, it's just the limitation of the browser. Even if you get past the fragment error it still won't work properly.

:cry:


Fix error message if discovery-url passed in osdf url

From fixing tests I discovered that if we have an osdf url (ex: osdf:///osgconnect/public/osg/testfile.txt) but specify the discovery-url even if it is osg-htc.org, (ex:  osdf://osg-htc.org/osgconnect/public/osg/testfile.txt), we get this failure:
ERROR[2024-01-31T22:15:38Z] Error while querying the Director: 404: No namespace found for path. Either it doesn't exist, or the Director is experiencing problems
ERROR[2024-01-31T22:15:38Z] 404: No namespace found for path. Either it doesn't exist, or the Director is experiencing problems

Instead, we should notify the user that we are using an osdf url and that the specified discovery-url is ignored and move on normally. Doing this because if the user is specifying an osdf url then they should expect to be using osdf functions.

From looking into this, I think I am just going to mark this as closed. It is a very specific case that would be harder to implement than it should be. Just because sometimes users use the /// or // for url's, it's hard to pull out just the hostname and check if that hostname actually is a discovery-url or not. I think this is okay, if one day we get users down the road confused by this, then we can revisit it but for now I do not think it is worth the effort in my opinion.


models(is_pure_julia) stopped working

MWE:
using MLJ, MLJBase
models(is_pure_julia)

TypeError: non-boolean (Missing) used in boolean context

Stacktrace:
[1] filter(::MLJModels.var"#12#14"{Tuple{typeof(is_pure_julia)}}, ::Array{NamedTuple,1}) at ./array.jl:2346
[2] models(::Function) at /Users/julio.hoffimann@ibm.com/.julia/packages/MLJModels/ayF3A/src/model_search.jl:149
[3] top-level scope at In[46]:1

@ablaom consider
julia> using MLJ, MLJBase
julia> is_pure_julia(models()[1])
missing

julia> models()[1].is_pure_julia
false

should be easy to fix

This is not a bug, as explained in our slack correspondence copied below:
The correct syntax is models(m->m.is_pure_julia). The objects filtered by models(...) are not literally model types (to which the is_pure_julia trait function can be applied) because these are not in scope before loading, but named-tuples representing the model metadata (“proxies” for the actual unloaded models). For each bona-fide model trait, the named tuple has a key. If you do models() you get all such named tuples.
See also https://alan-turing-institute.github.io/MLJ.jl/dev/model_search/


Fix logsparse on multiprocess spawn

close #463

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.87%. Comparing base (4575ed8) to head (8e2b973).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

:exclamation:  There is a different number of reports uploaded between BASE (4575ed8) and HEAD (8e2b973). Click for more details.
HEAD has 18 uploads less than BASE

Flag
BASE (4575ed8)
HEAD (8e2b973)

19
1

Additional details and impacted files
@@             Coverage Diff             @@
##            master     #480      +/-   ##
===========================================
- Coverage   100.00%   93.87%   -6.13%
===========================================
  Files           20       20
  Lines         2221     2222       +1
===========================================
- Hits          2221     2086     -135
- Misses           0      136     +136

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Feature/error reporting

Codecov Report

Merging #26 (446af2d) into develop (c93f326) will increase coverage by 0.93%.
The diff coverage is 78.82%.

@@             Coverage Diff             @@
##           develop      #26      +/-   ##
===========================================
+ Coverage    57.47%   58.41%   +0.93%
===========================================
  Files            6        6
  Lines          388      428      +40
  Branches        79       89      +10
===========================================
+ Hits           223      250      +27
- Misses         148      162      +14
+ Partials        17       16       -1


FaceId popup not show when call read()

Hi
I'm build on real iOS device. I can see FaceId popup when i call storage.read() at first time. But i call storage.read() at second times it auto return value from storage without FaceId verification.
So can i force FaceId verification when i call storage.read()

I think my changes in https://github.com/authpass/biometric_storage/pull/70 might resolve this issue but I don't have a device with FaceId support to test it myself.
I've only tested with authenticationValidityDurationSeconds set to > 0 but if it doesn't work for <= 0, I suspect that setting that to 1 second would be a reasonable workaround for all realistic use-cases.
For the record, with the current package version you would most likely find that if you wait for 10 minutes before calling storage.read(), you'll be prompted again. This is because the LAContext is being reused indefinitely but there appears to be a hidden fixed limit of 10 minutes for the validity of the context before iOS decides it needs to re-authenticate. That limit may vary across different iOS versions but definitely is the case in iOS 12 with TouchId.

Thanks for your response.
I'm looking forward new version.

@skyphantomhz same.

Anyone got solution for this?

Facing the same issue here, it works perfectly on android but it has a weird behavior in the iOS
it's been a long time since this issue is opened and yet, no solution??

Is it solved ?