Menu
▾
▴
lcd4linux-devel
|
From: Michael R. <re...@eu...> - 2004-02-17 06:00:54
|
Hi Martin, Hi Xavier, > Ok, maybe I'm missing something obvious here - but if we want to take > the easy routem, why can't we simply define that a function name > consists of > plugin_name + delimiter + function_name ? Ahh... > > If you want to make it look like OOP, you can use "." for a delimiter > (but it may screw up the parser, since "." is already used for string > concatenation). Right. A dot would look nice, but will not work. Maybe a ':' ?? (no, impossible, because of the a?b:c) I'm afraid we run out of delimiters :-) > The user must know which functions exist (and most naturally, that would > be documented on a "per plugin" basis, so the user would also know which > plugin the function belongs to). Actually, it might even make the > config-file more clear (since the plugin-name gives the function a > context, so it's easier to understand what's going on). It would > probably even solve the "duplicate function name" problem, since we > could think of each plugin as a name-space. What I'm thinking about here > is this: > the xmms plugin has a function "filename" (I don't know if it does, but > lets assume it does). If you know you're talking about xmms, "filename" > makes sense (pobably the name of the file currently being played). > If someone else is writing a "plugin_printspooler", "filename" might be > the name of the file currently being printed. In both cases, it's a > filename, but I guess it would be nice to know (simply from looking at > the config) which plugin is being used by a statement in the setup. Martin - that's why I've been waiting for your comments :-) I really LOVE this idea! It solves all our issues, and is a win-win solution! It gives us the same results as the "global function to plugin mapping", but easier to implement (no compile-time work necessary), and allows for modules to be used without recompiling all the stuff. It does not require a list of modules to be specified in the config file. Great! Xavier, what's your opinion? -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2004-02-18 07:12:04
|
Hi guys,
Here's my vote: I vote for '_'
why?
- there is no real 'object/method' system behind, so why try to mimic one?
- the only reason for this delimiter is that the evaluator needs a hint
how to find the plugin that offers a specific function. So the function
name has to start with the plugin name. If a plugin offers just one
function, it may take only the plugin name (without any extension)
- integrating into the parser is not that easy with other delimiters. Te
parser reads "tokens", and one possible token is a NAME, which consists
only of alphanumeric chars and the _. The trick is that variable names
and functions can be parsed the same way (and have the same token), if
the next char is an opening brace, it's a function, if not, its a variable.
When using any of the chars you suggested, I have rewrite the parser,
and take the following into account:
- double occurence of the delimiter
- delimiter at the beginning or the end
- delimiter in variable names
>> Maybe a plugin could register multiple namespaces, but how would the
>> eval know them ? We fall in the same problem :/
>>
>> Another solution would have to have : - xmms::parse('token')
>> - i2c_sensors::parse('token')
>> - proc_stat::parse('token')
>> - proc_stat::disk('token')
>> - proc_stat::cpu('token', 'delay')
>> - ...
>> So a plugin may have multiple functions, and one-function plugins
>> register only a generic parse() function. What about it ??
>
> Well, after checking the existing code of the plugins (and lots of
> editing this email...), that would sound like a very good idea to me, if
> we can get rid of the (somewhat redundant) "parse". Maybe something like
> a "default function", if only the name of a plugin is supplied?
I'm sorry, but I don't understand this discussion.
From the evaluator's point of view, he knows nothing about tokens and
parsers and stuff. It behaves simple:
function call to foo():
if foo is registered, call it
else try to load a modules called 'plugin_foo.so'
if registered now, call it
else remember the failure and output an error (so on the
next try it won't try loading again)
function call to foo_bar():
if foo_bar is registered, call it
else try to load a modules called 'plugin_foo.so'
...
from the plugin's point of view, it's absolutely free to you (the
author) wether to implement a "generic parsing function" with the
requested item as a parameter, or to implement a seperate function for
each item, or both.
Both ways may make sense: there are sources where you cannot know which
items may occur: netdev() for example: how should I know how much
network interfaces are there, and how thy're called today?
bye, Michael
--
Michael Reinelt Tel: +43 676 3079941
Geisslergasse 4 Fax: +43 316 692343
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Xavier V. <xav...@fr...> - 2004-02-18 10:29:00
|
Hello list ! > - there is no real 'object/method' system behind, so why try to mimic one? But there's a king of 'namespace/function' like in Perl, so I keep :: (I like being flamed ;) ). Another argument is below. > - the only reason for this delimiter is that the evaluator needs a hint > how to find the plugin that offers a specific function. So the function > name has to start with the plugin name. If a plugin offers just one > function, it may take only the plugin name (without any extension) > > function call to foo(): > [...] > function call to foo_bar(): > [...] And what about i2c_sensors() and proc_stat() ?? The eval will try to load plugin_i2c.so or plugin_proc.so !! We'll have to find another replacement for spaces or write i2csensors() or I2cSensors() which is quite uggly :/ So I don't think '_' is the best choice as it's already used. > from the plugin's point of view, it's absolutely free to you (the > author) wether to implement a "generic parsing function" with the > requested item as a parameter, or to implement a seperate function for > each item, or both. That's what we were talking about. But instead of calling xmms::parse() you call it xmms(). Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Xavier V. <xav...@fr...> - 2004-02-17 11:07:45
|
Hi Michael, hi Martin, hi list !
> > If you want to make it look like OOP, you can use "." for a delimiter
> > (but it may screw up the parser, since "." is already used for string
> > concatenation).
> Right. A dot would look nice, but will not work. Maybe a ':' ?? (no,
> impossible, because of the a?b:c)
we could use @, it seems to be very fashion ;) Moreover, it represents
well the 'namespace' concept.
> > The user must know which functions exist (and most naturally, that would
> > be documented on a "per plugin" basis, so the user would also know which
> > plugin the function belongs to). Actually, it might even make the
> > config-file more clear (since the plugin-name gives the function a
> > context, so it's easier to understand what's going on). It would
> > probably even solve the "duplicate function name" problem, since we
> > could think of each plugin as a name-space. What I'm thinking about here
> > is this:
So if I understand it all, instead of invoking xmms('filename'), the
user should invoke 'filename@xmms', so that the eval knows it need
plugin_xmms loaded ? Am I right ?
But then, how would the plugin handle this ?
Eval my call the function xmms('filename'), but this may lead to
problems with plugin_proc_stat :/
> It gives us the same results as the "global function to plugin mapping",
> but easier to implement (no compile-time work necessary), and allows for
> modules to be used without recompiling all the stuff. It does not
> require a list of modules to be specified in the config file.
Right, it may be a good solution.
About dynamic loading of plugins, Martin wrote :
> But I'm looking at embedded systems (well, not _quite_ embedded, but at
> least very limited as far as space goes), where building can be a pain,
> and always needs to be done on a separate system. So what I like to do
> is do a "build everything" on my devel box, and then just transfer the
> plugins/drivers I need on a specific installation. If a new module
> arrives in the source tree later on (and I need none of the new
> functionality of lcd4linux), I could simply pop in the new plugin on the
> embedded box, and be done with it.
I think you would have to pop lcd4linux binary too, or 'unresolved
symbols' may appear (think of hashes, cfg, ... which are evolving quite
rapidly). But, it's right, in this case my fixed-compiletime hash isn't
a good choice.
Bye !
--
Xavier VELLO <xav...@fr...>
|
|
From: Michael R. <re...@eu...> - 2004-02-17 15:05:08
|
Hi there,
>>>If you want to make it look like OOP, you can use "." for a delimiter=20
>>>(but it may screw up the parser, since "." is already used for string=20
>>>concatenation).
> we could use @, it seems to be very fashion ;) Moreover, it represents
> well the 'namespace' concept.
I don't like it, because I'd reverse the 'object' and the 'method'.
> So if I understand it all, instead of invoking xmms('filename'), the
> user should invoke 'filename@xmms', so that the eval knows it need
> plugin_xmms loaded ? Am I right ?
No, not really. There are some plugins that offer only one function=20
(like xmms). Here the function name should be the same as the plugin name.
With Martin's example, the xmms plugin would offer a function=20
'filename'. You would call this function 'xmms.filename()'. The=20
evaluator could use the portion before the dot to find the plugin.
That's what I mean with "reverse".
xmms@filename looks
>
> But then, how would the plugin handle this ?
> Eval my call the function xmms('filename'), but this may lead to
> problems with plugin_proc_stat :/
>
>
>>It gives us the same results as the "global function to plugin mapping=
",
>>but easier to implement (no compile-time work necessary), and allows f=
or
>>modules to be used without recompiling all the stuff. It does not
>>require a list of modules to be specified in the config file.
>
> Right, it may be a good solution.
>
> About dynamic loading of plugins, Martin wrote :
>
>>But I'm looking at embedded systems (well, not _quite_ embedded, but a=
t
>>least very limited as far as space goes), where building can be a pain=
,
>>and always needs to be done on a separate system. So what I like to do
>>is do a "build everything" on my devel box, and then just transfer the
>>plugins/drivers I need on a specific installation. If a new module
>>arrives in the source tree later on (and I need none of the new
>>functionality of lcd4linux), I could simply pop in the new plugin on t=
he
>>embedded box, and be done with it.
>
> I think you would have to pop lcd4linux binary too, or 'unresolved
> symbols' may appear (think of hashes, cfg, ... which are evolving quit=
e
> rapidly). But, it's right, in this case my fixed-compiletime hash isn'=
t
> a good choice.
>
> Bye !
ugly.
xmms.filename look cool, but will not work.
so lets try all the delimiters I can find:
xmms^filename: NO (power 3^2)
xmms=B0filename: NO (not standard ASCII)
xmms!filename: NO (logical NOT)
xmms"filename: NO (uncool)
xmms=A7filename: maybe
xmms$filename: maybe
xmms%filename: NO (modulo)
xmms&filename: maybe
xmms/filename: NO (division)
xmms(filename: NO
xmms)filename: NO
xmms=3Dfilename: NO (equality, assignment)
xmms?filename: NO (implicit if)
xmms`filename: NO (string delimiter)
xmms?filename: NO (dangerous becaue looks like `)
xmms+filename: NO (addition)
xmms*filename: NO (multiplication)
xmms~filename: NO (bitwise not)
xmms#filename: NO (comment)
xmms<filename: NO (less than)
xmms>filename: NO (greater than)
xmms|filename: NO (logical OR)
xmms,filename: NO (expression list)
xmms;filename: maybe, but uncool
xmms.filename: NO (string concatenation)
xmms:filename: NO (implicit if)
xmms_filename: NO (normal char)
xmms-filename: NO (subtraction)
xmms@filename: maybe, but uncool
Did I forget something?
Votes are welcome!
another possibility would be to use another char for string=20
concatenation (but which one? I used the dot because Perl does so)
bye, Michael
--=20
Michael Reinelt Tel: +43 676 3079941
Geisslergasse 4 Fax: +43 316 692343
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Martin H. <ma...@he...> - 2004-02-17 18:53:12
|
Hi Michael, Michael Reinelt wrote: >=20 > so lets try all the delimiters I can find: >=20 > xmms^filename: NO (power 3^2) > xmms=B0filename: NO (not standard ASCII) > xmms!filename: NO (logical NOT) > xmms"filename: NO (uncool) > xmms=A7filename: maybe > xmms$filename: maybe > xmms%filename: NO (modulo) > xmms&filename: maybe > xmms/filename: NO (division) > xmms(filename: NO > xmms)filename: NO > xmms=3Dfilename: NO (equality, assignment) > xmms?filename: NO (implicit if) > xmms`filename: NO (string delimiter) > xmms?filename: NO (dangerous becaue looks like `) > xmms+filename: NO (addition) > xmms*filename: NO (multiplication) > xmms~filename: NO (bitwise not) > xmms#filename: NO (comment) > xmms<filename: NO (less than) > xmms>filename: NO (greater than) > xmms|filename: NO (logical OR) > xmms,filename: NO (expression list) > xmms;filename: maybe, but uncool > xmms.filename: NO (string concatenation) > xmms:filename: NO (implicit if) > xmms_filename: NO (normal char) > xmms-filename: NO (subtraction) > xmms@filename: maybe, but uncool >=20 > Did I forget something? >=20 > Votes are welcome! I'd vote for "$" - that's the first one that came to my mind. What I=20 like about it is that it's a plain ascii character (no danger of messing = things up with UTF8 - which "=A7" does for example). From (briefly) looking at the evaluator, I guess it should also be=20 possible to use more than one character as a delimiter, without things=20 getting _too_ complicated (so, "::" or "->" should be doable). But I=20 don't see the need to do the extra work, which is why I'd vote for "$". If you want to get _really_ fancy (or if I lose my job and have tons of=20 time to spare), one could also extend the evaluator to do a more=20 sophisticated scanning/parsing (by writing up a grammar and feeding that = to lex and yacc), but I guess none of us has that much time to spare=20 (especially for little or no additional benefit). > another possibility would be to use another char for string=20 > concatenation (but which one? I used the dot because Perl does so) Well, it wouldn't really change anything - since then, we'd be looking=20 for a new separator for concatenation (and there's no "natural" one,=20 unless you think in Basic, where "+" or "&" are used for concatenation - = not terribly elegant, especially since it's already used anyway). Martin --=20 You think that's tough? Try herding cats! |
|
From: Xavier V. <xav...@fr...> - 2004-02-17 20:35:05
|
Hi all !
> From (briefly) looking at the evaluator, I guess it should also be
> possible to use more than one character as a delimiter, without things
> getting _too_ complicated (so, "::" or "->" should be doable). But I
> don't see the need to do the extra work, which is why I'd vote for "$".
I vote for xmms::filename, it's the same syntax as Perl !
In Perl, to call the function init() provided by module Gtk2, we call
Gtk2::init() or so. Great idea !
BTW:
> So if I understand it all, instead of invoking xmms('filename'), the
> > user should invoke 'filename@xmms', so that the eval knows it need
> > plugin_xmms loaded ? Am I right ?
> No, not really. There are some plugins that offer only one function
> (like xmms). Here the function name should be the same as the plugin name.
> With Martin's example, the xmms plugin would offer a function
> 'filename'. You would call this function 'xmms.filename()'. The
> evaluator could use the portion before the dot to find the plugin.
> That's what I mean with "reverse".
But don't we loose flexibility and extensibility ? A great advantage of
new generation is to have a function which provides tokens independants
from the code ! example: i2c_sensors can provide 'curr_input3' if
there's one an the day a new file 'coffe_machine1' (totally random
example ;) ) appears the plugin will handle it with no change.
Please don't trow this excelent feature !!
Maybe a plugin could register multiple namespaces, but how would the
eval know them ? We fall in the same problem :/
Another solution would have to have :
- xmms::parse('token')
- i2c_sensors::parse('token')
- proc_stat::parse('token')
- proc_stat::disk('token')
- proc_stat::cpu('token', 'delay')
- ...
So a plugin may have multiple functions, and one-function plugins
register only a generic parse() function. What about it ??
Bye !
--
Xavier VELLO <xav...@fr...>
|
|
From: Martin H. <ma...@he...> - 2004-02-17 21:40:52
|
Hi Xavier,
Xavier VELLO wrote:
>> From (briefly) looking at the evaluator, I guess it should also be
>>possible to use more than one character as a delimiter, without things
>>getting _too_ complicated (so, "::" or "->" should be doable). But I
>>don't see the need to do the extra work, which is why I'd vote for "$".
>
> I vote for xmms::filename, it's the same syntax as Perl !
> In Perl, to call the function init() provided by module Gtk2, we call
> Gtk2::init() or so. Great idea !
I agree that it would look nicer (or more familiar, to a coder) - but I
guess it mainly comes down to how difficult it is to implement that in
the evaluator. I mean, _theoretically_ it should not be difficult to
implement a "look-ahead" if the evaluator finds ":" to find out if the
next char is also a ":" - but as I said, I only looked briefly at the
evaluator, so I can't say if it's actually as easy as it sounds.
> Maybe a plugin could register multiple namespaces, but how would the
> eval know them ? We fall in the same problem :/
>
> Another solution would have to have :
> - xmms::parse('token')
> - i2c_sensors::parse('token')
> - proc_stat::parse('token')
> - proc_stat::disk('token')
> - proc_stat::cpu('token', 'delay')
> - ...
> So a plugin may have multiple functions, and one-function plugins
> register only a generic parse() function. What about it ??
Well, after checking the existing code of the plugins (and lots of
editing this email...), that would sound like a very good idea to me, if
we can get rid of the (somewhat redundant) "parse". Maybe something like
a "default function", if only the name of a plugin is supplied?
this would make it
xmms('token')
i2c_sensors('token')
proc_stat('token')
proc_stat::disk('token')
proc_stat::cpu('token', 'delay')
Which would look pretty appealing to me. We'd have the best of both
(especially being able to have functions, that take more than just one
parameter)
What do you think?
Martin
--
You think that's tough? Try herding cats!
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X