- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] wish for Iceberg

by Thierry Goubier

Hi Nicolas, Le 30/08/2016 Ã 01:18, Nicolas Passerini a Ã©crit : > > > On Mon, Aug 29, 2016 at 10:11 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@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). Why? If you integrate Iceberg like GitFileTree is (or reuse GitFileTree urls), then Metacello or Gofer will download (clone) git repositories and Iceberg should be able to work with them. Now, if in your sentence, I replace git by github (as in Metacello github:// urls), then it makes sense, yes. Thierry > 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. 30, 2016

[SO] X-509 certificates

by Max Leske

http://stackoverflow.com/questions/39210105/x-509-certificate-operations-wi…

Aug. 30, 2016

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