February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opening...

by Yanni Chiu

On 16/02/12 4:13 PM, S Krish wrote: > This is a VA App of about 3 million lines of code.. > > Ported to Java and now live. The VA work is now to maintain and sustain > it till Java can get its handle over all the major implementations over > the years ahead. Do you mean the Java port is now live? Then why does the VA App need to be maintained?

Feb. 17, 2012

Re: [Pharo-project] garbage collection

by Chris Muller

Ok. I thought you were trying to figure out whether the majority of the Semaphores you were seeing were due to Magma or not. I have a suspicion that they may be. Which might be a concern since I didn't realize there was a Semaphore limit.. I was suggesting that, since MaTimer references Mutex references Semaphore, you could do: Semaphore instanceCount - MaTimer instanceCount "The number of Semaphores allocated due to Magma's use of MaTimer" - Chris On Thu, Feb 16, 2012 at 10:57 AM, Milan Mimica <milan.mimica(a)gmail.com> wrote: > When Magma is down there are no instances of MaTimer. There are 3 instances > of MaServerSocket though. > > On 15 February 2012 18:41, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> Milan, try checking whether the number of instances of MaTimer >> correlate to the number of instances of Semaphore you are seeing. >> >> Â - Chris >> >> On Tue, Feb 14, 2012 at 2:01 PM, Milan Mimica <milan.mimica(a)gmail.com> >> wrote: >> > This is more of a GC theory question perhaps, but I do have practical >> > problems, so: I'm trying to figure out how come my headless Pharo 1.3 >> > image >> > with fairly recent Cog running Magma ran out of Semaphores. I know there >> > is >> > a fixed limit on number of semaphores Cog can handle, and only Magma and >> > RFB >> > server have been running on this image for two months, and there wasn't >> > any >> > heavy load whatsoever, so something must be leaking semaphores - or more >> > likely - something must be leaking objects having reference(s) to >> > semaphore(s).Â I am not leaking sockets btw. >> > >> > At the moment there is about 1400 instances of Semaphore class, and >> > around >> > 400 after GC. >> > So first question is: Suppose I haven't run GC manually, could the >> > semaphore >> > limit be hit? >> > >> > 400 is still too high for a idling image, don't you think? >> > >> > Anyway, what I try next is to shut down Magma completely and try to >> > clean >> > the memory by hand. I notice some MaServerSockets are still floating >> > around >> > so I track the pointers and I find that all the references are circular! >> > Question two: Does Pharo's GC solve circular references? If yes, how >> > good is >> > it at it? >> > >> > But then, thinking more about it, the whole running image is one big >> > graph >> > of circular references, you wouldn't want the GC to clean that :) So how >> > does it really work? That's my naive view anyway. >> > >> > After I wrote all this I figure I'm better of taking a fresh new image >> > and >> > load what I need into it, even if I have to do it every two months. Not >> > saving the image is also an option. Yeah, I think I'm going to do just >> > that. >> > I found my solution, at least this e-mail served for something. Since I >> > don't have a blog I'll send it anyway. >> > >> > >> > -- >> > Milan Mimica >> > >> > > > > -- > Milan Mimica > http://sparklet.sf.net

Feb. 17, 2012

Re: [Pharo-project] Traits in PHP

by Nicolas Passerini

On Thu, Feb 16, 2012 at 7:35 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > oh, ok. Yeah, I like the idea, but I agree with stef that you need tool > support... an environment like Self for example > I agree, it would need some tool support, I didn't have time to work on it yet. Which kind of tool support do you think we would need? (I love many of the ideas in Self, but the environment is not one of them.) One thing I would like to put some work on is refactorings for traits (including some not necessarily related with the previous idea).

Feb. 17, 2012

Re: [Pharo-project] Traits in PHP

by Hernan Wilkinson

oh, ok. Yeah, I like the idea, but I agree with stef that you need tool support... an environment like Self for example On Thu, Feb 16, 2012 at 6:11 PM, Nicolas Passerini <npasserini(a)gmail.com>wrote: > > > On Thu, Feb 16, 2012 at 4:20 PM, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> wrote: > >> It looks interesting, but how this relates to the state issue? >> >> >> > It is not directly related to the state issue. Just to different trait > models, I think that it would be a nice yet very simple enhancement, to be > able add a trait directly to an object at instantiation time istead of > always having to create a new class. > > I apologise if my mail was confusing. > > However mi little traits extension has also something to say about state. > When I do: > myObject := (*MyClass with: MyTrait*) new > > The class of myObject is created dynamically, so I can have MyTrait > declaring its required state an then the instance variables are created > automatically. It is also a little extension to declaring required methods. > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Nicolas Cellier

Le 16 fÃ©vrier 2012 22:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > > On Feb 16, 2012, at 4:35 PM, Nicolas Passerini wrote: > >> I think it would be very nice to be able to apply a trait directly to an object, without having to create a new class. >> This is possible for example in scala: >> >> Â Â Â val myObject = new MyClass with MyTrait >> >> I have programmed a simple implementation in Pharo which allows you to do: >> >> myObject := (MyClass with: MyTrait) new. >> >> The implementation is only a proof of concept and has some issues that should be addressed before being able to use it in a real program, but I can make it available if someone is interested. >> >> What do you think about this? > > I do not think that I want that. > Because: > Â Â Â Â what about tools support? > Â Â Â Â I do not see the use case. > > Now you can do prototypes for fun. > Stef I find it interesting if ever you create plenty composition options and don't want to provide a static implementation for the whole set of partitions N composable traits => (2 raisedTo: N) partitions... This also avoid to have a whole zoo of class names. But then, each instance will have it's own class copy created on the gly, which might be suboptimal. Unless we cache... Here is a dumb example (with stateful traits): you want to stop wasting 12 bits of identity hash in each object header, when you only rarely put these objects in identity hashed collections... You thus add the trait on the fly IdentityDictionary at: key put: value key acquireIdentityHash. snip... Object>>acquireIdentityHash ^self becomeForward: ((self class withTrait: IdentityHashed) basicNew copyStatesFrom: self; initializeIdentityHash) IdentityHashed>>acquireIdentityHash ^self IdentityHashed>>initializeIdentityHash identityHash ifNil: [identityHash := self createRandomIdentityHash] IdentityHashed>>identityHash ^identityHash If this was possible, you would of course not duplicate each class with its IdentityHashed variant :) Nicolas

Feb. 16, 2012

Re: [Pharo-project] [update 1.3] #13321

by Helene Bilbo

where can you find this version? on the website the newest version is 13315 and on Jenkins 13320. -- View this message in context: http://forum.world.st/update-1-3-13321-tp4390355p4395588.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 16, 2012

Re: [Pharo-project] TabbedPane Class/ Package / Workspace browsers

by S Krish

* Yes I do agree one single Tabbed Pane is a limitation, and I do not impose one. * There is great use to opening independent windows.. and it is allowed.. * TWM GroupedWindow does provide what you want: Group myriad windows into a GroupedWindow.. and you can have several.. either you implement #configureForEmbedding properly for SystemWindow / #Dialog ... required classes or remove that call and have embedding with top label, - + x buttons.. that will not be right within a tab... its minor work.. * You can use the framework of TabbedPanes I have to get the above.. simpler, without some of the other capabilities the above does provide that includes drag n drop.. not difficult to implement if reqd. * From a code window navigation.. its providing another clean choice.. I have not as yet moved in an optional file manager on the left pane.. that does help many a times. * eclipse is a well understood created by Smalltalkers IDE.. so I pick its simile.. but there is no copy here.. but what fits my use / percieved value beyond. ps: I do love the dance of Morphic..addictive actually, though this is staid corporate moves.. It would be nice to integrate openGL Lumiere, morpho-physics like stuff in a package that shows the potential of doing fancy stuff along with the plain old windowed widgets for the enterprise apps.. code browser : prefer a whole view of the class methods ( collapsible) .. while reviewing and refactoring, rather than mouse clicking/ jumping methods.. looking through . Infact I love the city scape painted from Moose with Lumiere, Lovely visualization, which can make sense for financial apps, to show a complete scape of their accounts/ subaccounts in clean blocks of towers and be hyperlinked to their specific tabular/ notebook of data...! Extend and mix openGL but with stability / crash proof views... it can make a difference/ paradigm shift to apps of the day.. On Fri, Feb 17, 2012 at 12:02 AM, Jimmie Houchin <jlhouchin(a)gmail.com>wrote: > I agree. I value highly many of the abilities our current UI. I would not > want to give up the ability to have multiple browsers open and placed in > certain positions to give me view into code in multiple areas as I edit > whatever I am editing. > > I do agree that we could make improvements and that we haven't arrived at > the ultimate solution. I don't even think anyone knows what that is. > > I don't have a problem with having an IDE-like window featured as desired > for those who want such. You could possibly have a world menu item for IDE > Window, which would open up a new IDE window. You could multiple such > windows. That's one thing I always wished for when developing a Python > project in PyDev (Eclipse) is that I could have multiple IDE windows, one > for each project I am working on. The tabbed interface just gets in my way. > > I would love to see the day that IDEs for other languages are or could be > written in Pharo instead of Java. We could have a better Python, Ruby, ..., > IDE written in Pharo than Eclipse. > > One thing I would find interesting with tabs is if I could have a window > with tabs where I group things that I want in that window. Browsers, > Workspaces, etc. I don't know TWM may provide just that. I haven't had the > time to explore and learn TWM. > > One thing that new users of the Smalltalk IDE need to realize up front is > that our ui is more operating system like than IDE like. We wouldn't want > to limit our OS to a single window and tabs. > > When I develop in Python I have more than one window open. I have PyDev in > one, a REPL in another, GitGui, ... But people unfamiliar with Smalltalk > impose views which just need adjusted or educated. > > For me personally, I feel like I am doing an elegant, graceful dance when > programming in Pharo/Smalltalk. When developing in Python, etc., it feels > like me an my partners are stepping all over each others feet. Little to no > integration, little to no cooperation between tools. > > People who love Eclipse, Emacs, and all there toolchains might feel that > that is their elegant dance. But for me its two left feet. > > Jimmie > > > On 2/16/2012 2:38 AM, Fernando Olivero wrote: > >> Hi, i wanted to comment a bit on the proposed ui. >> >> The problem with this single-window with tab panes, is that it forces >> the user to have a single focus of attention, which produces an >> overhead in navigation for those programming tasks that require >> looking at more than one element at a time. >> >> Thats why i see more value in our current user interface, of course it >> can highly improved... >> >> Fernando >> On Thu, Feb 16, 2012 at 8:57 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> >>> Nice >>> >>> Stef >>> >>> On Feb 16, 2012, at 7:15 AM, S Krish wrote: >>> >>> >>>> >>>> Just this quick n usable prototype.. ? >>>> >>>> Any comments of its utility.. I for one would rather prefer having >>>> everything navigable from one Tabbed Pane.. >>>> >>>> Panes capable of rendering about every window of the basic tools of >>>> Pharo.. workspace, Finder, ScriptManager, possibly Transcript as a console >>>> collapsible as reqd >>>> >>>> Akin to the eclipse but not really that intensively single windowed.. >>>> there are uses for spawning separate windows.. >>>> >>>> <PharoTabbedBrowsers.jpg> >>>> >>> >>> >>> >> >> > > >

Feb. 16, 2012

[Pharo-project] Opening...

by S Krish

http://ie.linkedin.com/jobs/jobs-Smalltalk-Senior-Software-2124837 Just in case I can put it in perspective.. . This is a VA App of about 3 million lines of code.. Ported to Java and now live. The VA work is now to maintain and sustain it till Java can get its handle over all the major implementations over the years ahead. That said it is great base, built over the last 19 years from a Enfin Smalltalk base, comparable to Kapital.. though a different domain that is vast and complex financial market. Fun to master the domain and its implementation therein in Smalltalk. -Skrish

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by Nicolas Passerini

On Thu, Feb 16, 2012 at 4:20 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > It looks interesting, but how this relates to the state issue? > > > It is not directly related to the state issue. Just to different trait models, I think that it would be a nice yet very simple enhancement, to be able add a trait directly to an object at instantiation time istead of always having to create a new class. I apologise if my mail was confusing. However mi little traits extension has also something to say about state. When I do: myObject := (*MyClass with: MyTrait*) new The class of myObject is created dynamically, so I can have MyTrait declaring its required state an then the instance variables are created automatically. It is also a little extension to declaring required methods.

Feb. 16, 2012

Re: [Pharo-project] Traits in PHP

by StÃ©phane Ducasse

On Feb 16, 2012, at 4:35 PM, Nicolas Passerini wrote: > I think it would be very nice to be able to apply a trait directly to an object, without having to create a new class. > This is possible for example in scala: > > val myObject = new MyClass with MyTrait > > I have programmed a simple implementation in Pharo which allows you to do: > > myObject := (MyClass with: MyTrait) new. > > The implementation is only a proof of concept and has some issues that should be addressed before being able to use it in a real program, but I can make it available if someone is interested. > > What do you think about this? I do not think that I want that. Because: what about tools support? I do not see the use case. Now you can do prototypes for fun. Stef

Feb. 16, 2012