Re: [Pharo-dev] About icon: and iconNamed:

Le 12/10/16 à 14:28, Denis Kudriashov a écrit : Hi Stef. It is really good idea. And it makes me think why we ask users for real icon Form and not just name? We could say any component which shows icons should be created with concrete ThemeIcons ("Smalltalk ui icons" by default) to

Re: [Pharo-dev] About icon: and iconNamed:

2016-10-12 15:01 GMT+02:00 Peter Uhnak : > Because ThemeIcons may not be the only place from which you draw icons, > and because programming with strings doesn't scale. > It is not programming with strings. Most users of icons (I really think all of them) are only specify name

Re: [Pharo-dev] About icon: and iconNamed:

On Wed, Oct 12, 2016 at 02:28:44PM +0200, Denis Kudriashov wrote: > Hi Stef. > > It is really good idea. And it makes me think why we ask users for real > icon Form and not just name? Because ThemeIcons may not be the only place from which you draw icons, and because programming with strings

Re: [Pharo-dev] About icon: and iconNamed:

Also regarding `#smallFindIcon asIcon`, there are many places where we can enter icons (e.g. Spec), so once we make a choice for Settings we should modify it there too. Peter On Wed, Oct 12, 2016 at 03:01:26PM +0200, Peter Uhnak wrote: > On Wed, Oct 12, 2016 at 02:28:44PM +0200, Denis

Re: [Pharo-dev] About icon: and iconNamed:

Hi Stef. It is really good idea. And it makes me think why we ask users for real icon Form and not just name? We could say any component which shows icons should be created with concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual form by name. And users should always specify

[Pharo-dev] About icon: and iconNamed:

Hi glamourers and other Hi I'm currently enhancing the API of Settings to propose to the users to pass not an icon but an icon named so that all the clients are not force to use. See below. Now it would be great if Glamour could do the same. Doru and Andrei? menuOn: aBuilder "Specify

[Pharo-dev] About iconNamed:

hi marcus Since you raise a problem related about iconNamed: My goal is to factor all the logic in a couple of root (Model/composableModel) instead of having is scattered in hundred of places. We cannot work with global access everywhere. I discussed about it with Guille and Pavel and for

Re: [Pharo-dev] About file printOn: method

> On Sep 10, 2016, at 12:28 PM, Udo Schneider > wrote: > >> On 10/09/16 10:52, stepharo wrote: >> So this is what I was trying to get done. >> I do not know if what you propose (which can be better than what I was >> planning) requires to change fileSystem, my

Re: [Pharo-dev] About file printOn: method

On Sun, Sep 11, 2016 at 4:37 AM, stepharo wrote: > o this is what I was trying to get done. > >> I do not know if what you propose (which can be better than what I was >>> planning) requires to change fileSystem, my goal was not to change for >>> now but just make sure that I

Re: [Pharo-dev] About Year not knowing exact daysInMonth

You could use Month class>>#daysInMonth:forYear: Which I think does what you want already. stepharo wrote > Hi > > I started to write a little utility to generate bills. > > And I need to know the number of days in a month and I was surprised that > > (Month month: 2) daysInMonth returns

[Pharo-dev] About Year not knowing exact daysInMonth

Hi I started to write a little utility to generate bills. And I need to know the number of days in a month and I was surprised that (Month month: 2) daysInMonth returns 28 because we do not know :) So I thought that I was obviously wrong and I should use (Year year: 2016) daysInMonth >

Re: [Pharo-dev] About file printOn: method

o this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into kind of objects I can manipulate

Re: [Pharo-dev] About file printOn: method

On 10/09/16 10:52, stepharo wrote: So this is what I was trying to get done. I do not know if what you propose (which can be better than what I was planning) requires to change fileSystem, my goal was not to change for now but just make sure that I can get cheaply file to print themselves into

Re: [Pharo-dev] About file printOn: method

ost if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo <steph...@free.fr> To: "Pharo Development List" <

Re: [Pharo-dev] About file printOn: method

On 04/09/16 09:47, stepharo wrote: It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo <steph...@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-d

Re: [Pharo-dev] About file printOn: method

turday, September 03, 2016 at 10:39 AM From: stepharo <steph...@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileRefe

Re: [Pharo-dev] About file printOn: method

<pharo-dev@lists.pharo.org> Subject: [Pharo-dev] About file printOn: method Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So th

Re: [Pharo-dev] about package naming

Nice. I wonder where the MC problem is actually coming (probably a notification handled the old way). Le 5/9/16 à 09:58, Nicolas Passerini a écrit : Yes Icebergs uses RPackages, I have RPackages and Tags and I do not remember having problems. On Mon, Sep 5, 2016 at 9:50 AM, Guille Polito

Re: [Pharo-dev] about package naming

Yes Icebergs uses RPackages, I have RPackages and Tags and I do not remember having problems. On Mon, Sep 5, 2016 at 9:50 AM, Guille Polito wrote: > As far as I understand, Iceberg uses RPackages. And RPackages do not > necessarily follow MC conventions. > > >

Re: [Pharo-dev] about package naming

As far as I understand, Iceberg uses RPackages. And RPackages do not necessarily follow MC conventions. Original Message Wow, I do not know where that email came from O_o. It looks a spammish email. Maybe it came from my phone? If it happens again, please tell me so I can

Re: [Pharo-dev] about package naming

Wow, I do not know where that email came from O_o. It looks a spammish email. Maybe it came from my phone? If it happens again, please tell me so I can take action. Now in-topic: I agree with having conventions and with the tests one particularly. But as you say, we should also think what

Re: [Pharo-dev] about package naming

Guille do you know if iceberg has the same problem? I do not remember what nicolas mentionned about if MC entities were kept around and used. Stef

Re: [Pharo-dev] about package naming

No guillermo. This is really annoying. With long package list like Collections* then you do not see well the tests. So we should check the bug like that we are free. Je suis pas de place que no necesita activar gustamucho la  que ya el otro lado Le 4 sept. 2016 10:18, "stepharo"

Re: [Pharo-dev] about package naming

Le 4/9/16 à 21:15, Cyril Ferlicot D. a écrit : Le 04/09/2016 à 20:52, Tudor Girba a écrit : Hi, That naming convention is due to the fact that there was a time when Monticello committed the content of packages based on prefix matching. So, if you had: FileSystem-Core

Re: [Pharo-dev] about package naming

> On 04 Sep 2016, at 20:52, Tudor Girba wrote: > > Actually, we still have the bug that if you would change something in > FileSystem-Core, FileSystem-Core-Tests would be marked as dirty. I think that this happens because we pretend to have packages, but behind the

Re: [Pharo-dev] about package naming

Le 04/09/2016 à 20:52, Tudor Girba a écrit : > Hi, > > That naming convention is due to the fact that there was a time when > Monticello committed the content of packages based on prefix matching. > > So, if you had: > FileSystem-Core > FileSystem-Core-Tests > committing

Re: [Pharo-dev] about package naming

Hi, That naming convention is due to the fact that there was a time when Monticello committed the content of packages based on prefix matching. So, if you had: FileSystem-Core FileSystem-Core-Tests committing FileSyste-Core would also commit FileSystem-Core-Tests as a

Re: [Pharo-dev] about package naming

Hi, I like the FileSystem-Core-Tests more, because then we can also have FileSystem-Core-Rules and FileSystem-Core-Rules-Tests. But I think that the other way to think about this is that if you want to (un)load all the test from filesystem you just work with FileSystem-Tests and not do it

[Pharo-dev] about package naming

Hi guys Sorry to be that dull and stupid but I do not get why (beside following the seaside convention - and I do not understand it either) why the test package for FileSystem-Core is named FileSystem-Tests-Core and not just FileSystem-Core-Tests like that we could have

Re: [Pharo-dev] About file printOn: method

It is raining and I will do it :) stef Le 4/9/16 à 02:38, monty a écrit : +1 Sent: Saturday, September 03, 2016 at 10:39 AM From: stepharo <steph...@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] About file printOn: method

Re: [Pharo-dev] About file printOn: method

+1 > Sent: Saturday, September 03, 2016 at 10:39 AM > From: stepharo <steph...@free.fr> > To: "Pharo Development List" <pharo-dev@lists.pharo.org> > Subject: [Pharo-dev] About file printOn: method > > Hi > > > I will implement the following becau

[Pharo-dev] About file printOn: method

Hi I will implement the following because this is too annoying. currently 'tmp/foo.txt' asFileReference > File @ tmp/foo.txt and it would be much much better to get back 'tmp/foo.txt' asFileReference So that we can get { 'tmp/foo.txt' asFileReference } > { 'tmp/foo.txt' asFileReference }

Re: [Pharo-dev] about clas deprecation

Gustavo The fix is now in Pharo 60 :) Stef Le 2/9/16 à 13:35, Gustavo Santos a écrit : Make sure to have the latest version of Refactoring-Core, because we fixed a bug on it yesterday On Fri, Sep 2, 2016 at 1:32 PM, Gustavo Santos >

Re: [Pharo-dev] about clas deprecation

Make sure to have the latest version of Refactoring-Core, because we fixed a bug on it yesterday On Fri, Sep 2, 2016 at 1:32 PM, Gustavo Santos wrote: > Gofer it >smalltalkhubUser: 'GustavoSantos' >project: 'Refactoring2'; >configurationOf: 'Refactoring2'; >

Re: [Pharo-dev] about clas deprecation

Gofer it smalltalkhubUser: 'GustavoSantos' project: 'Refactoring2'; configurationOf: 'Refactoring2'; loadDevelopment. then RBRenameAndDeprecateClassTransformation is the class you need On Fri, Sep 2, 2016 at 12:41 PM, Denis Kudriashov wrote: > > 2016-09-02

Re: [Pharo-dev] about clas deprecation

2016-09-02 11:35 GMT+02:00 Tudor Girba : > Excellent! > > How can I try it? > +100 and same question

Re: [Pharo-dev] about clas deprecation

Excellent! How can I try it? Doru > On Sep 2, 2016, at 10:31 AM, Nicolas Passerini wrote: > > Sounds good! > > On Fri, Sep 2, 2016 at 8:11 AM, stepharo wrote: > Hi > > Using the idea we got with Peter Uhnak, we know implemented using >

Re: [Pharo-dev] about clas deprecation

Sounds good! On Fri, Sep 2, 2016 at 8:11 AM, stepharo wrote: > Hi > > Using the idea we got with Peter Uhnak, we know implemented using > transformation library of gustavo two new transformation: > > - deprecate class > > just compile a new method raising a

Re: [Pharo-dev] About the non-use of Announcer in Bloc

this is really cool :) Le 1/9/16 à 10:21, Thierry Goubier a écrit : Hi Stef, here is the script I use: | c1 c2 c3 n1 n2 n3 l1 l2 l3 | c1 := c2 := c3 := 0. n1 := (Announcer>>#announce:) ast. n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ]. n3 :=

[Pharo-dev] about clas deprecation

Hi Using the idea we got with Peter Uhnak, we know implemented using transformation library of gustavo two new transformation: - deprecate class just compile a new method raising a warning: + a class method deprecated returning true (this could then improve to

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 10:29 GMT+02:00 Denis Kudriashov : > Hi Thierry. > > 2016-09-01 10:21 GMT+02:00 Thierry Goubier : > >> (Duration minutes: 1) wait. >> > > Just to mention our nice language: it could be written as: > > > 1 minutes wait > > > Thanks.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> On 01 Sep 2016, at 10:21, Thierry Goubier wrote: > > Hi Stef, > > here is the script I use: > > | c1 c2 c3 n1 n2 n3 l1 l2 l3 | > c1 := c2 := c3 := 0. > n1 := (Announcer>>#announce:) ast. > n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e |

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Thierry. 2016-09-01 10:21 GMT+02:00 Thierry Goubier : > (Duration minutes: 1) wait. > Just to mention our nice language: it could be written as: 1 minutes wait

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Stef, here is the script I use: | c1 c2 c3 n1 n2 n3 l1 l2 l3 | c1 := c2 := c3 := 0. n1 := (Announcer>>#announce:) ast. n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | (Announcer>>e) ast ]. n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 9:57 GMT+02:00 Denis Kudriashov : > Really? You lost me on that sentence. SystemAnnouncer current is shared by >> all the tools no? > > > Yes, you are right. I forgot this big monster :). > Now I look at senders of #announcer and there are many places with chain >

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 8:18 GMT+02:00 stepharo : > > But in practice we never share any announcer instance. > > Really? You lost me on that sentence. SystemAnnouncer current is shared by > all the tools no? Yes, you are right. I forgot this big monster :). Now I look at senders of

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Stef, 2016-09-01 8:13 GMT+02:00 stepharo : > Hi thierry > > I think that if we would have a tool to show us the activity I'm quite > sure that we would find bugs > > or mistaken behavior. > Yes. I did some checks on Morphic and AltBrowser after getting the numbers, to see

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Le 31/8/16 à 11:23, Denis Kudriashov a écrit : 2016-08-31 10:10 GMT+02:00 Glenn Cavarlé >: Hi all (I was out for some days), Hi Glenn What i see is that Bloc EventRegistry: 1) is not thread safe (no mutex +

Re: [Pharo-dev] About the non-use of Announcer in Bloc

To me, Announcer is really usefull and efficient when it is used as an event bus that can be shared between multiple objects. For instance, it seems to be useless to use an Announcer in NewValueHolder because it cannot be shared and it is only used internally to register handlers and to

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi thierry I think that if we would have a tool to show us the activity I'm quite sure that we would find bugs or mistaken behavior. could you send the scripts you did? Stef Le 30/8/16 à 22:36, Thierry Goubier a écrit : Numbers for the discussion: No activity, empty desktop:

Re: [Pharo-dev] About Pharo 60

On Wed, Aug 31, 2016 at 9:16 PM, stepharo wrote: > In squeak by example > > we could tag in the document code snippet as text and a perl script > > turn the expression into Sunit method and run the tests > > We lost that. Yes I remember this was very nice. We should have a

Re: [Pharo-dev] About Pharo 60

In squeak by example we could tag in the document code snippet as text and a perl script turn the expression into Sunit method and run the tests We lost that. Stef Le 31/8/16 à 12:21, Peter Uhnak a écrit : On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote: Ok, now I know what

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-31 18:01 GMT+02:00 Henrik Johansen : > > On 31 Aug 2016, at 10:10 , Glenn Cavarlé wrote: > > In Bloc the constraint is to propagate more than 2000 events/second without > to decrease fps > > > That's only a small part of the picture

Re: [Pharo-dev] About the non-use of Announcer in Bloc

On 31 Aug 2016, at 10:10 , Glenn Cavarlé wrote:In Bloc the constraint is to propagate more than 2000 events/second withoutto decrease fpsThat's only a small part of the picture though, how many listeners are there per each event?And how large do you think the overhead

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Denis, > Problem that concurrent modification of OrderedCollection could just fail. > You will got debugger. Yes, effectively, if there are multiple threads that try to add an handler on the same element at the same time, this could just fail. To me, it is not a problem, it is just a rule:

Re: [Pharo-dev] About Pharo 60

On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote: > Ok, now I know what I want. > > I want a better way to document. Because I’m trying to write a documentation > about my stuff, but there are too many disconnected ways to do that. I’m > trying to always have reasonable class

Re: [Pharo-dev] About Pharo 60

Ok, now I know what I want. I want a better way to document. Because I’m trying to write a documentation about my stuff, but there are too many disconnected ways to do that. I’m trying to always have reasonable class comments. But sometimes you need a more general description, so you write

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-31 10:10 GMT+02:00 Glenn Cavarlé : > Hi all (I was out for some days), > Hi Glenn > > What i see is that Bloc EventRegistry: > 1) is not thread safe (no mutex + #select:thenDo:) > 2) doesn't allow handler removal from the handler list currently used in > the >

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi all (I was out for some days), What i see is that Bloc EventRegistry: 1) is not thread safe (no mutex + #select:thenDo:) 2) doesn't allow handler removal from the handler list currently used in the thenDo: loop 3) is used specifically for a one-to-many communication (1 BlElement -> X handlers)

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Numbers for the discussion: No activity, empty desktop: announcements 608/minute subscribe add/remove9/minute Activity, AltBrowser: announcements 1109/minute subscribe add/remove207/minute Activity, Nautilus: announcements

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 17:36 GMT+02:00 Henrik Johansen : > > > On 30 Aug 2016, at 5:16 , Thierry Goubier > wrote: > > > > > > I have the same concern with an Announcer optimized for certain use > cases, in the fact that the announcer creator is the

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> On 30 Aug 2016, at 5:16 , Thierry Goubier wrote: > > > I have the same concern with an Announcer optimized for certain use cases, in > the fact that the announcer creator is the one choosing the 'kind of' > optimisation it would target, hoping that the listeners

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 16:01 GMT+02:00 Henrik Johansen : > > On 29 Aug 2016, at 6:39 , Denis Kudriashov wrote: > > And now question is why SubscriptionRegistry manages subscriptions as > IdentitySet instead of OrderedCollection? > > > 1) Performance of

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> On 29 Aug 2016, at 6:39 , Denis Kudriashov wrote: > > And now question is why SubscriptionRegistry manages subscriptions as > IdentitySet instead of OrderedCollection? 1) Performance of remove operation is the main reason. Sure, registration has a larger constant

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 11:12 GMT+02:00 Denis Kudriashov : > > 2016-08-30 10:35 GMT+02:00 Thierry Goubier : > >> >> 2016-08-30 10:28 GMT+02:00 Denis Kudriashov : >> >>> >>> 2016-08-30 10:21 GMT+02:00 Guille Polito

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 10:35 GMT+02:00 Thierry Goubier : > > 2016-08-30 10:28 GMT+02:00 Denis Kudriashov : > >> >> 2016-08-30 10:21 GMT+02:00 Guille Polito : >> >>> Hi, >>> >>> From the top of my head: I would understand that systems

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 10:41 GMT+02:00 Norbert Hartl : > > Am 30.08.2016 um 09:44 schrieb Denis Kudriashov : > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl : > >> I think for the 0 case we should think about instantiating the >>

Re: [Pharo-dev] About the non-use of Announcer in Bloc

One Morph <> One Announcer sounds bad in terms of memory consumption, yes. Maybe it makes more sense something like One Widged <> One Announcer But the problem is that today the line between Morphs and Widgets is not clearly set. I hope Bloc/Bric helps on this. Original

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> Am 30.08.2016 um 09:44 schrieb Denis Kudriashov : > > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl >: > I think for the 0 case we should think about instantiating the > SubscriptionRegistry lazily. This would also

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 10:28 GMT+02:00 Denis Kudriashov : > > 2016-08-30 10:21 GMT+02:00 Guille Polito : > >> Hi, >> >> From the top of my head: I would understand that systems where there are >> hundreds of thousands of events per second, maybe one does not

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 10:21 GMT+02:00 Guille Polito : > Hi, > > From the top of my head: I would understand that systems where there are > hundreds of thousands of events per second, maybe one does not want to pay > the overhead of announcements... > > But, How many events are

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi, From the top of my head: I would understand that systems where there are hundreds of thousands of events per second, maybe one does not want to pay the overhead of announcements... But, How many events are produced from a morph per second? One? Two? Five? Is it really the case of morphs

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 9:44 GMT+02:00 Denis Kudriashov : > Hi > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl : > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-30 9:44 GMT+02:00 Denis Kudriashov : > > 2016-08-30 8:52 GMT+02:00 Norbert Hartl : > >> I think for the 0 case we should think about instantiating the >> SubscriptionRegistry lazily. This would also mitigate the effect that if a >> lot of

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi 2016-08-30 8:52 GMT+02:00 Norbert Hartl : > I think for the 0 case we should think about instantiating the > SubscriptionRegistry lazily. This would also mitigate the effect that if a > lot of announcers are created they create only a single object instead of > two until

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> Am 30.08.2016 um 06:38 schrieb Stephan Eggermont : > > On 29/08/16 22:37, Denis Kudriashov wrote: >> It looks quite safe to not check anything because subscription items are >> instances of AnnouncementSubscription which are created internally >> inside Announcer during

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Le 29/8/16 à 21:37, Tudor Girba a écrit : Hi Denis, Thanks a lot for this analysis! In summary, the Bloc events are faster because: 1. they store the subscriptions in OrderedCollection instead of IdentitySet. This is likely something we can improve in Announcements. 2. they are unsafe. For

Re: [Pharo-dev] About Pharo 60

Additionally I would like to see: - investigation in the Win Pharo VM for being able to run again as a Windows Service (as it was possible for Squeak) to be able to easily provide, deploy and administrate a web app on Windows Definitively. Thanks for mentionning it. It will be

Re: [Pharo-dev] About the non-use of Announcer in Bloc

On 29/08/16 22:37, Denis Kudriashov wrote: It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription We should probably do something special for 0 and 1 subscriptions.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> On Aug 29, 2016, at 10:37 PM, Denis Kudriashov wrote: > > > 2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk : > > For 1., the only reason I can think of is to prevent the user to register > > twice the same object by mistake. I think this is an

Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk : > > For 1., the only reason I can think of is to prevent the user to > register twice the same object by mistake. I think this is an optimization > that should be the responsibility of the user. > > Alternatively we may use

Re: [Pharo-dev] About the non-use of Announcer in Bloc

> On 29 Aug 2016, at 21:37, Tudor Girba wrote: > > Hi Denis, > > Thanks a lot for this analysis! > > In summary, the Bloc events are faster because: > 1. they store the subscriptions in OrderedCollection instead of IdentitySet. > This is likely something we can improve

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Denis, Thanks a lot for this analysis! In summary, the Bloc events are faster because: 1. they store the subscriptions in OrderedCollection instead of IdentitySet. This is likely something we can improve in Announcements. 2. they are unsafe. For 1., the only reason I can think of is to

Re: [Pharo-dev] About Pharo 60

Thanks we are currently brainstorming with esteban on the pharo pro offer and this is nice to have your feedback. Stef Le 28/8/16 à 15:33, Torsten Bergmann a écrit : what are the points you are working on and that would deserve more focus and help from the community? I once started with

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Thanks Glenn!!! Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all

Re: [Pharo-dev] About the non-use of Announcer in Bloc

And expenses to deliver announcement caused also by protection and usage of IdentitySet. Also in announcements we first collect all subscriptions with interest to separate collection and only after we iterate and process given announcement. But in Bloc you use #select:thenDo: method instead. It

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Thank's. I try tests for subscribing and what I found is: Main problem that subscriptions inside SubscriptionRegistry are managed as IdentitySet which of cause much slower for addition then OrderedCollection. We probably could use OrderedCollection here because items are always created on fly and

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Ha... tag doesn't work... You can load Bloc and show the tests using this script: Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; configuration; loadDevelopment. Gofer it smalltalkhubUser: 'Pharo' project: 'Bloc'; package: 'Bloc-Tests'; load.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi, You can find the current Bloc image here: https://ci.inria.fr/moose/job/bloc/lastSuccessfulBuild/artifact/bloc.zip Cheers, Doru > On Aug 29, 2016, at 5:10 PM, Denis Kudriashov wrote: > > And could you write current repository? > > 2016-08-29 16:31 GMT+02:00 Glenn

Re: [Pharo-dev] About the non-use of Announcer in Bloc

And could you write current repository? 2016-08-29 16:31 GMT+02:00 Glenn Cavarlé : > You can load Bloc and show the tests using this script: > > > > > - > Glenn Cavarlé > -- > View this message in context: http://forum.world.st/About- >

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi, And the script is? :) Doru > On Aug 29, 2016, at 4:31 PM, Glenn Cavarlé wrote: > > You can load Bloc and show the tests using this script: > > > > > - > Glenn Cavarlé > -- > View this message in context: >

Re: [Pharo-dev] About the non-use of Announcer in Bloc

You can load Bloc and show the tests using this script: - Glenn Cavarlé -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913079.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi 2016-08-29 8:25 GMT+02:00 Tudor Girba : > Hi Glenn, > > Thanks a lot for this experiment. Could you send us the code snippet so > people can play with it? > Or some links where to download image with Bloc-Tests

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Hi Glenn, Thanks a lot for this experiment. Could you send us the code snippet so people can play with it? The question is if perhaps we can identify a slimmer announcement support so that people can choose depending on requirements (e.g. parallelism or not). Cheers, Doru --

Re: [Pharo-dev] About the non-use of Announcer in Bloc

Glenn Cavarlé Sent: Sunday, August 28, 2016 9:11 PM To: pharo-dev@lists.pharo.org Subject: [Pharo-dev] About the non-use of Announcer in Bloc Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare

[Pharo-dev] About the non-use of Announcer in Bloc

Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific

Re: [Pharo-dev] About Pharo 60

> what are the points you are working on and that would deserve more focus and > help from the community? I once started with a refactored version of GetText, covered with tests and tools. Code status I reached so far is here: http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext Idea

Re: [Pharo-dev] About Pharo 60

Hi, The answer was that Spotter is not different in any way than any other global shortcut. This means that if we want to have an interactive solution, we should do it at the level of the Keymapping framework not at the level of individual tools. In the meantime, how do we manage this?

Re: [Pharo-dev] About Pharo 60

> On 28 Aug 2016, at 00:55, Cyril Ferlicot D. wrote: > > Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit : >> yes, some years ago I made a package for this. >> later Ben tried something similar with the user manager. >> none of those approaches worked as general

Re: [Pharo-dev] About better communication in the community

Hi, I think this is a great idea. Thanks for opening the issues. Now, the only question is where to put these. You suggest the package Manifest. I think this would work for individual packages, but as we are moving to projects (with Metacello), I would suggest to put these methods in the

<    1   2   3   4   5   6   7   8   9   10   >