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

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

by Tudor Girba

Hi, On 2 Mar 2012, at 21:17, HernÃ¡n Morales Durand wrote: > -An omnibrowser for OWL ontologies Just out of curiosity, what do you mean by this? Do you already have OWL ontologies implemented? Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

March 2, 2012

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

by Tudor Girba

Hi Stef, On 2 Mar 2012, at 13:11, StÃ©phane Ducasse wrote: > 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. Excellent. > 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. Even better :) > 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. I understand, but we need to start somewhere :) > 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. Ok. So I downloaded the first Pharo Core 1.4: https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip but, I still do not know what packages to load. Is there an easy way to figure these ones out (and in particular the loading order)? > 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). Exactly. If you tell me from which image to start and the list of packages I will try to go through this experience. But, I need help because I am an outsider when it comes to this problem. Cheers, Doru > > 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" >> > > -- www.tudorgirba.com "One cannot do more than one can do."

March 2, 2012

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

by HernÃ¡n Morales Durand

To dream is easy: -HDF5 (http://www.hdfgroup.org/HDF5/) support like PyTables or h5py for Python -Information Retrieval/Full Text Search package like Lucene ( http://lucene.apache.org/) -A binding to R or SAS or SPSS -Better or more semantic web support (see http://en.wikipedia.org/wiki/Web_Services_Resource_Framework#Implementations ) -An omnibrowser for OWL ontologies -CSS template system -Support of a Distributed Hash Table protocol like Pastry ( http://www.freepastry.org/) -Workflow system with designer and plug-in architecture (see http://www.taverna.org.uk/) -Big data CSV parser plugin -Plugin for fast approximate search in strings cheers, 2012/3/2 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > 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 > > -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Camillo Bruni

On 2012-03-02, at 20:09, Frank Shearar wrote: > On 2 March 2012 18:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2012-03-02, at 18:27, Frank Shearar wrote: >> >>> On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>> Sven, >>>> >>>> A Monticello mcz file is a version data base for a single package .... Git is a version data base for a directory structure ... >>>> >>>> Monticello has branching by convention (change the name of a file to create the branch), although the mcz ancestry handles branches just fine. In Git branches are first class objects ... it is difficult to do things in git if you are not on one branch or another ... >>> >>> Bearing in mind that a branch is just a pointer to a commit: look in >>> your blah/.git/refs/heads/ and each file is a branch containing the >>> SHA1 id of the head of that branch. (And each commit knows its >>> ancestor/s, just like an mcz file, except that the hash means the >>> relationship's based on the commit's _contents_, not its _name_.) >> >> that's right. However mcz store a bunch of redundant data in there by having the complete ancestor history in there. in git you only store the pointers / hashes to the immediate ancestors which is enough in most cases. >> >> right now we spend quite some time in just parsing the complete ancestor history, whereas this could be done lazily or in a more efficient format. > > But since there's nothing stopping you from losing an mcz (by accident > or on purpose: it's happened to me by accident), storing the entire > history lets you know _something_ about the history. Otherwise, with > the git-style pointer, you'd be screwed if you wanted history. "Oh, > where's this mcz? I have no idea, nor any idea where to look!" > > Of course it's not necessary to parse the whole lot, which I suspect > is what you mean by "lazy". right. I honestly don't care about the data being around ;) that is indeed a nice integrity property of an mcz version. But as igor pointed out, we should consider a slightly more efficient way of storing / retrieving data. the current approach is just too slow I think. I don't know what happens on server side of squeaksource, but is it easy to just add another entry to an mzc file? To me this seems like an easy solution to speed up MC quite a bit on Pharo but still keep it backwards compatible on other platforms. best cami

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Igor Stasenko

i'd rather ask, why you need to parse ancestry info, while other stuff is simply serialized and takes much less time to load. i don't think that size of history matters. the problem is that it matters when you using slow method(s) to load it. -- Best regards, Igor Stasenko.

March 2, 2012

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

by Igor Stasenko

the three buttons right to code pane is takin too much space.. i'd rather put them as an overlay on top of text pane. On 2 March 2012 20:48, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > >> ... >> >> One can tweak the code to show the first tree right upto a class level and >> eliminate the middle morph.. question of eliminating the unnecessary..!.. >> >> ... >> > -- Best regards, Igor Stasenko.

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Frank Shearar

On 2 March 2012 18:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-03-02, at 18:27, Frank Shearar wrote: > >> On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> Sven, >>> >>> A Monticello mcz file is a version data base for a single package .... Git is a version data base for a directory structure ... >>> >>> Monticello has branching by convention (change the name of a file to create the branch), although the mcz ancestry handles branches just fine. In Git branches are first class objects ... it is difficult to do things in git if you are not on one branch or another ... >> >> Bearing in mind that a branch is just a pointer to a commit: look in >> your blah/.git/refs/heads/ and each file is a branch containing the >> SHA1 id of the head of that branch. (And each commit knows its >> ancestor/s, just like an mcz file, except that the hash means the >> relationship's based on the commit's _contents_, not its _name_.) > > that's right. However mcz store a bunch of redundant data in there by having the complete ancestor history in there. in git you only store the pointers / hashes to the immediate ancestors which is enough in most cases. > > right now we spend quite some time in just parsing the complete ancestor history, whereas this could be done lazily or in a more efficient format. But since there's nothing stopping you from losing an mcz (by accident or on purpose: it's happened to me by accident), storing the entire history lets you know _something_ about the history. Otherwise, with the git-style pointer, you'd be screwed if you wanted history. "Oh, where's this mcz? I have no idea, nor any idea where to look!" Of course it's not necessary to parse the whole lot, which I suspect is what you mean by "lazy". frank > cami > >> >> frank >> >>> You can merge with Monticello and you can merge with Git ... >>> >>> The big difference is that Git allows you to version a bunch of files together and with Monticello you are versioning a single file. >>> >>> Part of what Metacello was invented to do was to create a "data base" of versioned collections of mcz files ... Git was designed to manage collections of files... >>> >>> Is this what you were asking? >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Sven Van Caekenberghe" <sven(a)beta9.be> >>> | To: Pharo-project(a)lists.gforge.inria.fr >>> | Sent: Friday, March 2, 2012 12:31:42 AM >>> | Subject: Re: [Pharo-project] Monticello Version Info >>> | >>> | >>> | 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 ? >>> | >>> | Sven >>> >> > >

March 2, 2012

Re: [Pharo-project] creating new projects on ss

by Camillo Bruni

use gemstone :) no? http://ss3.gemstone.com/ best cami On 2012-03-02, at 19:50, Usman Bhatti wrote: > I'm not sure if its Friday evening fatigue that is hitting me or a change in the server policy, squeak server is not allowing me to create new projects and giving me this message: > > On this server, only the administrator can create new projects! > > Is there an alternative for creating projects? > thanx > usman

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Camillo Bruni

On 2012-03-02, at 18:27, Frank Shearar wrote: > On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Sven, >> >> A Monticello mcz file is a version data base for a single package .... Git is a version data base for a directory structure ... >> >> Monticello has branching by convention (change the name of a file to create the branch), although the mcz ancestry handles branches just fine. In Git branches are first class objects ... it is difficult to do things in git if you are not on one branch or another ... > > Bearing in mind that a branch is just a pointer to a commit: look in > your blah/.git/refs/heads/ and each file is a branch containing the > SHA1 id of the head of that branch. (And each commit knows its > ancestor/s, just like an mcz file, except that the hash means the > relationship's based on the commit's _contents_, not its _name_.) that's right. However mcz store a bunch of redundant data in there by having the complete ancestor history in there. in git you only store the pointers / hashes to the immediate ancestors which is enough in most cases. right now we spend quite some time in just parsing the complete ancestor history, whereas this could be done lazily or in a more efficient format. cami > > frank > >> You can merge with Monticello and you can merge with Git ... >> >> The big difference is that Git allows you to version a bunch of files together and with Monticello you are versioning a single file. >> >> Part of what Metacello was invented to do was to create a "data base" of versioned collections of mcz files ... Git was designed to manage collections of files... >> >> Is this what you were asking? >> >> Dale >> >> ----- Original Message ----- >> | From: "Sven Van Caekenberghe" <sven(a)beta9.be> >> | To: Pharo-project(a)lists.gforge.inria.fr >> | Sent: Friday, March 2, 2012 12:31:42 AM >> | Subject: Re: [Pharo-project] Monticello Version Info >> | >> | >> | 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 ? >> | >> | Sven >> >

March 2, 2012

[Pharo-project] creating new projects on ss

by Usman Bhatti

I'm not sure if its Friday evening fatigue that is hitting me or a change in the server policy, squeak server is not allowing me to create new projects and giving me this message: On this server, only the administrator can create new projects! Is there an alternative for creating projects? thanx usman

March 2, 2012