From adamjmurray at gmail.com Fri Feb 1 03:19:24 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Fri Feb 1 03:19:26 2008 Subject: [java-dev] Crash Report: send "get 1" message to mxj external Message-ID: <1f312.47a2f22a@www.cycling74.com> I accidentally sent my mxj object a bogus get message and Max immediately crashed. I can consistently crash Max this way. Steps to reproduce: 1. Instantiate ANY mxj external. Even something trivial like: import com.cycling74.max.MaxObject; public class test extends MaxObject { public void bang() { post("bang"); } } 2. Send the message "get 1" to the object's inlet. Kaboom! #P window setfont "Sans Serif" 9.; #P window linecount 1; #P message 143 78 33 196617 get 1; #P newex 143 106 101 196617 mxj playground.test; #P connect 1 0 0 0; #P window clipboard copycount 2; Here is my crash log (I cut out a lot, let me know if you want the full log): OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: MaxMSP Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP Parent: WindowServer [60] Version: ??? (4.6.3) PID: 371 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001 Thread 0 Crashed: 0 com.cycling74.mxj 0x1701f376 maxjava_handle_get + 135 1 com.cycling74.MaxMSP46 0x00030286 typedmess_fun + 256 (message.c:492) 2 com.cycling74.MaxMSP46 0x000e8585 outlet_anything + 355 (inletoutlet.c:967) 3 com.cycling74.MaxMSP46 0x00030286 typedmess_fun + 256 (message.c:492) 4 com.cycling74.MaxMSP46 0x00030c96 typedmess + 80 (message.c:399) 5 com.cycling74.MaxMSP46 0x000316f4 aeval + 1242 (message.c:1061) 6 com.cycling74.MaxMSP46 0x00009750 atombuf_eval + 204 (atombuf.c:234) 7 com.cycling74.MaxMSP46 0x000b6b0d vmessage_bang(_vmessage*) + 57 (vmessage.c:58) 8 com.cycling74.MaxMSP46 0x000b83a7 vmessage_click(_vmessage*) + 439 (vmessage.c:238) 9 com.cycling74.MaxMSP46 0x0000fbe8 box_click + 148 (box.c:123) 10 com.cycling74.MaxMSP46 0x000363b4 patcher_boxclick + 436 (patcher.c:2175) 11 com.cycling74.MaxMSP46 0x000382a1 patcher_click + 1195 (patcher.c:2424) 12 com.cycling74.MaxMSP46 0x0006a7c5 wind_click + 143 (window.c:1118) 13 com.cycling74.MaxMSP46 0x0006f880 wind_event + 394 (window.c:818) 14 com.cycling74.MaxMSP46 0x0002807d app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1273 (main.c:1658) 15 com.apple.HIToolbox 0x92def4d7 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093 16 com.apple.HIToolbox 0x92deeb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304 17 com.apple.HIToolbox 0x92df5f7c SendEventToEventTarget + 56 18 com.apple.HIToolbox 0x92df640f ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1169 19 com.apple.HIToolbox 0x92def88e DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2044 20 com.apple.HIToolbox 0x92deeb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304 21 com.apple.HIToolbox 0x92df5f7c SendEventToEventTarget + 56 22 com.apple.HIToolbox 0x92e39eb3 ToolboxEventDispatcher + 81 23 com.apple.HIToolbox 0x92e388cb RunApplicationEventLoop + 165 24 com.cycling74.MaxMSP46 0x00027854 app_run + 52 (main.c:1519) 25 com.cycling74.MaxMSP46 0x00027afe main + 680 (main.c:416) 26 com.cycling74.MaxMSP46 0x00002ba2 _start + 216 27 com.cycling74.MaxMSP46 0x00002ac9 start + 41 [snip other thread dumps] Thread 0 crashed with X86 Thread State (32-bit): eax: 0x01c9f3a0 ebx: 0x1701f2fd ecx: 0x01c9f3a0 edx: 0x00000000 edi: 0x00000001 esi: 0x00000000 ebp: 0xbfffd718 esp: 0xbfffd6d0 ss: 0x0000001f efl: 0x00010246 eip: 0x1701f376 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 From benjamin.eckel at gmail.com Fri Feb 1 20:53:45 2008 From: benjamin.eckel at gmail.com (Benjamin Eckel) Date: Fri Feb 1 20:53:47 2008 Subject: [java-dev] Running a Jar executable Message-ID: <1f353.47a3e948@www.cycling74.com> I have looked around the forum and I could not really find this. I need a way to open a jar executable (a simple swing app) . For instance. I want just a simple class which extends MaxObject (obviously) that has one "bang" input which opens up a jar executable of a swing java application I wrote. Should I try to use something like Runtime.exec()? Also, I have written small swing interfaces using Max before and I remember having to use SwingUtilities.invokeLater(), will I have to incorporate this as well. From ollie at icarus.nu Mon Feb 4 12:32:19 2008 From: ollie at icarus.nu (Oliver Bown) Date: Mon Feb 4 12:32:24 2008 Subject: [java-dev] newDefault() doesn't work for GUI objects Message-ID: <308ABC48-66BA-467B-9B5F-3C7E2351E720@icarus.nu> Hello Java Maxers, why is it OK for me to type "button" into a Max box and get a button, but it's not OK for me to call myPatcher.newDefault(x, y, "button", null) in an mxj object? The latter gives a failure message. Cheers, Ollie PS: I found this cool error message when you try to create an object from a Swing thread: "Constructing object from unknown thread!!!!This is no good. How did it happen!" I love the neurotic touch, especially in response to being told what to do Swing. I feel I can relate to mxj even more now. From adamjmurray at gmail.com Mon Feb 4 18:09:50 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Mon Feb 4 18:09:54 2008 Subject: [java-dev] Re: Running a Jar executable In-Reply-To: <1f353.47a3e948@www.cycling74.com> Message-ID: <1f45d.47a7b75d@www.cycling74.com> Quote: Benjamin wrote on Fri, 01 February 2008 19:53 ---------------------------------------------------- > I have looked around the forum and I could not really find this. I need a way to open a jar executable (a simple swing app) . For instance. I want just a simple class which extends MaxObject (obviously) that has one "bang" input which opens up a jar executable of a swing java application I wrote. Should I try to use something like Runtime.exec()? Also, I have written small swing interfaces using Max before and I remember having to use SwingUtilities.invokeLater(), will I have to incorporate this as well. ---------------------------------------------------- Hi Benjamin, Yes, you could do Runtime.exec(). But if you have a jar file, why not add it to the Max classpath and call into the code directly from your MaxObject? You should be able to call the main() method of the main class. If you are not sure which is the main class, unzip the jar, find its manifest file, and look for the "Main-Class" setting. If you really want/need to exec the jar, you could use one of the shell objects (search for "shell" on maxobjects.com) instead of making your own object to do the exec. I haven't coded in Swing in a while, but I believe you should always use invokeLater or invokeAndWait. Sun's tutorials have more info: http://java.sun.com/docs/books/tutorial/uiswing/concurrency/initial.html You only need to worry about this for the actual Swing code, not the exec call. -Adam From owen at owengreen.net Mon Feb 4 18:42:34 2008 From: owen at owengreen.net (Owen Green) Date: Mon Feb 4 18:43:07 2008 Subject: [java-dev] Re: Running a Jar executable In-Reply-To: <1f45d.47a7b75d@www.cycling74.com> References: <1f45d.47a7b75d@www.cycling74.com> Message-ID: <47A7BF0A.2040806@owengreen.net> Hi Adam & Benjamin, If the Swing stuff is to run in the same JVM as mxj, on OS X, then it has to be invokeLater() every time, due to bad cocoa-carbon mojo. So, Benjamin, if your original code doesn't do that, you'll either need to use Runtime.exec() or change it. -- Owen Adam Murray wrote: > I haven't coded in Swing in a while, but I believe you should always > use invokeLater or invokeAndWait. Sun's tutorials have more info: > http://java.sun.com/docs/books/tutorial/uiswing/concurrency/initial.html > You only need to worry about this for the actual Swing code, not the > exec call. From adamjmurray at gmail.com Tue Feb 5 01:57:40 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Tue Feb 5 01:57:42 2008 Subject: [java-dev] Tutorial: Setting up Eclipse for Max/MSP development Message-ID: <1f47b.47a82503@www.cycling74.com> Hi all, I recently did a fresh setup of my computer and took lots of notes. I figure this info can help some people. Here you will find everything you need to know about getting Eclipse setup to make Max/MSP externals: http://compusition.com/web/articles/maxmsp-eclipse Others have already provided instructions on this, but I assume absolutely no Eclipse experience. So if you are a complete newb this should help. I expect to be doing more of this in the future but hopefully on more interesting topics. I'm still trying to figure out the right format, so any feedback is welcome. -- Adam Murray compusition.com From julien.rabin at gmail.com Tue Feb 5 04:51:57 2008 From: julien.rabin at gmail.com (Rabin Julien) Date: Tue Feb 5 04:52:06 2008 Subject: [java-dev] Tutorial: Setting up Eclipse for Max/MSP development In-Reply-To: <1f47b.47a82503@www.cycling74.com> References: <1f47b.47a82503@www.cycling74.com> Message-ID: Le 5 f?vr. 08 ? 09:57, Adam Murray a ?crit : > Here you will find everything you need to know about getting Eclipse > setup to make Max/MSP externals: http://compusition.com/web/articles/maxmsp-eclipse > Others have already provided instructions on this, but I assume > absolutely no Eclipse experience. So if you are a complete newb this > should help. Learning Java is still on my to-do list, so I'm sure it will be of some help at one point. Thanks for sharing your work. Best, Julien From pcastine at gmx.net Tue Feb 5 06:54:03 2008 From: pcastine at gmx.net (Peter Castine) Date: Tue Feb 5 06:54:05 2008 Subject: [java-dev] Crash in JitterMatrix.copyMatrixToArray() ? Message-ID: <1f49b.47a86a7a@www.cycling74.com> Actually, an abort(). Here's the most relevant part of the Crash Log, I've attached the whole thing for the curious. I expect lines 8-10 are from inside my mxj code (also attached, it's presumably the jit_matrix method). Any ideas? Again, the full gory details in the attachment. Thread 0 Crashed: 0 libSystem.B.dylib 0x9588047a __kill + 10 1 libSystem.B.dylib 0x958f7782 raise + 26 2 libSystem.B.dylib 0x95906d3f abort + 73 3 libjvm.dylib 0x16c4bb65 JVM_RaiseSignal + 436741 4 libjvm.dylib 0x16b7af92 pss + 203970 5 libjvm.dylib 0x16b8fcdd JNI_CreateJavaVM_Impl + 71325 6 com.cycling74.JitterAPI 0x163105f3 jit_java_jitmatrix_copymatrixtoarray + 233 7 com.cycling74.JitterAPI 0x163108fb jit_java_jitmatrix_copymatrixtoarray_int + 49 8 ??? 0x1937189d 0 + 423041181 9 ??? 0x1936dc74 0 + 423025780 10 ??? 0x192b9227 0 + 422285863 11 libjvm.dylib 0x16aa163a 0x16988000 + 1152570 12 libjvm.dylib 0x16aa1356 0x16988000 + 1151830 13 libjvm.dylib 0x16a2b68c 0x16988000 + 669324 14 libjvm.dylib 0x16b841ab JNI_CreateJavaVM_Impl + 23403 15 com.cycling74.mxj 0x169543d4 call_method_with_coercion + 3624 16 com.cycling74.mxj 0x16954579 maxjava_anything + 344 17 ...diaSetup_01b03.appRuntime46 0x0001f25c typedmess_fun + 512 (message.c:492) -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time -------------- next part -------------- A non-text attachment was scrubbed... Name: jitSendPixm Crash Stuff.zip Type: application/zip Size: 25659 bytes Desc: not available Url : http://www.cycling74.com/pipermail/java-dev/attachments/20080205/fe4c9a46/jitSendPixmCrashStuff.zip From jkc at musork.com Tue Feb 5 11:16:29 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Tue Feb 5 11:16:35 2008 Subject: [java-dev] Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <1f49b.47a86a7a@www.cycling74.com> References: <1f49b.47a86a7a@www.cycling74.com> Message-ID: <9BFAD95B-5169-4D78-A6C9-FF4F4D90C37E@musork.com> On Feb 5, 2008, at 5:54 AM, Peter Castine wrote: > Actually, an abort(). > > Here's the most relevant part of the Crash Log, I've attached the > whole thing for the curious. I expect lines 8-10 are from inside my > mxj code (also attached, it's presumably the jit_matrix method). > > Any ideas? Again, the full gory details in the attachment. Can't reproduce here. Can you give us real repro steps? Something else corrupting memory? Worst case, you might switch to the copyVectorToArray() methods, since those functions have been more heavily tested and this copyMatrixToArray() routine might have some issues (if discovered, none of which would be fixed before Max 5). -Joshua From pcastine at gmx.net Tue Feb 5 12:55:58 2008 From: pcastine at gmx.net (Peter Castine) Date: Tue Feb 5 12:56:08 2008 Subject: [java-dev] Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <9BFAD95B-5169-4D78-A6C9-FF4F4D90C37E@musork.com> Message-ID: <1f4bf.47a8bf4e@www.cycling74.com> I'll get you a copy of the app we've built around my mxj Object. I need to get a current version from John Dekron. It'll probably be tomorrow. Thanks for taking the time to look at what I posted so far. FWIW, I was originally using getCell2d() calls, but they ate up CPU pretty seriously. -- P. -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time From jkc at musork.com Tue Feb 5 13:52:01 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Tue Feb 5 13:52:08 2008 Subject: [java-dev] Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <1f4bf.47a8bf4e@www.cycling74.com> References: <1f4bf.47a8bf4e@www.cycling74.com> Message-ID: <59275901-F071-4338-AF07-075D327AEC11@musork.com> On Feb 5, 2008, at 11:55 AM, Peter Castine wrote: > > I'll get you a copy of the app we've built around my mxj Object. I > need to get a current version from John Dekron. It'll probably be > tomorrow. > > Thanks for taking the time to look at what I posted so far. > > FWIW, I was originally using getCell2d() calls, but they ate up > CPU pretty seriously. As mentioned before, you might try copyVectorToArray(). This row by row copy is way faster than getCell2d() approach, and shouldn't be so much slower than a copyMatrixToArray() approach. On first glance the copyMatrixToArray() JNI code looks fine to me, but given your crashlog, maybe there's some problems for some cases in this function. I'm pretty sure that the copyVectorToArray() method is stable. That is unless this whole thing is the result of something else trashing memory. -Joshua From ferdy.guliker at student-theater.hku.nl Tue Feb 5 18:15:29 2008 From: ferdy.guliker at student-theater.hku.nl (Ferdy) Date: Tue Feb 5 18:15:31 2008 Subject: [java-dev] UdpSender not ready to send Message-ID: <1f4ce.47a90a30@www.cycling74.com> In an attempt to create a mxj object that enables a way of transmitting a jittermatrix over UDP (in small list pieces) I've come across a problem in my code claiming a UDPSender not ready to Send exception, thrown by the object itself. I realize it is not a common procedure to send jittermatrices through UDP but due to funding and hardware limitations (it's a school project with ?50 budget including PR-money, damn them) this is the only way without to much delay (we actually need it live so any delay bigger than 2-3 seconds is a problem) You can find the rar containing the java files, and a tiny test patcher to reproduce the exception, here: http://student-theater.hku.nl/~ferdy/maxMSP/JitSend.rar Or in the attachment. Can someone please look at the java code and perhaps explain to me what I'm doing wrong and perhaps give suggestions ion how to fix or get around the problem? (It's probably just bad code, but it's been years since my last java session) Thanks a million! Ferdy Utrecht School for the Arts (student) -------------- next part -------------- A non-text attachment was scrubbed... Name: JitSend.rar Type: application/octet-stream Size: 2539 bytes Desc: not available Url : http://www.cycling74.com/pipermail/java-dev/attachments/20080206/1c3a7d46/JitSend.obj From pcastine at gmx.net Wed Feb 6 08:51:10 2008 From: pcastine at gmx.net (Peter Castine) Date: Wed Feb 6 08:51:11 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <59275901-F071-4338-AF07-075D327AEC11@musork.com> Message-ID: <1f4f4.47a9d76d@www.cycling74.com> OK, I'll try the copyVector... route. If you have a machine with some time on its hands, the following steps ought to reproduce the error. 0) Open the 'jitSendPixm test2' Patch I uploaded yesterday 1) (Optional) delete the patch cord to the left inlet of [mxj jitSendPixm] (jit_matrix in inlet 0 triggers the TCP exchange with the PixelMaster hardware. The only PixelMasters are in Europe behind firewalls. If you leave the cord connected, you get zillions of •errors in the Max window but they're cosmetic.) 2) Start the qmetro and let it run. It can take a couple of hours to crash, but our app needs to run 24/7 unattended. Thanks -- Peter -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time From jkc at musork.com Wed Feb 6 09:53:14 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Wed Feb 6 09:58:40 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <1f4f4.47a9d76d@www.cycling74.com> References: <1f4f4.47a9d76d@www.cycling74.com> Message-ID: <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> On Feb 6, 2008, at 7:51 AM, Peter Castine wrote: > > It can take a couple of hours to crash, but our app needs to run > 24/7 unattended. Based on this and looking at activity monitor, there's a pretty big memory leak going on here. Shuffle shuffle, using shark malloc trace, it looks like something is up with copyMatrixToArray. I would suggest making your own function which calls copyVectorToArray() with one row size vector always and then copy to a whole matrix in Java. Let me know if that approach still has similar memory leaks. Will fix the copyMatrixToArray() issue in a future release. -Joshua From jkc at musork.com Wed Feb 6 13:31:13 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Wed Feb 6 14:57:42 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> References: <1f4f4.47a9d76d@www.cycling74.com> <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> Message-ID: FWIW, upon further investigation, the memory leak only happens if the array is not matched in size to the matrix size (product of all dimensions). So the issue in your example is using one matrixbuf for all inputs where the last input is not the same size as your array and you leak memory. If you disconnect the last input which is a different size than all the others, the memleak disappears (this matrix doesn't get copied to the buffer anyways either if the size doesn't match). I've fixed this for the next version of Jitter (Max 5 only), so for now, if you want to use these whole matrix at a time methods you'll want to make sure that the sizes match or else you'll mem leak. Otherwise use the recommended vector methods which should not be that much slower if at all. Thanks for finding this bug. -Joshua From pcastine at gmx.net Wed Feb 6 14:34:37 2008 From: pcastine at gmx.net (Peter Castine) Date: Wed Feb 6 14:57:48 2008 Subject: [java-dev] Re: Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> Message-ID: <1f50a.47aa27ed@www.cycling74.com> We're testing the copyVectorToArray() version now. It took me a while to get the incantation right. For the benefit of anyone looking for a matrix-to-array conversion, here's my code to replace copyMatrixToArray() ========== JitterMatrix jm = new JitterMatrix(...); int[] offset = new int[2]; // hard-wired to 2D matrices int[] matrixBuf = new int[/*whatever it takes*/]; int[] dim = jm.getDim(); ... offset[0] = 0; for (int j = 0; j < dim[1]; j++) { offset[1] = j; jm.copyVectorToArray(0, offset, matrixBuf, 4 * dim[0], 4 * dim[0] * j); } =========== Our app only deals with ARGB-plane matrices, a more general implementation would replace the constant 4 in the code with the current plane count. The same applies to the hard-wired 2D thing. The modification has worked for as long as I've spent writing this message. If it's still running after supper I'll be more confident.- -- P. -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time From pcastine at gmx.net Thu Feb 7 02:22:54 2008 From: pcastine at gmx.net (Peter Castine) Date: Thu Feb 7 02:22:56 2008 Subject: [java-dev] Re: Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: Message-ID: <1f550.47aacded@www.cycling74.com> At my end the good news is that the copyVectorToArray() version ran happily overnight and still has a constant memory footprint. It's running and performance is fine. I had originally matched the matrixbuf to the size of the incoming matrix by creating a new int[dim[0]*dim[1]*planecount] on each call to jit_matrix. But I found that approach takes a significant performance hit because GC gets called far too often. I also think that had an issue with cumulative memory fragmentation, but I'm not sure. Maintaining a single array large enough to hold the largest of the eight incoming matrices seemed to make a lot of sense. At least it works now. I hope. -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time From pcastine at gmx.net Thu Feb 7 02:42:37 2008 From: pcastine at gmx.net (Peter Castine) Date: Thu Feb 7 02:42:39 2008 Subject: [java-dev] Re: UdpSender not ready to send In-Reply-To: <1f4ce.47a90a30@www.cycling74.com> Message-ID: <1f551.47aad28c@www.cycling74.com> Looking at your code, I would think you need to instantiate your UdpSender with the UdpSender(address, port) signature. Instantiating the object with a void signature just creates an empty object that doesn't know where to send data to. In that situation, 'not ready to send' makes a lot of sense. You may or may not find the code I posted in my recent Java threads helpful. It's a similar project in that I'm taking Jitter Matrices and sending them over IP. It's different in that we're using TCP and that the receiving hardware doesn't know or care what a Jitter Matrix is, so I have to convert to a different data structure. The main thing is it has the same issue that it needs to wait for address & port attributes to be set before it can do any real work. HtH, Peter -- ---- Peter Castine Next Concert: Fri. 8 Feb, 2008 Oscar Peterson Concert Hall, Concordia University, Montr?al, QC, CA "The Door: Theme, Lines, Canon" --please check with venue for time From master2929 at web.de Thu Feb 7 03:53:02 2008 From: master2929 at web.de (Peter Winkler) Date: Thu Feb 7 03:53:04 2008 Subject: [java-dev] From Max to Processing (processing.org) Message-ID: <1f557.47aae30d@www.cycling74.com> Hi Folks, i just can`t get a propper OSC connection between Max and Processing. I tried to use CNMAT but couldn`t figure out which patch to use. Also, since i am working on Mac OS X 10.4.11, i don`t which adress to use to send OSC Messages? When sending to a other computer i used the IP and a certain port. DO i have to use localhost now? Thanks for helping! From jbmaxwell at rubato-music.com Thu Feb 7 12:59:23 2008 From: jbmaxwell at rubato-music.com (jbmaxwell) Date: Thu Feb 7 12:59:27 2008 Subject: [java-dev] perils of referencing Message-ID: <1f57f.47ab631b@www.cycling74.com> Hello All, I need to clear something up... Suppose I have two classes: ComplexThing, and Thing. ComplexThing is a composite object, made up of Things, which has some special powers as a result (night vision, omnipotence, etc.). It has a simple variable, Things, which is an ArrayList, and holds all Things that make up ComplexThing. ComplexThing has a method, getThings(), which returns all the Things from which it's made: ArrayList getThings() {return Things;} I have another class, Thingulator, which operates on ComplexThings. if Thingulator does something like: ComplexThing bigThing; Thing aThing; ArrayList theseThings = bigThing.getThings(); if(theseThings.contains(aThing)) theseThings.remove(aThing); Obviously, aThing gets removed from theseThings, but does it also get removed from ComplexThings.Things? I have a sinking feeling it does, as this makes perfect sense, given the whole idea of referencing, but that would also kind of suck if it did. I think there are a few places where I've done this sort of "removal", without realizing how far-reaching the references are... Also, if my fears are well-founded, is the only way around it a deep copy of ComplexThings.Things? I'm guessing so, but that also kind of sucks, as deep copies in Java are such a pain (why has this not been made simpler, over the years?). Any clarification welcome. cheers, J. From vboehm at gmx.ch Thu Feb 7 13:37:54 2008 From: vboehm at gmx.ch (vboehm@gmx.ch) Date: Thu Feb 7 13:38:03 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: References: <1f4f4.47a9d76d@www.cycling74.com> <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> Message-ID: <20080207203754.291920@gmx.net> On 06 Feb 2008, at 21:31, Joshua Kit Clayton wrote: > > FWIW, upon further investigation, the memory leak only happens if the > array is not matched in size to the matrix size (product of all > dimensions). > > I've fixed this for the next version of Jitter (Max 5 only), so for > now, if you want to use these whole matrix at a time methods you'll > want to make sure that the sizes match or else you'll mem leak. > Otherwise use the recommended vector methods which should not be that > much slower if at all. hmm, interesting. i didn't know about copyArrayToMatrix() - must have slipped in unnoticed somewhere inbetween. i was using copyArrayToVector() before and it works fine, as you said. on a speed comparison however, i was happy to notice that copyArrayToMatrix() is much faster than the vector method - at least in my situation. cpu usage came down half way for a 100x100 matrix (measured with top). BUT, i can't escape the memory leak even if the array and the matrix match in size! in the simplified example below, memory is still leaking. where am i going wrong? any help is welcome, since the speed increase could be crucial to the project i am working on. thanks, volker. import com.cycling74.max.*; import com.cycling74.jitter.*; public class LeakerTest extends MaxObject { int x = 100; int y = 100; int size = x * y; private int[] intArr = new int[size]; JitterMatrix mat = new JitterMatrix("mm", 1, "char", x, y); public LeakerTest (Atom[] args) { declareInlets(new int[]{DataTypes.ALL}); fill(100); } public void bang() { mat.copyArrayToMatrix( intArr ); } public void fill(int k) { for(int i=0; i References: <1f57f.47ab631b@www.cycling74.com> Message-ID: Couldn't you say ArrayList getThings() { return Things.clone(); } Then at least you have a copy that you can mess with in your Thingulator, and removing items from there shouldn't delete them in your ComplexThing. You don't really want a deep copy do you, just a shallow copy of the actual ArrayList so you can mess with it in the Thingulator, while leaving the management of the Thing object lifetimes to the Things array in ComplexThing? Your sinking feeling should be easy to verify with a small test class.. r. On 7-Feb-08, at 1159, jbmaxwell wrote: > > Hello All, > > I need to clear something up... > > Suppose I have two classes: ComplexThing, and Thing. > > ComplexThing is a composite object, made up of Things, which has > some special powers as a result (night vision, omnipotence, etc.). > It has a simple variable, Things, which is an ArrayList, and > holds all Things that make up ComplexThing. > > ComplexThing has a method, getThings(), which returns all the Things > from which it's made: > > ArrayList getThings() {return Things;} > > I have another class, Thingulator, which operates on ComplexThings. > > if Thingulator does something like: > > ComplexThing bigThing; > Thing aThing; > > ArrayList theseThings = bigThing.getThings(); > > if(theseThings.contains(aThing)) > theseThings.remove(aThing); > > Obviously, aThing gets removed from theseThings, but does it also > get removed from ComplexThings.Things? I have a sinking feeling it > does, as this makes perfect sense, given the whole idea of > referencing, but that would also kind of suck if it did. I think > there are a few places where I've done this sort of "removal", > without realizing how far-reaching the references are... > > Also, if my fears are well-founded, is the only way around it a deep > copy of ComplexThings.Things? I'm guessing so, but that also kind of > sucks, as deep copies in Java are such a pain (why has this not been > made simpler, over the years?). > > Any clarification welcome. > > cheers, > > J. > > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From ollie at icarus.nu Thu Feb 7 14:11:15 2008 From: ollie at icarus.nu (Oliver Bown) Date: Thu Feb 7 14:11:53 2008 Subject: [java-dev] perils of referencing In-Reply-To: <1f57f.47ab631b@www.cycling74.com> References: <1f57f.47ab631b@www.cycling74.com> Message-ID: <02BF7564-BE20-47EE-8457-2465833DADF4@icarus.nu> That's right. Except for primitives, everything in Java is a reference to an object somewhere in memory, and it's the reference that you're passing around. There's a book called Effective Java by Josh Bloch which I found quite useful on such topics, and recommended by many. It's very readable, and not too heavy. Ollie On 7 Feb 2008, at 19:59, jbmaxwell wrote: > > Hello All, > > I need to clear something up... > > Suppose I have two classes: ComplexThing, and Thing. > > ComplexThing is a composite object, made up of Things, which has > some special powers as a result (night vision, omnipotence, etc.). > It has a simple variable, Things, which is an ArrayList, and > holds all Things that make up ComplexThing. > > ComplexThing has a method, getThings(), which returns all the > Things from which it's made: > > ArrayList getThings() {return Things;} > > I have another class, Thingulator, which operates on ComplexThings. > > if Thingulator does something like: > > ComplexThing bigThing; > Thing aThing; > > ArrayList theseThings = bigThing.getThings(); > > if(theseThings.contains(aThing)) > theseThings.remove(aThing); > > Obviously, aThing gets removed from theseThings, but does it also > get removed from ComplexThings.Things? I have a sinking feeling it > does, as this makes perfect sense, given the whole idea of > referencing, but that would also kind of suck if it did. I think > there are a few places where I've done this sort of "removal", > without realizing how far-reaching the references are... > > Also, if my fears are well-founded, is the only way around it a > deep copy of ComplexThings.Things? I'm guessing so, but that also > kind of sucks, as deep copies in Java are such a pain (why has this > not been made simpler, over the years?). > > Any clarification welcome. > > cheers, > > J. > > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From jbmaxwell at rubato-music.com Thu Feb 7 14:42:49 2008 From: jbmaxwell at rubato-music.com (jbmaxwell) Date: Thu Feb 7 14:42:53 2008 Subject: [java-dev] Re: perils of referencing In-Reply-To: Message-ID: <1f58c.47ab7b59@www.cycling74.com> Oh yeah, jeepers... You're right. A deep copy would copy all the Things in the ArrayList, as well, wouldn't it! I just want a copy of the ArrayList itself. Good point. I don't know if I'll change my accessor method, but I get the idea. Is it possible to do something like: ArrayList theseThings = bigThing.getThings().clone(); That would leave my accessor method getThings() untouched, and a bit more efficient for most situations. J. -------------- Thanks Ollie. It does make sense to me, actually, but I like to get confirmation on things before I commit them to the "learned" pile... Passing references around is generally really handy, so I suppose it's not fair of me to complain about it now! ;-) cheers. From jbmaxwell at rubato-music.com Thu Feb 7 14:49:35 2008 From: jbmaxwell at rubato-music.com (jbmaxwell) Date: Thu Feb 7 14:49:36 2008 Subject: [java-dev] Re: perils of referencing In-Reply-To: <1f57f.47ab631b@www.cycling74.com> Message-ID: <1f58d.47ab7cee@www.cycling74.com> oh, duh... I just looked over some of my older code, and it looks like I've generally used something more like this: ArrayList theseThings = new ArrayList(); theseThings.addAll(ComplexThing.getThings()); That avoids the problem, too, doesn't it? J. From jkc at musork.com Thu Feb 7 15:07:25 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Thu Feb 7 15:07:29 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <20080207203754.291920@gmx.net> References: <1f4f4.47a9d76d@www.cycling74.com> <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> <20080207203754.291920@gmx.net> Message-ID: <96F0AD8C-66D9-4CDE-A82A-3D61E0DF7999@musork.com> On Feb 7, 2008, at 12:37 PM, vboehm@gmx.ch wrote: > > hmm, interesting. i didn't know about copyArrayToMatrix() - must > have slipped in unnoticed somewhere inbetween. > i was using copyArrayToVector() before and it works fine, as you said. > on a speed comparison however, i was happy to notice that > copyArrayToMatrix() is much faster than the vector method - at > least in my situation. cpu usage came down half way for a 100x100 > matrix (measured with top). > > BUT, i can't escape the memory leak even if the array and the > matrix match in size! > in the simplified example below, memory is still leaking. where am > i going wrong? > any help is welcome, since the speed increase could be crucial to > the project i am working on. Sorry, copyArrayToMatrix() *always* leaks in Jitter 1.6.x. It is copyMatrixToArray() which has no memory leak if matched in size. These methods were added later in the development cycle and were obviously not carefully tested w/r/t memory leaks. Solution for both in the next version for Max 5 only, but that doesn't really help much for now. Sorry about that. The one thing you might be able to hack together now is the creative use of one large array being sent into a single row matrix to jit.scanwrap to wrap that long row into a 2d matrix. -Joshua From maxmspjit at gmail.com Thu Feb 7 16:27:11 2008 From: maxmspjit at gmail.com (Ritchie Argue) Date: Thu Feb 7 16:27:17 2008 Subject: [java-dev] Re: perils of referencing In-Reply-To: <1f58c.47ab7b59@www.cycling74.com> References: <1f58c.47ab7b59@www.cycling74.com> Message-ID: <2D951F03-1C63-4A89-8D94-7CB969EFE272@gmail.com> You should grab Effective Java book that Oliver mentioned. It has some good tips in this area, including defensive copying. Its a good habit to let the callee do the copying, as you can't always control who the caller is (for example if you're writing a library that provides your Things to third party clients, they may accidentally do something malicious to it (as you have perhaps discovered)). Worry about efficiency when it becomes a problem, make sure it's correct first =) r. On 7-Feb-08, at 1342, jbmaxwell wrote: > > Oh yeah, jeepers... You're right. A deep copy would copy all the > Things in the ArrayList, as well, wouldn't it! I just want a copy of > the ArrayList itself. Good point. > > I don't know if I'll change my accessor method, but I get the idea. > > Is it possible to do something like: > > ArrayList theseThings = bigThing.getThings().clone(); > > That would leave my accessor method getThings() untouched, and a bit > more efficient for most situations. > > J. > > -------------- > > Thanks Ollie. > > It does make sense to me, actually, but I like to get confirmation > on things before I commit them to the "learned" pile... Passing > references around is generally really handy, so I suppose it's not > fair of me to complain about it now! ;-) > > cheers. > > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From jbmaxwell at rubato-music.com Thu Feb 7 18:03:35 2008 From: jbmaxwell at rubato-music.com (jbmaxwell) Date: Thu Feb 7 18:03:38 2008 Subject: [java-dev] Re: Re: perils of referencing In-Reply-To: <2D951F03-1C63-4A89-8D94-7CB969EFE272@gmail.com> Message-ID: <1f5a7.47abaa66@www.cycling74.com> Okay, sounds good. I'll try to track down the book. It's interesting that the callee would be a better place for the copy. I would have thought that such an accessor would be best left really simple in the callee. But it does make sense to do the copying there, as it is "safer", preventing callers from mucking about with the data - as you pointed out (and as I experienced!). I suppose I could have both the simple accessor getThings() and a "safer" one, getCopyOfThings(). But maybe there's not much point... Anyway, good to know... I really appreciate when a post helps me *think* about something from a different angle. It's nice to be given some insight into the reason for a particular practice, not just a "do this" reply - though I realize it takes more time to explain. So, thanks for that. cheers, J. Quote: maxmspjit wrote on Thu, 07 February 2008 23:27 ---------------------------------------------------- > You should grab Effective Java book that Oliver mentioned. It has some > good tips in this area, including defensive copying. Its a good habit > to let the callee do the copying, as you can't always control who the > caller is (for example if you're writing a library that provides your > Things to third party clients, they may accidentally do something > malicious to it (as you have perhaps discovered)). > > Worry about efficiency when it becomes a problem, make sure it's > correct first =) > > r. > > On 7-Feb-08, at 1342, jbmaxwell wrote: > > > > > Oh yeah, jeepers... You're right. A deep copy would copy all the > > Things in the ArrayList, as well, wouldn't it! I just want a copy of > > the ArrayList itself. Good point. > > > > I don't know if I'll change my accessor method, but I get the idea. > > > > Is it possible to do something like: > > > > ArrayList theseThings = bigThing.getThings().clone(); > > > > That would leave my accessor method getThings() untouched, and a bit > > more efficient for most situations. > > > > J. > > > > -------------- > > > > Thanks Ollie. > > > > It does make sense to me, actually, but I like to get confirmation > > on things before I commit them to the "learned" pile... Passing > > references around is generally really handy, so I suppose it's not > > fair of me to complain about it now! ;-) > > > > cheers. > > > > > > ---------------------------------------------------- From vboehm at gmx.ch Fri Feb 8 05:59:25 2008 From: vboehm at gmx.ch (=?ISO-8859-1?Q?volker_b=F6hm?=) Date: Fri Feb 8 05:57:47 2008 Subject: [java-dev] Re: Re: Crash in JitterMatrix.copyMatrixToArray() ? In-Reply-To: <96F0AD8C-66D9-4CDE-A82A-3D61E0DF7999@musork.com> References: <1f4f4.47a9d76d@www.cycling74.com> <14CA8A48-677D-4C36-9CB6-E31BA35FE0A4@musork.com> <20080207203754.291920@gmx.net> <96F0AD8C-66D9-4CDE-A82A-3D61E0DF7999@musork.com> Message-ID: <747558D8-E4C3-4100-80ED-C0804CC0A5D7@gmx.ch> On 07 Feb 2008, at 23:07, Joshua Kit Clayton wrote: > > On Feb 7, 2008, at 12:37 PM, vboehm@gmx.ch wrote: >> >> hmm, interesting. i didn't know about copyArrayToMatrix() - must >> have slipped in unnoticed somewhere inbetween. >> i was using copyArrayToVector() before and it works fine, as you >> said. >> on a speed comparison however, i was happy to notice that >> copyArrayToMatrix() is much faster than the vector method - at >> least in my situation. cpu usage came down half way for a 100x100 >> matrix (measured with top). >> >> BUT, i can't escape the memory leak even if the array and the >> matrix match in size! >> in the simplified example below, memory is still leaking. where am >> i going wrong? >> any help is welcome, since the speed increase could be crucial to >> the project i am working on. > > Sorry, copyArrayToMatrix() *always* leaks in Jitter 1.6.x. It is > copyMatrixToArray() which has no memory leak if matched in size. ah, my bad. didn't get you were talking about the other direction only. > > The one thing you might be able to hack together now is the > creative use of one large array being sent into a single row matrix > to jit.scanwrap to wrap that long row into a 2d matrix. that's a good one! a quick test shows not as good results as with copyArrayToMatrix(), but it's significantly faster than calling copyArrayToVector() for each row in the output image. thanks, would have never thought of that myself. volker. From droden66 at netscape.net Sat Feb 9 03:15:50 2008 From: droden66 at netscape.net (David Roden) Date: Sat Feb 9 03:15:51 2008 Subject: [java-dev] Re: Java 'Write' and Java 'Read' In-Reply-To: <09F2C9F7-A4D2-4ED6-89F4-3B231798CB54@cassiel.com> Message-ID: <1f61c.47ad7d55@www.cycling74.com> Thanks Nick. You're right of course about the overly complicated loop, though that wasn't the source of the difficulty. I've subsequently worked around it by backing up the arrays to dat files using DataOutPutStream. I've kept the text write method in as it was a handy debugging tool while tweaking my new Import and Export methods! From evrard.g at gmail.com Mon Feb 11 02:33:08 2008 From: evrard.g at gmail.com (guillaume) Date: Mon Feb 11 02:33:09 2008 Subject: [java-dev] Re: From Max to Processing (processing.org) In-Reply-To: <1f557.47aae30d@www.cycling74.com> Message-ID: <1f69d.47b01653@www.cycling74.com> hi peter, i managed to do this easily, be sure you have installed the oscP5 library for processing. Then, try to open an example for processing, you will see in the code that a listener is created : oscP5 = new OscP5(this,12000); means you have to send your osc messages to port 12000. this is done with the udpsend object : [udpsend localhost 12000]. here, you have a one side communication from max to processing. if you want to send osc messages from processing to max : myRemoteLocation = new NetAddress("127.0.0.1",13000); will declare the port max/msp is listening to, then : OscMessage myMessage = new OscMessage("/test"); myMessage.add(123); /* add an int to the osc message */ /* send the message */ oscP5.send(myMessage, myRemoteLocation); you will receive the messages in max/msp with the udpreceive object : [udpreceive 13000] this should work very well. cheers g -- -- Guillaume Evrard http://www.lagrandefabrique.com http://www.pucemuse.com http://www.?tite.net -- From adamjmurray at gmail.com Mon Feb 11 23:56:54 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Mon Feb 11 23:56:56 2008 Subject: [java-dev] Crash Report: call outlet() with an invalid outlet index Message-ID: <1f707.47b14333@www.cycling74.com> I know it should be the responsibility of my Max object to check outlet indexes, but I just got burned by this *again* so here we go... Steps to Reproduce: 1. Build this MXJ max object: import com.cycling74.max.MaxObject; public class crash extends MaxObject { public void bang() { outlet(2, "goodbye"); } } 2. Create this patch: #P button 93 63 15 0; #P newex 93 88 56 196617 mxj crash; #P connect 1 0 0 0; 3. Click the button. Max crashes. Expected behavior: Do not crash! Print an error to the Max window indicating an invalid outlet index was used. Crash Log: Process: MaxMSP [338] Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP Identifier: com.cycling74.MaxMSP46 Version: ??? (4.6.3) Code Type: X86 (Native) Parent Process: launchd [74] Date/Time: 2008-02-11 22:52:52.218 -0800 OS Version: Mac OS X 10.5.1 (9B21) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000050dd9a05 Crashed Thread: 0 Application Specific Information: Java information: Version: Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode) Virtual Machine version: Java HotSpot(TM) Client VM (1.5.0_13-119) for macosx-x86, built on Sep 28 2007 23:59:21 by root with gcc 4.0.1 (Apple Inc. build 5465) Exception type: Bus Error (0xa) at pc=0x0002ff41 Current thread (0x17f014d0): JavaThread "AWT-AppKit" [_thread_in_native, id=-1602322592] Stack: [0xbf800000,0xc0000000) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.cycling74.max.MaxObject.doOutlet(ILjava/lang/String;[Lcom/cycling74/max/Atom;)Z+0 j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;[Lcom/cycling74/max/Atom;)Z+49 j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;)Z+6 j crash.bang()V+4 v ~StubRoutines::call_stub Java Threads: ( => current thread ) 0x17f0ebb0 JavaThread "AWT-Shutdown" [_thread_blocked, id=17867264] 0x17f0b8b0 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=17573888] 0x17f0ae80 JavaThread "CompilerThread0" daemon [_thread_blocked, id=17570304] 0x17f0a930 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=17566720] 0x17f0a670 JavaThread "Surrogate Locker Thread (CMS)" daemon [_thread_blocked, id=17560064] 0x17f09d80 JavaThread "Finalizer" daemon [_thread_blocked, id=17556480] 0x17f09980 JavaThread "Reference Handler" daemon [_thread_blocked, id=17550336] =>0x17f014d0 JavaThread "AWT-AppKit" [_thread_in_native, id=-1602322592] Other Threads: 0x17f090d0 VMThread [id=17476608] 0x17f0c550 WatcherThread [id=17577472] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap par new generation total 4032K, used 1134K [0x1c3e0000, 0x1c7e0000, 0x1cbe0000) eden space 3968K, 28% used [0x1c3e0000, 0x1c4fbac0, 0x1c7c0000) from space 64K, 0% used [0x1c7c0000, 0x1c7c0000, 0x1c7d0000) to space 64K, 0% used [0x1c7d0000, 0x1c7d0000, 0x1c7e0000) concurrent mark-sweep generation total 61440K, used 0K [0x1cbe0000, 0x207e0000, 0x2c3e0000) concurrent-mark-sweep perm gen total 8192K, used 2772K [0x2c3e0000, 0x2cbe0000, 0x303e0000) Virtual Machine arguments: JVM args: -Xincgc -Xms64m -Xmx256m Java command: launcher type: generic Thread 0 Crashed: 0 com.cycling74.MaxMSP46 0x0002ff41 typedmess_lookup + 9 (message.c:405) 1 com.cycling74.MaxMSP46 0x000e854f outlet_anything + 301 (inletoutlet.c:968) 2 com.cycling74.MaxAPI 0x00e665b9 outlet_anything + 59 3 com.cycling74.mxj 0x1797b16e mxj_outlet_anything + 139 4 ??? 0x1a3679b1 0 + 439777713 5 ??? 0x1a361b2b 0 + 439753515 6 ??? 0x1a361b2b 0 + 439753515 7 ??? 0x1a361b2b 0 + 439753515 8 ??? 0x1a35f227 0 + 439743015 9 libjvm.dylib 0x17b9e63a 0x17a85000 + 1152570 10 libjvm.dylib 0x17b9e356 0x17a85000 + 1151830 11 libjvm.dylib 0x17b2868c 0x17a85000 + 669324 12 libjvm.dylib 0x17c954fa JNI_CreateJavaVM_Impl + 106170 13 com.cycling74.mxj 0x1796eb22 maxjava_bang + 73 14 com.cycling74.MaxMSP46 0x000e7af3 outlet_bang + 283 (inletoutlet.c:657) 15 com.cycling74.MaxMSP46 0x00075eb5 vbutton_click(vbutton*, Point) + 35 (button.c:179) 16 com.cycling74.MaxMSP46 0x0000fbe8 box_click + 148 (box.c:123) 17 com.cycling74.MaxMSP46 0x000363b4 patcher_boxclick + 436 (patcher.c:2175) 18 com.cycling74.MaxMSP46 0x000382a1 patcher_click + 1195 (patcher.c:2424) 19 com.cycling74.MaxMSP46 0x0006a7c5 wind_click + 143 (window.c:1118) 20 com.cycling74.MaxMSP46 0x0006f880 wind_event + 394 (window.c:818) 21 com.cycling74.MaxMSP46 0x0002807d app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1273 (main.c:1658) 22 com.apple.HIToolbox 0x95a0e863 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181 23 com.apple.HIToolbox 0x95a0dc9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405 24 com.apple.HIToolbox 0x95a2a08e SendEventToEventTarget + 52 25 com.apple.HIToolbox 0x95a3cb73 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1211 26 com.apple.HIToolbox 0x95a0ec1c DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2134 27 com.apple.HIToolbox 0x95a0dc9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405 28 com.apple.HIToolbox 0x95a2a08e SendEventToEventTarget + 52 29 com.apple.HIToolbox 0x95a97444 ToolboxEventDispatcher + 86 30 com.apple.HIToolbox 0x95a93c9e RunApplicationEventLoop + 222 31 com.cycling74.MaxMSP46 0x00027854 app_run + 52 (main.c:1519) 32 com.cycling74.MaxMSP46 0x00027afe main + 680 (main.c:416) 33 com.cycling74.MaxMSP46 0x00002ba2 _start + 216 34 com.cycling74.MaxMSP46 0x00002ac9 start + 41 [other threads omitted] -- Adam Murray compusition.com From nick at cassiel.com Tue Feb 12 11:19:41 2008 From: nick at cassiel.com (Nick Rothwell) Date: Tue Feb 12 11:19:44 2008 Subject: [java-dev] Announce: Groovy programming/scripting language for MaxMSP (beta) Message-ID: OK, so the embedded web server was a warm-up... I've been working on embedding the Groovy scripting language into MaxMSP, via MXJ. It loads source files from Max's search path, so it behaves rather like the JS support. Groovy is an agile, dynamic language for the Java Virtual Machine (JVM) which builds upon Java by providing features such as closures and support for domain-specific programming (such as XML processing and database access). It integrates seamlessly with Java and is very similar in syntax. For more information on Groovy, see http://groovy.codehaus.org The package download, including JARs, javadoc, example patchers/ scripts and sources is at: http://www.loadbang.net/space/Software/net.loadbang.groovy I've tagged this release as 0.9b1 - if it all works out I'll bump the version to 1.0 and punt it to the general Max list. -- N. Nick Rothwell / Cassiel.com Limited www.cassiel.com www.myspace.com/cassieldotcom www.last.fm/music/cassiel www.reverbnation.com/cassiel www.linkedin.com/in/cassiel www.loadbang.net From topher at topher.com Wed Feb 13 10:01:52 2008 From: topher at topher.com (topher lafata) Date: Wed Feb 13 10:01:59 2008 Subject: [java-dev] Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1f707.47b14333@www.cycling74.com> References: <1f707.47b14333@www.cycling74.com> Message-ID: <1C34D1FF-B7F0-48D6-8F9F-AAB276AF540A@topher.com> The thinking with this is that checking automatically if your outlet index is in range everytime adds overhead to the outlet call. If you wanted to subclass MaxObject with outletSafe it would be pretty trivial. We don't want to force the checking on someone who may not want it to happen every outlet call. t On Feb 11, 2008, at 22:56 PM, Adam Murray wrote: > > I know it should be the responsibility of my Max object to check > outlet indexes, but I just got burned by this *again* so here we go... > > > Steps to Reproduce: > > 1. Build this MXJ max object: > import com.cycling74.max.MaxObject; > public class crash extends MaxObject { > public void bang() { > outlet(2, "goodbye"); > } > } > > 2. Create this patch: > #P button 93 63 15 0; > #P newex 93 88 56 196617 mxj crash; > #P connect 1 0 0 0; > > 3. Click the button. Max crashes. > > > Expected behavior: > Do not crash! Print an error to the Max window indicating an > invalid outlet index was used. > > > Crash Log: > > Process: MaxMSP [338] > Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/ > MaxMSP > Identifier: com.cycling74.MaxMSP46 > Version: ??? (4.6.3) > Code Type: X86 (Native) > Parent Process: launchd [74] > > Date/Time: 2008-02-11 22:52:52.218 -0800 > OS Version: Mac OS X 10.5.1 (9B21) > Report Version: 6 > > Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000050dd9a05 > Crashed Thread: 0 > > Application Specific Information: > > Java information: > Version: Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode) > Virtual Machine version: Java HotSpot(TM) Client VM (1.5.0_13-119) > for macosx-x86, built on Sep 28 2007 23:59:21 by root with gcc > 4.0.1 (Apple Inc. build 5465) > Exception type: Bus Error (0xa) at pc=0x0002ff41 > > Current thread (0x17f014d0): JavaThread "AWT- > AppKit" [_thread_in_native, id=-1602322592] > Stack: [0xbf800000,0xc0000000) > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j com.cycling74.max.MaxObject.doOutlet(ILjava/lang/String;[Lcom/ > cycling74/max/Atom;)Z+0 > j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;[Lcom/ > cycling74/max/Atom;)Z+49 > j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;)Z+6 > j crash.bang()V+4 > v ~StubRoutines::call_stub > Java Threads: ( => current thread ) > 0x17f0ebb0 JavaThread "AWT-Shutdown" [_thread_blocked, id=17867264] > 0x17f0b8b0 JavaThread "Low Memory Detector" daemon > [_thread_blocked, id=17573888] > 0x17f0ae80 JavaThread "CompilerThread0" daemon [_thread_blocked, > id=17570304] > 0x17f0a930 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=17566720] > 0x17f0a670 JavaThread "Surrogate Locker Thread (CMS)" daemon > [_thread_blocked, id=17560064] > 0x17f09d80 JavaThread "Finalizer" daemon [_thread_blocked, > id=17556480] > 0x17f09980 JavaThread "Reference Handler" daemon > [_thread_blocked, id=17550336] > =>0x17f014d0 JavaThread "AWT-AppKit" [_thread_in_native, > id=-1602322592] > Other Threads: > 0x17f090d0 VMThread [id=17476608] > 0x17f0c550 WatcherThread [id=17577472] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: None > > Heap > par new generation total 4032K, used 1134K [0x1c3e0000, > 0x1c7e0000, 0x1cbe0000) > eden space 3968K, 28% used [0x1c3e0000, 0x1c4fbac0, 0x1c7c0000) > from space 64K, 0% used [0x1c7c0000, 0x1c7c0000, 0x1c7d0000) > to space 64K, 0% used [0x1c7d0000, 0x1c7d0000, 0x1c7e0000) > concurrent mark-sweep generation total 61440K, used 0K > [0x1cbe0000, 0x207e0000, 0x2c3e0000) > concurrent-mark-sweep perm gen total 8192K, used 2772K > [0x2c3e0000, 0x2cbe0000, 0x303e0000) > > Virtual Machine arguments: > JVM args: -Xincgc -Xms64m -Xmx256m > Java command: > launcher type: generic > > Thread 0 Crashed: > 0 com.cycling74.MaxMSP46 0x0002ff41 typedmess_lookup + 9 > (message.c:405) > 1 com.cycling74.MaxMSP46 0x000e854f outlet_anything + 301 > (inletoutlet.c:968) > 2 com.cycling74.MaxAPI 0x00e665b9 outlet_anything + 59 > 3 com.cycling74.mxj 0x1797b16e mxj_outlet_anything + > 139 > 4 ??? 0x1a3679b1 0 + 439777713 > 5 ??? 0x1a361b2b 0 + 439753515 > 6 ??? 0x1a361b2b 0 + 439753515 > 7 ??? 0x1a361b2b 0 + 439753515 > 8 ??? 0x1a35f227 0 + 439743015 > 9 libjvm.dylib 0x17b9e63a 0x17a85000 + 1152570 > 10 libjvm.dylib 0x17b9e356 0x17a85000 + 1151830 > 11 libjvm.dylib 0x17b2868c 0x17a85000 + 669324 > 12 libjvm.dylib 0x17c954fa JNI_CreateJavaVM_Impl > + 106170 > 13 com.cycling74.mxj 0x1796eb22 maxjava_bang + 73 > 14 com.cycling74.MaxMSP46 0x000e7af3 outlet_bang + 283 > (inletoutlet.c:657) > 15 com.cycling74.MaxMSP46 0x00075eb5 vbutton_click > (vbutton*, Point) + 35 (button.c:179) > 16 com.cycling74.MaxMSP46 0x0000fbe8 box_click + 148 > (box.c:123) > 17 com.cycling74.MaxMSP46 0x000363b4 patcher_boxclick + > 436 (patcher.c:2175) > 18 com.cycling74.MaxMSP46 0x000382a1 patcher_click + 1195 > (patcher.c:2424) > 19 com.cycling74.MaxMSP46 0x0006a7c5 wind_click + 143 > (window.c:1118) > 20 com.cycling74.MaxMSP46 0x0006f880 wind_event + 394 > (window.c:818) > 21 com.cycling74.MaxMSP46 0x0002807d app_eventhandler > (OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1273 (main.c: > 1658) > 22 com.apple.HIToolbox 0x95a0e863 > DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, > HandlerCallRec*) + 1181 > 23 com.apple.HIToolbox 0x95a0dc9d > SendEventToEventTargetInternal(OpaqueEventRef*, > OpaqueEventTargetRef*, HandlerCallRec*) + 405 > 24 com.apple.HIToolbox 0x95a2a08e > SendEventToEventTarget + 52 > 25 com.apple.HIToolbox 0x95a3cb73 > ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, > OpaqueEventRef*, void*) + 1211 > 26 com.apple.HIToolbox 0x95a0ec1c > DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, > HandlerCallRec*) + 2134 > 27 com.apple.HIToolbox 0x95a0dc9d > SendEventToEventTargetInternal(OpaqueEventRef*, > OpaqueEventTargetRef*, HandlerCallRec*) + 405 > 28 com.apple.HIToolbox 0x95a2a08e > SendEventToEventTarget + 52 > 29 com.apple.HIToolbox 0x95a97444 > ToolboxEventDispatcher + 86 > 30 com.apple.HIToolbox 0x95a93c9e > RunApplicationEventLoop + 222 > 31 com.cycling74.MaxMSP46 0x00027854 app_run + 52 (main.c: > 1519) > 32 com.cycling74.MaxMSP46 0x00027afe main + 680 (main.c:416) > 33 com.cycling74.MaxMSP46 0x00002ba2 _start + 216 > 34 com.cycling74.MaxMSP46 0x00002ac9 start + 41 > > [other threads omitted] > -- > Adam Murray > compusition.com > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From adamjmurray at gmail.com Wed Feb 13 10:20:17 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Wed Feb 13 10:20:18 2008 Subject: [java-dev] Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1C34D1FF-B7F0-48D6-8F9F-AAB276AF540A@topher.com> Message-ID: <1f7a6.47b326d0@www.cycling74.com> Quote: topher lafata wrote on Wed, 13 February 2008 09:01 ---------------------------------------------------- > The thinking with this is that checking automatically if your outlet > index is in range everytime adds overhead to the outlet call. > If you wanted to subclass MaxObject with outletSafe it would be > pretty trivial. We don't want to force the checking on someone > who may not want it to happen every outlet call. > t > I figured as much, and that definitely makes sense. Still, I wish there was a way it could bail on the current operation and not crash the whole Max application. At least the outletSafe() approach is indeed trivial to add when I need it. -- Adam Murray compusition.com From pcastine at gmx.net Thu Feb 14 03:33:14 2008 From: pcastine at gmx.net (Peter Castine) Date: Thu Feb 14 03:33:21 2008 Subject: [java-dev] Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1C34D1FF-B7F0-48D6-8F9F-AAB276AF540A@topher.com> Message-ID: <1f7d4.47b418e4@www.cycling74.com> Quote: topher lafata wrote on Wed, 13 February 2008 18:01 ---------------------------------------------------- > The thinking with this is that checking automatically if your outlet > index is in range everytime adds overhead to the outlet call. > If you wanted to subclass MaxObject with outletSafe it would be > pretty trivial. We don't want to force the checking on someone > who may not want it to happen every outlet call. ---------------------------------------------------- It's probably far too late to change the implementation... but it seems that in the Java mindset, it would be more idiomatic to have checking the default behavior (as is the case with arrays and everything else I can think of), and either a flag or a subclass to turn range&null checking off if the performance hit makes a difference. It's exceptional for an object to have a reason to speak to a null outlet, but seems it can happen. When programming C we're used to the fact that any mishap can crash Max and program carefully (for the most part). Java gives you this feeling of comfort that no matter how stupidly you code, Everything Will Be All Right... I'll read the moral of Adam's story to be that no programming language is really safe. Hang that in next to "Slow but steady wins the race" and "Look before you leap." -- P. -- ---- Peter Castine Litter Power: iCE Tools: From adamjmurray at gmail.com Thu Feb 14 10:39:04 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Thu Feb 14 10:39:06 2008 Subject: [java-dev] Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1f7d4.47b418e4@www.cycling74.com> Message-ID: <1f801.47b47cb6@www.cycling74.com> Quote: Peter Castine wrote on Thu, 14 February 2008 02:33 ---------------------------------------------------- > > It's probably far too late to change the implementation... but it seems that in the Java mindset, it would be more idiomatic to have checking the default behavior Yes, exactly. Crashing Max because of a bad outlet reference is caused by accessing an invalid location in memory. Java manages memory for you, so you get used to the idea that things like this won't happen. But since MXJ calls into the underlying Max C implementation, of course this kind of crash is possible. > > It's exceptional for an object to have a reason to speak to a null outlet, but seems it can happen. ... Java gives you this feeling of comfort that no matter how stupidly you code, Everything Will Be All Right... Well I have had my share of stupid coding moments, but to put this in perspective: I was running into this problem with my ruby object, because I have no control over what scripts the user will try to evaluate. It is entirely possible, and very easy, to reference a null outlet from a script and instantly crash Max. So I had to jump through some extra hoops to make sure this can't happen. Now I'm a little wiser :) -- Adam Murray compusition.com From jkc at musork.com Thu Feb 14 11:02:34 2008 From: jkc at musork.com (Joshua Kit Clayton) Date: Thu Feb 14 11:02:41 2008 Subject: [java-dev] Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1f801.47b47cb6@www.cycling74.com> References: <1f801.47b47cb6@www.cycling74.com> Message-ID: <18259020-3A05-4F8D-9951-1EA29B98C973@musork.com> The cost of a size comparison and branching should be close to zero as compared to the Java->Context switcth, so I think that this is worth fixing (Max 5). However, that wont help you for now. -Joshua From adamjmurray at gmail.com Thu Feb 14 11:47:25 2008 From: adamjmurray at gmail.com (Adam Murray) Date: Thu Feb 14 11:47:30 2008 Subject: [java-dev] Re: Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <18259020-3A05-4F8D-9951-1EA29B98C973@musork.com> Message-ID: <1f80d.47b48cbd@www.cycling74.com> Quote: jkc wrote on Thu, 14 February 2008 10:02 ---------------------------------------------------- > > The cost of a size comparison and branching should be close to zero > as compared to the Java->Context switcth, so I think that this is > worth fixing (Max 5). I was wondering about that when Topher brought up the issue of overhead. Great to hear! -- Adam Murray compusition.com From cjlacke at ilstu.edu Thu Feb 14 21:53:13 2008 From: cjlacke at ilstu.edu (Seejay James) Date: Thu Feb 14 21:53:16 2008 Subject: [java-dev] Help! Need to format list for udp ASAP! Message-ID: <1f857.47b51ab8@www.cycling74.com> Hi all, I need to ASAP be able to format a list of numbers to go thru the mxj.udp.send object. The patch is ready, it will send a list of about 400 RGB values in DMX format to a set of boards that will run LED's. Everything is fine with the lists and all but the format comes through as ASCII instead of the desired BYTES as numbers from 0 - 255. I have great washes of colors from a cool jit.bfg and some other manipulations, the only problem is the formatting of the lists!! It *has* to be the udp.send, so that it's wireless over Ethernet, otherwise I'd use jit.net.send which works great. So-----HOW do you tell mxj.net.send to send a list of numbers (a 1 as a start code, followed by a bunch of RGB triplet bytes, one triplet for each LED) to go out AS IS without coming out as ASCII -- the values, plus spaces, etc..? What am I missing? We can go below 256 and use atoi or iota or whatever if need be, but I'm sure there is a different fix... This is for (what could be) a really nice LED installation in a wedding coming up this weekend... it will be gorgeous if we can get past this damn formatting hurdle!! THANK YOU -- Can you tell I'm desperate?? --CJ From topher at topher.com Fri Feb 15 00:08:49 2008 From: topher at topher.com (topher lafata) Date: Fri Feb 15 00:08:55 2008 Subject: [java-dev] Re: Re: Crash Report: call outlet() with an invalid outlet index In-Reply-To: <1f80d.47b48cbd@www.cycling74.com> References: <1f80d.47b48cbd@www.cycling74.com> Message-ID: yes. perhaps the original decision to optimize for this sort of thing was premature given how things actually ended up playing out with the JNI context switch. sorry you suffered as a result adam. t On Feb 14, 2008, at 10:47 AM, Adam Murray wrote: > > Quote: jkc wrote on Thu, 14 February 2008 10:02 > ---------------------------------------------------- >> >> The cost of a size comparison and branching should be close to zero >> as compared to the Java->Context switcth, so I think that this is >> worth fixing (Max 5). > > I was wondering about that when Topher brought up the issue of > overhead. Great to hear! > > > -- > Adam Murray > compusition.com > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From owen at owengreen.net Fri Feb 15 04:07:50 2008 From: owen at owengreen.net (Owen Green) Date: Fri Feb 15 04:08:07 2008 Subject: [java-dev] Help! Need to format list for udp ASAP! In-Reply-To: <1f857.47b51ab8@www.cycling74.com> References: <1f857.47b51ab8@www.cycling74.com> Message-ID: <47B57286.2080208@owengreen.net> Have you tried iterating over the list, and sending a stream of ints to the mxj object instead? -- Owen Seejay James wrote: > Hi all, I need to ASAP be able to format a list of numbers to go thru > the mxj.udp.send object. The patch is ready, it will send a list of > about 400 RGB values in DMX format to a set of boards that will run > LED's. Everything is fine with the lists and all but the format comes > through as ASCII instead of the desired BYTES as numbers from 0 - > 255. I have great washes of colors from a cool jit.bfg and some other > manipulations, the only problem is the formatting of the lists!! > > It *has* to be the udp.send, so that it's wireless over Ethernet, > otherwise I'd use jit.net.send which works great. > > So-----HOW do you tell mxj.net.send to send a list of numbers (a 1 as > a start code, followed by a bunch of RGB triplet bytes, one triplet > for each LED) to go out AS IS without coming out as ASCII -- the > values, plus spaces, etc..? What am I missing? > > We can go below 256 and use atoi or iota or whatever if need be, but > I'm sure there is a different fix... > > This is for (what could be) a really nice LED installation in a > wedding coming up this weekend... it will be gorgeous if we can get > past this damn formatting hurdle!! > > THANK YOU -- Can you tell I'm desperate?? > > --CJ > > > > > _______________________________________________ java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev > From cjlacke at ilstu.edu Fri Feb 15 14:34:42 2008 From: cjlacke at ilstu.edu (Seejay James) Date: Fri Feb 15 14:34:44 2008 Subject: [java-dev] Re: Help! Need to format list for udp ASAP! In-Reply-To: <47B57286.2080208@owengreen.net> Message-ID: <1f91c.47b60571@www.cycling74.com> unfortunately it needs to be all in one list, as the hardware is expecting packets of all the DMX channel data. so a stream wouldn't work. Am looking into aka.datagram, which is perfect, though it's for Mac and we happen to be running on the Dark Side of the OS. will keep poking around, thanks! Was kind of hoping there was an easy change one could make at the mxj.udp.send level, here: public void inlet(int i) { us.send(i); } public void inlet(float f) { us.send(f); } public void list(Atom[] a) { us.send(a); } public void anything(String s, Atom[] a) { us.send(s,a); } Is there a change one could make to either of those last two function calls that would format the list as ints? All will be 0-255 values. I'm assuming the call being used is the Atom[] one since I'm sending a list, not a message / symbol. Thanks! --CJ From droolcup at gmail.com Fri Feb 15 15:03:35 2008 From: droolcup at gmail.com (Scott Fitzgerald) Date: Fri Feb 15 15:03:39 2008 Subject: [java-dev] Re: Help! Need to format list for udp ASAP! In-Reply-To: <1f91c.47b60571@www.cycling74.com> References: <47B57286.2080208@owengreen.net> <1f91c.47b60571@www.cycling74.com> Message-ID: <60b580310802151403r4b051f97s3eef17fedc37d677@mail.gmail.com> There's also this thread from awhile back http://www.cycling74.com/forums/index.php?t=msg&goto=70613&rid=0&srch=sending+raw+bytes+with+net.udp.send#msg_70681 I have the code i did there somewhere, but not easily accessible. ~s On Fri, Feb 15, 2008 at 10:34 PM, Seejay James wrote: > > unfortunately it needs to be all in one list, as the hardware is expecting packets of all the DMX channel data. so a stream wouldn't work. > > Am looking into aka.datagram, which is perfect, though it's for Mac and we happen to be running on the Dark Side of the OS. will keep poking around, thanks! > > Was kind of hoping there was an easy change one could make at the mxj.udp.send level, here: > > public void inlet(int i) { > us.send(i); > } > public void inlet(float f) { > us.send(f); > } > public void list(Atom[] a) { > us.send(a); > } > public void anything(String s, Atom[] a) { > us.send(s,a); > } > > Is there a change one could make to either of those last two function calls that would format the list as ints? All will be 0-255 values. I'm assuming the call being used is the Atom[] one since I'm sending a list, not a message / symbol. > > Thanks! > > > > --CJ > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev > From cjlacke at ilstu.edu Sun Feb 17 01:16:34 2008 From: cjlacke at ilstu.edu (Seejay James) Date: Sun Feb 17 01:16:35 2008 Subject: [java-dev] Re: Re: Help! Need to format list for udp ASAP! In-Reply-To: <60b580310802151403r4b051f97s3eef17fedc37d677@mail.gmail.com> Message-ID: <1f9fc.47b7ed60@www.cycling74.com> Hi guys, Thank you so much for your time and help. On this end we simply ran out of time, so the project won't go up as planned (tomorrow!). On the plus side, we are a LOT closer, we just keep running into strange Java networking stuff that is tough to debug. We started getting "java.net.socket Exception: max connections reached, buffer size reached" errors. Restarting the patch works for awhile... just when things started to work, too... The upside is that the pressure is off, I learned a ton, and I realized I should learn some more Java since there's so much it can do with lists etc. Any thoughts on the Exception thing? I've hunted around but don't really know what's happening. We will get this thing working eventually, most likely with the help of your files. The project WILL be a success, once we iron out everything. It's starting to look really cool, and the patch for setting the colors has a lot of potential. Best wishes, and thank you both very much again. It's not a lost cause, we just have to bail for this particular event. Now, Burning Man is another story... ;) CJ From topher at topher.com Mon Feb 18 11:17:39 2008 From: topher at topher.com (topher lafata) Date: Mon Feb 18 11:17:45 2008 Subject: [java-dev] udp In-Reply-To: <1f91c.47b60571@www.cycling74.com> References: <1f91c.47b60571@www.cycling74.com> Message-ID: <8C20073B-FC54-4D47-A1E1-C540B6820824@topher.com> I think it is also worth mentioning that if you are doing udp stuff you might want to check out udpsend and udpreceive first. they are c externs included with max/msp. t From garton at columbia.edu Thu Feb 21 11:51:42 2008 From: garton at columbia.edu (Brad Garton) Date: Thu Feb 21 11:51:54 2008 Subject: [java-dev] dynamically loading java classes in a standalone Message-ID: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> Hey gang -- I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz Intel MacBook), and I can get things to work by putting the max.jar file in "my.app/Contents/support/java/lib/". Now I have a large jar file, and I put it in "my.app/Contents/support/java/classes/". The problem is that the standalone is treating the jar file as a system jar and loading the entire thing into memory at start-up. I want to add the jar to the dynamic classpath so that it will only load the classes I need from the jar. I do this when running MaxMSP by setting the "max.dynamic.class.dir" in the "max.java.config.txt" to point to the large jar file. How can I set the dynamic classpath in a standalone? thanks! brad From topher at topher.com Thu Feb 21 13:44:42 2008 From: topher at topher.com (topher lafata) Date: Thu Feb 21 13:44:46 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> Message-ID: I don't really understand what you mean by saying that your entire jar is being loaded at startup. If you have any mxj instances in your standalone patch they should only load the classes that they have dependencies on. I am not aware of a way to get the JVM to force load a bunch of arbitrary classes.It loads any class when it needs it with the exception of the bootstrap classes. Regardless. I am not totally sure but if you include max.java.config.txt it is possible that mxj will find it. You might want to mess around with this. In the case that it does find it you will need to mess around with paths for the max.dynamic.jar.dir, max.dynamic.class.dir etc since they will need to be relative and I am not sure what they would be relative to. Sorry I can't be more helpful. t On Feb 21, 2008, at 10:51 AM, Brad Garton wrote: > Hey gang -- > > I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz Intel > MacBook), and I can get things to work by putting the max.jar file > in "my.app/Contents/support/java/lib/". Now I have a large jar > file, and I put it in "my.app/Contents/support/java/classes/". The > problem is that the standalone is treating the jar file as a system > jar and loading the entire thing into memory at start-up. I want > to add the jar to the dynamic classpath so that it will only load > the classes I need from the jar. > > I do this when running MaxMSP by setting the > "max.dynamic.class.dir" in the "max.java.config.txt" to point to > the large jar file. How can I set the dynamic classpath in a > standalone? > > thanks! > > brad > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From garton at columbia.edu Thu Feb 21 15:01:12 2008 From: garton at columbia.edu (Brad Garton) Date: Thu Feb 21 15:01:25 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> Message-ID: <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> I am guessing at behavior I don't understand. What is the difference between the 'immutable classpath" and the "dynamic classpath". I have a jar file that's about 6 Mbtyes, and inflates to about 30 Mbytes. If I put it on the system (immutable) classpath or just put it into one of the java classes/ or lib/ subdirs, it takes about a minute to instantiate the object that references a class in that jar. I can watch the memory usage slowly creep up to about 30 Mbytes from the starting point as apparently all of the classes are being loaded and inflated in memory If, however, I explicitly put the jar itself on the "dynamic classpath" then the object that draws on that jar load immediately with no huge memory allocation. I don't know what is causing the different behaviors. I assumed it had to do with how the JVM was loading the classes in the jar. Also, if I unpack the jar into all the separate classes in the classes/ dir, it acts like when I add the jar to the "dynamic classpath"; i.e. it loads quickly. brad On Feb 21, 2008, at 3:44 PM, topher lafata wrote: > I don't really understand what you mean by saying that your entire > jar is being loaded at startup. If you have any mxj instances in > your standalone patch they should only load the classes that they > have dependencies on. I am not aware of a way to get the JVM to > force load a bunch of arbitrary classes.It loads any class when it > needs it with the exception of the bootstrap classes. > > Regardless. I am not totally sure but if you include > max.java.config.txt it is possible that mxj will find it. You might > want to mess around with this. > In the case that it does find it you will need to mess around with > paths for the max.dynamic.jar.dir, max.dynamic.class.dir etc since > they will need to be > relative and I am not sure what they would be relative to. > > Sorry I can't be more helpful. > > t > > On Feb 21, 2008, at 10:51 AM, Brad Garton wrote: > >> Hey gang -- >> >> I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz Intel >> MacBook), and I can get things to work by putting the max.jar file >> in "my.app/Contents/support/java/lib/". Now I have a large jar >> file, and I put it in "my.app/Contents/support/java/classes/". >> The problem is that the standalone is treating the jar file as a >> system jar and loading the entire thing into memory at start-up. >> I want to add the jar to the dynamic classpath so that it will >> only load the classes I need from the jar. >> >> I do this when running MaxMSP by setting the >> "max.dynamic.class.dir" in the "max.java.config.txt" to point to >> the large jar file. How can I set the dynamic classpath in a >> standalone? >> >> thanks! >> >> brad >> >> _______________________________________________ >> java-dev mailing list >> java-dev@cycling74.com >> http://www.cycling74.com/mailman/listinfo/java-dev > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From topher at topher.com Thu Feb 21 15:42:11 2008 From: topher at topher.com (topher lafata) Date: Thu Feb 21 15:42:19 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> Message-ID: <1794D660-DCA5-484A-B10A-EBD007866E89@topher.com> On Feb 21, 2008, at 14:01 PM, Brad Garton wrote: > I am guessing at behavior I don't understand. What is the > difference between the 'immutable classpath" and the "dynamic > classpath". I have a jar file that's about 6 Mbtyes, and inflates > to about 30 Mbytes. If I put it on the system (immutable) > classpath or just put it into one of the java classes/ or lib/ > subdirs, it takes about a minute to instantiate the object that > references a class in that jar. I can watch the memory usage > slowly creep up to about 30 Mbytes from the starting point as > apparently all of the classes are being loaded and inflated in memory The system classpath is the normal java classpath which is specified to the vm at startup. java -classpath C:/blah/blah etc.Once the vm is started it can't be changed. This relates to the security of the vm. The only way you can add a new class to the vm at runtime is by using a custom classloader. The dynamic classpath is a construct we came up with so that classes could be reloaded by the mxj classloader (our custom classloader) so you don't have to quit and start max everytime you change a class definition. This is useful during the development phase of an mxj class. Thus, any class that you want to reload dynamically after its definition changes needs to be in the dynamic classpath.For a standalone the classes won't really be changing so you should put your jar in: my.app/Contents/support/java/lib/ alongside max.jar and see if that helps. The only reason that your code is working at all in the standalone is because as a last resort max will search the whole max search path for classes and jars it cannot find in the classpath. This would explain why it takes such a long time for your classes in the jar to load. The fact that the memory is increasing suggests that there may be a memory leak when max resorts to scanning the whole max search path for a class. It is not finding your jar in the classes directory since that directory is only for classes not jar files. However it is finding the classes in your jar file when it resorts to the full max searchpath. The c74/classes folder is by default part of the dynamic search path. We do not have a default dynamic jar path but one can be specified in max.java.config.txt. I am not sure how this plays out in a standalone since I am not sure how to specify a relative path to a dynamic jar directory in the context of a standalone. It would probably have to be relative to the max executable itself. In theory you could specify in max.java.config.txt these relative paths for any dynamic class and/or dynamic jar directories and included that max.java.config.txt in your standalone.It is just a question of finding out what they should be specified relative to which as i said above is probably the max executable itself. So to make a long story short. try moving your jar to the same directory as max.jar and see if your standalone behaves as expected. t > If, however, I explicitly put the jar itself on the "dynamic > classpath" then the object that draws on that jar load immediately > with no huge memory allocation. I don't know what is causing the > different behaviors. I assumed it had to do with how the JVM was > loading the classes in the jar. > > Also, if I unpack the jar into all the separate classes in the > classes/ dir, it acts like when I add the jar to the "dynamic > classpath"; i.e. it loads quickly. > > brad > > > On Feb 21, 2008, at 3:44 PM, topher lafata wrote: > >> I don't really understand what you mean by saying that your entire >> jar is being loaded at startup. If you have any mxj instances in >> your standalone patch they should only load the classes that they >> have dependencies on. I am not aware of a way to get the JVM to >> force load a bunch of arbitrary classes.It loads any class when it >> needs it with the exception of the bootstrap classes. >> >> Regardless. I am not totally sure but if you include >> max.java.config.txt it is possible that mxj will find it. You >> might want to mess around with this. >> In the case that it does find it you will need to mess around with >> paths for the max.dynamic.jar.dir, max.dynamic.class.dir etc since >> they will need to be >> relative and I am not sure what they would be relative to. >> >> Sorry I can't be more helpful. >> >> t >> >> On Feb 21, 2008, at 10:51 AM, Brad Garton wrote: >> >>> Hey gang -- >>> >>> I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz >>> Intel MacBook), and I can get things to work by putting the >>> max.jar file in "my.app/Contents/support/java/lib/". Now I have >>> a large jar file, and I put it in "my.app/Contents/support/java/ >>> classes/". The problem is that the standalone is treating the >>> jar file as a system jar and loading the entire thing into memory >>> at start-up. I want to add the jar to the dynamic classpath so >>> that it will only load the classes I need from the jar. >>> >>> I do this when running MaxMSP by setting the >>> "max.dynamic.class.dir" in the "max.java.config.txt" to point to >>> the large jar file. How can I set the dynamic classpath in a >>> standalone? >>> >>> thanks! >>> >>> brad >>> >>> _______________________________________________ >>> java-dev mailing list >>> java-dev@cycling74.com >>> http://www.cycling74.com/mailman/listinfo/java-dev >> >> _______________________________________________ >> java-dev mailing list >> java-dev@cycling74.com >> http://www.cycling74.com/mailman/listinfo/java-dev > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From topher at topher.com Thu Feb 21 15:50:37 2008 From: topher at topher.com (topher lafata) Date: Thu Feb 21 15:50:38 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> Message-ID: <380CC461-3DC2-4CFD-B88A-948CF675A51C@topher.com> one more question. how large are all of those classes before you jar them up? it is very possible that the jar is being unzipped when the mxj classloader falls back on trying to locate the class in the max search path. as a matter of fact it is entirely possible that all jars in the max search path are being unzipped temporarily into memory ,including max.jar, since the classloader needs to crack open any jar file it finds in the search path to check if it contains the class it is looking for. This previous point would explain the memory blowup you are seeing. As mentioned before, the long time it takes for instantiation would be due to the fact that the whole max search path is being scanned for each class you are loading since your jar is not in the system or dynamic classpath and the classloader is falling back to its last resort scheme for classloading. t On Feb 21, 2008, at 14:01 PM, Brad Garton wrote: > I am guessing at behavior I don't understand. What is the > difference between the 'immutable classpath" and the "dynamic > classpath". I have a jar file that's about 6 Mbtyes, and inflates > to about 30 Mbytes. If I put it on the system (immutable) > classpath or just put it into one of the java classes/ or lib/ > subdirs, it takes about a minute to instantiate the object that > references a class in that jar. I can watch the memory usage > slowly creep up to about 30 Mbytes from the starting point as > apparently all of the classes are being loaded and inflated in memory > > If, however, I explicitly put the jar itself on the "dynamic > classpath" then the object that draws on that jar load immediately > with no huge memory allocation. I don't know what is causing the > different behaviors. I assumed it had to do with how the JVM was > loading the classes in the jar. > > Also, if I unpack the jar into all the separate classes in the > classes/ dir, it acts like when I add the jar to the "dynamic > classpath"; i.e. it loads quickly. > > brad > > > On Feb 21, 2008, at 3:44 PM, topher lafata wrote: > >> I don't really understand what you mean by saying that your entire >> jar is being loaded at startup. If you have any mxj instances in >> your standalone patch they should only load the classes that they >> have dependencies on. I am not aware of a way to get the JVM to >> force load a bunch of arbitrary classes.It loads any class when it >> needs it with the exception of the bootstrap classes. >> >> Regardless. I am not totally sure but if you include >> max.java.config.txt it is possible that mxj will find it. You >> might want to mess around with this. >> In the case that it does find it you will need to mess around with >> paths for the max.dynamic.jar.dir, max.dynamic.class.dir etc since >> they will need to be >> relative and I am not sure what they would be relative to. >> >> Sorry I can't be more helpful. >> >> t >> >> On Feb 21, 2008, at 10:51 AM, Brad Garton wrote: >> >>> Hey gang -- >>> >>> I'm building some standalones (Max 4.6.3, OSX 10.4.11, 2 GHz >>> Intel MacBook), and I can get things to work by putting the >>> max.jar file in "my.app/Contents/support/java/lib/". Now I have >>> a large jar file, and I put it in "my.app/Contents/support/java/ >>> classes/". The problem is that the standalone is treating the >>> jar file as a system jar and loading the entire thing into memory >>> at start-up. I want to add the jar to the dynamic classpath so >>> that it will only load the classes I need from the jar. >>> >>> I do this when running MaxMSP by setting the >>> "max.dynamic.class.dir" in the "max.java.config.txt" to point to >>> the large jar file. How can I set the dynamic classpath in a >>> standalone? >>> >>> thanks! >>> >>> brad >>> >>> _______________________________________________ >>> java-dev mailing list >>> java-dev@cycling74.com >>> http://www.cycling74.com/mailman/listinfo/java-dev >> >> _______________________________________________ >> java-dev mailing list >> java-dev@cycling74.com >> http://www.cycling74.com/mailman/listinfo/java-dev > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From garton at columbia.edu Thu Feb 21 19:56:05 2008 From: garton at columbia.edu (Brad Garton) Date: Thu Feb 21 19:56:17 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <1794D660-DCA5-484A-B10A-EBD007866E89@topher.com> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> <1794D660-DCA5-484A-B10A-EBD007866E89@topher.com> Message-ID: <34960068-538C-4B42-813E-70060BADE4C9@columbia.edu> Ok, I see I'm pretty confused about this. But the behavior I'm seeing is also confusing, and I can't think of why. It's my maxlispj object, and the BGabcl.jar file is 6.0 Mbytes. Un-jarred and inflated, it's about 30 Mbytes of classes (which is the amount that gets allocated when it does the "slow load" thing). Here's the behavior: In a standalone, if I put the BGabcl.jar file in either of these directories: my.app/Contents/support/java/lib/ my.app/Contents/support/ it loads quickly without the additional 30 Mbyte memory allocation. If I put it here: my.app/Contents/support/java/classes/ it takes a long time to load and allocates about 30 Mbytes of memory. In the MaxMSP application, if I put it here: /Applications/MaxMSP 4.6/Cycling '74/java/classes/ it takes a long time to load and allocates about 30 Mbytes of memory. But if I add this line to the max.java.config.txt file: max.dynamic.class.dir "/Applications/MaxMSP 4.6/Cycling '74/java/ classes/BGabcl.jar" it loads quickly. Hence the source of my confusion about the dynamic classpath. One final weirdness, if I put the BGabcl.jar file here: /Applications/MaxMSP 4.6/Cycling '74/java/lib/ with or without an entry in the max.java.config.txt file, it loads quickly (and works ok!), but I get these errors in the Max window: error: java.util.zip.ZipException: No such file or directory error: at java.util.zip.ZipFile.open(Native Method) error: at java.util.zip.ZipFile.(ZipFile.java:203) error: at java.util.zip.ZipFile.(ZipFile.java:84) followed by some Lisp loader errors, but the object gets instantiated ok! I've been using the object a lot, and it seems to work well even in the slow-load case. I really don't know what's going on with the loading differences, though. I know you've got a lot going on right now, so don't delve into this too deeply unless something seems obvious to you from the above description. If I put it in the right dirs, it works fine, and I'm happy. brad From garton at columbia.edu Thu Feb 21 20:00:32 2008 From: garton at columbia.edu (Brad Garton) Date: Thu Feb 21 20:00:43 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <380CC461-3DC2-4CFD-B88A-948CF675A51C@topher.com> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> <380CC461-3DC2-4CFD-B88A-948CF675A51C@topher.com> Message-ID: This is what I think is happening, because the memory increase I see is about how large the un-jarred classes are. I think my confusion came from the dynamic classpath entry in the max.java.config.txt file making it work ok in the java/classes/ dir in the MaxMSP application hierarchy. brad On Feb 21, 2008, at 5:50 PM, topher lafata wrote: > one more question. > > how large are all of those classes before you jar them up? > > it is very possible that the jar is being unzipped when the mxj > classloader falls back on trying to locate the class in the max > search path. as a matter of fact it is entirely possible that all > jars in the max search path are being unzipped temporarily into > memory ,including max.jar, since the classloader needs to crack > open any jar file it finds in the search path to check if it > contains the class it is looking for. > > This previous point would explain the memory blowup you are seeing. > As mentioned before, the long time it takes for instantiation would > be due to the fact that the whole max search path is being scanned > for each class you are loading since your jar is not in the system > or dynamic classpath and the classloader is falling back to its > last resort scheme for classloading. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cycling74.com/pipermail/java-dev/attachments/20080221/1f1b52d0/attachment.htm From topher at topher.com Thu Feb 21 23:33:24 2008 From: topher at topher.com (topher lafata) Date: Thu Feb 21 23:33:29 2008 Subject: [java-dev] dynamically loading java classes in a standalone In-Reply-To: <34960068-538C-4B42-813E-70060BADE4C9@columbia.edu> References: <4CEBD2B4-E1E0-4A52-A7FB-2594E1AE6904@columbia.edu> <4C2B1C04-E7A8-4F9D-9C0D-883264B51F5C@columbia.edu> <1794D660-DCA5-484A-B10A-EBD007866E89@topher.com> <34960068-538C-4B42-813E-70060BADE4C9@columbia.edu> Message-ID: > it takes a long time to load and allocates about 30 Mbytes of > memory. But if I add this line to the max.java.config.txt file: > > max.dynamic.class.dir "/Applications/MaxMSP 4.6/Cycling '74/java/ > classes/BGabcl.jar" > > it loads quickly. Hence the source of my confusion about the > dynamic classpath. > yeah. dont do this. the class directory is for classes not jars. you could do: max.dynamic.jar.dir "/Applications/MaxMSP 4.6/Cycling '74/java/myjars" and put BGabcl.jar in it. I cant say what the behavior of mxj is when you set a dynamic class dir to a jar. suffice it to say that it is undefined. > One final weirdness, if I put the BGabcl.jar file here: > > /Applications/MaxMSP 4.6/Cycling '74/java/lib/ > > with or without an entry in the max.java.config.txt file, it loads > quickly (and works ok!), but I get these errors in the Max window: > > error: java.util.zip.ZipException: No such file or directory > error: at java.util.zip.ZipFile.open(Native Method) > error: at java.util.zip.ZipFile.(ZipFile.java:203) > error: at java.util.zip.ZipFile.(ZipFile.java:84) > there might be something weird in the way your jar is constructed? manifest out of sync? confusion about having that weird dynamic classpath entry point to a jar? i cant say. > I know you've got a lot going on right now, so don't delve into > this too deeply unless something seems obvious to you from the > above description. If I put it in the right dirs, it works fine, > and I'm happy. awesome. ciao t From puuukeey at comcast.net Tue Feb 26 20:37:29 2008 From: puuukeey at comcast.net (Matthew Aidekman) Date: Tue Feb 26 20:37:31 2008 Subject: [java-dev] Open Dialog is worthless Message-ID: <200e9.47c4daf8@www.cycling74.com> The included code for bringing up a file chooser appears to crash max unless housed in a ... new Runnable(){but my stuff here} ...type of deally. Unfortunately it seems that if you house it in a runnable, anything it reads (that is the point of a file chooser) can't be shared with the rest of the program since it's on a different thread. Has anyone else successfully read a file selected by a filechooser into their mxj? String initialPath = "."; String selectedPathname = null; JFileChooser openDialog = new JFileChooser(); openDialog.setSelectedFile( new File(initialPath) ); int openResult = openDialog.showOpenDialog(null); if(openResult == JFileChooser.APPROVE_OPTION) { selectedPathname = openDialog.getSelectedFile().getPath(); System.out.println(selectedPathname); } From garton at columbia.edu Tue Feb 26 20:52:06 2008 From: garton at columbia.edu (Brad Garton) Date: Tue Feb 26 20:52:23 2008 Subject: [java-dev] Open Dialog is worthless In-Reply-To: <200e9.47c4daf8@www.cycling74.com> References: <200e9.47c4daf8@www.cycling74.com> Message-ID: <3B536E5F-9915-4710-9899-8FA34CE1D28C@columbia.edu> Hey Matthew -- I ran into the same difficulty, but then I noticed that various filedialogs are included as part of the MaxSystem class (maybe the Runnable() scoping is why). This code sets up a [loadbuf] message, with or without an additional filename as part of the message. It reads the file into an internal buffer "lispbuf": String lispfname; public void loadbuf(String lf) { if (lf.length() == 0) lispfname = MaxSystem.openDialog(); else lispfname = lf; if (lispfname != null) { try { File ff = new File(lispfname); FileReader fr = new FileReader(ff); char [] cbuf = new char[(int)ff.length()]; fr.read(cbuf); lispbuf = new String(cbuf); } catch (IOException o) { error("could not load file: " + lispfname); } } } hope this helps! brad On Feb 26, 2008, at 10:37 PM, Matthew Aidekman wrote: > > The included code for bringing up a file chooser appears to crash > max unless housed in a ... > > new Runnable(){but my stuff here} > > ...type of deally. Unfortunately it seems that if you house it in > a runnable, anything it reads (that is the point of a file chooser) > can't be shared with the rest of the program since it's on a > different thread. > > Has anyone else successfully read a file selected by a filechooser > into their mxj? > > > > > > String initialPath = "."; > String selectedPathname = null; > JFileChooser openDialog = new JFileChooser(); > openDialog.setSelectedFile( new File(initialPath) ); > int openResult = openDialog.showOpenDialog(null); > > if(openResult == JFileChooser.APPROVE_OPTION) > { > selectedPathname = openDialog.getSelectedFile().getPath(); > System.out.println(selectedPathname); > } > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From puuukeey at comcast.net Tue Feb 26 21:49:51 2008 From: puuukeey at comcast.net (Matthew Aidekman) Date: Tue Feb 26 21:50:02 2008 Subject: [java-dev] Re: Open Dialog is worthless In-Reply-To: <3B536E5F-9915-4710-9899-8FA34CE1D28C@columbia.edu> Message-ID: <200f3.47c4ebee@www.cycling74.com> YOU My friend Just made my day! From topher at topher.com Thu Feb 28 01:59:18 2008 From: topher at topher.com (topher lafata) Date: Thu Feb 28 01:59:19 2008 Subject: [java-dev] Open Dialog is worthless In-Reply-To: <200e9.47c4daf8@www.cycling74.com> References: <200e9.47c4daf8@www.cycling74.com> Message-ID: <4BCEBAF5-5551-465D-B96A-FCD634ACC179@topher.com> i seem to remember java.awt.Dialog being better behaved than JDialog within max. t On Feb 26, 2008, at 19:37 PM, Matthew Aidekman wrote: > > The included code for bringing up a file chooser appears to crash > max unless housed in a ... > > new Runnable(){but my stuff here} > > ...type of deally. Unfortunately it seems that if you house it in > a runnable, anything it reads (that is the point of a file chooser) > can't be shared with the rest of the program since it's on a > different thread. > > Has anyone else successfully read a file selected by a filechooser > into their mxj? > > > > > > String initialPath = "."; > String selectedPathname = null; > JFileChooser openDialog = new JFileChooser(); > openDialog.setSelectedFile( new File(initialPath) ); > int openResult = openDialog.showOpenDialog(null); > > if(openResult == JFileChooser.APPROVE_OPTION) > { > selectedPathname = openDialog.getSelectedFile().getPath(); > System.out.println(selectedPathname); > } > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev From nick at cassiel.com Fri Feb 29 14:02:10 2008 From: nick at cassiel.com (Nick Rothwell) Date: Fri Feb 29 14:02:15 2008 Subject: [java-dev] Announce: Python for MaxMSP (beta) Message-ID: After a hectic flurry of activity, I now have a port of Python to MaxMSP, using the Jython package and MXJ. It was something of a refactoring effort, but there's now a common base of code supporting both the Groovy and Jython systems, which means that from a Max perspective they look very similar: the same interface, attributes and parameters. I even managed to port all the example patchers and scripts from the Groovy release into Jython. (At least one of the sub-patchers is identical in both systems.) There's a release at http://www.loadbang.net/space/Software/net.loadbang.jython I've labelled it a beta since there are one or two things I need to tidy up (involving threading and module reloading), but it would be good if folks could bash on it a little. The javadocs are online and the sources are included in the release, but I still need to package up the sources of the common scripting code. The javadocs are also a bit unfinished (I fully expect to find some occurrences of "Groovy" where it should say "Jython", for example). As an aside, I'm rather getting to like Python. It's a bit basic, but it's simple, clear and reliable, rather like a 2CV or an old labrador. -- N. Nick Rothwell / Cassiel.com Limited www.cassiel.com www.myspace.com/cassieldotcom www.last.fm/music/cassiel www.reverbnation.com/cassiel www.linkedin.com/in/cassiel www.loadbang.net From bthrew at gmail.com Fri Feb 29 17:44:08 2008 From: bthrew at gmail.com (barry threw) Date: Fri Feb 29 17:44:12 2008 Subject: [java-dev] Announce: Python for MaxMSP (beta) In-Reply-To: References: Message-ID: <3CBBA76A-8584-4EEF-9A45-7D8B31BE3799@gmail.com> You, sir, are being quite prolific of late. Good job. b On Feb 29, 2008, at 1:02 PM, Nick Rothwell wrote: > After a hectic flurry of activity, I now have a port of Python to > MaxMSP, using the Jython package and MXJ. > > It was something of a refactoring effort, but there's now a common > base of code supporting both the Groovy and Jython systems, which > means that from a Max perspective they look very similar: the same > interface, attributes and parameters. I even managed to port all the > example patchers and scripts from the Groovy release into Jython. > (At least one of the sub-patchers is identical in both systems.) > > There's a release at > > http://www.loadbang.net/space/Software/net.loadbang.jython > > I've labelled it a beta since there are one or two things I need to > tidy up (involving threading and module reloading), but it would be > good if folks could bash on it a little. The javadocs are online and > the sources are included in the release, but I still need to package > up the sources of the common scripting code. The javadocs are also a > bit unfinished (I fully expect to find some occurrences of "Groovy" > where it should say "Jython", for example). > > As an aside, I'm rather getting to like Python. It's a bit basic, > but it's simple, clear and reliable, rather like a 2CV or an old > labrador. > > -- N. > > > Nick Rothwell / Cassiel.com Limited > www.cassiel.com > www.myspace.com/cassieldotcom > www.last.fm/music/cassiel > www.reverbnation.com/cassiel > www.linkedin.com/in/cassiel > www.loadbang.net > > _______________________________________________ > java-dev mailing list > java-dev@cycling74.com > http://www.cycling74.com/mailman/listinfo/java-dev barry threw Media Art and Technology San Francisco, CA Work: 857-544-3967 Email: bthrew (at) gmail (dot) com Web: www.barrythrew.com