Help?

C
Andrew Kohlsmith wrote:

> > moment. And using an array with a write that checks for length, while
> > possibly not as space efficient as a struct, (although you'ld have to look
> > at the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation. After
>
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way too
> common in ModBUS packet data.

Agreed, the code I sent deals with ascii.

> I'm a big proponent of KISS -- the stupider your software, the less chance
> it has of biting you in the ass. But as Einstein said, "Things should be
> made as simple as possible -- but no simpler." Using string functions for
> binary data is breaking this rule.

Also agreed.

> > many years, I have found few instances where absolutely obvious code
> > is improved by obfustication. Also Modbus packets are variable length
> > and the simple code is reusable anyplace you have a file pointer. To do
> > Modbus/TCP you just open a socket and build your packet a little
> > differently. And yes, there probably should be a few (unsigned char) in
> > there but it's readable and it works. I compiled and ran it before I sent
> it.
>
> I agree with you that things should be simple (see above) -- At the same
> time though I must speak out when you claim that using structs and/or unions
> over array data is too complex. I can read all the data into a struct with
> a simple file pointer, just as you can. However my data is now structured;
> I can pull out the address or checksum or specific structured elements
> without resorting to pointer arithmetic or clunky #DEFINEs. Avoiding arrays
> because of possible padding issues is silly. Everyone was a newbie at one
> time; how do you learn?

I agree here too.. But, whose code is easier for a BASIC programmer to understand. And unions over array data, which declaring a struct on top of it would be, are much less than obvious. Everyone understands arrays and array ops. Of course it is
pointers under the covers and I often use both for convenience. The machine code generated is
probably identical. But the array ops are much more readable and understandable for someone coming from BASIC. For code that is to be shared, I try to make it obvious and I'm sufficiently secure that I don't mind being picked apart. I could rewrite the whole thing with pointers and even hex or binary constants to replace the silly defines in the header files but, I wouldn't be doing the person I wrote it for any favor. The reason I sent that particular hack is that I wrote it to show another programmer how to use the Matrix Orbital display and keypad. I am not a CS type, I write bonehead C because I have a lot of it around that I very infrequently look at and it helps me to be
able to jump back in quickly and easily. When I move on, it will help the poor soul who has to understand it immeasurably. Ten years ago, I used to write very terse code to fit in very small places with chunks of assembler to overcome speed issues. That is no longer necessary or in my view advisable unless profiling has shown a problem. I'm better now and have nothing to prove by outguessing the optimizer.

There is a larger issue here, we are writing code that is supposed to be useful to as many people as possible. If we want people to participate, the threshold should be as low as possible without sacrificing function. I find the code in the archive to be pretty tough sledding. I guess that makes me an idiot, but I have much more C
and Linux experience than the great majority of our target audience, the people we want to be able to use, study, and contribute to the code base. I doubt that too many people will want to dig into the core functionality we have so far but, as we move outward towards the user we have to make things a little more accessable or
having open source is of little consequence.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt:
> > And using an array with a write that checks for length, while possibly
> > not as space efficient as a struct, (although you'ld have to look at
> > the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation.

Andrew Kohlsmith:
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way
> too common in ModBUS packet data.

Agreed - definitely.

> But as Einstein said, "Things should be made as simple as possible -- but
> no simpler."

For simplest possible technique, I'd suggest using the buffer directly:

buf[0] = 42; /* first byte */
buf[1] = 86; /* second byte */
buf[2] = 99; /* third byte */

That's got to be simpler than sprintf(3)...


> At the same time though I must speak out when you claim that using
> structs and/or unions over array data is too complex.

Yup.

> I can read all the data into a struct with a simple file pointer, just as
> you can. However my data is now structured; I can pull out the address
> or checksum or specific structured elements

Exactly.

We should watch out for alignment problems, but I don't think I've ever seen gcc align a char. Byte-order is much more likely to bite us.

But do avoid the string functions, they'll do the wrong thing too often.

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Hopfgartner

My 2 cants: It really doesn't matter how the data is allocated in memory, keeping things in structs helps to keep your code readable. Simply provide your struct with "serialization", a read and a write function that generates univoquely a binary string from your struct and your struct from a binary string.

Peter

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Sorry about the `me too' post, but I just wanted to put my name to that.
Peter seems to have made the most sense of us all.

Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

I don't understand: arrays are already stored as serial data so why provide seperate routines that do nothing?

i.e.

typedef struct mystruct
{
char address;
int command;
char data[10];
char crc32;
};

*is* stored as a linear 15-byte array; it's just "organized" -- i.e. I can say mystruct.command instead of (int)data[1].

for read() and write() all you do is provide a pointer to the allocated structure. So long as the ocmpiler didn't decide to align your data you'll be fine (and how to prevent it from doing so has already been discussed). No "(de)serialization" functions are required.

If you want to access the data as a linear array, you can still do so.

i.e.
mystruct *data;

malloc(data, sizeof(struct mystruct));
read(fp, data, sizeof(struct mystruct));

mychecksum = (char *)data[14];
mychecksum = data->crc32;

Those last two lines are functionally equivalent but which is clearer to understand?

Anyway I never intended this to turn into a flame war. I just would prefer not to see the entire project littered with data[8], data[97], data[1], etc just because we want to protect the newbies from learning about arrays and pointers. They're very powerful constructs and if you haven't learned about them, dig in. Hell I was able to teach my brother about doubly linked lists in about an hour. Once past that initial hump it was all very clear. There's no point in keeping newbies newbies. And there's certainly no point
in DAMAGING the readability of code by not using arrays and pointers.

As Curt said (but I'm now paraphrasing and using against him): Open Source is a learning tool. If it's not readable it's useless.

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Well, first of all - no it is most probably not stored as 15 bytes.

It could take 14 bytes - if you have a 16 bit compiler and there is no aligning

It could take 15 bytes - if you have a 16 bit compiler and there is word align

It could take 16 bytes - if you have a 32 bit compiler and there is no aligning

It could take 17 bytes - if you have a 32 bit compiler and there is word align

It could take 21 bytes - if you have a 32 bit compiler and there is dword align

This is what I would expect and intel compiler to do, I would not bet that other compiler don't do it differently


First: never use int if you want to be sure of the size.

Second: as people here have said, there is the problem with aligning and it have to be taken into consideration if you want to store the entire struct in one operation. It would work, but be possibly less portable.

Third: the byte order would make this code behave
differently on different processor architectures.

File and communications formats should really be kept apart from how the information is stored in memory.

/Johan Bengtsson


Btw: you can not store a crc32 in a char, so I suggest either change the name to crc8 or to change the type to long or unsigned long.


Since everyone else have their side notes: does anyone of you know some site where _ can find some nice version of GirlFriend?


----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
This is not a confrontation Andrew, I respect you guys and support you guys and I believe we have better programmers than most in the private sector. I normally wouldn't even rise to the bait, but I am going to, for my own masochistic satisfaction, approach the whole project as a newbie and try to raise questions and communicate observations. The extent to which we can make that experience survivable will determine, in large part, how many people will actually join in our effort.

My only point is that we are not aiming this at universities. My goal is to get more people working on this. I assume we are speaking to the larger issue as that hack is not part of the project. For what it's worth, I still don't regret trying to help the guy. We haven't got any more questions, why do you think
that might be?
We need more programmers. If I am not qualified to contribute, I suspect the pool of potential developers is unworkably small. We are having a real problem with getting people over the hump from wanting to contribute to actually writing code. This is one of the barriers. I'm all ears for your suggestions on how to solve that problem. You won't be able to discourage me because I put myself in the position of being scorched by posting my code and I am the advocate for all the people who wanted to be involved and decided not to. If I had contributed that code, would I do it again? Not very likely. While I am
still very opinionated and very idealistic, I have put much of that aside for the good of the project. I would be extremely happy if we could get to the point where you have aspiring programmers to educate. Me, I'm incorrigable :^)
Help me get talent on board.

Regards

cww

PS I may not be much of a programmer, but I do have a lot of Linux automation code running in production as we speak.


______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> Well, first of all - no it is most probably not stored
> as 15 bytes.

> Second: as people here have said, there is the problem
> with aligning and it have to be taken into consideration
> if you want to store the entire struct in one operation.
> It would work, but be possibly less portable.

Okay let's not get silly here; this is for Linux: that is automatically a 32 bit compiler (even uClinux uses a 32 bit compiler). When the 64 bit
compilers come out we'll discuss that then. But right now that point is moot. Also, I had already discussed alignment issues and how to get around them.

> Third: the byte order would make this code behave
> differently on different processor architectures.

Using arrays would not help this situation, but this point is also moot: the byte order is irrelavent because you must use what the network specifies, regardless of your processor's endianness. Take a look at the TCP/IP code for numerous examples.

> File and communications formats should really be kept
> apart from how the information is stored in memory.

Totally agreed, but how do straight linear arrays avoid any of these problems?

> Btw: you can not store a crc32 in a char, so I suggest
> either change the name to crc8 or to change the type to
> long or unsigned long.

You are of course correct here. A slip of the key on my part, so to speak.

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> This is not a confrontation Andrew, I respect you guys and support you
guys
> and I believe we have better programmers than most in the private sector.
> I normally wouldn't even rise to the bait, but I am going to, for my own
> masochistic satisfaction, approach the whole project as a newbie and try
> to raise questions and communicate observations. The extent to which we
> can make that experience survivable will determine, in large part, how
many
> people will actually join in our effort.

I completely understand the need for more fingers at the keyboard. The question, however, is do we want good code or code that newbies can
understand? Before you hit ^R, read on...

Now my belief is that *both* can be satisfied. Arrays and pointers do NOT get tricky until you really start doing goofy things with them. And if a newbie wants to contribute that is a WONDERFUL thing! But dumbifying the code to the point where anyone who is 10 days into their "Learn C in 21 Days" book can contribute just so they can code is insane in my opinion.
The project will suffer and will become unreadable / unmaintainable. Structure is important!

If they have trouble grasping a concept, let them ask! I regularly have to ask questions of the senior engineers here because I simply don't know. But instead of reducing the project to something that anyone could work on they instead explain the one hitch or two that I couldn't get past and now not only am I smarter for asking, but the project doesn't suffer. (... and in a
couple weeks I'm on another hitch but that's what the process is all about.)

I didn't mean for my initial comment to turn into this big flame out. In fact I think this may be my last post on this matter. All I am humbly
suggesting is that the "cut off" point for programmers be someone with at least basic knowledge of C. Arrays, in my opinion, are basic knowledge of C. Advanced pointer arithmetic? Surely not. We're not asking for doubly-linked lists or balanced trees though; I'm just asking that we don't do everything in linear char arrays. It's the old hammer / nail saying.

> My only point is that we are not aiming this at universities. My goal is
to get
> more people working on this. I assume we are speaking to the larger issue
as
> that hack is not part of the project. For what it's worth, I still don't
regret
> trying to help the guy. We haven't got any more questions, why do you
think
> that might be?

Agreed. Totally agreed. I'm not asking that we use the latest and greatest coding techniques and algorithms. (Hell I don't agree with some of them
either but I digress.) There's no need for that. There's no need to hand-code in assembly. There's no need for this arguement. (? This is a
pretty calm arguement, heh) I am not condemning you for helping anybody!

> We need more programmers. If I am not qualified to contribute, I suspect
> the pool of potential developers is unworkably small. We are having a real
> problem with getting people over the hump from wanting to contribute to
actually
> writing code. This is one of the barriers. I'm all ears for your
suggestions on
> how to solve that problem. You won't be able to discourage me because I
put
> myself in the position of being scorched by posting my code and I am the
> advocate for all the people who wanted to be involved and decided not to.

I think part of this problem is that there is a large number of people who can do ladder logic and the higher level stuff waiting to use LinuxPLC but don't have the lowlevel know-how in order to help it to that point. I would FAR rather bring these people up to speed on certain aspects of C programming than I would bring the whole project to their current level of
comprehension of the C language. It might take a bit longer but the code base will be far better for it.

> If I had contributed that code, would I do it again? Not very likely.
While I am
> still very opinionated and very idealistic, I have put much of that aside
for
> the good of the project. I would be extremely happy if we could get to
the point
> where you have aspiring programmers to educate. Me, I'm incorrigable :^)
> Help me get talent on board.

As far as educating new programmers: I never said that's what I wanted to do: I'm just a grizzled old embedded C/asm programmer with too much time at my day job to read LinuxPLC. :) I would certainly help anyone who asked though.

Now if I were someone new to something and I knew that I didn't know everything, I would *expect* criticism on my contributed code. Would I
stop? If it became overwhelming, maybe. But I don't remember blasting anyone; I do remember backing up someone else's comment on how arrays are better suited to a specific type of problem.

Take uClinux for example: I *am* a newbie in this area. Kernel programming is challenging as hell, even when you have multiple architectures to go from. How am I learning it? I'm "forward-porting" uClinux-2.4 to the MCF5206 processor. The old 2.0.36 source worked beautifully on this
processor but there are a LOT of lowlevel changes between 2.0 and 2.4 and I've decided that the best way to learn lowlevel kernel programming is to forward port this.

Do I assume that what I'm doing is being done right? Hell no, I have asked countless questions, tinkered with endless bits of code and hit that damn reset button far more than I have wanted to. Do I get discouraged? Sometimes; I usually can only work on this kind of stuff at the end of the day and after the kids are in bed. So I'm already tired and a little grumpy. :) But in the same vein I don't expect the uClinux kernel hackers to say "That's alright, we'll let your newbie code into the core
anyway" -- I expect them to help bring me up to their level so that my code can stand alongside theirs and be as robust and *right* as possible. That means unlearning some things and relearning the right way to do things.

It's the same in this area (at least from my point of view) -- I am *personally* very happy that there are people who don't have all the
knowledge but yet want to take a crack at getting their name in the credits. To me, however, they must get themselves up to speed so that their code
meets certain standards I've come to like in the software industry. Getting up to speed involves hacking out code, putting it up for display and hearing people call bits and pieces ugly and other pieces art. It involves criticism and encouragement and trial and error and lots and lots of compiler time. Now I fully realize that I'm not the project lead and therefore my standards don't have much pull, but in an open mailing list I will certainly try and encourage them to do things the right way -- the
professional way -- so that they learn correctly instead of thinking that they do know it all. In effect I'll try and indoctrinate my standards on
others. This in iself gathers a lot of criticism (of my standards) and I often find that I'll end up raising them even higher because I learn new
things. Is this a bad thing?

I am very much a "throw me in the lake to learn to swim" kind of person; that's how I seem to pick up new ideas and technologies best. I suppose what you're seeing in my postings to the list is that type of mentality. "Get some code out there and be prepared to take notes on how to make it better." or, more broadly, "You have the opportunity to fail."

> PS I may not be much of a programmer, but I do have a lot of Linux
automation
> code running in production as we speak

I've never questioned your abilities as a programmer. Code which works is better than elegant code which doesn't, but should we not all strive for excellence?

Anyway I've already written too much. I hope that this clears up my standpoint on this (and I guess in life in general) and helps to AVERT some
flamage.

Regards,
Andrew

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Andrew Kohlsmith wrote:
>
> > This is not a confrontation Andrew, I respect you guys and support you
> guys
> > and I believe we have better programmers than most in the private sector.
> > I normally wouldn't even rise to the bait, but I am going to, for my own
> > masochistic satisfaction, approach the whole project as a newbie and try
> > to raise questions and communicate observations. The extent to which we
> > can make that experience survivable will determine, in large part, how
> many
> > people will actually join in our effort.
>
> I completely understand the need for more fingers at the keyboard. The
> question, however, is do we want good code or code that newbies can
> understand?

***YES***

Before you hit ^R, read on...

I did.


>
> Now my belief is that *both* can be satisfied. Arrays and pointers do NOT
> get tricky until you really start doing goofy things with them. And if a
> newbie wants to contribute that is a WONDERFUL thing! But dumbifying the
> code to the point where anyone who is 10 days into their "Learn C in 21
> Days" book can contribute just so they can code is insane in my opinion.
> The project will suffer and will become unreadable / unmaintainable.
> Structure is important!

For code, or building a cathedral?

>
> If they have trouble grasping a concept, let them ask! I regularly have to
> ask questions of the senior engineers here because I simply don't know. But
> instead of reducing the project to something that anyone could work on they
> instead explain the one hitch or two that I couldn't get past and now not
> only am I smarter for asking, but the project doesn't suffer. (... and in a
> couple weeks I'm on another hitch but that's what the process is all about.)

Most volunteers won't ask, especially if their hair is singed, they just go away.

> I didn't mean for my initial comment to turn into this big flame out. In
> fact I think this may be my last post on this matter. All I am humbly
> suggesting is that the "cut off" point for programmers be someone with at
> least basic knowledge of C. Arrays, in my opinion, are basic knowledge of
> C. Advanced pointer arithmetic? Surely not. We're not asking for
> doubly-linked lists or balanced trees though; I'm just asking that we don't
> do everything in linear char arrays. It's the old hammer / nail saying.
>

Right now, I'd take a ladder editor if it was written in BASIC.

> > My only point is that we are not aiming this at universities. My goal is
> to get
> > more people working on this. I assume we are speaking to the larger issue
> as
> > that hack is not part of the project. For what it's worth, I still don't
> regret
> > trying to help the guy. We haven't got any more questions, why do you
> think
> > that might be?
>
> Agreed. Totally agreed. I'm not asking that we use the latest and greatest
> coding techniques and algorithms. (Hell I don't agree with some of them
> either but I digress.) There's no need for that. There's no need to
> hand-code in assembly. There's no need for this arguement. (? This is a
> pretty calm arguement, heh) I am not condemning you for helping anybody!

You'll know when I'm arguing with you. This is a discussion, and an important one.

> > We need more programmers. If I am not qualified to contribute, I suspect
> > the pool of potential developers is unworkably small. We are having a real
> > problem with getting people over the hump from wanting to contribute to
> actually
> > writing code. This is one of the barriers. I'm all ears for your
> suggestions on
> > how to solve that problem. You won't be able to discourage me because I
> put
> > myself in the position of being scorched by posting my code and I am the
> > advocate for all the people who wanted to be involved and decided not to.
>
> I think part of this problem is that there is a large number of people who
> can do ladder logic and the higher level stuff waiting to use LinuxPLC but
> don't have the lowlevel know-how in order to help it to that point. I would
> FAR rather bring these people up to speed on certain aspects of C
> programming than I would bring the whole project to their current level of
> comprehension of the C language. It might take a bit longer but the code
> base will be far better for it.

And I would rather see a reasonable compromise or more importantly, consideration going forward.

> > If I had contributed that code, would I do it again? Not very likely.
> While I am
> > still very opinionated and very idealistic, I have put much of that aside
> for
> > the good of the project. I would be extremely happy if we could get to
> the point
> > where you have aspiring programmers to educate. Me, I'm incorrigable :^)
> > Help me get talent on board.
>
> As far as educating new programmers: I never said that's what I wanted to
> do: I'm just a grizzled old embedded C/asm programmer with too much time at
> my day job to read LinuxPLC. :) I would certainly help anyone who asked
> though.

Great, you have a skill set that we could really use! What can I mark you down for?

> Now if I were someone new to something and I knew that I didn't know
> everything, I would *expect* criticism on my contributed code. Would I
> stop? If it became overwhelming, maybe. But I don't remember blasting
> anyone; I do remember backing up someone else's comment on how arrays are
> better suited to a specific type of problem.
>
> Take uClinux for example: I *am* a newbie in this area. Kernel programming
> is challenging as hell, even when you have multiple architectures to go
> from. How am I learning it? I'm "forward-porting" uClinux-2.4 to the
> MCF5206 processor. The old 2.0.36 source worked beautifully on this
> processor but there are a LOT of lowlevel changes between 2.0 and 2.4 and
> I've decided that the best way to learn lowlevel kernel programming is to
> forward port this.
>
> Do I assume that what I'm doing is being done right? Hell no, I have asked
> countless questions, tinkered with endless bits of code and hit that damn
> reset button far more than I have wanted to. Do I get discouraged?
> Sometimes; I usually can only work on this kind of stuff at the end of the
> day and after the kids are in bed. So I'm already tired and a little
> grumpy. :) But in the same vein I don't expect the uClinux kernel
> hackers to say "That's alright, we'll let your newbie code into the core
> anyway" -- I expect them to help bring me up to their level so that my code
> can stand alongside theirs and be as robust and *right* as possible. That
> means unlearning some things and relearning the right way to do things.
>
> It's the same in this area (at least from my point of view) -- I am
> *personally* very happy that there are people who don't have all the
> knowledge but yet want to take a crack at getting their name in the credits.
> To me, however, they must get themselves up to speed so that their code
> meets certain standards I've come to like in the software industry. Getting
> up to speed involves hacking out code, putting it up for display and hearing
> people call bits and pieces ugly and other pieces art. It involves
> criticism and encouragement and trial and error and lots and lots of
> compiler time. Now I fully realize that I'm not the project lead and
> therefore my standards don't have much pull, but in an open mailing list I
> will certainly try and encourage them to do things the right way -- the
> professional way -- so that they learn correctly instead of thinking that
> they do know it all. In effect I'll try and indoctrinate my standards on
> others. This in iself gathers a lot of criticism (of my standards) and I
> often find that I'll end up raising them even higher because I learn new
> things. Is this a bad thing?
>
> I am very much a "throw me in the lake to learn to swim" kind of person;
> that's how I seem to pick up new ideas and technologies best. I suppose
> what you're seeing in my postings to the list is that type of mentality.
> "Get some code out there and be prepared to take notes on how to make it
> better." or, more broadly, "You have the opportunity to fail."
>
> > PS I may not be much of a programmer, but I do have a lot of Linux automation
> > code running in production as we speak
>
> I've never questioned your abilities as a programmer. Code which works is
> better than elegant code which doesn't, but should we not all strive for
> excellence?
>
> Anyway I've already written too much. I hope that this clears up my
> standpoint on this (and I guess in life in general) and helps to AVERT some
> flamage.
>
> Regards,
> Andrew

Don't think that I don't appreciate your viewpoint or that I'll even remember this next time we communicate. I simply am trying to deal with a less than ideal world and need more workable solutions than theory. My personal views on coding are secondary to what the project needs.

Peace,

cww
>
> _______________________________________________
> LinuxPLC mailing list
> [email protected]
> http://linuxplc.org/mailman/listinfo/linuxplc
 
C
We need programming and configuration tools, drivers, a generalized HMI, languages, flash memory facilities, whatever you want to do we can
accommodate you. In the meantime, spread the word in your circles that we could use C programmers and people with flex and bison experience. If all
our lurkers could just do that, we'll raise the body count.

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> > The project will suffer and will become unreadable / unmaintainable.
> > Structure is important!
> For code, or building a cathedral?

Both, actually. I've seen far too many experienced programmers driven by poor management and end up with disgustingly unmaintainable code.

[aside -- have you ever seen spaghetti C++ code? I didn't think it was possible until I had to clean it up.]

> Most volunteers won't ask, especially if their hair is singed, they just
> go away.

Hmmm... It sounds like they wouldn't have the gumption to be a maintaner anyway. It sounds pretty cynical but if they're gonna drop off like a bride's nightie their help won't be any help at all.

> Right now, I'd take a ladder editor if it was written in BASIC.

Noted.

> > don't have the lowlevel know-how in order to help it to that point. I
would
> > FAR rather bring these people up to speed on certain aspects of C
> > programming than I would bring the whole project to their current level
of
> > comprehension of the C language. It might take a bit longer but the
code
> > base will be far better for it.

> And I would rather see a reasonable compromise or more importantly,
> consideration going forward.

"consideration going forward" -- I don't understand this term...

You're right; there will have to be some compromise; And as people get up to speed and learn the what-to-do and what-not-to-dos, parts of the code will be rewritten and made "more better" as the project matures.

My comments about structure and ideals were more about what the "coding style" should be like, rather than a criticism on any individual module or alpha code. There is always room for improvement; I was just trying to say that "first run" or "functional prototype" code shouldn't be accepted as golden when obvious or newbie (from a fluent C standpoint) mistakes / techniques were used.

I'm not trying to stave off development. I'm just trying to prevent mediocre from being the norm.

> Great, you have a skill set that we could really use! What can I mark
> you down for?

As soon as I get some of my contract work off my plate I'd love to take a crack at the ladder logic entry. I'm not particularly good at UI (embedded means never having to make it human-pretty <g>) but I think I could do something which would work quite nicely.

Seeing as how you need that *now* though, I don't want to leave you in a lurch. Is there a list of what's needed somewhere?

> Don't think that I don't appreciate your viewpoint or that I'll even
> remember this next time we communicate. I simply am trying to deal with
> a less than ideal world and need more workable solutions than theory.
> My personal views on coding are secondary to what the project needs.

As stated in my previous paragraph: do you have a list of what's needed (however lengthy it may be at this point)? I briefly visited the linuxplc.org website and it looks like you have a lot of the base functionality laid out and have a clear direction for where you want to go with the project. That's more than a lot of projects have. Remember that just because it isn't progressing at Internet Time doesn't mean that it's all bad. :)

Regards,
Andrew


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Ok, I admit I got carried away by the example. I think everyone have got the point by now, if not before....

Sorry if I sounded too negative, that was not really my intent...


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
We need programming and configuration tools, drivers, a generalized HMI, languages, flash memory facilities, whatever you want to do we can
accommodate you. In the meantime, spread the word in your circles that we could use C programmers and people with flex and bison experience. If
all our lurkers could just do that, we'll raise the body count.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mark Woudenberg

The documentation for the Synet communication is still available round hear if your interested.
 
Mike,

To reuse the Sq d sy-max you will need the sfw374 program and a security key (dongle). You will also need a sq d interface to hook from your computer to channel 1 on the processor. I maintain 6 of these beast at my place of emoloyment every day. Feel free to email me if you have questions.

Don
 
Top