Re: Policy to deal with old web content - Archiving pages? (was: Old build Documentation)

[Keith N. McKenna]

On Sun, 20 Dec 2020 11:03:17 -0800, Dave Fisher wrote:

> Sent from my iPhone
> 
>> On Dec 20, 2020, at 9:58 AM, Keith N. McKenna
>>  wrote:
>> 
>> Greetings Peter, comments are inline.
>>> On Sun, 20 Dec 2020 00:32:15 +0100, Peter Kovacs wrote:
>>> 
>>> I change subject since I venture to more generic topic.
>>> 
>>> 
 On 19.12.20 22:15, Keith N. McKenna wrote:
  The Policy for the mwiki is and has been since the days of
  OpenOffice.org
 (OOo) to NOT delete pages from the wiki but mark them as outdated and
 be sure there is a link to any replacement document.
>>> 
>> All I am attempting to do is to explain what longstanding policy has
>> been for the wiki. If the community wants to change that fine I do
>> believe it needs a [Discusstion] thread of it's own rather than just a
>> change of topic in a related thread.
>> 
 
>>> I suggest we create a archive site (suggestion:
>>> archive.openoffice.org) site, and move pages there, that have only
>>> historic value.
>> 
>> Again should be in a [Discussion} thread devoted to a policy change.
> 
> I don’t think the effort to move obsolete Wiki pages to static html is
> worth it. It’s better to label and point. Perhaps it can be done with a
> macro.
> 

Dave I agree with you. There is a way to redirect outdated pages to the 
newer documents. I will look into the mediawiki documents for the way to 
do it.

regards
Keith

> For obsolete html in www.OpenOffice.org we could mark and move to
> Www.OpenOffice.org/archive/ rather than maintain yet another repository
> and website.
> 
> I think though we can add metadata and a template to quickly mark pages
> as obsolete. Redirection or inserted link using additional metadata is
> possible. This is a few hours work to setup. I would volunteer to enable
> it.
> 
> Regards,
> Dave
> 
> 
>> 
>>> There is no rush, but cleaning up would help us to refresh our minds.
>>> But to forget stuff is important or we run all the time with loads of
>>> old baggage around. And we have difficulties to find the right
>>> information.
>> 
>> That is where we definitely agree. The mwiki has suffered from neglect
>> for far to long and needs an overhaul. Whether that takes place here or
>> in a thread of it's own is up to the community.
>> 
>> Regards Keith
>> 
>> 
>>> just my 2 cents.
>>> 
>>> [1] https://en.wikipedia.org/wiki/Right_to_be_forgotten
>> 
>> 
>> 
>> -
>> 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: Policy to deal with old web content - Archiving pages? (was: Old build Documentation)

[Dave Fisher]

Sent from my iPhone

> On Dec 20, 2020, at 9:58 AM, Keith N. McKenna  
> wrote:
> 
> Greetings Peter, comments are inline.
>> On Sun, 20 Dec 2020 00:32:15 +0100, Peter Kovacs wrote:
>> 
>> I change subject since I venture to more generic topic.
>> 
>> 
>>> On 19.12.20 22:15, Keith N. McKenna wrote:
>>>  The Policy for the mwiki is and has been since the days of
>>>  OpenOffice.org
>>> (OOo) to NOT delete pages from the wiki but mark them as outdated and
>>> be sure there is a link to any replacement document.
>> 
> All I am attempting to do is to explain what longstanding policy has been 
> for the wiki. If the community wants to change that fine I do believe it 
> needs a [Discusstion] thread of it's own rather than just a change of 
> topic in a related thread.
> 
>> For me this rule does not add up. Marking pages out dated is not the
>> solution. We are not a museum.
> 
>> These pages are so dire old, no body knows if that what the pages are
>> saying are any accurate, or what.
> 
> That is why they were to be marked as outdated ank links to the newer 
> documents provided. There is also a way to create internal redirects to 
> the newer pages such that if the old document is clicked it automatically 
> opens the newer document.
> 
>> We should create an Archive section, and then create there a static html
>> site that preserves the state in order to honor history.
> 
> That is another way to handle it that deserves to be in a [Discussion] 
> thread for a policy change.
> 
>> We can add some information maybe like contributors and stuff. If this
>> sentiment is important. But we should move pages that are confusing and
>> irrelevant to our work somewhere they are not in the way.
>> 
>> I suggest we create a archive site (suggestion: archive.openoffice.org)
>> site, and move pages there, that have only historic value.
> 
> Again should be in a [Discussion} thread devoted to a policy change.

I don’t think the effort to move obsolete Wiki pages to static html is worth 
it. It’s better to label and point. Perhaps it can be done with a macro.

For obsolete html in www.OpenOffice.org we could mark and move to 
Www.OpenOffice.org/archive/ rather than maintain yet another repository and 
website.

I think though we can add metadata and a template to quickly mark pages as 
obsolete. Redirection or inserted link using additional metadata is possible. 
This is a few hours work to setup. I would volunteer to enable it.

Regards,
Dave

> 
>> 
>> There is no rush, but cleaning up would help us to refresh our minds.
>> But to forget stuff is important or we run all the time with loads of
>> old baggage around. And we have difficulties to find the right
>> information.
> 
> That is where we definitely agree. The mwiki has suffered from neglect for 
> far to long and needs an overhaul. Whether that takes place here or in a 
> thread of it's own is up to the community.
> 
> Regards
> Keith
> 
>> 
>> just my 2 cents.
>> 
>> [1] https://en.wikipedia.org/wiki/Right_to_be_forgotten
> 
> 
> 
> -
> 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: Policy to deal with old web content - Archiving pages? (was: Old build Documentation)

[Keith N. McKenna]

Greetings Peter, comments are inline.
On Sun, 20 Dec 2020 00:32:15 +0100, Peter Kovacs wrote:

> I change subject since I venture to more generic topic.
> 
> 
> On 19.12.20 22:15, Keith N. McKenna wrote:
>>   The Policy for the mwiki is and has been since the days of
>>   OpenOffice.org
>> (OOo) to NOT delete pages from the wiki but mark them as outdated and
>> be sure there is a link to any replacement document.
> 
All I am attempting to do is to explain what longstanding policy has been 
for the wiki. If the community wants to change that fine I do believe it 
needs a [Discusstion] thread of it's own rather than just a change of 
topic in a related thread.

> For me this rule does not add up. Marking pages out dated is not the
> solution. We are not a museum.

> These pages are so dire old, no body knows if that what the pages are
> saying are any accurate, or what.

That is why they were to be marked as outdated ank links to the newer 
documents provided. There is also a way to create internal redirects to 
the newer pages such that if the old document is clicked it automatically 
opens the newer document.

> We should create an Archive section, and then create there a static html
> site that preserves the state in order to honor history.

That is another way to handle it that deserves to be in a [Discussion] 
thread for a policy change.

> We can add some information maybe like contributors and stuff. If this
> sentiment is important. But we should move pages that are confusing and
> irrelevant to our work somewhere they are not in the way.
> 
> I suggest we create a archive site (suggestion: archive.openoffice.org)
> site, and move pages there, that have only historic value.

Again should be in a [Discussion} thread devoted to a policy change.

> 
> There is no rush, but cleaning up would help us to refresh our minds.
> But to forget stuff is important or we run all the time with loads of
> old baggage around. And we have difficulties to find the right
> information.

That is where we definitely agree. The mwiki has suffered from neglect for 
far to long and needs an overhaul. Whether that takes place here or in a 
thread of it's own is up to the community.

Regards
Keith

> 
> just my 2 cents.
> 
> [1] https://en.wikipedia.org/wiki/Right_to_be_forgotten



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Does AOO 4.1.8 run under macOS Big Sur?

[Jim Jagielski]

OK, thx. it seems that the switch from COMID s5abi to gcc3 is a LOT more 
fragile than it should be.

> On Dec 19, 2020, at 7:59 AM, Rony G. Flatscher (Apache)  
> wrote:
> 
> On 18.12.2020 16:25, Jim Jagielski wrote:
>> Can you try with:
>> 
>>http://home.apache.org/~jim/AOO-builds/
> 
> Same error:
> 
>wu114216:~ rony$ "/Applications/OpenOffice.app/Contents/program/unopkg" 
> add -f --shared 
> /Library/Frameworks/BSF4ooRexx.framework/Libraries/ScriptProviderForooRexx.oxt
>  dyld: Library not loaded: @___URELIB/libuno_cppu.dylib
>Referenced from: /Applications/OpenOffice.app/Contents/MacOS/uno.bin
>Reason: image not found
> 
> ---rony
> 
> 
> On Dec 17, 2020, at 11:34 AM, Rony G. Flatscher (Apache)  
> wrote:
> 
> ... cut ...
> 
 On 14.12.2020 13:33, Jim Jagielski wrote:
>> On Dec 12, 2020, at 5:21 AM, Matthias Seidel 
>>  wrote:
>> 
>> Hi Jim,
>> 
>> I have been able to open docx with your version (en-US) on Big Sur.
>> However, I am not sure if this bug ever applied to 4.2.x.
>> 
>> The Extension Manager is still broken. But similar behavior is to be
>> seen in 4.2.x on Windows, so the UNO problem is not mac specific.
>> 
> Yes... I am also looking into issues w/ 4.2.0-dev and check for updates 
> (main level)
 Ah, o.k. that might explain this. Got a minute so tried to test 4.2 beta 
 w.r.t. issue 127966  [1]
 and was not able to get ooRexx functional. When trying to register the oxt 
 package manually with
 unopkg, I got this error message:
 
  wu114216:~ rony$ "/Applications/OpenOffice.app/Contents/program/unopkg" 
 add -f --shared 
 /Library/Frameworks/BSF4ooRexx.framework/Libraries/ScriptProviderForooRexx.oxt
  dyld: Library not loaded: @___URELIB/libuno_cppu.dylib
Referenced from: /Applications/OpenOffice.app/Contents/MacOS/uno.bin
Reason: image not found
 
 ---rony
 
 [1] MacOS: Current directory wrongly set to root directory "/" for scripts:
 
 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Delete the ascii filter

[Bidouille]

This mail list is not the right place to post this kind of problem.
This dialog means probably that you try to open a corrupted document.
You can go on the community forum to get some help:
https://forum.openoffice.org/en/forum/search.php?st=0=t=d=topics=+%2Bascii++%2Bfilter++%2Bdialog


- Mail original -
> De: "J R WATSON" 
> À: dev@openoffice.apache.org
> Envoyé: Samedi 19 Décembre 2020 21:34:33
> Objet: Delete the ascii filter
> 
> How can I delete the ascii filter on my Mac . Can’t get some files
> opened because of that filter. Pleas replay in Laman terms because
> we are not the most computer literate people
> 
> Sent from my iPad
> 
> -
> 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: Where I think I'll be of the most use.

[Peter Kovacs]

On 20.12.20 01:16, Steve Lubbs wrote:
After spending a few hours poking around I have some ideas on where I 
can make the biggest impact given my background.


Multi-threading/Concurrency: This is one of my bailiwicks. Correct me 
if I'm wrong but it appears that concurrency support was removed when 
Mac OSX dropped support for standard  concurrency APIs. I saw that all 
the concurrency APIs were gutted in semaphore.h and mutex.h.  
Unfortunately replacing them with the OSX GCD (Grand Central 
Dispatcher, how cute) and dispatch queues won't fill the porting bill. 
I would like to look into ways to implement semaphores, mutexes,etc. 
so we can fill this gap. Might still be able to use dispatch queues 
for threading.


There is a theory that we have some concurrency issue when system is 
shutting down. maybe you can look into that too?





I have a pretty good background in threading and concurrency. For 
example, way back I needed to port some threaded unix code to an OS 
that had no support for threads or concurrency so implemented my own 
light-weight threads and concurrency primitives. For atomic operations 
I used a assembly-level compare and increment command. I was so proud 
of it I started writing an article for Dr. Dobbs, a big programming 
mag at the time. While I was so engaged, someone else beat me to the 
punch. Rats.


Architecture Documentation: It appears to be in need of major 
updating. I haven't seen anything updated in the last 10 years. I 
would like to update it as much as I can, at least WRT the modules I 
touch.


What do you think?

sounds good.


Sorry for bloviating.

No Problem. Better biovaliting then not talking. ;)


BTW, this is fun.


You are welcome!

Peter


--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org