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

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

by Igor Stasenko

On 2 March 2012 09:05, Marcus Denker <marcus.denker(a)inria.fr> 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. > >> 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. > ROFL :) > Â Â Â Â Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

March 2, 2012

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

by Marcus Denker

On Mar 2, 2012, at 2:38 PM, Tudor Girba wrote: > > That is even better. But, even without, I think that the current image > can be loaded quite fast if we work on it. > > So, how can I find/obtain a seed image? > https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%201.4/ reload worked last time in september, though... https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ ??? all a bit broken right now, because keeping shrink scripts current is nearly impossible. Marcus -- Marcus Denker -- http://marcusdenker.de

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Sebastian Sastre

+1 it would feel right (about timing) sebastian 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] pharo-seed and pharo

by Tudor Girba

Hi, On Fri, Mar 2, 2012 at 2:34 PM, 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. That is even better. But, even without, I think that the current image can be loaded quite fast if we work on it. So, how can I find/obtain a seed image? Cheers, Doru >> 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" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 2, 2012

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

by Camillo Bruni

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. > 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

Re: [Pharo-project] Monticello Version Info

by Camillo Bruni

On 2012-03-02, at 09:31, Sven Van Caekenberghe wrote: > > On 02 Mar 2012, at 01:52, Chris Cunningham wrote: > >> The issue is that Monticello is setup for distributed processing, and >> allowing for multiple repositories, some of which may not be available >> to all of the users for a project. For instance, a project might be >> developed internally (or on the developers hard-drive) until they feel >> comfortable distributing the code later. So, publicly, you get >> version 12, 17, 34, and 37. There is no access to the intermediate >> ones (unless you happen to be the one that created them and didn't >> release them). The 'whole ancestry' let's you do diffs off of a >> version derived from 37 against one derived from 34 - the ancestry can >> determine that version 34 if 'common', and work from there. [Note >> that just numbers aren't enough - the original developer, say, cbc >> could have version cbc.34, while you could have, say, CamilloBruni.34, >> but yours is based off of 17 (since you picked up that verison and >> started working there). So, merging cbc.37 with CamilloBruni.34 would >> need to pull down cbc.17 for a good merge to work.] >> >> At least, that's my understanding from long ago discussions. > > This makes sense, but how is this handled with git ? Git always publishes all versions (unless you squash multiple versions on purpose): - generally you work and commit locally for quite some time - then you pull the latest changes from a common / remote repository - you merge with that repository The main diff to MC is that git will publish all intermediate versions as well, you can see an example of that here: https://github.com/dh83/trex/network - two people worked on the project [ black / blue ] - the blue version development happened in a different / local repos - yet all the intermediate versions between merge points are in the main [black] repos so, chris, you're absolutely right, that if you want to be able to diff against the local history you need the complete history. 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. having that I would say it would suffice to publish all the intermediate versions to a remote repository to get a complete and nice diff behavior with MC, no? most probably I am missing a piece here ;) best cami

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Esteban Lorenzano

+1 El 02/03/2012, a las 6:17a.m., Norbert Hartl escribiÃ³: > > > > > Am 02.03.2012 um 09:48 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi guys >> >> I would like to see Pharo 1.4 going beta = >> focus on bugs, less changes. >> >> Does it make sense? > > Of course. And you know this. Release early, release often is also valid for pharo. And is not done, you just tell everyone else to do it like this ;) > > Norbert >> >> What are the key problems we should focus on? >> >> Stef >> >> >> >

March 2, 2012

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

by StÃ©phane Ducasse

Hi doru We already changed to build not from a snapshot (the one published on regular basis but manually by marcus) but from the latest jenkins build. Like that we do not need to load a bunch of versions. In addition benjamin showed to marcus the tools he built with camillo to support integration. I should sync with them because we would like to have more and more tools to help us avoiding manual work and that other people can review fixes and press the button ok without stress, like that sven, alain, ben, igor can integrate without stress. Now for the smaller image: Context: we need to see because we cannot simply take a small image and load the latest packages. Why? because some changes were made knowing that the system was in a given state. I hope that in the future we will always be able to load from the latest package versions but this is not as simple as that. Exp1: Now we can try and see. For example if we take the first 1.4alpha and load the list of packages listed in the latest versions of scriptLoader package. This could show some potential problems to upgrade directly to the latest versions of packages. If you want to help this would be a cool experience to do. With script loader you can simple ask scriptLoader to load a set of packages. Exp2: The second step is to see if it makes sense to manage Core Image with Metacello or if in addition to the list of packages we can load the tools manage with metacello (notice that it would mean also the packages that we will move out of current core): How much times does it take to load the packages and projects of tools that would be in Pharo (not Core) and check the time to do it. We can measure that from a version of core that we consider as a potential seed and/or with a version that would get some stuff loaded (and would correspond to the latest build). Stef On Mar 2, 2012, at 10:06 AM, 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 > > 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

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

by StÃ©phane Ducasse

it looks cool. Continue to polish it because it could be a nice alternative. Stef On Mar 2, 2012, at 10: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] CRC in System-Hashing?

by StÃ©phane Ducasse

Sounds good to me. Now for 1.5 alpha :) Stef On Mar 2, 2012, at 10:21 AM, Max Leske 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 > > 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