August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] wish for Iceberg

by stepharo

My important wish for Iceberg is managing Pull Request. Now I think that we should let nicolas release a version before bombarding him about features. Le 29/8/16 Ã 22:11, Alexandre Bergel a Ã©crit : > 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. 30, 2016

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

by stepharo

Le 29/8/16 Ã 21:47, Yuriy Tymchuk a Ã©crit : > >> On 29 Aug 2016, at 21:41, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@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. It does. We want a real editor in Pharo. > > Uko > >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com <http://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 <mailto:Moose-dev@list.inf.unibe.ch> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >

Aug. 30, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

>> 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 done by PharoPro :) >> >> - image size management under control (as Philip already suggested) >> >> - better support for REST based systems (as Philip already suggested) Can you be clearer? Because I thought that Seaside-REST was good and you can apply to non Seaside Application. Then there is Teapot. As Pharo core I do not see why Zinc is not enough. Now fr Pharo Pro I could see. >> >> - modern "Material style" UI (as Philip already suggested) but >> additionally with >> better out of the box Spec support and examples for regular widgets >> (Accordion, draggable Toolbars, calendar widget, date/time >> picker, ...) >> >> - clear rules to not accept undocumented classes/packages in the image >> And a clear separation in packages between CORE/BASE stuff and >> TESTS on top. Tests are already separated. Do you have some places where this is not the case? >> Because TEST are usually only for development and for >> production/deployment of an app >> TESTS usually should be thrown out. >> >> Christmas list would include: >> - 64 Bit support This is not a christmas list. It should be threr for September. >> - an out of the box Pharo Pi VM + image on the website >> >> Bye >> T. >> >> > > >

Aug. 30, 2016

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