From: King I. <ngo...@gm...> - 2009-02-11 03:03:07
|
On Tue, Feb 10, 2009 at 4:39 PM, Matěj Týč <mat...@gm...> wrote: > > Perhaps we need more volunteers, who are > > willing to *commit* to the effort needed, to assist Aaron in > > progressing his development plans. > What about telling it to the world on the MinGW website? Like "we need > people who can do this and that" etc.? > Actually people who like to make websites could benefit MinGW a lot > since the web is quite chaotic and it is difficult to find useful and > up-to-date information there. > Turning the site into a spam-protected wiki would certainly help since > people could contribute super easily, hm? > Still 'someone' always has to make the first step :-) > > I can't help all that much in the respect of actual programming, but I would be willing to port over the mess that is the MinGW site to a protected wiki, if you guys would want me to. At one point, I did have a website, but it wasn't popular so I stopped buying hosting service for it a let it die. There really are only two things I am good at: Making websites and making packages/installers for software. I would be willing to help on either one of those :) |
From: Charles W. <cwi...@us...> - 2009-02-11 03:49:44
|
Weddington, Eric wrote: >Doug wrote: >> Well, I didn't really want to say too much here. Being a >> project lead of >> an open source project myself I know how hard it is to get >> volunteers to >> contribute. I also know how important it is to build >> relationships with >> the people in my community so that they feel their contributions are >> appreciated, including suggestions on how to improve things. >> Suggestions >> do at times lead to real contributions. I just fear that people are >> being driven away from contributing. And that's too bad. Well, I didn't mean to poor gasoline on this fire -- or to discourage Doug (http://cdtdoug.blogspot.com/2009/02/mingw-frustrations.html) -- but I had to call 'em as I saw 'em. Apparently the medical issues thing has been going around lately; I've been dealing with the same for almost a year now -- that's part of the explanation for the marked dropoff in my participation. The other is that I no longer use mingw/eclipse daily as part of my paying gig; so, less incentive to scratch any itches. But, to sum up my *personal opinion* on the state of mingw-gcc... > I thought this thread was started > with intent of just simply trying to find out the status of the gcc > 4.3.0 port. 1) There has been a recent flurry of activity on the main gcc lists, gearing up for the 4.4.0 release. This includes various build fixes and some runtime/regression fixes for both cygwin and mingw. 2) Most of these are driven by Danny (who is still active "over there", just not "over here"), Kai Teitz (who is mostly focused on 64bit issues) and by Dave Korn, the guy who maintains the cygwin gcc packages. (Dave is not a *gcc* maintainer for cygwin -- that is, unlike Danny he can't approve patches for gcc, but can only update gcc svn after receiving a "real gcc maintainer's" approval. However, he is cygwin's gcc package release manager, so he could apply custom patches to *cygwin's* gcc packages if he wanted to.) Aaron LaFramboise was responsible for a number of fixes that went into the to-be-4.4 gcc last summer and early fall, but has been silent since then. 3) A lot of the effort has been going into build fixes, getting shared runtime libraries built/working, and getting dwarf-2 exception handling working correctly. 4) Dave Korn's plan for going forward -- on cygwin -- is to ensure that 4.4.0 has reasonable behavior "upstream", and then hack 4.3.x with "custom" patches to make it build in such a way that we do not see ABI issues between his 4.3.x cygwin releases, and any eventual 4.4.x ones. For instance, gcc-HEAD (what will be 4.4.0 RSN) will build a libgcc DLL on cygwin named cyggcc_s-1.dll (dw2 eh) cyggcc_s-sjlj-1.dll (sjlj eh) but, at present, if you can get it to build a libgcc DLL at all, 4.3.x makes one named libgcc_s-1.dll (no matter what eh model) This is bad, for a number of reasons -- not least, it conflicts with mingw's libgcc_s-1.dll! So, Dave's to-be-released in-the-next-week-or-so gcc-4.3.x package for cygwin has some really ugly local patches so that it, too, will have cyggcc_s-1.dll (dw2 eh) cyggcc_s-sjlj-1.dll (sjlj eh) NOTE: gcc-HEAD, when built for mingw with shared libgcc, will create: libgcc_s-sjlj-1.dll (sjlj eh) libgcc_s-dw2-1.dll (dw2 eh) See note below concerning tdm versions. NOTE2: the current "official" mingw test release of 4.3.x of 20080502 vintage, is sjlj and includes libgcc_s_1.dll This will differ from the name of the sjlj runtime provided by 4.4.x releases. I'd recommend that, if a mingw 4.3.x package were put into official release, that it include "really ugly local patches" to make it behave like gcc-HEAD as far as the runtime DLL names are concerned. If the "ugly hack" from 3.4.5 is included -- then that's a different ABI and the DLL SO version -- if shared runtimes are even provided in that case -- should be bumped to -2 or something. According to Dave (http://cygwin.com/ml/cygwin-apps/2009-02/msg00045.html), on cygwin at least, gcc-4.3.x (with local cygwin patches), and gcc-4.4.x (more or less stock svn-HEAD), both /now/ work pretty well in either dw2 or sjlj varieties, assuming shared runtime libraries. (gcc, g++, gfortran, objc, objc++, java). Ada still has some issues, but Dave is confident he can get those kinks resolved in short order. I *think* the same is true for mingw versions, for lesser or greater amounts of "really ugly local patches". The thing is, unless you want to give your users a really nasty surprise, you have to worry A LOT about ABI compatibility issues (and DLL naming, for shared runtimes). 5) When used with static runtimes (which seems to be preferred by mingw users), there still exists a problem with throwing exceptions from a userland DLL and catching it in (an application or another DLL). This is unsolved. tdragon has a forward port of Danny's original (and disavowed) hack in 3.4.x -- but this means that the ABI of code compiled with tdragon's compiler and code compiled with stock gcc (or a future stock gcc that has "a real fix" for the issue) won't interoperate. If all client code is self-build using the same compiler (e.g. MinGWPorts, or just "do it the hard way") -- then this won't matter to you. Aaron was working on a plan to address this issue ("as discussed with KT and VR"??) but AFAICT nothing came of it. My advice: after sufficient discussion, the mingw project has three choices: a) "if you want working exception handling, use -shared-libgcc" b) Find Aaron, KT(?), and VR(?) and convince them to continue -- or at least publish -- their work/discussions/ideas about this, and git-er-done. c) Officially adopt Danny's disavowed patch as ported by tdragon, and accept that ABI as "the" ABI for mingw. Me, I'd lean towards (a) but mingw users seem allergic to distributing "extra" DLLs (c.f. whining about mingwm10.dll). Also, there will undoubtedly be issues with 27 different copies of libgcc_s-sjlj-1.dll floating around on the same system -- unless we are very careful about ABI compatibility. (Does libgcc suffer from the "you can't have more than one of me installed" problems that cygwin1.dll does? I don't think so --- but I'm not sure.) 6) PR24196 is an issue with C++ std::strings that can be solved in several ways: a) use shared libgcc and libstdc++ b) if using static runtimes, then configure using --enable-fully-dynamic-string. This is what tdragon's builds do. c) if using static runtimes, apply a patch similar to the one at the bugzilla entry: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 This is what cygwin's 3.4.5 builds do. I'm not sure about mingw-official 3.4.5. Note that (b) represents an ABI change from "stock" gcc. (c) preserves the library ABI, but it is unclear whether code copied by stock gcc and code compiled with a (c)-modified gcc can interoperate. 7) dw2 is faster, but leads to problems catching exceptions thrown across "foreign frames". That is, suppose you have a callback compiled using gcc, and you pass that callback to a w32api function -- as is common in GUI event-driven programming. Then, suppose that your callback throws an exception. The stack begins to unwind from your callback, into the w32api function. But THAT function -- compiled by Redmond presumably -- doesn't have the dw2 unwinding information. So, the unwinding data gets corrupted, and skips right past whatever 'catch' statement you expected to get control. Instead, the stack unwinds all the way up to main, and your program terminates with an unhandled excpetion error, and a Win32 popup ("This application has terminated in an unexpected manner...") This is bad. Again, Aaron spent MOST of his time during his google Summer of Code project attempting to address this issue, but: > A large amount of work was spent here, but there are hard problems > that need more work to resolve. I wrote a few prototype unwinders, > which I intended to submit, but they turned out to have problems that > I have not yet resolved. I will continue working on this issue. I don't know if anything ever came of this. Therefore, most mingw users would probably prefer the slower -- but more reliable for w32 gui/event-driven programming -- sjlj variant. 8) About tdragon's 4.3.0 releases. The current ones (4.3.2-based, released in december) -- do not contain shared runtime libraries at all. They rely on the 3.4.x hack for exception handling across DLL boundaries. However: > The TDM-2 release of GCC 4.3.0 incorporated experimental builds of > libgcc and libstdc++ as DLLs in order to allow exceptions to be > thrown out of DLLs. With the more recent releases this has been > dropped in favor of a ported version of 3.4.5's shared memory patch, > because of various problems encountered in the DLL versions. (Once > these problems are solved, the DLL versions will be included again.) > > Therefore, you no longer need to add any additional command-line > options to throw exceptions out of a DLL. You should, however, still > add "-mthreads" to the command line any time you throw exceptions in > a multi-threading context. > > The ported exceptions/DLLs patch is experimental and has only > received limited testing, so please report any bugs you encounter in > throwing exceptions that are not present in the official MinGW 3.4.5 > release. Some early tdm 4.3.0 versions (circa May/June 2008) -- which DID include shared runtimes -- included them under the names libgcc_tdm_1.dll (sjlj) libstdc++_tdm_1.dll (sjlj, c++) ... etc ... libgcc_tdm_dw2_1.dll (dw2) libstdc++_tdm_dw2_1.dll (dw2, c++) ... etc ... So, the good news there is (a) tdragon ensured that his dw2 and sjlj builds didn't "conflict" -- unlike stock 4.3.0 (when you teased it into building shared runtimes at all), and (b) tdragon's runtime DLLs won't conflict with future "stock" 4.4.x shared runtimes. But, as he said, these early runtime DLLs had some issues, and he eventually retired them in favor of porting Danny's "hack" from 3.4.5. Now, these May/June builds were done *before* many of Aaron's fixes went into SVN. Also, they were done long before Dave Korn's recent efforts at getting shared runtimes to work properly on cygwin. I believe -- but do not know -- that those fixes will also benefit mingw shared-runtime builds. All current 4.3.x tdm builds include this bug: > Classes with virtual inheritance (in the class itself or any ancestor > class), an inline constructor or destructor, and the "dllimport" > attribute will cause an ICE in maybe_emit_vtables. It is technically > incorrect for any function definition to be marked dllimport, so this > situation typically implies brittle code that should be fixed. See > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654>. But that has been fixed in gcc-svn-HEAD and gcc-svn-4.3. tdragon's builds do not provide java. ======================================= To sum up: IMO none of the test releases "out there" are quite ready for prime time -- or at least, not without discussion of some of the implications involved in their adoption, like de-facto ABI modifications and DLL naming conventions. P.S. I could also sum up the status of the MSYS environment, and categorize the "up to date"/"most recent" packages for a "complete" installation, but I'm afraid I'd digress into unbecoming blue language. So we'll save that for later. -- Chuck |
From: Earnie B. <ea...@us...> - 2009-02-11 12:36:52
|
Quoting Charles Wilson <cwi...@us...>: > My advice: after sufficient discussion, the mingw project has three choices: > a) "if you want working exception handling, use -shared-libgcc" > b) Find Aaron, KT(?), and VR(?) and convince them to continue -- > or at least publish -- their work/discussions/ideas about this, > and git-er-done. > c) Officially adopt Danny's disavowed patch as ported by tdragon, > and accept that ABI as "the" ABI for mingw. > Me, I'd lean towards (a) but mingw users seem allergic to distributing > "extra" DLLs (c.f. whining about mingwm10.dll). Also, there will My choice would be (a) as well. We'd end up with on package that distributes just the libgcc.dll and mingwm10.dll. Then the distributors can point users to that package if they don't want to carry the source for them. > undoubtedly be issues with 27 different copies of libgcc_s-sjlj-1.dll > floating around on the same system -- unless we are very careful about > ABI compatibility. (Does libgcc suffer from the "you can't have more > than one of me installed" problems that cygwin1.dll does? I don't think > so --- but I'm not sure.) > Libgcc.dll would suffer if it uses a hardcoded shared memory region name but I doubt that it does. I resolved executing more than one version of MSYS by using the path to the msys-1.0.dll to create a hash for the shared memory region name. Earnie |
From: Doug S. <dsc...@ro...> - 2009-02-11 07:30:44
|
Thanks Charles, A most excellent status on the state of mingw gcc. This is something I can plan with. And yes, I'm top posting. Get over it. Doug. Charles Wilson wrote: > Weddington, Eric wrote: > >> Doug wrote: >> >>> Well, I didn't really want to say too much here. Being a >>> project lead of >>> an open source project myself I know how hard it is to get >>> volunteers to >>> contribute. I also know how important it is to build >>> relationships with >>> the people in my community so that they feel their contributions are >>> appreciated, including suggestions on how to improve things. >>> Suggestions >>> do at times lead to real contributions. I just fear that people are >>> being driven away from contributing. And that's too bad. >>> > > Well, I didn't mean to poor gasoline on this fire -- or to discourage > Doug (http://cdtdoug.blogspot.com/2009/02/mingw-frustrations.html) -- > but I had to call 'em as I saw 'em. > > Apparently the medical issues thing has been going around lately; I've > been dealing with the same for almost a year now -- that's part of the > explanation for the marked dropoff in my participation. The other is > that I no longer use mingw/eclipse daily as part of my paying gig; so, > less incentive to scratch any itches. > > But, to sum up my *personal opinion* on the state of mingw-gcc... > > >> I thought this thread was started >> with intent of just simply trying to find out the status of the gcc >> 4.3.0 port. >> > > 1) There has been a recent flurry of activity on the main gcc lists, > gearing up for the 4.4.0 release. This includes various build fixes and > some runtime/regression fixes for both cygwin and mingw. > > 2) Most of these are driven by Danny (who is still active "over there", > just not "over here"), Kai Teitz (who is mostly focused on 64bit issues) > and by Dave Korn, the guy who maintains the cygwin gcc packages. (Dave > is not a *gcc* maintainer for cygwin -- that is, unlike Danny he can't > approve patches for gcc, but can only update gcc svn after receiving a > "real gcc maintainer's" approval. However, he is cygwin's gcc package > release manager, so he could apply custom patches to *cygwin's* gcc > packages if he wanted to.) Aaron LaFramboise was responsible for a > number of fixes that went into the to-be-4.4 gcc last summer and early > fall, but has been silent since then. > > 3) A lot of the effort has been going into build fixes, getting shared > runtime libraries built/working, and getting dwarf-2 exception handling > working correctly. > > 4) Dave Korn's plan for going forward -- on cygwin -- is to ensure that > 4.4.0 has reasonable behavior "upstream", and then hack 4.3.x with > "custom" patches to make it build in such a way that we do not see ABI > issues between his 4.3.x cygwin releases, and any eventual 4.4.x ones. > For instance, gcc-HEAD (what will be 4.4.0 RSN) will build a libgcc DLL > on cygwin named > cyggcc_s-1.dll (dw2 eh) > cyggcc_s-sjlj-1.dll (sjlj eh) > but, at present, if you can get it to build a libgcc DLL at all, 4.3.x > makes one named > libgcc_s-1.dll (no matter what eh model) > This is bad, for a number of reasons -- not least, it conflicts with > mingw's libgcc_s-1.dll! So, Dave's to-be-released > in-the-next-week-or-so gcc-4.3.x package for cygwin has some really ugly > local patches so that it, too, will have > cyggcc_s-1.dll (dw2 eh) > cyggcc_s-sjlj-1.dll (sjlj eh) > > NOTE: gcc-HEAD, when built for mingw with shared libgcc, will create: > libgcc_s-sjlj-1.dll (sjlj eh) > libgcc_s-dw2-1.dll (dw2 eh) > See note below concerning tdm versions. > > > NOTE2: the current "official" mingw test release of 4.3.x of 20080502 > vintage, is sjlj and includes > libgcc_s_1.dll > This will differ from the name of the sjlj runtime provided by 4.4.x > releases. > > I'd recommend that, if a mingw 4.3.x package were put into official > release, that it include "really ugly local patches" to make it behave > like gcc-HEAD as far as the runtime DLL names are concerned. If the > "ugly hack" from 3.4.5 is included -- then that's a different ABI and > the DLL SO version -- if shared runtimes are even provided in that case > -- should be bumped to -2 or something. > > According to Dave > (http://cygwin.com/ml/cygwin-apps/2009-02/msg00045.html), on cygwin at > least, gcc-4.3.x (with local cygwin patches), and gcc-4.4.x (more or > less stock svn-HEAD), both /now/ work pretty well in either dw2 or sjlj > varieties, assuming shared runtime libraries. (gcc, g++, gfortran, objc, > objc++, java). Ada still has some issues, but Dave is confident he can > get those kinks resolved in short order. > > I *think* the same is true for mingw versions, for lesser or greater > amounts of "really ugly local patches". The thing is, unless you want to > give your users a really nasty surprise, you have to worry A LOT about > ABI compatibility issues (and DLL naming, for shared runtimes). > > 5) When used with static runtimes (which seems to be preferred by mingw > users), there still exists a problem with throwing exceptions from a > userland DLL and catching it in (an application or another DLL). This is > unsolved. tdragon has a forward port of Danny's original (and disavowed) > hack in 3.4.x -- but this means that the ABI of code compiled with > tdragon's compiler and code compiled with stock gcc (or a future stock > gcc that has "a real fix" for the issue) won't interoperate. If all > client code is self-build using the same compiler (e.g. MinGWPorts, or > just "do it the hard way") -- then this won't matter to you. Aaron was > working on a plan to address this issue ("as discussed with KT and > VR"??) but AFAICT nothing came of it. > > My advice: after sufficient discussion, the mingw project has three choices: > a) "if you want working exception handling, use -shared-libgcc" > b) Find Aaron, KT(?), and VR(?) and convince them to continue -- > or at least publish -- their work/discussions/ideas about this, > and git-er-done. > c) Officially adopt Danny's disavowed patch as ported by tdragon, > and accept that ABI as "the" ABI for mingw. > Me, I'd lean towards (a) but mingw users seem allergic to distributing > "extra" DLLs (c.f. whining about mingwm10.dll). Also, there will > undoubtedly be issues with 27 different copies of libgcc_s-sjlj-1.dll > floating around on the same system -- unless we are very careful about > ABI compatibility. (Does libgcc suffer from the "you can't have more > than one of me installed" problems that cygwin1.dll does? I don't think > so --- but I'm not sure.) > > 6) PR24196 is an issue with C++ std::strings that can be solved in > several ways: > a) use shared libgcc and libstdc++ > b) if using static runtimes, then configure using > --enable-fully-dynamic-string. This is what tdragon's builds do. > c) if using static runtimes, apply a patch similar to the one at the > bugzilla entry: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 > This is what cygwin's 3.4.5 builds do. > > I'm not sure about mingw-official 3.4.5. Note that (b) represents an > ABI change from "stock" gcc. (c) preserves the library ABI, but it is > unclear whether code copied by stock gcc and code compiled with a > (c)-modified gcc can interoperate. > > 7) dw2 is faster, but leads to problems catching exceptions thrown > across "foreign frames". That is, suppose you have a callback compiled > using gcc, and you pass that callback to a w32api function -- as is > common in GUI event-driven programming. Then, suppose that your > callback throws an exception. The stack begins to unwind from your > callback, into the w32api function. But THAT function -- compiled by > Redmond presumably -- doesn't have the dw2 unwinding information. So, > the unwinding data gets corrupted, and skips right past whatever 'catch' > statement you expected to get control. Instead, the stack unwinds all > the way up to main, and your program terminates with an unhandled > excpetion error, and a Win32 popup ("This application has terminated in > an unexpected manner...") > > This is bad. > > Again, Aaron spent MOST of his time during his google Summer of Code > project attempting to address this issue, but: > >> A large amount of work was spent here, but there are hard problems >> that need more work to resolve. I wrote a few prototype unwinders, >> which I intended to submit, but they turned out to have problems that >> I have not yet resolved. I will continue working on this issue. >> > I don't know if anything ever came of this. > > Therefore, most mingw users would probably prefer the slower -- but more > reliable for w32 gui/event-driven programming -- sjlj variant. > > 8) About tdragon's 4.3.0 releases. The current ones (4.3.2-based, > released in december) -- do not contain shared runtime libraries at all. > They rely on the 3.4.x hack for exception handling across DLL > boundaries. However: > >> The TDM-2 release of GCC 4.3.0 incorporated experimental builds of >> libgcc and libstdc++ as DLLs in order to allow exceptions to be >> thrown out of DLLs. With the more recent releases this has been >> dropped in favor of a ported version of 3.4.5's shared memory patch, >> because of various problems encountered in the DLL versions. (Once >> these problems are solved, the DLL versions will be included again.) >> >> Therefore, you no longer need to add any additional command-line >> options to throw exceptions out of a DLL. You should, however, still >> add "-mthreads" to the command line any time you throw exceptions in >> a multi-threading context. >> >> The ported exceptions/DLLs patch is experimental and has only >> received limited testing, so please report any bugs you encounter in >> throwing exceptions that are not present in the official MinGW 3.4.5 >> release. >> > Some early tdm 4.3.0 versions (circa May/June 2008) -- which DID include > shared runtimes -- included them under the names > libgcc_tdm_1.dll (sjlj) > libstdc++_tdm_1.dll (sjlj, c++) > ... etc ... > libgcc_tdm_dw2_1.dll (dw2) > libstdc++_tdm_dw2_1.dll (dw2, c++) > ... etc ... > So, the good news there is (a) tdragon ensured that his dw2 and sjlj > builds didn't "conflict" -- unlike stock 4.3.0 (when you teased it into > building shared runtimes at all), and (b) tdragon's runtime DLLs won't > conflict with future "stock" 4.4.x shared runtimes. But, as he said, > these early runtime DLLs had some issues, and he eventually retired them > in favor of porting Danny's "hack" from 3.4.5. > > Now, these May/June builds were done *before* many of Aaron's fixes went > into SVN. Also, they were done long before Dave Korn's recent efforts > at getting shared runtimes to work properly on cygwin. I believe -- but > do not know -- that those fixes will also benefit mingw shared-runtime > builds. > > All current 4.3.x tdm builds include this bug: > >> Classes with virtual inheritance (in the class itself or any ancestor >> class), an inline constructor or destructor, and the "dllimport" >> attribute will cause an ICE in maybe_emit_vtables. It is technically >> incorrect for any function definition to be marked dllimport, so this >> situation typically implies brittle code that should be fixed. See >> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654>. >> > But that has been fixed in gcc-svn-HEAD and gcc-svn-4.3. > > tdragon's builds do not provide java. > > ======================================= > > To sum up: IMO none of the test releases "out there" are quite ready for > prime time -- or at least, not without discussion of some of the > implications involved in their adoption, like de-facto ABI modifications > and DLL naming conventions. > > P.S. I could also sum up the status of the MSYS environment, and > categorize the "up to date"/"most recent" packages for a "complete" > installation, but I'm afraid I'd digress into unbecoming blue language. > So we'll save that for later. > > -- > Chuck > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > _______________________________________________ > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. > > Most annoying abuses are: > 1) Top posting > 2) HTML/MIME encoded mail > 3) Improper quoting > 4) Improper trimming > > |
From: Earnie B. <ea...@us...> - 2009-02-11 12:42:05
|
Quoting Doug Schaefer <dsc...@ro...>: > > And yes, I'm top posting. Get over it. > Attitude like this will most definitely get you moderated. The moderators tend to frown on extra work and your postings will either reside in queue for days or simply just be deleted. You could have simply trimmed the entire post. Earnie, One of the list moderators |
From: Earnie B. <ea...@us...> - 2009-02-11 13:04:39
|
Quoting Mat?j Tý? <mat...@gm...>: >> Perhaps we need more volunteers, who are >> willing to *commit* to the effort needed, to assist Aaron in >> progressing his development plans. > What about telling it to the world on the MinGW website? Like "we need > people who can do this and that" etc.? Because my experience with doing this tends to be a waste of my time. There tends to be better conveyance with flames like this on the matter. > Actually people who like to make websites could benefit MinGW a lot > since the web is quite chaotic and it is difficult to find useful and > up-to-date information there. > Turning the site into a spam-protected wiki would certainly help since > people could contribute super easily, hm? > Still 'someone' always has to make the first step :-) Our current website could be SPAM free if SF allowed communicating to the mail protocols from the Web server. I have thought sporadically of moving the website to a hosting service. Let me see where Mumit is on moving ownership of mingw.org to me. More later. Earnie |
From: Matěj T. <mat...@gm...> - 2009-02-12 10:05:11
|
>> What about telling it to the world on the MinGW website? Like "we need >> people who can do this and that" etc.? > > Because my experience with doing this tends to be a waste of my time. > There tends to be better conveyance with flames like this on the matter. Come on, you have to inspire people. If you manage to inspire 1%, it does not seem to be much, but it is more than enough. Actually King InuYasha has proposed some help, so what's wrong since noone has replied to him? |
From: Earnie B. <ea...@us...> - 2009-02-12 12:26:27
|
Quoting Mat?j Tý? <mat...@gm...>: > Actually King InuYasha has proposed some help, so what's wrong since > noone has replied to him? > You don't know if noone (sic) has replied to him. I personally did. I made it a private matter. Earnie |