Re: [Rd] R crashes in Mac OS 10.4 when Find is used (PR#9192)

2006-09-01 Thread Rob J Goedman
Matt,

This is not an R bug or r-devel issue. The proper email list is R-SIG- 
Mac.

Maybe the 1st step we can try is to install the latest version of the  
R.app,
which you can find at http://r.research.att.com/ .

Can you please download the nightly build of just the R.app GUI and
see if the problem still occurs? I have tried many times on my system
and can't reproduce the problem.

Thanks,
Rob

On Aug 31, 2006, at 7:42 AM, [EMAIL PROTECTED] wrote:

 Full_Name: Matt Fantle
 Version: 1.16
 OS: Mac OS 10.4.7
 Submission from: (NULL) (128.118.174.213)


 Problem:  R crashes when 'Command-f' is pressed to begin Find
 Frequency:  This problem is intermittant.  Once R crashes, the only  
 solution is
 to restart R and try to Find again.  There is no regularity to the  
 problem.  If
 R is opened by double-clicking on a .R file, the problem might be  
 there.  If R
 is opened by double-clicking the application or alias, the problem  
 may also
 still be there.

 Log report:
 OS Version: 10.4.7 (Build 8J135)
 Report Version: 4

 Command: R
 Path:/Applications/R.app/Contents/MacOS/R
 Parent:  WindowServer [60]

 Version: 1.16 (3198)

 PID:474
 Thread: 0

 Exception:  EXC_BREAKPOINT (0x0006)
 Code[0]:0x0001
 Code[1]:0x9295f120


 Thread 0 Crashed:
 0   com.apple.Foundation  0x9295f120 _NSRaiseError + 264
 1   com.apple.AppKit  0x937c9274 -[NSCarbonMenuImpl
 performActionWithHighlightingForItemAtIndex:] + 160
 2   com.apple.AppKit  0x937c8ce4 -[NSMenu  
 performKeyEquivalent:] + 272
 3   com.apple.AppKit  0x937c88c4 -[NSApplication  
 _handleKeyEquivalent:]
 + 220
 4   com.apple.AppKit  0x936d2408 -[NSApplication  
 sendEvent:] + 2944
 5   org.R-project.R   0xb730 -[RController  
 handleReadConsole:] + 88
 (RController.m:869)
 6   org.R-project.R   0x0002c0b8 Re_ReadConsole + 108
 (Rcallbacks.m:137)
 7   org.R-project.R   0x0003223c run_REngineRmainloop + 300
 (Rinit.c:341)
 8   org.R-project.R   0x0002aa1c -[REngine runREPL] + 68
 (REngine.m:167)
 9   org.R-project.R   0x0001d340 main + 680 (main.m:101)
 10  org.R-project.R   0x2e8c _start + 340 (crt.c:272)
 11  org.R-project.R   0x2d34 start + 60

 Thread 1:
 0   libSystem.B.dylib 0x9000b268 mach_msg_trap + 8
 1   libSystem.B.dylib 0x9000b1bc mach_msg + 60
 2   com.apple.CoreFoundation  0x907dbb78 __CFRunLoopRun + 832
 3   com.apple.CoreFoundation  0x907db47c CFRunLoopRunSpecific + 268
 4   com.apple.Foundation  0x92939598 -[NSConnection  
 sendInvocation:] + 1468
 5   com.apple.Foundation  0x92938034 -[NSObject 
 (NSForwardInvocation)
 forward::] + 408
 6   libobjc.A.dylib   0x90a430b0 _objc_msgForward + 176
 7   com.apple.Foundation  0x9293839c -[NSDistantObject
 methodSignatureForSelector:] + 268
 8   com.apple.Foundation  0x92937f04 -[NSObject 
 (NSForwardInvocation)
 forward::] + 104
 9   libobjc.A.dylib   0x90a430b0 _objc_msgForward + 176
 10  org.R-project.R   0xacc0 -[RController readThread:]  
 + 2436
 (RController.m:613)
 11  com.apple.Foundation  0x92944194 forkThreadForFunction + 108
 12  libSystem.B.dylib 0x9002bc28 _pthread_body + 96

 Thread 2:
 0   libSystem.B.dylib 0x9002c2e8 semaphore_wait_signal_trap  
 + 8
 1   libSystem.B.dylib 0x90030dcc pthread_cond_wait + 480
 2   com.apple.Foundation  0x9294b300 -[NSConditionLock  
 lockWhenCondition:] +
 68
 3   com.apple.AppKit  0x9376a708 -[NSUIHeartBeat  
 _heartBeatThread:] +
 324
 4   com.apple.Foundation  0x92944194 forkThreadForFunction + 108
 5   libSystem.B.dylib 0x9002bc28 _pthread_body + 96

 Thread 3:
 0   libSystem.B.dylib 0x9000b268 mach_msg_trap + 8
 1   libSystem.B.dylib 0x9000b1bc mach_msg + 60
 2   com.apple.CoreFoundation  0x907dbb78 __CFRunLoopRun + 832
 3   com.apple.CoreFoundation  0x907db47c CFRunLoopRunSpecific + 268
 4   com.apple.Foundation  0x9296b69c
 +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 264
 5   com.apple.Foundation  0x92944194 forkThreadForFunction + 108
 6   libSystem.B.dylib 0x9002bc28 _pthread_body + 96

 Thread 4:
 0   libSystem.B.dylib 0x9000b268 mach_msg_trap + 8
 1   libSystem.B.dylib 0x9000b1bc mach_msg + 60
 2   com.apple.CoreFoundation  0x907dbb78 __CFRunLoopRun + 832
 3   com.apple.CoreFoundation  0x907db47c CFRunLoopRunSpecific + 268
 4   com.apple.Foundation  0x9296c7dc +[NSURLCache  
 _diskCacheSyncLoop:] +
 152
 5   com.apple.Foundation  0x92944194 forkThreadForFunction + 108
 6   libSystem.B.dylib 0x9002bc28 _pthread_body + 96

 Thread 5:
 0   libSystem.B.dylib 0x9000b268 mach_msg_trap + 8
 1   libSystem.B.dylib 0x9000b1bc mach_msg + 60
 2   com.apple.CoreFoundation  0x907dbb78 __CFRunLoopRun + 832
 3   com.apple.CoreFoundation  0x907db47c CFRunLoopRunSpecific + 268
 4   com.apple.Foundation  0x92953164 

Re: [Rd] Computer algebra in R - would that be an idea??

2005-07-17 Thread Rob J Goedman
Hi,

Maybe sending an R expression and getting an R expression back
for a 'suitable subset' of expressions is ok initially. Suitable could
cover 3 levels:

1) Mapping of names and standard functions, e.g. pi to Pi and
  sin(x) to Sin(x) etc.

2) It would be nice if we can use threading of functions, which will  
require
  converting R lists, vectors, matrices etc to yacas lists.

3) And finally, what about functions such as apply, quote, etc.?

Not sure how to get around the superfluous parse step when
calling an R function, e.g.  yacas(rExp). Rebuilding the original
argument to pass to yacas with reparse(substitute(rExp)) again
might again be ok initially.

Earlier I asked the question on where to do the back and forth
translation of R expressions to yacas statements. At that time I
focused on R or C++. The latter likely if its done using the
parsed tree.

Two other possibilities might be to 'redo' yacas to make yacas much
closer to R (examples that come to mind is all cases of sin(x) in R to
Sin(x) in yacas - as in 1) above -, although as  Gabor indicated, CForm
helps on the way back). The 2nd option is adding a whole bunch of Rules
to the yacas scripts to do this, e.g '10 # sin(x) -- Sin(x)'. Not  
sure if
adding a special low level generic object to yacas would help here.

As rules in yacas are global, all of these substitutions could be  
collected
in 1 or a few yacas scripts read in when R's yacas function starts the
yacas_client.

I do work on Mac, have helped Simon and Stefano occasionally with
the Mac OS GUI.  If you have a yacas version as an Xcode project,  
that would
make playing around and trying some of above steps easier. I've  
looked at the
Mac OS GUI version of Yacas, seems based on an older version and  
vanilla 1.0.57
compiles fine on Mac OS. My guess is, if possible, we want a single  
approach
across the different platforms.

Rob


On Jul 17, 2005, at 8:29 AM, Ayal Pinkus wrote:

 Using this instead of Tcl_Eval() gives some efficiency gain, but more
 importantly, it avoids the quoting hell associated with the
 construction of the relevant command strings.

 Interesting. You are not the first person asking this, actually.

 I chose for the C API as it is nice and clean, no name mangling issues
 while switching to a new gcc compiler, and it allows people to use it
 from C also. Back then, I thought all people would want to do is  
 send a
 string and receive one back.

 Since both R and Yacas are Lisp under the hood languages (and Tcl
 too for that matter), it is a fairly good guess that their parse  
 trees
 are similar, and that it would be a fairly simple task to translate
 back and forth between them. Well, between suitable subsets, at  
 least.
 R's parse trees can in principle contain arbitrary R objects, but in
 this context, we might only need constants, names, operators, and
 function calls.

On Jul 15, 2005, at 6:25 AM, Peter Dalgaard wrote:

 I wonder how difficult it would be to translate expressions back and
 forth from R to yacas in either R or C++. And maybe strip 'In'  
 and 'Out' like parts.

 You could also just do what those examples do and embed the whole
 enchillada in R. The slightly bad news is that the yacas_eval
 interface is text-based, which means that to handle an R expression
 via yacas you're going through a deparse-parse-operate-deparse-parse
 sequence. It would be nicer if you could just convert parse trees
 between the two languages. The good news is that there's a Lisp route
 (see example3), which should make the parser/deparser coding somewhat
 easier.

On Jul 15, 2005, at 3:44 AM, Gabor Grothendieck wrote:

 On 7/15/05, Rob J Goedman [EMAIL PROTECTED] wrote:

 I wonder how difficult it would be to translate expressions back and
 forth from R to yacas in either R
 or C++. And maybe strip 'In' and 'Out' like parts.

 Not sure how generally this works but see my prior post:
http://tolstoy.newcastle.edu.au/R/help/04/03/1299.html

  system(echo 'WriteString(CForm(Integrate(x)1/x))' | yacas_client)
In WriteString(CForm(Integrate(x)1/x))
log(x)
Out True
In





[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel