Skip to content

File musical chairs#391

Merged
dwalton76 merged 18 commits intoev3dev:developfrom
dwalton76:file-musical-chairs
Oct 4, 2017
Merged

File musical chairs#391
dwalton76 merged 18 commits intoev3dev:developfrom
dwalton76:file-musical-chairs

Conversation

@dwalton76
Copy link
Copy Markdown
Collaborator

For issue #375

@dlech @ddemidov @WasabiFan @ensonic take a look, this is a first stab at getting everything split up and moved around. TouchSensor, Motors, ColorSensor, Buttons, InfraredSensor, and LEDs are all working.

Here is what we have

robot@evb[ev3dev-lang-python]# tree ev3dev/
ev3dev/
├── button.py
├── control
│   ├── GyroBalancer.py
│   ├── __init__.py
│   └── rc_tank.py
├── display.py
├── fonts
//
// chopped most of fonts to limit the output here
//
│   ├── timR18.pbm
│   ├── timR18.pil
│   ├── timR24.pbm
│   └── timR24.pil
├── helper.py
├── __init__.py
├── led.py
├── motor.py
├── _platform
│   ├── brickpi.py
│   ├── ev3.py
│   ├── evb.py
│   ├── __init__.py
│   └── pistorms.py
├── port.py
├── sensor
│   ├── __init__.py
│   └── lego.py
├── sound.py
├── version.py
└── webserver.py

4 directories, 421 files
robot@evb[ev3dev-lang-python]#
@dwalton76
Copy link
Copy Markdown
Collaborator Author

Ignoring the fonts directory, this is the current structure

robot@evb[ev3dev]# tree .
.
├── _button.py
├── button.py
├── control
│   ├── GyroBalancer.py
│   ├── __init__.py
│   ├── rc_tank.py
│   └── webserver.py
├── display.py
├── fonts
│   ├── charB08.pbm


│   ├── timR18.pil
│   ├── timR24.pbm
│   └── timR24.pil
├── helper.py
├── __init__.py
├── _led.py
├── led.py
├── motor.py
├── _platform
│   ├── brickpi.py
│   ├── ev3.py
│   ├── evb.py
│   ├── __init__.py
│   └── pistorms.py
├── port.py
├── sensor
│   ├── __init__.py
│   └── lego.py
├── sound.py
└── version.py

4 directories, 423 files
robot@evb[ev3dev]# 

@dwalton76
Copy link
Copy Markdown
Collaborator Author

dwalton76 commented Oct 3, 2017

Can we make travis have a /sys/class/board-info/? See CI failure...

@WasabiFan
Copy link
Copy Markdown
Member

Why are there two files for buttons?

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

version could be put in the root __init__.py, so there is no need for a module for just that.

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

fonts probably shouldn't be in the source code tree.

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

Is there anything left in helper.py after moving stuff to control?

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

It seems like it would be cleaner to do some import magic in _platform/__init__.py rather than having button/_button and led/_led

@dwalton76
Copy link
Copy Markdown
Collaborator Author

  • version.py is generated via python3 setup.py install
  • fonts not sure what the scoop is there, I've never used them
  • helper.py I'll go ahead and chop it, I just need to redo the MINDCUBER demo but at this point we need to redo all of the demos so no point holding off

@dwalton76
Copy link
Copy Markdown
Collaborator Author

dwalton76 commented Oct 3, 2017

yeah button and led need some work that was just what I came up with to get the importing working. These are both things where a platform specific class must live in _platform and that class must inherit from some parent class. So button for instance

  • we know we want the user to from ev3dev.button import Button
  • The Button class will live in _platform but needs ButtonEVIO
  • So where to put ButtonEVIO? It can't be in button.py else you get into a circular import situation between it and the _platform file.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

@ddemidov thoughts on fonts?

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

Why would we have platform-specific button classes? As far as I can tell, the only thing that should be different is the path to the device node.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

There is no guarantee that all platforms will have the same buttons...it just happens that EV3 and EVB do. And since pistorms doesn't have any it shouldn't really have a Button class.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Wait I think pistorms has a back button but that is it and brickpi doesn't have any buttons.

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

How will documentation work if the same class is not the same between platforms? It seems to me like it would be better to make them all the same and throw a RuntimeError if something is missing (and the documentation will say something like "raises RuntimeError on BrickPi" if a class or method is not supported on that platform).

P.S. PiStorms has a Go button. (And one can add buttons to BrickPi using extra gpios)

@dwalton76
Copy link
Copy Markdown
Collaborator Author

I'll give you it would certainly clean up the importing. What about LEDs though they differ a good deal from EV3 vs pistorms?

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

Out of interest, what does time python3 -c 'import ev3dev.ev3' (before the PR) and time python3 -c 'import ev3dev.motor' (after the PR) show?

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

thoughts on fonts?

I don't see why we could not leave them to be as is, except they are only usable with python3/PIL.

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

Can we make travis have a /sys/class/board-info/? See CI failure...

We could put a board-info file into ddemidov/ev3dev-lang-fake-sys (btw, should we move that repo under ev3dev?). Then we need to make the get_current_platform function to respect Device.DEVICE_ROOT_PATH constant (or, better yet, move the constant somewhere else). This way the travis tests will know where to look for the file.

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

See #225 for some background on fonts.

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

@dlech,

fonts probably shouldn't be in the source code tree

Do you mean we should put them into a separate package?

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

Re platform specific buttons: platform file could provide both path for the event file and the list of supported buttons. Since python is a dynamic language, we could use that list (during import) to create properties corresponding to the buttons inside Button class.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Before

robot@ev3dev[~]# time python3 -c 'import ev3dev.ev3'

real	0m14.938s
user	0m11.340s
sys	0m0.560s
robot@ev3dev[~]# 

After

robot@ev3dev[~]# time python3 -c 'import ev3dev.motor' 

real	0m11.645s
user	0m9.090s
sys	0m0.510s
robot@ev3dev[~]# 

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Latest commit removes _button.py with the assumption that all platforms have the same buttons. I'll test later on a pistorms and have it raise some NoButton exception if the user tries to use buttons on a device that doesn't have them. Do you guys like the way this looks more? If so I'll do the same for LEDs.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

btw, should we move that repo under ev3dev?

yes

@dwalton76
Copy link
Copy Markdown
Collaborator Author

We could put a board-info file into ddemidov/ev3dev-lang-fake-sys

cool, @ddemidov can you add that? I haven't done much with ev3dev-lang-fake-sys

@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 3, 2017

What should be in there? Should FAKE-SYS work?

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Works for me

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Should we move 'PowerSupply' out of 'init.py' and into a 'power.py'?

@WasabiFan
Copy link
Copy Markdown
Member

Should we move 'PowerSupply' out of 'init.py' and into a 'power.py'?

I'd say "yes", because it's pretty rare that someone would use the power supply class. In my mind it's just clutter for most use cases. (In fact, I think we should try to minimize the classes in init.py overall)

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

What about LEDs though they differ a good deal from EV3 vs pistorms?

How so? PiStorms just has one extra color. I wouldn't call that a big difference.

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

@dlech,

fonts probably shouldn't be in the source code tree

Do you mean we should put them into a separate package?

I'm not sure what is the usual way for distributing data files with python packages, but is just seems odd to have data files mixed in with source code files in the source repository. Maybe better to save this discussion for later though.

Comment thread ev3dev/_platform/ev3.py Outdated
INPUT_3 = 'in3'
INPUT_4 = 'in4'

buttons_filename = '/dev/input/by-path/platform-gpio_keys-event'
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All caps for constants?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

k

@dwalton76
Copy link
Copy Markdown
Collaborator Author

I was thinking EV3 had more LEDs than pistorms but now that I look at http://www.ev3dev.org/docs/platform-comparison/ I see that it doesn't. I'll clean up LEDs to follow the same model as buttons.

Comment thread ev3dev/button.py

import array
import time
import evdev
Copy link
Copy Markdown
Member

@dlech dlech Oct 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

evdev is probably a linux-specific module like fcntl

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was meaning to ask about the try/except around fcntl...do we have folks running api_test.py on windows?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not, but any editor with code completion will load the modules.

@dlech
Copy link
Copy Markdown
Member

dlech commented Oct 3, 2017

Since python is a dynamic language, we could use that list (during import) to create properties corresponding to the buttons inside Button class.

(Warning, getting a bit off topic here)

👍 for taking advantage of dynamic nature of python to adapt to platforms, but I think I would rather see a single function that works for all buttons rather than identical functions/properties for each button. For example, I have a USB keypad that I can use for BrickPi/PiStorms that has the essential 6 EV3 buttons plus a bunch more. If I wanted to take advantage of other buttons, say the 10 numeric digits, then I would have to write 10 functions, one to handle each button. Whereas, if the button key code is just passed as a parameter, then I just have to write one function with a bunch of elifs.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Working on LEDs now...

@dwalton76
Copy link
Copy Markdown
Collaborator Author

LEDs are cleaned up, I tested them on EV3 and tried testing on pistorms but ran into ev3dev/ev3dev#978

I think this is far enough along to merge and then we can tackle anything else via separate issues. Will merge tomorrow unless folks want me to hold off.

@dwalton76
Copy link
Copy Markdown
Collaborator Author

Also resolves #379

@dwalton76 dwalton76 merged commit 5e33dff into ev3dev:develop Oct 4, 2017
@dwalton76 dwalton76 deleted the file-musical-chairs branch October 4, 2017 11:32
@dwalton76 dwalton76 mentioned this pull request Oct 4, 2017
@ddemidov
Copy link
Copy Markdown
Member

ddemidov commented Oct 4, 2017

We could put a board-info file into ddemidov/ev3dev-lang-fake-sys

cool, @ddemidov can you add that? I haven't done much with ev3dev-lang-fake-sys

Done in ev3dev/ev3dev-lang-fake-sys@61d8ded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants