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

[Pharo-project] Extract parameters

by Adrien BARREAU

Hello all, When I worked on a command-line tool, I discovered SmalltalkImage>>extractParameters. I didn't find it very good, so I wrote the little method attached to this mail. I think it could be useful. What do you think about that? Here is an example: I suppose I run pharo with: `pharo myImage.image -minus1 'Hello' -minus2 -minus3 'Hello' 'World'`. This message will return a dictionary with: minus1 --> #(Hello) minus2 --> #() minus3 --> #('Hello' 'World'). The first extractParameters was quite strange, since it starts to look at the third parameter (or, the second can be used!), and can not return a list. Adrien. _________________________________________________________________ Installez gratuitement les nouvelles Emoch'ticones ! http://www.ilovemessenger.fr/emoticones/telecharger-emoticones-emochticones…

June 29, 2010

Re: [Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package

by StÃ©phane Ducasse

Argh indeed in Object it sucks a bit :) Stef On Jun 29, 2010, at 4:16 PM, Guillermo Polito wrote: > Hi, > > Why should it be in Object? Can't it be placed in ClassDefinition maybe? > Ok, i should look what the compiler does, it's just a suggestion. > > I think we should avoid putting more weird isXXX methods in Object :). > > On Tue, Jun 29, 2010 at 11:02 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi! > > > SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox > -=-=-=-=-=-= > Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. > -=-=-=-=-=-= > > Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly: > > composition := Compiler evaluate: self classTraitComposition. > ((((composition isCollection and: [ ( composition includes: nil ) not]) > or: [composition isKindOf: TraitComposition ]) > or: [composition isKindOf: Trait ]) > or: [composition isKindOf: TraitTransformation ]) > ifTrue: [ class class setTraitComposition: composition asTraitComposition ] > > Is that ok if I had Object>>isTraitComposition in the Trait package? > > Cheers, > Alexandre > > > > On 29 Jun 2010, at 13:04, StÃ©phane Ducasse wrote: > > > alex can you have a look at it? > > http://code.google.com/p/pharo/issues/detail?id=2598 > > > >>> > >>> Stef > >>> > >>> On Jun 28, 2010, at 10:45 PM, Simon Denier wrote: > >>> > >>>> > >>>> When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image. > >>>> > >>>> It seems closely related to previous issues 2477 and 2148 > >>>> But I am not sure if this is the same bug reappearing or a variant. > >>>> > >>>> To reproduce: > >>>> Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load > >>>> > >>>> Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes. > >>>> > >>>> > >>>> After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes: > >>>> > >>>> MOGraphNode subclass: #MABfsNode > >>>> uses: MATEdgeNode - {#previousEdges. #from:edge:} > >>>> instanceVariableNames: 'nextEdges firstDepth' > >>>> classVariableNames: '' > >>>> poolDictionaries: '' > >>>> category: 'Moose-Algos-Graph' > >>>> > >>>> MODisjointSetNode subclass: #MANextNode > >>>> uses: MATNodeNode - {#from:. #previousNodes} > >>>> instanceVariableNames: 'nextNodes' > >>>> classVariableNames: '' > >>>> poolDictionaries: '' > >>>> category: 'Moose-Algos-Graph' > >>>> > >>>> > >>>> > >>>> The problem has been reproduced in 11383 and 11400 RC2. > >>>> > >>>> > >>>> -- > >>>> Simon > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> -- > >> Simon > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 29, 2010

Re: [Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package

by StÃ©phane Ducasse

please! Stef On Jun 29, 2010, at 4:02 PM, Alexandre Bergel wrote: > Hi! > > > SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox > -=-=-=-=-=-= > Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. > -=-=-=-=-=-= > > Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly: > > composition := Compiler evaluate: self classTraitComposition. > ((((composition isCollection and: [ ( composition includes: nil ) not]) > or: [composition isKindOf: TraitComposition ]) > or: [composition isKindOf: Trait ]) > or: [composition isKindOf: TraitTransformation ]) > ifTrue: [ class class setTraitComposition: composition asTraitComposition ] > > Is that ok if I had Object>>isTraitComposition in the Trait package? > > Cheers, > Alexandre > > > > On 29 Jun 2010, at 13:04, StÃ©phane Ducasse wrote: > >> alex can you have a look at it? >> http://code.google.com/p/pharo/issues/detail?id=2598 >> >>>> >>>> Stef >>>> >>>> On Jun 28, 2010, at 10:45 PM, Simon Denier wrote: >>>> >>>>> >>>>> When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image. >>>>> >>>>> It seems closely related to previous issues 2477 and 2148 >>>>> But I am not sure if this is the same bug reappearing or a variant. >>>>> >>>>> To reproduce: >>>>> Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load >>>>> >>>>> Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes. >>>>> >>>>> >>>>> After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes: >>>>> >>>>> MOGraphNode subclass: #MABfsNode >>>>> uses: MATEdgeNode - {#previousEdges. #from:edge:} >>>>> instanceVariableNames: 'nextEdges firstDepth' >>>>> classVariableNames: '' >>>>> poolDictionaries: '' >>>>> category: 'Moose-Algos-Graph' >>>>> >>>>> MODisjointSetNode subclass: #MANextNode >>>>> uses: MATNodeNode - {#from:. #previousNodes} >>>>> instanceVariableNames: 'nextNodes' >>>>> classVariableNames: '' >>>>> poolDictionaries: '' >>>>> category: 'Moose-Algos-Graph' >>>>> >>>>> >>>>> >>>>> The problem has been reproduced in 11383 and 11400 RC2. >>>>> >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> Simon >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 29, 2010

Re: [Pharo-project] 1.2 vision

by StÃ©phane Ducasse

We should also clean the package naming structure XXX XXX-Core XXX-Test-Core XXX-Foo XXX-Test-Foo Stef On Jun 29, 2010, at 3:42 PM, StÃ©phane Ducasse wrote: > **Yes** I really want to come up with a pragma and to annotate tests to populate the help. > > > On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: > >> + More HelpSystem. >> + MetacelloRepository GUI, newbies struggle to find a package, must be easy. >> >> Laurent >> >> On Sun, Jun 27, 2010 at 10:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi all >> >> Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common >> vision. Here what I would like to get in 1.2. >> >> Now it does not mean that this is a definitive list and that we will have the energy to do all but like >> that you know that you can put energy do build this common vision :) >> >> - better infrastructure for integrating rb composite queries into the system >> The idea is to introduce a superclass on top of systemDictionary and to define there an API that >> is compatible with the one of RB (and potentially modified the one of RB) >> >> - another step towards using announcement for system notification >> >> - better tools for dev >> >> - have a look at the RB change model so that we could get a real undo and changes >> >> - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. >> Right now this looks too brittle to do anything >> >> - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) >> >> - New Compiler in beta >> >> - Helvetia hooks >> >> - ROME API >> >> - Sophie Event Hierarchy >> >> - Define some architectural action to get the system more modular >> >> - Hudson infrastructure >> >> - metacello to manage core >> >> - metacelloRepository for 1.0/1.1/1.2 >> Gofer >> >> - squeak collection optimisation? >> >> - Alien >> >> Open points: >> >> - What do we do with ToolBuilder? Not clear to me. >> >> - What should be done at the level of polymorph? >> - What should be done a the level of Pluggable**** >> can we use the fact that we have now block closure to get it better. >> >> As you guess it will not come simply but this is important that we all head towards a common understanding >> >> >> Stef >> >> >> >> >> _______________________________________________ >> 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 29, 2010

Re: [Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package

by Guillermo Polito

Hi, Why should it be in Object? Can't it be placed in ClassDefinition maybe? Ok, i should look what the compiler does, it's just a suggestion. I think we should avoid putting more weird isXXX methods in Object :). On Tue, Jun 29, 2010 at 11:02 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi! > > > SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 > in the inbox > -=-=-=-=-=-= > Monticello can now load a trait composition with exclusion from Monticello. > A test has been added for this. > -=-=-=-=-=-= > > Something else, I would like to introduce Object>>isTraitComposition. This > will greatly simplifify MCClassDefinition>>createClass. The following code > is really ugly: > > composition := Compiler evaluate: self classTraitComposition. > ((((composition isCollection and: [ ( composition > includes: nil ) not]) > or: [composition isKindOf: TraitComposition ]) > or: [composition isKindOf: Trait ]) > or: [composition isKindOf: > TraitTransformation ]) > ifTrue: [ class class setTraitComposition: > composition asTraitComposition ] > > Is that ok if I had Object>>isTraitComposition in the Trait package? > > Cheers, > Alexandre > > > > On 29 Jun 2010, at 13:04, StÃ©phane Ducasse wrote: > > > alex can you have a look at it? > > http://code.google.com/p/pharo/issues/detail?id=2598 > > > >>> > >>> Stef > >>> > >>> On Jun 28, 2010, at 10:45 PM, Simon Denier wrote: > >>> > >>>> > >>>> When loading a package with class definitions containing a trait > composition like ClassX uses: TraitY - {#selector}, the composition is lost > in the image. > >>>> > >>>> It seems closely related to previous issues 2477 and 2148 > >>>> But I am not sure if this is the same bug reappearing or a variant. > >>>> > >>>> To reproduce: > >>>> Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; > package: 'Moose-Tests-Algos-Graph'; load > >>>> > >>>> Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 > errors, all due to the missing trait composition in some classes. > >>>> > >>>> > >>>> After loading, you can make a diff changes in monticello, it will > highlight the package as dirty and show you the lost trait compositions in > two classes: > >>>> > >>>> MOGraphNode subclass: #MABfsNode > >>>> uses: MATEdgeNode - {#previousEdges. #from:edge:} > >>>> instanceVariableNames: 'nextEdges firstDepth' > >>>> classVariableNames: '' > >>>> poolDictionaries: '' > >>>> category: 'Moose-Algos-Graph' > >>>> > >>>> MODisjointSetNode subclass: #MANextNode > >>>> uses: MATNodeNode - {#from:. #previousNodes} > >>>> instanceVariableNames: 'nextNodes' > >>>> classVariableNames: '' > >>>> poolDictionaries: '' > >>>> category: 'Moose-Algos-Graph' > >>>> > >>>> > >>>> > >>>> The problem has been reproduced in 11383 and 11400 RC2. > >>>> > >>>> > >>>> -- > >>>> Simon > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> -- > >> Simon > >> > >> > >> > >> _______________________________________________ > >> 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 29, 2010

Re: [Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package

by Alexandre Bergel

Hi! SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox -=-=-=-=-=-= Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. -=-=-=-=-=-= Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly: composition := Compiler evaluate: self classTraitComposition. ((((composition isCollection and: [ ( composition includes: nil ) not]) or: [composition isKindOf: TraitComposition ]) or: [composition isKindOf: Trait ]) or: [composition isKindOf: TraitTransformation ]) ifTrue: [ class class setTraitComposition: composition asTraitComposition ] Is that ok if I had Object>>isTraitComposition in the Trait package? Cheers, Alexandre On 29 Jun 2010, at 13:04, StÃ©phane Ducasse wrote: > alex can you have a look at it? > http://code.google.com/p/pharo/issues/detail?id=2598 > >>> >>> Stef >>> >>> On Jun 28, 2010, at 10:45 PM, Simon Denier wrote: >>> >>>> >>>> When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image. >>>> >>>> It seems closely related to previous issues 2477 and 2148 >>>> But I am not sure if this is the same bug reappearing or a variant. >>>> >>>> To reproduce: >>>> Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load >>>> >>>> Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes. >>>> >>>> >>>> After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes: >>>> >>>> MOGraphNode subclass: #MABfsNode >>>> uses: MATEdgeNode - {#previousEdges. #from:edge:} >>>> instanceVariableNames: 'nextEdges firstDepth' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'Moose-Algos-Graph' >>>> >>>> MODisjointSetNode subclass: #MANextNode >>>> uses: MATNodeNode - {#from:. #previousNodes} >>>> instanceVariableNames: 'nextNodes' >>>> classVariableNames: '' >>>> poolDictionaries: '' >>>> category: 'Moose-Algos-Graph' >>>> >>>> >>>> >>>> The problem has been reproduced in 11383 and 11400 RC2. >>>> >>>> >>>> -- >>>> Simon >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Simon >> >> >> >> _______________________________________________ >> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 29, 2010

Re: [Pharo-project] 1.2 vision

by StÃ©phane Ducasse

**Yes** I really want to come up with a pragma and to annotate tests to populate the help. On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: > + More HelpSystem. > + MetacelloRepository GUI, newbies struggle to find a package, must be easy. > > Laurent > > On Sun, Jun 27, 2010 at 10:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi all > > Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common > vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will have the energy to do all but like > that you know that you can put energy do build this common vision :) > > - better infrastructure for integrating rb composite queries into the system > The idea is to introduce a superclass on top of systemDictionary and to define there an API that > is compatible with the one of RB (and potentially modified the one of RB) > > - another step towards using announcement for system notification > > - better tools for dev > > - have a look at the RB change model so that we could get a real undo and changes > > - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. > Right now this looks too brittle to do anything > > - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) > > - New Compiler in beta > > - Helvetia hooks > > - ROME API > > - Sophie Event Hierarchy > > - Define some architectural action to get the system more modular > > - Hudson infrastructure > > - metacello to manage core > > - metacelloRepository for 1.0/1.1/1.2 > Gofer > > - squeak collection optimisation? > > - Alien > > Open points: > > - What do we do with ToolBuilder? Not clear to me. > > - What should be done at the level of polymorph? > - What should be done a the level of Pluggable**** > can we use the fact that we have now block closure to get it better. > > As you guess it will not come simply but this is important that we all head towards a common understanding > > > Stef > > > > > _______________________________________________ > 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 29, 2010

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

by Douglas Brebner

On 28/06/2010 22:18, GermÃ¡n Arduino wrote: > > Blogger and Google in general yes, are moving to GData but xml-rpc is > still suported. > > But I understand your point, you think that isn't worth to invest in > this protocol. > > I need to think about. > > It is still in use though, and as mentioned elsewhere on this thread you don't get to dictate the protocol the people on the other side use :)

June 29, 2010

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

by Jan van de Sandt

Hello, For information about protocol usage see: http://www.programmableweb.com/apis REST: 72% XML-RPC: 2% Jan. On Mon, Jun 28, 2010 at 11:18 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > 2010/6/28 Philippe Marschall <philippe.marschall(a)netcetera.ch>: > > 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. > > > > Blogger and Google in general yes, are moving to GData but xml-rpc is > still suported. > > But I understand your point, you think that isn't worth to invest in > this protocol. > > I need to think about. > > Cheers. > GermÃ¡n. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Jan van de Sandt gsm: +31 (0)6 3039 5998

June 29, 2010

Re: [Pharo-project] Icon

by Alexandre Bergel

Ah!! I usually use .gif. I will try. Thanks Cheers, Alexandre On 29 Jun 2010, at 13:25, Tudor Girba wrote: > Hi Alex, > > Did you export it as PNG with transparent background from Omnigraffle? > > Cheers, > Doru > > > On 29 Jun 2010, at 12:49, Alexandre Bergel wrote: > >> Hi! >> >> When I do an icon (using the import of MenuIcons), background color remains white. Is there a way to specify the background to be transparent? >> I usually do icons using OmniGraffle and doing a 16x16 screenshot. Is there a better way? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 29, 2010