December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM page in pharo book is outdated

by Javier PimÃ¡s

Thanks for the comments. There are many things missing in the book yet, because we still don't have so many usage examples. We are trying to incorporate them as we get more usage experience. With the cairo wrapper and igor's help I got some experience, so I tried to put the learnt lessons in the book. If you find some example you would like to have, or some thing missing, just tell and we'll try to add it. Of course this is a work in progress, but igor's work on nativeboost is very complete. One last thing, as Igor told me one time, many people think that FFI is like rocket science, but that's not the case. I encourage people to try and start with it, because it's really easy and we are here to help. The base of the cairo wrapper took 1 afternoon, and the same happened with the X lib wrapper. Cheers, Javier On Wed, Nov 30, 2011 at 11:18 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Stef, Sig, > > Thanks for the preview! > > One thing that jumped out at me so far is the passing of strings by copy. > Interestingly, I can't find an example (in my code where I would have > sworn I had a few) of having an external library fill a string, but I know > I have encountered it and wonder if/how Spock would handle it. This > reminds me of Dolphin's default "pass by reference" (albeit in reverse) for > external byte objects. > > In short, the Dolphin vm automatically passes the address of certain > objects, and it often does what one wants. It also makes some things > difficult to do. For example, one time I had to pass a COM interface > pointer from one component to another, and to do it in Dolphin, I had to > construct an intermediate byte object to hold the pointer, just so the vm > would have a gratuitous level of indirection to remove in making the call. > In fairness, I encountered very few such examples, but OA did ultimately > express some regret over the decision. FWIW. > > A comment in the document asks about the available types, citing float, > double and boolean. All good examples. We also need a full range of > integer sizes (8, 16, 32, 64 bytes), signed and unsigned, and in array > form. We need Float and double arrays too. Floats are sometimes used to > save space (especially in multi-dimensional settings), and some researchers > might care to use floats and doubles separately to look at roundoff error > in computations. The real reason to have floats and doubles is that there > are libraries that use both types. > > Another type that crops up is long double. So far, I can't say they have > been critical to my work, but I have had to hack around appearances of them. > > The chapter shows the use of <primitive:module:> and states that it avoids > the need to create instances. Very true, but I pose the question of > whether we should encourage formal library (handle body) instances? The > idea is that it provides some hope of being able to unload a library while > the image is running. Whether that has any teeth is open for debate (I > recall having trouble getting libraries to actually unload on a certain OS > that will remain nameless<g>). In fairness to that OS, I do not recall the > circumstances, but it sure seemed like yet another weirdness. > > Another advantage of placing the library name in one method is that it can > be edited in one place. GSL has *thousands* of functions and hence > thousands of wrapper methods. Tweaking every one would be ugly. Worse, > ODBC goes by different names on Windows and Linux, and I doubt it is alone. > There is a real role for #moduleName to test the OS and answer the > appropriate string - something that can't be done with <primitive:module:>. > > Dolphin uses a class per library and a singleton instance of each; it > "felt right," and Pharo's FFI will work that way. I subclass > ExternalLibrary and do not specify a module name for each function call. > Bottom line, if you get callbacks working, I'll play along regardless of > small details :) > > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane > Ducasse [stephane.ducasse(a)inria.fr] > Sent: Wednesday, November 30, 2011 2:00 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] VM page in pharo book is outdated > > everything is public no secret > > https://gforge.inria.fr/scm/viewvc.php/?root=pharobooks > > just a lot of work â¦. and pain with english > > Stef > > > > On Nov 30, 2011, at 7:19 PM, Igor Stasenko wrote: > > > On 30 November 2011 18:56, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: > >> Stef, > >> > >> Apologies if I am exploiting something you meant to send privately, but > "draft of a chapter" on FFI?????!!!!!! :) :) :) > >> > >> I'm no expert, but I certainly like to see what is being written. It > is difficult to imagine how I could fail to learn something from it. > >> > > hmm, i seen a draft in my mailbox, but i cannot remember if i received > > privately or from public mailing list. > > > > And of course, there is no reason to keep it private: i think the more > > reviewers/readers it has, the better it will be. > > > >> Bill > >> > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Dec. 2, 2011

Re: [Pharo-project] The SmalltalkHub demo is online!

by Sean P. DeNigris

Sean P. DeNigris wrote > > I reported 3 bugs as per these instructions, and they seem to have > disappeared after the last update - doh! > Bump. Is it now safe to submit bugs via the site itself, or is there a better way? -- View this message in context: http://forum.world.st/The-SmalltalkHub-demo-is-online-tp4073806p4147053.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 2, 2011

Re: [Pharo-project] SystemTracer

by Pavel Krivanek

Just kernel from CI server. -- Pavel On Fri, Dec 2, 2011 at 11:34 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks a lot. > Did you try with Pharo1.4? or just kernel? > > Stef > > On Dec 2, 2011, at 10:00 AM, Pavel Krivanek wrote: > >> Well, so it works, I only had to remove line >> >> SystemWindow wakeUpTopWindowUponStartup. >> >> from the method SystemTracer2 processStartup. >> >> Cheers, >> -- Pavel >> >> >> On Fri, Dec 2, 2011 at 9:09 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> I published a new version in PharoTaskForces. >>> Thanks! >>> >>> stef >>> >>> >>> >>> On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: >>> >>>> What version of SystemTracer do you use, I would try Pharo-Kernel so >>>> we can see if it is UI related. >>>> >>>> -- Pavel >>>> >>>> On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >>>>> >>>>>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>> Hi guys >>>>>>> >>>>>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>>>>> Now when I execute >>>>>>> Â Â Â Â SystemTracer2 writeImage: 'clone.image' >>>>>>> the process finishes, the image I obtain start but the UI is not working. >>>>>>> >>>>>>> Benjamin was it working when you tried with igor? >>>>>>> >>>>>> >>>>>> Yes, we had a working image, but not without some voodoo dance. >>>>>> But i don't remember what we did. >>>>>> In Hazel we are replacing a process, so there is no UI thread. A >>>>>> SystemTracer alone, however should copy stuff as it is. >>>>> >>>>> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >>>>> We should have a look at that. >>>>> BTW are you better or still sick? >>>>> >>>>> Stef >>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >

Dec. 2, 2011

Re: [Pharo-project] SystemTracer

by Igor Stasenko

On 2 December 2011 10:00, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Well, so it works, I only had to remove line > > SystemWindow wakeUpTopWindowUponStartup. > yes, now i remember we were patching that (among other things). > from the method SystemTracer2 processStartup. > > Cheers, > -- Pavel > > > On Fri, Dec 2, 2011 at 9:09 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I published a new version in PharoTaskForces. >> Thanks! >> >> stef >> >> >> >> On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: >> >>> What version of SystemTracer do you use, I would try Pharo-Kernel so >>> we can see if it is UI related. >>> >>> -- Pavel >>> >>> On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >>>> >>>>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> Hi guys >>>>>> >>>>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>>>> Now when I execute >>>>>> Â Â Â Â SystemTracer2 writeImage: 'clone.image' >>>>>> the process finishes, the image I obtain start but the UI is not working. >>>>>> >>>>>> Benjamin was it working when you tried with igor? >>>>>> >>>>> >>>>> Yes, we had a working image, but not without some voodoo dance. >>>>> But i don't remember what we did. >>>>> In Hazel we are replacing a process, so there is no UI thread. A >>>>> SystemTracer alone, however should copy stuff as it is. >>>> >>>> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >>>> We should have a look at that. >>>> BTW are you better or still sick? >>>> >>>> Stef >>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >> >> > > -- Best regards, Igor Stasenko.

Dec. 2, 2011

Re: [Pharo-project] SystemTracer

by StÃ©phane Ducasse

Thanks a lot. Did you try with Pharo1.4? or just kernel? Stef On Dec 2, 2011, at 10:00 AM, Pavel Krivanek wrote: > Well, so it works, I only had to remove line > > SystemWindow wakeUpTopWindowUponStartup. > > from the method SystemTracer2 processStartup. > > Cheers, > -- Pavel > > > On Fri, Dec 2, 2011 at 9:09 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I published a new version in PharoTaskForces. >> Thanks! >> >> stef >> >> >> >> On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: >> >>> What version of SystemTracer do you use, I would try Pharo-Kernel so >>> we can see if it is UI related. >>> >>> -- Pavel >>> >>> On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >>>> >>>>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>> Hi guys >>>>>> >>>>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>>>> Now when I execute >>>>>> SystemTracer2 writeImage: 'clone.image' >>>>>> the process finishes, the image I obtain start but the UI is not working. >>>>>> >>>>>> Benjamin was it working when you tried with igor? >>>>>> >>>>> >>>>> Yes, we had a working image, but not without some voodoo dance. >>>>> But i don't remember what we did. >>>>> In Hazel we are replacing a process, so there is no UI thread. A >>>>> SystemTracer alone, however should copy stuff as it is. >>>> >>>> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >>>> We should have a look at that. >>>> BTW are you better or still sick? >>>> >>>> Stef >>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >> >> >

Dec. 2, 2011

Re: [Pharo-project] startup errors

by Andrea BrÂÃ¼hlmann

I tested it a bit in a fresh 1.3 image and opened the issue 5045, maybe we can continue the discussion there. The feature would be great! Andrea Igor Stasenko schrieb: > On 26 October 2011 11:51, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> wrote: > >> I tried it with this option now, but it did not solve the problem, because >> it just saved a new version of the image and quit, but did not open a >> debugger. Opening the new version does the same as the original. Did I miss >> something? >> >> > It should open a debugger. if not, then this is a bug :) > It might be, that if error happens in startup phase, then it is not > opens a debugger. > > >> I would appreciate a command line option that either opens a debugger or >> ignores the errors, because like this you usually have a clean image but if >> you have a problem, you can open the image and do something. >> >> Andrea >> >> Igor Stasenko schrieb: >> >>> On 25 October 2011 23:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> >>>> Sig, >>>> >>>> All too true, and very pure. But what if I just want to save a package, >>>> or some data, that might be locked away in the image? Code is generally >>>> safe, since one can recover lost changes into a healthy image, but there can >>>> still be other data lurking in an image. >>>> >>>> A middle-ground approach would be to have command line option that lets >>>> the image run. One should run w/o it to bring errors to attention, but at >>>> least it would be possible to override and at least have an opportunity to >>>> recover endangered bits. >>>> >>>> >>> look at settings, there's already an option to save a new version of >>> image before quit. >>> if you turn this option on, then any unhandled error will open a >>> debugger if you open an image saved in such state. >>> >>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >>>> [siguctua(a)gmail.com] >>>> Sent: Tuesday, October 25, 2011 9:40 AM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] startup errors >>>> >>>> On 24 October 2011 11:40, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> >>>> wrote: >>>> >>>>> It seems that pharo 1.3 introduced that the image quits if an error >>>>> happens >>>>> during startup. What are the reasons for this? >>>>> >>>>> >>>> The reasons are simple: >>>> if image fails to startup properly, there are no way to tell, if some >>>> services initialized properly or not (UI is one of them), >>>> and so, there are no any guarantees that image could run safely. >>>> So, the best thing which you can do is to write error to log and quit. >>>> >>>> This is because startup manager knows what to start-up and in what >>>> order, but it doesn't knows, how critical a given service for properly >>>> running the whole image. Therefore, if you don't handle startup errors >>>> in your service code, a startup manager has no other choice , but just >>>> leave to OS. >>>> >>>> >>>> >>>>> Or what's the state of the email below? >>>>> >>>>> Andrea >>>>> >>>>> >>>>> Camillo Bruni schrieb: >>>>> >>>>>> While working on Coral we encountered a rather annoying behavior of >>>>>> pharo >>>>>> images when starting up. >>>>>> >>>>>> We wanted to check if we can debug the CoralScriptLoader, but of corse >>>>>> since this happens at image startup time this is not a good ideaâ¦ >>>>>> HOWEVER we >>>>>> were no longer able to run the image as it immediately crashes during >>>>>> the >>>>>> startup. >>>>>> >>>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>>> startup >>>>>> scripts and then only show them after all other startupListItems are >>>>>> processed. >>>>>> >>>>>> All in all the behavior would not much differ from what is going on >>>>>> right >>>>>> now, but would prevent stupid users like me from losing a whole image. >>>>>> >>>>>> camillo >>>>>> >>>>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>>> >>>> >>> >>> >> -- >> AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >> | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >> | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 >> | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >> >> >> > > > >

Dec. 2, 2011

Re: [Pharo-project] SystemTracer

by Pavel Krivanek

Well, so it works, I only had to remove line SystemWindow wakeUpTopWindowUponStartup. from the method SystemTracer2 processStartup. Cheers, -- Pavel On Fri, Dec 2, 2011 at 9:09 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I published a new version in PharoTaskForces. > Thanks! > > stef > > > > On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: > >> What version of SystemTracer do you use, I would try Pharo-Kernel so >> we can see if it is UI related. >> >> -- Pavel >> >> On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >>> >>>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> Hi guys >>>>> >>>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>>> Now when I execute >>>>> Â Â Â Â SystemTracer2 writeImage: 'clone.image' >>>>> the process finishes, the image I obtain start but the UI is not working. >>>>> >>>>> Benjamin was it working when you tried with igor? >>>>> >>>> >>>> Yes, we had a working image, but not without some voodoo dance. >>>> But i don't remember what we did. >>>> In Hazel we are replacing a process, so there is no UI thread. A >>>> SystemTracer alone, however should copy stuff as it is. >>> >>> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >>> We should have a look at that. >>> BTW are you better or still sick? >>> >>> Stef >>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> > >

Dec. 2, 2011

Re: [Pharo-project] SystemNavigation vs. SystemOrganizer

by StÃ©phane Ducasse

This idea of globals is wrong and not modular. And the idea to use global variable instead of a instance variable makes the system difficult to cut in module. A namespace holds its organization. So it should be moreâ¦. SystemOrganizer>>default "look in the environment that the receiver organizes for the associated organization" ^ self environment organization On Dec 2, 2011, at 12:15 AM, Luc Fabresse wrote: > > 2011/12/1 Sean P. DeNigris <sean(a)clipperadams.com> > SystemNavigation default. -> an object that let's you navigate the current > system > SystemOrganizer default. -> ??? To get what I would expect from above, it > seems I need to access the global SystemOrganization. > > Does anyone else find this confusing? > > yes ;-) > > Luc > > > Sean > > -- > View this message in context: http://forum.world.st/SystemNavigation-vs-SystemOrganizer-tp4131010p4131010… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 2, 2011

Re: [Pharo-project] SystemTracer

by StÃ©phane Ducasse

I published a new version in PharoTaskForces. Thanks! stef On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: > What version of SystemTracer do you use, I would try Pharo-Kernel so > we can see if it is UI related. > > -- Pavel > > On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >> >>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Hi guys >>>> >>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>> Now when I execute >>>> SystemTracer2 writeImage: 'clone.image' >>>> the process finishes, the image I obtain start but the UI is not working. >>>> >>>> Benjamin was it working when you tried with igor? >>>> >>> >>> Yes, we had a working image, but not without some voodoo dance. >>> But i don't remember what we did. >>> In Hazel we are replacing a process, so there is no UI thread. A >>> SystemTracer alone, however should copy stuff as it is. >> >> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >> We should have a look at that. >> BTW are you better or still sick? >> >> Stef >> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

Dec. 2, 2011

Re: [Pharo-project] VM freezes sending #basicNew to Stream subclass

by StÃ©phane Ducasse

>>> >>> I only had a look in Pharo 1.4 >>> It sounds like a subtle bug related to introduction of >>> SubclassResponsibility in Pharo. >>> If you revert Object>>subclassResponsibility to its previous version >>> you get a more reliable error. >> >> What would be your hypothesis? Because I'm stuck. >> error: is also signaling an exception >> >> error: aString >> "Throw a generic Error exception." >> >> ^Error new signal: aString >> >> So I wonder why one is more robust. >> > > I'm stuck too, and the Debugger is currently unusable in Pharo 1.4 (I > just can't step overâ¦) Strange. Because I use it. Do you have a scenario that we can focus on to fix the problem you see. > I give up. I only had time for an easy task... > > Nicolas > >> >> >>> >>> Nicolas >>> >>> 2011/12/1 Larry White <ljw1001(a)gmail.com>: >>>> I was able to replicate with a clean version of the Seaside 3.0.6 One Click >>>> download by executing Stream #basicNew in a workspace. It did work a couple >>>> times ok using "do it" from the menu, but seems to lock pretty regularly >>>> using print or explore keyboard shortcuts. >>>> >>>> thanks. >>>> >>>> >>>> >>>> On Thu, Dec 1, 2011 at 1:33 PM, Larry White <ljw1001(a)gmail.com> wrote: >>>>> >>>>> I can do it with control-P (print) in the Workspace. I just did it with a >>>>> single try, though sometimes it takes more than one. Speed isn't an issue, >>>>> I can wait 10 minutes and see it happen sometimes.. >>>>> >>>>> I have to take a break now, but when I get a few minutes, I'll try again >>>>> with a fresh install of the latest Seaside one-click for the mac. >>>>> >>>>> thanks. >>>>> >>>>> On Thu, Dec 1, 2011 at 1:20 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>>> wrote: >>>>>> >>>>>> I just tried to hang 1.1.1 (using a traditional linux vm) and a 1.4 image >>>>>> with a Cog vm (also linux). No problems, but I do have questions that might >>>>>> be important to others trying to reproduce it: >>>>>> >>>>>> (1) how fast do you do this? >>>>>> (2) do you inspect the instances, or just let them get gc'd immediately? >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Larry White >>>>>> [ljw1001(a)gmail.com] >>>>>> Sent: Thursday, December 01, 2011 12:56 PM >>>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> Subject: Re: [Pharo-project] VM freezes sending #basicNew to Stream >>>>>> subclass >>>>>> >>>>>> I can do it with >>>>>> >>>>>> Stream basicNew. >>>>>> >>>>>> but I have to invoke it twice. The first time it works ok. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 1, 2011 at 12:48 PM, StÃ©phane Ducasse >>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>> >>>>>>> gary >>>>>>> >>>>>>> can you post the smallest code that makes the system hangs? >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On Dec 1, 2011, at 4:48 PM, Larry White wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Throwing this out there because it may be a bug. >>>>>>>> >>>>>>>> I'm running the Seaside one-click install on OS X Lion. >>>>>>>> Pharo1.3 >>>>>>>> Latest update: #13302 >>>>>>>> >>>>>>>> I can reliably cause my VM to freeze up and need to Force-Quit it from >>>>>>>> the OS. >>>>>>>> >>>>>>>> I'm implementing (copying) the probability logic from the blue book. >>>>>>>> When I tried to create an instance of the Binomial class, the system hung. I >>>>>>>> can replicate the problem by sending the message #basicNew to >>>>>>>> ProbabilityDistribution. ProbabilityDistribution is a direct subclass of >>>>>>>> Stream and I haven't overridden or modified #basicNew. >>>>>>>> >>>>>>>> What's happening is that it fails in the BlockClosure [anObject doit], >>>>>>>> but only when I instantiate a member of this particular class hierarchy. In >>>>>>>> the probability classes, a #doIt in a Workspace hits the line "self suspend" >>>>>>>> in the #terminate method of Process and the VM hangs there. >>>>>>>> >>>>>>>> I believe they had ProbabilityDistribution subclass from Stream >>>>>>>> because sampling from a distribution is like reading from a Stream, but I >>>>>>>> don't think any there's any actual shared code, so I switched the superclass >>>>>>>> of ProbabilityDistribution to Object and the code works fine now. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Larry >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >

Dec. 2, 2011