November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Stamp and other MQ systems (was Re: NAtiveBoost error)

by Sven Van Caekenberghe

> On 10 Nov 2014, at 20:28, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > Le 10/11/2014 20:00, Sven Van Caekenberghe a Ã©crit :> > >> On 10 Nov 2014, at 19:07, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > >> I have loaded your stamp package (very nice), and ran it against rabbitmq . > >> If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? > >> or should I publish my own package ? > >> What is the best practice with SmalltalkHub and what do you prefer ? > >> No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. > > > > It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread). > > > Yes, there is some benchmarking on time to send or receive. > I wanted to first add a sample 'helloworld' producer/consumer > and measure messages send/receive by second with one and several pharo VMs, and also may be find some benchs done by other MQ supplier. > And, as I should have a much more powerfull computer than my laptop in few weeks (nothing to do with christmas, I am my own santa claus, supplier delays), I could make some tests with several linux+pharo VMs. > I will add a Stamp-Benchmarks subpackage and put samples and code in it. OK. > This does not make sense under a client package perspective, but has under a server one. Just for the record (I am being pedantic here, sorry): STAMP is a STOMP client, a way to connect to a message queue; but in messaging speak the parties are called producers and consumers, not client and servers (although this qualification can be useful architecturally); to run any code you always need both or not much will happen. Sven

Nov. 10, 2014

Stamp and other MQ systems (was Re: NAtiveBoost error)

by Alain Rastoul

Le 10/11/2014 20:00, Sven Van Caekenberghe a Ã©crit :> >> On 10 Nov 2014, at 19:07, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> I have loaded your stamp package (very nice), and ran it against rabbitmq . >> If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? >> or should I publish my own package ? >> What is the best practice with SmalltalkHub and what do you prefer ? >> No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. > > It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread). > Yes, there is some benchmarking on time to send or receive. I wanted to first add a sample 'helloworld' producer/consumer and measure messages send/receive by second with one and several pharo VMs, and also may be find some benchs done by other MQ supplier. And, as I should have a much more powerfull computer than my laptop in few weeks (nothing to do with christmas, I am my own santa claus, supplier delays), I could make some tests with several linux+pharo VMs. I will add a Stamp-Benchmarks subpackage and put samples and code in it. This does not make sense under a client package perspective, but has under a server one. Alain

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by kilon alios

For the time being I am only interested in colors only. Concentrating on basic stuff that is easy to change on the fly. So I am not so interested in more advanced stuff like text format which should be handled by the tool itself and not a main Theme manager anyway. So no I am not interested in the difficult parts because I dont have time for them. My goal is very realistic actually, I am happy with the Dark Theme, I want more room to play with colors. This is why I referred to sub themes, I dont care about exposing my theme manager to all settings that a theme may have, just start with 12 settings and keep adding stuff if I feel the need for them. Anyway I will give it a try and see how it goes. I need this functionality anyway. On Mon, Nov 10, 2014 at 9:07 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Kilon wrote: > >Thanks Stephan for your honest answer :) > > Sorry about the negative attitude. > > Making sure that the window color in the preferences correctly reflects > the one in the theme would already be a great improvement. > > You are correct that editing the theme in the settings would > quickly become a mess. It would be a good idea to develop > a theme editor that can directly show the effects of all its > settings. That is difficult, as you need to make sure that > you can always see the effect of changes. For small changes > (space between text lines) you might need something like a > looking glass. > > You also need some way of finding out what settings might > be related to what you are trying to do. If the line height is a > calculation > of text size and interline distance, you want to be able to find that out. > > Stephan > > > >

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by Stephan Eggermont

Kilon wrote: >Thanks Stephan for your honest answer :) Sorry about the negative attitude. Making sure that the window color in the preferences correctly reflects the one in the theme would already be a great improvement. You are correct that editing the theme in the settings would quickly become a mess. It would be a good idea to develop a theme editor that can directly show the effects of all its settings. That is difficult, as you need to make sure that you can always see the effect of changes. For small changes (space between text lines) you might need something like a looking glass. You also need some way of finding out what settings might be related to what you are trying to do. If the line height is a calculation of text size and interline distance, you want to be able to find that out. Stephan

Nov. 10, 2014

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> On 10 Nov 2014, at 19:07, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > Le 08/11/2014 17:14, Sven Van Caekenberghe a Ã©crit : > >> Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. >> >> I don't know what you are looking for, I would just do some prototyping and see what happens. > > Thanks, somewhat what I'm thinking. > > To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. > Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. > I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? > May be the question was not clear or too broad, apologizes, this is my fault. > > About protocols, I tend to be focused on what I want to do and know I'm wrong here. > Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? > ... given that you are good at networking stuff, that would be great :) At the moment I have no plans in this direction. Writing something is not the biggest problem. Documentation, making it somewhat feature complete, supporting it for years, fulfilling requests, that is much more work. It is an ongoing responsibility. > I have loaded your stamp package (very nice), and ran it against rabbitmq . > If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? > or should I publish my own package ? > What is the best practice with SmalltalkHub and what do you prefer ? > No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread). > TIA > > regards, > Alain > >

Nov. 10, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Le 08/11/2014 17:14, Sven Van Caekenberghe a Ã©crit : > Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. > > I don't know what you are looking for, I would just do some prototyping and see what happens. Thanks, somewhat what I'm thinking. To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? May be the question was not clear or too broad, apologizes, this is my fault. About protocols, I tend to be focused on what I want to do and know I'm wrong here. Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? ... given that you are good at networking stuff, that would be great :) I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. TIA regards, Alain

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by kilon alios

Thanks Stephan for your honest answer :) On Mon, Nov 10, 2014 at 6:56 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Kilon wrote: > >Actually my point was the creation of themes, thats what a theme manager > does. No its not easy, its not easy to have to go to the System Browser > find Dark Theme class, try to guess which method is responsible >for the > background color and then go the usual Pharo rabbit hole of senders and > implementors so that I dont brake anything. It kills my inner child. > Slowly. Painfully. > > Well, then please don't. There is no current value in adding more themes. > Adding themes on the current code will just add to the mess that needs > to be cleaned up. It leads to more fragmentation. > > >About moving away from static values and replace them with references I > agree 100% with you > >but you also mention the very important that its something we have to > agree on and I don't want > > to go through the pain of asking permission each time I want to do > something like that. > > No need to ask for permission. Just take small steps and post mails on > your decisions. > defaultSpec implementations are good candidates, just like defaultBounds, > defaultBorderColor, > defaultBorderWidth, defaultColor and defaultExtent > > >Because writing code to create a theme , makes no sense to me whatsoever. > > Avoiding duplication tends to be extremely difficult otherwise. > > Stephan >

Nov. 10, 2014

Re: [Pharo-dev] Let's talk about Themes

by Stephan Eggermont

Kilon wrote: >Actually my point was the creation of themes, thats what a theme manager does. No its not easy, its not easy to have to go to the System Browser find Dark Theme class, try to guess which method is responsible >for the background color and then go the usual Pharo rabbit hole of senders and implementors so that I dont brake anything. It kills my inner child. Slowly. Painfully. Well, then please don't. There is no current value in adding more themes. Adding themes on the current code will just add to the mess that needs to be cleaned up. It leads to more fragmentation. >About moving away from static values and replace them with references I agree 100% with you >but you also mention the very important that its something we have to agree on and I don't want > to go through the pain of asking permission each time I want to do something like that. No need to ask for permission. Just take small steps and post mails on your decisions. defaultSpec implementations are good candidates, just like defaultBounds, defaultBorderColor, defaultBorderWidth, defaultColor and defaultExtent >Because writing code to create a theme , makes no sense to me whatsoever. Avoiding duplication tends to be extremely difficult otherwise. Stephan

Nov. 10, 2014

Re: [Pharo-dev] [update 4.0] #40364

by Sven Van Caekenberghe

> On 10 Nov 2014, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: > > >> 40364 >> ----- >> 14422 AnnouncementSpy is not needed anymore: GTInspector has all the functionality >> https://pharo.fogbugz.com/f/cases/14422 > > Is there a demonstration of this available somewhere? > cheers -ben Here is one I did: https://www.youtube.com/watch?v=rIBbeMdFCys Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello But there are others too. Sven

Nov. 10, 2014

Re: [Pharo-dev] [update 4.0] #40364

by Ben Coman

> 40364 > ----- > > 14422 AnnouncementSpy is not needed anymore: GTInspector has all the functionality > https://pharo.fogbugz.com/f/cases/14422 Is there a demonstration of this available somewhere? cheers -ben

Nov. 10, 2014