July 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Sharing/Versioning Data

by Sean P. DeNigris

abergel wrote > Mime64 is your friend :-) Thanks for the pointer! I did a little experiment... how does this look? sampleObjectToSerialize := { Date today. Time now }. ba := ByteArray streamContents: [ :str | FLSerializer serialize: sampleObjectToSerialize on: str ]. storableInMethod := ba base64Encoded. FLMaterializer materializeFromByteArray: storableInMethod base64Decoded asByteArray. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4766933.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 8, 2014

Re: [Pharo-dev] Workaround monticello issue

by Sebastian Sastre

Hi Thierry, is a Pharo3.0 Latest update: #30851 with Gofer new url: 'http://ss3.gemstone.com/ss/FileTree'; package: 'ConfigurationOfFileTree'; load. ((Smalltalk at: #ConfigurationOfFileTree) project version: #'stable') load. in it thanks for taking a look! On Jul 7, 2014, at 6:18 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Sebastian, > > which version are you using? I looked into 3.0 and 4.0, and there is nothing there about setting packageList to nil in MCFileRepositoryInspector. > > Thierry > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Sebastian Sastre [sebastian(a)flowingconcept.com] > EnvoyÃ© : lundi 7 juillet 2014 22:45 > Ã : Pharo Development List > Objet : [Pharo-dev] Workaround monticello issue > > Hi there, > > Iâve just hit an issue that prevented to open packages in monticello > > MessageNotUnderstood: receiver of "indexOf:" is nil > UndefinedObject(Object)>>doesNotUnderstand: #indexOf: > MCFileRepositoryInspector>>packageSelection > PluggableListMorph>>getCurrentSelectionIndex > PluggableListMorph>>updateList > PluggableListMorph>>update: > MCFileRepositoryInspector(Object)>>changed: in Block: [ :aDependent | aDependent update: aParameter ] > DependentsArray>>do: > MCFileRepositoryInspector(Object)>>changed: > MCFileRepositoryInspector>>refresh > MCFileRepositoryInspector>>setRepository:workingCopy: in Block: [ ... > BlockClosure>>newProcess in Block: [ ... > > This is what Iâm using as hacky workaround: > > > MCFileRepositoryInspector>>packageSelection > ^ self packageList isNil > ifTrue:[ 1 ] > ifFalse:[ self packageList indexOf: selectedPackage ] > > The problem is that packageList is nil for some reason. > > Looks like filetree is involved since > 1. Iâm using it and > 2. it sets an extension method #refresh that makes packageList := nil > > > > > sebastian > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept

July 7, 2014

[Article] Elegant Pharo Code

by Sven Van Caekenberghe

Hi, I have written a new article presenting Pharo using a list of 23 short examples. Elegant Pharo Code Beautiful & Powerful One-liners, Expressions and Snippets https://medium.com/@svenvc/elegant-pharo-code-bb590f0856d0 As mentioned at the end of the article, I welcome feedback, remarks, comments, alternative solutions and other examples. The idea is to create yet another way to lure people into exploring Pharo while explaining by example why we like Pharo. Enjoy! Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

July 7, 2014

Re: [Pharo-dev] Workaround monticello issue

by GOUBIER Thierry

Hi Sebastian, which version are you using? I looked into 3.0 and 4.0, and there is nothing there about setting packageList to nil in MCFileRepositoryInspector. Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Sebastian Sastre [sebastian(a)flowingconcept.com] EnvoyÃ© : lundi 7 juillet 2014 22:45 Ã : Pharo Development List Objet : [Pharo-dev] Workaround monticello issue Hi there, Iâve just hit an issue that prevented to open packages in monticello MessageNotUnderstood: receiver of "indexOf:" is nil UndefinedObject(Object)>>doesNotUnderstand: #indexOf: MCFileRepositoryInspector>>packageSelection PluggableListMorph>>getCurrentSelectionIndex PluggableListMorph>>updateList PluggableListMorph>>update: MCFileRepositoryInspector(Object)>>changed: in Block: [ :aDependent | aDependent update: aParameter ] DependentsArray>>do: MCFileRepositoryInspector(Object)>>changed: MCFileRepositoryInspector>>refresh MCFileRepositoryInspector>>setRepository:workingCopy: in Block: [ ... BlockClosure>>newProcess in Block: [ ... This is what Iâm using as hacky workaround: MCFileRepositoryInspector>>packageSelection ^ self packageList isNil ifTrue:[ 1 ] ifFalse:[ self packageList indexOf: selectedPackage ] The problem is that packageList is nil for some reason. Looks like filetree is involved since 1. Iâm using it and 2. it sets an extension method #refresh that makes packageList := nil sebastian<https://about.me/sebastianconcept> o/ blog: http://sebastianconcept.com<http://sebastianconcept.com/> LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

July 7, 2014

Workaround monticello issue

by Sebastian Sastre

Hi there, Iâve just hit an issue that prevented to open packages in monticello MessageNotUnderstood: receiver of "indexOf:" is nil UndefinedObject(Object)>>doesNotUnderstand: #indexOf: MCFileRepositoryInspector>>packageSelection PluggableListMorph>>getCurrentSelectionIndex PluggableListMorph>>updateList PluggableListMorph>>update: MCFileRepositoryInspector(Object)>>changed: in Block: [ :aDependent | aDependent update: aParameter ] DependentsArray>>do: MCFileRepositoryInspector(Object)>>changed: MCFileRepositoryInspector>>refresh MCFileRepositoryInspector>>setRepository:workingCopy: in Block: [ ... BlockClosure>>newProcess in Block: [ ... This is what Iâm using as hacky workaround: MCFileRepositoryInspector>>packageSelection ^ self packageList isNil ifTrue:[ 1 ] ifFalse:[ self packageList indexOf: selectedPackage ] The problem is that packageList is nil for some reason. Looks like filetree is involved since 1. Iâm using it and 2. it sets an extension method #refresh that makes packageList := nil sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

July 7, 2014

Re: [Pharo-dev] Athens and TextMorphs

by Nicolai Hess

What about the other morphs not fully drawable on athens (Polygonmorph, MenuItemMorph). I can implement the missing drawOnAthens methods. Or do we have other plans with it? 2014-07-02 13:38 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi nicolai > > what would be good is to give feedback to igor on the TxText because this > is the future :) > > Stef > > > > > Working with Text and Athens only works for FreeType fonts and >> with Athens primitive drawString: method. >> Morphs with Text can not be used on an Athens. >> (No TextMorph rendering and no font emphasis on String or LabelMorph). >> >> But there is a AthensText package with some classes for >> text morph/renderer/scanner/paragraph. >> These are only used in AthensTextRenderTest and AthensTextMorph >> both don't work and AthensTextMorph should not be used (?) >> Classcomment: "this class is subject of changes/removal. do not use it." >> >> Where do we go from here? >> What is supposed to work and is it worth while to fix the >> missing/wrong implementations? >> >> >> nicolai >> >> >

July 7, 2014

Contributing to Spec

by Yuriy Tymchuk

Hi, how can I contribute to Spec? Should I open a pull request on github? Uko

July 7, 2014

Re-run lint rule for a single method(class)

by Yuriy Tymchuk

Hi everyone, One usual practice about rerunning SmallLint rules is to execute #resetResult first. This is fine, but what if I have run in on a bit environment, then changed a single method and I want to re-run the rule for that method. Is there a common way to remove one specific critic from the ruleâs result? Uko

July 7, 2014

Re: [Pharo-dev] ZnNewLogEvent warning

by Sebastian Sastre

On Jul 7, 2014, at 4:07 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > *You* are not missing something, the configuration is. SSO does not properly depend on the core Zinc-HTTP package. I will fix that later. If you swap the two expressions, loading WebSocket before SSO, it should work. > > Sven Thanks Sven! Just to let you know, Iâve did (Smalltalk at:#ConfigurationOfZincHTTPComponents) project latestVersion load: 'WebSocket'. (Smalltalk at:#ConfigurationOfZincHTTPComponents) project latestVersion load: 'SSO'. in a new image and warning still pops up. Anyway, Iâm not stuck because of this, things end up loading and working sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept

July 7, 2014

[pharo-project/pharo-core]

by GitHub

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

July 7, 2014