Call to Action! Prototype of Micropython Plugin NOVA is ready to challenge brave testers!

[Ilia Motornyi (elmot)]

Compatibility: PyCharm 2024.2 2024.3 EAP

Tested setups:

• Windows/ESP32 (MicroPython v1.23.0)
• Windows/ESP8266 (MicroPython v1.23.0)
• Windows/RPi Pico (MicroPython v1.20.0...1.25.0.preview)

Features:

• WebRepl support
• Faster communication
• Repl history is back
• Instant file run
• Instant selected text run
• Instant file upload
• On-device file manager

Please download, install, try, share your feedback with us!

Download: intellij-micropython-2.0.0.pre-alpha13-2024.3.zip

PS: How to install the plugin from disk
PPS: Webrepl setup manuals could be found here or here

[Gabe Morris (gabemorris12)]

This is wonderful! I'm a brave tester, so I'll do it if I must. It's a sacrifice I'm willing to take.

I have a couple of comments/issues that I'd like to share. First off, I am able to normally use the REPL console, but every time there is some transfer of data, like pressing the "connect" button (the one that looks like a plug in the top left corner of the micropython window) or flashing a script, I get this error in the bottom left:

Additionally, the REPL console doesn't have the helpful message that explains how to reset the microcontroller with ctrl + D and stop with ctrl + C, though the latter one is a given, it would still be helpful. Also, maybe the ctrl + ] should be kept for disconnecting?

The File System tab isn't working for me at all:

Pressing connect doesn't do anything, and hitting the refresh button throws the same error in the previous picture.

Lastly, I'm not sure if the issue is me, but when I use the web repl, it doesn't quite work:

I think that's all I've got. I am very grateful that this repo is getting some attention! Thanks a lot for putting this work in! I use this plugin all the time.

[Ilia Motornyi (elmot)]

Gabe Morris (@gabemorris12) are you sure the plugin was upgraded?
If yes, I run out of ideas for now, and I don't have any access to macs to debug it.

[Gabe Morris (gabemorris12)]

Gabe Morris (@gabemorris12) are you sure the plugin was upgraded?

If yes, I run out of ideas for now, and I don't have any access to macs to debug it.

It's upgraded. It has the pre-alpha4 in the name. I'll be here to try anything else.

[Ilia Motornyi (elmot)]

Gabe Morris (@gabemorris12)
I added logging for all the serial communications
Can you please try attached version and then send me back IDE logs?

Note: those logs may contain personal data, so please don't send me if you don't want to share that data, and send it me directly(we'll find a way), to keep the data personal.

intellij-micropython-2.0.0.pre-alpha7-log-comm-2024.2.zip

[Gabe Morris (gabemorris12)]

Gabe Morris (@gabemorris12) I added logging for all the serial communications Can you please try attached version and then send me back IDE logs?

Note: those logs may contain personal data, so please don't send me if you don't want to share that data, and send it me directly(we'll find a way), to keep the data personal.

intellij-micropython-2.0.0.pre-alpha7-log-comm-2024.2.zip

I have emailed you the log file. This should help.

[Ilia Motornyi (elmot)]

Thanks for the log, it looks like I caught that insect eventually, it's #333
Please try pre-alpha9, attached to the top
NB: Please use PyCharm 2024.3 EAP

[Lukas Kremla (lukaskremla)]

Looks like a great release! Looking forward to coding with it. Will make sure to report back with my feedback once I spend some time with the plugin!

[jetsen-os]

I think the new approach of the plugin is great! I am very excited about the planned features.

I encountered a problem while testing:

When I start a new project, the settings under "Micropython" are not displayed and the plugin does not show any functionality. I get the same result when I uncheck "Enable MicroPython support".

Currently, there is only one way to fix the problem: If I insert the following lines into the [project_name].iml file and save it, all settings are displayed and everything works fine.

<component name="FacetManager">
    <facet type="MicroPython" name="MicroPython" />
</component>

System

PyCharm 2024.2.4 (Community Edition)
Build #PC-242.23726.102, built on October 22, 2024
Runtime version: 21.0.4+13-b509.26 amd64 (JCEF 122.1.9)
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.awt.windows.WToolkit
Windows 11.0
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 1500M
Cores: 16
Registry:
debugger.new.tool.window.layout=true
documentation.show.toolbar=true
ide.experimental.ui=true
i18n.locale=
Non-Bundled Plugins:
com.intellij.plugin.adernov.powershell (2.8.0)
com.godwin.json.parser (1.7.2)
eu.osimowicz.plugins.intellij.CodeBlocksSorter (0.1.2)
Batch Scripts Support (1.0.13)
dev.meanmail.plugin.nginx-intellij-plugin (2024.3)
de.docs_as_co.intellij.plugin.diagramsnet (0.2.6)
org.jetbrains.erlang (0.11.1241)
intellij-micropython (2.0.0.pre-alpha2-2024.2)
net.seesharpsoft.intellij.plugins.csv (4.0.0)
com.carbonblack.intellij.rpmspec (2.2.0)

Thank you very much for the great plugin and your work!

[Ilia Motornyi (elmot)]

I have fixed this just today. Please update to 2.0.0.pre-alpha4-2024.2, attached to the topmost message here.

[jetsen-os]

With 2.0.0.pre-alpha4-2024.2 it works! Thank you very much!

[Lukas Kremla (lukaskremla)]

I have spent some time in the IDE with the updated plugin, and I have found a few bugs:

1. Files with the ".old" extension which are located on the MCU file system can't be opened with the "right click -> Open file" option like others can (I have only tested .py, .txt and .old, there might be more unsupported extensions).

2. When I make a change to a file it takes around 5 seconds or a little less for the flash to I suppose "switch" to this file. What happens is that for a few seconds after modifying a file, the flash command will keep flashing an older version/the un-modified version.

3. If a "°" character is present in the file the following error will pop up and the flash will fail: "Upload files I/O error - Expected size is {insert expected size}, uploaded 0"

4. If I do "cmd + a" in the "File system" tab I will select the top "/" directory listing as well, which grays out the trash icon for deleting files and folders, I have to manually unselect the top most "/" entry and it works again - I list this as a bug as selecting all files and pressing the trash icon seems like the easiest way to fully erase the file system after the "Tools –> Erase flash" action was removed, cmd + a selecting the "/" folder as well complicates this ever so slightly.

First few bugs I came across. Tested on ESP32 S2 Mini 2 running latest MicroPython 1.24.0 flashed with Thonny, the ESP8266 is selected as the used device type, used the Serial communication option, did not test WebREPL for any of the described bugs. Build #PY-242.23726.102, built on October 22, 2024

Besides this, I have to applaud your work - this plugin will make PyCharm the best IDE out there for MicroPython projects of all kinds, from simple to very complicated company projects.

[Lukas Kremla (lukaskremla)]

Indeed, flashing certain files gives this error now "Upload files I/O error - Traceback (most recent call last): File " ", line 1 SyntaxError: invalid syntax Traceback (most recent call last): File " ", line 1 SyntaxError: invalid syntax"

class Class: def __init__(self): pass """ It's """

Also causes it

[Lukas Kremla (lukaskremla)]

Indeed, flashing certain files gives this error now "Upload files I/O error - Traceback (most recent call last): File " ", line 1 SyntaxError: invalid syntax Traceback (most recent call last): File " ", line 1 SyntaxError: invalid syntax"

class Class: def __init__(self): pass """ It's """

Also causes it

I also get this error when deleting files if they contain the " ' " character - print(f'STA mode activated on: "{self._sta_ssid}"') . "Delete I/O error - Traceback (most recent call last): File " ", line 1, in OSError: [Errno 2] ENOENT".

[Ilia Motornyi (elmot)]

One shall not fix bugs late night. Fixed again in pre-alpha6

[Lukas Kremla (lukaskremla)]

One shall not fix bugs late night. Fixed again in pre-alpha6

Haha, it happens to the best of us. Most of the bugs do seem fixed, I wasn't able to reproduce them with the pre-alpha6 version.

I have gotten farther in flashing my project - now there seems to be an issue with uploading large files. "Upload files I/O error - Timeout during command execution:___f.write(b'\xdd\xcb>\x1c\xb3R\x1a\x88\xa4\xba\x01P \x89\xc31\xd8\xbf\xc2\xecHI\x06\xaa\x1a\xddK\x881m\x92i\x1dZ\n4G\x16\x98\x07\xe2\xfa\x8d\xa3>\xa2\xf5\x0c1\xddP\x19\xf1\xec\x89\r\xcb:u\x8e\x90p\xfc\xd0\x06:\x0e\xd1\xefm\xad\xd6>h')"

The file in question is a ".js.gz" file with a size of 306KB. I have only tried to upload it with Serial communication option.

If the time out has a set time for the files to upload and this is what causes the timeout errors, maybe a different approach to consider is specifically checking whether data is being transferred or not to determine if an actual time out has occurred.

[Lukas Kremla (lukaskremla)]

Another thing is, it seems that if the connection to the device breaks under some unknown condition, it only happens on the background and the IDE does not disconnect - I don't have concrete steps to reproduce this. It usually happens if I flash files for long enough (repeatedly flashing - making changes, flashing, sending soft reset commands to REPL, rinse and repeat...). What happens is that I get an error that says something like this: "line 1 something "OS" error".

This is very low priority, as just disconnecting and reconnecting fixes it, I have more so left this here so that you or others can be on the lookout for this error, maybe someone else might run into it and be able to figure out what exactly causes it.

[Lukas Kremla (lukaskremla)]

I have another idea - from my experience WebREPL is not quite reliable for REPL terminal communication itself. Especially if I frequently develop on different STA Wi-Fi networks. Would you consider adding an option in the settings for choosing a separate way of communication for the file uploads and for the REPL terminal?

For me it makes a lot of sense to stick with REPL terminal over serial due to its increased reliability - and the fact that I can use the serial REPL terminal for debugging WebREPL. And then use WebREPL solely for file uploads/flashing, because of the increased file transfer speed.

[Lukas Kremla (lukaskremla)]

Lukas Kremla (@lukaskremla)

Now the only problem that I see is the fact that opening a file located in the device's file system clears the REPL terminal as well.

Please file a ticket

Especially for you: pre-alpha10 uses base64 uploads, that means upload performance on big binary files is faster up to x2.5. Please test intellij-micropython-2.0.0.pre-alpha10-2024.3.zip

I've tested the latest pre-alpha 12, here are the bugs I found:

1. If an action like uploading a file or opening a file gets cancelled or fails due to an error, the plugin will disconnect from the board.
2. Linked to this is a bug where the File System view doesn't get redrawn if the upload gets cancelled (might also happen when it fails). Meaning that the file system listing remains visible when the device is no longer connected after bug no. 1 happening. This is quite confusing, as in that case it might be harder to tell the device is no longer connected.
3. The new upload systems works in a way, where if I select the project folder itself for flashing/uploading, the source folders contained in it get uploaded to the device with the root folder. Additionally, the source folders themselves aren't ignored either. Meaning that all the functionality regarding source folders that worked before is now broken. Meaning the resulting file structure on the device looks something like ProjectName -> SrcFolder1, SrcFolder2.
4. Selecting Run Flash "FolderName" on a folder marked as source folder will cause it to get uploaded in a path with the project name. So on the device it looks like ProjectName -> SrcFolder -> Its content
5. Selecting upload directory to MicroPython device on a folder marked as source folder will result in the whole folder getting uploaded to the device, unlike before, when just the source folder content was uploaded.
6. The flash options seem to be mixed up now. I have a project which contains two source folders, clicking run Flash "FolderName" on either of them seems to always trigger the run Flash "ProjectName" configuration instead.
7. Uploading certain files, such as .json.gz files causes the ubinascii error.
   Se attached screenshot for details.

   
8. If I manually select multiple files (such as .py or .old files) and right click them to select upload files to MP device then only the file I selected first gets uploaded, others won't get uploaded.

9. After uploading a subfolder from my source folders to test things I have randomly received the following error. I don't know if any specific file does it, haven't been able to pin point it to any. It only seems to happen with the folder. Possibly it might happen after uploading many files in a row.

I also have a few suggestions for adjusting some of the File System and REPL view button names/descriptions. I would rename the description of the download button that pops-up on hover to something like "Download Item(s)" to make it more consistent with how the delete button description is written. Similarly I would capitalize the "New folder" description to "New Folder" and "Auto clear" to "Auto Clear REPL".

The new download and new folder features seem to work flawlessly.

I've also tested the bug where REPL gets cleaned after opening a file on the device file system, while it no longer does that, it will still print the "MicroPython v1.24.0 on 2024-10-25; Generic ESP32S2 module with ESP32S2
Type "help()" for more information.
" message. This made realize that opening a file has to interrupt the running program, which didn't click for me previously. This might need some better more transparent handling of the console output. I will open the ticket/issue so we can discuss it separately.

[Ilia Motornyi (elmot)]

Thanks for detailed reporting. Can you please hide screenshots and long stacktraces under spoilers next time? Otherwise the page looks very messy.

1. If a file system action like opening a file gets cancelled or fails due to an error, the plugin will disconnect from the board. #342
2. Fixed (I hope so) in pre-alpha13
3. New project upload algorithm #338
4. New project upload algorithm #338
5. Can you please make a screen recording or something, I did not get it out of text explanations
6. New project upload algorithm #338
7. Fixed (I hope so) in pre-alpha13
8. That's by design. The menu item is in a singular form. There is a reason behind - what if a folder and an item inside are both selected and uploaded? Shall they keep the same file structure or go to the same destination?
9. New project upload algorithm #338

Suggested rewordings are done,
Download tooltips are changed to more explanatory.

[Lukas Kremla (lukaskremla)]

5.

Screen.Recording.2024-11-18.at.20.49.39.mov

8. I understand now. Maybe this begs the addition of more file upload options?:

1 . Upload the file/directory directly to the File System root.
2 . Upload the file/directory maintaining the file structure in the project (keeping in mind the source file logic and so on).

And the problem you describe could be handled by graying out these options and perhaps adding another option underneath them, which would serve for letting the user know they have selected a conflicting combination. Or any other way possible with PyCharm GUI.

Even just throwing an error if the upload is attempted by the user without graying out these buttons could be sufficient, albeit less user-friendly than the first way.

[Lukas Kremla (lukaskremla)]

2. and 7. appear to be fixed in pre-alpha 13

[Santu OTTAVI (bc-109)]

Hi all,

For me it makes a lot of sense to stick with REPL terminal over serial due to its increased reliability - and the fact that I can use the serial REPL terminal for debugging WebREPL.

I'm just discovering the NOVA Work in Progress, but I didn't understand if this feature has been implemented or not. For me, serial REPL is absolutely mandatory, and I'd vore for it.

My current setup is :

• a Telnet server running on the device for remote REPL operations over WiFi or Ethernet
• a FTP server for remote file transfers
• local serial REPL for initial file transfer, and for debugging my FTP/Telnet code :-)

(I don't use WebREPL at all because I didn't really understand the philosophy behind it. I prefer using standard protocols such as Telnet and FTP, in the same way as for other platforms).

Thank you in advance for your answers.

[Ilia Motornyi (elmot)]

Many thanks to everyone for testing and for the feedback.
That was very helpful and motivating.
Now critical bugs seem to be fixed. If no new ones have appeared within a day or two, I'll advance NOVA from pre-alpha to alpha.

[Lukas Kremla (lukaskremla)]

Just to know what to expect, alpha means plugin marketplace release?

[Ilia Motornyi (elmot)]

We'll discuss that with Pavel Karateev (@lancelote)
At least I will go forward with some improvement ideas.
For instance, I just realized that MPy has library functions for crc32 and base64, that means upload/download speeds to be raised, in some circumstances drastically.

[Lukas Kremla (lukaskremla)]

Today I have tried the latest MicroPython plugin pre-alpha on the ESP32 S3 Lilygo display board, non-touch version.

Two odd bugs happen a lot.

I connect, flash a file, the device soft-reboots and I start interacting with the board through Microdot over wi-fi. Then after about 1-3 minutes I try to flash a new file, that times out, then I click the "Reset" button under "REPL". That throws the following: "Reset... error - SerialPortException: Port name - /dev/cu.usbmodem101; Method name - writeBytes; Exception type - Native exception occurred: Device not configured.

jssc.SerialPortException: Port name - /dev/cu.usbmodem101; Method name - writeBytes; Exception type - Native exception occurred: Device not configured.
at jssc.SerialPortException.wrapNativeException(SerialPortException.java:117)
at jssc.SerialPort.writeBytes(SerialPort.java:415)
at jssc.SerialPort.writeString(SerialPort.java:448)
at com.jetbrains.micropython.nova.SerialClient.send(SerialClient.kt:17)
at com.jetbrains.micropython.nova.MpyComm.reset(MpyComm.kt:365)
at com.jetbrains.micropython.nova.FileSystemWidget.reset(FileSystemWidget.kt:283)
at com.jetbrains.micropython.nova.SoftResetAction.performAction(actions.kt:385)
at com.jetbrains.micropython.nova.ReplAction$actionPerformed$1.invoke(actions.kt:64)
at com.jetbrains.micropython.nova.ReplAction$actionPerformed$1.invoke(actions.kt:64)
at com.jetbrains.micropython.nova.ActionsKt$performReplAction$1.invokeSuspend(actions.kt:95)
at com.jetbrains.micropython.nova.ActionsKt$performReplAction$1.invoke(actions.kt)
at com.jetbrains.micropython.nova.ActionsKt$performReplAction$1.invoke(actions.kt)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:62)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext(Builders.common.kt:163)
at kotlinx.coroutines.BuildersKt.withContext(Unknown Source)
at com.intellij.platform.util.progress.ProgressPipeImpl.collectProgressUpdates(ProgressPipe.kt:43)
at com.intellij.openapi.progress.impl.PlatformTaskSupport$runWithModalProgressBlockingInternal$2$taskJob$1.invokeSuspend(PlatformTaskSupport.kt:216)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:608)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:873)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:763)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:750)"

Now the second bug has the same steps to reproduce but when I press reset or try to upload something, instead of the above mentioned error the REPL gets stuck in some loop printing the same output over and over followed by "Server error: <class 'OSError'>: [Errno 112] EADDRINUSE". This repeats and the REPL gets filled with tons of these.

Right now it appears to be a coin toss between which of these bugs occurs.

What I am running on the device is WiFi AP interface and Microdot. As mentioned the device is an ESP32 S3 Lilygo with display, non touch version. Plugin version is pre-alpha 9, PyCharm is EAP - Build #PY-243.21565.33, built on October 30, 2024 and I work with an M2 mac.

[Ilia Motornyi (elmot)]

Seems to be some problems with boards UART.

[Ilia Motornyi (elmot)]

May I ask what is Microdot and how does it interact with the board? Does it touch webrepl?

[Lukas Kremla (lukaskremla)]

May I ask what is Microdot and how does it interact with the board? Does it touch webrepl?

I am pretty sure I found the problem, seems to have been a mistake in my code, apologies for the false alarm.

Microdot is Miguel Grinberg's compact MicroPython web server inspired by Flask. I deem it the best MicroPython web server around.

[bmartinGithub]

I just started learning python/micropython on the Raspberry Pi Pico using Pycharm upgraded to the latest version 243* and ran into the plugin out of date issue, so I maybe just not familiar with everything. I installed this alpha plug-in to try to continue. I noticed when I flash the project with the project root directory marked as the source or not, the flash process uploads the Project root directory into the root of the Pico filesystem as displayed in the MicroPython File System view.

However the main.py file does not seem to execute. If I manually delete the Project directory from the Pico file system then manually flash just the main.py file onto the system it will then execute the main.py file is run as expected. It seems like a redirect in the root of the Pico filesystem is needed if the Project root or Source directory is flashed onto the Pico.

In this configuration the main.py file highlighted runs as expected.
Forgive me if I'm using incorrect terminology.
I'm using: intellij-micropython-2.0.0.pre-alpha13-2024.3.zip

[Lukas Kremla (lukaskremla)]

I'd say it's better to install stubs using pip. https://micropython-stubs.readthedocs.io/en/main/11_install_stubs.html#install-to-typings-folder

I had a few problems with that, this approach worked flawlessly for me so I recommended it.

[Ilia Motornyi (elmot)]

Possibly Jos Verlinde (@Josverl) would like to know what kind of problems you faced

[Jos Verlinde (Josverl)]

Lukas Kremla (@lukaskremla),
Indeed I'm interested to understand what you ran into, and how to improve on that.
I'm sure the docs are never as up-to-date as they can be, so don't hesitate to point out mistakes or outdated content , and if possible propose an update or Documentation PR.

pip install micropython-<someport>-stubs into an .env or typings folder is just a simple way of copying , but if you prefer a manual copy rather that install from PyPI, I suggest sourcing from one of the distribution package that are ready for publication in the publish folder of the stubs repo.

FWIW, I'm aware I'm lagging on releasing stubs for v1.24.x , hope to have these released in the next weeks.

[Lukas Kremla (lukaskremla)]

Lukas Kremla (@lukaskremla), Indeed I'm interested to understand what you ran into, and how to improve on that. I'm sure the docs are never as up-to-date as they can be, so don't hesitate to point out mistakes or outdated content , and if possible propose an update or Documentation PR.

pip install micropython-<someport>-stubs into an .env or typings folder is just a simple way of copying , but if you prefer a manual copy rather that install from PyPI, I suggest sourcing from one of the distribution package that are ready for publication in the publish folder of the stubs repo.

FWIW, I'm aware I'm lagging on releasing stubs for v1.24.x , hope to have these released in the next weeks.

I've actually first tried to download the stubs to PyCharm back when I started learning Python/MicroPython. I didn't understand a whole lot about the way things work in PyCharm and I tried to install to a typings folder without marking it as a source root, that didn't work of course. Since I was a beginner back then I just moved on to keep learning without stubs.

Later when this pre-alpha was released and I came back to more actively using PyCharm and I saw elmot mention source folders and stubs in some context, so I set it up manually. That worked right away so I didn't even think about the pip installation being an option.

So now looking at the docs again, the only suggestion that comes to mind is explicitly mentioning that PyCharm only checks for stubs in source roots, this is something that was unclear to me when I was a beginner and reading the docs now, it isn't explicitly mentioned in the PyCharm section. If I would've used the command mentioned in this section, that would've worked back then, but as I didn't see anything about source folders in the docs it didn't occur to me that it's a requirement.

After your response here I thought about it again and I immediately realized why the command didn't work for me before.

[Jos Verlinde (Josverl)]

Thanks, I'll try to clarify the documentation on that.

[HarryFairhead]

I'm trying it out on an ESP32 S3 and ESP32. Some comments and questions - trying to be helpful.
Why isn't the old plugin available for the latest PyCharm?
Is it the case that the new plugin supports the ESP32 but doesn't list it in its selection of boards?
Can you change or add an option to disable the reset of the REPL on running - it was possible to do on the old plugin and it allowed the REPL to be used as a serial monitor - i.e. you could see the print output on it.
Is it possible to provide a link to the very latest version? It may be obvious but I can't find it.
Keep up the good work.

[Ilia Motornyi (elmot)]

Why isn't the old plugin available for the latest PyCharm?

With a limited manpower we're focusing on the new one, rather on supporting the old plugin.

Is it the case that the new plugin supports the ESP32 but doesn't list it in its selection of boards?

The board selector is about to be rewritten or thrown away completely. We're discussing a new, more universal approach in another discussion #336. However, you can use ESP8266 as a workaround for now. Stubs for both ESPs are quite similar. As an alternative, you can manually install official stub for your esp, as it discussed above here.

Can you change or add an option to disable the reset of the REPL on running - it was possible to do on the old plugin and it allowed the REPL to be used as a serial monitor - i.e. you could see the print output on it.

Can you please elaborate what what are you missing? What is your use case?

Is it possible to provide a link to the very latest version? It may be obvious but I can't find it.

Unfortunately, at this moment latest pre-alfa has problems. I still did not accept latest PR from Lukas Kremla (@lukaskremla), and probably right now it's not the best moment to try the stuff. I hope I am able to advance the version in a day or two.

Keep up the good work.

Thanks, we're trying to

[HarryFairhead]

I find it hard to see what could be ambiguous about the behavior I would expect an IDE to exhibit.
You press or select RUN and the program should run and you should be able to see the output of the program, if any, without having to do anything additional. So if the program is print("hello world") pressing say the run icon should let you see the output i.e. hello world - without having to do anything else - just select run.
No downloading of programs, no running in the REPL - just select run.
As far as I can tell this is a tiny change required to the way the REPL is treated to make this happen.

[Lukas Kremla (lukaskremla)]

I find it hard to see what could be ambiguous about the behavior I would expect an IDE to exhibit. You press or select RUN and the program should run and you should be able to see the output of the program, if any, without having to do anything additional. So if the program is print("hello world") pressing say the run icon should let you see the output i.e. hello world - without having to do anything else - just select run. No downloading of programs, no running in the REPL - just select run. As far as I can tell this is a tiny change required to the way the REPL is treated to make this happen.

Screen recording

Screen.Recording.2024-12-04.at.19.42.22.mov

What should be different?

[HarryFairhead]

That doesnt work for me :-(
I am using intellij-micropython-2.0.0.pre-alpha13-2024.3.zip
If it did then I would be happy - as long as clicking the run icon in the top bar produced the same result

[Lukas Kremla (lukaskremla)]

That doesnt work for me :-( I am using intellij-micropython-2.0.0.pre-alpha13-2024.3.zip If it did then I would be happy - as long as clicking the run icon in the top bar produced the same result

Please wait until my changes are merged, if they are that is. I think I might've fixed a bug in the logic that could be causing what you described.

[HarryFairhead]

Ah! You didn't say you were changing things... Many thanks, it really is a simplification for beginners who regard seeing
hello world appear as evidence that things are working.
Look forward to trying it out.

[MAKER WITAWAT (Witawat)]

In this version, once the project is created, there is no need to install micropython anymore, right?

You can write programs and send files right away.

[Lukas Kremla (lukaskremla)]

So it hangs on updating file system view? If you wait long enough (at most a minute) will you get some timeout error?

[MAKER WITAWAT (Witawat)]

So it hangs on updating file system view? If you wait long enough (at most a minute) will you get some timeout error?

yes

this video

Details

[Lukas Kremla (lukaskremla)]

So it hangs on updating file system view? If you wait long enough (at most a minute) will you get some timeout error?

yes

this video

I was unable to replicate this issue. I currently don't have a Windows computer to test this on, so I can't rule out the possibility that this bug is somehow windows specific, maybe the maintainer will be able to assist with this hanging deletion bug.

I've looked into the code where this issue could originate from, but I haven't found anything that would seem wrong.

[MAKER WITAWAT (Witawat)]

Have new version update ?

[Jos Verlinde (Josverl)]

Im not a pycharm user personally - but transferring a 0 bytes file is prone to errors ( and should be caught both by the IDE , and the user )

[Erik Brenn (brenn)]

Hello,
I just installed the new plugin and I must say this looks promising.
PyCharm 2024.3 / intellij-micropython-2.0.0.pre-alpha13 / MacOS

I have read through various threads and understand there has been discussions with regards to stubs, flash selection algorithm etc.
I have a few comments

Q1: When I installed the plugin and startet at new project a folder "typings" where created, which I assume contains the stubs.
It seems the plugin is uploading the whole project folder, including the "typings" folder to the device. This happens both if I juse "run test.py". or use a flash run configuration. Is that a bug?
In the future, will the plugin use some kind of hash feature to only upload changed files? That would be nice, as with the old plugin my workflow was to have a "update" folder where I contained the files I was working on, leaving lots of other files outside the flashing sequence.

Q2: I tried installing stubs for my esp32 board using : pip install -U micropython-stm32-stubs --target typings --no-user
My understanding is that the stubs are installed in my main python evironment. But how do I make this stubs visible from my project, and how to make them take precedence over the ones in the "typings" folder created by the plugin?

cheers!

[Lukas Kremla (lukaskremla)]

Hello, I just installed the new plugin and I must say this looks promising. PyCharm 2024.3 / intellij-micropython-2.0.0.pre-alpha13 / MacOS

I have read through various threads and understand there has been discussions with regards to stubs, flash selection algorithm etc. I have a few comments

Q1: When I installed the plugin and startet at new project a folder "typings" where created, which I assume contains the stubs. It seems the plugin is uploading the whole project folder, including the "typings" folder to the device. This happens both if I juse "run test.py". or use a flash run configuration. Is that a bug? In the future, will the plugin use some kind of hash feature to only upload changed files? That would be nice, as with the old plugin my workflow was to have a "update" folder where I contained the files I was working on, leaving lots of other files outside the flashing sequence.

Q2: I tried installing stubs for my esp32 board using : pip install -U micropython-stm32-stubs --target typings --no-user My understanding is that the stubs are installed in my main python evironment. But how do I make this stubs visible from my project, and how to make them take precedence over the ones in the "typings" folder created by the plugin?

cheers!

I don't remember this pre-alpha version doing anything with typings folders. Maybe it was created by some other plugin or by you installing the stubs via pip?

The algorithm for building the target paths is broken in the released version, the maintainer of this plugin is quite busy and I'm not sure if he'll be be able to fix it anytime soon.

If you have the stubs installed in a folder in your project root, mark it blue as a source root and put a dot at the start of the name, then restart the IDE. It's been a while since I last used this plugin, so I'm not sure if the current algorithm will skip the leading dot file when flashing, but it's meant to do so.

PyCharms language engine only checks source folders for stubs.

[Erik Brenn (brenn)]

blush, obviously the "pip install " created the typings folder as you hinted. I didn't know pip install could go to the current folder so I oversaw it.

I did rename the folder to .stubs and it is then ignored. Unfortunately the plugin dumps the full project structure, including project root. Hopefully that will be configurable in the future.

Otherwise things works great, command completion and working history in REPL is nice :)

[Gabe Morris (gabemorris12)]

Hi,

I'm still having some issues with flashing on a Mac. It's flashing the whole working directory instead of the one main.py file. See #357.

Gabe