- Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo code formatting

by Ihor Mykhalevych

Hello everyone! Does anyone know if there were some changes to the Pharo code formatter after Pharo version 2.0? Best regards, Ihor Mykhalevych

Dec. 27, 2013

Re: [Pharo-users] Is someone working with Log4s?

by dmacq

Hernan, The Visual Smalltalk method is this: currentClassAndMethod ^Association key: self class name asString value: (Processor activeProcess methodAtFrame: 1) selector asString I think the Pharo equivalent would be this: currentClassAndMethod ^Association key: self class name asString value: Processor activeProcess name Donald [|] -- View this message in context: http://forum.world.st/Is-someone-working-with-Log4s-tp4732633p4732750.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 27, 2013

Re: [Pharo-users] Is someone working with Log4s?

by jtuchel＠objektfabrik.de

#currentClassAndMethod is VAST specific. It was added to VAST for log4s, afaik. I am quite sure Donald is interested in hearing about your problems with it. Did you contact him just the other day or some time ago? Joachim Am 27.12.13 10:53, schrieb 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 > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Dec. 27, 2013

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

by Stephan Eggermont

When trying to load Designer in Pharo 3.0 I find uncompilable code in Animations: 'updateCurrentValue: aValue self target ifNil: [^ self]. self target perform: (self property, #:) asSymbol with: aValue.'

Dec. 27, 2013

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