On May 23 13:33, David Rothenberger wrote:
> On 5/23/2012 1:10 PM, Corinna Vinschen wrote:
> > On May 23 19:54, Corinna Vinschen wrote:
> >> On May 23 10:42, David Rothenberger wrote:
> >>> On 5/23/2012 10:18 AM, Corinna Vinschen wrote:
> Ok, for the time being I checked in my workaround. Ple
Hello,
With the new subversion (1.7.5) and the last
snapshot (20120523 21:51:34), the command 'svn --version' produces
segmentation fault, with no svn.exe.stackdump produced:
% /usr/bin/svn --version
Segmentation fault
%
All the other commands that i've tested are ok. Only svn seems impacted.
On May 24 09:06, Denis Excoffier wrote:
>
> Hello,
>
> With the new subversion (1.7.5) and the last
> snapshot (20120523 21:51:34), the command 'svn --version' produces
> segmentation fault, with no svn.exe.stackdump produced:
>
> % /usr/bin/svn --version
> Segmentation fault
> %
I just install
Le 21 mai 2012 à 20:56, AZ 9901 a écrit :
> 2012/5/21 Karl M :
>>
>> Take a look at SetACL.
>>
>>
>>
>> ...Karl
>>
> Hello Karl,
>
> Thank you !
> Is there also an official Microsoft tool ?
>
> Thank you !
>
> Best regards,
>
> Ben
I had a look, Microsoft tool is ICACLS, it has /save an
> I think I found the problem. I've uploaded a new snapshot. Please give
> it a try.
My testcases for asynchronous and deferred cancel work on threads
blocked in sem_wait() but still fail mostly on threads blocked in
read(STDIN_FILENO, ...), same as before. Sorry about that.
$ uname -v
20120523
> My testcases for asynchronous and deferred cancel work on threads
> blocked in sem_wait() but still fail mostly on threads blocked in
> read(STDIN_FILENO, ...), same as before. Sorry about that.
I spoke too soon. There seems to be some kind of runtime decay and a
dependency on semaphore.h.
Runn
On May 24 12:35, Otto Meta wrote:
> > My testcases for asynchronous and deferred cancel work on threads
> > blocked in sem_wait() but still fail mostly on threads blocked in
> > read(STDIN_FILENO, ...), same as before. Sorry about that.
>
> I spoke too soon. There seems to be some kind of runtime
Thank you. We have not, to date, seen any messages about forking
problems or dll loading problems. I presume, though, that other
behaviors might also indicate this rebase action is needed?
On Wed, May 23, 2012 at 3:12 PM, marco atzeri wrote:
> /usr/share/doc/rebase/README
--
Tcl - The glue o
On 5/23/2012 12:02 PM, Corinna Vinschen wrote:
On May 23 11:56, Ken Brown wrote:
On 5/23/2012 10:15 AM, Corinna Vinschen wrote:
On May 23 08:00, Ken Brown wrote:
I don't know what this has to do with the longjmp, but the thread
which gets crated right after pressing Ctrl-G is due to a select or
On May 24 11:22, Denis Excoffier wrote:
> On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote:
> >> On May 24 09:06, Denis Excoffier wrote:
> >> >
> >> > Hello,
> >> >
> >> > With the new subversion (1.7.5) and the last
> >> > snapshot (20120523 21:51:34), the command 'svn --version'
On May 24 14:18, Corinna Vinschen wrote:
> On May 24 11:22, Denis Excoffier wrote:
> > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote:
> > >> On May 24 09:06, Denis Excoffier wrote:
> > >> >
> > >> > Hello,
> > >> >
> > >> > With the new subversion (1.7.5) and the last
> > >> >
On May 24 14:25, thunderboy42 wrote:
> I have an embedded system connectet with my PC which sends debug data over the
> rs232. A simple terminal program unter cygwin is used to analyze this data.
> before cygwin 1.7.10 evertything went fine, but now it seems, most transmitted
> characters get lost.
On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
After an cygwin-upgrade this morning I'm experiencing performance problems with
emacs-X11 (23.4.2). The performance problem seem to be graphics related. Window
redraw is really slow, it can take up to a couple of seconds to redraw the
emacs win
Thanks a lot for the quick investigation of the problem.
It looks you found some cygwin builds that fixed the problem .
Is it possible to release a new version of cygwin package containing the
fix ?
I'm ready to try a beta version of the cygwin package containing the fix
in the same environm
I can confirm that same issue is present with GVim on a Windows XP
machine. The issue occurred after the last update (Gnome Libraries I
believe).
On Thu, May 24, 2012 at 8:51 AM, Ken Brown wrote:
> On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
>>
>> After an cygwin-upgrade this morning I'm e
On May 24 14:36, Corinna Vinschen wrote:
> On May 24 14:18, Corinna Vinschen wrote:
> > On May 24 11:22, Denis Excoffier wrote:
> > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote:
> > > >> On May 24 09:06, Denis Excoffier wrote:
> > > >> >
> > > >> > Hello,
> > > >> >
> > > >>
On 2012-05-24 13:19, Corinna Vinschen wrote:
> You know that Cygwin is just a user space DLL, right? There's no state
> information kept in the OS beyond the lifetime of any process using the
> Cygwin DLL. In case of pthreads, there's no state at all shared with
> other processes.
Yes, that’s ex
On May 24 17:03, Otto Meta wrote:
> On 2012-05-24 13:19, Corinna Vinschen wrote:
> > You know that Cygwin is just a user space DLL, right? There's no state
> > information kept in the OS beyond the lifetime of any process using the
> > Cygwin DLL. In case of pthreads, there's no state at all shar
t;
>> > Never mind that. I *can* reproduce the problem. For some reason it
>> > only occurs on XP, not on W7.
>>
>> I applied a patch. There was some pointer at process startup which was
>> apparently always 0 on W7 while it could have a random value on XP.
Hello Corinna,
I used a part from http://en.wikibooks.org/wiki/Serial_Programming/termios for
testting because my 'original' is a little bit complicated. (see the source at
the end)
But I think I found the problem in "fhandler_serial.cc". There was some code
added for leaving the method raw_read
> Weird. I tried under CMD now as well, but it still runs and runs and
> runs, without a failure. Tested on XP, W7, and 2008 R2.
Maybe It’s Just Me then.
> Another idea is that your system also fails due to the problem reported
> in http://cygwin.com/ml/cygwin/2012-05/msg00522.html
> I'm just a
Hi all,
I have installed Cygwin and am running sshd successfully. The
permission required for the sshd service account "create a token
object" is not permitted to be granted to any accounts in my
organization. As such I have decided to use LSA based on Method 2 on
the following page: http://cygwin
I'm trying to build a package that uses Qt4. The build fails at
#include
with "No such file or directory". But /usr/include/qt4/QtGui/QtGui
exists and -I/usr/include/qt4/QtGui is one of the flags for g++. What am
I missing here?
Bob T.
--
Problem reports: http://cygwin.com/problems.html
On 2012-05-24 20:56, Bob Tennent wrote:
I'm trying to build a package that uses Qt4. The build fails at
#include
with "No such file or directory". But /usr/include/qt4/QtGui/QtGui
exists and -I/usr/include/qt4/QtGui is one of the flags for g++. What am
I missing here?
Specific information: na
Buchbinder, Barry (NIH/NIAID) [E] niaid.nih.gov> writes:
>
> # Only set ThisTerm if not set.
> if [ -z "${ThisTerm}" ]
> then
> if [ ${PPID} = 1 ]
> then
> ThisTerm=cmd
> else
> if [ "$(cat /proc/${PPID}/exename)" = '/usr/bin/mintty' ]
> then
> ThisTerm=mintty
> else
>
Hi Ken,
Ken Brown wrote:
I've noticed the same thing on my XP
I notice this, yesterday, after the upgrade announcede here:
http://cygwin.com/ml/cygwin-xfree/2012-05/msg00040.html
My builds of Emacs trunk, do not work any more correctly after the
upgrade. Emacs is very very slow...
Thi
26 matches
Mail list logo
