[Pharo-project] Squeak/Pharo in Fedora
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? Cheers, -- Pavel
Hi,
I want make a little report about progress with making of Fedora pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by Jaroslav Å karvada.
Thanks!!!!
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.
totally
What is the latest CogVM/StackVM version number?
Cheers, -- Pavel
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
Cheers, -- Pavel
-- best, Eliot
Hi Eliot, On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)? What is the reason to exclude fbdev? -- Pavel
Cheers, -- Pavel
-- best, Eliot
On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
Hi Eliot,
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <
pavel.krivanek@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.
What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)?
Not anything to do with me.
What is the reason to exclude fbdev?
What's fbdev?
-- Pavel
Cheers, -- Pavel
-- best, Eliot
-- best, Eliot
In january we will brand our VM and build VM tests. We should improve on that and we should be more to work there and not only igor. Stef
On Tue, Dec 6, 2011 at 9:58 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Eliot,
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)?
Not anything to do with me.
It is in hands of Esteban. Strange, I thought that the Cog development is not splitted. The Git version uses cmake. SVN version autotools?
What is the reason to exclude fbdev?
What's fbdev?
framebuffer display device.
-- Pavel
Cheers, -- Pavel
-- best, Eliot
-- best, Eliot
On Tue, Dec 6, 2011 at 1:27 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Tue, Dec 6, 2011 at 9:58 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek <
pavel.krivanek@gmail.com>
wrote:
Hi Eliot,
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)?
Not anything to do with me.
It is in hands of Esteban. Strange, I thought that the Cog development is not splitted. The Git version uses cmake. SVN version autotools?
yes.
What is the reason to exclude fbdev?
What's fbdev?
framebuffer display device.
It wasn't used at Qwaq/Teleplace and as things evolved it was easier to leave it behind. Do you want it back?
-- Pavel
Cheers, -- Pavel
-- best, Eliot
-- best, Eliot
-- best, Eliot
2011/12/6 Eliot Miranda <eliot.miranda@gmail.com>:
On Tue, Dec 6, 2011 at 1:27 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Tue, Dec 6, 2011 at 9:58 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 12:56 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Hi Eliot,
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
What is the relation between this SVN repository and Git repository used by the CI server (https://git.gitorious.org/cogvm/blessed.git)?
Not anything to do with me.
It is in hands of Esteban. Strange, I thought that the Cog development is not splitted. The Git version uses cmake. SVN version autotools?
yes.
What is the reason to exclude fbdev?
What's fbdev?
framebuffer display device.
It wasn't used at Qwaq/Teleplace and as things evolved it was easier to leave it behind. Â Do you want it back?
It does not stem from any current practical needs however with fbdev, OSProcess and NativeBoost there may be done cool things ;-)
-- Pavel
Cheers, -- Pavel
-- best, Eliot
-- best, Eliot
-- best, Eliot
Hi,
It is in hands of Esteban. Strange, I thought that the Cog development is not splitted. The Git version uses cmake. SVN version autotools?
It is not... Igor first (and now myself) do an integration of what is on SVN regularly... also with a couple of patches of Igor not yet integrated to svn branch (AFAIK). We use gitorious because we believe is much better to community work the git way (svn is too restrictive), but we didn't split cog vm development. Right now, because the use of git and CMakeMaker, anyone can fork and do his own vm changes... then if they want they can ask for a merge... or not... I think is good for everybody. Said so... I do believe our versioning strategy is not good enough... is a little bit better now, but we need to improve. Cheers, Esteban
On Tue, Dec 6, 2011 at 11:06 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
It is in hands of Esteban. Strange, I thought that the Cog development is not splitted. The Git version uses cmake. SVN version autotools?
It is not... Igor first (and now myself) do an integration of what is on SVN regularly... also with a couple of patches of Igor not yet integrated to svn branch (AFAIK).
We use gitorious because we believe is much better to community work the git way (svn is too restrictive), but we didn't split cog vm development. Right now, because the use of git and CMakeMaker, anyone can fork and do his own vm changes... then if they want they can ask for a merge... or not... I think is good for everybody.
Said so... I do believe our versioning strategy is not good enough... is a little bit better now, but we need to improve.
OK, thank you for the explanation. -- Pavel
Cheers, Esteban
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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? 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
On Tue, Dec 6, 2011 at 1:07 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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
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?
Better. So I guess that at least in Pharo this method deserves an update: version "Return the version number string of the Virtual machine built" " Smalltalk vm version " ^(self getSystemAttribute: 1004), ' ', ((self getSystemAttribute: 1009) ifNil: ['']) 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
-- Mariano http://marianopeck.wordpress.com
can you open a ticket mariano? Tx On Dec 6, 2011, at 10:26 PM, Mariano Martinez Peck wrote:
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?
Better. So I guess that at least in Pharo this method deserves an update:
version "Return the version number string of the Virtual machine built" " Smalltalk vm version "
^(self getSystemAttribute: 1004), ' ', ((self getSystemAttribute: 1009) ifNil: [''])
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
-- Mariano http://marianopeck.wordpress.com
On Tue, Dec 6, 2011 at 10:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
can you open a ticket mariano?
With fix in inbox. http://code.google.com/p/pharo/issues/detail?id=5066
Tx
On Dec 6, 2011, at 10:26 PM, Mariano Martinez Peck wrote:
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
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?
Better. So I guess that at least in Pharo this method deserves an update:
version "Return the version number string of the Virtual machine built" " Smalltalk vm version "
^(self getSystemAttribute: 1004), ' ', ((self getSystemAttribute:
you need more packages than VMMaker, so you have to guess which version to use. 1009) ifNil: [''])
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
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Tue, Dec 6, 2011 at 10:17 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 1:07 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek <pavel.krivanek@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.
The VM originally used major.minor.revision naming. He was confused that he cannot see sequel. -- Pavel
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
participants (5)
-
Eliot Miranda -
Esteban Lorenzano -
Mariano Martinez Peck -
Pavel Krivanek -
Stéphane Ducasse