June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] GLORP in Pharo

by Mariano Martinez Peck

On Sun, Jun 27, 2010 at 11:52 AM, Alberto Bacchelli < alberto.bacchelli(a)usi.ch> wrote: > Hi, > > What is the current situation of GLORP in Pharo? > It should work. I couldn't spend time on it since the last months, but it should be working. The original squeak version of Glorp was coupled and hardcoded to the PostgreSQL driver. I don't know what database you want to use. We did such change under the GlorpDBX project. In summary, it lets the SqueakDatabaseAccessor to talk to a general DatabaseDriver class. THen you can implement any kind of Glorp database driver. We created one for SqueakDBX and one for the native postgreSQL driver. Now, for example, Diogenes Moreira build one for the Squeak ODBC driver. More information can be found in http://www.squeakdbx.org/GLORP%20integration Search for GlorpDBX or Glorp in the mailng list and you will some useful mails. Cheers Mariano > Is there any working porting? Otherwise are there reliable alternatives to > it? > > Thank you. > > Cheers, > Alberto > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 28, 2010

Re: [Pharo-project] Versions Browser diff checkboxes

by Mariano Martinez Peck

Thanks gary. I created http://code.google.com/p/pharo/issues/detail?id=2597 cheers mariano 2010/6/21 Gary Chambers <gazzaguru2(a)btinternet.com> > Attached a change set to theme/refactor the diffs/prettyDiffs "buttons" > in VersionsBrowsers. > > Was bugging me having the "old style" UpdatingThreePhaseButtonMorphs... > > Regards, Gary > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 28, 2010

Re: [Pharo-project] [OT] Ubuntu wallpaper

by Mariano Martinez Peck

On Thu, Jun 24, 2010 at 3:42 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >I have an error "'image format not recognized'" > > Check the correct URL: > > http://ubuntu.ecchi.ca/wallpapers/10.04//Maraetaibeforesunrise.jpg > > in a webbrowser and then try in Pharo 1.1. > > Which VM (Std/Cog?), which OS and which pharo image do you have? > Do you have the same error in another image? > > Pharo-1.1-11400-rc2 Latest update: #11400 VM: Squeak VM 4.2.2b1 What I evaluated: |form| form := (Form fromBinaryStream: (HTTPSocket httpGet: 'http://ubuntu.ecchi.ca/wallpapers/10.04/' , 'Maraetaibeforesunrise.jpg')). World backgroundImage: form layout: #scaled I attach the PharoDebug.log generated. The problem is in #formFromStream: aBinaryStream Because none of "ImageReadWriter withAllSubclasses" understands the format, and thus, it goes with the ifNone. Can you put a self halt and let me know which subclass in particular is working for you? Cheers Mariano > If the problem persists open a new issue with details. > > Bye > T. > > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 28, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by laurent laffont

2010/6/28 Mariano Martinez Peck <marianopeck(a)gmail.com> > just in case...in http://www.squeaksource.com/ObjectMetaTools > > you have interesting packages like MethodWrappers. It sohuld be working in > pharo. > Thanks, I will have a look. I've commited a (experimental) version of Autotest which counts hit on the modified method and displays it in the dashboard. It was quite tricky to develop it with unit tests & threads but fun. This sort of code you write and say "waouh this is really cool !". Thank you all ! I really like the hit count in the dashboard, brings confidence. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > cheers > > mariano > > 2010/6/27 laurent laffont <laurent.laffont(a)gmail.com> > > >> >> 2010/6/27 Benoit St-Jean <bstjean(a)hotmail.ca> >> >> Hi Laurent, >>> >>> Perhaps I am missing something but you only need 2 conditions to detect >>> what you are looking for: >>> >>> 1) changed method is a test (and defined in a subclass of TestCase) >>> 2) changed method has a sender that is a test method >>> >> >> First Autotest versions have these two heuristics. Then I feel the need to >> add: >> - change method is a setUp or tearDown -> run all tests of TestCase >> - and now when there's no senders of changed method in a TestCase (a >> private method for example) -> try to find tests of the changed method >> class (I think it can be better but I have no other solution yet) >> >> Indeed, using Autotest I feel the need to be sure that the method I've >> changed has been called. I would like to see a warning if it's not the case. >> >> Cheers >> >> Laurent >> >> >> >>> >>> >>> >>> ----------------- >>> Benoit St-Jean >>> A standpoint is an intellectual horizon of radius zero. >>> (Albert Einstein) >>> >>> >>> >>> >>> ------------------------------ >>> From: laurent.laffont(a)gmail.com >>> Date: Sun, 27 Jun 2010 17:33:53 +0200 >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: [Pharo-project] Xtreme Pharo hacker needed :) >>> >>> >>> Hi, >>> >>> I struggle for a functionality I want to add on Autotest. Suppose a class >>> with two methods A and B, such as A senders of B >>> >>> Zork>>methodA >>> self methodB >>> >>> And unit tests: >>> >>> ZorkTest>>testSomething >>> ..... >>> Zork new methodA >>> ... >>> self assert: .... >>> >>> >>> If I change methodA, Autotest detects it, search all senders of methodA >>> in tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it >>> will find and run it. >>> >>> Now if I change methodB and there's no senders in tests, the previous >>> heuristic won't work. So I added as last heuristic: if no method found, >>> search all TestCases that references the changed method class and run. >>> So here it will find ZorkTest and run all its tests. >>> The problem is that I don't really know if the method I've changed has >>> been actually "hit" by the tests. I just see that tests has been run. I >>> don't know if my method has been called when running the tests. >>> >>> So I want to detect this. >>> >>> One way of doing this seems to use >>> MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at >>> MessageTally. Is it the best solution ? >>> >>> So in Autotest>>findRunAndShowTestsOf: I try something like this >>> >>> Autotest>>findRunAndShowTestsOf:changedMethod >>> | testMethods aTestResult methodHit | >>> "Finds the test related to changedMethod, run them and tell the view to >>> update" >>> testMethods := search methodsFor: changedMethod. >>> methodHit := false. >>> thisContext sender >>> runSimulated: [aTestResult := runner run: testMethods] >>> contextAtEachStep: [:current| >>> (current method = changedMethod) "<--- here I detect if >>> changedMethod has been hit" >>> ifTrue: [methodHit := true]]. >>> ..... >>> >>> but using this debugger opens with "SimulationGuardException: triggered >>> by BlockClosure>>newProcess" in >>> MethodContext>>doPrimitive:method:receiver:args: >>> >>> As I don't (yet :) understand all this stuff, I want to know if it's the >>> right way to do it and what should I check. >>> >>> Thanks >>> >>> Laurent Laffont >>> >>> http://pharocasts.blogspot.com/ >>> http://magaloma.blogspot.com/ >>> >>> ------------------------------ >>> Enter for a chance to get your town photo on Bing.ca! Submit a Photo >>> Now! <http://go.microsoft.com/?linkid=9734379> >>> >>> _______________________________________________ >>> 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 >

June 28, 2010

Re: [Pharo-project] SUnit tests failures and errors

by Mariano Martinez Peck

uffff sorry....I have just seen your second attachment...forget what I said ;) 2010/6/27 Benoit St-Jean <bstjean(a)hotmail.ca> > If that helps (please say yes, it took HOURS to run!), here are the latest > results of running all unit tests for: > > Image: Pharo-1.1-11400-rc2 > Latest update: #11400 > OS: Windows XP, SP3 > VM version string: Squeak3.10.2 of ''5 June 2008'' [latest update: #7179] > > Hope this helps! > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs > SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version > used SystemNavigation#allSendersOf: which sometimes returns wrong results (I > think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class > side but allSendersOf: returns #scanCategory reference on class side and > instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > ------------------------------ > Turn down-time into play-time with Messenger games Play Now!<http://go.microsoft.com/?linkid=9734381> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 28, 2010

Re: [Pharo-project] SUnit tests failures and errors

by Mariano Martinez Peck

2010/6/27 Benoit St-Jean <bstjean(a)hotmail.ca> > If that helps (please say yes, it took HOURS to run!), here are the latest > results of running all unit tests for: > > Hi Benoit St-Jean. Yes, they are always useful. The HOURS is because I added Metacello tests to the dev image, which are a lot. > Image: Pharo-1.1-11400-rc2 > Latest update: #11400 > OS: Windows XP, SP3 > VM version string: Squeak3.10.2 of ''5 June 2008'' [latest update: #7179] > > Hope this helps! > > What it is interesting is that when you have few minutes and want to contribute to Pharo, you just take a particular test, adn try to analyze it. If possibe, fix it. BTW, there is a new way to exporting the results of a tests run: notice the button "file out results" in the right of the test runner. Then, search the file in the same directory where the image is. Cheers Mariano > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs > SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version > used SystemNavigation#allSendersOf: which sometimes returns wrong results (I > think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class > side but allSendersOf: returns #scanCategory reference on class side and > instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > ------------------------------ > Turn down-time into play-time with Messenger games Play Now!<http://go.microsoft.com/?linkid=9734381> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 28, 2010

Re: [Pharo-project] [Seaside] New structure for Seaside30, Magritte2, and Pier2 Metacello configurations

by Mariano Martinez Peck

Hi Dale. I didn't test it, but from the theorical point of view, I really like it. I hope other people too. I think we have to take advantage of Metacello features to do this kind of stuff. It is very interesting to have two groups: one for the core (and probably deployment) and one for development. If you do this changes, please update the workspace of ConfigurationOfSeaside explaining this :) (sorry if you already did it) Cheers mariano On Sun, Jun 27, 2010 at 7:54 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > I am looking for a little feedback on the changes that I have made to the > latest configurations of Seaside30, Magritte2, and Pier2. I have new > versions for each of these configurations queued up for release > (#development blessing), but before releasing them I'd like to hear if the > changes I've made will cause trouble for folks using Magritte2 and/or Pier2 > in their applications. > > In the past, when you referenced Seaside30 from a configuration, the entire > Seaside3.0 release would be loaded, including development tools, examples, > both adaptors (on Squeak/Pharo and GemStone)...basically the whole kitchen > sink. > > With the 3.0.0-alpha5.15 release I've defined several groups for Seaside3.0 > (with feedback from the Seaside devs:): Base, Base Tests, Development and > Development Tests. I will also add a One-click group to shdow the one-click > release. Without going into too much detail, the Base group defines the set > of packages that are needed for a production release, while the Development > group defines the set of packages that are useful in development (on top of > the Base). > > To see how these new groups work out, I have created new versions of the > configurations for Magritte2 and Pier2 that reference the Base group (plus > any other packages that were needed) instead of bringing in the entire > Seaside3.0 release...This is the big change. After loading the Magritte2 or > Pier2 configuration you will need to load from the Seaside30 configuration > any and all packages that you may need for your own application. > > I haven't released the changes yet, but if you are curious or concerned you > can try out the releases ahead of time ... depending upon feedback I may go > with a different scheme. > > In a fresh image, you can see what will be loaded for production by > executing one or more of the following expressions (note you need to get the > latest version of each of the configs from the SqueakSource > MetacelloRepository...oh and for best results use Metacello 1.0-beta.27.1): > > (ConfigurationOfMagritte2 project version: '2.0.5') load. > (ConfigurationOfPier2 project version: '2.0.6') load. > (ConfigurationOfPierAddOns2 project version: '2.0.6') load. > > Once you've loaded one of these configs, there will be no development tools > nor any adaptors so at a minimum you'll need to load one of the following > depending upon which adaptor you want to use: > > "All platforms" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Swazoo'). > "Squeak and Pharo" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Comanche'). > "GemStone" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-FastCGI'). > > If you want to load in the Seaside development environment then you would > evaluate the following expression: > > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Development'). > > So at this point you can see the direction I'm going with this ... the > Magritte2 and Pier2 configurations are currently aimed at loading the bare > minimum needed for functionality from Seaside3.0 for Magritte2 and Pier2 > with the idea that you'd load the additional functionality that you want by > dealing directly with Seaside30 configuration (like loading adaptors and > development)... > > Pier2 already depends upon the following javascript packages: > > 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' 'JQuery-UI' > > but if you're currently using Magritte2 and javascript, then you'll need to > explicitly load the javascript package(s) that you are using. > > There are other ways that the configs could be structured. This approach > minimizes the coupling between the Seaside3.0 and Magritte2/Pier2 > configurations, which I think is a good thing. > > I've taken the bare minimum step: loading what is required... it would be > reasonable to add 'Dev' groups to both Magritte2 and Pier2 that would bring > in Seaside30 dev support on the other hand, I don't think it is reasonable > to add support for loading the various Adaptors to Magritte2 and Pier2, so > if you're going to have to deal with the Seaside30 config directly anyway > why bother with adding dev groups ... > > Anyway this is what _I_ think and I am interested in what you folks > think... > > For GemStone folks ... the answer is yes, Magritte2 and Pier2 have been > ported to GemStone/S 64 2.4 finally:). If you've been working with > Seaside3.0 already, you can load the Magritte2/Pier2/PierAddOns2 configs > into a fresh 1.0-beta.8....otherwise I'll ask you to wait until I > announcement. > > Dale > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

June 28, 2010

Re: [Pharo-project] Xtreme Pharo hacker needed :)

by Mariano Martinez Peck

just in case...in http://www.squeaksource.com/ObjectMetaTools you have interesting packages like MethodWrappers. It sohuld be working in pharo. cheers mariano 2010/6/27 laurent laffont <laurent.laffont(a)gmail.com> > > > 2010/6/27 Benoit St-Jean <bstjean(a)hotmail.ca> > > Hi Laurent, >> >> Perhaps I am missing something but you only need 2 conditions to detect >> what you are looking for: >> >> 1) changed method is a test (and defined in a subclass of TestCase) >> 2) changed method has a sender that is a test method >> > > First Autotest versions have these two heuristics. Then I feel the need to > add: > - change method is a setUp or tearDown -> run all tests of TestCase > - and now when there's no senders of changed method in a TestCase (a > private method for example) -> try to find tests of the changed method > class (I think it can be better but I have no other solution yet) > > Indeed, using Autotest I feel the need to be sure that the method I've > changed has been called. I would like to see a warning if it's not the case. > > Cheers > > Laurent > > > >> >> >> >> ----------------- >> Benoit St-Jean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> >> >> >> >> ------------------------------ >> From: laurent.laffont(a)gmail.com >> Date: Sun, 27 Jun 2010 17:33:53 +0200 >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Xtreme Pharo hacker needed :) >> >> >> Hi, >> >> I struggle for a functionality I want to add on Autotest. Suppose a class >> with two methods A and B, such as A senders of B >> >> Zork>>methodA >> self methodB >> >> And unit tests: >> >> ZorkTest>>testSomething >> ..... >> Zork new methodA >> ... >> self assert: .... >> >> >> If I change methodA, Autotest detects it, search all senders of methodA in >> tests and run. As ZorkTest>>testSomething is sender of Zork>>methodA, it >> will find and run it. >> >> Now if I change methodB and there's no senders in tests, the previous >> heuristic won't work. So I added as last heuristic: if no method found, >> search all TestCases that references the changed method class and run. >> So here it will find ZorkTest and run all its tests. >> The problem is that I don't really know if the method I've changed has >> been actually "hit" by the tests. I just see that tests has been run. I >> don't know if my method has been called when running the tests. >> >> So I want to detect this. >> >> One way of doing this seems to use >> MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at >> MessageTally. Is it the best solution ? >> >> So in Autotest>>findRunAndShowTestsOf: I try something like this >> >> Autotest>>findRunAndShowTestsOf:changedMethod >> | testMethods aTestResult methodHit | >> "Finds the test related to changedMethod, run them and tell the view to >> update" >> testMethods := search methodsFor: changedMethod. >> methodHit := false. >> thisContext sender >> runSimulated: [aTestResult := runner run: testMethods] >> contextAtEachStep: [:current| >> (current method = changedMethod) "<--- here I detect if changedMethod >> has been hit" >> ifTrue: [methodHit := true]]. >> ..... >> >> but using this debugger opens with "SimulationGuardException: triggered by >> BlockClosure>>newProcess" in >> MethodContext>>doPrimitive:method:receiver:args: >> >> As I don't (yet :) understand all this stuff, I want to know if it's the >> right way to do it and what should I check. >> >> Thanks >> >> Laurent Laffont >> >> http://pharocasts.blogspot.com/ >> http://magaloma.blogspot.com/ >> >> ------------------------------ >> Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! >> <http://go.microsoft.com/?linkid=9734379> >> >> _______________________________________________ >> 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 >

June 28, 2010

Re: [Pharo-project] Changing/Removing Desktop Image in 1.1

by Mariano Martinez Peck

On Mon, Jun 28, 2010 at 1:05 PM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Le 28/06/2010 12:57, Rob Rothwell a Ã©crit : > > Great, thanks! >> >> Do you think this should be do-able from the settings dialog? >> > Hi all, > Yes, I will fix the setting. Normally, this can be done from the setting > browser ... > I am too exigent if I ask to be able also to browse with a file browser, select a picutre and be able to set it as background? At least with a general way: World backgroundImage: (ImageReadWriter formFromFileNamed: 'XXXXX.png') layout: #scaled. Cheers Mariano > Cheers > Alain > >> I am asking from the point of view of the Morphic-challenged like >> myself...! It seems like something I might be able to figure out how to >> add... >> >> Rob >> >> On Mon, Jun 28, 2010 at 3:16 AM, Mariano Martinez Peck < >> marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >> 2010/6/28 Benoit St-Jean <bstjean(a)hotmail.ca >> <mailto:bstjean@hotmail.ca>> >> >> >> That should do the trick: >> >> LogoImageMorph default: nil. >> >> >> yes, but this one only if you want to remove the Pharo logo. >> >> If you want to remove the background image, just these two lines: >> >> World backgroundMorph: nil. >> World restoreDisplay. >> >> >> BTW...I thought that "World color: Color white". >> should do the trick also, but it doesn't. >> >> >> Hope this helps! >> >> >> ----------------- >> Benoit St-Jean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) >> >> >> >> >> >> ------------------------------------------------------------------------ >> Date: Sun, 27 Jun 2010 18:45:13 -0400 >> From: r.j.rothwell(a)gmail.com <mailto:r.j.rothwell@gmail.com> >> >> To: pharo-project(a)lists.gforge.inria.fr >> <mailto:pharo-project@lists.gforge.inria.fr> >> >> Subject: [Pharo-project] Changing/Removing Desktop Image in 1.1 >> >> >> Can anyone remove the default image in 1.1 >> (Pharo-1.1-11400-rc2dev10.06.1)? Remove it? >> >> Using the settings browser has no effect for me. >> >> I can't even remove it by adding a halo and deleting it... >> >> Take care, >> >> Rob >> >> >> ------------------------------------------------------------------------ >> Enter for a chance to get your town photo on Bing.ca! Submit a >> Photo Now! <http://go.microsoft.com/?linkid=9734383> >> >> >> _______________________________________________ >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@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 >

June 28, 2010

Re: [Pharo-project] ESUG will sponsor the XMLRPC project!

by Serge Stinckwich

ROS (Robot Operating System) use XML-RPC : http://www.ros.org/wiki/ On Mon, Jun 28, 2010 at 6:11 PM, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 06/28/2010 12:25 AM, GermÃ¡n Arduino wrote: >> As flickr, > > Besides REST and SOAP > >> blogger, > > Nope, not any more. > >> wordpress, > > ok > >> Joomla sites, > > ok > >> Google blog search, > > Couldn't find anything about it. Google is standardizing on GData and > "AJAX". Even SOAP is being phased out. > >> Drupal sites, > > Moving away from XML-RPC like anybody else. > >> delicious, > > Couldn't find anything XML-RPC related, seems to use "REST". > >> zope, > > OK. > >> products as SAP, > > Still? I would have assumed they moved on. > >> to mention a few that >> I have in mind now.... >> >> I means, not only web sites, also products and I think also that is a >> compact protocol that could permit to implement an API to servers / >> products easily. > > My impression is that people either moved from XML-RCP to SOAP or > abandoned the idea and went to REST. I don't know anybody who considers > it for new projects. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

June 28, 2010