- Pharo-dev - lists.pharo.org

[Pharo-project] A new GUI visual designer

by nullPointer

https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… It really looks very professional. I made a user interface builder for Polymorph, which I left because I was too complicated for me. I hope that now someone more knowledgeable can really necessary to implement a tool for Squeak / Pharo as a visual designer user interfaces. Regards -- View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3067111.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 1, 2010

Re: [Pharo-project] Issue 3366 in pharo: CommandHistory Deprecated in 1.2

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3366 by aplantec: CommandHistory Deprecated in 1.2 http://code.google.com/p/pharo/issues/detail?id=3366 In InBox SLICE-Issue-3366-CommandHistory-Deprecated-in-12

Dec. 1, 2010

Re: [Pharo-project] Squeaksource down

by Alexander LazareviÄ

2010/12/1 Marcus Denker <marcus.denker(a)inria.fr> > It's up again. > Thanks! Alex

Dec. 1, 2010

Re: [Pharo-project] Squeaksource down

by Marcus Denker

On Dec 1, 2010, at 8:16 AM, Alexander LazareviÄ wrote: > http://downforeveryoneorjustme.com/www.squeaksource.com It's up again. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 1, 2010

[Pharo-project] Issue 3366 in pharo: CommandHistory Deprecated in 1.2

by pharo＠googlecode.com

Status: Accepted Owner: aplantec Labels: Milestone-1.2 New issue 3366 by aplantec: CommandHistory Deprecated in 1.2 http://code.google.com/p/pharo/issues/detail?id=3366 Since we have UndoManager now.

Dec. 1, 2010

[Pharo-project] Squeaksource down

by Alexander LazareviÄ

http://downforeveryoneorjustme.com/www.squeaksource.com

Dec. 1, 2010

Re: [Pharo-project] OSProcess update (was: [OSProcess] Proposal for Pharo 1.2 compatibility)

by Schwab,Wilhelm K

Dave, Does that mean that PipeableOSProcess can load w/o MVC support? That would be great! You've just reminded me that there is a Windows plugin - for a long time, I thought it was necessary to use ProcessWrapper there. I don't have much need for piping on Windows, but one never knows when it might surface again. Is there a binary for the plugin? I find the Linux VM wanting in diagnostic feedback, so I end up hacking and building it from source, but the Windows VM seems to just work as-is; I have not needed to build it for a long time. In fairness, I don't ask much of Windows these days, but I do need to target it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Tuesday, November 30, 2010 9:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] OSProcess update (was: [OSProcess] Proposal for Pharo 1.2 compatibility) To follow up on this, I have now updated both OSProcess and CommandShell to work on Pharo 1.2. I have not yet had a chance to look at the Metacello configurations, but loading the latest versions of OSProcess and CommandShell, and CommandShellPharo from SqueakSource will give the correct configurations. For CommandShell, ignore the MVC warnings on load, or you can load the individual sub-packages from SqueakSource and leave out CommandShell-MVC. The separate CommandShellPharo package in SqS/CommandShell provides world menu registration for opening a command shell morph on Pharo (open a new command shell morph with world -> Tools -> Command shell). This is in its own package because of the use of pragmas for menu registration, which cannot be loaded into some other Squeak images (e.g. Squeak 3.8 and earlier). I note that on Pharo: TextStyle named: 'DefaultFixedTextStyle' ==> a TextStyle Accuny12(FontSet) Which seems to be a proportional font rather than fixed, so the font in a CommandShell window is not as nice as it should be. OSProcess and CommandShell test suites are green on Squeak/Unix VM, but a bit flakey when I run them on Pharo. Issues are timing related, and I cannot say if they are issues in Pharo, CommandShell, or maybe just the way I wrote the tests. But for general use, everything seems to be working now. When running on Cog, you should expect #forkSqueak to fail, but it will no longer crash the VM as in earlier OSProcess versions. However, #forkSqueak is used extensively in the unit tests for various multiprocessing test setups, which means that the test suites will not run properly. That said, most of the rest of OSProcess and CommandShell should work on Cog. Most things should work on a Mac VM, although I cannot personally verify. Windows support is incomplete and the plugin is not widely available. Dave

Dec. 1, 2010

[Pharo-project] OSProcess update (was: [OSProcess] Proposal for Pharo 1.2 compatibility)

by David T. Lewis

To follow up on this, I have now updated both OSProcess and CommandShell to work on Pharo 1.2. I have not yet had a chance to look at the Metacello configurations, but loading the latest versions of OSProcess and CommandShell, and CommandShellPharo from SqueakSource will give the correct configurations. For CommandShell, ignore the MVC warnings on load, or you can load the individual sub-packages from SqueakSource and leave out CommandShell-MVC. The separate CommandShellPharo package in SqS/CommandShell provides world menu registration for opening a command shell morph on Pharo (open a new command shell morph with world -> Tools -> Command shell). This is in its own package because of the use of pragmas for menu registration, which cannot be loaded into some other Squeak images (e.g. Squeak 3.8 and earlier). I note that on Pharo: TextStyle named: 'DefaultFixedTextStyle' ==> a TextStyle Accuny12(FontSet) Which seems to be a proportional font rather than fixed, so the font in a CommandShell window is not as nice as it should be. OSProcess and CommandShell test suites are green on Squeak/Unix VM, but a bit flakey when I run them on Pharo. Issues are timing related, and I cannot say if they are issues in Pharo, CommandShell, or maybe just the way I wrote the tests. But for general use, everything seems to be working now. When running on Cog, you should expect #forkSqueak to fail, but it will no longer crash the VM as in earlier OSProcess versions. However, #forkSqueak is used extensively in the unit tests for various multiprocessing test setups, which means that the test suites will not run properly. That said, most of the rest of OSProcess and CommandShell should work on Cog. Most things should work on a Mac VM, although I cannot personally verify. Windows support is incomplete and the plugin is not widely available. Dave On Fri, Sep 03, 2010 at 04:17:05PM -0400, David T. Lewis wrote: > On Fri, Sep 03, 2010 at 08:57:55PM +0200, St?phane Ducasse wrote: > > Hi david > > > > I think that you should wait. 1.1 is stable and out. > > Thanks Stef, good advice, that's what I will do. > > Dave > > > > 1.2 is in flux. When 1.2 gets in beta this will be time to settle down things. > > Cyrille I know why you want 1.2 version else you cannot build a hudson working solution > > to run top of the edge version. Now I will do the changes suggested by henrik to get a backward compatible version. > > I suggest to use metacello to control version now I understand that people want to avoid branching > > now it means that we (the people working on the unstable stream may lack tools but this is ok). > > > > Stef > > > > On Sep 3, 2010, at 6:30 PM, David T. Lewis wrote: > > > > > On Fri, Sep 03, 2010 at 01:03:31PM +0200, Cyrille Delaunay wrote: > > >> Hello, > > >> > > >> I would suggest to replace the two methods > > >> -------------------------------------------------------------- > > >> OSPRocess class >> platformName > > >> "After Squeak version 3.6, #platformName was moved to SmalltalkImage " > > >> > > >> ^ ((Smalltalk classNamed: 'SmalltalkImage') > > >> ifNil: [^ Smalltalk platformName]) current platformName > > >> > > >> OSPRocess class >> osVersion > > >> "After Squeak version 3.6, #osVersion was moved to SmalltalkImage " > > >> > > >> ^ ((Smalltalk classNamed: 'SmalltalkImage') > > >> ifNil: [^ Smalltalk osVersion]) current osVersion > > >> > > >> -------------------------------------------------------------- > > >> by: > > >> ------------------------------------------------------------- > > >> OSProcess class >> platformName > > >> ^ ((Smalltalk classNamed: 'OSPlatform') > > >> ifNil: [ > > >> (Smalltalk classNamed: 'SmalltalkImage') current > > >> ifNil: [^ Smalltalk platformName]]) platformName > > >> > > >> OSProcess class >> osVersion > > >> ^ ((Smalltalk classNamed: 'OSPlatform') > > >> ifNil: [ > > >> (Smalltalk classNamed: 'SmalltalkImage') current > > >> ifNil: [^ Smalltalk osVersion]]) osVersion > > >> ------------------------------------------------------------ > > >> > > >> to avoid deprecation messages when using it in Pharo 1.2. Does it looks > > >> good? I'm not able to publish on the squeaksource repository > > > > > > This failed on the first Pharo image that I tried, which was a > > > Pharo-1.1-11400-rc2dev10.06.1 image. I think this is the subject > > > of some recent refactoring, so I'm not sure if it's safe to use > > > it yet (will somebody try to load OSProcess in one of the images > > > that has OSPlatform but that does not yet have the #platformName > > > refactoring?). > > > > > > I expect that there are several versions of Pharo in general > > > circulation, so can someone give me some guidance as to whether > > > it is safe to code for "OSPlatform current platformName" as the > > > expected idiom on Pharo, or should we wait a while and live with > > > the deprecation warnings? > > > > > > Thanks, > > > > > > Dave > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 1, 2010

Re: [Pharo-project] [squeak-dev] Web Services - SoapOpera problems

by GermÃ¡n Arduino

I agree, we must improve soap support. May be when I end with xmlrpc have a bit of time... 2010/11/30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks for reporting that. > Indeed we should improve on that level. > > Stef > > On Nov 30, 2010, at 7:47 PM, CÃ©drick BÃ©ler wrote: > >> Hi all, >> >> I'd like to try some webservice experiments. I loaded the last version of >> SoapOpera but then, I struggled a lot and I still can't make it work. >> >> First, I needed authentication and I didn't found how to do that in SOAP. >> I managed to make it work by hacking Kom. >> Does someone knows how to do that properly or if it's not possible? >> >> Second, I just can't make it work (whereas I can in PHP and it's dead >> simple :( with SoapClient). I have an error message saying that the >> interface is not known... After investigating a bit, I think that the >> problem is there is no "interpretation" of the wsdl file that describe the >> set of services. >> >> Can people confirm if I'm wrong or not ? >> What's the current state of SoapOpera development ? Are there alternatives >> ? >> >> TIA >> >> ps: in PHP >> >> $client = new SoapClient($WSDL, array('login'=> $LOGIN,'password'=> >> $PASS)); >> $client->TDOptionsPromotion( "whatever parameters"); >> >> in Smalltalk (not the example I tried but something else that nearly >> works, except I get one value, the last one, instead of an array of five) >> >> call := (SoapCallEntry tcpHost: 'footballpool.dataaccess.eu' port: 80) >> newCall. >> call targetObjectURI: 'data/info.wso'. >> call namespace: 'http://footballpool.dataaccess.eu'. >> call methodName: 'TopGoalScorers'. >> call addParameterNamed: 'iTopN' value: '5'. >> call invokeAndReturn. > > > -- ================================================= GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

Dec. 1, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Eliot Miranda

On Tue, Nov 30, 2010 at 2:55 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Nov 30, 2010 at 11:45 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Thanks to both for answering me. >>> Now, I have very very newbie question. >>> In my case, JUST BECAUSE i am testing, I directly access the >>> CompiledMethod using MethodDictionary >> #at:ifAbsent: >>> thus, I can intercept and load back the original proxy. >>> >>> Now, if I understood well, when you send a simple message to an object, >>> the method lookup is done at VM side, and there is no call to >>> MethodDictionary >> #at:ifAbsent: >>> >>> So, what I am saying is that someone (the system) can send messages to a >>> SmallInteger that acts as a compiled methods, without accessing it by >>> MethodDictionary >> #at:ifAbsent:. >>> If that message is understood by the SmallInetger, then it will probably >>> answer something different than the original method. >>> >> >> You're forgetting that the VM executes the methods it finds in a method >> dictionary, except if the VM finds other than a CompiledMethod in a method >> dictionary, in which case it sends run:with:in: to it. So the VM won't send >> anything to the SmallInteger method proxy other than run:with:in:. If it >> didn't send run:with:in: it would crash trying to execute the SmallInteger. >> >> > I think we are confusing exatly like we were confusing yesterday with my > supervisors. > > Eliot, one thing is to do this: > > > MyClass methodDict at: #foo put: 5. > MyClass new foo. > > Here I am SURE the VM will send #run:with:in to SmallInteger. > > Now, my question is when I send a MESSAGE to the CompiledMethod, and NOT to > the object which class has installed the compiled method. > > Suppose I do: (MyClass methodDict at: #foo) size. and that I don't > change the implementation of MethodDictionary >> #at:ifAbsent: > > In this case, the VM will just try to send the message size to that > whatever is there. Both, SmallInteger and CompiledMethod understand #size, > but both answer different things... > I cannot intercept this, and I cannot load back the original object. > > This is why with Levento we thought about modifying MethodDictionary >> > #at:ifAbsent: to something like this: > > > at: key ifAbsent: aBlock > > | index value | > index := self findElementOrNil: key. > (self basicAt: index) == nil ifTrue: [ ^ aBlock value ]. > value := array at: index. > (value mareaIsProxy) ifTrue: [value mareaUninstall]. > ^ array at: index > > > But then, my question is if the system may access by another way than that > one. Ok, I should also modify some other methods in MethodDictionary like > #valuesDo: etc,,, > but if I do that, is that enough? or the system can still send messages > without passing there? > > Thanks a lot! > AFAIA there are no other ways than in the VM or explicitly, except in the VM simulator ;). best, Eliot > > mariano > > > > > >> best >> Eliot >> >>> >>> Now, maybe what I am thinking cannot happen. >>> >>> Thanks once again >>> >>> Mariano >>> >>> >>> >>> On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>>> On Tue, 30 Nov 2010, Igor Stasenko wrote: >>>> >>>> .. and then you need to change #do: , #associationsDo: etc etc.. >>>>> >>>> >>>> Or he can subclass MethodDictionary and override those methods. >>>> >>>> >>>> Levente >>>> >>>> >>> >> >

Nov. 30, 2010