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

H. Hirzel hannes.hirzel at gmail.com
Tue Jan 8 20:35:16 CST 2013


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 <juan at jvuletich.org> 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 <Ken.Dickey at whidbey.com> 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
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>




More information about the Cuis mailing list