March 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Composing UI layout question

by Igor Stasenko

Hi folks, suppose you having a visual UI editing tool, where you can place morphs/controls and define their position(s). I have a model in mind, where coordinates can be defined by formal description, i.e. morph left: morph parent left + some offset morph width: morph parent width / 2 etc. but i wonder, in what way such relations can be represented by UI editor/design tool. I want that user could easily specify following: suppose i placing a button in form, and say that its corner (bottom/right) should be aligned to its parent corner, with some negative offset (-5 @ -5). And button width/height should be calculated by taking a button label text width & height. So, user by specifying two ordinates - corner and width & height, is fully describing a button visual layout. The problem is that button's label is submorph, and i not sure how to formally encode such relation i.e. parent width & height (or any other parent coordinate) depends on its submorph's fixed width/height. -- Best regards, Igor Stasenko AKA sig.

March 19, 2009

Re: [Pharo-project] Drawing graphics with OB

by David RÃ¶thlisberger

Hi Alex, > Each OBNode understand the message definition. In the first version of > OB, this definition method is supposed to return an instance of > OBDefinition or one of its subclass. > I saw a way to have a graphical object instead of the text pane. What > is the trick to achieve this? What I did is to use OBClosableDefinitionPanel that has an #exchangeContentWith: aMorph method where you can pass any morph that gets displayed instead of the text that is usually there. We could extend that to be able to also use "visualization definitions" directly in OBNode, but I haven't yet done this. The visualizations I added get displayed on the execution of a command, by default there is always a text definition shown that can get exchanged with a visualization at runtime. David

March 19, 2009

[Pharo-project] Fwd: [ANN] 10254

by StÃ©phane Ducasse

Issue 655: Overlapping Graphics on World do not Properly Repaint Issue 658: Preferences resetHaloSpecifications Issue 664: unimplemented errorCantGoBack Closed 665 now we will focus on the closures. Stef

March 19, 2009

Re: [Pharo-project] Font and OB

by Lukas Renggli

There are various examples for that in OB-Standard and OB-Refactory. Have a look at OBLimitProtocolFilter>>#displayString:forNode: or OBRescueFilter>>#displayString:forParent:child: or ORLintResultFilter>>#displayString: forNode:, ... Lukas On Thu, Mar 19, 2009 at 9:30 AM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > A further question on OB. How can I change the font of a list. Having > bold or italic menu entries for example. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 19, 2009

[Pharo-project] Font and OB

by Alexandre Bergel

A further question on OB. How can I change the font of a list. Having bold or italic menu entries for example. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 19, 2009

[Pharo-project] Drawing graphics with OB

by Alexandre Bergel

Hi David and others, Each OBNode understand the message definition. In the first version of OB, this definition method is supposed to return an instance of OBDefinition or one of its subclass. I saw a way to have a graphical object instead of the text pane. What is the trick to achieve this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 19, 2009

Re: [Pharo-project] Condense Changes error

by Damien Cassou

On Wed, Mar 18, 2009 at 3:25 PM, John Toohey <johnptoohey(a)gmail.com> wrote: > Just downloaded the latest image, and tried to install the latest > Seaside build (2.9-a3), and I get a MNU #resetMIMEDatabase error > again. Not sure what my options are now. Is it possible to condense > the changeset in another manner? You have to use the latest KomHttpServer and KomHttpServices in the squeaksource repository. -- Damien Cassou http://damiencassou.seasidehosting.st

March 19, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Dale Henrichs

----- "Michael van der Gulik" <mikevdg(a)gmail.com> wrote: | If you want to use multiple CPU cores, I believe that ST/X and | Gemstone both | do this. I haven't tried though. | | Smalltalk/X: http://www.exept.de/ | Gemstone: http://seaside.gemstone.com/ | | Gulik. GemStone allows you to spread the work across multiple machines as well as multiple cores on a single machine. State is shared on transaction boundaries, which has its advantages and disadvantages... Dale

March 18, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Michael van der Gulik

On Thu, Mar 19, 2009 at 1:16 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/3/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Hi all > > > > I found this email really interesting. > > Especially the concurrent aspects. > > Clearly some nice research projects in perspective. > > Also the immutability bit supports would be great. > > > > I hear the magic word 'concurrency' .. :) > With green threading model we have a kind of concurrency on a language > level.. > except that its not scaling on to multiple native threads. > There were a lot of discussion around native threading support and > everyone agrees that less sharing means less problems. > From this point, running separate object memory per native thread seem > most perspective way. > Running single object memory on multiple native threads opens a can of > worms. And the complexity of VM implementation will be overwhelming. > If you want to use multiple CPU cores, I believe that ST/X and Gemstone both do this. I haven't tried though. Smalltalk/X: http://www.exept.de/ Gemstone: http://seaside.gemstone.com/ Gulik. -- http://gulik.pbwiki.com/

March 18, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Igor Stasenko

2009/3/18 Antony Blakey <antony.blakey(a)gmail.com>: > > On 18/03/2009, at 10:46 PM, Igor Stasenko wrote: > >> I hear the magic word 'concurrency' .. :) >> With green threading model we have a kind of concurrency on a >> language level.. >> except that its not scaling on to multiple native threads. > > The Erlang/Scala/Clojure concurrency models are applicable to a green > threads model. Concurrency is difficult even with green threads. > Its not too difficult, i'd say. It is completely different from single threaded approach, so different, that to exploit its benefits you have to deeply rewrite your application(s). And smalltalk is not alone with this problem - many other imperative languages offer nothing in this regard and devs not in a position to get a full grasp of concurrency - they have to reinvent their own wheel first. >> There were a lot of discussion around native threading support and >> everyone agrees that less sharing means less problems. > > Which is what such concurrency models provide. I suggest gaining some > familiarity with Erlang/Scala/Clojure to protect against Smalltalk- > insularity. Yes, i familiar with couple of those. But the problem is, that their employ own concurrency models, which can't be applied directly/blindly to smalltalk. There is always a lot of different nuances who bury the whole idea in the end :) > >> From this point, running separate object memory per native thread seem >> most perspective way. > > That ties you to only doing large grained concurrency. What if I want > thousands of threads, automatically distributed over the available > hardware? Are you assuming that concurrency is limited to the number > of running images, and each image is strictly single threaded? In fact you need about 2 * number of cores native threads to have a fully loaded workstation. There is no need to allocate separate native thread for each smalltalk process. All you need is a scheduler which distributing the load between fixed set of native threads. > Concurrency is useful at many different levels of granularity. Using > multiple images requires you to use one method for dealing with per- > image concurrency (and currently those mechanisms aren't great) and > another when considering multiple threads. And what about the tools to > make debugging, profiling, deployment, management etc work over these > multi-image systems? That might be more work than just biting the > bullet and providing scalable concurrency within the image. > You right, but look at bright side: once you implement a remote debugging tool , you can use it for any image located anywhere. And remote debugging is a must for any development environment which claims to be mature one :) >> Running single object memory on multiple native threads opens a can of >> worms. And the complexity of VM implementation will be overwhelming. > > Not neccessarily. There may well be legacy issues related to specific > VMs and images, but the problem itself is not overwhelming. If it were > you wouldn't have the JVM or CLR. > > This argument is exactly what I meant when I wrote: > >> If this were the "good old days"(TM) I'm sure someone would be >> working on decent concurrency support for Smalltalk. Using multiple >> images is one approach, but not one that I like - it seems (IMHO) to >> be a reaction to the lack of resources to do something better. > > I would prefer to tackle this problem and do something worthy of > Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the > multi-image model is actually a good and principled decision - but > it's not, it's surrender. > If you familiar with Squeak codebase, there are little applications who tend to care about concurrency. Introducing a native concurrency is pointless without reshaping everything in Squeak from down to up, otherwise you will have no real gains. Having a VM which supports concurrency (GC, foreign calls e.t.c) is about 20% of overall job or less. I don't see how such huge amount of work could be done on a free-time basis. To make it possible, you need a team of dedicated people hired to do the job. So, it is a surrender - but objective one. If someone invest enough money to smalltalk systems it can easily match the JVM/CLR mates. > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > In anything at all, perfection is finally attained not when there is > no longer anything to add, but when there is no longer anything to > take away. > Â -- Antoine de Saint-Exupery > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 18, 2009