From xmath@nubz.org Tue Jan 1 17:49:13 2002 From: xmath@nubz.org (xmath) Date: Tue, 1 Jan 2002 18:49:13 +0100 Subject: [Coldstuff] Frobbery Message-ID: I just got involved with Cold so let my begin by saying Hi all! :-) >Frobs in general are useful, just not as VR objects. Sounds like waifs might be more suitable for this purpose. A waif behaves much more like a normal object and won't require special handling, yet at the same it has the benefits of a frob (in this context). A waif is kinda like an object, except: 1. it has exactly one parent, its "class" 2. it only has vars, no methods 3. it has no obj# or name 4. it's automatically destroyed when the last reference is gone I'm currently working on a patch for waif-support in Genesis - xmath From bruce@puremagic.com Tue Jan 1 18:08:19 2002 From: bruce@puremagic.com (Bruce Mitchener) Date: Tue, 01 Jan 2002 11:08:19 -0700 Subject: [Coldstuff] Frobbery References: Message-ID: <3C31FB13.9030301@cubik.org> xmath wrote: > I just got involved with Cold so let my begin by saying Hi all! :-) > >> Frobs in general are useful, just not as VR objects. > > Sounds like waifs might be more suitable for this purpose. A > waif behaves much more like a normal object and won't require > special handling, yet at the same it has the benefits of a frob > (in this context). > > A waif is kinda like an object, except: 1. it has exactly one > parent, its "class" 2. it only has vars, no methods 3. it > has no obj# or name 4. it's automatically destroyed when the > last reference is gone For those who don't know about waifs, you can find the definitive information at: http://www.ben.com/MOO/waif.html http://www.ben.com/MOO/waif-progman.html - Bruce From xmath@nubz.org Thu Jan 3 17:39:52 2002 From: xmath@nubz.org (xmath) Date: Thu, 3 Jan 2002 18:39:52 +0100 Subject: [Coldstuff] First version of waif-patch Message-ID: --============_-1202042902==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Here's a first version of the waif patch it's not totally done yet, but you can already play with it an see how I implemented the overall structure. Now would be the time for feedback :-) Note that I'm not completely sure where to send this to.. if there's a more appropriate place than this list feel free to correct me on that.. Getting it to work: it's a diff from the Genesis-1.1.9-STABLE source tree to my patched version thereof (Genesis-1.1.9-WAIF). I've never done this before so if I didn't make the diff right, tell me how I *should* do it :-) you'll then need to fiddle a bit with the core.. to create a waif: the function new_waif() creates a new waif, with the sender object as class. text dump of the db won't work if it contains waifs, since that's not implemented yet (and I wouldn't trust any text dump made by this development version anyway). I also haven't done garbage collection yet, so if you create circularly-referenced waifs, you need to clean 'em up manually or they'll stay in the db for ever. You can destroy a waif by calling .destroy(). A waif will also be destroyed when its refcount goes to zero, currently without notification.. that's another thing I still have to do. Note also I didn't really debug it very well, so there may still be numerous problems. Oh, and it'll generate a LOT of debug log output, you might want to log to stdout instead of a file :-) - xmath --============_-1202042902==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1202042902==_D============" --============_-1202042902==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%waif.patch.gz" Content-Disposition: attachment; filename="%waif.patch.gz" ; modification-date="Thu, 3 Jan 2002 18:28:37 +0100" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAA0AAAAJAAAASwAAACAA AAAIAAAAawAAABB3YWlmLnBhdGNoLmd6R3ppcEVaZ3oBAAA1AJcAAAAAAAAAAAAAAAAA AAAAAAADx19VA8dfVUttDAADx2H6 --============_-1202042902==_D============ Content-Type: application/octet-stream; name="waif.patch.gz" ; x-mac-type="477A6970" ; x-mac-creator="455A677A" Content-Disposition: attachment; filename="waif.patch.gz" Content-Transfer-Encoding: base64 H4sIAAAAAAAAB+19a3fbRpLoZ33wf2grE5sUSZkPvTVORpZoRxNZ8pXk5GaTHB6IBCWM KYALgHa0Gf/321XVbzQAUvbMnj13dWZiCV1d/aquqq6urppE0ynr3LDOhHVS1nnPttib MA6zKOv0Nnub+52r66NXZ8MXWTp+cRPFQfowudkcOzA/H52+diCedDqdZTCtXd8t2Hny kfX2WHfnoL93MOix3v7+/pNWq1XfzNrP4YT9PYgZ67N+/2DQP9jqsn6323/yt7+xzvZW u9dlLf7PHvvb356w8V2QsvFoPAuDeDSNZuGv/e3t3w+fsCcsy4M8GrPTOGeTG4KA753w jzxMY3aWxLdQkCfzwyedJ+zFBsvvooxFWfw857+G7D7JcnabBuNwupixT8FDm90scraR 3aWL2w228eIJ+2YSTqM4ZD8fXZ43Rtmoyf5kvz1ha9N5GsX5tBGmKXSqzXhZm/dzEqUj GmrzEAGjKZNA7OlL3ucJ/6vJi2Cwe/vt3j5r7e22+9s4WvlzE+X3wZy9ZMO3R2dnF8cN mIY2a9D30c0sGX/I2Au212z1qCH5cx/eZ2EuANusW1vpM0yZHGb2EI9HUTwJ/2jQSDsS b3Lzj3hxz3s0S5IPizlfijTLR/S1gdgU6Kc7GGxD1OCDPr+4Hh2dj05PhufXDlr4gSl6 KtCmYZ5G4cdQYqZ/2uxZMp3ycfFfsui/wmbTxQE/r49OzxrrJ0Ee3ARZyHAYrPHb+rfZ C/z9t/Umg/WPx0nMKTQP43zzt3jd7rzskOj9dy8FCXlbpCI+KQK6xXoFZBzmPkg/NM4u 3pweH52NXvHl/LFBw2m2GQ6nUMmd7ZjTtH+yP/M/WmInfEyiibOET1qIbjod5Ro5tn1I RbB79A/0RhTg9nE6xIsEwmpqIKA6OiCox1KArv1Fa293QvT1r7BqN0meJ/dOO+q7WnQD QziDpn3EU0BSIBsNsRTBaPBqUpF7vAXbXHGzZB7GI94OBwvHedYYjeaCsalOiJlElsuR T6FKY6rrcI7HK1msB1fRqij5XG+v1+71WKu3ty3YOpJqFEe54Ja8Nw34BmRBlJini3GO PB7/CvKbxVQMB2WC+jE69evZ6fnw9/YTVvwBKKQEgjmkHeTfGJ2yjdEp3xhMdFvIBVNi tRmQ4SZ+WHeFBFU7efX69Gxoz++6+G3dA4QjafNv6/gbgMA89/tdnOd+v1eY5zj89L+T /KWTPFlB9RoH47uwXO8SxdVKlwBau16E7O9cR+kNWH9w0B0cbG/Valyybp26tYfa1j6S yxqfsHEefQx/jX7fBE7Ct775aZ6GH/mnZ8a3Q9CGkpQ1/sELuofsH5x7YtOjSTjP7/iH VgsJbk2spKHVXNz8o816MPWysPOd4men5z+NLl79/fz9W87tdPmngPOZlyBoX7xgccKg k8GM6zZBHk5sokT4xThZxFwhfNm1mikZiSr3DB4+FXAoSFVL4eZfaFvubvPpbe3uiEl+ wfVK0C2fMD5+tiFm6zbMR3fJjKuHDSR+mgeYObVTOBlqofGtqPcpmvBZ1sKcgBoLQNIs AcbZwcaxj2JbAf/W440nggKeWrPEP9NqcnX6PRd3oEfTHmIBadV5EM34LsffZT024zJ3 E0YN87G/C0S3vyeJzjt19LsUYCRbRbtHYrlZwDhXE80jdsTlI7DWmk08WvfFXzjSsyj+ YI0G/7gLg4kcjBgKZ4xRTK0VqMmYJVr6nuDIvX6/PegrHX8UCKpstXhXvgljzlhkX+xd YCkZlorSVSoUHjKeqgEKbQPpNJymYdjAIj6/Um9wJ6NlzbHG6UUpkRnTPPwj1zNdaKAr G6B/aJRczVvwQxrRH6xDC+lRkCmvOOK/jD80JJWqwdpjZf/8pyBtAseC8XgWZJlUEdfM pqgHLbHmD8mn8d1ThuBy3bmWeJvE4VN+FOSVYN2xHb7cLTX6CVCFnjnB7qJsHKQT6ELT aki0f/7+7OwQm83u7trsU8iJ92OYctVqwbcsHk1VS3yq4MAKvIJ1vsoPsR2O7jL8z0WU htkB5xZRHgUzLnQnNIRNItnBdrvPj+C97T34lziWXHmYofAPvpl5Z6P8DufnlpN8LAh1 U7M3Yz2lTv/fwNk6nn1T2EwvTWnTfKJIBpfM4BFXYZCO7yxGwED2mRwI9SCQh8SJXHZ6 iCLwqcMrhFxUjJBYrNqCupt67ozNmIbTDBlJqfBrveRjGx5fj94NL69OuYJxfjzkmtaa uxNb5pfCXiTKZmufi9xTzIzi9965Qera5QyRc//e/gD+NY0eS/aafcPn5WT46v2b0fHR 8Q9DG4GXs37FgR4DLLuPsmyTnzqBJINYbow84YewAPRtNk35EZFzhA+WoOBLXBD2YkVN MrsE9mKIIq7sJvj3fBaMww5VbAMBR/lzzrhipyWgG66/8kYAe1sSDe44mxuu1cxAUfZe JHMY+WnMTwuzGaO+oOgXYt8hgYDPkLGbtJQu0fREmV+1EjJ1vwv6Q783AFOh1iCEELZV GKFErJlKna3O1LRpq3Ocovhk8IkriFy/uFV0qUqahsB3+AzRGh7kBj1QGfvbUmcsoXpF 7Z2OQe1IA5Kjqnn2sdUCSy2DNolzGqZhPOYLDE2zuygHtT8N7xO+6Ej3NYqSb12ZpXj7 9ECclp29dq/P5wWYR99RpkFEmKrA/zBZ060RNF9ZusB0Dvr7sJEG6viHjO7rqh0tjurT XYB6Feo4/D98XfgYvuffE7bIwoyzse/ZJGGnXCPiukgOh7rxbDEh1Sv73jou0RKgwdE2 ZhjrvdpBHUxW+J/yw7oBUn1gNwDdQ/v2wWC/9tBu1jcP7t2DXvegv6UP7js7sHQ7kj/Q zxhsn1fXl6fnbw40ZWV5Oh7fzxv8Xz71IzDsZI1Jj8vZTf4JTIpWQV8WaJkkMBPNHkjb I36DnhttCbza5kvoXCEnKp9xoW5UhkPiCHpKSODPtkAAvzflkQqPj73+XnHs16Ph5eXF 5YFvWwmQ15cXryqH0HNrnJweX1tDhA5NojFnUx/Ch6zz3Yyrv3yoXdnBbVwb0J/rF+cu yO5GYgHiBGAIPyzAI+Z/ome7bLKBF+FM827f5nfUHM4v+w4YFjLa3g6J2H3JZz3dYGuT MMuN5X7JOAlbHVi7ScPgA/Sk2OdWsToqIJMFJ1UTDx7fBaKWd0gSEYwCLOEwOgONIB6j NzjG3T6Ocdc3RoOQokkY5+p0B3sTcIZpmqTN2iHSiJy6dcMiEuXD4vCq8jNZm4vYG9D5 59j69evL4bBhlkmLmkCNjL7Hj3Rcbg76O+3+DqlMmjkA6cFsSSQVpCd5LXNNxFxGT6M/ fv2dz/6fz//yvM3wxrKJms3nQ/Nyi2xepjKsTofF+THauiAiIUKxIS1AE7+4hOmy792m UCk4UAe8jnMbCdX/+U+tEAX3IQjuTk9pEobVGu9e+BzmySjIxlHkjKPN4pvF1B5NoRFU egottepaMtE7tnixIl1YkuffPLfKlUrvGQqRO/SjYQ7f7n8ZsDkMu0ufNUGVmUwsAJs8 g8lEiCfxAfRM8YUGClTPJRkKM87YGllTt/+5ZHPabRgo1/8K+/a79TbbaZbxnPLKvwK/ +V1UtrfR1S9vX12cHeCm3Oputfs91triTFbYWZbfcnzQsK5/sdcVaJ8R9Vt7Tm6exN0s ZoFnW1krAjQ7nQW3GXvGTl6Pfj69/gG12KO3wyvPtlh5h+tKSfm+dRD4t/CjtjE2X8td Vti8nvsxVfPZM6cREL3w1ZxhfUy4ajZ96Iwud2hpPQBFppFUcA2DthyeUcU3VuYdq/MP Dw8p5SOeDuOG20G7wdbulrQ8rfHdK9YbWcws4kfpYAZTxUuA17RZUe62GS4SCtkCmxpT reffPa/hPyZ7H4PjApuge4Xok4/xtRkxJiYZk7qt38wf5rBo6r5MlxjqVSldLzUNetit mmG35LBbVXo0aNClzcmuApAx3xa+V+9fvx5eCma6P8CLzN5uUedGjm2dMaLJoY8tq2E9 3N8kswKU1AklGKqABShU3iQI0AxCFJfflnOoJ7qocMLM6YoS9JVw4cRESEi+saeh0bFJ OA0Ws/xgbe1PdnpOZtTR5fD44vKkAXTTZlzfkx1JO99FE9yRh0yZP1c+TeO+rjlOC5gl ztMC0jpQ9w+2+gdcb1/qQC0ROCfqwUF/X5+oyeSG/9UElCXjDyEQTJvdRPEEf8nC9GM8 xV8/BindhuBf1hK1GT8cEphExok9DTOC5UrLIgsJYSxayKP7MFnQ70l+h2vIiT+IZgQo 8dyFQZrfhEEuMN2Gf8ypi3LlOU6+gqKTWTAjyOkixg6auJL5OJmEWHwf5ncJ9SgCmyKX A7nAlkW3cTATg0zDcZ6IMYYJjVAIhJtgDD5IkyQOTbK3P7cNan/CTmFt2HxxM4vGWDhP k5y3IOZmnkYfg5yqpUlCA5nwj3J25qHosTXVcZJICHKI47+A/6Oc8QCsY4QgSeXXIE/u sRPyiNjrb5GpYcsgCoVGyS8wtK/TZ+VHolqwoeizglIt2lD0WUHZ02eDGmXKm01Mrw0I HxXGq+Hwx9HV8LoAJQtsyOP3l35IXmBDDs9P/JC8QEFywoKtUAAU31d1tMEtLq6ZqlmO BFqC50hQl+nsHgy6yzEdjeFuQVxnwHrdg8GO5YDT67f7SGLtwS6S2DdRTLbP9UUezTbv 1s1Ps+TW+fKfi2j8AYxI+P1J65tFzPk9Ex5OI9Ao4NYKTfVgOP4QhnMwwOYpJxy4r+H/ C2Yw8Q+dDK3OnEcKpyg2WYB8Z+J7hiboFtrEheJFJYeilR857szATHoHtIoGf3WbpbwL CaHhqC28BeQX5WrZ6XW7spWfglk0ifIHcf8A6IlzUZ/Ah2Wchpz75ThOsDkTZBR/hKqc m2TgMcT3ivC9YRyWHy/E+Ay38vEi5SpJcD8Xl/22py3ZdsKbxW0DvEpzOpxt3Ge3bbJC fMIz/NqnlCs4I750jXWgELrFYd98O2ONRRbchuzbSfOAfZtxre6TvH/BX7GU8+XsFnY2 qFNf0SsAr046HNMQ1JgO3pnAhCUxm3OpFucZmexD9o/kRrrAjPm8ofleSJJNxo5mWdJG RCAZyLyfsfvggd0F83kYw6FHX5Hyod2EKZEYEIcgPeFTsInXBcfJ/T3vRSTdEwJoCdcZ rwPwSlFQqHH/01GGH6D7OPxkXgC12fgMbIMbcmzqAChcsDj8ob26Y+zFCHpBTigAo851 huNi5Lv6oVPgk86aVr6RwOFWulPjK9xZ8zoId6gidKPyHllBdb6TC2mYROX4LbjxXTTj qkksAWH2ulKaEAjtdA7AGeXlNRcRR5fHP4yOrs1bK+1QAopRFNzM+E7L4R9cM+BS9Ke+ yyLkHDrb5CWGS9FP8N7hp6PLEbZ3ev5mdHX6H0MpQYxqgNWuytfGXxUPCtvtLXpfsi/u ju0umI6PNO/yCFfs7q+FRliH9VT9Tk9ZhcU0JzFMMVksjO/Cx1p8N0v4luKMzvA0wq/g Hh5OBK/8TGwRd85Xua4z9yC60y7mJZsPgYFleneOqKs8uHgVZdPEK1Y1Vk46r9NQEw0q r9QUnzLw1ResWd1+RuRrGrG/is6IRUEPYhaRx2lLOtDocrnAYKh5qqyseHVvm/nLajWl 64htm/eBc2GD0J8t7zflB2DBy73mKRX03fyXLfVX4f+tr8f/JUmtzM9bBX4OH8g3kW2g m0GryLtbvht64N0tH+9u1b3zWCt/3OFWI/eAtXkQR+PGuh4ozjKfInSwi8NbPDIIdKjj a15QKQioUWRFxDf0FAgMhohD6WaX1osQ2UKFBPEJB1LXKkSDIZoErCMdxMOF+znYit4O r3+4OClwew+SElmxPIKbWRB/yIjzeoqB/fBCHz5zsh4/piKO1YZUrG+OqFhaOSDmY8de UMmRO2ve9eDcUohLF0Cw0nslHUsAbIndWvNNkW7FKS804i/3agV+Sv3VNwsF3cBLEMtV 9epcZI31byMqywwyuSLbLRx9HtrCL6FqCwgMI0ESvgoWPOdBI92qRV2P7EwBQXVfNHih K97pQwUgmkZh6p9CLDc7jZYr2Wd81HhVNYFUX/bZB1+YP9Vk11L/q7RxPepH9detXt1d e4rN3uoZPpoI53btJIuahBQY6LPB1QshVSx/QRCIizmc2EeiGOVUm2RMMJk01dmL5kVd whE3KVG9OyWqtzXFruptX/KZu1D60KLOgZc9+Mil397aBi+gHvxruiqikixGh/qeoyEz U0MuqDBivFJnlvIZlWVzTjX5kuB2FFvnHOiFkfjUSdBW7EWPC12qU+M7q6nxnSXV+M5q anxnJTW+I9V4sy/o+UsmHm0KWjdWdr3N1CSZb1Fs8VF6JOjUHwm0uqZcahGOVD37eFVN Kq0lSKUIYyl/lhM7NikFW+2ymwpHycq74ropllBcW1jTVIA99B8eC8qOc3j06gnS2dts 2A9Ytc4GsH+pHfXFPiK67VWU6vp6cU5o+YTKsMT6GCK0ZHlEKQwcHMjE4kj3MoekHOCq 1fG1bCyO22zL16wPsmptBKhnUnVJcTK1ArHkhJLALJlPKoTecmnhCZ4A8+tndmbN2ql1 +mDMbF0HWoUOFKrZj2g8E03AnnlWBV/XJ52uXLb20PGzu6seVyhtUN4QUHwY41rBMFnK SwF8YWQ/SrTEgsQqnkYYD3pABIn3O3D0ZUkcumrPJJyNhLZhClqJ8zqczRRD/xSySQJB bdCKwvn7A7tP0lC/udrexdckvcKAEY2SBdDDDGQq+eg34kQZepCAQI1rs38seBuThPe9 uSmuWzfICsTQiEQGnwf2gZPNXcS7919hmsi+tsWDIPoTxs/1wWSRKkTK9oSTM0lCYy8Z RgZXRTGcWTxQlpRS0ziG8bieM0aJ4TkjESnHOLWnJtLiQS8StChkE/4/bQ75Q5e12aQp n2D0hBPyoA/PhNEezQl+jc+dpYGyNdvR6QPtLcOuqF/v+pQRcJBOk4eCPmK+bLtJEnrA DbpySKuexJbu3qBVIWNdU5Es1DSJFL2ruwOkOeuFgjYmObqFWhPfnCr9oziliqpoRtna 3ONzaDkcdtbmlrWqsYHYknmzYRS02TOkATTgzh0CKtSySo2qDKpWrOJcr6F897WFb9pa g+6OpAdp6BQrGcRjvpZJmlF4BfeVE6L7AaxpsJnkIyXCwT9Ar+U39DkDFfhQW06196jW 6bO7JM3ZOErHixxdMJS2aBdGupQVLaqXF1x8iEdPpnOk6bIPRsOe6cA38e7Ogl+bgVv4 u+/A04vWFt9Vmvi+lLTwVWXnO+zRU9mlpniHK520WMeLHkiBON5L+4kGyfyn5rs1AmwK 71JYcy4i1LqL4rbDkuCxO6H66ejs9GRED2cfjWvJQbkspE5+4trsb7V7/QFfnW14zCcF Epx3JYlPJkLjM0/GXLpc5SnbQC3POiW3GRoxTauacWJ2D0W6t2/C3BTKtFHj5FObZQnI 1HEQK/c8MMUHdB0G/DEbR/AE0jVW2Ltdh5ZIkg9IfsLYSoGx1I0LlHC08C6fTx8QCY3+ S7TypyWatrwmWVHVfurToNUjdDn9EZ6T9T2HfFdGb880mbl4Xr6kYBadNXMqDSj5wL1V hd3bRYlaPM/9w4/XIveo5OX364jrSvCiWYyX94ETCUVv4Aqc/fyaQAzbhDsqBMBOamdf fLKER5NSeOixMEqtWaOpxucH1siUUy6WeHb2MWp2XFfLwlCM/C4ApTZhYTwL0ttQxH6x DKcYUQaux5zRoFXROy/S3uj9vMH6rMXImjk6GZ5dH3lmCgyel0OyeDpFbWbZmXld/lOk uJEZYk0NoWB4JrLy2aOL33w9t+ua3Ta/u31uiT4Xu+NZNbK96psBMr2GsQpp46yXf4N6 CbRipxJJWRAGZ9G3qH8s1VKrbOO6tlmnDds4G8mTpGl8FXqYV9iIR+AoavyDhTfX0A94 et8pHAILYETudfYQgC5jAbLQdiGpEHW2dbCk6/r86ochMq80qOhOO3ym0GObQn1CEwtJ 0otVgqvtpVZIR7bwTtuhFY3HOhoWQakfjlKCRglHJ0GXPyyo1Er0C3XlFr2UjvI2SD8U lBTwx4YADJwJfwKhdJ9MoukDnMxAPMGJPsjCbEnlBLQgrn0Yt1901LcuxAyFhESc7blL 4/8ilUc39rVtZ/Zryi81hOnnXZWqT1lPKF6Bpcd42xBxDdbEdP4cKk8ZErsYyHiyydj7 Oa5V6kTlSGKDap5nAhN4xiTzBzKugCs/GS4Rm7T0PM8IJiEYI34LR6jxUIRVFZlGNlRy i7qmiVCPVGt11pWjq5jZNkZhVPw3aWuiR0JfElR/WApQ0M5K6ntL//3amHHF6xu2q4uZ X6tVMX317GpiVNJm5l201MN83fJqYU6/rdm0dLC6Hls1CxqYt6+ttTXnCWKhS19REbPZ AtGev7xC8SIgW+/yIPYVlulZGuUKapZHfJZqWbIL1UqWC6W4/ApKka8lRyfyNSMW/8UG efeHadpY/+Yb34jZtxN07i9yDUSIj5esZ7AekGbzEIxua4XuOLU95VRVvY+uvjISVdTj cX85sy+DlO294jZIIW4VNk0p1iWVRWkBlbpiBZmVaIp2Pyr0RBew2AFQEz8Gqd08AqDb gSQcrSKMpvCsEKpIaNsYRy/5mhSWZXcPw7Lsbe+0ezvKsPmWzGwbZG5rsw2Ijjob0Z+W BXhDm9u1CXhjYl1j+eKLCuWzYFq3XU1Nw5MZMNQKcqYQ2hcrFLJTFhdedVtXFq2ilokV JozrkgtDtAv740t5U+8EClWz2+Zyn2+jDKI43Ej2DYOhekaQLjmnmLxhi8LY9rfNxaib aHUOIIj/sVNPKohzNbr8hAfTHEMYrjjn+1v99gDC6Xb7e/LBnCR/cz+J9nEjlOzFNnuV JDPVA/vwFqvnsIfFPVbqWF7iIWSHodVhYOME3l7HSS7U0oNOU12tlPr0GHe3KVf50iw0 nKe5KgGHBAiCkszxmR8ph7dwxmP3QT6+kycDmAJDNYz1gQ7QNYhbfev3z6E6arFLHFZE cMVWJf6iAw5VUMj9nrwUtlFphrSGcG6C1/dchPxC+iwe9g4lMtTvD8v7DZjpd/K11SZp +PqyChyCKdS0VvAQcpvSTkUvS2Hvpa1a7hSujomgIzijoEo7gqu0uyqMQWVjn633T+rQ 6k75LyIGzP93Uw5BW+jr/SgYj8Msg5K3VyOYFvbvWZD/nXec96f/pnm3TjwkWtGVoyui BfR6Sj0rnIVAPyS0pWLJVueaBbl0x7WcVUWQUifsx0a6N/LNUUKhSNYLDqtWBPd64fQY TyqaxMF2e28Aswi/6Nt7wy1KzJ+cOhkrSLc9NdskwYgGrtkMbgnnYNKKckb/gLUrTcNs nsQTEJggYpQzkseA4lKTfD9jGRkLrqMuFFuD5YSULCDz2mAt5muLg1jD5/r380UeYnYD NF6QFQ5/xT4Jp6g1icGzxUuMHuIt8ZpnV/jsNUZxm5kvlPi+MRovPhoqa7n4tqZgdylv k4nLLwywIVpv+kZjvIoqG5EAwcNhu+TJUGnX7MrYrTW7T2IlL8MpGCLdp89rrhla1iT7 s3MTXvFcakV/aq8uVuY0TQwXtDTVu5KO2S+kqvXBmqFxGDKnGzf2FQ+5VnHo9g7e67jt G7mnP/awKzTVqrGoAaOIEfufa/Fi+5NGD2ZCwUOAFWRcnxfsbZ5grJ4MbIox53CCMah5 KSGIAskV3C8qnuDVk4B6iKf64VsYXyfKp9l8n1ezFPKNHp9RL6f7VbEu92FdEVw9kPQf hTxvBUuRO7AKs+cQxDw9EbzWJEnfY01dbissBIZ2JbIo0C+Hdql43iRMeYt5oyBewZYt iC/gR1fwCSPadI+T/pl0DNS10yw3iUi/1CklPoC517YH6LtQoaxDqGcJKt/FFslMd8b/ grOyJ9555Hu3cIjXswkK38qn88pprGDS0NjvJTgsGMy0II2l5V0sO+CXT2sZKxU9K30C bXerzmpsXO0bOmWN2RYqbXD087Yx9kfagbqH/1JlWlmJKOWtyMY1Cf/oCIli3L1z4TJJ FkB6SprgzSlHF0+CdKL04VkUQ+ARejMGl9K5tEEBenTlXWSgRZtSCYpEyodwhnGZFL7E 0tRlpS8zS8HyQI6PGi1E+QIc0orKQ2xZdaiKgMYp9lGWLdlAlbpQ17nC5nF6Bnn8oFv4 +bDqHR2yKseIVPH6rQTcug/lREfvQJAmEv5LANbHu+j2LkzZLPwY8mOYyMQM1/Nhzhe9 EIcWM7zBEwROQfwshL4IN/gvJ3xMGjFLbjnBRWMIGMhp9z5TW8HoSTD+0NYX/xpJJsL4 PVW05qSBLZ2q+5EM0fv29QhSszrJXSsnzlO5EBdX8AfxwFh6gCQ0DvBJlm4bUa6cK9Rj RPdir9iJZqUGJ0WXqWg5qEsG1yzXy2ykxqAu6WUUECsmjsGMe0VrNqi8wWQiXgsBEEln 7Y1iikz8tiG2Sp02sfYYWakUmbVKTYZEhNWdSmVibTW5qHSXtXLlRRkVyt3A9FqQtSyG iHNhEFPwPMWcPwUZyxZoaANDygPjUjPMw4l+ZNbf6bf7W6zVg9cXItehT9TKV21mfB9L wqZhtpjlRtAIChGKMWlXE7BaDFpv7drySV6Ue2078pX/00KocNU1lawa8Ng39zp8tarm v3R3omMLzdu6cBYghkeCE7pqmY65Ibjt3pihtj9LPwF3JoynFb7+mU6OFpUVPUSoox4t jJ9pi6TRNtbeTvQj4tObhFCqZikqgOeEaPozo059b7mCuVnI1Qy22TPxNsZh1F0dLXZv H19v9ba6g/bWrrJdCvZNLnN4+cYP9jhvsmXRKjzKsZo0MnJZZwfgiJhcb8H//ynmEjKd J1wotrl85bINwl9CnC2TwO0g+MUDXsvM7VkJaS+o1Kg7hcijFAMTHiPCwy6ZakAk57Ti dRnhuqpjW3U6OjH7yqGsqGVAa954UxkF4tSeTkYgXfGSUg4EkkuLBixHETEGjNEmx6ry 2Zgf7KF70yQgmLkk2D3lwVXoFm+CnnY26zKSGuHGZWeNWKYC/gt6CxtazmWno/tePa2i YT0Gva+xtsXqSsdWcVfBtwxXPsE5FiKSQMRr0CSC7ANY/+n3NA3iW8o49hy9YSEm/epp X1cMln4z5xpqRdRiUV4TsFhAORnHeoOD7SViFavKOkxxt3vQ7R107TDFFKVYpEp6wr7h mz2KQ3Z88fbd5fDqig3PoUMnuuTi8mR4OXr1y/Xwip2cXonSJy1ZTp5zN0kya9y0p/Mm m3JFf9xo3DTZ96zHDlgXwns3dQVg2gQP0A3OF8b4G+be0mBw2BJoORRE8nuCPtTQHD9w 8KNA2rl5APsqBiOE1Z/O6cQLT/u4SACRAxCdJJ0Ih3QR8leE8o1v6eFt3GaQLp5tQD9B PkGWRjkjKlnlPqQ73Wr3trROhLWxo+SuJp4GaEdI2EgzfGssEtoYXn7o1Kf320w9fzec ZdGL3ArZYMtFbBsHYgFZiKrbt8WAxseBm6zF4F8uxOF7Mm0cQzaophEeaQuTDra2dgbG E120YLZeGsikWVIcnKSiYjQqxc/p+fXw8vzojBYKaFoYdTJl1TEXq1UBLy06ThUnNJMY v0ESyCTMIz/Sr4g7u7vT7m/zAe9tyxRcXP2x+rCIa3tdEx1KJnk0A0UVOsWBcCNhl7F/ RTh1gHAgSyME1sKVYfT1siSmYWEk3q5XBFX0IVg6omJh1M0VQzr6ELDShy6lV3i+maIb MXdV19x5kbcoFqFJYKVEl8VZ8hba1wlljYrjq49IVrnAK78MdDGXBnj0DH2JSE8ll4T2 0CujRrpUr6I+mJwLdjWyPpcFmOyqAGRwK5tBiK3JpajmVkUO69sUwLC2e5gPZbvfs4LG LMd5xYO6pTmvhP8izmu+hjU47zZm72htD2QSj7WKyvLRg6jvXyeTW68wUqfGSmMtDLBI UzjWAQa+2N7aM8fqG+DKNOkO1EuTnrE9miadx804vG0MKrOtlIZVaJKc95cmSQH+RRRp vAoyCXJnH0exuy8X6fMShLZ89+0Kq5OZ/ZDKR2V7tAz7gwKVFZ4OrUZkziC9NFYc16NJ zH61hWmV+3jQ2Rn0KxPfGgvtJvukYdZkha2pXpPuFpcXbttUbUqV7DaNA9rr4YD2t6sz +drZCIvrVpPJt6Z6Xf5eYxhaSOMIfWPa3cIx7W5XZycuLnoh/WTNsJbAUDMyG4O7ZJ6h 7e61+aG9tdfttne1BfFzGaNTh96ro5+GIg4w6zqfMetMj8wgoG+h6eUWDPwYad9geqTR lB09OhTDSy4NbiEVJkmfJBwIHRjLAYFYpg1sxSmQmo2vTEoYX5ngDE4RbTY6ZptGUAkD R3aYMf6Pmi1hp9IGCmVeljv0mzCeRFOjGs19iWaC4ZrlBpVVyybCY9NW/rsuZjJlmhUL ICKLkIbQoeKES3DFgnpBnHhnhbaNuTZtyUWUxkIjaBHCWO4SCL3oBYDPpgO2YCpLULg5 DT5upIGMiHB+KPHVR+nOad9fWkLttoR3Ch1DP3JiWpE6erdoDqxqlsHNuOcWXuRHeR7y sy0Y0GZJMNEJvvgHRMF5zcdoHDLwEQnWa7eNsVc8EsjcNv55rdo4xm4pOYmu6d1SAuFs nDo6MaDc+IG1sOXrR5Cl1GMVV+6eAhGV7h+lejmbx693KauG+KBFnzlhklqLAtLaWV4w uezeQmNKvOXGnHjL9Xw0D62rYfdeWF/vFuu76Y8rNp1V2ZY1tRum7OSEW8jdM2VTWLVr ShoQd3iH1VB0dePfOyXL7oQaLwNzo457gEtkkB/YlUN+KHc3VTRcBCrV4Fa6Lgrh6qri ukiU11wXCShPPt1e/XWRrGzm0u0fDPpWVsudbTx0bIvzoTrEUbgkTnx4jyCf5R9SiGd2 fRdyErmdJTfBLMNHq+DoHuQidEaQ0qMdTiMsDrlMocBHkXBC0a0gf+J1RtLDWZ8i5akR SslKrorkuysoUm9/VSle0BBSzJibmYUwEChSmSelOr/Vp5TjfTOrME1CZt7nX/FxynFT 8EkK6CyjusxBbEmna5WBjc8EuLVpH1A9ZsO9uyVLfD6mssx5uW2UiOGqIr6V1ARIGDVu dDnScyAMvPdBLvzeXrIp/iLuRPZ38A5of8+8A/oUwTPlhtH2r/Mk+x3dP6wz1vHF27fD czxmwZsJ+kskNObNzmbJp4zFCTz5grTLURLLZ1PgLUC9lUEkMcW6nj5tLnO6AQ8LftfR zioQWYHFqrCwtcYG/zaaY7xKRsV9IwqQaITzn/u8If4oJEN/d/GOMqHvUR7rvcHASmQt FDdA/hKxmz/qCAqWHMqIjil1DmQU/y+fqVI0K8wTRfaH7LIvcVFJIgiM8KGRNdsEoeCN Ea9ZQ6XL2cF+extvZ3vtLcOiGOn3C0ZMET3qtrFpMCkHpjpBXz3nitK+NkWe31mJ54d/ hONFXsH0FUA111dgHi+Berava1fyfYip39uh2Pq9bYv8rPeyYprd4M97+kqsEPq5Uwj7 PE35rMpbGB2bvUXJqDEi9OjiElWtBiT69oHL1TJ7EkwmDTKoPVOhcHwN45PZtLZBAvuS hjKuxS3REIF9SUOLbIlmAGiJRuwA3iAq3wwv1efFJr0YETjn43qEaHneIg87uODodY0N K7G6FLVthhM3C+Hg+jDK+BEozBqyZpttawqUNX7t/u6lRbPcnMoSipRatjuxAkW7WBGj FwOM42GuvMrc1t2x/tr7vTSAuiy3e26/EXPyHahqfYX26pe3ry7OPOWLzezh/iaZWf6D RgNCF0eTZ6+La7rb3TckFvq6Lu5HQcrVhr/q52ny0z//aZR/Vyx/9qzoWV/2IytzLSEX b7StVw2iL4B3ROHHzR8nNKoJaFBKUkpDiZNowkM3Ls0kBc9Q+WO0DiuKuldj/duTzW+z RtNKLPptxtXH2wUoE99m4BH9n4uITwD/jsHKqmfsWWKFHbNWta5uGN9yKrkbwWOf2zBV q9hm8c1i2qutr5edL1UPfMXW19kBW4deIz1xrRLpaX/L0oBc1rCl543Y1EubSZlsKo/G Hw59iHyctUx4rSC+Vhdg9by4PJ2C1a0aFlDDoHv9/jb6u/X7Zu4F08MaHqrhUKw9JtV+ 7fBFUT0Kz4tQPX17NXp3efrT0fXwwH69U2ikjKc9fen/3vzTZra1CMEaZH9p/umnYJ+/ 6BKADvLSOrMZRCFM0sbx0dnZaHh5KafIV4XSjfQGvX306xz0ZJqWd++vfhi9fn9+3IjA 6wlse7Qr2mx8DheU9MO3RZv+BXaoK01nSQDVXp9dHF0DxPi1+IJnQVHNrUUsVCb+5BAU ABqjP7RNHsuFCNS1KsubUyJqqHwhvjCVLRobbOk6dJPDULpiA546SswWWiSaZ3jJ1zaC vrXF/mirLHm+2pNojBAnp8ei9gn/QrVlGfzrr01itS0kb1s8jhHzKwu1yC3URxLh4NdA IReXbau+LHTrE630Ba30d01aOT+6Pv1pWEstTRu8nk6cClUk4oDWE4SkBVGhnhqcFuoI wAGvW3F3qPVL7NSoX1Sxhnu7JBv5L9tSgTaskxP37XAIz4oxbw1xH/00V2bCcQ9olheA wTS9Ys6nD29wSVdaz1WJ19QmtbM8lY0Gb8UjFa5TW86Kw1nljH7L+8r1rs2HsuOzAqg+ oysw1zS7e9Dfrz2j69qVZ/Se4Pm9fUkB3+bJhzBGlePsgksPpXz8dHTJ3qivb4yvx0fX xz+Mhucn7Iej85Oz4SX8rjAdX55en0IV+QtCvru8eHf0hgsk/Rt+//v7t+9U1Yt316cX 56LGFW/mmuPGtMPqL2zpSUtUoJsUo/7o7dG70eXR+Zuh+OOHI75T1IfXp2eAxPj7/ET8 BcQi0ACvhI5Q0/rz6GT46v2bEYjY4eUV/xuF7fXl0fFQpNpDk2ZvW5o0VcXro6sfr8S/ o9Pz1xdY+fx4eMZ/eXf0/mrI/70cvr4cXv3Af+PtHv9I/16/vzLwHB8d/zCUCF5B52Vf +d/vz90vR9cXb0+Pjfoiv7hAMDw/vjgZ4rjEL1enUG34f98xeKH8Blq8uLLGAeVX/4cv CMdO0EccBNvCsncXP4s/+lj7/PUpoLm8eM8XrqMQvT7jHAxWgCjohCK3vebkdfYeOiII Sy300jX4b+fDn+mKjS4WLsMsTD+G9GZuusgXacgWmQie8GJDNnBx+SOGSl5l60fxeLaY hC/Gk/EIOEi2eVe2Pz2g1ezAU8Ex3nUHB9tbtYyhFA+wiB7r9w62dw+6+6YZjxJkChqG OvC0T/zgVQj9oJw5rIIQotSAEU7xIt2ceFpWLBfXMTr4KpcZDoi4zNGPIJDdO0CRjt7O zFDuxRYzI9GOlXWnCMrVIq1L/xSkIu0cTtug50wb3A65PxdkW47E/MHDIVoktp7yU/Ef 8827dWByT2SLqO6Yt+1wHXao/8ZHQNZdvIhSPKCI0aJPEttrCN5pvqeVbyKNeMVpOAd7 Nbq2mROL7jSNjXF0cgNwzQaCb5ArzUbTmC2uFCLg1X+ZgM3DR+0waYKu3V8KcLndpcDd vbXNt9fSe0tjMYRvb/9g0OOIDOFLsndfPgbD2AUBPD2bJ5/CFCOifErakC+Fn4ajjN2F s/mU9ymJ2c1iMnngCmCWh/ciu4ty8wNpMbKi7W3p0qPLNyMPxB4QGLgEQoQ6YRUKZLxM 8N0hvXgSzkOKjQjBIalfOXQNnAchBSTmoonD2yCPPmKkRU5Ii/sQwxrdhALLQ7Jg95A5 FuIdZ4v5fPaAKhyknqHwNqwhcTRlH1JOQ9CKGmbBKIIRv5vstyettUZj0pQGDvzdUEQb BNeE2Nrse9QZ2IFK4ah32cd7ul/608qRuUF3Ssb+kpY/dLIB7277hL0BprURbtGMjFI9 uhHv7UrmwMUkF2bq2ASnJdg54rM8HtGpyCiQxyA6/RgF8tAj+C3cuYkSebrRJbKOPMaI 04tRIk8s4qBidkAcTk5lyh/xXR5B5HdKbkuD3pOmoHP/oM/LBn1eNujz0kGflw76vHTQ 56WDPi8Z9Hn5oPt0pdjf2lU3ipq33wfjNMmIt0vnnM6juKFM17OEvmGALscRjQrFg8ig tzRPNPE4XHEH9BbNFXf32zuwO/bb5PN8fHF2ckwGC84XYcaNL3xPxn3nGzpCON/GSTyN boEojI8QHU/4VukleMwCoOiun3wBttzEC2CPY05/6Um3cAgFjyPYPdg2xRCdUqTRL/wj D9NYxNoAVTmejiCzCFdzKNcz/gX7g69mkD7gnx/CBwEWTCbgYDHClBgWLs7AuZ49QagY 79HbLI/uw2RBvyf5XZjib9MgmiGgi+Iu5Fz0JgyoAilH+OvNYjoVleHeQfQlC2a5B4sk RWoVPQzwVxHbCNOoQPCxeRrmiPTwScdCMIlSLpESMfYwodZuuABYzEeTJA6xTmvlOsLO GFGcHqv6fHEzi8YIM0+TnKMSMzlPo49BTrUh5TKtDv8oem6jiZPko5in7CEmfBT8Sswd iFxagySVX4M8uce2CxM5D8VsTUVfQlh++TvIX6z1mC0luWMdiUu45TaVhP4iVmYjUdsK dpbp/jDoUTZ3KeWl4nI5vH5/eT569f716+El102YnPb5IrsbESXzz4cS8Pry/bBQG067 WNeuDXH4sS6rrA3GR09t2NRL1AZLp6c2vWgp1G45tUlZK9QGyve1bQSXOBsenY9EoTAt AyL6jjptQ8+aBijBgNZm6ogfgwQoqU8KIyLw11cAIps7PiaDpO42OVhIDaLwI1UAZaPS dFEyKgIoqW4Qhr+6ACipblCGv7oA0ERhVTdIw19dAJC0BhdifuQgs/fo7cXJe3i88YLM PCL1+4DrXa0B17cN/yMwNDdGkxEcAF6fXl5dc1rhDZ0fD9GRAEu+e8nOjoySJvuTnysM 3zl69CCCcTJ4x4UH3XXeVwn3Wf0GHtYjMIHDsXrExRbfKekDxMXAxjpON/gZ5DEcU5ix azmmhFuOY0poi2N2D7a2lvEUKyAxNb+9g60ex2M4Crd7Pdbaafd71gYBS5VMWG9r0Pyw GgrbyIsX/OgaziYZegTzRbmNeVMYx+VT8ADnaq7M3CWL2YTdJfOQwtbB8fNTkEEkmPgB ccy5/OLHiw76AhlnQTAtiRdB4qzAVFYn66t0RJdhgUT0JHHTwdyQlPz7N/J03Zln4WKS fEMP8Vr6eAmvZw+Lt7yQNYiC1iRThBFxE4PsQ6ZiFRGGBSYCDdNiB0TBgTBC6dyhGsWC 4tPgO4JDTyfO+AzSNbUAgrP+xyiDCI13kcaDKZYoae2hbzCvZ8Gt6gdE57sJw9h26zbx cFXDPyl+PJOQL2XyUESE4a/qEWF8UnzIZFe/D0BPOlyiOkEKDiVgfgrSCHM4INliyDdB tRj1sk2GGBksDtSrjKx9YIIhZ3gVQNcIlgmWyggSQ8BFV0p2mFmWkIFF4zKS8iJolClk sGlEiFF8x1cIx5lA6NEPLAyyaPagAj+SsXjQbW/RHl4j+pPhKeXfZkhyOFhk6tEtn5N3 ZhR78FMHJ3euTn6MkkUmrEEYlJhobnwXRLFeVAoXaITkpg9QX8USgxiQLxIdmBhvAoAP pCL4Hj8WxJw/EHOPKEkWtSabOU7iWCbRjeVuB340HgEbgN9Uc4sYYteaUcus8HeHFtUg idHTNNmWj+s4TARITL4+k9U+l3dARWY7LJItdoBevlH6YLMbZnxrDy+DbsAJgdMYzNs0 sTpDHbLt9X+aUT1lhEvGSnDLOImtEparlvcaiRTWVWRZNfhaJNPIZZpqTAs/2xAe6EZY LSOfvPHVjErhb93IgFzTA+M2QuQQd9svfDQiFpiBLemGRApCvusLbIVv9is01N4boPzQ nXKav4luIbiwYgRYWVYESWOG85b1s4QkrHqrQlJ1lnByTKYaF0hVfc8uKOFP0tX67cE+ vOMHJUCxDuJqvO3D5XiJ6BAXyiSWVyOFTgUpdLyk0PGTgq/1pUih45DCmiKFjo8UOl5S 0K2fxuT1CdtfZnLXoeI7Hg1FoxR6h4CCZ0pfJrtNPCC71x4ruztfrteIGfoKmk3HWLLl +ZdeoUcLu44r7DqusNONfIGw6yhhJyVdx5R0YmOTuAMmz0SAxWuVB15uO0yx5SSE55wj up/PoukD8hmQOclU7iWogZdiuhb1Xm0Y9vMdp45PcK0U48vzaRqGxrUVKE/JIpf0w5ES vrytOVUc0uVUBqqOmVFBxAWdgA3wHkNU4hmiom+iAxSjvNDABNSvB7EnRDx7PlhqThhi d9ESq65IcCY3v8aPcG5Qpk80IiZ4/08KKTxKxkt7HbLX/YKk9Fe+auH8O6J/iJCJPBww 8r8Xt7OHp6LbP6NXhZ30i8/CB15byBJgVjhpgz4G2MzYDDL3OVegdC0K16CRIXtghmHz CtEFoY8RhRroD0fHP55fXA8P2NHl5eWbNnt1dKL+r5TVATrA9Xt7XGtVLzIFQ8SstIf2 t1kCb1M+WyltfxVONOSLc3X6H8Pf8dnI11y6TsXS8eMAJD7Ai3idG28xhxQhI6ETWrlM lnkLIXSrxga6ribzZkN5NYr8xRjAU7Qtb0HlKT3IRgGwWr6lR8Hij4ZMio33c/iHLDaQ /ERuFDJ17xjTXpXkz5aRTnRWFnHf1tumJ2eQEXggnBys6bGSEWdh7ukbhSehblJmYvyd r72TJviwgJ2khAyNYKG+oiK+IAFkp6B/PShkggWMqD/CuwmQww35IpkZ2YNazkd8ygCI KGwyXWjBblBbmEwLX5M0ARm9VoaDnDjMqmaO8QQBTBs2PqYRSOFOnTM+/j8Rer1D0xZO lLybLFBkiO9CSxZXDyS05QKi6BaN/cibyIwGaM9C4yhZVUQSNNfdBMLnS+JFtJObUZ7M DwsfKcw4NvT1p69sZxt0jytr0ZOdWxzIweEAIIrMreMBEXKxBkpxedjUXLUYu/DO9uc6 SnzrZz3FXnfkKU5mIRWMIRvB49xJfmeOuhJ+Es5rofmAx3xTBNAvG7JFkGq+6/pRDu/r hwtd3o8qXlrDR51l4wulFk60B8cKuYbVzUIyWFJ1nPVDrwsq8REUPVPxVtUBHuh2bNDe B04NJnqK21aCi55bl6BS3oWF99lLVoCB+mWMTHDgVICsJZUVOm4LWRbdxsU6lOzAFWRK vsKrB044X4as+HypKOnN5jyDDX1C2N+cB4FKnbF0j5fpLMeq21JdnQaLWf5VGqpoJorv QrCHTr5+Qx1nA8wX+bLqj0M1HaUXSFnAiV/GOS5TeBzVpgrHCBJyzUqTVi+FCURyXZdM HcxB2vqCyarbFfYOlL1//FRWoDBnknLcrIjmC6fR5ftcLPMqVgZEZs1mYqCM5aZ31mL1 vObFjtTnYVTSXYtVPKzUtCxEAT6JApfkqcwl0KlSpr+wpSX4sN0Z9ziAylxx0uwv+Pap COSeLMRT0tol8CZhKspHz8J5s3pB5CUbFIS1HB+Mu6KViqr0NHiFutmSzdIKyhWpwFLd A0IjHjD/SywDvuNXB0u+4vGr4zt3USuPO3d1rAMXYfoJbJBR/iBunrSxTxgkGyqgFGWk QxvUAveZzIoKN52zJx0wV2IVdRUKTRr2CpUilZL48PaVR4l5Wu4o17/VTmOyVv2hrATS fzYrAa47oin3xS85qQkcKx6Uaqt5z23+SuXHppIBLn96KpnYlQ5RJZ1Y8ixVRgdLHanU hCFOg0kuV83TY88pimLVRcK/vaa/laewjmleWeH0VlKv9hBXUq/+LFfS3oqnsM5qp7Dy 3q52GCvBs/qZrLOMxdg6ypSNYMUzWufL2nvEYW3VFr/kGNJ5BE18+WmkHtMqh5IqbF94 NilhTo86opQs12NOKiXdWurAYou1R58mOiueJtzRVx4q3BWtOluUIC49YpTM3XInjYqJ LzlwlNRY4dxRj6H2+FEx5tVPIfXIVjqMkNZtHxx81yGdirsX1Jy9F01IFZCFlZz78Rxt JkPlinoCz0pUjlE6a1emij2sS6h6WJvE1EUBi4nIG6rlAgyVO2iYb+R3NHZdYLovQ9Eq rt0i/Gl5vE8FUO3MrcAeFUtE166OJbK9gy88t3eMYF+vT4avG6/xLcTR26GIQrMu9uu6 +FvG4y5UwYg9usriXtbQoXiMGmcXFz++f6dqkHeLqkF/2jVOjq6P2opnrsP5dF3/DX+K 2DICXoaSIJh1+X5Q1FHPCc1gzvhCW13xZcr57U+Is/Hq7OJN2+Lb65ObWXK73nbYOdQf YRH73NYIXh0dGyMmBPSkzMWACKgIMKxGhNkLmIoqKpQQdWQo4TyvGgdL0KGurvPT9nqc Cg+2BgYhdumpcXfbE/WYYvgFeTJrWOGHIYggxc+EIFLNQxUc2Io1h2+CDnwYUcNpMo0G 4laVYJFpiVprRoYhXy8VMvl+wItOPHVyUMgEyJqcSfs+kBG8KICXLzK0GhM9vjb64R1T xdx4ulGYAyvP0pL9KJsPY5SuNp3fpcmnhniT6LmVWQeXtWmUZrmKhcka3540wbEJHooE 4rVFWxq4lEfppgg22e/vkj9Rf9+Mp4WaWzZCA5WKQXV6fno96o2OLt80js5/GV3/8m6o o83CCyU5Vgpi8FLFJ1C6n0TJ5+eno7PTE2CYw+PrBgH2zGQOflzw2sktcSLMGm2Q0Of/ H38wmqCgYrMsNAKk6jrnF2q882Te6K0Y7AP2u3g5VMl6JEw985GQyD/Ok4+st8e6Owf9 vYPB/lLsx0IgGVD3YHvgRL7eppg5yplZ/lz/cHnxc6Mx5xzHS4br357SS5NURin6lKQT 8igcBzHQ4Q061k1YAGDCOkrC1EV29cvbPgT804TgiaVGAqvldFC8Q26z9V+SBbT8PIeX 3crhG5Kkoxq03mxK13OVNqD0RFlovk0E2NMxgtsMHiiO+J7QUe2h5wL5s2fMTQPNnrG3 IPuPf2w2ixMdpvc0DnEW4ZNL753dOSVb6GRzXYQ43NrrihzNg3ZfumMasQPETKiQpOpM p33QzbAhwJksH11KE2u+qaBPTlgRI28h1yaOuOI+h1fcikVlm1Y81aco51Hn7jbM+VBs uJ4YVF4WudhGnNxuIYWL7NqxtJOiEy1GhlXerUifhoM7b84XENDIfOSPF6jTVHi65std y1ZLqGwFefXnP3Yj0E5Ko1/LYLoq9nVJzmT0GH/iiUGdmaF1xSc7hq+K1fhZ5ZVR6/Fu AW+11FJAGi6ROWX8QdMM8vMRfmwofq5fc0si1/kw4Y3GDpdvOztmvMjPzuaQtwaSlIzX S/IBC+2Liflw5WtQd2H48lVU2TQsvx2g8ybBKRG7VoilLD9Xh7+UYbaK6GHF4W+x3AJA LQsUqc8UXFYcdM0Se4vq2p6eOKmWPCuqEiy5S/ohmsgh/GsXUmVMK1vJTu0w3SxRSy07 DNDLAo0FARj/gpglbq7Fqq56s1p51kXdozmCaENdbtmCCKNRZY6Y4Z/G/gfLj5U9oyQd 9RrPKJQ7/DOWIWwfKZS0aFhuO6FOWl9HRaBVwxS3mFy7n4Tp99YAYRgYZx7UED6aHvwh 4LmSYejmau61NlS8Jy0PbGtE+18Kkx3qFoe+XFfo7vXLO0J47Er2vBmrLo8CDlvSlGyk /1D7yCxFWbTTh7B5rZ39nXa/W1TPzJvfph3CrbAFuK7NT4zLboBAnv84A0LxiZp4rCao dFOo/SCOct6N0KE/oUN6oq1r7NLVahfOx8vwuX/5xmrVjqii+yUEE8V5o4ER4wTmpkig h6SBqchbu5ZpA5XAieTjeMxXWsohV0PYRPP4P1RRm02K2T9keOin6lBeSEtg2xrY+jtE x7490cYEGuLmOjRx6LfcqD0sBAfSk3kON+NcN8333UYFMwg3BDzkh/5KHL6BQPHUHckk CWks+LQST4Ty4V3lqIq6Kybq6O5iGu+t3XZfp7rGxabONTxJTrxJFDATti/Im9JciAvQ XtyYHFr6jIrqoWMH0ElNPe5WcjC/A9uPpUO6ek3LHXzrK57F6YWUjEqBsT/MM7ns7zGB ga7EpwIBdKfpqKUvW6okAdUoxGyy16VVti6tzyBkLY3SOCVYR2Vi0K45Y4N5rHaTvsgb 1Cfy2dsxyccgYW0I+EUGH83m4RhengYQMDdAnVIeFzbXTeq1KPfzSkdoAEKuMgvjWy4i NYvD1ADAQ3oa2uivXvSf+W+ZeEs6SXjXZ3k0n/HNTc4NwEWxuxqFIjb8Is6Ga/JQopJe zcJ7pz9tppXbUk5X6Kpic4ytn3MKm9cxOx+bemrZMEsZm5cpuc0qzoTxCstadbGWyT0+ X0Z3Du1aUjTZH6WIsko+e7iB+K6NKMFsVuKc1xQRWtgniNArEujhplYxgAIVaEHMBQXo /RRk0j+yDUbrTg9mnFeFCC8YI4K3+SF40IrLpxSueV+W9KTMiqfJ+lDrP4Tqu5ecskSg h90Bxpvc6205Nw+Pk63LEh2rkY0vX1ZlmvB3ghqlbVrohPCuhafMgqdQR76KVK/eLuwr bBdW2C4O4y3NJieKl0v9QWHJ4cF7ax9yv/XNxJsl+nPVQVLdnzz1+JZUUq5IpqJmfBn+ 7mXYWkpDxmLcohD2ATYoSd91ky3YvMBY4S/ov7v2GJqYOnctu/MXcdMgqDQPPoQxrH0B YZUgxNXb2sfVG6jVM4S84ZyjOrakAaiwkqajT2EmHr1uRrjY9SNSpdSGwIzLAc7XaotW 31VW0Q0RsuSbb2clXSnqQVWKW9ny4eLt7OAxen+7Cw/nndV73MoxY+1K+gUESLkVV9GH H7tiannK7GxOl8rXpjDv6+cJbSeKdE9RB/lRiK/do5bJtt2gIkHbsGImTcKsqWGOVp6V IFgme/GCdb70Z/W7Xa6UB2DTqbne1WBL3PBqYDeFw+7B1t5yl7wmDsvRpLt1MDDueXe3 9ujQauYszzkHDcHU8QxN07+q6P+sw3q/K4OSSm2O4KT22IxhOU8RJWQlIq2petN62y4b lxevHHx0lfcxTEl0gS8uEHSUZ5ADhMITgVbMlUrbWULFANwXeXmRp2g3CHHsln7QG5RR RJRJTVvMGSVTgHTdHdb/XSXRnvshYFY1x0FUPjWys1awyxxjs7aXh1YbtcthNXIwB7sl 6EgB4maVRmUkUKtxV/Xj06CbgXi60Lz1EWL0IikV277kc2i3TLcpqRHQHVrn+JymFWXa BlLQ7sTQNeEhFewIKtjt2tmZq9Z6ULvWihr4mWQyC9P/pQjWEFOhmxIKsp8EfhATZzdH MgOaEdj+eylvVVECQW+rpQhB1AsQgnOiHW9z1t9fSnbI6pbYGOweDEz/xN0tyv+yJd2D 0GMZFSt400ivjg3fCs/VG7mvzOXlqKSWKV2VFvM0Lq+/LaGQrWnrX+3dkXYOM425lYoQ aiV6SigMdKpmhVIndSl30sAUMcvqp4XxZfCuLwX97/zienR0Pjo9GZ5fm3dW0qTTrVIq BZq/sm7pJBGI33OuZIJ0lc8r5qPLub43uSnfF7K8eldIKCJq2BPb4DQ3GBxs1TvNqco1 ruO0nKAxbGnHSQyqCBloVeZ4ruE0KJm6zJyG9i4yY5+/P5MOOPIhGEmo0/OfRspMoQlc 34pou+bPR5fnjcb6UZ6H93OMKQiHeDN8I99jwshu6N0iSa6weEfaaUMY6rqusQ8Nw+iR rt/j4XERmOUztDlx5grde/qSeaxQxX6m4U3EWQIacURWU3HQ56KFn0eipudAgjmVeUfA dRmtR4aG6BkTcS+01vR29xz73V0ym4AUwkffL8Wf2aELkKmyEgWDJkfY5KSff8fReY1D m5GhOJq4tlgEtQ95LrxORm/txpL3Sfgezq5Xmsv7swhKJ92CLWblebOF/RJU0GzDa/e8 yYrneL9FTnjNYV8kSTXkmhSRGJugKUPbe8qsw7HNHL2v0FZYGqsV9xxuN9UqbWrJpV06 7bp/bmVX5ylfEs7T07jpX0QEmDbWf0thg56ev1EBaMU25BIM7PExX5yUMhCHk83fYuFB 3hugVRzyast8m+Dcf3l+dCZeX+v4gJC8GPQmIzKgyGMl8ia8u+R15cubxmiElDsaTedO MovpfJGPG8//8lyUQgaLjlmYNQzKRDzaiGDUadXVsawPRkVpTix2/P1bXhd9A7z9psmG Iq5gAotbV8wMq5nYxaOHPZrege/y4anYC/Xbyr+dEGi+mIGzJySvse66O25LcBPvbjBl EPMCoqlL/lFpuIIfaxali8V03qzidzbJIMFYNVDfkaMUacS3+pjniP+768ypay4WCdYM CfxUjctUd2/T4KbouymVWF5F+ePBRkcURhjEkm3OhLm6tzUYgKGad3iLaxsD041Vi2aI Oo4O7I3J4n4O7ip34IuJBMIF8uvR66PTs/eXQ49+SanPZS0QdoALPDoLqJSZGyJEf2iz 21AElpb6RvLJHHYFHbaMG0b67/I9YN/wEXfV7E8iDF4MfYHMD3kYM4ihTJk90aEYo2LD VZXtHocLIeJki9s0+ksp7VtcZ4AUL72tvR3zZYTl6QXrq1y3kZOsHwKDBEo03bF4k7yb EP53koC+Q/egHYhl3eaqdC7MwExzSghBI/1EJfWhZzqoWtZWfAr7Cb4+jbIRJVm1/Bys y4YiGmtvLoOL2axznRQ3OeZyZuywYoRuVUM7THg6N7mYZKnIUJnNUT3+NyVLZDj3CNny W/xcFAptfws1ot52r28bhwrwer2FcJC+8XIhl/fu75ju9WX++DKThw8rTp0XdcuH2gLX +G2RA+UO4x4nEN5oEarB2xMQ5dLQ2tveIlV8e7urIobXzCKwFOACHM3zTPtUGy8ziszV dUP2ArkOy+XqlsUxss53M/Iq1xTlcdUjplD004Pv6KQnAqjDy7sBJLMc7Jq8XRAp/Ppb yuk0yyecp1kTM6O72nv2AaYIYr1nbDG3WDBhgSIDQ2cpZdnkF/X6rjkbWQwD5jtwlCej IBtHkck92iy+WUzd/cjX/pvn5ihNzVZezynkZfzEYCVeOPcyyaNPOj0wpzGL3WKxSJub m+YKiYTJmEe3t7MjE+mKw+uvf3R6v/O+0a99/esAfn2++VwtsTiI81I0pKx2W7XIo1m5 GYVKq40oBON5d1hvVhRVKw0ofT5BIFnxX7qFRxctThw0JfDQGaKd0GNn/rnNrOfPYFRR n4SzGj2EFphEkdzLwgizZl4tmSdCvF56fvH8wPazUp+LH39GWE8EnMmhfdT0v7YplDbm vwJpvITm2PfSMH9AdnjPOy11n/ExGAXpLbjGmcmkXbMJuIXx3sGunEV5mAazxrNJm528 Hv18ev2D1KGv3JpfZUGcrhTX5f8BYgafDBY8AQA= --============_-1202042902==_D============-- --============_-1202042902==_============-- From bruce@cubik.org Thu Jan 3 20:37:59 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Thu, 03 Jan 2002 13:37:59 -0700 Subject: [Coldstuff] First version of waif-patch References: Message-ID: <3C34C127.9030605@cubik.org> xmath wrote: > it's not totally done yet, but you can already play with it an > see how I implemented the overall structure. Now would be the > time for feedback :-) I will build this and look at it tonight and post some feedback. > Note that I'm not completely sure where to send this to.. if > there's a more appropriate place than this list feel free to > correct me on that.. This list is fine. There are other lists but I don't know if they work or not after Brandon re-did things and they don't appear to be archived any more on the cold website (after a quick look). - Bruce From bruce@cubik.org Fri Jan 4 06:00:56 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Thu, 03 Jan 2002 23:00:56 -0700 Subject: [Coldstuff] First version of waif-patch References: Message-ID: <3C354518.8020706@cubik.org> xmath wrote: > Here's a first version of the waif patch > > it's not totally done yet, but you can already play with it an see how I > implemented the overall structure. Now would be the time for feedback :-) I didn't try running this patch. I've only read it and am providing feedback based on that. The architecture for adding waif support that you've used in this patch adds overhead both in terms of memory usage and execution speed for the typical object. The use of ExtObj isn't something that will work for those reasons. One possibility might be to use structs that have the same layout for the shared portions and then to do some type casting. Another might be to look at just having a new thing in the cData union and a separate struct altogether. There are likely other possibilities. I'd like to see some discussion of how that will be structured and written (preferably here on this list since I'm not on the Cold Dark a lot of the time that you are due to timezones, etc). Also, negative object numbers happen when an object becomes invalid. (So, #2 becomes #-2 if you destroy it.) So, the changes to how objnums are compared doesn't look correct to me. The things that return ~waif when there is an error should return ~type usually. ~type indicates that something wasn't of the correct ~type and is something that code can and should be able to expect. Finally, if you're changing the indentation level with a part of your patch, please make sure that you fully correct the indentation level in the surrounding code. There are various small changes that I have questions about or that looked like they didn't really belong here in this patch. (Due to being entirely unrelated.) Once we're through some of the structural discussion, and there's a new draft patch, we can return to some of those things. Cheers, - Bruce From bruce@cubik.org Fri Jan 4 06:04:39 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Thu, 03 Jan 2002 23:04:39 -0700 Subject: [Coldstuff] First version of waif-patch References: <3C354518.8020706@cubik.org> Message-ID: <3C3545F7.8020706@cubik.org> Bruce Mitchener wrote: > xmath wrote: >> Here's a first version of the waif patch >> >> it's not totally done yet, but you can already play with it an >> see how I implemented the overall structure. Now would be the >> time for feedback :-) > > I didn't try running this patch. I've only read it and am providing > feedback based on that. And in that line of thought ... it'd be easier if, in the future, you provided a short doc explaining the structure of your changes and what some of the intent was as well as the thinking behind the choices made. - Bruce From vanish1024@onebox.com Fri Jan 4 06:14:10 2002 From: vanish1024@onebox.com (Vanish 1024) Date: Thu, 03 Jan 2002 22:14:10 -0800 Subject: [Coldstuff] Tutorials... Message-ID: <20020104061410.SWLW27009.mta05.onebox.com@onebox.com> -- Vanish 1024 vanish1024@onebox.com - email (818) 630-2340 x5993 - voicemail/fax Thanks to Bruce for sending me the tutorial files that he has on the website he recently put up. I'll give it my best shot to add any more thoughts to them. If anybody else is working on them I would certainly like to collaberate on the project and share ideas. ~Kris Anderson __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com From K Anderson" This is a multi-part message in MIME format. ------=_NextPart_000_01AB_01C194AC.01343910 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I was looking through an old Cold FAQ that said start.html should be = located in root/html so I went to $motd.build_html() and added a link = that would show up when I went to the startup page via the web and = basically said Start. The link shows up, but when I click it, web browser says nope, can't = find it. So I moved it to different sections of root to include = root/html and still no luck. Any ideas? I would like to be able to serve up web pages under Cold in = conjunction to other stuff. ------=_NextPart_000_01AB_01C194AC.01343910 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I was looking through an old Cold FAQ = that said=20 start.html should be located in root/html so I went to = $motd.build_html() and=20 added a link that would show up when I went to the startup page via the = web and=20 basically said <a = href=3D"start.html">Start</a>.
 
The link shows up, but when I click it, = web browser=20 says nope, can't find it.  So I moved it to different sections of = root to=20 include root/html and still no luck.
 
Any ideas?  I would like to be = able to serve=20 up web pages under Cold in conjunction to other stuff.
 
 
------=_NextPart_000_01AB_01C194AC.01343910-- From bruce@cubik.org Fri Jan 4 07:35:15 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Fri, 04 Jan 2002 00:35:15 -0700 Subject: [Coldstuff] Web pages References: <01ae01c194ef$0fd7cca0$6464a8c0@mouse> Message-ID: <3C355B33.3020804@cubik.org> K Anderson wrote: > I was looking through an old Cold FAQ that said start.html should be > located in root/html so I went to $motd.build_html() and added a link > that would show up when I went to the startup page via the web and > basically said Start. > > The link shows up, but when I click it, web browser says nope, can't > find it. So I moved it to different sections of root to include > root/html and still no luck. > > Any ideas? I would like to be able to serve up web pages under > Cold in conjunction to other stuff. I'm probably missing some steps here, but: * In your root directory: * mkdir html * mkdir html/foo * On your Cold: * ;$directories.add_entry("foo", $page_file_index); * Put the start.html file in root/html/foo * Try to load http://your.server:1180/foo/start.html See if that works? - Bruce From matthijs@cds.nl Fri Jan 4 12:09:45 2002 From: matthijs@cds.nl (Matthijs van Duin) Date: Fri, 4 Jan 2002 13:09:45 +0100 Subject: [Coldstuff] First version of waif-patch In-Reply-To: <3C354518.8020706@cubik.org> References: <3C354518.8020706@cubik.org> Message-ID: >The architecture for adding waif support that you've used in this >patch adds overhead both in terms of memory usage and execution >speed for the typical object. The use of ExtObj isn't something >that will work for those reasons. I actually doubt it will add a significant overhead, if you look at the code, dereferencing Obj->ext isn't done that often.. as for memory usage, it adds only 4 bytes + overhead of a malloc. I just did it because the other options were a *lot* more trouble. >One possibility might be to use structs that have the same layout >for the shared portions and then to do some type casting. That would require me to reallocate the cache spaces all the time. Right now I just efree() or EMALLOC() the ext structure whenever necessary (when I get a cache holder.. I check whether it's of the right type). >Another might be to look at just having a new thing in the cData >union and a separate struct altogether. That would require me to test for it in almost everything that supports both waifs and objs. Worse.. many things currently just use an Obj* or objnum. In that case, it'd have to change this all over the place to cData. If you're worried about memory and execution speed overhead.. this isn't a good idea. > There are likely other possibilities. I'd like to see some >discussion of how that will be structured and written (preferably >here on this list since I'm not on the Cold Dark a lot of the time >that you are due to timezones, etc). >Also, negative object numbers happen when an object becomes invalid. >(So, #2 becomes #-2 if you destroy it.) So, the changes to how >objnums are compared doesn't look correct to me. I'm fairly sure it can never go wrong, because I only use negative obj#s for waifs in places where invalid objects cannot occur. In places where invalid objects *can* occur, they're in a cData where I can check the actual type (WAIF / OBJNUM). >The things that return ~waif when there is an error should return >~type usually. ~type indicates that something wasn't of the correct >~type and is something that code can and should be able to expect. You don't expect ~type when calling obj.add_method(). I deliberately didn't use ~type because WAIFs and OBJs *are* treated as the same type in most of the functions. Only very few functions do something that you can't do on waifs, so *only* in those cases I throw ~waif (for example, del_method() will simply fail with ~methodnf). So using ~type would actually be inconsistent in those cases. >Finally, if you're changing the indentation level with a part of >your patch, please make sure that you fully correct the indentation >level in the surrounding code. I don't recall having made mistakes on that, where did I go wrong? >There are various small changes that I have questions about or that >looked like they didn't really belong here in this patch. (Due to >being entirely unrelated.) Once we're through some of the >structural discussion, and there's a new draft patch, we can return >to some of those things. Yea, in a few places where I can changing code anyway, I couldn't resist slightly cleaning them up... stupid of me ofcourse, but hard to reverse. >And in that line of thought ... it'd be easier if, in the future, >you provided a short doc explaining the structure of your changes >and what some of the intent was as well as the thinking behind the >choices made. Well, most of it is above now :-) - xmath PS could you please send msgs to the list only in the future? I'm subscribed in non-digest mode, so I get every message twice if you send it both to the list and to me directly Matthijs van Duin (NOTE: PGP key has changed!) - PGP Key: 0x2D6F0BA7 - - FP: 205D F7BA FFAD 9070 AB9E C5A8 BDB0 CA1B 2D6F 0BA7 - From xmath@nubz.org Fri Jan 4 14:49:19 2002 From: xmath@nubz.org (xmath) Date: Fri, 4 Jan 2002 15:49:19 +0100 Subject: [Coldstuff] More suggestions Message-ID: Awaiting further comments on waifs.. I have more suggestions: 1. [Genesis] A default method handler: so, if a method call is done and the method can't be found, object.handle_method_call('method, @args) is called. 2. [Genesis] Why isn't there a way to do bitwise operations (and, or, xor, not). Doing bitwise and is sometimes possible with %, and doing bitwise not is possible by doing (1-value) but it's not as nice.. 3. [Genesis] Support exponentiation of integers: INT pow(INT x, INT y) and optionally FLOAT pow(FLOAT x, INT y) I have fairly efficient implementations for these. (note that the FLOAT-INT pow isn't really necessary as you can use FLOAT-FLOAT pow for that, however INT-INT pow is a really different case. 4. [Genesis] It's a bit annoying that to convert a negative integer to a negative objnum, I have to do: fromliteral("#" + tostr(num)) because toobjnum doesn't work in that case. Maybe add an optional argument to toobjnum, "allow-negative" ? 5. [Genesis] Where is tofrob? To create a frob from variable parameters, I have to do: frob = fromliteral("<" + toliteral(object) + ", " + toliteral(data) + ", " + toliteral(handler) + ">") and that's pretty disgusting 6. [Genesis] Why does objnum() exist? Why not do toint(this()) instead? 7. [ColdCore] Add some mechanism to $root to associate custom meta-data with objects, such as custom flags. (yes, I have an application in mind, 'remote to indicate the method may be called by an RPC) 8. [ColdCore] There should be some way for programmers to get a list of tasks that are under their controls. So, a programmer-level @tasks and @kill Well, that's it for now I think.. :-) - xmath From bruce@cubik.org Fri Jan 4 15:37:28 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Fri, 04 Jan 2002 08:37:28 -0700 Subject: [Coldstuff] More suggestions References: Message-ID: <3C35CC38.1030400@cubik.org> xmath wrote: > Awaiting further comments on waifs.. I have more suggestions: > > 1. [Genesis] A default method handler: so, if a method call > is done and the method can't be found, > $oject.handle_method_call('method, @args) is called. This could be useful, but the name for it should probably be similar to one of the existing languages out there which provides this feature just to help make it slightly more familiar. There are performance issues for this patch, especially in the dev tree. Any code that relies upon calling methods and getting back a ~methodnf if it doesn't exist runs much faster in the dev tree because we cache negative responses. This moves some of the handling of that into the DB, makes the method cache less effective, etc. I suspect that you'd like this for doing RPC-based distribution, right? If so, there are other ways that you can accomplish the same end goal (distribution) without some of the issues. > 2. [Genesis] Why isn't there a way to do bitwise operations (and, or, > xor, not). Doing bitwise and is sometimes possible with %, and doing > bitwise not is possible by doing (1-value) but it's not as nice.. There are native methods on $integer for this. > 3. [Genesis] Support exponentiation of integers: > INT pow(INT x, INT y) and optionally FLOAT pow(FLOAT x, > INT y) I have fairly efficient implementations for these. > (note that the FLOAT-INT pow isn't really necessary as you > can use FLOAT-FLOAT pow for that, however INT-INT pow is a > really different case. This should be okay. > 4. [Genesis] It's a bit annoying that to convert a negative > integer to a negative objnum, I have to do: fromliteral("#" > + tostr(num)) because toobjnum doesn't work in that case. Maybe > add an optional argument to toobjnum, "allow-negative" ? What happens if you j ust toobjnum(abs(num)) ? Is there a reason that toobjnum() imposes this restriction? > 5. [Genesis] Where is tofrob? To create a frob from variable > parameters, I have to do: frob = fromliteral("<" + > toliteral(object) + ", " + toliteral(data) + ", " + > toliteral(handler) + ">") and that's pretty disgusting What's wrong with just literal data like you would do for a list, dictionary, or string: ? > 6. [Genesis] Why does objnum() exist? Why not do toint(this()) > instead? Cognitive differences. You're asking for the objnum. > 7. [ColdCore] Add some mechanism to $root to associate custom > meta-data with objects, such as custom flags. (yes, I have an > application in mind, 'remote to indicate the method may be > called by an RPC) No opinion as I don't work on ColdCore or use it. > 8. [ColdCore] There should be some way for programmers to get > a list of tasks that are under their controls. So, a > programmer-level @tasks and @kill Same as #7. :) - Bruce From brandon@roguetrader.com Fri Jan 4 15:35:27 2002 From: brandon@roguetrader.com (Brandon Gillespie) Date: Fri, 4 Jan 2002 08:35:27 -0700 Subject: [Coldstuff] First version of waif-patch In-Reply-To: ; from matthijs@cds.nl on Fri, Jan 04, 2002 at 01:09:45PM +0100 References: <3C354518.8020706@cubik.org> Message-ID: <20020104083527.A26096@mojo.cold.org> On Fri, Jan 04, 2002 at 01:09:45PM +0100, Matthijs van Duin wrote: > >Also, negative object numbers happen when an object becomes invalid. > >(So, #2 becomes #-2 if you destroy it.) So, the changes to how > >objnums are compared doesn't look correct to me. > > I'm fairly sure it can never go wrong, because I only use negative > obj#s for waifs in places where invalid objects cannot occur. > > In places where invalid objects *can* occur, they're in a cData where > I can check the actual type (WAIF / OBJNUM). negative object nums can appear in the entire negative numeric range. If you had object #14524342 and destroyed it, the objnum would become #-14524342, so there are no gaps which can be filled in (cold doesn't handle invalid objnums like MOO does). > >The things that return ~waif when there is an error should return > >~type usually. ~type indicates that something wasn't of the correct > >~type and is something that code can and should be able to expect. > > You don't expect ~type when calling obj.add_method(). I deliberately > didn't use ~type because WAIFs and OBJs *are* treated as the same > type in most of the functions. Only very few functions do something > that you can't do on waifs, so *only* in those cases I throw ~waif > (for example, del_method() will simply fail with ~methodnf). So using > ~type would actually be inconsistent in those cases. I think the intent Bruce had was to try to not add new error names wherever possible, so as to brake as litte existing code as possible. If you want it to be synonymous with objects, you may want to throw an object error instead of ~waif. -Brandon From xmath@nubz.org Fri Jan 4 15:58:18 2002 From: xmath@nubz.org (xmath) Date: Fri, 4 Jan 2002 16:58:18 +0100 Subject: [Coldstuff] First version of waif-patch In-Reply-To: <20020104083527.A26096@mojo.cold.org> References: <3C354518.8020706@cubik.org> <20020104083527.A26096@mojo.cold.org> Message-ID: First of all: can someone configure this list server to add a Reply-To: cold-coldstuff@cold.org header? When I click reply, the mail defaults to going to the sender alone, which is usually not the intended effect. > > In places where invalid objects *can* occur, they're in a cData where > > I can check the actual type (WAIF / OBJNUM). > >negative object nums can appear in the entire negative numeric range. >If you had object #14524342 and destroyed it, the objnum would become >#-14524342, so there are no gaps which can be filled in (cold doesn't >handle invalid objnums like MOO does). I know I know, however I've taken care of this: 1. if the data type is available and it's OBJNUM, it's always an object number, regardless of its value 2. if the data type is available and it's WAIF, it's always a waif (although positive numbers cannot occur in this case) 3. a cObjnum without type indication is an object if it's positive and a waif if it's negative. In the places where these are used, a negative object number can never occur (except -1), so using that number space for waifs is safe. Examples for (3): the db uses objnums for indexing, and Frame.sender is also a cObjnum. In neither case can a negative number ever occur (except as waif). Objnums are also passed as parameter to functions (in places where invalid object numbers can never occur). Trust me, it's safe :-) It's also unavoidable, if I don't do it I'd have to change a LOT of things all over the source code. (everywhere where an object is identified by cObjnum alone would have to get an extra is_waif flag or so). This is the cleanest way. (note that outside of the bowels of Genesis, this is never seen. for ColdC programmers, a waif is a totally different data type. The fact toint(waif) returns a negative number is actually convenient) >I think the intent Bruce had was to try to not add new error names >wherever possible, so as to brake as litte existing code as possible. >If you want it to be synonymous with objects, you may want to throw an >object error instead of ~waif. OK, what error should I use? (I really don't like ~type in this context, and I'm not familiar enough yet with the whole thing to know which errors are appropriate in which context) >One possibility might be to use structs that have the same layout >for the shared portions and then to do some type casting. I've been thinking about it some more, and on second thought this may actually not have the problems I first thought they'd have. I'd only have to fiddle a bit in caching (where it must make sure a struct of the right size is allocated/deallocated) but other than that there should be no problems. I'll make a new version in the next few days (I'll also pay attention not to make any unnecessary changes to the source code - in particular no cleaning up) - xmath From brandon@roguetrader.com Fri Jan 4 16:01:14 2002 From: brandon@roguetrader.com (Brandon Gillespie) Date: Fri, 4 Jan 2002 09:01:14 -0700 Subject: reply-to and mail loops (Re: [Coldstuff] First version of waif-patch) In-Reply-To: ; from xmath@nubz.org on Fri, Jan 04, 2002 at 04:58:18PM +0100 References: <3C354518.8020706@cubik.org> <20020104083527.A26096@mojo.cold.org> Message-ID: <20020104090114.B26496@mojo.cold.org> On Fri, Jan 04, 2002 at 04:58:18PM +0100, xmath wrote: > First of all: can someone configure this list server to add a > Reply-To: cold-coldstuff@cold.org header? When I click reply, the > mail defaults to going to the sender alone, which is usually not the > intended effect. It is up to the people on the list. The reason for it not doing a reply-to is anti-loop. But if nobody objects I'll set it up. -Brandon From xmath@nubz.org Fri Jan 4 16:00:41 2002 From: xmath@nubz.org (xmath) Date: Fri, 4 Jan 2002 17:00:41 +0100 Subject: [Coldstuff] More suggestions Message-ID: >This could be useful, but the name for it should probably be similar >to one of the existing languages out there which provides this >feature just to help make it slightly more familiar. Yes, the name was just suggestive ofcourse.. I don't know which other languages support it, or what it's called there >There are performance issues for this patch, especially in the dev >tree. Any code that relies upon calling methods and getting back a >~methodnf if it doesn't exist runs much faster in the dev tree >because we cache negative responses. This moves some of the >handling of that into the DB, makes the method cache less effective, >etc. You can put in the requirement that if handle_call_method exists and fails (throws ~methodnf), it must do so consistently. Then negative caching should be ok, you just need to flush the relevant parts when handle_call_method is altered. >I suspect that you'd like this for doing RPC-based distribution, >right? If so, there are other ways that you can accomplish the same >end goal (distribution) without some of the issues. Frobs yes.. I suppose it isn't needed that badly > > 2. [Genesis] Why isn't there a way to do bitwise operations (and, or, > > xor, not). Doing bitwise and is sometimes possible with %, and doing > > bitwise not is possible by doing (1-value) but it's not as nice.. > >There are native methods on $integer for this. OK, hadn't seen those yet. Maybe a different suggestion: better docs? :-) (if there's some convenient way for me to add those, I'd be happy to supply some) > > 3. [Genesis] Support exponentiation of integers: > >This should be okay. see http://www.nubz.org/pow.c.txt for implementations > > 4. [Genesis] It's a bit annoying that to convert a negative > > integer to a negative objnum, I have to do: fromliteral("#" > > + tostr(num)) because toobjnum doesn't work in that case. Maybe > > add an optional argument to toobjnum, "allow-negative" ? > >What happens if you j ust toobjnum(abs(num)) ? Is there a reason >that toobjnum() imposes this restriction? #1 is $root, #-1 is #-1, #1000 is #1000, #-1000 is #-1000 Apparently (haven't digged into the details of this mechanism yet) invalid objects are returned as negative numbers in certain cases, but it looks like positive and negative numbers are still different things. I want this ability to be able to convert any value to a buffer and back, without change (for RPC), so #-123 should be #-123, not #123 > > 5. [Genesis] Where is tofrob? > > Strange.. now it works.. last time I tried that I got a parse error so I assumed that didn't work or so. Disregard this suggestion then. > > 6. [Genesis] Why does objnum() exist? Why not do toint(this()) > > instead? > >Cognitive differences. You're asking for the objnum. this() is the objnum, with data type OBJNUM :-) anyway, it's not important ofcourse.. it just seemed a little redundant to me - xmath From brandon@roguetrader.com Fri Jan 4 16:31:29 2002 From: brandon@roguetrader.com (Brandon Gillespie) Date: Fri, 4 Jan 2002 09:31:29 -0700 Subject: [Coldstuff] More suggestions In-Reply-To: ; from xmath@nubz.org on Fri, Jan 04, 2002 at 05:00:41PM +0100 References: Message-ID: <20020104093128.A26889@mojo.cold.org> On Fri, Jan 04, 2002 at 05:00:41PM +0100, xmath wrote: > > > 3. [Genesis] Support exponentiation of integers: > > > >This should be okay. > > see http://www.nubz.org/pow.c.txt for implementations Checkout pow() in coldc :) It currently only supports floats, so for the int ops you would have to do a tofloat() first. There are alto other mathmatical functions of this caliber in ops/math.c and they are explained in in coldcore at: ?coldc>function>numeric>math -Brandon From brandon@roguetrader.com Fri Jan 4 16:34:01 2002 From: brandon@roguetrader.com (Brandon Gillespie) Date: Fri, 4 Jan 2002 09:34:01 -0700 Subject: [Coldstuff] More suggestions In-Reply-To: ; from xmath@nubz.org on Fri, Jan 04, 2002 at 05:00:41PM +0100 References: Message-ID: <20020104093401.B26889@mojo.cold.org> On Fri, Jan 04, 2002 at 05:00:41PM +0100, xmath wrote: > > > 6. [Genesis] Why does objnum() exist? Why not do toint(this()) > > > instead? > > > >Cognitive differences. You're asking for the objnum. > > this() is the objnum, with data type OBJNUM :-) > anyway, it's not important ofcourse.. it just seemed a little redundant to me >From ColdC this() is a dbreference, which has an object number and an object name. You can call both objnum() to retrieve the number and objname() to retrive the name. -Brandon From brandon@roguetrader.com Fri Jan 4 16:35:54 2002 From: brandon@roguetrader.com (Brandon Gillespie) Date: Fri, 4 Jan 2002 09:35:54 -0700 Subject: [Coldstuff] More suggestions In-Reply-To: ; from xmath@nubz.org on Fri, Jan 04, 2002 at 03:49:19PM +0100 References: Message-ID: <20020104093554.C26889@mojo.cold.org> On Fri, Jan 04, 2002 at 03:49:19PM +0100, xmath wrote: > 7. [ColdCore] Add some mechanism to $root to associate custom > meta-data with objects, such as custom flags. (yes, I have an > application in mind, 'remote to indicate the method may be called by > an RPC) It does exist. Look in $root.add_flag(), the code even says: // let them add any flag they want And from the command line you can do: @chflags me +fribble which adds the 'fribble flag to me. > 8. [ColdCore] There should be some way for programmers to get a list > of tasks that are under their controls. So, a programmer-level @tasks > and @kill Sounds like a great idea, feel free to writeup something :) -Brandon From matthijs@cds.nl Fri Jan 4 16:46:17 2002 From: matthijs@cds.nl (Matthijs van Duin) Date: Fri, 4 Jan 2002 17:46:17 +0100 Subject: [Coldstuff] More suggestions In-Reply-To: <20020104093554.C26889@mojo.cold.org> References: <20020104093554.C26889@mojo.cold.org> Message-ID: >Checkout pow() in coldc :) Yes.. ? >It currently only supports floats, so for the int ops you would have >to do a tofloat() first. Umm, no, for ints you'd change the check to allow ints :-) toint(pow(tofloat(x), tofloat(y)) isn't integer exponentiation pow(99.0, 99.0) is something along the lines of ~inf pow(99, 99) is 3762844539 exactly, because of the usual integer-wrapping pow(FLOAT,INT) doesn't add extra functionality, but it is faster than pow(FLOAT,FLOAT), or it should be at least. >There are alto other mathmatical functions of this caliber in >ops/math.c and they are explained in in coldcore at: >?coldc>function>numeric>math Most however really don't apply to integers >You can call both objnum() to retrieve the number and objname() to >retrive the name. OK, that makes sense. >It does exist. Look in $root.add_flag(), the code even says: Oops, I made a typo here. I meant methods. I know it exists for objects, but I meant methods. For example: http://www.nubz.org/method_meta.cold.txt > > 8. [ColdCore] There should be some way for programmers to get a list > > of tasks that are under their controls. So, a programmer-level @tasks > > and @kill > >Sounds like a great idea, feel free to writeup something :) I will - xmath Matthijs van Duin (NOTE: PGP key has changed!) - PGP Key: 0x2D6F0BA7 - - FP: 205D F7BA FFAD 9070 AB9E C5A8 BDB0 CA1B 2D6F 0BA7 - From xmath@nubz.org Fri Jan 4 23:05:05 2002 From: xmath@nubz.org (xmath) Date: Sat, 5 Jan 2002 00:05:05 +0100 Subject: [Coldstuff] Perhaps a silly problem, but.. Message-ID: Perhaps a silly problem, but.. what should I call those structures? Maybe I should use "Obj" for the common part of the Waifs and Objects (otherwise I'll need to change a LOT of occurances of Obj to whatever name a I choose for the common part) and use cWaif and cObject for the full versions. so struct Obj { objnum, cache info, vars, etc }; struct cWaif { Obj obj; cObjnum cclass; Long usage; }; struct cObject { Obj obj; parents, children, methods, idents, etc }; or do people have better suggestions? - xmath From xmath@nubz.org Sat Jan 5 20:28:48 2002 From: xmath@nubz.org (xmath) Date: Sat, 5 Jan 2002 21:28:48 +0100 Subject: [Coldstuff] Waifs draft 2 (was: Re: First version of waif-patch) Message-ID: --============_-1201859963==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >One possibility might be to use structs that have the same layout >for the shared portions and then to do some type casting. OK, included with this email is a new patch that does exactly that. Please let me know if this looks better than the previous one. You can also browse the modified sources at: http://www.liacs.nl/~mavduin/genesis-waif/ NOTE: textdb.c is not updated. this patched version does not actually build, and has not been tested in any way, it's just for review. however, I have confirmed that all sources except textdb.c and modules compile. this patch is actually larger than the previous one, mostly due to small changes (casts / type changes) and because this is a more thorough patch (neither this one nor the previous was done, but this one is more complete than the previous one). One thing that's still missing is you can't make frobs that target waifs, then again, do we need this anyway? >And in that line of thought ... it'd be easier if, in the future, >you provided a short doc explaining the structure of your changes >and what some of the intent was as well as the thinking behind the >choices made. OK.. my main changes: 1. The common part of waifs and objects is named "Obj" (to avoid too many changes) and waifs and objects themselves are "cWaif" and "cObject" 2. because of this, there's still a fair amount of places where "Obj" has been replaced by "cObject". quite a lot of casting was necessary too (mostly Obj -> cObject and vice versa) 3. in various places (cache, Obj->objnum, Frame->sender) a negative object number (except -1 which is always invalid) means a waif. - xmath --============_-1201859963==_============ Content-Id: Content-Type: multipart/appledouble; boundary="============_-1201859963==_D============" --============_-1201859963==_D============ Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="%waif2.patch.gz" Content-Disposition: attachment; filename="%waif2.patch.gz" ; modification-date="Sat, 5 Jan 2002 21:19:30 +0100" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAA4AAAAJAAAATAAAACAA AAAIAAAAbAAAABB3YWlmMi5wYXRjaC5nekd6aXBFWmd6AQAAnwEtAAAAAAAAAAAAAAAA AAAAAAAAA8oqYQPKKmJLbQwAA8oslQ== --============_-1201859963==_D============ Content-Type: application/octet-stream; name="waif2.patch.gz" ; x-mac-type="477A6970" ; x-mac-creator="455A677A" Content-Disposition: attachment; filename="waif2.patch.gz" Content-Transfer-Encoding: base64 H4sIAAAAAAAAB+19/XvbNtLgz/ZfgbhvUimSXFEflmQ37bqO03jr2DnbaW+v20dHS5TN jSzqSCqJr5v//TAzAAiAIEU5bm/3fdZPG0nk4HtmMBjMxzSczVjrmrVWrDVlrZj9GCyC JExa3q63O2pdXh3+cHr8TRJPvrkOF358P73enVgwvxyevLIgtlutVpWatq5uV+ws+sC8 IWvv7XeG+12PeaPRaLvRaKxvZuvST9lf/QVjfdZp73dG+16Xf2l3tv/yF9YaDZp7rMH/ HbK//GWb2X+vDk9Oazsv/dS/9pOAhYtp8InV/r7zNPkGv/99p87ChD+fRAveizRYpLt/ X+zUD9jfzcrCGatF1/9YrO7Ydy/Y9HqcRsu6DQR/9Iq9YAK6wTyorKHDBHPoS1bjt1Dq OkrT6K5uw4o66a2qNtc/DnLnx+9rp+c/nhwdno5/OD0/+qkWzWZJkNabLAn/b5AflGj+ BZtH0fvVcrwIPqVjelgzoT/zHzDde96o6XVYY6/jwac15cs4XKSz2s7h0U/77L+eJjC1 iyhl19FqMWVpxL56Og+fPGmy9GPgvw8XN7u7MNvNhX8XNGvzaHFTp9brB9ts25h7mKoO 7+nEn9wG4zhI4zD4ENSi9DaI6/U6+327ZY0smKTjaTDH8fD6sQJeb2MNWG1yjg/Z8zoT RYw5ow5Mw2Tix9OaDfF5W35Qf0QDfBH0fjRZOJVdcUBYXRDQ7tbhBbQ2rUziWEUxfYvX 5cQtgLauVgH762rOgCK7++3ufr+3lrJlWY2svcF+p7PvtTOy7nc5QTf4vyPEsa1vnrOT hT9Jww8Bm3M6ZdfBTbhImM//Y5NbP1ywaMaCu2V6L2Y02WXPv+ElQ1Hs1/C3XcBvjkP6 o2UcfOCPnmnP+IxuzaKY1f7BX7QP2D84fYp5D5bpLX/QaCDCbYn142DHbw5POcXVzmG5 PFhb7SU8hbWUQGJ5CZBJwNZ3ihxPzn4en//w17N3b7SKWt999DklQJdyVNz6bjXhNJYG 8Yu2UWXB8NR7x4zAowNchMFes8NXYTBo9ojUYUK3GY5GzMgNR9vbaD4N4topJ1/BURQ5 nixS4LkZN3wqyn0Mp3wmiQIyoNoKKqkXAONgsXH+XpT9IYrmTMxLxk3bGf8A3pGNbjEV SPDEmBP+GLqMaPaOs2bOVAQWMY6k8Cv1wzlgGHwPdUQUWEYLbTYEcw/9aCD2zliYfp1g BR9jmKr0fhlwThjf4zPs1T9WCUwFH3YSYMWNLbFLiMXn3cbPZ8+05c2PRSCNKgtgEn2o hjpjvFP3/j21AtBiDKoAn2GakaPbYPIeKvsI3QyQkScf/SXzF/fpbQirvpLzoJoUa/FE R2aaY6Nn0zBO7+k5ln3C97HlKiUmqVVUrwME7jH+IpzUdo6i1XyKm0uSRnHA+yJWbHdH EdXnjESBxc7iIBAsUxGV/pBtASMlJFjMwwUfc8pmMd91S1ZdTq4gJEVUB/I1/FB0qE/u FiHGLxoyxIE/n0cTP5XoV4YEMGs0jsA1MiZQ5fs8+/mFPwfmw/bLWVOe9cAHPJfbHEky gnIOZd99jiYf9RG0tgq55GP1NN9LtRHjF96/U1hSnbTxx23gTyVlixXG/QQ7DlzQ6+yB iOn1vGZngGxwm9fG//+GtR7lb7sBi7zdwAGa8s14MveTpCaZHi65pJ8nasiECfgT4cWu Y0oRMEm82lW8YBn7/AztqkUuKGyJXDVaFlFtnRfDclKeUbgqa6vTc7NxesYXJQqfMISU q3LLt/TrIFiwaZCkcXQfTL9n/2cVTt43Gd9sWByq1cLVhqlTA5jCWr7gAjc9cwlLomXR mbN3p6cH0I3k9rZJ/O1DELMZyau3XHyF+nGW+JI3Hm/JOfYgBl0EfGxxkOzzXTBMQ3/O 5fQpdXwXAd5EXLILAeAoWsDxJIHhE6I2FVNqsqk84szCeZAQ4nb3mlymaniDDnwC5kKr wLkcqPan799CQjaOQe26gUQoDRk7yLbCI1w6jbovAz+e3BokzECK09gQTsrAaw5Yo9Me NImYv+JtvTz+4d2P46PDo9fHpmg19oVY1Wjwtr4KFnwxxKZioLP+xEnB2g4j2RL2ZtjG 3nh7TclaxHAuAJU1ZsUPVhH+Xs79SdAimasJE4ViRcTpJUze074kZ5DvpZxk1F6K2yjK rWbfK/Q7z+zPoyWXsPnaJynfsxj1B6UlISmp/ZKWwucIoq2cvoE6xV6YnU6XI+6IT8/e sNnpFK+WWqVWS1slnAWJu6oVFwLnkLcIWl+eWRAHiwkfHjTNbrmowI8KcXAX8SGj0JDb TJghlTtFBkMud0kNzGKyyP75GpqsTu6VJh9Ggc6UvjiSKcH3SkO2hMErNR5dDpKMpolL Gor1528MytHwoUh6FhPDfuBf/TiY8WOkf80lSeS7TeM4n4Qw0+qwjvtCDTYmTuLhdDrn e0GY3mL1xDoZ+yX4mkuFiT/ju3piHPpVZQ+qSR8kKCzgBApbZpgsvkbZnQvFNLREjT68 C2D0nBynwbxWF7gvfupC7gFJSvoopVSn91cyk2Lq0UTTomPJln7+M88Pgvr2SNXTbXPq a2vnP+D3hG8TOBn8u20cbZuKZA3sdyTtqX+3aIr1BO0SyLPXQcrZC5c47r8niZykJFsZ JVeRJPYnJPzoe0P7IEercoEFhKdJZiVbW8ZQUFNB3bFPuQeImXA81BeXaec8gCIGYB/c XsiVqyMydLttEIK7A6lofXQZmFf1yy2nGM4KYNr5TrNKuCjEh/c9u7zF0x5/fA+q2vlq StIfJ70YzoDfA/O652SK1cChEMtyUvyIC8jJEggxiVYxJ/2Un5Z2d/kvdgKEz5d5GkzC aWDoN2iRZmGcpLUPUYhsEiai14GtutEb9MWObf+NQ30zsv9mQkUaxDEIas2db59OQQOq StWtHcyhrdRPew4Q40jreF/EMuy/CZc3w8UqsF593kTVGE2Dm2BRomyUAGvUjRLMUDi2 93ud/fZgvcJRlbZUjv19r5epHHt9XFi5rnxfS8MJ8ih+mh3/Y3W3RAZM2HCgAOAnA+2t ghgDztWgIPzSQJHfTcegQBiDQr52Qj/Yc/EUNgAB+yZIb6Mpez7jnHk+XuqnQI4DsPTF gOrspoCRXNlVcLeMYj++x207XnGmwOVG0J/4N6RvynrK3/Nuwcf4ejWjHWFvD6VV+kDc f75F9xlxzAmRFCOgQEvETp81wuvgAtMuFGHH/Osk5SeaC2R5oMG9o0Ekq5ALF3wTBqbm T6egW+Jir9Lt4OasmhXkwOHGVL5WbwJDAPkSeDsx74/wD3aQNMItOWEcJYLYTwNZ+G0c 3bDnS/5vk+lTvd2oUsKe823gqkpY5PiBU5JNFBP0DuNrZ9yc0+UYgRAfEtL20rllBCeW hvjUZx8kDjlAaGUMPWp998GP8QLmI3BVLsFFcXgDODK/57wzoaXITpeH02nCbubRtT/n OMrPmfA8TpqwDAlHC862bhLorDhPmSvJz6b83JwmSkKULDePA3SSkUtOS1IN5zdBeTX9 Ela0J5iZJDz+PJzODzZgaTA4/KeYqWkg5WxNA7RvUvr73dFaxqaX11nbcN/b2/e8jLXt 4SXpnkQcKWvwpZlM7pY1Wl0uzXGMqU291nerXf4Ibg2NFx35Qr+dA1U1oz1kX25H+Ax6 uZ+1JerN1MJUXf66Dwufnlxe7Qvt2xC1b52R1fm2XebVxfkPpV3w7BIvT45kK32cIa9v t3LrJ7djMQ2LCErVpnIaHjAL02zMxUPu9LrQmU5vT6pttmAjgaKChF4IWhpPV3z14kn2 Cs8F13Hgv1dSrtGThqpKCQEgSOkVaVKsqKghOzoNZv5qnu4rPf7JGUfns6Pj8cXx0fnF S6pC6LKVGj7mB01ePTTMUSqe1MX5YtjDYY68JsfVTPkh+vvDu1evji9g7uRYhcAMCG8M WOuna8A0PqtwfpBm6ydnV8c/YvM6hp2eH4o16qLGptHl2CnWyIUKkgmJN5yM1EV5MAs/ /fobn/7fv/6vr5usBi/ruHV9PtAlP7pscx438mPR2pL8UBQlbZkGoH9HXZFRGdg4yCOV ITyWq4ZzPWLblgkFnInYP/+ZyaE+Pxvzs0bLq5uThSd1tEzglJdGYz+ZhKHVQJMtOBII dOp2UH7r9tpOwRzqwn1tLC/hVfumnKyu7lnhhXuj6LWmd7EHn7FcYCUgsxBXFQ9AvSKe EG7AvQanFuTB82BRS+pZNz/TgPt0JNvri0tyJ/GY7WrN7PzvX4mCfttpslG9iF0Ul/8W COs7Xniv7mARpU1/i2qjxSTgxb22UjCSGN7uNb0+F8Q7nSYXzzcjLT53fJ05ReVoiBEp GM8BkQHZI2THRdSTewNFGBbibZkYeWAiD2D8bO5zwekZe/lq/MvJ1Ws8bx2+Ob7Mmayw zam8rH68I1akLC+ONiDmyEHC1cg4d3AtnC0HpKqe999mSqwNT/UhZyfYy3o9fxw2qysu yNx/otctQhAHQJ5DRTpfcpQQGPrV1wdCndDGO5pedyA3EncrlXiXg39V4GFr+ZhWuboD KBxV64E8vPHQmaVLewZ8hpfJGOwEeGsTuiZ2iN4ABY7eSJmuwXXMVo4zi4Jf//Z1IVe0 28qYeZMRY2Rfcc44QAGj+hSU1mvtBY3ijn/3dcaRDZHNFteoH7q8JurkIhuc+9KYagS4 JkPqkXM5wkvxvjcydttMEJc1cbZ/PQ6nB3nBW8nEIR4P/fg+Bye2MQkpBEGAyi2KhEFp T9UjR7+19XtOVlXDZtmgwymS2IFmx/d508MhUuqa06GAqXA8FJDG+bADii+OwpXOh7IC 64A42G9ruq9uh6RZYzE5BsRBkvDZBMuUGahU8fsiSPET7jWiFX1HO0z8NvPDOQHKem4D P06vAz8VNd0En5b4Va0nr5PP+mKGXxN/TpCz1QIxQ68rWoI2D1/TgR6/hqBJ4YSeitqS 8AY0A/B1GsZ8e4sQuZosiLANyaSu/QmYvU6jRaBjlfm4qeHUNjuB6WTL1fU8nODLZRyl vAUxN8s4/AAaIhxpFNFApvyhnJ1lIHo804e1iCIJkdwvqOJ5NHkvZ9wH9T1VEMXyqZ9G d9gJoSHiAjCelHXNtCqpthC4Ed6hxzuSkaqaTCh6rKDMaTFBtXc7kpmLaTMB4aGq8fL4 +Kfx5fFVDkq+MCGP3l24IfkLE/L47KUbkr8AyA1JWui8ymlaAlUgaglqU/Vgv9uuRtWq BpOs+95+Z5SRNT+kdnocJfaavAG0/3ikOxu0JGnxmo5B79jCe0A0BFywpR+jlUpIysB/ RNfy5nfiz+cAJOl6l7HDeRI1sSKgU4bWhAm78+/Zrb9cBgsQ3zLtL98rr4M4mMprQn/O j+7TexZ8Al3pLl7+ZGY01GZ0d0edStGCrA6dETJvgjfYaMyUZKYx2y115Abt8iL4qF9w NtnkFDX2cpxK3hVWsRyeoz+oDy7ODk+VInkc8n6RWAUgTXWQEJemTN6HSrHVdc1JAjbd EQt5Gp0NwDil5fIryDwVeCGXY8J2iwpCn9TRQ7Ppze6lJVTrO7nAL1CPjZojORcG3OQ2 nPMNZCEBYSbhrNdSenFtrT74cQiaf440eAEAKwO6N/qZ6cepalBt7/I3mknhzz6XU34+ vBhzWru4Ojn7cXx58r+Oldl8VgxqNYvyaXcXRUEH5Zxuv9ntK6b62dWXX3M1sBbzlM15 y1OyJNiXLqdgKInzDXtBpOzYqFK1wNnJlF4kdBX8gmFLnEUeXhy9Hh9eGUBoVKvZwRkm bwJDH9WmDWrBmh6FHTQejx0YppWbkHTDVAOISTOJNFQaxzyNNlw02lhDow03jTaytbVP 7MjdiLcU0a4y/TJQpJSIG+uJuOEiYpLIqpGwgLWomC6L2N0STh1vjq9en78sI2hZSQFN F1SANyLDpjdkjeFes5t5MVGlKDIkeEELV+Qvj8+uLs06jD7AjR0VEa4ZOg8sJteMCx5O hampQGth56dmHi+qOM2I9TFMyQCdV8hLxuJ1jbYXXCwuwGcKnIyxoK4GGZLOraPFQumJ tedgpaCeG2OzuYy86BG6A8VnRCGT/Tw65znitK9Mz0HIzJM/yqOAwHLvFYbLitzJrFkn dqUhFPqqzFpaaIZayjXP4LWKVqWl9MMplToJmzN+Md6tEv8mEEtQsgikIuFTjg6TXrPT hWNCV6pX+eyBO8eSbtsjBsJxOOHH5l0lFbXQykG3P9EvZmECNZknB2tfzuryTqhbVb7i 0GrHQOFMJ4IM84lnZfosXqliaZJDOGFkfXWFy7JVKYDgSVQ0Lgyu6Y5a2VqF5BUWsm+Z rBZlAGAY/LH0DRMsPnsPMgK4VwH5PVGqUnKHwVOK3Vm7FJoHolaDnwAU9DMX+Ad/jtCf qd/iQ/mJGPBSanO8FXzVENpwtiTjNa3QHDMjAY3JYcbkaDsBdF0YnHndDt3I9uEIIzm0 2Udiu9IDsiHxzo2gGsJl3geVlr6x2dI3Ki59Y7Olb2y09OCiI+0IS5e+sXbps9kCKDnw ZBlMQs4mWJKuZjM0ROcsZB5OcCblrEntO9YrbJWlr5liD5ajijBvQgPIRz2vIlr1PPKJ GOZ8IkwmJ21tbTRycjkJXMTohIApuY+UH8AtnT2fcgEU9v8D7Rz5XmmjVJXvhQJKiV18 oUM8RYC0IAyohM2yErVW8ThJ/TuUPkkh4KHc02l3dLLSpDybU2byA/RxF5SmHEoaDbay N5pFgaxD7ZrroLLbM0VqUylxkglmxrjZlP+XiaOfsndNNhX+De9R92NfpFn3/gRUdptt XmVDgbzgHMwDLnzxf+/445oO0mTPcMxYFglBf9v6bs5HowwpjN1Kh1NWFM7Wudju2P62 iqXD96hZ1IRD2CJoZJo817JslN+TuzrBwXrpsl+B78H7zGn9szhuKgZdRFzSJ4xWBKGE 7RhofTdhMrYZvZPHZNR0HUWp0BctFgE1GS0MsbyGrjbicFlXJAYla6pG8unpNLtg2NIZ NbuWV89r/wMeeWNwoxV+E8RBwflsGoEx8iKK79BKD6CaxHQzsPTWT4XW+DmVMQtkwopl LSzYqm0kLGbi82NadJPI6OSUFjrq5/JmAXO1zzf63TwWY1tb5Bos2GztOSI4P1HXxJOm 5LV1NAzU9HVLi80yeqZxbZpp0brBuelNpsTPLlOJnWfL/sZ/D0cTNIwknF7FZOSaO+lp zPtPYbjUVsZXLHaiIFxMWbGcPE9WPFCy5OV6hrzcjB0vDe2EtujaC40Ht6BACY9bUh8q 87dlxt0emXrgOHsWpcE+AxMZMM9uSR1Zwg946DDKNDstVltE5A7x5EldOelIUnoNKhil +5I1JhTLYuyvPpm6MAF+K/0dOh00O+4Y/g5CAfr68OdjodM4fik9DghF3RuVvks1CsBs Vl3PneycMVBcWMrPy0VICk5QBpLSYEcdtw3Z5+yrOWiqom7Y/aDC5oUYm0ZJDQvAGKmo SCc85TMCg3of3JvER/4CjD/Hfwzqg29NeFrPWdXBZolGrbNwMa3dEhRoLV+NIVbSu4tj hzUMaLCwEBcaZBlhddclO8hhFfSQu24JhliiTFUkgZrX44mx638ZQyMDPCSNXntPG7tm nYyqLzhyCtqb3PqLG2vvE3uY3LpkB/hWWFjOOmTky6pTh1Be0Qvr0CGWD3z8enwM3lBq g1BUnZJVCBxWM/85bXhT1nLOG7Bl/A56b8PQiyRg3W1QYLwwI4OBchRTDEq8blp7Gxh5 PUZVu1pYkUrjsoNJbH7+MiJC5dWneue0d1mLVwGXF6NVzKL5VNEEiINcDAQPVb4JgJUR eN0yFPNBkSGwnzzJ51MlOcrySuRAbODsDzw+ez0juJeYG7zBsnEabJTIAMnC50vwHwIr eQOVNfA8GmdFDAVhk13P/cV7dYcm5+NH4VMjTws4Z4voYxM8+z4G6NMrjYLAp9dnk3ng w1FikUxC8N22ZeUHLMppFL1HVoJ9BGcb0JerCzD0Y1ow2LM5ugBd0OjXK87gWkF43SjN Et5HdjF+QW/YzjOdUC6QoZsgDHCuknDArWdHM0eJ3EKpUnKZZJ9Ff8kBNQ5miXKBNI5o ObBsbKNmx4PBDeETuZGzEJnJiTsJR7y16guJBQnzxOhBL18+V0Xg6ycqi7vgHFMBfaGK 0CIvsHd+ji/yBEbwefrSy5RRGPyhTGhqnN748fscwTWFO/1HcJzn/OkOHMru4aAMrvD8 AVjoJY9AaEDtnJIy1zR1fNIe2cRlmQDR2KUBYw/oqN/rbkhHjtUoJ6OC5SikItJqryMi G0rSUL/dRwVnv98zDYpdBXF+zs6vxodnY7zofBRykucJSR4lMwZKHzd44XwV0JI5LNEV DGI3ghVuDHsdy7VLOQTq01/i1P8vIbUCDtDZJljcpLdKQgFJrS1xYEiuMMNBTw4ZAnPN hduqOuTjEUA8HCNETU42BuRkYQJeG9dKganXYsZyE8+4mGedlukFIopQQG0VnKdzkFS7 6rPeOOots3A0JdOG09ElDBh2zDNKNqNZ98VsUG0JBc8hE22ckZbXtDoqBVN9thoPrGY3 X5WO6mrsErWHfeRho3b3cVE7pwOyELoUj9ejKj9seirqzHkW9StazO/5P/IG+IAJ64k4 4HJ0En4I5vdKVB1S4KRRZ/TFa+rPUoik9AjLWlzTxis7GuHwekNteBfHVxcnx/xMfQ5W 7OcXY/7g3cWZIlrb6w52zdi/pqhRmryfPxhokfr+FZgcHHZi/0MQi1CcRufB0vgjL5Uo XBiRimo0kOfwLX7A8cneDFRAiFMY0m2XCzYBr1j062tQp5lxnDBmgBBqqCKll//oL9CP Po0wEB2aTIDxmRH7knfVv4PLHd6uZK3YdF3c3VtKxyJwg2MWO+hUKY9HcjcUXzeNVYgw pXjpIdguxm9etMA4PeaH3es5RCyFuwiiTIgTxSc3WwkuwIPwMeICvEf2kkI1mh2UVLCH aKEF7TQiMxRuT4YMgXIDER5GgZWklcVrWFtPSSWGgLxQ7gYHZlQBeGhf1FKrtm1gdjNl xK9rGPw5F7LRQRCZSR1fCTB4BLegiKx3KEYrYCefZT/lKxRRGAYYoSYWLzK5GKqroYkB e+q22qBLrbY3ACPyhtceeNKanGpTO7SYYmACgvkebNtRtkXkDMWypF2LO56HEkdohVSt DTd4nvPki2pdtoSUjP9o8QJyxwCtuSJs1JGDBKVGQQ05Ibe0FhMfbz/4800MAmgVydHH aw91nSUv/RLvsfWSdN0JevIwWiV07xmArYIw26W7UU7D21k4NHBYkeV/OTk9ZUeH7y6P 2duL8x9Oj99c8mWAi7AELr/uoxWpSdh1wNlCFj1Orz93melAIWke44bSPBl1aG3aZvqg ia74wGar+bzJB73EIHe0ZYZ8C5pEcRwky2iBsWmAeJRKLTNzpakejCCuQcPzuPjp7anJ dpo9qbjUL3LvhSHOr7Devx246zBgMODb9OCLjnCaRkGbTDfCk1lMaQELWiHyc97RZZO6 +yAm2t6Agz7QYsbziGQocCiJFw9YRtIPHhSUFtrDbOW2ipZuq1xbsqVCDtHpeIG8z18Q RalRf+TiUbKaTIIkAUy/Z2THMhWSjMkEaRo6Q5qG4UDjHCaTOshtCRUPmuAxOj48+5vc CaQVq+R930OEtuhuGc4D8aypKBrSeIByf0buqWxf31mrVOTaNYoqJXFGQ3ZQWEiJCkBN iwYT7UUwadTfet1O2zy5uOhOJoTQK3WRm4SzbSMMYuN8azVPpZG6pApi83T8wgjkMuCn in49wMsA3uNuW78V+GyeLp2m5QYCKw+IHPbS7Yi+9VJfHdxIT5OhZqUpvDJd3EgvYEyP XShTe+qGERAPMgoS3AJ095Lvs/nhBEHz09trdkcWn7czkBh7T/S+KTLSUAaAj9gZteeJ pCwY3548/4lazIihjSqgu46zIWxpGCAZrpQ+LthyFS+jJEiajLMCOBndBeBfI3DBjB5I 6yxsV7m8Z26rWihLtPuSF5Eq0pDl/NbQ43sCE1cROb+3VRZYQpG4sTmQTW0uOjnayCPu bRXGQfhsmc+TEU1ms2aEEHr8zstAodS68arVcg+IBlsWSdQe2jffMIyHhxHarllCITWv 4d4QtefgsOzD8RfuFIXpW3h3F0xD2DE1W7zN4q0Tn/iKHzaDGRsLotjE//Z6yQ/8Ja63 4v0ar1sBZYVZ87r7/QoOt7KwFT5yb7/T1sNHiviR/fyFAp2jBDMzbNygZrGBJJq49Ork 9Jg9n4FPWAm8Li3pZXL+FTL6BQYu7bn2HaOR1WLTblklNusYKejpo7BjUASmMdcrvS85 IL0jZvPCvavdzDrSJ0mPPjZbQXGTV3kFJfxGE9UntX6/06+6ght0yyqxWce6qK2kj/Ur aPfKuYKujqxfQVKI08dmK0j3R5UXUIBvNk0D1FnTR6X1q94ps8Bm3RrSpA17lVbP6pNz 8RzdWLt2ex0MZ7an5GJ3YL6yIIsf4zANxmAEk4uwM1uakREpKuYIWxw+vEUrQNULyOAz pR64Whx0scVBz3twizhzjRc0z46hOhoFRUSftzrsNDv9ErJofMX36HBBbY0xywLzwAsn Q3vav50IKe2qEQ409YbBp1gBF0Rmq4sgDUjxkPVAhBLJVlapARQ8RctmqmrwX6KkF1ab cldwvZP8xvVOoLP1ivpEt9W6YCz7lddb6EHYtBEVJNTR61lXAmVCvYC6HVXFs1kvtrC1 mywtY6+bUUhOdS6VoQNWTn0VWLEUa0D1pXH03LFQnym1SHubudCNrjskFxEIR8YFfdSK D9sqQ8m2wZArEIxOJpyDiII46xmyGZTignKSDaCfwZHATEDXo2Vzi0nVDtMUUijCFRc1 QDmWMGKzULHxA+OHcBIwuIzwd2z6E91yUaAlIrrfFlChubtZL61DKY6Xlr4KHRYQX56V F5eQXtiuAnk6LKY+57KWFCtFB1nOmvY1hGMtQzXoajRZTIdFi2bSpEaIjn1Wo8mh56FN M5h9CJp0SB5KPy4e0H5qb1sSx8xdN7d1FdFffrPOkNCiHANU0o+zeY2CnO81GnK+z6hI vjZyf2Q+yplHQ768HYRyDZXlJ2JNFrmKhUgXUkhr+WUr9S7ZrJy++M6CBTRXCF9AdYXw brrTwTFxcjHdiWU2Im86lrq4BjelFmA90a5GrBsogQLw/yxRAon3a5RAAsoRS3F9PnJV 2FQCdXv77Y4WaB9P6HvygK5ORmR7y8kadbPSlFHl5cB0N5R8ISHjkkBlnk1SiF0GylrI jEP5Ce8obYPInmAGG4MEEOr2LOuAXEH9ddY/eY8Db9VdjnqLWnEqieEXE/3lCVnNjMPF JEYnaGFf65Gduuflj+JoaqOMr8l7JbuXMe+UjFwc0gpUtISBH+UdzXZjbU0FNqXO2uSe cZnepSJJy3U0vTdcQ59Hq3S5SjcJJxh8CiartASVFUA5Liswh0ZzPTJnpS1sHu33tKig HS7VgnSLn3uayYdwYFMRoYaZW9fU9lhtGE9nMSeAzDRO5H2FjrF9ZqQimuquq1YxI1yA 3hnwTyPnt2fKTiTXo8LqwfQgiDettiZKJ5yrcdoUqv+qQ6JSjz6UVVKlUmZUKnIeSMc+ coXs6spGuB3HBkzvi9RP3lO4Tbj8HoufeKuXXQvcxP61LnRoT/NGwhZAsY2wbs1j2B1l 13erpQo3Jy+m/fgmyTIaysQ4wGr5kUc6Q/XJs7E/yns20j0bgtcy1F9n+Vxsxlc+rpyV UrETLHlxoZqxa+jTyS+pNjP8QUUush1AFvbVU7AkIxzG70QN9J3/8y3//7vdpwmrPZ3W IWVZzk10RmjXhC9UEX6levCrZVubC/8+kxYRDjPcLP65BoVCSDMX991dz26lulhxXehn oTvmAr3JARJhWKkMKFdce7RuJTCQvz1oPQefGRtdBfzUyronTq+jsb7EbpWWK4+/328L X5SuHdweeJa9i/T1udVfgk7ifpzww2aQ1GTJJuvn3a5/bf/mjJigv9eZZX5LaRRUN1u3 aTVK2lEX37kG7SH/6q0ZgGcPwL3udn+qFDOj8KiiHdWjy7+9+eH81PF+tZvc311Hc8Mm wCYtu1z3N+fGMyDBceD1ChIsFv1lVAqYg0ebHI3x4QHvH5OXqYHZFEVfMlQdUFuCyCnd GG+yRPRuIYCAzbAclkQjEsHJDsCCQYiXtLbz9CXnwJivlpPclPxaOUvmkCsQYZ8mTRkg IuHPnyYOLm3+PYsMdmjxQlwPulMb9HW7L0NgQscSTXLSRBBQTSX2i1KD4UeWDaTgSOcW 1aZ6YoItJ0I1pD1Lwwla5olgolcnRz9dCkwdDdDCc9huywxWTJOoXii01njeBx+IBOpU j0vksxZjxTL1g6TqDeTq9ZKjo2ctRyNrONQ62N2H98piWFM3o7K4FOoQKdPlcE+XoVDJ AWYsF8evxkfn786uhK5PippHaM+MMYrvZZTjSIQan0cJnpPDGHxO8AScKEsvYE34iGTK MQgaNSVsF/H4Ovsu07ttWHw3qyILW1RcAiUfgszJj6y2c3wcx8snXChU0zckB0TPlJ2l wtMlLxe2Xi46lxVzSdE5eLdArYFp3knkbUROd52BtT9JsysmMy9oNnJ55ppdXrB1JFIM Y4dxwmACn160D9gn9i2VGC8xDA5/ImJv6tshAcTR7NdPv5miH6RLegL5Ie+WJhRdnOEQ pE3riJzVvHa7U7Jlz8NFMKaQ3flFaOrruJzUC7ataDlGK/tf9eUhRv6rUcFvKmymUZ7u 9YI45jvp+e7Tk538EYStJbv8cYNVojXHmGourJeqWd0vu86+d89IUfn9ogkU6VPqMlhd u9+mxet3rcULNQNuzS+7aKhNqdJkNhe290F9J2zrwpXwj0kgfQvcgeSpsFk81dqyVKpo LQMpFZ0gvsozY7jS5iI7/nieNwK9WcPzIJfdnjG7IDFRpt/a0eHp6fj44mIMIsbZK0N7 8Qp8tcg6+FOqvFQidusvpnPpyJAkMn9zq9D6HjUz0u3Ing0LtR9SAd7eWObGzYrCewES N13p4aoVX0uxD6goG5SMN+gqcDf20a0C+OibyzF4NhTRbu4P3SD+dnzJhTb8enZe10M/ 6I73uOVXaj2LMv1FeLH1yIixVTaJYvVLYfI9rAjt6gNON/hX/00FHtCnHEBLCZbIvUuG Vp7X60j3VyWeyS4Ze3DCD3CTW1azly8XtQ1NwPiCXpyfX+3nyaIAGyxVEN9ToLxIe1iQ qLGaGnOzxncLO9BY34Hy812+bH6VoE0X/Of8I52J23P/8uLkZy0jcPZHXjQfA7ygI/9x Sj0fQmp7PjUYEA2nx80RfcHjKU8Ym4ZT8DcHFSqZ4UvG/iWr9NBJdU0ozYQO/dnc9/b2 yFdsb2TJFFibyEkmWIYUAOnogredTVBo0Fe9EeXAhB05O7zivVAb7h+igXd5I9EIRwMK I95pt23VpnAh5/2U/Ny5oWd7ebxarNm8M5dXLdqEFpiiQsECRpyP9FK43ahxZQNbs7c4 u22w2sbWF3d9DevG7jsdZSrx9E5nT6TL6Izgyx/A099yajq8On4oW3/yokA78PuGrBrY s0UGvxcx2fxsPspW8kdwfzG9j7ABvL04vzo+ujp+6dgDrJnN77xS3/LfY0ofZUN9ZGHm UQWTf/9F2lzqEUlESR/QyekD/kxx52FT/68sE3X65D9P/t9a5I1LtO+SDsA4bVqklhnT 1IYgNmVZ1rMdhy7tXxg70vesmB3tsyz7uTaN6jansJ4CWjTra3xRfbvOOtVY8VKJldWJ EAWl9em8G8ts8G9ejV+dX/xkXQgqaRMy7mrSiIwlI40lpKFEE/vWlE7zFDQiFzZ9uxyb H1OALRJhRXYlShbc7cgIY2/fXb4ev3p3dlSjK5KmuD1pMnKUbwpkEy+z65MPfgxhlLPy SBkc/AoI4/yiaZSXL0vKU1ropsj+zWEnP6xmkMRBvhB5o7PCjawweQYxvPxqalGwmypt WzO7jhdNi8bpRFELRV+F2pKv7xkVhz/IrmSCz+aRDwVenZ4fXgHY5JV4ghp5LEBT3hVT rtwk9WoqTLrV8PpptgqsmVc5jQJ6/UTWHy/rgUicMhAxpiBUo5cJ21MtQASZy6ptxg5d JwOXWzeSU8NJr5AzSjM7VYkDssT6w2wli3ZQ1JyywMuPDz3xQhUYNdsRNh1g6c3SJqXM a1hHl+GCR+Rkxe5WN4q94Y3e+fHufZG9qgIoN4pVYPm82p3RWqPYrLTl5z/c72l+/h75 qcLHEDH0aRq9Dxbs6OLk6oSLA+oL5BqH0FdvD3/k54/sGz7/67s3b1XR87dXJ+dnosTl 0eHV1bFIJax+8TfgoSkKQJ/BMVOVH785fDu+ODz78Vj8eH3IKVk9eHVyCpVov89eil+w iKIa4J/QEWqaBkspDjxlBClBx0eHR6+Pxydnr875jx+gPlmc/353Zj85vDp/c3KklRfm FKKC47Oj85fHDJxnxJfLEyh2/D/f8n9Pz3+EFs8vtfJXh/D+8n/wOeK1E/QhB8G28N3b 81/Ejw6WPnt1AtVcnL/jc9lSFb065UwPJuX14dnL0+OXpLJ/Nf758PQddIQeX6i5r1yC fzs7/mWMa0V2/hcBlxA+BBR2ZbbCJEBcaCDi/ua5bIDLItIGFS/QG92BlMWzXHXStp1J Y3cz8JBMaUx5s8Sv57QtQEASPDDl6sjlVqpUjxEJKlPmyJSxjkTBor1Y+jxsyC/CxWS+ mgbfTKaTMTDDZPe2iKgdoOU8xFHAMrFvd/f7vbXcxFWPyVe83n7P0/jKANnKQHAVKAO2 JiIj8uQVqN5IeISvB3kIlZOKvrogwkkqIUL0D7EhVBYs+dUBgx5YTCXM1doRf+guQn8o kpRCCKki31vAZ/F3DoHcHoAeHGdvgkUF5JCAFVFDgjsciTrVEUPVYm03PWO7GSIHGMpD 4/GnZSzcUSA6IX2vwVPxoGmAwN0cSBlHfhLIZxP5vYZP+QLF9/Ix/mga4LIKjeXwbgcx 5GQTp6K3cXQDOUX4h3DX0fJ4ViuVi1yGnEPZC22++MJfa+3aS7hqSy+hjZVvAyn3R5VX XlWScyXr6guP6y4dyWTSed2KxmK55M60nNDUScad94aS4E7VlZWQz6Vryuffc/ypDjPN wWodJHpiooX9AxZc+jStXXEFWG3JFbi9DfT5TlB5zbNacptAv6dvAh7tApLeuRjDhQ11 OjwRGSzkc3kGtJ/Lox6d8IAMxQt5qhNsl3DljN7Jgy+cd+GFeCwPuHSuVUkuqaMqpv5Z QUfPCjp6VtTRs5KOijBiNBb1k0qQxxqF+u8oryUZ0uTkjEtnJy9RUj05+5H9nXCx5rIo wzDZZCn12+51SKFen7zQVEpgHSdqYJvU8HdBc+tNOwXpVTPizIYJEjc/wL85rtUrjA1N 5KzCYoIqlRcjqz+IXlVKw/UUq4FWo1mtQP4o2PUqU61ej0W3nPoHGt0O202w/BjC2RDw 7uj89OURaaS4LLbo4CacPYsxJLz5bBItZuENkID2cBF8HItwAewBjtNyIPJsu3aqFWC1 iVbgW2+iBU1zB5njcL/frzzNWS2WKDSCc7uaZDyKSqtbMMam4uzbJJ368c3u7XfFB6PK 55mDsmPRBrVQFBixZYrjjrgzgB0P9vFFJJMysdkdr3V3dxcKahviIqIiSQ1qe+DGiJrW 9SsvwKqtuwD+IgFY1pEjLG9gnIoGeCqiVeeyaBAvROTWOJjx0zPEDWlyKTXFzzS8C6IV fY/gWgq/zXw+/QB4YFVxG/hxeh34VCDmAvmnJX4VKmasmjO+xQy/Jv48ddQi2QS1Kk1s 5UUBfuV7axAvOWpgpQfbLaOCaRhzvIrie4QNImoNMl2slmPIsIBlGhuXEapukcfLKL5c Xc/DCcJwCTzlVYmZXMbhBz+l0nEU0czQVZ1j6Iso+iDmKblfUH0UB17MHZr64BpEsXzq p9Edtv2QU92dP4mjCpuGhKuG0BL6i7YLVUkOpXXBvjeicJf/kVAqDe8RhRSSEDsguHa6 HWv+KZkO6vJq0zp5cCDyLleQLTeOrvnjA0rDA4BXF++Oc6VfnhxdOUpPw0laofTpyaWr NJ7V86UbVmlAR0dp4ACutrPWj06PD89EMqGxuPWCiug5J5ajn2q8fA6goAa8CKOOuGuQ ALQevS6uR69nrYdZZ7YqBXUSQEFxbVncxQVAQXFtXdzFBUC2JEZxbWHcxQUASXgQwuib 54xu4cZvzl++g4Bx3zxo6xeXR2t5pYSrxisltKUE6fWqhB7JVaLzytF+H2RHXQkyAiUI ydRK4NuZ8e1893YHJkzTFgp7ZimcqXxkxlMZtYk/Vprpn/04BB6SoEkLBneYYv5KyunR JD9bGakdQo8lFJYHmCaF6VFZQLT0PKBMCyH5JVyPCfuYeRJhGkutLi19LIKGiarso38v M9mi6xKaiegJgCLI4/WeBX4SasnROuJs3uySEfoWiZQi1CeFyoIQYyAVNLQbvB20s9wR ip19kVwY+y5iWeEEEY5PoTVZ+hUfgpCSk6aIHZ5I/0dInBLMZwc4UMxTz598Ta8p2J6s SQna0uBTxULnbbyNUIhKYNToDQN2RCo/jfSz5MuGBhIgWYdkV5tFaMdyB/oDKK83En4T saVsCK9p+F4SxCLAfpNy1GEeEWiJ4opAa7KZo2ixwIPBQgZgB1ydjFO5pPBTb/BkQb7d XHxUGU2znCQNPY+3cXW7Qh06xdQ6cJhonULiM+qbCJrHp+1DmEACM2Fk1cjUb+DfecBc pl6kawRvVoCBSrA41cxR8s6qaYWOqEF8kKtJvNiHfH7Z1X2WgS3rE2biovyyB64+vZr7 N/t65sDrIFiYQbH0ejiNHWxVrwdD3Uf3+YoAdd2TZFSEZnBoJWAW5yfc97l5cRZHyCmr 3UzqWMdnRBjrjkbLPKATSo77Ndzcr0EezTK3r0beyKNyTJCzpkvM9KtzAn6uijk9XIc3 nEdmPBALy4KAOkuNdGX5JJLJy1V+PU5pnNA4EUezrC6I+qE4G5cSOj3WGLRltnqJeJAu m+LhHWghrvHBWPA92gfWklzLRXIti1QEFBzevwxP9Xq+CE9bG5HguYv2WiLY6pdzFrG1 0hFRxAo8yNckOIBMegJ4nq3Sg9l9y2b3rRy7N64ybULKuvAFm0Ertxm0ijcDHeMoDKZ4 iCuBMS7Bck8LFyinjqKWUHayLA12SsJMEt4t55CNG+gRQtRGM1EggRLku90jT522UquJ uRFKsN/1lcRl1KZThRl0pu4yaBNimYhHBEfUyp7zF1Ct8yVEcjkQkejQo6jT6ah+8onY fYw/YXyhlDioDonwyh4Xkgt6aThR6jzhorJaQiKxseCyho4R0KtCEVupWMVHVLDx2nMM fhEt6zXxpCmu/5+DXzcT7UtFomifM46xD7TOsWHsrz7VZOJtNOrDH/K1VsnPwJqYyqU5 4RJrigFqHdngZNzyLOuVWD1v0Ox4cOhWEXmtKZJBGjAL2RgVaBjEwrqzJC241jDGjTLG ISZEi99rLcMsDgydsANEcNY1UJysiVZgVjljmdjw1vxzDrW4caNMvtcNfI3aOxiiyR3g vdYZ15CM9+7xNNaOx0JRKFM+piJFuZb9V0oi0kdfYFwyBieEaXqrr2Yp/DRYroXmA+ei 5tSHvlmQJcSxhjCsaeMTpSZOtAeWzXIOzWZtnIBcoMSSLXy4TGP2nN64EJSMv51Fs+Cy LapFC+GwBt7ROQr6YPYNryxCcZFb1DVHQa0laQCUCy9RUKBRPG95nDPnrlE+dwUxYbHR ovkrK1M4h/l+GvPYKJ3HshYL57KkELMKQTfdPF2GUbEKQFq7jQpowTiMMvgjt3Go/QzM 58Um0hugd31nr9f0SAhQu8OXJYw+KKhJD2yQZwlUEXEHyvtuV2qhAmeBvIiRGtXMExlp VS5kkCALLTZPP5xHrYclIM4PaH1mWMWRMwECJZc1IxB4asdk1tdJrDLsjfJq1JIlcFPM j8F8gvb5eSBbLBG+NjlAm2M6s1Pm5qTlmEdnps88OynMZplrpFHSiMPYrjxHo4ZDhakQ D/4IoZzsg0FZKRS0UsO5h740HZWzCqF/CoIlPy/GEMWXn3WEYwMc3PAAKc5M/KgGKZOu fWl5jdM2vR6n0VKyU/7rOkrT6A6zmbbbcnA/w2EvTO/pJI1V63mEWU0Zu6kU2QQZquTD oASebzO0uIQiSksshzbokrA8UsKyuhSQ+RPpPkDexG4oD4tSFcRiN2SBdOwGXisky9vk L5GV9XkoEZnzPXRKzg6wAgG66pAdcnSlYVcQp0U9gss+rypVryvmFK7dhUpkbPcgNxC1 3RO8mcTt7kRVwbuABKrJ33LCNhTDi3u8Xhov72+5UC7Kbiybr53htSJ6pVkuk4HXzHSF og+W26vMeIX2HyTFu8uuF+bd5dbL9AXtbSbak2dTuw+7W6ML8VX6um2XFLLKZXrKMFUi 0ZfU9qVyvRtjHibeu7HnQVL+2qo2E/bdo6wk85sbxUNF/yoKUfN0YM1A+UHAQpDS84C7 4uJjgXvuKp4Oiie+6JCwvrk1Z4X1Tbr8c9ylgHPJmYeFKRnq+hoodNLmVSQVO0EIZyNQ cWXl/aHaRLgnbVdac7SysGvtCcs4DRk8WR1irId0lskGSFd8FEhCXPRl5uX2QaO62dFd NF3xbsHnNJgVmx3ZcOVmRzb01uWKy/rgpeiBqXl3sN9GN8p2mdlRvhLb0rynWR2PMIHg SMZszQyPyLBOmB5ljyfTCTxrZE8+BOEcwbJHH4Nr6wnuQ356S/W1pPHY2bs3wu7rknUz mzL9cW87i0Yu4+ltMxrkmCzT55zv06B//Y2fYsVF3jPwR6Xnwr3rGXRVPSIg3lXriexq 9vizCIKPiU8bwzZczOv2e8KATZgLji9fnx6/umL9bgnExcmPrzlIrxDk7Jy/7mszRa9f X129lZ7j/T33a+Fh3h/kXl9eXZyc/cih3pyOjy+PDt9yqGEO6s3h1evxm5Oz8wvWHxW8 Pfwrf7vXdr89fPmS7Xnud5fvfmB7Hfe7l3zMe92CdyecTs6Ojtlezw1wdHF+ecn2+gXN Hh2e8rJ77rcnl+PT81+O+YgGboCri8Ozy7fnl7yK/HydHl7yfo809KXnFHxkfHU+/vn4 5HT89qerS1izArBXF+dvdMBBDtBY+6H7tVz7fG8ca8/Xr1G89nwFGyVr33G/xbXvut/h 2vfc73Dt+wXv1NrvuQHE2g8KmqW1H7rfZms/cgNkaz/Izxeu/cDTedqbwx9PjoB9cS72 A69XK2S/8tpeu9MbeiOowMHmKC5FD00c+0PhLo+ZCXbAVOMmiHdEEJyd5HYezFL5U/jU UDX06nOzuGgc3tyaZVVRfFVcdhFZbWZl+avPgvH+vkNOJgp0J43GyIyX79NEPhXl9FfF FUBKM7sKUYH5Kuv7bZoutc7ukHOyc8roVXHRYFFYlF5lRelcnnX8Nr2bjwMu8iyz8qKo 9oqXry6MiLwAxZkWFUC5+KHAHhRUJittChy9NjjIZW5OfYr+YCTZefXy+FXtlXDoUFNF h1U1S0aaLlHi9Pz8p3dvVQkyV1Il6KdZ4uXh1aGOBH7qa+sIP4W/h4CXgU2aAuGFl6Io o5wWtegfl/cJGIsqj0oV0Oh3iPryw+n5jybF7Eyv59FNjoyg/BhfsQ2xIfkGhlGGDhJi HT5IOIf3W7cCQqjiOkYM9/s9IccKjGjvIUag4ZMZQjkJKNiYFYaUEiqgRqOOGQ4pCRlE IDvIxeHEWgiz9vWIffwpdNVZdVanMIt01yqEtX07nB5lRxGh0CgSWj7FV+HotPwqbM0o isehJolc2SuMCMwyZ/5qnuZqmqS3cfSxBoZi4NRGdzedPmaE6nQGTa8jLqY0b168A6rr 6cjDZIwPdaN0YYVIMGcnV2NvfHjxY+3w7G/jq7+9Pc6y3kE4QzkECgomo4JpubtlC3zY 5GDGIY6PrmoE6Om5u911sX/+k9lvYG71hIJZG3SonEAmJK0Jikk3TwIjTLYsc3a+mWcr 0NAdPyCXEzNBrCdmgrNPldJnr72OmGVxk5h5DZobSx+jQfY71TKsaOkU/5QkK0Z7Sstd 1ovSVCvO6lS2ldJqvyDhymbYswjSj1H8vhyBFNB6HFKgjnTMnUp7QlaDhUn9/b6GSZ0e qibgY6RwSYZKes501sE33cPJJFimzBdSwq6RcOwJ7qXhIkzHXu0ZUHhTco96xhNcUIoT 1V3Zr9zs5IliJ8+eMfuNxU6uXl+c/1JTrJXtgMXzLIyTVGU6ZLWnL+vgK8EFanCoEu5k XF54JiqXg8C78xLupnVHxUKEHM657sA7crLeEcrQr57O2TQKqBPBpzDBDti1QUdE2FeI Jgs3EGARHqAc5E40pqJXG3F+wZVKMlg+3XEYfAhqudascLdPILqsGernEcZTqbqnLx21 acujalBLZE8O9D0fN5823mUQ35nNnTN/Dtfd9+gj4bOsImhYS7NZzwUkz4fj3YyfCPQr ZScSZj03kZBbV7crdhZ94HyAtfcgEGV3VImZqAos58q9/a4WbIjyRI/a2q5kUXxHUryM Stt2k3zLCJj8KHm8Nqttk2ReW9LHJkNsGbWIkNP7TadB2ZEXoHdHDDcwUmCjfJeho9TS s6cnpUQlYvvKHEIUN9rrFC+KZy7KBisimcZjrcm6+jZblS3Xgkz//y1Fl5ai+4cshThV PNZKrKnuy3Ld0R8fovfnLAi0JBcBsxA0vFwyAivZpj0f4eI2AIfpadGMrE8tV5LoUJuK tYnl1k/9nz+zwgUct93fRZidLnja0wcdW7NUD7o7N+lsY34OuVmAk+dkHvgxOMjP5+w6 YB9juFgMZ1qGI9Vp6A74eWJvONmBF7h6OI2UV931KmXPk9t4dfPcTJBrryJIjsXpX6Vf X2HR9Rlk9RnPUxy6KrnRq1LiwiqZLL8IsSplHXRwP5WrgDzvMNw1fIzWigkQB6OcGTZK kuWQyrD4FPC3aAWhEDi2+NOp8iNOI+FuvZMJ2vncu7xPHZ2+woTvXhSNeczPXdMaZbTd tqXapR8nmn6n26bjV7erOyAb2T6YlcdLBRFzcHkMH/aMQnzl8njJgpntRZ1VqMRKdJHL +UtZL55gFhETQ+zMGC/IMMI6UIgEk+UVyCyUwhhCq8LOZiLU/A4NhWa4lB+1ENQ0USEz hCquaM1UllRq9d9K0WETTQ8Ddjd6A115C+ZPv/ahdj2DuWGlYq1AlsVjGS1r3h+RJAQr V0GGolW6XKnn2D91KlKvKINIb+ihO05v2Gt6QzvmoSBOhXzKFEySrUy6rYJWTw0/bYpo kAs3qzkVS4x0qDsWkVITJGYqHY1ntWsPZFB6pinJg8Ragtl5W66A2l9VdnhptIybI+JA NJPkjj7QmX5GHPXtLpjIjVlwShDaSIBudBLPwuL5LoRHkEuOCcRDVBmykH3LcoD8sSOP uAGW+te/hr/t3sn04L0RBPBp9Ns9R0Ipq3OcViXu2Oo+xWAbRiodiBSwgoA4ak4XGKMk oISS2fqjSnqMD2tSvOx7Pczu1+94enI/h4AJcQ+4fKLiRYhli4Tbf0E2kjt3TsPiPLtC FlT5FQVR3HW+pCJMI9zYrD/ujIu53jU27N3aau2UxwaqQffvOqb8ijtdx0hmKzAy52tw 18lP010url0uL67Fbl0JxSq2uOtudVdruVEhP1lRajJjegwWVDaeTlGGtILWO67mP1sJ ruR+lQkjxrTijkOjrt05suK0Npj74royjWhjwxk1ebd24CLMlmcuYfjLj1pwyppBTN8C hYKWCa7f28MYNn1+pu30/nies1Hi9z8l5zuRO6nfOxWY3UYj6Pw5aetdY/gP7/pvwbv+ w650drXXIXfUPX707VGi68+WVYN0R5QoUBCCDEV9MHR4VHk9JwSKVguFwZZ55HHwBM2z tMphYEvdwatkcFvTXS2vGj92YqApl4xe5yxIRnzakl3XhGElsnt1qXHcyjqv9XTLOK1Z Q1AIohcuPw3Xc/PwOb/yMpxcbunfh3DE+4NXWrb+BUutBlB1rWFgueOeNqnwPr8c8unD 18LuqGMxlPeuPHjt9T1Q6u4NBrZSV3gFsyieBvH3xkLw9ZmA2tmDi3HY5eCHgActdMbs VHvaJV3O77gs92HjS2tybd6GsVG1vpKz85f3tLCesn7KOddQ3hCeMxzJ1pcOr3t7mCJo b9TTbKDXGnZUvaAyZIGSc6bD/qDxkPrcglhjA/21Oa/5SQwXnM4wt43oXKbMGrSHaLc3 6Pab3UwP4LILQLJzZuhQPJAi19C8P5+aETjNPTEz98sCwipWmd6Gi5ssBqmLSzbsxWxs pr+ybBhtFTsFe5PRTMGCXKnaDxxtC/WMGskRFZepraFgNhzSX2XRGsqoj0rkgpqbFh2N ohVrQJ/MXUuTWAw15HNEJ1v+f86m+SPBtJNXRuLtV5Elp26OJZV/csPnOxeFfuDfCvdF T79lqVP09EFnCE5qjQHn8T3PfZiUwu1GmAFwuIXNg8UN52oZmcHTOqj/vbzMb1vmADrd rfhYk2UwgUiUwSd/ks7v+WYtBbUsKPTuji3FG5ilKf8wdK36NpX7cTAP7qyOgsWKddaR CXSVQVrRMDKqOOPYK3r79KVpdAZWdVyGnj6s60KJq6fh/e4F7zJkNDfNvDSQOtsXuTUb OUOvgqFktln2YPJ3xMZQMmFl/emqhKnbs1NJIqa9w8pY7Lg8tRuz1OLZVYK9v5oP5RZh vPlcwuaUXt+fzwsCuNRFQHe6Hxep2JEfqqjavop0LBbl4204uYVgyDJmUJOLaazliVt1 CAiPQZp5m+/9+0zOpav3F0WhZApuuzKSFiMrr6bKBZpepcJOqpaQWzunltMuFrINGp30 W2aZz1gRBVsEbOseRGvZSa4kc3ihlSI2WsBGpLmiLx7LjrQcHXmiG9br3MCg+YKef8va YMVfWgd7BL6R195Ye6Z9UsYcD5Szb9QeNL32l1taSV6YC4FQhq5C81FuNLKZAMXbJlIH WwQgdBKASkQnbbEd/a9MetpY7PWkBGXKpBq79l9PT3RcTP33waJMLeSQLXAV+2RN2ilb xaKjfW7hjNATuR3iocukZfLa+QXzUEwjROJb/wOIufB+swXS+1l+hHcth94flwm20a28 CFomMzv9roZ76JbUGPWUe1L1RWKsxBSLWkarG7ILWbc8wI7WKj2sOounLzc1O2cRYTdg NloOB1OQsvn0PmgmTW0CygpEFSVTkdP6ihJVhy0Pm1zGEObamAtvNJQ+ovgS/H4uzg5P leoNzF2iJQRcr6loyCsRNgr4lIxGtGza0TSVzlvZYIBS3jAZcRllOICYofAVB6DkY5hy yQaZJTS1oYX9EpJHR3Gyxsg+A6tgZ58B28l9B/u9YTVTe60Ozdq+095vtw2HTocPWLiY WlYe5C2s5zJbThqN36Qg5fYXW1VxFiNPsGeoHP0V/x0vo4S1mPfbwb+H/f6WMtwHhkmB gcvsZXmJSmayxmUIhpKla1qUSuhDLphS6RcyDGlHA+/GxDtrhkePLFjfbm3pd0GZHmOr pnkh8ZOgofAQ5z9nSWIIGEaIMwBqfAw54SlErtQK7/WbQ9agDzkw/apZzk2TMm6Atj20 1eswlo8BOjPxl5rK4s/B6Mf2bmhtAXKhiyHh1UPcHSooKysYg2udWGcM/lD0zpt/D3oj MNEaqKSUFsfmm0mQ0rnLlGM28iJX1CPrU27XJpzTqxxu2PdJiulgBsdhp/tv0FlvOEC5 mH92HOZvpp9ugmcy+N5gntXOZ9udfgP2Wskc/RFM0h/RLN3t8lvK7ZUn0RdwfW/UpeUa dTdZrtZ/lutPX67NxMfUT9Z4exPEeqGR4Kzcl31vv13Nz1sUtxwzB/vdPT3pNUY3h4+R vkU7btG1TVpkW8S0ZbMiE7HqB74NPDUyCWXtJWoWA0IXYUrPX9Ko3huSQ96wr1HmA2ZF mNEJT6YNZ6VV0vWCRMli5NUL7bokOuxYAqGuTXHOG1GyT+MWOKejsdaR6gGCPDu/Gh+e jU9eHp9d6VfQUhve1heuoBrTW96JDATpDgRSMDFZkc9m4uZBM+duAHqyVcKh5X7/2Bju jEgALQpl33VA+r4oU/PJwWqVY4H1h4eCCcEB4nT8PzRzEWXPOwEA --============_-1201859963==_D============-- --============_-1201859963==_============-- From xmath@nubz.org Sat Jan 5 22:58:35 2002 From: xmath@nubz.org (xmath) Date: Sat, 5 Jan 2002 23:58:35 +0100 Subject: [Coldstuff] More suggestions In-Reply-To: <20020104093554.C26889@mojo.cold.org> References: <20020104093554.C26889@mojo.cold.org> Message-ID: > > 8. [ColdCore] There should be some way for programmers to get a list > > of tasks that are under their controls. So, a programmer-level @tasks > > and @kill > >Sounds like a great idea, feel free to writeup something :) > >-Brandon Here ya go: http://www.nubz.org/tasks.cold.txt Ofcourse I haven't been able to test it (because I lack privs to do so) but I did verify they compile, and I thoroughly checked the $scheduler methods (since that's where priv-checking is done). - xmath From bruce@cubik.org Sun Jan 6 09:49:17 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Sun, 06 Jan 2002 02:49:17 -0700 Subject: [Coldstuff] Waifs draft 2 (was: Re: First version of waif-patch) References: Message-ID: <3C381D9D.3080000@cubik.org> Hi, In looking at this patch with Brad and the overall aims of the effort, we'd come to the conclusion that there simply wasn't that much difference in the end between cWaif and cObject, except that cWaif didn't have a method table. (There are others, but they're relatively minor and are in how it gets used, not in the underlying differences between the datastructures.) So, we thought that it'd be easier to just make it possibly for the methods table to be NULL, only costing 4 bytes (by also moving idents and strings into a single structure for the method data). Brad's mostly done implementing this into the current dev-tree. This has the advantage of also reducing the size of any object without any methods fairly significantly. (About 1316 bytes or so, per object.) With that, that still leaves changes to be made (as you've done in your previous patch) to the compilation and decompilation of textdumps as well as supporting the other features of waifs. But being able to do it in such a manner that a new struct or datatype in the driver isn't required should significantly reduce the number of bugs (present and future, since introducing a lot of typecasts also reduces the ability for the compiler to detect some errors) as well as the complexity of the patch that will be needed. I was going to try to get a dev release of the dev tree out sometime this coming week, but with this, if Brad finishes up everything tonight or early enough tomorrow, I'll try and put one out tomorrow along side the 1.1.10 release that I'd already planned to do. I'm sorry that this comes after your two efforts, but it looked like the cleanest way and I guess that Brad was bored and in the mood to do the implementation work on that part of it. If this works for you as an implementation basis, let's talk about some of the rest of the changes. I think that this may make some of them easier with an object and waif using the same data storage. Regards, - Bruce From xmath@nubz.org Sun Jan 6 10:35:44 2002 From: xmath@nubz.org (xmath) Date: Sun, 6 Jan 2002 11:35:44 +0100 Subject: [Coldstuff] Waifs draft 2 (was: Re: First version of waif-patch) In-Reply-To: <3C381D9D.3080000@cubik.org> References: <3C381D9D.3080000@cubik.org> Message-ID: >So, we thought that it'd be easier to just make it possibly for the >methods table to be NULL, only costing 4 bytes (by also moving >idents and strings into a single structure for the method data). Sounds very nice unless you think that's too ugly, you could union it (since it's not used for waifs) with something that's waif-only, like the cclass or the usage count. >Brad's mostly done implementing this into the current dev-tree. >This has the advantage of also reducing the size of any object >without any methods fairly significantly. (About 1316 bytes or so, >per object.) Nice, nice >should significantly reduce the number of bugs Actually, I found that changing the name of the struct was fairly useful: it caused a lot of compile errors that forced me to check every single occurrence for the impact of waifs. >as well as the complexity of the patch that will be needed. That is true. >I'm sorry that this comes after your two efforts, but it looked like >the cleanest way and I guess that Brad was bored and in the mood to >do the implementation work on that part of it. Don't worry, I sometimes throw away many versions of my own work until I'm satisfied with it. I'm just trying to get waifs done in a hurry because I need 'em for trying out other ideas. :) >If this works for you as an implementation basis, let's talk about >some of the rest of the changes. I think that this may make some of >them easier with an object and waif using the same data storage. Yes, definitely. Until the dev release is available, I'll work on other things. - xmath From xmath@nubz.org Mon Jan 7 00:48:36 2002 From: xmath@nubz.org (xmath) Date: Mon, 7 Jan 2002 01:48:36 +0100 Subject: [Coldstuff] Method meta-data Message-ID: Here's an (untested) implementation of method meta-data, as well as two instances thereof: custom method flags, and method help http://www.nubz.org/method_meta.cold.txt I think it would be a nice addition to cold-core (once tested) - xmath From xmath@nubz.org Mon Jan 7 14:13:08 2002 From: xmath@nubz.org (xmath) Date: Mon, 7 Jan 2002 15:13:08 +0100 Subject: [Coldstuff] Method meta-data In-Reply-To: <3C38FCD4.70505@cubik.org> References: <3C38FCD4.70505@cubik.org> Message-ID: >You don't have an accessor to return all of the meta data for a single method I've now made all accessors public, and only do the sanity-checks if the caller() wasn't root (otherwise I'd have to make separate +access=root and +access=pub versions: one without and one with checks) (note I check against #0 instead of $root, because that's what Genesis does too) and I think I've addressed all the other issues too. new version again at: http://www.nubz.org/method_meta.cold.txt - xmath From bruce@cubik.org Mon Jan 7 14:39:39 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Mon, 07 Jan 2002 07:39:39 -0700 Subject: [Coldstuff] Method meta-data References: <3C38FCD4.70505@cubik.org> Message-ID: <3C39B32B.1080505@cubik.org> xmath wrote: >> You don't have an accessor to return all of the meta data for a single >> method > > I've now made all accessors public, and only do the sanity-checks if the > caller() wasn't root (otherwise I'd have to make separate +access=root > and +access=pub versions: one without and one with checks) > > (note I check against #0 instead of $root, because that's what Genesis > does too) Except #0 is $sys, not $root. Please just use the objnames and not objnums. Nothing in ColdCore should be directly referring to an object number. > and I think I've addressed all the other issues too. > > new version again at: > http://www.nubz.org/method_meta.cold.txt A couple of things still: Why is the method help returning, not throwing ~keynf? Errors should always be thrown. Spell out field and don't just use fld in the method names. I'd still rather see the underlying variable called method_metadata rather than just method_meta. There are other meanings for meta that could confuse the issue and the longer form is much less ambiguous. $root.defines_method() should probably just be what it claims: return method in (.methods()); In $root.set_method_flags(), could you rename current and drvr to be current_flags and driver_fags? That would increase the readability there as well. There are some other uses of this as well by the way that might be good to supply default implementations for: * Copyright info * Last-modified data/time/by whom * 'Currently being edited' (with some sort of timestamp so it can be expired.) - Bruce From matthijs@cds.nl Mon Jan 7 15:17:57 2002 From: matthijs@cds.nl (Matthijs van Duin) Date: Mon, 7 Jan 2002 16:17:57 +0100 Subject: [Coldstuff] Method meta-data In-Reply-To: <3C39B32B.1080505@cubik.org> References: <3C38FCD4.70505@cubik.org> <3C39B32B.1080505@cubik.org> Message-ID: updated version again at the same page >Except #0 is $sys, not $root. WHOOPS, mind blurp >Why is the method help returning, not throwing ~keynf? Errors >should always be thrown. 1. no error has occurred, I always allow clear 2. the reason is in the comment right above it When you do method_help on one that has no help, it returns a false value (~keynf, because of the critical expression). When you call set_method_help it'll return the value a subsequent call to method_help would return, which is ~keynf. >I'd still rather see the underlying variable called method_metadata >rather than just method_meta. There are other meanings for meta >that could confuse the issue and the longer form is much less >ambiguous. To be honest, I think it's pointlessly verbose. If you think it's really a major problem I'll can change it, but I don't think it makes the whole thing more clear. I think it causes expressions that use the var to become annoyingly long. There will always be things that remain ambiguous.. even if it would be called method_meta_data. Like what it is used for? what kind of data does it contain? etc.. Most variables are meaningless if you don't have access to the code that uses them. When you look at the methods that use method_meta, its meaning and purpose becomes fully clear. In short, I like method_meta more than method_meta_data, but if that would prevent the code to be added to ColdCore I'll change it ofcourse. >There are some other uses of this as well by the way that might be >good to supply default implementations for of later concern, this is just to provide the framework and two examples. note that date/user modified is already added as comment, and that's a better idea anyway, since the method meta-data is user-editable. copyright however could certainly be added later easily - xmath Matthijs van Duin (NOTE: PGP key has changed!) - PGP Key: 0x2D6F0BA7 - - FP: 205D F7BA FFAD 9070 AB9E C5A8 BDB0 CA1B 2D6F 0BA7 - From xmath@nubz.org Mon Jan 7 23:24:42 2002 From: xmath@nubz.org (xmath) Date: Tue, 8 Jan 2002 00:24:42 +0100 Subject: [Coldstuff] ColdRPC draft Message-ID: Brandon, you asked for docs on the rpc protocol I'm designing.. here is the first draft: http://www.nubz.org/coldrpc.txt notes: 1. it's a first draft, the specs are still a bit messy (the protocol isn't) 2. a large part of ColdRPC rests in standard defined methods (on $rpc and elsewhere) which will handle things like authentication, negotiation of features, etc etc. This isn't yet documented in any way, the draft contains just the "transport layer" basically. 3. although it speaks of "client" and "server", it's equally well suitable for server-to-server, where the "client" is just the server which connects to the other server. The only relevant difference is the site-numbering of objects. - xmath PS I'm CCing this to the coldstuff list because other people may be interested too, feedback welcome :) From daedalean@skyweb.net Tue Jan 8 03:56:13 2002 From: daedalean@skyweb.net (Jonathan Robertson) Date: Mon, 7 Jan 2002 19:56:13 -0800 (PST) Subject: [Coldstuff] Compile from Win32 to Linux Message-ID: <20020108035613.61800.qmail@web14502.mail.yahoo.com> Has anyone ever tried to Compile a textdump file that was decompiled from a win32 database? Jonathan __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From bruce@cubik.org Tue Jan 8 04:52:44 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Mon, 07 Jan 2002 21:52:44 -0700 Subject: [Coldstuff] Compile from Win32 to Linux References: <20020108035613.61800.qmail@web14502.mail.yahoo.com> Message-ID: <3C3A7B1C.7050306@cubik.org> Jonathan Robertson wrote: > Has anyone ever tried to Compile a textdump file that > was decompiled from a win32 database? If I was to guess, I'd suspect that you're asking because you're having a problem with it? The windows coldcc may decompile with Windows line termination, which the Linux coldcc may not recognize. If that's the case, you can try using dos2unix on the file, or doing a substitution in vi to remove the extra junk from the lines. (:%s/^V^M// where ^V^M is a control-V control-M). - Bruce From bruce@cubik.org Tue Jan 8 06:28:18 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Mon, 07 Jan 2002 23:28:18 -0700 Subject: [Coldstuff] ColdRPC draft References: Message-ID: <3C3A9182.3050002@cubik.org> xmath wrote: > you asked for docs on the rpc protocol I'm designing.. > here is the first draft: > > http://www.nubz.org/coldrpc.txt Some comments ... I think that overall, you did a good job with this. However, some thoughts, pointers, questions, etc for you. :) BEEP is an IETF standard that does much of the same sort of thing. Information about it can be found in: http://agora.cubik.org/wiki/view/Main/BeepProtocol The author of the BEEP spec also wrote RFC 3117, On the Design of Application Protocol, which contains a lot of solid wisdom earned over the years: ftp://ftp.rfc-editor.org/in-notes/rfc3117.txt Also, from reading comments in the scrollback on the Cold Dark (but not as closely as I'd have liked due to lack of time), I saw that you were aware of MCP, but didn't think it was well suited, despite (to me) having somewhat similar goals. Could you expand on why MCP isn't well suited? If what you're doing is looking to create a rich client/server interface, there's been some really good work done in that area over the last couple of years. There's still active development as well. I've spoken with Andrew Wilson (the tkMOO author) about reviving the old mcp-dev list to cover topics related to some of the packages currently in use and under development. A fair number of clients exist and some rich packages already do exist, including two GUI toolkits. All of the information that I have on hand is already in Agora: http://agora.cubik.org/wiki/view/Main/MudClientProtocol If you haven't looked at TWin, I'd recommend that you do, it really is quite cool: http://agora.cubik.org/wiki/view/Main/TWinClient One final comment on that note is that by using a package-based system defined by messages that are passed back and forth, you could not just harness the existing efforts, but end up with something that is portable between mud servers and more broadly useful, rather than only working with ColdCore. (Actually, there is one MCP-supporting client that I know about that isn't on those web pages. It hasn't been released yet, but should be open source and is written in ObjC for Cocoa. It really is quite nice.) (If there are other MUD client authors on this list, I'd encourage you to support MCP/2.1! :) ) (There's also a bunch of other mud networking type protocols or other mud client/server things laying about on Agora on: http://agora.cubik.org/wiki/view/Main/NetworkingProtocols ) > PS I'm CCing this to the coldstuff list because other people may be > interested too, feedback welcome :) Definitely. This is something that interests me a lot and is something that I consult with others on during my spare time. :) Btw, in the webserver, there was support at one point for invoking arbitrary methods via the web interface. This relied upon $dmi_data to specify what methods could be called as well as a bunch of metadata about the args that a method takes, how to convert them from strings to the right datatypes and so on. I'm not sure how much of that has survived in the last 3-4 years of it is still in use at all. That was intended to let some RPC-like stuff happen by way of piggy-packing on HTTP as a transport. Anyway, that's just my set of thoughts at the moment. I'd love to continue to discuss this. Regards, - Bruce From xmath@nubz.org Tue Jan 8 12:19:28 2002 From: xmath@nubz.org (xmath) Date: Tue, 8 Jan 2002 13:19:28 +0100 Subject: [Coldstuff] ColdRPC draft In-Reply-To: <3C3A9182.3050002@cubik.org> References: <3C3A9182.3050002@cubik.org> Message-ID: OK, based on what I've read, I'm still sticking to my current ColdRPC design. I'll explain later in more detail the reasons why.. but the basics are: 1. it should be simple and efficient 2. it should be nicely symmetrical, asynchronous, and have support for message fragmentation 3. it should allow for ColdC methods to be called remotely, and therefore carry any value representable in Cold Using any text-based protocol already basically rules this out: they have too much overhead without having any benefits in this situation. The only advantages of text-based protocols are: 1. easy to use by humans: irrelevant after the debugging phase, ColdRPC is used between programs, not between people. for direct use by humans, I'd rather make a convenient little tool, "ColdRPC-Console" or so. 2. extendible: ColdRPC only needs to be extended when new value types are defined, something that very rarely occurs. Even when it does, ColdRPC still has enough room to add it without incompatibility. No existing protocol (as far as I know) has the features I'm looking for, nor does extending some existing protocol have benefits over making a new one. In short, ColdRPC is simple, efficient, specialized at Cold and it's good at what it's specialized at. If people want I can work on MCP some time in the future, I agree it would be nice to be able to support MCP-clients, but personally I'd prefer ColdRPC over MCP anytime: for communicating with a Cold server that is. MCP is nice, but doesn't do what ColdRPC can do (if you're logged in as programmer, ColdRPC can directly call any method with your privs, even for example if you can't use the eval command because of a .read() in progress), because MCP is meant to be universally useful, and therefore doesn't harness the features of specific systems such as Cold. And indeed, if Brandon doesn't like method meta-data, then I can instead make a $remote object or so, which will allow you to mark an object as remotely callable, and specify exactly which methods may be called by an unauthenticated RPC session. (or use $dmi_data if that's in any way still relevant.. haven't looked at it) - xmath From xmath@nubz.org Tue Jan 8 14:04:08 2002 From: xmath@nubz.org (xmath) Date: Tue, 8 Jan 2002 15:04:08 +0100 Subject: [Coldstuff] ColdRPC draft Message-ID: >I don't know anyone who's tried using MCP as a server-to-server >connection. It *could* do the job I think, but so far most people >have been interested in client-to-server uses only. MCP is meant as an extension of the normal line-based client->server session, which doesn't exist between servers. I suppose it could be done but it wouldn't be the best choice. >If I had to pick server-to-server RPC implementation to go with I'd >choose SOAP or XML-RPC. ... So you can wire up calendars, games, and >whatever other services 3rd parties are building using >XML-over-the-web techniques. if I had to pick something XMLish, I think BEEP would be better: SOAP and XML-RPC are both layered on HTTP, which just isn't great for this purpose. It isn't symmetrical and there's no real concept of a "session" which I do need sometimes. It's just too one-shot. Don't get me wrong, if someone has XML parsing nicely working in Cold, I'd be happy to write XML-RPC support or so, to be able to access other systems that use it and vice versa. But it wouldn't be my protocol of choice for a Cold client-server or server-server connection. >The MCP data is sent over the same connection as ordinary chat, and >is meant to be in a format that can be interleaved with other >traffic. My limited understanding of SOAPs is that they're >basically one-shot HTTP requests, existing in their own connection >and with no other transmissions getting in the way. ColdRPC and BEEP are even different: they're simply a dedicated (unlike MCP which is interleaved with other data) symmetrical (unlike SOAP and XML-RPC) connection, which allows messages in either direction. Note that ColdRPC has big advantages, in that it's very easy to use: if you want to experiment with it, create some object $my_object that derived from $remote. Add my_method and mark it as remote. Set the +remote flag of $my_object and then you can call from anywhere (via ColdRPC): $my_object.my_method() With MCP you still have to worry about data conversion, registering your package with the central handling of those things, etc. MCP etc could possibly be made to fit the purpose of doing RPCs, but ColdRPC fits it nicely and exactly, being custom-tailored, while still allowing a little room for growth. In short, they're just different protocols for different purposes. And XML-RPC, SOAP, MCP, ColdRPC and whatever don't necessarily exclude each other. I have the time to implement multiple of 'em :-) (Note also I'm rather fond of efficiency: ColdRPC has a 4-byte message header, and packs data in a way that's even more compact than what Genesis does, except for objects because ColdRPC pack the name while Genesis packs just the number) - xmath PS damn, again I sent the reply to the sender, rather than to the list From xmath@nubz.org Tue Jan 8 23:51:55 2002 From: xmath@nubz.org (xmath) Date: Wed, 9 Jan 2002 00:51:55 +0100 Subject: [Coldstuff] ColdRPC Layer 2 Message-ID: I've gone a bit ahead and written a draft on ColdRPC-L2, the layer on top of ColdRPC (L1) which handles "feature" management etc. http://www.nubz.org/ColdRPC-L2.txt it's not even a decently finished draft, but it should already give a proper "feel" of what I had in mind. Note that in many cases where it seems I'm using objects or so (like the "consoles" of the console-feature) they're more likely actually frobs, although sometimes they may be actual objects (or maybe waifs when they're implemented). This is up to the implementation: whichever is most convenient will be used. Note also that the client must be able to create "objects", as console handlers etc. The most convenient for most applications would probably to allocate ids, perhaps multiple ranges for different kinds of objects. ColdRPC allows for objects to be referred to by number, so that would work. Feedback welcome as usual - xmath From bruce@cubik.org Thu Jan 10 05:56:09 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Wed, 09 Jan 2002 22:56:09 -0700 Subject: [Coldstuff] Release of Genesis 1.1.10 Message-ID: <3C3D2CF9.7000508@cubik.org> Hello all! I just released Genesis 1.1.10 to the FTP site. The changes are: 1.1.10 [9-Jan-2002] * fix object size for objects without an objnum (Brad) * fix parent list leak in binarydb decompilation (Brad) * fix method_bytecode() bug with 'catch any' (Allen Noe) * fix gmt offset calculation on some platforms (Brandon) * port to Mac OS X (Bruce) * remove regsub references (not implemented/used) (Bruce) * add calling_method() (Psyclone) * fixed README (Bruce) If you have changes that you were hoping to see go into this that aren't in here, please re-send them to coldstuff and they'll have a shot at 1.1.11. I'd like to do a 1.1.11 soon for the improved compilation support under MS VisualC++ on Windows. Also, feel free to report any problems that you might have with 1.1.10 to coldstuff so that we can address those in 1.1.11. That should also include documentation problems or whatever else, as long as it is related to Genesis and ColdC (but not ColdCore or other DBs). Cheers, - Bruce From bruce@cubik.org Thu Jan 10 21:39:09 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Thu, 10 Jan 2002 14:39:09 -0700 Subject: [Coldstuff] Random plans and needs Message-ID: <3C3E09FD.5050408@cubik.org> In the short term future, I've got a few things in mind with respect to a release schedule for Genesis and some things that I could use some help with. First up is a release of 1.2.0 which contains work that Brad and I have done over the last 3 years. It is a rewrite of many core components of Genesis and performs significantly better in some areas as well as having a smaller on-disk footprint for the compiled database. A full changelog will be posted at the time of release. I'm currently expecting to do that sometime next week. (I have some stuff to do on it before a release and it takes time that is a little bit tight at the moment.) Next up will be Genesis 1.1.11 with any patches that I missed for 1.1.10 that are suitable for inclusion. It will also include support for MSVC++ compilation. Finally, the state of the documentation must improve. Anyone who can file substantial bugs with detailed information (so not "the docs suck") about particular flaws, errors and shortcomings in the documentation would be appreciated. I'm personally mainly interested in that for ColdC rather than ColdCore (since I don't use ColdCore). I'll be working through some of the bugs and fixing them, but would also appreciate any help on that front that people might want to provide. Feel free to post with any thoughts on this. - Bruce From vanish1024@onebox.com Fri Jan 11 07:54:47 2002 From: vanish1024@onebox.com (Vanish 1024) Date: Thu, 10 Jan 2002 23:54:47 -0800 Subject: [Coldstuff] Random plans and needs Message-ID: <20020111075447.MHHD29423.mta06.onebox.com@onebox.com> If you're not using ColdCore, what are you using? I looked at ColdHELL but it was heavily changed from what I'm use to under coldcore. Also, still sort of sprucing up the files that you sent to me. I'll have a copy available for review soon. :) -- Vanish 1024 vanish1024@onebox.com - email (818) 630-2340 x5993 - voicemail/fax ---- Bruce Mitchener wrote: > In the short term future, I've got a few things in mind with respect > to > a release schedule for Genesis and some things that I could use some > > help with. > > First up is a release of 1.2.0 which contains work that Brad and I > have > done over the last 3 years. It is a rewrite of many core components > of > Genesis and performs significantly better in some areas as well as > > having a smaller on-disk footprint for the compiled database. A full > > changelog will be posted at the time of release. I'm currently > expecting to do that sometime next week. (I have some stuff to do on > it > before a release and it takes time that is a little bit tight at the > > moment.) > > Next up will be Genesis 1.1.11 with any patches that I missed for 1.1.10 > > that are suitable for inclusion. It will also include support for > > MSVC++ compilation. > > Finally, the state of the documentation must improve. Anyone who can > > file substantial bugs with detailed information (so not "the docs suck") > > about particular flaws, errors and shortcomings in the documentation > > would be appreciated. I'm personally mainly interested in that for > > ColdC rather than ColdCore (since I don't use ColdCore). I'll be > working through some of the bugs and fixing them, but would also > appreciate any help on that front that people might want to provide. > > Feel free to post with any thoughts on this. > > - Bruce > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com From bruce@cubik.org Fri Jan 11 14:05:58 2002 From: bruce@cubik.org (Bruce Mitchener) Date: Fri, 11 Jan 2002 07:05:58 -0700 Subject: [Coldstuff] Random plans and needs References: <20020111075447.MHHD29423.mta06.onebox.com@onebox.com> Message-ID: <3C3EF146.2070809@cubik.org> Vanish 1024 wrote: > If you're not using ColdCore, what are you using? I looked at > ColdHELL but it was heavily changed from what I'm use to under > coldcore. I work on The Eternal City (http://www.skotos.net/games/eternal-city/ so I tend to just do development on there. (Our own core, started from a 1995 or early 1996 ColdCore, but really not much left of it. > Also, still sort of sprucing up the files that you sent to me. I'll > have a copy available for review soon. :) Great! I'm looking forward to seeing that. - Bruce From xmath@nubz.org Sat Jan 12 00:46:39 2002 From: xmath@nubz.org (xmath) Date: Sat, 12 Jan 2002 01:46:39 +0100 Subject: [Coldstuff] $stream Message-ID: I've been requested to give some details on the architecture of $stream and descendents. First of all, I'm still fiddling with them, but they can be viewed by going to: http://ice.cold.org:1180/bin/object?target=stream and following the links from there I also had $local_stream and $local_listener, but I wasn't happy with 'em yet so I destroyed them. I'll see if I can make 'em again tomorrow. Why $stream? I basically created it because of a few separate issues I had with networking, in genesis and coldcore (UDP is poorly implemented, the negative port-number for udp using open_connection is a kludge, and in generic there's no room for other protocol, $connection is line-oriented without byte-oriented equivalent etc). I designed $stream to be a generic and clean system for IO. What is a $stream? Basically anything related to IO. The name "stream" doesn't imply it's just byte-oriented. It equally well supports streams of structures messages. Even the $tcp_listener is a $stream (you could say a stream of incoming connections). Architecture The internal methods are prefixed with stream_ and are protected. They're usually native methods. One major exception is stream_event which is actually called by the IO-implementation (usually in Genesis) to notify the stream-object of events. All streams implement some form of stream_open and stream_close (arguments may vary). Most streams also implement stream_read and stream_write. Internals I'd replace both the conn and file fields of Obj by a single stream field, a pointer to a structure with a file descriptor and some flags. Buffering is done in ColdC rather than Genesis (I doubt this will be significantly slower, especially since in Genesis, buffer_append is used too). Native methods are placed on whichever object is the best place to put them. For example, stream_close is placed on $stream because it applies to all streams. If the stream is actually fully implemented in ColdC (like local streams or wrapper streams) then no harm is done.. they'll just override it ($stream.stream_close would do nothing or throw an error) Object overview $stream: any kind of stream $data_stream: stream of bytes $packet_stream: stream of discrete pieces of data (represented by single values) $listener_stream: the name says it all $tcp_stream, $udp_stream, $tcp_listener, $file_stream should be obvious $line_stream: a special mix-in to make a stream of bytes into a stream of lines In all cases, .stream_read and .stream_write are non-buffered and non-blocking. The high-level method .read and .write are buffered and blocking by default, but this can be overridden with flags. In case of $tcp_stream, stream_close is not immediate, but instead will cause a close-event when the close has been acknowledged. You can make it immediate by specifying the 'immediate flag. The $line_stream object is easy to use: for example, to make a line-based TCP stream, make an object with parents: $line_stream, $tcp_stream (in that order) and it works. Note that streams are passive: you just get notified when data has arrived, you still have to read it yourself. You could for example put a loop in .read_notify that reads lines (non-blocking) and calls .parse_line, until no more lines are available. Well, looks like this is about it. I'm gonna sleep, bye :-) - xmath From xmath@nubz.org Sun Jan 13 00:01:48 2002 From: xmath@nubz.org (xmath) Date: Sun, 13 Jan 2002 01:01:48 +0100 Subject: [Coldstuff] To all cold admins out there: bug fixes Message-ID: Bug fixes for everybody who admins a coldcore-derived server, especially if people can get programmer access: 1. $connection.write lacks (> .perms(sender()) <); just add that as first line (already done at the Cold Dark) 2. $scheduler.cancel allows any preempted (non-suspended) task to be killed by anyone. I think only admins should be allowed to do that (maybe the user, but I seriously doubt that, since a task killed in middle of execution could leave things in an inconsistent state). Add an elseif-clause, like: } else if (!$sys.is_system(sender())) { throw(~perm, sender() + " may not kill task " + task_id); } 3. Users can be trapped in a $location with no means of escape, by overriding $location.will_leave to always throw an error. Solution: allow the manager of an object to eject it. On a side note: perhaps eject should allow ejecting objects to their .home() instead. And why not add an argument to .move_to to remove the will-checks (will_move, will_leave, will_arrive) if the sender() is properly authorized. eject can then just check perms and determine the right destination, and call the unchecked version of .move_to. Saves code-duplication. An @eject command would be nice too (and @eject! for a rude version, in case the offending place *is* your home) Here's a write-up (tested on a server, although not thoroughly) that does it all, and allows admins to refuse ejecting from a location. http://www.nubz.org/move-eject.cold.txt 4. There are problems with changing the parents of an object. I'll give a fix as soon as I've figured out what exactly goes wrong and how to fix it. - xmath From xmath@nubz.org Sun Jan 13 00:17:47 2002 From: xmath@nubz.org (xmath) Date: Sun, 13 Jan 2002 01:17:47 +0100 Subject: [Coldstuff] To all cold admins out there: bug fixes In-Reply-To: References: Message-ID: >4. There are problems with changing the parents of an object. I'll >give a fix as soon as I've figured out what exactly goes wrong and >how to fix it. Found it, in $root.chparents: // $sys.clear_definer_vars(a, branch); $sys.clear_definer_vars(a, [this()]); Why is the first line commented out? it IS the correct action the uncommented line leaves variable instances lying around that are annoyingly difficult to get rid of. (at the very least you need to chparent back) - xmath From coldstuff@cold.org Sun Jan 13 18:02:44 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Sun, 13 Jan 2002 11:02:44 -0700 Subject: [Coldstuff] To all cold admins out there: bug fixes In-Reply-To: ; from xmath@nubz.org on Sun, Jan 13, 2002 at 01:17:47AM +0100 References: Message-ID: <20020113110244.A4498@mojo.cold.org> On Sun, Jan 13, 2002 at 01:17:47AM +0100, xmath wrote: > >4. There are problems with changing the parents of an object. I'll > >give a fix as soon as I've figured out what exactly goes wrong and > >how to fix it. > > Found it, in $root.chparents: > > // $sys.clear_definer_vars(a, branch); > $sys.clear_definer_vars(a, [this()]); > > Why is the first line commented out? it IS the correct action > > the uncommented line leaves variable instances lying around that are > annoyingly difficult to get rid of. (at the very least you need to > chparent back) Cleaning ancestry when changing objects has always been a problem, primarily because of MI. It has been a while since this debate last reigned, you should be able to dig it out of the archives... I think Brian's code was a result of the last round of debates, as for if it works properly or not I cannot say, you should try to catch Brian. I would not recommend uncommenting it without first checking with Brian and reading the archives. -Brandon From coldstuff@cold.org Sun Jan 13 18:16:50 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Sun, 13 Jan 2002 11:16:50 -0700 Subject: [Coldstuff] To all cold admins out there: bug fixes In-Reply-To: ; from xmath@nubz.org on Sun, Jan 13, 2002 at 01:01:48AM +0100 References: Message-ID: <20020113111650.A4639@mojo.cold.org> On Sun, Jan 13, 2002 at 01:01:48AM +0100, xmath wrote: > 3. Users can be trapped in a $location with no means of escape, by > overriding $location.will_leave to always throw an error. Solution: > allow the manager of an object to eject it. On a side note: perhaps > eject should allow ejecting objects to their .home() instead. And why > not add an argument to .move_to to remove the will-checks (will_move, > will_leave, will_arrive) if the sender() is properly authorized. > eject can then just check perms and determine the right destination, > and call the unchecked version of .move_to. Saves code-duplication. > An @eject command would be nice too (and @eject! for a rude version, > in case the offending place *is* your home) What situations can you forsee where .will_leave would be throwing an improper error AND the user wasn't the one who caused the error and thus couldn't remove or fix .will_leave in their current location...? It seems more like a workaround for poorly written code; my personal philosophy is if a programmer gets themselves in a bind, they can work themselves out of it, rather than building the system to be able to be nice to them for their oversight :) -Brandon From coldstuff@cold.org Sun Jan 13 18:27:28 2002 From: coldstuff@cold.org (Bruce Mitchener) Date: Sun, 13 Jan 2002 11:27:28 -0700 Subject: [Coldstuff] To all cold admins out there: bug fixes References: <20020113111650.A4639@mojo.cold.org> Message-ID: <3C41D190.8070205@cubik.org> Brandon Gillespie wrote: > On Sun, Jan 13, 2002 at 01:01:48AM +0100, xmath wrote: > >>3. Users can be trapped in a $location with no means of escape, by >>overriding $location.will_leave to always throw an error. Solution: >>allow the manager of an object to eject it. On a side note: perhaps >>eject should allow ejecting objects to their .home() instead. And why >>not add an argument to .move_to to remove the will-checks (will_move, >>will_leave, will_arrive) if the sender() is properly authorized. >>eject can then just check perms and determine the right destination, >>and call the unchecked version of .move_to. Saves code-duplication. >>An @eject command would be nice too (and @eject! for a rude version, >>in case the offending place *is* your home) > > What situations can you forsee where .will_leave would be throwing an > improper error AND the user wasn't the one who caused the error and > thus couldn't remove or fix .will_leave in their current location...? > > It seems more like a workaround for poorly written code; my personal > philosophy is if a programmer gets themselves in a bind, they can work > themselves out of it, rather than building the system to be able to be > nice to them for their oversight :) No, the problem is that .will_leave and .will_arrive are called on the locations, so that's code that the user doesn't and can't control. Yet that code can still trap them somewhere. - Bruce From coldstuff@cold.org Sun Jan 13 22:06:37 2002 From: coldstuff@cold.org (Jonathan) Date: Sun, 13 Jan 2002 14:06:37 -0800 Subject: [Coldstuff] Compile from Win32 to Linux Message-ID: <02011314063700.00569@linuxcore> More Information on the compile issues This is the current error I am getting. ********************************************* Compiling database... Reading from "textdump". Compiling #10451...Segmentation fault ********************************************** I have also gotten an error like the following. *********************************************** Line 1134509 ERROR: Textdump ended inside method definition! *********************************************** The #10451 is the object and is the last item in the textdump file. The Line 1134509 was the last line in fhe textdump file. This is the last information in the file. *********************************************** new object #10451: #793; name $gm_group #10451; var #1 manager = #815; var #1 flags = ['variables, 'methods, 'code]; var #1 created_on = 983126843; var #793 group = #[[#882, 1], [#1176, 1], [#5586, 1], [#8069, 1], [#10891, 1], [#13024, 1], [#26837, 1], [#25107, 1], [#854, 1], [#85662, 1], [#86802, 1], [#13918, 1], [#104248, 1], [#125912, 1], [#129560, 1], [#56698, 1], [#138906, 1], [#89333, 1], [#67734, 1], [#42615, 1], [#148003, 1], [#149345, 1], [#892, 1], [#1354, 1], [#7554, 1], [#8784, 1], [#11560, 1], [#815, 1], [#13637, 1], [#12443, 1], [#75686, 1], [#83721, 1], [#91664, 1], [#13955, 1], [#71598, 1], [#127701, 1], [#130738, 1], [#11027, 1], [#141255, 1], [#141425, 1], [#139717, 1], [#45467, 1], [#149091, 1], [#148150, 1], [#904, 1], [#4207, 1], [#7842, 1], [#9016, 1], [#12118, 1], [#26768, 1], [#12271, 1], [#50634, 1], [#12030, 1], [#85606, 1], [#83741, 1], [#921, 1], [#67625, 1], [#127734, 1], [#82007, 1], [#116923, 1], [#94820, 1], [#141700, 1], [#36842, 1], [#148609, 1], [#149163, 1], [#154265, 1], [#156671, 1], [#156692, 1], [#157635, 1]]; var #1 inited = 1; ********************************************** I have gotten it to work *once* by adding a ; to one of the blank lines and the next time I booted into linux I took off the ; and it compiled fine. Any suggestions? I think it has something to do with the EOF possibly. I have also tried doing a dos2unix on the file and I get the same message with both of the files. Thanks, Jonathan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From coldstuff@cold.org Mon Jan 14 15:24:03 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Mon, 14 Jan 2002 08:24:03 -0700 Subject: [Coldstuff] To all cold admins out there: bug fixes In-Reply-To: <3C41D190.8070205@cubik.org>; from bruce@cubik.org on Sun, Jan 13, 2002 at 11:27:28AM -0700 References: <20020113111650.A4639@mojo.cold.org> <3C41D190.8070205@cubik.org> Message-ID: <20020114082403.A10697@mojo.cold.org> On Sun, Jan 13, 2002 at 11:27:28AM -0700, Bruce Mitchener wrote: > Brandon Gillespie wrote: > > On Sun, Jan 13, 2002 at 01:01:48AM +0100, xmath wrote: > > > >>3. Users can be trapped in a $location with no means of escape, by > >>overriding $location.will_leave to always throw an error. Solution: > >>allow the manager of an object to eject it. On a side note: perhaps > >>eject should allow ejecting objects to their .home() instead. And why > >>not add an argument to .move_to to remove the will-checks (will_move, > >>will_leave, will_arrive) if the sender() is properly authorized. > >>eject can then just check perms and determine the right destination, > >>and call the unchecked version of .move_to. Saves code-duplication. > >>An @eject command would be nice too (and @eject! for a rude version, > >>in case the offending place *is* your home) > > > > What situations can you forsee where .will_leave would be throwing an > > improper error AND the user wasn't the one who caused the error and > > thus couldn't remove or fix .will_leave in their current location...? > > > > It seems more like a workaround for poorly written code; my personal > > philosophy is if a programmer gets themselves in a bind, they can work > > themselves out of it, rather than building the system to be able to be > > nice to them for their oversight :) > > No, the problem is that .will_leave and .will_arrive are called on the > locations, so that's code that the user doesn't and can't control. Yet > that code can still trap them somewhere. Sortof... my belief is that the programmer will break those on their own room, and are hopefully disciplined enough to test their changes. Somebody stumbling into the room without privs is unfortunate, but highly unlikely. A problem of this magnitude should be noticed immediately, and quickly remedied. There are also admins who can usually be paged and brought in to fix the problem... I just am not comfortable with the idea of building a hack into place for the sole purpose of working around programming mistake which would happen very rarely (hasn't yet in my realm) and which can also be fixed immediately... -Brandon From coldstuff@cold.org Mon Jan 14 16:01:35 2002 From: coldstuff@cold.org (xmath) Date: Mon, 14 Jan 2002 17:01:35 +0100 Subject: [Coldstuff] To all cold admins out there: bug fixes In-Reply-To: <20020114082403.A10697@mojo.cold.org> References: <20020113111650.A4639@mojo.cold.org> <3C41D190.8070205@cubik.org> <20020114082403.A10697@mojo.cold.org> Message-ID: >Sortof... my belief is that the programmer will break those on their >own room, and are hopefully disciplined enough to test their >changes. Somebody stumbling into the room without privs is >unfortunate, but highly unlikely. A problem of this magnitude >should be noticed immediately, and quickly remedied. There are also >admins who can usually be paged and brought in to fix the problem... It doesn't have to be a mistake, it may be deliberate. To annoy someone, or as part of a puzzle/exercise, like the Paper Bag at MOO. In either case it may be desirable for someone to have an OOC way to escape in case the IC way doesn't work. (in my suggested code, I added a way for admins to disable this escape mechanism, should it not be desirable) >I just am not comfortable with the idea of building a hack into >place for the sole purpose of working around programming mistake >which would happen very rarely (hasn't yet in my realm) and which >can also be fixed immediately... I don't see why you think it's a hack.. the eject mechanism was already there, I just generalized it a bit, slightly cleaned up the code (less duplicate code) and made a user-accessible command for it. - xmath From coldstuff@cold.org Tue Jan 15 04:04:57 2002 From: coldstuff@cold.org (Adam Cormany) Date: Mon, 14 Jan 2002 23:04:57 -0500 Subject: [Coldstuff] evaluate method Message-ID: <001401c19d79$cbd322a0$c8bab218@spdwy1.in.home.com> This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C19D4F.E2A92E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been trying and can't figure out how to do this on my own so = hopefully the cold gods will smile on me tonight:) I'm parsing some text and by the time it's all finished, I have a string = of an equation of numbers. Is there a way to process this string to get = the answer? For example, I have a string "1+1", is there a way to = process this to get 2? I know about @eval or ; and I want to do exactly = that but inside some code as a method. I've been looking at = $programmer.eval_cmd and $programmer.evaluate but I'm lost. Am I missing = something or is there a simple way to do =3D .("1+1") = ? ------=_NextPart_000_0011_01C19D4F.E2A92E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've been trying and can't figure out = how to do=20 this on my own so hopefully the cold gods will smile on me=20 tonight:)
 
I'm parsing some text and by the time = it's all=20 finished, I have a string of an equation of numbers. Is there a way to = process=20 this string to get the answer? For example, I have a string "1+1", is = there a=20 way to process this to get 2?  I know about @eval or ; and I want = to do=20 exactly that but inside some code as a method. I've been looking at=20 $programmer.eval_cmd and $programmer.evaluate but I'm lost. Am I missing = something or is there a simple way to do <variable> =3D=20 .<method>("1+1") ?
 
------=_NextPart_000_0011_01C19D4F.E2A92E40-- From coldstuff@cold.org Tue Jan 15 05:15:45 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Mon, 14 Jan 2002 22:15:45 -0700 Subject: [Coldstuff] evaluate method In-Reply-To: <001401c19d79$cbd322a0$c8bab218@spdwy1.in.home.com>; from acormany@home.com on Mon, Jan 14, 2002 at 11:04:57PM -0500 References: <001401c19d79$cbd322a0$c8bab218@spdwy1.in.home.com> Message-ID: <20020114221545.A15331@mojo.cold.org> On Mon, Jan 14, 2002 at 11:04:57PM -0500, Adam Cormany wrote: > I've been trying and can't figure out how to do this on my own so hopefully the cold gods will smile on me tonight:) > > I'm parsing some text and by the time it's all finished, I have a string of an equation of numbers. Is there a way to process this string to get the answer? For example, I have a string "1+1", is there a way to process this to get 2? I know about @eval or ; and I want to do exactly that but inside some code as a method. I've been looking at $programmer.eval_cmd and $programmer.evaluate but I'm lost. Am I missing something or is there a simple way to do = .("1+1") ? > @eval and ; on coldcore use .evaluate(), but there is a distilled version as .eval which you can use. The only gotcha is it expects a full method, so include complete statements with 'return'. For your case, do: variable = .eval(["return 1+1"])[2]; Or you can do what .eval is doing, and do your own .add_method, exec, del_method. -Brandon From coldstuff@cold.org Tue Jan 15 13:33:21 2002 From: coldstuff@cold.org (Joerg Weber) Date: Tue, 15 Jan 2002 14:33:21 +0100 (CET) Subject: [Coldstuff] Secure Client/Server ideas? In-Reply-To: <20020114221545.A15331@mojo.cold.org> Message-ID: Hello all, I realize this is the least appropriate forum to ask this, but IF I should happen to win the lottery this, or maybe next week, I'll dig out my nifty core again and do all these cool things with cold I always wanted to. Heh. Anyways. Part of my changes to the ColdCore was a web-interface which is used for RPing. Like a complete substitute for the 'normal' login interface. Since that's available, I wanted to add some spiffy java applets or jscript etc. for some things to interact with the user. But, I'd like that to be somewhat secure. I therefore try to think of concepts about how to run code on an untrusted machine. I know that's the question of life, the universe and everything, but maybe someone has a smart idea? Like, passing a magic session ID to the applet which is used to obfuscate the return values it sends to the server (to stop someone doing this by hand, supplzying desired results)? If someone has some ideas, I'd be happy to hear them. Just keep in mind please that this is in the ideas-stage, I'm afraid I won't have too much time in the forseeable future to work things out. Unless I win the damn lottery, of course :) Cheers, Joerg From coldstuff@cold.org Tue Jan 15 13:46:57 2002 From: coldstuff@cold.org (Adam Cormany) Date: Tue, 15 Jan 2002 05:46:57 -0800 (PST) Subject: [Coldstuff] evaluate method In-Reply-To: <20020114221545.A15331@mojo.cold.org> Message-ID: <20020115134657.21528.qmail@web12801.mail.yahoo.com> I just tried $root.eval on my cold and also on ice.cold with this: @program $user_soth.atc() +access=pub var resp; resp = .eval(["return 1 + 1"]); .tell("resp=" + resp); // $#Edited: 15 Jan 02 06:42 $user_soth When I run this as ;.atc(); I get this result: resp=['errors, ["Line 2: parse error"], 0, 0] It looks like add_method doesn't like what I'm doing? Any other suggestions or am I misunderstand $root.eval? --- Brandon Gillespie wrote: > On Mon, Jan 14, 2002 at 11:04:57PM -0500, Adam > Cormany wrote: > > I've been trying and can't figure out how to do > this on my own so hopefully the cold gods will smile > on me tonight:) > > > > I'm parsing some text and by the time it's all > finished, I have a string of an equation of numbers. > Is there a way to process this string to get the > answer? For example, I have a string "1+1", is there > a way to process this to get 2? I know about @eval > or ; and I want to do exactly that but inside some > code as a method. I've been looking at > $programmer.eval_cmd and $programmer.evaluate but > I'm lost. Am I missing something or is there a > simple way to do = .("1+1") ? > > > > @eval and ; on coldcore use .evaluate(), but there > is a distilled > version as .eval which you can use. The only gotcha > is it expects a > full method, so include complete statements with > 'return'. For your > case, do: > > variable = .eval(["return 1+1"])[2]; > > Or you can do what .eval is doing, and do your own > .add_method, exec, > del_method. > > -Brandon > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From coldstuff@cold.org Tue Jan 15 13:56:50 2002 From: coldstuff@cold.org (Joerg Weber) Date: Tue, 15 Jan 2002 14:56:50 +0100 (CET) Subject: [Coldstuff] evaluate method In-Reply-To: <20020115134657.21528.qmail@web12801.mail.yahoo.com> Message-ID: Hi there! On Tue, 15 Jan 2002, Adam Cormany wrote: > I just tried $root.eval on my cold and also on > ice.cold with this: > @program $user_soth.atc() +access=pub > var resp; > > resp = .eval(["return 1 + 1"]); > .tell("resp=" + resp); > > // $#Edited: 15 Jan 02 06:42 $user_soth > I think you have but a small typo: resp = .eval(["return 1+1"])[2]; Try that :) Can't check it out right now, no access to a ColdCore. Joerg From coldstuff@cold.org Tue Jan 15 14:03:48 2002 From: coldstuff@cold.org (Adam Cormany) Date: Tue, 15 Jan 2002 06:03:48 -0800 (PST) Subject: [Coldstuff] evaluate method In-Reply-To: Message-ID: <20020115140348.89781.qmail@web12805.mail.yahoo.com> I left the [2] out to see what the entire return would be. If you add the [2], you'll only get: resp=["Line 2: parse error"] I wish it was that simple:) --- Joerg Weber wrote: > Hi there! > On Tue, 15 Jan 2002, Adam Cormany wrote: > > > I just tried $root.eval on my cold and also on > > ice.cold with this: > > @program $user_soth.atc() +access=pub > > var resp; > > > > resp = .eval(["return 1 + 1"]); > > .tell("resp=" + resp); > > > > // $#Edited: 15 Jan 02 06:42 $user_soth > > > I think you have but a small typo: > resp = .eval(["return 1+1"])[2]; > > Try that :) > Can't check it out right now, no access to a > ColdCore. > > Joerg > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From coldstuff@cold.org Tue Jan 15 14:46:15 2002 From: coldstuff@cold.org (Jeremy Weatherford) Date: Tue, 15 Jan 2002 08:46:15 -0600 (CST) Subject: [Coldstuff] evaluate method In-Reply-To: <20020115134657.21528.qmail@web12801.mail.yahoo.com> Message-ID: Actually, it's simpler than the other change mentioned... if you have the statement: return 1 + 1 in a method, what do you get? A parse error, of course, because there's no trailing semicolon. :) Try: resp = .eval(["return 1 + 1;"]); Jeremy Weatherford xidus@xidus.net http://xidus.net On Tue, 15 Jan 2002, Adam Cormany wrote: > I just tried $root.eval on my cold and also on > ice.cold with this: > @program $user_soth.atc() +access=pub > var resp; > > resp = .eval(["return 1 + 1"]); > .tell("resp=" + resp); > > // $#Edited: 15 Jan 02 06:42 $user_soth > > When I run this as ;.atc(); I get this result: > resp=['errors, ["Line 2: parse error"], 0, 0] > > It looks like add_method doesn't like what I'm doing? > Any other suggestions or am I misunderstand > $root.eval? > > --- Brandon Gillespie wrote: > > On Mon, Jan 14, 2002 at 11:04:57PM -0500, Adam > > Cormany wrote: > > > I've been trying and can't figure out how to do > > this on my own so hopefully the cold gods will smile > > on me tonight:) > > > > > > I'm parsing some text and by the time it's all > > finished, I have a string of an equation of numbers. > > Is there a way to process this string to get the > > answer? For example, I have a string "1+1", is there > > a way to process this to get 2? I know about @eval > > or ; and I want to do exactly that but inside some > > code as a method. I've been looking at > > $programmer.eval_cmd and $programmer.evaluate but > > I'm lost. Am I missing something or is there a > > simple way to do = .("1+1") ? > > > > > > > @eval and ; on coldcore use .evaluate(), but there > > is a distilled > > version as .eval which you can use. The only gotcha > > is it expects a > > full method, so include complete statements with > > 'return'. For your > > case, do: > > > > variable = .eval(["return 1+1"])[2]; > > > > Or you can do what .eval is doing, and do your own > > .add_method, exec, > > del_method. > > > > -Brandon > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > From coldstuff@cold.org Tue Jan 15 16:09:22 2002 From: coldstuff@cold.org (xmath) Date: Tue, 15 Jan 2002 17:09:22 +0100 Subject: [Coldstuff] Secure Client/Server ideas? In-Reply-To: References: Message-ID: >But, I'd like that to be somewhat secure. I therefore try to think >of concepts about how to run code on an untrusted machine. You can't trust an untrusted machine. Whatever you think you can invent, it'll be crackable. Some people try, with copy-protection schemes etc, but it's trivial to prove that it *can* be cracked, therefore it will be if someone with sufficient skill has enough to benefit from it. The only solution is to make sure the code that runs on the untrusted machine isn't trusted, and that the user doesn't benefit from meddling with it. For example, if it is some kind of UI or allows the user to "do" things, make sure the server simply doesn't accept anything that isn't allowed. In general, the security of a system should never depend on the secrecy of its inner workings, and remember that anything that's on the user's HD or runs on the user's computer, *IS* in hands of the user. This is only not the case if: 1. the software is protected by a secure operating system 2. the OS + software runs on secure hardware 3. the hardware is made tamper-proof, for example by putting it in a building with a camera aimed at the hardware, watched by a security guard I assume this isn't the case, therefore you cannot trust *anything* that comes from the user's computer or any code that runs on the user's computer. Unless tampering with the system cannot give any benefit to the user. (Make an analysis: who would want to mess with your system? what is their goal?) - xmath PS I'm currently reading "Secrets & Lies: Digital Security in a Networked World" by Bruce Schneider... good book :-) From coldstuff@cold.org Thu Jan 24 01:50:07 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Wed, 23 Jan 2002 18:50:07 -0700 Subject: [Coldstuff] Advisory: Security hole with ColdCore Message-ID: <20020123185007.A22072@mojo.cold.org> This is an advisory to anybody running ColdCore. There is a security hole which was found by xmath where anybody can run code as an administrator. I'll post the fix here in a week or so, to give administrators a chance to fix it first. To get the fix either contact me via email or get on the Cold Dark and ask either me or xmath. -Brandon Gillespie From coldstuff@cold.org Thu Jan 24 02:05:27 2002 From: coldstuff@cold.org (Brad Roberts) Date: Wed, 23 Jan 2002 18:05:27 -0800 (PST) Subject: [Coldstuff] Advisory: Security hole with ColdCore In-Reply-To: <20020123185007.A22072@mojo.cold.org> Message-ID: What permissions does the user have to have to exploit? In other words, does it require $guest, $user, $builder, $programmer? Can it be exploited remotely via the default services (http, smtp, etc)? These sorts of things are useful to properly weigh the risk and urgency of obtaining the fix. There's probably other questions worth asking, but you get the point. Its possible to provide some detail other than "you've got a problem, see me for a fix" without giving out the gory details. Later, Brad On Wed, 23 Jan 2002, Brandon Gillespie wrote: > Date: Wed, 23 Jan 2002 18:50:07 -0700 > From: Brandon Gillespie > Reply-To: coldstuff@cold.org > To: coldstuff@cold.org > Subject: [Coldstuff] Advisory: Security hole with ColdCore > > This is an advisory to anybody running ColdCore. There is a security > hole which was found by xmath where anybody can run code as an > administrator. I'll post the fix here in a week or so, to give > administrators a chance to fix it first. To get the fix either > contact me via email or get on the Cold Dark and ask either me or > xmath. > > -Brandon Gillespie > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > From coldstuff@cold.org Thu Jan 24 06:40:00 2002 From: coldstuff@cold.org (xmath) Date: Thu, 24 Jan 2002 07:40:00 +0100 Subject: [Coldstuff] Advisory: Security hole with ColdCore In-Reply-To: References: Message-ID: >What permissions does the user have to have to exploit? In other words, >does it require $guest, $user, $builder, $programmer? Can it be exploited >remotely via the default services (http, smtp, etc)? > >These sorts of things are useful to properly weigh the risk and urgency of >obtaining the fix. There's probably other questions worth asking, but you >get the point. Its possible to provide some detail other than "you've got >a problem, see me for a fix" without giving out the gory details. To be able to exploit the security hole, the user must be able to execute a public method, which normally means he has to be $programmer. If he can exploit the hole, he can basically do anything, including making himself an admin. - xmath From coldstuff@cold.org Fri Jan 25 04:55:48 2002 From: coldstuff@cold.org (Vanish 1024) Date: Thu, 24 Jan 2002 20:55:48 -0800 Subject: [Coldstuff] Advisory: Security hole with ColdCore Message-ID: <20020125045548.YQV12575.mta04.onebox.com@onebox.com> I'ld like the gory details if you please :) And the fix too. -- Vanish 1024 vanish1024@onebox.com - email (818) 630-2340 x5993 - voicemail/fax ---- Brad Roberts wrote: > What permissions does the user have to have to exploit? In other words, > does it require $guest, $user, $builder, $programmer? Can it be exploited > remotely via the default services (http, smtp, etc)? > > These sorts of things are useful to properly weigh the risk and urgency > of > obtaining the fix. There's probably other questions worth asking, > but you > get the point. Its possible to provide some detail other than "you've > got > a problem, see me for a fix" without giving out the gory details. > > Later, > Brad > > On Wed, 23 Jan 2002, Brandon Gillespie wrote: > > > Date: Wed, 23 Jan 2002 18:50:07 -0700 > > From: Brandon Gillespie > > Reply-To: coldstuff@cold.org > > To: coldstuff@cold.org > > Subject: [Coldstuff] Advisory: Security hole with ColdCore > > > > This is an advisory to anybody running ColdCore. There is a security > > hole which was found by xmath where anybody can run code as an > > administrator. I'll post the fix here in a week or so, to give > > administrators a chance to fix it first. To get the fix either > > contact me via email or get on the Cold Dark and ask either me or > > xmath. > > > > -Brandon Gillespie > > _______________________________________________ > > Cold-Coldstuff mailing list > > Cold-Coldstuff@cold.org > > http://web.cold.org/mailman/listinfo/cold-coldstuff > > > > > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com From coldstuff@cold.org Fri Jan 25 05:45:54 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Thu, 24 Jan 2002 22:45:54 -0700 Subject: [Coldstuff] new ColdCore Message-ID: <20020124224554.A4270@mojo.cold.org> There is a new ColdCore on the ftp site; consider it beta-grade primarily due to lack of docs and no upgrade path. I expect to follow follow it up soon with better information. From coldstuff@cold.org Fri Jan 25 05:52:22 2002 From: coldstuff@cold.org (Joerg Weber) Date: Fri, 25 Jan 2002 06:52:22 +0100 (CET) Subject: [Coldstuff] new ColdCore In-Reply-To: <20020124224554.A4270@mojo.cold.org> Message-ID: Hello, just out of curiousity: What exactly is the 'lack of upgrade path'? Means, I can't run it and incorporate my patches which worked on former ColdCores? Thanks, J On Thu, 24 Jan 2002, Brandon Gillespie wrote: > There is a new ColdCore on the ftp site; consider it beta-grade > primarily due to lack of docs and no upgrade path. I expect to > follow follow it up soon with better information. > _______________________________________________ > Cold-Coldstuff mailing list > Cold-Coldstuff@cold.org > http://web.cold.org/mailman/listinfo/cold-coldstuff > From coldstuff@cold.org Fri Jan 25 15:50:43 2002 From: coldstuff@cold.org (Brandon Gillespie) Date: Fri, 25 Jan 2002 08:50:43 -0700 Subject: [Coldstuff] new ColdCore In-Reply-To: ; from joerg@fs.is.uni-sb.de on Fri, Jan 25, 2002 at 06:52:22AM +0100 References: <20020124224554.A4270@mojo.cold.org> Message-ID: <20020125085043.A2325@mojo.cold.org> On Fri, Jan 25, 2002 at 06:52:22AM +0100, Joerg Weber wrote: > Hello, > > just out of curiousity: > What exactly is the 'lack of upgrade path'? Means, I can't run it and > incorporate my patches which worked on former ColdCores? > > Thanks, I used to have an automated way of upgrading a db (the upgradedb scripts), which are not available with this release. I was going to look into resurrecting those. -Brandon From coldstuff@cold.org Fri Jan 25 22:36:42 2002 From: coldstuff@cold.org (xmath) Date: Fri, 25 Jan 2002 23:36:42 +0100 Subject: [Coldstuff] Advisory: Security hole with ColdCore In-Reply-To: <002301c180ff$88d71f60$9900a8c0@alpha> References: <20020123185007.A22072@mojo.cold.org> <002301c180ff$88d71f60$9900a8c0@alpha> Message-ID: (to other admins: I've given the fix to "Vanish 1024" and "Jon" - just letting you know to avoid duplicate efforts) - xmath