On Thu, Nov 21, 2013 at 5:12 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
>
>
> On 22 November 2013 01:59, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>>
>>
>>
>> On Thu, Nov 21, 2013 at 4:40 PM, Igor Stasenko <siguctua at gmail.com>wrote:
>>
>>> Hi, Eliot
>>>
>>> you have good point. One of the strengths of having SCM under our control
>>> is that we can easily extend it for advanced uses (like history analysis
>>> you mentioned,
>>> and proper metadata handling, loading/initialization order etc etc)
>>>
>>> but there was a good reason for 'surrendering' VMMaker to git.
>>>
>>
>>  But I didn't.  VMMaker is still under Monticello.  What I did was store
>> generated sources in svn *alongside* the existing platform sources.  IIRC,
>> Ian Piumarta had already done this with the unix builds.
>>
>
> You know my opinion in that regard: generated code is already a build
> process artifact,
> in this regard, storing it under SCM, is nothing better as if you would
> just store compiled VM binary too. And besides, where is guarantees that
> you can recreate them from first principles?
> I know, you also storing .image and .changes files, which even worse..
> causing
> a huge bloat in repository, but works as a poor-man's solution to desync
> problem :)
>

In fact it's a waste of space.  I never keep it up-to-date.  I should nuke
it and rely on Metacello to recreate VMMaker images.

Because having parts of VM sources stored in MC package , while other
>>> parts  ALREADY in
>>> external repository is even worse, which was always causing problems of
>>> desync
>>> and messy and complicated update process.
>>>
>>
>> Agreed.
>>
>>
>>> Now it is in one repository, which means single git shapshot == full
>>> sources for given version of VM which simplifies process A LOT.. this
>>> simply overweights all the drawbacks of surrendering to git IMO.
>>>
>>
>> But I haven't surrendered VMMaker to git.
>>
>
> I know, but we (in Pharo) did.
>
>
>>
>>
>>> And regarding name too long issue, i think it easy to solve: just get
>>> rid of that infamous Genie plugin, which nobody using anyways, or at least
>>> it needs serious refactoring,
>>> because you really need to be genius to know how to properly use
>>> primitive which takes 15+ arguments. Its just insane :)
>>>
>>
>> That's not a solution.  That's avoidance ;-).
>>
>>
> sure. but in this particular case, i think more fitting term would be
> "legacy code cleanup" :)
>
>
>>
>>>
>>>
>>> On 20 November 2013 18:46, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>>
>>>> Hi Frank,
>>>>
>>>> On Wed, Nov 20, 2013 at 2:10 AM, Frank Shearar <frank.shearar at gmail.com
>>>> > wrote:
>>>>
>>>>> On 19 November 2013 22:00, Eliot Miranda <eliot.miranda at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Tue, Nov 19, 2013 at 1:39 PM, Frank Shearar <
>>>>> frank.shearar at gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> On 19 November 2013 21:24, Eliot Miranda <eliot.miranda at gmail.com>
>>>>> wrote:
>>>>> >> > Hi Frank,
>>>>> >> >
>>>>> >> > On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <
>>>>> frank.shearar at gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> On 8 November 2013 22:30, Chris Muller <asqueaker at gmail.com>
>>>>> wrote:
>>>>> >> >> > The trunk is a huge part of the Squeak development process and
>>>>> >> >> > ecosystem that deserves and needs representation somewhere in
>>>>> the
>>>>> >> >> > system.  Access to it is reasonably needed by ReleaseBuilder,
>>>>> >> >> > Installer, source.squeak.org's SqueakSource and
>>>>> >> >> > MonticelloConfigurations.
>>>>> >> >>
>>>>> >> >> Does noone else in the Squeak community use MCMs? I don't, but my
>>>>> >> >> libraries are all very, very small.
>>>>> >> >>
>>>>> >> >> > Squeak has been using its own flavor of Monticello for several
>>>>> years
>>>>> >> >> > now, as does Pharo and GemStone.  So, to me, it feels fine to
>>>>> make it
>>>>> >> >> > Monticello-For-Squeak, meaning to relax restrictions imposed by
>>>>> >> >> > multiplatform so it can go as far as we want toward supporting
>>>>> the
>>>>> >> >> > Squeak process.
>>>>> >> >>
>>>>> >> >> It's not really germane to this discussion, but if I could flick
>>>>> a
>>>>> >> >> switch and have us updating from github, I would do so without
>>>>> >> >> hesitation. Monticello predates git by about 3 years, so we were
>>>>> right
>>>>> >> >> on the bleeding edge there for a while, but git is now very,
>>>>> very far
>>>>> >> >> ahead. It just makes so much sense to me to just use a world
>>>>> class
>>>>> >> >> tool that _we don't have to maintain_. (*)
>>>>> >> >
>>>>> >> >
>>>>> >> > Here's an example of why surrendering one's source code control to
>>>>> >> > something
>>>>> >> > else is a really bad idea for an IDE:
>>>>> >>
>>>>> >> An IDE _always_ (*) surrenders source code control to something
>>>>> else!
>>>>> >> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,
>>>>> >> IntelliJ, ...
>>>>> >
>>>>> >
>>>>> > No it doesn't.  And the fact that all the ones you mention do isn't a
>>>>> > strength.  All IDEs I know of surrender the *storage* of the
>>>>> repository to
>>>>> > something else, a file system, a database, a remote directory.  But
>>>>> lots of
>>>>> > Smalltalk environments keep firm control of their own source code
>>>>> control,
>>>>> > Store in VisualWorks, Orwell and later Team/V in Digitalk,
>>>>> Monticello in
>>>>> > Squeal/Pharo.  Just the addition of the simple version scheme in
>>>>> Squeak
>>>>> > changes & sources files puts it head and shoulders ahead of
>>>>> VisualWorks in
>>>>> > the ease of investigating history, undoing changes, etc.  This is
>>>>> vital to
>>>>> > the ease of programming, its flow, etc.  Squeak doers a great ob.  We
>>>>> > surrender that to something else at our peril.
>>>>>
>>>>> Mild talking past each other here. IntelliJ uses your favourite
>>>>> version control system under the hood to store your code: it supplies
>>>>> menus for driving, for instance, git to commit code and whatnot. It
>>>>> does, in addition, store versions for every time you hit enter (or
>>>>> after a period of time). These are distinct features. I'm not
>>>>> proposing losing the versions button or using git to store the data
>>>>> behind the versions button.
>>>>>
>>>>> I'm proposing that we keep the Monticello front end, add a few new
>>>>> buttons, and rip out the storage of source on disk, replacing it with
>>>>> git. I have yet to find a decent mapping of Smalltalk code to files,
>>>>> but I'd put up with a crap one if it meant one less thing that we
>>>>> didn't need to do.
>>>>>
>>>>
>>>> Replacing the simplest part of Monticello (storing files on disc) with
>>>> something much more complex (n interface with git) does not make any sense
>>>> to me.  The system already has an interface to files, already has an
>>>> interface to a webdav repository, etc.  These already work really well.
>>>>  Does it really need an interface with something that has complex state,
>>>> can get mucked up, is open to meddling through the file-system, can get out
>>>> of sync, etc, etc.  All of these pathologies have happened with
>>>> MemoryHole's use of mercurial.  They can and will happen with git.
>>>>  Monticello is bedrock.  KISS.
>>>>
>>>> Smalltalk was 30 years ahead of its time in 1980. It's now a decade
>>>>> behind other languages. That is a tragedy that, in my opinion at
>>>>> least, largely comes from the Smalltalk community's extreme
>>>>> insularity/NIH.
>>>>>
>>>>
>>>> I agree and don't like the NIH syndrome.  Smalltalk should play well
>>>> with others.  That Squeak doesn't excel here is one reason for it's lack of
>>>> popularity.  To improve it ability to play well with others is one of the
>>>> design goals behind Spur.  But playing well with others, for me, does not
>>>> imply weakening strong parts of the system.  Make the FFI better, don't
>>>> make Monticello worse.  Make the VM loadable as a dll.  Don't replace the
>>>> programming environment with Eclipse.
>>>>
>>>>
>>>> > One of the things we're not doing is trying to solve looking at
>>>>> long-term
>>>>> > history (ie. some kind of server that serves the long-term history of
>>>>> > packages).
>>>>> >
>>>>> > Something I'm really excited to see the Pharo folks looking at is
>>>>> richer
>>>>> > change analysis than just method history, i.e. being able to spot
>>>>> method
>>>>> > refactorings, class renames and class hierarchy refactorings.
>>>>>
>>>>> >> (*) Squeak being the exception
>>>>> >
>>>>> >
>>>>> > Smalltalk being the exception actually.  Smalltalk has proved
>>>>> powerful
>>>>> > enough for it to provide its own source code control, and that's
>>>>> been a
>>>>> > great strength.
>>>>>
>>>>> I claim synecdoche :)
>>>>>
>>>>> >  AT work I have to use a thin skin above Mercurial that is
>>>>> > the solution for Newspeak and I despise it.  Compared to Monticello,
>>>>> it's
>>>>> > junk.
>>>>>
>>>>> I've not used MemoryHole, so I have no idea how much of "it's junk"
>>>>> comes from mercurial and how much from MemoryHole.
>>>>
>>>>
>>>> Most of it comes from Mercurial.  MemoryHole is broken w.r.t. merging,
>>>> and that's its problem.  But much of the interface between it and mercurial
>>>> is confused and buggy, and that's the problem of trying to keep two complex
>>>> beasts in sync.
>>>>
>>>>
>>>>> I do know that the
>>>>> biggest reason I've not written any Newspeak (and I'm fully aware that
>>>>> I have failed in communicating this to Gilad) is that I don't want to
>>>>> touch the UI with a barge pole. I made a tiny start at writing a
>>>>> newspeak-mode for Emacs, and that's as far as I got.
>>>>>
>>>>
>>>> But the UI (Hopscotch and Brazil) is great.  Vassili's engineered
>>>> something really powerful and elegant there.  It's not complete; only one
>>>> person's worked on it.  But it's innovative and provides radically better
>>>> tools.  For example, the ability to see as many open methods as one wants
>>>> on the stack in the debugger.
>>>>
>>>>>
>>>>> >> The given error is unfortunate, but that's not even git's fault -
>>>>> >> "Filename too long" says it all. That super long filename comes from
>>>>> >> filetree, so the error's existent is a confluence of a particular
>>>>> >> source->file mapping together with a file system limitation.
>>>>> >
>>>>> >
>>>>> > But the net effect is the same.  By relying on something external
>>>>> the system
>>>>> > broke.  And it's not easy for the Pharo community to get it fixed.
>>>>>  They'll
>>>>> > have to wrk-around the problem, and compromise something they want
>>>>> in their
>>>>> > name mangling.  I live with crap like this all the time in building
>>>>> the VM
>>>>> > (mingw and cygwin are awful things to depend on).  At least in the VM
>>>>> > building context (and Newspeak) it is only a few souls who have to
>>>>> suffer.
>>>>> > I hope we don't inflict this kind of thing on the general Squeak
>>>>> community.
>>>>>
>>>>> Sure. Bugs are bugs. Let's not forget the recent Monticello fail
>>>>> regarding UTF-8. We'll also _always_ depend on something. But that
>>>>> doesn't mean that we should take responsibility for the entire world,
>>>>> because we don't have the manpower. Even if we did, it's not even a
>>>>> good idea.
>>>>>
>>>>
>>>> Agreed.  But having excellent control of Smalltalk programs is a must
>>>> have and relying on an external source code control system that is designed
>>>> for files won't accomplish that.
>>>>
>>>>
>>>>> frank
>>>>>
>>>>> >> > "When doing a git clone, I do get the following:
>>>>> >> >
>>>>> >> >
>>>>> >> > Philippe at gravitation7 ~
>>>>> >> > $ git clone --depth=1
>>>>> https://github.com/pharo-project/pharo-vm.git
>>>>> >> > Cloning into 'pharo-vm'...
>>>>> >> > remote: Counting objects: 17493, done.
>>>>> >> > remote: Compressing objects: 100% (12363/12363), done.
>>>>> >> > remote: Total 17493 (delta 4271), reused 17137 (delta 4143)
>>>>> >> > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s,
>>>>> done.
>>>>> >> > Resolving deltas: 100% (4271/4271), done.
>>>>> >> > Checking connectivity... done
>>>>> >> > error: unable to create file
>>>>> >> > mc/VMMaker-oscog.package/GeniePlugin.class/instance
>>>>> >> >
>>>>> >> >
>>>>> /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.
>>>>> >> >
>>>>> >> >
>>>>> mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla
>>>>> >> > g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too
>>>>> long)
>>>>> >> > Checking out files: 100% (17525/17525), done.
>>>>> >> > fatal: unable to checkout working tree
>>>>> >> > warning: Clone succeeded, but checkout failed.
>>>>> >> > You can inspect what was checked out with 'git status'
>>>>> >> > and retry the checkout with 'git checkout -f HEAD'
>>>>> >> >
>>>>> >> > Pretty weird error I'd say.
>>>>> >> >
>>>>> >> > Anyone knowing what this is related to?"
>>>>> >> >
>>>>> >> > IMO having Monticello under our own control is a key strength.
>>>>>  yes,
>>>>> >> > it's
>>>>> >> > effortful to maintain but I don't see why we can't summon that
>>>>> effort.
>>>>> >> > I do
>>>>> >> > fear that if we don't we just become like everything else and soon
>>>>> >> > enough
>>>>> >> > we're just another scripting language.  The Smalltalk team had a
>>>>> name
>>>>> >> > for
>>>>> >> > this, something like "error 22", meaning depending on the success
>>>>> of
>>>>> >> > other
>>>>> >> > projects or infrastructure.  It's a bad idea, unless its bedrock.
>>>>> >>
>>>>> >> Monticello was great, back in the day. But why do we _have_ to
>>>>> saddle
>>>>> >> ourselves with the effort of maintaining it ourselves? What else
>>>>> might
>>>>> >> we _better_ do if we didn't spend all our time NIHing everything?
>>>>> >>
>>>>> >> And now, 7 years of git later, I'd consider git to be bedrock. Git
>>>>> >> _has succeeded_. It and mercurial have gutted the competition:
>>>>> darcs,
>>>>> >> monotone, bazaar, ...
>>>>> >>
>>>>> >> frank
>>>>> >>
>>>>> >> >> > Having said that, I must admit this really does make it
>>>>> >> >> > Squeak-specific, no longer generic.  So, maybe an alternative
>>>>> should
>>>>> >> >> > be to model our development process elements in a new package,
>>>>> >> >> > SqueakDevelopmentProcess (?), which would depend on our
>>>>> Squeak's
>>>>> >> >> > generic Monticello to represent the elements of our development
>>>>> >> >> > process.
>>>>> >> >>
>>>>> >> >> I'm not terribly concerned with Squeak-specific or otherwise.
>>>>> It's
>>>>> >> >> just that it's _trunk_ specific. I'd rather see a
>>>>> >> >> SqueakDevelopmentProcess package than see it in the Monticello
>>>>> >> >> package.
>>>>> >> >>
>>>>> >> >> frank
>>>>> >> >>
>>>>> >> >> (*) Finding that switch to flick is pretty hard though, which is
>>>>> why I
>>>>> >> >> don't rant and rave about this all the time. Filetree's OK, but
>>>>> >> >> destroys the ability of browsing source on the git repository
>>>>> (but
>>>>> >> >> gives you the proper fine-grained version control you'd want).
>>>>> >> >> gitfiletree supplies a Pharo UI to filetree, and it would be
>>>>> >> >> worthwhile to port that UI to Squeak, through
>>>>> ToolBuilderification.
>>>>> >> >> Continuing this discussion would necessitate a subject thread
>>>>> change!
>>>>> >> >>
>>>>> >> >> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier
>>>>> >> >> > <nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>> >> >> >> I have same feeling as Frank,
>>>>> >> >> >> a specific address of a specific repository for a specific
>>>>> usage has
>>>>> >> >> >> not
>>>>> >> >> >> much thing to do in MC.
>>>>> >> >> >> MC package should not integrate each and every possible usage
>>>>> of MC.
>>>>> >> >> >> If this does not belong to ReleaseBuilder, then we can make
>>>>> it a
>>>>> >> >> >> System
>>>>> >> >> >> thing...
>>>>> >> >> >> If it's only for MCM, didn't we get a MCMcmUpdater
>>>>> defaultUpdateURL?
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >> 2013/11/8 Chris Muller <asqueaker at gmail.com>
>>>>> >> >> >>>
>>>>> >> >> >>> MonticelloConfigurations has no dependency on ReleaseBuilder
>>>>> and I
>>>>> >> >> >>> don't think we should introduce one.
>>>>> >> >> >>>
>>>>> >> >> >>> If you at least acknowledge "trunk" is a real-thing in the
>>>>> real
>>>>> >> >> >>> world,
>>>>> >> >> >>> then note existence of MCRepository>>#trunk.  Sure, we could
>>>>> make a
>>>>> >> >> >>> class-var or something if that helps you feel better, but my
>>>>> >> >> >>> opinion
>>>>> >> >> >>> right now is that is not necessary because code can change
>>>>> if/when
>>>>> >> >> >>> it
>>>>> >> >> >>> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect
>>>>> be the
>>>>> >> >> >>> enemy of pragmatic progress in the present.
>>>>> >> >> >>>
>>>>> >> >> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar
>>>>> >> >> >>> <frank.shearar at gmail.com>
>>>>> >> >> >>> wrote:
>>>>> >> >> >>> > On 8 November 2013 15:25,  <commits at source.squeak.org>
>>>>> wrote:
>>>>> >> >> >>> >> Chris Muller uploaded a new version of Monticello to
>>>>> project The
>>>>> >> >> >>> >> Trunk:
>>>>> >> >> >>> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> ==================== Summary ====================
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> Name: Monticello-cmm.575
>>>>> >> >> >>> >> Author: cmm
>>>>> >> >> >>> >> Time: 3 October 2013, 9:42:40.555 pm
>>>>> >> >> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
>>>>> >> >> >>> >> Ancestors: Monticello-cmm.573
>>>>> >> >> >>> >>
>>>>> >> >> >>> >> - Integrate Berts suggestions.  Refactored and renamed
>>>>> the API
>>>>> >> >> >>> >> for
>>>>> >> >> >>> >> the
>>>>> >> >> >>> >> new history and origin browsing functions to avoid
>>>>> ambiguity
>>>>> >> >> >>> >> with
>>>>> >> >> >>> >> other MC
>>>>> >> >> >>> >> domain elements.  Went from "version" nomenclature to
>>>>> "history".
>>>>> >> >> >>> >> - Related to those functions, browsing a list of patch
>>>>> >> >> >>> >> operations
>>>>> >> >> >>> >> is
>>>>> >> >> >>> >> now abstracted from browsing a Patch.  MCPatch is now a
>>>>> >> >> >>> >> MCOperationsList
>>>>> >> >> >>> >> and, likewise, a MCPatchBrowser inherits from a
>>>>> >> >> >>> >> MCOperationsBrowser.
>>>>> >> >> >>> >> - Added well-known repository accessors for #trunk and
>>>>> >> >> >>> >> #packageCache,
>>>>> >> >> >>> >> and #trunkUrlString avoids scattering the hard-coded url
>>>>> string
>>>>> >> >> >>> >> literal in
>>>>> >> >> >>> >> so many places.
>>>>> >> >> >>> >
>>>>> >> >> >>> > I don't like this last item. MCHttpRepository has no
>>>>> business
>>>>> >> >> >>> > knowing
>>>>> >> >> >>> > about any particular location, nor should we commit
>>>>> ourselves to
>>>>> >> >> >>> > any
>>>>> >> >> >>> > particular repository implementation. For instance, it
>>>>> might make
>>>>> >> >> >>> > a
>>>>> >> >> >>> > whole lot of sense to build a repository backed by
>>>>> Cassandra.
>>>>> >> >> >>> >
>>>>> >> >> >>> > I'm not convinced that ReleaseBuilder isn't the right
>>>>> place for
>>>>> >> >> >>> > this
>>>>> >> >> >>> > info. Or, to avoid the double negative, I think
>>>>> ReleaseBuilder is
>>>>> >> >> >>> > the
>>>>> >> >> >>> > place that should know about the trunk URL, because
>>>>> >> >> >>> > ReleaseBuilder's
>>>>> >> >> >>> > the class responsible for this kind of thing. One kind of
>>>>> release
>>>>> >> >> >>> > we
>>>>> >> >> >>> > build is a release candidate, for instance.
>>>>> >> >> >>> >
>>>>> >> >> >>> > frank
>>>>> >> >> >>> >
>>>>> >> >> >>>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >>
>>>>> >> >> >
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> > --
>>>>> >> > best,
>>>>> >> > Eliot
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > best,
>>>>> > Eliot
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> Eliot
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131121/69f6b533/attachment.htm