Community
Participate
Working Groups
Hi, Do you have plans to port Hyades to Mac OS X? I could not find any RFE in the bug database. I am looking for a profiling plugin for Eclipse on Mac OS X to find hotspots in my Java program, but I could not find any. As Hyades has been ported to many OS including AIX/PPC it should be possible to create a Mac OS X or BSD version.
Stefan, Thanks for your request. We have had other also mention they are interetsed in this. There is a contributer working on the port, but his time is limited. Unfortunately, I cannot provide a date when this will be completed. For the most part, the code should just build and work on Mac OS X. The biggest issue would be the lack of support for high speed timestamps for the G4 and G5 processors. This would be a minor piece of specialized code for this platform that would pay great dividends.
Being a Mac/BSD person, I'd love to see this as well.
Me too.
How would one try to help? I found no quick way to create the native libraries. The code is not in the SDK package for 4.1.0. And the other people: please actually *vote* for this. Putting this in text here doesn not count. Press the "Vote for this bug" link on the bug report page.
Any news on this?
Another vote YES!
Time::HiRes (a Perl module) provides a high resolution timer which appears to work on MacOS X. Superficially it provides sub micro-second timing, anyway. How good timing do we need? I could have a look at the C code for that perl module and see how hard it would be to code something similar for JNI... A little more investigation suggests that MacOS X has the getitimer/setitimer/gettimeofday calls as well as nanosleep, which seems promising. I would be interested in helping getting this working, but I'd need some 'hand-holding' from someone more familiar with the eclipse codebase.
Jules, Thank you for offering to help with this port. How can we support you? -Sri
Changing target to future. If someone is able to accomplish the port in time for the start of the 4.2i2 test pass (3 April 2006) we will revisit.
In case it helps: I've been investigating other java profilers for OS X on PowerPC, and there are some open source ones with native libraries. Perhaps their source could help here? One of them is the NetBeans Profiler, now experimental on OS X but WorksForMe. (but I'd prefer Eclipse :P). Another one is the Extensible Java Profiler ( http://ejp.sourceforge.net ). And another one is the Java Memory Profiler ( http://www.khelekore.org/jmp/macbuild.html ). Note that this is NOT ONLY a memory profiler.
(In reply to comment #10) TPTP tools aleady run on a wide range of Linux and Unix flavors. I expect that Mac OS X port would be trivial. But there is an ongoing cost to building and testing. TPTP will welcome community contributed builds of Mac OS X. If anyone is interested, contact us.
*** Bug 129959 has been marked as a duplicate of this bug. ***
I'm willing to spend some days in trying to do a port. I have a G5 iiMac, so somebody else may need to try on Intel. How do I get access to the source code?
I would really like to get this working, it seems sad that this bug has been out for nearly two years and still no working OS X version. I've got some experience compiling other open source libraries on OS X, but this build process for this is obtuse. Most notably, there is no configure script common with such builds. I've tried making customized make files to no avail. If someone can point me towards, or provide me with, documentation on how the existing builds are made, I'll take another stab at it.
Copying Randy Smith who can provide information on how to build the agent controller on Linux.
Soliciting help with porting and contributing builds of agent controller.
(In reply to comment #16) > Soliciting help with porting and contributing builds of agent controller. I volunteered to help with Mac ports, but I need some help getting started...
As Sri said in Comment #15, I'm probably your contact point. The source code is on dev.eclipse.org, accessible via anonymous CVS, with a base at /cvsroot/tptp. The project is under the platform/org.eclipse.tptp.platform.agentcontroller project. Right now the RAC is under src-native [SN for now] while the new tech AC is under src-native-new [SNN for now]. Under [SNN]/bin you will find a readme.txt with some fairly decent instructions on re-building the code and building the samples to test that build. I also have a build document in the works but (1) it's not finished, (2) it's more about the "build environment" that Hubert@IBM and I@Intel have to do the "distributed building", and (3) you'll probably want to go through me anyway for check-ins (unless you're a committer?). Being Unix/Linux-based, you'll probably have fairly smooth sailing. You'll want to find a compile-time #define that can set off you system-specific items (hopefully something the compiler defines automatically for you). Most of our system-specific stuff is very small and well contained in files easily recognized as system-specific. The tough part is the "moving target" of [SN]<=>[SNN]... for windows, I go over into [SN] and build a "RAC SDK" that has the RAC libraries for shared memory, sockets, and a couple of others (it should mimic tptpdc.linux_<platform>.sdk like what comes under the SDK links on the download page). That then is placed in an area addressed in [SNN] as $RAC_SDK_HOME ... it has include and lib subdirectories with the .h and .so files needed (or is it .lib... I'll have to check). Anyway, I'm about to make that "fix" for the Linux builds as well... for now the Linux-IA32 platform just depends on tptpdc.linux_ia32.sdk, and the Linux-{IPF|EM64T} builds build their own libs under [SNN] where we have (outdated) copies of src/transport/{RACommon|RASharedMemory|RASocket} (I think it is). For now, you'll want to build just like those two platforms. So, look at makefile (covers all Linux platforms) which calls [SNN]/build/build_tptp_ac.script64 (and [SNN]/build/build_tptp_samples.script... but that's later when you're working well!). Determine if there is a "uname" way of seeing you're Mac_OS and set the uniqueness of your build accordingly. Maybe see the diffs between the [64] version of the build script and the one without the 64 on the end. With any luck it will be little to do before make in [SNN] "just works" for you! Hmmm, I just realized you'll quickly find that besides $RAC_SDK_HOME, you'll also need a $XERCESC_HOME and a $CBE_SDK_HOME ... the first might be a piece of cake in that *someone* has to have already ported XercesC to Mac_OS ... but XercesC can be a bear to build even if it's for a supported platform! The CBE stuff will come from platform/org.eclipse.hyades.logging.core, I think it is... it's structured much as the actual AC build is. Let me know any way I can help! I'll be more than happy to answer questions. If it requires actually executing on a Mac_OS, though, you might have to send the question *with* your system! :-)
(In reply to comment #18) > Let me know any way I can help! I'll be more than happy to answer questions. If > it requires actually executing on a Mac_OS, though, you might have to send the > question *with* your system! :-) I'll see if I can give this a shot soon. I'll keep you posted.
I'm just becoming aware of this issue, as I'm attempting to get TPTP profiling up and running on my intel Mac. I notice the last comment was in June - is anyone making any progress on this issue? Any hope of OS X support in the near term? TIA, - Chris Beams
(In reply to comment #19) > I'll see if I can give this a shot soon. I'll keep you posted. (In reply to comment #20) > I'm just becoming aware of this issue, as I'm attempting to get TPTP profiling > up and running on my intel Mac. I notice the last comment was in June - is > anyone making any progress on this issue? Any hope of OS X support in the near > term? Hmm, I guess the answer is no. I said I'd try and get to it soon, but haven't. :) I guess it's no longer a high priority for me.
I need agent controller as well, so I am interested in helping.
(In reply to comment #18) Hi Randy, > The tough part is the "moving target" of [SN]<=>[SNN]... for windows, I go over > into [SN] and build a "RAC SDK" that has the RAC libraries for shared memory, > sockets, and a couple of others (it should mimic tptpdc.linux_<platform>.sdk > like what comes under the SDK links on the download page). That then is placed > in an area addressed in [SNN] as $RAC_SDK_HOME ... it has include and lib > subdirectories with the .h and .so files needed (or is it .lib... I'll have to > check). Anyway, I'm about to make that "fix" for the Linux builds as well... Why would the "new tech AC" need the RAC .so libs? I understand you need the .h for compatibility? I don't want to port RAC if it's unnecessary.
Hi, My company, Zenika, is happy to contribute a patch to port CBE on Mac OS X. The patch is at [1], and will be attached here also. We have provided a build should you want to test it, you can download it at [2]. Hopefully, patches for the AC and the RAC will be completed in the near future. Then we will probably get to check for Darwin/x86 as well. [1] http://www.zenika.com/eclipse/cbe-darwin-200612101300.diff [2] http://www.zenika.com/eclipse/cbe.darwin_ppc.sdk-TPTP-200612101300.zip
Created attachment 55369 [details] CommonBaseEvent patch for Darwin (PPC, untested on x86)
I've made a patch to the AC sources to get it to (seemingly) work on OS X. I'm using Mac OS X 10.4 with Apple's GCC 4.0.1. Of course, this patch is EPL licensed. It now builds and runs. There are still 2 specific questions to answer: 1. I think the README omits some precious information on "probekits". I have no idea where these come from; as a result make finally fails, when trying to copy some non-existent files to the destroot. 2. I don't understand why the ossLatch* functions were inlined? I didn't remove it, but I used a linker hack to get Apple's GCC to link RAServer. The tentative patch will be posted here, also duplicated at [1]. Best wishes, -- Pierre Queinnec http://www.zenika.com [1] http://www.zenika.com/eclipse/ac-darwin-200612262240.diff
Created attachment 56192 [details] AgentController patch for Darwin (PPC, untested on x86)
Transferring general agent controller enhancement requests to new project lead (Joanna) for consideration in future releases.
Could somebody please comment on the status of this? It's a real pitty not having access to such an important tool on the Mac. i.e., What is left to be done in order for this to be available via the update manager? Can I also suggest that in the interum that both the update manager and the installation pages be more clear about not bothering to download all the other TPTP components when/if the agent controller is not available for your platform (or via the network). It's really quite annoying downloading all of it via the update manager (without warning that it won't work in the end).
Sorry for our delayed response and thank you for the patch. Supporting Mac OS is definitely something the TPTP development community would like to do. We will assign some resource to run our test suite against the patch and post the results to this defect.
Hi Is there any ETA on "We will assign some resource to run our test suite against the patch and post the results to this defect."? If it's week or so I can wait, but otherwise I have to set up a linux machine/VM for profiling... Thanks
Unfortunately, we won't be able to test this until we finish our 4.4 testing. That won't be for a few weeks yet.
I would like to echo the comments from #29 (see below). I just spent some hours getting all the TPTP components only to discover that this wouldn't work. If I knew where, I would raise a bug requesting that the downloading manager be a bit smarter about what it will download. Can anyone point me to the right place? I have voted for this - keep up the good work. John "Can I also suggest that in the interum that both the update manager and the installation pages be more clear about not bothering to download all the other TPTP components when/if the agent controller is not available for your platform (or via the network). It's really quite annoying downloading all of it via the update manager (without warning that it won't work in the end)."
(In reply to comment #32) > Unfortunately, we won't be able to test this until we finish our 4.4 testing. > That won't be for a few weeks yet. > It's been 2 months since this post suggesting testing would start in "a few weeks." Also, TPTP 4.4 was released a week ago. Should we hope to see test results for this patch soon? Thanks!
Sorry for the delay, we needed to finish in plan 4.4 line items before we could turn our attention to this. Jonathan, please work with Alan to test this function.
Is any assistance required with getting this going on an intel Mac? I only see mention of PPC so far.
(In reply to comment #36) > Is any assistance required with getting this going on an intel Mac? I only see > mention of PPC so far. The project has been busy with some long running bugs and shutting down the 4.4.0 stream. I am raising this specific question to the pmc. It would seem if we can get an x86 machine with the right prereqs installed we should be able to at least provide tech preview drivers for that configuration relatively easily.
Adding myself to the CC list - this coulda saved me hours this weekend...
As we set about preparing to test the port, we noticed that the code patches code in the src-native directory of the agent controller, rather than the src-native-new directory of the agent controller. Would it be a lot of work to port the new AC to Mac OS X? We would obviously need to provide and support the same code base across all supported platforms.
Voted for this bug. I'm developing RCPs cross platform, and it seems I can't profile at all on OSX. Great work in pushing this forwards, folks.
Voted and I hereby join the chorus. I spent an entire day trying to get this up and running, came by this bug at the end of it. I'm sad by the low priority of the bug, being reported June 2004 and still not fixed despite so many people expressing their need for it. Thanks to everyone engaged and working on this bug, and keep up the good work, Eclipse & TPTP teams. :-) Cheers Nik
Spent the whole day trying a get a decent profiler running. No success so far. Got quite close with this one, and then mac is not supported. What a disappointment. Did anyone try the patch attached to an earlier comment. (With success, I mean ;-) Would I just drop this in my install and have a chance that it runs ? Thanks, Tom.
(In reply to comment #37) > (In reply to comment #36) > > Is any assistance required with getting this going on an intel Mac? I only see > > mention of PPC so far. > > The project has been busy with some long running bugs and shutting down the > 4.4.0 stream. I am raising this specific question to the pmc. It would seem if > we can get an x86 machine with the right prereqs installed we should be able to > at least provide tech preview drivers for that configuration relatively easily. > This enhancement was discussed at the last PMC call (October 2, 2007). It was decided that although this enhancement is important to our users, it cannot be contained in the TPTP 4.5 plan due to insufficient resources. As indicated by the 'helpwanted', we are asking the TPTP community for assistance with this enhancement, including: -porting -defects -testing
I have access to both PPC and Intel Mac running 10.4 and am prepared to help with testing.
(In reply to comment #44) > I have access to both PPC and Intel Mac running 10.4 and am prepared to help > with testing. > Thanks for offering John. Would you be willing to help get the build working? If someone could help Joel create a build, then we could publish tech preview drivers that the community could use and test. There is much desire to do this in the project, just not the horsepower
*** Bug 177070 has been marked as a duplicate of this bug. ***
If TPTP profiling support is not going to be added for OS X, would you consider at least adding a platform check and an appropriate error message? If, after 3+ years, it hasn't been done, can we assume it's not going to be done at all and at least mitigate the damage. I, like many other commenters, have just blown a few hours trying to debug why TPTP doesn't work, and would have spent some more if I hadn't seen a bunch of platform-specific bundles go by when downloading and gone looking for a thread like this. The current error message about not being able to connect to an agent leads everyone along a merry chase without a clue to the fundamental problem. Matthew.
(In reply to comment #47) Thanks Matthew for your comments. > If TPTP profiling support is not going to be added for OS X, would you consider > at least adding a platform check and an appropriate error message? Yes, we can consider adding an informational dialog for unsupported OSes. Please open a defect (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=TPTP%20Agent%20Controller) under the Platform.Communication component for this request. > If, after 3+ > years, it hasn't been done, can we assume it's not going to be done at all and > at least mitigate the damage. We are still interested in supporting OSX but our project does not have sufficient resources to do the port and support (e.g. defects/testing). As indicated by the 'helpwanted' keyword, we are asking the TPTP community for assistance with this enhancement. Would you or your company be interested in contributing? > I, like many other commenters, have just blown a few hours trying to debug why > TPTP doesn't work, and would have spent some more if I hadn't seen a bunch of > platform-specific bundles go by when downloading and gone looking for a thread > like this. The current error message about not being able to connect to an > agent leads everyone along a merry chase without a clue to the fundamental > problem. On every TPTP download page, there is a link to the JRE and OS support statement: http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.4/support.html Users should always read this statement (and others, including the Installation Guide and Release Notes) before downloading and installing TPTP for the first time and/or a new TPTP release.
Thanks for the response Paul. I understand not wanting ship something you can't realistically support. (In reply to comment #48) > (In reply to comment #47) > > If TPTP profiling support is not going to be added for OS X, would you consider > > at least adding a platform check and an appropriate error message? > > Yes, we can consider adding an informational dialog for unsupported OSes. > Please open a defect > (https://bugs.eclipse.org/bugs/enter_bug.cgi?product=TPTP%20Agent%20Controller) > under the Platform.Communication component for this request. Done (#208831). > > If, after 3+ > > years, it hasn't been done, can we assume it's not going to be done at all and > > at least mitigate the damage. > > We are still interested in supporting OSX but our project does not have > sufficient resources to do the port and support (e.g. defects/testing). As > indicated by the 'helpwanted' keyword, we are asking the TPTP community for > assistance with this enhancement. Would you or your company be interested in > contributing? I'm just now evaluating TPTP on Windows in a VM. If it looks like something we'd like to use on a regular basis, I'd certainly be looking at doing some work on this, especially since it appears an earlier contributor has made a good start already. > On every TPTP download page, there is a link to the JRE and OS support > statement: > > http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.4/support.html That page is blank for me, just a title followed by no content. I got TPTP via the update site, and had assumed that the Eclipse plug in system would tell me if the plug ins had any unsupported requirements. Matthew.
(In reply to comment #49) > > On every TPTP download page, there is a link to the JRE and OS support > > statement: > > > > http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.4/support.html > > That page is blank for me, just a title followed by no content. I got TPTP via > the update site, and had assumed that the Eclipse plug in system would tell me > if the plug ins had any unsupported requirements. Sorry for the late reply. This link is working: http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.4/support.html You can also navigate to this page for a specific download by clicking the 'JRE and OS support statement' in the Documentation section on the download site.
Unfortunately the 'JRE and OS support' statement page is blank. :-)
(In reply to comment #51) > Unfortunately the 'JRE and OS support' statement page is blank. :-) Try to open the page in Firefox. I had the same problem using Safari: you just get an empty page and wonder why people reference this page... :-) I believe the problem is that the page uses javascript to apply an XSL style sheet to an XML file to generate an HTML page. If you don't want to use an other browser, try the URL below, where I put the generated page (saved from firedox). http://www.stud.uni-karlsruhe.de/~uqv9/support.html
Re: "JRE and OS support statement is blank". Ironically I can't see the problem. I can see content in both my IE (version 6.0.2900.2180.xpsp_sp2_gdr.070227-2254) and Firefox (version 2.0.0.6). Can I ask someone who is having the problem to open the page in IE and then click on the little yellow warning icon in the bottom left hand corner of IE? (The icon is part of the status bar, if I remember correctly.) If you double-click on this you should see a warning dialog box pop up. I'm hoping that the details in that box will help me debug the problem. Thanks!
The funny thing is: I can see http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.4/support.html with firefox but I can't see http://www.stud.uni-karlsruhe.de/~uqv9/support.html. It might help you to know that I see the page for a small fraction of a second and then it turns white.
Created attachment 87834 [details] Patch to fix the Safari JRE/OS display problem Hi folks, I had hoped that I'd be able to fix the Safari display problem for all files on the TPTP web site but I don't think that I can, unfortunately. I've created a workaround for Safari for only the JRE/OS support statements so at least you can see that Mac isn't a supported OS. :o) The web site display problem is caused by the technique that I used to construct the JRE/OS support statement. The JRE/OS support statement is an XSLT transformation of an XML file and that XSLT transformation is done via JavaScript. Safari doesn't support this type of transformation (see http://developer.apple.com/internet/safari/faq.html#anchor21). I've done the workaround that's documented in that FAQ and tested that the workaround doesn't break IE or Firefox. For the blank page, I guess that Safari doesn't support JavaScript "alert" boxes? Because the script did try to launch an alert box to warn the user that their browser couldn't display the page. I changed the alert into a "document.write" so that the page itself displays the error. Paul, I've attached a patch to fix the JRE/OS problem. Once you've had a chance to apply the patch, could you post a note here to ask for a Mac volunteer to test drive the fix? Thanks, Ruth.
(In reply to comment #55) Thanks Ruth for this patch. I have checked it into CVS (HEAD). Christopher, can you verify the fix?
I have a Mac at home (and am working from home today), so I can unfortunately confirm that this does not fix the problem. The page is still blank in Safari on the Mac. Well, not really blank -- it has the header and the title "TPTP v4.4 prerequisites and tested operating systems and JRE combinations", but that's the end. Note that there is a version of Safari for Windows now, so we can probably test this fix without needing a Mac. When I view the source in Safari, here's the entirety of the page (which at least confirms that I am seeing the updated file): <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>TPTP v4.4 prerequisites and tested operating systems and JRE combinations</title> <link rel="stylesheet" type="text/css" href="../../../../eclipse_style.css"/> <link rel="stylesheet" type="text/css" href="../table.css"/> <script src="http://www.eclipse.org/tptp/resources/transform.js"></script> </head> <body onload="Initialize('support44.xml'); SetTarget('target_content'); SetInput('support44.xml'); SetStylesheet('../support_summary.xsl'); Transform();"> <div id="content"> <div id="page_header">Eclipse Test & Performance Tools Platform v4.4</div> <div id="page_sub_header">Release information</div> <div id="section_header">TPTP v4.4 prerequisites and tested operating systems and JRE combinations</div> </div> <div id="target_content"></div> </body> </html>
(In reply to comment #55) The problem is that this page is not valid, so Firefox should not actually be showing it either. There are five major errors in the HTML, so Safari's behavior is actually the correct behavior for this page. Firefox is the broken browser here. Please correct the page, especially lines 4, 7, and 8 which incorrectly use self closing tags.
Fixing the HTML problems until the W3C HTML validator passed the page did not fix the problem. I traced it down to that JavaScript; the script incorrectly identified Safari as Firefox and attempted to transform the XSLT, which unfortunately isn't supported by Safari. The fix was to detect Safari and if it is then to write the error message and provide an alternate link to the XML file for viewing. That said, I tested it using Safari 3.0.4 for Windows, so if someone wants to test this page on a Mac to confirm that it's good? If it's not then let me know. In the mean time I'll be spending my time fixing other HTML files with self-closing tags. ;o)
I confirm that I can view this correctly on Safari on a Mac (running Tiger). The page first appears with an error message, saying that the browser doesn't support XSLT transforms via Javascript, and there's a link to go to an alternate page, which renders correctly. Not sure if it's worth the trouble, but it might be less intrusive to just redirect to the alternate page automatically. (No reason to bother the user with information about their browser capabilities.)
Good idea re: redirect, Joe. Done.
I started this wiki page: http://wiki.eclipse.org/Notes_on_Building_AC_on_Mac_OS_X I do not have it building, and I doubt that I will get it building before I run out of time or interest. But hopefully by documenting my progress others can help or get started faster.
Created attachment 97731 [details] updated CBE patch Here is an update to the original CBE patch for OS X. The code is unchanged, it just puts the files in the correct location, and removes some commented out code. To build and test the CBE with this patch: 1. check out the CBE dev.eclipse.org:/cvsroot/tptp:platform/org.eclipse.tptp.platform.logging.events 2. apply patch to src.native folder 3. cd src.native/CommonBaseEvent 4. built it: make 5. test it: chmod a+x UnitTest/scripts/UT_CBE_Darwin.sh UnitTest/scripts/UT_CBE_Darwin.sh -l packaging -a ut 6. run sample program: packaging/Sample For more details see the wiki page: http://wiki.eclipse.org/Notes_on_Building_AC_on_Mac_OS_X
I'm looking at trying to get the org.eclipse.tptp.platform.agentcontroller/src-native-new folder building on OSX. This will require some changes to the makefile setup. In the CBE and org.eclipse.tptp.platform.agentcontroller/src-native there is a include.common and then a include."arch" setup that is used by the makefiles. However in the src-native-new there is no such setup. There are 32 makefiles used by the build_tptp_ac.script src-native-new and it seems there is no common file which all of them import. I can try to implement something like include.common setup, but I wanted to check if that is what you want or you have something else planned. However if the build system is being revised, would it make sense to try to use autotools instead?
I'm also surprised that even after over 4 years since the bug was opened, the Eclipse update manager doesn't even give a warning that the TPTP components won't work on OS X. I'd like to help but I don't understand the system beyond my simple use of the most basic functions (profiling for execution time). What work exactly needs to be done?
(In reply to comment #65) > I'm also surprised that even after over 4 years since the bug was opened, the > Eclipse update manager doesn't even give a warning that the TPTP components > won't work on OS X. > > I'd like to help but I don't understand the system beyond my simple use of the > most basic functions (profiling for execution time). What work exactly needs to > be done? > We all share your angst ;-( There are a few issues at play. 1. update manager does not handle the concept of platform specific plugins. The eclipse platform provides a separate install image for each platform, but if you look inside, you generally find a dir for each OS/hdw platform and the unused ones are empty. If your plugin has native code like the agent controller and the jvm instrumentation code in TPTP you are stuck. Providing all the binaries in the plugin and at runtime selecting the one you need can technically work but it makes the download HUGE and people complain. Providing a platform specific plugin for separate download and install by the user creates a bad out of the box experience and people complain. We have worked with the update mgr folks on this, but it is only one of many things they are dealing with. 2. The project committer base has changed and reduced a lot over the last few years. Not due to lack of user interest, but due to lack of investor interest. TPTP does what they need and the investment reflects that. This has limited our ability or sustain teh community let alone address update mgr problems. In fact you will notice that we have had to reduce the supported content of TPTP year over year, including the reduction of the number of platforms we can port and support. Because of this we are very careful in committing code that we don't have someone agreeing to regularly test and answer questions on. 3. Further to #2 our basic issue for XOS is not interest from users. It is clear many people want this support. At one point we almost had the hardware and people willing ot build and test the drivers. However that did not happen and we actually had to reduce the platform coverage. 4. To move forward on getting an OSX driver built and published, we simply need someone or more people to be willing and able to do regular builds and fix platform specific bugs (all within the Eclipse foundation contributor rules). I personally would love to see some fresh contribution to the project and some growth in the committer list. To be clear this is net new work for the project and the current people are fully tapped out already. So we need new people to step up to the plate and run with this under all the contributor rules of Eclipse. If you have the hardware and can legally commit the time and effort, we will do our best to support you in building and publishing drivers. This is a base principal of open source ;-)
(In reply to comment #66) > 4. To move forward on getting an OSX driver built and published, we simply need > someone or more people to be willing and able to do regular builds and fix > platform specific bugs (all within the Eclipse foundation contributor rules). I > personally would love to see some fresh contribution to the project and some > growth in the committer list. > To be clear this is net new work for the project and the current people are > fully tapped out already. So we need new people to step up to the plate and run > with this under all the contributor rules of Eclipse. > > If you have the hardware and can legally commit the time and effort, we will do > our best to support you in building and publishing drivers. This is a base > principal of open source ;-) Hi Harm, If you can give me some pointers to the relevant docs and tools (I've never contributed to Eclipse projects before), I would be happy to do some work on the OS X (x86) drivers, if it's within my capabilities. Oisín
> Hi Harm, > > If you can give me some pointers to the relevant docs and tools (I've never > contributed to Eclipse projects before), I would be happy to do some work on > the OS X (x86) drivers, if it's within my capabilities. > > Oisín > Hi Oisín, Below is a quick review of the Eclipse Process for contribution: http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf You can also get more detail about the contribution process here: http://www.eclipse.org/legal/ Please let me know if you need any further information. Eugene
I would also be interested in contributing and might have 2-4 weeks to work on it fulltime in late November or December. I will read up on it until then, and watch this topic to see if my effort could be used.
Rich: I am the TPTP lead and TPTP would like to have you help out with the Mac OS port :) A way forward here would be for you to make sure that you can comply with the legal requirements (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf). This may look a little scary, but what it really means is that you have to have to be able to give your software to open source eclipse. That means your employer must agree, and that you can't put in other peoples copyrighted stuff, etc. Eclipse (and TPTP) is a meritocracy. That is a good thing! All the work is done in the open. For meritocracies to work, people need to know each other. What is the best way for us to get to know you and the quality of your work (and vica versa)? So, how about this for a plan. You make sure that you can open source the Mac OS software that you plan to write and you can commit enough effort that you are pretty sure that you can get the job done. TPTP will support you with about 8 hours of question answering regarding the AC and TI over the period of a month or so. If you get it all finished and it is good, we get it into TPTP (we would have to do some review work) for the whole world to see your glory and your merit ;) If there are some snags along the way, then we see how to proceed. In this way, TPTP can bound it's commitment to someone who has not yet earned their eclipse wings and you can be assured of a reasonable level of support in your effort. If it goes well, then you might even become the most exalted of the exalted: an eclipse committer :) You even get a special shirt :) :) Note that there are a few possibilities for the result of your efforts. If you can commit to supporting this code after it is completed, then a possibility would be to include it in the TPTP download that is built for each delivery. If you cannot commit to that support, then it can survive in the TPTP code base and the community can build it, but TPTP would not include it in the official TPTP builds.
The plan sounds good. I will make sure I can do the legal mumbo-jumbo with my employer, and I will continue to investigate what needs to be done - with questions to follow :)
:) We have the TPTP PMC call on wednesdays at 10 EST. In this weeks call, we will identify the person to be your point of contact. Then we can move out and get er done. Did you look at the age of this bugzilla? "In TPTP, we promise fast service no matter how long it takes". Great expectations!
(In reply to comment #72) > Then we can move out and get er done. Did you look at the age of this > bugzilla? "In TPTP, we promise fast service no matter how long it takes". It's a bit like saying "we promise a low fatality rate, no matter how many people are killed" :D
I think I should chime in and comment that I've done a significant amount of work on a Mac port. I've taken an interest in the Mac platform over the last year - enough interest to 'donate' some of my time to try to get a port running over the last few months. I have an Agent Controller that compiles and runs. In the best interests of the project (and not duplicating work), I've posted my patches here so that the work can be continued. Background on the patches: --------------------------- The patches run on a Tiger (10.4) Intel box. I do not have access to a 10.5 (Leopard) box so it is untested, but I don't think it many (if any) problems would be encountered. I was using the GCC and Make implementations that are included with XCode 2.5. Versions are below: macintosh:~ root# make -v GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. macintosh:~ root# g++ -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) I suspect newer versions of XCode will include more recent GCC and make implementations - I'm not sure if that will be a problem. Description of patches: ----------------------- I've attached both patches to the defect. Both patches are based off of the 4.5.0 TPTP Branch. ac-patch-4.5.0.txt - the patch to the org.eclipse.tptp.platform.agentcontroller plugin cbe-patch-4.5.0.txt - the patch to the org.eclipse.tptp.platform.logging.events plugin I'm not sure how many changes have been committed into the CVS since 4.5, but it may be a good idea to try to apply the patches to the plugins from HEAD and continue the port work from that point. What is completed/tested with the patches: ---------------------------------------- - New Execution Framework agents TestAgent.java and TestProcess.java tested and working. (from http://www.eclipse.org/tptp/platform/documents/newtechAC/javadoc/overview-summary.html) - FileTransferAgent does not work (fails trying to get the FileTransferAgent ... this functionality works in TPTPProcess.java and tptpFileTransferAgent can be run on it's own...could be a problem in agent.xml/configuration issue) TODO list/Items not covered by the patches ------------------------------------------ Items on my immediate 'TODO' list: 1) I have not gotten to several agents/scenarios which are usually tested: - piAgent was not tested (however, this may not be necessary given that PI is no longer supported) - URL test from workbench was not tested - LoggingAgent was not tested (available in the CVS). This is a java agent using the old execution framework. 2) Fix broken agents listed in previous section. We also need the TI Agent ported for profiling. This involves porting the following three plugins: 3) Harmony plugin port (org.apache.harmony._vmcore_verifier plugin). No work on this has been completed on this portion yet. 4) Probekit port. (org.eclipse.hyades.probekit plugin). No work on this has been completed on this portion yet. 5) TI Agent (org.eclipse.tptp.platform.jvmti.runtime plugin). No work on this has been completed on this portion yet. All three above plugins are in the tptp CVS. I'm not sure which one of these issues/outstanding items should be addressed first. Comments? Potential Issues/Problems/Complaints with the patches: ------------------------------------------------------ - There are my debug comments in code. I thought about taking them out before creating the patch, but they are useful for tracing the execution. They will need to be removed before the final patch it submitted. Basic Instructions to get the AC building: ----------------------------------------- 1) Download Xerces. The AC ships with Xerces 2.8 on other platforms, so that's what I used too (xerces-c_2_8_0-x86-macosx-gcc_4_0) 2) Apply the cbe-patch-4.5.0.txt to org.eclipse.tptp.platform.logging.events. Compile this plugin - the output will be a shared library called libcbe.dylib. This library will be needed for the main AC build. 3) Apply the ac-patch-4.5.0.txt patch to org.eclipse.tptp.platform.agentcontroller. - The build scripts is <AC_HOME>/src-native-new/builds/build_tptp_ac.script. There are several paths/variables at the top of that script that must be set correctly. - Several components look for jni.h so you will need to link to Java correctly - There is a symbolic link at /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK which should point to the newest java for your platform. Setting JAVA_HOME to that link should be sufficient for linking. (but double-check that for your platform). - You will also need to build the sample/test agents. This is done using the <AC_HOME>/src-native-new/builds/build_tptp_samples.script file 4) When the build succeeds, you will need to run <AC_HOME>/src-native-new/SetConfig.sh to setup the configuration. You will need to create a config.jar and place it in the <AC_HOME>/src-native-new/lib directory. The config.jar needs to be the contents of the org.eclipse.tptp.platform.agentcontroller/src-config directory.
Created attachment 117488 [details] Patch for Agent Controller 4.5
Created attachment 117489 [details] Patch for CBE 4.5 plugin
Hi folks, I'll be lead committer for code contributions related to the Mac port, and I'll also be involved in reviewing patches as they come in. Paul and I have been working together on AC porting, and between the two of us we should be able to answer any code questions that you have... just post to the Bugzilla entry and we'll get to them as soon as we can. ;)
*** Bug 213458 has been marked as a duplicate of this bug. ***
Would you be able to summarize the current state of Mac OS X support? Can I test TPTP on Mac OS X , and what still needs to be done? Thanks, Greg (In reply to comment #77) > Hi folks, I'll be lead committer for code contributions related to the Mac > port, and I'll also be involved in reviewing patches as they come in. Paul and > I have been working together on AC porting, and between the two of us we should > be able to answer any code questions that you have... just post to the Bugzilla > entry and we'll get to them as soon as we can. ;) >
Hi Greg, some work has been done on porting the Agent Controller to OSX, however, it is not yet in a state that it can be tested. The work on the Agent Controller port must still be completed, and the JVMTI profiling agent must be ported, as well. Rich has said he will begin work fairly shortly, and I imagine any help would be appreciated.
Hi Rich, it's been a while since we've heard anything, have you made any progress with the code?
FYI ac-patch-4.5.0.txt does not apply cleanly to the HEAD anymore.
Created attachment 136113 [details] reworked patchset now builds Here is my rework on the patches posted already, This gets me to the point where ./build_tptp_ac.script gets me the message "No failures -- build successful" I've split the original patch into 6 separate patches, and hope to isolate patches further so that they canbe incrementally merged into the cvs. Two of them I've already submitted for commits.
I have extracted code bits from the patches that are straight forward commits and put them as dependent bugs, the more code we can get to commit in the cvs and coexist with other ports, the easier it will be to make progress. By the way I got the thing to build now but I don't know what the next step is. I'd appreciate if someone can guide me.
Here are my build notes. Things I had to do myself which are not documented by the patches. 1) I could not build xcerses the way AC would be happy with it, I ended up downloading and expanding this file which worked like a charm: http://www.apache.org/dist/xerces/c/2/binaries/xerces-c_2_8_0-x86-macosx-gcc_4_0.tar.gz 2) AC expects to access CBE header files (there are, total of two .h files in all of src.native) in $CBE_SDK_HOME/include . So I copied those files over to my workspace/org.eclipse.tptp.platform.logging.events/include. 3) AC build system expects gmake. It's called make on darwin. So I ended up making a softlink called gmake in my path. Didn't try aliasing. Too lazy to look it up. 4) the build script build_tptp_ac.script has to be executed while being in that directory. Meaning cd src-native-new/build and then exectue. 5) Build script expects a lib directory at ../lib . so mkdir src-native-new/lib footnote: looking at the makefiles, I figured I'd need to copy libcbe.dylib from org.eclipse.tptp.platform.logging.events/src.native/CommonBaseEvent/packaging/libcbe.dylib to org.eclipse.tptp.platform.logging.events/lib . But he scripts haven't complained yet.
Question: I tried to run cbe sample as per Scott's directions, this is what I got, is that the right output or I need to go hunting for the problem? On one hand I see a double malloc, on the other hand it says sample executed successfully. mermaid:CommonBaseEvent spundun$ packaging/Sample <CommonBaseEvent creationTime="2009-05-17T10:23:25.960776Z" globalInstanceId="AA0FE59D000EA6967DD7A5F5401EA9A3" localInstanceId="Sample Event" msg="Hyades Common Base Event v1.0.1 Sample log message." severity="60" version="1.0.1"> <extendedDataElements name="Sample extended data element name" type="string"> <values>Sample extended data element value</values> </extendedDataElements> <sourceComponentId component="Sample" componentIdType="Application" location="127.0.0.1" locationType="IPV4" subComponent="main" componentType="Eclipse_TPTP"/> <situation categoryName="ReportSituation"> <situationType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ReportSituation" reasoningScope="INTERNAL" reportCategory="LOG"/> </situation> Sample(21839) malloc: *** error for object 0x100550: double free *** set a breakpoint in malloc_error_break to debug </CommonBaseEvent> Sample successfully ended!
Regarding the double malloc/free: I created the following bug about it, but it got resolved won't fix: https://bugs.eclipse.org/bugs/show_bug.cgi?id=229000 I believe the test is running correctly. Most of the other bugs I opened that are linked from that wiki page also got resolved won't fix.
I was reviewing the patches and the changes to TPTPSemaphore.c that were introduced by Paul don't seem right to me. I checked the semaphore api on my mac osx 10.5 intel core2 duo, and it looks exactly the same as linux. Maybe the api has changed since Paul's patch. I'm dropping out those changes for now. (I haven't yet done any meaningful testing yet, focusing on getting the patches cleaned up for building). Oh, and still waiting for Jonathan or someone else to guide me to the next step, while I review and cleanup the patches, ready to be committed to the cvs repository.
Created attachment 136140 [details] more clean up, refactoring Here is a new patchset, updated with the new bugs. I have submitted all of the C code in total of 4 patch requests (see the depends bugs). If we get all those 4 patchsets in the cvs then we will have all the C code that Pierre, Scott, Paul, me and others have worked on in the repository. It will mean there will be much smaller patch to carry around and keep updating with time. Only patches I've not submitted for inclusion yet are the ones that change the makefile build system and the shell scripts that go with the agent.
I made config.jar (by exporting it through eclipse) and put it in the src-native-new/lib directory. then `cd src-native-new/bin` and ./SetConfig.sh gave me the following output. Specify the fully qualified path of "java" (e.g. /usr/java1.4/jre/bin/java): Default>"/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java" (Press <ENTER> to accept the default value) New value> Network access mode (ALL=allow any host, LOCAL=allow only this host, CUSTOM=list of hosts): Default>"LOCAL" (Press <ENTER> to accept the default value) New value> Security enabled. (true/false): Default>"FALSE" (Press <ENTER> to accept the default value) New value> Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/icu/util/ULocale at org.eclipse.tptp.platform.agentcontroller.config.SetConfig.generateConfiguration(SetConfig.java:1192) at org.eclipse.tptp.platform.agentcontroller.config.SetConfigSkeleton.run(SetConfigSkeleton.java:135) at org.eclipse.tptp.platform.agentcontroller.config.SetConfig.generateConfig(SetConfig.java:138) at org.eclipse.tptp.platform.agentcontroller.config.SetConfig.main(SetConfig.java:88) I tried setting export CLASSPATH=/Applications/Other/eclipse/plugins/:$CLASSPATH thinking that maybe that will fix it... but no. What's the solution to that? why is it not documented, did I do something wrong? (I tried to go through the bin/readme.txt file no mention of icu)
I fixed the exception by copying a jarfile as follows. cp /Applications/Other/eclipse/plugins/com.ibm.icu_3.8.1.v20080530.jar lib/config.nl1.jar I wish this was documented somewhere (if it is, then I wish I would have found it sooner). now I'm trying to figureout what needs to be done once you run SetConfig.sh successfully, I see that serviceconfig.xml file got filled, I don't know what to do with it yet. going back to the readme.txt file. Ah, now you try to run bin/ACStart.sh . That's telling me Starting Agent Controller. dyld: Library not loaded: ../../../lib/libtptpUtils.dylib.5.0.0 Referenced from: /Users/spundun/work/2009-spring/OSA/workspace/org.eclipse.tptp.platform.agentcontroller/src-native-new/bin/./../bin/ACServer Reason: image not found ./ACStart.sh: line 70: 3679 Trace/BPT trap ACServer "$@" ACServer started successfully. not sure if it started successfully or not... :/ (probably not, looking for the easy fix)
Fixed that by adding DYLD_LIBRARY_PATH and copying the xcerses dylib file into src-native-new/lib directory. Still not sure how exactly the whole thing is supposed to be bundled and how does the AC architecture expect to load all this machine code, and where. Continuing the exploration.
Ok, I spoke too soon, Paul's semaphore changes seem to be right on the money (sleep deprivation, my excuse :) ). I'll apply those and see how far I get.
Hi Spundun, thanks for splitting your changes up into separate bugs, it's very helpful as compared to reading a bugzilla that has grown to 30+ pages. :) Here are my comments on the above (>> >> 1) I could not build xcerses the way AC would be happy with it, I ended up >> downloading and expanding this file which worked like a charm: >> http://www.apache.org/dist/xerces/c/2/binaries/xerces-c_2_8_0-x86-macosx-gcc_4_0.tar.gz Yes, you can just grab the 2.8.0 Xerces. >> 2) AC expects to access CBE header files (there are, total of two .h files in >> all of src.native) in $CBE_SDK_HOME/include . So I copied those files over to >> my workspace/org.eclipse.tptp.platform.logging.events/include. Yes, one needs to set CBE_SDK_HOME to the SDK download of the CBE. >> 3) AC build system expects gmake. It's called make on darwin. So I ended up >> making a softlink called gmake in my path. Didn't try aliasing. Too lazy to >> look it up. We switched it from make to gmake in our makefiles as gmake is GNU make on all existing platforms (including Linux). Good to know that there is a platform that breaks our convention :). >> 4) the build script build_tptp_ac.script has to be executed while being in that >> directory. Meaning cd src-native-new/build and then exectue. Correct. >> 5) Build script expects a lib directory at ../lib . so mkdir src-native-new/lib Correct, it is necessary to create that lib dir whenever checking out a fresh copy of the AC code from CVS. As for the CBE sample, no one has worked on this code in sometime, hence the WONTFIX the bug got last year. AFAIK this problem does not occur in our application of the CBE code, being its use in the AC logging functionality. Next, for the ULocale, this comes from the com.ibm.icu_[...]jar, which you can grab from the one of the existing agent controller builds from under the /plugins directoru. The message about ACServer is starting succesfully is printed by the shell script, rather than the agent controller itself. Consequently, it can be wrong. The shell script code merely checks a ps run for the resulting process after some number of seconds (and may need to be updated for your platform). In fact, the ACStart.sh and ACStop.sh are responsible for adding the appropriate libraries to the library path (PATH on Windows, LD_LIBRARY_PATH on Linux), as well as adding the ICU jar to the classpath when SetConfig.sh is run.
There's active participation in the community on contributing to this effort. So I'm tentatively targeting this to TPTP 4.6.1 so that this is not lost in the massive house cleaning effort currently underway for all resolved enhancements. Which release this enhancement would go in would very much depend on the level of community contribution we are able to get for this effort.
Thanks Kathy, I was a bit worried. :)
I really would like to use TPTP on macosx (my development platform). If you need GNU utilities such as gmake, they are available for macosx via the MacPorts project here: http://www.macports.org/ For easier GUI-level installation of macports configurations of popular unix/gnu utilities, I use Porticus available here: http://porticus.alittledrop.com/
I want to clarify that the patches I contributed are new and did not use any code from the other contributors.
My patch is based on paul's patch, most of the fragments are covered by other dependent bugs that I created. However there are some build related patches that I haven't apwaned into a new bug yet. As a matter of fact, paul's patch on bug #278622 probably replaces all the work in the build patch. + here is the rights note. -> I Authorize all the work that I've done, to be used under EPL, by the project that this bugzilla currently belongs to. -> It should be noted that some of the contribution has come under my time at work with my employer "University of Southern California, Information Sciences Institute". The official url is www.isi.edu . -> Please understand that my efforts were mostly spent in re-organizing existing patches and code. This code was already contributed to bug #68111 by other folks. I *did* contribute improvements to the existing patch, in terms of better organization, readability, and overall compatibility with current CVS head.
Comment on attachment 55369 [details] CommonBaseEvent patch for Darwin (PPC, untested on x86) Marking the patch as obsolete as it's not used in the current "working copy" submitted by Paul and modified by Spundun.
Comment on attachment 56192 [details] AgentController patch for Darwin (PPC, untested on x86) Marking the patch as obsolete as it's not used in the current "working copy" submitted by Paul and modified by Spundun.
Comment on attachment 87834 [details] Patch to fix the Safari JRE/OS display problem Marking the patch as obsolete as it's not used in the current "working copy" submitted by Paul and modified by Spundun.
Comment on attachment 97731 [details] updated CBE patch Marking the patch as obsolete as it's not used in the current "working copy" submitted by Paul and modified by Spundun.
Please add the following to the header of all files contributed by Spundun: ****** Contributed by Spundun Bhatt (spundun@gmail.com), with the support and encouragement of the University of Southern California Information Sciences Institute Distributed Scalable Systems Division. ****** Note that the CQ for Spundun's contribution to this RFE (and it's child defects bug 276591 bug 276607, bug 276615 and bug 276640) have been approved by the Eclipse IPO under CQ 3397 (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3397). The code can be checked in now with the above update to the header of all files contributed by Spundun.
Deferring to TPTP 4.6.2.
When is the TPTP milestone 4.6.2 expected to come out? (In reply to comment #105) > Deferring to TPTP 4.6.2.
(In reply to comment #106) > When is the TPTP milestone 4.6.2 expected to come out? > The latest development schedules can be viewed at http://www.eclipse.org/tptp/home/project_info/index.php? .
A TPTP wiki page on Mac OS development is created. An AC for Mac OS X platform is built and posted on the page. Comment and feedback are welcome to help enrich the content of the page. link to page: http://wiki.eclipse.org/Agent_Controller_on_MAC_OS
Here's the wiki page with the latest development of the MAC OS port for the Agent Controller: http://wiki.eclipse.org/Agent_Controller_on_MAC_OS As stated on that page, [HELP WANTED] The development of MAC OX support depends largely on community contribution to move forward. A copy of the latest build is made available on this page to help interested party to start the development process.
Looking forward to this in earnest. I'm available for testing on OSX 10.6.2 on Java 1.6.
No further development effort was received from the community for quite a few months. Resolving as WONTFIX.
Someone recently expressed interest in working on this as a GSOC project on the soc-dev list: http://dev.eclipse.org/mhonarc/lists/soc-dev/msg01490.html
Closing.
