|
|
|
Home » Developing U++ » U++ Developers corner » U++ talk
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17877 is a reply to message #17875] |
Mon, 01 September 2008 15:00   |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
| amrein wrote on Mon, 01 September 2008 15:43 |
It would be so cool to have libupp.so.x.y.z and a clean version number before releasing anything into popular Linux distro. It's not a simple work (need to modify TheIDE, ...).
U++ is a monolith. It's so far from "re-use my lib" policy of all other FOSS software and libraries... The "build all from source" is very interesting for proprietary companies (and for debugging too) but for FOSS... it's another universe. How can I port the entire Gnome 2.x interface to upp if I don't have a lib to do a thin gnome 3.0 for example?
(Yes, Gnome, because those guys are still using C. They don't have a powerful and thin C++ library to replace GTK+. KDE use Qt.)
|
I wouldn't call it a monolith, since it is very modular. And this is the problem: how to build a single lib? Some apps need just some packages, and the most natural would be to have a so for every package. But that's quite some work and not very convenient.
Also, as Mirek said, we do not have a x.y.x versioning system. Our versioning system boils down practically to "year" (not counting dev releases). And I don't think we have the man power to do such versioning, especially that we have to increment a given number anytime we break link compatibility, which is very easy in C++. I honestly don't know what the solution for this problem is, except to link statically.
Or maybe we consider x 2008, and y 1  .
And I don't understand the part about Gnome? Who wants to port Gnome? And they do have GtkMM, but with all the gobject crap that's in the background, I wouldn't call it thin.
|
|
|
|
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17894 is a reply to message #17877] |
Tue, 02 September 2008 11:38 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| cbpporter wrote on Mon, 01 September 2008 15:00 |
And I don't understand the part about Gnome? Who wants to port Gnome? And they do have GtkMM, but with all the gobject crap that's in the background, I wouldn't call it thin.
|
What is the memory and disk footprint of 30 applications, from the windows manager to the control panel, from the text edit tool to the word processor, ... when each of them use the same code but don't share it with a dynamic library.
Gnome was an example.
[Updated on: Tue, 02 September 2008 12:51] Report message to a moderator |
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17895 is a reply to message #17893] |
Tue, 02 September 2008 12:45 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| luzr wrote on Tue, 02 September 2008 10:06 |
...
In fact, it is considered that we perhaps might create a "runtime environment" for U++, to make it behave even more like scripting language. It would just use GCC in the process
Mirek
|
Binding for Python, Perl, Rubby, Tcl, Gambas (http://gambas.sourceforge.net/), Java... Could be done in hours if we had a dynamic library.
It should be possible to create a new package like "libupp" statically linking with all upp, and the output should be a dynamic library libupp.so.0.8.1 instead of an application.
Resume
Since the beginning, I talked about website, doc, dynamic linking, version number, directories clean up, file names policy, class names policy, ... to answer a simple expectation (mine): "How can U++ have a wider audience and become mainstream in FOSS". What amaze me the most now: I'm trying to answer my question, but nobody, except me, see my solutions as interesting suggestions. I have no more idea to submit. The answer I got are completely justified in that context:
Website left menu: Generated from Topic++. Modifications should go there first.
Doc with title and plan: Get it and improve it, if the result is cool, we will use it.
Version number x.y.z (0.year-2000.svntag?): We prefer Year.Release. Use what you want if you work on a dynamic library.
U++ as a dynamic library too: Too much work. U++ and TheIDE API change too often. TheIDE use static linking.
Manage Topic++ doc as doxygen comments in the source: We prefer external Topic++ documentation.
Cpp an .h file names policy (all lower case for better portability): No need for policy, our programmers are used to current file names.
Class names without abbreviations (like Ctrl->Control): No thanks, this is what we are used to.
Directory clean up: Well perhaps TheIDE could be in its own Package/Assembly/Nest. Perhaps U++ directories structure are not clean enough for you but we are comfortable with it and we works on it each days, as many other U++ users
Something easier than "Assembly/Nest/Package": "Assembly/Nest/Unit"?
(...)
I have no more ideas. I won't be able to help as I thought I could. At least, I can help for the rpm build process.
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17896 is a reply to message #17895] |
Tue, 02 September 2008 13:53 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Tue, 02 September 2008 06:45 |
| luzr wrote on Tue, 02 September 2008 10:06 |
...
In fact, it is considered that we perhaps might create a "runtime environment" for U++, to make it behave even more like scripting language. It would just use GCC in the process
Mirek
|
Binding for Python, Perl, Rubby, Tcl, Gambas (http://gambas.sourceforge.net/), Java... Could be done in hours if we had a dynamic library.
It should be possible to create a new package like "libupp" statically linking with all upp, and the output should be a dynamic library libupp.so.0.8.1 instead of an application.
|
Creating .so is the least problem.
The major problem is HOW MANY.
Surely, you can mix the whole uppsrc into single .so. But in that process, you will have a lot of external dependencies for everybody - and not everybody is using e.g. PGSQL.
BTW, thinking about other language bindings, if we forget for the moment a strong coupling of U++ with C++ (I am not sure how much will be left in other language), maybe the correct solution would be to create thin "fixed API" layer over U++.
Such API would change infrequently, exactly as "FOSS traditional versioning scheme" requires, and linked with UPP using it as "engine code". In that case, you would get exactly what you need.
| Quote: |
Since the beginning, I talked about website, doc, dynamic linking, version number, directories clean up, file names policy, class names policy, ...
|
Talk is cheap...
| Quote: |
What amaze me the most now: I'm trying to answer my question, but nobody, except me, see my solutions as interesting suggestions.
|
I definitely see the list as interesting, if nothing else, it helps me to see us from another perspective. In fact, I think it has helped a lot.
But, as newcomer, you cannot expect everything you suggest to be accepted immediately and also if anything IS accepted (like BSD license), to happen in days.
| Quote: |
Website left menu: Generated from Topic++. Modifications should go there first.
Doc with title and plan: Get it and improve it, if the result is cool, we will use it.
|
Will you do it?
Frankly, I would like to have better website, but our resources are limited right now...
| Quote: |
I have no more ideas. I won't be able to help as I thought I could. At least, I can help for the rpm build process.
|
Thanks for that!
Mirek
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17898 is a reply to message #17896] |
Tue, 02 September 2008 14:17 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
Well, this was posted by mr_ped while I was splitting the thread, because it was not about "Releasing U++ rpms" anymore...
| mr_ped wrote on Tue, 02 September 2008 08:07 |
And you still didn't even hit the "contribute the code, get refused anyway" scenario. 
Well, keep contributing with ideas, discussing them, and your target is to make Mirek believe those changes are good and important.
|
Now imagine what would happen if the gates would be totally open...
In fact, I have hard times to "fix" some old design mistakes made by Tom years ago...
| Quote: |
(Or "Uno" is your second change to change something in official U++, the third member of core U++ team does not show up at forums AFAIK)
|
The list is growing. Make James Thomas (mrjt) believe and you have a very strong argument
Mirek
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17899 is a reply to message #17895] |
Tue, 02 September 2008 14:19 |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
Don't get thing wrong please. We both appreciate and need help in general, but a lot of you suggestions are related to parts which actually work. It is not as much resistance to change, as it is a lack of interest and man-power to improve something which works quite well rather than focus on the parts which don't work too well.
Regarding creation of .so: I believe we are open to the usage of .so. I don't know who really needs it, but it would definitely be great to have a dll version too. It would also make things easier for those who don't want to use TheIDE. If you're willing to do this, be my guest. I will do my best to help you, but I'm not interested in this on my own, because it would not benefit me: I distribute 2-3 binary systems: one is the installer, and the rest are the application executable. With only 2-3 exe's, code sharing between .so is not that great on memory footprint reduction, and I get the added disadvantage of slower function calls.
But in practice it is not that easy. First of all, we've got all the templates that can't be embedded in the .so. Then there's the versioning, API/ABI issue. We would need a rigorous system to track ABI breaks. For example, there was a little “bug” some time ago where a function should have ended in const because it did not change the status of the object. We added const to be correct, but this definitely would have broken compatibility with binary .so because of name mangling.
So I think that dll's are a good idea, but only if you build a version specific to you application and ship it with your application. Getting a general .dll is a lot harder. If you are aware of a solution that would solve such issues, then please tell us.
| Quote: |
Cpp an .h file names policy (all lower case for better portability): No need for policy, our programmers are used to current file names.
|
I'm sorry, but I consider lower case names as deprecated as I do non-case sensitive paths. Even under Windows I always use proper cased names for files, and also except to get such names. So "Ctrl.h" is not a caseless or lower case name which was written with a capital "C" because Windows is not case-sensitive, it is really called "Ctrl.h" and referring to it as "ctrl.h" is an error IMO. And since all Unixes are case sensitive and Windows is case neutral, I don't think we have any issues left with this scheme. Also, if we change to lower case on Unix, all programs will cease to compile until we manually modify all include clause.
The same applies to using more longer and intuitive names. How can we change the name of a file and except old code to compile. How can we change the name of a class and still except to link with the .so that we are going to produce?
| Quote: |
Something easier than "Assembly/Nest/Package": "Assembly/Nest/Unit"?
|
Actually I don't care what they are named, but I kind of like their meaning and implication on code layout. A little clean up on interface level and I'm sure things would seem a little cleaner for new people. Also, "assembly" sounds familiar to .Net crowd, but has different semantics, so a change would not be a bad idea.
Doxygen: I'm all for reusing technology which works (i.e. doxygen) and wouldn't mind using it instead of Topic++. Topic may be more intimately tied to A++, but I don't think this mattes that much since docs are not autogenerated.
On the other hand, using doxygen would increase compilation times. I'll go crazy if I use another 0.5 second time per build. I would hate to have to abandon both the language and framework that I have grown to love and switch over to .NET because of trivial issues like compilation speed which should have been fixed decades ago.
And docs are coming along .
On the other hand, I don't see why we should argue about little issues like filenaming, when we need a better C++ parser for example. Code sequences that short out Assist++ are hard to circumvent and they spread like a virus.
Out of all these things, I think that .so should be a priority if you still need it. If we get that process working, adding support for TheIDE to build a dynamic lib and link your project to it would definitely be doable.
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17900 is a reply to message #17894] |
Tue, 02 September 2008 14:22 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Tue, 02 September 2008 05:38 |
| cbpporter wrote on Mon, 01 September 2008 15:00 |
And I don't understand the part about Gnome? Who wants to port Gnome? And they do have GtkMM, but with all the gobject crap that's in the background, I wouldn't call it thin.
|
What is the memory and disk footprint of 30 applications, from the windows manager to the control panel, from the text edit tool to the word processor, ... when each of them use the same code but don't share it with a dynamic library.
Gnome was an example.
|
Well
a) we are not creating X11 desktop (yet?
b) you can very easily workaround the problem by providing a single application that does it all (and I bet such complete desktop application would be about 1/10 of those 30 Gnome apps combined size).
c) you can, RIGHT NOW, compile U++ to .so modules that would be shared. But this has package = .so equivalency, not really practical for "classic use".
Mirek
|
|
|
|
| Re: Does the provided upp.spec works for you and on which distro? [message #17901 is a reply to message #17899] |
Tue, 02 September 2008 14:29 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| cbpporter wrote on Tue, 02 September 2008 08:19 |
Doxygen: I'm all for reusing technology which works (i.e. doxygen) and wouldn't mind using it instead of Topic++. Topic may be more intimately tied to A++, but I don't think this mattes that much since docs are not autogenerated.
And docs are coming along .
|
Do not forget one small practical issue. With doxygen style docs, people need write access to trunk code to edit documentation.
Meanwhile, separate .tpp directories do not present any danger to the code. Broken docs is something fixed easily. But I would not want to have deployed broken app because somebody accidentally damaged the code when working on docs.
Means, we can allow much more people to edit docs with T++...
That said, I had and have really hard time deciding this (T++ vs doxygen). This is not a new issue, I was at it since the very beginning.
I see the pros/cons:
Doxygen pros:
- known standard tool that works
- not much work required (except moving doc back from T++)
- very thight integration with code (because it is in the code)
cons:
- needs write access to the code to document it
- hard to put images into docs
- harder to put "explanation passages" (because the document structure is fixed)
T++ pros:
- separate docs with separate write rights
- comfortable wordprocessor with spelling checker
- no problem screenshotting widgets and putting images
- same environment to create code reference docs ("src") and explanation/tutorial docs ("srcdoc")
- possible to add implementation articles
cons:
- "invented here"
- a lot of work programming it (but, we need some of it anyway)
(I might have forgoten something)
Mirek
Mirek
[Updated on: Tue, 02 September 2008 14:38] Report message to a moderator |
|
|
|
|
|
| Re: U++ talk [message #17909 is a reply to message #17875] |
Tue, 02 September 2008 20:47 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
As long as upp version is not higher than 0.99.999..., the API can broke. That doesn't matter much. A present It could be 0.8.1. No problem with anyone compiling with 2008.1.
2009.0 then? Anyone using static linking will certainly need to rebuild their application too. In FOSS, when a lib is updated to a new release, all distro rebuild their packages if they need it.
U++ don't need to care about API stability. Really. There are a lot of libraries modifying their API and some of them broke it for each release. If U++ API is broken from version X to version Y, than it's mean that new U++ version is better. Other FOSS software will just have to follow.
The only problem could be if the U++ team wanted to backport fix to the 2008.1 branch for example. Most distro do it themselft and submit patches (or you can get them from their source packages). They also see by themselves from svn what is a fix and what will break the official release. They don't get all fix because a perfect product (for them) are not perfect to sell (no need to update to next release).
| Quote: |
I'm sorry, but I consider lower case names as deprecated as I do non-case sensitive paths. Even under Windows I always use proper cased names for files, and also except to get such names. So "Ctrl.h" is not a caseless or lower case name which was written with a capital "C" because Windows is not case-sensitive, it is really called "Ctrl.h" and referring to it as "ctrl.h" is an error IMO. And since all Unixes are case sensitive and Windows is case neutral, I don't think we have any issues left with this scheme. Also, if we change to lower case on Unix, all programs will cease to compile until we manually modify all include clause.
|
Yes. "#include" clean-up + a strict policy for all new .cpp and .h names.
You can find this policy in Qt, Epoc, Symbian, Gtk, wxWindows, WinCE... Most cross platform libraries use it.
You are used to U++ source code. You don't see it as I do.
| Quote: |
The same applies to using more longer and intuitive names. How can we change the name of a file and except old code to compile. How can we change the name of a class and still except to link with the .so that we are going to produce?
|
A source clean-up + a strict lower-case name policy for all new .cpp and .h doesn't mean rename internal class. No need to change their names.
The exceptions: class using abbreviations shouldn't use abbreviations. No need to get used to those abbreviations and source code is easier to understand.
| Quote: |
Doxygen: I'm all for reusing technology which works (i.e. doxygen) and wouldn't mind using it instead of Topic++. Topic may be more intimately tied to A++, but I don't think this mattes that much since docs are not autogenerated.
On the other hand, using doxygen would increase compilation times. I'll go crazy if I use another 0.5 second time per build. I would hate to have to abandon both the language and framework that I have grown to love and switch over to .NET because of trivial issues like compilation speed which should have been fixed decades ago.
|
Doxygen comment are just C++ comment. The C++ parser is optimised to skip them.
Things like dependencies, methods, attributes, class hierarchy, call graph are computed by doxygen.
Note: When you recompile, you don't recompile U++ (BLITZ...). Just your own application. We could say just your modified files.
How to include an image in the final doc: html tag in the doxygen source comment.
How to include a link to another doc or source code(tutorial...): html tag in the doxygen source comment.
How to include a link to load and see the original source code: one option to activate in the doxygen configuration file.
Is it possible to create an external documentation referring to the html output. Something like we already have on ultimatepp.org? Yes.
Do you know a powerful tools that will extract, insert and manage automatically source code comments for doxygen? No 
How can people still add new documentation without touching the source code? Well. You will hate me. An applications like linguist (from Qt) use one tool output, lupdate tool (from Qt too), to extract all translation from .cpp and output a xml file. You can then do the translation job on this file with linguist. It's like TheIDE translation tool but with 2 stand alone applications. They don't reinsert the translation, they load it at run time to save memory (only one language for each xml file because with big application you can have several Mo in one file), but, in a documentation tool like Topic++, this metadata could be validated and reinserted by the documentation project manager.
Then, why still use doxygen: Because doxygen can do a lot of things that Topic++ can't right now. Because if Topic++ become an universal doxygen source code documentation tool it will have a wider audience and will also promote TheIDE and U++.
I include a simple doxygen file to test. Download it in ~/upp, cd into ~/upp then type "doxygen". Doc will be generated in ~/upp/documentation. I used doxywizard (from doxygen package) to create it.
I didn't add "search support" because I guess all people here don't use apache+php on their Pc.
-
Attachment: Doxyfile
(Size: 10.54KB, Downloaded 247 times)
[Updated on: Tue, 02 September 2008 21:06] Report message to a moderator |
|
|
|
|
|
|
|
| Re: U++ talk [message #17916 is a reply to message #17910] |
Tue, 02 September 2008 22:20 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| luzr wrote on Tue, 02 September 2008 21:23 |
| Quote: |
A source clean-up + a strict lower-case name policy for all new .cpp and .h doesn't mean rename internal class. No need to change their names.
|
Well, but you would have to fix all #includes...
|
I can make a bash script if you want. It's not hard to do.
| Quote: |
| Quote: |
The exceptions: class using abbreviations shouldn't use abbreviations. No need to get used to those abbreviations and source code is easier to understand.
|
Not ever. Very long name can make it less understandable.
"Ctrl" is appropriate name for frequently used class.
Also, sometimes there simply is not a proper word to name a thing. That is where those pseudowords are perhaps better than wrong names. At least, so I believe.
|
Sometimes yes.
Control . You save 3 letters.
FileSel, DocEdit::Fmt, PalCtrl...
With TheIDE with Control+","... do we really need to save those few keystrokes?
| Quote: |
| Quote: |
How to include an image in the final doc: html tag in the doxygen source comment.
|
Sure, but that is as tedious as it can get....
|
Not with Topic++ managing Doxygen doc. Do you see it?
[Updated on: Tue, 02 September 2008 22:22] Report message to a moderator |
|
|
|
| Re: U++ talk [message #17917 is a reply to message #17909] |
Tue, 02 September 2008 22:30 |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
| Quote: |
Doxygen comment are just C++ comment. The C++ parser is optimised to skip them.
|
I've seen that optimization in practice... (sarcasm)
| Quote: |
How can people still add new documentation without touching the source code? Well. You will hate me. An applications like linguist (from Qt) use one tool output, lupdate tool (from Qt too), to extract all translation from .cpp and output a xml file. You can then do the translation job on this file with linguist. It's like TheIDE translation tool but with 2 stand alone applications. They don't reinsert the translation, they load it at run time to save memory (only one language for each xml file because with big application you can have several Mo in one file), but, in a documentation tool like Topic++, this metadata could be validated and reinserted by the documentation project manager.
|
It's not about creating translation (current system is working great) as contributing documentation. Someone has to write the documentation directly in the source code. That means write access is needed, plus someone has to test that it still compiles.
If user has doesn't have write access, somebody needs to merge the changes for him. Also, after every doc commit, people will have to recompile their sources and run doxygen on them. And if you distribute prebuilt documentation, you basically are back to square one.
But I'm also unhappy with Topic++. I would like to have an autogenerated DB style documentation, with doxygen style tags but only for some logical ordering, like saying that function Split should appear on the documentation page "String manipulation function" and on "Strings". Running the topic++ toll would generate all pages in qtf, but would not let you edit only specific parts of the file, like implementation notes and parameter descriptions. Also, if a function is removed, it's attached documentation would be hidden, but the information not lost. You could always pull up a screen with dependency graphs.
But Mirek did not like the idea, so now I'm waiting for his idea and when it is ready I'll write some doc pages and hope that other people in the community will have the patience to manually format a consistent looking help content.
|
|
|
|
|
|
|
|
| Re: U++ talk [message #17922 is a reply to message #17917] |
Tue, 02 September 2008 23:37 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| Quote: |
It's not about creating translation (current system is working great) as contributing documentation. Someone has to write the documentation directly in the source code. That means write access is needed, plus someone has to test that it still compiles.
|
At present, people use topic++ right? They save the doc in external files. What I said: do exactly the same process. The document manager (not his subordinates) can have a look into the topic++ work (what his subordinate, those without write access to the code, have done) than, if he think that all is ok, he presses a topic++ button and all validated modifications are synchronized back into the source file, ready for doxygen and U++ final release.
| Quote: |
If user doesn't have write access, somebody needs to merge the changes for him.
|
Yes, modifications has to be validated. U++ API can break at any time before final release. Two eyes are better than one. You keep total control of the final documentation submitted but your contributors have full access to the topic++ generated documentation.
| Quote: |
Also, after every doc commit, people will have to recompile their sources and run doxygen on them. And if you distribute prebuilt documentation, you basically are back to square one.
|
If they don't want to edit the topic++ output, and want the last doxygen output then yes. What prevent them from using topic++ to see the unstable doc? Nothing. How could the topic++ documentation break the source if the integration process is automated by topic++?
|
|
|
|
Goto Forum:
Current Time: Thu Apr 18 08:39:43 CEST 2024
Total time taken to generate the page: 0.01303 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
