|
|
Home » Developing U++ » U++ Developers corner » Google Summer of Code
|
|
|
|
Re: Google Summer of Code [message #31223 is a reply to message #25695] |
Tue, 15 February 2011 23:16 |
raxvan
Messages: 60 Registered: December 2009
|
Member |
|
|
Hello,
The main purpose of the app is to use the computing power of idle workstations in order to speed up the compiling speed for a project. Usually most of the time, the CPU of a machine is not used 100% therefore when other people need to compile a big project the extra power can speed up this process significantly.
Also another advantage of having such a system is the ability to compile and run on other remote platforms making the development for multiple operating systems much easier. The programmer can use the development environment of his choice and compile for any OS that has a build server running. This will increases productivity many times over just because the developer will use the IDE he is used with (constantly switching between Window and Mac is really a pain).
Having a server with the ability to compile code remotely allows users to create a really powerful build machine keeping the costs of other computers down just because the user has to only run a simple editor. Also, if we take for example the package system of TheIde, the server can dynamically choose already built sources increasing the build speed even further.
The main purpose of the Distributed Build System is to allow programmers to build projects on multiple machines, but this can be extended even further. For example the server can keep track of the source repository, automated nightly buils, or last stable binary files.
Raxvan.
92b48bf94855483bb4cec8bcc8c0c933
|
|
|
Re: Google Summer of Code [message #31267 is a reply to message #31220] |
Thu, 17 February 2011 16:49 |
|
Another Idea:
- Name:
Google V8 JavaScript in U++
- Proposed by:
Ion Lupascu
- Difficulty:
Medium
- Experience required:
UPP, V8 JavaScript, JavaScript
- Description:
V8 implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors. In U++ V8 will be a good choise to create possibility for extensions.
- Mentors:
TBD
- Roadmap:
TBD
|
|
|
|
Re: Google Summer of Code [message #31303 is a reply to message #31277] |
Sat, 19 February 2011 22:02 |
|
koldo
Messages: 3372 Registered: August 2008
|
Senior Veteran |
|
|
Hello all
At the same time of IRC meeting, I was talking with Borja, the GSoC administrator for Globus and mentor of OpenNebula. I expect in next days help from a KDE mentor too.
He helped OpenMedula last year and they were accepted, so I think his help will be valuable .
Borja said the most important thing in a project is the ideas list. The level of detail for our list is good, but he says we need more ideas, at least 10.
He also said that ideas list often lead to interesting projects, but (in his experience) the best projects come from students that propose their own projects based on discussions with potential mentors.
So it is a good idea to include a list of mentors including their "skills" to encourage the students to contact with them. This way if they have ideas for a project that are not part of the list provided, they know to whom to contact.
He commented that people often includes ideas too complicated to be resolved in 3 months by a student. In Globus and OpenMedula they call them "blue sky" ideas.
He considered it was a good idea to create the "Tutoring Plan" because Google appreciates that the organization has experience working with students.
In a short summary:
- we have to submit more ideas
- if you want to be a mentor, please join the team and describe your skills in few words
- if you are a student, let us know (we will indicate that the idea comes from a student), an talk with possible mentors to polish the idea.
Best regards
Iñaki
[Updated on: Sun, 20 February 2011 09:24] Report message to a moderator
|
|
|
|
|
Re: Google Summer of Code [message #31306 is a reply to message #31305] |
Sun, 20 February 2011 12:10 |
gprentice
Messages: 260 Registered: November 2005 Location: New Zealand
|
Experienced Member |
|
|
koldo wrote on Sun, 20 February 2011 21:33 |
Included!
We have now 8 ideas. With a few more we will be more eligible .
|
lol!
I'd like to suggest an extension to Mr Ped idea of the T++ preview. Improve the infrastructure of U++ help in general, maybe using Kohait help viewer. Possibly even create a standalone help package.
1. Structured table of contents in parallel with existing "package reference" help. Anyone can add things or add their own pages locally.
2. Existing topic++ pages can be linked to and links within those pages work whether they're viewed from the "new" help or existing.
3. Provide, history, favorites, bookmarks and retrace.
4. Press F1 in source code and the help window shows help for word under cursor i.e. add a mechanism that supports this.
5. Click on a blue square and you see the topic page in non-edit mode i.e. go straight to Mr Ped "preview mode".
6. Improve the help search so it takes you to the exact line.
7. Add "tag word" mechanism so that tag words can be assigned to a topic++ page and searched for.
For extra credit
1. Generate pdf with table of contents of it all
2. Convert from topic++ format to google docs format and vice versa - maybe.
3. Improve/ automate the mechanism for users to submit changes/ improvements to the help.
Should be plenty of people capable of mentoring this but I'm not one of them...
Sooner or later I'm going to do some of this myself if no-one else does.
Graeme.
[Updated on: Sun, 20 February 2011 12:13] Report message to a moderator
|
|
|
|
|
|
|
Re: Google Summer of Code [message #31333 is a reply to message #31324] |
Wed, 23 February 2011 06:07 |
Novo
Messages: 1363 Registered: December 2006
|
Ultimate Contributor |
|
|
koldo wrote on Mon, 21 February 2011 18:24 |
Novo wrote on Sun, 20 February 2011 17:43 |
andreincx wrote on Wed, 09 February 2011 03:35 | - U++ as a library - lib files for simple linkage from other IDE's and dll/so to make it easier to write plugins which use U++.
Andrei
|
How about using application itself as a library? Export required symbols from application and link against it. Theoretically, this should work.
|
Hello Novo
Could you detail it more . Like to be understood by (a dummy like) me...
|
Applications in ELF and COFF (Unix and Windows) formats are DLLs by them self. By default they do not export any symbols. This situation can be changed by using -E options with gcc linker on Linux (this will export all symbols), using dllexport on Windows (as with regular DLL), or by using a special file, which lists all symbols, which should be exported (this should work at least on Windows).
If I remember correctly, you do not need to do anything else in case of Unix (ELF). By default Unix applications (ELF) are compiled with lazy symbol binding. This means that symbols are resolved at run time only if they are needed. If they are exported from application, they will be resolved.
In case of Windows and old Unix (COFF format) all symbols should be resolved at link time. You will need to link your DLL against your_application.lib. I haven't tried to do this by myself, but I believe this should work.
Regards,
Novo
|
|
|
Re: Google Summer of Code [message #31334 is a reply to message #31333] |
Wed, 23 February 2011 09:20 |
|
koldo
Messages: 3372 Registered: August 2008
|
Senior Veteran |
|
|
Novo wrote on Wed, 23 February 2011 06:07 |
koldo wrote on Mon, 21 February 2011 18:24 |
Novo wrote on Sun, 20 February 2011 17:43 |
andreincx wrote on Wed, 09 February 2011 03:35 | - U++ as a library - lib files for simple linkage from other IDE's and dll/so to make it easier to write plugins which use U++.
Andrei
|
How about using application itself as a library? Export required symbols from application and link against it. Theoretically, this should work.
|
Hello Novo
Could you detail it more . Like to be understood by (a dummy like) me...
|
Applications in ELF and COFF (Unix and Windows) formats are DLLs by them self. By default they do not export any symbols. This situation can be changed by using -E options with gcc linker on Linux (this will export all symbols), using dllexport on Windows (as with regular DLL), or by using a special file, which lists all symbols, which should be exported (this should work at least on Windows).
If I remember correctly, you do not need to do anything else in case of Unix (ELF). By default Unix applications (ELF) are compiled with lazy symbol binding. This means that symbols are resolved at run time only if they are needed. If they are exported from application, they will be resolved.
In case of Windows and old Unix (COFF format) all symbols should be resolved at link time. You will need to link your DLL against your_application.lib. I haven't tried to do this by myself, but I believe this should work.
|
Hello Novo
Do you mean, to create a kind of dynamic plugin system?
Best regards
Iñaki
|
|
|
Re: Google Summer of Code [message #31340 is a reply to message #31334] |
Wed, 23 February 2011 15:44 |
Novo
Messages: 1363 Registered: December 2006
|
Ultimate Contributor |
|
|
koldo wrote on Wed, 23 February 2011 03:20 | Do you mean, to create a kind of dynamic plugin system?
|
Anything, which can be used as extension of UPP. Dynamic plugin system requires support in UPP. Theoretically, packages can be compiled as DLLs and linked in or loaded on demand.
Regards,
Novo
|
|
|
|
Re: Google Summer of Code [message #31345 is a reply to message #31342] |
Wed, 23 February 2011 23:55 |
|
koldo wrote on Wed, 23 February 2011 16:34 | Hello Novo
In this recent post mirek said he did not want a dynamic plugin.
|
Hi Koldo,
I think Mirek wanted to say that the plugin architecture you're exposed in that thread can't be used as plugins (dll/so) loadable at runtime. AFAIK Mirek agree to have possibility to use plugins with U++. IMO the only thing that stops that is that U++ can't be compiled (easily?) as dll/so. But if Novo is right, then it should be possible, yet i like more the traditional solution
Andrei
|
|
|
Goto Forum:
Current Time: Mon Jun 17 07:40:17 CEST 2024
Total time taken to generate the page: 0.03121 seconds
|
|
|