Hi,
I'd like to ask a more general question regarding the porting effort. As we all have seen, activity died down after an initial euphoria. This is dangerous as it might lead to a complete standstill.
Therefore, the question is this: Currently, work is underway to get the dependencies ported. But in the very early stages, some of them aren't really needed. So theoretically, work could be started on the low-level parts of OpenOffice itself, for example the build environment and SAL, resolving dependencies as they come up, maybe even creating "dummies" for seldom-used functionality (for example, I've never used any USB stuff with OpenOffice).
Ok, that's just food for thought.
BTW, OOo builds via dmake, which we already ported (SNAP also builds with dmake). It just depends on newlib V3 which will be in the next update.
Regards,
On 2005-05-30, Thomas Frieden wrote:
<SNIP>
really needed. So theoretically, work could be started on the low-level parts of OpenOffice itself, for example the build environment and SAL, resolving dependencies as they come up, maybe even creating "dummies" for seldom-used functionality (for example, I've never used any USB stuff with OpenOffice).
Ok, that's just food for thought.
<SNIP>
Well, it is a good idea (I think). One candidate which I think I mentioned earlier (=several moths ago) might be UNO. Looking at UNO bridges for different languages (C, C++, Python?) might be one way to get the actual OOo porting started and it would be fairly easy to write tests I think. (But I am in no way certain since I am not familiar with the internals of UNO).
-Peter aka. Archprogrammer
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
Hi,
Peter Bengtsson wrote:
Well, it is a good idea (I think). One candidate which I think I mentioned earlier (=several moths ago) might be UNO. Looking at UNO bridges for different languages (C, C++, Python?) might be one way to get the actual OOo porting started and it would be fairly easy to write tests I think. (But I am in no way certain since I am not familiar with the internals of UNO).
Me neither. And AFAIK, it's got Java on one end ? In that case, you can forget about me. I don't know a single thing about Java :S
Regards,
On 2005-05-31, Thomas Frieden wrote:
Hi,
Peter Bengtsson wrote:
Well, it is a good idea (I think). One candidate which I think I mentioned earlier (=several moths ago) might be UNO. Looking at UNO bridges for different languages (C, C++, Python?) might be one way to get the actual OOo porting started and it would be fairly easy to write tests I think. (But I am in no way certain since I am not familiar with the internals of UNO).
Me neither. And AFAIK, it's got Java on one end ? In that case, you can forget about me. I don't know a single thing about Java :S
I do not think Java is required. I seem to recall that UNO was somewhat similar to CORBA - i.e. it is a message-passing/method-invocation layer between different parts of OOo. If no Java is required, it will be possible to test by e.g. invoking an UNO method from a C program to another C (or C++) program.
Oh well, back to grading exams...
-Peter aka. Archprogrammer
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
Hi,
Peter Bengtsson wrote:
I do not think Java is required. I seem to recall that UNO was somewhat similar to CORBA - i.e. it is a message-passing/method-invocation layer between different parts of OOo. If no Java is required, it will be possible to test by e.g. invoking an UNO method from a C program to another C (or C++) program.
Oh, so it's the OOo incarnation of Mozilla's XPCOM :)
I'll try to get some more information about it.
Regards,
Hi,
Peter Bengtsson wrote:
Well, it is a good idea (I think). One candidate which I think I mentioned earlier (=several moths ago) might be UNO. Looking at UNO bridges for different languages (C, C++, Python?) might be one way to get the actual OOo porting started and it would be fairly easy to write tests I think. (But I am in no way certain since I am not familiar with the internals of UNO).
I had a bit of a look at UNO, and it seems to be tied to SAL.
So I would suggest to start out with the system abstraction layer first.
I offer to take a look at it and make an assesment of the work required.
Regards,
Hello Thomas
On 06/06/2005, you wrote:
I had a bit of a look at UNO, and it seems to be tied to SAL.
So I would suggest to start out with the system abstraction layer first.
I offer to take a look at it and make an assesment of the work required.
I took the liberty to create a Project called SAL on the devsite, and created a task for this, good luck ;)
Regards
Hello Thomas
On 30/05/2005, you wrote:
Hi,
I'd like to ask a more general question regarding the porting effort. As we all have seen, activity died down after an initial euphoria. This is dangerous as it might lead to a complete standstill.
This is partly (mostly?) my fault, my personal life got in the way of the porting effort, for wich i apologise.
Therefore, the question is this: Currently, work is underway to get the dependencies ported. But in the very early stages, some of them aren't really needed. So theoretically, work could be started on the low-level parts of OpenOffice itself, for example the build environment and SAL, resolving dependencies as they come up, maybe even creating "dummies" for seldom-used functionality (for example, I've never used any USB stuff with OpenOffice).
Agreed, this was actually the original idea, except we started/tried to start with things that could be usefull to other projects (lubusb/sane in itself is in my opinion a worthy project, as it would provide OS4 with scanner support for hundreds of scanners), but maybe we should review these desissions.
Also, we really need to start using the CVS, so that when people disapear their work doesn't
Ok, that's just food for thought.
BTW, OOo builds via dmake, which we already ported (SNAP also builds with dmake). It just depends on newlib V3 which will be in the next update.
Theoretical question, could dmake run/build on classic and would it be worth the hassle?
Regards
Hi,
Christophe Ochal wrote:
This is partly (mostly?) my fault, my personal life got in the way of the porting effort, for wich i apologise.
No worries. I've been through some pretty stiff times myself as well.
Agreed, this was actually the original idea, except we started/tried to start with things that could be usefull to other projects (lubusb/sane in itself is in my opinion a worthy project, as it would provide OS4 with scanner support for hundreds of scanners), but maybe we should review these desissions.
It's definitely worth it, but it shouldn't keep others from working on the core parts already :)
Also, we really need to start using the CVS, so that when people disapear their work doesn't
BTW: Olaf Barthel has ported subversion to OS4.
Theoretical question, could dmake run/build on classic and would it be worth the hassle?
Well, it builds with newlib, not clib2. With clib2, a 68k port would be possible without modification... with newlib, it's not that easy...
Speaking of ports necessary for the work on OOo, I've got most of coreutils ported as well :)
Regards,
On 2005/05/31, Thomas Frieden wrote:
Also, we really need to start using the CVS, so that when people disapear their work doesn't
BTW: Olaf Barthel has ported subversion to OS4.
I have been testing Olaf's port of svn and found that there is a bug in commit.
I install a svn server on my VIA server and imported some project without any problems, but later I wanted to commit some changes to my source and that dident go well. So untill Olaf correct the bug I cant recomment switching to svn just yet... I have sent a bug report to Olaf so only time well tell when it's gonna be fixed.
PS: dont get me wrong, I'm all for using SVN in sted of CVS
Regards Rene W. Olsen
Hi,
It is possible i soon will have a dedicated server in colocation where i will have full access. (soon is within 6 months ;) If/when i obtain it, i will be able to host a svn server (with backup) aswell as give shell accounts to trusted people with access to gcc & cross compilers, including ftp access.
However, is it possible to sync svn with cvs? If so, i could get the server to sync it with the sourceforge cvs.
Op 1-jun-05, om 13:58 heeft Rene W. Olsen het volgende geschreven:
On 2005/05/31, Thomas Frieden wrote:
Also, we really need to start using the CVS, so that when people disapear their work doesn't
BTW: Olaf Barthel has ported subversion to OS4.
I have been testing Olaf's port of svn and found that there is a bug in commit.
I install a svn server on my VIA server and imported some project without any problems, but later I wanted to commit some changes to my source and that dident go well. So untill Olaf correct the bug I cant recomment switching to svn just yet... I have sent a bug report to Olaf so only time well tell when it's gonna be fixed.
PS: dont get me wrong, I'm all for using SVN in sted of CVS
Regards Rene W. Olsen
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Hi,
Ochal Christophe wrote:
However, is it possible to sync svn with cvs? If so, i could get the server to sync it with the sourceforge cvs.
cvs2svn can do something like this, it was used to convert AROS cvs to svn repository, though there were some issues.
Markus
Hello Markus
On 01/06/2005, you wrote:
Hi,
Ochal Christophe wrote:
However, is it possible to sync svn with cvs? If so, i could get the server to sync it with the sourceforge cvs.
cvs2svn can do something like this, it was used to convert AROS cvs to svn repository, though there were some issues.
I'll look into it, oh, and there are always issue's with things in linuxland, you get used to that :P
Regards
Hi,
Rene W. Olsen wrote:
PS: dont get me wrong, I'm all for using SVN in sted of CVS
I didn't want to imply going to SVN instead of CVS. I just mentioned that there is a client now since we discussed it at one point in the past...
Regards,
Hi,
Thomas Frieden wrote:
BTW, OOo builds via dmake, which we already ported (SNAP also builds with dmake). It just depends on newlib V3 which will be in the next update.
Another thing that we've developed that might be very interesting: We now have a tool that can turn a standard static link library into a shared library, i.e. you feed it libXXX.a and it generates XXX.so, including a linker stub that automtatically imports symbols.
In addition, we have libdl.a which implements (based on these shared libraries) the functions dlopen/dlysm/dlclose.
This might come in handy :)
Regards,
Hi all,
I've written several replies to these things, but it seems something at home is knackered, blocking port 25, i'm going to be troubleshooting these issue's tonight.
I'll send them when it's working again.
(Gotta love computers eh?)
Op 31-mei-05, om 16:03 heeft Thomas Frieden het volgende geschreven:
Hi,
Thomas Frieden wrote:
BTW, OOo builds via dmake, which we already ported (SNAP also builds with dmake). It just depends on newlib V3 which will be in the next update.
Another thing that we've developed that might be very interesting: We now have a tool that can turn a standard static link library into a shared library, i.e. you feed it libXXX.a and it generates XXX.so, including a linker stub that automtatically imports symbols.
In addition, we have libdl.a which implements (based on these shared libraries) the functions dlopen/dlysm/dlclose.
This might come in handy :)
Regards,
-- Thomas Frieden ThomasF@hyperion-entertainment.biz Hyperion Entertainment
- Naur dan i-deryg lhuin
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
-
Christophe Ochal -
Markus Weiss -
Ochal Christophe
-
Peter Bengtsson -
Rene W. Olsen -
Thomas Frieden