March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Sebastian Sastre

it sounds like having a couple interesting features. In system browsers I always felt missing the feature of a good tree component (where the whole hierarchy is always available) while finding the packages pane a terrible use of screen's real state. How can I install this to play around? sebastian o/ On Mar 2, 2012, at 6:54 AM, S Krish wrote: > Couple of screenshots of a usable code browser, does well for my use > for now.. need to bring in the basic refactoring, variables text box > under the class tree, in the middle. > > Feels lot more productive in combination with the standard browsers > where needed. > > On 2/29/12, Krishsmalltalk <krishnamachari.sudhakar(a)gmail.com> wrote: >> >> Sure I understood that, I am still just month and a half of dabbling in >> morphic, that i am still learning.... I do not take any comments amiss. >> >> Thx >> >> >> On Feb 29, 2012, at 5:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> I was not criticizing your solution. I was actually asking for help :). >>> >>> I would like to get a text morph in the tree and have it scale both >>> horizontally to fill the available space, and vertically to >>> accommodate the entire text. I show the example with the >>> GeneralScrollPane because I managed to make it work there (with the >>> help of Gary), but I cannot do it on MorphTreeMorph. So, if you, or >>> someone else, have ideas I would be happy to hear them. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Feb 28, 2012 at 10:09 AM, S Krish >>> <krishnamachari.sudhakar(a)gmail.com> wrote: >>>> Sure.. that is fine.. for the use case you state >>>> >>>> Mine is quick n dirty hack to what I wanted: >>>> >>>> but my use case is I do wish to have more of these sources partially >>>> visible >>>> through the vertical pane. so I restrain it to max of 210.. and width of >>>> 600 >>>> to be able to to throw up another pane next to it.. for grouping methods >>>> I >>>> am interested in .. to view it more closely.. >>>> >>>> >>>> >>>> On Tue, Feb 28, 2012 at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the explanation. >>>>> >>>>> I took a look. calculateExtent is triggered when you create the >>>>> TextMorph. >>>>> This is nice, but I am interested in getting the TextMorph to always >>>>> expand >>>>> to fill the width of the surrounding element, and to expand vertically >>>>> according to the text :). >>>>> >>>>> Here is a variation of what I am thinking about with just a simple list >>>>> of >>>>> morphs within a GeneralScrollPane: >>>>> https://gist.github.com/1930477 >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On 28 Feb 2012, at 03:22, Krishsmalltalk wrote: >>>>> >>>>>> It does have the code to calculateTextExtent. You can modify it the way >>>>>> you want. >>>>>> >>>>>> The height is defaulted to a max 210 and fixed 600. But on expand it >>>>>> goes to max ht of 600 >>>>>> >>>>>> >>>>>> Modify the logic in that method as you want it to >>>>>> >>>>>> >>>>>> On Feb 28, 2012, at 2:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I gave it a try. I am not necessarily looking for the looks as for the >>>>>>> solution to make the text editor within the tree span horizontally and >>>>>>> vertically with the size of the method. Unfortunately, this does not >>>>>>> work in >>>>>>> this example, either. >>>>>>> >>>>>>> Does anyone have ideas of how to make it work? :) >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On 27 Feb 2012, at 21:43, StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> MorphicViewNewPackageBrowser new packageNames: #('UIManager') ; open >>>>>>>> >>>>>>>> >>>>>>>> But it does not look that nice :) >>>>>>>> >>>>>>>> >>>>>>>> On Feb 27, 2012, at 6:42 PM, StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>>> this looks really nice. >>>>>>>>> I would really like to see if we cannot include a version so that >>>>>>>>> people can browse change set and other code like that. >>>>>>>>> I'm really happy to see that the work done by alain and ben around >>>>>>>>> treeMorph pays off that well. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>>> Can take the latest of the package.. >>>>>>>>>> >>>>>>>>>> PackageTree-Browser-Experiment >>>>>>>>>> >>>>>>>>>> * Find class added and a crude/ workable expand for text morph.. >>>>>>>>>> >>>>>>>>>> As stated in the comments: will require a hack in Pharo 1.4 for >>>>>>>>>> now. >>>>>>>>>> >>>>>>>>>> Will work towards integrating TabbedPane with TWM/ this too as an >>>>>>>>>> addon with more complete features month ahead. >>>>>>>>>> <Pharo_CodeBrowser02.JPG> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "One cannot do more than one can do." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Sometimes the best solution is not the best solution." >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> > <Pharo_Tabbed_TreeCodeBrowser01.JPG><Pharo_Tabbed_TreeCodeBrowser02.JPG>

March 2, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by blake

I like that! On Fri, Mar 2, 2012 at 1:54 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > Couple of screenshots of a usable code browser, does well for my use > for now.. need to bring in the basic refactoring, variables text box > under the class tree, in the middle. > > Feels lot more productive in combination with the standard browsers > where needed. > > On 2/29/12, Krishsmalltalk <krishnamachari.sudhakar(a)gmail.com> wrote: >> >> Sure I understood that, I am still just month and a half of dabbling in >> morphic, that i am still learning.... Â I do not take any comments amiss. >> >> Thx >> >> >> On Feb 29, 2012, at 5:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> I was not criticizing your solution. I was actually asking for help :). >>> >>> I would like to get a text morph in the tree and have it scale both >>> horizontally to fill the available space, and vertically to >>> accommodate the entire text. I show the example with the >>> GeneralScrollPane because I managed to make it work there (with the >>> help of Gary), but I cannot do it on MorphTreeMorph. So, if you, or >>> someone else, have ideas I would be happy to hear them. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Tue, Feb 28, 2012 at 10:09 AM, S Krish >>> <krishnamachari.sudhakar(a)gmail.com> wrote: >>>> Sure.. that is fine.. for the use case you state >>>> >>>> Mine is quick n dirty hack to what I wanted: >>>> >>>> but my use case is I do wish to have more of these sources partially >>>> visible >>>> through the vertical pane. so I restrain it to max of 210.. and width of >>>> 600 >>>> to be able to to throw up another pane next to it.. for grouping methods >>>> I >>>> am interested in .. to view it more closely.. >>>> >>>> >>>> >>>> On Tue, Feb 28, 2012 at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the explanation. >>>>> >>>>> I took a look. calculateExtent is triggered when you create the >>>>> TextMorph. >>>>> This is nice, but I am interested in getting the TextMorph to always >>>>> expand >>>>> to fill the width of the surrounding element, and to expand vertically >>>>> according to the text :). >>>>> >>>>> Here is a variation of what I am thinking about with just a simple list >>>>> of >>>>> morphs within a GeneralScrollPane: >>>>> https://gist.github.com/1930477 >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> On 28 Feb 2012, at 03:22, Krishsmalltalk wrote: >>>>> >>>>>> It does have the code to calculateTextExtent. You can modify it the way >>>>>> you want. >>>>>> >>>>>> The height is defaulted to a max 210 and fixed 600. But on expand it >>>>>> goes to max ht of 600 >>>>>> >>>>>> >>>>>> Modify the logic in that method as you want it to >>>>>> >>>>>> >>>>>> On Feb 28, 2012, at 2:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I gave it a try. I am not necessarily looking for the looks as for the >>>>>>> solution to make the text editor within the tree span horizontally and >>>>>>> vertically with the size of the method. Unfortunately, this does not >>>>>>> work in >>>>>>> this example, either. >>>>>>> >>>>>>> Does anyone have ideas of how to make it work? :) >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On 27 Feb 2012, at 21:43, StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> MorphicViewNewPackageBrowser new packageNames: #('UIManager') ; open >>>>>>>> >>>>>>>> >>>>>>>> But it does not look that nice :) >>>>>>>> >>>>>>>> >>>>>>>> On Feb 27, 2012, at 6:42 PM, StÃ©phane Ducasse wrote: >>>>>>>> >>>>>>>>> this looks really nice. >>>>>>>>> I would really like to see if we cannot include a version so that >>>>>>>>> people can browse change set and other code like that. >>>>>>>>> I'm really happy to see that the work done by alain and ben around >>>>>>>>> treeMorph pays off that well. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>>> Can take the latest of the package.. >>>>>>>>>> >>>>>>>>>> PackageTree-Browser-Experiment >>>>>>>>>> >>>>>>>>>> * Find class added and a crude/ workable expand for text morph.. >>>>>>>>>> >>>>>>>>>> As stated in the comments: will require a hack in Pharo 1.4 for >>>>>>>>>> now. >>>>>>>>>> >>>>>>>>>> Will work towards integrating TabbedPane with TWM/ this too as an >>>>>>>>>> addon with more complete features month ahead. >>>>>>>>>> <Pharo_CodeBrowser02.JPG> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "One cannot do more than one can do." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Sometimes the best solution is not the best solution." >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Chris Cunningham

On Fri, Mar 2, 2012 at 5:30 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > But I am not completely sure how the internals work with MC, but from my research > so far I am almost convinced that versions are found merely by their name. Since > the VersionInfo does not track the repository it relates to. > It does appear to find versions by name, but there is an internal id number that it uses to validate the file is the right one. I've been 'bitten' by this a few times - it is a really good idea to NOT rename MCZ files.

March 2, 2012

Re: [Pharo-project] CRC in System-Hashing?

by Max Leske

Oops! #hashStream: *does* actually take a streamâ¦ #hashMessage: takes a string or a ByteArray and sends #readStream to the argument. So: different proposal: drop #hashMessage: completely. Instead add: SHA1 class>>hashStream: aPositionableStream ^ self new hashStream: aPositionableStream; yourself Thanks Igor for unintentionally bumping me in the head :) On 02.03.2012, at 15:03, Igor Stasenko wrote: > On 2 March 2012 10:21, Max Leske <maxleske(a)gmail.com> wrote: >> Thanks for the responses. >> >> I'll wait a little longer and see if Rob has anything to say about this. >> Otherwise I will do what Henrik suggests: >> >> deprecate SecureHashAlgorithm (why not remove it completely?) >> refactor users of SecureHashAlogrithm to use SHA1 instead >> add CRC to SystemHashing (possibly a copy from Cryptography) >> refactor the Zip implementation to use the new CRC class >> deprecate crc methods in Zip implementation >> >> >> I actually like #hashMessage: better than #hashStream:. #hashStream: says to >> my "I expect a stream as my argument" where in reality it will take a string >> or a ByteArray (neither of which is obviously a streamâ¦). >> What I found irritating though was that one has to send #new to >> SecureHashAlgorithm first before hashing. So I propose to keep #hashMessage: >> but to move it to the class side of SHA1: >> >> SHA1 class>>hashMessage: aStringOrByteArray >> ^ self new >> hashStream: aStringOrByteArray; >> yourself >> > > hmm.. #hashMessage: sounds a bit weird to my taste. > maybe #hashCollection: then? > >> Cheers, >> Max >> > > -- > Best regards, > Igor Stasenko. >

March 2, 2012

[Pharo-project] loading nautilus

by Tudor Girba

Hi, I am trying to load Nautilus in 1.4, but there seems to be a problem with the configuration. I run: Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) loadRelease. But, the Growl dependency is incorrect: spec project: 'Growl' with:[ spec repository: 'http://www.squeaksource.com/Growl'; package: 'Growl' ]. We could create a ConfigurationOfGrowl, or just load the package directly: spec package: 'Growl' with: [spec repository: 'http://www.squeaksource.com/Growl' ]. Which one do you prefer? Btw, the Moose build is failing because of this :). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Guillermo Polito

+1 On Fri, Mar 2, 2012 at 10:40 AM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > +1 > > it would feel right (about timing) > > sebastian <http://about.me/sebastianconcept> > > o/ > > On Mar 2, 2012, at 5:48 AM, StÃ©phane Ducasse wrote: > > Hi guys > > I would like to see Pharo 1.4 going beta = > focus on bugs, less changes. > > Does it make sense? > > What are the key problems we should focus on? > > Stef > > > > > > > >

March 2, 2012

Re: [Pharo-project] CRC in System-Hashing?

by Guillermo Polito

Sorry, I couldn't resist :$ On Fri, Mar 2, 2012 at 6:21 AM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the responses. > > I'll wait a little longer and see if Rob has anything to say about this. > Otherwise I will do what Henrik suggests: > > - deprecate SecureHashAlgorithm (why not remove it completely?) > - refactor users of SecureHashAlogrithm to use SHA1 instead > > http://code.google.com/p/pharo/issues/detail?id=5427&thanks=5427&ts=1330699… > > - add CRC to SystemHashing (possibly a copy from Cryptography) > - refactor the Zip implementation to use the new CRC class > - deprecate crc methods in Zip implementation > > http://code.google.com/p/pharo/issues/detail?id=5426&thanks=5426&ts=1330699… Guille > > I actually like #hashMessage: better than #hashStream:. #hashStream: says > to my "I expect a stream as my argument" where in reality it will take a > string or a ByteArray (neither of which is obviously a streamâ¦). > What I found irritating though was that one has to send #new to > SecureHashAlgorithm first before hashing. So I propose to keep > #hashMessage: but to move it to the class side of SHA1: > > SHA1 class>>hashMessage: aStringOrByteArray > ^ self new > hashStream: aStringOrByteArray; > yourself > > Cheers, > Max > > > On 02.03.2012, at 09:46, Henrik Johansen wrote: > > > On Mar 2, 2012, at 9:05 AM, Marcus Denker wrote: > > > On Mar 2, 2012, at 8:19 AM, Max Leske wrote: > > > I need to calculate CRC for Git and couldn't find it in the system > packages (I guess I'd find it in Cryptography). Since Pharo has a system > package called "System-Hashing" I was wondering if anyone sees a reason why > CRC should not be part of that package. That would also allow the Zip > implementation to use the system CRC function (at the moment Zip implements > its own CRC check). > > > Yes, that would be nice. But people will yell at you for making Pharo > bloated and going in the completely wrong direction and > > that you should and never ever add any code. > > > Decomposing != Bloating. > As long as you refactor the current users (which currently use the > implementation in ZipWriteStream) to use the new CRC class, it should be > fine. > I would suggest deprecating the class method in ZipWriteStream rather than > removing it though, based on the users in image, it is a likely method to > be in use by external packages doing CRC calculations. > > It also seems the primitive for updating CRC is not reliant on the > CrcTable class var, so should be safe to use in new class' method as well. > > > Another thing: going through Sytem-Hashing I noticed that there are two > implementations for SHA1: "SHA1" and "SecureHashAlgorithm". They both have > the exact same class comment but vary slightly in the messages they > implement (although most of them are present in both classes). Can we > remove one? > > > Yes. But for sure someone will yell at you if you remove it, because the > system should be stable and not force people to > > change their code. > > > IIRC, it was initially included as SecureHashAlgorithm, being renamed when > imported from the Cryptography package. > To allow existing packages relying on Crypto to load cleanly, SHA1 was > later also included. > > As there are already other name clashes with the Crypto package (MD5 for > instance) I would vote for deprecating SecureHashAlgorithm. > (SHA1 is arguably a more descriptive name anyways) > Not sure if it's worth including hashMessage: in SHA1, it's just a utility > method. > > Cheers, > Henry > > > > >

March 2, 2012

[Pharo-project] Project ideas for GSoC, 7 days left!

by Janko MivÅ¡ek

Hi everyone, 7 days to deadline for ideas of this year GSoC! Please think about what would be a nice project for students to work and that way join our community. And yes, students are welcome to propose projects too! Let we "recycle" past project ideas too! Please review them and propose those still valuable. Or change the proposal to suit better. Here they are: http://gsoc2010.esug.org/ideas . Let me and Carla post GSoC related stuff only on Pharo, Squeak and VWNC mailing lists while for other let someone forward those mails there please. It is just too hard to post on 10+ mailing lists, you know... Past GSoC mentors please join the debate on special Smalltalk GSoC mentors list: http://groups.google.com/group/smalltalk-gsoc-mentors. If you want to be mentor this year you are welcome to join that list too. Best regards Janko S, Janko MivÅ¡ek piÅ¡e: > Dear Smalltalkers, > > Let we apply this year again for the Google Summer of Code, which as you > know is a Google's stipendium program for students to encourage them > working on open-source projects [1]. > > Ok, our first step as community is to collect ideas for possible > projects and to apply to the GSoC as an organization. Deadline is next > Friday, so please hurry on with ideas. Just put them as reply to this > email or to admins directly and we will put them on our website [2]. > > Your project idea should be written as answers to these questions: > > Name > Level (Beginner, Intermediate, Advanced) > Possible mentor > Possible second mentor > > Description > Technical Details > Benefits to the Student > Benefits to the Community > > > See how such ideas look like in past: http://gsoc2010.esug.org/ideas. > > Waiting for your ideas > Carla and Janko, your GSoC Admin team > > [1] http://www.google-melange.com/gsoc/homepage/google/gsoc2012 > [2] http://gsoc2012.esug.org > -- Janko MivÅ¡ek Smalltalk GSoC Admin Team http://gsoc2012.esug.org

March 2, 2012

Re: [Pharo-project] CRC in System-Hashing?

by Igor Stasenko

On 2 March 2012 10:21, Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the responses. > > I'll wait a little longer and see if Rob has anything to say about this. > Otherwise I will do what Henrik suggests: > > deprecate SecureHashAlgorithm (why not remove it completely?) > refactor users of SecureHashAlogrithm to use SHA1 instead > add CRC to SystemHashing (possibly a copy from Cryptography) > refactor the Zip implementation to use the new CRC class > deprecate crc methods in Zip implementation > > > I actually like #hashMessage: better than #hashStream:. #hashStream: says to > my "I expect a stream as my argument" where in reality it will take a string > or a ByteArray (neither of which is obviously a streamâ¦). > What I found irritating though was that one has to send #new to > SecureHashAlgorithm first before hashing. So I propose to keep #hashMessage: > but to move it to the class side of SHA1: > > SHA1 class>>hashMessage: aStringOrByteArray > ^ self new > hashStream: aStringOrByteArray; > yourself > hmm.. #hashMessage: sounds a bit weird to my taste. maybe #hashCollection: then? > Cheers, > Max > -- Best regards, Igor Stasenko.

March 2, 2012

Re: [Pharo-project] pharo-seed and pharo

by Frank Shearar

On 2 March 2012 13:34, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-03-02, at 10:06, Tudor Girba wrote: > >> Hi, >> >> I believe everyone agrees that one important goal in Pharo is to get >> to a small code/kernel/seed. During the Pharo Sprint at Bern we saw >> that the only reason for now having a unified image is just a >> temporary convenience that stems from two things: >> 1. Until Pharo 1.3, the core team worked in the core image, and this >> was frustrating because they were missing proper tools >> 2. After 1.3, building a pharo image out of a seed image was perceived >> as being too long and not fitting for the process of integration > > this mainly comes from the fact that MC is not particularly fast. > I was recently amazed how fast simple CS loading is compared to the same > with a SLICE. So I think that rebuilding a dev image from a core image > might even work locally given that MC can be made 10 to 100 times faster. > > I recently made updates on my machines some 10 times faster by actually > using the package-cache and not always reloading the versions from the > remote server! So MC has quite some room for performance improvements. To be fair, that's not MC's fault. A usability fault, perhaps. When you load a package you load from a repository. Your package-cache is but one such repository. Metacello will (Dale can correct me as necessary!) check your package-cache before downloading something, if it's configured correctly in some ConfigurationOfFoo. So I guess what I'm saying is that the tools _around_ MC might need adjusting, but otherwise MC's just doing what you tell it to do! I don't want to give the impression that I have it perfect, but if you look at http://www.squeaksource.com/MetacelloRepository/ConfigurationOfSqueakCheck-… you'll see in the #ensureMetacello how to make your configuration use the package-cache. (It's not just performance either: using the package-cache first lets you work offline, provided you have a properly populated package-cache. For me, working offline is crucial: a lot of my Smalltalk hacking happens on my train commute.) frank >> It's clear that the core team needs development tools. However, we >> think that 2 can be actually quite cheap if the build starts from the >> latest seed, and not from the original seed of 1.4 as it currently >> seem to happen. If this would be fast, we could go back to having one >> seed image (I call it seed just to avoid confusion and wrong feelings, >> but you can call it anyway you want) out of which the Pharo >> distribution (like the current image is) is built. The core team would >> work on this distribution, and Jenkins would do the rest. By switching >> the distribution build to work with the latest seed, we can probably >> reduce the amount of build time to a couple of minutes (at least this >> is what we saw during a couple of quick tests). >> >> Regarding the flow of the integrator, we saw that actually, when >> multiple changes need to be integrated, you can base the second change >> on the image that already exists locally, without needing to wait >> until Jenkins finishes. >> >> I would be interested in providing help. So, what do you say? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

March 2, 2012