Package structure et al

> FYI: I keep siblings in a directory named by the (major) release:
>  ../CUIS-1.4/Cuis
>  ../CUIS-1.4/Cuis-Ia-En
>
> I would prefer this to .gitIgnore as I suspect there will be fewer name
> collisions.
>
> We already have the potential for confusion with package names.
>
> Perhaps someone wants to add code for Interlingua to
> Spanish/French/Italian/.. in the Interlingua package.
>
> If the code is unshared, siblings can be loaded in any order.  If common
> code is used, there will be a composition order.
>
> In the ideal world, one should be able to look at package info [assume a
> package header/manifest & requirements] and do a transitive closure over all
> package requirements to get a proper load order or find a missing
> requirement or code clash [e.g. same class name defined with different
> code].
>
>
> The question I like to ask is "What is the simplest thing that will work?".
> (eXtreme Programming question)
>
>
> In the short term, I favor sibling directories as I think that this will
> confuse me the least.
>
> I would like to move to a package header which gives the
> compatibility.version = major.minor and lists package dependencies: zero or
> more of { packageName compatibility }.. ).
>
> I don't think an implementation is needed until the first package with a
> dependency requirement, but given networking, web servers, and so forth this
> day may not be far off.
>
> As far as I am concerned, Juan is king of the CUIS universe (think Linus
> Torvalds and Linux).  We should not overburden him with demands.
>
> One way to go forward is to have people who propose things do a
> prototype/sample implementation.  This helps avoid too many people proposing
> too many things, gives concrete examples to aid communication, and gives
> people something to try out and improve or discard.  Juan can then either
> ignore, replace, improve, or adapt a suggestion without having to write
> every line of code himself.
>
> Right now we are doing "baby steps" so this is not (yet) a big thing.  But
> success must be carefully managed so CUIS can grow without being smothered.
>
>
> Wow.  This is getting long.  I better stop typing.
>
> So, what is the simplest thing which works?
>
> -KenD
> --------------------
> When I works, I works hard.
> When I rests, I rests easy.
> When I thinks, I goes to sleep.
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

>
>> May I ask you to rework (not much) what you have written in the
> previous mail, describe how we think development should be done in
> terms of directory structure, put it into an *.md file, add it to your
> Cuis fork and issue a pull request to Juan?  This will keep the
> results of this thread readily accessible to other people who will
> join the Cuis effort  :-)
>
> Hannes,
>
> I will be happy to do that, but let's allow some other folks time for
> discussion and critique.
>
> -KenD
>
>

> 2013/1/9 H. Hirzel <[hidden email]>
>
>> Thank you Ken, for the additional explanations.
>>
>> Yes, labeling the basic directory with the version number (e.g.
>> Cuis-1.4) and having Cuis (with the image) and all the packages as
>> subdirectories makes sense according to
>>     "What is the simplest thing that will work?". (eXtreme Programming
>> question)
>>
>> Regarding package dependencies. We have
>>
>> * WebClient depends on Network
>> * some packages depend on the Pharo 1.4 compatibility package done by
>> German A.
>>
>
> Not at the moment, I'm moving all the compatibility stuff to a more general
> package:
>
> https://github.com/garduino/Cuis-CompatibilityWithOtherSmalltalks
>
> and the network delta surely will be moved to a repo with a better name
> when I have more work done.

> FYI: I keep siblings in a directory named by the (major) release:
>  ../CUIS-1.4/Cuis
>  ../CUIS-1.4/Cuis-Ia-En
>
> I would prefer this to .gitIgnore as I suspect there will be fewer name collisions.
>
> We already have the potential for confusion with package names.  
>
> Perhaps someone wants to add code for Interlingua to Spanish/French/Italian/.. in the Interlingua package.
>
> If the code is unshared, siblings can be loaded in any order.  If common code is used, there will be a composition order.
>
> In the ideal world, one should be able to look at package info [assume a package header/manifest & requirements] and do a transitive closure over all package requirements to get a proper load order or find a missing requirement or code clash [e.g. same class name defined with different code].
>  

> The question I like to ask is "What is the simplest thing that will work?". (eXtreme Programming question)
>
>
> In the short term, I favor sibling directories as I think that this will confuse me the least.
>
> I would like to move to a package header which gives the compatibility.version = major.minor and lists package dependencies: zero or more of { packageName compatibility }.. ).
>
> I don't think an implementation is needed until the first package with a dependency requirement, but given networking, web servers, and so forth this day may not be far off.
>
> As far as I am concerned, Juan is king of the CUIS universe (think Linus Torvalds and Linux).  We should not overburden him with demands.
>
> One way to go forward is to have people who propose things do a prototype/sample implementation.  This helps avoid too many people proposing too many things, gives concrete examples to aid communication, and gives people something to try out and improve or discard.  Juan can then either ignore, replace, improve, or adapt a suggestion without having to write every line of code himself.
>
> Right now we are doing "baby steps" so this is not (yet) a big thing.  But success must be carefully managed so CUIS can grow without being smothered.
>  

> Wow.  This is getting long.  I better stop typing.
>
> So, what is the simplest thing which works?
>
> -KenD
> --------------------
> When I works, I works hard.
> When I rests, I rests easy.
> When I thinks, I goes to sleep.
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>  

> Yes, Ken
>
> I have now deleted my former repository https://github.com/hhzl/Cuis
> and forked it again from https://github.com/jvuletich/Cuis.
>
> I had copies of other packages in a subdirectory in the deleted
> repository. Before I copied oujt the things I had done there. I
> consider it now as an exercise of learning how to use branches with
> github.
>
> Now I am applying the new system you propose, i.e. write load scripts
> which follow it.
>
> Thank you for your idea of labeling the base directory with the version number.
>
> Thus I have
>
> Cuis4.1
>     Cuis
>     Cuis-PetitParser
>     Cuis-Ia-En
>
> I got this by doing
>
> mkdir Cuis4.1
> cd Cuis4.1
> git clone git clone https://github.com/hhzl/Cuis.git
> git clone  git clone https://github.com/hhzl/Cuis-PetitParser.git
> git clone  git clone https://github.com/hhzl/Cuis-Ia-En.git
>
> Regards
>
> --Hannes
>
> On 1/9/13, Ken Dickey <[hidden email]> wrote:
>  
>>> May I ask you to rework (not much) what you have written in the
>>>      
>> previous mail, describe how we think development should be done in
>> terms of directory structure, put it into an *.md file, add it to your
>> Cuis fork and issue a pull request to Juan?  This will keep the
>> results of this thread readily accessible to other people who will
>> join the Cuis effort  :-)
>>
>> Hannes,
>>
>> I will be happy to do that, but let's allow some other folks time for
>> discussion and critique.
>>
>> -KenD
>>
>>
>>    
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>