Our new official repo is on github
LCD Smartie version 5.6 is released!
Download it now: https://github.com/LCD-Smartie/LCDSmartie/releases

"String" library

Discussing issues that occur during plugin development.

Moderators: _X7JAY7X_, caesar, IFR, mattcro, limbo

Post Reply
ReverseEngineered
Plugin Author
Posts: 192
Joined: January 18th, 2006, 11:09 pm
Location: Saskatoon, Saskatchewan, Canada

"String" library

Post by ReverseEngineered »

Given the number of assorted plugins out there for handling string manipulation (cut, sandr, swap, splittitle, etc), I think it's time we made a general purpose plugin for all of this--or at least a set of plugins which would accomplish these things.

Being from a mainly Linux background, I would like to see plugins which would emulate some of the basic tools we use there, such as sed, awk, grep, etc. As mentioned elsewhere, my first step would be to implement at least basic regular expressions; hopefully using an existing regexp library to do so. This would easily perform the job of grep, or splittitle. A simple extension of this would allow sed/awk/sandr to be implemented, giving us much greater control over search and replace; VERY important for formatting RSS feeds (like my horribly long weather forecast).

I would like input from the community as to what they would like to see here. Now that my serial AVR adapter is well on its way, I'm considering a shift to writing plugins, and I think this is the first place I need to start.

One interesting thought as to how to approach this is to actually use the mature, stable Linux tools as backends. It is very easy to get access to copies of these tools which are compiled using mingw, allowing them to function under Windows. By writing simple DLL wrappers, we could call these programs from a screen and just return the values from the program. The ultimately simplest way to do this would be to have an "exec" command, which would simply execute the given command line, replacing the $dll call with the string which was returned on STDIN. Thus we would be able to use the entire gamut of unix tools which have been compiled for Windows. I realize this could possibly open up a security problem (since we would be able to execute ANY program), but this would be limited by the user's privledges, and would be set exclusively by the user, so we shouldn't have to worry about putting in dangerous commands (since he wrote the screen himself).

Anyway, time for me to go. Let me know what you think about creating a large string handling plugin, and hopefully I'll be able to start on it soon.

limbo
Plugin Author
Posts: 1604
Joined: February 13th, 2005, 7:38 pm
Location: Athens - Greece
Contact:

Post by limbo »

I believe that a mod on main program to autoscan the plugins directory (displaying the available plugins in a list box) will be more flexible! :)

I like the idea of opening the config screen of LCD Smartie and have alist of plugins available for use. This will eliminate the typing long $dll( strings on the configuration.
Building a complex plugin is possible, but I think that every time I`m trying to use a plugin (even my own plugins) I`m lost in the syntax and I have to check the info files. With a more complex plugin... the things going to be more complex :shock:

ReverseEngineered
Plugin Author
Posts: 192
Joined: January 18th, 2006, 11:09 pm
Location: Saskatoon, Saskatchewan, Canada

Post by ReverseEngineered »

The ability to find plugins and list them is definitely a necessity. It may require some small modification to the API, so that plugins could return a "usage" or "description" to LCDSmartie. This would make it much easier to use.

I definitely would be alright with making several seperate plugins, but I would like to make one large package (a collection of plugins) which would accomodate all of the necessary string functions, so that users wouldn't have to visit several websites to get what they need. Also, by using regular expressions, you would be able to accomplish several different tasks using the same plugin, or even just extend the abilities of the current plugins (e.g., sandr would be able to use wildcards and placeholders, cut could actually search for the location to begin and end the cut).

If the community would prefer several seperate plugins rather than one large plugin, I will do that. This would definitely be beneficial if LCDSmartie were able to find and list them.


I would also like to see more plugins be brought into a single area (like the downloads page one Smartie's website). Perhaps even have a new tab for plugins. Smartie could host plugins for people who don't already have websites (or have only made a couple of plugins), and could provide links to others who have made several plugins.


I think LCDSmartie is a great program, and now that it works (and has a significant user base), it needs a little refinement. I certainly intend of providing thorough documentation one of these days (as you can tell, I like writing lengthy, detailed articles ;)).

krisp
Plugin Author
Posts: 51
Joined: February 17th, 2006, 4:53 am

Post by krisp »

I agree that the API should be modified to include a "usage" or "info" function that returns delimited list of functions along with their basic syntax. Perhaps something along the lines of:

Code: Select all

function1:short_function_name:param1-syntax:param2-syntax;function2..;functionN
That way a single function can return all the necessary information on how to use the plugin. It would look like "function1:GetTVInfo:tuner_number:show_desc".

Another idea would be to have another function with an abbreviated version of the documentation embeded in it, so that LCDSmartie or an external plugin browser could pick up that data and show it to the user so they can select the proper functions.

limbo
Plugin Author
Posts: 1604
Joined: February 13th, 2005, 7:38 pm
Location: Athens - Greece
Contact:

Post by limbo »

Hey RE!

That's best news
An LCD Smartie documentation! :lol:
I believe that you're the best person to do it!

limbo
Plugin Author
Posts: 1604
Joined: February 13th, 2005, 7:38 pm
Location: Athens - Greece
Contact:

Post by limbo »

krisp wrote:I agree that the API should be modified to include a "usage" or "info" function that returns delimited list of functions along with their basic syntax. Perhaps something along the lines of:

Code: Select all

function1:short_function_name:param1-syntax:param2-syntax;function2..;functionN
That way a single function can return all the necessary information on how to use the plugin. It would look like "function1:GetTVInfo:tuner_number:show_desc".

Another idea would be to have another function with an abbreviated version of the documentation embeded in it, so that LCDSmartie or an external plugin browser could pick up that data and show it to the user so they can select the proper functions.

That's a good idea...
We need some code alter for this :)

I had an idea for this adding some extra info about the functionallity of the pluging in every function. The only thing you want to do is to add "about" to first parameter and "function" to the second.

After a long time with no feedback for this I'm not sure about the utilization of this extra info.... :(

krisp
Plugin Author
Posts: 51
Joined: February 17th, 2006, 4:53 am

Post by krisp »

I like that idea too. That way there doesn't need to be any major API changes to accomidate it.

ReverseEngineered
Plugin Author
Posts: 192
Joined: January 18th, 2006, 11:09 pm
Location: Saskatoon, Saskatchewan, Canada

Post by ReverseEngineered »

Good idea limbo, it's something we should definitely adopt.

I think one reason you haven't heard much about it is that people don't usually speak their mind about such things. That and I'm sure some people never think of it. However, if we did implement something like that, users would definitely appreciate it.

As soon as I finish off the AVR project and get my Smartie setup (i.e. figure out how it all works), I'll start writing some documentation.

limbo
Plugin Author
Posts: 1604
Joined: February 13th, 2005, 7:38 pm
Location: Athens - Greece
Contact:

Post by limbo »

OK Reverse Enginnered...
First things first... Go back to your evil deeds :lol:

ReverseEngineered
Plugin Author
Posts: 192
Joined: January 18th, 2006, 11:09 pm
Location: Saskatoon, Saskatchewan, Canada

Post by ReverseEngineered »

I'm almost done making a single DLL that performs four functions, all based on regular expressions (using cpp_regexp). These functions are:

1: Return the portion of the input string which matches the pattern
2: Split the input string up into groups (as given in the pattern), concatentating them with seperators in between.
3: Perform (several) replacements given a set of patterns and strings to replace them. Includes the ability to use backreferences, so that the user can use pieces of the matched string in the replacement (makes life easier).
4: Return the number of times the pattern is matched in the input string.

My only problem is that, in the third function, I have started to receive access violations, though I wasn't originally and haven't modified anything (or atleast, not intentionally).

I think part of the problem might be with the way strings are used in Smartie. The plugin demo shows using a static char* for my string. From this I presume that Smartie does not free the char* that is receives, correct? In this case, one each call to the DLL I need to free and recreate that string, since my new one may be of a different size. Is this safe in Smartie, or will it try to use that pointer during the call to the DLL?

I'm going to keep playing with it, but I have no real way to debug it (not familiar with DLLs in the first place, let alone debugging them).

ReverseEngineered
Plugin Author
Posts: 192
Joined: January 18th, 2006, 11:09 pm
Location: Saskatoon, Saskatchewan, Canada

Post by ReverseEngineered »

Nevermind, the problem was definitely somewhere else. This code worked in all of my other functions, but not in that one (for some reason):

Code: Select all

string output;
static char *s = 0;
...
output = [the result of the replacement command];

s = new char[sizeof(output.c_str())];
strcpy(s, output.c_str());
Note that those last two lines are standard practice. To fix it, I replaced sizeof(output.c_str()) with output.length() + 1. This solved the problem.

I'm just writing up the documentation. I'll have it posted within the hour.

Post Reply