- Pharo-dev - lists.pharo.org

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

by 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 subscription We should probably do something special for 0 and 1 subscriptions. Stephan

Aug. 30, 2016

Re: [Pharo-dev] IceBerg and push for projects vs packages

by Dale Henrichs

On 8/29/16 8:12 AM, Esteban A. Maringolo wrote: > 2016-08-29 9:12 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: >> On Mon, Aug 29, 2016 at 2:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> On 29 Aug 2016, at 14:04, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >>>> >>>> On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini >>>> <npasserini(a)gmail.com> wrote: >>>>> Well, I am not sure if this has to do with Iceberg itself, because Iceberg >>>>> does nothing with dependencies. >>>>> >>>>> But I am not sure that a ConfigurationOfXXX really has information of only >>>>> one package. Normally you will have only one configuration for each project, >>>>> am I wrong? >>>>> Then the configuration specifies (among other stuff) dependencies between >>>>> the parts (packages) of your project... I think this is right. >>>>> If you depend in another project, then you should not depend in specific >>>>> packages but in another configuration. >>>> With the Iceberg tool, you can load or unload packages. >>>> How it will works if the dependencies are not loaded before ? >>> AFAIK, this is not iceberg concernâ¦ this is a work for metacello (or cargo). >> Yes you are right, but when you load a package from Iceberg, the >> dependencies should be loaded at the same time I guess. > No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello > for dependency management. A proper package manager (Cargo?) should > coordinate artifacts of both. > > Christophe and I are talking about the fact that there is overlap between Cargo and Metacello with regards to dependency management ... We'll see how things evolve ... Dale

Aug. 29, 2016

Re: [Pharo-dev] IceBerg and push for projects vs packages

by Nicolas Passerini

> > >>> With the Iceberg tool, you can load or unload packages. > >>> How it will works if the dependencies are not loaded before ? > >> > >> AFAIK, this is not iceberg concernâ¦ this is a work for metacello (or > cargo). > > > > Yes you are right, but when you load a package from Iceberg, the > > dependencies should be loaded at the same time I guess. > > No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello > for dependency management. A proper package manager (Cargo?) should > coordinate artifacts of both. > > > I think I agree with both Estebans, I hope that Metacello/Cargo will use Iceberg to load packages, but it should be their responsibility to decide which packages and versions to load.

Aug. 29, 2016

Re: [Pharo-dev] wish for Iceberg

by Nicolas Passerini

On Mon, Aug 29, 2016 at 10:11 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > It would be great to be able to save the repositories on the disk, > somewhere. And to not have to type them all the time. > You're right, this is already in my backlog. This is good feedback because now I can prioritize it better. > > Also, if I install a git repository, I would like to be able to commit / > push after modifying it. > > This is a bit more difficult, because (if I understand what you mean) you have a git repo that you probably downloaded with Gofer or Metacello. So Iceberg can not use it for committing/pushing (because it is not a real git repo). I have been talking with Dale and Cristophe, so that Metacello and Cargo will use Iceberg for downloading git repos... so you will not have that problem any more. Still, it might be a while until those changes are integrated in Metacello (I think). So in the meantime I can build a tool to convert a git metacello-downloaded MCRepository to an Iceberg repository in a simple way. Do you think it would be useful?

Aug. 29, 2016

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

by Tudor Girba

> On Aug 29, 2016, at 10:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > 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 OrderedCollection and just check if it includes the subscription before adding. I think that more events are fired than clients are subscribed per a period of time > > > It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription +1 Doru -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

Aug. 29, 2016

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

by Denis Kudriashov

2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > 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 OrderedCollection and just check if it includes > the subscription before adding. I think that more events are fired than > clients are subscribed per a period of time > > It looks quite safe to not check anything because subscription items are instances of AnnouncementSubscription which are created internally inside Announcer during subscription

Aug. 29, 2016

wish for Iceberg

by Alexandre Bergel

Hi! It would be great to be able to save the repositories on the disk, somewhere. And to not have to type them all the time. Also, if I install a git repository, I would like to be able to commit / push after modifying it. Cheers, Alexandre

Aug. 29, 2016

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

by Yuriy Tymchuk

> On 29 Aug 2016, at 21:37, Tudor Girba <tudor(a)tudorgirba.com> 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 in Announcements. > 2. they are unsafe. > > 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 OrderedCollection and just check if it includes the subscription before adding. I think that more events are fired than clients are subscribed per a period of time Uko > > For 2. the question is if Bloc really does not need the mutex. > > Cheers, > Doru > > > >> On Aug 29, 2016, at 6:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> 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 is unsafe because event handlers can be modified during delivering (by producing new subscriptions or by unsubscribing inside handlers). >> >> So if you want to address it (and I sure you do) it will lead to same code and performance of announcements. >> >> >> >> >> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> 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 identitySet has no sense. >> >> Another problem is access protection by mutex (semaphore) which make it 3 times slower. >> >> So with OrderedCollection and disabled mutex performance for subscribing is same. >> >> I pretty sure that protection is required for Block handlers too. >> >> 2016-08-29 17:18 GMT+02:00 Glenn CavarlÃ© <glenn.cavarle(a)gmail.com>: >> 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. >> BlAnnouncerVsBlEventRegistryTest browse >> >> >> >> >> ----- >> Glenn CavarlÃ© >> -- >> View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > >

Aug. 29, 2016

Re: [Pharo-dev] [Moose-dev] [ann] pillar support in gtinspector

by Yuriy Tymchuk

> On 29 Aug 2016, at 21:41, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this: > > Gofer new > smalltalkhubUser: 'Moose' project: 'PetitParser'; > package: 'PetitAnalyzer'; > package: 'PetitIndent'; > package: 'PetitIslands'; > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load > > Then you can just inspect a book folder and you get this: > > <inspector-pillar.png> Cool! > > I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes. > > It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. To make things sadder: when I need to write some short ârichish" Iâm using markdown instead for pillar because in ATOM I can open the rendered version of my document that will update while i type (and will display images and so on). It could be nice to have the same functionality in Pharo, but Iâm really busy with improving other parts. Additionally Iâm not sure that it makes sense to reimplement rich text editor in Pharo. Uko > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Aug. 29, 2016

[ann] pillar support in gtinspector

by Tudor Girba

Hi, I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this: Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load Then you can just inspect a book folder and you get this: I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes. It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Aug. 29, 2016