Re: [Mingw-w64-public] [ANN] Website changes

[Adrien Nader]

(catching up with my mails LIFO-style, the best way to cause huge
delays)

On Wed, Mar 25, 2015, Ruben Van Boxem wrote:
> 2015-03-24 21:20 GMT+01:00 Adrien Nader :
> 
> > Hi,
> >
> > On Tue, Mar 24, 2015, David Macek wrote:
> > > On 20. 3. 2015 22:51, Adrien Nader wrote:
> > > > Hi,
> > > >
> > > > I've just pushed a redirect from http://mingw-w64.sourceforge.net to
> > > > http://mingw-w64.yaxm.org in order to serve a new website.
> > > >
> > > > [snip]
> > > >
> > > > Any constructive criticism is welcome; don't hesitate.
> > >
> > > Hi. I took a look on the website and I've got some notes which may or
> > may not be applicable to other visitors:
> > >
> > > === Downloads/Others:
> > >
> > > The first paragraph in the tab talks about OS X builds straight away, as
> > if Others == OSX. This also led to an impression that Rubenv's builds are
> > also for OS X. Also most of the contents of the tab seems to belong to
> > other tabs. I imagine that if a visitor was interested only in toolchains
> > for Windows, he/she could be led to believe that the three options in the
> > first tab were the only one, because he/she would never even look at the
> > Others tab and discovered the link to SF.net file repository.
> > >
> > > The following organisation would make more sense to me: I propose 1)
> > moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE
> > to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or
> > completely outside of them), and 4) renaming the tab from Other to OS X. I
> > don't think moving these mentions from the Others tab to the other tabs
> > will confuse users as to which one to download, as the gray boxes with
> > logos serve well to make their contents seem as more trust-worthy than the
> > plain text around.
> >
> > The "Others" tab has not received much love and that dates back to the
> > creation of the download page on the previous website.
> > When I put rubenvb and opensuse toolchains back when I created the
> > download page (it's been some time already), the reactions I had
> > received from both upstreams were at best "meh" and without many more
> > details so I couldn't do a lot. I really wanted to put them somewhere
> > though (I think Opensuse's effort started at least 7 years ago and
> > rubenvb toolchains were widespread). Ideally they'd be in a proper
> > place: the "others" section would ideally only contain the link to
> > Sourceforge's FRS. That requires the corresponding toolchain creator to
> > provide information about their releases.
> >
> 
> I think I sent you an email with the required info as you asked for way
> back when. If I didn't, my fault, but I'm not too worried about my
> toolchains. They are dated now and should really be retired from the
> download page.

I don't remember receiving such a mail. Since that was already a fairly
long time ago, I don't remember well but maybe you had sent some infos
but not enough details which was probably quite a lot of work
considering the diversity of your toolchains.

> >
> > Following Vincent Torri's mail, I did some changes this morning and I
> > just noticed I had not done these changes for every block but only for
> > the ones that fell under Windows and Linux tabs. I've now corrected it.
> > Basically I've removed title elements and added blue-colored blocks
> > instead. They should make it easier to tell each block apart. Can you
> > check the page again and tell me if it looks better?
> >
> > Also, the OS X situation currently is not very good as there is
> > toolchain provider and the toolchains that are available are old,
> > experimental and unsupported. I'm not worrying about it at the moment
> > since it should change soon (more on that later on).
> >
> > > === Downloads/Source:
> > >
> > > This may be just my profession talking, but links to various stuff on
> > SF.net with "SourceForge" as the title seem misleading.
> > >
> > > === Downloads/Linux:
> > >
> > > I know Arch Linux users are generally competent, but I'd like to see the
> > link point to something actually related to mingw-w64, rather than just to
> > AUR homepage. This may be a good link: <
> > https://aur.archlinux.org/packages/?SeB=n&K=mingw-w64&SB=c&PP=250>
> >
> > I'm not an Arch Linux user and the link in place was the only one I had.
> > I've updated the page, thanks.
> >
> > > Also, wouldn't it be better to also mention the packages in official
> > Arch repos?  They don't
> > seem outdated or anything.
> >
> > I wasn't aware of these packages (maybe they're newer than the
> > arch-linux-related update). I'm not sure how they relate to AUR ones;
> > I'm under the impression the toolchain is in the base and non-toolchain
> > packages should be built from AUR but I need a confirmation from at
> > least one actual user.
> >
> 
> I can confirm whatever you need: I made the original AUR packages, these
> were absorbed into the binary [Community] repository

Re: [Mingw-w64-public] printf speedup [PATCH]

[Kai Tietz]

Hi Mattias,

patch is ok.  I am still a bit curious to learn about that high delay
caused by getenv ().

Kai

2015-04-01 5:35 GMT+02:00 Dongsheng Song :
> Hi Mattias,
>
> Could you share your micro benchmark data ?
>
> In my testing, getenv() is very fast.
>
> *) unset PRINTF_EXPONENT_DIGITS
>
> preheat 1 times, then perform 100 times (use 4.6 seconds)
> getenv cost: 4.6 us
>
> *) set PRINTF_EXPONENT_DIGITS=3
> preheat 1 times, then perform 100 times (use 3.41991 seconds)
> getenv: 3.41991 us
>
> My CPU is Core2 E6550 at 2.33 GHz.
>
> On Wed, Apr 1, 2015 at 10:26 AM, Dongsheng Song 
> wrote:
>>
>> Cache getenv() looks a good idea !
>> Patch is OK for me.
>>
>> On Wed, Apr 1, 2015 at 4:16 AM, Mattias Engdegård 
>> wrote:
>>>
>>> The functions in the __mingw_printf family are very slow because of the
>>> getenv("PRINTF_EXPONENT_DIGITS") call that is made every time, even when
>>> that information isn't actually needed.
>>>
>>> Please consider this patch. It only calls getenv once, caching the result
>>> (as is traditionally done in libraries that use environment variables this
>>> way). It also only computes the minimum exponent digits when actually
>>> needed, at most once per format call.
>>>
>>> With this patch, __mingw_sprintf(buf, "x") goes from being several orders
>>> of magnitude slower than the MSVCRT sprintf, to about 66% faster. You don't
>>> see this kind of improvement every day.
>>
>>
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Kai Tietz]

Hi Adrien,

yes, I think we should separate between pure toolchain and
environment.  Eg msys2, cygwin etc. are first hand environments, but
of course each of them provides at least one toolchain package.  So if
we want to provide lists of additional packages available for a
specific environment, we should put that into a separate page.  Not
sure if it should be a separate page for each, or if it is of interest
to collect them all on one page.  Later could allow to make tables
comparing features ... not sure if this is worth the effort.

Cheers,
Kai

2015-04-01 9:16 GMT+02:00 Adrien Nader :
> (catching up with my mails LIFO-style, the best way to cause huge
> delays)
>
> On Wed, Mar 25, 2015, Ruben Van Boxem wrote:
>> 2015-03-24 21:20 GMT+01:00 Adrien Nader :
>>
>> > Hi,
>> >
>> > On Tue, Mar 24, 2015, David Macek wrote:
>> > > On 20. 3. 2015 22:51, Adrien Nader wrote:
>> > > > Hi,
>> > > >
>> > > > I've just pushed a redirect from http://mingw-w64.sourceforge.net to
>> > > > http://mingw-w64.yaxm.org in order to serve a new website.
>> > > >
>> > > > [snip]
>> > > >
>> > > > Any constructive criticism is welcome; don't hesitate.
>> > >
>> > > Hi. I took a look on the website and I've got some notes which may or
>> > may not be applicable to other visitors:
>> > >
>> > > === Downloads/Others:
>> > >
>> > > The first paragraph in the tab talks about OS X builds straight away, as
>> > if Others == OSX. This also led to an impression that Rubenv's builds are
>> > also for OS X. Also most of the contents of the tab seems to belong to
>> > other tabs. I imagine that if a visitor was interested only in toolchains
>> > for Windows, he/she could be led to believe that the three options in the
>> > first tab were the only one, because he/she would never even look at the
>> > Others tab and discovered the link to SF.net file repository.
>> > >
>> > > The following organisation would make more sense to me: I propose 1)
>> > moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE
>> > to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or
>> > completely outside of them), and 4) renaming the tab from Other to OS X. I
>> > don't think moving these mentions from the Others tab to the other tabs
>> > will confuse users as to which one to download, as the gray boxes with
>> > logos serve well to make their contents seem as more trust-worthy than the
>> > plain text around.
>> >
>> > The "Others" tab has not received much love and that dates back to the
>> > creation of the download page on the previous website.
>> > When I put rubenvb and opensuse toolchains back when I created the
>> > download page (it's been some time already), the reactions I had
>> > received from both upstreams were at best "meh" and without many more
>> > details so I couldn't do a lot. I really wanted to put them somewhere
>> > though (I think Opensuse's effort started at least 7 years ago and
>> > rubenvb toolchains were widespread). Ideally they'd be in a proper
>> > place: the "others" section would ideally only contain the link to
>> > Sourceforge's FRS. That requires the corresponding toolchain creator to
>> > provide information about their releases.
>> >
>>
>> I think I sent you an email with the required info as you asked for way
>> back when. If I didn't, my fault, but I'm not too worried about my
>> toolchains. They are dated now and should really be retired from the
>> download page.
>
> I don't remember receiving such a mail. Since that was already a fairly
> long time ago, I don't remember well but maybe you had sent some infos
> but not enough details which was probably quite a lot of work
> considering the diversity of your toolchains.
>
>> >
>> > Following Vincent Torri's mail, I did some changes this morning and I
>> > just noticed I had not done these changes for every block but only for
>> > the ones that fell under Windows and Linux tabs. I've now corrected it.
>> > Basically I've removed title elements and added blue-colored blocks
>> > instead. They should make it easier to tell each block apart. Can you
>> > check the page again and tell me if it looks better?
>> >
>> > Also, the OS X situation currently is not very good as there is
>> > toolchain provider and the toolchains that are available are old,
>> > experimental and unsupported. I'm not worrying about it at the moment
>> > since it should change soon (more on that later on).
>> >
>> > > === Downloads/Source:
>> > >
>> > > This may be just my profession talking, but links to various stuff on
>> > SF.net with "SourceForge" as the title seem misleading.
>> > >
>> > > === Downloads/Linux:
>> > >
>> > > I know Arch Linux users are generally competent, but I'd like to see the
>> > link point to something actually related to mingw-w64, rather than just to
>> > AUR homepage. This may be a good link: <
>> > https://aur.archlinux.org/packages/?SeB=n&K=mingw-w64&SB=c&PP=250>
>> >
>> > I'm not an Arch Linux user and the link in place was the on

Re: [Mingw-w64-public] printf speedup [PATCH]

[Mattias Engdegård]

> patch is ok.  I am still a bit curious to learn about that high delay
> caused by getenv ().

It was a while since I dissected it, but I believe getenv takes a lock. This 
hurts multithreaded programs in particular. Even without a lock, getenv still 
needs to do a linear string search through the entire environment (because it 
typically fails).


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf speedup [PATCH]

[Mattias Engdegård]

1 apr 2015 kl. 05.35 skrev Dongsheng Song :

> In my testing, getenv() is very fast.
> 
> *) unset PRINTF_EXPONENT_DIGITS
> 
> preheat 1 times, then perform 100 times (use 4.6 seconds)
> getenv cost: 4.6 us
> 
> *) set PRINTF_EXPONENT_DIGITS=3
> preheat 1 times, then perform 100 times (use 3.41991 seconds)
> getenv: 3.41991 us

4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic library 
function such as sprintf.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf speedup [PATCH]

[Martin Mitáš]

Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
> 1 apr 2015 kl. 05.35 skrev Dongsheng Song :
> 
>> In my testing, getenv() is very fast.
>>
>> *) unset PRINTF_EXPONENT_DIGITS
>>
>> preheat 1 times, then perform 100 times (use 4.6 seconds)
>> getenv cost: 4.6 us
>>
>> *) set PRINTF_EXPONENT_DIGITS=3
>> preheat 1 times, then perform 100 times (use 3.41991 seconds)
>> getenv: 3.41991 us
> 
> 4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic 
> library function such as sprintf.

If I assume getenv() iterates over complete environment in most cases (when
PRINTF_EXPONENT_DIGITS is not set), then there is probably much worse overhead 
in a real world programs which is not likely covered in a trivial test program.

The function getenv() shall replace data in CPU cache, which are likely useful
for the ongoing program computation, with a lot of junk (the complete process
environment).

Morous

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] printf speedup [PATCH]

[Dongsheng Song]

On Wed, Apr 1, 2015 at 4:33 PM, Martin Mitáš  wrote:

>
>
> Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
> > 1 apr 2015 kl. 05.35 skrev Dongsheng Song :
> >
> >> In my testing, getenv() is very fast.
> >>
> >> *) unset PRINTF_EXPONENT_DIGITS
> >>
> >> preheat 1 times, then perform 100 times (use 4.6 seconds)
> >> getenv cost: 4.6 us
> >>
> >> *) set PRINTF_EXPONENT_DIGITS=3
> >> preheat 1 times, then perform 100 times (use 3.41991 seconds)
> >> getenv: 3.41991 us
> >
> > 4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic
> library function such as sprintf.
>
> If I assume getenv() iterates over complete environment in most cases (when
> PRINTF_EXPONENT_DIGITS is not set), then there is probably much worse
> overhead
> in a real world programs which is not likely covered in a trivial test
> program.
>
> The function getenv() shall replace data in CPU cache, which are likely
> useful
> for the ongoing program computation, with a lot of junk (the complete
> process
> environment).
>
> Morous
>

I'm certainly not opposed your patch, but a bit curious why getenv() slow
your program. we can always simplify a real world program to a test program
to discourse the performance issue.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Jason Curl]

On 30/03/2015 22:03, Adrien Nader wrote:
>> Hi, on the page: http://mingw-w64.yaxm.org/doku.php/documentation
>> the link to "libmangle" is broken. Clicking on it takes me here:
>> http://mingw-w64.yaxm.orglibmangle/
> Thanks for the notice. This was due to an overly simple rewrite rule.
> Libmangle's API documentation is still on sourceforge servers.
> Note that since the redirects use the HTTP 301 code, your browser is
> going to be a bit reticent to asking the server again for the actual
> location of the page (i.e. clear your cache).
>
The link to libmangle now works.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] static libgcc in multiple shared libraries

[Greg Jung]

My 2c, which is not authoritative but perhaps can throw a few more
topics into the mix.
First remember this: there are compiler-specific versions of
libstdc++, incompatible but nevertheless named the same,  dependent
upon the exception method deployed by the compiler.
AFAIK the only way to force a user to find only the (shared lib)
version of libstdc++ you designate is to include this where the .exe
resides and to run the program from that directory (since you can't
count on the path being set).

If a program is linked with static libgcc, again AFAIK, libgcc is a
dead end and doesn't need more support except what is commonly
available, i.e. in windows/system32/...  So a library built in the
same manner
will be using its own copies of libgcc routines and all of the names
have been stripped, so there would be no clashes.  If one of the libs
used shared libgcc thats ok too, and libstd++ will use that instead of
loading its own.


On Tue, Mar 31, 2015 at 7:02 AM, Cosmin Apreutesei
 wrote:
> Hi,
>
> I'm looking for the best way to distribute binaries for a main exe and
> several C and C++ plugins separately and I have a few questions about
> linking libgcc and libstdc++.
>
> Currently, the main exe (a C program) is linked with static-libgcc.
> Several C libraries that are loaded via LoadLibrary() are linked with
> static-libgcc too.
>
> Is this setup supported? I.e. does libgcc have initialization or
> shared globals that require it to be always linked dynamically or am I
> ok to link it statically into multiple shared libraries like that?
>
> What happens if I also load a C++ library next? A C++ library will
> pull in libstdc++ which will pull in a shared libgcc. Am I still on
> solid ground here? Basically now I have libgcc statically linked into
> the main exe _and_ dynamically linked from libstdc++.
>
> Good or no good?
>
> Thank you,
> Cosmin.
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] static libgcc in multiple shared libraries

[Yaron Keren]

Hi,

Having different libgcc copies used from different parts of your program
may be a big problem or not, depending upon how it is used in your program.
Different libgccs do not share data, so C++ exceptions will not work
between different libgccs. Your C program may not care for exceptions but
dynamically allocated memory and other libgcc-stored data also can't be
passed around. This can lead to nasty random bugs, for instance with one
libgcc allocating memory and the other freeing it. If you are sure none of
this happening you can have different libgccs linked around, but why?

As Greg wrote, if you have more than single executable, the EXE and DLLs
should dynamically link libgcc and place all required DLLs in the same
directory the EXE is in. That's the first location Windows will look for
the DLLs, see


https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

under "Standard Search Order for Desktop Applications".

Yaron



2015-04-02 1:16 GMT+03:00 Greg Jung :

> My 2c, which is not authoritative but perhaps can throw a few more
> topics into the mix.
> First remember this: there are compiler-specific versions of
> libstdc++, incompatible but nevertheless named the same,  dependent
> upon the exception method deployed by the compiler.
> AFAIK the only way to force a user to find only the (shared lib)
> version of libstdc++ you designate is to include this where the .exe
> resides and to run the program from that directory (since you can't
> count on the path being set).
>
> If a program is linked with static libgcc, again AFAIK, libgcc is a
> dead end and doesn't need more support except what is commonly
> available, i.e. in windows/system32/...  So a library built in the
> same manner
> will be using its own copies of libgcc routines and all of the names
> have been stripped, so there would be no clashes.  If one of the libs
> used shared libgcc thats ok too, and libstd++ will use that instead of
> loading its own.
>
>
> On Tue, Mar 31, 2015 at 7:02 AM, Cosmin Apreutesei
>  wrote:
> > Hi,
> >
> > I'm looking for the best way to distribute binaries for a main exe and
> > several C and C++ plugins separately and I have a few questions about
> > linking libgcc and libstdc++.
> >
> > Currently, the main exe (a C program) is linked with static-libgcc.
> > Several C libraries that are loaded via LoadLibrary() are linked with
> > static-libgcc too.
> >
> > Is this setup supported? I.e. does libgcc have initialization or
> > shared globals that require it to be always linked dynamically or am I
> > ok to link it statically into multiple shared libraries like that?
> >
> > What happens if I also load a C++ library next? A C++ library will
> > pull in libstdc++ which will pull in a shared libgcc. Am I still on
> > solid ground here? Basically now I have libgcc statically linked into
> > the main exe _and_ dynamically linked from libstdc++.
> >
> > Good or no good?
> >
> > Thank you,
> > Cosmin.
> >
> >
> --
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public