February 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN 1.1] pre-built Core#11229

by Marcus Denker

http://gforge.inria.fr/frs/download.php/26457/PharoCore-1.1-11229-UNSTABLE.… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 23, 2010

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by Gary Chambers

Some kind of graph-based GUI would certainly help in this scenario to visualise the dependencies/changes... just a thought. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 23, 2010 4:02 PM Subject: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system) > Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, > which came into my mind, when i complete coding the method trailers. > > I made a method trailers open for future extensions. > A first step would be to introduce an abstract 'source management' > layer, which will be responsible for delivering > a method's and classes sources from some abstract data source. The > next step is actually implement such data sources. > > So, the idea is to abandon hardwiring with .sources and .changes files. > What new opportunities it gives to us? > Suppose that instead of storing sources into file, you putting them > directly to database , such as CouchDB (yes! :). > > Now if you imagine that anyone could access to this database on some > public location, this means that we automagically made a source code > exchange hub, and could do a very cool things with it. > > Suppose that ALL source code is put into a single database. Now > different users creating own accounts and makind own 'forks' from > original. What we getting is a number of update streams (methods, > doits etc etc), which lying in those databases, > and if one user wants to load/merge code from one of the sources he > simply points to it and it get loaded into his image. > We could organize things very closely to what github currently is: > everyone could create any number of new projects, or forks of existing > ones. Freely exchange the code, do a cherry picking etc etc. > And what is most important, that with such organization you can track > any methods, classes in the image and their evolutionary history back > to its origin. As well as, you can query database, how an when a > concrete method/class get deleted (everything is recorded, not just > current state). > > Also, it would allow us to manipulate the code at the lowest level of > granularity (individual methods/classes/doits, same as DS does), not > at a package level. > There are a lot of synergy with DeltaStreams - it could serve as an > 'offline' format, in same way as git storing the files locally, but > can reconnect with remote storage (which can be a public database). > One of the things, which could be made is to allow stashing/popping > code from stash. Suppose two projects started from a single starting > point (Squeak 3.9). Now suppose that by clicking a single button you > could get either trunk image, or Pharo 1.0 image. > But that's not all! With DeltaStreams, you could then click once more, > and revert things back from , say Pharo 1.0 to trunk or vice versa :) > Of course it would be stupid to do things at such large scale, but if > we put some common 'root' stuff into database, then we could very > easily track all changes & compare them. This would make cherry > picking and code exchange much more easier. > > This could get us on the next level of code management and system > organization and organization of community efforts. > > > > 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se>: >> Hi! >> >> GermÃ¡n Arduino wrote: >>> Hi GÃ¶ran: >>> >>> Sorry by my intromision here, but want to say somethings :) >>> >>> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se <mailto:goran@krampe.se>> >> [SNIP] >>> What I have seen so far in Metacello is indeed nothing new - the >>> senarios and discussions about dependencies etc go loooong way back. >>> >>> >>> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >>> packages, >>> etc, but only discussions on most of cases. I think Metacello solves the >>> dependencies >>> questions very well and the other tools not (with exception of Universes >>> probably, but >>> abandoned now). Also Metacello provides all the features explained on >>> the excellent >>> mail of Torsten, assuring that the configurations will work with the >>> time not breaking >>> stuffs. >>> >>> The solution of using Metacello+Monticello is, imho, very simple, easy >>> and productive >>> and is here, available to us. :) >> >> I never claimed otherwise! I am just saying that there is nothing new - >> and frankly, though I admit not having read carefully, I didn't find the >> example so... impressive. Perhaps I need to read it again. >> >> Again though - I am not saying anything negative about Metacello. >> >> [SNIP] >>> Anyway, "common exchange mechanism" - I am working on Deltastreams which >>> I even presented at Brest, though unfortunately colliding with the >>> Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >>> this problem (fork interchange), and it was born in 2007: >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… >>> >>> I and Igor are the ones working on it - and after Brest we have had very >>> little time to move it forward. I still think it is a very important >>> piece of the puzzle though. >>> >>> But Deltastreams are ready to use on production systems? >> >> Nope, not yet, although very close. But since the topic came up I wanted >> to mention it. But AFAIK there is no other tool/project aimed at that >> use case. Again, I may be wrong :) >> >> regards, GÃ¶ran >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Pharo won't make a VM in linux

by Javier PimÃ¡s

Made some tests to find out what is happening, and found the problem. I can confirm that this happens both in squeak and pharo. The thing is that B3DAccelerator doesn't work as internal plugin in unix. Making it external worked fine. This lead me to some questions: - To make it work as internal the only thing needed is to add that -lGL to the linking process. Does anybody know how to modify the cmake files to do that? Maybe it's just a thing of adding a line to unix/plugins/B3DAcceleratorPlugin/config.cmake or unix/vm/config.cmake?? - Does anybody build the VM in unix? using cmake? Regards, Javier. On Mon, Feb 22, 2010 at 1:07 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com>wrote: > I'm cross-posting to vm-dev because I get the same errors with Squeak > 3.10.2.7179 image. I have > > GL_VERSION = 3.2.0 NVIDIA 190.53 > > After navigating trough the makefiles, I found I was right, it's not > linking to opengl. The linking command was autogenerated and sitting in > blddir/CMakeFiles/squeakvm.dir/link.txt. Adding -lGL to it solved that > problem. Does anybody know what caused the missing "-lGL" and how to solve > it? > > Now I can get back to trying to compile alien! > > Regards, > Javier. > > > > But I don't think it's a version problem, these undefined functions are > there since OpenGL 1. the > > On Sun, Feb 21, 2010 at 4:27 PM, Martin McClure <martin(a)hand2mouse.com>wrote: > >> Javier PimÃ¡s wrote: >> > >> > Linking C executable squeakvm >> > >> > >> > B3DAcceleratorPlugin/libB3DAcceleratorPlugin.a(sqOpenGLRenderer.c.o): In >> > function >> > `glRenderVertexBuffer': >> > >> > >> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:846: >> > undefined reference to >> > `glColorMaterial' >> > >> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:847: >> > undefined reference to >> > `glGetError' >> > >> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:848: >> > undefined reference to >> > `glEnable' >> > >> /home/javier/st/squeak-svn/platforms/Cross/plugins/B3DAcceleratorPlugin/sqOpenGLRenderer.c:849: >> > undefined reference to `glGetError' >> > >> > ... >> > >> > >> /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:159: >> > undefined reference to `glLightModelfv' >> > >> /home/javier/st/squeak-svn/platforms/unix/plugins/B3DAcceleratorPlugin/sqUnixOpenGL.c:160: >> > undefined reference to `glGetError' >> > collect2: ld returned 1 exit status >> > make[2]: *** [squeakvm] Error 1 >> > make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 >> > make: *** [all] Error 2 >> > >> > >> > Maybe it should be linking to opengl lib but it isn't, what do you >> think? >> >> What version of OpenGL do you have installed on your machine? I haven't >> looked at the details, but I believe that the interface changed quite a >> lot between OpenGL 1.x and OpenGL 2.x, so if B3D is expecting 2.x and >> you have 1.x, or the other way around, you might get problems like this. >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > -- Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 23, 2010

[Pharo-project] Source code management - my vision. (Was: Re: Why a package management system)

by Igor Stasenko

Since Goran mentioned DeltaStreams, i'd like to share one of my ideas, which came into my mind, when i complete coding the method trailers. I made a method trailers open for future extensions. A first step would be to introduce an abstract 'source management' layer, which will be responsible for delivering a method's and classes sources from some abstract data source. The next step is actually implement such data sources. So, the idea is to abandon hardwiring with .sources and .changes files. What new opportunities it gives to us? Suppose that instead of storing sources into file, you putting them directly to database , such as CouchDB (yes! :). Now if you imagine that anyone could access to this database on some public location, this means that we automagically made a source code exchange hub, and could do a very cool things with it. Suppose that ALL source code is put into a single database. Now different users creating own accounts and makind own 'forks' from original. What we getting is a number of update streams (methods, doits etc etc), which lying in those databases, and if one user wants to load/merge code from one of the sources he simply points to it and it get loaded into his image. We could organize things very closely to what github currently is: everyone could create any number of new projects, or forks of existing ones. Freely exchange the code, do a cherry picking etc etc. And what is most important, that with such organization you can track any methods, classes in the image and their evolutionary history back to its origin. As well as, you can query database, how an when a concrete method/class get deleted (everything is recorded, not just current state). Also, it would allow us to manipulate the code at the lowest level of granularity (individual methods/classes/doits, same as DS does), not at a package level. There are a lot of synergy with DeltaStreams - it could serve as an 'offline' format, in same way as git storing the files locally, but can reconnect with remote storage (which can be a public database). One of the things, which could be made is to allow stashing/popping code from stash. Suppose two projects started from a single starting point (Squeak 3.9). Now suppose that by clicking a single button you could get either trunk image, or Pharo 1.0 image. But that's not all! With DeltaStreams, you could then click once more, and revert things back from , say Pharo 1.0 to trunk or vice versa :) Of course it would be stupid to do things at such large scale, but if we put some common 'root' stuff into database, then we could very easily track all changes & compare them. This would make cherry picking and code exchange much more easier. This could get us on the next level of code management and system organization and organization of community efforts. 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se>: > Hi! > > GermÃ¡n Arduino wrote: >> Hi GÃ¶ran: >> >> Sorry by my intromision here, but want to say somethings :) >> >> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se <mailto:goran@krampe.se>> > [SNIP] >> Â Â What I have seen so far in Metacello is indeed nothing new - the >> Â Â senarios and discussions about dependencies etc go loooong way back. >> >> >> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >> packages, >> etc, but only discussions on most of cases. I think Metacello solves the >> dependencies >> questions very well and the other tools not (with exception of Universes >> probably, but >> abandoned now). Also Metacello provides all the features explained on >> the excellent >> mail of Torsten, assuring that the configurations will work with the >> time not breaking >> stuffs. >> >> The solution of using Metacello+Monticello is, imho, very simple, easy >> and productive >> and is here, available to us. :) > > I never claimed otherwise! I am just saying that there is nothing new - > and frankly, though I admit not having read carefully, I didn't find the > example so... impressive. Perhaps I need to read it again. > > Again though - I am not saying anything negative about Metacello. > > [SNIP] >> Â Â Anyway, "common exchange mechanism" - I am working on Deltastreams which >> Â Â I even presented at Brest, though unfortunately colliding with the >> Â Â Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY >> Â Â this problem (fork interchange), and it was born in 2007: >> >> Â Â http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… >> >> Â Â I and Igor are the ones working on it - and after Brest we have had very >> Â Â little time to move it forward. I still think it is a very important >> Â Â piece of the puzzle though. >> >> But Deltastreams are ready to use on production systems? > > Nope, not yet, although very close. But since the topic came up I wanted > to mention it. But AFAIK there is no other tool/project aimed at that > use case. Again, I may be wrong :) > > regards, GÃ¶ran > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 23, 2010

Re: [Pharo-project] Diff tools

by Gary Chambers

If you can describe exactly what you wish I'm sure it can be done ;-) ... Remember, conflicts are conflicts and *should* be checked on a one-by-one basis when merging. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, February 11, 2010 7:57 AM Subject: Re: [Pharo-project] Diff tools > gary > do we have resolved all conflict by taking the incoming? > and the inverse because in the old diff tools we could and this is handy. > > On Feb 9, 2010, at 4:24 PM, GARY CHAMBERS wrote: > >> New version on SqueakSource Polymorph-Tools-Diff-gvc.20. >> >> Descriptions added and small bug fix for merge tool (selecting next >> conflict now ignores "resolved" conflicts). >> >> Merge and select incoming for each conflict to load.. >> >> Regards, Gary >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Lukas Renggli

> and with that I did not mean to "use" those other DVCS but maybe take ideas > from them :) This is not a problem any DVCS tackles. Rather take ideas of package management systems like aptitude, rpm, portage, fink, ... As you see in all such system, they ship the code (binary or source) together with the package definition. None of these mechanisms refer to the VCS where the code is developed, but they include all the dependencies they need. I was thinking more along of something of a SAR file that would include the Metacello configuration and all the referenced mcz files in one file. Dragging and dropping that file onto the image (or using some GUI) would bootstrap Metacello, execute the Metacello definition, and if necessary download and pull in other SAR files from a well known place. That's how Linux works quite successful for over a decade. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 23, 2010

[Pharo-project] [update 1.1] #11229

by Marcus Denker

11229 ----- Issue 2035: use Behavior>>#methods and Behavior>>#selectors Issue 2043: clean codeloader a little This does a #releaseCleanup afterwards. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 23, 2010

Re: [Pharo-project] Pharo by Example is back on Lulu

by Serge Stinckwich

Thank you Oscar for the great job ! On Tue, Feb 23, 2010 at 1:46 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which messed up the fonts on several pages. Â By turning all th efigures into embedded PNGs, the problem finally went away. > > Cheers, > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Geert Claes

and with that I did not mean to "use" those other DVCS but maybe take ideas from them :) -- View this message in context: http://n4.nabble.com/Metacello-How-to-make-sure-that-we-will-be-able-to-loa… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Geert Claes

Hi, I am very interested in the whole configuration management, metacello, monticello, public/private repository, project, library/package, object, project, environment, release, version stuff ... some clarity around is badly needed. My first contact with the whole Squeak/Pharo packages and versioning was very confusing with SqueakSource, SqueakMap, Sake/Packages, Package Universe, Monticello. Why not look at other distributed version control systems like Darcs, Bazaar, GIT ... and see what could work for smalltalk? -- View this message in context: http://n4.nabble.com/Metacello-How-to-make-sure-that-we-will-be-able-to-loa… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 23, 2010