Squeak-dev October 2002

squeak-dev@lists.squeakfoundation.org

183 participants
406 discussions

[ENH] Image Browser: for browsing code in the other .image file
by Yoshiki.Ohshima＠acm.org 02 Nov '02

02 Nov '02

Hello, Are you getting tired to create unnecessary file outs when all you want to do is to take a look at the code in another image and to see the diffs? Here is what you can do. * File in the attachment, * Open a FileList, * Select a .image file and choose 'browse in ImageBrowser' from the FileList menu, * Open the menu at the class pane of the ImageBrowser, * Choose 'add classes to list' and type the name of classes yo want to see. From a help from InterpreterSimulator, the ImageBrowser reads the source pointers stored in the CompiledMethods in the image file, and get the code from its accompanying .change file. (All file operations are done in 'read only mode'. So, don't worry about breaking your image file.) The convenient functions inherited from FileContentsBrowser, such as 'remove unmodified categories' are there, too. ImageBrowser works for M17n images as well. I happened to notice the recent discussion about 'Diff between two change sets'. This ImageBrowser helps you to get diff between two images:-) Hooking up the internal machinary of this one with Bob's Comparison Browser would be interesting, (although I couldn't find an image to test it.) Let me know any suggestions and comments, -- Yoshiki P.S. My email address has changed.

3 5

[ANN] CGUI WidgetSet
by Chris Burkert 02 Nov '02

02 Nov '02

[Soory for sending the first mail with the wrong Subject] Hi By learning Morphic I started to create a set of widgets called CGUI. You can find it at the Swiki at http://minnow.cc.gatech.edu/squeak/2900. Other Widgets will follow later. If there is interest in general please let me know by writing a mail. Regards Chris Burkert -- ------------------------------------------------------------------------ Student of applied Computer Science at Chemnitz University of Technology http://www.chrisburkert.de/ chbu(a)hrz.tu-chemnitz.de ------------------------------------------------------------------------ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." - Alan Kay --> http://www.squeak.org/

3 4

Looking to share Oopsla accommodation
by Derek Brans 02 Nov '02

02 Nov '02

Anyone have a room and want to go halves or thirds (I don't mind sleeping on a cot)? I've got a hostel budget. I'm pretty quiet and clean. Cheers, Derek Nerd on a Wire: Web and Information Solutions Website Design - Database Systems - Site Hosting 604.874.6463 mailto:info@nerdonawire.com For more information, visit http://nerdonawire.com

2 1

RE: destructors, how?
by Peter Crowther 02 Nov '02

02 Nov '02

> From: Philip Metz [mailto:metzp@interlog.com] > Pardon my ignorance, but how is it possible to access an object > *after* it has been GCd? It isn't. The object is asked for its executor - the thing that deals with cleaning up after its death. The executor typically maintains a copy of sufficient of the object's state to be able to do the cleanup. - Peter

11 14

[ENH] Image Browser: for browsing code in the other .image file
by Yoshiki.Ohshima＠acm.org 01 Nov '02

01 Nov '02

--===-=-= Hello, Are you getting tired to create unnecessary file outs when all you want to do is to take a look at the code in another image and to see the diffs? Here is what you can do. * File in the attachment, * Open a FileList, * Select a .image file and choose 'browse in ImageBrowser' from the FileList menu, * Open the menu at the class pane of the ImageBrowser, * Choose 'add classes to list' and type the name of classes yo want to see. From a help from InterpreterSimulator, the ImageBrowser reads the source pointers stored in the CompiledMethods in the image file, and get the code from its accompanying .change file. (All file operations are done in 'read only mode'. So, don't worry about breaking your image file.) The convenient functions inherited from FileContentsBrowser, such as 'remove unmodified categories' are there, too. ImageBrowser works for M17n images as well. I happened to notice the recent discussion about 'Diff between two change sets'. This ImageBrowser helps you to get diff between two images:-) Hooking up the internal machinary of this one with Bob's Comparison Browser would be interesting, (although I couldn't find an image to test it.) Let me know any suggestions and comments, -- Yoshiki P.S. My email address has changed. --===-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=ImageBrowser.cs.gz Content-Transfer-Encoding: base64 H4sICDiRwD0AA0ltYWdlQnJvd3Nlci5jcwDtPWtz2ziSn/VB/wFxrkrSxNbY8iMJM94qx5Ps+nYc p+JMUndZx0VJkM01RWpJKh5Ppe63Xz/w5EOWE2l2PuxMVSyCAPqJRqPRADuvs3Qqzv81l+GN2O0P RDoROzviv+fxnRhsbw/EpzgsZF6I+WwMPwLxeO/5ztMLkSZid1ucjYp0KDOuGRbiINjZCbb3xGza edTeOL4OkyspzmURtFon0/BKvszS21xm7Z+xq1arNXjuddE+mhfXaYZv/ifNr6ObSJxdw99p2G4f CdVYTNJMFNdSjNKxFFFCv1P4JxP9CIGISRRLESZj0R8RBjmV9Nvts5lMRFSI26i4hgpC/jbLZJ5H aRK0W10XQzGkv1T0GhoHosM8AhYxlE6v3QZEJsg+rPFLBEyaymQOcIR4r/G7vY5G1wAwjsVQinGU z+LwTo5FmAGKo2IexsBo+VuRwQMUU3dIUD9P59mokRYhTojwNLvbFHfpXIyAnNssKqCyGMtROp1B NcurPJrOUZBjQchviuG8QE5EuYjlpKB6mQzHMsuDrV5741G7jUQdp0khkyLXXMnnw1Ec5jmogSfP VpTkRZiM5Icwi8JhLN+EUwm1Op12ixrUlM/SNP45GhXAfXhpagOSV0AVPCnRb7mQQK3ajzxBAanA 9eK8CKczaHSXip3tH3e3fySV3HkWbO92xCyLQKvE9qP/aNEfqUUgq7PhP+WoaNIb+v2OGjSrUAQq mM0EtX+PL0SSJsf49Nc4HYYxl+V3eSGnZ9lVmES/h6hUgmlHruaML/7EXsXatdIh7IEKekIMJG5P JRjDsZilxIHckWpJQa9kQeWsCaIARRBhnCZXrKJRkYscoVf0Im9UcjX+34ajGwRVlp8qbxYaa8E6 GI1cPS+g/2kTVrZGM35xOgrjNetCBZ37VWHPs1VoWsD8omURRUqCczqDkmk0jUZUDl0m4zAbo9D4 fX/B8FOYnbtjZtEQ1CQfZVl4J/TTeZHOciFjiTTxq7Uzs4TyQzmqOPYFhhMyFXwdYp7fKXGu/eil vA6/QEs1DvPX2EknHI3Q1sPYUsNzrGm66/Aoq6LxNBjsACU85o7BnoOEoIejIhA5sA8coExEk6Nh DpQEInwJynnTbrc+iy68nihAyDtwsWqbfPqsWokvYTyXFz00CecEjkER7rZhQg+TR4IIPWYzPz5l gjxy1fxBk9A0TEACyO5FlG4DpfdCJyVptzbeSaggv8DMixPHKAX9y+YjtmYuaJ6AYJph5Pob7dZX XWESh1cv72DK+tpumd+XRKAAMEUfJmVTfii2260W4vPJKRvs74iNPJ1qoFswZWhYuQA1YChccxMw hUkaegIsWi0Yd9BZt7sDAzIQuz1AOEZKoTCIxFfGQ8ltAjPo71JsiQhEdCged7cF/N+7uOhBT9Hk fTaX4EK0Pm28STV1yvqLrS07IZNZT2HqBa2diQTHGKIC+kJ8dWZumiZFIm9tWZ0kFKmMI+LSMtVZ ghd9h7c/ARcGwkX3NLyCUaXnlAqqVTwXIIoN3kN9ZTqIa4V+Jtxa300LaN55BHMluQlJmk3D+IWw E68dqHbGxGkRkO8qsSj9Kis61EYLDMI9FEkUA5Neh3EuaYRySwU9RSzRigBQ9N1uM5yuPc4N4wjm 5W6SEvl5b6O9TgmTLfgDTIHiEI19j91qoCO/kdebQA/o/TRKkEuuGwtckb+hzwIqic+zNI9IkEZW OOrFrhiCsuZs40uWwzQBk9E1D0qm2OlbVYajdFurOgoRhIpjAQTxTk7TQlGF/Cfncj6FpWxg+zkh XDWEwPwiCeTUtq2ssOP9O0wnCmO9KCgze/BcMXs32N8HZoPjPsWG2NerZAy9Ay7zyST6TSDZcTiU MbjqUQJ80TqSIxPUm0txloHbJsfHbMNoeMhbIJjbNL+3vS2ow5gcis5wOuuAaezakqto0un5Rf+c XZWLYBqYlst+KBfMEmhn7SkGMIi4cDw+imNwgbqdlFZw5ETDyi8Em5OM09sOu63mBThY5HqcTGdp VuTw2mkX5mIILslVls6TcUf0+iRRwwUL7DE24n6SjwRHPI6oRyoU9P4of2k6E70Lj1nTNJtdl9hF ZXmZ8nxWw5x6TpALDLQCGdx/Ff+AUTvF13rYUq3aXmZZiq5mcz9vuYLuqUTjOO4sRpTE8TGF8ZTF MPYX4TuWMdY+iqNRCQy407m8KvFSY15Wo2wJ3n0f1cO083BxDdP0phneS3jbwOJo/ABoGF8AZ3kc kRmrh4d1TqFKDaz0SyQfAI3GFakitmsk7ig/xQo+LLVufQA0Dsqgvwnzl9Dta6Fy1XdUk6OZuQ89 L0qAR5VRWULFfUHejEWSbCwBVviit3hRGnPahvH00lFTBA0P9AKYHLDugJim1LDIFMAYIWsHDJc0 H4iJlGNVIxyPcAIFeXDMV1u3evzAm91pNn6M5bnUM4EqKNI38pYZei4LzWfFYf2IeiUeM5K/AGxC EdRuXvxKeJUNZX47+Qadew3ewgLzd5RTBR9SUTwYEqxrpCjuZriWSRYYjKP8/fvXPrSr35cFpnUD Bon2BzEyKWHkd+wjRg5oVC+atbCLv/5vNNMRYPE4h2WQV1Ji/+74IYOQgqi7P58vsC/IDqhRNS9F OHuwdcEVJBosnLSbwb2HnuvN520WPxQkuBbLTFgf3p3+UoV3XUxL8KAkXgLkUEVOGuGdJCq44gP8 PSr7ZPePnmx0HYEBQV1ZBPGI632gaj7UHxqmfa3JVzKRGY71v70//eV7DFEmURJkUny9PX5nolJ3 pIy40Dynt4vn4r/KJJLwb17MMylsJ/V8wCYuqAoOFNIHd2EmsyJScdiHoaL6ELaTxaiUIPqC4d2J ++ZQ0DcvXLdgEqV6vHaiWCHUxKW+FqF9ROGaJ9MXr0/rF0m4NIKSPA9plmteIz2HNZKDDazEF+/W 8DpuHlOkuK9Xal6bZkQorE7ENa6RnwXbzwAlVlNaycv8JNG4fYUBRvFWu5Aq0huZYDSfIsCwcOMa l2LG4VF4lU7lKw7JulsmN/IOEMrPYdnhrczCnISBouc+L8VH3P9RMWZcs3btGjcA7OE/HIUMeJxi mCvHMBc3SMDFfjsvaNTlL0QOeJHQHRoaFogB7gBvQ1VF46U4H4UJjH5ya3L4/Z5eBBrUSM1DGFBR bRidAhnTKmAEZTnuTf06Aw0Hl0bahTyqqYMS6WkBhYgqRWg4ajceK6EEjhD66i17VajgxGdUS6Ui 368hjtLuPWUNUZiQXoz4txJMVT++qjC8qXKJm4vxSfL+Wr6E2egGnN9/zcFyAcBXFF7EsAkG6DBc oprShuBtCHoE/gIPDbIHSVREYXyU5LcY6ujgmPeBRfmr6ay4c4Jf7dZSCvAMzce94veAOS1c4d8v /Vrxk/z5n8UKcLEWSR94kg5EaBlEYleDHDlid0CAXDv4cRo8FDseqbpVvZEAWnxB2eocsCYDLMdq /4VpN5U0thZRD+t+W7Q8ZC/Ley3gpU7CeVzg6Al4YlDRIq8dyTya3JFd0cC1npJtI5nOcY63FdRf Nt5q1OY+/MBjJg5ten+stqUQLY7hXaJzURn5fu1zUMhYFnUmgoKWJ/lZIqvvqiCXqUNoLbRFja9U 01Vr8Haw98zTYB6itJPVgVIjMLWXiWHNzlrQ0ANpnhfp9BTan2BgFFXTlABWXecRDMXfQUZnk0Dg IwW9PO/XrQtd0wqU4quPy/TiNjwNBOfNBXWlR1mpL+VnLNXP6tm1H+zsAbuMciBWwCnFo8/8C4cX +2lBuyxKFGNbhRJ4r4EC8VQMo5vmCzBgaqdW+V/kVYnusMeAYT6a5KL7ptfm+AD9OZtjvzgr9ft9 DWGeTNNxNInkWO9Do5/bVosCdPUHYk8ciGfiea+tfVGAT68sIwV3x7snchwVzi9GVE15vBPyGrFV QQqs+A7RZVS5ocL3WBGDSOvfCOdXg/WxQbon2qsSpnEod4MB+riUCXSSTFKaNjj3g/msPYOyeSdk cadU7ziHVAKWIkI2j3t2StHtzb4SV6XlA0G6FGaDz9lJs1ugCuQpk4XWucc49kwXaiJztl50152f kpRr/6XDq4l8DhO8MCRvio4AxmxypZWNl0YWD6xHdi93G5i7FG8/a7q+kbertxu76JlGwAJc2Ouo EDIDjPux5geOKBv+OzwUj2HC5bfOthohr6ZrZGpQ63xcaBZ6fAXT/Ya2Wk1vHdIMgwU4HdMwjosw vqlySu2fousLy6O76TCN3cQK7KhKgjUYDlQDL0kLQKjthnY7yrz8BkYRmBvjPtOdzjrkub1zwS30 JNF5g9FcbNa5aMZCCdrbaGbyuyV8BCcqNKjghTfZOawzP0dWERu6NqVRMornY5jH1OK9WTl9sB21 7az5w+zqiE1ub4acP5sSo1iVO+WagzVMmHvBNvoXVEl5OK0NXg6xOHn21jmTvLcoiqjABAIax7zx p5HBIe3x59zz9ShJLZoAm5HWzsUaBvIO0qNaaLD3uwGVmTpVbjS6XgK3onna9ifwmnlcYV+axHfF QXUCZ5inHqo6WAZIVF84Y8QpRT9A0akna/uI6PlN7iqzOCtqvg6j+pxkwRlfkwl1E+qFPufwhW9z OR+nPNZyd4xx0geO7oD+Fb5mAu4TMZTFrZRseUbzLKNAUTq708lwV9EXeEugftRd/kidmSxgxmaW pV+isRxvtD2br1I1vtYbYFqmoRH2iEAJqL0wN6XNxDcAuzB/D6Ma7Q/isrSx6i42SvSr55mTRrgm 86dEKs7AbiofmcjjeZYDu27DCOMK+XV6+/GaQoqfsDuU7Mt5FGOK7BD/6mBsWIxorz3QbMScMo1P xL5mYBGYZbIo7rA3nSmFkKDuW/viYtUO0NNggLkmPCRgQV7n2yq/U2Gp/rjLdgri0i+yb9pxomLl PNkCG6TsvM1SlX8JJqWjM+Gh9Ap3tlAM5zJBzo9IAG8xe47WI4HgBD3bK/mY43lGq7hPwTCkWEqr vlqq0vkocGjQvnSRBNgRxb+xJ8rD1AWLIzBcRauwrnslCyVtA86tqDwJP6SlGX6pWY7JZdr3tG0d x5FCJyqIK2Mmr9XqVioq/cZ0qK6G0pDO6npPOF2hW6X010PWoKMtrslPY2Q5DGf+qMrGc1meirom dfSUvervo8pCfRB9qXuAgVtSMNUOrQZ2LNnQBDiNL70odOQFjAKxvfrV1F6wv9dgTJx4t+MseFbE CX42Dy6n8aXytCqmpaesN6rQiBRo1Dwe++a1o4Nmxcq+8KhZW3XNC7XV4ODHOswIaMBOoAKNAHQ+ cvcovkF85QNUTn6oTnKPF7q/2/42Gu+V6f1KL1KdmgiuKqEsdrVFjWQ686RwZ0nLAGpx6eyvqvhw K/2WqLJrjN1zBTRHUIFisibHbUOoGA+mJsrML2dz+5aaW0x55+F7g9k0iLuai8Ehz5dAIKeVliPc BvwLh5Y8cEWiVAa5iklk3DMu6wMjrBFMJgXt4ed6FRCUljKdWgVzz0J5WqZ2kpTRqijcM+NvsMKh n3RsdjRJzcZ0JoLEC2MdVIO4eJbOkI2oXmNWHnWEDHyFs+E/eZ9Jb5yqV3haCk19l1o8Ec96eluL 909BW8YAIkKnqqSIdafRFlRn/6Kr4crkqrjGsHPIdsj1NJimCo5U80k3+mGP0iF0VxGIlFvoSHbn lzS9mc/+Lu86PX+ectvo3xMJzidRgm27ZcZQ10+e9Xqcg38qMdWZoMDUFnKgoleeDY08qozW/fWd msw8HFwaPK4MziauJwS99UyoRs+582IRxv0mZHyS9fuVYWQ7pKnX32drtVBHL02/vKqqYz3Tsdez QBjDLnZwKB6fV44+VuRABoJGkFuNiKOxWA9SC0e5KHWKjpxBNGol4PXieh5VL+J7jcSBSu5oJtFY QRAIh2yXPdT2td2qOV3qzx/lCYjHuj3fdqTMDU/MbiFK3MWtbxsxLqVGWFjTxsNYNXHLqk1qqfJQ C/zH/sIWhGzgP9a3cNEKvKdVaoYNqVC4Duc1lV8a6IRYmrInKYMIOLGfXJjWxonuXHLkhP0JmHAy WuPf6T1MPgxgi9Hj5XxPeCl00IA9YfeEbb4JQxSPg+TREA9io6W2R9Kdihgkhn5KcEoNmMnmAFYX isNEAPoh7dBFRU+nQ1Bn2OTDqe1tEztJdDi6AupM06PxQmIc2ogeKqTzo3GMlafY3bk9gc0Hbwxl YxxVG3Ej1RUKGrCDXidjTm8BR0ZLgdKW/CJo8TYsrkl1jKDRMnWhPYJ8RStqTzd8M6rxA5Nt9xN0 VAnmWHDBT0FHIjwjZ4/hlidefyuitgUZW4yAnyXxnT6zDi4pYaqS0YgOD1cyr6UpBhrU9OO0cleD mr5o8oai+sGnzyOb8l4vq8iPI94jFjWK7mG6G9uzPL+XlPtJ+KyrP8TKmPO+FQOzbxN39vUGunZN Hd9Bh+7tFGydWIWVeX6Q/WvGTE+Kg2AfEzK8uw8omO+VrBjoAe8L1jgLBLqu/AHwVVj0X3OZaZ+f TshW0z73GJ/BINgZuOcQoZ9yYK0miG5WsrQe8G9icBYWpfPZxotUY4tqaQXQG3OqMz2teycu3Tgy b/yAJRvzAk21K3enkdJbzkTkWy5EfNS5R1uxdKKxo7fRvfOs6hCh6ifQpD9IV5aX1b6NLeyWZOVh ESYn8ONKZm3vFCefCP2K9xdwqpZ//hID6ucuW5yOiC/N5z+XbVrhqbNvgMf4nZtIKE6MaPVqzoW+ oATa4+t5crMmVj+3q+oDxWqadaAfukQBD9osx2+ap2Uy1rzSeblqe+hPI452y+Y2N9zLgSKgRFZd 01wPEpRtJR5fz9XlInQqPqLlfq2E+6UTylbO+o0j7dYGkXsdwgQJ06fL2EvhdeNS+hcxsJQ2ABNb AvfBW/57aKqDlaV2fjU8VaGKpLwR/3co/uvRo4sLvJIolgi4gnoVjCuLe4FBnY1cpy0bLgWeqm2V OLLR1sep0T2jdyOb2HG4jGemwvksW53NQlsKRTZVewolDv506CLlsASatdTCGxurpPjAUuOuqy9q Pbel6DbJykvod27ypR+g4/1KevAyoLqw0KKbqDBqaHZKNpVg7qWKAzYPxLJfl0zXaC9nWfSFTjY2 OA07wS7e2LKUzeJrTOaZWp+QzVN76e61BXyFFx5aCGGZ5F18gAYAcxL4rJ4Y3tnOQbE33uP1BdF0 xgtlbqoOr+4OTj0gYYx7PcX1lDflrymOCP9e2h7Fjz+Ck5bRQQ46b/EZ3v8kdl23+zryU2ygBtqQ 1XKY0uiWte4+k80I9Pm8VkbG6RK8hEru63/8415Wx6VsJujhidNoxTzfe65CIc7K/HVNAMRer0Ne qBsv0at+vdb6qgMBakdc3XD3YVffMdaxCzNVpbQ0H4a51GtajGf7b40BKC3de5vl1WVabNrj4BTf UqgqT8LSnQcudTURIGct6TReNn5kYbNDcKm2oNSRNoUVP6muHuTtLSHnZ56cAWUMHKiHJrTFf+Je 64p7mSZj/VOnvbiP5XiJr/olCVZiMt6Vfo3xsw+nnXyZ8JmNU32ZYuCsJmjjoO7fcGCGXX3Qxmln 86q8oI0qqsadlqNx7THCfyPlq4q4rYgEjfBDzBevUmmGT2DWWxC5oWTIhbsl1Z0c3OCjFAve4c1p wwwLv5Z2Y2q3Jd2+cRsYOefslVY6cLZBqYy2QG0qobouivCxsMyeb7k7Z1/aJC0ERI3ZOK6ko1kC K8RUsH0izK4xw6Glqr95Z/chTc89FSH+zDx90Fy1vLD3dhxh1+1yebKmCr6ob9Ns7EpZV7lPyDuD BinrDlYjZNXbt8iYKGsUr0ZzGelG7Jl+wPRERA57Xqd4bRLH7q4Okv8sOa3ZREpJsDiHfggzlYdH v/DKUPpBR3xsuBbce3RK8PI2WwgLyvwjuVQdUclG+GwitWE9Cki/wUC5fOqZLh4sR3Ytkm62alNt Q4iqrJ5r65Zo1WFdr7TUpt1SHLnn8P4uH91Xlb2j+l739XU4de6GckvOzYWyTkLdCfDrfCZHHnY9 B2IOc5L0qVVvRtkLUYTDFx7ATtN1tC8oPEB9aZnd15UWT1M/Rp73dVRzjS2lVal+tKTvxcfee+s2 7y7YYD+bqJxGl7smukLjV4M0NyOsYSTv81WDhMJrvDrT3/Wwp+H0nGuzbkoZNVbJvbR/c8Vig8mq 5PloCE92Bqht66H5QNNcq+VE9YS4QdfQ8i/XNNSwqm8q2j0de7+kejWMivPraAJ0bj3t4dMRhmx3 DrLXa6J0b9tsZt7NfEuzHoAUaWs2n1ah3qbs5xiNUuruJgBiLpK9HWUZ3as79Wfk4MGt5rCZ/p+I 3UGv7EW4bU1KnnNPkO9F0D6cY8krV7VQSlFz4qIHTiUw/ilyDTnNrT6njQLgWox4Er7qhULznpOm sOxFNQNvrmNKMdWIfebqZTX4rl95FQgbyqa7bIyrVLmEZg0+8bbyiRu3iM32MAfszEpgQveIeje8 uhe0uscNoeREddLru9UqNsldaDhXPLnoLBpL6F+RaNXpAOcclu6YDCJi7qgLKhUTfpLYsWM2xXUL V+PMzAGKwE210ACTdS5eFuXbkYS8CgvWqeV6965gDkq2p9zB961gSr2teJVaxvVPuEi1k9VgQGfe GxYGJGTthOm5IfSk/R0eUdioDo4LdNBbIMjQSnC5FYOyog1CrVskNGYzU6612djpRls7PZFO+AMV FjPe+/M7bjbCf5C/S0lU+csI42aRcv84j0o9iL8cioN1QX/K0PEy8wXgn60TuF44LYA/WC/5H2V4 0wT9UOytA/YBnzspL3gNDuZodSjUkCmuQ/oWEgZowW2hqA2VjWU+yqKhtFuO0ReZdXJaTbdb6cR8 oWVTyIg+QhVCtat5HGbOq1B8UYI4d8raLV2KOnJeU/sjIGLLcZ4Wt8BPXdTHPU72CcqMdkMoHa8R 8IvOV6tmVQ3xosq6mj+GONO1ppav66qaWxOQqSMakXIqmwmuU8sKrH3Rbq5brudVyl2Qa9C+3WBn n28CCP0DKt+8yF7snBmnqelMzHqCggeKxmUCgw8I+5UvQ3lAaO/7g2key3VwZnWBrnVPfHYXeX/g 3EUxWkGcZ0kVNAFuu7x+tia/nYIP1pv+N1I4qD1dvYJZbBel2BhxVpmdCyIrtKDEXXS+CBGqqF+r CLDMloqtHJRjK7qZs66p3ClaH19Z4ESrTp/Q2sOh2NS8LxKpO6DYi+XTg9vvYCzpgXbIwRd9dQv9 Poedzw7XHO0DD+ao+MD3WJQx1VzkyNCfx2m3kRO61LAS4tALcfNCfzySFJRzRbyVeKnignO93Nge LTXyoBOIkYzHBgVTm6JzqhDXvdVInXrZEz8IPAA6vAvEnhapHoSLFtc6D1nVcc5CV1fQTjVa6pUz d8vMoNAP1zdjnFbpXo8mbve5xPU1WfSdbfOpPecUhB9DYx1AGs1HzWYph8maNnG99n3vS3Ou44RF gbmO3lngVjpY5pt0nJ7Nh30bPzBXBd/VX5lDHHqNSFywY+19h84XePU7dH3xJuUPlxUp6CF9Ae8z 4U8yrv9GHHXmfySuL6odUT/UDQrj0spmC5mhwxpbwolGbNFnvgKxtePZOW6P//4ATQ8opFTlUikE 4TOnp80V9LKmfQ8MKyzY1/X9D1sRn+gQ+mq8kpbfczXLQIeW9lAy7iTsNzQbAb8mdOurHDNj/W34 DgAlj7zd0jRUJ2K/Y3CNaEL9XDVdqosHWRLndMyCg3N0DgkTGs8SexcI3ysIPgdt3NIDLVVtbBvm B/qR4bfrzvlrySlfYb5sZ/22c1rfHhXUxY3Ju86FJV6ivDpEoRY37v0c+uqT+65+cT5XQMb1nku/ WW/NIy7O8IYIVqR3coRREToYZzcR1NE2vafCnzCioVzTz6ULbFN0XdB6jlLX6IAXWbtATNLignI/ j60pVdXtaQVbXQ+fC3LLMAMck7lXcBdZlbj6S8lqKqqrgswQR7PnXDzWRSwj3BrgfTv1PWb3XKp7 crm7eEXd9qI0tirekPfr7H1acfYcnjlOuM22UZeIlC7EaKm1OW59A3SMg0mMpyWpc5pnjBdmmp42 cfFskz75AyQtdZzRHrJxdc9+ulOdA/3DiUeM1AHSzLVQNUdIN1r+IdK25lLNtVBOXsGqWMl8vODz Vc4OokK74l/3vXp4l9HP/rVs5vCrVsi6vU331Ktz4ki3WXxmUat6w0FYvoxEmZhLwSn9dBWY/s6E +vQLQ+Xhus0ehzrfyBtdppOR7aLebfa0j7FgsLjKrfSBM/dO6cqU5U5duWO8EkprOFOl2lSOVq2C Qcvwh9R0nJ4UC3ihLyjwL4558Oy1zyeOrAlUkbSSYfwWGMZxeKZONTVcJkaLeoJ3KZqclft9hX19 nCh3P0/kegDfQ4K6NMC5boz4tOhkQp0SfZeongXbO+ZWwFob1zYfnVGWkKax2v1Tk8dDESK+1RVm T5w8c77pzxwTdduTgn4STksGhFByVx1LRLJ5Ld1Uw+FdvkNt8V1ndJfEAv3RH4XH296EuQJHvmi8 wK5d6/Q5tmNpzdjhO5aM7Akb81SndauAYu6/bePxOlWITqAOra8G7IC39nHkvVOnHvQVi+DNyaJW 2OVbn5aGdsCxdS9Bn9jpl1RJWylEPF+pQZcvqlJv6tj7zTg8DbafOjjUJbSqi4PTWW5izM6T89V1 U+hPc/0KEzlMZaqvlKASUwkpT4xcslqIu2WIdWLUV4etQ4wKBzdvh4j2CtYLzyW5dPOZfrFavd3T d2XUq52b3WUU13u+9O+Uo7hsORtYrQo9EVaSbrxefzoEt8mrT8lSXsgl0v7TZ/cG2LowhT9p0SE6 9bWefD7DL5Yv+rbiU/sNAZval1K8vVQMvEidoM1aMLGpf5T3Z54U+b+AizmHXl8lX6IsTezXEktK kYs7WYh5Qu/ojt4F16LvoS1QJ+6O0+SLzAp1c4pMRukYJiteN9JSyCtSdk21feW86pdqlrMy0bWB 5njXjAEpQJd17gJ9SnMMzFVBDqJRf67G7dlekB945Zz48CZNpHGl7HlFxAOegb3l/Mpap8h+IuJR u1vnFZV8mF676bZivycau+ULianx/wNUHkk+3pAAAA== --===-=-=-- --=-=-= -- Cleanliness is next to impossible. --=-=-=--

3 6

RE: An uncomfortable question
by Swan, Dean 01 Nov '02

01 Nov '02

Goran, I didn't mean in any way to call your baby ugly, but it *IS* just a database with a user interface that makes it easy to do useful things, and from a USER point of view (as opposed to a package PUBLISHER or DEVELOPER) it is simply a tool for importing new code into a local image. That is what I mean by monolithic image based. The fact that SM supports multiple file formats is wonderful, but that really has nothing to do with the structure of the underlying source code. Unless I've missed something, once you use SM to import a package into an image, there is no easy way to "undo" this package addition. This is also consistent with the "monlithic image model". Please don't misunderstand. I'm not attemtping to criticize any any of the great work being done in Squeak. Microsoft, I am criticizing, but not Squeak or Squeak contributions. If anything I was trying to make the point that flexibility does not come for free, and that I prefer Dan Ingalls's original premise of "the simplest thing that could possibly work". -Dean -----Original Message----- From: goran.hultgren(a)bluefish.se [mailto:goran.hultgren@bluefish.se] Sent: Thursday, October 31, 2002 3:42 AM To: squeak-dev(a)lists.squeakfoundation.org Subject: RE: An uncomfortable question Hi all! "Swan, Dean" <Dean_Swan(a)Mitel.COM> wrote: [SNIP] > And regarding SqueakMap and DVS, realize that these are based on the monolithic image model. They are more or less fancy user interfaces to manage filing in the various change sets (I know I'm oversimplifying a bit, but the point is still valid). Well... No, I think you are oversimplifying a bit too much. SqueakMap is a distributed catalog of packages that can be installed into a Squeak image. It is already supporting different package formats: -.st, .cs, .st.gz, .cs.gz (Simple fileins as you mention) -.pr (Implemented but not released) -.sar (Neds new megaformat capable of anything, probably similar to debs, rpms) -.st DVS (Avi's DVS .st format which both can be filed in conventionally AND filed in using DVS thus making a package more or less upgradeable) My point here is that SM doesn't just handle changesets but any package format. And when the package formats evolve further we will start seeing new ways to deal with them - like a controlled upgrade for example. Or uninstall. I am not sure what you mean with "based on the monolithic image model" but IMHO SqueakMap together with DVS etc is changing this. As a small example, very soon Celeste can be cut out of the image and be published on SM - I think Daniel is itching to do that and we already have all the tools that it takes. In fact SM itself is probably (this is the current proposal) the very first package that is NOT going into the image! Yep, eating my own dogfood. For the curious this means that when SM hits the update stream for 3.2 (we are hopefully talking days now) it will actually only be a little bootstrap script going in - not SM itself. What does this mean in practice? It means that when you update 3.2 you will get a chance to install SM into it "by remote". As the user you will not see the difference but for us package developers it is a huge difference. The SM code that you now have in your image is NOT maintained using the regular update stream. It is maintained outside of the image. When I (being the maintainer of SM) integrate new fixes etc and decide to release a new version of SM I can do that independently and you will be able to upgrade (from within SM) SM itself when you decide to, also independently of other packages. In short, packages published in SM (including SM itself) have their own maintainers, their own "updatestreams" and their own place of storage on the net - so they are completely independent of the image. > Of course, monolithic systems have the issue of shared namespaces which can make it difficult to make different packages play nice together in the same image, so like I said, the problem is non-trivial. Yes, namespaces etc is cool and we will probably end up with it sometime. But we don't need to solve all problems at once - simple class name prefixes go a long way. SqueakMap does work pretty nicely already - and we all know things are missing but we are working on it. The next big step for SM will probably be versions of packages and handling dependencies (in some way - there are different ways to do it) between them. Before that though I want to wrap up the extensions sent to me from Ned and Avi, smack down on a few silly bugs and get 1.0 out the door. regards, Göran

2 1

RE: An uncomfortable question
by Swan, Dean 01 Nov '02

01 Nov '02

Colin, I agree that code management is one of the problems that is trying to be addressed by the modules effort(s). >So again, I don't think I understand your concern. Are you saying that >you prefer the SM/DVS route to 3.3 modules? Well, I guess that is more or less what I'm saying. > How do you define "modular" and "monolithic?" I save an image, and when I restart a Squeak VM, it comes back with *everything* exactly the way I left it. I call that "monolithic". Your point that keeping multiple Squeak images around is a "Good Thing" is significant (IMO). Squeak is a "virtual machine" and running multiple virtual machines on one "real" machine with different images in each is a perfectly reasonable thing to do. I start up a Sqeak VM and it goes hunting all over my disk (and possibly the network) looking for bits and pieces that it thinks it's supposed to have to build an image before I can do anything useful. That would be one kind of "modular", and I wouldn't like it. -Dean -----Original Message----- From: Colin Putney [mailto:cputney@whistler.com] Sent: Thursday, October 31, 2002 4:09 AM To: squeak-dev(a)lists.squeakfoundation.org Subject: Re: An uncomfortable question On Wednesday, October 30, 2002, at 05:33 PM, Swan, Dean wrote: > Colin, > > Consider the case where there are dependencies between the modules and > more than one version of each module. The current effort of > implementing modules is attempting to deal with these issues, and it > is a non-trivial problem. It is also possible that because of certain > interdependencies between different versions of different modules that > some modules may become mutually incompatible. This situation is > witnessed with MS Windows .DLL libraries quite often. > > One common effect is that some applications have to be installed on a > Windows machine in a particular order in order for them to all > function properly on the same machine. There can arise instances > where because of different sets of .DLL versions required, a set of > applications may not all function correctly on one machine. Well sure, incompatibilities between different parts of the system is always a danger. Certain parts of the system expect particular behaviour from other parts of the system. If you make changes you run the risk of violating those expectations. This is true whether those parts are modules, classes, functions or DLLs. The nice thing about Squeak is that you can have multiple images lying around. So if you need different versions of a module in different situations, you do that without having to say, swap out your hard drive when switching between applications. Now, this is not to say that dependency tracking, versioning and so on is a non-issue. It is a problem that we're going to have to address. But the ability to build images for specific purposes is a mitigating factor. So when we do have incompatibilities between modules - and it will happen - instead of "hell" we're faced with a mere problem. > And regarding SqueakMap and DVS, realize that these are based on the > monolithic image model. They are more or less fancy user interfaces > to manage filing in the various change sets (I know I'm > oversimplifying a bit, but the point is still valid). Hmm. It sounds like we have different definitions of "monolithic." When I speak of modularizing the image I mean grouping the code into clusters of classes and methods that a) provide a distinct and coherent piece of functionality, and b) interact with other clusters through well defined interfaces. Once that's accomplished (and yes, it's a non-trivial task) many of the clusters can be removed from the base image and maintained separately. I place that scenario opposite the "monolithic" system used by Squeak 3.2. Everything is really intertwined and you can't easily remove any functionality from the image. Adding functionality is easier, but still quite a hassle because of the some what artificial distinction between "blessed" code that's maintained by SqC and other stuff, which is floating around in ChangeSets. So again, I don't think I understand your concern. Are you saying that you prefer the SM/DVS route to 3.3 modules? How do you define "modular" and "monolithic?" As to SqueakMap and DVS, sure. They really are just tools to make it easier to move code in and out of images. But that's the point! The whole problem here is that it's difficult to manage code. > Of course, monolithic systems have the issue of shared namespaces > which can make it difficult to make different packages play nice > together in the same image, so like I said, the problem is > non-trivial. > > While it would certainly be possible to produce an MPEG player image, > with only the items necessary to play MPEGs, and a MIDI image with > only the items needed for MIDI processing, and so on, factoring out > the common components can be difficult. This is especially true when > some "applications" use different versions of a particular component > and rely on some characteristic behavior. A hardware example of this > is the 4046 phase locked loop IC. It is a fairly standard part, BUT > the Motorola Version and the Philips versions are incompatible in that > the external timing components require different values to get the > same frequency out of the two parts. The same kind of thing can > happen in software. No, it's not trivial, but it can be solved, and it's not even all that difficult. For one thing, the package model used by DVS makes the problem easier by virtue of its inflexibility. A given package can contain classes and methods. When a package is loaded, it can create classes and it can add methods to existing classes. It cannot modify methods belonging to another package, and it can't delete methods. So it avoids all kinds of problems that can arise when modules can modify each other. A second factor that makes the problem tractable is that Squeak images offer developers much more control over the execution environment than, say, a desktop operating system. For development, you can build an image that has exactly the configuration you need - all the right packages, of the right versions, loaded in the correct order. For deployment, you just distribute that image. There's no need to have users load your package into whatever randomly configured system they happen to be running. That's the situation that creates DLL hell and it just doesn't apply to Squeak. And finally, if you do run into a compatibility problem, just fix it! The source code is there, there's a community of people willing to help, and with SqueakMap and DVS, you've got the tools to easily distribute your fix to the rest of the community and to easily benefit from their efforts. As Daniel mentioned, we've got a social advantage over the commercial world. Cheers, Colin

2 1

BitBlt question
by Stephan B. Wessels 01 Nov '02

01 Nov '02

I need some direction from someone more familiar with the particulars of using BitBlt. In my current project there are 3 forms: srcForm dstForm maskForm of which scrForm and dstForm are 32-bit depth and the maskForm is 1-bit depth. The maskForm contains black pixels in a non-rectangular shape. I want to copy pixels from the scrForm onto the dstForm using the maskForm for inclusion. The srcForm is smaller in extent than the dstForm. The maskForm is the same size as the dstForm. I've tried a number of things, and frankly went into this believing it would be very simple, but ended up implementing pixel copies. There must be a smarter way. - Steve

2 3

Re: An uncomfortable question
by danielv＠netvision.net.il 31 Oct '02

31 Oct '02

I think if we ever have selector name spaces and such (that produce the capability I call "co-existance") there should be no link between the name spaces, versions, and dependencies. To try and predict and specify in advance which versions of other modules this module will work with seems to me very similar to declaring variable types. I think it's the same sort of decision (I think I know what kind object will come here..), with some of the same costs (maintainance, cost of change rises, opportunities lost). Anyway, Squeak is very far from being used as a typical OS, and maybe never will. The real question is, does this technology, that will require low level changes, and will require people to let go of some important working assumptions(1), solve a problem we actually have, right now? is that problem that big? (1) example - "if the debugger stack says I'm in Bla>>blur, and I'm in the Browser, looking at that method, and I haven't changed anything, then I'm definitely looking at what was running when the error happened, because that's all there is". Let go of enough such assumptions and you bring the barrier of entry into coding in such a system high enough, that your community will change in ways you might not like. Again, the tradeoffs for this decision are very different if you live in a closed source world... Daniel Vainsencher Les Tyrrell <tyrrell(a)canis.uiuc.edu> wrote: > > ----- Original Message ----- > From: "Colin Putney" <cputney(a)whistler.com> > To: <squeak-dev(a)lists.squeakfoundation.org> > Sent: Thursday, October 31, 2002 1:38 AM > Subject: Re: An uncomfortable question > > > > > > Daniel Joyce wrote the following in reference to Dean Swan's post : > > > > > He's implying we'll end up with the equivalent of DLL Hell that Windows > > > ( and to a lesser extent ) windows have. > > > > > > Linux survives in the fact that diff versions of the same libs can live > > > together happily by using symbolic links, and ld. Simple, and works > > > better than windows registry pain.... > > > > > > Modules MUST support version dependency, and different versions of the > > > same modules living on the host system if this is to work... > > > > I agree that packages should be versioned, and that dependencies should > > include version information. But I also think that having multiple > > versions of a package installed in a single image would not be a good > > idea. The benefits are not worth the complexity it would require. > > > It is a bit early to state it that emphatically. There is no evidence to > support the notion that having this ability would be any more complex in > practice than not having it, as we do now. You are used to the situation we > have now... so you think of it as being "simple", by virtue of familiarity. > As long as we arbitrarily ignore the vast amounts of code which are *not* > routinely packaged in the official release, then certainly we can "simplify" > the problem. However, if you now want to consider what it takes to use all > those other bits of code, then we find that there is a fair bit of missing > tool support to make this job easier. Deliberately choosing to neither > develop nor use such tools does not "simplify" life. > > > > Consider that images are not the same as operating systems. Linux can > > have multiple versions of a library installed and allow different > > executables to link against the versions they require. But you can't > > have two different versions of a library linked into the same process > > space. The Squeak parallel would be to have multiple versions of a > > package available on SqueakMap and have different versions installed in > > different images. > > > Or provide the means to support multiple versions in the image simultaneously. > Nontrivial, but feasible and already largely demonstrated in Oasis. But at a > higher level I'd reccomend that we consider that OS's do a lot of things much > better than what we are doing "within" the image right now. It is worth > considering ( as I believe Stephen Pair once suggested ) a comparison and > contrast between Squeak/Smalltalk/image and OS/file systems. To wit: in an > OS, having something be *available* to use is not the same thing as > *demanding* that it already be in memory. And when done using that thing, > it goes away. Compare that to the way in which we currently manage our > images. There is a big realm of transient things that are not managed at > all- we load them at some point, and from that point on, they stay in the > image, because we do not have tools to identify the extent of these things and > what is needed to remove them. I just don't see how deliberately deciding to > never develop such tools will ever be a good thing. > > > > Now consider the complexity supporting this would introduce to Squeak. > > The VM would have to take dependencies into account during method > > lookups. You'd have to have separate namespaces for globals. The > > Browser would have to present multiple versions of methods to the user, > > the Compiler would have to store compiled methods in the right > > namespace etc. That's all possible of course, but it's a low-level, > > far-reaching change with deep implications. > > > The specifics are not exactly what I'd anticipate, but the gist I agree with- > very deep impact at a low level, decidedly non-trivial. However, technically > feasible- a big chunk of this is already working rather well in Oasis. > > > > And then there's the complexity cost at the user/developer level. Can > > you imaging debugging in an image where there are different versions of > > the same method floating around and the version that actually gets > > execcuted depends on the class of the sender? Dear God! > > > Having method lookup based partially on the sender is actually vital and > neccessary if this is all going to work coherently... the easiest way to > understand this is to ask yourself, "when travelling overseas or in another > country, do I continue to behave according to my own culture's beliefs and > values, or do I adopt the behaviors of the country I'm visiting?" Things go > a lot easier when you do your best to respect and blend in with the local > customs. In our Smalltalk world, this means that objects crossing domain ( or > module or whatever ) boundaries need to behave according to the local customs > ( ie, methods which may have been provided/altered for them by the > module/domain they are visiting ) of the domain that they are visiting. This > makes it trivial to reason about the behavior of say, OrderedCollection, when > instances are zooming through Module X or Module Y, where X & Y provide > differing behavior for OrderedCollections. Also perhaps non-trivial, but I > believe that Stephen Pair has some form of selector namespaces already > working. > > Take care, > > - les

2 1

Re: An uncomfortable question
by danielv＠netvision.net.il 31 Oct '02

31 Oct '02

Of course, it's not the sort of argument that validly proves my point is right and yours wrong. I'm highlighting a trade off. We got lots of flexibility for the cost of classes (which is not negligable - OO is harder than imperative programming, for simple enough programs). We do actually want software complex enough to justify it, so it's a pretty good deal. Coexistance of modules adds yet another such layer of ambiguity. Ok, that's a cost that's not unthinkable, but also not negligable. What exactly are we buying? how do we make the cost not hurt us too much? I happen to think that right now in the Squeak community, it is very rare for a person to want to load two versions of a package, among things, because most of the time people are working with either their own code, or something that came in the specific image they loaded. The situation is very simple, not much potential for conflict. As it becomes easier for people to publish, maintain and use projects outside the image, and for packages to depend on one another, we might get to the point where conflict happens more often. Eventually, the tradeoff might look quite different. IMO, open/closed source makes quite a difference to the trade off - with open source, it might be easier to fix the conflict between the two packages than to live with it. This is much harder with closed source software - you can't fix what you can't see. Daniel Vainsencher Les Tyrrell <tyrrell(a)canis.uiuc.edu> wrote: > I don't buy that as a valid argument- the same thing could have been said in > response to the notion of having classes contain subroutines. "If I am in the > debugger looking at subroutine blah(); how can I know which blah() I'm > looking at?". I don't think the solution to that problem turned out to be all > that bad, and I don't think it matters whether you are dealing with closed or > open source. > > - les

1 0

Jump to page: