December 2017 - Pharo-users

Re: [Pharo-users] Running headless on Windows

by Denis Kudriashov

Hi. I think there is separate PharoConsole.exe for headless on Windows 2017-12-27 16:39 GMT+01:00 Andrei Stebakov <lispercat(a)gmail.com>: > When I run Pharo 6.1 with -- headless option on Windows, it executes the > eval command as expected but during the execution (which lasts 4 sec) it > opens the Pharo GUI. > Is it expected? I thought headless means that the whole execution would > happen in the background >

Dec. 27, 2017

Running headless on Windows

by Andrei Stebakov

When I run Pharo 6.1 with -- headless option on Windows, it executes the eval command as expected but during the execution (which lasts 4 sec) it opens the Pharo GUI. Is it expected? I thought headless means that the whole execution would happen in the background

Dec. 27, 2017

Re: [Pharo-users] Breakpoints in Pharo

by Nicolai Hess

2017-12-27 10:49 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-12-27 10:37 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> Works for me too (on windows). >> But sometimes, a change and accept of the current method, does not >> removes the "Breakpoint"-Icon. >> So, it looks like there is a breakpoint, but isn't anymore and the code >> of course does not trigger the debugger. >> The icon vanishes, if I unselect and select the current method. >> > > I think it is fixed in Calypso > In Nautilus, I traced this bug back to NautilusUI>>methodModified: anAnnouncement ... (selectedMethod = oldMethod ) ifTrue: [ self sourceTextModel hasUnacceptedEdits ifTrue: [ self forceSelectedMethod: method. self updateCategoryAndMethodList. self highlightCategory: method] ifFalse: [ self selectedMethod: method. self updateCategoryAndMethodList ]] ifFalse: [self updateCategoryAndMethodList ] "<<< If compiled method changed, we do not call forceSelectMethod, which would reset the icon styler" > > 2017-12-27 10:27 GMT+01:00 kmo <voxkmp(a)gmail.com>: >> >>> Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So >>> presumably >>> this is a Pharo on Windows issue. >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >

Dec. 27, 2017

in-image pharo user objet ?

by CÃ©drick BÃ©ler

Hi all, For now, it is asked (by convention) a string containing our first name and last name (when code is submitted). Just wandering if you could have a better representation of a user of a Pharo image. Could we imagine a user id instead ? That shouldnât be heavy to deal with and eventually one could add more functionalities (one being the authentification to a pharo based application). The difficulty is to find a proper universal user id. I would have used something that encode date and place of birth in the id but it suffers some privacy related issues. Any ideas ? Another question is if an image may be used by several people ? To me allowing one user is ok for a developer image but it might be interesting to switch user spaces if itâs for a pharo application ? Cheers, CÃ©drick

Dec. 27, 2017

Re: [Pharo-users] Usability issues with Calypso

by Denis Kudriashov

Hi Sean 2017-09-24 14:46 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Sean > > 2017-09-23 19:57 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Stephane Ducasse-3 wrote >> > Calypso is still an enfant and this is >> > IMPORTANT that people tell what >> > they do not like so that we can improve. >> >> A few more impressions now that I've been using Calypso as my default >> browser: >> - Overall really enjoying it! >> - When browsing a class from its own package, and then adding an extension >> protocol via '*...' in "New protocol" context menu, the dialog closes >> without objection, but then the new protocol doesn't seem to exist. I had >> to >> create a dummy protocol and then DND the methods into the >> package-to-be-extended. >> > > In Calypso you should not create protocols with star. In method editor > status bar there is explicit checkbox "extension" to specify external > package for the method. > We should move away from star convention and work directly with packages. > Calypso gives you the tools for this. > > But I will add special notification when user creates new protocol with > star. I think it will help "old" Pharo users to adopt. > https://github.com/dionisiydk/Calypso/issues/96 > It is done in latest stable version. In addition there is new behavior when user selects extended class (which is grey in class list): - extending package group is added to the method group list. It is placed just after "extensions" group. - extending package group is selected by default which shows only extended methods instead of all method - automatic selection of extended class side: - if instance side is extended then browser switches to instance side when you select it - if class side is extended then browser switches to class side when you select it - if both sides are extended there will be two classes in class list: "AClass" and "AClass class" It means that now when you select extended class the browser will show "expected" extended methods. You do not need anymore to scroll protocol list to find current package. And you do not need to guess where extension is actually defined: in instance side or in class side. > > >> - When Calypso is set to be the default browser, it would be helpful if >> the >> World menu item changed from "Calypso Browser" to "Nautilus" >> - Lack of word wrapping is becoming teeeeeeedious >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Dec. 27, 2017

Re: [Pharo-users] Breakpoints in Pharo

by Ben Coman

On 27 December 2017 at 07:26, Ben Coman <btc(a)openinworld.com> wrote: > Hi Andrei, > > On 26 December 2017 at 09:51, Andrei Stebakov <lispercat(a)gmail.com> wrote: > >> Can I expect that break points in Pharo work in the same way as in Visual >> Works? >> When I set a break point in Pharo (6.1 on Windows), it displays a red dot >> with an exclamation mark and when I send this message to an object, the >> debugger doesn't get invoked. >> > > Sorry I'm not familiar with VisualWorks. > If I define this method (Pharo 6.1 on Linux)... > Object >> myTest > "Object new myTest" > self halt. > self inform: 'test'. > > then evaluate the comment, a debugger is invoked. > > If your example is different, could you explain it in more detail? > > cheers -ben > By strange co-incidence, I've just experienced a similar problem, that I've never seen before. Slightly rearranging my previous example... Object >> myTest "Object new myTest" self inform: 'test'. self halt. evaluating the comment pops up 'test' but doesn't open a debugger at the "self halt". It was working earlier today, but since then I had an episode which opened a large number of debug windows. I guess it could somehow be related. Actually its worse, Spotter doesn't show any contents, and "1 inspect" from Playground does nothing, although that does work from the old Workspace. All a bit strange. I'll move to fresh Image. I can upload this Image if someone cared to give it a once over. btw, version info... Latest update: #60520 (64bit) Unix built on Aug 27 2017 20:00:40 Compiler: 4.6.3 VMMaker versionString VM: 201708271955 cheers -ben

Dec. 27, 2017

Re: [Pharo-users] Breakpoints in Pharo

by Denis Kudriashov

2017-12-27 10:37 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Works for me too (on windows). > But sometimes, a change and accept of the current method, does not removes > the "Breakpoint"-Icon. > So, it looks like there is a breakpoint, but isn't anymore and the code of > course does not trigger the debugger. > The icon vanishes, if I unselect and select the current method. > I think it is fixed in Calypso 2017-12-27 10:27 GMT+01:00 kmo <voxkmp(a)gmail.com>: > >> Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So >> presumably >> this is a Pharo on Windows issue. >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Dec. 27, 2017

Re: [Pharo-users] Breakpoints in Pharo

by Nicolai Hess

Works for me too (on windows). But sometimes, a change and accept of the current method, does not removes the "Breakpoint"-Icon. So, it looks like there is a breakpoint, but isn't anymore and the code of course does not trigger the debugger. The icon vanishes, if I unselect and select the current method. 2017-12-27 10:27 GMT+01:00 kmo <voxkmp(a)gmail.com>: > Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably > this is a Pharo on Windows issue. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Dec. 27, 2017

Re: [Pharo-users] Breakpoints in Pharo

by kmo

Just tried it in Pharo 6.1 on Linux 32 bit. Breakpoints work. So presumably this is a Pharo on Windows issue. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 27, 2017

Re: [Pharo-users] Pharo Catalog Submission

by Stephane Ducasse

Here is what cyril replied to me once "Classic smalltalkhub" Metacello new smalltalkhubUser: 'KevinLanvin' project: 'MaterialDesignLite'; "Same as: http://smalltalkhub.com/mc/KevinLanvin/MaterialDesignLite/main " configuration: 'MaterialDesignLite'; version: #development; load. "Classic github" Metacello new githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: 'development' "SHA/BranchName/Tag" path: 'src'; "Same as: 'github://DuneSt/MaterialDesignLite:development/src'" baseline: 'MaterialDesignLite'; load. "With groups" Metacello new githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: 'development' path: 'src'; baseline: 'MaterialDesignLite'; loads: 'default'. Metacello new githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: 'development' path: 'src'; baseline: 'MaterialDesignLite'; loads: #('default' 'colors'). "In case of conflict" Metacello new githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish: 'development' path: 'src'; baseline: 'MaterialDesignLite'; onWarningLog; "Option to log warning instead of raising a UI element requiring user interaction" onConflictUseIncoming; "Can be #onConflictUseOutgoing or #onConflict:" load. On Wed, Dec 27, 2017 at 5:15 AM, Evan Donahue <emdonahu(a)gmail.com> wrote: > Hi, > > I have just finished making a BaselineOf and ConfigurationOf for submitting > my github-based project to the Pharo catalog. > > If my ConfigurationOf is with my code on github (via Iceberg), what > Metacello command should I run to test that it works correctly before > submitting to the catalog (to fetch the ConfigurationOf and then load it)? > > Thanks, > Evan

Dec. 27, 2017