M
Jiri Baum wrote:
> Hello,
>
> > > > I remeber you saying that points may not overlap, but I think we
> > > > should allow it for read points
>
> > > No problem - points may not overlap in the config file, partly because
> > > it's confusing, partly to prevent different permissions to be assigned
> > > to the same bits. Actual point handles may overlap as much as desired.
>
> > > (Already it's possible and OK to get any number of handles to a point.)
>
> > > > For write points, also allow overlap,
>
> > > I don't even mind an overlapping mixed read-write point, as long as the
> > > programmer knows what he's doing. However, I reserve the right to doubt
> > > that the programmer knows what he's doing in this case
>
> > OK. I see where you are getting at. Do not allow any kind of overlap in
> > the config file (actually it is easier to check for this in
> > mgr_load_confmap(), and I have it almost implemented), but allow for any
> > kind of overlap in point handles obtained through plc_get_pt_by_loc(), as
> > long as the ownership is not touched.
>
> Exactly.
>
> Basically, my reasoning goes like this:
>
> The point handles access the private map; each module is welcome to
> scribble all over its private map if it feels like it. (Though it's not
> necessarily a good idea to do so.)
>
> The config defines access to the global map; that has to be strict.
>
> [...]
> > > > Example of overlapping read points: Module A is a function often used
> > > > in several programs, and requires at least one input value. It is
> > > > written as using a general point Pinput as its input value. When this
> > > > function is integrated in a larger program, this point is defined as
> > > > overlapping the point that will be used as the real input point.
>
> > > This should probably be handled by putting the name of the point in the
> > > config. I guess that means new conffile_get_value/table_pt()
> > > functions... (Or plc_pt_by_conf(), I don't know.)
I favour
plc_pt_t conffile_get_value/table_pt();
But I don't really think this is at all necessary. Pls see below why.
> > > If you just use a single pre-defined name, you have the problems of
> > > - namespace pollution: no end-user and no other module may use that
> > > name, even to mean something completely unrelated.
> > > - no reentrancy: you cannot run Module A twice.
>
> > > With configurable point names, you have separate sections, and if you want
> > > to run a module twice you use the --PLCmodule switch to tell the two copies
> > > to use different sections.
>
> > OK. Well put.
>
> > But I was considering a module written in a higher level language (like
> > the IL compiler).
>
> For end-programmer written programs, it's the end-programmer's problem.
>
> For libraries, this will be just one of many problems we have to solve - IL
> doesn't lend itself all that fabulously to modularization, as far as I see.
> Whatever program is using the library will have to cope with that (provide
> actual points for the formal points used in the library).
>
> For pre-supplied programs-
>
> > This means the higher level language will have to contain 'macros' to
> > specify that the real name of a point should be obtained from the config
> > file.
>
> Yes, that's probably the best solution. It'll need those macros for tuning
> parameters, anyway (so that process constants can be read from the config).
>
> [...]
>
> > I don't think we will require any conffile_get_value/table_pt()
> > functions. Point names are just text strings, so we can go from there.
>
> Just for convenience - getting a point handle is a specific-enough task
> that it's possible to make sensible error messages; for instance, every
> time a point is taken from the config, there is the possibility of the
> error message "value VARNAME in section SEC should be a point name but it
> is `VALUE' which is not a point nor alias" (or words to that effect).
>
> (The logging policy should say how to refer to config values. Actually, the
> documentation policy should say that.)
>
> Even if it's just to encapsulate the five lines of code into one function
> it's worth it, because most of the code will be error-checking, and it's
> far too tempting to skimp on it.
OK. Here's why I don't think it is necessary:
plc_pt_t conffile_get_value_pt(const char *mod, const char *name) {
plc_pt_t p = plc_pt_by_name(conffile_get_value(mod, name));
if (p.valid == 0) plc_log_errmsg(...);
return p;
}
The code that calls this function will also have to verify if (p.valid == 0) again. There is no way we can let the main prog skimp on error checking. And the error message that the main prog will log will probably be more informative (ex. could not find point xxx, using default yyy).
Maybe later it might come in useful, but for now I can't see it's use.
> > > I'm for the "alias" syntax. That makes it clear what's going on.
>
> > Yes... agreed.
>
> We theoretically could have module-specific aliases, but it'd be hell to
> debug such a system. If there's demand for them, they could be "mod_alias".
>
> (Maybe put the previous paragraph in a comment somewhere near the alias
> code, so it's not forgotten.)
Module specific aliases requires the confmap to be aware of them, unlike global aliases. I would prefer not to support this, and let the modules work with conffile_get_value() for local aliases.
> > > Also, there should be a function to provide anonymous subaliases.
>
> > Don't think that is really required. Anonymous point handles are obtained
> > through plc_pt_by_loc(). This can handle every permutation (grouping
> > points, sub-aliases, ...)
>
> The more I think about plc_pt_by_loc(), the less I like it...
I wrote it mainly to allow mgr_load_conf_map() check if there is any overlaying of points. mgr_load_confmap() sets all the bits of every defined point to 1. Before inserting a point into the confmap, I get an anonymous point handle to check all the bits are 0.
We can make this function private, or create a confmap function to remove a point.
At moment I still favour keeping plc_pt_by_loc(). Eventually somebody will want to do funny thinks we can't even imagine. We might just as well let them, but put up a warning that they take full responsibility once they start using anonymous
handles obtained through this function.
>
> To create a sub-alias, the code would first have to call a function to tell
> it the physical location of the given point, do the arithmetic and then
> call plc_pt_by_loc() - error-checking everything along the way, of course.
> Again, it's a specific-enough task that I think a utility function is
> warranted...
OK. I agree with you here.
> Grouping points is a bit more difficult; in general, there is no guarantee
> that the points will be contiguous - therefore the code would have to have
> two variants, one for contiguous points and one for the general case. I'd
> be willing to grant the use of plc_pt_by_loc() to such code...
>
> Only the end-programmer, presumably after rigorous profiling, has the
> priviledge of guaranteeing contiguity of points (and even then the freedom
> is not complete - structs will always be contiguous).
I think the support for point grouping will be unnecessary if we support structs.
> Just for completeness, there should probably be a plc_pt_null() function
> which returns a handle to a 0-bit point (like /dev/null). I'll probably
> write it sometime when I'm feeling whimsical
Nice concept, though I can't see where it would come in useful. I'm sure you or someone else can.
> > > There may eventually be special syntaxes that declare a point and a
> > > bunch of subaliases in one line, for struct-like constructs.
>
> > Yes, good idea. This is what the PID module really needs.
>
> Exactly.
>
> > Sorry to keep bothering you with all these details.
>
> No worries. A lot of this discussion should actually be taking place on the
> list - partly to get other input (more heads more eyes), partly so it
> doesn't look so dead...
>
> If you agree, you can reply to this on-list.
>
> [...]
> > I think we have cleared the point configuration up for now, unless you
> > have anything further to add?
>
> I think so - points, aliases, maybe subaliases. That's about it, I think,
> apart from structs.
Aren't subaliases repleaceable by structs? Or vice-versa?
>
>
> > Any sugestions for the struct-like construct syntax?
>
> Not really - I'll have a think about it.
>
I'm assuming we are limiting a struct's total length to 32 bits for now. In the end a struct is just a collection of points that may overlap, but require a special syntax in the conf file so this overlapping is obvious and not subtle.
I sugest we go with subaliases and leave out structs for now.
[...]
Mario
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> Hello,
>
> > > > I remeber you saying that points may not overlap, but I think we
> > > > should allow it for read points
>
> > > No problem - points may not overlap in the config file, partly because
> > > it's confusing, partly to prevent different permissions to be assigned
> > > to the same bits. Actual point handles may overlap as much as desired.
>
> > > (Already it's possible and OK to get any number of handles to a point.)
>
> > > > For write points, also allow overlap,
>
> > > I don't even mind an overlapping mixed read-write point, as long as the
> > > programmer knows what he's doing. However, I reserve the right to doubt
> > > that the programmer knows what he's doing in this case
>
> > OK. I see where you are getting at. Do not allow any kind of overlap in
> > the config file (actually it is easier to check for this in
> > mgr_load_confmap(), and I have it almost implemented), but allow for any
> > kind of overlap in point handles obtained through plc_get_pt_by_loc(), as
> > long as the ownership is not touched.
>
> Exactly.
>
> Basically, my reasoning goes like this:
>
> The point handles access the private map; each module is welcome to
> scribble all over its private map if it feels like it. (Though it's not
> necessarily a good idea to do so.)
>
> The config defines access to the global map; that has to be strict.
>
> [...]
> > > > Example of overlapping read points: Module A is a function often used
> > > > in several programs, and requires at least one input value. It is
> > > > written as using a general point Pinput as its input value. When this
> > > > function is integrated in a larger program, this point is defined as
> > > > overlapping the point that will be used as the real input point.
>
> > > This should probably be handled by putting the name of the point in the
> > > config. I guess that means new conffile_get_value/table_pt()
> > > functions... (Or plc_pt_by_conf(), I don't know.)
I favour
plc_pt_t conffile_get_value/table_pt();
But I don't really think this is at all necessary. Pls see below why.
> > > If you just use a single pre-defined name, you have the problems of
> > > - namespace pollution: no end-user and no other module may use that
> > > name, even to mean something completely unrelated.
> > > - no reentrancy: you cannot run Module A twice.
>
> > > With configurable point names, you have separate sections, and if you want
> > > to run a module twice you use the --PLCmodule switch to tell the two copies
> > > to use different sections.
>
> > OK. Well put.
>
> > But I was considering a module written in a higher level language (like
> > the IL compiler).
>
> For end-programmer written programs, it's the end-programmer's problem.
>
> For libraries, this will be just one of many problems we have to solve - IL
> doesn't lend itself all that fabulously to modularization, as far as I see.
> Whatever program is using the library will have to cope with that (provide
> actual points for the formal points used in the library).
>
> For pre-supplied programs-
>
> > This means the higher level language will have to contain 'macros' to
> > specify that the real name of a point should be obtained from the config
> > file.
>
> Yes, that's probably the best solution. It'll need those macros for tuning
> parameters, anyway (so that process constants can be read from the config).
>
> [...]
>
> > I don't think we will require any conffile_get_value/table_pt()
> > functions. Point names are just text strings, so we can go from there.
>
> Just for convenience - getting a point handle is a specific-enough task
> that it's possible to make sensible error messages; for instance, every
> time a point is taken from the config, there is the possibility of the
> error message "value VARNAME in section SEC should be a point name but it
> is `VALUE' which is not a point nor alias" (or words to that effect).
>
> (The logging policy should say how to refer to config values. Actually, the
> documentation policy should say that.)
>
> Even if it's just to encapsulate the five lines of code into one function
> it's worth it, because most of the code will be error-checking, and it's
> far too tempting to skimp on it.
OK. Here's why I don't think it is necessary:
plc_pt_t conffile_get_value_pt(const char *mod, const char *name) {
plc_pt_t p = plc_pt_by_name(conffile_get_value(mod, name));
if (p.valid == 0) plc_log_errmsg(...);
return p;
}
The code that calls this function will also have to verify if (p.valid == 0) again. There is no way we can let the main prog skimp on error checking. And the error message that the main prog will log will probably be more informative (ex. could not find point xxx, using default yyy).
Maybe later it might come in useful, but for now I can't see it's use.
> > > I'm for the "alias" syntax. That makes it clear what's going on.
>
> > Yes... agreed.
>
> We theoretically could have module-specific aliases, but it'd be hell to
> debug such a system. If there's demand for them, they could be "mod_alias".
>
> (Maybe put the previous paragraph in a comment somewhere near the alias
> code, so it's not forgotten.)
Module specific aliases requires the confmap to be aware of them, unlike global aliases. I would prefer not to support this, and let the modules work with conffile_get_value() for local aliases.
> > > Also, there should be a function to provide anonymous subaliases.
>
> > Don't think that is really required. Anonymous point handles are obtained
> > through plc_pt_by_loc(). This can handle every permutation (grouping
> > points, sub-aliases, ...)
>
> The more I think about plc_pt_by_loc(), the less I like it...
I wrote it mainly to allow mgr_load_conf_map() check if there is any overlaying of points. mgr_load_confmap() sets all the bits of every defined point to 1. Before inserting a point into the confmap, I get an anonymous point handle to check all the bits are 0.
We can make this function private, or create a confmap function to remove a point.
At moment I still favour keeping plc_pt_by_loc(). Eventually somebody will want to do funny thinks we can't even imagine. We might just as well let them, but put up a warning that they take full responsibility once they start using anonymous
handles obtained through this function.
>
> To create a sub-alias, the code would first have to call a function to tell
> it the physical location of the given point, do the arithmetic and then
> call plc_pt_by_loc() - error-checking everything along the way, of course.
> Again, it's a specific-enough task that I think a utility function is
> warranted...
OK. I agree with you here.
> Grouping points is a bit more difficult; in general, there is no guarantee
> that the points will be contiguous - therefore the code would have to have
> two variants, one for contiguous points and one for the general case. I'd
> be willing to grant the use of plc_pt_by_loc() to such code...
>
> Only the end-programmer, presumably after rigorous profiling, has the
> priviledge of guaranteeing contiguity of points (and even then the freedom
> is not complete - structs will always be contiguous).
I think the support for point grouping will be unnecessary if we support structs.
> Just for completeness, there should probably be a plc_pt_null() function
> which returns a handle to a 0-bit point (like /dev/null). I'll probably
> write it sometime when I'm feeling whimsical
Nice concept, though I can't see where it would come in useful. I'm sure you or someone else can.
> > > There may eventually be special syntaxes that declare a point and a
> > > bunch of subaliases in one line, for struct-like constructs.
>
> > Yes, good idea. This is what the PID module really needs.
>
> Exactly.
>
> > Sorry to keep bothering you with all these details.
>
> No worries. A lot of this discussion should actually be taking place on the
> list - partly to get other input (more heads more eyes), partly so it
> doesn't look so dead...
>
> If you agree, you can reply to this on-list.
>
> [...]
> > I think we have cleared the point configuration up for now, unless you
> > have anything further to add?
>
> I think so - points, aliases, maybe subaliases. That's about it, I think,
> apart from structs.
Aren't subaliases repleaceable by structs? Or vice-versa?
>
>
> > Any sugestions for the struct-like construct syntax?
>
> Not really - I'll have a think about it.
>
I'm assuming we are limiting a struct's total length to 32 bits for now. In the end a struct is just a collection of points that may overlap, but require a special syntax in the conf file so this overlapping is obvious and not subtle.
I sugest we go with subaliases and leave out structs for now.
[...]
Mario
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc