December 2011 - Pharo-dev - lists.pharo.org

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

by Diogenes Moreira

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] Waiting for deferred UI messages

by Gary Chambers

This will get stuck if running in the UI process itself... Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean(a)clipperadams.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, December 10, 2011 7:38 AM Subject: [Pharo-project] Waiting for deferred UI messages > testSimulateRightClick > > | workspace menu sem | > workspace := Workspace open. > [ morph := World submorphThat: [ :m | m model == workspace ] ifNone: [ nil > ]. > (Delay forMilliseconds: 100) wait. > morph isNil ] whileTrue. > > WorldState addDeferredUIMessage: [ morph simulateRightClick ]. > > > [ "execution gets stuck in this loop" > menu := World submorphThat: [:m | m isKindOf: MenuMorph ] ifNone: [ nil ]. > (Delay forMilliseconds: 100) wait. > menu isNil ] whileTrue. > self assert: menu isNil not. > menu delete. > > When running from OB, the above deferred message block never gets > evaluated. > Execution loops forever in the last block. I thought that the delay would > give the UI an opportunity to process it. How do I modify this to work? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/Waiting-for-deferred-UI-messages-tp4179541p4179541.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 12, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Carlo

Hi Wouldn't the fact that you use hash cause potential loops now? e.g. collection refers to another object that refers to first collection. --> aCollection>>hash references an item which causes this current collection's hash to be called again? identityHash is deterministic in this case. Does this help? Cheers Carlo On 12 Dec 2011, at 10:58 AM, Mariano Martinez Peck wrote: Hi guys. I hope this is not a very stupid question. Background: in Fuel we have a IdentityDictionary where we put each of the objects we find while traversing the graph. We need to use IdentitySet because we cannot have repetitions (and to avoid loops) so we NEED to use #==. In such dictionary we put ALL objects of the graph, so it can be very big. Since IdentitySet uses #identityHash, it means it will be using those ONLY 12 bits in the object header. It means that we have 2^12 = 4096 different values. Question: having explained the previous, I wanted to be able to use #hash rather than #identityHash since several classes implement #hash and hence I thought that using #hash I could have less colisions and hence a better performance. I tried to make a subclass of IdentitySet that uses #hash rather than #identityHash but my image freezes. I also tried something like: set := PluggableSet new. set hashBlock: [ :elem | elem hash ]. set equalBlock: [ :a :b | a == b ]. But it doesn't work either. I works with simple tests in a workspace but when I run the full tests of Fuel, it enters in a loop in the method #hash of Collection.. Anyway, my question is, should that work? if not, what is the exact reason? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2011

Re: [Pharo-project] IdentitySet but using #hash rather than #identityHash ?

by Levente Uzonyi

On Mon, 12 Dec 2011, Levente Uzonyi wrote: > On Mon, 12 Dec 2011, Mariano Martinez Peck wrote: > >> Hi guys. I hope this is not a very stupid question. Background: in Fuel we >> have a IdentityDictionary where we put each of the objects we find while >> traversing the graph. We need to use IdentitySet because we cannot have >> repetitions (and to avoid loops) so we NEED to use #==. In such dictionary >> we put ALL objects of the graph, so it can be very big. Since IdentitySet >> uses #identityHash, it means it will be using those ONLY 12 bits in the >> object header. It means that we have 2^12 = 4096 different values. >> >> Question: having explained the previous, I wanted to be able to use #hash >> rather than #identityHash since several classes implement #hash and hence I >> thought that using #hash I could have less colisions and hence a better >> performance. I tried to make a subclass of IdentitySet that uses #hash >> rather than #identityHash but my image freezes. I also tried something >> like: >> >> set := PluggableSet new. >> set hashBlock: [ :elem | elem hash ]. >> set equalBlock: [ :a :b | a == b ]. >> >> But it doesn't work either. I works with simple tests in a workspace but >> when I run the full tests of Fuel, it enters in a loop in the method #hash >> of Collection.. >> >> Anyway, my question is, should that work? if not, what is the exact reason? > > If the serialized objects remain unchanged, then it can work. You can also > give another IdentitySet implementation a try, e.g.: > http://leves.web.elte.hu/squeak/LargeIdentitySet.st . You can also take a look at SystemTracer, because (IIRC) it uses an IdentitySet which will contain all objects at a point, and it's reasonably fast. IIRC the idea is to use the identityHash of the object mixed with the hash of its class to increase the number of bits in the key. Levente > > > Levente > >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Dec. 12, 2011

Re: [Pharo-project] Citezen

by Alexandre Bergel

Not yet. Smacc does not tell where the error happen. Cheers, Alexandre On 12 Dec 2011, at 08:42, StÃ©phane Ducasse wrote: > did you try to find the ugly entries that break it > because I can parse all rmod.bib. > > Stef > > On Dec 12, 2011, at 12:26 PM, Alexandre Bergel wrote: > >> Hi! >> >> Apparently, Citezen does not parse scg.bib (http://scg.unibe.ch/scgbib) The following expression raises an error: CZBibParser parse: (FileStream fileNamed: '/Users/alexandrebergel/Workspace/scgbib/scg.bib') contents >> >> Is there something obvious I missed? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 12, 2011

Re: [Pharo-project] Do we need the URI Package?

by Marcus Denker

On Dec 12, 2011, at 12:32 PM, Frank Shearar wrote: >> > > Indeed - Squeak's Network-URI supports things like mailto: schemes, > and there's a registration mechanism for arbitrary URIs (like SIP > URIs). I can't imagine that Pharo's Network-URI has diverged very far > from Squeak's? No, we did no change anything since I added URI to Squeak 3.8 or 3.9... Marcus -- Marcus Denker -- http://marcusdenker.de

Dec. 12, 2011

Re: [Pharo-project] Citezen

by StÃ©phane Ducasse

did you try to find the ugly entries that break it because I can parse all rmod.bib. Stef On Dec 12, 2011, at 12:26 PM, Alexandre Bergel wrote: > Hi! > > Apparently, Citezen does not parse scg.bib (http://scg.unibe.ch/scgbib) The following expression raises an error: CZBibParser parse: (FileStream fileNamed: '/Users/alexandrebergel/Workspace/scgbib/scg.bib') contents > > Is there something obvious I missed? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 12, 2011

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

by StÃ©phane Ducasse

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] Do we need the URI Package?

by Frank Shearar

On 11 December 2011 16:51, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 11 Dec 2011, at 11:38, Marcus Denker wrote: > >> Hi, >> >> There are three packages concerned with URLs: >> >> Â Â Â -> ZnUrl in Zinc >> Â Â Â -> Network-URI >> Â Â Â -> Network-Url >> >> URI was a package from Impara that was used extensively in all Impara products and Sophie... back than, >> the idea was to integrate Impara infrastructure in Squeak, but that did not happen due to politics... >> >> Network-URI seems to be used nowhere in the system, so I guess we can remove it? Or is anyone using it? > > ZnUrl started as a copy of Seaside's WAUrl. From the class comment: > > Â I am ZnUrl, an implementation of an interpreted HTTP(S) URL/URI. > Â Contrary to other implementations, this one is specific for HTTP(S). > > In other words, it might not be general enough, although I think it is better in its domain. > Covering all possible URI/URL types over all kinds of applications is not simple. Indeed - Squeak's Network-URI supports things like mailto: schemes, and there's a registration mechanism for arbitrary URIs (like SIP URIs). I can't imagine that Pharo's Network-URI has diverged very far from Squeak's? frank > Yes, we need to simplify this, but it is a lot of work. Maybe we could have a look at what other libraries do. > > Sven

Dec. 12, 2011

[Pharo-project] Citezen

by Alexandre Bergel

Hi! Apparently, Citezen does not parse scg.bib (http://scg.unibe.ch/scgbib) The following expression raises an error: CZBibParser parse: (FileStream fileNamed: '/Users/alexandrebergel/Workspace/scgbib/scg.bib') contents Is there something obvious I missed? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 12, 2011