I actualize Monticello and PackageInfo for let trunk could use “ProcustesEnd”, or Monticello behave like old friend SAR and you could save into squeaksource code, picts, music, initialized Morphs, etc. What I test. Load Squeak3.10.2-Trunk-091024. Hit updates button, save as Squeak3.10.2-trunk.2009-11-16.image. In Monticello , add MCHttpRepository location: 'http://squeaksource.com/Ladrillos' user: 'squeak' password: 'squeak' Load Monticello-edc.333, should loads PackageInfo-Base-edc.31. Then load MorphicPuzzle-edc.2. Enjoy ! I left the polish of this to younger Squeakers Edgar. FunTrunk.2.jpg (33K) Download Attachment |
On Mon, Nov 16, 2009 at 09:54:22AM -0200, Edgar J. De Cleene wrote:
> > I actualize Monticello and PackageInfo for let trunk could use > ?ProcustesEnd?, or Monticello behave like old friend SAR and you could save > into squeaksource code, picts, music, initialized Morphs, etc. > > What I test. > Load Squeak3.10.2-Trunk-091024. > Hit updates button, save as Squeak3.10.2-trunk.2009-11-16.image. > > In Monticello , add MCHttpRepository > location: 'http://squeaksource.com/Ladrillos' > user: 'squeak' > password: 'squeak' > > Load Monticello-edc.333, should loads PackageInfo-Base-edc.31. > Then load MorphicPuzzle-edc.2. Thanks Edgar, this is great! I am not a Monticello expert, but I wonder what others think of Edgar's extensions for storing non-code things in an MC archive? I also note that loading MorphicPuzzle on a 64-bit Linux VM exposes a VM bug (it works fine on a 32-bit VM though): lewis@linux-6xfc:~/squeak/Squeak3.10-dev> Segmentation fault 44600172 JPEGReadWriter2>nextImageSuggestedDepth: 44600080 JPEGReadWriter2>nextImage 44599988 >formFromStream: 44599884 BlockClosure>ensure: 44599792 Cursor>showWhile: 44590412 >formFromStream: 44590296 >fromBinaryStream: 43898440 >initialize Dave |
On 16-Nov-09, at 6:25 AM, David T. Lewis wrote: > I am not a Monticello expert, but I wonder what others think of > Edgar's extensions for storing non-code things in an MC archive? I haven't looked at Edgar's work in particular, but I have to say I don't like the general trend of using MC as deployment tool rather than a development tool. MC was not designed for deployment, but the fact that individual versions in an MC repository can be referenced by URL make it really tempting to just skip the whole packaging-for- deployment step and just deploy straight out of the repository. I think this weakens MC as a development tool, while also obscuring the weaknesses in our deployment technologies. Edgar mentioned SAR, which is the best deployment technology we have at the moment. What's missing from SAR that requires MC provides? I think it would be better to add (deployment) functionality to SAR than to MC. Colin |
On Mon, Nov 16, 2009 at 08:00:16AM -0800, Colin Putney wrote:
> > On 16-Nov-09, at 6:25 AM, David T. Lewis wrote: > > >I am not a Monticello expert, but I wonder what others think of > >Edgar's extensions for storing non-code things in an MC archive? > > I haven't looked at Edgar's work in particular, but I have to say I > don't like the general trend of using MC as deployment tool rather > than a development tool. MC was not designed for deployment, but the > fact that individual versions in an MC repository can be referenced by > URL make it really tempting to just skip the whole packaging-for- > deployment step and just deploy straight out of the repository. I > think this weakens MC as a development tool, while also obscuring the > weaknesses in our deployment technologies. > > Edgar mentioned SAR, which is the best deployment technology we have > at the moment. What's missing from SAR that requires MC provides? I > think it would be better to add (deployment) functionality to SAR than > to MC. That makes good sense to me. Dave |
In reply to this post by Colin Putney
On Mon, 2009-11-16 at 08:00 -0800, Colin Putney wrote:
> On 16-Nov-09, at 6:25 AM, David T. Lewis wrote: > > > I am not a Monticello expert, but I wonder what others think of > > Edgar's extensions for storing non-code things in an MC archive? > > I haven't looked at Edgar's work in particular, but I have to say I > don't like the general trend of using MC as deployment tool rather > than a development tool. MC was not designed for deployment, but the > fact that individual versions in an MC repository can be referenced by > URL make it really tempting to just skip the whole packaging-for- > deployment step and just deploy straight out of the repository. I > think this weakens MC as a development tool, while also obscuring the > weaknesses in our deployment technologies. > > Edgar mentioned SAR, which is the best deployment technology we have > at the moment. What's missing from SAR that requires MC provides? I > think it would be better to add (deployment) functionality to SAR than > to MC. > > Colin Ken signature.asc (197 bytes) Download Attachment |
Free forum by Nabble | Edit this page |