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

Re: [Pharo-dev] Percent-encoding problem

by Sven Van Caekenberghe

Bernhard, > On 30 Jun 2016, at 21:12, Bernhard Pieber <bernhard(a)pieber.com> wrote: > > Hi Sven, > > Thanks for the answer. I needed to overwrite encodeQuery:on: and printQueryOn: for my use case. See attachment. I think being able to optionally configure the characterEncoder would be useful for ZnUrl in general. ZnUrl would then need to pass the characterEncoder to all calls to ZnResourceMetaUtils, not only to some like now. That would also be more consistent. Having ZnResourceMetaUtils use ZnUTF8Encoder by default seems a bit dangerous also. What do you think? Like I said, IMHO there is no need for this flexibility, UTF-8 is the standard/default, it makes no sense to use another one, doing so is an error. https://en.wikipedia.org/wiki/Percent-encoding#Current_standard https://tools.ietf.org/html/rfc3986 (which obsoletes 3 older ones) Unless you can point me to some still relevant RFC that says otherwise, I am afraid things will stay as they are. But it is good that you were able to deal with your requirement - your code might be useful for others. Sven > Thanks for Zinc! > > Cheers, > Bernhard > > <ZnEncodingUrl.st> >> Am 28.06.2016 um 22:16 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> Bernard, >> >> I understand the issue, but this is not so easy to fix. >> >> I must start by saying that encoding a (part of) a URL with anything but UTF-8 is wrong (how would the receiver know, unless you have a mutual external agreement). So I guess you must be using some old web service. >> >> The solution is to make your own ZnUrl subclass and overwrite #encodePath:on: >> >> Then you just instanciate your subclass from elementary parts (no encoding) and pass it to ZnClient>>#url: as an object, not a string. >> >> Mind you, I haven't tried this yet. >> >> Sven >> >>> On 28 Jun 2016, at 20:26, Bernhard Pieber <bernhard(a)pieber.com> wrote: >>> >>> 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 30, 2016

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

by Tudor Girba

Hi, > 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}} Yes I know :). An instance of Pragma denotes an concrete annotation of a method. I now would like a meta-object that describes all Pragma instances having the same selector. For example, the protocol on the class side of the Pragma class is actually a query protocol that is better suited for the instance side of a PragmaDescription meta-object. For example: Pragma class>>allNamed: aSymbol in: aClass would become PragmaDescription>>pragmasIn: aClass and you would use it like: (PragmaDescription named: aSymbol) pragmasIn: aClass Creating an instance of PragmaDescription would imply searching the image for the <pragma:> definition. I would also like to have a Flyweight pool per environment such that we always get only one instance of a PragmaDefinition per selector (like it happens with Symbols). > So we could add the information you want to Pragma, and have it be lazy. It does not quite belong to the Pragma. A comment is common to all Pragma instances, and having it duplicated at the instance level is less elegant. But, looking for the users (all senders of the pragma selector - the methods that use the annotation) of a Pragma would be even less inconvenient to have on the instance side of Pragma. > 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. The design sketched above would require no runtime penalty for a Pragma instance. All code that works now would work identically afterwards. We would only have one selector in Pragma to get the corresponding description: Pragma>>description ^ PragmaDescription named: self selector Alternatively, we could modify the compilation to associate the PragmaDescription in an inst var of a Pragma instance. So, CompiledMethod>>pragmas would always return instances of Pragmas with a PragmaDefinition inst var. I think I would start with the lazy lookup first, and this would disturb nothing from the current behavior. > 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 > > 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 "Not knowing how to do something is not an argument for how it cannot be done."

June 30, 2016

Re: [Pharo-dev] Percent-encoding problem

by Bernhard Pieber

Hi Sven, Thanks for the answer. I needed to overwrite encodeQuery:on: and printQueryOn: for my use case. See attachment. I think being able to optionally configure the characterEncoder would be useful for ZnUrl in general. ZnUrl would then need to pass the characterEncoder to all calls to ZnResourceMetaUtils, not only to some like now. That would also be more consistent. Having ZnResourceMetaUtils use ZnUTF8Encoder by default seems a bit dangerous also. What do you think? Thanks for Zinc! Cheers, Bernhard > Am 28.06.2016 um 22:16 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Bernard, > > I understand the issue, but this is not so easy to fix. > > I must start by saying that encoding a (part of) a URL with anything but UTF-8 is wrong (how would the receiver know, unless you have a mutual external agreement). So I guess you must be using some old web service. > > The solution is to make your own ZnUrl subclass and overwrite #encodePath:on: > > Then you just instanciate your subclass from elementary parts (no encoding) and pass it to ZnClient>>#url: as an object, not a string. > > Mind you, I haven't tried this yet. > > Sven > >> On 28 Jun 2016, at 20:26, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> >> 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 30, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] b51a9d: 60128

by Esteban Lorenzano

looks like something went wrong > On 30 Jun 2016, at 19:50, stepharo <stepharo(a)free.fr> wrote: > > what were the changes? > > > Stef > > > Le 30/6/16 Ã 14:49, GitHub a Ã©crit : >> Branch: refs/heads/6.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 >> https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca3… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2016-06-30 (Thu, 30 Jun 2016) >> >> Changed paths: >> M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st >> M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st >> M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st >> M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st >> M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st >> M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st >> M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st >> A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st >> A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st >> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st >> M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st >> A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st >> R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st >> A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st >> M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> >> Log Message: >> ----------- >> 60128 >> Moose >> >> http://files.pharo.org/image/60/60128.zip >> >> > >

June 30, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] b51a9d: 60128

by stepharo

what were the changes? Stef Le 30/6/16 Ã 14:49, GitHub a Ã©crit : > Branch: refs/heads/6.0 > Home: https://github.com/pharo-project/pharo-core > Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 > https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca3… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-06-30 (Thu, 30 Jun 2016) > > Changed paths: > M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st > A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st > M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st > M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st > A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st > M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st > A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st > M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st > A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st > M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st > M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st > A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st > A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st > M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st > M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st > A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st > M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 60128 > Moose > > http://files.pharo.org/image/60/60128.zip > >

June 30, 2016

Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready

by Marcus Denker

> On 30 Jun 2016, at 14:57, John Brant <brant(a)refactoryworkers.com> wrote: > > On 06/30/2016 03:17 AM, Marcus Denker wrote: > >> I added a new Code-Critic rule "RBDeadBlockRule", with >> >> initialize >> super initialize. >> self matcher >> matches: '`{:node | node isBlock and: [node parent isSequence >> and: [ node isLastStatementInBlock not ]]}' >> do: [ :node :answer | node ] > > Instead of "node parent isSequence and: [ node isLastStatementInBlock not ]", you can use "node isUsed not". > Nice! I have submitted a patch to change it. Marcus

June 30, 2016

Re: [Pharo-dev] Subscription Form to FogBugz

by Alexandre Bergel

Thanks Tomas! Alexandre > On Jun 30, 2016, at 8:08 AM, Tomas Saez Binelli <tomas.saezbin(a)gmail.com> wrote: > > it's fixed! > thanks > > bye! Tomas > > 2016-06-30 1:15 GMT-04:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yeah, noâ¦ there was a problem with credentials in app. > can you try again? > > thanks, > Esteban > > > On 29 Jun 2016, at 23:56, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli > > <tomas.saezbin(a)gmail.com> wrote: > >> Hi everybody! > >> > >> I was trying to create an account on Fogbugz during a Sprint using the link > >> posted here: > >> > >> https://pharo.fogbugz.com/ > >> > >> But after filling the form and submiting it, i received the following > >> message: > >> > >> "Incorrect password or username" > >> > >> This is a little bit strange because i was not able to finish the > >> registration and create an account. > >> > >> Sending this email to make the error public. > >> > >> > >> Bye! > >> Tomas > >> > > > > Thanks for the report Tomas. I think I've seen this a long time ago, > > maybe your account was created but something went wrong with setting > > the password. As a work around, see if you can find a password reset > > button. > > > > cheers -ben > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2016

Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready

by John Brant

On 06/30/2016 03:17 AM, Marcus Denker wrote: > I added a new Code-Critic rule "RBDeadBlockRule", with > > initialize > super initialize. > self matcher > matches: '`{:node | node isBlock and: [node parent isSequence > and: [ node isLastStatementInBlock not ]]}' > do: [ :node :answer | node ] Instead of "node parent isSequence and: [ node isLastStatementInBlock not ]", you can use "node isUsed not". John Brant

June 30, 2016

[pharo-project/pharo-core] b51a9d: 60128

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60128 Moose http://files.pharo.org/image/60/60128.zip

June 30, 2016

[pharo-project/pharo-core]

by GitHub

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

June 30, 2016