Re: svn commit: r1798446 - /openoffice/ooo-site/trunk/content/stats/countries.html
Am 18.06.2017 um 21:48 schrieb Matthias Seidel: Looks good! ;-) thanks I think there is a word missing in the first sentence: "The data in this table is *based* on download statistics" Should I add it? Sure, go ahead. Marcus Am 18.06.2017 um 21:44 schrieb Marcus: Am 18.06.2017 um 15:31 schrieb Marcus: Am 12.06.2017 um 19:48 schrieb Marcus: Am 12.06.2017 um 19:00 schrieb Matthias Seidel: I just unified it with the other pages, where you preferred that style... ;-) sure, the graphics on the other page are smaller. Here the table is loong. So, putting the text before the table would be better. But maybe that page can be deleted as it is outdated anyhow? Or better it could be updated. I'll have a look. OK, a first test shows that a day needs ca. 15 min. for processing. I'll process the numbers first for a shorter timeframe, update the webpage and then extend it with more and more days from the past. Anyway, we need to be patient. ;-) it seems my Inet access way a bit slow at this moment. Updating the download numbers goes faster than tested. In the meantime I've updated them from 2012 until today and committed it already. Marcus Am 12.06.2017 um 18:57 schrieb Marcus: Am 12.06.2017 um 14:30 schrieb msei...@apache.org: Author: mseidel Date: Mon Jun 12 12:30:17 2017 New Revision: 1798446 URL: http://svn.apache.org/viewvc?rev=1798446&view=rev Log: Reversed order (text<->table) Modified: openoffice/ooo-site/trunk/content/stats/countries.html what is the purpose behind this change? For me it looks better when the table is introduced with some explaining text. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1798446 - /openoffice/ooo-site/trunk/content/stats/countries.html
Hi Marcus, Looks good! ;-) I think there is a word missing in the first sentence: "The data in this table is *based* on download statistics" Should I add it? Matthias Am 18.06.2017 um 21:44 schrieb Marcus: > Am 18.06.2017 um 15:31 schrieb Marcus: >> Am 12.06.2017 um 19:48 schrieb Marcus: >>> Am 12.06.2017 um 19:00 schrieb Matthias Seidel: I just unified it with the other pages, where you preferred that style... ;-) >>> >>> sure, the graphics on the other page are smaller. Here the table is >>> loong. So, putting the text before the table would be better. >>> But maybe that page can be deleted as it is outdated anyhow? >>> >>> Or better it could be updated. I'll have a look. >> >> OK, a first test shows that a day needs ca. 15 min. for processing. >> >> I'll process the numbers first for a shorter timeframe, update the >> webpage and then extend it with more and more days from the past. >> >> Anyway, we need to be patient. ;-) > > it seems my Inet access way a bit slow at this moment. Updating the > download numbers goes faster than tested. In the meantime I've updated > them from 2012 until today and committed it already. > > Marcus > > > Am 12.06.2017 um 18:57 schrieb Marcus: > Am 12.06.2017 um 14:30 schrieb msei...@apache.org: >> Author: mseidel >> Date: Mon Jun 12 12:30:17 2017 >> New Revision: 1798446 >> >> URL: http://svn.apache.org/viewvc?rev=1798446&view=rev >> Log: >> Reversed order (text<->table) >> >> Modified: >> openoffice/ooo-site/trunk/content/stats/countries.html > > what is the purpose behind this change? > > For me it looks better when the table is introduced with some > explaining text. > > Marcus > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r1798446 - /openoffice/ooo-site/trunk/content/stats/countries.html
Am 18.06.2017 um 15:31 schrieb Marcus: Am 12.06.2017 um 19:48 schrieb Marcus: Am 12.06.2017 um 19:00 schrieb Matthias Seidel: I just unified it with the other pages, where you preferred that style... ;-) sure, the graphics on the other page are smaller. Here the table is loong. So, putting the text before the table would be better. But maybe that page can be deleted as it is outdated anyhow? Or better it could be updated. I'll have a look. OK, a first test shows that a day needs ca. 15 min. for processing. I'll process the numbers first for a shorter timeframe, update the webpage and then extend it with more and more days from the past. Anyway, we need to be patient. ;-) it seems my Inet access way a bit slow at this moment. Updating the download numbers goes faster than tested. In the meantime I've updated them from 2012 until today and committed it already. Marcus Am 12.06.2017 um 18:57 schrieb Marcus: Am 12.06.2017 um 14:30 schrieb msei...@apache.org: Author: mseidel Date: Mon Jun 12 12:30:17 2017 New Revision: 1798446 URL: http://svn.apache.org/viewvc?rev=1798446&view=rev Log: Reversed order (text<->table) Modified: openoffice/ooo-site/trunk/content/stats/countries.html what is the purpose behind this change? For me it looks better when the table is introduced with some explaining text. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release Manager for 4.2.0?
Am 18.06.2017 um 16:47 schrieb Andrea Pescetti: > Matthias Seidel wrote: >> Bouncing up your mail from march... > > Not only from March, but from March 2016! Wow, didn't even notice it... But I must have thought it was important because I kept it in my archive! ;-) > >> Am 27.03.2016 um 22:13 schrieb Andrea Pescetti: >>> 2) Localization. I got shell access to the Pootle server a few days >>> ago. I'm still looking around, and if someone else want to join this >>> is an important part. We need to have a solid process for updating >>> translations (the full route: new strings in code -> Pootle -> back to >>> code -> in localized builds) in place. >> >> This is the part I would be interested to help! >> Pootle synchronisation is essential for 4.2.0 and beyond. > > Good! So the first step would be that you try exporting a language > (likely German in you case) from Pootle to SDF and check how it looks. > > While I assumed Pootle was aligned with 4.1.x (no strings are added > within the 4.1.x series) Ariel did some work in early 2017 and found > out that actually Pootle reflects some other, not perfectly clear, > status of code. > > Anyway, the first action I suggest is: > > 1) Download German PO files from https://translate.apache.org/de/ (you > will need to login; I've just given you permission to download the PO > files in case you didn't have them) Yes, that did work! I will try the next steps... And I just learned what the KeyID (lang="kid") is for, may be helpful! Regards, Matthias > > 2) Convert the PO files to SDF; search "sdf" in > https://wiki.openoffice.org for documentation > > 3) Compare the files you obtain with those at > http://svn.apache.org/viewvc/openoffice/branches/AOO413/extras/l10n/source/de/ > > (note: it's a huge text file, use some reliable editor) > > 4) You can also build the AOO414 branch -or trunk- with the new SDF if > you want to have some fun. > > This is a first check to understand how stuff works and the > translation status. Feel free to open a new dedicated discussion for > follow-up if you need some more information. Note that I only know the > high-level steps but I'm not familiar with details, so some > documentation digging will still be needed. > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: Release Manager for 4.2.0?
Matthias Seidel wrote: Bouncing up your mail from march... Not only from March, but from March 2016! Am 27.03.2016 um 22:13 schrieb Andrea Pescetti: 2) Localization. I got shell access to the Pootle server a few days ago. I'm still looking around, and if someone else want to join this is an important part. We need to have a solid process for updating translations (the full route: new strings in code -> Pootle -> back to code -> in localized builds) in place. This is the part I would be interested to help! Pootle synchronisation is essential for 4.2.0 and beyond. Good! So the first step would be that you try exporting a language (likely German in you case) from Pootle to SDF and check how it looks. While I assumed Pootle was aligned with 4.1.x (no strings are added within the 4.1.x series) Ariel did some work in early 2017 and found out that actually Pootle reflects some other, not perfectly clear, status of code. Anyway, the first action I suggest is: 1) Download German PO files from https://translate.apache.org/de/ (you will need to login; I've just given you permission to download the PO files in case you didn't have them) 2) Convert the PO files to SDF; search "sdf" in https://wiki.openoffice.org for documentation 3) Compare the files you obtain with those at http://svn.apache.org/viewvc/openoffice/branches/AOO413/extras/l10n/source/de/ (note: it's a huge text file, use some reliable editor) 4) You can also build the AOO414 branch -or trunk- with the new SDF if you want to have some fun. This is a first check to understand how stuff works and the translation status. Feel free to open a new dedicated discussion for follow-up if you need some more information. Note that I only know the high-level steps but I'm not familiar with details, so some documentation digging will still be needed. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1798446 - /openoffice/ooo-site/trunk/content/stats/countries.html
Am 12.06.2017 um 19:48 schrieb Marcus: Am 12.06.2017 um 19:00 schrieb Matthias Seidel: I just unified it with the other pages, where you preferred that style... ;-) sure, the graphics on the other page are smaller. Here the table is loong. So, putting the text before the table would be better. But maybe that page can be deleted as it is outdated anyhow? Or better it could be updated. I'll have a look. OK, a first test shows that a day needs ca. 15 min. for processing. I'll process the numbers first for a shorter timeframe, update the webpage and then extend it with more and more days from the past. Anyway, we need to be patient. ;-) Marcus Am 12.06.2017 um 18:57 schrieb Marcus: Am 12.06.2017 um 14:30 schrieb msei...@apache.org: Author: mseidel Date: Mon Jun 12 12:30:17 2017 New Revision: 1798446 URL: http://svn.apache.org/viewvc?rev=1798446&view=rev Log: Reversed order (text<->table) Modified: openoffice/ooo-site/trunk/content/stats/countries.html what is the purpose behind this change? For me it looks better when the table is introduced with some explaining text. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A refactoring proposal
On 6/18/2017 5:51 AM, Carl Marcum wrote: On 06/17/2017 01:52 PM, Patricia Shanahan wrote: Without going into details here, some recently fixed security issues have related to the use of fixed size arrays without bounds checks. In general, that is not a very robust programming practice. It depends on careful checking in the source code to prevent array overflow. I suggest a project to replace raw arrays with Standard Template Library classes as appropriate. All accesses should be through safe functions such as std::array::at. In some cases we could replace a limited size but large array with e.g. a std::vector that can start small and grow only as needed. This matches nicely with my observations of volunteers. We are not getting many people with the skills and experience to dive into a very large body of code and debug it. We are getting students and early career programmers who could work on something like this. It might also be a viable Google Summer of Code project. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org That sounds like a good idea. Do you think the calls may be common enough to find with a search to get a list of files to look in? Array access, including unchecked index access to STL array-like structures, can be identified by the use of '[.*]' bracketed expressions. STL access with bounds checking uses function call syntax instead of overloaded array access syntax. That is going to get a lot of hits so some prioritization is needed. I suggest working first on files that have been culprits in array-related security problems we have fixed. We know those use fixed size arrays and were written or edited by people who did not always check the bounds. I would then work out to other files in the same modules, and then anything involved in building internal structures from input files. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A refactoring proposal
On 06/17/2017 01:52 PM, Patricia Shanahan wrote: Without going into details here, some recently fixed security issues have related to the use of fixed size arrays without bounds checks. In general, that is not a very robust programming practice. It depends on careful checking in the source code to prevent array overflow. I suggest a project to replace raw arrays with Standard Template Library classes as appropriate. All accesses should be through safe functions such as std::array::at. In some cases we could replace a limited size but large array with e.g. a std::vector that can start small and grow only as needed. This matches nicely with my observations of volunteers. We are not getting many people with the skills and experience to dive into a very large body of code and debug it. We are getting students and early career programmers who could work on something like this. It might also be a viable Google Summer of Code project. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org That sounds like a good idea. Do you think the calls may be common enough to find with a search to get a list of files to look in? Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Mac Buildsystem at Apache
Hi all First of all, sorry for the crossposting. Since long time we have no mac buildsystem anymore. I know, that OpenOffice and Weex has an interest in having one. My Question is, are there other Communities who has interest in a Mac build system? Regards, Raphael -- My introduction https://youtu.be/Ln4vly5sxYU - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A refactoring proposal
Awesome! Thanks for the Clarification. Am 18.06.2017 um 10:19 schrieb Patricia Shanahan: In that case, we are talking about the same class. std::array is defined in header . See http://en.cppreference.com/w/cpp/container/array On 6/17/2017 9:58 PM, Peter Kovacs wrote: The book says it is in . The book is about C++11, providing a quick reference on C++. I cam across when I saw this youtube video: https://www.youtube.com/watch?v=86xWVb4XIyE And since I learned C++ in the 90ies, but never used it I thought it is a good invest. Am 18.06.2017 um 01:06 schrieb Patricia Shanahan: I don't know. I have not read that particular book. If the code snippet includes "using namespace std" then "array" means "std::array". I have a time gap in my C++ experience - I used it professionally in the 1980's, and now I'm coming back to it for AOO. I don't think the Standard Template Library came into wide use until the 1990's. At this point I think we should use the STL for the next layer of data structures above raw arrays, including arrays with bounds checking. I have not heard of a competing library and I do not like to roll my own if I can possibly avoid it. On 6/17/2017 3:50 PM, Peter Kovacs wrote: +1 I have a question thought. In Tour of C++ (Bjarn Stroustrup) its recommended to use array instead of buildin arrays and only to use Arrays if we know the amount of elements (constexpr). buildin arrays example: Circle myarray[10] array example: array myarray so std::array::at is equal to the arrayexample? sorry if the question is dumb. I am not sure if what I know is the same what you talk about. I am in the "early carrier" category. lol. All the best Peter Am 17.06.2017 um 19:52 schrieb Patricia Shanahan: Without going into details here, some recently fixed security issues have related to the use of fixed size arrays without bounds checks. In general, that is not a very robust programming practice. It depends on careful checking in the source code to prevent array overflow. I suggest a project to replace raw arrays with Standard Template Library classes as appropriate. All accesses should be through safe functions such as std::array::at. In some cases we could replace a limited size but large array with e.g. a std::vector that can start small and grow only as needed. This matches nicely with my observations of volunteers. We are not getting many people with the skills and experience to dive into a very large body of code and debug it. We are getting students and early career programmers who could work on something like this. It might also be a viable Google Summer of Code project. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A refactoring proposal
In that case, we are talking about the same class. std::array is defined in header . See http://en.cppreference.com/w/cpp/container/array On 6/17/2017 9:58 PM, Peter Kovacs wrote: The book says it is in . The book is about C++11, providing a quick reference on C++. I cam across when I saw this youtube video: https://www.youtube.com/watch?v=86xWVb4XIyE And since I learned C++ in the 90ies, but never used it I thought it is a good invest. Am 18.06.2017 um 01:06 schrieb Patricia Shanahan: I don't know. I have not read that particular book. If the code snippet includes "using namespace std" then "array" means "std::array". I have a time gap in my C++ experience - I used it professionally in the 1980's, and now I'm coming back to it for AOO. I don't think the Standard Template Library came into wide use until the 1990's. At this point I think we should use the STL for the next layer of data structures above raw arrays, including arrays with bounds checking. I have not heard of a competing library and I do not like to roll my own if I can possibly avoid it. On 6/17/2017 3:50 PM, Peter Kovacs wrote: +1 I have a question thought. In Tour of C++ (Bjarn Stroustrup) its recommended to use array instead of buildin arrays and only to use Arrays if we know the amount of elements (constexpr). buildin arrays example: Circle myarray[10] array example: array myarray so std::array::at is equal to the arrayexample? sorry if the question is dumb. I am not sure if what I know is the same what you talk about. I am in the "early carrier" category. lol. All the best Peter Am 17.06.2017 um 19:52 schrieb Patricia Shanahan: Without going into details here, some recently fixed security issues have related to the use of fixed size arrays without bounds checks. In general, that is not a very robust programming practice. It depends on careful checking in the source code to prevent array overflow. I suggest a project to replace raw arrays with Standard Template Library classes as appropriate. All accesses should be through safe functions such as std::array::at. In some cases we could replace a limited size but large array with e.g. a std::vector that can start small and grow only as needed. This matches nicely with my observations of volunteers. We are not getting many people with the skills and experience to dive into a very large body of code and debug it. We are getting students and early career programmers who could work on something like this. It might also be a viable Google Summer of Code project. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Release 4.1.4 - Can we add a script to the release to help user support in working around an issue?
Hello all, John (in CC) suggested to add the Script of Hanya (also in CC) to the Open Office Release as a first improvement. On the discussion in this thread @dev declared only stuff that is in trunc can be part of an release. Since Hanya has comitter rights granted it was suggested he should be the one commiting his script. @Hanya: Do you believe that your script is stable enough to be added or is there work to do to get it commited? Can you commit your work, so we can add it for release? @Jim (Release Manager): What is the timeframe for you to get this script into 4.1.4. You only stated that it has to be in svn, not until when and what the timeframe is. My understanding is the current Version is close to a RC. Hope this drives this topic a little further. All the best Peter Am 13.06.2017 um 23:42 schrieb Marcus: Am 13.06.2017 um 23:24 schrieb Andrea Pescetti: Marcus wrote: assumed it's OK on trunk and 4.1.4, how do we integrate this into the installation process? I see it as an on-demand tool. So nothing would be added to the installation process. A new menu item would be available for it (the current solution uses the macro runner menu). It seems, though, that the current implementation relies on being executed from the user profile and this will probably not work for our 4.1.4 use case: I haven't checked, but I believe that the profile is left unchanged by maintenance (4.1.x) updates. This should be investigated though: there is likely a way to bundle it as a "shared" script that would then be available even without touching the profile. an alternative would be to create a new Help menu entry (e.g., "Help - Spell check fix"). This opens a webpage which provides a download link to the file and a text with explainations/instructions: Why is it needed, how to unpack/install/execute it, what is it going to do, etc. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
