Finding class references (Was Re: [squeak-dev] The Trunk: SMLoader-fbs.78.mcz)
Locked
Finding class references (Was Re: [squeak-dev] The Trunk: SMLoader-fbs.78.mcz)
 
|
On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote:
> :) > > I'm working on an InstallerGitHub that will pull in WebClient as > needed So I have something that will happily load chunk-format files: (Installer github user: 'frankshearar' repository: 'Zippers' commitId: 'master') install pulls a zipball down from github, unzips it and loads all the *.st files in that repository. Except that I neglected to consider the small detail that since RootContext subclasses ZipperContext, I must first load (the file containing) ZipperContext before I load (the file containing) RootContext, since class initialization will otherwise fail. Which leaves me in a mild pickle. I can either resolve the load order problem manually - GNU Smalltalk does this, with a package.xml file containing the load order (among other things), or I can try identify class names in each file and load the files in a topologically sorted fashion. The former is brain-dead but requires people to write a package.xml file. The latter is perhaps easier to use but rather more difficult to implement... and possibly fragile. Thoughts? frank |
Re: Finding class references (Was Re: [squeak-dev] The Trunk: SMLoader-fbs.78.mcz)
|
|
Am 26.02.2013 um 16:00 schrieb Frank Shearar <[hidden email]>:
> On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote: >> :) >> >> I'm working on an InstallerGitHub that will pull in WebClient as >> needed > > So I have something that will happily load chunk-format files: > > (Installer github user: 'frankshearar' repository: 'Zippers' commitId: > 'master') install > > pulls a zipball down from github, unzips it and loads all the *.st > files in that repository. > > Except that I neglected to consider the small detail that since > RootContext subclasses ZipperContext, I must first load (the file > containing) ZipperContext before I load (the file containing) > RootContext, since class initialization will otherwise fail. > > Which leaves me in a mild pickle. I can either resolve the load order > problem manually - GNU Smalltalk does this, with a package.xml file > containing the load order (among other things), or I can try identify > class names in each file and load the files in a topologically sorted > fashion. > > The former is brain-dead but requires people to write a package.xml > file. The latter is perhaps easier to use but rather more difficult to > implement... and possibly fragile. > > Thoughts? Cypress[1]/FileTree[2]? [1] https://github.com/CampSmalltalk/Cypress [2] https://github.com/dalehenrich/filetree differently said, When you load filetree, you can access github-filetree based projects via a monticello api... more details at dale :) Best -Tobias |
Re: Finding class references (Was Re: [squeak-dev] The Trunk: SMLoader-fbs.78.mcz)
|
|
In reply to this post by Frank Shearar-3
On 2013-02-26, at 16:00, Frank Shearar <[hidden email]> wrote:
> On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote: >> :) >> >> I'm working on an InstallerGitHub that will pull in WebClient as >> needed WebClient is on Github? What about this: http://www.squeaksource.com/WebClient.html > So I have something that will happily load chunk-format files: > > (Installer github user: 'frankshearar' repository: 'Zippers' commitId: > 'master') install > > pulls a zipball down from github, unzips it and loads all the *.st > files in that repository. > > Except that I neglected to consider the small detail that since > RootContext subclasses ZipperContext, I must first load (the file > containing) ZipperContext before I load (the file containing) > RootContext, since class initialization will otherwise fail. > > Which leaves me in a mild pickle. I can either resolve the load order > problem manually - GNU Smalltalk does this, with a package.xml file > containing the load order (among other things), or I can try identify > class names in each file and load the files in a topologically sorted > fashion. > > The former is brain-dead but requires people to write a package.xml > file. The latter is perhaps easier to use but rather more difficult to > implement... and possibly fragile. > > Thoughts? Well, doing the topo sorting automatically sounds good. You may be able to employ MCStReader and MCDependencySorter for that. But then, why not use MC in the first place? I'm surprised you're not using the MC FileTree package format, which would let Monticello do all its loading magic. See e.g. https://github.com/bertfreudenberg/gezira/tree/master/bindings/squeak - Bert - |
Re: Finding class references (Was Re: [squeak-dev] The Trunk: SMLoader-fbs.78.mcz)
|
|
On 26 February 2013 15:53, Bert Freudenberg <[hidden email]> wrote:
> On 2013-02-26, at 16:00, Frank Shearar <[hidden email]> wrote: > >> On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote: >>> :) >>> >>> I'm working on an InstallerGitHub that will pull in WebClient as >>> needed > > WebClient is on Github? What about this: > > http://www.squeaksource.com/WebClient.html No, this thing will pull in WebClient the way SMLoader does when you first open up SqueakMap. >> So I have something that will happily load chunk-format files: >> >> (Installer github user: 'frankshearar' repository: 'Zippers' commitId: >> 'master') install >> >> pulls a zipball down from github, unzips it and loads all the *.st >> files in that repository. >> >> Except that I neglected to consider the small detail that since >> RootContext subclasses ZipperContext, I must first load (the file >> containing) ZipperContext before I load (the file containing) >> RootContext, since class initialization will otherwise fail. >> >> Which leaves me in a mild pickle. I can either resolve the load order >> problem manually - GNU Smalltalk does this, with a package.xml file >> containing the load order (among other things), or I can try identify >> class names in each file and load the files in a topologically sorted >> fashion. >> >> The former is brain-dead but requires people to write a package.xml >> file. The latter is perhaps easier to use but rather more difficult to >> implement... and possibly fragile. >> >> Thoughts? > > Well, doing the topo sorting automatically sounds good. You may be able to employ MCStReader and MCDependencySorter for that. But then, why not use MC in the first place? > > I'm surprised you're not using the MC FileTree package format, which would let Monticello do all its loading magic. See e.g. > > https://github.com/bertfreudenberg/gezira/tree/master/bindings/squeak I've used Filetree. I understand why Dale wrote it the way it does - mapping the smallest unit of code to a file. I understand the benefits of doing so - no inter-method merge issues, tracking history of a single method. And I still don't want to use it because it breaks using GitHub's interface to look at code. What I'm trying to find is the sweet spot between using a version control system on the file system (git, in particular) and working in the image. In particular, I don't want to HAVE TO work in the image, which I do with Monticello and Filetree (because it's an MC back end). I _do_ use Filetree - https://github.com/frankshearar/Control for instance - but I'm convinced there must be a better way. frank > - Bert - > > > |
FileTree etc. (was: Finding class references)
|
|
On 2013-02-26, at 18:19, Frank Shearar <[hidden email]> wrote: > On 26 February 2013 15:53, Bert Freudenberg <[hidden email]> wrote: >> On 2013-02-26, at 16:00, Frank Shearar <[hidden email]> wrote: >> >>> On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote: >>>> :) >>>> >>>> I'm working on an InstallerGitHub that will pull in WebClient as >>>> needed >> >> WebClient is on Github? What about this: >> >> http://www.squeaksource.com/WebClient.html > > No, this thing will pull in WebClient the way SMLoader does when you > first open up SqueakMap. How does a github installer help with that? >>> So I have something that will happily load chunk-format files: >>> >>> (Installer github user: 'frankshearar' repository: 'Zippers' commitId: >>> 'master') install >>> >>> pulls a zipball down from github, unzips it and loads all the *.st >>> files in that repository. >>> >>> Except that I neglected to consider the small detail that since >>> RootContext subclasses ZipperContext, I must first load (the file >>> containing) ZipperContext before I load (the file containing) >>> RootContext, since class initialization will otherwise fail. >>> >>> Which leaves me in a mild pickle. I can either resolve the load order >>> problem manually - GNU Smalltalk does this, with a package.xml file >>> containing the load order (among other things), or I can try identify >>> class names in each file and load the files in a topologically sorted >>> fashion. >>> >>> The former is brain-dead but requires people to write a package.xml >>> file. The latter is perhaps easier to use but rather more difficult to >>> implement... and possibly fragile. >>> >>> Thoughts? >> >> Well, doing the topo sorting automatically sounds good. You may be able to employ MCStReader and MCDependencySorter for that. But then, why not use MC in the first place? >> >> I'm surprised you're not using the MC FileTree package format, which would let Monticello do all its loading magic. See e.g. >> >> https://github.com/bertfreudenberg/gezira/tree/master/bindings/squeak > > I've used Filetree. I understand why Dale wrote it the way it does - > mapping the smallest unit of code to a file. I understand the benefits > of doing so - no inter-method merge issues, tracking history of a > single method. And I still don't want to use it because it breaks > using GitHub's interface to look at code. > > What I'm trying to find is the sweet spot between using a version > control system on the file system (git, in particular) and working in > the image. In particular, I don't want to HAVE TO work in the image, > which I do with Monticello and Filetree (because it's an MC back end). > > I _do_ use Filetree - https://github.com/frankshearar/Control for > instance - but I'm convinced there must be a better way. > > frank Agreed, it's not nice to look at. But neither is chunk format. Maybe you should give the Coral syntax a try ... OTOH that seems useful mostly if you actually switch over to coding externally, building images fresh every time. So it only needs to support installing code, not updating code in the image (which would e.g. require removing older methods, too). For maintaining images collaboratively, we haven't found anything better than Monticello, yet. That's why a Monticello backend is still desirable. IIRC FileTree can actually handle various directory formats, maybe one that does not split each method into a file would be the solution? - Bert - |
Re: FileTree etc. (was: Finding class references)
|
|
On 26 February 2013 18:12, Bert Freudenberg <[hidden email]> wrote:
> > On 2013-02-26, at 18:19, Frank Shearar <[hidden email]> wrote: > >> On 26 February 2013 15:53, Bert Freudenberg <[hidden email]> wrote: >>> On 2013-02-26, at 16:00, Frank Shearar <[hidden email]> wrote: >>> >>>> On 26 February 2013 07:21, Frank Shearar <[hidden email]> wrote: >>>>> :) >>>>> >>>>> I'm working on an InstallerGitHub that will pull in WebClient as >>>>> needed >>> >>> WebClient is on Github? What about this: >>> >>> http://www.squeaksource.com/WebClient.html >> >> No, this thing will pull in WebClient the way SMLoader does when you >> first open up SqueakMap. > > How does a github installer help with that? It doesn't. It has nothing to do with anything other than the thread from which this thread spawned mentioned it :) >>>> So I have something that will happily load chunk-format files: >>>> >>>> (Installer github user: 'frankshearar' repository: 'Zippers' commitId: >>>> 'master') install >>>> >>>> pulls a zipball down from github, unzips it and loads all the *.st >>>> files in that repository. >>>> >>>> Except that I neglected to consider the small detail that since >>>> RootContext subclasses ZipperContext, I must first load (the file >>>> containing) ZipperContext before I load (the file containing) >>>> RootContext, since class initialization will otherwise fail. >>>> >>>> Which leaves me in a mild pickle. I can either resolve the load order >>>> problem manually - GNU Smalltalk does this, with a package.xml file >>>> containing the load order (among other things), or I can try identify >>>> class names in each file and load the files in a topologically sorted >>>> fashion. >>>> >>>> The former is brain-dead but requires people to write a package.xml >>>> file. The latter is perhaps easier to use but rather more difficult to >>>> implement... and possibly fragile. >>>> >>>> Thoughts? >>> >>> Well, doing the topo sorting automatically sounds good. You may be able to employ MCStReader and MCDependencySorter for that. But then, why not use MC in the first place? >>> >>> I'm surprised you're not using the MC FileTree package format, which would let Monticello do all its loading magic. See e.g. >>> >>> https://github.com/bertfreudenberg/gezira/tree/master/bindings/squeak >> >> I've used Filetree. I understand why Dale wrote it the way it does - >> mapping the smallest unit of code to a file. I understand the benefits >> of doing so - no inter-method merge issues, tracking history of a >> single method. And I still don't want to use it because it breaks >> using GitHub's interface to look at code. >> >> What I'm trying to find is the sweet spot between using a version >> control system on the file system (git, in particular) and working in >> the image. In particular, I don't want to HAVE TO work in the image, >> which I do with Monticello and Filetree (because it's an MC back end). >> >> I _do_ use Filetree - https://github.com/frankshearar/Control for >> instance - but I'm convinced there must be a better way. >> >> frank > > > Agreed, it's not nice to look at. But neither is chunk format. Maybe you should give the Coral syntax a try ... Surprisingly enough, I dislike Coral syntax! Mainly because it's gratuitously different from GNU Smalltalk's. Eventually I'll get around to implementing GNU Smalltalk syntax, which only has one really ugly part, and that's that class variables are implicitly defined. > OTOH that seems useful mostly if you actually switch over to coding externally, building images fresh every time. So it only needs to support installing code, not updating code in the image (which would e.g. require removing older methods, too). For maintaining images collaboratively, we haven't found anything better than Monticello, yet. That's why a Monticello backend is still desirable. IIRC FileTree can actually handle various directory formats, maybe one that does not split each method into a file would be the solution? Well as it turns out MC has an excellent chunk format reader - thanks for pointing me to MCStReader and MCDependencySorter. I _do_ want to make developing outside the image a lot easier. To be precise: I want to be able to choose how much in-image work I'd like to do. I'd like to swizzle my source in a nice syntax that groups things better/more coarsely than one-method-per-file and looks better than chunk format. That would let me use GitHub the way it's meant to be used. I'd like to develop the source in-image if I feel like it, or hack on it in Emacs if that's quicker. I do very much want to move towards building images up rather than trying to extract them from my development environment. frank > - Bert - > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |