December 2013 - Pharo-users

Re: [Pharo-users] have a question for morphic Designer in pharo.

by Stephan Eggermont

Peter Yoo wrote: >1. im look monticello now. can look more version now. 28, 30 Interesting. I still cannot see anything newer than .24 in http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository Are you sure that it is exactly the same repository? There is likely to be a different one for designer itself. >2. email to Marcel Taeumel already. but not receive return mail. mabe into spam? Possible, but unlikely. The last days were the worst time of the year to reach someone in Germany. The weeks around christmas (24-26 december) and newyear are family holidays, so it's likely that he doesn't read his mail. He reacted to your stackoverflow post though. >3. latest squeak is cannot use too. squeak 4.1 image(in squeak 4.4 all in one vm) >with morphic designer standard version can use. but class not same(squeak version >and pharo version). im little panic. It should work in the latest squeak image. It is not used enough/doesn't have enough test coverage that all mistakes are immediately noticed, but Marcel fixes bugs that are found. With the quality of issue report you provide the major problem should be his availability/priorities. The next week he's likely to have holidays. >4. im look already. pharo canvas class not same squeak canvas class. >this problem not easy. i try more now. but im newbie user. maybe so hard work. They started as the same, but Pharo has made more radical and drastic clean-ups. Pharo will break existing applications in order to improve things. The advantage is that innovation can be much faster in Pharo, a disadvantage is that applications need to co-evolve. The support for co-evolving is gradually improving, the continuous integration server provided for Pharo contributions gives fast feedback on consequences of changes. Squeak tries to keep compatible with older applications while gradually making everything unloadable. That is a much slower and more difficult approach. Quite a lot of code that was not used was removed. Once in a while we find out that a project uses that code and needs to be reintroduced. Or should be in a separate extension package, or be moved into the using project. The issue you are now running into seems to be the cleaning up of event handling that has taken place in Pharo and not yet or not in the same way in Squeak. A lot of the code deep in the system was very difficult to understand, so yes, this can be difficult work. >5. im look already another UI project(http://uipainter-gsoc.over-blog.com/). >but not handsome(little joke). maybe can then i want use this project. now im trace >another way(for UiItemViewport class. but mouse event is not same to squeak env). Yes, this years GSoC project did not get as far as Marcel's one. And the event handling has changed since Marcel wrote the Designer. Signals was pretty intrusive. UITreeViewPort doesn't seem to correctly set the source of its dragSpec. I tried to change dragDropSpec in UiItemViewPort to dragDropSpec ^ dragDropSpec source: self; yourself That allowed the drag-and-dropping of a lot of the widgets, but created errors where the dragDropSpec was set to nil (Tree widget). Then I looked at where UiItemViewDragDropSpec was used, and found out that the source was not set in UIDesigner initialize. I can do drag and drop of all widgets with self ui widgetList selectionMode: UiViewSingleSelection; dragDropSpec: (UiItemViewDragDropSpec new source: (self ui widgetList); dropEnabled: false; dragTransferType: #widgetClass). So, in all I needed to make the following changes to make the designer work in 20628 after loading development of ConfigurationOfDesigner-mt.24.mcz: UIDesigner>gridForm | form canvas | form := Form extent: 20@20 depth: 32. form floodFill2: (Color gray: 0.98) at: 0@0. canvas := FormCanvas on: form. form pixelValueAt: 0@0 put: (form pixelValueFor: (Color gray: 0.2)). ^ form UIDesigner>initialize super initialize. self ui setupUi: self. self ui prop addPaneSplitters. self selectDefaultModel. self ui centralScroller borderWidth: 0; fillStyle: (BitmapFillStyle fromForm: self gridForm). "BAD: Viewport should not be accessed from the outside." self ui widgetList viewport dragEnabled: true. self ui widgetList selectionMode: UiViewSingleSelection; dragDropSpec: (UiItemViewDragDropSpec new source: (self ui widgetList); dropEnabled: false; dragTransferType: #widgetClass). self ui filterEdit deferEditSignalTime: 300. propertyTable := self ui propertyScroller widget. self connect: self ui filterEdit signal: #textEdited: toSelector: #nameFilter:. self connect: self ui newBtn signal: #clicked: toSelector: #reset. self connect: self ui saveBtn signal: #clicked: toSelector: #save. self connect: self ui openBtn signal: #clicked: toSelector: #load. UIAbstractWidgetModel>initialize super initialize. self updateWidgets. SystemAnnouncer uniqueInstance on: ClassAdded send: #updateWidgets to: self.

Dec. 27, 2013

Re: [Pharo-users] Is there any fundamental technical barrier to compiling to JVM byte codes?

by StÃ©phane Ducasse

On 27 Dec 2013, at 18:21, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: > > <<<From: St?phane Ducasse <stephane.ducasse(a)inria.fr> > > The fun is important. > What we want is well designed and powerful libraries that enabled people. > For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. > Now I do not understand why people develop their own vm instead of joining forces. > Doing in the long term something and finishing a task are the most difficult things. > Stef > á§ > >>> > > Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all. > > I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk. I was not aware of that one :) So this means that we have gravel, redline and Rtalk. http://i.cmpnet.com/ddj/images/mediacenter/jvmlanguagesummit/2011_Roos_Rtal… I understand the motivation behind Rtalk and this is cool that they succeeded. Now what people often forget is that behind the technical challenges you have the libraries and the boring but important work of building greta frameworks. > I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes. > > Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off. I do not know because the problem is that on such topics the devil are in the details. Now what is important is having a bootstrap and clean test covered code base because we could also see how to deploy a gemstone vm or other platform in the future. > I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier. > > Cheers > Andy > >

Dec. 27, 2013

Re: [Pharo-users] Is there any fundamental technical barrier to compiling to JVM byte codes?

by Andy Burnett

<<<From: St?phane Ducasse <stephane.ducasse(a)inria.fr> The fun is important. What we want is well designed and powerful libraries that enabled people. For the JVM question: it is a question of resources + the fact that jvm do not really support well some key smalltalk operations. Now I do not understand why people develop their own vm instead of joining forces. Doing in the long term something and finishing a task are the most difficult things. Stef á§ >>> Thank you to everyone for your comments. I am replying to Stephane's email, just as a catch all. I am curious to know more about the limitations in the JVM. My thinking was sparked - in part - by Mark Roos's work on RTalk. I realised, after my post, that he had actually worked the other way around, i.e. I think he built a Digitalk bytecode layer on top of the JVM, rather than compiling to JVM bytecodes. Either way, what I was vaguely wondering about was how difficult it would be to have a 'compile to JVM' option in Pharo. I could probably live - quite happily - developing in 'real' Pharo, and then deploying an app to e.g. Google App Engine, as a compiled Jar. Obviously, it would be much better to retain all the dynamism of a true Smalltalk environment even when the app has been deployed, but it it gave simple hosting, and scaling, it might be a reasonable trade off. I agree with Stephane, it would be great for people to join forces around a vm. Would make like so much easier. Cheers Andy > >

Dec. 27, 2013

Re: [Pharo-users] [Seaside-dev] [Seaside] [ANN] Seaside 3.1 and 3.0.10 release

by Sven Van Caekenberghe

On 27 Dec 2013, at 11:57, Philippe Marschall <philippe.marschall(a)gmail.com> wrote: > We are pleased to announce the releases of Seaside 3.1 and 3.0.10. That is great news. Congratulations and thank you to the whole team. > Seaside 3.1 is a feature release and contains a range of improvements > and fixes from a variety of people. Seaside 3.0.10 is a minor release > of Seaside 3.0 containing only a single bug fix. > > The changes can be view here: > http://code.google.com/p/seaside/wiki/Seaside310Changelog and here: > http://code.google.com/p/seaside/wiki/Seaside3010Changelog > > A one-click image is available here: > http://www.seaside.st/distributions/Seaside-3.1-OneClick.zip and here: > http://www.seaside.st/distributions/Seaside-3.0.10-OneClick.zip > Mavericks user beware the one click images are not signed. Itâs a pity those are still based on Pharo 1.3, which is becoming quite old now. > Seaside's Metacello configuration has been updated, so Seaside 3.1 can > be loaded into Pharo with: > > Gofer new > url:'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; > package: 'ConfigurationOfSeaside3'; > load. > ((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load. Images of Pharo 2.0 or 3.0 with Seaside preloaded can be found here: https://ci.inria.fr/pharo-contribution/job/Seaside/ Sven > For more control over what gets loaded check out the class comment of > ConfigurationOfSeaside3 that lists the supported groups. > > We would like to thank everybody who contributed to these releases. > > The Seaside Team > _______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Dec. 27, 2013

[ANN] Seaside 3.1 and 3.0.10 release

by Torsten Bergmann

Details here: http://lists.squeakfoundation.org/pipermail/seaside/2013-December/030350.ht…

Dec. 27, 2013

Re: [Pharo-users] Image starts and closes automatically

by HernÃ¡n Morales Durand

Next time put information about your environment, which OS, which Image, which VM, because people cannot help with such missing important information. People cannot guess what Pharo are you using. So any replies would be wasteful. 2013/12/27 Esteban A. Maringolo <emaringolo(a)gmail.com> > Esteban Lorenzano wrote: > > do you have a PharoDebug.log? > > this things are usually related to an open socket not well handledâ¦ > > It might be, the last thing I did before saving was to close the Zinc > server. But it never failed before. > > If there was a PharoDebug.log I didn't see it. (see next) > > 2013/12/27 phil(a)highoctane.be <phil(a)highoctane.be>: > > Time for some Oz magic... > > > > Got this kind of thing as well a couple times. > > Sometimes I rely too much on the image stability. And when it fails, it > hurts. > > Fortunately I saved all the Monticello packages before saving and > closing the image. So I was able to restore it quickly. > > I need to implement a private CI ASAP. > > > Regards! > >

Dec. 27, 2013

Re: [Pharo-users] Image starts and closes automatically

by Esteban A. Maringolo

Esteban Lorenzano wrote: > do you have a PharoDebug.log? > this things are usually related to an open socket not well handledâ¦ It might be, the last thing I did before saving was to close the Zinc server. But it never failed before. If there was a PharoDebug.log I didn't see it. (see next) 2013/12/27 phil(a)highoctane.be <phil(a)highoctane.be>: > Time for some Oz magic... > > Got this kind of thing as well a couple times. Sometimes I rely too much on the image stability. And when it fails, it hurts. Fortunately I saved all the Monticello packages before saving and closing the image. So I was able to restore it quickly. I need to implement a private CI ASAP. Regards!

Dec. 27, 2013

Is someone working with Log4s?

by HernÃ¡n Morales Durand

Because there is a missing method (#currentClassAndMethod) and author didn't replied. Maybe I am using it wrong EsLogManager runForever: '[log4s] debugEnabled=''true'' quietMode=''false'' globalLevel=''All'' ;runForever=() ;runForever=''75'', ''7'' dailyRollingFileAppender=''TestDailyRollingFileAppender'', ''root'', ''dallyRollingFileTopOfDay.log'', ''false'', ''All'', '''', ''%-15d [dailyRollingFileAppenderTopOfDay] %-16m'', ''true'', ''topOfDay'' ' Cheers, HernÃ¡n

Dec. 27, 2013

Re: [Pharo-users] have a question for morphic Designer in pharo.

by StÃ©phane Ducasse

On 27 Dec 2013, at 01:41, peter yoo <onionmixer(a)gmail.com> wrote: > 1. im look monticello now. can look more version now. 28, 30 > > 2. email to Marcel Taeumel already. but not receive return mail. mabe into spam? > > 3. latest squeak is cannot use too. squeak 4.1 image(in squeak 4.4 all in one vm) with morphic designer standard version can use. but class not same(squeak version and pharo version). im little panic. No donât I think that you are doing a really good job but this is difficult when the platform changes. > > 4. im look already. pharo canvas class not same squeak canvas class. this problem not easy. i try more now. but im newbie user. maybe so hard work. Yes this is hard and Iâm sorry that you have to face this situation. > 5. im look already another UI project(http://uipainter-gsoc.over-blog.com/). but not handsome(little joke). maybe can then i want use this project. now im trace another way(for UiItemViewport class. but mouse event is not same to squeak env). What could be interesting is to port some widgets to pharo and learn how we can turn the event into announcement. then only have one pane and one widget to start and learn. > > thank you your answer. stephan !!!

Dec. 27, 2013

Re: [Pharo-users] Image starts and closes automatically

by phil＠highoctane.be

Time for some Oz magic... Got this kind of thing as well a couple times. Phil On Fri, Dec 27, 2013 at 7:40 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > do you have a PharoDebug.log? > > this things are usually related to an open socket not well handledâ¦ > > On 26 Dec 2013, at 22:04, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > OS > VM version > Image version > ? > > > > 2013/12/26 Esteban A. Maringolo <emaringolo(a)gmail.com> > >> Help please! >> >> I closed my image with "Save & Quit" and now everytime I try to open >> it it opens the window but closes immediately. No error or anything >> else. >> >> It is... the image opens, I can see a couple of workspaces. But then >> quits. >> >> I'm using: >> /pharo-ui myapp.image >> >> >> I also tried to start it using my startup script, and the same thing >> happens. >> >> Any idea? >> >> Regards. >> >> >> Esteban A. Maringolo >> >> > >

Dec. 27, 2013