|
Henrik Jensen |
|
|
Patches licensed under LGPLv3+/MPL 1.1 ( or what ever Bjoern Michaelsen prefers :-) )
A series of 7 suggested patches to fix some bugs and migrate to One Git in Bjoern Michaelsen Jenkins Continuous Integration Serversetup found in contrib/dev-tools/ubuntu-jenkins Patch descriptions: --------------------------------------------------------------------------------------------------- 0001-Bugfix-Prevent-redundant-tarfile-downloads.patch Bugfix: Prevent redundant tarfile downloads. './download' sources 'Env.Host.sh', not 'LinuxX86-64Env.Set.sh',so we must add 'set_tarfile_location.sh' to 'Env.Host.sh' after first './autogen.sh' run. I speculate if this is an artifact of the cloning from the master and "down-branching" to 3-4 !!!? - Maybe ./download should be called after the second autogen.sh though I can't yet see through the consequences of that? --------------------------------------------------------------------------------------------------- 0002-Bugfix-x86-processor-architecture-agnostic.patch Bugfix: x86 processor architecture agnostic. Checks if 2nd. run of 'autogen.sh' has generated 'LinuxX86Env.Set.sh' or 'LinuxX86-64Env.Set.sh' and use the appropriate one. --------------------------------------------------------------------------------------------------- 0003-Bugfix-Using-the-new-Env.Host.sh-in-libreoffice-mast.patch Bugfix: Using the new 'Env.Host.sh' in libreoffice-master instead of hardcoding 'LinuxX86-64Env.Set.sh' --------------------------------------------------------------------------------------------------- 0004-Bugfix-libreoffice-master-job-needs-a-make-before-ma.patch Bugfix: 'libreoffice-master' job needs a 'make' before 'make dev-install' 'dev-install' has dependencies to the 'all' target but it's not reflected in the lo-root makefile. --------------------------------------------------------------------------------------------------- 0005-Migrate-to-One-Git-keep-possibility-for-3-4-build.patch Migrate to One Git, keep possibility for 3-4 build. - Cloning from 'repo-mirror/core.git' for 'libreoffice-master'. - Cloning from 'repo-mirror-pre-one-git/bootstrap.git' for 'libreoffice-3-4'. - Adding a 'repo-mirror-pre-one-git' to still support the 'libreoffice-3-4' job - Disable cron schedule for the new (old) 'repo-mirror-pre-one-git'. Adding 2 repo-mirrors to support both the new master and the 'libreoffice-3-4' seems a bit unnecessary, but as I understand from asking on #libreoffice-dev the new one-git master can't be used to checkout libreoffice.3.4. Also tried a './g checkout libreoffice-3-4' on the new one-git repo Output: "error: pathspec 'libreoffice-3-4' did not match any file(s) known to git." A solution might be to only mirror the old locked remote master gits and locally use the onegit.sh conversion script located in 'anongit.freedesktop.org/libreoffice/contrib/dev-tools/onegit' to create a new copy and then 'git fetch --all --tags' to update it to the newest? --------------------------------------------------------------------------------------------------- 0006-Using-the-JENKINS_HOME-variable.patch Using the ${JENKINS_HOME} variable Using the ${JENKINS_HOME} variable instead of hardcoding to the '~/.jenkins' path This commit sets up an easier transition to a more generalized install procedure see: https://wiki.jenkins-ci.org/display/JENKINS/Winstone and https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins for the ${JENKINS_HOME} variable --------------------------------------------------------------------------------------------------- 0007-Install-Jenkins-in-current-dir-instead-of-.jenkins.patch Install Jenkins in current dir in stead of ~/.jenkins Let Jenkins be installed in current dir instead of force to '~/.jenkins' 'setup-ubuntu-jenkins.sh' now creates a 'start-lo-jenkins.sh' with the appropriate startup arguments --------------------------------------------------------------------------------------------------- TODO: - Add the ccache lines to './autogen.sh' command line instead of concatenating to 'XEnv.Set.sh/Env.Host.sh' - Let installer choose between installing Jenkins default dir ('~/.jenkins') or current dir. --Henrik Jensen (HenrikJ on #libreoffice-dev) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Norbert Thiebaud |
|
|
On Wed, Aug 10, 2011 at 4:56 PM, Henrik Jensen <[hidden email]> wrote:
> Patches licensed under LGPLv3+/MPL 1.1 ( or what ever Bjoern Michaelsen prefers :-) ) > TODO: > - Add the ccache lines to './autogen.sh' command line instead of concatenating to 'XEnv.Set.sh/Env.Host.sh' ccache is now (on master) automatically used if present in PATH, so there should not be any need for special ccache lines to autogen.sh anymore Norbert _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Noel Power |
|
|
In reply to this post by Henrik Jensen
I guess Bjoern knows most about this, adding him to cc list, think
he is on vacation now but surely will look when he gets back
Noel On 10/08/11 22:56, Henrik Jensen wrote:
_______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
In reply to this post by Henrik Jensen
A few more suggested patches to 'setup-ubuntu-jenkins.sh'
( committed to local clone after 0007-Install-Jenkins-in-current-dir-instead-of-.jenkins.patch so I guess they are dependent ) Patch descriptions: --------------------------------------------------------------------------------------------------- 0001-Add-install-path-to-cmdln.-args.patch: Add install path to cmdln. args. Per default installs in ~/.jenkins or the path added to the command line of setup-ubuntu-jenkins.sh --------------------------------------------------------------------------------------------------- 0002-Add-simple-instructions-for-h-help.patch: Add simple instructions for -h/--help --------------------------------------------------------------------------------------------------- --Henrik Jensen (HenrikJ on #libreoffice-dev) On Wed, 2011-08-10 at 22:56 +0100, Henrik Jensen wrote: Patches licensed under LGPLv3+/MPL 1.1 ( or what ever Bjoern Michaelsen prefers :-) ) > > > A series of 7 suggested patches to fix some bugs and migrate to One Git in Bjoern Michaelsen > Jenkins Continuous Integration Serversetup found in contrib/dev-tools/ubuntu-jenkins > > Patch descriptions: > --------------------------------------------------------------------------------------------------- > 0001-Bugfix-Prevent-redundant-tarfile-downloads.patch > > Bugfix: Prevent redundant tarfile downloads. > > './download' sources 'Env.Host.sh', not 'LinuxX86-64Env.Set.sh',so we must add > 'set_tarfile_location.sh' to 'Env.Host.sh' after first './autogen.sh' run. > I speculate if this is an artifact of the cloning from the master and "down-branching" > to 3-4 !!!? - Maybe ./download should be called after the second autogen.sh though I > can't yet see through the consequences of that? > > --------------------------------------------------------------------------------------------------- > 0002-Bugfix-x86-processor-architecture-agnostic.patch > > Bugfix: x86 processor architecture agnostic. > > Checks if 2nd. run of 'autogen.sh' has generated 'LinuxX86Env.Set.sh' or > 'LinuxX86-64Env.Set.sh' and use the appropriate one. > > --------------------------------------------------------------------------------------------------- > 0003-Bugfix-Using-the-new-Env.Host.sh-in-libreoffice-mast.patch > > Bugfix: Using the new 'Env.Host.sh' in libreoffice-master instead of hardcoding 'LinuxX86-64Env.Set.sh' > > --------------------------------------------------------------------------------------------------- > 0004-Bugfix-libreoffice-master-job-needs-a-make-before-ma.patch > > Bugfix: 'libreoffice-master' job needs a 'make' before 'make dev-install' > > 'dev-install' has dependencies to the 'all' target but it's not reflected in the > lo-root makefile. > > --------------------------------------------------------------------------------------------------- > 0005-Migrate-to-One-Git-keep-possibility-for-3-4-build.patch > > Migrate to One Git, keep possibility for 3-4 build. > > - Cloning from 'repo-mirror/core.git' for 'libreoffice-master'. > - Cloning from 'repo-mirror-pre-one-git/bootstrap.git' for 'libreoffice-3-4'. > - Adding a 'repo-mirror-pre-one-git' to still support the 'libreoffice-3-4' job > - Disable cron schedule for the new (old) 'repo-mirror-pre-one-git'. > > Adding 2 repo-mirrors to support both the new master and the 'libreoffice-3-4' > seems a bit unnecessary, but as I understand from asking on #libreoffice-dev > the new one-git master can't be used to checkout libreoffice.3.4. > Also tried a './g checkout libreoffice-3-4' on the new one-git repo > Output: "error: pathspec 'libreoffice-3-4' did not match any file(s) known to git." > > A solution might be to only mirror the old locked remote master gits and locally use > the onegit.sh conversion script located in > 'anongit.freedesktop.org/libreoffice/contrib/dev-tools/onegit' to create a new > copy and then 'git fetch --all --tags' to update it to the newest? > > --------------------------------------------------------------------------------------------------- > 0006-Using-the-JENKINS_HOME-variable.patch > > Using the ${JENKINS_HOME} variable > > Using the ${JENKINS_HOME} variable instead of hardcoding to the '~/.jenkins' path > This commit sets up an easier transition to a more generalized install procedure > see: https://wiki.jenkins-ci.org/display/JENKINS/Winstone > and https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins > for the ${JENKINS_HOME} variable > > --------------------------------------------------------------------------------------------------- > 0007-Install-Jenkins-in-current-dir-instead-of-.jenkins.patch > > Install Jenkins in current dir in stead of ~/.jenkins > > Let Jenkins be installed in current dir instead of force to '~/.jenkins' > 'setup-ubuntu-jenkins.sh' now creates a 'start-lo-jenkins.sh' with the appropriate startup arguments > > --------------------------------------------------------------------------------------------------- > > TODO: > - Add the ccache lines to './autogen.sh' command line instead of concatenating to 'XEnv.Set.sh/Env.Host.sh' > - Let installer choose between installing Jenkins default dir ('~/.jenkins') or current dir. > > > > --Henrik Jensen > (HenrikJ on #libreoffice-dev) > _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice > _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
In reply to this post by Noel Power
> I guess Bjoern knows most about this, adding him to cc list, think he is on vacation now but surely will look when he gets back
> >Noel Ok, I've put Bjoern Michaelsen on CC for some further small patches. Hope his is alright with that. --Henrik Jensen (HenrikJ on #libreoffice-dev) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
In reply to this post by Norbert Thiebaud
On Thursday, 11 August 2011, 0:56 Norbert Thiebaud wrote:
>On Wed, Aug 10, 2011 at 4:56 PM, Henrik Jensen <[hidden email]> wrote: >> Patches licensed under LGPLv3+/MPL 1.1 ( or what ever Bjoern Michaelsen prefers :-) ) >> TODO: >> - Add the ccache lines to './autogen.sh' command line instead of concatenating to 'XEnv.Set.sh/Env.Host.sh' > >ccache is now (on master) automatically used if present in PATH, so >there should not be any need for special ccache lines to autogen.sh >anymore > >Norbert Ok, well I guess the ccache lines could be removed from the libreoffice-master job in jenkins, but I imagined the ubuntu-jenkins as an easy "one click" method of getting a working build (with added administrative bonuses) for relative newbee/wouldbe developers of lo, so the target users probably does not have ccache set in the enviroment in the first place. ( Though I don't know if that's the way Bjoern Michaelsen visioned it, so I'll wait for his opinions on the subject.) --Henrik Jensen (HenrikJ on #libreoffice) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
In reply to this post by Henrik Jensen
0001-Bugfix-ups-forgot-a-leading-in-shebang-in-start-lo-j.patch:
Bugfix: ups - forgot a leading '/' in shebang in start-lo-jenkins.sh --Henrik Jensen (HenrikJ on #libreoffice-dev) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Bjoern Michaelsen |
|
|
Hi Henrik,
great work, all pushed! On Mon, 15 Aug 2011 06:11:35 +0100 (BST) Henrik Jensen <[hidden email]> wrote: > 0001-Bugfix-ups-forgot-a-leading-in-shebang-in-start-lo-j.patch: As my local setup moved quite a bit from the stuff I originally uploaded, I did not update the scripts there yet. Feel free to commit to the dev-tools repo directly, improving the jenkins setup even more would be awesome! Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
> >Hi Henrik, > >great work, all pushed! > Thanks. >As my local setup moved quite a bit from the stuff I originally >uploaded, I did not update the scripts there yet. Feel free to >commit to the dev-tools repo directly, improving the jenkins setup >even more would be awesome! I appreciate the trust Bjoern :-), but I don't have an freedesktop.org/Libreoffice account yet. I've have only been following the lo-dev project (actively) in a few weeks so I don't think my very low seniority status would entitle me to commit rights on the source tree. (AFAIK I can't get partial commit right to contrib/dev-tools/ubuntu-jenkins) Besides, my git skills are still on the Mickey Mouse level, so I would be a bit fearful 'Goofying' around the source tree ;-). Though I do hope to make some contribution (aside from ubuntu-jenkins) later on. I have thought of some auto-genereated IDE project files (eclipse, netbeans xml stuff) just for browsing the source files (not for compiling), generated from parsing 'make -np' dryruns. Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) code-completion functionality to the star-basic editor. > >Best, > >Bjoern Likewise --Henrik _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Michael Meeks |
|
|
Hi Henrik,
On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote: > > Feel free to commit to the dev-tools repo directly, improving the >> jenkins setup even more would be awesome! > > I appreciate the trust Bjoern :-), but I don't have an freedesktop.org/Libreoffice > account yet. Hey - welcome to the project :-) there are obvious historical Jenkins / LibreOffice synergies somewhere here I think; great to have you on board. > (AFAIK I can't get partial commit right to contrib/dev-tools/ubuntu-jenkins) We can easily ask you to push only to there without further approval, which I suspect is a stronger force than most access controls out there ;-) but it'd be good to get a few more patches first, as you say. > Besides, my git skills are still on the Mickey Mouse level, so I would be a bit > fearful 'Goofying' around the source tree ;-). As long as you don't 'git push' randomly you're safe; and the most errors problems should be disallowed by the server so ... > Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) > the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser > as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) > code-completion functionality to the star-basic editor. Ah - that would indeed be nice; unfortunately - queryInterface makes a dogs breakfast of type inference from objects: by the power of 'meta'ness ;-) we have no idea what interfaces are supported, and we are constantly loosing strong type information down 'Any' shaped holes - which is a shame. But - it'd be great to resurrect the object browser & get it integrated no doubt. Thanks ! Michael. -- [hidden email] <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
Hi Michael On 16-08-2011 17:50, Michael Meeks wrote: > Hi Henrik, > > On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote: >>> Feel free to commit to the dev-tools repo directly, improving the >>> jenkins setup even more would be awesome! >> >> I appreciate the trust Bjoern :-), but I don't have an freedesktop.org/Libreoffice >> account yet. > > Hey - welcome to the project :-) there are obvious historical Jenkins / > LibreOffice synergies somewhere here I think; great to have you on > board. > Thanks :-) I'm not really into Jenkins (yet) but a blog post by Bjoern http://sweetshark.livejournal.com/1858.html inspired me to use Jenkins as a starting point for my local source tree so I can experiment to my hearts content with git and the code, an always be able to do a complete revert without needing a slow clone from the remote repo. >> (AFAIK I can't get partial commit right to contrib/dev-tools/ubuntu-jenkins) > > We can easily ask you to push only to there without further approval, > which I suspect is a stronger force than most access controls out > there ;-) but it'd be good to get a few more patches first, as you say. > Yeah, I'll just continue to submit patches for ubuntu-jenkins here for Bjoern and others to review when the see the time to it. >> Besides, my git skills are still on the Mickey Mouse level, so I would be a bit >> fearful 'Goofying' around the source tree ;-). > > As long as you don't 'git push' randomly you're safe; and the most > errors problems should be disallowed by the server so ... > >> Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) >> the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser >> as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) >> code-completion functionality to the star-basic editor. > > Ah - that would indeed be nice; unfortunately - queryInterface makes a > dogs breakfast of type inference from objects: by the power of > 'meta'ness ;-) we have no idea what interfaces are supported, and we are > constantly loosing strong type information down 'Any' shaped holes - > which is a shame. Oh my, that sounds more like politicians with vague promises than interfaces with contracts. :-P. Heh, I got this feeling I'm probably better off slowly turning the lid back on what appears to be a can of worms, hoping not to many noticed, and focus on more realistic objectives for the near future. :-) Jokes aside, I'm a bit surprised of these difficulties because there seems to be plenty of reflection interfaces in the uno-framework: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/AdvUNO/UNO_Reflection_API ? Is the Editor component on a too low layer to take advantages of these ? > > But - it'd be great to resurrect the object browser& get it integrated > no doubt. > > Thanks ! > > Michael. > Thanks for the reply --Henrik _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
In reply to this post by Henrik Jensen
Makes it easier to move the jenkins install directory without the need to change
paths in 'start-lo-jenkins.sh' This script could now be placed as a file in the contrib/devtools/ubuntu-jenkins dir alternative to being generated by setup-ubuntu-jenkins.sh as it currently is. I'm not sure what's preferable. --Henrik Jensen (HenrikJ on #libreoffice-dev) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Bjoern Michaelsen |
|
|
On Fri, 19 Aug 2011 01:33:47 +0100 (BST)
Henrik Jensen <[hidden email]> wrote: > Makes it easier to move the jenkins install directory without the > need to change paths in 'start-lo-jenkins.sh' Pushed, thanks! Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Stephan Bergmann |
|
|
In reply to this post by Henrik Jensen
On Aug 19, 2011, at 2:06 AM, Henrik Jensen wrote:
> On 16-08-2011 17:50, Michael Meeks wrote: >> On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote: >>> Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) >>> the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser >>> as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) >>> code-completion functionality to the star-basic editor. >> >> Ah - that would indeed be nice; unfortunately - queryInterface makes a >> dogs breakfast of type inference from objects: by the power of >> 'meta'ness ;-) we have no idea what interfaces are supported, and we are >> constantly loosing strong type information down 'Any' shaped holes - >> which is a shame. > > Oh my, that sounds more like politicians with vague promises than interfaces with contracts. :-P. Heh, I got this feeling I'm probably better off slowly turning the lid back on what appears to be a can of worms, hoping not to many noticed, and focus on more realistic objectives for the near future. :-) > > Jokes aside, I'm a bit surprised of these difficulties because there seems to be plenty of reflection interfaces in the uno-framework: > http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/AdvUNO/UNO_Reflection_API ? > Is the Editor component on a too low layer to take advantages of these ? The problem is rather that much of the interesting information about UNO objects is only available dynamically, at runtime. The static type information that is available is indeed often just only XInterface (or some other basic interface type) or ANY. So you generally face the same problems wrt code completion as you face with any of today's dynamic programming languages. UNO has the concepts to do better, but most parts of the API do not make use of them. -Stephan _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen |
|
|
Hi Stephan
On 19-08-2011 09:40, Stephan Bergmann wrote: > On Aug 19, 2011, at 2:06 AM, Henrik Jensen wrote: >> On 16-08-2011 17:50, Michael Meeks wrote: >>> On Mon, 2011-08-15 at 23:40 +0100, Henrik Jensen wrote: >>>> Later when I feel more comfortable with the code, I hope to be able to use (resurrect ?) >>>> the old GSOC 2006 project http://wiki.services.openoffice.org/wiki/BASIC/UNO_Object_Browser >>>> as a stepping stone for pursuing an old dream of adding (at least some primitive kind of) >>>> code-completion functionality to the star-basic editor. >>> >>> Ah - that would indeed be nice; unfortunately - queryInterface makes a >>> dogs breakfast of type inference from objects: by the power of >>> 'meta'ness ;-) we have no idea what interfaces are supported, and we are >>> constantly loosing strong type information down 'Any' shaped holes - >>> which is a shame. >> >> Oh my, that sounds more like politicians with vague promises than interfaces with contracts. :-P. Heh, I got this feeling I'm probably better off slowly turning the lid back on what appears to be a can of worms, hoping not to many noticed, and focus on more realistic objectives for the near future. :-) >> >> Jokes aside, I'm a bit surprised of these difficulties because there seems to be plenty of reflection interfaces in the uno-framework: >> http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/AdvUNO/UNO_Reflection_API ? >> Is the Editor component on a too low layer to take advantages of these ? > > The problem is rather that much of the interesting information about UNO objects is only available dynamically, at runtime. The static type information that is available is indeed often just only XInterface (or some other basic interface type) or ANY. So you generally face the same problems wrt code completion as you face with any of today's dynamic programming languages. UNO has the concepts to do better, but most parts of the API do not make use of them. > > -Stephan If I understand the problem correctly: So the hypothetical code-completion engine has to, at runtime, initialize all kinds of temp-objects and objects they use and so forth and destroy them afterwards, to be able to extract type information on them. This kind of tedious house holding should have been eased with the reflection and introspection interfaces but the rest of the api does not support these interfaces very good? --Henrik _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Noel Power |
|
|
On 20/08/11 11:41, Henrik Jensen wrote:
> Hi Stephan > > On 19-08-2011 09:40, Stephan Bergmann wrote: > If I understand the problem correctly: So the hypothetical > code-completion engine has to, at runtime, initialize all kinds of > temp-objects and objects they use and so forth and destroy them > afterwards, to be able to extract type information on them. This kind > of tedious house holding should have been eased with the reflection > and introspection interfaces but the rest of the api does not support > these interfaces very good? an object you need some hint about the type, unfortunately there are 2 things that make doing this with the basic IDE difficult, a) Libreoffice basic like most scripting languages is a very loosely typed, so mostly there is *no* information available at compile time. Most scripting languages ( VBA for example ) allow you to explicitly define the type of an object and this is where you can get some real bang with a refection api. Libreoffice basic only has the 'Object' type ( which could be an UNO object ) it doesn't support any specific uno object types. b) like Stephan and others mention, the problem about the uno objects is that mostly the useful information is only available at runtime, so.. even if stronger typing were available from Basic( and it would be possible to do that I think without needing heroic effort ) the amount of useful information would not be that great ( but maybe better than nothing ) Of course that would bring the question of what 'types' should you be able to define an object as, defining an object as some sort of XSomething in reality only would allow you access to a small facet of the object's methods/properties etc. Being able to define an object as some sort of Service type has been proposed in previous discussion along these lines but I don't think the needed information is currently stored in the types/services db(s) additionally the accuracy of such definitions where they exist could be well... questionable. Noel _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Andrew Douglas Pitonyak |
|
|
In reply to this post by Henrik Jensen
When I write a macro, I am usually using a loosely typed object so the type is not fully known. Even worse, based on the execution path, the object type may be completely different than expected. Unless your variables are explicitly stated as to type, it would likely not be possible to implement. _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen-2 |
|
|
In reply to this post by Henrik Jensen
--Henrik Jensen (HenrikJ on #libreoffice-dev) _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Bjoern Michaelsen |
|
|
On Fri, 26 Aug 2011 16:42:31 +0100 (BST)
Henrik Jensen <[hidden email]> wrote: > > --Henrik Jensen > > > (HenrikJ on #libreoffice-dev) PUSHED as dev-tools:487e084c291fd9d1827a2190671a386f0303c5aa. Please confirm this patch (and hopefully all following to the list) to be MPL 1.1 / GPLv3+ / LGPLv3+ licensed. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
|
Henrik Jensen-2 |
|
|
> ----- Original Message ----- > From: Bjoern Michaelsen <[hidden email]> > To: Henrik Jensen <[hidden email]> > Cc: Henrik Jensen <[hidden email]>; "[hidden email]" <[hidden email]> > Sent: Friday, 26 August 2011, 18:07 > Subject: [Libreoffice] [PUSHED] Download and install git plugin for jenkins > > On Fri, 26 Aug 2011 16:42:31 +0100 (BST) > Henrik Jensen <[hidden email]> wrote: > > > > --Henrik Jensen > > > > > > (HenrikJ on #libreoffice-dev) > > PUSHED as dev-tools:487e084c291fd9d1827a2190671a386f0303c5aa. > > Please confirm this patch (and hopefully all following to the list) to > be MPL 1.1 / GPLv3+ / LGPLv3+ licensed. > > Best, > > Bjoern I hereby confirm that this patch, all my previous patches and following patches to this list are licensed under MPL 1.1 / GPLv3+ / LGPLv3+. --Henrik _______________________________________________ LibreOffice mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/libreoffice |
| Powered by Nabble | Edit this page |