Brian,
Yes, I install everything. Cygwin has so many great utilities.
I'd like to change this to remove Gnome and KDE, and run updates from
the command line with setup-x86.exe, ignoring downloading or updating
Gnome and KDE.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 2018-01-12 13:23, Houder wrote:
> On Fri, 12 Jan 2018 12:33:46, Keith Christian wrote:
>> I run the 32 bit Cygwin on a 64 bit Windows 7 machine and install
>> everything, because it has been unnecessary to waste time picking and
>> choosing packages even though I don't use them all. I've been d
Greetings, Brian Inglis!
> On 2018-01-11 14:27, Marco Atzeri wrote:
>> On 11/01/2018 21:39, Brian Inglis wrote:
>>> On 2018-01-07 07:35, Marco Atzeri wrote:
Version 1.8.20-1 of
>>> Copied to Cygwin as announcement did not make it onto that list.
>> the archive shows it.
>> https://cygwin.com/
On 1/12/2018 3:41 PM, Corinna Vinschen wrote:
> On Jan 12 14:59, cyg Simple wrote:
>> On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
>>> On Jan 12 15:06, Christian Franke wrote:
Timing [cm]alloc() calls without actually using the allocated memory might
produce misleading results due to laz
On 1/12/2018 9:06 AM, Christian Franke wrote:
This variant of the above code adds one write access to each 4KiB page (guarded by "volatile" to
prevent dead assignment optimization):
#include
#include
#define ALLOCATION_SIZE (100 * 1024 * 1024)
int main (int argc, char *argv[]) {
for (in
See my post in the other "Re: Future of 32-bit distro" thread about
using setup-x86.exe to remove KDE and GNOME.
Keith
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On Jan 12 14:59, cyg Simple wrote:
> On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
> > On Jan 12 15:06, Christian Franke wrote:
> >> Timing [cm]alloc() calls without actually using the allocated memory might
> >> produce misleading results due to lazy page allocation and/or zero-filling.
> >>
> >>
> On Jan 12, 2018, at 12:11 PM, Yaakov Selkowitz wrote:
>
> On 2018-01-12 03:13, Corinna Vinschen wrote:
>> On Jan 11 22:52, Denis Excoffier wrote:
>>> The full list contains 8006 lines, i have the complete Cygwin 32bit
>>> installation
>>
>> The bottom line of this is, and it has been said befo
On 1/12/2018 2:59 PM, cyg Simple wrote:
> On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
>> On Jan 12 15:06, Christian Franke wrote:
>>> Lee wrote:
Why is the cygwin gcc calloc so much slower than the
i686-w64-mingw32-gcc calloc?
1:12 vs 0:11
$cat calloc-test.c
#incl
Yaakov,
I find that your mail to cygwin-announce has no Message-Id header. Can
that be fixed to aid the threading of the messages?
TIA,
--
cyg Simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com
On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
> On Jan 12 15:06, Christian Franke wrote:
>> Lee wrote:
>>> Why is the cygwin gcc calloc so much slower than the
>>> i686-w64-mingw32-gcc calloc?
>>>1:12 vs 0:11
>>>
>>> $cat calloc-test.c
>>> #include
>>> #include
>>> #define ALLOCATION_SIZE (10
On Fri, 12 Jan 2018 12:02:18, Brian Inglis wrote:
When the 32 bit toolchain is available under x86_64 for cross builds and
testing
this doesnt make sense. at least with Mingw-w64, this is already the case:
- mingw64-x86_64-gcc-core: 64-bit tools for building 64-bit EXEs
- mingw64-i686-gcc-core
I run the 32 bit Cygwin on a 64 bit Windows 7 machine and install
everything, because it has been unnecessary to waste time picking and
choosing packages even though I don't use them all. I've been doing
this for years and suspect many other Cygwin aficionados do the same.
I asked a related quest
On 2018-01-12 11:11, Yaakov Selkowitz wrote:
> On 2018-01-12 03:13, Corinna Vinschen wrote:
>> On Jan 11 22:52, Denis Excoffier wrote:
>>> The full list contains 8006 lines, i have the complete Cygwin 32bit
>>> installation
>>
>> The bottom line of this is, and it has been said before and I can't
On 2018-01-12 03:13, Corinna Vinschen wrote:
> On Jan 11 22:52, Denis Excoffier wrote:
>> The full list contains 8006 lines, i have the complete Cygwin 32bit
>> installation
>
> The bottom line of this is, and it has been said before and I can't
> stress this enough, we can't support this scenari
On 01/11/2018 01:32 PM, Christian Franke wrote:
> After 4.4.3-1 upgrade, rebase always fails on 32- and 64-bit Cygwin:
>
> $ rebase -s -T /var/cache/rebase/rebase_all
> rebase: Too many DLLs for available address space: Cannot allocate memory
Confirmed, I suddenly had the same issue.
> A downgra
On Jan 12 15:06, Christian Franke wrote:
> Lee wrote:
> > Why is the cygwin gcc calloc so much slower than the
> > i686-w64-mingw32-gcc calloc?
> >1:12 vs 0:11
> >
> > $cat calloc-test.c
> > #include
> > #include
> > #define ALLOCATION_SIZE (100 * 1024 * 1024)
> > int main (int argc, char *a
Lee wrote:
Why is the cygwin gcc calloc so much slower than the
i686-w64-mingw32-gcc calloc?
1:12 vs 0:11
$cat calloc-test.c
#include
#include
#define ALLOCATION_SIZE (100 * 1024 * 1024)
int main (int argc, char *argv[]) {
for (int i = 0; i < 1; i++) {
void *temp = calloc(
Hi folks,
I have updated the version of rebase to 4.4.4-1.
This release fixes the problem introduced in 4.4.3. It also
adds a check for a lower DLL rebase limit on x86 (0x100) as
well as x86_64 (0x2).
This means on 32 bit x86 only a subset of DLLs of the entire
distribution can coex
On 1/12/18, Marco Atzeri wrote:
> On 12/01/2018 08:19, Lee wrote:
>> Why is the cygwin gcc calloc so much slower than the
>> i686-w64-mingw32-gcc calloc?
>>1:12 vs 0:11
>>
>> $cat calloc-test.c
>> #include
>> #include
>> #define ALLOCATION_SIZE (100 * 1024 * 1024)
>> int main (int argc, char
On Jan 11 22:52, Denis Excoffier wrote:
> > On 2018-01-11 13:32, Christian Franke wrote:
> >
> > After 4.4.3-1 upgrade, rebase always fails on 32- and 64-bit Cygwin:
> >
> > $ rebase -s -T /var/cache/rebase/rebase_all
> > rebase: Too many DLLs for available address space: Cannot allocate memory
>
On 12/01/2018 08:19, Lee wrote:
Why is the cygwin gcc calloc so much slower than the
i686-w64-mingw32-gcc calloc?
1:12 vs 0:11
$cat calloc-test.c
#include
#include
#define ALLOCATION_SIZE (100 * 1024 * 1024)
int main (int argc, char *argv[]) {
for (int i = 0; i < 1; i++) {
On 1/12/2018 2:19 AM, Lee wrote:
Why is the cygwin gcc calloc so much slower than the
i686-w64-mingw32-gcc calloc?
Since your test repeatedly allocates and frees one chunk
of size 100 Mb (ouch!) my guess is that the slow behavior is
rooted in something to do with mmap. Perhaps Corinna
or anoth
23 matches
Mail list logo
