[Cuis-dev] Package dependencies satisfaction (was Re: Converting Tonel packages)

Thierry Goubier thierry.goubier at gmail.com
Fri Aug 30 04:39:22 PDT 2019


Hi Chris, David,

thanks guys.

Out of topic, but related. Do package dependencies satisfaction a
significant issue in development and deployment, and if yes, how that
could be addressed?

I'm familiar with Metacello/Gofer up to the version ordering
implementation details and the constraints it brings on the filetree
implementation; I've seen recently in the golang space this
(https://blog.golang.org/versioning-proposal) and all the Russ Cox
blog posts on the subject. How does Cuis stands about that?

Regards,

Thierry

Le ven. 30 août 2019 à 07:06, Chris Muller via Cuis-dev
<cuis-dev at lists.cuis.st> a écrit :
>
> On Thu, Aug 29, 2019 at 5:41 PM David T. Lewis via Cuis-dev <cuis-dev at lists.cuis.st> wrote:
>>
>> Thierry,
>>
>> I am a casual user of various git tools in Cuis, Squeak and Pharo,
>> and your explanation is very helpful for me to understand some of
>> the tradeoffs.
>
>
> +1 me too.    :)
>
>
>>
>>
>> Thanks,
>> Dave
>>
>>
>> On Thu, Aug 29, 2019 at 12:52:56PM +0200, Thierry Goubier via Cuis-dev wrote:
>> > Hi Philip,
>> >
>> > as someone who has worked a bit on filetree, I'd say there are no
>> > philosophical differences. Just implementation compromises with the way
>> > Smalltalk has to deal with the world outside of the image for storing code.
>> >
>> > For example, Tonel has been introduced to solve issues with filetree: the
>> > fact filetree generates too many files creating performance issues with the
>> > host filesystem implementation (and issues with the poor support of Windows
>> > long paths in the virtual machines), and losing space because the files are
>> > small (and that current storage tech has solved its performance issues with
>> > large files by forcing a large minimum allocation size). Filetree is itself
>> > a compromise to have a different fit with current version management
>> > systems (git, for example). As I said, just implementation compromises(*),
>> > no philosophy behind that.
>> >
>> > If there is a philosophical difference, I would say that there is only one:
>> > declarative or imperative storage format. Traditiional Smalltalk is
>> > imperative... you don't load code, you execute a program. Newer formats
>> > like filetree or tonel, or probably the database-oriented ones (VW, Magma)
>> > are more declarative in nature (but have still imperative parts).
>> >
>> > The picture grows more complex if you consider what are version control
>> > systems. They are in fact databases (even git), so a more natural fit for
>> > Smalltalk would be an object persistency layer used with code objects (VW,
>> > again. Gemstone?).
>> >
>> > To give you an idea of how that looks, for all formats:
>> >
>> > In Smalltalk, you have code as an object graph (class, CompiledMethod
>> > instances, etc...) with an optimisation to store the text (the sources and
>> > changes files). When you save, you iterate over that object graph and
>> > convert it to a file / multiple files. Then you interact with your version
>> > control system to record the files (either automatically or manually). Then
>> > your version control system store your changes into a database, as a set of
>> > objects...
>> >
>> > This also explains why you have those Smalltalk to database for storing
>> > code implementations: avoid that file layer that is extremely annoying.
>> >
>> > Thierry
>> >
>> > (*) For example, the last version of GitFileTree, a git-enabled filetree,
>> > never manipulates any files in Smalltalk. Git does file operations but only
>> > as a kind of user interface layer, to allow users to solve conflicts.
>> >
>> > Le jeu. 29 ao??t 2019 ?? 10:26, Philip Bernhart via Cuis-dev <
>> > cuis-dev at lists.cuis.st> a ??crit :
>> >
>> > > Hi Hernan,
>> > >
>> > > could you find out the philosophical differences regarding
>> > > the "new" package formats like filetree or tonel?
>> > >
>> > > If yes, what are they? I'm curious why thinks are supposed to
>> > > be better the way pharo and visual works (?) went.
>> > >
>> > >
>> > > Thanks for your time,
>> > > Philip
>> > >
>> > > Hernan Wilkinson via Cuis-dev <cuis-dev at lists.cuis.st> writes:
>> > >
>> > > > well well well, even I do admire you and so on, I would not call it a
>> > > > date ????????
>> > > > (we are starting to have fun!!)
>> > > >
>> > > > On Wed, Jul 31, 2019 at 4:44 PM Dale Henrichs via Cuis-dev <
>> > > > cuis-dev at lists.cuis.st> wrote:
>> > > >
>> > > >> Hernan,
>> > > >>
>> > > >> Excellent! It's a date then:)
>> > > >>
>> > > >> Dale
>> > > >> On 7/31/19 12:32 PM, Hernan Wilkinson via Cuis-dev wrote:
>> > > --
>> > > Cuis-dev mailing list
>> > > Cuis-dev at lists.cuis.st
>> > > https://lists.cuis.st/mailman/listinfo/cuis-dev
>> > >
>>
>> > --
>> > Cuis-dev mailing list
>> > Cuis-dev at lists.cuis.st
>> > https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev


More information about the Cuis-dev mailing list