- Pharo-dev - lists.pharo.org

Shorter Pharo Launcher download link

by Dmitri Zagidulin

This is in the same vein as Sean's recent 'Clean up Download Instructions' email. While updating the Pharo By Example chapter on installing Pharo, we decided to mention the Pharo Launcher project as a convenient way to use multiple images, etc. Unfortunately, as far as I know, the download link for it is: https://ci.inria.fr/pharo/view/Launcher/job/Launcher/PHARO=40,VERSION=stabl… (And even then, you have to scroll down to the tiny 'Last Successful Artifacts' section). That's a bit awkward to put in a book for people to type out, to say the least. Is there any way we can either: 1) Use an existing URL shortener to link to that 2) Have some Apache-redirected URLs off of pharo.org? Something like pharo.org/launcher/ that would have the download links to the various Launcher builds? The same also goes for some of the books, by the way. In a later chapter, we link to Pharo for the Enterprise, and we actually type out the link: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… Sub-optimal. :)

April 10, 2015

[Urgent]: Clean up Download Instructions before 4.0 Release

by Sean P. DeNigris

Esteban A. Maringolo wrote > This particular comment let me hanging though: > https://news.ycombinator.com/item?id=5395496 > > We should pay special attention to those feedbacks, otherwise we'll be > always "preaching to the choir". We handled two out of three of the poster's difficulties: 1. Nuke one-click in favor of platform-specific downloads 2. Add a warning about the 32-bit lib requirement to the download to the README However... I tried installing on Ubuntu and Debian from the perspective of a new user based on the instructions at http://pharo.org/download and they are a shambles! Very confusing and incomplete. Two requests: - some clarifications and changes are straightforward and non-controversial. Will someone give me access to edit the website directly? - for the rest, and things I'm not sure about, I created https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Download… to keep track of things that need to be changed I also created Issue 15328: "Clean up Download Instructions before 4.0 Release" https://pharo.fogbugz.com/default.asp?15328 which references the roadmap ----- Cheers, Sean -- View this message in context: http://forum.world.st/Urgent-Clean-up-Download-Instructions-before-4-0-Rele… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 10, 2015

Fwd: [Moose-dev] Re: Wrong version loaded using Metacello

by stephan

-------- Forwarded Message -------- Subject: [Moose-dev] Re: Wrong version loaded using Metacello Date: Fri, 10 Apr 2015 17:10:54 +0200 From: Jan KurÅ¡ <kurs.jan(a)gmail.com> Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> To: Moose-related development <moose-dev(a)iam.unibe.ch> Hi Dale, That works for me! Do you have any idea, when will this fix appear in Pharo? Thank you for fixing this! Cheers, Jan On 9 April 2015 at 04:33, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: Jan, I believe that I've fixed the bug [1], but of course the proof will be in the pudding:) So If you could run the following Metacello update script in your image (this will work in pharo3.0 or pharo4.0) and make sure it works for you: Metacello new Ã baseline: 'Metacello'; Ã repository: 'github://dalehenrich/metacello-work:master/repository'; Ã get. Metacello new Ã baseline: 'Metacello'; Ã repository: 'github://dalehenrich/metacello-work:master/repository'; Ã onConflict: [:ex | ex allow]; Ã load The proper package was loaded for me in my test in Pharo3.0: Ã Ã Ã Loaded -> PetitIndent-JanKurs.1 --- http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- cache Dale [1] https://github.com/dalehenrich/metacello-work/issues/339 On 04/08/2015 12:14 AM, Jan KurÃÂ¡ wrote: > Dale, Thank you for the information and your help. And honestly, I > am surprised as well :) > > Cheers, > Jan > > On 7 April 2015 at 23:21, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Jan, > > This looks like a bug in MetacelloGoferPackage>>matches: ...Ã > I've submitted a bug[1] and will work on getting a patch out > as soon as I can ... I am a bit surprised that this particular > bug has remained hidden (or unreported) for so long, but it is > a good find ... thanks for provided the details I needed to > identify the problem ... > > Dale > > [1] https://github.com/dalehenrich/metacello-work/issues/339 > > > On 04/07/2015 09:08 AM, Jan KurÃÂ¡ wrote: >> Hi Dale, >> >> One can reproduce the behaviour by evaluating this in Pharo 3 >> or Pharo 4 image: >> >> Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; >> Ã Ã Ã configurationOf: #PetitParser; load. >> >> (ConfigurationOfPetitParser project version: '1.10') load. >> >> The first command loads (in my case) >> ConfigurationOfPetitParser (JanKurs.68) >> >> When I evaluate: >> (ConfigurationOfPetitParser project version: '1.10') record >> asString. >> >> I get: >> a MetacelloNullRecordingMCSpecLoader(linear load : >> Ã Ã Ã linear load : 1.10 [ConfigurationOfPetitParser] >> Ã Ã Ã Ã Ã Ã load : ConfigurationOfGlamour >> Ã Ã Ã atomic load : 1.10 [ConfigurationOfPetitParser] >> Ã Ã Ã Ã Ã Ã load : PetitParser-JanKurs.262 >> Ã Ã Ã Ã Ã Ã load : PetitTests-JanKurs.67 >> Ã Ã Ã Ã Ã Ã Ã ... >> Ã Ã Ã Ã Ã Ã Ã ... >> Ã Ã Ã Ã Ã Ã load : PetitIslands-JanKurs.18 >> Ã Ã Ã Ã Ã Ã load : PetitIndent-JanKurs.1 >> Ã Ã Ã Ã Ã Ã load : Factorial-Language-lr.6 >> Ã Ã Ã Ã Ã Ã explicit load : Glamour >> Ã Ã Ã Ã Ã Ã Ã Ã Ã load : ConfigurationOfGlamour-AndreiChis.203 >> Ã Ã Ã Ã Ã Ã linear load : 3.0.6 [ConfigurationOfGlamour] >> Ã Ã Ã Ã Ã Ã Ã ... >> >> >> Yet if I really load, the transcript shows (see the full >> transcript in the attachement): >> >> >> Loading 1.10 of ConfigurationOfPetitParser... >> Fetched -> ConfigurationOfGlamour-AndreiChis.203 --- >> http://smalltalkhub.com/mc/Moose/Glamour/main/ --- >> http://smalltalkhub.com/mc/Moose/Glamour/main/ >> Loaded -> ConfigurationOfGlamour-AndreiChis.203 --- >> http://smalltalkhub.com/mc/Moose/Glamour/main/ --- >> /home/kursjan/tmp/pharo16/package-cache >> Fetched -> PetitParser-JanKurs.262 --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ >> Fetched -> PetitTests-JanKurs.67 --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ >> ... >> ... >> Fetched -> PetitIndent-JanKurs.11 --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ --- >> http://smalltalkhub.com/mc/Moose/PetitParser/main/ >> ... >> ... >> >> >> >> Cheers, >> Jan >> >> On 6 April 2015 at 23:23, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Jan, >> >> I would really like to see the Transcript output for this >> load .... also I'd like to know which mcz version of >> ConfigurationOfPetitParser you are using ... I can guess, >> but there are often a number of different versions of >> configurations floating around and I don't want to waste >> time on a version that does not match the one that you >> are having trouble with ... >> >> Dale >> >> >> On 04/04/2015 03:01 AM, Jan KurÃÂ¡ wrote: >>> Hi All, >>> >>> In ConfigurationOfPetitParser, there is a stable version >>> 1.10 for Pharo 3.0 which says to load version >>> PetitIndent.JanKurs.1. >>> >>> version110: spec >>> Ã Ã Ã <version: '1.10' imports: #('1.6-baseline' )> >>> >>> Ã Ã Ã spec for: #'common' do: [ >>> >>> Ã Ã Ã .. >>> Ã Ã Ã package: 'PetitIndent' with: 'PetitIndent-JanKurs.1'; >>> Ã Ã Ã .. >>> >>> Yet, if I load the stable version from Pharo 3.0: >>> >>> Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; >>> Ã Ã Ã configurationOf: #PetitParser; load. >>> (ConfigurationOfPetitParser project version: '1.10') load. >>> >>> >>> >>> I got PetitIndent.JanKurs.11 loaded, which is very >>> unfortunate, since other packages are kept old. >>> >>> Does anyone knows why is this? >>> >>> Cheers, >>> Jan >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

April 10, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by ClÃ©ment Bera

Well I guess I used to click proceed and not close the debugger... 2015-04-10 1:24 GMT-07:00 Max Leske <maxleske(a)gmail.com>: > For a little more context: the issue was originally raised by Clara in the > thread titled "MNU: receiver of "stepToCallee:" is nilâ. IIRC the issue > was easily reproducible when debugging a test, then closing the debugger > (via the close icon). Clicking âProceedâ on the other hand gracefully > terminated the process. > > Cheers, > Max > > > On 10 Apr 2015, at 09:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> I was using it frequently too and I have never experienced any issues... >> > > Ok, can you describe a use case, what test case you can start and > close the debugger without image freeze? > > Maybe we can find what is the difference between that > test case and those that freeze the image, and than find a fix. > > >> >> 2015-04-09 14:58 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> >>> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> >>>> No Debug Tests? >>>> >>>> Geez, I am using that all the time. >>>> >>> >>> And you're never encountered this issue 14689 >>> <https://pharo.fogbugz.com/default.asp?14689>? >>> Or did this work in older versions? >>> >>> >>> >>> >>>> >>>> Phil >>>> >>>> >>>> On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr> >>>> wrote: >>>> >>>>> >>>>> > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)clipperadams.com> >>>>> wrote: >>>>> > >>>>> > Nicolai Hess wrote >>>>> >> >>>>> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… >>>>> > >>>>> > Ah, I miss that too! From that thread, it seems it was removed >>>>> temporarily >>>>> > until we have real breakpoints. Is there an issue for its return? >>>>> > >>>>> >>>>> Not yet. >>>>> >>>>> Marcus >>>>> >>>> >>>> >>> >> > >

April 10, 2015

Problem during the loading of setting on Pharo 4

by Ferlicot D. Cyril

Hi ! I use Pharo Launcher and each time I open a new Pharo 4 image, this image load my Pharo 4 settings. But since the version 40601 when Pharo load the settings i've an error: "MessageNotUnderstood: GTPlayBook class>> customDirectory:". If others have the same problem i'll open a bug repport.

April 10, 2015

[pharo-project/pharo-core]

by GitHub

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

April 10, 2015

[pharo-project/pharo-core] b6fb1c: 40602

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b6fb1c3d3af2e05b10b54d8fea6596dbfbe85e12 https://github.com/pharo-project/pharo-core/commit/b6fb1c3d3af2e05b10b54d8f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-10 (Fri, 10 Apr 2015) Changed paths: M NativeBoost-Tests.package/NBInterpreterProxyTest.class/instance/tests/testStackPointer.st M NativeBoost-Tests.package/NBInterpreterProxyTest.class/instance/tests/testStackPointer2.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script601.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script602.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40601.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40602.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40602 15317 NBInterpreterProxyTest #testStackPointer and #testStackPointer2 fail on Windows with new VM https://pharo.fogbugz.com/f/cases/15317 http://files.pharo.org/image/40/40602.zip

April 10, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by Ben Coman

I find the tree view in Playground really useful. I like the sense of vertical searching, and I like the way that I can open multiple paths and compare them by scrolling up and down. Without it you can only drill down one path at a time. I guess an equivalent feature would multi-selecting from a list of items and having a vertical stack of panes scrolled horizontal in a synchronous way. cheers -ben On Fri, Apr 10, 2015 at 4:44 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 9/4/15 08:49, Tudor Girba a Ã©crit : > > Hi Stef, > > This Raw view is the result of many debates and negotiations. We can > safely say it was designed by committee. > > As I mentioned before, I think the tree is overkill in this context and > it makes things unnecessarily slow. > > Totally agree on this one. It defeats the purpose of navigation. > To me this is terrible. > > > But, we will try better for Pharo 5 :) > > Cheers, > Doru > > On Fri, Apr 3, 2015 at 7:23 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> The Playground has inspect on Cmd+Shift+i as requested by you. >> >> >> Ok good to know because this is important. >> What aboout an help? >> >> >> There is a problem with the update as it does not scale in the current >> form. Please see the reply of Andrei. We will likely remove that feature >> for the release. >> >> Just to clarify: When did we ever say that someone is stupid? >> >> >> Esteban told me that it was not freezing when we had to trash the image. >> Just that the machine was slow. To me this is a non answer. >> >> >> If we could get a real raw = basic inspect tabe then we can use GT and >> work. >> To me the raw tab with an explorer inside is counterproductive: we can >> get lost, it is slow, it does not work well with navigation of GT. >> >> Cheers, >> Doru >> >> >> >> On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> This morning GTInspector was so slow that it blocked the complete system >>> on the machine of Cyril. :( >>> We can tell him that he is stupid to have a bad machine or we could try >>> to use this to see how >>> we can help our users. >>> >>> So we had to use basicInspect to get our job done (once we ctrl-. to >>> escape the render hell) >>> because raw uses a tree morph. >>> >>> Why raw cannot reproduce the old simple and working basicInspect >>> then we could have a "basic" inspect on double click to avoid to use >>> this bad tree and that we can work. >>> >>> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. >>> Even on my superfast machine is >>> is sluggish. >>> >>> I really think that we should support backdoors. >>> We need to have a mini browser, a mini debugger and a working inspector. >>> >>> Setf >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

April 10, 2015

Re: [Pharo-dev] Problem with asClass usage

by phil＠highoctane.be

On Fri, Apr 10, 2015 at 2:35 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The Gofer script does not solve the problem of triggering a special > loading selector in the ConfigurationOfXYZ. Furthermore, asClass can be > used for other usages as well, but it is clear that it is intended for > scripts and not for production code. For example, I recently sent around a > script that showed this: > > Object subclass: #AClass > instanceVariableNames: '' > classVariableNames: '' > category: 'XYZ'. > #AClass asClass compile: 'someMethod'. > ... > That's how some methods are patched upon system startup in a startup script of mine. Some value ranges etc can be set by a sysadmin in a couple files. > > I do agree that checking the existence of classes should not happen > explicitly in code. For example, the code in Brick that checks for classes > should not exist at all. > > However, removing asClass will only change the way a class can be looked > up from a string. It will still not prevent people to look classes up by > symbols in the code. In my mind: > - saying: "#AClass asClass" > - should have the same semantics as saying "AClass" > +1 > > All in all, I think asClass has a legitimate usage, but we should > certainly combat explicit class checking in code. > +1 x 2 > > Cheers, > Doru > > > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

April 10, 2015

Re: [Pharo-dev] Problem with asClass usage

by Tudor Girba

Hi, The Gofer script does not solve the problem of triggering a special loading selector in the ConfigurationOfXYZ. Furthermore, asClass can be used for other usages as well, but it is clear that it is intended for scripts and not for production code. For example, I recently sent around a script that showed this: Object subclass: #AClass instanceVariableNames: '' classVariableNames: '' category: 'XYZ'. #AClass asClass compile: 'someMethod'. ... I do agree that checking the existence of classes should not happen explicitly in code. For example, the code in Brick that checks for classes should not exist at all. However, removing asClass will only change the way a class can be looked up from a string. It will still not prevent people to look classes up by symbols in the code. In my mind: - saying: "#AClass asClass" - should have the same semantics as saying "AClass" All in all, I think asClass has a legitimate usage, but we should certainly combat explicit class checking in code. Cheers, Doru

April 10, 2015