New package management code testing

BuZz

I am interesting in getting some user/dev feedback on some new WIP code (Ideally from those confident in using git and linux commandline) -

https://github.com/RetroPie/RetroPie-Setup/pull/1489 (the branch is https://github.com/joolswills/RetroPie-Setup/tree/modular)

This is the first step in changing the way packages are installed/removed etc - and it allows updating only the currently installed packages too. It doesn't yet remove entries from EmulationStation however when removing - that will come later.

Mostly interested in any new bugs I have introduced when changing this around.

meleu

@BuZz

~~You said to not use rp_module_menus but keep using it at scriptmodules/supplementary/*.sh scripts. Is that correct?~~

BuZz

@meleu not sure what you mean?

meleu

Please forgive me. I was dealing with old files. Shame on me...

Now let me ask: would you mind if I make some Pull Requests with some comments (and just comments) in your code?

BuZz

That's a rather odd request. I would prefer not because it's a work in progress - I am interested in feedback in regards to functionality at this stage (ie bugs)

BuZz

This code has now been merged. Anyone who updates the RetroPie-Setup script will get the new code. There will no doubt be some bugs, and there are a few cases where things will not show as installed uninstall they are re-installed.

There are many more binaries available now though, and it should be much easier to quickly install optional packages etc.

meleu

@BuZz said in New package management code testing:

That's a rather odd request. I would prefer not because it's a work in progress - I am interested in feedback in regards to functionality at this stage (ie bugs)

Yeah, it seems to be an odd request, but the purpose is to make the functions more clear to the future developers. At least to fit to what is recommended RetroPie-Setup Script Code Style Guide for function comments.

I'm trying to learn how to code a "config" module by reading the scripts at scriptmodules/supplementary directory. And they use a some functions like getDepends, isPlatform, hasPackage, iniConfig, iniSet, etc... I realised that these functions comes from helpers.sh, inifuncs.sh, etc. And I need to read almost every line of these codes to contribute.

I think it should not be needed such effort to make a small contribution. Quoting what is said in Shell Style Guide:

Any function that is not both obvious and short must be commented. (...) It should be possible for someone else to learn how to use your program or to use a function in your library by reading the comments (and self-help, if provided) without reading the code.

What I am doing is volunteering me to read and comment on these codes so that future developers do not have to go through all this effort.

BuZz

I have already given you an answer on this.

It's not too difficult to follow currently - others have managed. Please don't quote our styleguide at me - I am aware what is in there, since I helped adjust it to our project.

I have already said I will document the API more in the future. I am likely going to use a bash supporting extension to doxygen or similar. As I wrote the functions I would like to document it myself - but in my own time.

meleu

WOW! I didn't expect this reaction!

I'm sure I can manage it. I just suggested it because I think my job gives some time to read the code, but I have no access to a linux box to actually write a code. I'm an industry operator, I have to control several variables (level, pressure, temperature, start pumps, etc.) and sometimes these variables are behaving very well. This is when I can read and comment the code. (Please, don't think I operate like a Homer Simpson! :D We have several trends to monitor these variables.)

I thought "If I have to read it to understand what it does, why not comment to help future contributors?". But it's OK, I see you are very attached to your code :-) I won't touch it!

Please, sorry, I won't bore you on this anymore.

BuZz

Please don't overreact :)

I don't think it make much sense for someone else to document the code that they have said they don't fully understand because it is not documented ? I also have my own plans for this and want to make further changes to the API, but I appreciate the offer.

Please understand that I am not working on this in my free time simply to make it easier for you to implement something - as with the other thread when you said "please rewrite this in python for me". I don't work for you. Sorry.

I listen to user suggestions, and try and improve RetroPie as I can, but it is not my job.

meleu

@BuZz said in New package management code testing:

(...) as with the other thread when you said "please rewrite this in python for me". I don't work for you. Sorry.

Oh, I didn't want to sound like a boss. Sorry again :-)

The jslist.c is so small. And actually I learned the minimum python knowledge needed to translate jslist.c to jslist.py, and I did it. But I did it with python3 and then I realized this "python2 vs. python3" issue. It's a little tricky to install pygame for python3. I did it, but I don't want to force the users to install a new package for such a small task (list the available joysticks). I'll keep it in C until the will to rewrite in python2 comes to my mind. :-)

BuZz

It should be possible to get a list of the system joysticks without an external tool from shell script directly btw, which would remove the need of an additional tool to compile. I plan to implement better support for multi player and joystick assigning (it is needed to fix up player 2 configuration on keyboard also), but may do it as part of the configuration editor, or even via some changes to ES as with recalbox.

meleu

@BuZz the use of SDL2 lib is usefull for detect joysticks regardless of the connection method (usb, bluetooth, etc.).

BuZz

I assume all joysticks create a /dev/jsX device though - so should be possible (if it can be worked out how to match the order etc if it's not the same as the /dev/jsX order)

meleu

@BuZz [I'm not sure if we should be using this thread for this, but it's going interesting! :D ]

Yeah. Indeed they are all /dev/input/jsX. But, for example, when I use udevadm info -q all -n /dev/input/js0 for my 8bitdo zero bluetooth controller, it doesn't show me the joystick name, neither in ID_MODELnor anywhere. This is why I went to SDL2.

BuZz

I will take a look - I wanted to use the names in the configuration editor, so I will need this (or a tool like yours)

meleu

@BuZz
Oh... I've just remember that I created a thread to discuss this about a month ago:
https://retropie.org.uk/forum/topic/991/solved-how-can-i-get-the-connected-joypad-names/

@Zigurana pointed me to the SDL2 approach.

BuZz

I will continue there if I have an update.