- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Athens work in progress: couple screenshots

by Javier PimÃ¡s

This is great! We have to keep improving it. Cheers, Javier. On Wed, Nov 30, 2011 at 9:32 AM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > I've implied using meta-programming,in order to have a uniform > protocol in the abstract Canvas. > AthensCanvas>>transformDescribedBy: aName > self perform: ( aName , 'Transform' ) asSymbol . > > But i see that your approach is simpler, there's no need for a uniform > protocol because when you are using a particular AthensCanvas you are > fully aware of that! > > Regarding the build, after a lonnnngg series of errors, i also managed > to build universal binaries of Cairo, using MacPorts (brew just > doesn't ease the task of creating 32 bit libraries). > sudo port cairo +universal, worked for me, taking at least 30 min to build. > > ATTENTION: Before entering the port cairo install command, I've had to > manually install appleGcc4.2, found @ [1] (file name > gcc-42-5666.3-darwin11.pkg. Given that i have Lion, XCode4.2, and if > you just allow macports to build appleGcc4.2, it will run a process > that consumes resources and finally stalls your computer! > > I've attached a screen shot that may help somebody else, for setting > up the examples. Using NativeBoost Cog VM for Mac, downloadable from > NativeBoost site or Jenkins. > > Great work Javier, and Igor! I'm looking forward to implement a Text > editor using Cairo+Pango + "my new morphic". > > Fernando > [1] http://r.research.att.com/tools/ > > > > On Tue, Nov 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 29 November 2011 16:12, Fernando Olivero <fernando.olivero(a)usi.ch> > wrote: > >> I get the point now, something like the brushes in seaside. > >> Thanks for the explanation. > >> > >> Regarding the protocol, did you consider reusing the same idea, but > >> one step before, as in the following: > >> > >> pathTransform := canvas transformDescribedBy: 'path'. > >> pathTransform scaleBy: 0.5. > >> > >> imageTransform := canvas transformDescribedBy: 'image'. > >> imageTransform scaleBy: 0.5. > >> > >> Maybe add the following for documentation: > >> > >> AthensCairo>>availableTransforms > >> ^ #('path'. 'image'. ) > >> > >> AthensOpenGL>>availableTransforms > >> ^ #('modelView'. 'projection'. ) > >> > >> This would unify the canvas protocol, for all the available rendering > engines. > >> > > > > This sounds more complicated. We can map different matrices in > > different engines to Athens. > > So, it is not necessary for client code to know which of them are > > there, because then code will be > > filled with tons of #ifTrue: branches ... . > > > > > > > > -- > > Best regards, > > Igor Stasenko. > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Dec. 2, 2011

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

by Nicolas Petton

On Fri, 2011-12-02 at 05:50 -0800, Sean P. DeNigris wrote: > 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? Yeah, as I said I just flushed the db when I put the new demo online. Cheers, Nico > > -- > 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

[Pharo-project] [update 1.4] #14240

by Marcus Denker

14240 ----- Issue 5037: Remove the failing CompiledMethodTest>>testAuthor http://code.google.com/p/pharo/issues/detail?id=5037 Issue 3529: TextMorph>>releaseCachedState creates a paragraph which causes a Subscript out of bounds in an internal RunArray http://code.google.com/p/pharo/issues/detail?id=3529 Issue 3621: The S in fullscreen should not be capitalized http://code.google.com/p/pharo/issues/detail?id=3621 -- Marcus Denker -- http://marcusdenker.de

Dec. 2, 2011

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