On Tue, Dec 6, 2011 at 1:07 PM, Mariano Martinez Peck <marianop...@gmail.com > wrote:
> > > On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.mira...@gmail.com>wrote: > >> >> >> On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.kriva...@gmail.com >> > wrote: >> >>> Hi, >>> >>> I want make a little report about progress with making of Fedora >>> pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by >>> Jaroslav Škarvada. >>> >>> Currently there are three packages in Fedora repositories - squeak-vm, >>> squeak-image and squeak-vm-nonXOplugins (that contains plugins like >>> OSProcess). It uses resources from the Squeak site. >>> >>> Red Hat has quite restrictive demands on packages and it is a small >>> miracle that they tolerate current squeak packages :-). The conditions >>> simply do expect that a program is a set of source codes and not a >>> system of communicating objects. One problem is that Squeak VM is one >>> of few metacircular packages that are needed for their own building. >>> Because binary executables are prohibited, it would require a special >>> bureaucratically problematic exception. Fortunately for virtual >>> machine generation we may use the current squeak packages - more >>> precisely their updated versions. The next issue for virtual machine >>> generation may be the fact, that some packages used for VM generation >>> are in repositories with public read&write permissions. >>> >>> Because image can be likened to *.jar files that are prohibited and >>> must be recompiled during package generation, we are lucky that >>> squeak-image package is currently accepted. If someone starts >>> tinkering, we are in big trouble. >>> >>> There is a little issue with *.sources placement. The current VM >>> package contains symlinks from VM path to sources files that are >>> present in package with the image. This is really ugly solution. >>> Squeak and Pharo uses this sequence for sources lookup: vm path, image >>> path, current path. So I think that the best solution will be to have >>> sources file in the image package, do not have symlinks in vm package >>> and to create symlink to sources together with changes in the image >>> path via mysqueak initialization script. >>> >>> Btw., Jaroslav told me that he saw a lot of creepy projects but >>> nothing like Squeak VM :-) >>> >>> And there is a mess in VM versioning. What is the latest CogVM/StackVM >>> version number? >>> >> >> How so? My latest version is SVN >> http://www.squeakvm.org/svn/squeak/branches/Cog/ r2519. Monticello >> package http://source.squeak.org/VMMaker/VMMaker.oscog-eem.139. >> > > But where is such information stored? > Then, the VMMaker package version says nothing, because to buiyld the VM > you need more packages than VMMaker, so you have to guess which version to > use. > Moreoever, there is also ANOTHER version in VM which is VMMaker > class>>versionString which is different from that. > Then from the image or from a log we get: VM: Mac OS - intel - 1068 - > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog > 3.0.0 > so where it is the svn version? > (1007 to: 1009) collect: [:n| Smalltalk getSystemAttribute: n] #('CoInterpreter VMMaker.oscog-eem.138 uuid: f9a63bdf-7bbc-4ae5-9634-ecd6fd814c9d Nov 18 2011' 'StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: c2849383-9768-4948-b9b2-a5c22d482b07 Nov 18 2011' 'r2519 http://www.squeakvm.org/svn/squeak/branches/Cog') Good enough? In fact, only the last is required since the VM and plugin source is included in http://www.squeakvm.org/svn/squeak/branches/Cog/src. > So...all in all, I think that indeed, it is quite a mess. But it is also > complicated to manage and I don't really know what to suggest. > With ConfigurationOfCog at least with one number we group all image side > related packages. > Then we only need svn/git version. Moreover, we can store this svn/git as > the description in each version of ConfigurationOfCog. That way, you know > *exactly* what do you need. > > Cheers > > > >> >> >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> >> -- >> best, >> Eliot >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot
