- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] New Reef page and Tutorial available
by StÃ©phane Ducasse Oct. 9, 2010

Oct. 9, 2010

Cool we want more :) Yes :) May be after we could turn that into a chapter for the book. Stef > Hi, > As I promised at ESUG 2010, I created a page to keep Reef information and documentation... > You can see it here: http://www.smallworks.com.ar/en/community/Reef > > Also, I began to write a tutorial for Reef, the first part is here: http://www.smallworks.com.ar/en/community/Reef/reefSimpleTutorialPart1 > And the slides for the presentation is here: http://www.slideshare.net/EstebanLM/reef-esug-2010 > > > Cheers, > Esteban > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] Soap Webservices for pharo
by StÃ©phane Ducasse Oct. 9, 2010

Oct. 9, 2010

cool! > A little of progress... > > I fixed the underscores assignments, and Preferences references. > I built a first metacello configuration to download this package: > > Gofer it > squeaksource:'MetacelloRepository'; > package:'ConfigurationOfSoapOpera'; > load > > ConfigurationOfSoapOpera project lastVersion load > > It depends on ConfigurationOfKomHttpServer (Komanche). > I will enhance it in the future to make it depend in the Xml parser in XMLSupport. > > By now, in my 1.2 core image the tests are: 134 run, 121 passes, 0 expected failures, 2 failures, 11 errors, 0 unexpected passes. > > Cheers! > > 2010/10/4 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi guys, > > Nice to see that SOA Web Services in Squeak/Pharo is rolling on again. > We really need that, if we want Pharo to be useful in commercial, > specially in so called "enterprisely" world. Those who listen Andreas > ThÃ¶nne's talk on ESUG, know what I mean. > > What we really need on SOA Web Services front: > > - WSDL support, > - XML <-> Object mapping. > - Tools > > Goal should be a "one-click" use of Web Services. From both client and > server setup. As all Smalltalks support it, except Squeak/Pharo yet not. > Look at excellent VW or VA Smalltlak WebServices suport for inspiration. > > Best regards > Janko > > On 04. 10. 2010 16:21, Guillermo Polito wrote: > > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html > > > > So, we have some tasks now: > > > > - put it in squeaksource > > - test it in pharo > > - build a metacello config > > - document it? > > > > Any help is really appreciated, since I don't have too much time. > > > > Cheers, > > Guille > > > > ---------- Forwarded message ---------- > > From: *Masashi Umezawa* <umejava(a)mars.dti.ne.jp > > <mailto:umejava@mars.dti.ne.jp>> > > Date: Mon, Oct 4, 2010 at 8:46 AM > > Subject: Re: About SoapOpera and SoapCore > > To: Guillermo Polito <guillermopolito(a)gmail.com > > <mailto:guillermopolito@gmail.com>> > > > > > > Hi Guillermo, > > > > I am happy to hear that SoapOpera and SoapCore would be useful for your > > projects. Please feel free to reuse my Soap stuff. > > Recently I do not have enough time to upgrade those packages. So I > > really appreciate your offer. > > > > I hope SoapOpera and SoapCore will start growing again! > > > > Best regards, > > > > Guillermo Polito <guillermopolito(a)gmail.com > > <mailto:guillermopolito@gmail.com>> wrote: > >> Hi! > >> > >> My name's Guillermo and I'm from Argentina. I'm participating in the > > pharo > >> project (www.pharo-project.org <http://www.pharo-project.org>), and I > > would love to integrate your soap > >> package into our available packages :). > >> I was wandering if you let us put it into squeaksource > > (www.squeaksource.com <http://www.squeaksource.com>) > >> and mantain it for our use, because pharo is growing very quickly and it > >> needs this kind of really cool stuff :). Of course we will keep the MIT > >> license. > >> > >> Thank you for your time and sorry for bothering :P! > >> Guille > > > > --- > > [:masashi | ^umezawa] > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > 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

3 2

Re: [Pharo-project] [squeak-dev] Cog+NativeBoost Linux32 binaries available
by Fernando olivero Oct. 9, 2010

Oct. 9, 2010

Ok, thanks for the info. i'm more than interested in the doing the MacOsX port of NBOpenGL. When i have the time ( not in the near future) i will produce a native boost mac vm deployable , plus the NBOpenGL-MacOsX. Regarding the window downloable, i followed the instructions in the page, the load order of packages but a certain class seems to be missing when i want to try the example ( the true type font example rendering ) in the NBOpenGL-Morphic package. Thanks, Fernando On Oct 6, 2010, at 2:53 PM, Igor Stasenko wrote: > On 6 October 2010 09:16, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >> GREAT! thanks Igor. >> >> Is there also an NPOpenGL version working in Linux? >> > > Not yet. A platform-specific code needs to be written for it. > > An NBOpenGL-Win holds a windoze-specific code for it. > In order to use NBOpenGL on linux, you should similarily, subclass from > NBGlx , and implement a missing parts of it. > > I don't know when i'll be able to get free time to implement it, so if > you wanna help, > you are wellcome. > >> Fernando >> On Oct 6, 2010, at 3:37 AM, Igor Stasenko wrote: >> >>> + as a bonus, it also includes new finalization enhancements. :) >>> >>> See >>> http://code.google.com/p/nativeboost/downloads/list >>> for downloads. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

3 7

Re: [Pharo-project] XTream was Re: Ocean (was Re: Less plugins, more Smalltalk code!)
by mkobetic＠gmail.com Oct. 9, 2010

Oct. 9, 2010

I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks! Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-). As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side). Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc. That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if there are people interested in this. Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there). Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc. Martin "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes that's a correct description of the past and present. > > The futur is opened, and the main options for Squeak Xtream are: > 1) change goals to get closer to VW - with a compatible API and lot of > mud underneath to glue the implementation on squeak > 2) stay at a proof of concept experimental level > 3) continue developping independantly as a replacement for Stream > > There is a lot of buzz recently, and a renewed interest in VW Xtream. > So there is a chance to gather enough force to attempt a squeak port, > whether based on Squeak Xtream experiments or not. > But it's not to me alone to answer this challenge. > > Nicolas > > > Sven > > > > > > _______________________________________________ > > 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

3 2

[Pharo-project] Strange code replacement when prompting unknown selector
by Guillermo Polito Oct. 9, 2010

Oct. 9, 2010

http://code.google.com/p/pharo/issues/detail?id=3070 Cheers! Guille

3 3

Re: [Pharo-project] OrderedCollection
by StÃ©phane Ducasse Oct. 9, 2010

Oct. 9, 2010

looks like an exercise :) Stef On Oct 9, 2010, at 12:50 PM, Paper Spot Paper Spot wrote: > Hello, > > I've a small question about the OrderedCollection. I've an OrderedCollection wich contains some Users. Every Users have a name and a password. > > How can I search a user with a specific name ? > > Thank you in advance. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] OrderedCollection
by Paper Spot Paper Spot Oct. 9, 2010

Oct. 9, 2010

Hello, I've a small question about the OrderedCollection. I've an OrderedCollection wich contains some Users. Every Users have a name and a password. How can I search a user with a specific name ? Thank you in advance.

2 1

Oct. 9, 2010

even better :) On Oct 9, 2010, at 8:51 AM, Alain Plantec wrote: > Le 08/10/2010 22:01, StÃ©phane Ducasse a Ã©crit : >> alain may be we should that as comments in one of the class of the package. >> >> > but this is already in the comment of the class (only one class in the package) :-)

2 1

[Pharo-project] DejaVu vs Bitmap DejaVu / missing fonts folder
by Veronica Isabel Uquillas Gomez Oct. 9, 2010

Oct. 9, 2010

Hi, I would like to know if i am the only one having the indentation problem when using bitmap fonts. The Torch dashboard makes use of small and big DejaVu Sans fonts. For configuring it the fonts folder is needed (that now is gone in the last version pharo 1.1.1 dev, why?). Got the suggestion of using the new DejaVu package and I tried... However, they are Bitmap DejaVu fonts and I have the problem of text indentation. I show the changed source code in popup views. With DejaVu sans fonts the text appears as it is written (first image), but with Bitmap fonts not -- all is aligned to the left, and it is impossible to read a method like that (second image). Do I need to set something else for those fonts to work? Any idea why do I have this problem? Can the fonts folder be include again in the distribution? Best regards, Veronica Uquillas

2 4

Oct. 9, 2010

On Oct 8, 2010, at 10:05 PM, mkobetic(a)gmail.com wrote: > I saw this thread on the pharo list and figured that a bit of feedback from Michael and myself might be helpful. Please, forgive the cross-posting, this concerns both dialects and I'd like to make this discussion visible on the VW side as well. > > First of all, let me thank everyone for the "xtreamly" positive feedback. It sure feels good to get a thumbs up once in a while. So, thanks! > > Since there was a question earlier about availability of my ESUG slides, I'll also add that a rather crude and plain but usable pdf export of those is available on the ESUG slideshare. I'd be happy to forward the pdf to anyone interested as well. It's full of examples and it certainly should be easier to copy those from there than from the video or memory :-). > > As far as the future plans for Xtreams go (at least on VW side), we'd primarily like to validate the design with actual use, and fix any outstanding issues of course. We are certainly open towards collaboration with others on further development or porting efforts. I'd be happy to help sort out any porting issues (at least from the VW side). > > Regarding the general direction of the project, we are skeptical about the possibility of maintaining backward compatibility with the classic streams and yet being able to make the kind of changes that we're experimenting with in Xtreams. At this point we believe that the only practical approach is to let them live side by side and let people chose whichever fits better their needs. If Xtreams ever do gain significant acceptance there certainly is a very real possibility that we'll end up having to live with both frameworks, maybe forever. But we don't think there's practical way to somehow evolve the classic streams into something like Xtreams without wreaking havoc. The best strategy. > That's also partly why we took the liberty of changing even the basic APIs. They don't behave quite the same way (intentionally) in a number of cases and given that the two will likely have to coexist in the same context, it might be actually beneficial to make them distinctly different, so that it's clear which one is used where. Anyway, what I'm getting at is that some of the choices we've already made with Xtreams might be hard for us to compromise on, but we can certainly discuss the options. On the other hand, implementation changes that aid portability and don't compromise the basic goals are certainly a fair game. Ideally we'll be able to agree on an arrangement that would allow the project to co-evolve on multiple-dialects without the need to effectively fork the code-base. That would certainly be worth-while and we're definitely interested in trying to achieve that. I'll be at the Smalltalks 2010 conference in november and would be happy to discuss any details if the > re are people interested in this. > > Obviously, given the license, people are free to fork the code or start from scratch or whatever and take it in whatever direction they see fit. I just want to make it clear that we are open to collaboration as long as we can agree on general direction. So, no hard feelings Nicolas :-), although we may want to sort out the naming eventually just for the sake of avoiding confusion in the Squeak and Pharo world (if Xtreams ever get traction there). + Yes Nicolas why not upstreams flow > > Anyway, I'm now subscribed to the pharo list so I'm reachable both there and on vwnc. > > Martin > > "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Yes that's a correct description of the past and present. >> >> The futur is opened, and the main options for Squeak Xtream are: >> 1) change goals to get closer to VW - with a compatible API and lot of >> mud underneath to glue the implementation on squeak >> 2) stay at a proof of concept experimental level >> 3) continue developping independantly as a replacement for Stream >> >> There is a lot of buzz recently, and a renewed interest in VW Xtream. >> So there is a chance to gather enough force to attempt a squeak port, >> whether based on Squeak Xtream experiments or not. >> But it's not to me alone to answer this challenge. >> >> Nicolas >> >>> Sven >>> >>> >>> _______________________________________________ >>> 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

1 0