headers
Vladimir Tzankov | 1 Mar 2011 15:01
Picon

Re: clisp: cvs --> hg

On 3/1/11, Sam Steingold <sds <at> gnu.org> wrote:
> OK, please try to push...

looks like it works.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Mar 2011 17:37
Picon

Re: clisp: cvs --> hg

> * Vladimir Tzankov <igmnaxbi <at> tznvy.pbz> [2011-02-25 08:46:02 +0200]:
>
> Sam, I cloned the repository and it contains the same files as my last
> cvs update.
> I committed locally in the new hg repository the only change I have
> pending (fix in GC when gen 0 is split fue to large holes at its end).
> So far everything looks fine.

you pushed to the wrong (closed!) branch.
this is no good.
what is your hg version?

--

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://palestinefacts.org http://memri.org http://camera.org
http://truepeace.org http://www.memritv.org http://pmw.org.il
Democrats, get out of my wallet! Republicans, get out of my bedroom!

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vladimir Tzankov | 1 Mar 2011 22:11
Picon

Re: clisp: cvs --> hg

On 3/1/11, Sam Steingold <sds <at> gnu.org> wrote:
> you pushed to the wrong (closed!) branch.
> this is no good.
> what is your hg version?

I pushed from OSX and have used Mercurial 1.7.5 (downloaded from
http://mercurial.berkwood.com/). Have not done anything fancy - just
clone, replace ChangeLog and spvw_garcol.d, commit, push.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 1 comment |
headers
Sam Steingold | 2 Mar 2011 15:46
Picon

Re: clisp: cvs --> hg

> * Vladimir Tzankov <igmnaxbi <at> tznvy.pbz> [2011-03-01 23:11:23 +0200]:
>
> On 3/1/11, Sam Steingold <sds <at> gnu.org> wrote:
>> you pushed to the wrong (closed!) branch.
>> this is no good.
>> what is your hg version?
>
> I pushed from OSX and have used Mercurial 1.7.5 (downloaded from
> http://mercurial.berkwood.com/). Have not done anything fancy - just
> clone, replace ChangeLog and spvw_garcol.d, commit, push.

you pushed into a closed branch.
I fixed that.
please do "hg update default" and see if everything is OK.

--

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://dhimmi.com http://truepeace.org http://honestreporting.com
http://thereligionofpeace.com http://mideasttruth.com http://ffii.org
Rhinoceros has poor vision, but, due to his size, it's not his problem.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 3 Mar 2011 18:56
Picon
Favicon

[ clisp-Bugs-3198722 ] CLISP issues arg warning despite :allow-other-keys t

Bugs item #3198722, was opened at 2011-03-03 17:56
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3198722&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Bruno Haible (haible)
Summary: CLISP issues arg warning despite :allow-other-keys t

Initial Comment:
(compile nil (lambda () (directory "/" 'xach t :allow-other-keys t))) signals a full warning:

WARNING: keyword XACH is not allowed for function DIRECTORY.
         The only allowed keywords are :IF-DOES-NOT-EXIST, :CIRCLE and :FULL.

I expected no warning, because :allow-other-keys has a compile-time constant value of t.

Also, when putting :allow-other-keys before the unknown keyword, I get this warning:

WARNING: DIRECTORY: ignored keyword XACH T
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Cohen | 6 Mar 2011 02:39
Favicon

more problems from MT debugger


Code is below.  (It's similar to what I've sent before.)
I build from current source, run, load the file below.
Next, go to another shell and telnet to localhost port 1234.
The response is something like this:
 telnet localhost 1234
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.

 ((1 . #<THREAD "debugger-2011-3-5 16:56:59">) (2 . #<THREAD "debug-server">)
 (3 . #<THREAD "main thread">)) 
 enter the number of a thread to interrupt/debug: 

If I enter 1 then things seem to work.
I've recently noticed that if I enter anything else then bad things
happen.  For instance,

 2
 ** - Continuable Error
 debug
 If you continue (by typing 'continue'): Return from BREAK loop
 Break 1 [1]> 

up to this point everything is as expected.  However, I then type
() followed by enter and get

 Connection closed by foreign host.
The original clisp image is not doing so well either.
In one case, while trying to get a response I saw this:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Don Cohen | 6 Mar 2011 09:12
Favicon

stack overflow => segfault in MT

I send this on the theory that any segfault qualifies as a clisp bug.
This is with current source.  On non-MT I get 
  *** - Program stack overflow. RESET 
whereas in MT I get segfault.
This is, of course, caused by a bug in my program.
In this case I was lucky and got a warning at each recursion,
so was able to break by setting CUSTOM:*BREAK-ON-WARNINGS* to T.
Here's the backtrace a few recursions into the process that 
eventually ends in segfault.

 > Break 1 AP5[8]> :bt
 > <1/3091> #<SYSTEM-FUNCTION EXT:SHOW-STACK> 3
 > <2/3084> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE>
 > <3/3078> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE>
 > <4/3069> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2
 > <5/3066> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-3>
 > <6/3062> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2
 > <7/3048> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2>
 > <8/3046> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
 > <9/3006> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP>
 > <10/2989> #<COMPILED-FUNCTION SYSTEM::WARN-OF-TYPE>
 > <11/2981> #<COMPILED-FUNCTION SYSTEM::C-WARNING>
 > <12/2976> #<COMPILED-FUNCTION SYSTEM::C-WARN>
 > <13/2973> #<COMPILED-FUNCTION SYSTEM::NOTE-FUNCTION-USED>
 > <14/2969> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <15/2948> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <16/2940> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <17/2919> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <18/2838> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL-INLINE>
 > <19/2832> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION-CALL>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Tzankov | 6 Mar 2011 23:27
Picon

Re: more problems from MT debugger

On 3/6/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
>
> Code is below.  (It's similar to what I've sent before.)
> ...
>     (unwind-protect
> 	(mt:thread-interrupt
> 	 ans
> 	 :function
> 	 (lambda nil
> 	   (let ((*standard-input* socket)
> 		 (*standard-output* socket)
> 		 (*debug-io* socket)
> 		 (*error-output* socket)
> 		 (*trace-output* socket)
> 		 (*query-io* socket))
> 	     (break "debug"))))
>       (close socket))))

You are closing the socket too early! In your previous mails the code
of your debug-server closes the socket within the interrupted thread:
 (mt:thread-interrupt
 ans
 :function
 (lambda nil
   (let ((*standard-input* socket)
         (*standard-output* socket)
         (*debug-io* socket)
         (*error-output* socket)
         (*trace-output* socket)
                        (*query-io* socket))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Tzankov | 6 Mar 2011 23:28
Picon

Re: stack overflow => segfault in MT

On 3/6/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
> I send this on the theory that any segfault qualifies as a clisp bug.
> This is with current source.  On non-MT I get
>   *** - Program stack overflow. RESET
> whereas in MT I get segfault.

With MT - only the "main thread" (first one) has stack overflow detection.
Stack overflow detection/recovery is implemented via libsigsegv and it
supports single stack range.
May be libsigesgv should be enhanced with multiple stack range support? gSam?

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 0 comments |
headers
Don Cohen | 7 Mar 2011 00:00
Favicon

Re: more problems from MT debugger/stack overflow => segfault

Vladimir Tzankov writes:
 > You are closing the socket too early!
(ah, one of the few places where moving something later in the code
causes it to happen earlier in the execution!)

 > However having segfaults even in this case (read from closed socket)
 > is not good. Will check.
I suspect the next message explains what's happening here.
If each complaint about the closed stream leads to an attempt to enter
the debugger, and the debugger tries to print to the same stream which
causes another error, then we get a stack overflow, and since it's
occuring in a non-main thread, that causes the segfault.

Vladimir Tzankov writes:
 > On 3/6/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
 > > I send this on the theory that any segfault qualifies as a clisp bug.
 > > This is with current source.  On non-MT I get
 > >   *** - Program stack overflow. RESET
 > > whereas in MT I get segfault.
 > 
 > With MT - only the "main thread" (first one) has stack overflow detection.
 > Stack overflow detection/recovery is implemented via libsigsegv and it
 > supports single stack range.
 > May be libsigesgv should be enhanced with multiple stack range support? ?

A few thoughts on this.
- Perhaps there's some shorter term solution involving checking when 
doing at least some operations that use more stack?
- I thought there was something similar used for generational GC, which
I imagined was going to need to detect writes to arbitrary sets of pages.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane