OCompletion package
Locked
 
|
Hi Squeak-Dev, So one of the things that I can't live without in my image is auto-completion as provided by OComplete. Levente made a release for Squeak 4.2, and it has worked in every release since then but the package has not been updated to indicate this. In addition, the "extending the workspace" code that allows for the installation of OComplete triggers a debugger when it calls Smalltalk at: ECToolSet, as this key cannot be found. However, installing the Squeak 4.2 compatible version from SqueakMap does work nicely in 4.4.Thanks for your help, Jeff G. |
|
|
On 4 January 2013 06:15, Jeff Gonis <[hidden email]> wrote:
> Hi Squeak-Dev, > > So one of the things that I can't live without in my image is > auto-completion as provided by OComplete. Levente made a release for Squeak > 4.2, and it has worked in every release since then but the package has not > been updated to indicate this. In addition, the "extending the workspace" > code that allows for the installation of OComplete triggers a debugger when > it calls Smalltalk at: ECToolSet, as this key cannot be found. However, > installing the Squeak 4.2 compatible version from SqueakMap does work nicely > in 4.4. > > The OComplete package is not listed as community supported, so I don't > believe that I can edit it, although I get the full interface when I > right-click on the package and select "Edit Release". > > So I have two questions: > > 1) Can we make OCompletion into a Community Supported Package? I believe > that it provides considerable benefits when developing in Squeak > > 2) Once it is community supported, do I just select "Edit Release" on the > 4.2 compatible release, change the compatibility level to Squeak 4.4, update > the name and enter my squeak map id/password? I want to get some experience > doing this, but I'd rather not learn by doing it wrong the first time and > ending up with some egg on my face. I think it would be more appropriate to make a _new_ release for 4.4 (which is just as easy as editing a release). frank > Maybe a bit of a tutorial on how to go about editing a community supported > package would be helpful. > > Thanks for your help, > Jeff G. |
|
|
The problem is that Jeff does not have the right to do that and he
likes to have some guidance.... --Hannes On 1/4/13, Frank Shearar <[hidden email]> wrote: > On 4 January 2013 06:15, Jeff Gonis <[hidden email]> wrote: >> Hi Squeak-Dev, >> >> So one of the things that I can't live without in my image is >> auto-completion as provided by OComplete. Levente made a release for >> Squeak >> 4.2, and it has worked in every release since then but the package has >> not >> been updated to indicate this. In addition, the "extending the >> workspace" >> code that allows for the installation of OComplete triggers a debugger >> when >> it calls Smalltalk at: ECToolSet, as this key cannot be found. However, >> installing the Squeak 4.2 compatible version from SqueakMap does work >> nicely >> in 4.4. >> >> The OComplete package is not listed as community supported, so I don't >> believe that I can edit it, although I get the full interface when I >> right-click on the package and select "Edit Release". >> >> So I have two questions: >> >> 1) Can we make OCompletion into a Community Supported Package? I believe >> that it provides considerable benefits when developing in Squeak >> >> 2) Once it is community supported, do I just select "Edit Release" on the >> 4.2 compatible release, change the compatibility level to Squeak 4.4, >> update >> the name and enter my squeak map id/password? I want to get some >> experience >> doing this, but I'd rather not learn by doing it wrong the first time and >> ending up with some egg on my face. > > I think it would be more appropriate to make a _new_ release for 4.4 > (which is just as easy as editing a release). > > frank > >> Maybe a bit of a tutorial on how to go about editing a community >> supported >> package would be helpful. >> >> Thanks for your help, >> Jeff G. > > |
|
|
On 4 January 2013 08:02, H. Hirzel <[hidden email]> wrote:
> The problem is that Jeff does not have the right to do that Yes, and I can't help with that. > and he > likes to have some guidance.... I thought that's what I did? "Don't edit the release, make a new one instead" :) I don't know how to handle versioning things for packages that work in multiple images, but perhaps Dave can suggest something? OSProcess has had to work across multiple Squeaks for ages. frank > --Hannes > > On 1/4/13, Frank Shearar <[hidden email]> wrote: >> On 4 January 2013 06:15, Jeff Gonis <[hidden email]> wrote: >>> Hi Squeak-Dev, >>> >>> So one of the things that I can't live without in my image is >>> auto-completion as provided by OComplete. Levente made a release for >>> Squeak >>> 4.2, and it has worked in every release since then but the package has >>> not >>> been updated to indicate this. In addition, the "extending the >>> workspace" >>> code that allows for the installation of OComplete triggers a debugger >>> when >>> it calls Smalltalk at: ECToolSet, as this key cannot be found. However, >>> installing the Squeak 4.2 compatible version from SqueakMap does work >>> nicely >>> in 4.4. >>> >>> The OComplete package is not listed as community supported, so I don't >>> believe that I can edit it, although I get the full interface when I >>> right-click on the package and select "Edit Release". >>> >>> So I have two questions: >>> >>> 1) Can we make OCompletion into a Community Supported Package? I believe >>> that it provides considerable benefits when developing in Squeak >>> >>> 2) Once it is community supported, do I just select "Edit Release" on the >>> 4.2 compatible release, change the compatibility level to Squeak 4.4, >>> update >>> the name and enter my squeak map id/password? I want to get some >>> experience >>> doing this, but I'd rather not learn by doing it wrong the first time and >>> ending up with some egg on my face. >> >> I think it would be more appropriate to make a _new_ release for 4.4 >> (which is just as easy as editing a release). >> >> frank >> >>> Maybe a bit of a tutorial on how to go about editing a community >>> supported >>> package would be helpful. >>> >>> Thanks for your help, >>> Jeff G. >> >> > |
SqueakMap release versions (was: OCompletion package)
|
|
On Fri, Jan 04, 2013 at 08:49:53AM +0000, Frank Shearar wrote:
> On 4 January 2013 08:02, H. Hirzel <[hidden email]> wrote: > > The problem is that Jeff does not have the right to do that > > Yes, and I can't help with that. > > > and he > > likes to have some guidance.... > > I thought that's what I did? "Don't edit the release, make a new one instead" :) > > I don't know how to handle versioning things for packages that work in > multiple images, but perhaps Dave can suggest something? OSProcess has > had to work across multiple Squeaks for ages. I am doing what you suggest, make a new release of each package for each new release. This is actually a change from the way SqueakMap used to work, because I used to be able to declare an OSProcess release that corresponded so some version level of OSProcess itself, and for that release I would select all the Squeak versions that I claimed were compatible. The current SqueakMap approach is more focused on Squeak versions than on versions of the external packages themselves, and it requires the package maintainer to declare a new release every time a new Squeak image is released. From my point of view as a package maintainer this is extra work, and I no longer have any way to indicate that a package such as TwosComplement works across a wide range of Squeak image versions. But from the point of view of an "app store" for Squeak, it supports clear identification of packages that have been validated for a given Squeak image version. Minor annoyances aside, seeing SqueakMap updated and actively used is great, and it's really very little work for package maintainers to do these updates, so I encourage everyone to keep doing so! Since you asked for long-term perspective, I will mention one more thing that I think is sometimes overlooked. We as a community tend to focus on tools and on the main Squeak (or Pharo) image, and assume that there is some base of highly motivated package maintainers who would like nothing better than to spend a few hours or days doing boring and annoying maintenance programming to support the creative endeavors of the central team. In reality, these package maintainers are in the same category as unicorns. There are not really very many of them, and they do not necessarily appear in public just on account of somebody wanting to see one of them ;-) Dave |
|
|
In reply to this post by Jeff Gonis-2
> So I have two questions:
> > 1) Can we make OCompletion into a Community Supported Package? I believe > that it provides considerable benefits when developing in Squeak Its up to Levente. Levente would you prefer the SM catalog entry for OCompletion to be Community-Supported or do you prefer to maintain that yourself? > 2) Once it is community supported, do I just select "Edit Release" on the > 4.2 compatible release, change the compatibility level to Squeak 4.4, update > the name and enter my squeak map id/password? I want to get some experience > doing this, but I'd rather not learn by doing it wrong the first time and > ending up with some egg on my face. > > Maybe a bit of a tutorial on how to go about editing a community supported > package would be helpful. http://wiki.squeak.org/squeak/6180 |
|
|
Hi Everyone, Thanks for the replies. Chris I read the wiki link you posted and from this it would seem that editing the release would be the way to go, as there are no bugs that I can find, or the need to update any of the packages being loaded. Frank, you have suggested I create a new package, however. Can I ask why you suggest a new release? I am open to going with either approach if we decide to make this a community supported package, but I don't have enough information yet to understand why I would choose one approach or the other. Thanks again, Jeff On Fri, Jan 4, 2013 at 9:15 AM, Chris Muller <[hidden email]> wrote:
|
Re: SqueakMap release versions (was: OCompletion package)
|
|
In reply to this post by David T. Lewis
> I am doing what you suggest, make a new release of each package for
> each new release. This is actually a change from the way SqueakMap used > to work, because I used to be able to declare an OSProcess release that > corresponded so some version level of OSProcess itself, and for that > release I would select all the Squeak versions that I claimed were > compatible. I believe this can still be done through the web-interface. > The current SqueakMap approach is more focused on Squeak versions > than on versions of the external packages themselves, and it requires > the package maintainer to declare a new release every time a new > Squeak image is released. From my point of view as a package maintainer > this is extra work, and I no longer have any way to indicate that > a package such as TwosComplement works across a wide range of Squeak > image versions. But from the point of view of an "app store" for > Squeak, it supports clear identification of packages that have been > validated for a given Squeak image version. I can't seem to remember why I couldn't make that list a multi-select -- it may have had to do with limits of the HTTP communication; not sure. In any case, I agree it seems like it should be able to do it. > Minor annoyances aside, seeing SqueakMap updated and actively used is > great, and it's really very little work for package maintainers to do > these updates, so I encourage everyone to keep doing so! Yes, SCM tools are good at SCM but we need something that handles the "Publish" and "Consume" use-cases. > Since you asked for long-term perspective, I will mention one more > thing that I think is sometimes overlooked. We as a community tend to > focus on tools and on the main Squeak (or Pharo) image, and assume > that there is some base of highly motivated package maintainers who > would like nothing better than to spend a few hours or days doing > boring and annoying maintenance programming to support the creative > endeavors of the central team. In reality, these package maintainers > are in the same category as unicorns. There are not really very many > of them, and they do not necessarily appear in public just on account > of somebody wanting to see one of them ;-) LOL! |
|
|
In reply to this post by Jeff Gonis-2
> Thanks for the replies. Chris I read the wiki link you posted and from this
> it would seem that editing the release would be the way to go, as there are > no bugs that I can find, or the need to update any of the packages being > loaded. Frank, you have suggested I create a new package, however. Can I > ask why you suggest a new release? I am open to going with either approach > if we decide to make this a community supported package, but I don't have > enough information yet to understand why I would choose one approach or the > other. The advantage of "Create New Release" over "Edit Release" is that folks still using Squeak 4.2 will keep their entry for OCompletion. Although the web interface can be used to tag compatibility with multiple versions, I'm starting to think "Create New Release" is probably the best way to go.. |
|
|
On 1/4/13, Chris Muller <[hidden email]> wrote:
>> Thanks for the replies. Chris I read the wiki link you posted and from >> this >> it would seem that editing the release would be the way to go, as there >> are >> no bugs that I can find, or the need to update any of the packages being >> loaded. Frank, you have suggested I create a new package, however. Can >> I >> ask why you suggest a new release? I am open to going with either >> approach >> if we decide to make this a community supported package, but I don't have >> enough information yet to understand why I would choose one approach or >> the >> other. > > The advantage of "Create New Release" over "Edit Release" is that > folks still using Squeak 4.2 will keep their entry for OCompletion. > Although the web interface can be used to tag compatibility with > multiple versions, I'm starting to think "Create New Release" is > probably the best way to go.. Then I would say we'd go for "Create New Release". I perceive Chris as Mr. SqueakMap these days, so let's follow the advice of the "expert in residence". --Hannes |
|
|
In reply to this post by Chris Muller-3
On 4 January 2013 17:18, Chris Muller <[hidden email]> wrote:
>> Thanks for the replies. Chris I read the wiki link you posted and from this >> it would seem that editing the release would be the way to go, as there are >> no bugs that I can find, or the need to update any of the packages being >> loaded. Frank, you have suggested I create a new package, however. Can I >> ask why you suggest a new release? I am open to going with either approach >> if we decide to make this a community supported package, but I don't have >> enough information yet to understand why I would choose one approach or the >> other. > > The advantage of "Create New Release" over "Edit Release" is that > folks still using Squeak 4.2 will keep their entry for OCompletion. > Although the web interface can be used to tag compatibility with > multiple versions, I'm starting to think "Create New Release" is > probably the best way to go.. What Chris said. Editing the release means that folks using 4.2 have the meaning of "this version on this image" changed under their feet. Now if (and only if) the code needs no changing, I'd say edit the release to show that it's for both 4.2 and 4.4. But the Release Editor doesn't let you do that at the moment, at least AFAIK. frank |
|
|
Hey Everyone, Just thought I'd send another message to keep this in everyone's minds. Has anyone heard from Levente if it is possible to make OComplete a community supported package? It would be really great to get this marked as supported for 4.4Thanks again, Jeff On Fri, Jan 4, 2013 at 1:04 PM, Frank Shearar <[hidden email]> wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |