A 1 million bucks question :)
Locked
123
123
Re: Re: A 1 million bucks question :)
 
|
2009/12/16 Andreas Raab <[hidden email]>:
> Question for the Unix folks: If we know that what you get via package > install is most likely very old, would it make sense to check inside Squeak > whether a new version is available? I.e., just a simple > > (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = > SystemVersion current ifFalse:[self inform: 'A new version of Squeak has > become available. Would you like to install it now?']. > > might help get people more accustomed with later developments. Would that be > a sensible thing to do? > But i don't like software which starts using my wires without asking my permission. > Cheers, > - Andreas > > Frank Shearar wrote: >> >> Igor Stasenko wrote: >>> >>> Just to let you know, >>> >>> i found that >>> http://squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.sh >>> works just well out of the box on my freshly installed Ubuntu 9.10 - >>> 32bit system. >> >> Or, if you like Squeak 3.9 (and are running Ubuntu 9.10), "apt-get install >> squeak". Which of course is a neat illustration of what Ken spoke of >> earlier: the version in the package often lags behind the most recent >> version. >> >> It's not an uncommon problem: Steel Bank Common Lisp's Ubuntu port >> installs SBCL 1.0.29 when the latest version is 1.0.33, for instance. >> >> frank >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Re: A 1 million bucks question :)
|
|
In reply to this post by Andreas.Raab
On Wed, 16 Dec 2009, Andreas Raab wrote:
> Question for the Unix folks: If we know that what you get via package install > is most likely very old, would it make sense to check inside Squeak whether a > new version is available? I.e., just a simple > > (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion > current ifFalse:[self inform: 'A new version of Squeak has become available. > Would you like to install it now?']. > > might help get people more accustomed with later developments. Would that be > a sensible thing to do? > If it will run after the startscript then maybe :). It's already really annoying when one wants to start an image without display from the commandline and the image stops before the script runs, because the sources file is not available and a dialog box is waiting for the user to click OK... This should be fixed someday too. Btw, IIRC 3.8 had something like this. Levente > Cheers, > - Andreas > |
|
|
In reply to this post by Andreas.Raab
On 16.12.2009, at 09:23, Andreas Raab wrote:
> > Question for the Unix folks: If we know that what you get via package install is most likely very old, would it make sense to check inside Squeak whether a new version is available? I.e., just a simple > > (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion current ifFalse:[self inform: 'A new version of Squeak has become available. Would you like to install it now?']. > > might help get people more accustomed with later developments. Would that be a sensible thing to do? It would be highly unusual in Linux, where version management and updates are provided by the system rather than by individual packages. Also, we'd have to state to how to actually get the new version. Which there are a ton of possibilities for, depending on how you got Squeak in the first place. This would, however, make sense for a self-contained Squeak version (similar to Etoys-To-Go or the various "one-click" products). - Bert - |
|
|
Bert Freudenberg wrote:
> On 16.12.2009, at 09:23, Andreas Raab wrote: >> Question for the Unix folks: If we know that what you get via package install is most likely very old, would it make sense to check inside Squeak whether a new version is available? I.e., just a simple >> >> (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion current ifFalse:[self inform: 'A new version of Squeak has become available. Would you like to install it now?']. >> >> might help get people more accustomed with later developments. Would that be a sensible thing to do? > > It would be highly unusual in Linux, where version management and updates are provided by the system rather than by individual packages. Never mind then ;-) > Also, we'd have to state to how to actually get the new version. Which there are a ton of possibilities for, depending on how you got Squeak in the first place. Fire up a web browser pointing at http://www.squeak.org/download/linux#distro Cheers, - Andreas |
|
|
Andreas Raab wrote:
> Bert Freudenberg wrote: >> On 16.12.2009, at 09:23, Andreas Raab wrote: >>> Question for the Unix folks: If we know that what you get via package >>> install is most likely very old, would it make sense to check inside >>> Squeak whether a new version is available? I.e., just a simple >>> >>> (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = >>> SystemVersion current ifFalse:[self inform: 'A new version of Squeak >>> has become available. Would you like to install it now?']. >>> >>> might help get people more accustomed with later developments. Would >>> that be a sensible thing to do? >> >> It would be highly unusual in Linux, where version management and >> updates are provided by the system rather than by individual packages. > > Never mind then ;-) You know, actually I take my original proposal back. What we should probably do is to hook something into the update mechanism that checks whether there is a newer *released* version of Squeak and points people there if so. This would make sense for two reasons: First, it's tied into the update mechanism so telling you that there's a new release is valuable. Second, it would mean you're going to stick with the released versions instead of getting interim development stuff. If you're still on the latest release you just fetch updates (fixes) for this release. If there's a newer one, we tell you (with the option of ignoring that of course). How does that sound as a concept? Cheers, - Andreas |
|
|
In reply to this post by Andreas.Raab
On 16.12.2009, at 11:58, Andreas Raab wrote:
> > Bert Freudenberg wrote: >> On 16.12.2009, at 09:23, Andreas Raab wrote: >>> Question for the Unix folks: If we know that what you get via package install is most likely very old, would it make sense to check inside Squeak whether a new version is available? I.e., just a simple >>> >>> (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion current ifFalse:[self inform: 'A new version of Squeak has become available. Would you like to install it now?']. >>> >>> might help get people more accustomed with later developments. Would that be a sensible thing to do? >> It would be highly unusual in Linux, where version management and updates are provided by the system rather than by individual packages. > > Never mind then ;-) > >> Also, we'd have to state to how to actually get the new version. Which there are a ton of possibilities for, depending on how you got Squeak in the first place. > > Fire up a web browser pointing at http://www.squeak.org/download/linux#distro > > Cheers, > - Andreas And then what? Linux has advanced beyond "./configure; make; make install". Downloading a tarball feels antiquated. Regular users don't do that anymore unless they absolutely have to. Package maintainers do and bundle this in a package for their distro. Even downloading a DEB or RPM from random web sites doesn't make it much better, because this interferes with distro packages, again bypassing the official update mechanism. IMHO the debs and rpms on squeak.org should be removed, and maintenance moved to the respective distros. Empower and support the maintainers, like Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey Lim. - Bert - |
|
|
In reply to this post by Andreas.Raab
On 16.12.2009, at 12:18, Andreas Raab wrote:
> > Andreas Raab wrote: >> Bert Freudenberg wrote: >>> On 16.12.2009, at 09:23, Andreas Raab wrote: >>>> Question for the Unix folks: If we know that what you get via package install is most likely very old, would it make sense to check inside Squeak whether a new version is available? I.e., just a simple >>>> >>>> (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion current ifFalse:[self inform: 'A new version of Squeak has become available. Would you like to install it now?']. >>>> >>>> might help get people more accustomed with later developments. Would that be a sensible thing to do? >>> >>> It would be highly unusual in Linux, where version management and updates are provided by the system rather than by individual packages. >> Never mind then ;-) > > You know, actually I take my original proposal back. What we should probably do is to hook something into the update mechanism that checks whether there is a newer *released* version of Squeak and points people there if so. This would make sense for two reasons: First, it's tied into the update mechanism so telling you that there's a new release is valuable. Second, it would mean you're going to stick with the released versions instead of getting interim development stuff. If you're still on the latest release you just fetch updates (fixes) for this release. If there's a newer one, we tell you (with the option of ignoring that of course). How does that sound as a concept? > > Cheers, > - Andreas Sounds good, but is not exactly specific to *nix :) OTOH, on the Mac it would be much more comfortable to use John's Sparkle plugin. Sparkle has a nice interface and is used by a lot of Mac software already, so users are familiar with its workings (though they wouldn't even know it's provided by Sparkle, it looks like it's build into the app). Not sure if something similar exists on Windows. - Bert - |
Re: Re: A 1 million bucks question :)
|
|
In reply to this post by Igor Stasenko
On Wed, Dec 16, 2009 at 12:41:07PM +0200, Igor Stasenko wrote:
> 2009/12/16 Andreas Raab <[hidden email]>: > > Question for the Unix folks: If we know that what you get via package > > install is most likely very old, would it make sense to check inside Squeak > > whether a new version is available? I.e., just a simple > > > > (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = > > SystemVersion current ifFalse:[self inform: 'A new version of Squeak has > > become available. Would you like to install it now?']. > > > > might help get people more accustomed with later developments. Would that be > > a sensible thing to do? > > > most of software nowadays doing so. > But i don't like software which starts using my wires without asking > my permission. I think i would be good to make it very easy for the first time user to get the latest version, but it should be optional. For example, a workspace the says "Please click this button to complete your installation. Clicking OK will load the latest Squeak software versions from servers on the network." I agree with Igor that software should not do things like this without asking for permission. Also, we should respect that many users will not be connected to high speed networks, so it would not be good if the first-time user experience involved a 48 hour download over a 300 baud phone coupler ;) Dave |
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> On 16.12.2009, at 11:58, Andreas Raab wrote: >> Bert Freudenberg wrote: >>> On 16.12.2009, at 09:23, Andreas Raab wrote: >>>> Question for the Unix folks: If we know that what you get via package install is most likely very old, would it make sense to check inside Squeak whether a new version is available? I.e., just a simple >>>> >>>> (HTTPSocket httpGet: 'http://www.squeak.org/current_version') = SystemVersion current ifFalse:[self inform: 'A new version of Squeak has become available. Would you like to install it now?']. >>>> >>>> might help get people more accustomed with later developments. Would that be a sensible thing to do? >>> It would be highly unusual in Linux, where version management and updates are provided by the system rather than by individual packages. >> Never mind then ;-) >> >>> Also, we'd have to state to how to actually get the new version. Which there are a ton of possibilities for, depending on how you got Squeak in the first place. >> Fire up a web browser pointing at http://www.squeak.org/download/linux#distro >> >> Cheers, >> - Andreas > > And then what? > > Linux has advanced beyond "./configure; make; make install". Downloading a tarball feels antiquated. Regular users don't do that anymore unless they absolutely have to. Package maintainers do and bundle this in a package for their distro. > > Even downloading a DEB or RPM from random web sites doesn't make it much better, because this interferes with distro packages, again bypassing the official update mechanism. > > IMHO the debs and rpms on squeak.org should be removed, and maintenance moved to the respective distros. Empower and support the maintainers, like Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey Lim. > > - Bert - > > More generally, is this about getting a new VM, a new image or updates to the image? I think this is what is likely to confuse users where Squeak is concerned as opposed to regular app updates, ie, predominantly just the binaries. As a user if there an "update" then ideally I want an updated VM and updated image with my own changes preserved (tricky). Re image updating via established methods, didn't someone do a FUSE plug-in a while back so the image could be accessed like a file system? Maybe this could open up some options? -D |
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> > And then what? How the heck do I know? ;-) But you are sounding self-contradicting here. This discussion started with you pointing out that you wouldn't expect to find anything current in the package management system of choice. As a consequence I've been trying to find some ways by which we could get users the information that there's something more up to date. But now you're saying leave it to the distro maintainers? Isn't that directly contradicting your initial statement? If we assume that the packages are generally current, then there's no point whatsoever to this entire discussion (which started by Igor pointing out that current packages are *not* current). Confused, - Andreas > > Linux has advanced beyond "./configure; make; make install". Downloading a tarball feels antiquated. Regular users don't do that anymore unless they absolutely have to. Package maintainers do and bundle this in a package for their distro. > > Even downloading a DEB or RPM from random web sites doesn't make it much better, because this interferes with distro packages, again bypassing the official update mechanism. > > IMHO the debs and rpms on squeak.org should be removed, and maintenance moved to the respective distros. Empower and support the maintainers, like Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey Lim. > > - Bert - > > > > |
|
|
On 16.12.2009, at 15:20, Andreas Raab wrote:
> > Bert Freudenberg wrote: >> And then what? > > How the heck do I know? ;-) But you are sounding self-contradicting here. This discussion started with you pointing out that you wouldn't expect to find anything current in the package management system of choice. I don't think I started the discussion this time, but it's true nonetheless, for now. But the solution IMHO is not ignoring the distro packages. Downloading from squeak.org should become only the second-best option after the one expected by Linux users. > As a consequence I've been trying to find some ways by which we could get users the information that there's something more up to date. Appreciated. But I don't think the primary problem is that people are unaware of newer versions, but that getting a current Squeak is harder than usual for Linux software. > But now you're saying leave it to the distro maintainers? Isn't that directly contradicting your initial statement? If we assume that the packages are generally current, then there's no point whatsoever to this entire discussion (which started by Igor pointing out that current packages are *not* current). > > Confused, > - Andreas I'm looking for ways to actually fix this, not for more workarounds. And what we do as interim solution should not interfere with the proper way. So IMHO it is good if we provide a tarball on squeak.org for those who like to install manually (though IMHO it should include an image, not like the one currently linked on the homepage). And we should at least not do anything that undermines the efforts of packagers, instead encouraging use of the distro packages. If nobody uses them they won't get fixed. So next time someone notices a problem with a distro package *please* file a bug report in the distro's tracker. - Bert - > >> Linux has advanced beyond "./configure; make; make install". Downloading a tarball feels antiquated. Regular users don't do that anymore unless they absolutely have to. Package maintainers do and bundle this in a package for their distro. >> Even downloading a DEB or RPM from random web sites doesn't make it much better, because this interferes with distro packages, again bypassing the official update mechanism. >> IMHO the debs and rpms on squeak.org should be removed, and maintenance moved to the respective distros. Empower and support the maintainers, like Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey Lim. >> - Bert - > > |
|
|
Hi -
I think I'll stand back from this discussion. It's clear that I don't understand the constraints on Linux and that I'm pushing directions that are not appropriate. I would like to see the ability for new users on Linux to get to the latest versions though; if there's anything we can do to make this happen, please let us know. Cheers, - Andreas Bert Freudenberg wrote: > On 16.12.2009, at 15:20, Andreas Raab wrote: >> Bert Freudenberg wrote: >>> And then what? >> How the heck do I know? ;-) But you are sounding self-contradicting here. This discussion started with you pointing out that you wouldn't expect to find anything current in the package management system of choice. > > I don't think I started the discussion this time, but it's true nonetheless, for now. But the solution IMHO is not ignoring the distro packages. Downloading from squeak.org should become only the second-best option after the one expected by Linux users. > >> As a consequence I've been trying to find some ways by which we could get users the information that there's something more up to date. > > Appreciated. But I don't think the primary problem is that people are unaware of newer versions, but that getting a current Squeak is harder than usual for Linux software. > >> But now you're saying leave it to the distro maintainers? Isn't that directly contradicting your initial statement? If we assume that the packages are generally current, then there's no point whatsoever to this entire discussion (which started by Igor pointing out that current packages are *not* current). >> >> Confused, >> - Andreas > > I'm looking for ways to actually fix this, not for more workarounds. And what we do as interim solution should not interfere with the proper way. > > So IMHO it is good if we provide a tarball on squeak.org for those who like to install manually (though IMHO it should include an image, not like the one currently linked on the homepage). > > And we should at least not do anything that undermines the efforts of packagers, instead encouraging use of the distro packages. If nobody uses them they won't get fixed. So next time someone notices a problem with a distro package *please* file a bug report in the distro's tracker. > > - Bert - > >>> Linux has advanced beyond "./configure; make; make install". Downloading a tarball feels antiquated. Regular users don't do that anymore unless they absolutely have to. Package maintainers do and bundle this in a package for their distro. >>> Even downloading a DEB or RPM from random web sites doesn't make it much better, because this interferes with distro packages, again bypassing the official update mechanism. >>> IMHO the debs and rpms on squeak.org should be removed, and maintenance moved to the respective distros. Empower and support the maintainers, like Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey Lim. >>> - Bert - >> > > > > > |
|
|
On Wed, Dec 16, 2009 at 8:21 AM, Andreas Raab <[hidden email]> wrote: Hi - I think Bert is simply saying that the place an image goes to check for up-to-date versions must be configurable such that a squeak package maintainer for a particular distro can easily make images in their distro check their site for updates, not squeak.org. i.e. when one updates the debian squeak package one is not updating by installing stuff from squeak.org.
What are the constraints? If the image needs to be identical then the location for the update check needs to be external to the image. e.g. on Unix we could (via a getenv: primitive and/or FFI call) access an environment variable (say SQUEAK_DISTRO__MOST_UP_TO_DATE_VERSION_URL ;) ;) ) and if this is not set the image code defaults to something like http://www.squeak.org/current_version. The distro maintainer can then arrange to set the env var in the squeak shell script used to launch squeak. That's much easier to arrange than having to modify the image.
Am I presuming correctly Bert? BTW, I notice we're already at version 404.
|
|
|
In reply to this post by Andreas.Raab
2009/12/16 Andreas Raab <[hidden email]> Hi - Hi Andreas, from my experience as Debian maintainer of both: etoys and squeak-vm, what I've mainly missed is: a) help with the issues in non 32 bits platforms
b) collaboration with the people who package the vm in squeak.org c) help with the issues with the Squeak license For a): adding new plugins needed by the etoys image (RomePlugin, GstreamerPlugin) is great when the plugin can be compiled, but it's only tested in a 32 bits platform, and doesn't use to follow the gnu/autotools standards that most unix applications use. As a result: it doesn't work in other platforms, specially important are the problems in amd64. Ian Piumarta fixed the problems the vm had in 64 bits, but whenever a new plugin is added, new bugs are added, and Ian is not responsible of every plugin. The bugs I added to mantis have stayed there for years.
For b): there were some discussions in this list. As result of them I created a group in alioth.debian.org to work together, I offered all my help and nobody has added a line of code.
For c): I don't think I need to explain anything about the license. I "met" Squeak on 2003, and the steps to get a "free" image begun on 2007, four years after being asking/trying a solution. Anyway, Squeak development is so "weird" in the software world that I don't think the final problems will ever solved: bootstraping an image from sources, or have any way to demonstrate (working from the OS, not inside Squeak) that the image contains only free code.
c) causes etoys to be in the non-free section of Debian b) has caused the current delay in Debian, because I've been waiting for 6 months, just in case anybody wants to help. I've already given up, so I will upload the latest version before the end of this month. Before the setting up of the collaborative project I kept the squeak-vm very updated in Debian. In fact I used to compile it from svn, to get the latest patches, trying to make the images work with the newest plugins. But, even when the image was the same in Debian than in squeak.org, and the vm was in Debian newer and more polished than the one in squeak.org, I always saw how squeak.org documentation recommended for Debian (and derivatives) users installing the packages avoiding to use the standard way in the distribution, and making it almost impossible to use for a non-experienced user in Linux.
a) is still causing me headaches when the users fill bugs and ask for help. My 20 cents Regards José L.
|
|
|
>>>>> "José" == José Luis Redrejo <[hidden email]> writes:
José> or have any way to José> demonstrate (working from the OS, not inside Squeak) that the image contains José> only free code. Isn't that a bit like saying that they can't include any OpenOffice documents because they can't tell "working from the OS, not inside OpenOffice" that the documents contains only free text? At what point did we forget how to deal with binary files? The image file is just a binary file. The Squeak VM is its reader/manipulator, in the same way as a postgres database is a binary file, and postgres is its reader/manipulator. Probably the only thing we're missing is a way to generate a definitive complete text-dump version of the .image, preferrably one that won't show spurious differences when a changeset is applied. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
|
In reply to this post by José Luis Redrejo
On Wednesday 16 December 2009 11:47:50 pm José Luis Redrejo wrote:
> b) has caused the current delay in Debian, because I've been waiting for 6 > months, just in case anybody wants to help. I've already given up, so I > will upload the latest version before the end of this month. Before the > setting up of the collaborative project I kept the squeak-vm very updated > in Debian. In fact I used to compile it from svn, to get the latest > patches, trying to make the images work with the newest plugins. José, What do you think of the new launcher scripts - squeak and squeak.sh? Do they have enough flexibility for a distro packager? Building plugins is currently painful, I agree. Perhaps there should be two packages - squeakvm (runtime) and squeakvm-dev (plugin development). (branching this discussion to vm-dev) Subbu |
|
|
In reply to this post by José Luis Redrejo
2009/12/16 José Luis Redrejo <[hidden email]>:
> > > > > Hi Andreas, from my experience as Debian maintainer of both: etoys and > squeak-vm, what I've mainly missed is: > a) help with the issues in non 32 bits platforms > b) collaboration with the people who package the vm in squeak.org > c) help with the issues with the Squeak license > For a): adding new plugins needed by the etoys image (RomePlugin, > GstreamerPlugin) is great when the plugin can be compiled, but it's only > tested in a 32 bits platform, and doesn't use to follow the gnu/autotools > standards that most unix applications use. As a result: it doesn't work in > other platforms, specially important are the problems in amd64. Ian Piumarta > fixed the problems the vm had in 64 bits, but whenever a new plugin is > added, new bugs are added, and Ian is not responsible of every plugin. The > bugs I added to mantis have stayed there for years. > For b): there were some discussions in this list. As result of them I > created a group in alioth.debian.org to work together, I offered all my help > and nobody has added a line of code. > For c): I don't think I need to explain anything about the license. I "met" > Squeak on 2003, and the steps to get a "free" image begun on 2007, four > years after being asking/trying a solution. Anyway, Squeak development is so > "weird" in the software world that I don't think the final problems will > ever solved: bootstraping an image from sources, or have any way to > demonstrate (working from the OS, not inside Squeak) that the image contains > only free code. > > c) causes etoys to be in the non-free section of Debian > b) has caused the current delay in Debian, because I've been waiting for 6 > months, just in case anybody wants to help. I've already given up, so I will > upload the latest version before the end of this month. Before the setting > up of the collaborative project I kept the squeak-vm very updated in Debian. > In fact I used to compile it from svn, to get the latest patches, trying to > make the images work with the newest plugins. But, even when the image was > the same in Debian than in squeak.org, and the vm was in Debian newer and > more polished than the one in squeak.org, I always saw how squeak.org > documentation recommended for Debian (and derivatives) users installing the > packages avoiding to use the standard way in the distribution, and making it > almost impossible to use for a non-experienced user in Linux. > a) is still causing me headaches when the users fill bugs and ask for help. > My 20 cents Jose, we are discussed this topic during the last Board meeting. Let me familiarize you with some of our opinions. First and foremost, a distro maintainers should collaborate closely with VM maintainers. Currently, David T.Levis is a VM-dev Team Leader, so anyone who wants to get the latest status on VM, report bugs, ask for a fix and so on, should primarily contact with him, or as usual post on vm-dev. Dave runs things pretty well during last months, fixing bugs & pushing them to new releases. He also very responsive and helpful and reacts quickly on anything related to vm. Second, we think that best place for discussions concerning packaging (no matter what platform is) is vm-dev list, instead of a separate list. This including reporting a problems, bugs, and announcing new package releases. Lets not scatter resources. And finally, we are welcome anyone who willing to step up and become a maintainer of distribution on linux, as well as any other platfom. Please, contact us directly on any outstanding issue, which you think prevents you from moving forward. I think we will manage to solve any of them if we will work together as a team. > Regards > José L. > > -- Best regards, Igor Stasenko AKA sig. |
Re: Re: Unix updates
|
|
In reply to this post by K. K. Subramaniam
2009/12/16 K. K. Subramaniam <[hidden email]>
squeak.sh has the same problem I've discussed once again in this list for the last four years: they are developer focused. I don't have anything against a developer view, but I want the squeak packages being end-user friendly. I'm very focused/biased on the educational uses of Squeak, and I don't think a console script is a good idea these days.
I will integrate the changes these scripts have, so the one I use in the package can be called from a terminal, but I want to keep the gnome/kde and mime integration I added to the squeak-vm package. Building plugins is currently painful, I agree. Perhaps there should be two The problem comes when new etoys images do need those plugins to work properly, and they are just experimental works somebody does and nobody maintains later. (branching this discussion to vm-dev) I'm subscribed to vm-dev, so no cc'ed is needed. Regards José L. Subbu |
|
|
On Thu, 17 Dec 2009, José Luis Redrejo Rodríguez wrote:
> 2009/12/16 K. K. Subramaniam <[hidden email]> > >> On Wednesday 16 December 2009 11:47:50 pm José Luis Redrejo wrote: >> >>> b) has caused the current delay in Debian, because I've been waiting for >> 6 >>> months, just in case anybody wants to help. I've already given up, so I >>> will upload the latest version before the end of this month. Before the >>> setting up of the collaborative project I kept the squeak-vm very >> updated >>> in Debian. In fact I used to compile it from svn, to get the latest >>> patches, trying to make the images work with the newest plugins. >> José, >> >> What do you think of the new launcher scripts - squeak and squeak.sh? Do >> they >> have enough flexibility for a distro packager? >> >> > squeak.sh has the same problem I've discussed once again in this list for > the last four years: they are developer focused. I don't have anything > against a developer view, but I want the squeak packages being end-user > friendly. I'm very focused/biased on the educational uses of Squeak, and I > don't think a console script is a good idea these days. > I will integrate the changes these scripts have, so the one I use in the > package can be called from a terminal, but I want to keep the gnome/kde and > mime integration I added to the squeak-vm package. http://lists.squeakfoundation.org/pipermail/vm-dev/2009-August/003092.html "Another script, squeak.sh, is intended to launch Squeak from a menu. It's begging for improvement." Levente > > > > >> Building plugins is currently painful, I agree. Perhaps there should be two >> packages - squeakvm (runtime) and squeakvm-dev (plugin development). >> >> > > The problem comes when new etoys images do need those plugins to work > properly, and they are just experimental works somebody does and nobody > maintains later. > > > >> (branching this discussion to vm-dev) >> >> > > I'm subscribed to vm-dev, so no cc'ed is needed. > > Regards > José L. > > >> Subbu >> > |
Re: Re: Unix updates
|
|
In reply to this post by Igor Stasenko
2009/12/16 Igor Stasenko <[hidden email]>
2009/12/16 José Luis Redrejo <[hidden email]>: Sure, and the vm maintainers have changed for years and I've always been in contact with the current one. Currently, David T.Levis is a VM-dev Team Leader, so anyone who wants I know, I'm in vm-dev list. Last april he finally fixed the bug that made the vm crash in 64 bits whenever a sound was played. The bug had been there for years and he did a great job in a few days.
Second, we think that best place for discussions concerning packaging I don't want to scatter resources, I just gave Andreas some hints after he said he didn't understand the Linux problems. As I said in my first email, I've done a try of making squeak packages in Debian a collaborative work, and after six months without any help, I've given up and will continue the work on my own. The things I've said in this email are things I've said in the last years in this list, in vm-dev or in person with some of the squeakers, from Alan Kay to Yoshiki Ohshima. I don't want to begin a new discussion, I just surrender to the evidences. That's all
And finally, we are welcome anyone who willing to step up and become a I hope so, I gave that step on February 2005 (with the packages I did in Linex and installed in 80000 pc in Extremadura schools) so it's good to know it now. Please, contact us directly on any outstanding issue, which you think Great, I just want to add that it would be a good progress having only one Debian version of the squeak packages, updated, and done between all the people who is interested in it. Now there are at least three packages for the same squeak-vm: one in Debian, another in Ubuntu, and another in squeak.org That's simply a waste of resources. Last april I open a collaborative project on https://alioth.debian.org/projects/pkg-squeak/ , Both Matej Kosik and Bert Freudenberg have sent emails announcing it, but nobody has joined or apported a line. I think that would be a good starting point but I'm open to any other suggestion.
Regards. José L. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |