Package structure et al

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Package structure et al

KenDickey
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
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

Hannes Hirzel
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.

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

On 1/9/13, KenD <[hidden email]> wrote:

> 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
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

garduino


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.

The load order is in the installation script documented in README.md from:

https://github.com/garduino/Cuis-WebClient


--
Sincerely,
Germán Arduino
about.me/garduino

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

KenDickey
In reply to this post by KenDickey

> 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
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

Hannes Hirzel
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
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

Hannes Hirzel
In reply to this post by garduino
Hello Germán

On 1/9/13, Germán Arduino <[hidden email]> wrote:

> 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.

You mean a repository
   Cuis-NetworkSupport

or somethjing like that
?

I would welcome that.

>
> The load order is in the installation script documented in README.md from:
>
> https://github.com/garduino/Cuis-WebClient

Thank you, this helps me.


Kind regards
Hannes

>
>
> --
> Sincerely,
> Germán Arduino
> about.me/garduino
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

Juan Vuletich-4
In reply to this post by KenDickey
Hi Ken,

KenD wrote:

> 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].
>  

This would be good, indeed. It is just that as everybody's time is
limited, it is important to prioritize.

> 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.
>  

Thank you Ken. This is very thoughtful.

Cheers,
Juan Vuletich

> 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
>
>
>  


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Package structure et al

Juan Vuletich-4
In reply to this post by Hannes Hirzel
Hi Folks,

Just experiment, and document your finding. If you come up with a
"recommended practice", that would be great. It doesn't need to be
perfect. But if we do it the same way, and keep improving the docs, it
will be consistent and efficient.

Thanks,
Juan Vuletich

H. Hirzel wrote:

> 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
>
>
>  


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org