Question about using Grad-CAM

Hello,
Thank you for your great work.
I was trying to use the draw_cam.py script to extract heatmap from results, but there were some errors occured during the experiment, and I do not really understand the problem here:

Traceback (most recent call last):
File "draw_cam.py", line 115, in
draw_CAM(model, img_path, save_path, transform=data_transforms, visual_heatmap=False)
File "draw_cam.py", line 42, in draw_CAM
output.register_hook(extract)
File "/.pyenv/versions/anaconda3-2021.05/lib/python3.8/site-packages/torch/_tensor.py", line 289, in register_hook
raise RuntimeError("cannot register a hook on a tensor that "
RuntimeError: cannot register a hook on a tensor that doesn't require gradient

Could you check the script again and teach me how to solve this problem?
Thank you and best regards.

Hello,
You can try to use heatmap.py to extract heatmap. The script of draw_cam.py may be not work, and I forgot to delete it.

Thank you for your response.
I have one more question about the "Effect of the drone distance to the geographic target" part.
Could you explain about how you divided the dataset into three different parts (Long, middle and short) please?
Thank you and best regards.

I did not divide the dataset. In this experiment.  I use "--scale_test" in test.py and select a fixed image index to denote Long or Middle or Short.  The indxe=0, index=36 and index=54 refer to the long, middle and short respectively.


V1 production build - classnames conflicts

The css class names definitions are duplicated for some components  - in my case it is duplicated (I guess from my debugging) for MuiIconButton and MuiModal - check current behavior

[ x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
The class names should not be duplicated across components.
Current Behavior

My button styles:

The class is duplicated.
Styles definition:

It is working in development mode:
My buttons styles:

and found the definitions:

and from modal:

Steps to Reproduce (for bugs)

I can try to prepare the environment to reproduce the problem but right now I just wanted to report it here.
Context

I'm trying to release my application with the production environment.
Your Environment

Tech
Version

Material-UI
1.0.0-beta.10

React
15.6.1

browser
any

webpack
^3.3.0

I need some hints where may be the problem. I'm not using withStyles solution anywhere - I use styled components for styles overriding.

I have already seen some issue around this problem. It was always linked to duplicated className generator instances. I can't help more without a reproduction.

I'm closing the issue for now as not actionable. Let me know if you have a reproduction example.

@oliviertassinari I was able to reproduce the problem. Here is the webpack bin - https://www.webpackbin.com/bins/-KuO6ia3h-JDpBOJncZ3
In my case, I have 2 application roots which are mounted independently to 2 different div. Both use the same material-ui ThemeProvider wrapped with JssProvider to override insertionPoint from jss.

Based on createGenerateClassName function, you use counter to have unique class names
export default function createGenerateClassName(): generateClassName {
  let ruleCounter = 0;

  return (rule: Rule, sheet?: StyleSheet): string => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.',
      ].join(''),
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

And my screenshot confirms that for some reason the counter is duplicated.
I need help. I don't know what I'm doing wrong right now.

@darkowic You need to share the jss instance between the different react tree. You should be good with such change https://www.webpackbin.com/bins/-KuO6ia3h-JDpBOJncZ3.

@oliviertassinari I think I'm doing it using my custom ThemeProvider
  <JssProvider registry={context.sheetsRegistry} jss={context.jss}>
    <MuiThemeProvider
      theme={context.theme}
      sheetManage={context.sheetsManager}
      {...props}
    />
  </JssProvider>

I wrap my every react tree with this.

This issue should be opened.

Sure, let's sum up what we know so far. This issue arise as soon as you are using multiple react rendering tree. The jss provider is going to create two class name generators, one for each tree. Hence we end up with class name conflicts.
@oleg008 Should we extend the JssProvider from react-jss to accept a class name generator?

WORKAROUND for client-side application: You can create your own createGenerateClassName and move ruleCounter outside the wrapper function
import warning from 'warning';

// Returns a function which generates unique class names based on counters.
// When new generator function is created, rule counter is reset.
// We need to reset the rule counter for SSR for each request.
//
// It's an improved version of
// https://github.com/cssinjs/jss/blob/4e6a05dd3f7b6572fdd3ab216861d9e446c20331/src/utils/createGenerateClassName.js
//
// Copied from material-ui due to issue https://github.com/callemall/material-ui/issues/8223

// This counter is moved outside from `createGenerateClassName` to solve the issue
let ruleCounter = 0;

export default function createGenerateClassName() {
  return (rule, sheet) => {
    ruleCounter += 1;
    warning(
      ruleCounter < 1e10,
      [
        'Material-UI: you might have a memory leak.',
        'The ruleCounter is not supposed to grow that much.'
      ].join('')
    );

    if (process.env.NODE_ENV === 'production') {
      return `c${ruleCounter}`;
    }

    if (sheet && sheet.options.meta) {
      return `${sheet.options.meta}-${rule.key}-${ruleCounter}`;
    }

    return `${rule.key}-${ruleCounter}`;
  };
}

Nice one, we had such a use case on the server and I was already planing to for a bold hint in the documentation see #5
But now you actually found a good reason to support 2 parallel running providers.

We need to research if there are use cases for a strong need of multiple parallel JssProviders. If there are, we need to think of something to support it.

@kof You have just found a use case for a multiple parallel JssProviders. And I think the proposed solution is simple to implement :).

move ruleCounter outside the wrapper function

This will mean that on the server, ruleCounter will never get reseted. We can't do that.

On the server side, the JssProviders definitely needs to support concurrent async rendering of a react tree (strong need). But the current implementation makes it already supported :)

@darkowic Proposed a workaround having no access to the underlying stack. We do. We can do better with this extra flexibility.

Also same request should always respond with same class names.

@kof Should we extend the JssProvider from react-jss to accept a class name generator?

Yeah one possible way would be to allow JssProvider accept a class name generator like this:

import {createGenerateClassName} from 'react-jss'

const generateClassName = createGenerateClassName()

<JssProvider generateClassName={generateClassName}>
  <App1 />
</JssProvider>

<JssProvider generateClassName={generateClassName}>
  <App2 />
</JssProvider>

Another potential option would be to provide some prefix, like an application name. This could work if we assume we don't have unpredictable amount of applications.

<JssProvider classNamesPrefix="app-1">
  <App1 />
</JssProvider>

<JssProvider classNamesPrefix="app-2">
  <App2 />
</JssProvider>

Actually it makes sense to have both props classNamePrefix  and generateClassName. First for debugging, second for automated uniqueness of classnames.

I've ran into this issue via https://github.com/facebookincubator/create-react-app/issues/3173 (and the linked reduced test case).
In my case, a material UI-dependant component (v1.0.0-beta.11) was included into an app that also uses material-ui (same versions). In development, this works fine, but in production the layout is broken due to conflicting class names.
I'm not sure if this qualifies as "multiple react rendering trees" and moving var ruleCounter = 0; before createGenerateClassName() did not workaround the issue, but commenting out the following, did work:
https://github.com/callemall/material-ui/blob/2361339fd6df9bfbb85ed2ee4da9d42ee6fee71c/src/styles/createGenerateClassName.js#L26-L28

Sorry, I couldn't provide more info at the time I opened #7855.😊
This basically covers the issue I faced when running production build.
A workaround for this in the pipeline?

Created a PR which should fix this in react-jss https://github.com/cssinjs/react-jss/pull/155

So let's sum up.

@darkowic's issues root cause is described here: https://github.com/callemall/material-ui/issues/8223#issuecomment-331076580 and will be fixed thanks to @kof's PR: cssinjs/react-jss#155 and a new warning will be added to prevent this situation in the future: #8341.

@tlvince's issue symptoms are the same, but the root cause is different. You are using a single react render tree. It could be linked to a duplicated Material-UI version installed. Check your warnings and if you can figure out exactly what's going on, please open another issue.

@Robophil's issue is too vague to be actionable.

I had the colliding classnames and adding a prefix in createGenerateClassName options solved the problem.
Used the great, comprehensive doc here

@oliviertassinari thanks for the summary!
In a single react render tree, this is most probably cause by different material-ui versions in your build. Make sure to check your dependency tree and check for material-ui versions being used.
yarn list | grep material-ui

My webpack config is as follows
module.exports = {
    entry: {
        FirstComp: path.join(paths.JS, '/components/FirstComponent/MyFirstComp.js'),
        SecondComp: path.join(paths.JS, '/components/SecondComponent/MySecondComp.js'),
    },
}

I have these two components and a common component that is built using the splitChunks option.
I wrapped the default exported component in MyFirstComp and MySecondComp using JSSProvider.
How should I be using the JSSProvider around the common component?

@Sewdn I also think it can be caused by different material-ui versions. This className conflict problem was introduced in my app yesterday when I started to migrate to hooks and the useStyles hook created by makeStyles from @material-ui/styles which is at 3.0.0-alpha.1
Also I was using "@material-ui/core" which is at 3.6.0
Suddenly my app classes and the material-ui classes both started with jss1, counting up in parallel. That would mix everything up. My header for example with jss5 was also styled with the jss5 of let's say MuiListItem.
After following this solution https://github.com/mui-org/material-ui/issues/8223#issuecomment-412349569 by @iamhosseindhv the mui-componts get prefixed with a c and the problem was solved.

@christiaanwesterbeek Are you using the install step correctly? We use dependency injection. It needs to run before all the higher order compnent imports.

@oliviertassinari I'm afraid I don't know what step you are referring to. Also, I don't know what install() is part of and where it needs to be called. I'd be glad to learn more about it, but I need to know where it's documented.

@christiaanwesterbeek I'm referring to https://material-ui.com/css-in-js/basics/#migration-for-material-ui-core-users.

@oliviertassinari Seems that install() should be called in every component's file? I have thought that we just need to call it once in the entry file. Maybe we need a more clear description.

Maybe I'm wrong, install can't resolve conflicts.
To switch from the default style implementation to this newest version, you need to execute the following code before importing any Material-UI's components:
import { install } from '@material-ui/styles';

install();

@oliviertassinari How to install it before importing any Material-UI's components?
importing is always be handled by babel and tsc statically

@oliviertassinari I moved the importing order from
// entry index.js
import * as React from 'react'
import * as ReactDOM from 'react-dom'
import CssBaseline from '@material-ui/core/CssBaseline'
import { install } from '@material-ui/styles'

to
import * as React from 'react'
import * as ReactDOM from 'react-dom'
import { install } from '@material-ui/styles'
import CssBaseline from '@material-ui/core/CssBaseline'

the code reports error Cannot read property 'text' of undefined, if I switch back the importing order, this part works fine.
const useStyles = makeStyles(
  (theme: Theme) => ({
    root: {
      flexShrink: 0,
      color: theme.palette.text.secondary,
    },
  }),
)

@zheeeng

the code reports error Cannot read property 'text' of undefined. By inspecting the theme object, it is empty.

I had the same problem. It was fixed by either upgrading "@material-ui/core" to 3.6.0 or @material-ui/styles which to 3.0.0-alpha.1. I forgot which. Better do both.
However the exact theme that the function passed to makeStyles would receive, was not the theme that I had created with createMuiTheme. Instead it got the default theme. What I ended up doing was to not rely on whatever theme that would get passed. Instead I imported the theme in every file that the styles needed it.

This seems unrelated to this issue (8223) at hand. But here goes anyway. Just import theme and don't rely on it being passed into the function that you pass to makeStyles. And you're done.

Can somebody confirm whether the install step is still required with v3.7.0 ( https://github.com/mui-org/material-ui/releases/tag/v3.7.0 )

Hi, I am using material just for a single input, button and form on my site and I had to use a <JssProvider /> following this comment  https://github.com/mui-org/material-ui/issues/8223#issuecomment-331412432
It's annoying to need this jss provider, is there another fix we can do that would not increase the final build size?

@kopax What are you using JssProvider for?

In production before visiting another route:

In production after visiting a route or in development

Something similar here happens with a form (weird box shadows), we need to visit another page to have the proper css, that happens only in production:

Both issue are fixed if we add JssProvider

I have no idea. I can't help with the provided information.

Everything is broken too. I observe jssXX classes instead of Mui classes for html blocks in production build with CRA.
Can't find the reason yet.

@oliviertassinari perhaps those version number used by<EMAIL_ADDRESS>we are using would help you tell us what's going on:
        "@material-ui/core": "^1.4.0",
        "@material-ui/icons": "^1.0.0",
        "material-ui-chip-input": "1.0.0-beta.6 - 1.0.0-beta.8",

Could you make sure Material-UI is only installed once? Using two versions at the same time could create the same buggy behavior. It might not be this root cause, but it's a possible.

Well. It's possible. We're using react-admin which has recommended version ~1.5.
I solved the bug on production by adding JssProvider. Now I can refresh the page normally.
import React from "react";
import { Admin, Resource } from "react-admin";
import JssProvider from "react-jss/lib/JssProvider";

const App = () => (
  <JssProvider>
    <Admin dataProvider={dataProvider}>
      <Resource name="trip" list={RequestsList} className="resourceItem" />
    </Admin>
  </JssProvider>
);

export default App;

@andrewkslv this is exactly what we are trying to avoid, we'd prefer to use it without JssProvider because we only use one Input and Button component from @material-ui, instead we prefer to use for the rest another ui for react-admin.
@oliviertassinari I've just checked and I did have some dependencies issues. I fixed it but still got the errors with the following npm ls @material-ui/core:
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>
After doing:
rm -rf node_modules/@bootstrap-styled/ra-ui/node_modules/@material-ui/
rm -rf node_modules/ra-ui-materialui/node_modules/@material-ui/
npm ls @material-ui/core
├─┬<EMAIL_ADDRESS>│ └── UNMET DEPENDENCY<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>  └── UNMET DEPENDENCY<EMAIL_ADDRESS>
Then now it does working (no css issue in production) but I guess this is not what I want.
Related project @material-ui dependencies:

@bootstrap-styled/ra-ui/package.json#L293
marmelab/react-admin/package.json

Any idea what to do?

@kopax It's hard to tell without something I can debug. I'm happy to hear it's working now. I have noticed you are using styled-components with Material-UI. If you have some time, I would love to chat about the integration on Gitter.

The working solution isn't natural. Which means it involve task that cannot be run with npm. I will not use it, i gave this as a hint.
We'll have the chance on monday, I'll join the mui gitter channel.

Hi @kopax, did you manage to find a solution?

No not yet. Not without the provider.  @oliviertassinari I am on gitter.

@andrewkslv Your solution really worked for me. I'm also using react-admin  and AWS Amplify. Anytime I would deploy my react application to a S3 bucket, the style would be all broken, and your solution really saved me.

Same issue here. Why adding JssProvider helps?

I have added a warning in v4 to warn when duplicated style instance are used: #15422.

I don't know. I raised this issue in react-admin when they were implementing a new version of material ui to the framework but it was ignored.
https://github.com/marmelab/react-admin/pull/3102#issuecomment-484228320

Where i can find the solution about production build - classnames conflicts #8223 ?
Thanks,

Facing this issue again, even though i have followed all the instructions. Since it is working for others, i guess i might be missing something basic.
https://stackoverflow.com/questions/58938080/jssprovider-not-generating-class-prefix-with-classnameprefix

Thanks @KannugoPrithvi , this is the good solution ! https://material-ui.com/styles/api/#creategenerateclassname-options-class-name-generator


pico_node can't be found and Serial Exception: device reports readiness to read but returned no data

I'm trying to run the example from the README but the pico_node can't be found.
The problems are similar to the post (https://github.com/micro-ROS/micro_ros_raspberrypi_pico_sdk/issues/26) from kappa 95 and I have make sure that my cmake command returns the following when the code is being compiled.
-- Defaulting build type to 'Release' since not specified.
PICO compiler is pico_arm_gcc
PICO_GCC_TRIPLE defaulted to arm-none-eabi
-- The C compiler identification is GNU 9.3.1
-- The CXX compiler identification is GNU 9.3.1
-- The ASM compiler identification is GNU

however, when the code is run the miniterm terminal would receive this SerialException error, where it says the device is ready to read but there is no data returned.

caxas@caxas-Lenovo-ideapad-700-15ISK:~/micro_ros_raspberrypi_pico_sdk/build$ sudo miniterm /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
␀␀␀␀�Exception in thread rx:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 500, in read

--- exit ---
    raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/bin/miniterm", line 445, in reader
    data = self.serial.read(self.serial.in_waiting or 1)
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 509, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read

And of course ros2 node list would return nothing, although the pico is running.
caxas@caxas-Lenovo-ideapad-700-15ISK:~/micro_ros_raspberrypi_pico_sdk/build$ sudo micro-ros-agent serial --dev /dev/ttyACM0 -b 115200
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[1622642059.282302] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1622642062.136104] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 3
[1622642062.136149] error    | TermiosAgentLinux.cpp | init                     | open device error      | device: /dev/ttyACM0, errno: 2
[1622642078.640980] error    | TermiosAgentLinux.cpp | init                     | open device error      | device: /dev/ttyACM0, errno: 1
[1622642079.141126] error    | TermiosAgentLinux.cpp | init                     | open device error      | device: /dev/ttyACM0, errno: 13. Please re-run with superuser privileges.
[1622642079.646925] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1622642080.148194] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 3
[1622642080.149290] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3
[1622642080.149310] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 3
[1622642080.150302] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 3

Assistance on this would be much appreciated. Thanks in advance.

Can you share the output of the micro-ROS Agent with the flag -v6? Do not open the micro-ROS Agent and minicom simultaneously.

Hi pablogs9, this is currently the output I'm getting,
caxas@caxas-Lenovo-ideapad-700-15ISK:~$  docker run -it -v /dev:/dev --privileged microros/micro-ros-agent:foxy serial --dev /dev/ttyACM0 -v6 [1623159026.064243] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 4 [1623159026.064512] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6
In this case only the micro-ROS Agent is being run and nothing else.
The ros2 node list returns nothing so far.
Apologies as well for the late reply, I was away for awhile.

UPDATE
I run the code again and I got this
caxas@caxas-Lenovo-ideapad-700-15ISK:~$ docker run -it -v /dev:/dev --privileged microros/micro-ros-agent:foxy serial --dev /dev/ttyACM0 -v6 [1623159545.762984] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 4 [1623159545.763237] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6 [1623159557.662916] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 4 [1623159557.673038] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159558.677549] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159559.682923] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159560.688567] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159560.911450] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 4 [1623159585.068894] info     | TermiosAgentLinux.cpp | fini                     | server stopped         | fd: 4 [1623159585.069107] error    | TermiosAgentLinux.cpp | init                     | open device error      | device: /dev/ttyACM0, errno: 19 [1623159585.079219] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159586.081590] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159587.085418] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159588.090018] info     | TermiosAgentLinux.cpp | init                     | Serial port not found. | device: /dev/ttyACM0, error 2, waiting for connection... [1623159589.048011] info     | TermiosAgentLinux.cpp | init                     | running...             | fd: 4 [1623159596.696098] info     | Root.cpp           | create_client            | create                 | client_key: 0x49C6B4EB, session_id: 0x81 [1623159596.696221] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x1237759211, address: 0 [1623159596.696411] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 19, data:  0000: 81 00 00 00 04 01 0B 00 00 00 58 52 43 45 01 00 01 0F 00 [1623159597.626446] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159597.626916] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159597.627626] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159597.627897] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159597.805078] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159597.805383] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159598.908706] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159598.908990] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159599.053981] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159599.054265] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159599.233099] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159599.233296] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159599.243502] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159599.243725] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159600.526087] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159600.526296] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159600.585888] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159600.586070] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159600.611094] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159600.611301] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159600.940046] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159600.940288] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80 [1623159601.201070] debug    | SerialAgentLinux.cpp | recv_message             | [==>> SER <<==]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80 [1623159601.201318] debug    | SerialAgentLinux.cpp | send_message             | [** <<SER>> **]        | client_key: 0x49C6B4EB, len: 13, data:  0000: 81 00 00 00 0A 01 05 00 00 00 00 01 80
The peculiar things is I did not change anything in the .uf2 file and I'm running the same command as before.
and I at least can find the node now
caxas@caxas-Lenovo-ideapad-700-15ISK:~$ ros2 node list /pico_node
but the topic called /pico_publisher is not appearing
caxas@caxas-Lenovo-ideapad-700-15ISK:~$ ros2 topic list /image /parameter_events /rosout

Try to use the agent this way:
docker run -it -v /dev:/dev -v /dev/shm:/dev/shm --privileged microros/micro-ros-agent:foxy serial --dev /dev/ttyACM0 -v6

Thank you so much!!! Running the docker with
docker run -it -v /dev:/dev -v /dev/shm:/dev/shm --privileged microros/micro-ros-agent:foxy serial --dev /dev/ttyACM0 -v6
fixed it.
It's running again.


add each new note to the queue

Perhaps you can do something like the Spaced Repetition plugin that uses user-defined tag(s) to indicate which notes are added the the queue.
This would be preferable to adding every note manually to the queue and having every note added the the queue.

For the next release I just added a simple toggle to add all new notes to the default queue, I'll look into tags for the next version.


Set up database and models

User Stories

As a user, I need a database that can store my account, posts, comments, or upvotes

created all models needed for backend using the sqlalchemy ORM


test报错：No module named 'hat'

如何解决
File "d:\hma\hma\archs_init_.py", line 11, in
arch_modules = [importlib.import_module(f'hat.archs.{file_name}') for file_name in arch_filenames]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Anaconda\Lib\importlib_init.py", line 90, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'hat'

Same for me. HAT is another upscaler project. Did author @korouuuuu forget to include it in requirements?

Python 3.8
Dependencies: pip install "numpy==1.21.5" "ipython==7.21.0" "opencv-python==<IP_ADDRESS>" "torch==2.0.1" "torchvision==0.15.2" "einops==0.4.1" "basicsr==1.4.2" (because the recommended basicsr does not compile so I used the latest instead)

Executing with this (path is set because it's the only way HMA can find its own modules):
env PYTHONPATH="$(pwd)" python hma/test.py -opt options/test/HMA_SRx2.yml

Error:
/HMA/.venv/lib/python3.8/site-packages/torchvision/transforms/functional_tensor.py:5: UserWarning: The torchvision.transforms.functional_tensor module is deprecated in 0.15 and will be **removed in 0.17**. Please don't rely on it. You probably just need to use APIs in torchvision.transforms.functional or in torchvision.transforms.v2.functional.
  warnings.warn(
Traceback (most recent call last):
  File "hma/test.py", line 4, in <module>
    import hma.archs
  File "/HMA/hma/hma/__init__.py", line 3, in <module>
    from .data import *
  File "/HMA/hma/hma/data/__init__.py", line 11, in <module>
    _dataset_modules = [importlib.import_module(f'hat.data.{file_name}') for file_name in dataset_filenames]
  File "/HMA/hma/hma/data/__init__.py", line 11, in <listcomp>
    _dataset_modules = [importlib.import_module(f'hat.data.{file_name}') for file_name in dataset_filenames]
  File "/home/johnny/.pyenv/versions/3.8.20/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named 'hat'

Hmm. I noticed that the https://github.com/XPixelGroup/HAT project structure is nearly identical to HMA, and that the requirements are identical. HMA is basically a copy-paste of HAT with some network architecture changes (I guess) and better training. So the solution is simple: Copy-paste the hat directory from HAT's repo to HMA.
In my case, I did this:
git clone https://github.com/korouuuuu/HMA.git
git clone https://github.com/XPixelGroup/HAT.git
ln -srv HAT/hat hma/hat

This gave me progress. Now I have a BasicSR error instead, so I guess I went to too far with my BasicSR version upgrade. :D

Okay I have figured out every problem with this repo:

It needs code from the HAT repo that it was based on. Which for some reason wasn't included here.
The BasicSR package cannot be installed at the same time as Torch. It must be installed AFTER Torch.

To fix all issues, here's my install steps:
pyenv local 3.8
python -m venv .venv
source ".venv/bin/activate"

# Manually install requirements based on cog.yaml since requirements.txt is wrong.
pip install --upgrade pip
pip install "numpy==1.21.5" "ipython==7.21.0" "opencv-python==<IP_ADDRESS>" "torch==2.0.1" "torchvision==0.15.2" "einops==0.4.1"
pip install "basicsr==<IP_ADDRESS>"

# Fix HAT dependency.
git clone https://github.com/korouuuuu/HMA.git
git clone https://github.com/XPixelGroup/HAT.git
ln -srv HAT/hat HMA/hat

# Write necessary version metadata.
cd HMA
python setup.py develop

# Now run, with PYTHONPATH because nothing is correct about how this package searches for modules.
env PYTHONPATH="$(pwd)" python hma/test.py -opt options/test/HMA_SRx2.yml

But there's still one more problem. Of course! :D
Error:
HMA/.venv/lib/python3.8/site-packages/torchvision/transforms/functional_tensor.py:5: UserWarning: The torchvision.transforms.functional_tensor module is deprecated in 0.15 and will be **removed in 0.17**. Please don't rely on it. You probably just need to use APIs in torchvision.transforms.functional or in torchvision.transforms.v2.functional.
  warnings.warn(
Traceback (most recent call last):
  File "hma/test.py", line 4, in <module>
    import hma.archs
  File "HMA/test/HMA/hma/__init__.py", line 3, in <module>
    from .data import *
  File "HMA/test/HMA/hma/data/__init__.py", line 11, in <module>
    _dataset_modules = [importlib.import_module(f'hat.data.{file_name}') for file_name in dataset_filenames]
  File "HMA/test/HMA/hma/data/__init__.py", line 11, in <listcomp>
    _dataset_modules = [importlib.import_module(f'hat.data.{file_name}') for file_name in dataset_filenames]
  File "/home/johnny/.pyenv/versions/3.8.20/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ModuleNotFoundError: No module named 'hat.data.paired_imagenet_dataset'

This error is because hat's file is named hat.data.imagenet_paired_dataset but for some reason HMA tries to import hat.data.paired_imagenet_dataset instead.
So yeah this repo is a mess but the work itself looks so awesome that I really hope someone figures out the rest of these bugs!

Ah I have probably figured otu the last error.
HMA names its own file hma/data/paired_imagenet_dataset.py
HAT names its own file hat/data/imagenet_paired_dataset.py
HMA contains __init__.py files in each subdir that still refer to the hat. project, which scans for all files in the directory and then tries to load the hat. variant, so it ends up trying to load the HAT version of that file but with the HMA filename.
I will figure this out soon, but I will not delete my previous troubleshooting messages. I want people to feel the same pain I felt. :)

So, the bug was actually that HMA took HAT's code, but did not properly rewrite the folder/includes to the new HMA name instead. It does NOT need HAT as a dependency. It's just very clear that koro did development with the files still named "hat", and then hastily renamed them to "hma" when publishing, without realizing that they are still trying to import hat code.
Here's the final fixed instructions, until this repo is fixed:
pyenv local 3.8
python -m venv .venv
source ".venv/bin/activate"

# Manually install requirements based on cog.yaml since requirements.txt is wrong (it's wrong in HAT too).
pip install --upgrade pip
pip install "numpy==1.21.5" "ipython==7.21.0" "opencv-python==<IP_ADDRESS>" "torch==2.0.1" "torchvision==0.15.2" "einops==0.4.1"
pip install "basicsr==<IP_ADDRESS>"

# Clone HMA.
git clone https://github.com/korouuuuu/HMA.git

# Fix old references to HAT in the code. It's a problem in the __init__.py files.
find HMA -name "__init__.py" -exec sed -i"" -E 's,\bhat\.,hma.,g' "{}" \;

# Write necessary version metadata.
cd HMA
python setup.py develop

# Now run, with PYTHONPATH because nothing is correct about how this package searches for modules (HAT has the same problem).
env PYTHONPATH="$(pwd)" python hma/test.py -opt options/test/HMA_SRx2.yml

Of course, the project still breaks with another error now. This is the same BasicSR error I saw earlier when I thought my BasicSR was "too new", but now it's the exact version recommended and it's still not working.
So the final conclusion is: This repo is very broken in many ways. I have fixed MOST of the bugs with my steps above, but there's more bugs and I am too tired to continue. @korouuuuu :)
env PYTHONPATH="$(pwd)" python hma/test.py -opt options/test/HMA_SRx2.yml
Traceback (most recent call last):
  File "hma/test.py", line 4, in <module>
    import hma.archs
  File "HMA/test/HMA/hma/__init__.py", line 3, in <module>
    from .data import *
  File "HMA/test/HMA/hma/data/__init__.py", line 11, in <module>
    _dataset_modules = [importlib.import_module(f'hma.data.{file_name}') for file_name in dataset_filenames]
  File "HMA/test/HMA/hma/data/__init__.py", line 11, in <listcomp>
    _dataset_modules = [importlib.import_module(f'hma.data.{file_name}') for file_name in dataset_filenames]
  File "/home/johnny/.pyenv/versions/3.8.20/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "HMA/test/HMA/hma/data/paired_imagenet_dataset.py", line 9, in <module>
    from basicsr.utils import FileClient, imfrombytes, img2tensor, rgb2ycbcr
ImportError: cannot import name 'rgb2ycbcr' from 'basicsr.utils' (HMA/test/.venv/lib/python3.8/site-packages/basicsr/utils/__init__.py)

Thanks @korouuuuu I was just cloning your repo now to fix bugs and submit PR but I see you started editing already. <3

Alright, after #5 is merged, the "only" things people have to do to run this locally are these steps:
pyenv local 3.8
python -m venv .venv
source ".venv/bin/activate"

# Manually install requirements based on cog.yaml since requirements.txt is wrong (it's wrong in HAT too).
pip install --upgrade pip
pip install "numpy==1.21.5" "ipython==7.21.0" "opencv-python==<IP_ADDRESS>" "torch==2.0.1" "torchvision==0.15.2" "einops==0.4.1"

# We must install BasicSR AFTER Torch (not on the same line), otherwise it will not install at all.
pip install "basicsr==<IP_ADDRESS>"

# Clone HMA.
git clone https://github.com/korouuuuu/HMA.git

# Write necessary version metadata.
cd HMA
python setup.py develop

# Now run, with PYTHONPATH because nothing is correct about how this package searches for modules (HAT has the same problem).
env PYTHONPATH="$(pwd)" python hma/test.py -opt options/test/HMA_SRx2.yml

@Arcitec  Thanks for your determination!! Your bug-fix experience really inspires me, I will try your fix solution on weekend.


Rustls transport?

Hi,
I've been looking at the security of the cargo / crates.io ecosystem, and I've noticed that it depends heavily on the security of TLS. The index of crates is downloaded over HTTPS from GitHub, and serves as the root of trust for subsequent crate downloads, because it contains the sha256 hashes of the crates.
Given that, I think it makes sense to use the strongest TLS implementation. Fortunately, rustls is a very high quality implementation, and is in Rust! Besides the memory safety benefits, it has a couple of other benefits: It does not implement older TLS versions (1.0 and 1.1), which have some vulnerabilities. Similarly it does not implement weaker ciphersuites. Also, it ships by default with webpki-certs, which is beneficial because it tends to be more up-to-date than the native root store on Debian-derived operating systems. When there's a CA that's been removed from the Mozilla root program (and others), but not removed yet from a root store, that's a big risk. In that situation there aren't (necessarily) any audits or controls happening any longer to ensure the CA is doing the right thing.
So I was thinking it would be useful to implement a git transport for HTTPS that uses Rustls. Probably the most straightforward way to do that would be to incorporate a Rust HTTP client. I see git2-rs already has a small HTTP client in git2-curl, but that it's considered less battle-tested (and has an issue with pulling a whole repository into memory), so isn't used as the default in cargo, but is only used when there are special HTTP setting, like proxies or custom root stores.
Is that something you think would be useful? Since my goal would be for cargo to (eventually) adopt this as the default instead of libgit's built-in HTTP transport, what quality and testing bar would it need to meet?
Thanks,
Jacob

Seems reasonable to me! There's the git2-curl crate which implements all HTTP crate fetches through the curl crate, so presumably there could be a git2-hyper crate (or something like that) which disables all of libgit2's internal networking and provides it via hyper+rustls?

Being able to use a pure rust ssl makes using a lot of rust tools a lot easier where finding openssl or building ssl from source is tricky. Building cargo, cargo-audit etc. It would make a big chunk of the ecosystem easier for people to use.

Hi. I am wondering about how to integrate an async HTTP backend like hyper into git2. And it seems that spawning threads for hyper in the Read/Write trait is the most feasible solution which I can come up with. If there is other possible approach, please share it here. I am happy to do some experiments.

@weihanglo We’re doing something like this. You can also pass around an executor.

Hi, I just implemented a HTTP back-end and send a pull request.

Checking back in on this, is there still a desire to create a feature that will let users of git2 enable rustls instead of openssl?

Yes, I'm still very interested in using git2-rs with a rustls backend. I wrote a couple of starts at this in https://github.com/rust-lang/git2-rs/pull/624 and https://github.com/rust-lang/git2-rs/pull/625. What I found was that what's needed is not just a TLS transport but also an HTTP implementation. I think it should be quite possible to dust off one of those PRs and proceed either with the ureq HTTP client or with a hyper HTTP client (or both).

Just wanted to add a heavy interest in a rustls usage because openssl crate does not support libressl or modern openssl, while rustls does. Openssl-vendored kinda bloats the binaries so i would greatly appreciate a rustls version

Two years on and at a different place and I find things still failing to install due to openssl dependencies. Pure rust might be more secure by now as well as work first time. It would help rust's roll out if we could ween ourselves off openssl.

@gilescope @Shifulor have you tried @henry40408's git2-hyper crate? https://github.com/henry40408/git2-hyper

I Did not, it seems like a nice project tho. Sadly it does not help in my specific case, because it would require remodeling a lot of code. Also his example puts the code into unsafe brackets, which honestly worries me (No idea if this crate maybe also does so don't pin me on that :cold_sweat: )

I'm about to port crates-index and cargo-audit from git2 to gitoxide specifically because gitoxide supports rustls.
I'd be very happy to see this issue fixed, and save myself and the ecosystem the migration.

I would like to express my interest as well. It would be absolutely great to have rustls support in git2!

Would also like to see this for gitui

also means you don't have to scrounge around to find exactly what the openssl dev package is named in your distro.

How about depend on reqwest and its support of rustls?
I think it has advantages over past PRs:

won't (re-?)implement HTTP client (#624 or #685)
will support HTTP/2 (unlike ureq, #625)


FIX: DOCS: color-system.mdx

Incorrect file name in code sample title.

Hey @mountainash,
I'm closing this PR as the changes are already in place, but your input was valuable and I wanted to acknowledge that. Looking forward to more contributions in the future!