- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] Company/freelance working with Pharo/Seaside

by Francois Stephany

Thanks Stef! >> Again I repeat it (and I know that you know): we are really interested in making business grows around pharo. We know =) > It is also important that success stories, even small ones, are shared. > Having a public list of available consultancy resources would be good, yes. Yep, that's the two main points for me. > But I guess that half the people on these lists are available for remotely delivered services in one form or another ;-) That's true. And I guess there are many silent observers in the list as well. How many people are there on Pharo-Dev and Pharo-Users by the way? Francois

Dec. 12, 2011

Re: [Pharo-project] [Pharo-users] Company/freelance working with Pharo/Seaside

by Diogenes Moreira

+1 i'm fully agree. http://about.me/diogenes.moreira 2011/12/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks diogenes. > > > First we should > - get a consortium > - a list of possible freelancers > - pay an engineer and see. > > Stef > On Dec 12, 2011, at 2:01 PM, Diogenes Moreira wrote: > > > Well, i'll write my answer in english and spanish (Mariano and Esteban, > please help if in my translate loose some think). > > > > > > English > > > > At least for my experience in other technologies management, (My > Smalltalks clients are small companies, and save in any think they can), > the client feel more comfortable if pait to support to a third person. > > That is, for much as a small payment, and answers them one person at a > call center, which has no idea what the answer and just follow the guide > for questions and answers such as "Is the power machine on?" not matter, > they feel more comfortable. > > Especially when you go to the production stage. In 90% of the cases, > calling the provider of the solution to any problem, but they feelmore > secure if you have Oracle, Microsofts, Etc. support > > If you see as the business model of Gemstone Currently, only the > Enterprise license is paid. > > In this sense, I think it would be very important to have a figure as > official support and a supported release, is something like RedHator > PostgreSQL. If the goal is to grow in space Pharo Enterprise. > > > > On the other hand, I agree there is an active community, it is almost > meaningless, but keep in mind that many cases those who manage a technology > area, don't know technology, and need a comfort zone and someone to call at > a crisis > > > > With regard to structure, I think that those who agreed to join the > Consortum have to have a role, I guess the first line (the most common > questions) should be results from a list. After X time, for example 48 > hours, or whatever you define. > > The case must be taken by one of the engineers. All you have to keep in > mind that contact with the subscriber, should be one and only, not to make > noise. > > > > Best > > > > Spanish. > > > > Por lo menos durante mi experiencia de gestiÃ³n en otros tecnologÃa, (Los > clientes que tengo en smalltalk, son PyMes y ahorran en todo lo que pueden > ), el cliente se siente mas cÃ³modo si paga a un tercero, para soporte. > > Es decir, por mas que sea un canon chico, y lo atiende una persona en un > call center, que no tiene idea de lo que esta contestando y solo sigue una > guÃa de preguntas y respuestas tal como, "Tiene encendida la maquina", no > importa, se sienten mas comodos. > > Sobre todo cuando pasan a la etapa de producciÃ³n, en el 90% de los > casos, terminan llamando al proveedor de la soluciÃ³n, pero se sienten mas > seguros, si tiene el soporte de Oracle, Microsofts, Etc. > > Si ven como esta armando el negocio de Gemstone Actualmente, solo la > licencia de uso Enterprise tiene precio. > > En este sentido creo que serÃa muy importante que exista una figura de > soporte oficial y un release soportado, algo asÃ como tiene RedHat o > PostgreSql. Si el objetivo es hacer crecer Pharo en el espacio Enterprise. > > > > Por otra parte estoy de acuerdo existiendo una comunidad activa, esto > casi carece de sentido, pero tengan en cuenta que muchos casos los que > gestionan un Ã¡rea de tecnologÃa, no conocen de ella y necesitan una Ã¡rea de > comodidad y alguien a quien llamar ante una crisis. > > > > Con respecto a la estructura para esto, creo que aquellos que aceptamos > formar parte del Consortum tenemos que tener un rol, supongo que una > primera linea (las preguntas mÃ¡s comunes) deberÃ¡ ser resulta por una lista > y pasado X tiempo, por ejemplo 48 horas, o lo que se defina. > > El caso deberÃ¡ ser tomado por alguno de los ingenieros. Lo Ãºnico que > habrÃa que tener en cuenta que el contacto con el suscriptor, deberÃa ser > uno y solo, para no hacer lios. > > > > Saludos > > > > > > http://about.me/diogenes.moreira > > > > > > 2011/12/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > > On Dec 12, 2011, at 11:45 AM, Sven Van Caekenberghe wrote: > > > > > > > > On 12 Dec 2011, at 11:28, StÃ©phane Ducasse wrote: > > > > > >> We need your inputs to build a structure to answer these questions. > > >> So what would help you to make your clients feel more confident? > > >> Again I repeat it (and I know that you know): we are really > interested in making business grows around pharo. > > >> > > >> so do you think that the consortium could have a list of > > >> companies offering services? > > >> freelancers? > > >> â¦ > > >> The consortium should help you. > > > > > > Having an active community where many people participate in making > Pharo better all the time is the best reference. > > > > > > It is also important that success stories, even small ones, are shared. > > > > > > Having a public list of available consultancy resources would be good, > yes. > > > > > > But I guess that half the people on these lists are available for > remotely delivered services in one form or another ;-) > > > > > > Although it is important that the community keeps on growing, we > reached critical mass a long time ago, IMHO. > > > > :) > > Yes but I would like to structure that point :) > > > > > > > > Sven > > > > > > > > >

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by StÃ©phane Ducasse

On Dec 12, 2011, at 5:35 PM, Igor Stasenko wrote: > On 12 December 2011 17:16, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> ok, i see your point. I will refactor back to Javier's approach. >> My rationale was to reify the Cairo library as it is, luckily all the >> other examples work. > > Well, it makes sense to do things like that, when you want a fast and > dirty working stuff. > But a good wrapping makes a lot of difference: there is no need to > indicate that you using a library > through 'self cairo' everywhere. It is just an indirection without any benefit. > > Wrapper classes and their instances should provide a required > functionality through well defined protocols, and then from user's > standpoint it is really > makes no difference who implements them. > That's why we need Athens. Indeed we do want to have cairo dependencies inside our system just encapsulated in their respective canvases. >> If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost >> automatically associates the type? Because i've been putting directly >> "int". Would be nice to have a couple of examples of NB (whenever the >> time is enough for you guys, i know you are busy) >> > > Yes, but these examples were written specifically to show how to wrap > a library in object-oriented way :) > Look at pharo by example book [1], there you can find an explanation > how to use shared pools. > Of course it is far from complete, but my opinion that your > refactoring gives a bad example to future developers. > They should think in terms of objects and place callouts in > corresponding classes with nicely formed protocol(s). > > I am looking forward for you to come, so i can explain things more > directly and easier :) > > [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… > >> thanks for the feedback, >> Fernando >> >> >> >> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> CairoSamplePrograms>>rectangleAndText >>> does not works, because it uses a following method: >>> >>> NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>> ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, >>> String aFamily, >>> >>> cairo_font_slant_t slant, >>> >>> cairo_font_weight_t aWeight) ) >>> >>> >>> and during code generation it barks that it unable to resolve >>> 'cairo_font_slant_t' type. >>> Because NBCairo class does not includes a corresponding shared pool >>> (NBCairoTypes). >>> >>> Also, Fernando, i don't like that you put everything into a single >>> class (NBCairo). >>> This is wrong, not object-oriented. The original organization made by >>> Javier was much more closer to my tastes. >>> >>> This approach to wrapping a library is too mechanical. It is much >>> better to place calls at proper place(s) in proper classes, >>> rather than putting everything into a single one. Which means that in >>> this way you are at least 1 message send farther from >>> real function call. >>> But in your case its not even that.. >>> >>> NBCairoPattern>>status >>> ^ self cairo patternStatusOf: self >>> >>> cairo >>> ^ NBCairo default >>> >>> so , it is 2 extra message sends, instead of direct call to foreign function! >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by StÃ©phane Ducasse

Igor what is the link between pango cairo and the work you did on the text model in athens? Because I have the impression that you work on text modeling is important. Stef > A taste of what will be available: rendering the same GLabel (the > gaucho equivalent to StringMorph), scaling the CairoCanvas. > > Pesudo Code: > > "create a label" > label := GLabel on : 'hello Pango-Cairo'. > > "draw it on the canvas" > label drawOn: canvas. > > "scale the canvas" > canvas translateBy: aDelta ; scaleBy: aScale. > > "draw it on the canvas" > label drawOn: canvas. > > "repeat"

Dec. 12, 2011

Re: [Pharo-project] Waiting for deferred UI messages

by StÃ©phane Ducasse

if the symptoms continue you should stop :) I knew pharo was a strong drug but not at this level :) Stef > Thanks Gary! I actually had a dream about this last night (I obviously need > a vacation or another hobby). I visualized myself flying through the path of > execution and realized exactly that. > > -- > View this message in context: http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4186571.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 12, 2011

Re: [Pharo-project] Morphic Cleanup Status

by Sean P. DeNigris

Fernando olivero-2 wrote > > my overall impression , was that we need to stop being backward > compatible in order to create a simple Morphic-like framework for > Pharo, and start from scratch Having worked with all three (Morphic, SimpleMorphic, and your from-scratch version), what are the tradeoffs with each? Is the complexity of SimpleMorphic, and more still Morphic, essential [1] or accidental [2]? What I'm really asking is: do you envision your version to offer similar features and power as either of the others? I (totally ignorantly) feel like we could squeeze most of the awesome power of Morphic into a *much* smaller package. Also, it'd be great to read the original Morphic papers (if you haven't already) for inspiration to let the intended liveness and directness shine through in this new project. This work that you're doing is incredibly important. In the hallways at every conference, I hear dreams of amazing tools people have in mind (myself included), which are put on hold due to the mind-boggling complexity and uncertainty of Morphic and its future. Let me know when there's anything I can do. Sean [1] http://en.wikipedia.org/wiki/Essential_complexity [2] http://en.wikipedia.org/wiki/Accidental_complexity -- View this message in context: http://forum.world.st/Morphic-Cleanup-Status-tp4106566p4186864.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2011

Re: [Pharo-project] Scat - Public Release and announcement

by StÃ©phane Ducasse

Hi bernat Excellent! do you have code that we removed and changed that you would like to be in the system? Stef On Dec 12, 2011, at 4:56 PM, Bernat Romagosa wrote: > Hi list, > > Joan GÃ¼ell and I have been working on Scat -the Scratch port to Pharo- quite a lot recently. We wanted to push it to a point where we could release the first reasonably working version, which we've just managed today. > > Please take a look at the release announcement (which should be read in a bit of a humorous tone), in which we explain what's up with the project and what future is left for it. > > For the tl;dr version, please read: > â¢ Many things are working, many aren't, but the state of the project allows us to move into more interesting stuff based on the graphic programming metaphor. > â¢ Scat is a time-consuming, brain-smashing, life sucking-project. > â¢ We no longer will be maintaining this massive unmaintainable code. > â¢ Suddenly: free time for other projects! > Cheers everyone! > > -- > Bernat Romagosa.

Dec. 12, 2011

Re: [Pharo-project] [ANN] Eclipse Icons for Pharo

by StÃ©phane Ducasse

http://www.famfamfam.com/ ? > Hi Fernando, > > oops... I forgot your icon importer, sorry :P > > I would like âfor a futureâ to integrate it to pharo and replace current ThemeIcons with an icon strategy based on your package... maybe that is the best "future scenario" for icons. > > best, > Esteban > > El 11/12/2011, a las 8:49a.m., Fernando Olivero escribiÃ³: > >> Hi Esteban, nice work! >> For importing the icons you can use the toolset i've developed: it >> automates completely the process of importing a complete set of icons >> of a given family. >> >> ExternalIconFamily @ squeaksource. >> I've used it for importing the Oxygen icon set, and others (you can >> google the list for previous related emails). >> >> Fernando >> >> On Sun, Dec 11, 2011 at 10:38 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Esteban >>> I know that feeling :) >>> >>> :) >>> Now I'm not sure that I would like to carry the Eclipse License around in Pharo :) >>> What are the other icons sets we could use with a nice license and we do it :). >>> famfam? >>> >>> We should clean also the old icons because some are really old. >>> Thanks for pushing that. I would love to have new icons for Pharo. >>> Stef >>> >>> >>> >>> On Dec 11, 2011, at 3:15 AM, Esteban Lorenzano wrote: >>> >>>> Hi, >>>> >>>> Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... and I never liked the current Pharo icons, so I took one icon library I really like and changed all needed icons (well... all that I saw). >>>> Here a couple of screen shots: >>>> >>>> <Captura de pantalla 2011-12-10 a la(s) 23.05.55.png> >>>> <Captura de pantalla 2011-12-10 a la(s) 23.06.20.png> >>>> >>>> Of course, I don't think they are perfect (also maybe I didn't pick the best icons), but I think they look a lot better than the older. >>>> >>>> If you want to see how they look, this are the packages: >>>> >>>> for Pharo 1.3: >>>> >>>> <Eclipse-Icons-EstebanLorenzano.2.mcz> >>>> >>>> for Pharo 1.4: >>>> >>>> <Eclipse-Icons-EstebanLorenzano.4.mcz> >>>> >>>> >>>> Then you execute: >>>> >>>> ThemeIcons initializeIcons. >>>> World resetWorldMenu. >>>> >>>> ... and enjoy your new icons :) >>>> >>>> btw... this icons are in an open-source license, the EPL: http://www.eclipse.org/legal/epl-v10.html >>>> so, maybe âif all agreeâ, we can add this icons to regular distribution :) >>>> >>>> best, >>>> Esteban >>>> >>> >>> >> > >

Dec. 12, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Igor Stasenko

On 12 December 2011 17:16, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > ok, i see your point. I will refactor back to Javier's approach. > My rationale was to reify the Cairo library as it is, luckily all the > other examples work. Well, it makes sense to do things like that, when you want a fast and dirty working stuff. But a good wrapping makes a lot of difference: there is no need to indicate that you using a library through 'self cairo' everywhere. It is just an indirection without any benefit. Wrapper classes and their instances should provide a required functionality through well defined protocols, and then from user's standpoint it is really makes no difference who implements them. That's why we need Athens. > > If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost > automatically associates the type? Because i've been putting directly > "int". Would be nice to have a couple of examples of NB (whenever the > time is enough for you guys, i know you are busy) > Yes, but these examples were written specifically to show how to wrap a library in object-oriented way :) Look at pharo by example book [1], there you can find an explanation how to use shared pools. Of course it is far from complete, but my opinion that your refactoring gives a bad example to future developers. They should think in terms of objects and place callouts in corresponding classes with nicely formed protocol(s). I am looking forward for you to come, so i can explain things more directly and easier :) [1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Ali… > thanks for the feedback, > Fernando > > > > On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> CairoSamplePrograms>>rectangleAndText >> does not works, because it uses a following method: >> >> NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext >> Â Â Â Â <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> Â Â Â Â ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext, >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â String aFamily, >> >> cairo_font_slant_t slant, >> >> cairo_font_weight_t aWeight) ) >> >> >> and during code generation it barks that it unable to resolve >> 'cairo_font_slant_t' Â type. >> Because NBCairo class does not includes a corresponding shared pool >> (NBCairoTypes). >> >> Also, Fernando, i don't like that you put everything into a single >> class (NBCairo). >> This is wrong, not object-oriented. The original organization made by >> Javier was much more closer to my tastes. >> >> This approach to wrapping a library is too mechanical. It is much >> better to place calls at proper place(s) in proper classes, >> rather than putting everything into a single one. Which means that in >> this way you are at least 1 message send farther from >> real function call. >> But in your case its not even that.. >> >> NBCairoPattern>>status >> Â Â Â Â ^ self cairo patternStatusOf: self >> >> cairo >> Â Â Â Â ^ NBCairo default >> >> so , it is 2 extra message sends, instead of direct call to foreign function! >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Dec. 12, 2011

Re: [Pharo-project] Waiting for deferred UI messages

by Sean P. DeNigris

Gary Chambers-4 wrote > > This will get stuck if running in the UI process itself... > Thanks Gary! I actually had a dream about this last night (I obviously need a vacation or another hobby). I visualized myself flying through the path of execution and realized exactly that. -- View this message in context: http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4186571.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 12, 2011