June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi Eliot, I will get back to this email after tomorrow. I need a bit of time to put an answer together. Cheers, Doru > On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > > On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I agree with most things you say (except the conclusion :)), and I think that we are talking about complementary issues. > > As I mentioned before, there already is a need to distinguish between a plain selector and one that is associated with pragmas. This is what you find in PragmaType in Spotter and Inspector. This is a kind of meta-object and having it adds value. I can search for pragmas âtypeâ (we can also call it a PragmaSelector), and I can distinguish between all occurrences of a pragma âtypeâ and its utilization in computation. But, the current implementation of PragmaType is a mere pseudo-meta-object, given that it has no casual connection to the runtime. > > What we know from Smalltalk is that the analysis model does not have to differ from the runtime one. The consequence is that every time we do see a difference, we should investigate because we might uncover a hidden need opportunity. > > I know the VW model, and indeed, we could have something like: > > MyConcept class>>myPragmaDefinition > âa comment about the pragma" > <pragma: #selector> > > However, this only deals with the definition of the pragma type not with the internal representation. There could still well be an object that encapsulates both the selector and the comment. And that object would also allow us to build tools around it. We could call it a PragmaType, PragmaDefinition, or even PragmaSelector. And we could get the Pragma to point to this type either through an inst var or through a query (I would probably prefer an instvar). > > Well, there already /is/ a meta-object called Pragma, and it gets instantiated when one accesses the compiled method via pragmas: > > (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas collect: [:ea| {ea. ea class}] {{<export: true> . Pragma} . {<var: #tablePtr type: 'int *'> . Pragma}} > > So we could add the information you want to Pragma, and have it be lazy. The Pragma could go search for the defining class-side pragma methods and use the parser to extract the comment(s) when asked. Hence simple access to pragmas, interested only in the selectors for applying, wouldn't have their performance be impacted. > > > I think that this proposition does not remove from the simplicity of the implementation at all, but allows the new needs to be accommodated nicely. The alternative is to not do anything, in which case we will continue to have an analysis-only-pseudo-meta-object which is not nice at all. I do not think we should jump on this lightly, but I do think we should have a critical look and evaluate the options. > > This pseudo-meta-object (Pragma) can sty ill be causally connected, in the same way that a MethodReference can be causally connected. The causation is things like "remove", "recompile", but that's dubious. It's essentially a read-only relationship; one wants to be able to locate the method from the pragma, but changing the method from the pragma isn't necessarily a good idea. Would you agree that convenience methods like "remove" on MethodReference are a bad idea and one should stick to the removeSelector: protocol on Behavior and ClassDescription? > > > What do you think? > > Have I and enough coffee to scramble my thoughts might be a more pertinent question ;-) > > > Cheers, > Doru > > > > On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Doru, > > > >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> The CompiledMethod already has a way to retrieve Pragma instances: > >> > >> CompiledMethod>>pragmas. > >> > >> However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. > > > > Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get > > - executable pragmas that can be applied using perform: or wrappers such as sentTo: > > - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. > > - a rich pragma language that can have many, named parameters > > - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement > > > > So its parsimony is an important part of its virtues. It is minimal. > > > > One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). > > > > This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg > > kernelPragmas > > <pragma: #primitive:> > > <pragma: #primitive:error:> > > <pragma: #primitive:module:> > > <pragma: #primitive:module:error:> > > > > We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. > > > > If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. > > > > None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). > > > > So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. > > > >> Cheers, > >> Doru > > > > Thanks for reading. > > Cheers, Eliot > > > >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >>> > >>> > >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >>> Hi, > >>> > >>> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? > >>> > >>> How it could be done? > >>> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Be rather willing to give than demanding to get." > >> > >> > >> > >> > >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

June 28, 2016

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Sarcasm never really works on mailing lists :) Doru > On Jun 28, 2016, at 6:02 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact >> > Are you being serious or sarcastic? > >> 28 Ð¸ÑÐ½Ñ 2016 Ð³. 11:45 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Jan Vrany" <jan.vrany(a)fit.cvut.cz> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> >> On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: >>> >>> >>> On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> 2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: >>> That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes. >>> >>> Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :) >>> >>> Yep. >> >> Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class >> with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class). >> >> When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted >> and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the >> environment. So I'd be very careful.. >> >> Jan >> >> P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else >> do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right... >> >> -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

June 28, 2016

Re: [Pharo-dev] Having comments for pragma?

by stepharo

> When I implemented annotation support I was initially thinking the > same - let's create an instance of CoolAnnotationClass when the code > is accepted > and then one can add arbitrary code to his CoolAnnotationClass. I > quickly realized this is a (very) bad idea. Or, to be precise, it is a > bad idea given the > environment. So I'd be very careful.. can you explain your statement? Stef > > Jan > > P.S.: As for "which always forced me to hate Java": I found myself a > very enlightening to think carefully about why somebody else > do things differently before I start to hate her/him. Besides, there's > whole lot of things that Java guys got right... > >

June 28, 2016

Percent-encoding problem

by Bernhard Pieber

I have a web service where I have to use a URL with percent-encoded (URL encoded) special characters â German Umlauts â but not using UTF8 but ISO-8859-1. I have been given the following table for the âcorrectâ encodings: http://www.degraeve.com/reference/urlencoding.php I found out that I can use the following to get the encoding I need (%FC): ZnPercentEncoder new characterEncoder: (ZnCharacterEncoder newForEncoding: 'iso-8859-1'); encode: 'Ã¼'. However, when I try to use the encoded URL with ZnClient ZnClient new url: 'http://example.com/%FC'; get. I get a ZnUTF8Encoder>>errorIllegalLeadingByte (Illegal leading byte for utf-8 encoding). Any help is greatly appreciated. Cheers, Bernhard

June 28, 2016

why slots template calls only instance variables slots?

by Peter UhnÃ¡k

I switched to slot-based variable template (because I like it more), however I do not understand why instanceVariables have been renamed to slots, but classVariables are still classVariables. Also wouldn't it be confusing for newcomers to see slots instead of instanceVariables? Why the need for the rename in the first place? Peter

June 28, 2016

Re: [Pharo-dev] Smalltalk Hub on Chrome

by Dale Henrichs

I just checked and it seems that GitLab has indeed changed the download filenames to the point where I think that a `gitlab://` url for Metacello could be supported ... Dale On 6/28/16 8:43 AM, Dale Henrichs wrote: > With regards to GitLab and Metacello. A couple of years ago, I looked > into adding GitLab support to Metacello, similar to `github:\\` for > downloading repository without requiring git to be installed and found > that there were issues[1] ... Now that was in 2014 and it's possible > that GitLab has fiddled with their zip download support, but I haven't > checked ... > > `github://` is convenient but if you are moving to full git support > and expect everyone to be cloning projects into local repos (by hook > or by crook) not being able to download a zip version of the project > is less of a problem ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/issues/287#issuecomment-59815… > > > On 6/27/16 7:05 PM, Ben Coman wrote: >> On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris >> <sean(a)clipperadams.com> wrote: >>> stepharo wrote >>>>> maybe we need to consider deprecate the amber client >>>>> and use a full-pharo version. >>>> Torsten what is the state of your solution? >>> Is it worth it to take another trip down this road of >>> rolling-our-own source >>> code repo? Whatever we create, we accept the responsibility to >>> maintain, and >>> with GitHub's social coding features, BitBucket for free private repo >>> hosting, and all the advances in Pharo-git integration, it seems our >>> limited >>> resources would be most effectively committed elsewhere... >> Jumping ahead to the end game of not needing to support development of >> the repository backend ourselves, >> there are a couple of levels to this... >> >> 1. Create a "SmalltalkHub" organisation on github and move *all* >> repositories (maintaining privacy. Synchronize between the two servers >> for a couple of years so as to not abandon old Pharo versions or break >> existing Configurations, or build a thin forwarding service such that >> requests received at smalltalkhub interact with github - perhaps this >> is read only. Build a thin web SmalltalkHub home page with github >> pages at smalltalkhub.io. >> >> 2. While GitHub gets most of the glory, its closed source and there >> are some open source git options to consider like GitLab (MIT license) >> or Gerrit (Apache license). This might be the path to choose if we >> need some Smalltalk customizations like Smalltalk syntax highlighting. >> The advantage of integrating with GitLab would be that the community >> could use their hosted solution, but private companies could run their >> own GitLab server if they have secrets they want to be more careful >> about sharing with third parties. >> >> 3. We might run a GitLab/Gerrit server in place of the existing >> Smalltalkhub server, and make it look the same for pre-git Pharo >> clients. There would still be some administration cost, but a larger >> community for support, features and bug fixing, or paid support >> options. >> * https://www.linux.com/learn/how-run-your-own-git-server >> * https://about.gitlab.com/applications/ >> * https://www.gerritcodereview.com/ >> * >> https://gerrit-review.googlesource.com/Documentation/config-plugins.html >> >> But these considerations shouldn't stop an intermediate solution. >> cheers -ben >> >

June 28, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60124 Home: https://github.com/pharo-project/pharo-core

June 28, 2016

[pharo-project/pharo-core] 3cf763: 60124

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3cf76321baddb6fdb56f1a52affedc17ab057ff4 https://github.com/pharo-project/pharo-core/commit/3cf76321baddb6fdb56f1a52… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-28 (Tue, 28 Jun 2016) Changed paths: R Kernel.package/CompiledMethod.class/instance/accessing/bytecode.st R Kernel.package/CompiledMethod.class/instance/accessing/clearFlag.st R Kernel.package/CompiledMethod.class/instance/accessing/clearSignFlag.st R Kernel.package/CompiledMethod.class/instance/accessing/comment.st R Kernel.package/CompiledMethod.class/instance/accessing/encoderClass.st R Kernel.package/CompiledMethod.class/instance/accessing/endPC.st R Kernel.package/CompiledMethod.class/instance/accessing/flag.st R Kernel.package/CompiledMethod.class/instance/accessing/frameSize.st R Kernel.package/CompiledMethod.class/instance/accessing/initialPC.st R Kernel.package/CompiledMethod.class/instance/accessing/numArgs.st R Kernel.package/CompiledMethod.class/instance/accessing/numLiterals.st R Kernel.package/CompiledMethod.class/instance/accessing/numTemps.st R Kernel.package/CompiledMethod.class/instance/accessing/referredInstVars.st R Kernel.package/CompiledMethod.class/instance/accessing/scanner.st R Kernel.package/CompiledMethod.class/instance/accessing/setSignFlag.st R Kernel.package/CompiledMethod.class/instance/accessing/signFlag.st R Kernel.package/CompiledMethod.class/instance/accessing/trailer.st R Kernel.package/CompiledMethod.class/instance/cleaning/voidCogVMState.st R Kernel.package/CompiledMethod.class/instance/comparing/=.st R Kernel.package/CompiledMethod.class/instance/comparing/equivalentTo_.st R Kernel.package/CompiledMethod.class/instance/comparing/hash.st R Kernel.package/CompiledMethod.class/instance/comparing/sameLiteralsAs_.st R Kernel.package/CompiledMethod.class/instance/converting/asOrderedCollection.st R Kernel.package/CompiledMethod.class/instance/debugger support/pcPreviousTo_.st R Kernel.package/CompiledMethod.class/instance/initialize-release/needsFrameSize_.st R Kernel.package/CompiledMethod.class/instance/initialize-release/setFrameBit_.st R Kernel.package/CompiledMethod.class/instance/literals/allLiterals.st R Kernel.package/CompiledMethod.class/instance/literals/hasLiteralSuchThat_.st R Kernel.package/CompiledMethod.class/instance/literals/hasLiteralThorough_.st R Kernel.package/CompiledMethod.class/instance/literals/hasLiteral_.st R Kernel.package/CompiledMethod.class/instance/literals/hasSelector_.st R Kernel.package/CompiledMethod.class/instance/literals/hasSelector_specialSelectorIndex_.st R Kernel.package/CompiledMethod.class/instance/literals/header.st R Kernel.package/CompiledMethod.class/instance/literals/headerDescription.st R Kernel.package/CompiledMethod.class/instance/literals/indexOfLiteral_.st R Kernel.package/CompiledMethod.class/instance/literals/literalAt_.st R Kernel.package/CompiledMethod.class/instance/literals/literalAt_put_.st R Kernel.package/CompiledMethod.class/instance/literals/literalStrings.st R Kernel.package/CompiledMethod.class/instance/literals/literals.st R Kernel.package/CompiledMethod.class/instance/literals/literalsDo_.st R Kernel.package/CompiledMethod.class/instance/literals/objectAt_.st R Kernel.package/CompiledMethod.class/instance/literals/objectAt_put_.st R Kernel.package/CompiledMethod.class/instance/literals/refersToLiteral_.st R Kernel.package/CompiledMethod.class/instance/literals/sendsSelector_.st R Kernel.package/CompiledMethod.class/instance/printing/asString.st R Kernel.package/CompiledMethod.class/instance/printing/longPrintOn_.st R Kernel.package/CompiledMethod.class/instance/printing/primitiveErrorVariableName.st R Kernel.package/CompiledMethod.class/instance/printing/symbolic.st R Kernel.package/CompiledMethod.class/instance/printing/symbolicBytecodes.st R Kernel.package/CompiledMethod.class/instance/printing/timeStamp.st R Kernel.package/CompiledMethod.class/instance/scanning/abstractBytecodeMessageAt_.st R Kernel.package/CompiledMethod.class/instance/scanning/abstractBytecodeMessagesDo_.st R Kernel.package/CompiledMethod.class/instance/scanning/abstractBytecodeMessagesFrom_to_do_.st R Kernel.package/CompiledMethod.class/instance/scanning/accessesSlot_.st R Kernel.package/CompiledMethod.class/instance/scanning/hasInstVarRef.st R Kernel.package/CompiledMethod.class/instance/scanning/messages.st R Kernel.package/CompiledMethod.class/instance/scanning/readsField_.st R Kernel.package/CompiledMethod.class/instance/scanning/readsRef_.st R Kernel.package/CompiledMethod.class/instance/scanning/readsSlot_.st R Kernel.package/CompiledMethod.class/instance/scanning/scanFor_.st R Kernel.package/CompiledMethod.class/instance/scanning/sendsToSuper.st R Kernel.package/CompiledMethod.class/instance/scanning/writesField_.st R Kernel.package/CompiledMethod.class/instance/scanning/writesRef_.st R Kernel.package/CompiledMethod.class/instance/scanning/writesSlot_.st R Kernel.package/CompiledMethod.class/instance/source code management/argumentNames.st R Kernel.package/CompiledMethod.class/instance/source code management/author.st R Kernel.package/CompiledMethod.class/instance/source code management/definition.st R Kernel.package/CompiledMethod.class/instance/source code management/stamp.st R Kernel.package/CompiledMethod.class/instance/testing/containsHalt.st R Kernel.package/CompiledMethod.class/instance/testing/isCollection.st R Kernel.package/CompiledMethod.class/instance/testing/isExternalCallPrimitive.st R Kernel.package/CompiledMethod.class/instance/testing/isNamedPrimitive.st R Kernel.package/CompiledMethod.class/instance/testing/isPrimitive.st R Kernel.package/CompiledMethod.class/instance/testing/isQuick.st R Kernel.package/CompiledMethod.class/instance/testing/isRealPrimitive.st R Kernel.package/CompiledMethod.class/instance/testing/usesPrimaryBytecodeSet.st R Kernel.package/CompiledMethod.class/instance/testing/usesSecondaryBytecodeSet.st M OpalCompiler-Core.package/IRMethod.class/instance/debugging/instructionForPC_.st R OpalCompiler-Core.package/extension/CompiledMethod/instance/compiler.st R OpalCompiler-Core.package/extension/CompiledMethod/instance/compilerClass.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60123.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60124.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60123.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60124.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60124 18619 Introduction of FullBlockClosure (4) moving code from CompiledMethod to CompiledCode https://pharo.fogbugz.com/f/cases/18619 18633 InstructionForPC: not working with new bytecode set https://pharo.fogbugz.com/f/cases/18633 http://files.pharo.org/image/60/60124.zip

June 28, 2016

Re: [Pharo-dev] Having comments for pragma?

by Eliot Miranda

> On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact > Are you being serious or sarcastic? > 28 Ð¸ÑÐ½Ñ 2016 Ð³. 11:45 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Jan Vrany" <jan.vrany(a)fit.cvut.cz> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: >> >> >>> On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini(a)gmail.com> wrote: >>> >>> >>>> On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>> >>>> 2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: >>>>> That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes. >>>> >>>> Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :) >>> >>> Yep. >> >> Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class >> with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class). >> >> When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted >> and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the >> environment. So I'd be very careful.. >> >> Jan >> >> P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else >> do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...

June 28, 2016

Re: [Pharo-dev] Smalltalk Hub on Chrome

by Dale Henrichs

With regards to GitLab and Metacello. A couple of years ago, I looked into adding GitLab support to Metacello, similar to `github:\\` for downloading repository without requiring git to be installed and found that there were issues[1] ... Now that was in 2014 and it's possible that GitLab has fiddled with their zip download support, but I haven't checked ... `github://` is convenient but if you are moving to full git support and expect everyone to be cloning projects into local repos (by hook or by crook) not being able to download a zip version of the project is less of a problem ... Dale [1] https://github.com/dalehenrich/metacello-work/issues/287#issuecomment-59815… On 6/27/16 7:05 PM, Ben Coman wrote: > On Tue, Jun 28, 2016 at 6:36 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> stepharo wrote >>>> maybe we need to consider deprecate the amber client >>>> and use a full-pharo version. >>> Torsten what is the state of your solution? >> Is it worth it to take another trip down this road of rolling-our-own source >> code repo? Whatever we create, we accept the responsibility to maintain, and >> with GitHub's social coding features, BitBucket for free private repo >> hosting, and all the advances in Pharo-git integration, it seems our limited >> resources would be most effectively committed elsewhere... > Jumping ahead to the end game of not needing to support development of > the repository backend ourselves, > there are a couple of levels to this... > > 1. Create a "SmalltalkHub" organisation on github and move *all* > repositories (maintaining privacy. Synchronize between the two servers > for a couple of years so as to not abandon old Pharo versions or break > existing Configurations, or build a thin forwarding service such that > requests received at smalltalkhub interact with github - perhaps this > is read only. Build a thin web SmalltalkHub home page with github > pages at smalltalkhub.io. > > 2. While GitHub gets most of the glory, its closed source and there > are some open source git options to consider like GitLab (MIT license) > or Gerrit (Apache license). This might be the path to choose if we > need some Smalltalk customizations like Smalltalk syntax highlighting. > The advantage of integrating with GitLab would be that the community > could use their hosted solution, but private companies could run their > own GitLab server if they have secrets they want to be more careful > about sharing with third parties. > > 3. We might run a GitLab/Gerrit server in place of the existing > Smalltalkhub server, and make it look the same for pre-git Pharo > clients. There would still be some administration cost, but a larger > community for support, features and bug fixing, or paid support > options. > * https://www.linux.com/learn/how-run-your-own-git-server > * https://about.gitlab.com/applications/ > * https://www.gerritcodereview.com/ > * https://gerrit-review.googlesource.com/Documentation/config-plugins.html > > But these considerations shouldn't stop an intermediate solution. > cheers -ben >

June 28, 2016