Talk:Open64: Difference between revisions
→Open64 Branches: Maybe this compromise will work? |
No edit summary |
||
Line 56: | Line 56: | ||
I feel that if we can agree on the importance of the forks to the development of Open64, we should be able to come up with wording that says the forks began from Pro64 and that later many of the changes from those forks were merged into Open64. This way, we aren't implying anything about the naming, yet we leave the important information there about the development. What do you think? <span style="border:1px solid;background:black">[[User:snaphat|'''<span style="background:teal;color:white"> snaphat </span>''']][[User talk:snaphat|<span style="color:black;background-color:wheat;">►</span>]]</span> 06:10, 30 August 2011 (UTC) |
I feel that if we can agree on the importance of the forks to the development of Open64, we should be able to come up with wording that says the forks began from Pro64 and that later many of the changes from those forks were merged into Open64. This way, we aren't implying anything about the naming, yet we leave the important information there about the development. What do you think? <span style="border:1px solid;background:black">[[User:snaphat|'''<span style="background:teal;color:white"> snaphat </span>''']][[User talk:snaphat|<span style="color:black;background-color:wheat;">►</span>]]</span> 06:10, 30 August 2011 (UTC) |
||
My sticky point is that this article is about Open64 and not Pro64 forks. Do you agree about that? Referencing a dozen forks of Pro64 offers no value to the reader or this article - Do you agree with that? (I think this is what you're asking me) If you want to create a Pro64 article and reference Pro64 forks then it seems very relevant. I don't check this often and I thought it's resolved. |
|||
Anyone can take the original Pro64 tarball - apply a mountain patch on top of it, but it doesn't mean that's where the project "started". It's the view of one of the founders, Sun Chan, who I referenced before that said it originated with ORC. Also the dates on svn are clear that they occurred *after* the ORC timeline. If you write code I shouldn't even have to explain or discuss this further. |
|||
I'm going to once again delete the information. Open64 is not an "official" successor to Pro64 anymore than the various other *Pro64* forks which exist. If every fork of "Pro64" referenced all the other forks would that make any sense at all? Adding superfluous information because there's nothing else to write about doesn't improve the quality of the article or wikipedia. |
Revision as of 01:49, 21 September 2011
Computing Unassessed | ||||||||||
|
The Open64 article says that there are many branches but only mentions a few. I was looking for which branch compiles for the x86 architecture, but such a branch is not even mentioned, even though the first paragraph seems to indicate such a branch exists. —Preceding unsigned comment added by 74.210.3.120 (talk) 15:37, 1 May 2009 (UTC)
- I think the x86/x64 branch was merged into the mainline quite a while ago. However, you should check on the mailing list instead of asking for the details here. Raysonho (talk) 21:42, 1 May 2009 (UTC)
- AMD has a relation to Open64 too, they are even shipping a bit newer version than listed on the SF page --92.224.196.34 (talk) 14:55, 21 August 2009 (UTC)
Open64 Branches
In reference to commits by user 58.8.60.38: Pro64 was renamed to Open64 in 2001. The branches are important because they refer to the same compiler with simply a new name. Moreover, the svn commit log is incomplete because it was moved from sourceforge so you can't use that as a reference for release date. See this link from 2001 which shows Open64 was around in 2001. There's an announcement of the first official release under the name Open64 here in 2002 (it is version 0.14 because the numbering convention continues from the last release 0.13 under the Pro64 name).
Furthermore, if the information regarding Tilera/Tensilica/Qlogic/PathScale is inaccurate please fix it and don't just delete it. I myself don't see incorrect information (if poorly written). This Thesis has some of the history of open64 as well as a timeline if you need more information or anyone needs citations to fix the article with.
snaphat (talk) 23:17, 5 July 2011 (UTC)
1) Just because Juergen put it in his thesis doesn't make it fact. Does he cite a reference to the source of this information or is it just hearsay? You should email him for clarification because I suspect there are factual errors.
2) Deleting wholly wrong information is imho the correct fix. Poorly written or not do what you want about Tilera and Tensilica, but I'm removing references to Qlogic/PathScale. People at these companies work hard and don't appreciate it.
3) This article is about Open64 and not Pro64. Check the relatively recent mailing list references from one of the founders (Sun Chan) explained it came after ORC with regards to timeline
4) These "branches" if diff'ed would be larger than the original source. It would be like saying Sun Compiler or Cray's compiler environment, which uses an ancestor of the same Cray Fortran front-end, is a "branch". It's misleading and in some ways disparaging. — Preceding unsigned comment added by 58.8.59.230 (talk) 05:59, 16 August 2011 (UTC)
Firstly, I would like to thank you for discussing this on the talk page. I am going to respond to each of your numbered points one by one below:
- Juergen states his sources as follows: "The figure is based on private slides from Fred Chow and additional information from Shin-Ming Liu and Sun Chan." My understanding is that Juergen worked with pathscale during this period of time. Part of the information is co-verifiable via the sourceforge message archives which I linked above. Moreover, what is your reasoning for saying this information is incorrect? A few months ago, you incorrectly switched the release date of Open64 to 2005-2006. Following this, I had a discussion with Juergen, and he provided sources that give the correct release dates. I am not sure what you are looking for here, but Juergen provided two of the sources above and cites his sources for the historical information and timeline in his thesis. This isn't ideal given that we would like to have many other sources doing the same, but it is enough to keep the information.
- You haven't shown that this information is wrong. On the contrary we have sources that say the opposite. You have in the past before and are now electing to remove only part of the information that you call incorrect here which makes it seem as if you have some sort of pro pathscale agenda here. Why don't you care about Tilera and Tensilica? Whether or not the people at the companies appreciate the information is isn't relevant. Wikipedia's purpose isn't to censor or remove information because people or companies don't like it. Your edits so far have only attempted to remove information that relates Open64 <--> Pathscale in both the Open64 and Pathscale articles. See WP:CENSOR.
- I stated above that Open64 is just a rename of Pro64. SGI released it as Pro64 under GPL in 2000. Around a year later SGI dropped support and UD took control and renamed it Open64. Simply because branches were made in 2000, prior to the name change, does not make it a different compiler. Can you provide the mailing list references from Sun Chan so that we can improve the article? They would be a great addition to what we already have. Sun Chan is actually one of the sources for the information in Juergen's thesis. Moreover, my understanding of ORC is that it was from 2001-2004 and branched from Open64 directly (after the renaming).
- That may or may not be true, but even so that doesn't mean relevant history should be deleted. The difference in wording would be something like 'branch' vs 'based off of'. In both cases, Pathscale and Path64 is still mentioned.
snaphat ► 16:56, 18 August 2011 (UTC)
My response down here. It's incredibly difficult to have a discussion here..
- Yes Juergen interned at PathScale, but my information is correct and verifiable. Under NDA I'm happy to prove and resolve this once and for all if it's his word vs mine. Also the slides you're referring to were corrected by me two years ago and I'm happy to send you accurate versions.
- Have you diffed the sources?????!!!! We are not a fork, a branch of Open64 and any comparison is really just misleading to the reader.
Facts about the source. 1) Total codebase size Open64 1GB vs Path64 110MB 2) Look at who contributes to Open64 and Path64. There is unfortunately zero overlap. 3) In the Open64 commit logs you can see commits which took *PathScale* code and merged it to Open64. Do you want the commit revision? Wouldn't that make Open64 a fork of PathScale and not the opposite?? Some parts which are relatively unchanged from the Pro64 days could still be similar, but that will almost certainly be heavily changed in the next year. I have no agenda and just tired of people twisting the words to grasp at an association which simple doesn't exist. (Except in the minds of people who have been told wrong information) Please fill the article with more important information than hearsay. What if Path64 totally drops the Pro64 code and merges in parts of LLVM.... Would you delete the reference here and run to the LLVM article and add a reference there?
- Why don't I care about Tilera and Tensilica? I don't have detailed access to their source bases and only 2nd hand knowledge like you. Would you submit a paper to a conference with this information? Personally I hold a higher standard for the accuracy of information I state as true.
- Open64 is not just a rename of Pro64. I have stated before and even told you my source. (One of the founders.) Since you are too lazy to look at the mailing list I referenced here it is for you.
"Not exactly, the open64 tree was started with Intel ORC effort based on the open sourced SGI compiler. Pathscale source was merged in later on. The site has always reside in U of Delaware, and that was also start by Intel Research where Roy Ju and myself was in charge of that project." From Sun Chan 5/26/2011 [1]
- The lineage is clear Pro64 2000 -> ORC 2001-200[4-6] -> Open64+ (with most of the early major contributions being merges from PathScale source, but not the other way. Check the commit logs at [2])
- I corrected the Open64 release date based on commit log history which is currently available. I wasn't aware that was inaccurate and actually don't think it is inaccurate, but I don't have the tenacity to research back to prove otherwise — Preceding unsigned comment added by 69.174.255.99 (talk) 17:26, 27 August 2011 (UTC)
Can you provide the corrected diagram? The problem is simply that you have been saying a lot of things, but we need verifiable information. Wikipedia can't go on someones words alone for encyclopedic content and also NDA isn't going to work because no-one can verify that. I understand what you are saying now regarding Open64's lineage; however, you are misrepresenting the order of events a bit. What I am about to say is verifiable via the Open64 repository. Open64 began by duplicating the last release under the Pro64 name. Following that, they merged in some OCR changes. I agree that Open64 merged in Pathscale code as well as OCR code and other code, etc. That's not particularly relevant regarding the lineage though. Sun Chan's comment is correct in the sense that the merges of Pro64 + OCR did go into Open64 in the first few commits, but is incorrect because Open64 began first with the Pro64 sources. Again, I stress that this is verifiable by looking at the first few commits of the repository. It starts with the import of Pro64 .13.
Ideally, here is what I would like to occur. I would like the article to mention forks that occurred while under the Pro64 name. Maybe something like: A number of forks occurred while Open64 was still under the Pro64 name. [INSERT A FEW SENTENCES ABOUT THE FORKS]. Many of the changes were later folded back into Open64.
Right now, you agree that changes were folded back in. Even if you disagree with me regarding the name, do you agree that many of the forks whether they began from Pro64/Open64 are important in the sense that they folded a lot of code back into Open64 and the much of the development of Open64 consists of merges back into its main line from other efforts be them forks of Pro64 or Open64?
Please don't delete information from the article during discussion. I realize this is taking awhile, but if we could have the discussion more frequently than every month, it would work better. snaphat ► 05:58, 30 August 2011 (UTC)
I feel that if we can agree on the importance of the forks to the development of Open64, we should be able to come up with wording that says the forks began from Pro64 and that later many of the changes from those forks were merged into Open64. This way, we aren't implying anything about the naming, yet we leave the important information there about the development. What do you think? snaphat ► 06:10, 30 August 2011 (UTC)
My sticky point is that this article is about Open64 and not Pro64 forks. Do you agree about that? Referencing a dozen forks of Pro64 offers no value to the reader or this article - Do you agree with that? (I think this is what you're asking me) If you want to create a Pro64 article and reference Pro64 forks then it seems very relevant. I don't check this often and I thought it's resolved.
Anyone can take the original Pro64 tarball - apply a mountain patch on top of it, but it doesn't mean that's where the project "started". It's the view of one of the founders, Sun Chan, who I referenced before that said it originated with ORC. Also the dates on svn are clear that they occurred *after* the ORC timeline. If you write code I shouldn't even have to explain or discuss this further.
I'm going to once again delete the information. Open64 is not an "official" successor to Pro64 anymore than the various other *Pro64* forks which exist. If every fork of "Pro64" referenced all the other forks would that make any sense at all? Adding superfluous information because there's nothing else to write about doesn't improve the quality of the article or wikipedia.