[4.1][Test] PetitParser
Locked
12
12
Re: Telling GitHub that our code is Smalltalk
 
|
Hi Angel,
Yes. From all that, it seems that the way to do it would be to use *.cs.st and *.pck.st file extensions for ChangeSets and Packages. *.st is the only file extension recognized as Smalltalk. It is a reasonable solution. I thought that a manual override should be possible... If we don't find another solution, maybe I'll switch to *.cs.st and *.pck.st as the defaults in the code, and rename files in the Cuis repository. Then, it would be good if folks start renaming .pck files in their own repository. I guess supporting the older (current!) extensions will not be a problem. Cheers, Juan Vuletich Angel Java Lopez wrote: > I just found: > > http://stackoverflow.com/questions/5318580/how-does-github-figure-out-a-projects-language > > then > > https://github.com/github/linguist > > but I don't sure if it is used to classify a project. Is it used > beyond syntax highlighting? > > > Language detection > > Linguist defines the list of all languages known to GitHub in a yaml > file > <https://github.com/github/linguist/blob/master/lib/linguist/languages.yml>. > In order for a file to be highlighted, a language and lexer must be > defined there. > > Most languages are detected by their file extension. This is the > fastest and most common situation. > > For disambiguating between files with common extensions, we use > a bayesian classifier > <https://github.com/github/linguist/blob/master/lib/linguist/classifier.rb>. > For an example, this helps us tell the difference between |.h| files > which could be either C, C++, or Obj-C. > > > and its issues: > https://github.com/github/linguist/issues > > > > On Sun, Dec 30, 2012 at 9:53 AM, Juan Vuletich <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi Hannes, > > In addition to .pck we also have .cs files. I'd like to be able to > tell GitHub that: > *.pck is Smalltalk > *.cs is Smalltalk > The whole project is a Smalltalk project (so it shows in > https://github.com/languages/Smalltalk ) > > I found how to tell git that some files are in a specific language > (see http://schacon.github.com/git/gitattributes.html ), but > smalltalk is not listed there. But if git already thinks that *.st > means smalltalk, I believe the same could be done for *.pck and *.cs. > > Please folks, help me! I can't find a way to do it, but it should > be possible! > > As a last resource, we could switch to *.pck.st <http://pck.st> > and *.cs.st <http://cs.st>, but that would make things a bit more > awkward for us, and especially for users of other Smalltalk > environments... > > Thanks, > Juan Vuletich > > H. Hirzel wrote: > > And the packages files (*.pck) should have a Smalltalk > extension *.st, > so e.g. *.pck.st <http://pck.st> so that the repos show up on > the github Smalltalk > page. > > https://github.com/languages/Smalltalk > > This makes it easier to see what is going on. > > For example Bernhard's Cuis fork appears there (no *.cs files) > whereas > Juan's does not (many *.cs files, counted as C-Sharp). > > > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[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 |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by Angel Java Lopez
On 12/30/12, Angel Java Lopez <[hidden email]> wrote:
> Hi people! > > Yes, you usually work on master (it could be called the "developer > branch"), and when you are ready, tag it. Ummm.. you tag your local repo, > and then push the tags to Github. AFAIK, you could move the tag to other > commit, for example, if there are a minor fix in documentation or something > alike. > > Having packages out of the central repo, is more agile. +1 > > Maybe a "solution at the middle": some "blessed" (easy to test, to load > from core in central repo, many used, important for community, etc...) > packages are at central repo, and the other packages are listed in a page I think a 'scripts' and a doc subdirectory in the main repo are fine at the moments. I.e. https://gist.github.com/4387924 should be moved to a directory there and maintained by the community through pull requests. People need to a) find the loadable packages b) know about their status c) have a means to load them automatically (not through a GUI) for example "To install Cypress, assuming the package files are in 'cuis-cypress-master' in a subdirectory of the working directory" #( 'cuis-cypress-master\Cypress-Definitions.pck' 'cuis-cypress-master\Cypress-Structure.pck' 'cuis-cypress-master\Cypress-Mocks.pck' 'cuis-cypress-master\Cypress-Tests.pck' ) do: [ :fileName | CodeFileBrowser installPackage: (FileStream concreteStream readOnlyFileNamed: fileName) ] However preferably directly through web access to github without having to download the pck files first. --Hannes > Angel "Java" Lopez > @ajlopez > > On Sun, Dec 30, 2012 at 9:01 AM, Juan Vuletich <[hidden email]> wrote: > >> Hi Angel, >> >> I really like the idea of having a single and consistent git commit of a >> Cuis version and all the packages that work on it. It would make much >> easier to go back to some date, and grab stuff that works well together. >> One downside is a bit more work for repo admin. A bigger one is that it >> makes things a slower for package maintainers. But the consistency might >> outweigh them. >> >> Below, I extracted Angel's comments on this. Folks, please comment. Add >> steps or ideas to complete or enhance Angel's suggestion. Or if you don't >> like it, please say why. This is a rather important decision, and I'd >> like >> we to make a good choice. >> >> One quick question for Angel (I'm a beginner with github): Can we tag a >> commit after it was done? That way, we could work together on Cuis and >> Packages for several days (involving many commits) and only when we are >> all >> happy, we can tag the last one as "v4.1 with packages" or something like >> that. >> >> Cheers, >> Juan Vuletich >> >> Angel Java Lopez wrote: >> >>> ... >>> >>> But having the central repo with the package (not a link), has an >>> advantage: central repo could have tags. So, the packages at tag >>> "v0.1.0" >>> are all compatible with that tag, and every improvement at tag "v0.2.0" >>> should be committed to that tag. The "master" tag is the development >>> tag. >>> >>> So, I could download the v0.2.0 with all the optional packages of that >>> version, without struggling going to each package author repo, and >>> trying >>> to guess what package/tag is compatible with Cuis v0.2.0 >>> >>> Cons: it put more responsability to central repo author(s). >>> >>> >>> >>> 2012/12/27 Angel Java Lopez <[hidden email] >>> <mailto:[hidden email]>**> >>> >>> Until you have a package manager, first idea: >>> >>> Use the cuis repo at GitHub. >>> >>> Every contributor make a fork. >>> He/she add the code to his/her fork. >>> Make a pull request to central repo >>> >>> Maybe, a guide to have folders per package/topic. >>> ... >>> >>> Angel "MyLifeIsGitHub" Lopez ;-) >>> github:ajlopez >>> >>> >> >> ______________________________**_________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >> > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
ok, but how will we do the switch?
I mean, we need to rename all the packages in our local repos? and then commit then to GitHub.... and then delete the old names in GitHub? We will wait you release fixes in Cuis to consider the new names?
2012/12/30 Juan Vuletich <[hidden email]> Hi Angel, _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Telling GitHub that our code is Smalltalk
|
|
The normal flow in other technologies:
1- Fork the central Cuis repo 2- Make the changes in your fork 3- Send a pull request to central Cuis repo But you can still keep your repo, and organize it at your wil. And when sure, do the above steps.
On Sun, Dec 30, 2012 at 10:41 AM, Germán Arduino <[hidden email]> wrote: ok, but how will we do the switch? _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by garduino
Ok, a typical graph
you can drag the graph, to scroll it The fork level is usually only one level deep: core, and your fork.
On Sun, Dec 30, 2012 at 10:06 AM, Germán Arduino <[hidden email]> wrote: I'm only a newbie with GitHub, really I don't know it deeper to have a valid opinion. But my main concern is (as in the list with the packages) forks and more forks seems not be very practical..... _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Telling GitHub that our code is Smalltalk
|
|
In reply to this post by garduino
Ok. Done. Uploaded a new prebuilt image and a couple of changesets. Now,
when you save a package or change set, extension will be '.pck.st' and '.cs.st'. But you can load files without the '.st' suffix as usual. Now Cuis shows up at https://github.com/languages/Smalltalk/updated . There's no urgency in updating your repos, but if you do, I believe they'll get correctly identified as Smalltalk stuff by GitHub. Cheers, Juan Vuletich Germán Arduino wrote: > ok, but how will we do the switch? > > I mean, we need to rename all the packages in our local repos? and > then commit then to GitHub.... and then delete the old names in GitHub? > > We will wait you release fixes in Cuis to consider the new names? > > > > 2012/12/30 Juan Vuletich <[hidden email] <mailto:[hidden email]>> > > Hi Angel, > > Yes. From all that, it seems that the way to do it would be to use > *.cs.st <http://cs.st> and *.pck.st <http://pck.st> file > extensions for ChangeSets and Packages. *.st is the only file > extension recognized as Smalltalk. It is a reasonable solution. I > thought that a manual override should be possible... > > If we don't find another solution, maybe I'll switch to *.cs.st > <http://cs.st> and *.pck.st <http://pck.st> as the defaults in the > code, and rename files in the Cuis repository. Then, it would be > good if folks start renaming .pck files in their own repository. I > guess supporting the older (current!) extensions will not be a > problem. > > Cheers, > Juan Vuletich > > Angel Java Lopez wrote: > > I just found: > > http://stackoverflow.com/questions/5318580/how-does-github-figure-out-a-projects-language > > then > > https://github.com/github/linguist > > but I don't sure if it is used to classify a project. Is it > used beyond syntax highlighting? > > > Language detection > > Linguist defines the list of all languages known to GitHub in > a yaml file > <https://github.com/github/linguist/blob/master/lib/linguist/languages.yml>. > In order for a file to be highlighted, a language and lexer > must be defined there. > > > Most languages are detected by their file extension. This is > the fastest and most common situation. > > For disambiguating between files with common extensions, we > use a bayesian classifier > <https://github.com/github/linguist/blob/master/lib/linguist/classifier.rb>. > For an example, this helps us tell the difference between |.h| > files which could be either C, C++, or Obj-C. > > > > and its issues: > https://github.com/github/linguist/issues > > > > On Sun, Dec 30, 2012 at 9:53 AM, Juan Vuletich > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> wrote: > > Hi Hannes, > > In addition to .pck we also have .cs files. I'd like to be > able to > tell GitHub that: > *.pck is Smalltalk > *.cs is Smalltalk > The whole project is a Smalltalk project (so it shows in > https://github.com/languages/Smalltalk ) > > I found how to tell git that some files are in a specific > language > (see http://schacon.github.com/git/gitattributes.html ), but > smalltalk is not listed there. But if git already thinks > that *.st > means smalltalk, I believe the same could be done for > *.pck and *.cs. > > Please folks, help me! I can't find a way to do it, but it > should > be possible! > > As a last resource, we could switch to *.pck.st > <http://pck.st> <http://pck.st> > and *.cs.st <http://cs.st> <http://cs.st>, but that would > make things a bit more > > awkward for us, and especially for users of other Smalltalk > environments... > > Thanks, > Juan Vuletich > > H. Hirzel wrote: > > And the packages files (*.pck) should have a Smalltalk > extension *.st, > so e.g. *.pck.st <http://pck.st> <http://pck.st> so > that the repos show up on > > the github Smalltalk > page. > > https://github.com/languages/Smalltalk > > This makes it easier to see what is going on. > > For example Bernhard's Cuis fork appears there (no > *.cs files) > whereas > Juan's does not (many *.cs files, counted as C-Sharp). > > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[hidden email]> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > > > > _______________________________________________ > Cuis mailing list > [hidden email] <mailto:[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 |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by Hannes Hirzel
Ok. Added the list to https://github.com/jvuletich/Cuis .
Please send pull requests, or email, to update it. Cheers, Juan Vuletich H. Hirzel wrote: > On 12/30/12, Angel Java Lopez <[hidden email]> wrote: > >> Hi people! >> >> Yes, you usually work on master (it could be called the "developer >> branch"), and when you are ready, tag it. Ummm.. you tag your local repo, >> and then push the tags to Github. AFAIK, you could move the tag to other >> commit, for example, if there are a minor fix in documentation or something >> alike. >> >> Having packages out of the central repo, is more agile. >> > > +1 > > > > > >> Maybe a "solution at the middle": some "blessed" (easy to test, to load >> from core in central repo, many used, important for community, etc...) >> packages are at central repo, and the other packages are listed in a page >> > > I think a 'scripts' and a doc subdirectory in the main repo are fine > at the moments. > I.e. > https://gist.github.com/4387924 > should be moved to a directory there and maintained by the community > through pull requests. > > People need to > > a) find the loadable packages > b) know about their status > c) have a means to load them automatically (not through a GUI) > > for example > > > > "To install Cypress, assuming the package files are in 'cuis-cypress-master' > in a subdirectory of the working directory" > > #( > 'cuis-cypress-master\Cypress-Definitions.pck' > 'cuis-cypress-master\Cypress-Structure.pck' > 'cuis-cypress-master\Cypress-Mocks.pck' > 'cuis-cypress-master\Cypress-Tests.pck' > ) > do: > [ :fileName | CodeFileBrowser installPackage: > (FileStream concreteStream readOnlyFileNamed: fileName) > ] > > > However preferably directly through web access to github without > having to download the pck files first. > > --Hannes > > >> Angel "Java" Lopez >> @ajlopez >> >> On Sun, Dec 30, 2012 at 9:01 AM, Juan Vuletich <[hidden email]> wrote: >> >> >>> Hi Angel, >>> >>> I really like the idea of having a single and consistent git commit of a >>> Cuis version and all the packages that work on it. It would make much >>> easier to go back to some date, and grab stuff that works well together. >>> One downside is a bit more work for repo admin. A bigger one is that it >>> makes things a slower for package maintainers. But the consistency might >>> outweigh them. >>> >>> Below, I extracted Angel's comments on this. Folks, please comment. Add >>> steps or ideas to complete or enhance Angel's suggestion. Or if you don't >>> like it, please say why. This is a rather important decision, and I'd >>> like >>> we to make a good choice. >>> >>> One quick question for Angel (I'm a beginner with github): Can we tag a >>> commit after it was done? That way, we could work together on Cuis and >>> Packages for several days (involving many commits) and only when we are >>> all >>> happy, we can tag the last one as "v4.1 with packages" or something like >>> that. >>> >>> Cheers, >>> Juan Vuletich >>> >>> Angel Java Lopez wrote: >>> >>> >>>> ... >>>> >>>> But having the central repo with the package (not a link), has an >>>> advantage: central repo could have tags. So, the packages at tag >>>> "v0.1.0" >>>> are all compatible with that tag, and every improvement at tag "v0.2.0" >>>> should be committed to that tag. The "master" tag is the development >>>> tag. >>>> >>>> So, I could download the v0.2.0 with all the optional packages of that >>>> version, without struggling going to each package author repo, and >>>> trying >>>> to guess what package/tag is compatible with Cuis v0.2.0 >>>> >>>> Cons: it put more responsability to central repo author(s). >>>> >>>> >>>> >>>> 2012/12/27 Angel Java Lopez <[hidden email] >>>> <mailto:[hidden email]>**> >>>> >>>> Until you have a package manager, first idea: >>>> >>>> Use the cuis repo at GitHub. >>>> >>>> Every contributor make a fork. >>>> He/she add the code to his/her fork. >>>> Make a pull request to central repo >>>> >>>> Maybe, a guide to have folders per package/topic. >>>> ... >>>> >>>> Angel "MyLifeIsGitHub" Lopez ;-) >>>> github:ajlopez >>>> >>>> >>>> >>> ______________________________**_________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<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 |
|
|
Nice.
2012/12/30 Juan Vuletich <[hidden email]> Ok. Added the list to https://github.com/jvuletich/Cuis . _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Yes, I convertes some of mines and now I can saw it as Smalltalk :)
2012/12/30 Juan Vuletich <[hidden email]> Ok. Done. Uploaded a new prebuilt image and a couple of changesets. Now, when you save a package or change set, extension will be '.pck.st' and '.cs.st'. But you can load files without the '.st' suffix as usual. Now Cuis shows up at https://github.com/languages/Smalltalk/updated . _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Telling GitHub that our code is Smalltalk
|
|
Nice, I see it on
https://github.com/languages/Smalltalk/updated --Hannes On 12/30/12, Germán Arduino <[hidden email]> wrote: > Yes, I convertes some of mines and now I can saw it as Smalltalk :) > > > 2012/12/30 Juan Vuletich <[hidden email]> > >> Ok. Done. Uploaded a new prebuilt image and a couple of changesets. Now, >> when you save a package or change set, extension will be '.pck.st' and '. >> cs.st'. But you can load files without the '.st' suffix as usual. Now >> Cuis shows up at >> https://github.com/languages/**Smalltalk/updated<https://github.com/languages/Smalltalk/updated>. >> >> There's no urgency in updating your repos, but if you do, I believe >> they'll get correctly identified as Smalltalk stuff by GitHub. >> >> Cheers, >> Juan Vuletich >> >> Germán Arduino wrote: >> >>> ok, but how will we do the switch? >>> >>> I mean, we need to rename all the packages in our local repos? and then >>> commit then to GitHub.... and then delete the old names in GitHub? >>> >>> We will wait you release fixes in Cuis to consider the new names? >>> >>> >>> >>> 2012/12/30 Juan Vuletich <[hidden email] >>> <mailto:[hidden email]>> >>> >>> >>> Hi Angel, >>> >>> Yes. From all that, it seems that the way to do it would be to use >>> *.cs.st <http://cs.st> and *.pck.st <http://pck.st> file >>> >>> extensions for ChangeSets and Packages. *.st is the only file >>> extension recognized as Smalltalk. It is a reasonable solution. I >>> thought that a manual override should be possible... >>> >>> If we don't find another solution, maybe I'll switch to *.cs.st >>> <http://cs.st> and *.pck.st <http://pck.st> as the defaults in the >>> >>> code, and rename files in the Cuis repository. Then, it would be >>> good if folks start renaming .pck files in their own repository. I >>> guess supporting the older (current!) extensions will not be a >>> problem. >>> >>> Cheers, >>> Juan Vuletich >>> >>> Angel Java Lopez wrote: >>> >>> I just found: >>> >>> http://stackoverflow.com/**questions/5318580/how-does-** >>> github-figure-out-a-projects-**language<http://stackoverflow.com/questions/5318580/how-does-github-figure-out-a-projects-language> >>> >>> then >>> >>> >>> https://github.com/github/**linguist<https://github.com/github/linguist> >>> >>> but I don't sure if it is used to classify a project. Is it >>> used beyond syntax highlighting? >>> >>> >>> Language detection >>> >>> Linguist defines the list of all languages known to GitHub in >>> a yaml file >>> <https://github.com/github/**linguist/blob/master/lib/** >>> linguist/languages.yml<https://github.com/github/linguist/blob/master/lib/linguist/languages.yml> >>> >. >>> In order for a file to be highlighted, a language and lexer >>> must be defined there. >>> >>> >>> Most languages are detected by their file extension. This is >>> the fastest and most common situation. >>> >>> For disambiguating between files with common extensions, we >>> use a bayesian classifier >>> <https://github.com/github/**linguist/blob/master/lib/** >>> linguist/classifier.rb<https://github.com/github/linguist/blob/master/lib/linguist/classifier.rb> >>> >. >>> For an example, this helps us tell the difference between |.h| >>> files which could be either C, C++, or Obj-C. >>> >>> >>> >>> and its issues: >>> >>> https://github.com/github/**linguist/issues<https://github.com/github/linguist/issues> >>> >>> >>> >>> On Sun, Dec 30, 2012 at 9:53 AM, Juan Vuletich >>> <[hidden email] <mailto:[hidden email]> >>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote: >>> >>> Hi Hannes, >>> >>> In addition to .pck we also have .cs files. I'd like to be >>> able to >>> tell GitHub that: >>> *.pck is Smalltalk >>> *.cs is Smalltalk >>> The whole project is a Smalltalk project (so it shows in >>> >>> https://github.com/languages/**Smalltalk<https://github.com/languages/Smalltalk>) >>> >>> I found how to tell git that some files are in a specific >>> language >>> (see >>> http://schacon.github.com/git/**gitattributes.html<http://schacon.github.com/git/gitattributes.html>), >>> but >>> smalltalk is not listed there. But if git already thinks >>> that *.st >>> means smalltalk, I believe the same could be done for >>> *.pck and *.cs. >>> >>> Please folks, help me! I can't find a way to do it, but it >>> should >>> be possible! >>> >>> As a last resource, we could switch to *.pck.st >>> <http://pck.st> <http://pck.st> >>> and *.cs.st <http://cs.st> <http://cs.st>, but that would >>> >>> make things a bit more >>> >>> awkward for us, and especially for users of other Smalltalk >>> environments... >>> >>> Thanks, >>> Juan Vuletich >>> >>> H. Hirzel wrote: >>> >>> And the packages files (*.pck) should have a Smalltalk >>> extension *.st, >>> so e.g. *.pck.st <http://pck.st> <http://pck.st> so >>> >>> that the repos show up on >>> >>> the github Smalltalk >>> page. >>> >>> >>> https://github.com/languages/**Smalltalk<https://github.com/languages/Smalltalk> >>> >>> This makes it easier to see what is going on. >>> >>> For example Bernhard's Cuis fork appears there (no >>> *.cs files) >>> whereas >>> Juan's does not (many *.cs files, counted as C-Sharp). >>> >>> >>> >>> ______________________________**_________________ >>> Cuis mailing list >>> [hidden email] <mailto:[hidden email]> >>> <mailto:[hidden email] <mailto:[hidden email]>> >>> >>> >>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> >>> >>> ______________________________**_________________ >>> Cuis mailing list >>> [hidden email] <mailto:[hidden email]> >>> >>> >>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >>> >>> >>> >>> ______________________________**_________________ >>> Cuis mailing list >>> [hidden email] <mailto:[hidden email]> >>> >>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >>> >>> >>> >>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> >>> ______________________________**_________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >>> >>> >> >> >> ______________________________**_________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org> >> > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Seems that 2013 will be a great year to Cuis, with Morphic 3 and (hopefully) a lot of usable packages!
Go Cuis Go! :)
2012/12/30 H. Hirzel <[hidden email]> Nice, I see it on ============================================ Germán S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogspot.com ============================================ _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Hi Juan,
I have thought a little bit about the topic. While I can understand the arguments, my gut feeling is, that we should not put all packages into the Cuis repository. Here are my reasons: - It is problematic for cross-dialect packages. - The repository gets more complex. You get a lot of branches. - It requires more coordination. - It is probably more work. - Not everyone will need all the packages. I think an extension workspace with load scripts similar to Squeak would be simpler and adequate. Just my 0.02 cents. Cheers Bernhard Am 30.12.2012 um 13:01 schrieb Juan Vuletich: > Hi Angel, > > I really like the idea of having a single and consistent git commit of a Cuis version and all the packages that work on it. It would make much easier to go back to some date, and grab stuff that works well together. One downside is a bit more work for repo admin. A bigger one is that it makes things a slower for package maintainers. But the consistency might outweigh them. > > Below, I extracted Angel's comments on this. Folks, please comment. Add steps or ideas to complete or enhance Angel's suggestion. Or if you don't like it, please say why. This is a rather important decision, and I'd like we to make a good choice. > > One quick question for Angel (I'm a beginner with github): Can we tag a commit after it was done? That way, we could work together on Cuis and Packages for several days (involving many commits) and only when we are all happy, we can tag the last one as "v4.1 with packages" or something like that. > > Cheers, > Juan Vuletich > > Angel Java Lopez wrote: >> ... >> >> But having the central repo with the package (not a link), has an advantage: central repo could have tags. So, the packages at tag "v0.1.0" are all compatible with that tag, and every improvement at tag "v0.2.0" should be committed to that tag. The "master" tag is the development tag. >> >> So, I could download the v0.2.0 with all the optional packages of that version, without struggling going to each package author repo, and trying to guess what package/tag is compatible with Cuis v0.2.0 >> >> Cons: it put more responsability to central repo author(s). >> >> >> >> 2012/12/27 Angel Java Lopez <[hidden email] >> <mailto:[hidden email]>> >> >> Until you have a package manager, first idea: >> >> Use the cuis repo at GitHub. >> >> Every contributor make a fork. >> He/she add the code to his/her fork. >> Make a pull request to central repo >> >> Maybe, a guide to have folders per package/topic. >> ... >> >> Angel "MyLifeIsGitHub" Lopez ;-) >> github:ajlopez >> > > > _______________________________________________ > 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: Once central repo for Cuis and Packages? Or just a central list?
|
|
Hello Bernhard
On 12/31/12, Bernhard Pieber <[hidden email]> wrote: > Hi Juan, > > I have thought a little bit about the topic. > > While I can understand the arguments, my gut feeling is, that we should not > put all packages into the Cuis repository. > > Here are my reasons: > - It is problematic for cross-dialect packages. > - The repository gets more complex. You get a lot of branches. no duplication of files which are not changed. > - It requires more coordination. The coordination is done through github. > - It is probably more work. > - Not everyone will need all the packages. Yes, and because of that we need a build scripts directory. > I think an extension workspace with load scripts similar to Squeak would be > simpler and adequate. For the time beeing surely a good intermediary step. But how do you create the load script without having a HttpClient (to fetch *.pck files from github and other places)? I would say we should not jump too quickly to conclusions but just try out different things, see for example https://github.com/jvuletich/Cuis/network and check out my branch 'packages' as an example how a setup with a packages collection might look like. https://github.com/hhzl/Cuis/tree/packages Learning github (see other thread), in particular http://gitimmersion.com/) is surely not time wasted. If not for this project than for others. Anyhow as said at the moment I am fine with a central list and load scripts. https://github.com/hhzl/Cuis/blob/packages/README.md (see example at the end, how can it be improved?) The challenge is not so much this data organisation question but rather getting packages to work with Cuis. In particular I need a web client for productive use of Cuis. And as German Arduino found out the porting effort is not to be underestimated. Kind regards Hannes > Cheers > Bernhard > > Am 30.12.2012 um 13:01 schrieb Juan Vuletich: > >> Hi Angel, >> >> I really like the idea of having a single and consistent git commit of a >> Cuis version and all the packages that work on it. It would make much >> easier to go back to some date, and grab stuff that works well together. >> One downside is a bit more work for repo admin. A bigger one is that it >> makes things a slower for package maintainers. But the consistency might >> outweigh them. >> >> Below, I extracted Angel's comments on this. Folks, please comment. Add >> steps or ideas to complete or enhance Angel's suggestion. Or if you don't >> like it, please say why. This is a rather important decision, and I'd like >> we to make a good choice. >> >> One quick question for Angel (I'm a beginner with github): Can we tag a >> commit after it was done? That way, we could work together on Cuis and >> Packages for several days (involving many commits) and only when we are >> all happy, we can tag the last one as "v4.1 with packages" or something >> like that. >> >> Cheers, >> Juan Vuletich >> >> Angel Java Lopez wrote: >>> ... >>> >>> But having the central repo with the package (not a link), has an >>> advantage: central repo could have tags. So, the packages at tag "v0.1.0" >>> are all compatible with that tag, and every improvement at tag "v0.2.0" >>> should be committed to that tag. The "master" tag is the development >>> tag. >>> >>> So, I could download the v0.2.0 with all the optional packages of that >>> version, without struggling going to each package author repo, and trying >>> to guess what package/tag is compatible with Cuis v0.2.0 >>> >>> Cons: it put more responsability to central repo author(s). >>> >>> >>> >>> 2012/12/27 Angel Java Lopez <[hidden email] >>> <mailto:[hidden email]>> >>> >>> Until you have a package manager, first idea: >>> >>> Use the cuis repo at GitHub. >>> >>> Every contributor make a fork. >>> He/she add the code to his/her fork. >>> Make a pull request to central repo >>> >>> Maybe, a guide to have folders per package/topic. >>> ... >>> >>> Angel "MyLifeIsGitHub" Lopez ;-) >>> github:ajlopez >>> >> >> >> _______________________________________________ >> 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 |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by bpi
Hi Bernhard,
It looks like all of us see both upsides and downsides on storing packages in the Cuis repository. There's no rush to make a decision. So, for the time being, I guess each package should reside at the maintainer's repository. In any case, I want to remark that the idea was not to make storing packages in the Cuis repository "mandatory". It makes no sense for cross-dialect packages. And it is useless to try to force a package maintainer. Each package maintainer has the last word wrt his packages. Cheers, Juan Vuletich Bernhard Pieber wrote: > Hi Juan, > > I have thought a little bit about the topic. > > While I can understand the arguments, my gut feeling is, that we should not put all packages into the Cuis repository. > > Here are my reasons: > - It is problematic for cross-dialect packages. > - The repository gets more complex. You get a lot of branches. > - It requires more coordination. > - It is probably more work. > - Not everyone will need all the packages. > > I think an extension workspace with load scripts similar to Squeak would be simpler and adequate. > > Just my 0.02 cents. > > Cheers > Bernhard > > Am 30.12.2012 um 13:01 schrieb Juan Vuletich: > > >> Hi Angel, >> >> I really like the idea of having a single and consistent git commit of a Cuis version and all the packages that work on it. It would make much easier to go back to some date, and grab stuff that works well together. One downside is a bit more work for repo admin. A bigger one is that it makes things a slower for package maintainers. But the consistency might outweigh them. >> >> Below, I extracted Angel's comments on this. Folks, please comment. Add steps or ideas to complete or enhance Angel's suggestion. Or if you don't like it, please say why. This is a rather important decision, and I'd like we to make a good choice. >> >> One quick question for Angel (I'm a beginner with github): Can we tag a commit after it was done? That way, we could work together on Cuis and Packages for several days (involving many commits) and only when we are all happy, we can tag the last one as "v4.1 with packages" or something like that. >> >> Cheers, >> Juan Vuletich >> >> Angel Java Lopez wrote: >> >>> ... >>> >>> But having the central repo with the package (not a link), has an advantage: central repo could have tags. So, the packages at tag "v0.1.0" are all compatible with that tag, and every improvement at tag "v0.2.0" should be committed to that tag. The "master" tag is the development tag. >>> >>> So, I could download the v0.2.0 with all the optional packages of that version, without struggling going to each package author repo, and trying to guess what package/tag is compatible with Cuis v0.2.0 >>> >>> Cons: it put more responsability to central repo author(s). >>> >>> >>> >>> 2012/12/27 Angel Java Lopez <[hidden email] >>> <mailto:[hidden email]>> >>> >>> Until you have a package manager, first idea: >>> >>> Use the cuis repo at GitHub. >>> >>> Every contributor make a fork. >>> He/she add the code to his/her fork. >>> Make a pull request to central repo >>> >>> Maybe, a guide to have folders per package/topic. >>> ... >>> >>> Angel "MyLifeIsGitHub" Lopez ;-) >>> github:ajlopez >>> >>> _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
2012/12/31 Juan Vuletich <[hidden email]>
Hi Bernhard, I agree. We have still only a few packages and I think that is better that each maintainer take care of them for now. Cheers. Germán. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by Juan Vuletich-4
Hello all,
So the one drawback to keeping everything in one repo is, every working copy is a copy of the *whole* repository, with *all* of the history. Right now, no problem, later we might have to reconsider if cloning becomes a big chore as a result, but not for a longish time. I think it's worth trying out.
On Sun, Dec 30, 2012 at 4:01 AM, Juan Vuletich <[hidden email]> wrote: Hi Angel, Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
At GitHub, the file space is optimized.
For local disk clone, you can use git clone ..... --depth 1 (please, check the doc, I wrote the above command by hand)
In case of the end of the world (or space on disks ;-) there is a git rebase command to use
On Mon, Dec 31, 2012 at 6:38 PM, Casey Ransberger <[hidden email]> wrote: Hello all, _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
Thank you Angel for your contributions about git/github. It is really
amazing what you can do with it. For the time being I will maintain a downstream version of Cuis with packages which run fine on Cuis (all tests green). https://github.com/hhzl/Cuis I'll keep the packages in a branch 'packages3' whereas the main branch 'master' is the same as Juan's. So I can pull in his changes from time to time. So far the selection of packages is based on my needs. What I need in addition is some king of HttpAccess. Maybe I should try the ZnEasyHttp class first... And a port of the Colin's FSFilesystem. --Hannes On 12/31/12, Angel Java Lopez <[hidden email]> wrote: > At GitHub, the file space is optimized. > > For local disk clone, you can use > > git clone ..... --depth 1 > > (please, check the doc, I wrote the above command by hand) > > In case of the end of the world (or space on disks ;-) there is a git > rebase command to use > > On Mon, Dec 31, 2012 at 6:38 PM, Casey Ransberger > <[hidden email]>wrote: > >> Hello all, >> >> So the one drawback to keeping everything in one repo is, every working >> copy is a copy of the *whole* repository, with *all* of the history. >> Right >> now, no problem, later we might have to reconsider if cloning becomes a >> big >> chore as a result, but not for a longish time. I think it's worth trying >> out. >> >> > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
In reply to this post by bpi
On 12/31/12, Bernhard Pieber <[hidden email]> wrote:
> Hi Juan, > > I have thought a little bit about the topic. > > While I can understand the arguments, my gut feeling is, that we should not > put all packages into the Cuis repository. > > Here are my reasons: > - It is problematic for cross-dialect packages. > - The repository gets more complex. You get a lot of branches. > - It requires more coordination. > - It is probably more work. > - Not everyone will need all the packages. > > I think an extension workspace with load scripts similar to Squeak would be > simpler and adequate. > Let's do an extension workspace then. From a user experience point of view this is not too different from having a central repository.... What do we need to make this happen? --Hannes _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Once central repo for Cuis and Packages? Or just a central list?
|
|
H. Hirzel wrote:
> On 12/31/12, Bernhard Pieber <[hidden email]> wrote: > >> Hi Juan, >> >> I have thought a little bit about the topic. >> >> While I can understand the arguments, my gut feeling is, that we should not >> put all packages into the Cuis repository. >> >> Here are my reasons: >> - It is problematic for cross-dialect packages. >> - The repository gets more complex. You get a lot of branches. >> - It requires more coordination. >> - It is probably more work. >> - Not everyone will need all the packages. >> >> I think an extension workspace with load scripts similar to Squeak would be >> simpler and adequate. >> >> > > Let's do an extension workspace then. From a user experience point of > view this is not too different from having a central repository.... > > What do we need to make this happen? > > --Hannes > Just send the contents, and I'll add the workspace to the image. Cheers, Juan Vuletich _______________________________________________ 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 |