Re: [dev] Executable Memory
On Fri, 2006-03-17 at 10:17 +0100, Stephan Bergmann wrote: 3 Exploiting the fact that the executable memory in question is never freed, add a simple, special-purpose (executable) memory allocator to bridges/source/cpp_uno/shared. It would work similar to rtl_allocateMemory by using mmap (or equivalent), but would be much simpler since it would not have to keep track of a free list: if there is enough space left at the end of the last obtained mmap area, use that; otherwise, obtain a new mmap area. Pro: local change in C++ UNO bridges, no new interface in rtl/alloc.h needed, does not make too much memory executable. Con: can't think of one. Sure. It sounds the quickest and easiest fix. It's a real non-theoretical problem for OOo under SELinux enabled linux (e.g. Fedora) which has been biting us for a while. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Executable Memory
Hi Stephan, sorry for jumping in late; see my comments inline... Stephan Bergmann wrote On 03/17/06 15:59,: Kay Ramme - Sun Germany - Hamburg wrote: Stephan, Stephan Bergmann wrote: 2 Add rtl_allocateExecutableMemory to rtl/alloc.h, which internally uses the same logic as rtl_allocateMemory, but works on a second set of memory, independent of the original set of memory managed by plain rtl_allocateMemory (and the second set of memory would be executable, while the original set would not be). Pro: general solution, re-uses existing program logic, does not make too much memory executable. Con: extends rtl/alloc.h interface, complicates rtl/alloc. Matthias Huetsch is AFAIK implementing this API for rtl anyway. So, I suggest to go with this approach. With which motivation, Matthias? Part of my motivation is the issue that you mentioned in the email that started this thread, i.e. issue 47132 (and its predecessor issue 25250, that has been workarounded for OOo 1.1.1 as you described under your topic 1). The primary motivation though is that I am currently fixing a couple of performance issues with the existing allocators (rtl_allocateMemory and class FixedMempool). To start with this, I wrote down a short list of requirements for allocators, and your issue is on that list, of course. AFAIK bridges/cpp_uno is the only place where executable memory is needed. Yes, that's true. There are no other consumers of such an API right now. Or are we about to fix the same issue simultaneously? Yes, looks like we're doing some overlapping work here. More precisely, I'm going to offer the functionality that you need to fix your issue. So, I guess we better start to coordinate our work here. -Stephan Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Executable Memory
Matthias Huetsch wrote: Hi Stephan, sorry for jumping in late; see my comments inline... Stephan Bergmann wrote On 03/17/06 15:59,: [...] Part of my motivation is the issue that you mentioned in the email that started this thread, i.e. issue 47132 (and its predecessor issue 25250, that has been workarounded for OOo 1.1.1 as you described under your topic 1). The primary motivation though is that I am currently fixing a couple of performance issues with the existing allocators (rtl_allocateMemory and class FixedMempool). To start with this, I wrote down a short list of requirements for allocators, and your issue is on that list, of course. AFAIK bridges/cpp_uno is the only place where executable memory is needed. Yes, that's true. There are no other consumers of such an API right now. Or are we about to fix the same issue simultaneously? Yes, looks like we're doing some overlapping work here. More precisely, I'm going to offer the functionality that you need to fix your issue. So, I guess we better start to coordinate our work here. Matthias, I'll take issue 47132 off of target 2.0.3 and postpone it until your changes to rtl/alloc are done---any idea what timeframe that will be? -Stephan -Stephan Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] How can I load a JavaScript library in a JavaScript Macro enviroment?
How can I load a library in JavaScript Macro enviroment? I need use functions in another (js/Macro) file, how can I do that? I only know how to do that in StarBasic, but the same function don't work with JavaScript and I can't find documentation about that. Thanks about some help. - Yahoo! Search Dê uma espiadinha e saiba tudo sobre o Big Brother Brasil.
Re: [dev] Using the 'shell' command in OOo 2.0.2
On Tue, 2006-03-21 at 01:42 +0100, Gerrit Jasper wrote: Gentlemen/ladies, I'm not sure that I completely understand the 'curl part is skipped' part of your description, but ... Have you checked the environment that OOo executes the script in? I see that the soffice script modifies and exports LD_LIBRARY_PATH and PATH by adding locations to the head of the list, so a conflicting library and utility name may change behaviour somehow. I would check the environment of your working and non-working shells using 'ps' with the 'e' flag, or look in the /proc filesystem. (Put a long 'sleep' call in your script to make it wait while you check). If it is the environment, you could perhaps ensure that your script is not dependent on the inherited environment. Hope that helps. 1.After reading reassurances on the lists (dev, api-dev) that previously written code can be run on OOo 2.0 without a problem, I switched from 1.1.4 (I think it was) to 2.0.1 some weeks ago, and then to 2.0.2. Indeed my Basic macros run happily, I can use the mouse to select points in charts where I want trend lines, have them do calculations on that, etc. Happily, until they (the macros) need to use the 'shell' command or call one of my dialogs (separate e-mail). 2.Some years ago I made a bunch of bash scripts to collect data from the internet, have them convert html2text, select data I want as plain text, and trigger my OOo spreadsheet to come and get it. That worked fine with pre-2.0 OOo. Not any more. 3.The bash script removes an existing file and then issues a 'curl' command to get a webpage (http://curl.haxx.se; it came with SuSE 10.0), checks progress and finally calls the spreadsheet. With OOo 2.0.2 the command 'shell( /usr/gerrit/nt_web/crl_opt_dB )' does get to the bash script, because the existing file will be removed, /but the 'curl' part is skipped or doesn't work/, the progress check times out and the script quits. 4. When I run this same script from the KDE browser or from the console it works perfectly, calls the spreadsheet and that imports the plain text data all right. That is why I think there is something wrong with the 'shell' command, but I have no idea what. Is this a bug or did I miss something? I checked the Basic Help and I have been tinkering with commas, bSync true and false. Default is false, so 'shell' should let go immediately after issuing the command. Does anybody have any idea? Sincerely, Gerrit Jasper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How can I load a JavaScript library in a JavaScript Macro enviroment?
Hi Luiz, i am not really a JavaScript user, is it possible to load a JavaScript library from another library? If yes you should try it the same way. Maybe it helps to take a look to http://www.beanshell.org/ and/or http://www.mozilla.org/rhino/ Sorry that i can't help further Juergen Luiz Siqueira wrote: How can I load a library in JavaScript Macro enviroment? I need use functions in another (js/Macro) file, how can I do that? I only know how to do that in StarBasic, but the same function don't work with JavaScript and I can't find documentation about that. Thanks about some help. - Yahoo! Search Dê uma espiadinha e saiba tudo sobre o Big Brother Brasil. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
