- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cmd+click in Rubric

by Yuriy Tymchuk

> On 10 Nov 2014, at 16:56, kilon alios <kilon.alios(a)gmail.com> wrote: > > The reason why I dont contribute to Pharo and decided to create my own project because frankly I cannot risk my code get rejected or debated upon. I know I am new to Pharo and I am not experienced coder in any way but still my free time is super valuable to me. I had made one contribution to Pharo and it met some fierce resistance and I had zero problem with that. My fix was accepted. I know people have their own preferences and ideologies when it comes to coding like all things in life and I think its 100% to reject my code or request an improvement. Frankly I am also afraid of braking things and making other people life miserably. > > But rejections and debates cost me valuable time. Sure if i was paid I would have zero problem. > > I mention this because I hear again and again, why people do not contribute. This is my reason. You should come to some sprint. This way you can see that you are not a bad coder, and itâs easy to improve :). Uko > > On Mon, Nov 10, 2014 at 5:36 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > I didnât tell anything about Alain investing into Rubric. Itâs just that Rubric is in GTInspector which I use, and I miss cmd+click feature. I think I could help to work on txText, but Iâve already broken quite a lot of things in Smalllint, so Iâll continue improving that part :) > > Uko > > > > On 10 Nov 2014, at 11:17, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > Guys > > > > I just discussed with Alain who is at my place working with Igor. > > Alain will not invest in Rubric. Rubric is the past. I told him to send a mail but he told me that he already said it. > > We should push txText. I will spend some time with igor to push it again but we need more people to have a look > > and help. > > > > Stef > > > > On 9/11/14 18:12, Yuriy Tymchuk wrote: > >> Dear all. > >> > >> Iâve already reported this issue but didnât make it clear. > >> > >> When I cmd+click some text in nautilus, I can âbrowseâ it. This means browse class implementation, browse method implementors. When I cmd+click something in rubric it opens a context menu. > >> > >> I anybody using cmd+click besides of me? > >> Can this be solved? > >> > >> Uko > >> > > > > > > >

Nov. 10, 2014

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

by Sven Van Caekenberghe

> On 10 Nov 2014, at 21:36, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > Le 10/11/2014 20:52, Sven Van Caekenberghe a Ã©crit : > >> 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 >> > okok, didn't you forgot brokers ? > I know but thank you anyway > I should have untitled it 'Stamp, RabbitMQ and other MQ systems' > not 'Stamp and other MQ systems', but the Rabbit went away, > sorry :) > > > just that I'm thinking of writing a small STOMP server may be within the Stamp package. > Because to me stamp was a package name not a stomp client, if your feeling is that it is a client may be this package should not have a server or server benchs in it? > > I can put it outside, I don't mind, and the benchs too with the server (also that I do not want to break or dirty your work Sven) > as I previously said, it has no sense from a client perspective. > the benchs are done in that perspective : a way to compare performance of different servers, not to bench the stamp client performance (which is important too , but to do that I would have written the bench in java and C too, to bench Stamp client against java and C client. > what I don't think I will). > > mmm... I did well to ask No, you misunderstood me. My point was that in messaging parlance a client is any party talking to the messaging broker or server. If you would be doing a server implementation, that would mean you are rewriting RabbitMQ, not impossible but quite a challenge ;-) Any self-contained (apart from the MQ itself) demo will always contain a producer and a consumer, or not much will happen, right ? Often you organise functionality in a client and server part. For example: testSimpleRpc | client server request response | "The server is a client listening on commands coming in on a queue named factorial" server := self client. [ server open. server subscribeTo: 'factorial'. server runWith: [ :message | | number | message body = 'quit' ifTrue: [ ConnectionClosed signal ]. number := message body asInteger. server sendText: number factorial asString to: message replyTo ] ] fork. client := self client. client open. 10 to: 20 do: [ :each | request := client newSendFrameTo: 'factorial'. request text: each asString. request replyTo: '/temp-queue/factorial'. client write: request. "Wait up to standard timeout for a reply" response := client readMessage. self assert: response body equals: each factorial asString ]. client sendText: 'quit' to: 'factorial'. client close Notice how both the 'client' and 'server', architecturally speaking, are actually STOMP 'clients', in the protocol sense of the word. So a benchmark or tutorial will fit in a separate category. Sven BTW, I am happy that you got up and running on your own. Your previous experience probably helped. Keep the feedback coming.

Nov. 10, 2014

Nautilus side buttons are polling :)

by stepharo

Hi guys Alain told me that the two buttons on the right of the text pane are polling using step to know if they should be greyed out. It would be nice to remove such slowish behavior. Stef

Nov. 10, 2014

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

by Alain Rastoul

Le 10/11/2014 20:52, Sven Van Caekenberghe a Ã©crit : > 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 > okok, didn't you forgot brokers ? I know but thank you anyway I should have untitled it 'Stamp, RabbitMQ and other MQ systems' not 'Stamp and other MQ systems', but the Rabbit went away, sorry :) just that I'm thinking of writing a small STOMP server may be within the Stamp package. Because to me stamp was a package name not a stomp client, if your feeling is that it is a client may be this package should not have a server or server benchs in it? I can put it outside, I don't mind, and the benchs too with the server (also that I do not want to break or dirty your work Sven) as I previously said, it has no sense from a client perspective. the benchs are done in that perspective : a way to compare performance of different servers, not to bench the stamp client performance (which is important too , but to do that I would have written the bench in java and C too, to bench Stamp client against java and C client. what I don't think I will). mmm... I did well to ask Alain

Nov. 10, 2014

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