Coding/testing guidelines?

samy · 2009-07-21 18:31:52

Hey guys,

I don't think we need any hardcore coding/testing guidelines at this point in the pm3 project, but I do think we should at least make a couple of simple guidelines that we all agree upon to just keep the project going in the right direction. I don't see any reason for red tape, but maybe just a few guidelines we can agree to follow.

I see more and more we end up with different compilation problems between the Windows and Linux clients (I've created compilation issues myself). Obviously we don't all have access to both OS's, but I'd like to keep our code base pretty clean and ensure support on both (and even OS X if possible). Mainly I'd like to prevent checkins of code that don't compile on both primary OS's.

I would be happy to provide shell access to a Linux box to the developers if you guys can just test compiling on there. I can also provide an OS X shell but it won't always be available (laptop). If Google Code's SVN supported hooks, I would just hook it in entirely if possible so check-ins will auto-test compilation. Do you guys know if they support this?

Also, the only other guidelines I think we need to set are the following:
- any source code that can be beneficial in any sort of stand-alone mode (basically anything *not* related to plotting) should be built into the ARM, not the GUI/UI [the old code we can just slowly start porting over, no need to do it all at once]
- any new functions or adjustments to functions should be documented within the wiki
- document code in general

What do you guys think, does this sound reasonable?

Also, any suggestions on automating or helping prevent code check-ins that don't compile in one OS or the other? I do want to keep this a very simple process and prevent much overhead for the developers. We should essentially have a single command that we can run that will test the entire process in both Win32 and Linux, and return yay or nay.

Last edited by samy (2009-07-21 18:33:50)

adam@algroup.co.uk · 2009-07-21 18:45:19

Without access to both windows and linux dev environments it's almost impossible to be sure any change is not going to affect the other... It would be nice to make sure it works in both before doing so, I don't think it's a good idea to prevent committing code that hasn't yet been tested in the other environment. The repo is by definition a development environment - if you want stable/tested, you need to stick to binaries. I expect a repo checkout to break things and if it's within my power I will try to fix it. The new grid command is a good example - it broke the linux compile, so that meant a linux developer needed to step in and fix it. That in turn broke the windows compile so we had to do another iteration. All sorted in a few hours, so not a biggy!

samy · 2009-07-21 18:53:51

Adam,

I totally agree -- with no access, we can't test it! I'm thinking if we have any dedicated systems setup, we should create a simple script that can upload our source to both a Linux and Windows environment, compile (just to test that it compiles), and returns any errors.

I'm happy to set this up for the Linux environment, so maybe I'll set this up and at least Windows developers can start testing on Linux without any major work (again, it should be as simple as ./test). I test my stuff in Windows but it's in Parallels on my laptop so it's not usually available for others to test on.

I'll try setting this up and see if it's a good method or not. Happy to scrap it if it sucks

d18c7db · 2009-07-22 02:53:11

samy wrote:

Hey guys,
- any source code that can be beneficial in any sort of stand-alone mode (basically anything *not* related to plotting) should be built into the ARM, not the GUI/UI [the old code we can just slowly start porting over, no need to do it all at once]

It's a little more complicated than that. I agree that as much as possible useful code should make it's way to the ARM for those wishing to run in untethered mode, but I personally find it quite useful to have processing code in the client that can run offline (without the board attached). One of the reasons I wrote fskdemod was that I wanted to take raw capture files, load them in the client and decode them there. Thechnically by your definition fskdemod is redundant as we have hidfskdemod and should be deleted

samy · 2009-07-22 03:06:22

d18,

Damn, you make a really good point and I do agree there.

Maybe we need a shared source between the client and ARM? I just would hate to have duplicate code in the ARM and client for some of this stuff.

Thoughts?

kazola · 2009-07-22 11:48:42

Wow, just this morning I was thinking in contributing in the PM3 community and I was questioning myself...

- Windows or Linux?
- When do people put code in UI or in Firmware?

I hope I can start in helping somehow. From your point of view... which system do I prepare? Right now I'm preparing the Windows build environment but I have no inconvenient in working in VMWare environments... or perhaps pure Linux installations to avoid possible problems?

I'll be waiting for your answers, preferences, advices! Thanks a lot! I hope we can share some efforts and tests

Sorry for my English, I'm from Catalonia!

----------------------------
Catalonia is not Spain

d18c7db · 2009-07-22 12:55:31

Choose whichever platform you feel more comfortable in

henryk · 2009-09-01 00:33:26

Since this is SVN, branches and merges are somewhat painful so I would recommend against them. However, tags at stable points are a good idea and I will set one at the next opportunity when preparing a set of stable official binaries. However, I want to have some sanity checking in the Flash code first before designating the next set of images fit for mass consumption.

Proxmark3 community

Announcement

#1 2009-07-21 18:31:52

Coding/testing guidelines?

#2 2009-07-21 18:45:19

Re: Coding/testing guidelines?

#3 2009-07-21 18:53:51

Re: Coding/testing guidelines?

#4 2009-07-22 02:53:11

Re: Coding/testing guidelines?

#5 2009-07-22 03:06:22

Re: Coding/testing guidelines?

#6 2009-07-22 11:48:42

Re: Coding/testing guidelines?

#7 2009-07-22 12:55:31

Re: Coding/testing guidelines?

#8 2009-09-01 00:33:26

Re: Coding/testing guidelines?

Board footer