[Convention] External packages in sibling directories of Cuis?

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

[Convention] External packages in sibling directories of Cuis?

Hannes Hirzel
Hello

What follows is a simple question asked by Ken D. with a long comment:

Should repos of external packages be in sibling directories of the
Cuis directory?
Ken suggests this and I agree.

Ken did an external package (BTW, Ken the extension for packages
should be now  *.pck.st to make sure github tags them as Smalltalk
files, Juan recently changed this after some discussion here
http://jvuletich.org/pipermail/cuis_jvuletich.org/2012-December/000301.html).

Ken has a fork of Cuis and a package 'Cuis-la-En'.

His directory structure is something like this

MyDocuments
    Cuis    // contains his fork which is https://github.com/KenDickey/Cuis
    Cuis   //  contains his dictionary application 'Cuis-la-En with
the package Interlingua


He loads his package into Cuis with


 CodeFileBrowser installPackage:
               (FileStream concreteStream
                      readOnlyFileNamed: '../Cuis-Ia-En/Interlingua.pck').

The path (a relative path) is hard coded.

The question is: Can we rely on people using this kind of setup? We
have not come up with a convention on this yet.

I would say YES, I think it is a good directory layout. We had a
related discussion about having a central repo vs. just a list . We
were in favor of not having a central repo. Just maintain a list of
packages and their status.
https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md

So this is the continuation of the discussion.

How are people supposed to arrange the repos they get from various places?

Kind regards
--Hannes


On 1/8/13, Ken Dickey <[hidden email]> wrote:

> Greetings,
>
> I did a simple Interlingua <--> English lookup window.
>
> IEDictWindow>>buildMorphicWindow is an example of LayoutMorph / LayoutSpec
> usage in a SystemWindow.
>
> You can get the code from GitHub:
>
> https://github.com/KenDickey/Cuis-Ia-En
>
>
> I usually first load the package into an image and then open the window:
>
> "----Workspace----"
> { '../Cuis-Ia-En/Interlingua.pck' .
> } do:  [ :fileName | CodeFileBrowser installPackage:
>                (FileStream concreteStream readOnlyFileNamed: fileName)].
>
> IEDictWindow open. "DoIt after the package code is loaded"
>
> "-----------------"
>
> IEDict>>WhyMe gives some sample Interlingua and references to more
> information on Interlingua on the web.
>
>
> The above brings up a couple of issues.
>
> The class initialization code loads a dictionary file ("iedict.txt") from a
> sibling directory to the CUIS directory.
>
> In other words I have a Cuis directory git-cloned from CUIS and a sibling
> Cuis-Ia-En directory git-cloned from the above.
>
> Currently, the class initialization code in IEDict loads
> FileStream oldFileNamed: '../Cuis-Ia-En/iedict.txt'.
>
> Note also the relative path in the package loading workspace code above.
>
> I could make the relative directory path an IEDict class variable to make it
> easier to change, but I am wondering if there is a convention that we could
> adopt (e.g. that we can assume sibling-level directory access).

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

Re: [Convention] External packages in sibling directories of Cuis?

Juan Vuletich-4
I like Ken's idea.

Cheers,
Juan Vuletich

H. Hirzel wrote:

> Hello
>
> What follows is a simple question asked by Ken D. with a long comment:
>
> Should repos of external packages be in sibling directories of the
> Cuis directory?
> Ken suggests this and I agree.
>
> Ken did an external package (BTW, Ken the extension for packages
> should be now  *.pck.st to make sure github tags them as Smalltalk
> files, Juan recently changed this after some discussion here
> http://jvuletich.org/pipermail/cuis_jvuletich.org/2012-December/000301.html).
>
> Ken has a fork of Cuis and a package 'Cuis-la-En'.
>
> His directory structure is something like this
>
> MyDocuments
>     Cuis    // contains his fork which is https://github.com/KenDickey/Cuis
>     Cuis   //  contains his dictionary application 'Cuis-la-En with
> the package Interlingua
>
>
> He loads his package into Cuis with
>
>
>  CodeFileBrowser installPackage:
>                (FileStream concreteStream
>                       readOnlyFileNamed: '../Cuis-Ia-En/Interlingua.pck').
>
> The path (a relative path) is hard coded.
>
> The question is: Can we rely on people using this kind of setup? We
> have not come up with a convention on this yet.
>
> I would say YES, I think it is a good directory layout. We had a
> related discussion about having a central repo vs. just a list . We
> were in favor of not having a central repo. Just maintain a list of
> packages and their status.
> https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md
>
> So this is the continuation of the discussion.
>
> How are people supposed to arrange the repos they get from various places?
>
> Kind regards
> --Hannes
>
>
> On 1/8/13, Ken Dickey <[hidden email]> wrote:
>  
>> Greetings,
>>
>> I did a simple Interlingua <--> English lookup window.
>>
>> IEDictWindow>>buildMorphicWindow is an example of LayoutMorph / LayoutSpec
>> usage in a SystemWindow.
>>
>> You can get the code from GitHub:
>>
>> https://github.com/KenDickey/Cuis-Ia-En
>>
>>
>> I usually first load the package into an image and then open the window:
>>
>> "----Workspace----"
>> { '../Cuis-Ia-En/Interlingua.pck' .
>> } do:  [ :fileName | CodeFileBrowser installPackage:
>>                (FileStream concreteStream readOnlyFileNamed: fileName)].
>>
>> IEDictWindow open. "DoIt after the package code is loaded"
>>
>> "-----------------"
>>
>> IEDict>>WhyMe gives some sample Interlingua and references to more
>> information on Interlingua on the web.
>>
>>
>> The above brings up a couple of issues.
>>
>> The class initialization code loads a dictionary file ("iedict.txt") from a
>> sibling directory to the CUIS directory.
>>
>> In other words I have a Cuis directory git-cloned from CUIS and a sibling
>> Cuis-Ia-En directory git-cloned from the above.
>>
>> Currently, the class initialization code in IEDict loads
>> FileStream oldFileNamed: '../Cuis-Ia-En/iedict.txt'.
>>
>> Note also the relative path in the package loading workspace code above.
>>
>> I could make the relative directory path an IEDict class variable to make it
>> easier to change, but I am wondering if there is a convention that we could
>> adopt (e.g. that we can assume sibling-level directory access).
>>    
>
> _______________________________________________
> 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: [Convention] External packages in sibling directories of Cuis?

Hannes Hirzel
Yes, as I wrote earlier today I like the idea of Ken as it helps me to
have a directory structure for Cuis and external packages which is
nicely structured.

However later today it came to my mind that we might make use of the
.gitignore file, a thing I have not used before.

That would allow us to have a subdirectory

packages

in the main Cuis folder.

For the Cuis repo we then would have to use a
  .gitignore
file.

Examples what other projects do with .gitignore files are here:

https://github.com/github/gitignore
for example
https://github.com/github/gitignore/blob/master/Grails.gitignore


The content of .gitignore file in the Cuis folder would then be

# ignore files in the packages subdirectory as they have their own repos
packages/*

# Ignore VM files
Croquet*.*

I have not tested this .gitignore file yet.

The advantage is that everything Cuis is under one base directory.

However with the siblings idea everything might be under one base
directory as well. The question is just: how should that directory be
named. As well 'Cuis'? Then we have
/mydocuments/Cuis/Cuis for the image
/mydocuments/Cuis/Cuis-Ia-en for a package


Kind regards

Hannes

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

> I like Ken's idea.
>
> Cheers,
> Juan Vuletich
>
> H. Hirzel wrote:
>> Hello
>>
>> What follows is a simple question asked by Ken D. with a long comment:
>>
>> Should repos of external packages be in sibling directories of the
>> Cuis directory?
>> Ken suggests this and I agree.
>>
>> Ken did an external package (BTW, Ken the extension for packages
>> should be now  *.pck.st to make sure github tags them as Smalltalk
>> files, Juan recently changed this after some discussion here
>> http://jvuletich.org/pipermail/cuis_jvuletich.org/2012-December/000301.html).
>>
>> Ken has a fork of Cuis and a package 'Cuis-la-En'.
>>
>> His directory structure is something like this
>>
>> MyDocuments
>>     Cuis    // contains his fork which is
>> https://github.com/KenDickey/Cuis
>>     Cuis   //  contains his dictionary application 'Cuis-la-En with
>> the package Interlingua
>>
>>
>> He loads his package into Cuis with
>>
>>
>>  CodeFileBrowser installPackage:
>>                (FileStream concreteStream
>>                       readOnlyFileNamed:
>> '../Cuis-Ia-En/Interlingua.pck').
>>
>> The path (a relative path) is hard coded.
>>
>> The question is: Can we rely on people using this kind of setup? We
>> have not come up with a convention on this yet.
>>
>> I would say YES, I think it is a good directory layout. We had a
>> related discussion about having a central repo vs. just a list . We
>> were in favor of not having a central repo. Just maintain a list of
>> packages and their status.
>> https://github.com/jvuletich/Cuis/blob/master/ListOfCuisPackages.md
>>
>> So this is the continuation of the discussion.
>>
>> How are people supposed to arrange the repos they get from various
>> places?
>>
>> Kind regards
>> --Hannes
>>
>>
>> On 1/8/13, Ken Dickey <[hidden email]> wrote:
>>
>>> Greetings,
>>>
>>> I did a simple Interlingua <--> English lookup window.
>>>
>>> IEDictWindow>>buildMorphicWindow is an example of LayoutMorph /
>>> LayoutSpec
>>> usage in a SystemWindow.
>>>
>>> You can get the code from GitHub:
>>>
>>> https://github.com/KenDickey/Cuis-Ia-En
>>>
>>>
>>> I usually first load the package into an image and then open the window:
>>>
>>> "----Workspace----"
>>> { '../Cuis-Ia-En/Interlingua.pck' .
>>> } do:  [ :fileName | CodeFileBrowser installPackage:
>>>                (FileStream concreteStream readOnlyFileNamed: fileName)].
>>>
>>> IEDictWindow open. "DoIt after the package code is loaded"
>>>
>>> "-----------------"
>>>
>>> IEDict>>WhyMe gives some sample Interlingua and references to more
>>> information on Interlingua on the web.
>>>
>>>
>>> The above brings up a couple of issues.
>>>
>>> The class initialization code loads a dictionary file ("iedict.txt") from
>>> a
>>> sibling directory to the CUIS directory.
>>>
>>> In other words I have a Cuis directory git-cloned from CUIS and a
>>> sibling
>>> Cuis-Ia-En directory git-cloned from the above.
>>>
>>> Currently, the class initialization code in IEDict loads
>>> FileStream oldFileNamed: '../Cuis-Ia-En/iedict.txt'.
>>>
>>> Note also the relative path in the package loading workspace code above.
>>>
>>> I could make the relative directory path an IEDict class variable to make
>>> it
>>> easier to change, but I am wondering if there is a convention that we
>>> could
>>> adopt (e.g. that we can assume sibling-level directory access).
>>>
>>
>> _______________________________________________
>> 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
>

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