- Pharo-dev - lists.pharo.org

Re: [Pharo-project] what's happened to the blogger group?

by Adrian Lienhard

On Mar 6, 2011, at 12:09 , Geert Claes wrote: > Francois has posted another nice weekly summary on his blog at > http://articles.tulipemoutarde.be For visibility I thought Dmitri and > Farncois were to be given access to the Pharo website so they can post on > the Pharo news/blg area too? Yes. I've created an account on our website for Dmitri. And I'll gladly create one for Farncois too (or anybody else who would like to take responsibility for posting news to the website). Cheers, Adrian

March 6, 2011

[Pharo-project] Issue 3786 in pharo: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3786 by jvdsa...(a)gmail.com: Debug test .. (d) menu option in OBSystenBrowser gives SystemGuardException in Pharo 1.2 http://code.google.com/p/pharo/issues/detail?id=3786 Pharo image: Pharo Pharo core version: Pharo1.2rc2 update #12340 (Build #169) Virtual machine used: CogVM on OSX Class browser used: OBSystemDebugger Steps to reproduce: 1. Select any test method in the browser 2. Choose " Debug test ..." from the methods context menu Attachments: PharoDebug.log 28.1 KB

March 6, 2011

Re: [Pharo-project] what's happened to the blogger group?

by Geert Claes

Francois has posted another nice weekly summary on his blog at http://articles.tulipemoutarde.be For visibility I thought Dmitri and Farncois were to be given access to the Pharo website so they can post on the Pharo news/blg area too? -- View this message in context: http://forum.world.st/what-s-happened-to-the-blogger-group-tp3337416p333749… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 6, 2011

Re: [Pharo-project] defaultBorderColor and defaultBorderStyle

by StÃ©phane Ducasse

Hi doug Many things should be fixed it you want to see something happening faster, join :) provide a change. Stef On Mar 6, 2011, at 10:33 AM, DougEdmunds wrote: > Styles ( such as #inset, #raised, etc) should be separated out from > non-intuitive "defaultBorderColor" methods and consistently replaced with > defaultBorderStyle. > > For example, > Slider>>defaultBorderColor is #inset. > > Slider>>defaultBorderStyle would be much clearer. > > > > > -- > View this message in context: http://forum.world.st/defaultBorderColor-and-defaultBorderStyle-tp3337429p3… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 6, 2011

Re: [Pharo-project] Binding data to controls widgets in CLFramework

by StÃ©phane Ducasse

On Mar 6, 2011, at 11:20 AM, nullPointer wrote: > IÂ´m not sure understand good all message, Stephane. > > I believe the integration is easy from CLFramework to Pharo and reverse and > really donÂ´t need changes: > > The mechanism than widgets launch events is the same of system, the trigger > mechanism. I only encapsulate that basic functionality on a TCLPublishEvents > trait, for send rich event arguments in some cases, and force the handler of > event is always of two parameters, the sender of event and the information > of event, but the functionality for launch the events is the same of system. > > In some types of control usability I implemented news widgets: listview, > button, treeview, statusbar, grid, splitterpanel and tablepanel. The others > widgets be Polymorphs sons. Really a widget in CLFramework is a normal morph > implementing the trait TCLControl, for only basic properties (#location, > #style ,#tabIndex, #text ..... ). Exists others traits: TCLCollectionControl > for list type widgets, TCLContainerControl for panels, > TCLObservableCollectionListener for controls than need listen a > ObservableCollection instance etc The reason of that news widgets is the > velocity, clean methods interface and inexistence like basic and huge needed > grid. good to know we should have a look at your widgets when we will do a pass one all the widgets. First we should clean polymorph. > Really Pharo has been repeat updated and I didnÂ´t have problems. I believe > than unique dependence of Pharo is Polymorph. The unique problem I have in > last step is the imposibility of save on a external file the preferences. In > Pharo 1.1 that works. I did use that functionality for my Deployment tool > mechanism. > > > Clean the system and remove useless code from system is a great idea, but in > GUI I believe Pharo needs some enhancements: > > Â·Another more fast way for render the morphs, the GUI still slow compared > another languages. yes this is why somebody should look at SimpleMorphic and this is why we should clean Morph. > Â·Posibility of open independent windows (integrate ffenestri on Core??). Not easy it requires a large effort. I would love that but at least 2/3 months of work. + probably VM changes. > Â·Embed a pharo world on a browser for have the same application on the > desktop or the web, ala Silverlight (something I did see lasts days). > > Â·Basic widgets like a good and fast grid (not like my shit grid) for upset, > group, filter and edit data. I believe the difference in some cases for > create enterprise applications or not create will be widgets like that. Ok > Â·Bindings implementation on widgets ala WPF/XAML. The link of widget value > and data model must be with bindings mechanism, not with simple events. > > Â·A GUI designer. I believe the Morphic designer is the good way. but this will need to again integrate other widgets and event model. > > > I wait understood the question. yes > > Regards. > > > > > > -- > View this message in context: http://forum.world.st/Binding-data-to-controls-widgets-in-CLFramework-tp333… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by Norbert Hartl

well, I provided a fix already. And it seems that 3 mails to the list and the mentioning withing this mail does not make it visible. It needs an integration step or just to load the newest ImageForDevelopers How to tell? Norbert On 06.03.2011, at 08:45, laurent laffont wrote: > testUndeclared is failing because of DEVImageWorkspaces class>>openGettingStartedWorkspace and #openExternalProjectWorkspace > > (I can provide a fix later). > > Laurent > > > On Sun, Mar 6, 2011 at 8:32 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > If I download Pharo-1.2-AfterRunningTests.zip #168 and try only Tests.Release.ReleaseTest.testUndeclared fails on my machine. > > And I'm still not able to reproduce results of Hudson. If I run all tests I have far more failures and errors ( http://forum.world.st/Re-1-2-one-click-OSX-and-Linux-more-failing-tests-tp3… ) > > Laurent > > > On Sat, Mar 5, 2011 at 10:55 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Today I had a look at the hudson server. For pharo 1.2 dev there was only one bug left. So I took a look and fixed it > > http://code.google.com/p/pharo/issues/detail?id=3784 > > Two hours later there was a new build in hudson and then there were three bugs (one of these is the fixed one which hasn't been integrated). How can this happen? > > Norbert > >

March 6, 2011

Re: [Pharo-project] Binding data to controls widgets in CLFramework

by nullPointer

IÂ´m not sure understand good all message, Stephane. I believe the integration is easy from CLFramework to Pharo and reverse and really donÂ´t need changes: The mechanism than widgets launch events is the same of system, the trigger mechanism. I only encapsulate that basic functionality on a TCLPublishEvents trait, for send rich event arguments in some cases, and force the handler of event is always of two parameters, the sender of event and the information of event, but the functionality for launch the events is the same of system. In some types of control usability I implemented news widgets: listview, button, treeview, statusbar, grid, splitterpanel and tablepanel. The others widgets be Polymorphs sons. Really a widget in CLFramework is a normal morph implementing the trait TCLControl, for only basic properties (#location, #style ,#tabIndex, #text ..... ). Exists others traits: TCLCollectionControl for list type widgets, TCLContainerControl for panels, TCLObservableCollectionListener for controls than need listen a ObservableCollection instance etc The reason of that news widgets is the velocity, clean methods interface and inexistence like basic and huge needed grid. Really Pharo has been repeat updated and I didnÂ´t have problems. I believe than unique dependence of Pharo is Polymorph. The unique problem I have in last step is the imposibility of save on a external file the preferences. In Pharo 1.1 that works. I did use that functionality for my Deployment tool mechanism. Clean the system and remove useless code from system is a great idea, but in GUI I believe Pharo needs some enhancements: Â·Another more fast way for render the morphs, the GUI still slow compared another languages. Â·Posibility of open independent windows (integrate ffenestri on Core??). Â·Embed a pharo world on a browser for have the same application on the desktop or the web, ala Silverlight (something I did see lasts days). Â·Basic widgets like a good and fast grid (not like my shit grid) for upset, group, filter and edit data. I believe the difference in some cases for create enterprise applications or not create will be widgets like that. Â·Bindings implementation on widgets ala WPF/XAML. The link of widget value and data model must be with bindings mechanism, not with simple events. Â·A GUI designer. I believe the Morphic designer is the good way. I wait understood the question. Regards. -- View this message in context: http://forum.world.st/Binding-data-to-controls-widgets-in-CLFramework-tp333… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 6, 2011

[Pharo-project] Add to website Re: [Pharo-users] Pharo-project weekly summary #4

by Mariano Martinez Peck

Hi. These summaries are awesome. Can we link to them somehow from pharo web site? Maybe we can have two sections under news: one with what is now (the blog) and another one with this summaries (just a text explaining what it is and a link to the original website) cheers mariano On Sun, Mar 6, 2011 at 10:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes! > > On Mar 5, 2011, at 10:16 PM, Tudor Girba wrote: > > > Thanks :) > > > > Doru > > > > > > On 5 Mar 2011, at 22:06, Francois Stephany wrote: > > > >> Hi guys, > >> > >> The summary for this week is out. Please comment if I said something > stupid or forgot something. > >> > >> http://articles.tulipemoutarde.be/pharo-mailing-list-weekly-summary-4 > >> > >> See you next week ;) > >> > > > > -- > > www.tudorgirba.com > > > > "From an abstract enough point of view, any two things are similar." > > > > > > > > > > >

March 6, 2011

[Pharo-project] defaultBorderColor and defaultBorderStyle

by DougEdmunds

Styles ( such as #inset, #raised, etc) should be separated out from non-intuitive "defaultBorderColor" methods and consistently replaced with defaultBorderStyle. For example, Slider>>defaultBorderColor is #inset. Slider>>defaultBorderStyle would be much clearer. -- View this message in context: http://forum.world.st/defaultBorderColor-and-defaultBorderStyle-tp3337429p3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 6, 2011

Re: [Pharo-project] Pharo 1.2 and test failures

by Marcus Denker

On Mar 6, 2011, at 10:00 AM, StÃ©phane Ducasse wrote: > We should remove the tests only crashing on the server for now. > It's not that simple... a test started failing just yesterday. So I think the problem is that we are not loading a *fixed* set of versions, but a changed one. e.g. someone commits a new version of a project --> it's loaded in 1.2 We need to change that. Especially considering that we want to build 1.3, too. (we never build a 1.3 Full image...). And there is 1.1, too, where the loaded packages seem to change depending on the moon, or something... All in all, maybe we should re-think if how we do the full image is sustainable? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 6, 2011