- Pharo-dev - lists.pharo.org

Is there an official JSON parser/writer?

by Esteban A. Maringolo

Hi, tl;dr: Question: Which JSON library is the "recommended" one? Long: I'm modifying the PostgresV2 package to support JSON datatype but instead of using the JSON package from PharoExtras I'm trying to use NeoJSON. The problem is no JSON parser is bundled by default, so adding the dependency to either class is arbitrary. Regards! Esteban A. Maringolo

May 26, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Ben Coman

On Tue, May 26, 2015 at 9:38 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> I vote for renaming to Rectangle>>translatedBy:, because it returns a new >> translated rectangle instance. > > > -1 > There is no benefit in renaming a single method, apart from creating more > confusion. I wouldn't say "no benefit". Consistent conventions are beneficial. It could be useful to bring these into line with the general "-ed" convention of returning a new object. I don't see how this would create confusion, though it might create work. Whether its worth the work is a slightly different question. > If anything, the whole Rectangle API would have to be changed, as there is > plethora of similar methods (expandBy:, extendBy:, merge:, etc.) For a better feel of the work involved... Rectangle methods select: [ :m | m sourceCode includesSubstring: '^ Rectangle ' ]. Rectangle>>#intersect: Rectangle>>#quickMerge: Rectangle>>#encompass: Rectangle>>#intersect:ifNone: Rectangle methods select: [ :m | m sourceCode includesSubstring: '^Rectangle ' ]. Rectangle>>#intersect: Rectangle>>#translateBy: Rectangle>>#scaleBy: Rectangle>>#merge: Rectangle>>#compressTo: Rectangle>>#expandTo: Rectangle>>#roundTo: Rectangle>>#truncateTo: The following already follow the convention... Rectangle>>#compressed Rectangle>>#expanded Rectangle>>#rounded Rectangle>>#truncated > Pretty much all Rectangle messages are immutable and create new Rectangle, > thus I feel it is unnecessary to state it explicitly. > > In VW there is plenty of methods (e.g. left:) that mutates it, thus unlike > Pharo a clear distinction is required. Still, it is reasonable to consider the impact of inconsistent conventions on the rest of the system outside of Rectangle. cheers -ben

May 26, 2015

[pharo-project/pharo-core]

by GitHub

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

May 26, 2015

[pharo-project/pharo-core] d6a5f6: 50067

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d6a5f6e4931908ba03194a4b87f14b7c3da95746 https://github.com/pharo-project/pharo-core/commit/d6a5f6e4931908ba03194a4b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-26 (Tue, 26 May 2015) Changed paths: A OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages factored/emitCaseOf_otherwiseBlock_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages/emitCaseOfOtherwise_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages/emitCaseOf_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50066.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50067.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50066.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50067.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50067 15570 CaseOf: pattern from Opal is different from old compiler and breaks the JIT compiler https://pharo.fogbugz.com/f/cases/15570 http://files.pharo.org/image/50/50067.zip

May 26, 2015

Re: [Pharo-dev] Gofer upgrade error

by Ben Coman

Thanks Leo. Indeed I see the commands you tried are suggested in those references. On Tue, May 26, 2015 at 3:26 AM, Leo <lpaniceres(a)gmail.com> wrote: > Ben, > the documentation for "Gofer upgrade" is > http://file-pharo.inria.fr/doc/4.0/class/Gofer.html Doing this is 50064 I gives... 'MNU receiver of "default" is nil' in... GoferUnload>>unregisterPackageInfo: aWorkingCopy PackageOrganizer default unregisterPackage: aWorkingCopy packageInfo where PackageOrganizer is an unknown class. I've logged an issue... https://pharo.fogbugz.com/default.asp?15615 (whoops, I didn't notice Stef already created 15602) > and for "Gofer gofer update" > http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Gofer.pdf Doing this gives... 'MNU: MCWorkingCopy>>packageInfo' in... GoferCleanup>>cleanupCategories: aWorkingCopy aWorkingCopy packageInfo systemCategories do: [ :category | (SystemOrganization goferClassesInCategory: category) isEmpty ifTrue: [ SystemOrganization removeSystemCategory: category ] ] Doing this again but in 20628 gives... "The method MCPackageManager>>packageInfo has been deprecated. Use #packageSet" So there remain 9 senders of packageInfo in 50064. I wasn't sure what issue to log here. But the bigger question is how might we guard against this sort of thing slipping through when we remove deprecations from the Image? cheers -ben > afectuosamente > Leo > > Message: 5 > Date: Mon, 25 May 2015 23:59:38 +0800 > From: Ben Coman <btc(a)openinworld.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Gofer upgrade error > Message-ID: > <CAProBT=B2yzdjUWveea8w2c4PY_NH2ZuGk-TW-ZWhHC3iv9KzA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > > Hi Leo, > > I'm probably not the one able to provide a useful answer, but I'm > curious which documentation describes that procedure :) ? It looks > like something you might do in another different application. > > btw, which third party packages are you trying to update? > > cheers -ben > > > > P.S. Ideally all mail-list posts would be "plain text" (e.g. [1] for > gmail), but please at least refrain from using garish fonts :) > > [1] https://mathiasbynens.be/notes/gmail-plain-text > > > On Mon, May 25, 2015 at 9:54 PM, Leo Paniceres <lpaniceres(a)gmail.com> wrote: > > > Hi Stephan > I'm trying to have my image updated to the last version of each package > that I'm using. > I'm trying first: > Gofer upgrade (to update Gofer) > and then to update: > Gofer gofer update (also have an error) > > Any advice to have all my third party packages updated? > > Thanks > > > > ------------------------------ > > Message: 4 > Date: Mon, 25 May 2015 08:53:26 +0200 > From: stepharo <stepharo(a)free.fr> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Gofer upgrade error > Message-ID: <5562C6E6.901(a)free.fr> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hello leo > > Thanks for your feedback. We will fix this > > unregisterPackageInfo: aWorkingCopy > PackageOrganizer default > unregisterPackage: aWorkingCopy packageInfo > https://pharo.fogbugz.com/default.asp?15602 > > > I do not think that anybody ever used upgrade. :) > What do you want to do exactly? > have a look at the deep into pharo book, there is a chapter on Gofer. > > > Le 25/5/15 08:02, Leo a ?crit : > > I have a fresh image of Pharo 4 -just downloaded-. > > When I try > Gofer upgrade > > I receive a MessageNotUnderstood: receiver of default is nil. > > What is happening? > > thanks

May 26, 2015

[Update][Pharo4] 40614

by Marcus Denker

40614 15284 [Backport 4.0]: 15384 kommiter throws DNU when browsing remotes https://pharo.fogbugz.com/f/cases/15284 http://files.pharo.org/image/40/40614.zip

May 26, 2015

[pharo-project/pharo-core]

by GitHub

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

May 26, 2015

Re: [Pharo-dev] String>>#adaptToNumber:andSend:

by Marcus Denker

> On 26 May 2015, at 15:51, Florin Mateoc <fmateoc(a)gmail.com> wrote: > > On 5/26/2015 9:38 AM, Marcus Denker wrote: >> >>> On 26 May 2015, at 14:51, Florin Mateoc <fmateoc(a)gmail.com <mailto:fmateoc@gmail.com>> wrote: >>> >>> Hi Stef, >>> >>> I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the >>> strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus >>> the adaptTo...:andSend: methods) should simply be removed from String. >>> While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. >> >> I committed a slice: >> >> >> https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend> >> >> >> >> Marcus > > > Hi Markus, > > Thank you. > I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore > Ah, yes. I have updated the fix. Marcus

May 26, 2015

Re: [Pharo-dev] String>>#adaptToNumber:andSend:

by Florin Mateoc

On 5/26/2015 9:38 AM, Marcus Denker wrote: > >> On 26 May 2015, at 14:51, Florin Mateoc <fmateoc(a)gmail.com <mailto:fmateoc@gmail.com>> wrote: >> >> Hi Stef, >> >> I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the >> strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus >> the adaptTo...:andSend: methods) should simply be removed from String. >> While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. > > I committed a slice: > > https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend > > > Marcus Hi Markus, Thank you. I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore Florin

May 26, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Peter UhnÃ¡k

> > I vote for renaming to Rectangle>>translatedBy:, because it returns a new > translated rectangle instance. > -1 There is no benefit in renaming a single method, apart from creating more confusion. If anything, the whole Rectangle API would have to be changed, as there is plethora of similar methods (expandBy:, extendBy:, merge:, etc.) Pretty much all Rectangle messages are immutable and create new Rectangle, thus I feel it is unnecessary to state it explicitly. In VW there is plenty of methods (e.g. left:) that mutates it, thus unlike Pharo a clear distinction is required. Peter

May 26, 2015