# developer questions

G

#### Greg Goodman

To whom does one apply for a cvs login? Alternatively, to whom might one submit contributed code? I've written a loadable Tcl extension for interacting with the LPLC, along with a couple of scripts (including a Tk interface to the chaser demo). I also have a question about the proper handling of bug reports and change requests. That is, I have some complaints and suggestions regarding the implementation of plc_init() and the resolution of config files, but do not think it appropriate to change the system spec or code unilaterally. Does control.com have a bug tracking system that PuffinPLC plans to use for numbering bugs and tracking their states? And if the mailing list is the only forum for reporting and tracking bugs, do we have a "Subject:" header convention for distinguishing bug reports from other discussions? Other than perusing the comments in the source code, is there a published "to do list" of things that have already been identified as needing attention? By this, I do not necessarily mean new features, but areas where cleanup or improved robustness are needed. Greg Goodman Chiron Consulting [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

Hi Greg Good start! Code looms large. I believe Dan Pearson is the keeper of the keys. Then put your stuff in a directory and the other guys can get a look at it. Questions and complaints can be aired right here. We're not swamping the archive. I am most interested in your Tcl Stuff. We've got Ncurses and Vitrine, but I think a scripting language is more likely to attract user development. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Greg Goodman: > To whom does one apply for a cvs login? Alternatively, to whom might > one submit contributed code? I've written a loadable Tcl extension for > interacting with the LPLC, along with a couple of scripts (including a > Tk interface to the chaser demo). Any of the active / semi-active developers. If you send it to me I'll put it in for you. I assume you want it to become a part of LPLC? That is, LPLC will be the primary place for this piece of code? > I also have a question about the proper handling of bug reports and > change requests. Right now, nothing, really. Send them to the mailing list, there's no convention yet about subjects and things. We'll have to deal with that somehow once we get more of those coming in... > Other than perusing the comments in the source code, is there a > published "to do list" of things that have already been identified as > needing attention? By this, I do not necessarily mean new features, but > areas where cleanup or improved robustness are needed. There are occasional TODO files in the individual directories (or TODO sections in the READMEs), but there's no central one. I guess that'll be part of the bug-tracking system once we put one in place. For now, if we have something like that, I guess it goes in doc/TODO (just make it a text file). Jiri _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

Greg Goodman wrote: > > Other than perusing the comments in the source code, is there a > published "to do list" of things that have already been identified as > needing attention? By this, I do not necessarily mean new features, but > areas where cleanup or improved robustness are needed. > Hi Greg, One area I would like to have cleaned up, but have yet to find the time to, is the smm library. It uses its own code for linked lists/arrays/??? (sorry, can't remember offhand), and we have more code to do almost the exact same thing under the /lib/misc directory. It seems there are also standard C libraries that have this implemented too. Maybe you would like a go at this? Improved robustness: going through all the code that uses the configuration file and adding more consistincy checks and more understandable error logging. If you want to work on new features, may I sugest support for online changes. I have an idea of how to go about it (it's mentioned in passing in the /doc/lplc-article.txt file), that would entail slight additions to the code of every existing module. Hoping to hear from you! Cheers, Mario. -- ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Curt Wuollet: > Code looms large. I believe Dan Pearson is the keeper of the keys. Then > put your stuff in a directory ... I'd suggest a lang/tcl directory for this - we don't as yet have support for languages other than the native C, but I think that'd be the right place for it. What do you guys think? Is that a good place for it? > but I think a scripting language is more likely to attract user > development. A lisp interface might also be good - a lot of engineers know it - but unfortunately my lisp is close to non-existent. We should have C++ just so we are OO, but it's partly trivial and partly not all that useful. Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

Jiri Baum wrote: > > Curt Wuollet: > > Code looms large. I believe Dan Pearson is the keeper of the keys. Then > > put your stuff in a directory > ... > > I'd suggest a lang/tcl directory for this - we don't as yet have support > for languages other than the native C, but I think that'd be the right > place for it. > > What do you guys think? Is that a good place for it? Why do we have to keep programing languages under separate top level directories? Our current cvs structure is organised into functionality, and not programing language. I think the code should go into a directory depending on functionality, and not programing language. Programming language should be (mostly) irrelevant. What did Greg really write? Is it a tcl based graphic interface? Then I think it should go under the mmi/tcl directory. Mario. ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

G

#### Greg Goodman

Jiri: > I assume you want it to become a part of LPLC? That is, LPLC will be the > primary place for this piece of code? Yes. As this code implements Tcl commands that wrap certain parts of the LPLC 'C' API, it has no value other than as a component of the LPLC. > > I also have a question about the proper handling of bug reports and > > change requests. > > Right now, nothing, really. Send them to the mailing list, there's no > convention yet about subjects and things. Coming up. Curt: > I believe Dan Pearson is the keeper of the keys. I talked to Dan and got a login. I'll commit to the CVS as soon as possible. > Code looms large. That's why I wrote it. It was something I could do, it's something I and others may find useful, it helps establish my bona fides as someone who knows what he's talking about, and it buys me the right to say how I think things should be. Jiri & Mario: > > I'd suggest a lang/tcl directory for this - we don't as yet have support > > for languages other than the native C, but I think that'd be the right > > place for it. > > > > What do you guys think? Is that a good place for it? > > Why do we have to keep programing languages under separate top > level directories? Our current cvs structure is organised into > functionality, and not programing language. I think the code > should go into a directory depending on functionality, and not > programing language. Programing language should be (mostly) > irrelevant. > > What did Greg really write? Is it a tcl based graphic interface? > Then I think it should go under the mmi/tcl directory. The bulk of what I wrote is a dynamically loadable extention to Tcl that implements native Tcl commands to connect to the LPLC and get and put values. (There's more to write, but that was enough to allow me to write functional scripts.) That's all 'C' code that conforms to the Tcl Extension Architecture and makes calls into linuxplc.a. I also wrote a couple Tcl scripts that use the new commands. One script is a generic PLC monitor (sort of a "plctest -d" with a GUI and an update frequency). The other implements a GUI for the chaser demo (labelled "lights" that change color and buttons to change the direction). I think the extension belongs in a tcl or a lang/tcl directory; it's an API, not a specific functionality. scripts are application-level functionality, and go where they go: the generic monitor into mmi/tcl, and the chaser gui into demo/basic. Regards, Greg Goodman Chiron Consulting [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

C

#### Curt Wuollet

> > Code looms large. > > That's why I wrote it. It was something I could do, it's something I > and others may find useful, it helps establish my bona fides as someone > who knows what he's talking about, and it buys me the right to say how I > think things should be. I'll try to read it. Although I have wanted to learn tcl/tk and family, it seems as if there isn't much free material and I haven't had time lately. I am quickly becoming without credentials and have had to content myself with peripherals and PR. I have had to read the great article by the programming guys to know what's going on. On that note, you guys could cc the list a bit more. Pretty soon I'll know nothing about it. Then I suppose I'll have to go into sales. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Jiri Baum: > > I'd suggest a lang/tcl directory for this - we don't as yet have > > support for languages other than the native C, but I think that'd be > > the right place for it. > > What do you guys think? Is that a good place for it? Mario de Sousa: > Why do we have to keep programing languages under separate top level > directories? Our current cvs structure is organised into functionality, > and not programing language. Yes, of course - I was under the impression that the functionality here was using the LPLC from the Tcl language'. The lang directory would be basically wrappers around the LPLC library for other languages, and maybe some language-specific convenience routines. Things written *in* those other languages go under logic or mmi or io or whatever, as appropriate. > What did Greg really write? Is it a tcl based graphic interface? Then I > think it should go under the mmi/tcl directory. Definitely - but the parts that enable things in general to be written in tcl should go in lang/tcl (a fine line sometimes, I guess). Similarly we might have a lang/cpp directory that would have an object-oriented wrapper for the lplc library (I should really write one, one of these days). Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

M

#### Mario de Sousa

Jiri Baum wrote: > > Yes, of course - I was under the impression that the functionality here was > using the LPLC from the Tcl language'. Yep. It seems it was _my_ first impression that was wrong! > > The lang directory would be basically wrappers around the LPLC library for > other languages, and maybe some language-specific convenience routines. > > Things written *in* those other languages go under logic or mmi or io or > whatever, as appropriate. I completely agree now. Sorry for raising all the confusion... :-( Cheers, Mario. -- ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

Mario de Sousa: > I completely agree now. Sorry for raising all the confusion... > :-( No worries. Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

J

#### Jiri Baum

> Jiri: > > I assume you want it to become a part of LPLC? That is, LPLC will be > > the primary place for this piece of code? Greg Goodman: > Yes. OK. > Jiri & Mario: > > > I'd suggest a lang/tcl directory for this ... > > What did Greg really write? Is it a tcl based graphic interface? Then > > I think it should go under the mmi/tcl directory. > The bulk of what I wrote is a dynamically loadable extention to Tcl that > implements native Tcl commands to connect to the LPLC and get and put > values. Good - that's what I thought you were talking about... > I think the extension belongs in a tcl or a lang/tcl directory; it's an > API, not a specific functionality. Yup - I prefer the two-level variant, because we'll probably have other languages in the future. > scripts are application-level functionality, and go where they go: the > generic monitor into mmi/tcl, and the chaser gui into demo/basic. Yup. BTW, I'm not sure that setpt and getpt should call plc_update(); in fact, they probably shouldn't, to keep with the PLC-style semantics. (However, an option to call plc_update_point() would make sense.) Jiri -- Jiri Baum <[email protected]> Connect the power cable, interface cable and ground wire only in the methods indicated in the this manual. It may lead to fire. -- OKIPAGE 8z user's manual _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc