Home » Developing U++ » U++ Developers corner » What about LUA plugin?
|
|
| Re: What about LUA plugin? [message #4812 is a reply to message #4805] |
Tue, 22 August 2006 21:28   |
 |
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| luzr wrote on Tue, 22 August 2006 17:50 |
Anobody to contribute?
Mirek
|
I've tried Lua. Lua is slow. I think slower than Ruby or similar. No good! Or at least, they are too much below my speed patience level 
Python is faster but I don't like its syntax and its C base.
...The main reason of arilect.com and then why I joined U++ was ... interpreters things and my favourite interpreter Dialect. Also, not very known like U++. Even less. But very fast! And very nice syntax.
I made a very limited working version (UDialect?) with some of U++ Ctrls in February this year but then I had learn more U++ things and things like PHP, forums, agg, some more databases etc...
And the reason I was asking some questions about Esc speeds was that I want to make the opposite thing as well - a good interpreter embedded into U++...
So, anyway, I expect to publish it in the nearest future (2-3 months?...)
But at the moment I want to polish agg-svg-upp things (1 month).
Btw, why Lua?
If you are interested about Dialect:
(the first link doesn't work with opera)
http://secure.mtd-inc.com/dialect/
(and the project itself which is very very quiet. Unlike U++ )
http://dialect.sourceforge.net/
|
|
|
|
|
|
| Re: What about LUA plugin? [message #4814 is a reply to message #4812] |
Tue, 22 August 2006 23:07 |
|
|
| fudadmin wrote on Tue, 22 August 2006 15:28 |
Btw, why Lua?
|
Because it's very modern, flexible language and it has really small footprint. The library size is about 200-300kb. In my company we added sql interface to it and use it to write quick-fix apps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: What about LUA plugin? [message #5220 is a reply to message #5215] |
Sun, 10 September 2006 23:47 |
thierry
Messages: 9
Registered: September 2006
|
Promising Member |
|
|
| luzr wrote on Sun, 10 September 2006 20:50 |
| thierry wrote on Sun, 10 September 2006 13:45 |
Ok. And you shall add Esc for custom controls in layout editor.
|
No, I will not add Esc for custom controls. I have done so 2 years ago
| Quote: |
Then I just wonder if there would be kind a uppforge.net for custom packages !
|
I hope that in future, yes. At the moment, we are not as popular yet
Mirek
|
About Esc, I wasn't saying the intregation of Esc was a todo, but just mentionning it as yet another configuration mean of theIDE to add to the list xml, serialize.
I was more trying to put the emphasis on the fact that configuration means were multiplying. All with their pros and cons, then without deep design consideration about why using them other than marketing done around them.
But in the end they all tend to be used, thus asking more code to be written (even if small, this is still a bloat) and cores to be linked.
Given machine strength, most of the needs could be satisfied with one small core script language, like lua proves, but why not another as long as it can have a critical mass, or a database when data are larger.
Then why paying the effort of maintaining a script language where you don't want to maintain a database engine? And to which extent, this can predate the development of other nice features.
Don't take it for U++, this is more general consideration about users architecture decision, and a tool like U++ aims to address as many kind of users needs as possible. Including yours at first with your existent code base.
My only worry would be that serialization is more supported by external streaming operators in a more modular and extensible aspect oriented design.
something like:
#include <iostream>
struct XmlIO {
template<class T> XmlIO& operator()(const char* tag, T& v)
{ std::cout << "<" << tag << ">" << v << "<\\" << tag << ">"; return *this; }
};
#define SERIALIZABLE(Class) template<class stream> friend stream& operator<<(stream&, Class&);
// End user code
class C {
int v1, v2;
SERIALIZABLE(Class);
public:
C() : v1(12), v2(24) {}
};
template<> std::ostream& operator<<(std::ostream& s, C& c) { return s << c.v1 << std::endl << c.v2; }
template<> XmlIO& operator<<(XmlIO& xml, C& c) { return xml("v1", c.v1)("v2", c.v2); }
int main() {
C c;
std::cout << c << std::endl;
XmlIO s;
s << c;
return 0;
}
About a uppforge, why waiting high demand? Won't the offer create demand? At least, this shall only encourage sharing U++ code, thus giving more examples of U++ code. Maybe just letting a space where to put code snipset would be nice.
|
|
|
|
| Re: What about LUA plugin? [message #5221 is a reply to message #5220] |
Mon, 11 September 2006 00:24 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Quote: |
struct XmlIO {
template<class T> XmlIO& operator()(const char* tag, T& v)
{ std::cout << "<" << tag << ">" << v << "<\\" << tag << ">"; return *this; }
};
|
It is bidirectional, so cout does not make it, however I see the point...
| Quote: |
#define SERIALIZABLE(Class) template<class stream> friend stream& operator<<(stream&, Class&);
// End user code
class C {
int v1, v2;
SERIALIZABLE(Class);
public:
C() : v1(12), v2(24) {}
};
|
Yep. But using macro is ugly and requires more typing. Instead, there is
template <class T> XmlIO XmlIO::operator()(const char *tag, T& var) {
XmlIO n(*this, tag);
Xmlize(n, var);
return *this;
}
soo if you want to be aspect aware, which I understand as being able to add xmlization to existing class, simply define Xmlize *function* for it.
Xmlize itself has template
template <class T>
void Xmlize(XmlIO xml, T& var)
{
var.Xmlize(xml);
}
(Now if somebody asks what we mean by "aggresive use of C++", here is the answer).
Note that sometimes you might want to define more funtions to xmlize single type to express the value the type really represents, e.g. there is XmlizeLang that interprets int as language indentifier (e.g. "en-us").
| Quote: |
About a uppforge, why waiting high demand? Won't the offer create demand? At least, this shall only encourage sharing U++ code, thus giving more examples of U++ code. Maybe just letting a space where to put code snipset would be nice.
|
What I really wanted to say is that U++ is not popular enough for somebody to start one. If you feel like starting such effort, go for it, it will definitely help us.
Mirek
|
|
|
|
|
|
| Re: What about LUA plugin? [message #5224 is a reply to message #5221] |
Mon, 11 September 2006 01:12 |
qwerty
Messages: 130
Registered: May 2006
|
Experienced Member |
|
|
uh, I almost oversee this topic .
Lua plugin? yes, I have it somewhere. the question is, if you want port it to c++. native lua supports C (*func) only, so there are some interesting projects to make it posible w/ C++, I guess, the choice is yours(www.lua.org). if there is interest to upload somewhere plugin, which I am using(personally, it's not worth of to tell a "plugin", just the slight modified/created files), drop the note.
Lua is slow?? heh heh, yes and the sun rises on the west side :>
|
|
|
|
|
|
| Re: What about LUA plugin? [message #5226 is a reply to message #5223] |
Mon, 11 September 2006 01:22 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| thierry wrote on Sun, 10 September 2006 19:10 |
Maybe, you miss the point, because your solution forces to modify class C with adding a method C::Xmlize().
|
No, you missed it 
You just have to define your Xmlize *function*. You do not need to alter header to do that.
| Quote: |
And I also meant I wanted to add new streams kind (like ShallowTraceOutStream, DeepTraceOutStream or whatever I can imagine, DBstream, or LuaStream).
|
XmlIO is really not a stream and cannot be a stream - it is in fact an interface to map hierarchy (that is what XML file is...). Well, maybe in future it would be nice to virtualize XmlIO to support other map hierarchies. At the time of creating XmlIO, it seem as far fetched idea from practical point of view.
Mirek
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sun Apr 28 15:23:11 CEST 2024
Total time taken to generate the page: 0.02669 seconds
|
Members
Pages
Help
Register
Login
Home
