Re: Apache C++ Standard Library and the Attic
On 07/18/13 09:03 PM, Brett Porter wrote: At this month's board meeting, a resolution was passed to move Apache C++ Standard Library to the Attic, due to inactivity. The Attic home page [1] contains some details about its purpose - it is the destination for Apache projects that can no longer provide oversight or muster votes for a release. It isn't a reflection on the contributors or the codebase, and is intended to be non-impacting to users. Please let us know if you have any questions or comments, or if you are available to work with the Attic to help with the transition of resources. This was a stupid decision made by bureaucrats. The project still has potential and the lack of vision and belief from the board that those interested could actually achieve it - it's flat out disappointing. What's it cost the board to actually let it have another chance? There are other passionate people like myself who use the software everyday.. It's a silent community... This decision came from those who had some issue with the project for a long time and wouldn't stop until they had their way... I may be wrong and apologies if I am, but the behind the scenes information I have points in one direction only. -1 ASF
Re: Search for new chair
On 05/29/13 06:29 PM, Jim Jagielski wrote: I am stepping down as Chair of the C++ StdLib PMC. So the question is: Does this project and community elect a new Chair, or does it enter the Attic? I'd be willing to chair if others are supportive
Re: Search for new chair
On 05/30/13 03:48 AM, Leandro T. C. Melo wrote: Hi, although I follow this list for a few years, it's actually my first post. I agree community would be on top, so let's say one would like to contribute to the project... What would be the greatest motivating factor? I'd say our target is c++ enthusiasts/professionals, system maintainers and compiler engineers Licensing, portability, quality of codebase, standards conformance and hopefully performance (though I don't have benchmarks to substantiate this claim right now) I mean: This project has been relatively quiet; There's now libc++, which can probably better attract developers (specially given its connection with clang) Based on the commit logs - how much non-Apple/general clang contributions does libc++ get? STL hacking isn't the sexiest project to contribute to generally.. - as fair as I know Window/Linux are not complete yet; I guess STLport is also missing C++11, but I'd assume it's more widely spread than the STDCXX and with more derivations, then more potential as well. STLport's last release was 2008 and I'm not sure how much potential could be derived from that From a more practical side, regarding popularity and consequently an active community: How much people (and who) are using STDCXX (I couldn't find this on the page, sorry if it's there somewhere) and in which areas can the STDCXX be awesome and differentiate from the others. Portability, i18n... I know of a few companies/projects using stdcxx, but it's probably better to leave this as a TODO.
Re: STDCXX-1056 : numpunct fix
On 09/21/12 07:39 AM, Liviu Nicoara wrote: Now, in all honesty, it is not too hard to do that. Once you can satisfactorily explain to yourself what is wrong in the program, the creation of a test case is trivial. Some multi-threading bugs are insidious and hard to reproduce, but even then it's doable by isolating as little a portion of the codebase as possible, as a standalone program, and trimming it until the failure becomes easily reproducible. fencepost comment - The results are based on tools and I don't think he has a large program which actually triggers the conditions. (Creating one may take quite some time)
Re: [REPORT] Apache C++ Standard Library (stdcxx)
On 09/13/12 11:40 PM, Jim Jagielski wrote: On Sep 13, 2012, at 8:43 AM, Jim Jagielskij...@jagunet.com wrote: Is this all about your point of view that even though Apache stdcxx is designed as a library, esp as a system library, that GPLv2 programs cannot use and link to it because the FSF says that the ALv2 is incompatible w/ GPLv2? And all this despite the fact that GPLv2 makes specific accommodations for system libraries... Is that the actionable item of which you speak? You want the ASF to verify something in the GPLv2? FWIW (for completeness) let me state that *every* lawyer I've spoken to says that since stdcxx is designed *AS* a system library, and as a *standard* system library, the whole GPLv2 and ALv2 licenses are incompatible argument is completely moot. The idea that one could not, for example, replace the current stdcxx library in FreeBSD with Apache stdcxx *because of the GPLv2 and ALv2 license incompatibility* is completely bogus. Since this basic argument is baseless, the idea that somehow stdcxx needs to be licensed under something else *because of this* is also bogus. PS: Even if the stdcxx library was under a commercial license, and/or completely proprietary, since it would be a standard, system library, GPLv2 applications would *still* be able to link to it... The GPL does NOT force system libs to even be open source. We appreciate you telling the choir, but it doesn't help resolve this. How to best proceed? Is legal-discuss the best way to go forward or something else? [System lib exception was of course brought up during the BSD discussion, but it was said that system libraries are usually shipped by default with the system. This may not always be the case with STDCXX.]
Re: [REPORT] Apache C++ Standard Library (stdcxx)
On 09/13/12 07:43 PM, Jim Jagielski wrote: Is that the actionable item of which you speak? You want the ASF to verify something in the GPLv2? No - We want to discuss the Apache foundation transferring their rights granted under the contributor agreement to another open source foundation.
Re: [REPORT] Apache C++ Standard Library (stdcxx)
On 09/12/12 05:39 PM, Jim Jagielski wrote: DESCRIPTION * There was some licensing FUD discussed on the list, mostly to promote a rationale for moving the project elsewhere and/or releasing stdcxx under a different license. This has (hopefully) been clarified. You willfully ignore the point and there is a clear need for an actionable item here. Should someone email legal-discuss or what's the correct process for this? --- Once again - This is not about *my* views, your views or your cousin bob's views. If/when STDCXX ships to a large community of users their views may differ - At the very least the FSF has clearly stated their views which gives *others* concern. This point of objection needs to be resolved and we appreciate your help in doing so.
Re: New chair and/or attic
On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no?
Re: STDCXX forks
On 08/31/12 07:40 PM, Liviu Nicoara wrote: Please correct me if I am wrong. I have seen two forks on github, one belonging to C. Bergstrom/Pathscale and the other to Stefan Teleman. The first one contains a number of genuine code changes outside the Apache repository, but without canonical and meaningful commit comments, and without accompanying test cases. We can help clean this up if it makes a real difference Some carry what seem to be bug id's from a private bug database. Some of the changes, e.g., 84d01405124b8c08bb43fdc3755ada2592449727 iirc we renamed the files because of some problem with cmake - it was trying to compile those files instead of treating them like headers. , fa9a45fb36e45b71ba6b4ae93b50bd6679549420, seem odd. I forget why we did this tbh - I'll try to get an answer in case it comes up again as a question Are you guys dropping support for any platforms? Not intentionally - We are using/testing this on Solaris, FBSD and Linux - We may add OSX/Win to that list soon, but I can't promise at this point. For targets we only are able to test x86 and x86_64 NetBSD also has a fork I believe, but not sure if it's public/status Stefan's seem like a complete git-ification of the whole Apache repository but with no changes I could detect. He has quite a number of patches and forget where those are kept. I'm guessing a lot of his fixes target KDE/Qt apps and the Perennial C++VS testsuite. http://www.peren.com/pages/cppvs_set.htm
Re: STDCXX forks
On 08/31/12 08:10 PM, Liviu Nicoara wrote: NetBSD also has a fork I believe, but not sure if it's public/status Do you know where that is? He just posted his bulk patch http://www.netbsd.org/~joerg/stdcxx.diff There's a small amount of CVS noise and we already have one part on our github. I don't have more information
Re: New committers?
On 09/ 1/12 01:13 AM, Jim Jagielski wrote: On Aug 31, 2012, at 9:42 AM, Wojciech Meyerwojciech.me...@arm.com wrote: Jim Jagielskij...@jagunet.com writes: So how are/were they committers?? Hi! Chime in - I think we need to clarify what kind of problems we have with stdcxx being hosted as an Apache project. The two significant ones (as far as I can understand): - as I heard from Christopher Bergström that it's hard to push the stdcxx to FreeBSD ports repository (I can understand it and that sounds pretty bad, if that's the case then the board should consider re-licensing as advised; I agree in general it's a hard decision for the board, but imagine the project would benefit, IANAL tho) Not exactly sure why, or how, since there are other ASF projects in the FreeBSD ports directory... LOTS of others. Do they come bundled with the compiler and link against every c++ application by default? I suspect that their risk assessment may be higher with something that's equivalent to libc on the system. (btw - anecdotal evidence and flippant comments don't help resolve this. Did you even read my previous email explaining this?)
Re: New chair and/or attic
On 09/ 1/12 01:17 AM, Jim Jagielski wrote: The idea that ALv2 projects can't be added to FreeBSD ports is complete and total hogwash. Pure FUD. Thanks for the top post and your view... Can you actually address the issue and question? On Aug 31, 2012, at 8:43 AM, C. Bergströmcbergst...@pathscale.com wrote: On 08/31/12 07:20 PM, Jim Jagielski wrote: On Aug 30, 2012, at 8:00 PM, C. Bergströmcbergst...@pathscale.com wrote: While STDCXX is at Apache it will never be BSD licensed. Solution - move it away from Apache foundation and have them transfer some of the additional rights they received to allow recipient foundation to relicense. I thought this would be a win for the project and everyone, but for some reason instead of opening a discussion to transfer - it's just death grip and pushing to the attic. What is wrong with ALv2? Armchair lawyer discussion on this will never end and I'll try to keep this brief.. Apache lawyer views, our lawyer views, your views.. etc (not the problem here) FSF views which probably have some weight across the open source community is summed up with this.. Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html That view seems to have been accepted by the FBSD community - The effect is that the large amount of GPLv2 code in ports/elsewhere can't take advantage of STDCXX due to it's license. Please note I'm not arguing if this is correct, but just the feedback I've gotten. I'm not interested to fight that. Open source works like this in my experience : people use it, they love it and they contribute back. To get users we need to solve problems for larger communities - Make sense? Can you help clear this roadblock, yes or no?
Re: New committers?
On 09/ 1/12 01:35 AM, Stefan Teleman wrote: On Fri, Aug 31, 2012 at 2:27 PM, C. Bergström cbergst...@pathscale.com wrote: stdcxx ends up linking against *EVERY* C++ application if it's used in the default compiler setup. (Which is what I was trying to achieve) That includes ***GPLv2 software in ports. Get it? How exactly is APLv2 different from 2-clause BSD or 3-clause BSD in this respect? The BSD licenses are just as incompatible with GPLv2 as APLv2 is. Our views may be the same, but others are not from the apache website Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2 http://www.apache.org/licenses/GPL-compatibility.html
Re: New chair and/or attic
On 09/ 1/12 01:28 AM, Jim Jagielski wrote: Your suggestion is that, somehow, one cannot push stdcxx as part of the FreeBSD ports collection. And that is because it is licensed under ALv2. My response is that that suggestion is total hogwash. That's not an authoritative response - To help resolve this maybe we could 1) Have Apache lawyers say the same thing via a letter to FBSD foundation or 2) Please have this link updated and provide a reference to where FSF has stated their revised compatibility views about APLv2 + GPLv2 http://www.apache.org/licenses/GPL-compatibility.html Can you help with either of those?
Re: New chair and/or attic
On 09/ 1/12 02:01 AM, Jim Jagielski wrote: On Aug 31, 2012, at 2:41 PM, C. Bergströmcbergst...@pathscale.com wrote: On 09/ 1/12 01:28 AM, Jim Jagielski wrote: Your suggestion is that, somehow, one cannot push stdcxx as part of the FreeBSD ports collection. And that is because it is licensed under ALv2. My response is that that suggestion is total hogwash. That's not an authoritative response - To help resolve this maybe we could 1) Have Apache lawyers say the same thing via a letter to FBSD foundation or 2) Please have this link updated and provide a reference to where FSF has stated their revised compatibility views about APLv2 + GPLv2 http://www.apache.org/licenses/GPL-compatibility.html Ummm... system library These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. armchair lawyer response not acceptable - Unless you're an Apache lawyer?
Re: New chair and/or attic
I'm sincerely sorry to ask this and I have my own answers, but why continue STDCXX when such negativity from Apache is apparent.. Will Apache consider passing along some/all of it's CLA granted rights/additional permissions to another foundation that hosts open source projects? or Why not move to libc++? (Yes I realize the amount of effort involved here) ./C
Re: New chair and/or attic
On 08/31/12 03:10 AM, Pavel Heimlich, a.k.a. hajma wrote: 2) Posting the project is dead on a public list certainly doesn't help grow a community well, it's half year since revival of the project was announced and has there been any progress/improvements? The state of this is a koma at best. Just because bureaucrats say jump doesn't mean anything is going to happen. --- The facts as I know it 1) Our fork is maintained (continuous bug fixes - which we won't submit to Apache now) 2) Stefan is putting in some work (one man army) 3) Wojciech Meyer had put in some work 4) NetBSD has a small amount of patches they could probably push upstream (If Jörg has the time) 5) Martin is/was great for feedback in all areas of STL/C++/occasional code review - I'm really not sure if to you this would make the project dead or in a koma. The problem as I have said before is there needs to be some compelling reason to use STDCXX vs libc++. Instead of just trying to sweep it under the rug - why not find it a new home, put a one line call for help on a blog/homepage or etc. Apache leaders have a huge readership, but this koma issue isn't on the general radar. STDCXX isn't some stupid ass java framework or widget - It's a *critical* part of a C++ stack and the cost of leaving it out of the attic is negligible - What's the benefit of bringing up these attic discussions?
Re: STDCXX fork
On 06/26/11 10:31 PM, Stefan Teleman wrote: On 2011/6/26 C. Bergströmcbergst...@pathscale.com wrote: Do any of your patches fix these and if so which one(s)? Do you have reduced test cases or which test suite? Yes, the vast majority of the patches are about C++2003 conformance. C++VS - Perennial C++ Validation Suite (CPPVS) http://www.peren.com/pages/cppvs_set.htm Yes we do have reduced test cases for the violations, but we cannot publish them because Perennial CPPVS must be licensed. PathScale has a Perennial license and feel free to privately email which issues the patches specifically fix. Thanks
Re: STDCXX fork
On 06/27/11 01:17 AM, Stefan Teleman wrote: 2011/6/26 C. Bergströmcbergst...@pathscale.com: PathScale has a Perennial license and feel free to privately email which issues the patches specifically fix. Your false statements are annoying and unnecessary. Please don't avoid the question as I'm trying to help review your changes. Either publicly or privately email which patch fixes which Perennial test. (If in fact you've ran them at all)
Re: STDCXX fork
On 06/26/11 11:23 AM, Stefan Teleman wrote: On 2011/6/17 C. Bergströmcbergst...@pathscale.com wrote: I hope we can also take a look at the Solaris and Windows patches :) You can svn co all the stdcxx Solaris patches from here: http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/ The patches can be found in the Solaris/diffs/ directory. The shell script to apply the patches is Solaris/apply_patches.sh The patches are based on the stdcxx 4.2.1 release. Anonymous svn should work. If it doesn't work for you please let me know, it only means something is messed up. Some of the patches are very Solaris and/or Studio C++ specific (the sunpro.config patches, the GNUmakefile* patches and the patches for the Standard C Library forwarding header files (cstdio, cstdlib, cstring, clocale, etc ...). I will start submitting patches here (at Apache) soon. The last time we checked the patches they caused some boost regressions so please make sure to run the boost test suite. Our compiler runs on Solaris and which patches are platform, but not compiler specific? Thanks
Re: STDCXX fork
On 06/17/11 09:54 PM, Wojciech Meyer wrote: Hi all Hi, 1) better cmake build system (Actually this has nothing to do with Apache or the current build system.) 2) Faster code review, QA and easier contribution process (Only the last part is slowed down by Apache) 3) Actively maintained (To start just bug fixes, better support for Win/ARM/Solaris and performance improvements[2]. If we get enough interest we'll start on C++0x) We have some armcc porting patches against 5.2.1 (or trunk), would you be able to try to include them in your big merge? They are basically build system amendments to cross compile stdcxx with our compiler and make it work with our run time. Obviously if the build system is going to change, I would need to spend some time porting them to cmake (hopefully it will be straight forward), so let me know WDYT. Anything not build related please send me a pull request on. We have a cross compile build system for our compiler, but I'm not sure how easy it will be to pull that out just for STDCXX. When the engineer who owns this code is back from holiday we'll get it sorted out. I hope we can also take a look at the Solaris and Windows patches :) ./C
STDCXX fork
Hi all PathScale has been maintaining our internal branch of STDCXX for a while now and recently it's gone open source (along with a few other things[1]) Having it hosted at Apache seems to have created some barriers we're hoping to resolve. 1) better cmake build system (Actually this has nothing to do with Apache or the current build system.) 2) Faster code review, QA and easier contribution process (Only the last part is slowed down by Apache) 3) Actively maintained (To start just bug fixes, better support for Win/ARM/Solaris and performance improvements[2]. If we get enough interest we'll start on C++0x) Note: The cmake based build system isn't in the tree now and should merge mid/late next week. If you're interested https://github.com/pathscale/stdcxx/ If you have outstanding patches please clone and send a pull request. We're going to work hard to get all the backlog of stuff reviewed and integrated. ./C @CTOPathScale [1] http://www.pathscale.com/ekopath4-open-source-announcement [2] There's been a number of reported issues where just swapping out the STL between GNU and STDCXX resolves performance issues
Windows 2008 build/test host
Hi I've started an amazon ec2 instance for another project inside our company today. If anyone is interested to help set it up a scheduled task to run the STDCXX tests let me know. Best, ./C
Re: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
Wojciech Meyer wrote: Hi, We are trying to cross compile stdcxx library. The problem we are facing is that there is no way of telling stdcxx build system, that we don't want to run configuration files created by configuration step by build system directly on a host system (through a shell). For instance, this command (taken from log): ./UNISTD_DECL invoked during configuration process runs natively the executable through a shell. However we want to be able to run it on an emulator like this: path to our emulator UNISTD_DECL This command will run the UNISTD_DECL through an emulator. The patch we are proposing, is to introduce a new Makefile variable, called EXEC_RUNNER, which allows us to do it. EXEC_RUNNER defaults to /bin/sh -c. so it does not interfere with the rest of build process (at least on Unix/MSys/Cygwin environment, pure Win32 platform has completely separate build system). Patch is against `trunk'. We have ported stdcxx over to cmake and will likely be cross compiling. (mingw and other targets) When the work is more complete I'll ping you for early testing.
Re: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to run configuration executable files created by the build system during configuration step on emulators in order to cross compile the li
Wojciech Meyer wrote: C. Bergström wrote: We have ported stdcxx over to cmake and will likely be cross compiling. (mingw and other targets) When the work is more complete I'll ping you for early testing. Thanks. That's a good news. Please do a pull request on ML once it's working. BTW: We will have some more patches that you might be interested in, particularly related to `stdcxx vs no-posix stuff', please see this thread: http://www.mail-archive.com/dev@stdcxx.apache.org/msg01625.html It would be good to coordinate if you plan some massive changes on trunk, (the former patch applies to stdcxx-4.2.x line too). Yeah I'm tracking this list and most of the discussions.. We don't have a contributor agreement in place and so I'm not sure how much will get pushed to trunk yet. The cmake stuff is all new and shouldn't conflict with anything.. It'll mostly just make it *a lot* easier to build and test the project.. cmake + ctest is really awesome..
Re: C++0x support?
Martin Sebor wrote: On 06/04/2010 03:17 PM, C. Bergström wrote: Martin Sebor wrote: ... The biggest but possibly the only reason that occurs to me is portability. The target platform of libc++ is gcc/clang on Apple OS X. stdcxx on the other hand has been ported to dozens of compilers and operating systems and versions, and is easily portable to new ones (check out the nightly test matrix: http://stdcxx.apache.org/builds/4.2.x/). Maybe integrate with the suse build service to catch platforms that aren't in the test matrix currently.. I see SLE11 missing from the matrix and I know that's really important for us and some others.. FreeBSD 8 is broken.. etc Also is it really nightly? Generated Thu Aug 27 15:00:33 UTC 2009 ... It was (or in response to a commit) until Rogue Wave stopped running the builds a few months ago. We haven't yet found a replacement infrastructure. I'll work with you off list and happy if I can help.. I can cover lastest NetBSD, FreeBSD, OpenSolaris and various flavors of Linux.. (I'm reluctant for Mac and Win64, but tbd)
Re: C++0x support?
Stefan Teleman wrote: 2010/6/4 C. Bergström cbergst...@pathscale.com: Portability is interesting to us, but we're also very much interested in performance. So previous to the upcoming release we only supported Linux, but now we're looking to add OpenSolaris, FreeBSD, NetBSD, Mac and possibly other platforms as we have time to bring them up to production levels. I am pleased to report that the latest Express version of the Oracle Studio (nee Sun Studio) Compilers supports the Apache Standard C++ Library (4.2.1): Hi Stefan, Does that mean the suncc team will be helping to improve it? If neither please don't hijack threads. I removed maybe too much context from the email, but it was in reference to C++0x + OpenSolaris. (imho stdcxx support is a great thing in sun cc and it really should be the system default in place of libCrun..) ./C
Re: C++0x support?
Stefan Teleman wrote: 2010/6/4 C. Bergström cbergst...@pathscale.com: Hi Stefan, Does that mean the suncc team will be helping to improve it? If neither please don't hijack threads. I removed maybe too much context from the email, but it was in reference to C++0x + OpenSolaris. You should ask the compiler team directly what their plans are. I cannot speak for them. My email was in response to your statement about supporting C++0X in OpenSolaris with the Sun C++ compiler (which you have restated in this message). I never said Sun C++ compiler.. I in fact said PathScale.. (see below) I wonder how you plan on supporting C++0X in OpenSolaris with the Sun C++ compiler, when this compiler does not currently support *any* C++0X features, and support for these features will not be available for quite some time. And the compiler is not open source. So no, I am not hijacking threads. I am seeking some clarification with respect to your own statements. So in case you haven't read the thread 1) PathScale has a port to OpenSolaris 2) We are going to switch to stdcxx 3) We are interested in working on C++0x in stdcxx on the platforms we support I checked my email and I think you just assumed sun cc.. bye
