[Convention] External packages in sibling directories of Cuis?
Locked
[Convention] External packages in sibling directories of Cuis?
 
|
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 |
Re: [Convention] External packages in sibling directories of Cuis?
|
|
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 |
Re: [Convention] External packages in sibling directories of Cuis?
|
|
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 |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |