- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

I would not do that. I think that removing the example pragma check is sufficient for now. Could we do it? Cheers, Doru On Wed, Apr 8, 2015 at 5:16 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-08 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> >> And, to have a better chance of having a clean slate discussion later on >> in which to consider the value we associate to names, I would like to >> remove the <example> check from isExampleMethod and continue to preserve >> the treatment of #example* selectors in Nautilus. >> >> > Wouldn't we need to change the check to: > > isExampleMethod > if selector starts with 'example' *AND HAS NOT* a <example> (or > <gtExample>) pragma > > because there are tons of #example* methods, some of them open an example > and some of them with the pragma, create an instance for the inspector? > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

Inspecting Slots raises an error

by Juraj Kubelka

Hi, I have tried to inspect Model allSlots and if I click on a slot it raises an error "WordLayout does not understand #definesSlot:â Is it problem of Slots or of GT-Inspector definition? Pharo #40597 Cheers, Juraj

April 9, 2015

Re: [Pharo-dev] source code mgmt issues in Pharo4

by Thierry Goubier

Le 08/04/2015 19:41, Johan Brichau a Ã©crit : > Hi all, > > Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. > > On several occasions, I had severe issues with the package management: > - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package > - versions of methods disappeared (i.e. no longer accessible in the version history of a method) > - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). > > This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. > > I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. > > Anyone experience similar issues? Hi Johan, Yuriy's issue with Komitter and GitFileTree is the same problem. I'd really need to have the ability to reproduce that. Or have access to an image where it has happened. I'd really like to inspect the relevant package working copy, its ancestry and the associated RPackage. Thierry

April 8, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Uko, you seem to have the same bug Johan is describing. MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. I've seen it happen at times, but rarely enough so I didn't pay attention to it. Thierry Le 08/04/2015 09:44, Yuriy Tymchuk a Ã©crit : > >> On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 07/04/2015 11:01, Yuriy Tymchuk a Ã©crit : >>> Hi, thank you very much for investigating this. >> >> You're working on it too :) >> >>> These are the steps to reproduce: >>> >>> 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) >>> 2. Add it as gitfiletree repo to the pharo image. >>> 3. Change something, commit part of the changes with Komitter. >>> 4. Change something more. >>> 5. Open Komitter, you should see a strange diff. >>> 6. Select 1 or 2 methods & commit them. >>> 7. Now you should have only 2 methods in your repo. >> >> I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). >> >> Can you show a screenshot at step 5? > > Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov > > Uko > >> >> Thierry >> > > >

April 8, 2015

source code mgmt issues in Pharo4

by Johan Brichau

Hi all, Over the last week, I started working with Pharo4, mostly to make Seaside work cleanly. On several occasions, I had severe issues with the package management: - methods that were changed in a class were not recorded as âchangedâ in monticello and were absent from the published package - versions of methods disappeared (i.e. no longer accessible in the version history of a method) - looking at the âchangedâ in Monticello showed all code of the package as changed (though only a single method has changed). This makes working with Pharo4 extremely problematic. I cannot trust the source code packaging/publishing and merging anymore. I cannot discern a scenario that leads to these issues but I do have an image right now where I only changed a single method and the entire package shows up as âchangedâ. Anyone experience similar issues? Johan

April 8, 2015

vm crash from BalloonEngine (maybe B2DPlugin or BitBltPlugin)

by Nicolai Hess

In order to reproduce it, draw a rectangle with radial gradient fill, with direction and normal, both of length 1. This one works (no vm crash): |form canvas fill direction normal| direction := 1@0. normal := 0@0. form := Form extent:300@300 depth:32. canvas := form getCanvas. fill := GradientFillStyle new colorRamp:{0 -> Color white . 0.5 -> Color green . 1 -> Color blue};origin:150@150 ;direction:direction;normal:normal;radial:true;yourself. canvas fillRectangle: (50@50 extent:200@200) fillStyle: fill. Display getCanvas drawImage: form at: 300@300. direction := 1@0. normal := 0@0. -> OK direction := 0@0. normal := 0@1. -> OK direction := 1@0. normal := 0@1. -> VM-Crash (Pharo and Squeak) Pharo: VM Version: Cog VM 4.0.0 (release) from Feb 16 2015 Compiler: gcc 4.6.2 Interpreter Build: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015 Cogit Build: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Feb 16 2015 Source Version: https://github.com/pharo-project/pharo-vm.git Commit: 55fbd0b0279998a4a33852f5afb3d213986cc3ae Date: 2015-02-16 17:54:00 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14895 Current byte code: -1 Primitive index: 117 Smalltalk stack dump: 0x24c830 M BalloonEngine>copyLoopFaster 0x6b09b80: a(n) BalloonEngine 0x24c848 M BalloonEngine>copyBits 0x6b09b80: a(n) BalloonEngine 0x24c860 M BalloonEngine>postFlushIfNeeded 0x6b09b80: a(n) BalloonEngine 0x24c884 I BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: 0x6b09b80: a(n) BalloonEngine 0x24c8b8 I BalloonCanvas>drawRectangle:color:borderWidth:borderColor: 0x6b099c0: a(n) BalloonCanvas 0x24c8e8 I BalloonCanvas>fillRectangle:basicFillStyle: 0x6b099c0: a(n) BalloonCanvas Squeak: VM Version: Cog VM 4.0.0 (release) from Aug 22 2013 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Interpreter Build: CoInterpreter VMMaker.oscog-eem.331 uuid: 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 Source Version: VM: r2776 http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Current byte code: -1 Primitive index: 117 nicolai

April 8, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Nicolai Hess

2015-04-08 10:20 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > And, to have a better chance of having a clean slate discussion later on > in which to consider the value we associate to names, I would like to > remove the <example> check from isExampleMethod and continue to preserve > the treatment of #example* selectors in Nautilus. > > Wouldn't we need to change the check to: isExampleMethod if selector starts with 'example' *AND HAS NOT* a <example> (or <gtExample>) pragma because there are tons of #example* methods, some of them open an example and some of them with the pragma, create an instance for the inspector?

April 8, 2015

Re: [Pharo-dev] About the singleton pattern

by Esteban A. Maringolo

2015-04-08 7:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 08 Apr 2015, at 12:01, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Wed, Apr 8, 2015 at 11:52 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> >> > On 08 Apr 2015, at 11:37, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> > Sometimes I use #new >> thatâs horrible! >> completely misleading > > > I'm curious, if it is singleton, should you worry from outside about the > fact that it is a singleton? Shouldn't that be hidden from the user? > > nope. > new means new. > you are confusing your user if you send a new message and you receive an > already existing (aka not new) object. > the literature existing always recommend to use an specific method (usually > #instance or #uniqueInstance, in smalltalk.. who decided to use > #uniqueInstance as a convention). +1 I like #current as the selector, because most of the times I use singleton as a globally accessible object. And as with any global reference it is good practice to avoid them as much as possible. Regards! Esteban A. Maringolo

April 8, 2015

Re: [Pharo-dev] New Pharo-Launcher package for Mac and Windows

by Sean P. DeNigris

Damien Cassou wrote > I've just renamed it to latest.dmg.md5sum. I think we are in sync. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-Pharo-Launcher-package-for-Mac-and-Windows-tp4815… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 8, 2015

Problem with asClass usage

by stepharo

Hi We want to raise a strong warning against the extension of the use of asClass and friends. asClass should not be used in Pharo distribution. I will propose to deprecate it. We are working on dependency analysis, module system, remote debugging and asClass introduces lose class references and many related problems. I would like to remove this behavior because it is clear that it will just grow up and lead to deadcode and ugly dependencies. First, most of the time you can avoid to query Smalltalk globals at: and that BY CONSTRUCTION a software system should be built and it should define its own customization. Second, at least use self class environment at: #foo Why is it much much much better? because it does not rely on String class resolution and as such is much more modular. You do not want to have the resolution of a symbol related to the place where String is defined but on where your code is actually. Imagine that tomorrow your code is in its own module. Then you want to know from your code point of you if a binding exist not from the one of environment in which String is. here are some examples: ============================== quadrangleClass ^ 'QuadrangleForTesting' asClass Strange it simply breaks. Of course it broke the smallLint rule. ============================== Metacello should better define OSProcess as a dependent.Because it is not clear what will happen if if not there? extractRepositoryFrom: zipFile to: directory "unzip <zipFile> into <directory>" | out err proc errorMessage | out := FileStream forceNewFileNamed: '/tmp/zip.out'. err := FileStream forceNewFileNamed: '/tmp/zip.err'. errorMessage := ''. [ proc := #OSProcess asClass thisOSProcess forkJob: '/usr/bin/unzip' arguments: {'-u'. zipFile. '-d'. directory} environment: nil descriptors: (Array with: nil with: out with: err). ================== I do not get why we need this funky logic. openInBrickWindowLabeled: aLabel #GLMSystemWindowBrick asClassIfAbsent: [ ^ self asMorph openInWindow ]. ^ #GLMSystemWindowBrick asClass new label: aLabel; color: Color transparent; addBrickBack: ( GLMBrick new vSpaceFill window "Answer the receiver's window." #GLMWindowBrick asClassIfAbsent: [ ^ self ownerThatIsA: SystemWindow ]. ^ (self ownerThatIsA: #GLMWindowBrick asClass) ifNil: [ self ownerThatIsA: SystemWindow ] sendUsageData: aBoolean | settingsClass | settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ self ]. ^ settingsClass sendUsageData: aBoolean sendUsageData | settingsClass | settingsClass := #GTSpotterEventRecorderSettings asClassIfAbsent: [ ^ false ]. ^ settingsClass sendUsageData

April 8, 2015