Oh my, <http://www.openoffice.org/udk/>
Damjan and Carl will know much more about this. I am a little curious what the Win32 implementations of some of those are. A place I have been avoiding. This is useful too, <https://wiki.openoffice.org/wiki/User:Kr> See the section 10.2 on threading. If there are other broken links in there, there is better information for tracking them down using the bibliographic information Kay Ramme has included. It appears we have found the correct Ousterhout paper. It looks like the safe thing to do is fix the code rather than remove it. We need to find out more about aquireProfile and put this one to rest. Thanks for finding this, Patricia. - Dennis, still wondering when and where those profiles get written by the shipped code. > -----Original Message----- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Thursday, March 3, 2016 17:43 > To: dev@openoffice.apache.org > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > curve) > > On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote: > >> -----Original Message----- > >> From: Patricia Shanahan [mailto:p...@acm.org] > >> Sent: Thursday, March 3, 2016 14:38 > >> To: dev@openoffice.apache.org > >> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning > >> curve) > >> > >> I am seriously considering starting a project to eliminate profile.c > >> etc. and seeing what, if anything, breaks. > >> > >> Before I do that, I have a question about whether it could be > accessed > >> through any of OpenOffice's extension or plugin facilities? Even if > it > >> can, 14 years seems quite long enough for people to migrate off a > >> deprecated interface. > > [orcmid] > > > > I think the extensions and plugins depend on UNO objects. So long as > that is the case, the profile code should be unreachable. > > I have found a file main/sal/util/sal.map that begins with: > > UDK_3_0_0 { > global: > GetVersionInfo; > osl_acceptConnectionOnSocket; > osl_acceptPipe; > osl_acquireSocket; > osl_acquirePipe; > osl_acquireMutex; > osl_acquireSemaphore; > osl_addSignalHandler; > osl_addToSocketSet; > osl_assertFailedLine; > osl_bindAddrToSocket; > osl_breakDebug; > osl_checkCondition; > osl_clearSocketSet; > osl_closeDirectory; > osl_closePipe; > osl_closeProfile; > ... > > and goes on to mention several other profile.c /osl_.*Profile.*/ > function names in the same list. > > Unfortunately, I am seeing some indications that "UDK" relates to UNO. > > At the worst, the deprecation just means that other modules are supposed > to access the profile only through UNO, not by including the header file > and calling the functions directly. > > Patricia > > --------------------------------------------------------------------- > 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
