- Pharo-users - lists.pharo.org

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

by HernÃ¡n Morales Durand

Do not have a copy of VAST or VisualSmalltalk now but this could make it: currentClassAndMethod ^Association key: self class name asString value: thisContext method selector HernÃ¡n 2013/12/28 dmacq <dmacq(a)instantiations.com> > What I posted before just gets the name of the process, not the name of the > method that is currently executing. I don't know how to do that off the > top > of my head, but I will look into it this weekend. > > Suggestions welcome. > > Donald [|] > > > > -- > View this message in context: > http://forum.world.st/Is-someone-working-with-Log4s-tp4732633p4732811.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Dec. 28, 2013

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

by Tobias Pape

On 28.12.2013, at 10:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I guess that > > #: should be #â:â That is one way. In this particular case, self property asMutator was the better version, tho. Best -Tobias PS: Just curious, what was the reason to no longer allow #: ? Or, where can I find the respective discussion, just want to lern. > > On 27 Dec 2013, at 19:44, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> 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. 28, 2013

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

by dmacq

What I posted before just gets the name of the process, not the name of the method that is currently executing. I don't know how to do that off the top of my head, but I will look into it this weekend. Suggestions welcome. Donald [|] -- View this message in context: http://forum.world.st/Is-someone-working-with-Log4s-tp4732633p4732811.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 28, 2013

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

by StÃ©phane Ducasse

This is really cool :) I would love to see how we could change the event system used because using thisContext all the time does not work and breaks the idea of not reifying the stack all the time. Once it will be working, it would be really nice to see if we can generate spec specification. Stef > I was successfull in making Designer start in Pharo 3.0 30659, with some help from > Tobias Pape. Tx tobias. > The following changes were needed (compared to what was needed for Pharo 2.0) > - floodfill2:at: is gone from Form. I replaced it with a simple fillColor: > That it had gone missing was not clear from issue 11570 Do you like method with floodFill23 in their name and not invoked at all :)? > - outsetBy: is deprecated and replaced by expandBy: in a lot of places we also cleaned a lot the logic and added MorphMargin to support polymorphic margins. So may be this is beneficial > - (some symbol or string or something else, #:) asSymbol is replaced by ... asMutator > in a lot of places. > - TranslucentColor is replaced by Color > > <PastedGraphic-1.png> > > TextMorph handleInteraction:forEvent: no longer exists, but gives a different problem in Pharo 2 than in 3 > just replacing it by handleInteraction: does not work. That makes a mess of the selection in > theUiTextLineMorphs in the object inspector. That I have no idea. > > Stephan > >

Dec. 28, 2013

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

by ClÃ©ment Bera

Main problems to compile Smalltalk to java bytecode: - there's no context in java. This means our implementation of continuations and exceptions is not valid anymore. This also means we cannot have a debugger with edit-and-continue as we have now. - there's no become:, which is used to keep the system live Basically you can find tricks to still have become: and a live environment/debugger but in this case the Smalltalk created would be super slow. So compiling smalltalk to java is not an easy problem. Now compiling Pharo to the gemstone VM should be possible and not as hard. The complexity depends mostly on how well the gemstome contexts are implemented. 2013/12/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > 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. 28, 2013

Re: [Pharo-users] Pharo code formatting

by StÃ©phane Ducasse

Not much as far as I know. > 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. 28, 2013

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

by StÃ©phane Ducasse

I guess that #: should be #â:â On 27 Dec 2013, at 19:44, Stephan Eggermont <stephan(a)stack.nl> wrote: > 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. 28, 2013

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

by peter yoo

great! "source: (self ui widgetList);" this code line is real solution. before i dont know, where inittilize "source". drag and drop is ok. and look object is ok. but cannot edit object property.(maybe mouse focus event problem) encounter new error then make new thread right? ps. thank you. Stephan Eggermont/StÃ©phane Ducasse

Dec. 28, 2013

Event handling in TextMorphs

by Stephan Eggermont

handleInteraction:fromEvent: no longer exists in TextMorph in Pharo 3.0. Just replacing it by handleInteraction: doesn't do the right thing. What should I be doing instead? Stephan mouseDown: evt evt yellowButtonPressed ifTrue: [ ^ self yellowButtonActivity: evt shiftPressed]. self grabKeyboard. editor ifNotNil: [:e | self handleInteraction: [e mouseDown: evt] fromEvent: evt].

Dec. 28, 2013

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

by Stephan Eggermont

I was successfull in making Designer start in Pharo 3.0 30659, with some help from Tobias Pape. The following changes were needed (compared to what was needed for Pharo 2.0) - floodfill2:at: is gone from Form. I replaced it with a simple fillColor: That it had gone missing was not clear from issue 11570 - outsetBy: is deprecated and replaced by expandBy: in a lot of places - (some symbol or string or something else, #:) asSymbol is replaced by ... asMutator in a lot of places. - TranslucentColor is replaced by Color TextMorph handleInteraction:forEvent: no longer exists, but gives a different problem in Pharo 2 than in 3 just replacing it by handleInteraction: does not work. That makes a mess of the selection in theUiTextLineMorphs in the object inspector. Stephan

Dec. 28, 2013